Cisco | Catalyst 6503-E Switch | Catalyst 6504-E Switch | Catalyst 6500 Series Switches | Catalyst 6506-E Switch | EOL Details | Catalyst 6509-E Switch | Catalyst 6509-NEB-A Switch | Catalyst 6509-V-E Switch | User manual | Release 15.1SY Supervisor Engine 2T Software

Cisco IOS Software Configuration Guide
Cisco IOS Release 15.1SY
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:
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 UCB’s 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)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
© October 1, 2016, Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface
45
Audience
45
Related Documentation
Conventions
45
45
Obtaining Documentation, Obtaining Support, and Security Guidelines
46
Product Overview
Product Overview
1-3
Supervisor Engine 2T-10GE Flash Memory Devices
Supervisor Engine 2T-10GE Ports
1-4
1-4
Supervisor Engine 2T-10GE Connectivity Management Processor (CMP)
Determining System Hardware Capacity
Module Status Monitoring
1-5
1-8
Enabling Visual Identification of Modules or Ports
User Interfaces
1-5
1-8
1-9
Software Features Supported in Hardware by the PFC and DFC
1-9
Configuration Fundamentals
Command-Line Interfaces
Accessing the CLI
2-1
2-1
Accessing the CLI through the EIA/TIA-232 Console Interface
Accessing the CLI through Telnet
Performing Command Line Processing
Performing History Substitution
Cisco IOS Command Modes
2-2
2-3
2-4
2-4
Displaying a List of Cisco IOS Commands and Syntax
Securing the CLI
2-2
2-6
2-7
ROM-Monitor Command-Line Interface
2-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1
Contents
Smart Port Macros
3-1
Prerequisites for Smart Port Macros
3-1
Restrictions for Smart Port Macros
3-2
Information About Smart Port Macros
3-3
Information about Cisco-Provided Smart Port Macros
Information about User-Created Smart Port Macros
Default Settings for Smart Port Macros
How to Configure Smart Port Macros
3-4
3-4
Using the Cisco-Provided Smart Port Macros
Creating Smart Port Macros
3-4
3-13
Verifying the Smart Port Macro Configuration
3-15
Virtual Switching Systems (VSS)
Virtual Switching Systems
4-1
Prerequisites for VSS
4-1
Restrictions for VSS
4-2
General VSS Restrictions
VSL Restrictions
4-2
4-2
Multichassis EtherChannel (MEC) Restrictions
Dual-Active Detection Restrictions
4-3
VSS Mode Service Module Restrictions
Information About Virtual Switching Systems
VSS Overview
4-4
4-4
VSS Redundancy
4-12
Multichassis EtherChannels
Packet Handling
4-15
4-18
System Monitoring
4-22
Dual-Active Detection
VSS Initialization
4-24
4-25
Default Settings for VSS
4-27
How to Configure a VSS
4-28
Converting to a VSS
4-28
Displaying VSS Information
4-35
Converting a VSS to Standalone Chassis
Configuring VSS Parameters
4-37
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2
4-4
4-35
4-2
3-3
3-4
Contents
Configuring Multichassis EtherChannels
4-45
Configuring Port Load Share Deferral on the Peer Switch
Configuring Dual-Active Detection
4-46
Configuring Service Modules in a VSS
4-50
Viewing Chassis Status and Module Information in a VSS
How to Upgrade a VSS
4-46
4-53
4-53
Performing a Fast Software Upgrade of a VSS
4-53
Performing an Enhanced Fast Software Upgrade of a VSS
4-55
High Availability
Enhanced Fast Software Upgrade
Prerequisites for eFSU
5-1
Restrictions for eFSU
5-2
Information About eFSU
eFSU Operation
5-1
5-3
5-3
Outage Time and Support Considerations
Reserving Module Memory
5-4
Error Handling for eFSU Preload
Default Settings for eFSU
5-5
How to Perform an eFSU
5-5
eFSU Summarized Procedure
Preparing for the Upgrade
5-4
5-5
5-5
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)
Forcing a Switchover from Active to Standby
5-10
5-10
Accepting the New Software Version and Stopping the Rollback Process (Optional)
Committing the New Software to the Standby
Verifying the Software Installation
Aborting the Upgrade Process
5-12
5-12
5-13
How to Upgrade a Non-eFSU Image to an eFSU Image
Fast Software Upgrade
5-14
6-1
Stateful Switchover (SSO)
7-1
Prerequisites for SSO
7-1
Restrictions for SSO
5-11
7-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3
Contents
General Restrictions
7-2
Configuration Mode Restrictions
Switchover Process Restrictions
Information About SSO
7-2
7-2
7-3
SSO Overview
7-3
SSO Operation
7-5
Route Processor Synchronization
SSO Operation
7-6
7-8
SSO-Aware Features
7-10
Default Settings for SSO
7-10
How to Configure SSO
7-10
Troubleshooting SSO
7-11
Possible SSO Problem Situations
SSO Troubleshooting
7-11
7-12
Verifying the SSO Configuration
7-12
Verifying that SSO Is Configured
7-12
Verifying that SSO Is Operating on the Device
Verifying SSO Features
7-13
Configuration Examples for SSO
Nonstop Forwarding (NSF)
7-16
8-1
Prerequisites for NSF
8-1
Restrictions for NSF
8-2
General Restrictions
8-2
Restrictions for BGP NSF
8-2
Restrictions for EIGRP NSF
8-2
Restrictions for OSPF NSF
8-2
Restrictions for IS-IS NSF
8-2
Restrictions for IPv6 NSF
8-3
Information About NSF
NSF Overview
8-3
8-3
Feature Interaction with NSF
Default Settings for NSF
How to Configure NSF
8-4
8-9
8-9
Configuring and Verifying BGP for NSF
Configuring and Verifying EIGRP NSF
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4
8-9
8-10
7-13
Contents
Configuring and Verifying OSPF NSF
Configuring and Verifying IS-IS NSF
8-12
8-13
Troubleshooting Cisco Nonstop Forwarding
Configuration Examples for NSF
8-14
8-15
Example: Configuring BGP NSF
8-15
Example: Configuring BGP NSF Neighbor Device
Example: Verifying BGP NSF
8-15
8-16
Example: Configuring EIGRP NSF Converge Timer
8-16
Example: EIGRP Graceful-Restart Purge-Time Timer Configuration
Example: Configuring EIGRP NSF Route-Hold Timer
Example: Configuring EIGRP NSF Signal Timer
Example: Verifying EIGRP NSF
Example: Configuring OSPF NSF
Example: Verifying OSPF NSF
Prerequisites for RPR
8-18
8-18
8-19
8-19
9-1
9-1
Restrictions for RPR
9-1
General RPR Restrictions
9-2
Hardware Restrictions for RPR
Information About RPR
9-2
9-2
Supervisor Engine Redundancy Overview
RPR Operation
8-17
8-18
Example: Configuring IS-IS NSF
Route Processor Redundancy (RPR)
8-17
8-17
Example: Disabling EIGRP NSF Support
Example: Verifying IS-IS NSF
8-16
9-3
9-3
Supervisor Engine Configuration Synchronization
Default Settings for RPR
How to Configure RPR
9-4
9-4
9-4
Configuring RPR Mode
9-4
Synchronizing the Supervisor Engine Configurations
Displaying the Redundancy States
Copying Files to the RP
9-5
9-5
9-6
Interface and Hardware Components
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5
Contents
Interface Configuration
10-1
Information About Interface Configuration
How to Configure a Range of Interfaces
10-2
10-2
How to Define and Use Interface-Range Macros
How to Configure Optional Interface Features
10-2
10-3
Configuring Ethernet Interface Speed and Duplex Mode
Configuring Jumbo Frame Support
10-6
Configuring IEEE 802.3x Flow Control
Configuring the Port Debounce Timer
10-9
10-10
Information About Online Insertion and Removal
How to Monitor and Maintain Interfaces
Monitoring Interface Status
10-11
10-12
Clearing Counters on an Interface
Resetting an Interface
10-12
10-13
Shutting Down and Restarting an Interface
How to Check Cable Status with the TDR
UniDirectional Link Detection ( UDLD)
Prerequisites for UDLD
10-14
1-1
1-1
Information About UDLD
1-2
1-2
UDLD Aggressive Mode
Fast UDLD
10-13
1-1
Restrictions for UDLD
UDLD Overview
10-11
1-3
1-4
Default Settings for UDLD
How to Configure UDLD
1-4
1-4
Enabling UDLD Globally
1-5
Enabling UDLD on LAN Interfaces
1-5
Disabling UDLD on Nonfiber-Optic LAN Interfaces
Disabling UDLD on Fiber-Optic LAN Interfaces
Configuring the UDLD Probe Message Interval
Configuring Fast UDLD
1-6
Resetting Disabled LAN Interfaces
Instant Access (IA)
2-1
Prerequisites for Instant Access
Restrictions for Instant Access
2-1
2-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6
1-7
1-6
1-6
1-5
10-3
Contents
Information About Instant Access
2-6
Default Settings for Instant Access
How to Configure Instant Access
2-6
2-6
Configure Instant Access Staggered Initialization Mode
Enable IA Client Preprovisioning
2-7
Configure Instant Access Port-Channel Interfaces
Configure Instant Access Channel Groups
2-8
2-8
Identify Connected IA Client Stack Modules
Configure IA Clients
2-7
2-9
2-10
Display or Clear SDP and SRP Traffic
2-10
To clear the protocol counters, enter the clear fex fex_number {sdp | srp} command. Configure
Optional Parameters for an IA Client 2-10
Configuring EnergyWise
Power Management
3-1
4-1
Power Management Overview
4-1
How to Enable or Disable Power Redundancy
How to Power Modules Off and On
4-3
How to Display System Power Status
How to Power Cycle Modules
Environmental Monitoring
4-2
4-4
4-5
5-1
Environmental Monitoring Overview
5-1
How to Determine Sensor Temperature Thresholds
How to Monitor the System Environmental Status
Information About LED Environmental Indications
Online Diagnostics
5-2
5-3
5-4
6-1
Prerequisites for Online Diagnostics
Restrictions for Online Diagnostics
6-1
6-1
Information About Online Diagnostics
6-2
Default Settings for Online Diagnostics
6-2
How to Configure Online Diagnostics
6-2
Setting Bootup Online Diagnostics Level
6-2
Configuring On-Demand Online Diagnostics
Scheduling Online Diagnostics
6-3
6-5
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7
Contents
Configuring Health-Monitoring Diagnostics
How to Run Online Diagnostic Tests
6-5
6-6
Overview of Diagnostic Test Operation
6-6
Starting and Stopping Online Diagnostic Tests
Running All Online Diagnostic Tests
6-6
6-7
Displaying Online Diagnostic Tests and Test Results
How to Perform Memory Tests
6-24
How to Perform a Diagnostic Sanity Check
Onboard Failure Logging (OBFL)
Prerequisites for OBFL
Restrictions for OBFL
6-24
7-1
7-1
7-2
Information About OBFL
7-2
Overview of OBFL
7-2
Information about Data Collected by OBFL
Default Settings for OBFL
Enabling OBFL
7-2
7-8
7-9
Configuration Examples for OBFL
7-10
Enabling OBFL Message Logging: Example
OBFL Message Log: Example
7-10
7-10
OBFL Component Uptime Report: Example
7-10
OBFL Report for a Specific Time: Example
7-11
Switch Fabric Functionality
8-1
Prerequisites for Switch Fabric Functionality
8-1
Restrictions for Switch Fabric Functionality
8-1
Information About the Switch Fabric Functionality
Default Settings for Switch Fabric Functionality
How to Configure the Switch Fabric Functionality
Monitoring the Switch Fabric Functionality
Cisco IP Phone Support
9-1
Prerequisites for Cisco IP Phone Support
9-1
Restrictions for Cisco IP Phone Support
9-1
Information About Cisco IP Phone Support
Cisco IP Phone Connections
9-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8
8-4
9-2
8-2
8-2
8-3
6-8
Contents
Cisco IP Phone Voice Traffic
9-3
Cisco IP Phone Data Traffic
9-4
Other Cisco IP Phone Features
9-4
Default Setting for Cisco IP Phone Support
9-4
How to Configure Cisco IP Phone Support
9-5
Configuring Voice Traffic Support
9-5
Configuring Data Traffic Support
Power over Ethernet (PoE) Support
Prerequisites for PoE
Restrictions for PoE
PoE Overview
10-1
10-1
10-1
Information About PoE
Device Roles
9-6
10-2
10-2
10-2
CPD-Based PoE Management
10-3
Inline Power IEEE Power Classification Override
10-4
LLDP Inline Power Negotiation for PoE+ (IEEE 802.3at)
How to Configure PoE Support
Displaying PoE Status
10-4
10-4
10-5
Configuring Per-Port PoE Support
Configuring PoE Power Priority
10-5
10-6
Configuring PoE Monitoring and Policing
10-8
Disabling LLDP Power Negotiation (IEEE 802.3at)
10-8
LAN Switching
LAN Ports for Layer 2 Switching
11-1
Prerequisites for Layer 2 LAN Interfaces
11-1
Restrictions for Layer 2 LAN Interfaces
11-2
Information About Layer 2 Switching
11-2
Information about Layer 2 Ethernet Switching
Information about VLAN Trunks
Layer 2 LAN Port Modes
11-2
11-4
11-4
Default Settings for Layer 2 LAN Interfaces
11-5
How to Configure LAN Interfaces for Layer 2 Switching
11-5
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9
Contents
Configuring a LAN Port for Layer 2 Switching
11-6
Enabling Out-of-Band MAC Address Table Synchronization
Configuring MAC Address Table Notification
11-7
Configuring a Layer 2 Switching Port as a Trunk
11-8
Configuring a LAN Interface as a Layer 2 Access Port
11-13
Configuring a Custom IEEE 802.1Q EtherType Field Value
Flex Links
11-6
11-15
12-1
Prerequisites for Flex Links
12-1
Restrictions for Flex Links
12-2
Information About Flex Links
12-2
Default Settings for Flex Links
How to Configure Flex Links
Monitoring Flex Links
EtherChannels
12-4
12-4
12-6
13-1
Prerequisites for EtherChannels
Restrictions for EtherChannels
13-1
13-2
Information About EtherChannels
13-3
EtherChannel Feature Overview
13-3
Information about EtherChannel Configuration
13-4
Information about LACP 1:1 Redundancy
13-6
Information about Port Channel Interfaces
13-7
Information about Load Balancing
Default Settings for EtherChannels
How to Configure EtherChannels
13-7
13-7
13-7
Configuring Port Channel Logical Interfaces
Configuring Channel Groups
13-8
13-9
Configuring the LACP System Priority and System ID
Configuring EtherChannel Load Balancing
13-11
13-11
Configuring the EtherChannel Hash-Distribution Algorithm
Configuring the EtherChannel Min-Links Feature
Configuring LACP 1:1 Redundancy
13-12
13-13
13-14
Configuring Auto Interleaved Port Priority For LACP Port Channels
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10
13-15
Contents
Configuring LACP Port-Channel Standalone Disable
IEEE 802.1ak MVRP and MRP
14-1
Prerequisites for IEEE 802.1ak MVRP and MRP
Restrictions for IEEE 802.1ak MVRP and MRP
14-1
14-2
Information About IEEE 802.1ak MVRP and MRP
Overview
13-16
14-2
14-2
Dynamic VLAN Creation
14-4
MVRP Interoperability with VTP
14-4
MVRP Interoperation with Non-Cisco Devices
14-6
MVRP Interoperability with Other Software Features and Protocols
Default Settings for IEEE 802.1ak MVRP and MRP
How to Configure IEEE 802.1ak MVRP and MRP
Enabling MVRP
14-8
14-8
14-8
Enabling Automatic Detection of MAC Addresses
Enabling MVRP Dynamic VLAN Creation
Changing the MVRP Registrar State
Troubleshooting the MVRP Configuration
14-9
14-9
14-10
14-10
Configuration Examples for IEEE 802.1ak MVRP and MRP
Enabling MVRP
Enabling Dynamic VLAN Creation
Changing the MVRP Registrar State
VLAN Trunking Protocol (VTP)
15-1
Restrictions for VTP
15-1
Information About VTP
14-11
14-12
14-12
15-1
Prerequisites for VTP
15-2
VTP Overview
15-3
VTP Domains
15-3
15-4
VTP Advertisements
15-4
VTP Authentication
15-5
VTP Version 2
15-5
VTP Version 3
15-6
VTP Pruning
14-11
14-11
Enabling MVRP Automatic Detection of MAC Addresses
VTP Modes
14-6
15-7
VLAN Interaction
Default Settings for VTP
15-9
15-9
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11
Contents
How to Configure VTP
15-10
Configuring VTP Global Parameters
Configuring the VTP Mode
15-10
15-15
Configuring VTP Mode on a Per-Port Basis
Displaying VTP Statistics
15-17
Virtual Local Area Networks (VLANs)
Prerequisites for VLANs
Restrictions for VLANs
VLAN Ranges
16-1
16-1
16-2
Information About VLANs
VLAN Overview
16-2
16-2
16-2
Default Settings for VLANs
16-3
How to Configure VLANs
16-4
Configurable VLAN Parameters
VLAN Locking
15-16
16-4
16-4
Creating or Modifying an Ethernet VLAN
16-5
Assigning a Layer 2 LAN Interface to a VLAN
16-6
Configuring the Internal VLAN Allocation Policy
Configuring VLAN Translation
Saving VLAN Information
Private VLANs
16-7
16-9
17-1
Prerequisites for Private VLANs
Restrictions for Private VLANs
17-1
17-2
Secondary and Primary VLANs
Private VLAN Ports
Information About Private VLANs
Private VLAN Domains
Private VLAN Ports
17-2
17-4
Limitations with Other Features
17-4
17-5
17-5
17-7
Primary, Isolated, and Community VLANs
Private VLAN Port Isolation
17-7
17-8
IP Addressing Scheme with Private VLANs
Private VLANs Across Multiple Switches
17-8
17-9
Private VLAN Interaction with Other Features
Default Settings for Private VLANs
17-10
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12
16-6
17-9
Contents
How to Configure Private VLANs
17-10
Configuring a VLAN as a Private VLAN
17-11
Associating Secondary VLANs with a Primary VLAN
17-12
Mapping Secondary VLANs to the Layer 3 VLAN Interface of a Primary VLAN
Configuring a Layer 2 Interface as a Private VLAN Host Port
17-14
Configuring a Layer 2 Interface as a Private VLAN Promiscuous Port
Monitoring Private VLANs
Private Hosts
17-13
17-15
17-16
18-1
Prerequisites for Private Hosts
18-1
Restrictions for Private Hosts
18-1
General Private Host Restrictions
Private Host ACL Restrictions
18-2
18-2
Private Host VLAN on Trunk Port Restrictions
Private Host Interaction with Other Features
Private Host Spoofing Protection
18-3
Private Host Multicast Operation
18-4
Information About Private Hosts
Private Hosts Overview
18-3
18-3
18-4
18-4
Isolating Hosts in a VLAN
18-4
Restricting Traffic Flow (Using Private Hosts Port Mode and PACLs)
Port ACLs
18-5
18-7
Default Settings for Private Hosts
18-8
How to Configure Private Hosts
Configuration Summary
18-8
18-8
Detailed Configuration Steps
Configuration Examples
IEEE 802.1Q Tunneling
18-9
18-10
19-1
Prerequisites for 802.1Q Tunneling
19-1
Restrictions for 802.1Q Tunneling
19-1
Information About 802.1Q Tunneling
Default Settings for 802.1Q Tunneling
How to Configure 802.1Q Tunneling
Configuring 802.1Q Tunnel Ports
19-4
19-5
19-6
19-6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13
Contents
Configuring the Switch to Tag Native VLAN Traffic
Layer 2 Protocol Tunneling
20-1
Prerequisites for Layer 2 Protocol Tunneling
20-1
Restrictions for Layer 2 Protocol Tunneling
20-1
Information About Layer 2 Protocol Tunneling
20-2
Default Settings for Layer 2 Protocol Tunneling
How to Configure Layer 2 Protocol Tunneling
Spanning Tree Protocols
20-3
1-1
Prerequisites for Spanning Tree Protocols
1-1
Restrictions for Spanning Tree Protocols
1-2
Information About Spanning Tree Protocols
Information about STP
1-2
1-2
Information about IEEE 802.1w RSTP
Information about MST
1-13
1-18
Detecting Unidirectional Link Failure
1-25
Default Settings for Spanning Tree Protocols
Default STP Configuration
Default MST Configuration
Configuring STP
Configuring MST
PortFast
1-26
1-26
1-26
1-37
2-1
2-2
Information about PortFast
Enabling PortFast
Bridge Assurance
2-2
2-2
2-4
Information about Bridge Assurance
Enabling Bridge Assurance
BPDU Guard
2-7
2-7
Information about BPDU Guard
Enabling BPDU Guard
PortFast Edge BPDU Filtering
2-7
2-7
2-9
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14
1-25
1-25
How to Configure Spanning Tree Protocols
Optional STP Features
20-2
2-4
19-6
Contents
Information about PortFast Edge BPDU Filtering
Enabling PortFast Edge BPDU Filtering
UplinkFast
Enabling UplinkFast
BackboneFast
2-11
2-12
2-13
Information about BackboneFast
Enabling BackboneFast
EtherChannel Guard
2-13
2-15
2-16
Information about EtherChannel Guard
Enabling EtherChannel Guard
2-16
2-16
2-17
Information about Root Guard
Enabling Root Guard
Loop Guard
2-10
2-11
Information about UplinkFast
Root Guard
2-9
2-17
2-17
2-17
Information about Loop Guard
Enabling Loop Guard
PVST Simulation
2-17
2-19
2-20
Information about PVST Simulation
Configuring PVST Simulation
2-20
2-21
Verifying the Optional STP Features
2-21
Using the show spanning-tree Commands
2-22
Examples of the show spanning-tree Commands
2-22
IP Switching
IP Unicast Layer 3 Switching
3-1
Prerequisites for Hardware Layer 3 Switching
Restrictions for Hardware Layer 3 Switching
Information About Layer 3 Switching
Hardware Layer 3 Switching
3-1
3-1
3-2
3-2
Layer 3-Switched Packet Rewrite
3-2
Default Settings for Hardware Layer 3 Switching
How to Configure Hardware Layer 3 Switching
Displaying Hardware Layer 3 Switching Statistics
3-4
3-4
3-5
IP Routing Protocols
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15
Contents
Policy-Based Routing (PBR)
Prerequisites for PBR
4-1
4-1
Restrictions for PBR
4-2
Information About PBR
PBR Overview
4-2
4-2
PBR Recursive Next Hop for IPv4 Traffic
Default Settings for PBR
How to Configure PBR
Configuring PBR
4-3
4-3
4-4
Configuring Local PBR
4-5
Configuring PBR Recursive Next Hop
Configuration Examples for PBR
Equal Access Example
4-5
4-7
4-7
Differing Next Hops Example
4-8
Recursive Next-Hop IP Address: Example
Layer 3 Interfaces
4-3
4-8
5-1
Restrictions for Layer 3 Interfaces
5-1
How to Configure Subinterfaces on Layer 3 Interfaces
5-3
Unidirectional Ethernet (UDE) and Unidirectional Link Routing (UDLR)
Prerequisites for UDE and UDLR
6-1
Restrictions for UDE and UDLR
UDE Restrictions
6-2
6-2
UDLR Back-Channel Tunnel Restrictions
Information About UDE and UDLR
UDE and UDLR Overview
Information about UDE
Information about UDLR
6-3
6-3
6-4
Default Settings for UDE and UDLR
How to Configure UDE and UDLR
Configuring UDE
Configuring UDLR
6-3
6-4
6-5
6-5
6-6
MPLS Features
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16
6-3
6-1
Contents
Multiprotocol Label Switching (MPLS)
Prerequisites for MPLS
7-1
Restrictions for MPLS
7-1
Information About MPLS
MPLS Overview
IP to MPLS
7-2
7-2
7-4
MPLS to MPLS
MPLS to IP
7-4
7-4
MPLS VPN Forwarding
Recirculation
7-1
7-5
7-5
Hardware Supported Features
Supported MPLS Features
Default Settings for MPLS
7-5
7-6
7-7
How to Configure MPLS Features
Configuring MPLS
7-7
7-7
Configuring MUX-UNI Support on LAN Cards
Configuration Examples for MPLS
MPLS VPN Support
7-7
7-9
8-1
Prerequisites for MPLS VPN
8-1
Restrictions for MPLS VPN
8-2
Information About MPLS VPN Support
How to Configure MPLS VPNs
8-3
Configuration Example for MPLS VPNs
Ethernet over MPLS (EoMPLS)
9-1
Restrictions for EoMPLS
9-2
Information About EoMPLS
EoMPLS Overview
8-4
9-1
Prerequisites for EoMPLS
AToM Overview
8-2
9-3
9-3
9-3
Default Settings for EoMPLS
How to Configure EoMPLS
9-3
9-4
Configuring VLAN-Based EoMPLS
Configuring Port-Based EoMPLS
9-4
9-6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17
Contents
Virtual Private LAN Services (VPLS)
Prerequisites for VPLS
10-1
Restrictions for VPLS
10-2
Information About VPLS
VPLS Overview
10-2
10-2
Full-Mesh Configuration
H-VPLS
10-1
10-3
10-4
Supported Features
10-4
Default Settings for VPLS
How to Configure VPLS
10-6
10-6
Configuring PE Layer 2 Interfaces to CEs
10-7
Configuring Layer 2 VLAN Instances on a PE
Configuring MPLS in the PE
10-10
10-11
Configuring the VFI in the PE
10-12
Associating the Attachment Circuit with the VSI at the PE
H-VPLS with MPLS Edge
10-14
VPLS Integrated Routing and Bridging
10-17
Configuring Multicast Snooping Support
Configuration Examples for VPLS
Configuring A-VPLS
10-13
10-18
10-18
11-1
Prerequisites for A-VPLS
11-1
Restrictions for A-VPLS
11-2
Information About A-VPLS
11-2
How to Configure A-VPLS
11-3
Enabling Load-Balancing with ECMP and FAT Pseudowires
Enabling Port-Channel Load-Balancing
11-3
11-3
Explicitly Specifying the PE Routers As Part of Virtual Ethernet Interface Configuration
Configuring an MPLS Traffic Engineering Tunnel
Configuring a GRE Tunnel
11-5
Routed Pseudo-Wire (RPW) and Routed VPLS
Ethernet Virtual Connections (EVCs)
Prerequisites for EVCs
Restrictions for EVCs
12-1
12-2
Information About EVCs
EVC Overview
12-1
12-3
12-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18
11-8
11-5
11-4
Contents
Ethernet Flow Points
12-4
Service Instances and EFPs
12-4
Encapsulation (Flexible Service Mapping)
EFPs and MSTP
12-7
Bridge Domains
12-7
Rewrite Operations
12-9
Layer 3 and Layer 4 ACL Support
Advanced Frame Manipulation
Egress Frame Filtering
How to Configure EVCs
12-9
12-9
12-9
Default Settings for EVCs
Monitoring EVCs
12-5
12-9
12-10
12-14
Layer 2 over Multipoint GRE (L2omGRE)
Prerequisites for L2omGRE
Restrictions for L2omGRE
13-1
13-2
Information About L2omGRE
13-2
Default Settings for L2omGRE
How to Configure L2omGRE
13-1
13-3
13-3
Configuring a Loopback Interface
13-3
Configuring an mGRE Tunnel Interface
Configuring a VLAN Interface
13-3
13-4
L2omGRE Configuration Examples
Verifying the L2omGRE Configuration
13-5
13-5
Multicast
IPv4 Multicast Layer 3 Features
14-1
Prerequisites for IPv4 Multicast Layer 3 Features
14-1
Restrictions for IPv4 Multicast Layer 3 Features
14-1
Information About IPv4 Multicast Layer 3 Features
IPv4 Multicast Layer 3 Features Overview
Distributed MRIB and MFIB Infrastructure
Multicast Layer 3 Hardware Features Entries
Layer 3-Switched Multicast Statistics
14-2
14-2
14-3
14-4
14-4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19
Contents
Layer 3-Switched Multicast Packet Rewrite
Replication Modes
14-5
14-5
Local Egress Replication Mode
14-6
PIM-SM hardware register support
14-6
PIM-SM hardware SPT-switchover support
Control Plane Policing (CoPP)
Non-RPF Traffic Processing
Multicast Boundary
14-6
14-7
14-7
14-7
IPv4 Bidirectional PIM
14-8
Supported Multicast Features
14-8
Default Settings for IPv4 Multicast Layer 3 Features
How to Configure IPv4 Multicast Layer 3 Features
Enabling IPv4 Multicast Routing Globally
Enabling IPv4 PIM on Layer 3 Interfaces
14-15
14-15
14-16
14-16
Enabling IP Multicast Layer 3 Switching on Layer 3 Interfaces
Enabling IP MFIB forwarding on Layer 3 Interfaces
Configuring the Replication Mode
Configuring Multicast Boundary
14-16
14-17
14-18
14-18
Verifying Local Egress Replication
14-19
Displaying IPv4 Multicast PIM-SM register tunnel information
Displaying the IPv4 Multicast Routing Table
Displaying IPv4 MRIB Information
14-21
Displaying IPv4 MFIB Information
14-22
Viewing Directly Connected Entries
14-23
14-20
Displaying IPv4 Hardware Switching Information
Displaying IPv4 CoPP Information
14-20
14-24
14-25
Source-Specific Multicast with IGMPv3, IGMP v3lite, and URD
Configuring IPv4 Bidirectional PIM
14-26
14-26
Enabling IPv4 Bidirectional PIM Globally
14-27
Configuring the Rendezvous Point for IPv4 Bidirectional PIM Groups
Displaying IPv4 Bidirectional PIM Information
Using IPv4 Debug Commands
14-31
Redundancy for Multicast Traffic
14-31
IGMP Snooping for IPv4 Multicast Traffic
15-1
Prerequisites for IGMP Snooping
Restrictions for IGMP Snooping
15-1
15-1
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20
14-27
14-27
Contents
General IGMP Snooping Restrictions
15-2
IGMP Snooping Querier Restrictions
15-2
Information About IGMP Snooping
15-2
IGMP Snooping Overview
15-3
Joining a Multicast Group
15-3
Leaving a Multicast Group
15-5
Information about the IGMP Snooping Querier
Information about IGMP Version 3 Support
Default Settings for IGMP Snooping
15-6
15-8
How to Configure IGMP Snooping
15-8
Enabling the IGMP Snooping Querier
Enabling IGMP Snooping
15-6
15-9
15-9
Configuring the IGMP Snooping Lookup Method
15-11
Configuring a Static Connection to a Multicast Receiver
Configuring a Multicast Router Port Statically
Configuring the IGMP Snooping Query Interval
15-11
15-12
15-12
Enabling IGMP Snooping Immediate-Leave Processing
15-13
Configuring IGMPv3 Snooping Explicit Host Tracking
15-13
Displaying IGMP Snooping Information
PIM Snooping
15-14
16-1
Prerequisites for PIM Snooping
Restrictions for PIM Snooping
16-1
16-2
Information About PIM Snooping
Default Settings for PIM Snooping
How to Configure PIM Snooping
16-2
16-4
16-5
Enabling PIM Snooping Globally
Enabling PIM Snooping in a VLAN
16-5
16-5
Disabling PIM Snooping Designated-Router Flooding
Multicast VLAN Registration (MVR)
Restrictions for MVR
17-1
Restrictions for MVR
17-1
Information About MVR
MVR Overview
16-6
17-1
17-2
17-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
21
Contents
Using MVR in a Multicast Television Application
Default MVR Configuration
How to Configure MVR
17-5
17-5
Configuring MVR Global Parameters
Configuring MVR Interfaces
Clearing MVR Counters
17-5
17-6
17-8
Displaying MVR Information
IPv4 IGMP Filtering
17-3
17-8
18-1
Prerequisites for IGMP Filtering
18-1
Restrictions for IGMP Filtering
18-1
Information About IGMP Filtering
IGMP Filtering Overview
IGMP Filter Precedence
18-2
18-3
18-4
Default Settings for IGMP Filtering
How to Configure IGMP Filters
18-4
18-4
Configuring IGMP Group and Channel Access Control
Configuring IGMP Group and Channel Limits
Configuring IGMP Version Filtering
Clearing IGMP Filtering Statistics
18-5
18-6
Verifying the IGMP Filtering Configuration
18-6
Displaying IGMP Filtering Configuration
Displaying IGMP Filtering Statistics
Configuration Examples for IGMP Filtering
IPv4 Router Guard
18-7
18-8
19-1
Prerequisites for Router Guard
Restrictions for Router Guard
19-1
19-1
Information About Router Guard
19-2
Default Settings for Router Guard
19-2
How to Configure Router Guard
19-2
Enabling Router Guard Globally
19-3
Disabling Router Guard on Ports
19-3
Clearing Router Guard Statistics
19-3
Verifying the Router Guard Configuration
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
22
18-6
19-4
18-5
18-4
Contents
Displaying Router Guard Configuration
Displaying Router Guard Interfaces
IPv4 Multicast VPN Support
20-1
Prerequisites for mVPNs
20-1
Restrictions for mVPNs
19-4
19-5
20-1
General Restrictions
20-2
mVPN with L3VPN over mGRE Restrictions
Information About mVPN
mVPN Overview
20-3
20-3
20-3
Multicast Routing and Forwarding and Multicast Domains
Multicast Distribution Trees
20-4
Multicast Tunnel Interfaces
20-7
PE Router Routing Table Support for mVPN
Multicast Distributed Switching Support
Hardware-Assisted IPv4 Multicast
20-8
20-8
20-8
Information About mVPN with L3VPN over mGRE
Default Settings for mVPNs
How to Configure mVPNs
20-4
20-9
20-10
20-11
Configuring a Multicast VPN Routing and Forwarding Instance
Configuring Multicast VRF Routing
20-16
Configuring Interfaces for Multicast Routing to Support mVPN
Configuring mVPN with L3VPN over mGRE
Configuration Examples for mVPNs
20-11
20-20
20-22
20-27
mVPN Configuration with Default MDTs Only
20-27
mVPN Configuration with Default and Data MDTs
20-29
Verifying the mVPN with L3VPN over mGRE Configuration
20-32
Configuration Sequence for mVPN with L3VPN over mGRE
20-33
IPv6 Multicast Support
21-1
Prerequisites for IPv6 Multicast
Restrictions for IPv6 Multicast
21-1
21-1
Information About IPv6 Multicast Support
21-2
Hardware-Supported IPv6 Layer 3 Multicast Features
21-2
Partially Hardware-Supported IPv6 Layer 3 Multicast Features
21-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
23
Contents
Software-Supported IPv6 Layer 3 Multicast Features
Unsupported IPv6 Layer 3 Multicast Features
How to Configure IPv6 Multicast Support
21-3
21-4
Verifying the IPv6 Multicast Layer 3 Configuration
Verifying MFIB Clients
21-3
21-4
21-5
Displaying the Switching Capability
21-5
Verifying the (S,G) Forwarding Capability
21-5
Verifying the (*,G) Forwarding Capability
21-5
Verifying the Subnet Entry Support Status
21-5
Verifying the Current Replication Mode
21-5
Displaying the Replication Mode Auto-Detection Status
Displaying the Replication Mode Capabilities
Displaying Subnet Entries
21-5
21-6
21-6
Displaying the IPv6 Multicast Summary
21-6
Displaying the NetFlow Hardware Forwarding Count
21-7
Displaying the FIB Hardware Bridging and Drop Counts
21-7
Displaying the Shared and Well-Known Hardware Adjacency Counters
IPv6 MLD Snooping
22-1
Prerequisites for MLD Snooping
22-1
Restrictions for MLD Snooping
22-2
General MLD Snooping Restrictions
22-2
MLD Snooping Querier Restrictions
22-2
Information About MLD Snooping
MLD Snooping Overview
MLD Messages
22-3
22-3
22-4
Source-Based Filtering
22-4
Explicit Host Tracking
22-4
MLD Snooping Proxy Reporting
22-5
Joining an IPv6 Multicast Group
22-5
Leaving a Multicast Group
22-7
Information about the MLD Snooping Querier
Default MLD Snooping Configuration
How to Configure MLD Snooping
22-9
22-9
Enabling the MLD Snooping Querier
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
24
22-10
22-8
21-8
Contents
Configuring the MLD Snooping Query Interval
Enabling MLD Snooping
22-10
22-11
Configuring a Static Connection to a Multicast Receiver
Configuring a Multicast Router Port Statically
Enabling Fast-Leave Processing
Enabling SSM Safe Reporting
22-12
22-12
22-12
22-13
Configuring Explicit Host Tracking
Configuring Report Suppression
22-13
22-14
Verifying the MLD Snooping Configuration
22-14
Network Management
NetFlow Hardware Support
23-1
Prerequisites for NetFlow Hardware Support
Restrictions for NetFlow Hardware Support
23-1
23-1
Information About NetFlow Hardware Support
23-2
Default Settings for NetFlow Hardware Support
How to Configure NetFlow Hardware Support
Configuring Inactive Flow Aging
Configuring Fast Aging
23-2
23-2
23-3
23-3
Configuring Active Flow Aging
23-4
Verifying the NetFlow Table Aging Configuration
Call Home
23-4
24-1
Prerequisites for Call Home
24-2
Restrictions for Call Home
24-2
Information About Call Home
Call Home Overview
24-3
Anonymous Reporting
Smart Call Home
24-3
24-4
24-4
Alert Group Trigger Events and Commands
Message Contents
24-5
24-13
Sample Syslog Alert Notification in Long-Text Format
Sample Syslog Alert Notification in XML Format
Default Settings for Call Home
How to Configure Call Home
24-17
24-17
24-21
24-21
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
25
Contents
Configuring Call Home Customer Contact Information
Configuring Destination Profiles
Subscribing to Alert Groups
24-22
24-31
Configuring Call Home Data Privacy
Enabling Call Home
24-21
24-37
24-37
Configuring Call Home Traffic Rate Limiting
Configuring Syslog Throttling
24-38
Testing Call Home Communications
24-38
Configuring the Smart Call Home Service
Verifying the Call Home Configuration
System Event Archive (SEA)
24-42
24-45
25-1
Information About the System Event Archive
25-1
How to Display the SEA Logging System
25-2
How to Copy the SEA To Another Device
25-3
Backplane Traffic Monitoring
24-38
26-1
Prerequisites for Backplane Traffic Monitoring
Restrictions for Backplane Traffic Monitoring
Information About Traffic Monitoring
26-1
26-2
26-2
Default Settings for Backplane Traffic Monitoring
How to Configure Backplane Traffic Monitoring
Local SPAN, RSPAN, and ERSPAN
26-2
26-3
27-1
Prerequisites for Local SPAN, RSPAN, and ERSPAN
27-1
Restrictions for Local SPAN, RSPAN, and ERSPAN
27-2
Feature Incompatibilities
27-2
Local SPAN, RSPAN, and ERSPAN Session Limits
27-3
Local SPAN, RSPAN, and ERSPAN Interface Limits
27-3
General Restrictions for Local SPAN, RSPAN, and ERSPAN
Restrictions for VSPAN
27-5
Restrictions for RSPAN
27-5
Restrictions for ERSPAN
27-6
Restrictions for Distributed Egress SPAN Mode
27-7
Information About Local SPAN, RSPAN, and ERSPAN
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
26
27-7
27-3
Contents
Local SPAN, RSPAN, and ERSPAN Overview
Local SPAN, RSPAN, and ERSPAN Sources
27-7
27-11
Local SPAN, RSPAN, and ERSPAN Destinations
27-12
Default Settings for Local SPAN, RSPAN, and ERSPAN
How to Configure Local SPAN, RSPAN, and ERSPAN
27-12
27-12
Configuring a Destination as an Unconditional Trunk (Optional)
Configuring Destination Trunk VLAN Filtering (Optional)
Configuring Destination Port Permit Lists (Optional)
Configuring the Egress SPAN Mode (Optional)
Configuring Local SPAN
Configuring RSPAN
27-13
27-13
27-15
27-15
27-16
27-20
Configuring ERSPAN
27-26
Configuring Source VLAN Filtering in Global Configuration Mode
Verifying the SPAN Configuration
27-31
Configuration Examples for SPAN
27-31
SNMP IfIndex Persistence
27-30
28-1
Prerequisites for SNMP IfIndex Persistence
Restrictions for SNMP IfIndex Persistence
28-1
28-1
Information About SNMP IfIndex Persistence
Default Settings for SNMP IfIndex Persistence
How to Configure SNMP IfIndex Persistence
28-2
28-2
28-2
Enabling SNMP IfIndex Persistence Globally
Disabling SNMP IfIndex Persistence Globally
28-2
28-3
Enabling and Disabling SNMP IfIndex Persistence on Specific Interfaces
Clearing SNMP IfIndex Persistence Configuration from a Specific Interface
Top-N Reports
28-3
28-4
29-1
Prerequisites for Top-N Reports
Restrictions for Top-N Reports
29-1
29-1
Information About Top-N Reports
Top-N Reports Overview
29-2
Top-N Reports Operation
29-2
29-2
Default Settings for Top-N Reports
How to Use Top-N Reports
29-3
29-3
Enabling Top-N Reports Creation
29-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
27
Contents
Displaying Top-N Reports
Clearing Top-N Reports
Layer 2 Traceroute Utility
29-4
29-5
30-1
Prerequisites for the Layer 2 Traceroute Utility
30-1
Restrictions for the Layer 2 Traceroute Utility
30-1
Information About the Layer 2 Traceroute Utility
How to Use the Layer 2 Traceroute Utility
Mini Protocol Analyzer
30-2
30-3
31-1
Prerequisites for the Mini Protocol Analyzer
Restrictions for the Mini Protocol Analyzer
31-1
31-1
Information About the Mini Protocol Analyzer
How to Configure the Mini Protocol Analyzer
Configuring a Capture Session
31-2
31-2
31-2
Filtering the Packets to be Captured
Starting and Stopping a Capture
31-4
31-5
Displaying and Exporting the Capture Buffer
31-7
Configuration Examples for the Mini Protocol Analyzer
General Configuration Examples
31-8
Filtering Configuration Examples
Operation Examples
Display Examples
31-7
31-9
31-10
31-10
Quality of Service
PFC QoS Overview
32-1
Restrictions for PFC QoS
General Guidelines
33-1
33-2
PFC and DFC Guidelines
33-4
Class Map Command Restrictions
33-5
Policy Map Class Command Restrictions
33-5
Supported Granularity for CIR and PIR Rate Values
33-5
Supported Granularity for CIR and PIR Token Bucket Sizes
IP Precedence and DSCP Values
33-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
28
33-6
Contents
Classification, Marking, and Policing
34-1
Information About Classification, Marking, and Policing Policies
Classification, Marking, and Policing Policy Overview
Traffic Classification
Traffic Marking
34-1
34-1
34-2
34-3
Information about Policing
34-4
How to Configure Classification, Marking, and Policing Policies
Enabling Distributed Aggregate Policing
Configuring a Class Map
Configuring a Policy Map
34-7
34-7
34-8
34-9
Attaching a Policy Map to an Interface
34-17
Configuring Dynamic Per-Session Attachment of a Policy Map
Policy-Based Queueing
34-19
35-1
Prerequisites for Policy-Based Queueing
35-1
Restrictions for Policy-Based Queueing
35-2
Information About Policy-Based Queueing
Port-Based Queue Types
Queueing Policies
35-4
35-4
35-8
How to Configure Policy-Based Queueing
35-10
Configuring a Queueing Policy Class Map
Verifying a Queueing Policy Class Map
Configuring Queueing Policy Maps
Verifying a Queueing Policy Map
35-11
35-11
35-11
35-17
Attaching a Queueing Policy Map to an Interface
Configuration Examples for Policy-Based Queueing
Queueing Policy Sample Configuration
35-17
35-18
35-18
Queueing Policy Commands Supported by Each Queue Type
35-19
Queueing Policy Commands Sample Configurations for Each Queue Type
QoS Global and Interface Options
35-33
36-1
How to Configure the Ingress LAN Port CoS Value
How to Configure Egress DSCP Mutation
36-2
36-3
Configuring Named DSCP Mutation Maps
36-3
Attaching an Egress DSCP Mutation Map to an Interface
36-4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
29
Contents
How to Configure Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports
Ingress CoS Mutation Configuration Guidelines and Restrictions
Configuring Ingress CoS Mutation Maps
36-4
36-4
36-6
Applying Ingress CoS Mutation Maps to IEEE 802.1Q Tunnel Ports
How to Configure DSCP Value Maps
36-6
36-7
Mapping Received CoS Values to Internal DSCP Values
36-7
Mapping Received IP Precedence Values to Internal DSCP Values
Configuring DSCP Markdown Values
36-7
36-8
Mapping Internal DSCP Values to Egress CoS Values
36-9
How to Configure Trusted Boundary with Cisco Device Verification
Legacy Configuration Procedures for Queueing-Only Mode
36-10
36-11
Legacy Configuration Procedures for VLAN-Based PFC QoS on Layer 2 LAN Ports
Legacy Configuration Procedures for Port Trust State
36-13
Legacy Configuration Procedures for DSCP-Based Queue Mapping
Enabling DSCP-Based Queue Mapping
36-14
36-14
Configuring Ingress DSCP-Based Queue Mapping
36-15
Mapping DSCP Values to Standard Receive-Queue Thresholds
36-15
Mapping DSCP Values to Standard Transmit-Queue Thresholds
Mapping DSCP Values to the Transmit Strict-Priority Queue
AutoQoS
37-1
Restrictions for AutoQoS
37-2
Information About AutoQoS
37-2
AutoQoS Support for a Cisco IP Phone
37-3
AutoQoS Support for Cisco IP Communicator
AutoQoS Support for Marked Traffic
Default Settings for AutoQoS
How to Configure AutoQoS
37-3
37-4
37-4
37-4
Configuring AutoQoS Support for a Cisco IP Phone
37-5
Configuring AutoQoS Support for Cisco IP Communicator
Configuring AutoQoS Support for Marked Traffic
MPLS QoS
38-1
Terminology
38-2
MPLS QoS Features
38-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
30
36-18
37-1
Prerequisites for AutoQoS
37-7
36-16
37-6
36-12
Contents
MPLS Experimental Field
Trust
38-3
38-3
Classification
38-3
Policing and Marking
Preserving IP ToS
EXP Mutation
38-3
38-4
38-4
MPLS DiffServ Tunneling Modes
MPLS QoS Overview
38-4
38-4
Specifying the QoS in the IP Precedence Field
MPLS QoS
38-4
38-5
MPLS Topology Overview
38-5
LERs at the Input Edge of an MPLS Network
LSRs in the Core of an MPLS Network
38-6
38-6
LERs at the Output Edge of an MPLS Network
LERs at the EoMPLS Edge
38-7
LERs at the IP Edge (MPLS, MPLS VPN)
LSRs at the MPLS Core
38-8
38-11
MPLS QoS Default Configuration
MPLS QoS Commands
38-15
MPLS QoS Restrictions
38-15
How to Configure MPLS QoS
38-7
38-13
38-16
Enabling Queueing-Only Mode
38-17
Configuring a Class Map to Classify MPLS Packets
Configuring a Policy Map
Displaying a Policy Map
38-20
38-24
Configuring MPLS QoS Egress EXP Mutation
Configuring EXP Value Maps
38-25
MPLS DiffServ Tunneling Modes
38-26
Short Pipe Mode
Uniform Mode
38-17
38-24
38-27
38-28
MPLS DiffServ Tunneling Restrictions and Usage Guidelines
How to Configure Short Pipe Mode
38-30
38-30
Ingress PE Router—Customer Facing Interface
38-30
Configuring Ingress PE Router—P Facing Interface
Configuring the P Router—Output Interface
38-32
38-33
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
31
Contents
Configuring the Egress PE Router—Customer Facing Interface
How to Configure Uniform Mode
38-34
Configuring the Ingress PE Router—Customer Facing Interface
Configuring the Ingress PE Router—P Facing Interface
38-35
38-36
Configuring the Egress PE Router—Customer Facing Interface
PFC QoS Statistics Data Export
38-34
38-37
39-1
Prerequisites for PFC QoS Statistics Data Export
Restrictions for PFC QoS Statistics Data Export
39-1
39-1
Information About PFC QoS Statistics Data Export
39-2
Default Settings for PFC QoS Statistics Data Export
39-2
How to Configure PFC QoS Statistics Data Export
39-2
Security
Cisco IOS ACL Support
40-1
Restrictions for Cisco IOS ACLs
40-1
Restrictions for Layer 4 Operators in ACLs
Determining Layer 4 Operation Usage
40-2
40-2
Determining Logical Operation Unit Usage
Information About ACL Support
Policy-Based ACLs (PBACLs)
40-4
40-5
Restrictions for PBACLs
40-6
Information about PBACLs
40-6
How to Configure PBACLs
40-6
MAC ACLs
40-3
40-9
How to Configure Protocol-Independent MAC ACL Filtering
How to Enable VLAN-Based MAC QoS Filtering
ARP ACLs
40-12
Optimized ACL Logging
40-13
Restrictions for OAL
40-13
Information about OAL
40-13
How to Configure OAL
40-13
Dry Run Support for ACLs
40-15
Restrictions for Dry Run Support
40-15
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
32
40-10
40-9
Contents
Information About Dry Run Support
40-16
How to Configure Dry Run Support for ACLs
Hardware ACL Statistics
40-16
40-17
Restrictions for Hardware ACL Statistics
40-17
Information About Hardware ACL Statistics
How to Configure Hardware ACL Statistics
Cisco TrustSec (CTS)
40-18
41-1
Hardware Supported
AutoSecure
40-17
41-3
42-1
Prerequisites for AutoSecure
42-1
Restrictions for AutoSecure
42-2
Information About AutoSecure
AutoSecure Overview
42-2
42-2
Management Plane Security Enabled by AutoSecure
Forwarding Plane Security Enabled by AutoSecure
How to Configure AutoSecure
Configuring Additional Security
42-7
42-8
42-8
Examples for AutoSecure Configuration
MAC Address-Based Traffic Blocking
Port ACLs (PACLs)
42-9
43-1
44-1
Prerequisites for PACls
44-1
Restrictions for PACLs
44-2
Information About PACLs
PACL Overview
44-2
44-2
EtherChannel and PACL Interactions
44-3
Dynamic ACLs (Applies to Merge Mode Only)
Trunk Ports
42-6
42-7
Configuring AutoSecure Parameters
Verifying AutoSecure
42-3
44-4
44-4
Layer 2 to Layer 3 Port Conversion
Port-VLAN Association Changes
PACL and VACL Interactions
How to Configure PACLs
44-4
44-4
44-4
44-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
33
Contents
Configuring IP and MAC ACLs on a Layer 2 Interface
Configuring Access-group Mode on Layer 2 Interface
Applying ACLs to a Layer 2 Interface
Applying ACLs to a Port Channel
44-8
44-8
44-9
Displaying an ACL Configuration on a Layer 2 Interface
VLAN ACLs (VACLs)
44-7
44-9
45-1
Prerequisites for VACLs
45-1
Restrictions for VACLs
45-2
Information About VACLs
45-2
How to Configure VACLs
45-3
Defining a VLAN Access Map
45-3
Configuring a Match Clause in a VLAN Access Map Sequence
45-3
Configuring an Action Clause in a VLAN Access Map Sequence
Applying a VLAN Access Map
45-4
Verifying VLAN Access Map Configuration
45-5
VLAN Access Map Configuration and Verification Examples
Configuring a Capture Port
45-6
Configuring VACL Logging
Policy-Based Forwarding (PBF)
Prerequisites for PBF
46-1
46-2
Information About PBF
46-2
Default Settings for PBF
How to Configure PBF
Monitoring PBF
45-7
46-1
Restrictions for PBF
46-2
46-2
46-3
Configuration Examples for PBF
Denial of Service (DoS) Protection
Security ACLs and VACLs
QoS Rate Limiting
46-3
47-1
47-2
47-2
Global Protocol Packet Policing
47-3
Prerequisites for Global Protocol Packet Policing
Restrictions for Global Protocol Packet Policing
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
34
45-4
47-3
47-3
45-5
Contents
Information About Global Protocol Packet Policing
47-5
How to Configure Single-Command Global Protocol Packet Policing
How to Configure Policy-Based Global Protocol Packet Policing
Unicast Reverse Path Forwarding (uRPF) Check
Prerequisites for uRPF Check
47-7
How to Configure Unicast RPF Check
47-8
47-9
Monitoring Packet Drop Statistics
47-10
Prerequisites for Packet Drop Statistics
Restrictions for Packet Drop Statistics
47-10
47-10
Information About Packet Drop Statistics
How to Monitor Dropped Packets
Control Plane Policing (CoPP)
Prerequisites for CoPP
47-10
48-1
48-2
48-3
Default Settings for CoPP
Configuring CoPP
48-3
48-5
48-5
Defining CoPP Traffic Classification
Monitoring CoPP
47-10
48-1
Information About CoPP
How to Configure CoPP
47-6
47-7
Information about uRPF Check
Restrictions for CoPP
47-6
47-7
Restrictions for uRPF Check
Configuring Sticky ARP
47-5
48-6
48-9
Dynamic Host Configuration Protocol (DHCP) Snooping
Prerequisites for DHCP Snooping
49-1
Restrictions for DHCP Snooping
49-2
DHCP Snooping Configuration Restrictions
DHCP Snooping Configuration Guidelines
Minimum DHCP Snooping Configuration
Information About DHCP Snooping
Overview of DHCP Snooping
Trusted and Untrusted Sources
49-2
49-2
49-3
49-3
49-4
49-4
DHCP Snooping Binding Database
Packet Validation
49-1
49-5
49-5
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
35
Contents
DHCP Snooping Option-82 Data Insertion
49-5
Overview of the DHCP Snooping Database Agent
Default Configuration for DHCP Snooping
How to Configure DHCP Snooping
49-7
49-8
49-9
Enabling DHCP Snooping Globally
49-9
Enabling DHCP Option-82 Data Insertion
49-10
Enabling the DHCP Option-82 on Untrusted Port Feature
Enabling DHCP Snooping MAC Address Verification
Enabling DHCP Snooping on VLANs
49-10
49-11
49-11
Configuring the DHCP Trust State on Layer 2 LAN Interfaces
Configuring Spurious DHCP Server Detection
49-12
49-13
Configuring DHCP Snooping Rate Limiting on Layer 2 LAN Interfaces
The DHCP Snooping Database Agent
49-14
Displaying the DHCP Snooping Binding Table
IP Source Guard
49-18
50-1
Prerequisites for IP Source Guard
Restrictions for IP Source Guard
50-1
50-2
Information About IP Source Guard
Overview of IP Source Guard
50-2
50-2
IP Source Guard Interaction with VLAN-Based Features
Channel Ports
50-3
Layer 2 and Layer 3 Port Conversion
IP Source Guard and Voice VLAN
50-3
50-3
IP Source Guard and Web-Based Authentication
Default Settings for IP Source Guard
How to Configure IP Source Guard
50-3
50-3
Displaying IP Source Guard PACL Information
Displaying IP Source Binding Information
Dynamic ARP Inspection (DAI)
Prerequisites for DAI
51-1
Restrictions for DAI
51-2
Information About DAI
51-1
51-3
Information about ARP
51-3
ARP Spoofing Attacks
51-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
36
50-6
50-5
50-3
50-2
49-14
Contents
DAI and ARP Spoofing Attacks
51-4
Interface Trust States and Network Security
Rate Limiting of ARP Packets
51-4
51-5
Relative Priority of ARP ACLs and DHCP Snooping Entries
Logging of Dropped Packets
Default Settings for DAI
How to Configure DAI
51-6
51-6
51-7
Enabling DAI on VLANs
51-7
Configuring DAI Hardware Acceleration
51-8
Configuring the DAI Interface Trust State
51-8
Applying ARP ACLs for DAI Filtering
51-9
Configuring ARP Packet Rate Limiting
51-10
Enabling DAI Error-Disabled Recovery
51-11
Enabling Additional Validation
Configuring DAI Logging
51-11
51-13
Displaying DAI Information
51-15
Configuration Examples for DAI
51-16
Two Switches Support DAI
One Switch Supports DAI
Traffic Storm Control
51-6
51-16
51-21
52-1
Prerequisites for Traffic Storm Control
Restrictions for Traffic Storm Control
52-1
52-2
Information About Traffic Storm Control
52-2
Default Setting for Traffic Storm Control
52-4
How to Enable Traffic Storm Control
52-4
Displaying Traffic Storm Control Settings
Unknown Unicast Flood Control
52-5
53-1
Prerequisites for Unknown Traffic Flood Control
Restrictions for Unknown Traffic Flood Control
53-1
53-1
Information About Unknown Traffic Flood Control
Default Settings for Unknown Traffic Flood Control
How to Configure Unknown Traffic Flood Control
How to Configure UUFB
How to Configure UUFRL
53-2
53-2
53-2
53-2
53-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
37
Contents
Configuration Examples for Unknown Traffic Flood Control
IEEE 802.1X Port-Based Authentication
54-1
Prerequisites for 802.1X Authentication
54-1
Restrictions for 802.1X Authentication
54-2
802.1X Authentication
802.1X Host Mode
53-3
54-2
54-3
VLAN Assignment, Guest VLAN, Restricted VLAN, and Inaccessible Authentication
Bypass 54-3
MAC Authentication Bypass
Web-Based Authentication
54-5
54-5
Network Edge Access Topology (NEAT) and Client Information Signalling Protocol (CISP)
Information About 802.1X Port-Based Authentication
802.1X Overview
54-6
54-6
802.1X Device Roles
54-7
Port-based Authentication Process
54-8
Authentication Initiation and Message Exchange
Ports in Authorized and Unauthorized States
802.1X Host Modes
54-12
54-13
802.1X Authentication with DHCP Snooping
802.1X Accounting
54-10
54-15
54-16
802.1X Authentication with VLAN Assignment
54-17
Multiple VLANs and VLAN User Distribution with VLAN Assignment
802.1X Authentication with Guest VLAN
54-19
802.1X Authentication with Restricted VLAN
54-20
802.1X Authentication with Inaccessible Authentication Bypass
802.1X Authentication with Voice VLAN Ports
802.1X Authentication with Port Security
54-21
54-22
54-23
802.1X Authentication with ACL Assignments and Redirect URLs
802.1X Authentication with Port Descriptors
54-26
Network Admission Control Layer 2 IEEE 802.1X Validation
MAC Move
MAC Replace
54-23
54-26
802.1X Authentication with MAC Authentication Bypass
802.1X Authentication with Wake-on-LAN
54-18
54-27
54-28
54-28
54-29
802.1x Supplicant and Authenticator Switches with Network Edge Access Topology (NEAT)
54-30
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
38
54-5
Contents
Default Settings for 802.1X Port-Based Authentication
How to Configure 802.1X Port-Based Authentication
Enabling 802.1X Authentication
54-31
54-32
54-33
Configuring Switch-to-RADIUS-Server Communication
Configuring 802.1X Authenticator Host Mode
Enabling Fallback Authentication
54-34
54-35
54-36
Enabling Periodic Reauthentication
54-38
Manually Reauthenticating the Client Connected to a Port
54-39
Initializing Authentication for the Client Connected to a Port
Removing 802.1X Client Information Globally
54-40
Removing 802.1X Client Information from an Interface
Clearing Authentication Sessions
Changing 802.1X Timeouts
54-40
54-40
54-40
Setting the Switch-to-Client Frame Retransmission Number
Setting the Reauthentication Number
Configuring IEEE 802.1X Accounting
Configuring VLAN User Distribution
Configuring a Guest VLAN
54-42
54-43
54-43
54-44
54-45
Configuring a Restricted VLAN
54-46
Configuring the Inaccessible Authentication Bypass Feature
Configuring MAC Authentication Bypass
54-47
54-49
Configuring NAC Layer 2 IEEE 802.1X Validation
Configuring NAC Agentless Audit Support
54-50
54-51
Configuring the Switch for DACLs or Redirect URLs
Configuring 802.1X Authentication with WoL
Enabling MAC Move
54-39
54-51
54-53
54-53
Enabling MAC Replace
54-54
Configuring NEAT Authenticator and Supplicant Switches
Disabling 802.1X Authentication on the Port
54-56
Resetting the 802.1X Configuration to the Default Values
Displaying Authentication Status and Information
Displaying 802.1X Status
54-54
54-57
54-57
54-57
Displaying Authentication Methods and Status
54-58
Displaying MAC Authentication Bypass Status
54-61
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
39
Contents
Web-Based Authentication
55-1
Prerequisites for Web-based Authentication
55-1
Restrictions for Web-based Authentication
55-1
Information About Web-Based Authentication
Web-Based Authentication Overview
Device Roles
55-2
55-2
55-3
Host Detection
Session Creation
55-3
55-4
Authentication Process
AAA Fail Policy
55-4
55-5
Customization of the Authentication Proxy Web Pages
55-5
Web-based Authentication Interactions with Other Features
Default Web-Based Authentication Configuration
How to Configure Web-Based Authentication
55-7
55-7
Web-based Authentication Configuration Task List
55-8
Configuring the Authentication Rule and Interfaces
55-8
Configuring AAA Authentication
55-9
Configuring Switch-to-RADIUS-Server Communication
Configuring the HTTP Server
55-9
55-11
Configuring an AAA Fail Policy
55-13
Configuring the Web-based Authentication Parameters
Removing Web-based Authentication Cache Entries
Displaying Web-Based Authentication Status
Port Security
55-5
55-14
55-14
55-15
56-1
Prerequisites for Port Security
56-1
Restrictions for Port Security
56-1
Information About Port Security
56-2
Port Security with Dynamically Learned and Static MAC Addresses
Port Security with Sticky MAC Addresses
Port Security with IP Phones
Enabling Port Security
56-3
56-4
Default Port Security Configuration
How to Configure Port Security
56-3
56-4
56-4
56-4
Configuring the Port Security Violation Mode on a Port
56-6
Configuring the Maximum Number of Secure MAC Addresses on a Port
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
40
56-7
Contents
Enabling Port Security with Sticky MAC Addresses on a Port
Configuring a Static Secure MAC Address on a Port
Configuring Secure MAC Address Aging on a Port
Verifying the Port Security Configuration
56-8
56-8
56-9
56-10
Lawful Intercept
Lawful Intercept
57-1
Prerequisites for Lawful Intercept
57-1
Restrictions for Lawful Intercept
57-1
General Configuration Restrictions
MIB Guidelines
57-2
57-3
Information About Lawful Intercept
Lawful Intercept Overview
57-4
Benefits of Lawful Intercept
CALEA for Voice
57-3
57-4
57-5
Network Components Used for Lawful Intercept
Lawful Intercept Processing
Lawful Intercept MIBs
57-5
57-7
57-7
How to Configure Lawful Intercept Support
Security Considerations
57-9
57-9
Accessing the Lawful Intercept MIBs
57-9
Restricting Access to the Lawful Intercept MIBs
Configuring SNMPv3
57-10
57-10
Appendixes
Online Diagnostic Tests
1-1
Global Health-Monitoring Tests
TestAsicSync
1-2
1-2
TestEARLInternalTables
1-3
TestErrorCounterMonitor
TestFexModeLoopback
TestIntPortLoopback
1-3
1-4
1-4
TestL3TcamMonitoring
1-4
TestLtlFpoeMemoryConsistency
TestMacNotification
TestPortTxMonitoring
1-5
1-6
1-6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
41
Contents
TestScratchRegister
1-7
TestSnrMonitoring
1-7
TestUnusedPortLoopback
Per-Port Tests
1-8
1-8
TestActiveToStandbyLoopback
TestCCPLoopback
1-9
TestDataPortLoopback
TestDCPLoopback
1-10
1-10
TestL2CTSLoopback
1-11
TestL3CTSLoopback
1-11
TestLoopback
1-9
1-12
TestMediaLoopback
1-12
TestMgmtPortsLoopback
1-13
TestNetflowInlineRewrite
1-13
TestNonDisruptiveLoopback
TestNPLoopback
1-14
TestTransceiverIntegrity
PFC Layer 2 Tests
1-15
1-15
TestBadBpduTrap
1-15
TestDontConditionalLearn
TestMatchCapture
DFC Layer 2 Tests
1-17
1-17
TestBadBpdu
1-18
TestCapture
1-18
TestConditionalLearn
TestDontLearn
1-19
TestIndexLearn
1-20
TestNewLearn
1-19
1-20
TestPortSecurity
1-21
TestProtocolMatchChannel
TestStaticEntry
1-21
1-22
1-22
PFC Layer 3 Tests
TestAclDeny
1-22
1-23
TestAclPermit
1-23
TestAclRedirect
TestDQUP
1-16
1-16
TestNewIndexLearn
TestTrap
1-14
1-24
1-24
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
42
Contents
TestInbandEdit
1-25
TestIPv4FibShortcut
1-25
TestIPv6FibShortcut
1-26
TestL3Capture2
1-26
TestMPLSFibShortcut
1-27
TestNATFibShortcut
1-27
TestNetflowShortcut
1-28
TestRBAcl
1-28
DFC Layer 3 Tests
TestAclDeny
1-28
1-29
TestAclPermit
1-29
TestAclRedirect
TestInbandEdit
1-30
1-30
TestIPv4FibShortcut
1-31
TestIPv6FibShortcut
1-31
TestL3Capture2
1-32
TestMPLSFibShortcut
1-32
TestNATFibShortcut
1-33
TestNetflowShortcut
1-33
TestRBAcl
1-34
Replication Engine Tests
1-34
TestEgressSpan
1-34
TestIngressSpan
1-35
TestL3VlanMet
1-35
Fabric Tests
1-35
TestFabricCh0Health
1-36
TestFabricCh1Health
1-36
TestFabricExternalSnake
1-37
TestFabricFlowControlStatus
TestFabricInternalSnake
1-37
1-38
TestFabricVlanLoopback
1-38
TestFexFabricLinkStatus
1-39
TestSynchedFabChannel
1-39
Exhaustive Memory Tests
TestAclQosTcam
1-40
TestAsicMemory
1-40
TestEarlMemOnBootup
Service Module Tests
1-39
1-41
1-41
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
43
Contents
TestPcLoopback
1-41
TestPortASICLoopback
Stress Tests
1-42
1-42
TestEobcStressPing
TestMicroburst
1-42
1-43
TestNVRAMBatteryMonitor
TestTrafficStress
General Tests
1-43
1-44
1-44
ScheduleSwitchover
TestCFRW
1-44
1-45
TestFirmwareDiagStatus
TestOBFL
1-45
1-45
TestRwEngineOverSubscription
TestVDB
1-46
Critical Recovery Tests
1-46
TestTxPathMonitoring
ViSN Tests
1-46
1-47
1-47
TestRslHm
1-47
TestVSActiveToStandbyLoopback
TestVslBridgeLink
1-48
TestVslLocalLoopback
TestVslStatus
1-49
1-49
Migrating From a 12.2SX QoS Configuration
Command Migration
1-48
2-1
2-1
Global Configuration Command Queueing Parameters
INDEX
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
44
2-7
Preface
This preface describes who should read the Supervisor Engine 2T Software Configuration Guide,
Release 15.1SY, 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 15.1SY.
Related Documentation
See the documents listed on this page:
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.
[ ]
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
-45
Chapter
Convention
Description
boldface screen
Information you must enter is in boldface screen font.
Preface
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 Control—for 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
What’s 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
-46
PART
1
Product Overview
CH AP TE R
1
Product Overview
Note
•
Supervisor Engine 2T-10GE Flash Memory Devices, page 1-4
•
Supervisor Engine 2T-10GE Ports, page 1-4
•
Supervisor Engine 2T-10GE Connectivity Management Processor (CMP), page 1-5
•
Determining System Hardware Capacity, page 1-5
•
Module Status Monitoring, page 1-8
•
Enabling Visual Identification of Modules or Ports, page 1-8
•
User Interfaces, page 1-9
•
Software Features Supported in Hardware by the PFC and DFC, page 1-9
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
For complete information about the supported chassis, modules, and software features, see the
Release Notes for Cisco IOS Release 15.1SY:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/release_notes.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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-3
Chapter 1
Product Overview
Supervisor Engine 2T-10GE Flash Memory Devices
Supervisor Engine 2T-10GE 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.
•
bootdisk: (active) and slavebootdisk: (standby): 1-GB internal flash memory
Supervisor Engine 2T-10GE Ports
•
Console ports:
– EIA/TIA-232 (RS-232) port with RJ-45 connector
– USB port
By default (no media-type rj45 configured on the console 0 interface), either connector can be used
and if an active USB connection is detected, the RJ-45 connector is deactivated. With the no
media-type rj45 command configured on the console 0 interface, the RJ-45 connector can only be
used when there is no active USB connection. With the media-type rj45 command configured on
the console 0 interface, only the RJ-45 connector can be used. See this publication for information
about USB drivers:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Sup_E
ng_Guide/03instal.html#USB_Console_Port_Driver_Installation
Note
Note
With Release 15.1(1)SY, be aware of the console disconnect feature, which is
enabled by default.
•
Ports 1, 2, and 3: Gigabit Ethernet SFP (fiber or 10/100/1000 Mbps RJ-45)
•
Ports 4 and 5—10-Gigabit Ethernet X2
•
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 platform 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 Supervisor Engine 2T-10GE Connectivity Management Processor Configuration Guide for
information about the 10/100/1000 Mbps RJ-45 port.
See the “How to Configure Optional Interface Features” section on page 10-3 for information about
configuring the ports.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-4
Chapter 1
Product Overview
Supervisor Engine 2T-10GE Connectivity Management Processor (CMP)
Supervisor Engine 2T-10GE
Connectivity Management Processor (CMP)
See this publication:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/cmp_configuration/guide/sup2T_10GEcmp.ht
ml
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
3
0% / 0%
7 RP
2% / 0%
Processor memory: Module
Bytes:
Total
3
1612928756
7 RP
1569347520
I/O memory: Module
Bytes:
Total
3
268435456
7 RP
268435456
1 minute
1%
1%
Used
164136704
242739196
Used
21163672
110324056
5 minutes
1%
1%
%Used
10%
15%
%Used
8%
41%
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
3
Rx:
25
57626
Tx:
19
45490
7 RP
Rx:
36456689392
54747
Tx:
25
66898
Dropped packets
0
0
0
0
This example shows how to display the current and peak switching utilization:
Router# show platform hardware capacity fabric
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%
1
1
20G
12%
80% 12:34 12mar45
12%
80%
4
0
20G
12%
80% 12:34 12mar45
12%
80%
13
0
8G
12%
80% 12:34 12mar45
12%
80%
12:34
12:34
12:34
12:34
12mar45
12mar45
12mar45
12mar45
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-5
Chapter 1
Product Overview
Determining System Hardware Capacity
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
3
dfc#3-bootflash:
15990784
7 RP nvram:
2552192
7 RP const_nvram:
1048556
7 RP bootdisk:
1024196608
7 RP disk0:
1024655360
Used
0
40640
676
99713024
77824000
%Used
0%
2%
1%
10%
8%
This example shows how to display the capacity and utilization of the PFC and DFCs present in the
system:
Router# show platform hardware capacity forwarding
L2 Forwarding Resources
MAC Table usage:
Module Collisions Total
6
0 65536
VPN CAM usage:
Total
512
L3 Forwarding Resources
FIB TCAM usage:
Total
72 bits (IPv4, MPLS, EoM)
196608
144 bits (IP mcast, IPv6)
32768
detail:
Protocol
IPv4
MPLS
EoM
IPv6
IPv4 mcast
IPv6 mcast
Adjacency usage:
Forwarding engine load:
Module
6
Netflow Resources
TCAM utilization:
ICAM utilization:
Total
1048576
pps
8
Module
6
Module
6
Flowmasks:
Mask#
IPv4:
0
IPv4:
1
IPv4:
2
IPv4:
3
IPv6:
IPv6:
IPv6:
IPv6:
CPU Rate Limiters Resources
Rate limiters:
Layer 3
Layer 2
peak-pps
1972
0
1
2
3
%Used
1%
%Used
0%
Used
36
7
%Used
1%
1%
Used
36
0
0
%Used
1%
0%
0%
4
3
0
1%
1%
0%
Used
175
%Used
1%
peak-time
02:02:17 UTC Thu Apr 21 2005
Created
1
Created
0
Failed
0
Failed
0
%Used
0%
%Used
0%
Type
Features
reserved
none
Intf FulNAT_INGRESS NAT_EGRESS FM_GUARDIAN
unused
none
reserved
none
reserved
unused
unused
reserved
Total
9
4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-6
Used
11
Used
0
none
none
none
none
Used
4
2
Reserved
1
2
%Used
44%
50%
Chapter 1
Product Overview
Determining System Hardware Capacity
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
6
1%
1%
1%
1%
1%
1%
0%
0%
AND OR
0% 0%
ADJ
1%
Router#
This example shows how to display the interface resources:
Router# show platform hardware capacity interface
Interface drops:
Module
Total drops:
Tx
Rx
9
0
2
Interface buffer sizes:
Module
1
5
Router#
Bytes:
Highest drop port: Tx
0
Tx buffer
12345
12345
Rx
48
Rx buffer
12345
12345
This example shows how to display SPAN information:
Router# show platform hardware capacity monitor
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#
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 redundant
operationally non-redundant (single power supply)
System power: 3795W, 0W (0%) inline, 865W (23%) total allocated
Powered devices: 0 total, 0 Class3, 0 Class2, 0 Class1, 0 Class0, 0 Cisco
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-7
Chapter 1
Product Overview
Module Status Monitoring
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
6
Microflow policer configurations: Module
6
Netflow policer configurations: Module
6
Aggregate policer configs:
Module
6
Distributed policers: Total
Used
4096
1
QoS Tcam Entries: Module
1
2
3
Total
16384
Total
128
Total
384
Total
1024
%Used
1%
Total
16384
16384
16384
Used
16
Used
1
Used
0
Used
8
%Used
1%
%Used
1%
%Used
0%
%Used
1%
Used
1171
1171
1171
%Used
7%
7%
7%
Router#
This example shows how to display information about the key system resources:
Router# show platform hardware capacity system
System Resources
PFC operating mode: PFC4
Supervisor redundancy mode: administratively sso, operationally sso
Switching resources: Module
Part number
Series
CEF mode
6
VS-SUP2T-10G
supervisor
CEF
Router#
This example shows how to display VLAN information:
Router# show platform hardware capacity vlan
VLANs: 4094 total, 10 VTP, 0 extended, 0 internal, 4084 free
Router#
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.
Enabling Visual Identification of Modules or Ports
To make a module easy to identify visually, you can configure the blue ID LED (also called the blue
beacon LED) on these modules to blink:
•
Supervisor Engine 2T-10GE
•
WS-X6908-10GE 10-Gigabit Ethernet switching module
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-8
Chapter 1
Product Overview
User Interfaces
This is the command to enable blinking on a module:
Router(config)# hw-module slot slot_number led beacon
This is the command to disable blinking on a module:
Router(config)# no hw-module slot slot_number led beacon
To make a port easy to identify visually, you can configure the link LED on these modules to blink:
•
Supervisor Engine 2T-10GE
•
WS-X6908-10GE 10-Gigabit Ethernet switching module
This is the command to enable blinking on a port:
Router(config-if)# led beacon
This is the command to disable blinking:
Router(config-if)# no led beacon
User Interfaces
•
CLI—See Chapter 2, “Command-Line Interfaces.”
•
SNMP—See the SNMP Configuration Guide, Cisco IOS Release 15.1SY, at this URL:
http://www.cisco.com/en/US/docs/ios-xml/ios/snmp/configuration/15sy/snmp-15-sy-book.html
•
Cisco IOS web browser interface—See the HTTP Services Configuration Guide,
Cisco IOS Release 15.1SY, at this URL:
http://www.cisco.com/en/US/docs/ios-xml/ios/https/configuration/15-sy/https-15-sy-book.html
Software Features Supported in Hardware by the PFC and DFC
•
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 40, “Cisco IOS ACL
Support.”
•
Bidirectional Protocol Independent Multicast (PIM) in hardware—See “IPv4 Bidirectional PIM”
section on page 14-8.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-9
Chapter 1
Product Overview
Software Features Supported in Hardware by the PFC and DFC
•
Dynamic address resolution protocol (ARP) inspection (DAI)—See Chapter 51, “Dynamic ARP
Inspection (DAI).”
•
Multiple-path Unicast Reverse Path Forwarding (RPF) Check—To configure Unicast RPF Check,
see the “Unicast Reverse Path Forwarding (uRPF) Check” section on page 47-6.
•
Except on MPLS interfaces, Network Address Translation (NAT) for IPv4 unicast and multicast
traffic.
Note the following information about hardware-assisted NAT:
– The PFC and any DFCs do not support NAT of multicast traffic. (CSCtd18777)
– The PFC and any DFCs do not support NAT configured with a route-map that specifies length.
– When you configure NAT and NDE on an interface, the RP processes all traffic in fragmented
packets in software.
– 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 platform rate-limit unicast acl {ingress | egress}
command.
Note
•
NetFlow—See Chapter 23, “NetFlow Hardware Support.”
•
Policy-based routing (PBR)—See Chapter 4, “Policy-Based Routing (PBR).”
The PFC and DFC do not provide hardware acceleration for tunnels configured with the tunnel key
command.
•
IPv4 Multicast over point-to-point generic route encapsulation (GRE) Tunnels.
•
GRE Tunneling and IP in IP Tunneling—The PFC and DFC 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.
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-xml/ios/interface/configuration/15-sy/ir-impl-tun.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:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-10
Chapter 1
Product Overview
Software Features Supported in Hardware by the PFC and DFC
– The PFC4 and DFC4 support up to 8 multicast rendevous points (RP).
– 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. (CSCdy72539)
– Each tunnel interface uses one internal VLAN.
– Each tunnel interface uses one additional router MAC address entry per router MAC address.
– The PFC and DFC support PFC QoS features on tunnel interfaces.
– Tunnels configured with egress features on the tunnel interface are supported in software.
Examples of egress features are output Cisco IOS ACLs, NAT (for inside to outside translation),
TCP intercept, and encryption.
•
Tip
VLAN ACLs (VACLs)—To configure VACLs, see Chapter 45, “VLAN ACLs (VACLs).”
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-11
Chapter 1
Software Features Supported in Hardware by the PFC and DFC
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-12
Product Overview
PART
2
Configuration Fundamentals
CH AP TE R
2
Command-Line Interfaces
Note
•
Accessing the CLI, page 2-1
•
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-6
•
Securing the CLI, page 2-7
•
ROM-Monitor Command-Line Interface, page 2-7
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Accessing the CLI
•
Accessing the CLI through the EIA/TIA-232 Console Interface, page 2-2
•
Accessing the CLI through Telnet, page 2-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-1
Chapter 2
Command-Line Interfaces
Accessing the CLI
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
Router#
Completes enable mode enable.
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.
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:
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
Step 3
Router> enable
Initiates enable mode enable.
Step 4
Password: password
Router#
Completes enable mode enable.
Step 5
Router# quit
Exits the session when finished.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-2
If no password has been configured, press Return.
Chapter 2
Command-Line Interfaces
Performing Command Line Processing
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
press the left arrow key
Moves the cursor back one character.
Press Ctrl-F or
press the right arrow key
Moves the cursor forward one character.
Note
Note
The arrow keys function only on ANSI-compatible terminals
such as VT100s.
The arrow keys function only on ANSI-compatible terminals
such as VT100s.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
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
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.
Note
Ctrl-N or the down arrow key.
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.
Note
Router# show history
The arrow keys function only on
ANSI-compatible terminals such as
VT100s.
The arrow keys function only on
ANSI-compatible terminals such as
VT100s.
While in EXEC mode, lists the last several
commands you have just entered.
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-xml/ios/fundamentals/configuration/15_sy/fundamentals-15-sy-book.
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-6.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-4
Chapter 2
Command-Line Interfaces
Cisco IOS Command Modes
Note
You can enter EXEC mode commands by entering the do keyword before the EXEC mode command.
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
User EXEC
Connect to remote devices, change Log in.
terminal settings on a temporary
basis, perform basic tests, and
display system information.
Prompt
Router>
Privileged EXEC (enable) Set operating parameters. The
privileged command set includes
the commands in user EXEC
mode, as well as the configure
command. Use this command to
access the other command modes.
From the user EXEC mode, enter
the enable command and the
enable password.
Router#
Global configuration
Configure features that affect the
system as a whole.
From the privileged EXEC mode,
enter the configure terminal
command.
Router(config)#
Interface configuration
Many features are enabled for a
particular interface. Interface
commands enable or modify the
operation of an interface.
From global configuration mode,
enter the interface type slot/port
command.
Router(config-if)#
Console configuration
From the directly connected
console or the virtual terminal
used with Telnet, use this
configuration mode to configure
the console interface.
From global configuration mode, Router(config-line)#
enter the line console 0 command.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-5
Chapter 2
Command-Line Interfaces
Displaying a List of Cisco IOS Commands and Syntax
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?
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
network
overwrite-network
terminal
<cr>
Configure
Configure
Overwrite
Configure
from NV memory
from a TFTP network host
NV memory from TFTP network host
from the terminal
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-6
Chapter 2
Command-Line Interfaces
Securing the CLI
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 this publication:
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, see this
publication:
http://www.cisco.com/en/US/docs/ios-xml/ios/security/config_library/15-sy/secdata-15-sy-library.html
•
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, see this publication:
http://www.cisco.com/en/US/docs/ios-xml/ios/security/config_library/15-sy/secdata-15-sy-library.html
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/sec_user_services/configuration/guide/sec_cfg_sec_4cli.ht
ml
•
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/15-sy/sec-usr-ssh-sec-copy.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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-7
Chapter 2
Command-Line Interfaces
ROM-Monitor Command-Line Interface
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.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-8
CH AP TE R
3
Smart Port Macros
Note
•
Prerequisites for Smart Port Macros, page 3-1
•
Restrictions for Smart Port Macros, page 3-2
•
Information About Smart Port Macros, page 3-3
•
Default Settings for Smart Port Macros, page 3-4
•
How to Configure Smart Port Macros, page 3-4
•
Verifying the Smart Port Macro Configuration, page 3-15
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Smart Port Macros
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-1
Chapter 3
Smart Port Macros
Restrictions for Smart Port Macros
Restrictions for Smart Port Macros
•
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.
•
You cannot edit a macro. If the name following the macro name command is an existing macro’s
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.
•
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-2
Chapter 3
Smart Port Macros
Information About Smart Port Macros
•
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.
Information About Smart Port Macros
•
Information about Cisco-Provided Smart Port Macros, page 3-3
•
Information about User-Created Smart Port Macros, page 3-4
Information about Cisco-Provided Smart Port Macros
Use the show parser macro user EXEC command to display the Cisco-provided smart port macros and
the commands they contain.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-3
Chapter 3
Smart Port Macros
Default Settings for Smart Port Macros
Information about 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.
Default Settings for Smart Port Macros
This example shows how to list the Cisco-provided smart port macros that are provided by default:
Router# show parser macro brief
default global
: cisco-global
default interface: cisco-desktop
default interface: cisco-phone
default interface: cisco-switch
default interface: cisco-router
How to Configure Smart Port Macros
•
Using the Cisco-Provided Smart Port Macros, page 3-4
•
Creating Smart Port Macros, page 3-13
Using 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
•
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
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-4
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
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
platform qos map cos-dscp 0 8 16 26 32 46 48 56
# Enable aggressive mode UDLD on all fiber uplinks
udld aggressive
# 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.
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
•
Displaying the Contents of the cisco-desktop Smart Port Macro, page 3-6
•
Applying the cisco-desktop Smart Port Macro, page 3-6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-5
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
Displaying 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
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 bpduguard enable
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.
Step 2
Router(config)# interface type slot/port
Selects the interface to configure.
Step 3
Router(config-if)# macro apply cisco-desktop
$AVID access_vlan_ID
Applies the cisco-desktop smart port macro. The
recommended range for access_vlan_ID is 2–4094.
Step 4
Router(config-if)# end
Returns to privileged EXEC mode.
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
--------------------------------------------------------------
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-6
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
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
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
•
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
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 bpduguard enable
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-7
Chapter 3
Smart Port Macros
How to Configure 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.
Step 2
Router(config)# interface type slot/port
Selects the interface to configure.
Step 3
Router(config-if)# macro apply cisco-phone $AVID
access_vlan_ID $VVID voice_vlan_ID
Applies the cisco-phone smart port macro. The
recommended range for access_vlan_ID is 2–4094. The
recommended range for voice_vlan_ID is 2–4094.
Step 4
Router(config-if)# end
Returns to privileged EXEC mode.
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 15.1SY:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/release_notes.html
•
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
Router# show parser macro description interface gigabitethernet 2/2
Global Macro(s): cisco-global
Interface
Macro Description(s)
--------------------------------------------------------------
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-8
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
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]
platform 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
•
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
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
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-9
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
# speed up
switchport
switchport
switchport
convergence
trunk encapsulation dot1q
mode trunk
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.
Step 2
Router(config)# interface type slot/port
Selects the interface to configure.
Step 3
Router(config-if)# macro apply cisco-switch
$NVID native_vlan_ID
Applies the cisco-switch smart port macro. The
recommended range for native_vlan_ID is 2–4094.
Step 4
Router(config-if)# end
Returns to privileged EXEC mode.
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
switchport nonegotiate
shutdown
macro description cisco-switch
spanning-tree link-type point-to-point
end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-10
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
Using 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-11
Displaying 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
# speed up
switchport
switchport
switchport
trunk and disable negotiation to
convergence
trunk encapsulation dot1q
mode trunk
nonegotiate
# Configure qos to trust this interface
auto qos voip trust
platform qos trust dscp
# Ensure fast
# Ensure that
spanning-tree
spanning-tree
access to the network when enabling the interface.
switch devices cannot become active on the interface.
portfast
bpduguard enable
Router#
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.
Step 2
Router(config)# interface type slot/port
Selects the interface to configure.
Step 3
Router(config-if)# macro apply cisco-router
$NVID native_vlan_ID
Applies the cisco-router smart port macro. The
recommended range for native_vlan_ID is 2–4094.
Step 4
Router(config-if)# end
Returns to privileged EXEC mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-11
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
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
platform qos trust cos command to the port, but the cisco-router smart port macro changes the port trust
state to trust DSCP with the platform qos trust dscp command. When you apply the cisco-router smart
port macro, ignore messages that instruct you to enter the platform 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
!
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]
platform qos trust dscp
auto qos voip trust
macro description cisco-router
spanning-tree portfast
spanning-tree bpduguard enable
end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-12
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
Creating Smart Port Macros
•
Creating Smart Port Macros, page 3-13
•
Applying User-Created Smart Port Macros, page 3-14
Creating Smart Port Macros
To create a smart port macro, perform this task:
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-13
Chapter 3
Smart Port Macros
How to Configure Smart Port Macros
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 User-Created Smart Port Macros
To apply a smart port macro, perform this task:
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}
macro-name [keyword value] [keyword value]
[keyword value]
Applies or traces and applies each individual command
defined in the macro.
For global macros:
•
To find any syntax or configuration errors, enter the
macro global 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 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.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-14
Chapter 3
Smart Port Macros
Verifying the Smart Port Macro Configuration
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’
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 gigabitethernet1/2
Router(config-if)# macro apply desktop-config
Router(config-if)# end
Router# show parser macro description
Interface
Macro Description
-------------------------------------------------------------Gi1/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
Verifying the Smart Port Macro Configuration
Table 3-2
Commands to Display 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
Tip
[interface interface-id] Displays the macro description for all interfaces or for a
specified interface.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-15
Chapter 3
Verifying the Smart Port Macro Configuration
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-16
Smart Port Macros
PART
2
Virtual Switching Systems (VSS)
CH AP TE R
4
Virtual Switching Systems
Note
•
Prerequisites for VSS, page 4-1
•
Restrictions for VSS, page 4-2
•
Information About Virtual Switching Systems, page 4-4
•
Default Settings for VSS, page 4-27
•
How to Configure a VSS, page 4-28
•
How to Upgrade a VSS, page 4-53
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for VSS
The VSS configurations in the startup-config file must match on both chassis.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-1
Chapter 4
Virtual Switching Systems
Restrictions for VSS
Restrictions for VSS
•
General VSS Restrictions, page 4-2
•
VSL Restrictions, page 4-2
•
Multichassis EtherChannel (MEC) Restrictions, page 4-2
•
Dual-Active Detection Restrictions, page 4-3
•
VSS Mode Service Module Restrictions, page 4-4
General VSS Restrictions
•
VSS mode does not support supervisor engine redundancy within a chassis.
•
If you configure a new value for switch priority, the change takes effect only after you save the
configuration file and perform a restart.
•
Out-of-band MAC address table synchronization among DFC-equipped switching modules (the
mac address-table synchronize command) is enabled automatically in VSS mode, which is the
recommended configuration.
•
Because the output of the show running-config command on ICS supervisor engines could be out
of sync with the active supervisor engine, ICS supervisor engines do not support the
show running-config command. The active and standby supervisor engines support the
show running-config command.
VSL 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 platform qos channel-consistency command is automatically applied when you configure
the VSL. Do not remove this command.
•
VSL ports cannot be Mini Protocol Analyzer sources (the monitor ... capture command). Monitor
capture sessions cannot be started if a source is the VSL on the port channel of the standby switch.
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 (MEC) Restrictions
•
All links in an MEC must terminate locally on the active or standby chassis of the same virtual
domain.
•
For an MEC using the LACP control protocol, the minlinks command argument defines the
minimum number of physical links in each chassis for the MEC to be operational.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-2
Chapter 4
Virtual Switching Systems
Restrictions for VSS
•
For an MEC using the LACP control protocol, the maxbundle command argument 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 “Information about LACP 1:1 Redundancy” section on page 13-6.
•
An MEC can be connected to another MEC in a different VSS domain.
•
Ports on the supervisor engines are not stateful and will experience a reset across switchovers (see
the “Switchover Process Restrictions” section on page 7-2).
•
With an MEC that includes supervisor engine ports configured on a VSS that supports the VSS
Quad-Sup SSO (VS4O) feature, be aware of CSCuh51005.
Dual-Active Detection Restrictions
•
If Flex Links are configured on the VSS, use PAgP dual-active detection.
•
For dual-active detection link redundancy, configure 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.
•
When you configure dual-active fast hello mode, all existing configurations are removed
automatically from the interface except for these commands:
– 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
•
Only these configuration commands are available on dual-active detection fast hello ports:
– default
– description
– dual-active
– exit
– load-interval
– logging
– no
– shutdown
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-3
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
•
ASIC-specific QoS commands are not configurable on dual-active detection 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 Chapter 33, “Restrictions for
PFC QoS.”
VSS Mode Service Module Restrictions
Note
•
When configuring and attaching VLAN groups to a service module interface, 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, use the switch {1 | 2} command keyword.
•
EtherChannel load balancing (ECLB) is not supported between an IDSM-2 in the active chassis and
an IDSM-2 in the standby chassis.
•
A switchover between two service modules in separate chassis of a VSS is considered an
intrachassis switchover.
For detailed instructions, restrictions, and guidelines for a service module in VSS mode, see the
configuration guide and command reference for the service module.
Information About Virtual Switching Systems
•
VSS Overview, page 4-4
•
VSS Redundancy, page 4-12
•
Multichassis EtherChannels, page 4-15
•
Packet Handling, page 4-18
•
System Monitoring, page 4-22
•
Dual-Active Detection, page 4-24
•
VSS Initialization, page 4-25
•
VSS Topology, page 4-5
•
Key Concepts, page 4-5
•
VSS Functionality, page 4-8
•
Hardware Requirements, page 4-10
•
Information about VSL Topology, page 4-12
VSS Overview
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-4
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
VSS Topology
Network operators increase network reliability by configuring switches in redundant pairs and by
provisioning links to both switches in the redundant pair. Figure 4-1 shows a typical 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.
VSS mode combines a pair of switches into a single network element. VSS mode manages the redundant
links, which externally act as a single port channel.
VSS mode 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 Network Design
Access
Distribution
181320
Core
Key Concepts
•
Virtual Switching System, page 4-5
•
Active and Standby Chassis, page 4-6
•
Virtual Switch Link, page 4-7
•
Multichassis EtherChannel (MEC), page 4-7
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. VSS mode manages
redundancy and load balancing on the port channel. This capability enables a loop-free Layer 2 network
topology. VSS mode also simplifies the Layer 3 network topology because VSS mode reduces the
number of routing peers in the network.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-5
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
VSS in the Distribution Network
Physical view
Logical view
Virtual Distribution Switch
Virtual Distribution Switch
Access
Access
181321
Figure 4-2
Active and Standby Chassis
When you create or restart a VSS, the peer chassis negotiate their roles. One chassis becomes the active
chassis, and the other chassis becomes the standby.
The active chassis controls the VSS. It runs the Layer 2 and Layer 3 control protocols for the switching
modules on both chassis. The active chassis also provides management functions for the VSS, such as
module online insertion and removal (OIR) and the console interface.
The active and standby chassis perform packet forwarding for ingress data traffic on their locally hosted
interfaces. However, the standby chassis sends all control traffic to the active chassis for processing.
You can defer the traffic load on a multichassis EtherChannel (MEC) chassis to address traffic recovery
performance during the standby chassis startup. For example, Figure 4-3 represents network layout
where a VSS (active and standby switches) is interacting with an upstream switch (switch 2) and a
downstream switch (switch 1).
Figure 4-3
Switch Interconnected Through VSS
Switch 2
PO2
Active
Switch
Standby
Switch
Switch 1
282323
PO1
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-6
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
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.
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-4. 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-4
Virtual Switch Link
Virtual switch
Chassis 2
181322
Chassis 1
Virtual switch link
(VSL)
Multichassis EtherChannel (MEC)
An EtherChannel, which is configured on a port channel interface, is 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 MEC is a port channel with member ports on both chassis of the VSS. A connected non-VSS device
views the MEC as a standard EtherChannel. See Figure 4-5.
VSS mode supports a maximum of 512 EtherChannels. This limit applies to the combined total of
regular EtherChannels and MECs. Because the VSL requires two EtherChannel numbers (one for each
chassis), there are 510 user-configurable EtherChannels. Service modules that use an internal
EtherChannel are included in the total.
Figure 4-5
VSS with MEC
VSL
Chassis 1
Chassis 2
181323
MEC
Note
Ports on the supervisor engines are not stateful and will experience a reset across switchovers (see the
“Switchover Process Restrictions” section on page 7-2).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-7
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
VSS Functionality
•
Redundancy and High Availability, page 4-8
•
Packet Handling, page 4-8
•
System Management, page 4-8
•
VSS Quad-Sup SSO (VS4O), page 4-9
•
Interface Naming Convention, page 4-10
•
Software Features, page 4-10
Redundancy and High Availability
In VSS mode, supervisor engine redundancy operates between the active and standby chassis, using
stateful switchover (SSO) and nonstop forwarding (NSF). The peer chassis exchange configuration and
state information across the VSL and the standby supervisor engine runs in hot standby mode.
The standby chassis monitors the active chassis using the VSL. If it detects failure, the standby chassis
initiates a switchover and takes on the active role. When the failed chassis recovers, it takes on the
standby role.
Note
Ports on the supervisor engines are not stateful and will experience a reset across switchovers (see the
“Switchover Process Restrictions” section on page 7-2).
If the VSL fails completely, the standby chassis assumes that the active chassis has failed, and initiates
a switchover. After the switchover, if both chassis are 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-24.
Packet Handling
The 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 standby chassis is actively forwarding traffic, the active supervisor engine distributes
updates to the standby supervisor engine PFC and all standby chassis DFCs.
System Management
The active supervisor engine acts as a single point of control for the VSS. For example, the active
supervisor engine handles OIR of switching modules on both chassis. The active supervisor engine uses
VSL to send messages to and from local ports on the standby chassis.
The command console on the active supervisor engine is used to control both chassis. In virtual switch
mode, the command console on the standby supervisor engine blocks attempts to enter configuration
mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-8
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
The standby chassis runs a subset of system management tasks. For example, the standby chassis handles
its own power management.
VSS Quad-Sup SSO (VS4O)
Release 15.1(1)SY1 and later releases support the VSS Quad-Sup SSO (VS4O) feature.
Figure 4-6
Typical VSS Quad-Supervisor Configuration
Supervisor 2:
standby, ICA
Supervisor 3 ICS
Supervisor 4 ICS
Linecard 1
Linecard 1
Linecard 2
Linecard 2
Linecard N
Linecard N
Active chassis
197277
VSL
Supervisor 1:
active, ICA
Standby chassis
These are the quad-supervisor VSS roles:
•
In-chassis active (ICA) supervisor engines—The VSS active supervisor engine in one chassis and
the VSS standby supervisor engine in the other chassis are ICA supervisor engines.
If the VSS active ICA supervisor engine crashes, a switchover to the standby ICA supervisor engine
in other chassis occurs. Both VSS chassis remain active. All switching modules remain active.
In the chassis with the previously active ICA supervisor engine, an SSO switchover from the
previously active ICA supervisor engine to the ICS standby supervisor engine occurs and the ICS
takes over as the ICA. The failed ICA reloads and becomes the ICS.
You can verify the switchover mode of the supervisor engines by entering the show module
command.
•
In-chassis standby (ICS) supervisor engines—The other supervisor engines are ICS supervisor
engines. The supervisor engine uplinks ports are available to forward traffic.
Note
ICS supervisor engines do not support show commands. To avoid tracebacks, do not issue
show commands on ICS supervisor engines.
If the supervisor engine PFC modes do not match then an ICS supervisor engine is reset to
ROMMON. Configure both chassis to run in the same PFC mode.
ICS supervisor engines boot in SSO standby mode, which fully initializes and configures the ICS
and maintains stateful feature and user session information.
To verify the switchover mode of the supervisor engines, enter the show module command.
When not in VSS quad supervisor engine mode, if you insert a supervisor engine to be an ICS , the
supervisor engine resets to update the supervisor engine number and then reboots before going
online.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-9
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Quad-supervisor SSO (VS4O) supports eFSU upgrades. You can upgrade or downgrade your VSS
system using ISSU. See “How to Upgrade a VSS” section on page 4-53 for more information about eFSU
upgrades.
Interface Naming Convention
In VSS mode, interfaces are specified using 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, VSS mode has feature parity with non-VSS mode. Major exceptions include:
•
VSS mode does not support supervisor engine redundancy within a chassis.
•
Port-based QoS and PACLs can be applied to any physical port, except VSL ports. PACLs can be
applied to no more than 2,046 ports.
Hardware Requirements
•
Chassis and Modules, page 4-10
•
VSL Hardware Requirements, page 4-10
•
PFC, DFC, and CFC Requirements, page 4-11
•
Multichassis EtherChannel Requirements, page 4-11
•
Service Module Support, page 4-11
Chassis and Modules
Table 4-1
VSS Hardware Requirements
Hardware
Count Requirements
Chassis
2
All chassis supported with Supervisor Engine 2T in
Cisco IOS Release 15.1SY support VSS mode.
Note
Supervisor Engines
2
The two chassis need not be identical.
Either two VS-SUP2T-10G or two VS-SUP2T-10G-XL supervisor
engines.
The two supervisor engines must match exactly.
Switching Modules
2+
VSS mode support as shown in the Release Notes.
In VSS mode, unsupported switching modules remain powered off.
VSL Hardware Requirements
The VSL EtherChannel supports only 40-Gigabit and 10-Gigabit Ethernet ports. The ports can be located
on the supervisor engine (recommended) or on one of the following switching modules:
•
WS-X6904-40G-2T
•
WS-X6908-10GE
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-10
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
•
WS-X6816-10T-2T, WS-X6716-10T
•
WS-X6816-10G-2T, WS-X6716-10G
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 40-Gigabit or 10-Gigabit
Ethernet ports on switching modules that support the VSL.
Note
•
When using the ports on a switching module that can operate in oversubscribed mode as VSL links,
you must operate the ports in performance mode, not in oversubscription mode. Enter the no
hw-module switch x slot y oversubscription port-group num command when configuring the
switching module. If you enter the no hw-module switch switch_number slot slot_number
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 mode for VSL with the unused ports administratively shutdown, while the
others can still operate in oversubscribed mode.
PFC, DFC, and CFC Requirements
Switching modules with a CFC, DFC4, or DFC4XL support VSS mode.
With a PFC4, the VSS will automatically operate in PFC4 mode, even if some of the modules have a
DFC4XL. With a PFC4XL, but some modules equipped with a DFC4, you need to configure the VSS to
operate in PFC4 mode. The platform hardware vsl pfc mode non-xl configuration command sets the
system to operate in PFC4 mode after the next restart. See the “SSO Dependencies” section on page 4-26
for further details about this command.
Multichassis EtherChannel Requirements
Physical links from any module with a CFC, DFC4, or DFC4XL can be used to implement a
Multichassis EtherChannel (MEC).
Service Module Support
•
Application Control Engine (ACE):
– ACE20-MOD-K9
– ACE30-MOD-K9
•
ASA Services Module: WS-SVC-ASA-SM1-K9
•
Firewall Services Module (FWSM): WS-SVC-FWM-1-K9
•
Network Analysis Module (NAM):
– WS-SVC-NAM-1
– WS-SVC-NAM-2
– WS-SVC-NAM3-6G-K9
•
Wireless Services Module (WiSM):
– WS-SVC-WISM-1-K9
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-11
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
– WS-SVC-WISM2
Note
Before deploying a service module in VSS mode, upgrade the module to the minimum supported release
in standalone mode. See the service module release notes for information about the minimum required
service module software version.
Information about VSL Topology
A VSS is two chassis that communicate using the VSL, which is a special port group. 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 40- or 10-Gigabit Ethernet ports. This configuration
provides additional VSL capacity. See Figure 4-7 for an example topology.
Figure 4-7
VSL Topology Example
VSS Redundancy
•
Overview, page 4-13
•
RPR and SSO Redundancy, page 4-13
•
Failed Chassis Recovery, page 4-14
•
VSL Failure, page 4-15
•
User Actions, page 4-15
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-12
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Overview
A VSS operates stateful switchover (SSO) between the active and standby supervisor engines. Compared
to standalone mode, VSS mode has the following important differences in its redundancy model:
•
The active and standby supervisor engines are hosted in separate chassis and use the VSL to
exchange information.
•
The active supervisor engine controls both chassis of the VSS. The active supervisor engine runs the
Layer 2 and Layer 3 control protocols and manages the switching modules on both chassis.
•
The active and standby chassis both perform data traffic forwarding.
If the active supervisor engine fails, the standby supervisor engine initiates a switchover and assumes
the active role.
RPR and SSO Redundancy
The VSS normally runs stateful switchover (SSO) between the active and standby supervisor engines
(see Figure 4-8). The VSS determines the role of each supervisor engine during initialization.
Figure 4-8
Chassis Roles in VSS Mode
The VSS uses the VSL link to synchronize configuration data from the active to the standby supervisor
engine. Also, protocols and features that support high availability synchronize their events and state
information to the standby supervisor engine.
VSS mode operates with stateful switchover (SSO) redundancy if it meets the following requirements:
•
Both supervisor engines are running the same software version.
•
The VSL-related configuration in the two chassis matches.
•
The PFC mode matches.
•
SSO and nonstop forwarding (NSF) are configured on both chassis.
See the “SSO Dependencies” section on page 4-26 for additional details about the requirements for SSO
redundancy on a VSS. See Chapter 8, “Nonstop Forwarding (NSF)” for information about configuring
SSO and NSF.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-13
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
With SSO redundancy, the supervisor engine in the standby chassis runs in hot standby state and is
always ready to assume control following a fault on the active supervisor engine. Configuration,
forwarding, and state information are synchronized from the active supervisor engine to the redundant
supervisor engine at startup and whenever changes to the 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 uses route processor redundancy
(RPR). In RPR mode, the active supervisor engine does not synchronize configuration changes or state
information with the standby. The standby supervisor engine is only partially initialized and the
switching modules on the standby supervisor are not powered up. If a switchover occurs, the standby
supervisor engine completes its initialization and powers up the switching modules. Traffic is disrupted
for approximately 2 minutes.
Failed Chassis Recovery
If the active chassis or supervisor engine fails, the VSS initiates a stateful switchover (SSO) and the
former standby supervisor engine assumes the active role. The failed chassis performs recovery action
by reloading the supervisor engine.
If the 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 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 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 standby chassis
become operational after the SSO.
After the SSO, much of the processing power of the active supervisor engine is consumed in bringing up
a large number of ports simultaneously in the 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:
•
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 Standby Recovery” section on page 4-44.
•
You can defer the load sharing of the peer switch’s MEC member ports during reestablishment of
the port connections. See the “Failed Chassis MEC Recovery” section on page 4-17 for details about
load share deferral.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-14
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
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 standby chassis detects complete VSL link failure, it initiates a stateful switchover (SSO). If the
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 active chassis is still operational, this is a dual-active scenario. The
VSS detects that both chassis are operating in active mode and performs recovery action. See the
“Dual-Active Detection” section on page 4-24 for additional details about the dual-active scenario.
User Actions
From the 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 standby chassis, use redundancy reload peer command.
To force a switchover from the active to the standby supervisor engine, use the redundancy
force-switchover command.
To reset the VSS standby supervisor engine or to reset either the VSS active or VSS standby supervisor
engines, use the redundancy reload shelf command.
Multichassis EtherChannels
•
Overview, page 4-15
•
MEC Failure Scenarios, page 4-16
Overview
A multichassis EtherChannel is an EtherChannel with ports that terminate on both chassis of the VSS
(see Figure 4-9). 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 active chassis, the VSS will select
an MEC link from the 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 active chassis. PAgP or LACP control packets destined for an MEC link on the standby chassis are
sent across VSL.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-15
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
An MEC can support up to eight active physical links, which can be distributed in any proportion
between the active and standby chassis.
Figure 4-9
MEC Topology
Router, switch
or server
Active chassis
MEC
Supervisor
engine
Standby chassis
181327
Virtual switch
Supervisor
engine
MEC Failure Scenarios
Note
•
Single MEC Link Failure, page 4-16
•
All MEC Links to the Active Chassis Fail, page 4-16
•
All MEC Links to the Standby Chassis Fail, page 4-17
•
All MEC Links Fail, page 4-17
•
Standby Chassis Failure, page 4-17
•
Active Chassis Failure, page 4-17
•
Failed Chassis MEC Recovery, page 4-17
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).
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 Active Chassis Fail
If all links to the active chassis fail, the MEC becomes a regular EtherChannel with operational links to
the standby chassis.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-16
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Data traffic terminating on the active chassis reaches the MEC by crossing the VSL to the standby
chassis. Control protocols continue to run in the active chassis. Protocol messages reach the MEC by
crossing the VSL.
All MEC Links to the Standby Chassis Fail
If all links fail to the standby chassis, the MEC becomes a regular EtherChannel with operational links
to the active chassis.
Control protocols continue to run in the active chassis. All control and data traffic from the standby
chassis reaches the MEC by crossing the VSL to the 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.
Standby Chassis Failure
If the standby chassis fails, the MEC becomes a regular EtherChannel with operational links on the
active chassis. Connected peer switches detect the link failures, and adjust their load-balancing
algorithms to use only the links to the active chassis.
Active Chassis Failure
Active chassis failure results in a stateful switchover (SSO). See the “VSS Redundancy” section on
page 4-12 for details about SSO on a VSS. After the switchover, the MEC is operational on the new 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 active chassis.
Failed Chassis MEC Recovery
When a failed chassis returns to service as the new 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 peer’s deferred MEC port channels will establish
with an initial load share of 0. During the configured deferral interval, the peer’s 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-17
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Packet Handling
•
Packet Handling Overview, page 4-18
•
Traffic on the VSL, page 4-18
•
Layer 2 Protocols, page 4-19
•
Layer 3 Protocols, page 4-19
•
SPAN Support with VSS, page 4-21
Packet Handling Overview
In VSS mode, the 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. VSS mode minimizes
the amount of data traffic that must traverse the VSL.
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 active supervisor engine, but received or transmitted by interfaces on the standby
chassis. Control traffic also includes module programming between the active supervisor engine and
switching modules on the 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 active supervisor engine where the ingress interface is on the
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 standby chassis
to the 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).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-18
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Layer 2 Protocols
•
Layer 2 Protocol Overview, page 4-19
•
Spanning Tree Protocol, page 4-19
•
Virtual Trunk Protocol, page 4-19
•
EtherChannel Control Protocols, page 4-19
•
Multicast Protocols, page 4-19
Layer 2 Protocol Overview
The 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 standby chassis
switching modules must traverse the VSL to reach the active supervisor engine.
Spanning Tree Protocol
The active chassis runs Spanning Tree Protocol (STP). The standby chassis redirects STP BPDUs across
the VSL to the 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 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-24.
Multicast Protocols
With Release 15.1(1)SY1 and later releases, fast-redirect optimization makes multicast traffic
redirection between inter-chassis or intra-chassis line cards faster for Layer 2 trunk and Layer3
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
•
Layer 3 Protocol Overview, page 4-20
•
IPv4, page 4-20
•
IPv6, MPLS, and VPLS, page 4-20
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-19
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
•
IPv4 Multicast, page 4-20
•
Software Features, page 4-21
Layer 3 Protocol Overview
The RP on the 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 standby chassis is actively forwarding traffic, the active supervisor engine distributes
updates to the standby supervisor engine PFC and all standby chassis DFCs.
IPv4
The supervisor engine on the active chassis runs the IPv4 routing protocols and performs any required
software forwarding.
Routing updates received on the standby chassis are redirected to the active chassis across the VSL.
Hardware forwarding is distributed across all DFCs on the VSS. The supervisor engine on the active
chassis sends FIB updates to all local DFCs, remote DFCs, and the standby supervisor engine PFC.
All hardware routing uses the router MAC address assigned by the active supervisor engine. After a
switchover, the original MAC address is still used.
The supervisor engine on the 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 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. See Chapter 8, “Nonstop Forwarding (NSF).”
From a routing peer perspective, EtherChannels remain operational during a switchover (only the links
to the failed chassis are down).
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, MPLS, and VPLS
The VSS supports IPv6 unicast, MPLS, and VPLS.
IPv4 Multicast
The IPv4 multicast protocols run on the active supervisor engine. Internet Group Management Protocol
(IGMP) and Protocol Independent Multicast (PIM) protocol packets received on the standby supervisor
engine are transmitted across VSL to the active chassis.
The active supervisor engine sends IGMP and PIM protocol packets to the standby supervisor engine in
order to maintain Layer 2 information for stateful switchover (SSO).
The active supervisor engine distributes multicast FIB and adjacency table updates to the standby
supervisor engine and switching module DFCs.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-20
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
For Layer 3 multicast in the VSS, learned multicast routes are stored in hardware in the 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 active chassis does not program the multicast expansion table (MET) on the
standby chassis. The standby supervisor engine programs the outgoing interface hardware entries for all
local multicast receivers
If all switching modules on the active chassis and standby chassis are egress capable, the multicast
replication mode is set to egress mode; otherwise, the mode is set to ingress mode.
In egress replication 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.
Software Features
Software features run only on the active supervisor engine. Incoming packets to the 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 active
supervisor engine, the standby supervisor engine, and all DFCs.
SPAN Support with VSS
The VSS supports all SPAN features for non-VSL interfaces. The VSS supports SPAN features on VSL
interfaces with the following limitations:
•
VSL ports cannot be a SPAN destination.
•
VSL ports cannot be an RSPAN, ERSPAN, or egress-only SPAN source.
•
If a VSL port is configured as a local SPAN source, the SPAN destination interface must be on the
same chassis as the source interface.
•
SPAN copies are always made on the chassis where the ingress port is located.
•
Two VSLs cannot share the same SPAN session.
•
A pair of LTL indices are used to avoid duplicate SPAN copies across VSL interfaces.
The number of SPAN sessions available to a VSS is the same as for a single chassis running in standalone
mode.
With a VSL port as a SPAN source, the following limitations apply:
•
The SPAN destination must be on the same chassis.
•
Port channel interfaces cannot be the SPAN destination.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-21
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
System Monitoring
•
Power Management, page 4-22
•
Environmental Monitoring, page 4-22
•
File System Access, page 4-22
•
Diagnostics, page 4-22
•
Service Modules, page 4-23
•
Network Management, page 4-23
Power Management
You can control power-related functions for the standby chassis from the active chassis. For example,
use the (no) power enable switch command to control power to the modules and slots on the 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 standby chassis reports notifications to
the active supervisor engine. The active chassis gathers log messages for both chassis. The active chassis
synchronizes the calendar and system clock to the standby chassis.
File System Access
You can access file systems of both chassis from the active chassis. Prefix the device name with the
switch number and slot number to access directories on the standby chassis. For example, the command
dir sw2-slot6-disk0: lists the contents of disk0 on the standby chassis (assuming switch 2 is the standby
chassis). You can access the standby chassis file system only when VSL is operational.
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.
VSL Diagnostics
The following VSL-specific diagnostics tests are disruptive:
•
TestVSActiveToStandbyLoopback
•
TestVslBridgeLink
•
TestVslLocalLoopback
The following VSL-specific diagnostics test is available for VSL ports on switching modules or the
supervisor engine. This test is not disruptive:
•
TestVslStatus
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-22
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Service Modules
The following system monitoring and system management guidelines apply to service modules
supported in VSS mode:
•
The supervisor engine in the same chassis as the service module controls service module power up.
After service modules are online, you can initiate sessions from the active supervisor engine to the
service module.
•
Use the session command to connect to a service module. If a service module is in the standby
chassis, the session runs over the VSL.
•
The active chassis performs graceful shutdown of all service modules, including any in the standby
chassis.
Network Management
•
Telnet over SSH Sessions and the Web Browser User Interface, page 4-23
•
SNMP, page 4-23
•
Console Connections, page 4-23
Telnet over SSH Sessions and the Web Browser User Interface
VSS mode supports remote access using Telnet over SSH sessions and the Cisco web browser user
interface.
All remote access is directed to the active supervisor engine, which manages the VSS.
A VSS switchover disconnects Telnet over SSH sessions and web browser sessions.
SNMP
The SNMP agent runs on the active supervisor engine. CISCO-VIRTUAL-SWITCH-MIB is the MIB for
VSS 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
Console Connections
Connect console cables to both supervisor engine console ports. The console on the standby chassis adds
the characters “-stdby” to the command line prompt to indicate that the chassis is operating in standby
mode. You cannot enter configuration mode on the standby chassis console.
The following example shows the prompt on the standby console:
Router-stdby> show switch virtual
Switch mode
:
Virtual switch domain number :
Local switch number
:
Local switch operational role:
Virtual Switch
100
1
Virtual Switch Standby
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-23
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Peer switch number
: 2
Peer switch operational role : Virtual Switch Active
Dual-Active Detection
•
Dual-Active Detection Overview, page 4-24
•
Dual-Active Detection Using Enhanced PAgP, page 4-24
•
Dual-Active Detection Using Dual-Active Fast Hello Packets, page 4-25
•
Recovery Actions, page 4-25
Dual-Active Detection Overview
If the VSL fails, the standby chassis cannot determine the state of the active chassis. To ensure that
switchover occurs without delay, the standby chassis assumes the active chassis has failed and initiates
switchover to take over the active role.
If the original active chassis is still operational, both chassis are now 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 two methods for detecting a dual-active scenario:
•
Enhanced PAgP—Uses PAgP messaging over the MEC links to communicate between the two
chassis through a neighbor switch.
•
dual-active fast-hello—Uses special hello messages over a backup Ethernet connection.
You can configure both detection methods to be 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.
Dual-Active Detection Using Enhanced PAgP
If a VSS MEC terminates on a Cisco switch, you can run the port aggregation protocol (PAgP) on the
MEC. If enhanced PAgP is running on an MEC between the VSS and another switch running
Release 12.2(33)SXH1 or a later release, the VSS can use enhanced PAgP to detect a dual-active
scenario.
The MEC must have at least one port on each chassis of the VSS. In VSS mode, PAgP messages include
a new type length value (TLV) that contains the ID of the VSS active switch. Only switches in VSS mode
send the new TLV.
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 active chassis is still operational, it detects the dual-active scenario because the active ID
in the PAgP messages changes. This chassis initiates recovery actions as described in the “Recovery
Actions” section on page 4-25.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-24
Chapter 4
Virtual Switching Systems
Information About Virtual Switching Systems
Dual-Active Detection Using Dual-Active Fast Hello Packets
To use the dual-active fast hello packet detection method, you must provision a direct Ethernet
connection between the two VSS chassis. 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 peer’s 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. For more information, see the “Configuring Enhanced PAgP
Dual-Active Detection” section on page 4-46.
Recovery Actions
An 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 physically repair the VSL failure.
When the shut down chassis detects that VSL is operational again, the chassis reloads and returns to
service as the standby chassis.
Loopback interfaces are also shut down in recovery mode. Do not configure loopback interfaces 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 save the running configuration and then
reload manually.
VSS Initialization
•
VSS Initialization Overview, page 4-25
•
Virtual Switch Link Protocol, page 4-26
•
SSO Dependencies, page 4-26
•
Initialization Procedure, page 4-27
VSS Initialization Overview
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 active role. The VSS forms when the second
chassis becomes operational and both chassis bring up their VSL interfaces.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-25
Chapter 4
Virtual Switching Systems
Information About 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 (active or 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.
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 standby chassis sends virtual
switch information from the startup-config file to the active chassis. The 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 active chassis console and the
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 active chassis, and then restart the standby chassis.
•
PFC mode check—If both supervisor engines are provisioned with PFC4, the VSS will
automatically operate in PFC4 mode, even if some of the switching modules are equipped with
DFC4XLs.
However, if the supervisor engines are provisioned with PFC4XL and there is a mixture of DFC4
and DFC4XL switching modules, the system PFC mode will depend on how the DFC4XL and
DFC4XL 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 PFC4XL and all the switching modules in the chassis are provisioned with
DFC4XL, the PFC mode for the chassis is PFC4XL. However, if any of the switching modules is
provisioned with DFC4, the chassis PFC mode will be set to PFC4. 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 non-xl command to force the
VSS to operate in PFC4 mode after the next reload.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-26
Chapter 4
Virtual Switching Systems
Default Settings for VSS
•
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 8, “Nonstop Forwarding (NSF).”
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-12.
Initialization Procedure
•
VSL Initialization, page 4-27
•
System Initialization, page 4-27
•
VSL Down, page 4-27
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 (active or 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 (active or standby).
3.
The active chassis completes the boot sequence, including the consistency check described in the
“SSO Dependencies” section on page 4-26.
4.
If the consistency check completed successfully, the standby chassis comes up in SSO standby
mode. If the consistency check failed, the standby chassis comes up in RPR mode.
5.
The active chassis synchronizes configuration and application data to the standby chassis.
System Initialization
If you boot both chassis simultaneously, the VSL ports become active, and the chassis will come up as
active and 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 active. When
you subsequently boot up the other chassis, the VSL links become active, and the new chassis comes up
as 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 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.
Default Settings for VSS
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-27
Chapter 4
Virtual Switching Systems
How to Configure a VSS
How to Configure a VSS
•
Converting to a VSS, page 4-28
•
Displaying VSS Information, page 4-35
•
Converting a VSS to Standalone Chassis, page 4-35
•
Configuring VSS Parameters, page 4-37
•
Configuring Multichassis EtherChannels, page 4-45
•
Configuring Port Load Share Deferral on the Peer Switch, page 4-46
•
Configuring Dual-Active Detection, page 4-46
•
Configuring Service Modules in a VSS, page 4-50
•
Viewing Chassis Status and Module Information in a VSS, page 4-53
•
Performing a Fast Software Upgrade of a VSS, page 4-53
•
Performing an Enhanced Fast Software Upgrade of a VSS, page 4-55
Converting to a VSS
•
VSS Conversion Overview, page 4-28
•
Backing Up the Standalone Configuration, page 4-29
•
Configuring SSO and NSF, page 4-30
•
Assigning Virtual Switch Domain and Switch Numbers, page 4-31
•
Configuring the VSL Port Channel, page 4-31
•
Configuring the VSL Ports, page 4-32
•
Verifying the PFC Operating Mode, page 4-32
•
Converting the Chassis to Virtual Switch Mode, page 4-33
•
Auto-Configuring the Standby VSL Information, page 4-34
•
(Optional) Configuring Standby Chassis Modules, page 4-34
VSS Conversion Overview
The standalone mode is the default operating mode (a single chassis switch). VSS mode combines two
standalone switches into one virtual switching system (VSS), operating in VSS mode.
Note
When you convert two standalone switches into one VSS, all non-VSL configuration settings on the
standby chassis revert to default settings.
To convert two standalone chassis into a VSS, 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-28
Chapter 4
Virtual Switching Systems
How to Configure a VSS
•
Configure the peer VSL information.
In the procedures that follow, the example commands assume the configuration shown in Figure 4-10.
Figure 4-10 Example VSS
T 5/1
T 5/2
Chassis B
(Switch 2)
181325
Chassis A
(Switch 1)
Virtual switch link
(VSL)
Two chassis, A and B, are converted into a VSS with virtual switch domain 100. 10-Gigabit Ethernet
port 5/1 on Switch 1 is connected to 10-Gigabit Ethernet port 5/2 on Switch 2 to form the VSL.
Backing Up the Standalone Configuration
Save the configuration files for both chassis. These files are needed to revert to standalone mode from
virtual switch mode.
Switch 1 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
disk0:old-startup-config
Copies the startup configuration to a backup file.
Switch 2 Task
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
disk0:old-startup-config
Copies the startup configuration to a backup file.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-29
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Configuring SSO and NSF
SSO and NSF must be configured and enabled on both chassis.
Switch 1 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 ospf processID
Enables an OSPF routing process, which places the
router in router configuration mode.
Step 5
Switch-1(config-router)# nsf
Enables NSF operations for OSPF.
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.
Switch 2 Task
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.
Step 3
Switch-2(config-red)# exit
Exits redundancy configuration mode.
Step 4
Switch-2(config)# router ospf processID
Enables an OSPF routing process, which places the
router in router configuration mode.
Step 5
Switch-2(config-router)# nsf
Enables NSF operations for OSPF.
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 8, “Nonstop Forwarding
(NSF).”
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-30
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Assigning Virtual Switch Domain and Switch Numbers
Configure the same virtual switch domain number on both chassis. 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.
Switch 1 Task
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.
Switch 2 Task
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).
Configuring the VSL Port Channel
The VSL is configured with a unique port channel on each chassis. During the conversion, the VSS
configures both port channels on the active chassis. If the 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.
Switch 1 Task
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-31
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Switch 2 Task
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.
Configuring the VSL Ports
You must add the VSL physical ports to the port channel. In the following example, 10-Gigabit Ethernet
ports 3/1 and 3/2 on Switch 1 are connected to 10-Gigabit Ethernet ports 5/2 and 5/3 on Switch 2. For
VSL line redundancy, configure the VSL with at least two ports per chassis. For module redundancy, the
two ports can be on different switching modules in each chassis.
Switch 1 Task
Command
Purpose
Step 1
Switch-1(config)# interface range
tengigabitethernet 3/1-2
Enters configuration mode for interface range
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
Switch-1(config-if)# no shutdown
Activates the port.
Switch 2 Task
Command
Purpose
Step 1
Switch-2(config)# interface range tengigabitethernet
5/2-3
Enters configuration mode for interface range
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.
Verifying the PFC Operating Mode
Ensure that the PFC operating mode matches on both chassis. 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
PFC4XL mode, you can configure it to use PFC4 mode with the platform hardware vsl pfc mode
non-xl command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-32
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Switch 1 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-1(config)# platform hardware vsl pfc mode
(Optional) Sets the PFC operating mode to PFC4 on
Chassis A.
non-xl
Switch 2 Task
Command
Purpose
Step 3 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 4 Switch-2(config)# platform hardware vsl pfc mode
(Optional) Sets the PFC operating mode to PFC4 on
Chassis B.
non-xl
Converting the Chassis to Virtual Switch Mode
Conversion to VSS 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_#.
Before restarting, 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.
Switch 1 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.
Switch 2Task
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-33
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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_#).
Auto-Configuring the Standby VSL Information
The two chassis now form a VSS, and the system will auto-configure the standby VSL. After the merge
has completed successfully, enter all configuration commands for the VSS on the active chassis. The
startup configuration file is automatically synchronized to the standby chassis after the standby chassis
reaches the ready state. The VSSmode automatically merges the configuration information on the
standby chassis.
All non-VSL interface configurations on the standby chassis revert to the default configuration and
non-VSL related configurations are not merged. If you fail to perform any of the required configurations,
you will have to repeat the configuration on the active chassis. Auto-configuration merges these
commands for the standby chassis:
•
hw-module switch number slot number
•
switch virtual domain number
•
switch number priority priority
•
power redundancy-mode combined switch number
•
no power enable switch num module number
•
interface port-channel num switch virtual link number
•
interface type switch_#/slot_#/port_# channel-group number mode on
(Optional) Configuring Standby Chassis Modules
After the reboot, each chassis contains the module provisioning for its own slots. In addition, the
modules from the standby chassis are automatically provisioned on the active chassis with default
configuration.
Configurations for the standby chassis modules revert 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(50)SY 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-34
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
Displaying VSS Information
These commands display basic information about the VSS:
Command
Purpose
show switch virtual
Displays the virtual switch domain number, and the switch number and role for each of the
chassis.
show switch virtual role
Displays the role, switch number, and priority for each of the chassis in the VSS.
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 domain number :
Local switch number
:
Local switch operational role:
Peer switch number
:
Peer switch operational role :
Virtual Switch
100
1
Virtual Switch Active
2
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
•
Copying the VSS Configuration to a Backup File, page 4-36
•
Converting the Active Chassis to Standalone, page 4-36
•
Converting the Peer Chassis to Standalone, page 4-36
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-35
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Copying the VSS Configuration to a Backup File
Save the configuration file from the active chassis. You may need this file if you convert to virtual switch
mode again. You only need to save the file from the active chassis, because the configuration file on the
standby chassis is identical to the file on the 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 you 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 Active Chassis to Standalone
When you convert the active chassis to standalone mode, the 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 standby chassis of the VSS becomes active. VSL links on this chassis are down because the peer is
no longer available.
To convert the active chassis to standalone mode, perform this task on the 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 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 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-36
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Configuring VSS Parameters
•
Configuring VSL Switch Priority, page 4-37
•
Configuring the PFC Mode, page 4-38
•
Configuring a VSL, page 4-39
•
Configuring VSL Encryption, page 4-39
•
Displaying VSL Information, page 4-41
•
Configuring VSL QoS, page 4-42
•
Subcommands for VSL Port Channels, page 4-42
•
Subcommands for VSL Ports, page 4-43
•
Configuring the Router MAC Address Assignment, page 4-43
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
[priority_num]
Configures the priority for the chassis. The switch
with the higher priority assumes the active role. The
range is 1 (lowest priority) to 255 (highest priority);
the default is 100.
Note
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
standby state, you can make it the 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.
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 configured priority values. You can manually set the standby
switch to active using the redundancy force-switchover command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-37
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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 the PFC Mode
If you have a mixture of DFC4 and DFC4XL switching modules in the VSS, set the PFC mode by
performing this task:
Command
Purpose
Router(config)# platform hardware vsl pfc
mode non-xl
Sets the PFC configuration mode for the VSS to
PFC4.
Note
This command requires a system reload
before it takes effect.
This example shows how to set the PFC configuration mode for the VSS to PFC4. You can wait until the
next maintenance window to perform the reload command.
Router(config)# platform hardware vsl pfc mode non-xl
Router(config)# end
Router# reload
If all the supervisor engines and switching modules in the VSS are XL, the following warning is
displayed if you set the PFC mode to PFC4:
Router(config)# platform hardware vsl pfc mode non-xl
PFC Preferred Mode: PFC4XL. The discrepancy between Operating Mode and
Preferred Mode could be due to PFC mode config. Your System has all PFC4XL modules.
Remove ' platform hardware vsl pfc mode non-xl ' from global config.
This example shows how to display the operating and configured PFC modes:
Router# show platform hardware pfc mode
PFC operating mode : PFC4
Configured PFC operating mode : PFC4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-38
Chapter 4
Virtual Switching Systems
How to Configure 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
Configuring VSL Encryption
•
VSL Encryption Overview, page 4-39
•
VSL Encryption Restrictions, page 4-39
•
Configuring the VSL Encryption Key, page 4-40
•
Enabling VSL Encryption, page 4-40
•
Displaying the VSL Encryption State, page 4-41
VSL Encryption Overview
Cisco IOS Release 15.1SY supports HW-based encryption on a VSL configured on a
Supervisor Engine 2T or WS-X6908-10GE switching module. VSL encryption uses an encryption key
that you manually configure. The encryption key is stored securely.
VSL Encryption Restrictions
•
VSL encryption requires a MACSec license on each chassis.
•
The chassis must be rebooted to configure an encryption key or enable VSL encryption.
•
You enter the encryption key on the active chassis. You cannot enter the encryption key on the
standby chassis.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-39
Chapter 4
Virtual Switching Systems
How to Configure a VSS
•
If it is acceptable to send the key as plain text over the VSL to the other chassis, then you can allow
one chassis to send the key to the other chassis. For maximum security, configure the encryption key
on each chassis.
•
There are no show commands that display the encryption key.
•
You cannot remove the encryption key while VSL encryption is enabled.
•
The following commands take effect after a reboot:
– To remove the encryption key, enter the clear switch pmk EXEC mode command.
– To disable VSL encryption, enter the no vsl-encryption virtual switch domain configuration
submode command.
•
If the encryption key and VSL encryption state on the two chassis do not match, the VSL does not
transition to the link-up state.
•
In VSS mode, you cannot configure the FIPS encryption mode without VSL encryption. To avoid a
system shutdown, enable VSL encryption before you enable FIPS encryption mode. (CSCts96040,
CSCtx58304)
Configuring the VSL Encryption Key
To configure the VSL encryption key, perform this task:
Command
Purpose
Router# switch pmk encryption_key
Configures the VSL encryption key.
•
encryption_key is a hexadecimal string up to
32 characters (256 bits).
•
You will be asked if you want to automatically
synchronize the encryption key. If you do not
automatically synchronize the encryption key,
configure the same encryption key on the
other chassis.
This example show how to configure a VSL encryption key:
Router# switch pmk encryption_key
Key effective only upon reboot and will override old VSL PMK.
Key needs to be provisioned on both VSS switches.
Warning - Sending the key to standby will cause the key to be sent over an unencrypted VSL
link.
Do you want to automatically synchronize the key [yes/no]?
Enabling VSL Encryption
To enable VSL encryption, perform this task:
Command
Purpose
Step 1
Router(config)# switch virtual domain domain_id
Enters VSS configuration mode.
Step 2
Router(config-vs-domain)# vsl-encryption
Enables VSL encryption.
This example shows how to enable VSL encryption:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-40
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Router(config)# switch virtual domain domain_id
Router(config-vs-domain)# vsl-encryption
Note
•
If you manually configure the encryption key on each chassis:
– Reboot the active chassis; the standby chassis becomes active.
– Configure the encryption key on new active chassis.
– Reboot the new active chassis.
•
If you allow the encryption key to be sent to the standby chassis, reboot the active chassis.
Displaying the VSL Encryption State
This example shows how to display the VSL encryption state:
Router# show switch virtual link | include Encryption
VSL Encryption : Configured Mode - On, Operational Mode - On
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
I
H
R
U
f
-
down
P - bundled in port-channel
stand-alone s - suspended
Hot-standby (LACP only)
Layer3
S - Layer2
in use
N - not in use, no aggregation
failed to allocate aggregator
M
m
u
w
-
not in use, no aggregation due to minimum links not met
not in use, port not aggregated due to minimum links not met
unsuitable for bundling
waiting to be aggregated
Group Port-channel Protocol
Ports
------+-------------+-----------+--------------------------------------------10
Po10(RU)
Te1/5/4(P) Te1/5/5(P)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-41
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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 platform qos 10g-only global configuration command.
In Cisco IOS Release 12.2(50)SY and later releases, when the platform 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.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-42
Chapter 4
Virtual Switching Systems
How to Configure a VSS
Table 4-2
Interface Subcommands for VSL Port Channels (continued)
Subcommand
Description
load-interval
Specifies interval for load calculation for an
interface.
logging
Configures logging for interface.
platform
Specifies platform-specific command.
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.
Configuring the Router MAC Address Assignment
When the VSS is started for the first time, the initial 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
active chassis as the router MAC address.
In the rare case where both chassis later become inactive and then start up with the second supervisor
engine becoming the initial 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-43
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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 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
Configuring Deferred Port Activation During Standby Recovery
Instead of allowing all ports to be activated simultaneously when a failed chassis is restarted as the
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-44
Chapter 4
Virtual Switching Systems
How to Configure a VSS
To specify deferred port activation, perform this task:
Command
Purpose
Router(config)# switch virtual domain 1
Enters VSS configuration mode.
Router(config-vs-domain)# standby port
delay delay-time
Specifies that the port activation will be initially
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.
Router(config-vs-domain)# standby port
bringup number cycle-time
Specifies the number of ports to be activated per
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(50)SY support a maximum of 128 port channels.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-45
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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:
Step 1
Command
Purpose
Router(config)# port-channel load-defer time
(Optional) Configures the port load share deferral
interval for all port channels.
•
time—The 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
channel-num
Enters interface configuration mode for the port channel.
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.
Note
To provide the best support for multicast traffic, configure the load share deferral feature on all
EtherChannels that have member ports on more than one module.
Configuring Dual-Active Detection
•
Configuring Enhanced PAgP Dual-Active Detection, page 4-46
•
Configuring Fast Hello Dual-Active Detection, page 4-48
•
Configuring the Exclusion List, page 4-49
•
Displaying Dual-Active Detection, page 4-49
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 below).
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-46
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
trust channel-group group_number
Enables trust mode for the specified port channel.
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
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-47
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
fast-hello
Enables the fast hello dual-active detection method.
Fast hello dual-active detection is enabled by default.
Step 3
Router(config-vs-domain)# exit
Exits virtual switch submode.
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.
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
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-48
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
interface type switch/slot/port
Specifies an interface to exclude from shutting down
in dual-active recovery.
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 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
[pagp | fast-hello | summary]
Displays information about dual-active detection
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
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 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
-
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-49
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
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
Note
•
Opening a Session with a Service Module in a VSS, page 4-51
•
Assigning a VLAN Group to a Firewall Service Module in a VSS, page 4-51
•
Assigning a VLAN Group to an ACE Service Module in a VSS, page 4-52
•
Verifying Injected Routes in a Service Module in a VSS, page 4-52
For detailed instructions on configuring a service module in a VSS, see the configuration guide and
command reference for the service module.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-50
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
processor-id
Opens a session with the specified module.
•
num—Specifies the switch to access; valid values are 1
and 2.
•
slot—Specifies the slot number of the module.
•
processor-id—Specifies 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
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
vlan-group [vlan_group | vlan_range]
Assigns VLANs to a firewall group in the specified module.
•
num—Specifies the switch to access; valid values are 1
and 2.
•
slot—Specifies the slot number of the module.
•
vlan_group—Specifies the group ID as an integer.
•
vlan_range—Specifies 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-51
Chapter 4
Virtual Switching Systems
How to Configure a VSS
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
vlan-group [vlan_group | vlan_range]
Assign VLANs to a firewall group in the specified module.
•
num—Specifies the switch to access; valid values are 1
and 2.
•
slot—Specifies the slot number of the module.
•
vlan_group—Specifies the group ID as an integer.
•
vlan_range—Specifies 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
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.
•
num—Specifies the switch to access; valid values are 1
and 2.
•
slot—Specifies 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-52
20
1
0
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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:
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
16
CEF720 16 port 10GE with DFC
WS-X6716-10GE
SAL1215M55F
3
1
Application Control Engine Module
ACE20-MOD-K9
SAD120603SU
.
.
.
How to Upgrade a VSS
•
Performing a Fast Software Upgrade of a VSS, page 4-53
•
Performing an Enhanced Fast Software Upgrade of a VSS, page 4-55
Performing a Fast Software Upgrade of a VSS
The FSU of a VSS is similar to the RPR-based standalone chassis FSU described in Chapter 6, “Fast
Software Upgrade.” While the standalone chassis upgrade is initiated by reloading the standby supervisor
engine, the VSS upgrade is initiated by reloading the standby chassis. During the FSU procedure, a
software version mismatch between the active and the 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
If IA (Instant Access) client switches are connected to the VSS system they will be automatically
upgraded via the client software image that is bundled with the Catalyst 6500 or 6800 Series software
image. This is initiated once active supervisor detects version mismatch between the bundled image and
running image on FEX.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-53
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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 active and 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.
Step 8
Router# redundancy reload peer
Reloads the 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 standby chassis will be in RPR redundancy
mode.
Note
Step 9
Router# redundancy force-switchover
Before reloading the standby chassis, make sure
you wait long enough to ensure that all
configuration synchronization changes have
completed.
Forces the standby chassis to assume the role of the
active chassis running the new Cisco IOS image. The
modules are reloaded and the module software is
downloaded from the new active chassis.
The old active chassis reboots with the new image and
becomes the 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
IA (Instant Access) Client Upgrade Details
When IA client switches are attached to the VSS system they are also upgraded as part of the FSU
upgrade process in case active supervisor detects version mismatch between the bundled image and
running image on FEX. A TAR file containing the IA image is loaded from the VSS controller switch to
the IA stack master switch. The IA stack master extracts the bin (Binary) image into local flash and then
the IA stack master extracts the bin image to the local flash of each slave switch in the stack in serial,
one switch at a time. All switches in the entire IA stack are reloaded at the same time after all the
switches in the stack have extracted the image. If there are multiple IA stacks being upgraded they will
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-54
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
upgrade in parallel via this procedure. The fex stagger {delay_value} global configuration command
can be used to avoid excessively high CPU that might occur on the VSS controller if multiple IA client
switch stacks attempted to initialize simultaneously. FEX refers to Fabric Extender which is an alternate
term for an Instant Access switch.
For an IA stack of 2 switches, it takes approximately 30 minutes for the stack to be upgraded (5 minutes
to detect a version mismatch between the VSS controller and IA switch stack, 15 minutes for image
download/extraction of tar file between VSS controller and 6800IA, 5-10 minutes for switch reload). It
takes approximately 40 minutes for a stack of 5 switches (max stack size) to be upgraded.
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)
and applies to both the Catalyst 6500 and Catalyst 6800 series switches. 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 Chapter 5, “Enhanced Fast
Software Upgrade,” 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. If one or more IA (Instant Access) client switches are connected
to the VSS switch pair, then they should be upgraded at this time via the client software image that is
bundled with the Catalyst 6500 or 6800 Series software image from active Supervisor.
This section contains the following topics:
•
eFSU Restrictions and Guidelines, page 4-55
•
eFSU Stages for a VSS Upgrade, page 4-56
•
Configuring and Performing an eFSU Upgrade, page 4-58
•
eFSU Upgrade Example when IA (Instant Access) Client Switches are not present, page 4-61
•
eFSU Upgrade Example when IA (Instant Access) Client Switches are present, page 4-66
eFSU Restrictions and Guidelines
When performing an eFSU, note the following guidelines and restrictions:
•
Images from different features sets, regardless of release, fail the eFSU compatibility check.
•
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 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 Chapter 5, “Enhanced Fast Software Upgrade,” with the following
differences:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-55
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
– 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 the eFSU process, do not perform any changes to the VSS or IA (Instant Access) switching
topology.
•
During the eFSU process, running 2 separate images on the 2 VSS controller switches for an
extended period of time is not recommended.
•
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 standby’s ICS is not because the bootvar of the
SSO VSS standby’s ICS is not modified during an abort executed after the loadversion command.
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-56
•
Loadversion Stage, page 4-57
•
Runversion Stage, page 4-57
•
Acceptversion Stage (Optional), page 4-57
•
IA Runversion Stage (Required only when Instant Access Client switches are present), page 4-57
•
Commitversion Stage, page 4-57
•
Abortversion (Optional), page 4-58
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.
Note
Make sure enough space is available to accommodate one image in each 6800ia flash, which are
registered with VSS.
FEX should be dual-homed to avoid the loss of connectivity. FEX will take auto image download process
in case FEX losses the connectivity with controller as a part of upgrade.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-56
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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
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 before the issu commitversion command is entered to complete the upgrade
process.
IA Runversion Stage (Required only when Instant Access Client switches are present)
eFSU capability is extended to support Instant Access clients. The client software image is bundled with
the Catalyst 6500 or 6800 Series software image. A user can specify a set (or range) of Instant Access
client stacks (FEX IDs) by using issu runversion fex <fex-id | all | id,.. > command, this command
forces the FEX to download the bundled image from the controller (in case FEX is running a different
version than the bundled version) and reloads with downloaded image. After all clients are upgraded, a
user has the choice to either abort the eFSU process and go back to the previous software version using
the issu abortversion command or to complete the eFSU process with the issu commitversion
command. FEX refers to Fabric Extender which is an alternate term for an Instant Access switch.
Commitversion Stage
Note
Commit version is not allowed unless all FEX are upgraded to bundled version present on the active
Supervisor.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-57
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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.
IA Client Upgrade Details
When IA (Instant Access) client switches are attached (FEX should be in online state) to the VSS system
they are also upgraded as part of the eFSU upgrade process. During the IA Runversion Stage of an eFSU
upgrade a TAR file containing the IA image is loaded from the VSS controller switch to the IA stack
master switch. The IA stack master extracts the bin (Binary) image into local flash and then the IA stack
master extracts the bin image to the local flash of each slave switch in the stack in serial, one switch at
a time. During the eFSU process each IA switch in a stack is booted individually once the image is
extracted. This is to ensure that there is always a master switch active in the switch stack. If there are
multiple IA stacks being upgraded they will upgrade in parallel via this procedure. The fex stagger
{delay_value} global configuration command can be used to avoid excessively high CPU that might
occur on the VSS controller if multiple IA client switch stacks attempted to initialize simultaneously.
FEX refers to Fabric Extender which is an alternate term for an Instant Access switch.
For an IA stack of 2 switches, it takes approximately 30 minutes for the stack to be upgraded (5 minutes
to detect a version mismatch between the VSS controller and IA switch stack, 15 minutes for image
download/extraction of tar file between VSS controller and 6800IA, 5-10 minutes for switch reload). It
takes approximately 40 minutes for a stack of 5 switches (max stack size) to be upgraded.
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-59
•
Performing an eFSU Upgrade, page 4-59
•
Aborting an eFSU Upgrade, page 4-60
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-58
Chapter 4
Virtual Switching Systems
How to Upgrade 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
{seconds | hh:mm:ss}
(Optional) Sets the rollback timer to ensure that the upgrade
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 ICS’s, 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
Step 3
Router# issu loadversion
[active_switch/slot] active-image
[standby_switch/slot] standby-image
You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Starts the upgrade process by loading the new software
image onto the 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-59
Chapter 4
Virtual Switching Systems
How to Upgrade 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 runversion [fex [range] <num |
all>]
(Required only when IA client switches are
present)
Upgrades the IA Client switches with the client software
image that is bundled with the Catalyst 6500 or 6800 Series
software VSS system image. A user can specify a set (or
range) of FEX IDs for the rolling upgrade and reload of
Instant Access clients. FEX refers to Fabric Extender which
is an alternate term for an Instant Access switch.
Step 7
Router# issu commitversion
Loads the new software image onto the VSS 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 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 when IA (Instant Access)
Client Switches are not present” section on page 4-61.
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-60
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
eFSU Upgrade Example when IA (Instant Access) Client Switches are not present
This example shows how to perform and verify an eFSU upgrade for a VSS when IA (Instant Access)
Client Switches are not present.
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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
=
=
=
=
=
=
=
=
=
1/2
Active
Init
disk0:s72033-oldversion.v1,12;
sso
N/A
N/A
disk0:s72033-oldversion.v1
PrstVbl
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
2/7
Standby
Init
disk0:s72033-oldversion.v1,12;
sso
N/A
N/A
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
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
0
18
0x0
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-61
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
000133: Aug 6 16:17:44.486 PST:
TenGigabitEthernet1/2/4, changed
000134: Aug 6 16:17:43.507 PST:
TenGigabitEthernet2/7/4, changed
000135: Aug 6 16:17:43.563 PST:
changed state to down
000136: Aug 6 16:17:44.919 PST:
changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface
state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface
state to down
%LINK-3-UPDOWN: Interface TenGigabitEthernet2/7/4,
%LINK-3-UPDOWN: Interface TenGigabitEthernet1/2/4,
(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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-62
Chapter 4
Virtual Switching Systems
How to Upgrade 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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
=
=
=
=
=
=
=
=
=
1/2
Active
Load Version
disk0:s72033-oldversion.v1,12
sso
disk0:s72033-oldversion.v1
disk0:s72033-newversion.v2
disk0:s72033-oldversion.v1
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
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
1
18
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]
(Deleted many lines)
Download Start
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-63
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(Deleted many lines)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Download Completed! Booting the image.
Self decompressing the image :
##########################################################################################
(Deleted many lines)
################################################################################ [OK]
running startup....
(Deleted many lines)
000147: Aug
succeeded
6 16:53:43.199 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync
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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
1/2
Standby
Run Version
disk0:s72033-oldversion.v1,12
sso
disk0:s72033-newversion.v2
disk0:s72033-oldversion.v1
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
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
1
18
0x0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-64
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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:
TenGigabitEthernet2/7/4, changed
000149: Aug 6 17:17:28.287 PST:
TenGigabitEthernet1/2/4, changed
%LINEPROTO-5-UPDOWN: Line protocol on Interface
state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface
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
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:s72033-newversion.v2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-65
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
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
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
Tip
=
=
=
=
=
30000 milliseconds
9000 milliseconds
1
18
0x0
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
Participate in the Technical Documentation Ideas forum
eFSU Upgrade Example when IA (Instant Access) Client Switches are present
This example shows how to perform and verify an eFSU upgrade for a VSS when IA (Instant Access)
client switches are present.
This example upgrade procedure was performed for Cisco IOS Software Release 15.1(2)SY to Release
15.1(2)SY1. In the sections FEX refers to Fabric Extender which is an alternate term for an Instant
Access switch.
Verify the System Readiness
The Catalyst 6500 chassis with Switch ID 1 is Active and the Switch with ID 2 is Standby (Hot). Both
of the chassis are up on Cisco IOS Software Release 15.1(2)SY. A single 6800IA that runs Cisco IOS
software Release 15.0(2)EX2 is connected to VSS on WS-X6904-40G linecards with a dual-home
connection. The FEX port-channel number is 99 and the FEX ID is 110. Make sure that the new Cisco
IOS image (Cisco IOS software Release 15.1(2)SY1) is present in the bootdisk and the slavebootdisk.
Router# show mod sw all
Switch Number:
1
Role:
Virtual Switch Active
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------2
5 Supervisor Engine 2T 10GE w/ CTS (Acti VS-SUP2T-10G
SAL1632K9P2
3
20 DCEF2T 4 port 40GE / 16 port 10GE
WS-X6904-40G
SAL1741E4ZA
Mod MAC addresses
Hw
Fw
Sw
Status
--- ---------------------------------- ------ ------------ ------------ ------2 c471.fe7c.de96 to c471.fe7c.de9d
1.3
12.2(50r)SYS 15.1(2)SY
Ok
3 e02f.6d6a.698c to e02f.6d6a.699f
1.0
12.2(50r)SYL 15.1(2)SY
Ok
Mod Sub-Module
Model
Serial
Hw
Status
---- --------------------------- ------------------ ----------- ------- -------
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-66
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
2
2
3
Policy Feature Card 4
VS-F6K-PFC4
CPU Daughterboard
VS-F6K-MSFC5
Distributed Forwarding Card WS-F6K-DFC4-E
SAL1637MCQQ
SAL1637MKX8
SAL1745FSD6
1.2
1.4
1.0
Ok
Ok
Ok
Mod Online Diag Status
---- ------------------2 Pass
3 Pass
Switch Number:
2
Role: Virtual Switch Standby
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------2
5 Supervisor Engine 2T 10GE w/ CTS (Hot) VS-SUP2T-10G
SAL1650UC8L
3
20 DCEF2T 4 port 40GE / 16 port 10GE
WS-X6904-40G
SAL17173QD3
Mod
--2
3
MAC addresses
Hw
Fw
Sw
Status
---------------------------------- ------ ------------ ------------ ------2c54.2dc4.2f3a to 2c54.2dc4.2f41
1.4
12.2(50r)SYS 15.1(2)SY
Ok
70ca.9b8f.510c to 70ca.9b8f.511f
1.0
12.2(50r)SYL 15.1(2)SY
Ok
Mod Sub-Module
Model
Serial
---- --------------------------- ------------------ ----------2 Policy Feature Card 4
VS-F6K-PFC4
SAL1651UG8P
2 CPU Daughterboard
VS-F6K-MSFC5
SAL1651UEBY
3 Distributed Forwarding Card WS-F6K-DFC4-E
SAL17173QHY
Hw
Status
------- ------1.2
Ok
1.5
Ok
1.2
Ok
Mod Online Diag Status
---- ------------------2 Pass
3 Pass
Switch Number:
110
Role:
FEX
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------1
48 C6800IA 48GE
C6800IA-48TD
FOC1736W1A6
Mod MAC addresses
Hw
Fw
Sw
Status
--- ---------------------------------- ------ ------------ ------------ ------1 c025.5cc2.2d00 to c025.5cc2.2d33
0.0
Unknown
15.0(2)EX2
Ok
Mod Online Diag Status
---- ------------------1 Pass
Router# show switch virtual
Switch mode
:
Virtual switch domain number :
Local switch number
:
Local switch operational role:
Peer switch number
:
Peer switch operational role :
Virtual Switch
100
1
Virtual Switch Active
2
Virtual Switch Standby
Router# dir bootdisk: | in s2t54
5 -rw120035816 Jan 23 2014 22:35:12 +00:00
s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
8 -rw119792104 Feb 10 2014 19:42:12 +00:00
s2t54-adventerprisek9-mz.SPA.151-2.SY.bin
dir slavebootdisk: | in s2t54
Router#
5
-rw-
120035816
Jan 23 2014 22:26:14 +00:00
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-67
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
8 -rw119792104 Feb 10 2014 19:46:14 +00:00
s2t54-adventerprisek9-mz.SPA.151-2.SY.bin
Router# show issu state detail
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Summary: the system will be upgraded in in-tandem mode.
Slot = 1/2
RP State = Active
ISSU State = Init
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12;
Operating Mode = sso
ISSU Sub-State = No Upgrade Operation in Progress
Starting Image = N/A
Target Image = N/A
Current Version =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin
Slot = 2/2
RP State = Standby
ISSU State = Init
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12;
Operating Mode = sso
ISSU Sub-State = No Upgrade Operation in Progress
Starting Image = N/A
Target Image = N/A
Current Version =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin
This system is Fex-capable
Fex-ID
110
ISSU Status
FEX_INIT
Router# show redundancy
Redundant System Information :
-----------------------------Available system uptime
Switchovers system experienced
Standby failures
Last switchover reason
Hardware Mode = Duplex
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
36 minutes
0
0
none
=
=
=
=
sso
sso
Disabled
Up
Current Processor Information :
------------------------------Active Location =
Current Software state =
Uptime in current state =
Image Version =
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-68
slot 1/2
ACTIVE
36 minutes
Cisco IOS Software, s2t54 Software
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
(s2t54-ADVENTERPRISEK9-M),
Version 15.1(2)SY, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Wed 04-Sep-13 12:37 by prod_rel_team
BOOT =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12;
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2102
Peer Processor Information :
---------------------------Standby Location
Current Software state
Uptime in current state
Image Version
=
=
=
=
slot 2/2
STANDBY HOT
34 minutes
Cisco IOS Software, s2t54 Software
(s2t54-ADVENTERPRISEK9-M),
Version 15.1(2)SY, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Wed 04-Sep-13 12:37 by prod_rel_team
BOOT =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12;
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2102
Load the New Image to the VSS Standby Chassis
Use the issu loadversion command in order 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. It might take several seconds to a few
minutes for the new image to load and for the VSS standby chassis to transition to SSO mode.
Router# issu loadversion 1/2 bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin 2/2
slavebootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
System configuration has been modified. Save? [yes/no]: yes
Building configuration...
[OK]
%issu loadversion initiated successfully, upgrade sequence will begin shortly
*Feb 11 05:24:40.091: %ISSU_PROCESS-SW1-3-LOADVERSION: Loadversion sequence
will begin in 60 seconds. Enter 'issu abortversion' to cancel.
*Feb 11 05:25:10.091: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Resetting Standby shortly
<..output truncated..>
*Feb 11 05:29:46.075: %VS_GENERIC-SW1-6-VS_HA_HOT_STANDBY_NOTIFY: Standby switch
is in Hot Standby mode
*Feb 11 05:29:46.079: %HA_CONFIG_SYNC-SW1-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded
*Feb 11 05:29:46.079: %RF-SW1-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
*Feb 11 05:30:25.091: %ISSU_PROCESS-SW1-3-LOADVERSION: Loadversion has completed.
Please issue the 'issu runversion' command after all modules come online.
!
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-69
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
! Boot variable for standby should point to new Image in ?show issu state detail?
output.
Router# show issu state det
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Summary: an in-tandem upgrade is in progress.
Slot = 1/2
RP State = Active
ISSU State = Load Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin,12;
Operating Mode = sso
ISSU Sub-State = Load Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Slot = 2/2
RP State = Standby
ISSU State = Load Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
Operating Mode = sso
ISSU Sub-State = Load Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
This system is Fex-capable
Fex-ID
110
ISSU Status
FEX_UPGRADE_INIT
Router# show redundancy states
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
Manual Swact = enabled
Communications = Up
client count = 144
client_notification_TMR
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
1
19
0x0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-70
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
Execute a Switchover to the New Image
When the VSS standby chassis successfully runs the new image in the SSO redundancy state and all the
Line Cards on the VSS standby chassis are up and online, enter the issu runversion command in order
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]
%issu runversion initiated successfully
*Feb 11 05:35:19.035: %RF-SW1-5-RF_RELOAD: Self reload. Reason: Admin ISSU runversion
CLI
<..output truncated..>
Feb 11 05:35:21.411: %SYS-SW1-5-SWITCHOVER: Switchover requested by Exec.
Reload Reason: Admin ISSU runversion CLI.
Resetting .......
!
!Standby chassis now becomes active. Below logs are from new active switch.
!
Initializing as Virtual Switch ACTIVE processor
.
.
*Feb 11 05:37:36.107: %PFREDUN-SW2-6-ACTIVE: Standby initializing for SSO mode
*Feb 11 05:39:56.563: %HA_CONFIG_SYNC-SW2-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded
*Feb 11 05:39:56.563: %RF-SW2-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
*Feb 11 05:39:56.555: %PFREDUN-SW1_STBY-6-STANDBY: Ready for SSO mode in Default Domain
! Wait till all the modules and Fex Port-channel 99 links come up
!
*Feb 11 05:41:28.467: %ISSU_PROCESS-SW2-6-RUNVERSION_INFO: Runversion has completed.
Please issue the 'issu acceptversion' command
Feb 11 05:43:13.034: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed
state to up (FEX-110)
Feb 11 05:43:14.033: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet1/0/2, changed state to up (FEX-110)
*Feb 11 05:43:14.491: %SATMGR-SW2-5-FABRIC_PORT_UP: SDP up on interface
Te1/3/5,connected to FEX 110, uplink 52
*Feb 11 05:43:14.491: %SATMGR-SW2-5-DUAL_ACTIVE_DETECT_CAPABLE: channel group 99 is now
dual-active detection capable
Router# show issu state
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Summary: an in-tandem upgrade is in progress.
Slot = 2/2
RP State = Active
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-71
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
ISSU State = Run Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
Slot = 1/2
RP State = Standby
ISSU State = Run Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin,12;
This system is Fex-capable
Fex-ID
110
ISSU Status
FEX_UPGRADE_INIT
Router# show fex 110 detail
FEX: 110
Description: FEX0110
state: online
FEX version: 15.0(2)EX2
Extender Model: C6800IA-48TD, Extender Serial: FOC1736W1A6
FCP ready: yes
Image Version Check: enforced
Fabric Portchannel Ports: 2
Fabric port for control traffic: Te2/3/5
Fabric interface state:
Po99
- Interface Up.
Te1/3/5
- Interface Up.
state: bound
Te2/3/5
- Interface Up.
state: bound
Accept the New Image to Stop the Rollback Timer
Use the issu acceptversion command in order to stop the Rollback Timer. This is necessary because if
the timer expires, the upgraded chassis reloads and reverts to the previous software version.
Router# issu acceptversion
% Rollback timer stopped. Please issue the 'issu commitversion' command..
Upgrade the IA Client Switches
Use the issu runversion fex all command in order to start the image download and upgrade procedure
on the FEX (6800IA). The FEX triggers the image download from the new software bundle of the
Supervisor (here Cisco IOS software Release 15.1(2)SY1). If you use FEX stacks, the master is
responsible to extract the image to its members. A TFTP server runs at 192.1.1.1.
Router# issu runversion fex all
% Successfully initiated 'runversion fex' for Fex IDs: 110.
Use 'show issu state' for more information.
Router# show issu state det
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-72
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
Summary: an in-tandem upgrade is in progress.
Slot = 2/2
RP State = Active
ISSU State = Run Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;bootdisk:s2t54-adventerprisek9-mz.S
PA.151-2.SY.bin,12
Operating Mode = sso
ISSU Sub-State = Run Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Slot = 1/2
RP State = Standby
ISSU State = Run Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin,12;
Operating Mode = sso
ISSU Sub-State = Run Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
This system is Fex-capable
Fex-ID ISSU Status
110 FEX_UPGRADE_IN_PROGRESS
Following are the logs on from FEX 6800IA console:
Router# attach fex-id 110
Attach FEX:102 ip:192.1.1.102
Trying 192.1.1.102 ... Open
User Access Verificatio
Password: cisco
FEX-110>en
Password: cisco
FEX-110#
!
!192.1.1.1 is the tftp running on FEX controller i.e. VSS active and vlan 1012 is the
control vlan associated with fex.
!
FEX-110#
Loading c6800ia-universalk9-mz.150-2.EX4.bin from 192.1.1.1
(via Vlan1012):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 15493122 bytes]
examining image...
extracting info (112 bytes)
extracting c6800ia-universalk9-mz.150-2.EX4/info (792 bytes)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-73
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
extracting info (112 bytes)
Stacking Version Number: 1.55
System Type:
Ios Image File Size:
Total Image File Size:
Minimum Dram required:
Image Suffix:
Image Directory:
Image Name:
Image Feature:
FRU Module Version:
0x00000000
0x00EB5200
0x00EC6A00
0x08000000
universalk9-150-2.EX4
c6800ia-universalk9-mz.150-2.EX4
c6800ia-universalk9-mz.150-2.EX4.bin
IP|LAYER_2|SSH|3DES|MIN_DRAM_MEG=128
No FRU Version Specified
Old image for switch 1: flash:/c6800ia-universalk9-mz.150-2.EX2 Old image will be left
alone
Extracting images from archive into flash...
! The console will be waiting for about 5-10 minutes after the above line.
<output truncated>
New software image installed in flash:/c6800ia-universalk9-mz.150-2.EX4
Following are the logs from the VSS Active supervisor:
*Feb 11 06:00:30.387: %SATMGR-SW2-5-ONLINE: FEX 110 online
*Feb 11 06:00:30.391: %SATMGR-SW2-5-FEX_MODULE_ONLINE: FEX 110, module 1 online
*Feb 11 06:00:30.395: %OIR-SW2-6-INSREM: Switch 110 Physical Slot 1 - Module Type
LINE_CARD inserted
*Feb 11 06:00:30.951: %SATMGR-SW2-5-FABRIC_PORT_UP: SDP up on interface Te2/3/5,
connected to FEX 110, uplink 51
*Feb 11 06:00:30.951: %SATMGR-SW2-5-DUAL_ACTIVE_DETECT_CAPABLE: channel group 99 is now
dual-active detection capable
*Feb 11 06:01:00.983: %OIR-SW2-6-SP_INSCARD: Card inserted in Switch_number = 110,
physical slot 1, interfaces are now online
FEX-110#show ver | in image
System image file is "flash:/c6800ia-universalk9-mz.150-2.EX4/
c6800ia-universalk9-mz.150-2.EX4.bin"
Router# show issu state det
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Summary: an in-tandem upgrade is in progress.
Slot = 2/2
RP State = Active
ISSU State = Run Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
Operating Mode = sso
ISSU Sub-State = Run Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Slot = 1/2
RP State = Standby
ISSU State = Run Version
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-74
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin,12;
Operating Mode = sso
ISSU Sub-State = Run Version Completed
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
This system is Fex-capable
Fex-ID
110
ISSU Status
FEX_UPGRADE_COMPLETE
Commit the New Image to the VSS Standby Chassis
In order to continue, enter the issu commitversion command to upgrade the VSS standby chassis and
complete the ISSU 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 and all the LC on the new VSS-Standby are up and online. Once complete, the 6500 chassis
with Switch ID 2 is Active and the Switch with ID 1 is Standby (Hot). They are now on Cisco IOS
Software Version 15.1(2)SY1. The Instant Access client (6800IA) now runs Cisco IOS software Release
15.0(2)EX4.
Router# issu commitversion
%issu commitversion initiated successfully, upgrade sequence will continue shortly
*Feb 11 06:05:30.839: %ISSU_PROCESS-SW2-3-COMMITVERSION: issu commitversion;
Commitversion sequence will begin in 60 seconds. Enter 'issu abortversion'
to cancel.
*Feb 11 06:06:00.839: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Resetting Standby shortly
*Feb 11 06:08:48.571: %PFREDUN-SW2-6-ACTIVE: Standby initializing for SSO mode
*Feb 11 06:09:01.163: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Standby has come online,
wait for terminal state
.
.
*Feb 11 06:10:41.267: %VS_GENERIC-SW2-6-VS_HA_HOT_STANDBY_NOTIFY: Standby switch is in
Hot Standby mode
*Feb 11 06:10:41.271: %HA_CONFIG_SYNC-SW2-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded
*Feb 11 06:10:41.271: %RF-SW2-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
*Feb 11 06:10:46.403: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Upgrade has completed,
updating boot configuration
!
!Boot variable now displays both new and old image in ?show issu state detail? output.
!
Router# show issu state detail
The system is configured to be upgraded in staggered mode.
2 supervisor nodes are found to be online.
Summary: an in-tandem upgrade is in progress.
Slot = 2/2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-75
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
RP State = Active
ISSU State = Commit Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
Operating Mode = sso
ISSU Sub-State = Commit Version completed, waiting for system to
settle
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Slot = 1/2
RP State = Standby
ISSU State = Commit Version
Boot Variable =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
Operating Mode = sso
ISSU Sub-State = Commit Version completed, waiting for system to
settle
Starting Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY..bin
Target Image = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin
This system is Fex-capable
Fex-ID
110
ISSU Status
FEX_UPGRADE_COMPLETE
Router# show redundancy
Redundant System Information :
-----------------------------Available system uptime
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
1 hour, 28 minutes
1
1
user forced
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
sso
sso
Disabled
Up
Current Processor Information :
------------------------------Active Location = slot 2/2
Current Software state = ACTIVE
Uptime in current state = 36 minutes
Image Version = Cisco IOS Software, s2t54 Software
(s2t54-ADVENTERPRISEK9-M), Version 15.1(2)SY1, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Thu 28-Nov-13 12:58 by prod_rel_team
BOOT =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
CONFIG_FILE =
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-76
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
BOOTLDR =
Configuration register = 0x2102
Peer Processor Information :
---------------------------Standby Location = slot 1/2
Current Software state = STANDBY HOT
Uptime in current state = 1 minute
Image Version = Cisco IOS Software, s2t54 Software
(s2t54-ADVENTERPRISEK9-M),
Version 15.1(2)SY1, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Thu 28-Nov-13 12:58 by prod_rel_team
BOOT =
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY1.bin,12;
bootdisk:s2t54-adventerprisek9-mz.SPA.151-2.SY.bin,12
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2102
Router# show mod swi all
Switch Number:
1
Role: Virtual Switch Standby
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------2
5 Supervisor Engine 2T 10GE w/ CTS (Hot) VS-SUP2T-10G
SAL1632K9P2
3
20 DCEF2T 4 port 40GE / 16 port 10GE
WS-X6904-40G
SAL1741E4ZA
Mod
--2
3
MAC addresses
Hw
Fw
Sw
Status
---------------------------------- ------ ------------ ------------ ------c471.fe7c.de96 to c471.fe7c.de9d
1.3
12.2(50r)SYS 15.1(2)SY1
Ok
e02f.6d6a.698c to e02f.6d6a.699f
1.0
12.2(50r)SYL 15.1(2)SY1
Ok
Mod Sub-Module
Model
Serial
---- --------------------------- ------------------ ----------2 Policy Feature Card 4
VS-F6K-PFC4
SAL1637MCQQ
2 CPU Daughterboard
VS-F6K-MSFC5
SAL1637MKX8
3 Distributed Forwarding Card WS-F6K-DFC4-E
SAL1745FSD6
Hw
Status
------- ------1.2
Ok
1.4
Ok
1.0
Ok
Mod Online Diag Status
---- ------------------2 Pass
3 Pass
Switch Number:
2
Role:
Virtual Switch Active
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------2
5 Supervisor Engine 2T 10GE w/ CTS (Acti VS-SUP2T-10G
SAL1650UC8L
3
20 DCEF2T 4 port 40GE / 16 port 10GE
WS-X6904-40G
SAL17173QD3
Mod
--2
3
MAC addresses
Hw
Fw
Sw
Status
---------------------------------- ------ ------------ ------------ ------2c54.2dc4.2f3a to 2c54.2dc4.2f41
1.4
12.2(50r)SYS 15.1(2)SY1
Ok
70ca.9b8f.510c to 70ca.9b8f.511f
1.0
12.2(50r)SYL 15.1(2)SY1
Ok
Mod Sub-Module
Model
Serial
---- --------------------------- ------------------ ----------2 Policy Feature Card 4
VS-F6K-PFC4
SAL1651UG8P
2 CPU Daughterboard
VS-F6K-MSFC5
SAL1651UEBY
3 Distributed Forwarding Card WS-F6K-DFC4-E
SAL17173QHY
Hw
Status
------- ------1.2
Ok
1.5
Ok
1.2
Ok
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-77
Chapter 4
Virtual Switching Systems
How to Upgrade a VSS
Mod Online Diag Status
---- ------------------2 Pass
3 Pass
Switch Number:
110
Role:
FEX
---------------------- ----------------------------Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------1
48 C6800IA 48GE
C6800IA-48TD
FOC1736W1A6
Mod MAC addresses
Hw
Fw
Sw
Status
--- ---------------------------------- ------ ------------ ------------ ------1 c025.5cc2.2d00 to c025.5cc2.2d33
0.0
Unknown
15.0(2)EX4
Ok
Mod Online Diag Status
---- ------------------1 Pass
Router# show switch virtual
Switch mode
:
Virtual switch domain number :
Local switch number
:
Local switch operational role:
Peer switch number
:
Peer switch operational role :
Virtual Switch
100
2
Virtual Switch Active
1
Virtual Switch Standby
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-78
PART
2
High Availability
CH AP TE R
5
Enhanced Fast Software Upgrade
Note
•
Prerequisites for eFSU, page 5-1
•
Restrictions for eFSU, page 5-2
•
Information About eFSU, page 5-3
•
Default Settings for eFSU, page 5-5
•
How to Perform an eFSU, page 5-5
•
How to Upgrade a Non-eFSU Image to an eFSU Image, page 5-14
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for eFSU
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-1
Chapter 5
Enhanced Fast Software Upgrade
Restrictions for eFSU
Restrictions for eFSU
•
SX SY EFSU Compatibility Matrix
•
The Release 15.0(1)SY no payload encryption (NPE) images do not support the hitless ACL update
feature or the [no] platform hardware acl update-mode hitless command.
The Release 15.0(1)SY1 and later no payload encryption (NPE) images support hitless ACL update
and the platform hardware acl update-mode hitless command is configured by default (because
it is the default, the command does not appear in the configuration file).
In other releases and images that support the hitless ACL update feature, the platform hardware
acl update-mode hitless command is configured by default.
With NPE images, to avoid problems when doing a downgrade from Release 15.0(1)SY1 or later to
Release 15.0(1)SY, do not disable the hitless ACL update feature (no platform hardware acl
update-mode hitless), because the CLI does not exist in the Release 15.0(1)SY NPE images, and
configuring the nondefault condition causes the CLI to appear in the Release 15.0(1)SY1
configuration file, which then, as an unsupported command, causes problems with
Release 15.0(1)SY.
The hitless ACL update feature consumes TCAM resources. If TCAM utilization is high, enabling
the hitless ACL update feature to support a downgrade might cause TCAM conflicts with other
configured features.
•
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-4 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.
•
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-2
Chapter 5
Enhanced Fast Software Upgrade
Information About eFSU
Note
•
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).
•
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. During this
process, the module software image is also upgraded on those modules that support eFSU.
For ISSU downgrade of any Quad-sup supported image to Quad-sup not supported image, the customer
should disable the ICS and continue with the ISSU downgrade.
Information About eFSU
Note
•
eFSU Operation, page 5-3
•
Outage Time and Support Considerations, page 5-4
•
Reserving Module Memory, page 5-4
•
Error Handling for eFSU Preload, page 5-5
The switch supports eFSU in VSS mode. See the “Restrictions for VSS” section on page 4-2 for more
information.
eFSU Operation
eFSU is an enhanced software upgrade procedure. 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-3
Chapter 5
Enhanced Fast Software Upgrade
Information About eFSU
The WS-X67xx modules modules support eFSU preload. 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.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-4
Chapter 5
Enhanced Fast Software Upgrade
Default Settings for eFSU
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.
Error Handling for eFSU Preload
If problems occur during eFSU preload, the switch takes the following actions:
•
Module crash during loadversion—The module is reset when a switchover occurs.
•
Module not active when eFSU started—No 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 rollback—The module boots with the software image
version that corresponds to the software image that is present on the active supervisor engine.
Default Settings for eFSU
None.
How to Perform an eFSU
•
eFSU Summarized Procedure, page 5-6
•
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-12
•
Committing the New Software to the Standby, page 5-12
•
Verifying the Software Installation, page 5-12
•
Aborting the Upgrade Process, page 5-13
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-5
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
eFSU Summarized Procedure
This task is a summarized procedure for an eFSU:
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.
Step 3
Router# show version | in image
Router# show bootvar
These show commands verify that the switch is ready to run
eFSU. The show version and show bootvar commands
verify the boot image settings.
Router# show redundancy
Router# show issu state [detail]
The show redundancy and show issu state commands
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
active-image standby-slot standby-image
Starts the upgrade process and loads the new software
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
Router# show issu state [detail]
Verifies the status of the upgrade process. If the upgrade
was successful, both the active and standby supervisor
engines are running the new software version.
Preparing for the Upgrade
•
Verifying the Boot Image Version and Boot Variable, page 5-7
•
Verifying Redundancy Mode, page 5-7
•
Verifying eFSU State, page 5-8
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-6
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
Note
Before attempting to perform a software upgrade, be sure to review the “Restrictions for eFSU” section
on page 5-2.
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 =
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
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
45 minutes
0
0
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
sso
sso
Disabled
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-7
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
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
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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
ROMMON CV
=
=
=
=
=
=
=
=
=
=
6
Active
Load Version
disk0:image_name
sso
disk0:sierra.0217
disk0:sierra.0217
disk0:sierra.0217
PrstVbl
[disk0:image_name]
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
5
Standby
Load Version
disk0:image_name
sso
disk0:image_name
disk0:image_name
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-8
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
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.
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
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
1 hour, 0 minutes
0
1
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
sso
sso
Disabled
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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
ROMMON CV
=
=
=
=
=
=
=
=
=
=
6
Active
Load Version
disk0:image_name
sso
disk0:image_name
disk0:image_name
disk0:image_name
PrstVbl
[disk0:image_name]
Slot = 5
RP State = Standby
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-9
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
Load Version
disk0:image_name
sso
disk0:image_name
disk0:image_name
disk0:image_name
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
------ ------------------------------------------1 CEF720 8 port 10GE with DFC
2 96-port 10/100 Mbps RJ45
4 CEF720 48 port 1000mb SFP
MDR Mode
Max Outage Time
----------- --------------WARM_RELOAD
300 secs
RELOAD
360 secs
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
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
1 hour, 9 minutes
1
0
user forced
Hardware Mode = Duplex
Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-10
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
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
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
Note
Router# show issu state detail
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
ROMMON CV
=
=
=
=
=
=
=
=
=
=
5
Active
Run Version
disk0:image_name
sso
disk0:image_name
disk0:image_name
disk0:image_name
PrstVbl
[disk0:image_name]
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
6
Standby
Run Version
disk0:image_name
sso
disk0:image_name
disk0:image_name
disk0:image_name
To complete the upgrade process, enter the issu acceptversion (optional) and issu commitversion
commands (as described in the following sections).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-11
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
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.
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-12
Chapter 5
Enhanced Fast Software Upgrade
How to Perform an eFSU
Last switchover reason = user forced
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
sso
sso
Disabled
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
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
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
Variable Store
ROMMON CV
=
=
=
=
=
=
=
=
=
=
5
Active
Init
disk0:image_name
sso
N/A
N/A
disk0:image_name
PrstVbl
[disk0:simage_name ]
Slot
RP State
ISSU State
Boot Variable
Operating Mode
Primary Version
Secondary Version
Current Version
=
=
=
=
=
=
=
=
6
Standby
Init
disk0:image_name
sso
N/A
N/A
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-13
Chapter 5
Enhanced Fast Software Upgrade
How to Upgrade a Non-eFSU Image to an eFSU Image
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]).
How to Upgrade 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 “eFSU Summarized Procedure” section on page 5-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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-14
CH AP TE R
6
Fast Software Upgrade
Note
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
Supported only with redundant supervisor engines. Cisco IOS software is upgraded on the standby
RP, and a manual switchover is performed. The new Cisco IOS image can then be upgraded on the
other RP.
•
During the upgrade process, different images will be loaded on the RPs for a very short period of
time. If a switchover occurs during this time, the device will recover in RPR mode.
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
Participate in the Technical Documentation Ideas forum
To upgrade or downgrade the Cisco IOS image, perform this task:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# copy {ftp: | http:// | https:// | rcp: |
scp: | tftp:} device:filename
Copies a Cisco IOS image onto the flash device of the
active RP.
Step 3
Router# copy {ftp: | http:// | https:// | rcp: |
scp: | tftp:} slavedevice:filename
Copies a Cisco IOS image onto the flash device of the
standby RP.
Step 4
Router# configure terminal
Enters global configuration mode.
Step 5
Router(config)# no boot system flash
[flash-fs:][partition-number:][filename]
(Optional) Clears any existing system flash boot image
specification.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-1
Chapter 6
Fast Software Upgrade
Command
Purpose
Step 6
Router(config)# boot system flash
[flash-fs:][partition-number:][filename]
Specifies the filename of stored image in flash memory.
Step 7
Router(config)# config-register 0x2102
Sets the configuration register setting to the default value.
Step 8
Router(config)# exit
Exits global configuration mode and returns the router to
privileged EXEC mode.
Step 9
Router# copy running-config startup-config
Saves the configuration changes to the startup
configuration file.
Step 10
hw-module {module standby_slot} reset
Resets and reloads the standby processor with the
specified Cisco IOS image, and executes the image.
Step 11
redundancy force-switchover
Forces a switchover to the standby RP.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-2
CH AP TE R
7
Stateful Switchover (SSO)
Note
Tip
•
Prerequisites for SSO, page 7-1
•
Restrictions for SSO, page 7-2
•
Information About SSO, page 7-3
•
Default Settings for SSO, page 7-10
•
How to Configure SSO, page 7-10
•
Troubleshooting SSO, page 7-11
•
Verifying the SSO Configuration, page 7-12
•
Configuration Examples for SSO, page 7-16
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
SSO and NSF do not support IPv6 multicast traffic.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for SSO
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-1
Chapter 7
Stateful Switchover (SSO)
Restrictions for SSO
Restrictions for SSO
•
General Restrictions, page 7-2
•
Configuration Mode Restrictions, page 7-2
•
Switchover Process Restrictions, page 7-2
General Restrictions
•
Two RPs must be installed in the chassis, each running the same version of the Cisco IOS software.
•
Both RPs must run the same Cisco IOS image. If the RPs are operating different Cisco IOS images,
the system reverts to RPR mode even if SSO is configured.
•
Configuration changes made through SNMP may not be automatically configured on the standby RP
after a switchover occurs.
•
Load sharing between dual processors is not supported.
•
The Hot Standby Routing Protocol (HSRP) is not supported with Cisco Nonstop Forwarding with
Stateful Switchover. Do not use HSRP with Cisco Nonstop Forwarding with Stateful Switchover.
•
Enhanced Object Tracking (EOT) is not stateful switchover-aware and cannot be used with HSRP,
Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP) in SSO
mode.
•
Multicast is not SSO-aware and restarts after switchover; therefore, multicast tables and data
structures are cleared upon switchover.
Configuration Mode Restrictions
•
The configuration registers on both RPs must be set the same for the networking device to behave
the same when either RP is rebooted.
•
During the startup (bulk) synchronization, configuration changes are not allowed. Before making
any configuration changes, wait for a message similar to the following:
%HA-5-MODE:Operating mode is sso, configured mode is sso.
Switchover Process Restrictions
•
If any changes to the fabric configuration happen simultaneously with an RP switchover, the chassis
is reset and all line cards are reset.
•
If the switch is configured for SSO mode, and the active RP fails before the standby is ready to
switch over, the switch will recover through a full system reset.
•
During SSO synchronization between the active and standby RPs, the configured mode will be RPR.
After the synchronization is complete, the operating mode will be SSO. If a switchover occurs
before the synchronization is complete, the switchover will be in RPR mode.
•
If a switchover occurs before the bulk synchronization step is complete, the new active RP may be
in inconsistent states. The switch will be reloaded in this case.
•
Switchovers in SSO mode will not cause the reset of any line cards.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-2
Chapter 7
Stateful Switchover (SSO)
Information About SSO
•
Interfaces on the RP itself are not stateful and will experience a reset across switchovers. In
particular, the GE interfaces on the RPs are reset across switchovers and do not support SSO.
•
Any line cards that are not online at the time of a switchover (line cards not in Cisco IOS running
state) are reset and reloaded on a switchover.
Information About SSO
•
SSO Overview, page 7-3
•
SSO Operation, page 7-5
•
Route Processor Synchronization, page 7-6
•
SSO Operation, page 7-8
•
SSO-Aware Features, page 7-10
SSO Overview
The switch is supports fault resistance by allowing a redundant supervisor engine to take over if the
primary supervisor engine fails. Cisco SSO (frequently used with NSF) minimizes the time a network is
unavailable to its users following a switchover while continuing to forward IP packets. The switch is
supports route processor redundancy (RPR). For more information, see Chapter 9,
“Route Processor Redundancy (RPR).”
SSO is particularly useful at the network edge. Traditionally, core routers protect against network faults
using router redundancy and mesh connections that allow traffic to bypass failed network elements. SSO
provides protection for network edge devices with dual Route Processors (RPs) that represent a single
point of failure in the network design, and where an outage might result in loss of service for customers.
SSO has many benefits. Because the SSO feature maintains stateful feature information, user session
information is maintained during a switchover, and line cards continue to forward network traffic with
no loss of sessions, providing improved network availability. SSO provides a faster switchover than RPR
by fully initializing and fully configuring the standby RP, and by synchronizing state information, which
can reduce the time required for routing protocols to converge. Network stability may be improved with
the reduction in the number of route flaps had been created when routers in the network failed and lost
their routing tables.
SSO is required by the Cisco Nonstop Forwarding (NSF) feature (see Chapter 8, “Nonstop Forwarding
(NSF)”).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-3
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Figure 7-1 illustrates how SSO is typically deployed in service provider networks. In this example, Cisco
NSF with SSO is primarily at the access layer (edge) of the service provider network. A fault at this point
could result in loss of service for enterprise customers requiring access to the service provider network.
For Cisco NSF protocols that require neighboring devices to participate in Cisco NSF, Cisco NSF-aware
software images must be installed on those neighboring distribution layer devices. Additional network
availability benefits might be achieved by applying Cisco NSF and SSO features at the core layer of your
network; however, consult your network design engineers to evaluate your specific site requirements.
Figure 7-1
Cisco NSF with SSO Network Deployment: Service Provider Networks
Service
provider
core
layer
Cisco NSF with SSO
features may provide
some benefit, but usually
not required
Service provider
distribution
layer
Good position for
NSF-aware
routers
Service
provider
access layer
Primary deployment
position for Cisco NSF
with SSO capable-routers
72134
Customers
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-4
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Additional levels of availability may be gained by deploying Cisco NSF with SSO at other points in the
network where a single point of failure exists. Figure 7-2 illustrates an optional deployment strategy that
applies Cisco NSF with SSO at the enterprise network access layer. In this example, each access point
in the enterprise network represents another single point of failure in the network design. In the event of
a switchover or a planned software upgrade, enterprise customer sessions would continue uninterrupted
through the network.
Cisco NSF with SSO Network Deployment: Enterprise Networks
Service
provider
core
layer
Cisco NSF with SSO
features may provide
some benefit, but usually
not required
Service provider
distribution
layer
Good position for
NSF-aware
routers
Service
provider
access layer
Primary deployment
position for Cisco NSF
with SSO-capable routers
Enterprise
access
layer
Secondary deployment
position for Cisco NSF
with SSO-capable
or -aware routers
Enterprise
distribution
layer
Good position for
NSF-aware
routers
Enterprise
core
layer
SSO may provide
some benefit
72064
Figure 7-2
SSO Operation
SSO establishes one of the RPs as the active processor while the other RP is designated as the standby
processor. SSO fully initializes the standby RP, and then synchronizes critical state information between
the active and standby RP.
During an SSO switchover, the line cards are not reset, which provides faster switchover between the
processors. The following events cause a switchover:
•
A hardware failure on the active supervisor engine
•
Clock synchronization failure between supervisor engines
•
A manual switchover or shutdown
An SSO switchover does not interrupt Layer 2 traffic. An SSO switchover preserves FIB and adjacency
entries and can forward Layer 3 traffic after a switchover. SSO switchover duration is between 0 and 3
seconds.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-5
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Route Processor Synchronization
•
Synchronization Overview, page 7-6
•
Bulk Synchronization During Initialization, page 7-6
•
Synchronization of Startup Configuration, page 7-6
•
Incremental Synchronization, page 7-7
Synchronization Overview
In networking devices running SSO, both RPs must be running the same configuration so that the
standby RP is always ready to assume control if the active RP fails. SSO synchronizes the configuration
information from the active RP to the standby RP at startup and whenever changes to the active RP
configuration occur. This synchronization occurs in two separate phases:
•
While the standby RP is booting, the configuration information is synchronized in bulk from the
active RP to the standby RP.
•
When configuration or state changes occur, an incremental synchronization is conducted from the
active RP to the standby RP.
Bulk Synchronization During Initialization
When a system with SSO is initialized, the active RP performs a chassis discovery (discovery of the
number and type of line cards and fabric cards, if available, in the system) and parses the startup configuration
file.
The active RP then synchronizes this data to the standby RP and instructs the standby RP to complete
its initialization. This method ensures that both RPs contain the same configuration information.
Even though the standby RP is fully initialized, it interacts only with the active RP to receive incremental
changes to the configuration files as they occur. Executing CLI commands on the standby RP is not
supported.
Synchronization of Startup Configuration
During system startup, the startup configuration file is copied from the active RP to the standby RP. Any
existing startup configuration file on the standby RP is overwritten.
The startup configuration is a text file stored in the NVRAM of the RP. It is synchronized whenever you
perform the following operations:
•
CLI command copy system:running-config nvram:startup-config is used.
•
CLI command copy running-config startup-config is used.
•
CLI command write memory is used.
•
CLI command copy filename nvram:startup-config is used.
•
SNMP SET of MIB variable ccCopyEntry in CISCO_CONFIG_COPY MIB is used.
•
System configuration is saved using the reload command.
•
System configuration is saved following entry of a forced switchover CLI command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-6
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Incremental Synchronization
•
Incremental Synchronization Overview, page 7-7
•
CLI Commands, page 7-7
•
SNMP SET Commands, page 7-7
•
Routing and Forwarding Information, page 7-7
•
Chassis State, page 7-7
•
Line Card State, page 7-7
•
Counters and Statistics, page 7-8
Incremental Synchronization Overview
After both RPs are fully initialized, any further changes to the running configuration or active RP states
are synchronized to the standby RP as they occur. Active RP states are updated as a result of processing
feature information, external events (such as the interface becoming up or down), or user configuration
commands (using CLI commands or Simple Network Management Protocol [SNMP]) or other internal
events.
CLI Commands
CLI changes to the running configuration are synchronized from the active RP to the standby RP. In
effect, the CLI command is run on both the active and the standby RP.
SNMP SET Commands
Configuration changes caused by an SNMP set operation are synchronized on a case-by-case basis.
Currently only two SNMP configuration set operations are supported:
•
shut and no-shut (of an interface)
•
link up/down trap enable/disable
Routing and Forwarding Information
Routing and forwarding information is synchronized to the standby RP:
•
State changes for SSO-aware features (for example, SNMP) are synchronized to the standby RP.
•
Cisco Express Forwarding updates to the Forwarding Information Base (FIB) are synchronized to
the standby RP.
Chassis State
Changes to the chassis state due to line card insertion or removal are synchronized to the standby RP.
Line Card State
Changes to the line card states are synchronized to the standby RP. Line card state information is initially
obtained during bulk synchronization of the standby RP. Following bulk synchronization, line card
events, such as whether the interface is up or down, received at the active processor are synchronized to
the standby RP.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-7
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Counters and Statistics
The various counters and statistics maintained in the active RP are not synchronized because they may
change often and because the degree of synchronization they require is substantial. The volume of
information associated with statistics makes synchronizing them impractical.
Note
Not synchronizing counters and statistics between RPs may create problems for external network
management systems that monitor this information.
SSO Operation
•
SSO Conditions, page 7-8
•
Switchover Time, page 7-8
•
Online Removal of the Active RP, page 7-9
•
Fast Software Upgrade, page 7-9
•
Core Dump Operation, page 7-9
SSO Conditions
An automatic or manual switchover may occur under the following conditions:
•
A fault condition that causes the active RP to crash or reboot—automatic switchover
•
The active RP is declared dead (not responding)—automatic switchover
•
The CLI is invoked—manual switchover
The user can force the switchover from the active RP to the standby RP by using a CLI command. This
manual procedure allows for a “graceful” or controlled shutdown of the active RP and switchover to the
standby RP. This graceful shutdown allows critical cleanup to occur.
Note
Caution
This procedure should not be confused with the graceful shutdown procedure for routing protocols in
core routers—they are separate mechanisms.
The SSO feature introduces a number of new command and command changes, including commands to
manually cause a switchover. The reload command does not cause a switchover. The reload command
causes a full reload of the box, removing all table entries, resetting all line cards, and interrupting
nonstop forwarding.
Switchover Time
The time required by the device to switch over from the active RP to the standby RP is between zero and
three seconds.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-8
Chapter 7
Stateful Switchover (SSO)
Information About SSO
Although the newly active processor takes over almost immediately following a switchover, the time
required for the device to begin operating again in full redundancy (SSO) mode can be several minutes,
depending on the platform. The length of time can be due to a number of factors including the time
needed for the previously active processor to obtain crash information, load code and microcode, and
synchronize configurations between processors.
On DFC-equipped switching modules, forwarding information is distributed, and packets forwarded
from the same line card should have little to no forwarding delay; however, forwarding packets between
line cards requires interaction with the RP, meaning that packet forwarding might have to wait for the
switchover time.
Online Removal of the Active RP
Online removal of the active RP automatically forces a stateful switchover to the standby RP.
Fast Software Upgrade
You can use Fast Software Upgrade (FSU) to reduce planned downtime. With FSU, you can configure
the system to switch over to a standby RP that is preloaded with an upgraded Cisco IOS software image.
FSU reduces outage time during a software upgrade by transferring functions to the standby RP that has
the upgraded Cisco IOS software preinstalled. You can also use FSU to downgrade a system to an older
version of Cisco OS or have a backup system loaded for downgrading to a previous image immediately
after an upgrade.
SSO must be configured on the networking device before performing FSU.
Note
During the upgrade process, different images will be loaded on the RPs for a short period of time. During
this time, the device will operate in RPR mode.
Core Dump Operation
In networking devices that support SSO, the newly active primary processor runs the core dump
operation after the switchover has taken place. Not having to wait for dump operations effectively
decreases the switchover time between processors.
Following the switchover, the newly active RP will wait for a period of time for the core dump to
complete before attempting to reload the formerly active RP. The time period is configurable. For
example, on some platforms an hour or more may be required for the formerly active RP to perform a
coredump, and it might not be site policy to wait that much time before resetting and reloading the
formerly active RP. In the event that the core dump does not complete within the time period provided,
the standby is reset and reloaded regardless of whether it is still performing a core dump.
The core dump process adds the slot number to the core dump file to identify which processor generated
the file content.
Note
Core dumps are generally useful only to your technical support representative. The core dump file, which
is a very large binary file, must be transferred using the TFTP, FTP, or remote copy protocol (rcp) server
and subsequently interpreted by a Cisco Technical Assistance Center (TAC) representative that has
access to source code and detailed memory maps.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-9
Chapter 7
Stateful Switchover (SSO)
Default Settings for SSO
SSO-Aware Features
A feature is SSO-aware if it maintains, either partially or completely, undisturbed operation through an
RP switchover. State information for SSO-aware features is synchronized from active to standby to
achieve stateful switchover for those features.
The dynamically created state of SSO-unaware features is lost on switchover and must be reinitialized
and restarted on switchover.
The output of the show redundancy clients command displays the SSO-aware features (see the
“Verifying SSO Features” section on page 7-13).
Default Settings for SSO
None.
How to Configure SSO
Note
See Chapter 6, “Fast Software Upgrade,” for information about how to copy images onto the switch.
During the upgrade process, different images will be loaded on the RPs for a very short period of time.
If a switchover occurs during this time, the device will recover in RPR mode.
Either the SSO or RPR redundancy mode is always configured. The SSO redundancy mode is configured
by default. To revert to the default SSO redundancy mode from the RPR redundancy mode, perform
this task:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# redundancy
Enters redundancy configuration mode.
Step 4
Router(config)# mode sso
Sets the redundancy configuration mode to SSO on
both the active and standby RP.
Note
After configuring SSO mode, the standby
RP will automatically reset.
Step 5
Router(config-red)# end
Exits redundancy configuration mode and returns
the switch to privileged EXEC mode.
Step 6
Router# copy running-config startup-config
Saves the configuration changes to the startup
configuration file.
This example shows how to configure the SSO redundancy mode:
Router> enable
Router# configure terminal
Router(config)# redundancy
Router(config)# mode sso
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-10
Chapter 7
Stateful Switchover (SSO)
Troubleshooting SSO
Router(config-red)# end
Router# copy running-config startup-config
Router#
Troubleshooting SSO
•
Possible SSO Problem Situations, page 7-11
•
SSO Troubleshooting, page 7-12
Possible SSO Problem Situations
•
The standby RP was reset, but there are no messages describing what happened—To display a log
of SSO events and clues as to why a switchover or other event occurred, enter the show redundancy
history command on the newly active RP:
Router# show redundancy history
•
The show redundancy states command shows an operating mode that is different than what is
configured on the networking device—On certain platforms the output of the show redundancy
states command displays the actual operating redundancy mode running on the device, and not the
configured mode as set by the platform. The operating mode of the system can change depending
on system events. For example, SSO requires that both RPs on the networking device be running the
same software image; if the images are different, the device will not operate in SSO mode, regardless
of its configuration.
For example, during the upgrade process different images will be loaded on the RPs for a short
period of time. If a switchover occurs during this time, the device will recover in RPR mode.
•
Reloading the device disrupts SSO operation—The SSO feature introduces a number of commands,
including commands to manually cause a switchover. The reload command is not an SSO command.
This command causes a full reload of the box, removing all table entries, resetting all line cards, and
thereby interrupting network traffic forwarding. To avoid reloading the box unintentionally, use the
redundancy force-switchover command.
•
During a software upgrade, the networking device appears to be in a mode other than SSO—During
the software upgrade process, the show redundancy command indicates that the device is running in
a mode other than SSO.
This is normal behavior. Until the FSU procedure is complete, each RP will be running a different
software version. While the RPs are running different software versions, the mode will change to
either RPR. The device will change to SSO mode once the upgrade has completed.
•
The previously active processor is being reset and reloaded before the core dump completes—Use
the crashdump-timeout command to set the maximum time that the newly active processor waits
before resetting and reloading the previously active processor.
•
Issuing a “send break” does not cause a system switchover—This is normal operation. Using “send
break” to break or pause the system is not recommended and may cause unpredictable results. To
initiate a manual switchover, use the redundancy force-switchover command.
In Cisco IOS software, you can enter ROM monitor mode by restarting the switch and then pressing
the Break key or issuing a “send break” command from a telnet session during the first 60 seconds
of startup.The send break function can be useful for experienced users or for users under the
direction of a Cisco Technical Assistance Center (TAC) representative to recover from certain
system problems or to evaluate the cause of system problems.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-11
Chapter 7
Stateful Switchover (SSO)
Verifying the SSO Configuration
SSO Troubleshooting
The following commands may be used as needed to troubleshoot the SSO feature. These commands do
not have to be entered in any particular order.
Command
Purpose
Router(config-red)# crashdump-timeout [mm | hh:mm]
Sets the longest time that the newly active RP will wait before
reloading the formerly active RP.
Router# debug redundancy {all | ui | clk | hub}
Debugs redundancy on the networking device.
Router# show diag [slot-number | chassis | subslot
slot/subslot] [details | summary]
Displays hardware information.
Router# show redundancy [clients | counters |
debug-log | handover | history | switchover history |
states | inter-device]
Displays the redundancy configuration mode of the RP. Also
displays information about the number of switchovers, system
uptime, processor uptime, and redundancy state, and reasons
for any switchovers.
Router# show version
Displays image information for each RP.
Verifying the SSO Configuration
•
Verifying that SSO Is Configured
•
Verifying that SSO Is Operating on the Device
•
Verifying SSO Features
Verifying that SSO Is Configured
In the following example, the show redundancy command is used to verify that SSO is configured on
the device.
Router> enable
Router# show redundancy
Redundant System Information :
-----------------------------Available system uptime
Switchovers system experienced
Standby failures
Last switchover reason
=
=
=
=
3 days, 4 hours, 35 minutes
0
1
none
Hardware Mode
Configured Redundancy Mode
Operating Redundancy Mode
Maintenance Mode
Communications
=
=
=
=
=
Duplex
sso
sso
Disabled
Up
Current Processor Information :
------------------------------Active Location =
Current Software state =
Uptime in current state =
Image Version =
Synced to ...
Copyright (c) 1986-2011 by Cisco
slot 5
ACTIVE
3 days, 4 hours, 35 minutes
Cisco IOS Software, s2t54 Software ...
Systems, Inc.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-12
Chapter 7
Stateful Switchover (SSO)
Verifying the SSO Configuration
Compiled ...
BOOT
CONFIG_FILE
BOOTLDR
Configuration register
= disk0:0726_c4,12
=
=
= 0x2102
Peer Processor Information :
---------------------------Standby Location =
Current Software state =
Uptime in current state =
Image Version =
Synced to ...
Copyright (c) 1986-2011 by Cisco
Compiled ...
BOOT =
CONFIG_FILE =
BOOTLDR =
Configuration register =
slot 6
STANDBY HOT
3 hours, 55 minutes
Cisco IOS Software, s2t54 Software ...
Systems, Inc.
disk0:0726_c4,12
0x2102
Router#
Verifying that SSO Is Operating on the Device
In the following example, the show redundancy command with the states keyword is used to verify that
SSO is configured on the device.
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
Redundancy State
= sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up
client count = 135
client_notification_TMR
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
1
18
0x0
Router#
Verifying SSO Features
Enter the show redundancy clients command to display the list of features that have registered as SSO
features.
Router# show redundancy clients
clientID = 0
clientSeq =
clientID = 1319
clientSeq =
clientID = 29
clientSeq =
clientID = 139
clientSeq =
0
1
60
61
RF_INTERNAL_MSG
Cat6k Platform First
Redundancy Mode RF
IfIndex
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-13
Chapter 7
Verifying the SSO Configuration
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
3300
25
1515
3100
77
1328
1334
1333
1302
1331
1303
518
1306
1501
1503
1310
1700
78
305
304
22
88
114
225
1505
1509
1337
75
1338
512
501
513
71
24
146
301
306
1504
1507
520
210
5
138
1308
1351
1358
502
514
1313
1318
23
49
72
113
1335
200
207
202
208
20
21
1352
1307
74
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
62
68
69
73
80
81
82
83
84
86
88
89
93
98
99
100
101
102
103
104
105
106
107
108
111
114
116
120
124
126
127
128
129
130
132
135
139
146
147
151
152
153
155
156
157
158
162
163
165
166
171
172
173
174
180
181
183
184
186
193
197
201
202
206
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-14
Persistent Variable
CHKPT RF
HAL RF
MCM
Event Manager
Cat6k Asic API RF Cl
Cat6k AUTOSHUT RF Cl
Cat6k OVERSUB RF Cli
Cat6k Fabric Manager
Cat6k Inline Power
Cat6k OIR
PM Port Data
Cat6k QoS Manager
Cat6k CWAN HA
CWAN VLAN RF Client
Cat6k Feature Manage
Cat6k L3 Lif
TSPTUN HA
Multicast ISSU Conso
IP multicast RF Clie
Network RF Client
HSRP
GLBP
VRRP
Cat6k SPA TSM
Cat6k Online Diag HA
Cat6k MPLS RF Client
Tableid HA
Cat6k CTS Manager
LAN-Switch BD Manage
LAN-Switch VTP VLAN
LAN-Switch IDBHAL
XDR RRP RF Client
CEF RRP RF Client
BFD RF Client
MRIB RP RF Client
MFIB RRP RF Client
Cat6k CWAN Interface
CWAN LTL Mgr HA RF C
RFS RF
Auth Mgr
Config Sync RF clien
MDR SM
Cat6k Local Target L
RF VS Client
Cat6k VSlot
LAN-Switch Port Mana
SWITCH_VLAN_HA
Cat6k Platform
Cat6k Power
Frame Relay
HDLC
LSD HA Proc
MFI STATIC HA Proc
C6K EFP RF client
ETHERNET OAM RF
ECFM RF
ETHERNET LMI RF
LLDP
IPROUTING NSF RF cli
PPP RF
C6K_provision_rf_cli
Cat6k IDPROM
MPLS VPN HA Client
Stateful Switchover (SSO)
Chapter 7
Stateful Switchover (SSO)
Verifying the SSO Configuration
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
clientID
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
34
1502
52
35
90
250
252
54
73
76
57
50
1508
1304
1305
503
1309
1311
1317
1506
83
145
84
85
87
504
507
105
1510
203
151
94
516
508
509
515
135
136
130
400
3099
4005
93
1320
510
511
1321
1322
1315
141
1000
1001
3150
3151
3152
3153
3154
1332
1367
4032
4020
4021
1339
1362
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
clientSeq
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
208
209
210
219
231
243
245
247
248
249
250
257
263
267
271
272
273
275
276
277
284
285
286
287
291
294
295
298
304
307
310
311
314
316
317
318
322
323
324
326
335
338
342
343
345
346
347
348
350
352
361
362
363
364
365
366
367
373
375
379
381
382
404
405
SNMP RF Client
CWAN APS HA RF Clien
ATM
History RF Client
RSVP HA Services
EEM Server RF CLIENT
EEM POLICY-DIR RF CL
SNMP HA RF Client
LDP HA
IPRM
ARP
FH_RF_Event_Detector
CWAN LTL SP RF Clien
Cat6k Ehc
Cat6k PAgP/LACP
Spanning-Tree Protoc
CMRP RF Client
Cat6k L3 Manager
Cat6k CAPI
CWAN SRP RF Client
AC RF Client
VFI Mgr
AToM manager
SSM
SLB RF Client
Switch SPAN client
Switch Backup Interf
DHCP Snooping
Call-Home RF
MVRP RF
IP Tunnel RF
Config Verify RF cli
EnergyWise rf client
Port Security Client
LAN-Switch IP Host T
SISF table
IKE RF Client
IPSEC RF Client
CRYPTO RSA
IP Admission RF Clie
ISSU process
ISSU Test Client
Network RF 2 Client
Cat6k PF_ML_RP
LAN-Switch PAgP/LACP
LAN-Switch Private V
PM SP client
VLAN Mapping
Cat6k Clear Counter
DATA DESCRIPTOR RF C
CTS HA
Keystore
SIA SD RF CLIENT
SIA SB RF CLIENT
SIA SCL RF CLIENT
SIA SVE RF CLIENT
SIA TCP RF CLIENT
PCLC
Cat6k ITASCA_RP
ACL handle RF Client
IOS Config ARCHIVE
IOS Config ROLLBACK
Cat6k blue beacon RF
VS HA
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-15
Chapter 7
Stateful Switchover (SSO)
Configuration Examples for SSO
clientID = 517
clientID = 1336
clientID = 65000
clientSeq = 406
clientSeq = 415
clientSeq = 416
LAN-Switch IDBHAL2
Cat6k NTI SUP SI swi
RF_LAST_CLIENT
Configuration Examples for SSO
This example configures the SSO redundancy mode :
Router# configure terminal
Router(config)# redundancy
Router(config-red)# mode sso
Router(config-red)# exit
Router# copy running-config startup-config
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-16
CH AP TE R
8
Nonstop Forwarding (NSF)
Note
•
Prerequisites for NSF, page 8-1
•
Restrictions for NSF, page 8-2
•
Information About NSF, page 8-3
•
Default Settings for NSF, page 8-9
•
How to Configure NSF, page 8-9
•
Configuration Examples for NSF, page 8-15
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
Stateful switchover (SSO) and nonstop forwarding (NSF) do not support IPv6 multicast traffic.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for NSF
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-1
Chapter 8
Nonstop Forwarding (NSF)
Restrictions for NSF
Restrictions for NSF
•
General Restrictions, page 8-2
•
Restrictions for BGP NSF, page 8-2
•
Restrictions for EIGRP NSF, page 8-2
•
Restrictions for OSPF NSF, page 8-2
•
Restrictions for IS-IS NSF, page 8-2
•
Restrictions for IPv6 NSF, page 8-3
General Restrictions
•
NSF requires SSO (see Chapter 7, “Stateful Switchover (SSO)”).
•
The Hot Standby Routing Protocol (HSRP) is not supported with Cisco Nonstop Forwarding with
Stateful Switchover. Do not use HSRP with Cisco Nonstop Forwarding with Stateful Switchover.
Restrictions for BGP NSF
•
All neighboring devices participating in BGP NSF must be NSF-capable, having been configured
for BGP graceful restart as described in the “Configuring and Verifying BGP for NSF” section on
page 8-9.
Restrictions for EIGRP NSF
•
All neighboring devices participating in EIGRP NSF operation must be NSF-capable or NSF-aware.
•
An NSF-aware router cannot support two NSF-capable peers performing an NSF restart operation
at the same time. However, both neighbors will reestablish peering sessions after the NSF restart
operation is complete.
Restrictions for OSPF NSF
•
OSPF NSF for virtual links is not supported.
•
All OSPF networking devices on the same network segment must be NSF-aware (that is, running an
NSF software image).
•
OSPF NSF for sham links is not supported.
Restrictions for IS-IS NSF
•
For IETF IS-IS, all neighboring devices must be running an NSF-aware software image.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-2
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
Restrictions for IPv6 NSF
•
IPv6 must be enabled on your router for IPv6 NSF to be supported.
Information About NSF
•
NSF Overview, page 8-3
•
Feature Interaction with NSF, page 8-4
NSF Overview
NSF works with SSO to minimize the amount of time a network is unavailable to its users following a
switchover. The main objective of Cisco NSF is to continue forwarding IP packets following a route
processor (RP) switchover.
Usually, when a networking device restarts, all routing peers of that device detect that the device went
down and then came back up. This transition results in what is called a routing flap, which could spread
across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities,
which are detrimental to the overall network performance. Cisco NSF helps to suppress routing flaps in
SSO-enabled devices, thus reducing network instability.
Cisco NSF allows for the forwarding of data packets to continue along known routes while the routing
protocol information is being restored following a switchover. With Cisco NSF, peer networking devices
do not experience routing flaps. Data traffic is forwarded through intelligent line cards while the standby
RP assumes control from the failed active RP during a switchover. The ability of line cards to remain up
through a switchover and to be kept current with the Forwarding Information Base (FIB) on the active
RP is key to Cisco NSF operation.
The Cisco NSF feature has several benefits, including the following:
•
Improved network availability—NSF continues forwarding network traffic and application state
information so that user session information is maintained after a switchover.
•
Overall network stability—Network 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 link flapping—Because the interfaces remain up across a
switchover, neighboring routers do not detect a link flap (that is, the link does not go down and come
back up).
•
Prevents routing flaps—Because SSO continues forwarding network traffic in the event of a
switchover, routing flaps are avoided.
•
No loss of user sessions—User sessions established prior to the switchover are maintained.
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 and would rebuild routing information from NSF-aware or
NSF-capable neighbors.
CEF is always enabled on the switch and cannot be disabled. The routing protocols depend on CEF to
continue forwarding packets during switchover while the routing protocols rebuild the Routing
Information Base (RIB) tables. Once the routing protocols have converged, CEF updates the FIB table
and removes stale route entries and CEF updates the line cards with the new FIB information.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-3
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
Feature Interaction with NSF
•
Cisco Express Forwarding, page 8-4
•
Routing Protocol Operation, page 8-4
•
BGP Operation, page 8-5
•
EIGRP Operation, page 8-5
•
IS-IS Operation, page 8-6
•
OSPF Operation, page 8-7
•
IPv6 Routing Protocol Operation, page 8-8
Cisco Express Forwarding
A key element of NSF is packet forwarding. In a Cisco networking device, packet forwarding is provided
by CEF. CEF is always enabled on the switch and cannot be disabled. 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 RP synchronizes its current FIB and adjacency
databases with the FIB and adjacency databases on the standby RP. Upon switchover of the active RP,
the standby RP initially has FIB and adjacency databases that are mirror images of those that were
current on the active RP. For platforms with intelligent line cards, the line cards will maintain the current
forwarding information over a switchover; for platforms with forwarding engines, CEF will keep the
forwarding engine on the standby RP current with changes that are sent to it by CEF on the active RP.
In this way, the line cards 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 in turn 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 line cards or forwarding engine during convergence. The RP
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.
Routing Protocol Operation
The routing protocols run only on the active RP, and they receive routing updates from their neighbor
routers. Routing protocols do not run on the standby RP. 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
standby RP to help rebuild the routing table on the NSF-capable device in environments where neighbor
devices are not NSF-aware.
For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the
routing protocols rebuild the routing information.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-4
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
BGP Operation
When a 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 declaration 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 peer(s) 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.
If the BGP session is lost during the RP 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 means that no packets are lost while the
newly active RP is waiting for convergence of the routing information with the BGP peers.
After an RP 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. Once 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. Following that, the BGP protocol 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.
EIGRP Operation
EIGRP NSF capabilities are exchanged by EIGRP peers in hello packets. The NSF-capable router
notifies its neighbors that an NSF restart operation has started by setting the restart (RS) bit in a hello
packet. When an NSF-aware router receives notification from an NSF-capable neighbor that an
NSF-restart operation is in progress, the NSF-capable and NSF-aware routers immediately exchange
their topology tables. The NSF-aware router sends an end-of-table (EOT) update packet when the
transmission of its topology table is complete. The NSF-aware router then performs the following
actions to assist the NSF-capable router:
•
The EIGRP hello hold timer is expired to reduce the time interval set for hello packet generation and
transmission. This allows the NSF-aware router to reply to the NSF-capable router more quickly
reducing the amount of time required for the NSF-capable router to rediscover neighbors and rebuild
the topology table.
•
The route-hold timer is started. This timer is used to set the period of time that the NSF-aware router
will hold known routes for the NSF-capable neighbor. This timer is configured with the
timers nsf route-hold command. The default time period is 240 seconds.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-5
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
•
The NSF-aware router notes in the peer list that the NSF-capable neighbor is restarting, maintains
adjacency, and holds known routes for the NSF-capable neighbor until the neighbor signals that it
is ready for the NSF-aware router to send its topology table or the route-hold timer expires. If the
route-hold timer expires on the NSF-aware router, the NSF-aware router will discard held routes and
treat the NSF-capable router as a new router joining the network and reestablishing adjacency
accordingly.
•
The NSF-aware router will continue to send queries to the NSF-capable router which is still in the
process of converging after switchover, effectively extending the time before a stuck-in-active (SIA)
condition can occur.
When the switchover operation is complete, the NSF-capable router notifies its neighbors that it has
reconverged and has received all of their topology tables by sending an EOT update packet to the
assisting routers. The NSF-capable then returns to normal operation. The NSF-aware router will look for
alternate paths (go active) for any routes that are not refreshed by the NSF-capable (restarting router).
The NSF-aware router will then return to normal operation. If all paths are refreshed by the NSF-capable
router, the NSF-aware router will immediately return to normal operation.
Note
NSF-aware routers are completely compatible with non-NSF aware or capable neighbors in an EIGRP
network. A non-NSF aware neighbor will ignore NSF capabilities and reset adjacencies and otherwise
maintain the peering sessions normally.
IS-IS Operation
The IS-IS protocol can be configured to use state information that has been synchronized between the
active and the standby RP to recover route information following a switchover instead of information
received from peer devices.
When an IS-IS NSF-capable router performs an RP switchover, it must perform two tasks in order to
resynchronize its Link State Database with its IS-IS neighbors. First, it must relearn the available IS-IS
neighbors on the network without causing a reset of the neighbor relationship. Second, it must reacquire
the contents of the Link State Database for the network.
The IS-IS NSF feature offers two options when configuring NSF:
•
Internet Engineering Task Force (IETF) IS-IS
•
Cisco IS-IS
If neighbor routers on a network segment are NSF-aware, meaning that neighbor routers are running a
software version that supports the IETF Internet draft for router restartability, they will assist an IETF
NSF router which 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 standby RP. A benefit of Cisco configuration is that it does not rely on NSF-aware
neighbors.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-6
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
IETF IS-IS Configuration
Using the IETF IS-IS configuration, as quickly as possible after an RP switchover, the NSF-capable
router sends IS-IS NSF restart requests to neighboring NSF-aware devices. Neighbor networking devices
recognize this restart request as a cue 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.
Once 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 RP 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 standby RP will
boot up and synchronize its configuration with the active RP. 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 standby RP. Following a switchover, the newly active RP maintains its adjacencies using the
checkpointed data, and can quickly rebuild its routing tables.
Note
Following a switchover, Cisco IS-IS NSF has complete neighbor adjacency and LSP information;
however, it must wait for all interfaces that had adjacencies prior to the switchover to come up. If an
interface does not come up 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 up in a timely fashion.
The switchover from one RP 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 standby RP will
boot up and synchronize its configuration with the active RP. Once this synchronization is completed,
IS-IS adjacency and LSP data is checkpointed to the standby RP; 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.
OSPF Operation
When an OSPF NSF-capable router performs an RP switchover, it must perform two tasks in order to
resynchronize its Link State Database with its OSPF neighbors. First, it must relearn the available OSPF
neighbors on the network without causing a reset of the neighbor relationship. Second, it must re-acquire
the contents of the Link State Database for the network.
As quickly as possible after an RP switchover, the NSF-capable router sends an OSPF NSF signal to
neighboring NSF-aware devices. Neighbor networking devices recognize this signal as a cue 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-7
Chapter 8
Nonstop Forwarding (NSF)
Information About NSF
Once 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.
The OSPF RFC 3623 Graceful Restart feature allows you to configure IETF NSF in multivendor
networks. For more information, see the OSPF RFC 3623 Graceful Restart document.
IPv6 Routing Protocol Operation
IPv6 support for NSF includes the following features:
•
Nonstop Forwarding and Graceful Restart for MP-BGP IPv6 Address Family, page 8-8
•
Nonstop Forwarding for IPv6 RIP, page 8-8
•
Nonstop Forwarding for IPv6 Static Routes, page 8-8
Nonstop Forwarding and Graceful Restart for MP-BGP IPv6 Address Family
The switch supports the graceful restart capability for IPv6 BGP unicast and VPNv6 address families,
enabling Cisco NSF functionality for BGP IPv6. The BGP graceful restart capability allows the BGP
routing table to be recovered from peers without keeping the TCP state.
NSF continues forwarding packets while routing protocols converge, therefore avoiding a route flap on
switchover. Forwarding is maintained by synchronizing the FIB between the active and standby RP. On
switchover, forwarding is maintained using the FIB. The RIB is not kept synchronized; therefore, the
RIB is empty on switchover. The RIB is repopulated by the routing protocols and subsequently informs
FIB about RIB convergence by using the NSF_RIB_CONVERGED registry call. The FIB tables are
updated from the RIB, removing any stale entries. The RIB starts a failsafe timer during RP switchover,
in case the routing protocols fail to notify the RIB of convergence.
The Cisco BGP address family identifier (AFI) model is modular and scalable, and supports multiple
AFIs and subsequent address family identifier (SAFI) configurations.
For information about how to configure the IPv6 BGP graceful restart capability, see the “Implementing
Multiprotocol BGP for IPv6” document.
Nonstop Forwarding for IPv6 RIP
RIP registers as an IPv6 NSF client. Doing so has the benefit of using RIP routes installed in the Cisco
Express Forwarding table until RIP has converged on the standby.
Nonstop Forwarding for IPv6 Static Routes
Cisco NSF supports IPv6 static routes.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-8
Chapter 8
Nonstop Forwarding (NSF)
Default Settings for NSF
Default Settings for NSF
None.
How to Configure NSF
•
Configuring and Verifying BGP for NSF, page 8-9 (optional)
•
Configuring and Verifying EIGRP NSF, page 8-10 (optional)
•
Configuring and Verifying OSPF NSF, page 8-12 (optional)
•
Configuring and Verifying IS-IS NSF, page 8-13 (optional)
•
Troubleshooting Cisco Nonstop Forwarding, page 8-14 (optional)
Configuring and Verifying BGP for NSF
•
Configuring BGP for NSF, page 8-9
•
Verifying NSF for BGP, page 8-10
Configuring BGP for NSF
Perform this task to configure BGP for NSF. Repeat this task on each BGP NSF peer device:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# router bgp autonomous-system-number
Enables a BGP routing process, and enters router
configuration mode.
Step 4
Router(config-router)# bgp graceful-restart
[restart-time seconds | stalepath-time seconds]
Enables the BGP graceful restart capability, which
starts NSF for BGP.
This example shows how to configure BGP for NSF:
Router> enable
Router# configure terminal
Router(config)# router bgp 120
Router(config-router)# bgp graceful-restart
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-9
Chapter 8
Nonstop Forwarding (NSF)
How to Configure NSF
Verifying NSF for BGP
Perform this task to verify that the graceful restart function is configured on the SSO-enabled networking
device and on the neighbor devices:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# show running-config
Displays the contents of the current running
configuration file.
Verify that the phrase “bgp graceful-restart”
appears in the BGP configuration of the
SSO-enabled router.
Repeat this step on each of the BGP neighbors.
Step 3
Router# show ip bgp neighbors [ip-address
[advertised-routes | dampened-routes | flap-statistics
| paths [reg-exp] | received prefix-filter |
received-routes | routes | policy [detail]]]
Displays information about BGP and TCP
connections to neighbors.
On the SSO device and the neighbor device, this
command verifies that the graceful restart function
is shown as both advertised and received, and
confirms the address families that have the graceful
restart capability. If no address families are listed,
then BGP NSF also will not occur.
This example shows how to NSF for BGP:
Router>
Router#
Router#
Router#
enable
configure terminal
show running-config
show ip bgp neighbors
Configuring and Verifying EIGRP NSF
•
Configuring EIGRP for NSF, page 8-10
•
Verifying EIGRP for NSF, page 8-11
Configuring EIGRP for NSF
Note
•
An NSF-aware router must be completely converged with the network before it can assist an
NSF-capable router in an NSF restart operation.
•
Distributed platforms that run a supporting version of Cisco IOS software can support full NSF
capabilities. These routers can perform a restart operation and can support other NSF capable peers.
•
Single processor platforms that run a supporting version of Cisco IOS software support only NSF
awareness. These routers maintain adjacency and hold known routes for the NSF-capable neighbor
until it signals that it is ready for the NSF-aware router to send its topology table or the route-hold
timer expires.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-10
Chapter 8
Nonstop Forwarding (NSF)
How to Configure NSF
Perform this task to configure EIGRP for NSF. Repeat this procedure on each EIGRP NSF peer device:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# router eigrp as-number
Enables an EIGRP routing process, and enters
router configuration mode.
Step 4
Router(config-router)# nsf [{cisco | ietf} | interface
wait seconds | interval minutes | t3 [adjacency |
manual seconds]
(Optional) Enables EIGRP NSF support on an NSF
capable router. Enter this command on only
NSF-capable routers. NSF awareness is enabled by
default when a supporting version of Cisco IOS
software is installed on a router that supports NSF
capability or NSF awareness.
Step 5
Router(config-router)# timers nsf converge seconds
Adjusts the maximum time that restarting router
will wait for the EOT notification from an
NSF-capable or NSF-aware peer.
Step 6
Router(config-router)# timers nsf route-hold seconds
Sets the route-hold timer to determine how long an
NSF-aware router that is running EIGRP will hold
routes for an inactive peer.
Step 7
Router(config-router)# timers nsf signal seconds
Adjusts the maximum time for the initial restart
period.
This example shows how to configure EIGRP for NSF:
Router> enable
Router# configure terminal
Router(config)# router eigrp 109
Router(config-router)# nsf
Router(config-router)# timers nsf converge 60
Router(config-router)# timers nsf route-hold 120
Router(config-router)# timers nsf signal seconds
Verifying EIGRP for NSF
Perform this task to verify that NSF awareness or capability or both are enabled on the SSO-enabled
networking device and on the neighbor devices.
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# show ip protocols
Displays the parameters and current state of the
active routing protocol process.
Repeat this step on each of the EIGRP neighbors.
This example shows how to verify EIGRP for NSF:
Router> enable
Router# show ip protocols
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-11
Chapter 8
Nonstop Forwarding (NSF)
How to Configure NSF
Configuring and Verifying OSPF NSF
•
Configuring OSPF for NSF, page 8-12
•
Verifying OSPF for NSF, page 8-12
Configuring OSPF for NSF
Note
All peer devices participating in OSPF NSF must be made OSPF NSF aware; NSF awareness is enabled
by default when a supporting version of Cisco IOS software is installed on a router that supports NSF
capability or NSF awareness.
Perform this task to configure OSPF for NSF:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# router ospf process-id [vrf vpn-name]
Enables an OSPF routing process, and places the
router in router configuration mode.
Step 4
Router(config-router)# nsf [{cisco | ietf} | interface
wait seconds | interval minutes | t3 [adjacency |
manual seconds]
Enables EIGRP NSF support on an NSF capable
router.
•
Enter this command on NSF-capable routers
only.
This example shows how to configure OSPF for NSF:
Router> enable
Router# configure terminal
Router(config)# router ospf 12
Router(config-router)# nsf
Verifying OSPF for NSF
Perform this task to verify OSPF for NSF:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# show ip ospf [process-id]
Displays general information about OSPF routing
processes.
This example shows how to verify OSPF for NSF:
Router> enable
Router# show ip ospf
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-12
Chapter 8
Nonstop Forwarding (NSF)
How to Configure NSF
Configuring and Verifying IS-IS NSF
•
Configuring NSF for IS-IS, page 8-13
•
Verifying NSF for IS-IS, page 8-14
Configuring NSF for IS-IS
Perform this task to configure NSF for IS-IS:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# router isis area-tag
Enables the IS-IS routing protocol to specify
an IS-IS process, and places the router in
router configuration mode.
Step 4
Router(config-router)# nsf [{cisco | ietf} | interface
wait seconds | interval minutes | t3 [adjacency | manual
seconds]
Enables NSF operation for IS-IS.
•
ietf—Enables IS-IS in homogeneous
network where adjacencies with
networking devices supporting IETF
draft-based restartability is guaranteed.
•
cisco—Runs IS-IS in heterogeneous
networks that might not have adjacencies
with NSF-aware networking devices.
Step 5
Router(config-router)# nsf interval minutes
Configures the minimum time between Cisco
NSF restart attempts.
Step 6
Router(config-router)# nsf t3 {manual seconds | adjacency}
Specifies the methodology used to determine
how long IETF Cisco NSF will wait for the
link-state packet (LSP) database to
synchronize before generating overloaded
link-state information for itself and flooding
that information out to its neighbors.
Step 7
Router(config-router)# nsf interface wait seconds
Specifies how long a Cisco NSF restart will
wait for all interfaces with IS-IS adjacencies to
come up before completing the restart.
This example shows how to configure NSF for IS-IS:
Router> enable
Router# configure terminal
Router(config)# router isis cisco1
Router(config-router)# nsf ietf
Router(config-router)# nsf interval 2
Router(config-router)# nsf t3 manual 40
Router(config-router)# nsf interface wait 15
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-13
Chapter 8
Nonstop Forwarding (NSF)
How to Configure NSF
Verifying NSF for IS-IS
Perform this task to verify NSF for IS-IS:
Command
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your
password if prompted).
Step 2
Router# show running-config
Displays the contents of the current running
configuration file.
Step 3
Router# show isis nsf
Displays current state information regarding IS-IS
NSF.
This example shows how to verify NSF for IS-IS:
Router> enable
Router# show running-config
Router# show isis nsf
Troubleshooting Cisco Nonstop Forwarding
To troubleshoot Cisco Nonstop Forwarding, use the following commands as needed:
Command
Purpose
Router# debug eigrp nsf
Displays notifications and information about NSF events for
an EIGRP routing process.
Router# debug ip eigrp notifications
Displays information and notifications for an EIGRP routing
process. This output includes NSF notifications and events.
Router# debug isis nsf [detail]
Displays information about the IS-IS state during a Cisco
NSF restart.
Router# debug ospf nsf [detail]
Displays debugging messages related to OSPF Cisco NSF
commands.
Router# show cef nsf
Displays the current NSF state of CEF on both the active and
standby RPs.
Router# show cef state
Displays the CEF state on a networking device.
Router# show clns neighbors
Display both end-system and intermediate system neighbors.
Router# show ip bgp
Displays entries in the BGP routing table.
Router# show ip bgp neighbor
Displays information about the TCP and BGP connections to
neighbor devices.\
Router# show ip cef
Displays entries in the FIB that are unresolved, or displays a
FIB summary.
Router# show ip eigrp neighbors [interface-type |
as-number | static | detail]
To display detailed information about neighbors discovered
by EIGRP.
Router# show ip ospf
Displays general information about OSPF routing processes.
Router# show ip ospf neighbor [detail]
Displays OSPF-neighbor information on a per-interface basis.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-14
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
Command
Purpose
Router# show ip protocols
Displays the parameters and current state of the active routing
protocol process. The status of EIGRP NSF configuration and
support is displayed in the output.
Router# show isis database [detail]
Displays the IS-IS link-state database.
Router# show isis nsf
Displays the current state information regarding IS-IS Cisco
NSF.
Configuration Examples for NSF
•
Example: Configuring BGP NSF, page 8-15
•
Example: Configuring BGP NSF Neighbor Device, page 8-15
•
Example: Verifying BGP NSF, page 8-16
•
Example: Configuring EIGRP NSF Converge Timer, page 8-16
•
Example: EIGRP Graceful-Restart Purge-Time Timer Configuration, page 8-16
•
Example: Configuring EIGRP NSF Route-Hold Timer, page 8-17
•
Example: Configuring EIGRP NSF Signal Timer, page 8-17
•
Example: Disabling EIGRP NSF Support, page 8-18
•
Example: Verifying EIGRP NSF, page 8-17
•
Example: Configuring OSPF NSF, page 8-18
•
Example: Verifying OSPF NSF, page 8-18
•
Example: Configuring IS-IS NSF, page 8-19
•
Example: Verifying IS-IS NSF, page 8-19
Example: Configuring BGP NSF
The following example shows how to configure BGP NSF on a networking device.
Router# configure terminal
Router(config)# router bgp 590
Router(config-router)# bgp graceful-restart
Example: Configuring BGP NSF Neighbor Device
The following example shows how to configure BGP NSF on a neighbor router. All devices supporting
BGP NSF must be NSF-aware, meaning that these devices recognize and advertise graceful restart
capability.
Router# configure terminal
Router(config)# router bgp 770
Router(config-router)# bgp graceful-restart
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-15
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
Example: Verifying BGP NSF
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
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 family 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
Example: Configuring EIGRP NSF Converge Timer
The timers nsf converge command is used to adjust the maximum time that a restarting router will wait
for the EOT notification from an NSF-capable or NSF-aware peer. The following example shows how to
set the converge timer to one minute.
Router# configure terminal
Router(config)# router eigrp 101
Router(config-router)# timers nsf converge 60
Example: EIGRP Graceful-Restart Purge-Time Timer Configuration
The timers graceful-restart purge-time command is used to set the route-hold timer that determines
how long an NSF-aware router that is running EIGRP will hold routes for an inactive peer. The following
example shows how to set the route-hold timer to two minutes:
Router(config-router)# timers graceful-restart purge-time 120
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-16
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
Example: Configuring EIGRP NSF Route-Hold Timer
The timers nsf route-hold command is used to set the maximum period of time that an NSF-aware
router will hold known routes for an NSF-capable neighbor during a switchover operation. The following
example shows how to set the route-hold timer to two minutes.
Router# configure terminal
Router(config)# router eigrp 101
Router(config-router)# timers nsf route-hold 120
Example: Configuring EIGRP NSF Signal Timer
The timers nsf signal command is used to adjust the maximum time for the initial restart period. The
following example shows how to set the signal timer to 10 seconds.
Router# configure terminal
Router(config)# router eigrp 101
Router(config-router)# timers nsf signal 10
Example: Verifying EIGRP NSF
Verify that EIGRP NSF support is present in the installed Cisco IOS software image by entering the
show ip protocols command. “EIGRP NSF-aware route hold timer is...” is displayed in the output when
either NSF awareness or capability is supported. This line displays the default or user-defined value for
the route-hold timer. “EIGRP NSF...” is displayed in the output only when the NSF capability is
supported. This line will also print “disabled” or “enabled” depending on the status of the EIGRP NSF
feature.
Router# show ip protocols
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
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:
10.4.9.0/24
Routing Information Sources:
Gateway
Distance
Last Update
Distance: internal 90 external 170
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-17
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
Example: Disabling EIGRP NSF Support
EIGRP NSF capability is enabled by default on distributed platforms that run a supporting version of
Cisco IOS software. The nsf command used to enable or disable the EIGRP NSF capability. The
following example shows how to disable NSF capability:
Router# configure terminal
Router(config)# router eigrp 101
Router(config-router)# no nsf
Example: Configuring OSPF NSF
The following example shows how to configure OSPF NSF on a networking device:
Router# configure terminal
Router(config)# router ospf 400
Router(config-router)# nsf
Example: Verifying OSPF NSF
To verify NSF for OSPF, you must check that the NSF function is configured on the SSO-enabled
networking device. 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
Next, use 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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-18
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
Example: Configuring IS-IS NSF
The following example shows how to configure Cisco proprietary IS-IS NSF operation on a networking
device:
Router# configure terminal
Router(config)# router isis
Router(config-router)# nsf cisco
The following example shows how to configure IS-IS NSF for IETF operation on a networking device:
Router# configure terminal
Router(config)# router isis
Router(config-router)# nsf ietf
Example: Verifying IS-IS NSF
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 Cisco IS-IS or IETF IS-IS configuration. The
following example indicates that the device uses the Cisco implementation of IS-IS NSF:
Router# show running-config
router isis
nsf cisco
If the NSF configuration is set to cisco, use 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
standby RPs. The following example shows output for the Cisco configuration on the active RP. In this
example, note the presence of the phrase “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 example shows sample output for the Cisco configuration on the standby RP. In this
example, note the presence of the phrase “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
The following example 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:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-19
Chapter 8
Nonstop Forwarding (NSF)
Configuration Examples for NSF
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
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
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-20
CH AP TE R
9
Route Processor Redundancy (RPR)
Note
•
Prerequisites for RPR, page 9-1
•
Restrictions for RPR, page 9-1
•
Information About RPR, page 9-2
•
Default Settings for RPR, page 9-4
•
How to Configure RPR, page 9-4
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
In route processor redundancy (RPR) redundancy mode, the ports on a supervisor engine in standby
mode are disabled.
•
RPR supports IPv6 multicast traffic.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for RPR
None.
Restrictions for RPR
•
General RPR Restrictions, page 9-2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-1
Chapter 9
Route Processor Redundancy (RPR)
Information About RPR
•
Hardware Restrictions for RPR, page 9-2
General RPR Restrictions
•
When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the
standby 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 standby 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 standby
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.
•
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.
Hardware Restrictions for RPR
Note
•
Cisco IOS 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.
•
Except during an FSU, both supervisor engines must have the same system image (see the “Copying
Files to the RP” section on page 9-6).
•
The configuration register must be set to 0x2102 ( config-register 0x2102).
There is no support for booting from the network.
Information About RPR
•
Supervisor Engine Redundancy Overview, page 9-3
•
RPR Operation, page 9-3
•
Supervisor Engine Configuration Synchronization, page 9-4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-2
Chapter 9
Route Processor Redundancy (RPR)
Information About RPR
Supervisor Engine Redundancy Overview
The switch supports fault resistance by allowing a standby 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 standby supervisor engines
•
Hardware signals that detect and decide the active or standby status of supervisor engines
•
Clock synchronization every 60 seconds from the active to the standby supervisor engine
•
A standby supervisor engine that is booted but not all subsystems are up: if the active supervisor
engine fails, the standby supervisor engine become fully operational
•
An operational supervisor engine present in place of the failed unit becomes the standby supervisor
engine
•
Support for fast software upgrade (FSU) (see Chapter 6, “Fast Software Upgrade”.)
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 route processor (RP) and Policy Feature
Card (PFC) become fully operational. The RP and PFC on the standby supervisor engine come out of
reset but are not operational.
In a switchover, the standby supervisor engine become fully operational and the following occurs:
Note
•
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
In a switchover, there is a disruption of traffic because some address states are lost and then restored after
they are dynamically redetermined.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-3
Chapter 9
Route Processor Redundancy (RPR)
Default Settings for RPR
Supervisor Engine Configuration Synchronization
Note
Configuration changes made through SNMP are not synchronized to the standby 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 standby
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.
Default Settings for RPR
None.
How to Configure RPR
•
Configuring RPR Mode, page 9-4
•
Synchronizing the Supervisor Engine Configurations, page 9-5
•
Displaying the Redundancy States, page 9-5
•
Copying Files to the RP, page 9-6
Configuring RPR Mode
To configure RPR mode, 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
standby supervisor engine is reloaded and begins to work
in RPR mode.
This example shows how to configure the system for RPR:
Router> enable
Router# configure terminal
Enter configuration commands, one per line.
Router(config)# redundancy
Router(config-red)# mode rpr
Router(config-red)# end
Router# show running-config
Router# show redundancy states
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-4
End with CNTL/Z.
Chapter 9
Route Processor Redundancy (RPR)
How to Configure RPR
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
Redundancy Mode
Split Mode
Manual Swact
Communications
(Operational) = Route Processor Redundancy
(Configured) = Route Processor Redundancy
= Disabled
= Enabled
= Up
client count = 11
client_notification_TMR
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
9000 milliseconds
0
18
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) = rpr
Redundancy Mode (Configured) = rpr
Redundancy State
= Non Redundant
Maintenance Mode = Disabled
Communications = Down
Reason: Simplex mode
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-5
Chapter 9
Route Processor Redundancy (RPR)
How to Configure RPR
client count = 11
client_notification_TMR
keep_alive TMR
keep_alive count
keep_alive threshold
RF debug mask
=
=
=
=
=
30000 milliseconds
4000 milliseconds
0
7
0x0
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 standby 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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-6
PART
2
Interface and Hardware Components
CH AP TE R
10
Interface Configuration
Note
•
Information About Interface Configuration, page 10-2
•
How to Configure a Range of Interfaces, page 10-2
•
How to Define and Use Interface-Range Macros, page 10-2
•
How to Configure Optional Interface Features, page 10-3
•
Information About Online Insertion and Removal, page 10-11
•
How to Monitor and Maintain Interfaces, page 10-11
•
How to Check Cable Status with the TDR, page 10-14
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-1
Chapter 10
Interface Configuration
Information About Interface Configuration
Information About 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)
•
Slot number—The slot in which the module is installed. On switches supported by
Cisco IOS Release 15.1SY, slots are numbered starting with 1 from top to bottom.
•
Port number—The physical port number on the module. On switches supported by
Cisco IOS Release 15.1SY, 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.
See this document for information about the interface command:
http://www.cisco.com/en/US/docs/ios-xml/ios/interface/command/ir-i1.html#GUID-0D6BDFCD-3FBB-4D
26-A274-C1221F8592DF
How to Configure 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. See this document for information about the interface range
command:
http://www.cisco.com/en/US/docs/ios-xml/ios/interface/command/ir-i1.html#GUID-8EC4EF91-F929-45F8
-95CA-E4C9A9724FFF
How to Define and Use 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
{vlan vlan_ID - vlan_ID} | {type slot/port - port} [,
{type slot/port - port}]
Defines the interface-range macro and save it in NVRAM.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-2
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
This example shows how to define an interface-range macro named enet_list to select Gigabit Ethernet
ports 1/1 through 1/4:
Router(config)# define interface-range enet_list gigabitethernet 1/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 GigabitEthernet1/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)#
How to Configure Optional Interface Features
•
Configuring Ethernet Interface Speed and Duplex Mode, page 10-3
•
Configuring Jumbo Frame Support, page 10-6
•
Configuring IEEE 802.3x Flow Control, page 10-9
•
Configuring the Port Debounce Timer, page 10-10
Configuring Ethernet Interface Speed and Duplex Mode
•
Speed and Duplex Mode Configuration Guidelines, page 10-4
•
Configuring the Ethernet Interface Speed, page 10-4
•
Setting the Interface Duplex Mode, page 10-5
•
Configuring Link Negotiation on Gigabit Ethernet Ports, page 10-5
•
Displaying the Speed and Duplex Mode Configuration, page 10-6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-3
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
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:
Note
Caution
•
You cannot set the Ethernet port speed to auto (the no speed command) if the duplex mode in not
set to auto (the no duplex command).
•
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.
A LAN port cannot automatically negotiate Ethernet port speed and duplex mode if the connecting port
is configured to a value other than auto.
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/1000-Mbps Ethernet port, both speed and
duplex are autonegotiated. 10-Gigabit Ethernet ports do not support autonegotiation.
To configure the port speed for a 10/100/1000-Mbps Ethernet port, perform this task:
Command
Purpose
Step 1
Router(config)# interface gigabitethernet
slot/port
Selects the Ethernet port to be configured.
Step 2
Router(config-if)# speed {10 | 100 | 1000 |
{auto [10 100 [1000]]}}
Configures the speed of the Ethernet interface.
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 Gigabit Ethernet port 1/4:
Router(config)# interface gigabitethernet 1/4
Router(config-if)# speed 100
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-4
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
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/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 Gigabit Ethernet port, perform this task:
Command
Purpose
Step 1
Router(config)# interface gigabitethernet
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 Gigabit Ethernet port 1/4:
Router(config)# interface gigabitethernet 1/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).
Table 10-1 shows the four possible link negotiation configurations and the resulting link status for each
configuration.
Table 10-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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-5
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
To configure link negotiation on a port, perform this task:
Command
Purpose
Step 1
Router(config)# interface gigabitethernet
slot/port
Selects the port to be configured.
Step 2
Router(config-if)# speed nonegotiate
Disables link negotiation.
This example shows how to enable link negotiation on Gigabit Ethernet port 1/4:
Router(config)# interface gigabitethernet 1/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
Router# show interfaces type slot/port [transceiver
properties]
Displays the speed and duplex mode configuration. To display
autonegotiation status for speed and duplex, add the
transceiver properties option.
Configuring Jumbo Frame Support
•
Information about Jumbo Frame Support, page 10-6
•
Configuring MTU Sizes, page 10-8
Information about Jumbo Frame Support
•
Jumbo Frame Support Overview, page 10-6
•
Nondefault MTU Sizes on Ethernet Ports, page 10-7
•
VLAN Interfaces, page 10-8
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/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/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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-6
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
“Configuring the Global Egress LAN Port MTU Size” section on page 10-9).
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 10-9).
Nondefault MTU Sizes on Ethernet Ports
•
Ethernet Port Overview, page 10-7
•
Layer 3 Ethernet Ports, page 10-7
•
Layer 2 Ethernet Ports, page 10-8
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.
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 10-9).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-7
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
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 10-9).
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
•
Configuring the MTU Size, page 10-8
•
Configuring the Global Egress LAN Port MTU Size, page 10-9
Configuring the MTU Size
To configure the MTU size, perform this task:
Command
Purpose
Step 1
Router(config)# interface {{vlan vlan_ID} |
{{type slot/port} | {port-channel
port_channel_number} slot/port}}
Selects the interface to configure.
Step 2
Router(config-if)# mtu mtu_size
Configures the MTU size.
Step 3
Router(config-if)# end
Exits configuration mode.
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 10-9).
•
MTU size on a Layer 2 interface is always set to maximum. If you reconfigure the MTU size to
enable jumbo frame support, MTU size does not get updated in the MTU hardware table for L2
interface at the egress. The interface (L2) MTU size check happens only at the ingress port.
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#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-8
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
Configuring the Global Egress LAN Port MTU Size
To configure the global egress LAN port MTU size, perform this task:
Step 1
Command
Purpose
Router(config)# system jumbomtu mtu_size
Configures the global egress LAN port MTU size.
Note
Step 2
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)
Exits configuration mode.
Router(config)# end
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.
To configure flow control on an Ethernet port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the port to configure.
Step 2
Router(config-if)# flowcontrol {receive | send}
{desired | off | on}
Configures a port to send or respond to pause frames.
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.
•
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-9
Chapter 10
Interface Configuration
How to Configure Optional Interface Features
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
Gi1/1
Desired
Gi1/2
Desired
<output truncated>
Receive
OFF
ON
Configuring the Port Debounce Timer
The port debounce timer delays notification of a link change, which can decrease traffic loss due to
network reconfiguration. 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
Step 1
Router(config)# interface type slot/port
Selects the port to configure.
Step 2
Router(config-if)# link debounce
[time debounce_time]
Configures the debounce timer.
When configuring the debounce timer on a port, note the following information:
•
The time keyword is supported only on fiber 1000 Mpbs or faster Ethernet ports.
•
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 10-2 lists the time delay that occurs before notification of a link change.
Table 10-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 or 10 Gbps over copper media:
300 milliseconds
3100 milliseconds
Ports operating at 1000 Mpbs or 10 Gbps over fiber media:
10 milliseconds
100 milliseconds
Note
The show interfaces debounce command does not display the default value for 10-GigabitEthernet ports when the port
debounce timer is disabled.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-10
Chapter 10
Interface Configuration
Information About Online Insertion and Removal
Note
On all 10-Gigabit Ethernet ports, the Debounce Timer Disabled value is 10 milliseconds and the
Debounce Timer Enabled value is 100 milliseconds.
This example shows how to enable the port debounce timer on Gigabit Ethernet port 1/12:
Router(config)# interface gigabitethernet 1/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
Gi1/12 enable
3100
Information About Online Insertion and Removal
The online insertion and removal (OIR) feature 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.
When a module has been removed or installed, the 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.
How to Monitor and Maintain Interfaces
•
Monitoring Interface Status, page 10-12
•
Clearing Counters on an Interface, page 10-12
•
Resetting an Interface, page 10-13
•
Shutting Down and Restarting an Interface, page 10-13
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-11
Chapter 10
Interface Configuration
How to Monitor and Maintain Interfaces
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.
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.
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} |
{type slot/port} | {port-channel channel_ID}}
Clears interface counters.
This example shows how to clear and reset the counters on Gigabit Ethernet port 1/5:
Router# clear counters gigabitethernet 1/5
Clear "show interface" counters on this interface [confirm] y
*Sep 30 08:42:55: %CLEAR-5-COUNTERS: Clear counter on interface GigabitEthernet1/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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-12
Chapter 10
Interface Configuration
How to Monitor and Maintain Interfaces
Resetting an Interface
To reset an interface, perform this task:
Command
Purpose
Router# clear interface type slot/port
Resets an interface.
This example shows how to reset Gigabit Ethernet port 1/5:
Router# clear interface gigabitethernet 1/5
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} |
{type slot/port} | {port-channel channel_ID}}
Selects the interface to be configured.
Step 2
Router(config-if)# shutdown
Shuts down the interface.
Step 3
Router(config-if)# no shutdown
Reenables the interface.
This example shows how to shut down Gigabit Ethernet port 1/5:
Router(config)# interface gigabitethernet 1/5
Router(config-if)# shutdown
Router(config-if)#
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 Gigabit Ethernet port 1/5:
Router(config-if)# no shutdown
Router(config-if)#
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-13
Chapter 10
Interface Configuration
How to Check Cable Status with the TDR
How to Check Cable Status with 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.
Note
•
TDR can test cables up to a maximum length of 115 meters.
•
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
interface_number}
Starts or stops the TDR test.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-14
CH AP TE R
1
UniDirectional Link Detection ( UDLD)
Note
•
Prerequisites for UDLD, page 1-1
•
Restrictions for UDLD, page 1-1
•
Information About UDLD, page 1-2
•
Default Settings for UDLD, page 1-4
•
How to Configure UDLD, page 1-4
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for UDLD
None.
Restrictions for UDLD
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-1
Chapter 1
UniDirectional Link Detection ( UDLD)
Information About UDLD
Information About UDLD
•
UDLD Overview, page 1-2
•
UDLD Aggressive Mode, page 1-3
•
Fast UDLD, page 1-4
UDLD Overview
The Cisco-proprietary UDLD protocol allows devices connected through fiber-optic or copper (for
example, Category 5 cabling) Ethernet cables connected to LAN ports to monitor the physical
configuration of the cables and detect when a unidirectional link exists. When a unidirectional link is
detected, UDLD shuts down the affected LAN port and alerts the user. Unidirectional links can cause a
variety of problems, including spanning tree topology loops.
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 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 locally disabled on copper LAN ports to avoid sending unnecessary control traffic
on this type of media since it is often used for access ports.
Figure 1-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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-2
Chapter 1
UniDirectional Link Detection ( UDLD)
Information About UDLD
Figure 1-1
Unidirectional Link
TX
RX
TX
RX
Switch B
18720
Switch A
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, nonaggressive UDLD with the default 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.
Note
In UDLD normal mode, when a unidirectional error is detected, the port is not disabled. In UDLD
aggressive mode, when a unidirectional error is detected, the port is disabled.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-3
Chapter 1
UniDirectional Link Detection ( UDLD)
Default Settings for UDLD
Fast UDLD
Release 15.0(1)SY1 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:
•
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 60 ports with a Supervisor Engine 2T.
Default Settings for UDLD
Feature
Default Value
UDLD global enable state
Globally disabled.
UDLD aggressive mode
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.
Fast UDLD
Disabled.
Fast UDLD error reporting
Disabled.
How to Configure UDLD
•
Enabling UDLD Globally, page 1-5
•
Enabling UDLD on LAN Interfaces, page 1-5
•
Disabling UDLD on Nonfiber-Optic LAN Interfaces, page 1-5
•
Disabling UDLD on Fiber-Optic LAN Interfaces, page 1-6
•
Configuring the UDLD Probe Message Interval, page 1-6
•
Configuring Fast UDLD, page 1-6
•
Resetting Disabled LAN Interfaces, page 1-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-4
Chapter 1
UniDirectional Link Detection ( UDLD)
How to Configure UDLD
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 Interfaces
To enable UDLD on a LAN port, perform this task:
Command
Purpose
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 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.
•
On fiber-optic LAN ports, the no udld port command reverts
the LAN port configuration to the udld enable global
configuration command setting.
Disabling UDLD on Nonfiber-Optic LAN Interfaces
To disable UDLD on a nonfiber-optic LAN port., perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# no udld port [aggressive]
Disables UDLD on a nonfiber-optic LAN port.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-5
Chapter 1
UniDirectional Link Detection ( UDLD)
How to Configure UDLD
Disabling UDLD on Fiber-Optic LAN Interfaces
To disable UDLD on individual fiber-optic LAN ports, perform this task:
Command
Purpose
Router(config)# interface type slot/port
Selects the LAN port to configure.
Router(config-if)# udld port disable
Disables UDLD on a fiber-optic LAN port.
Note
The no form of this command, which
reverts to the udld enable global
configuration command setting, is only
supported on fiber-optic LAN ports.
Configuring the UDLD Probe Message Interval
To configure the time between UDLD probe messages on ports that are in advertisement mode and are
currently determined to be bidirectional, perform this task:
Command
Purpose
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.
Configuring Fast UDLD
Release 15.0(1)SY1 and later releases support fast UDLD. These sections describe how to configure fast
UDLD:
Note
•
Configuring Fast UDLD on a Port, page 1-7
•
Enabling Fast UDLD Error Reporting, page 1-7
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-6
Chapter 1
UniDirectional Link Detection ( UDLD)
How to Configure UDLD
Configuring Fast UDLD on a Port
To configure fast UDLD on a port, perform this task:
Step 1
Command
Purpose
Router(config-if)# udld fast-hello interval
Configures the fast UDLD probe message interval on a port.
•
See the guidelines and restrictions in the “Fast UDLD”
section on page 1-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
Step 3
Displays fast UDLD configuration and operational state.
Router# show udld fast-hello
Router# show udld fast-hello type
1.
1
slot/number
Verifies the per-port fast UDLD configuration and
operational state.
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-7
Chapter 1
UniDirectional Link Detection ( UDLD)
How to Configure 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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-8
CH AP TE R
2
Instant Access (IA)
Note
•
Prerequisites for Instant Access, page 2-1
•
Restrictions for Instant Access, page 2-2
•
Information About Instant Access, page 2-6
•
Default Settings for Instant Access, page 2-6
•
How to Configure Instant Access, page 2-7
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
Prerequisites for Instant Access
•
An IA parent—A VSS-mode Catalyst 6800 switch or a VSS-mode Catalyst 6500 switch equipped
with a Supervisor Engine 2T and one or more WS-X6904-40G-2T switching modules, configured
to support 10GE links.
•
IA clients—Catalyst 6800ia access switches
See this publication for more information:
http://www.cisco.com/en/US/prod/collateral/switches/ps10902/ps715/ps13198/data_sheet_c78-72
8230.html
•
See this publication for more information about Instant Access:
http://www.cisco.com/en/US/prod/collateral/switches/ps10902/ps715/ps13198/white_paper_c11-7
28265.html
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-1
Chapter 2
Instant Access (IA)
Restrictions for Instant Access
•
For image download during ISSU upgrade, remove ip tftp source-interface config on IA Parent,
and add a static route to copy image through mgmt intf.
Restrictions for Instant Access
•
The IA parent must operate in VSS mode.
Note
•
• You can enable VSS mode on a single chassis to support IA clients.
• The VSS Quad-Sup SSO (VS4O) feature is supported with IA clients from Release
15.1(2)SY2.
The IA parent-client connection is supported on links between WS-X6904-40G-2T switching
module 10GE ports and Catalyst 6800ia access switch 10GE ports.
– You can use up to 6 IA client 10GE ports in the IA parent-client link. See this document for
information about WS-X6904-40G-2T switching module port configuration:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-696669
.html
– IA client 10-Gigabit Ethernet ports require no configuration.
– UDLD, LLDP, and CDP are not supported on the A parent-client link.
– Instant Access does not use STP on the IA parent-client connection.
– Use only XL based modules for scale FEX QoS configuration to prevent issues with TCAM
(ternary content-addressable memory) utilization. When QoS policy is configured on 1500 FEX
host ports, the first 511 interfaces share the TCAM utilization. But, remaining ports will start
using new TCAM entries for each interface and will exhaust non-XL TCAM utilization.
•
IA client maximum values:
•
IA client ports do not support these features:
Value Description:
Maximum Value
Maximum IA client ports
1008 ports across 21 Catalyst 6800ia access switches
Maximum IA client stacks
12 (defined by IA client FEX number 1–12 range.)
Maximum Catalyst 6800ia access switches 3
per IA client stack
•
An IA client stack acts as single switch unit.
•
Instant access only supports connection with stacking
cables to form a stack.
•
With an IA client that has multiple Catalyst 6800ia
access switches, the switches in the stack assign
incrementing switch numbers to themselves
(automatic stacking capability).
•
If you add Catalyst 6800ia access switches to a
configured IA client, the additional switches assign
incrementing switch numbers to themselves.
•
The IA client configuration does not persist if the
access switch number changes.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-2
Chapter 2
Instant Access (IA)
Restrictions for Instant Access
Value Description:
Maximum Value
Maximum number of VLANs
per IA client stack
You can set upto 1,000 VLANs, we recommend to set not
more than 20 VLANs per FEX.
Maximum Number of Port Channels
512
– Configuring EtherChannels with combination of FEX Ports from different FEX-IDs or
combination of FEX ports with IA parent switch linecard ports is not supported. However, FEX
host port channel from the same FEX is supported.
– FEX host port EtherChannel load balancing is not supported.
– Port debounce timer
– UDLR tunnel ARP and IGMP proxy
– Uni-Directional Link Routing (UDLR)
– IEEE 802.1Q tunneling
– VLAN Mapping
– VLAN Translation
– IEEE 802.1Q custom ethertypes
– L2PT - Layer 2 protocol tunneling
– L2PT - Layer 2 protocol tunneling on trunk ports
– 802.1ad tunnelling
– Port security on 802.1Q tunnel ports
– Private VLANs (PVLAN)
– VACL capture
– Per-VLAN load balancing for Advanced QinQ service mapping
– Cisco TrustSec NDAC (Network Device Admission Control)
– Cisco TrustSec security association protocol (SAP) for MACSec encryption
– Cisco TrustSec confidentiality and integrity with MACsec (IEEE 802.1AE)
– Cisco TrustSec identity port mapping
– Network edge authentication topology (NEAT)
– AutoQoS
– MQC queuing policy support
– Priority queueing (PQ)
– QoS aggregated DSCP values for WRED
– QoS aggregated precedence values for WRED
– Class based weighted fair queuing (CBWFQ)
– Class-based shaping
– DiffServ-compliant dWRED
– Diffserv-compliant WRED
– Selective packet discard (SPD)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-3
Chapter 2
Instant Access (IA)
Restrictions for Instant Access
– Strict priority low latency queueing (LLQ)
– Weighted fair queueing (WFQ)
– Weighted RED (WRED)
– QoS policer rate increase to 256G
– Ethernet over MPLS (EoMPLS) - IEEE 802.1q Tag Stacking
– H-VPLS N-PE redundancy for QinQ access
– Connectivity fault management (CFM)
– Ethernet connectivity fault management (E-CFM)
– Ethernet local management interface (LMI) at provider edge (PE)
– Ethernet operations, administration, and Maintenance (OAM)
– Ethernet-OAM 3.0: CFM over BD, Untagged
– IEEE 802.1ag - D8.1 standard Compliant CFM, Y.1731 multicast LBM / AIS / RDI / LCK, IP
SLA for Ethernet
– IEEE 802.1ag Compliant CFM (D8.1)
•
To use an IA client port as a SPAN destination, add the IA client port VLAN to the SPAN allowed
VLAN list with the switchport trunk allowed vlan command.
•
When FEX IA parent-client link portchannel is configured as SPAN source in Tx direction or both
directions, the SPAN destination should not be on the same FEX. This is applicable for both stacked
and standalone FEX.
•
To enable formation of ISIS adjacencies on IA client ports, configure an explicit connectionless
network service (CLNS) MTU size on the IA client and peer ports. The maximum MTU value that
can be configured for CLNS is 9216. The CLNS MTU size should be the same on both sides of the
ISIS link.
This example shows how to configure the default MTU size on an IA client port:
Router# configure terminal
Router(config)# interface interface Gig118/1/0/1
Router(config-if)# ip router isis
Router(config-if)# clns mtu 1497
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-4
Chapter 2
Instant Access (IA)
Restrictions for Instant Access
•
IA client port QoS:
– Configure ingress QoS on the IA parent port-channel interface.
– The egress QoS configuration on IA client ports is not configurable.
– Port architecture (Rx/Tx): 1p3q3t
1p3q3t strict-priority egress queue (queue 1)
CoS
Not supported
DSCP
32, 33, 40–47
Tail-drop
100% (nonconfigurable)
WRED-drop Not supported
1p3q3t standard egress queue 2
(high priority)
Threshold 1
CoS
Not supported
DSCP
16–23, 26–31, 34–39
Tail-drop
Disabled; 100%
WRED-drop Not supported
Thresholds 2
CoS
Not supported
DSCP
24
Tail-drop
Disabled; 100%
WRED-drop Not supported
Thresholds 3
CoS
Not supported
DSCP
48-63
Tail-drop
Disabled; 100%
WRED-drop Not supported
1p3q3t standard egress queue 3
(medium priority)
Threshold 1
CoS
Not supported
DSCP
25
Tail-drop
Disabled; 70%
WRED-drop Not supported
Threshold 2
CoS
Not supported
DSCP
None.
Tail-drop
Disabled; 100%
WRED-drop Not supported
Thresholds 3
CoS
Not supported
DSCP
0–7
Tail-drop
Disabled; 100%
WRED-drop Not supported
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-5
Chapter 2
Instant Access (IA)
Information About Instant Access
1p3q3t standard egress queue 4
(lowest priority)
Threshold 1
CoS
Not supported
DSCP
8, 9, 11, 13, 15
Tail-drop
Disabled; 70%
WRED-drop Not supported
Threshold 2
CoS
Not supported
DSCP
10, 12, 14
Tail-drop
Disabled; 100%
WRED-drop Not supported
Threshold 3
CoS
Not supported
DSCP
None.
Tail-drop
Disabled; 100%
WRED-drop Not supported
Information About Instant Access
The Instant Access (IA) feature supports multiple Catalyst 6800ia access switches that function as
clients of the IA parent switch. The IA parent and client switches form a single extended switch with a
single management domain, managed by the IA parent.
The IA parent uses the Satellite Discovery Protocol (SDP) and the Satellite Registration Protocol (SRP)
to automatically discover IA clients when they connect and monitor the IA client-parent link. The
IA parent upgrades the IA client software image if it is not the same as the parent.
The IA parent features are applied to IA client traffic. The IA clients do not perform any local packet
forwarding. All traffic originating from IA client ports are sent to the IA parent, which makes all the
switching and forwarding decisions.
These online diagnostic tests support Instant Access clients:
•
TestFexModeLoopback, page 1-4
•
TestFexFabricLinkStatus, page 1-39
Default Settings for Instant Access
By default, these configurations are present on each interface:
switchport
switchport trunk allowed vlan 1
switchport mode dynamic auto
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-6
Chapter 2
Instant Access (IA)
How to Configure Instant Access
How to Configure Instant Access
•
Configure Instant Access Staggered Initialization Mode, page 2-7
•
Enable IA Client Preprovisioning, page 2-7
•
Configure Instant Access Port-Channel Interfaces, page 2-8
•
Configure Instant Access Channel Groups, page 2-8
•
Identify Connected IA Client Stack Modules, page 2-9
•
Renumbering FEX Switch-ID, page 2-10
•
Configure IA Clients, page 2-12
•
Display or Clear SDP and SRP Traffic, page 2-13
•
Configure Optional Parameters for an IA Client, page 2-13
Configure Instant Access Staggered Initialization Mode
Instant Access staggered initialization mode avoids any excessively high CPU utilization that might
occur if multiple IA clients attempt to initialize simultaneously. To configure Instant Access staggered
initialization mode, perform this task:
Command
Purpose
Router(config)# fex stagger delay_value
Configures Instant Access staggered initialization
mode. The delay_value can be 0 through 500.
Note
The recommended delay_value is 120.
This example shows how to configure Instant Access staggered mode:
Router# configure terminal
Router(config)# fex stagger 120
Enable IA Client Preprovisioning
To allow IA client port configuration before the IA client is connected, perform this task:
Command
Purpose
Router# module provision create fex fex_number
type {C6800IA-48FPD | C6800IA-48TD | C6800IA-48FPDR}
[slot switch_number]
Enables IA client port configuration before the IA client is
connected. Enter the slot switch_number keyword and
argument to enable configuration of a specific
IA client stack member or an additional stack member
before it is added to the IA client stack.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-7
Chapter 2
Instant Access (IA)
How to Configure Instant Access
Configure Instant Access Port-Channel Interfaces
To create a port channel interface to support IA clients, perform this task:
Command
Purpose
Step 1 Router(config)# interface port-channel group_number Creates the port channel interface. There can be up to a
maximum of 512 port-channel interfaces
(12 port-channel interfaces can be used to support IA
clients).
If desired, you can configure the group_number
to match the IA client FEX number.
Note
Step 2 Router(config-if)# switchport
Configures the port channel interface for Layer 2 switching.
Step 3 Router(config-if)# switchport mode fex-fabric
Configures the port channel interface to support IA clients.
Step 4 Router(config-if)# fex associate fex_number
Configures the IA client FEX number.
•
The valid value range is 101–199.
•
Maximum of 12 IA client FEX numbers.
This example shows how to create port channel interface 1 and configure it to support
IA FEX number 118:
Router# configure terminal
Router(config)# interface port-channel 118
Router(config-if)# switchport
Router(config-if)# switchport mode fex-fabric
Router(config-if)# fex associate 118
Configure Instant Access Channel Groups
To configure channel groups to support IA clients, perform this task for the 10 Gigabit Ethernet LAN
ports that connect to IA clients:
Command
Purpose
Step 1
Router(config)# interface range first_10ge_port, last_10ge_port
Selects the ports to configure.
Step 2
Router(config-if)# switchport
Configures the port channel interface for
Layer 2 switching.
Step 3
Router(config-if)# switchport mode fex-fabric
Configures the port channel interface to
support IA clients.
Step 4
Router(config-if)# channel-group group_number mode on
Configures the LAN port in an IA Client
port channel and configures the mode
as on.
Note
More links can be added to the channel group at any time.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-8
Chapter 2
Instant Access (IA)
How to Configure Instant Access
This example shows how to configure 10 Gigabit Ethernet ports 1/2/5 and 2/2/5 into port channel 118
with mode on:
Router# configure terminal
Router(config)# interface range tengigabitethernet 1/2/5, 2/2/5
Router(config-if)# switchport
Router(config-if)# switchport mode fex-fabric
Router(config-if)# channel-group 118 mode on
Router(config-if)# end
This example shows how to verify the IA configuration when the IA client is connected:
Router# show fex 118 detail
FEX: 118 Description: FEX0118 state: online
FEX version: version_string
Extender Model: C6800IA-48TD, Extender Serial: serial_number
FCP ready: yes
Image Version Check: enforced
Fabric Portchannel Ports: 2
Fabric port for control traffic: Te1/2/5
Fabric interface state:
Po20 - Interface Up.
Te1/2/5 - Interface Up. state: bound
Te2/2/5 - Interface Up. state: bound
Identify Connected IA Client Stack Modules
•
Identify IA Client Stack Modules by Serial Number, page 2-9
•
Identify IA Client Modules by Beacon LED, page 2-9
Identify IA Client Stack Modules by Serial Number
This example shows how to identify IA client stack modules by serial number:
Router# show interface fex
Fabric
Fabric Port FEX
FEX
FEX Port
State
Uplink
Model
Serial
--------------------------------------------------------------------101 Te1/2/5
bound
Te1/0/1
C6800IA-48FPD
FHH1707P00S
101 Te1/2/13 bound
Te2/0/1
C6800IA-48FPD
FHH1707P00S
101 Te2/2/5
bound
Te1/0/2
C6800IA-48FPD
FHH1707P00S
101 Te2/2/13 bound
Te2/0/2
C6800IA-48FPD
FHH1707P00S
102 Te1/2/6
bound
Te1/0/2
C6800IA-48TD
FOC1709Z2V9
102 Te2/2/17 bound
Te2/0/2
C6800IA-48TD
FOC1709Z2V9
Identify IA Client Modules by Beacon LED
Router(config)# hw-module fex <> slot <> led beacon
This example shows how to activate the beacon LED on IA client 118, slot 1:
Router(config)# hw-module fex 118 slot 1 led beacon
This example shows how to verify the beacon LED on IA client 118, slot 1:
Router(config)# show hw-module fex led beacon
C6K FEX BLUE BEACON CONFIG
---------------------------------hw-module fex 118 slot 1 led beacon
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-9
Chapter 2
Instant Access (IA)
How to Configure Instant Access
Renumbering FEX Switch-ID
The renumbering of IA clients can be managed using switch-id allocation from controller, after stack
boot up. Also, a priority can be assigned to the FEX members to take over as the master switch.
The following conditions must exist for successful execution of FEX switch-id allocation:
– For renumbering, the source slot should be online and the target slot should be offline.
– If the source slot FEX type is different than target slot FEX type, the interface configurations
will be lost if you proceed with renumbering.
– Same target slot cannot be used for renumbering multiple source slots.
– Same source slot cannot be renumbered to multiple target slot.
– You can enter multiple renumbering entries along with different swapping scenarios.
– When priority is modified for a member IA, the whole stack will reload.
– During In Service Software Upgrade (ISSU) process, switch-id renumbering or priority changes
are not allowed.
To renumber FEX switch-id and assign priority, perform this task:
Command
Purpose
Step 1 Switch# module provision update fex fex_id
Enters into switch renumber sub-mode.
Step 2 Switch(exec-fex-update)# renumber source_slot to
Renumbers source_slot to target_slot
target_slot
Step 3 Switch(exec-fex-update)# priority source_slot value
number
Step 4 Switch(exec-fex-update)# commit
Note
Assigns the mentioned priority number to the
source_slot.
Commits all entries entered under exec-fex-update
sub-mode.
After the commit operation, you will be prompted whether you want to release the old source-vslot or
not. This confirmation will not be asked only in a switch-id swap scenario (for example, renumber 1 to
2 and renumber 2 to 1) because both renumbering are done in a single commit operation.
To renumber FEX switch-id when scale is set to maximum FEX slots, perform this task:
Command
Step 1 Switch# module provision update fex fex_id
temp-vslot-allow enable
Purpose
When maximum vslots are already allocated,
temp-vslot-allow will enable the temporary vslot module
to come online.
Step 2 Switch# module provision update fex fex_id
Enters into switch renumber sub-mode.
Step 3 Switch(exec-fex-update)# renumber source_slot to
target_slot
Renumbers source_slot to target_slot
Step 4 Switch(exec-fex-update)# priority source_slot value
Assigns the mentioned priority number to the
source_slot.
number
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-10
Chapter 2
Instant Access (IA)
How to Configure Instant Access
Command
Purpose
Step 5 Switch(exec-fex-update)# commit
Commits all entries entered under exec-fex-update
sub-mode.
Step 6 Switch# module provision update fex fex_id
Disables the temporary vslot module to go offline.
temp-vslot-allow disable
Note
After the commit operation, you will be prompted whether you want to release the old source-vslot or
not. This confirmation will not be asked only in a switch-id swap scenario (for example, renumber 1 to
2 and renumber 2 to 1) because both renumbering are done in a single commit operation.
Example: Renumbering FEX switch-id and setting priority
Switch# module provision update fex 101
Switch(exec-fex-update) renumber 3 to 4
Switch(exec-fex-update) priority 2 value 1
%FEX 101 will reload upon commit.
Are you sure you want to proceed? [no]: yes
Switch(exec-fex-update)#commit
%Do you want to release FEX 101 module 3 source interface configs(vslot) after module
offline? [no]: yes
%FEX 101 All modules will reload.
Are you sure you want to proceed? [no]: yes
Example: Identifying if temporary vslot is online
This example shows how to identify when a particular temporary FEX vslot is online:
Switch# show fex system platform usage
FEX id usage details
Fex-ids inuse: 150
Fex-ids online: 150
Total
Used
Free
----------42
1
41
FEX slot usage details
FEX-id
Switch-id
Vslot
Pslot
Status
--------------------------150
3
51
2
In-use
150
3
52
3
In-use
150
3
53
5
Reserved
150
3
55
4
In-use
150
3
92
1
Temp-In-use
Total
Used
Reserved Temp-Use/Free Free
--------------- ------------- ---47
3
1
1/4
42
Current Temp vslot allowed FEXs: 150
Current Temp VSLOT usage:
-----------------------FEX 150 module 1
FEX ports usage details
FEX-id
Switch-id
Ports
-----------------150
3
192
Total
Used
Free
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-11
Chapter 2
Instant Access (IA)
How to Configure Instant Access
----2016
---192
---1824
Stack members usage details
FEX-id
Switch-id
Used
Free
Example: Identifying FEX IDs where temp-vslot-allow command is enabled
This example verifies the active entries under sub-mode and also the FEX IDs on which
"temp-vslot-allow" is enabled.
Switch(exec-fex-update)#show
Current module renumber mappings for FEX 101
-------------------------------------------renumber 1 to 2
Current module Priority mappings for FEX 101
-------------------------------------------priority 1 value 15
Temp vslots allowed:YES
Current Temp vslot allowed FEXs:101
Switch(exec-fex-update)#
Configure IA Clients
The configuration for IA clients can be entered on the IA parent before or after the IA clients are
connected. IA client 10-Gigabit Ethernet ports require no configuration. IA client Gigabit Ethernet ports
use this format:
gigabitethernet/fex_number/access_switch_number/0/port_number
– fex_number—The IA client FEX number:
—Maximum of 12 IA FEX numbers.
—The valid value range is 101–199.
– access_switch_number—The access switch number:
—The valid values are 1, 2, or 3.
—Multiple-switch stacks assign incrementing switch numbers to themselves.
—See the “Identify Connected IA Client Stack Modules” section on page 2-9.
– The third interface parameter is always zero.
– The port_number valid value range is 1–48.
Note
•
IA client configuration does not persist if the access switch number changes.
•
The interface-range configuration mode supports IA clients ports (see “How to Configure a Range
of Interfaces” section on page 10-2)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-12
Chapter 2
Instant Access (IA)
How to Configure Instant Access
Display or Clear SDP and SRP Traffic
To display the counters that record the SDP packet traffic on IA client 118, enter the following command:
Router#
130
129
130
129
Note
show fex
SDP pkts
SDP pkts
SDP pkts
SDP pkts
118 protocol | incl SDP
sent
received
sent
received
The command displays a sent and received value for each link in the IA channel group.
To clear the protocol counters, enter the clear fex fex_number {sdp | srp} command.
Configure Optional Parameters for an IA Client
•
Enter the IA Client Configuration Mode, page 2-13
•
Configure a Description, page 2-13
•
Configure the Custom Location Type Feature, page 2-13
•
Configure MTU, page 2-14
Enter the IA Client Configuration Mode
To enter the IA client configuration mode, perform this task:
Command
Router(config)# fex
Router(config-fex)#
Purpose
fex_number
Enters IA client configuration mode.
Note
Sets the IA client description to FEX0fex_number.
Configure a Description
To configure a description for the IA client or for each module in the IA client stack, perform this task:
Command
Purpose
Router(config-fex)# [module module_number] description description_string
Configures a description for the IA
FEX number or for a module in the
IA client stack.
Configure the Custom Location Type Feature
You can configure the custom location type feature for the IA client in IA client configuration mode. See
these publications for information about the location command:
http://www.cisco.com/en/US/docs/ios-xml/ios/cether/command/ce-cr-book.html
http://www.cisco.com/en/US/docs/ios-xml/ios/cether/command/ce-e1.html
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-13
Chapter 2
Instant Access (IA)
How to Configure Instant Access
Note
The location commands support the optional fex-location keyword for IA clients.
Configure MTU
You can configure MTU on the IA FEX using the mtu command in fex config mode. In an IA client
stack, the configured MTU value is applied to all the host members in the stack.
To configure MTU for an IA client, perform this task:
Command
Purpose
Router# configure terminal
Enters the global configuration mode.
Router(config)# fex 110
Enters IA client configuration mode.
Router(config-fex)# mtu 2000
Resets the MTU value for the FEX system. All
the FEX ports will be set to use the new MTU
value.
The default MTU value for a FEX host port is
9216.
Note
For Cisco Catalyst C6840 series switch,
the maximum supported MTU for native
interface is 9154.The default MTU
value is 1500. If the MTU of peer
(Catalyst 6880 or Sup2T) is configured
higher than 9154, the packet will not be
processed. When using existing
configuration from a Catalyst 6880 or
Sup2T, ensure that the MTU is reset or
removed.
Exits the global configuration mode.
Router# end
Note
Reload the FEX for the MTU change to
take effect.
If you want to avoid reloading the FEX, you can configure an explicit connectionless network service
(CLNS) MTU size on the IA client and peer ports as shown in the following example:
Router# configure terminal
Router(config)# interface interface Gig118/1/0/1
Router(config-if)# ip router isis
Router(config-if)# clns mtu 1497
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-14
CH AP TE R
3
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 Phase 2 introduced on Catalyst 6500 Series switches
15.0(1)SY1
EnergyWise Phase 2.6 introduced on Catalyst 6500 Series switches
15.1(1)SY1
EnergyWise Phase 2.7 introduced on Catalyst 6500 Series switches
For hardware compatibility matrices, new feature information, and to understand EnergyWise release
numbering, see the Cisco EnergyWise release notes:
http://www.cisco.com/en/US/products/ps10195/prod_release_notes_list.html
EnergyWise configuration guides and 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
Additional Cisco EnergyWise documents, such as White Papers, Data Sheets, FAQs, and are located at
the following URL:
http://www.cisco.com/en/US/products/ps10195/
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-1
Chapter 3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-2
Configuring EnergyWise
CH AP TE R
4
Power Management
Note
•
Power Management Overview, page 4-1
•
How to Enable or Disable Power Redundancy, page 4-2
•
How to Power Modules Off and On, page 4-3
•
How to Display System Power Status, page 4-4
•
How to Power Cycle Modules, page 4-5
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Power Management Overview
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-1
Chapter 4
Power Management
How to Enable or Disable Power Redundancy
How to Enable or Disable 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 “How to Display System Power Status” section on page 4-4).
Table 4-1 describes how the system responds to changes in the power supply configuration.
Table 4-1
Effects of Power Supply Configuration Changes
Configuration Change
Redundant to nonredundant
Nonredundant to redundant (both
power supplies must be of equal
wattage)
Equal wattage power supply is
inserted with redundancy enabled
Equal wattage power supply is
inserted with redundancy disabled
Higher or lower wattage power
supply is inserted with redundancy
enabled
Effect
•
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.
•
System log and syslog messages are generated.
•
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 log and syslog messages are generated.
•
System power equals the power capability of one supply.
•
No change in module status because the power capability is unchanged.
•
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.
•
System log and syslog messages are generated.
•
If the system power used is more than 83% of the higher wattage power supply
capacity, the lower wattage power supply shuts down. The system will operate in
redundant mode, with only the higher wattage power supply.
•
If the system power used is less than 83% of the higher wattage power supply
capacity, the lower wattage power supply comes online. The system will operate in
non-redundant combined mode, with both the power supplies.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-2
Chapter 4
Power Management
How to Power Modules Off and On
Table 4-1
Effects of Power Supply Configuration Changes (continued)
Configuration Change
Effect
Higher or lower wattage power
supply is inserted with redundancy
disabled
•
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.
Power supply is removed with
redundancy enabled
•
System log and syslog messages are generated.
•
No change in module status because the power capability is unchanged.
Power supply is removed with
redundancy disabled
•
System log and syslog messages are generated.
•
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 log and syslog messages are generated.
•
If the system power used is more than 83% of the higher wattage power supply
capacity, the lower wattage power supply shuts down. The system will operate in
redundant mode, with only the higher wattage power supply.
•
If the system power used is less than 83% of the higher wattage power supply
capacity, the lower wattage power supply comes online. The system will operate in
non-redundant combined mode, with both the power supplies.
•
System log and syslog messages are generated.
•
System power equals the combined power capability of both power supplies.
•
The system powers up as many modules as the combined capacity allows.
System is booted with power
supplies of different wattage
installed and redundancy enabled
System is booted with power
supplies of equal or different
wattage installed and redundancy
disabled
How to Power 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.
Note
When you enter the no power enable module slot command to power down a module, the module’s
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-3
Chapter 4
Power Management
How to Display System Power Status
How to Display System Power Status
The show power command displays the current power status of system components:
Router# show
system power
system power
system power
system power
system power
power
redundancy mode = redundant
redundancy operationally = non-redundant
total =
3795.12 Watts (90.36 Amps @ 42V)
used =
864.78 Watts (20.59 Amps @ 42V)
available = 2930.34 Watts (69.77 Amps @ 42V)
Power-Capacity PS-Fan Output Oper
PS
Type
Watts
A @42V Status Status State
---- ------------------ ------- ------ ------ ------ ----1
none
2
WS-CAC-4000W-US
3795.12 90.36 OK
OK
on
Pwr-Allocated Oper
Fan Type
Watts
A @42V State
---- ------------------ ------- ------ ----1
WS-C6506-E-FAN
140.70 3.35 OK
Pwr-Requested Pwr-Allocated Admin Oper
Slot Card-Type
Watts
A @42V Watts
A @42V State State
---- ------------------ ------- ------ ------- ------ ----- ----5
(Redundant Sup)
362.04 8.62 6
VS-SUP2T-10G
362.04 8.62
362.04 8.62 on
on
system auxiliary power mode = off
system auxiliary power redundancy operationally = non-redundant
system primary connector power limit =
7266.00 Watts (173.00 Amps @ 42V)
system auxiliary connector power limit = 10500.00 Watts (250.00 Amps @ 42V)
system primary power used =
864.78 Watts (20.59 Amps @ 42V)
system auxiliary power used =
0 Watt
Router#
The show power command displays the current power status of a specific power supply:
Router# show power status power-supply
Power-Capacity PS-Fan Output Oper
PS
Type
Watts
A @42V
---- ------------------ ------- -----2
WS-CAC-4000W-US
3795.12 90.36
Router#
2
Status Status State
------ ------ ----OK
OK
on
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 environment status power-supply command as follows:
Router# show environment 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 environment status power-supply 2
power-supply 2:
power-supply 2 fan-fail: OK
power-supply 2 power-input 1: none
power-supply 2 power-input 2: AC low
power-supply 2 power-input 3: AC high
power-supply 2 power-output: low (mode 1)<<< high for highest mode only
power-supply 2 power-output-fail: OK
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-4
Chapter 4
Power Management
How to Power Cycle Modules
How to Power Cycle 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.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-5
Chapter 4
How to Power Cycle Modules
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
4-6
Power Management
CH AP TE R
5
Environmental Monitoring
Note
•
Environmental Monitoring Overview, page 5-1
•
How to Determine Sensor Temperature Thresholds, page 5-2
•
How to Monitor the System Environmental Status, page 5-3
•
Information About LED Environmental Indications, page 5-4
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Environmental Monitoring 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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-1
Chapter 5
Environmental Monitoring
How to Determine Sensor Temperature Thresholds
How to Determine Sensor Temperature Thresholds
The system sensors set off alarms based on different temperature threshold settings. Use the show
environment alarm threshold command to display the 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
threshold #1 for EARL 1 outlet temperature:
(sensor value > 60) is system minor alarm
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-2
Chapter 5
Environmental Monitoring
How to Monitor the System Environmental Status
threshold
(sensor
threshold
(sensor
threshold
(sensor
#2 for EARL
value > 75)
#1 for EARL
value > 50)
#2 for EARL
value > 65)
1 outlet temperature:
is system major alarm EARL 1 inlet temperature: N/O
1 inlet temperature:
is system minor alarm
1 inlet temperature:
is system major alarm
How to Monitor the System Environmental Status
To display system status information, enter the show environment [alarm | cooling | status |
temperature] command. The keywords display the following information:
•
alarm—Displays environmental alarms.
– status—Displays alarm status.
– thresholds—Displays alarm thresholds.
•
cooling—Displays fan tray status, chassis cooling capacity, ambient temperature, and per-slot
cooling capacity.
•
status—Displays field-replaceable unit (FRU) operational status and power and temperature
information.
•
temperature—Displays 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 type: WS-C6513-E-FAN
fan-tray 1 mode: High-power
fan-tray 1 fan-fail: OK
chassis per slot cooling capacity: 94 cfm
ambient temperature: < 55C
module 3 cooling requirement: 84 cfm
module 7 cooling requirement: 35 cfm
Router# show environment status
backplane:
operating clock count: 2
operating VTT count: 3
operating fan count: 1
fan-tray 1:
fan-tray 1 type: WS-C6513-E-FAN
fan-tray 1 mode: High-power
fan-tray 1 fan-fail: OK
VTT 1:
VTT 1 OK: OK
VTT 1 outlet temperature: 30C
VTT 2:
VTT 2 OK: OK
VTT 2 outlet temperature: 28C
VTT 3:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-3
Chapter 5
Environmental Monitoring
Information About LED Environmental Indications
VTT 3 OK: OK
VTT 3 outlet temperature: 29C
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-input: AC low
power-supply 1 power-output-mode: low
power-supply 1 power-output-fail: OK
power-supply 2:
power-supply 2 fan-fail: OK
power-supply 2 power-input: AC low
power-supply 2 power-output-mode: low
power-supply 2 power-output-fail: OK
module 3:
module 3 power-output-fail: OK
module 3 outlet temperature: N/O
module 3 inlet temperature: N/O
module 3 asic-1 temperature: 72C
module 3 asic-2 temperature: 81C
module 3 EARL outlet temperature: 43C
module 3 EARL inlet temperature: 33C
module 7:
module 7 power-output-fail: OK
module 7 outlet temperature: 44C
module 7 inlet temperature: 27C
module 7 device-1 temperature: 39C
module 7 device-2 temperature: 41C
module 7 asic-1 temperature: 69C
module 7 asic-2 temperature: 68C
module 7 asic-3 temperature: 50C
module 7 asic-4 temperature: 72C
module 7 asic-5 temperature: 55C
module 7 asic-6 temperature: 60C
module 7 asic-7 temperature: 63C
module 7 asic-8 temperature: 59C
module 7 RP outlet temperature: 39C
module 7 RP inlet temperature: 34C
module 7 RP device-1 temperature: 42C
module 7 EARL outlet temperature: 42C
module 7 EARL inlet temperature: 30C
Router#
Information About LED Environmental Indications
The LEDs 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, giving you
notice of a problem that could turn critical if corrective action is not taken.
When the system has an alarm (major or minor), that indicates an overtemperature condition, the alarm
is not canceled nor is any action taken (such as module reset or shutdown) for 5 minutes. If the
temperature falls 5°C (41°F) below the alarm threshold during this period, the alarm is canceled.
Table 5-1 lists the environmental indicators for the supervisor engine and switching modules.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-4
Chapter 5
Environmental Monitoring
Information About LED Environmental Indications
Note
Table 5-1
See the Catalyst 6500 Series Switch Module Installation Guide for additional information on LEDs,
including the supervisor engine SYSTEM LED.
Environmental Monitoring for Supervisor Engine and Switching Modules
Component
Supervisor engine temperature
sensor exceeds major threshold
Alarm
Type
LED Indication
Action
Major
STATUS LED red
Generates syslog message and an SNMP trap.
If there is a redundancy situation, the system switches
to a redundant supervisor engine and the active
supervisor engine shuts down.
Note
•
Temperature sensors monitor key supervisor engine
components including daughter cards.
If there is no redundancy situation and the
• A STATUS LED is located on the supervisor engine front panel overtemperature condition is not corrected, the system
shuts down after 5 minutes.
and all module front panels.
•
The STATUS LED is red on the failed supervisor engine. If
there is no redundant supervisor, the SYSTEM LED is red also.
Supervisor engine temperature
sensor exceeds minor threshold
Minor
STATUS LED orange
Generates syslog message and an SNMP trap.
Monitors the condition.
Redundant supervisor engine
temperature sensor exceeds major Major
or minor threshold
Generates syslog message and an SNMP trap.
STATUS LED red
If a major alarm is generated and the overtemperature
condition is not corrected, the system shuts down after
5 minutes.
Minor
STATUS LED orange
Monitors the condition if a minor alarm is generated.
Switching module temperature
sensor exceeds major threshold
Major
STATUS LED red
Generates syslog message and SNMP.
Switching module temperature
sensor exceeds minor threshold
Minor
Tip
Powers down the module (see the “How to Power
Modules Off and On” section on page 4-3 for
instructions).
STATUS LED orange
Generates syslog message and an SNMP trap.
Monitors the condition.
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-5
Chapter 5
Information About LED Environmental Indications
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
5-6
Environmental Monitoring
CH AP TE R
6
Online Diagnostics
Note
•
Prerequisites for Online Diagnostics, page 6-1
•
Restrictions for Online Diagnostics, page 6-1
•
Information About Online Diagnostics, page 6-2
•
Default Settings for Online Diagnostics, page 6-2
•
How to Configure Online Diagnostics, page 6-2
•
How to Run Online Diagnostic Tests, page 6-6
•
How to Perform Memory Tests, page 6-24
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Online Diagnostics
None.
Restrictions for Online Diagnostics
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-1
Chapter 6
Online Diagnostics
Information About Online Diagnostics
Information About 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 user’s request (on-demand).
The online diagnostics detect problems in the following areas:
•
Hardware components
•
Interfaces (GBICs, Ethernet ports, and so forth)
•
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.
Default Settings for Online Diagnostics
See the default information for each test in Appendix 1, “Online Diagnostic Tests.”
How to Configure Online Diagnostics
•
Setting Bootup Online Diagnostics Level, page 6-2
•
Configuring On-Demand Online Diagnostics, page 6-3
•
Scheduling Online Diagnostics, page 6-5
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:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-2
Chapter 6
Online Diagnostics
How to Configure Online Diagnostics
Command
Purpose
Router(config)# diagnostic bootup level {minimal | complete}
Sets the bootup diagnostic level.
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)# show diagnostic bootup level
Current bootup diagnostic level: complete
Router(config)#
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-3
Chapter 6
Online Diagnostics
How to Configure Online Diagnostics
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.
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 iteration_count}
| {action-on-error {continue | stop} [error_count]}
Configures on-demand diagnostic tests to run, how many
times to run (iterations), and what action to take when errors
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#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-4
Chapter 6
Online Diagnostics
How to Configure Online Diagnostics
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
test {test_id | test_id_range | all} [port {num |
num_range | all}] {on mm dd yyyy hh:mm} | {daily
hh:mm} | {weekly day_of_week hh:mm}
Schedules on-demand diagnostic tests on the specified
module for a specific date and time, how many times to run
(iterations), and what action to take when errors are found.
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
number test {test_id | test_id_range | all} [hour
hh] [min mm] [second ss] [millisec ms] [day day]
Configures the health-monitoring interval of the specified
tests. The no form of this command will change the
interval to the default interval, or zero.
Step 2
Router(config)#[no] diagnostic monitor module
number test {test_id | test_id_range | all}
Enables or disables health-monitoring diagnostic tests.
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-5
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
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)#
How to Run Online Diagnostic Tests
•
Overview of Diagnostic Test Operation, page 6-6
•
Starting and Stopping Online Diagnostic Tests, page 6-6
•
Running All Online Diagnostic Tests, page 6-7
•
Displaying Online Diagnostic Tests and Test Results, page 6-8
Overview of Diagnostic Test Operation
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.
•
Enable the logging console/monitor to see all warning messages before you enable any online
diagnostics tests.
•
When you are running disruptive tests, 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
| test_id_range | minimal | complete | basic |
per-port | non-disruptive | all} [port {num |
port#_range | all}]
Starts a diagnostic test on a port or range of ports on the
specified module.
Router# diagnostic stop module number
Stops a diagnostic test on the specified module.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-6
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
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#
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.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-7
Chapter 6
Online Diagnostics
How to Run 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
To display the diagnostic tests that are configured, perform this task:
Command
Purpose
show diagnostic {bootup level | content [module num] |
events [module num] [event-type event-type] | health |
ondemand settings | result [module num] [detail] |
schedule [module num]}
Displays the test results of online diagnostics and lists
supported test suites.
This example shows how to display the online diagnostics that are configured on module 6:
Router# show diagnostic content module 6
Module 6: Supervisor Engine 2T 10GE w/ CTS (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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-8
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
ID
====
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
42)
43)
44)
45)
46)
47)
48)
49)
50)
Test Name
==================================
TestTransceiverIntegrity -------->
TestLoopback -------------------->
TestActiveToStandbyLoopback ----->
TestL2CTSLoopback --------------->
TestL3CTSLoopback --------------->
TestScratchRegister ------------->
TestNewIndexLearn --------------->
TestDontConditionalLearn -------->
TestBpduTrap -------------------->
TestMatchCapture ---------------->
TestProtocolMatchChannel -------->
TestMacNotification ------------->
TestPortSecurity ---------------->
TestIPv4FibShortcut ------------->
TestL3Capture2 ------------------>
TestIPv6FibShortcut ------------->
TestMPLSFibShortcut ------------->
TestNATFibShortcut -------------->
TestAclPermit ------------------->
TestAclDeny --------------------->
TestAclRedirect ----------------->
TestRBAcl ----------------------->
TestQos ------------------------->
TestDQUP ------------------------>
TestL3VlanMet ------------------->
TestIngressSpan ----------------->
TestEgressSpan ------------------>
TestNetflowShortcut ------------->
TestInbandEdit ------------------>
TestFabricInternalSnake --------->
TestFabricExternalSnake --------->
TestFabricVlanLoopback ---------->
TestTrafficStress --------------->
TestL3TcamMonitoring ------------>
TestFibTcam --------------------->
TestAclQosTcam ------------------>
TestEarlMemOnBootup ------------->
TestAsicMemory ------------------>
ScheduleSwitchover -------------->
TestFirmwareDiagStatus ---------->
TestAsicSync -------------------->
TestUnusedPortLoopback ---------->
TestNonDisruptiveLoopback ------->
TestFabricFlowControlStatus ----->
TestPortTxMonitoring ------------>
TestOBFL ------------------------>
TestCFRW ------------------------>
TestLtlFpoeMemoryConsistency ---->
TestErrorCounterMonitor --------->
TestEARLInternalTables ---------->
Attributes
============
**PD*X**I***
M*PD*X**I***
M*PDSX**I***
M*PD*X**I***
M*PD*X**I***
***N****A***
M**N****I***
M**N****I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**NS***A***
M**D*X**I***
M**N****I***
M**D*X**I***
M**N****I***
M**N****I***
M**N****I***
M**N****I***
M**D*X**I***
M**N****I***
M**N****I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**D*X**I***
M**N*X**I***
***D*X**I**T
***N****A***
***D*X**IR**
***D*X**IR**
M**N*X**I***
***D*X**IR**
***D*X**I***
M**N****I***
***N****A***
**PN****A***
**PN****A***
***N****I***
**PN****A***
M**N****I***
M*VN*X**I***
***N****A***
***N****A***
***N****A***
Test Interval
day hh:mm:ss.ms
===============
not configured
not configured
not configured
not configured
not configured
000 00:00:30.00
000 00:00:15.00
000 00:00:15.00
not configured
not configured
not configured
000 00:00:15.00
not configured
000 00:00:15.00
not configured
000 00:00:15.00
000 00:00:15.00
000 00:00:15.00
000 00:00:15.00
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
not configured
000 00:00:15.00
not configured
not configured
not configured
not configured
not configured
000 00:00:15.00
000 00:00:15.00
000 00:01:00.00
000 00:00:10.00
000 00:00:15.00
000 00:01:15.00
000 00:00:15.00
not configured
000 00:00:30.00
000 00:00:30.00
000 00:05:00.00
Threshold
=====
n/a
n/a
n/a
n/a
n/a
5
10
10
n/a
n/a
n/a
10
n/a
10
n/a
10
10
10
10
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
10
n/a
n/a
n/a
n/a
n/a
10
10
10
10
10
5
10
n/a
1
10
1
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-9
Chapter 6
How to Run Online Diagnostic Tests
This example shows how to display the online diagnostic results for module 6:
Router# show diagnostic result module 6
Current bootup diagnostic level: minimal
Module 6: Supervisor Engine 2T 10GE w/ CTS (Active)
Overall Diagnostic Result for Module 6 : PASS
Diagnostic level at card bootup: minimal
Test results: (. = Pass, F = Fail, U = Untested)
1) TestTransceiverIntegrity:
Port 1 2 3 4 5
------------------U U U U U
2) TestLoopback:
Port 1 2 3 4 5
------------------. . . . .
3) TestActiveToStandbyLoopback:
Port 1 2 3 4 5
------------------U U U U U
4) TestL2CTSLoopback:
Port 1 2 3 4 5
------------------. . . . .
5) TestL3CTSLoopback:
Port 1 2 3 4 5
------------------. . . . .
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
TestScratchRegister ------------->
TestNewIndexLearn --------------->
TestDontConditionalLearn -------->
TestBpduTrap -------------------->
TestMatchCapture ---------------->
TestProtocolMatchChannel -------->
TestMacNotification ------------->
TestPortSecurity ---------------->
TestIPv4FibShortcut ------------->
TestL3Capture2 ------------------>
TestIPv6FibShortcut ------------->
TestMPLSFibShortcut ------------->
TestNATFibShortcut -------------->
TestAclPermit ------------------->
TestAclDeny --------------------->
TestAclRedirect ----------------->
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-10
.
.
.
.
.
.
U
.
.
.
.
.
.
.
.
.
SerialNo : SAD132602A6
Online Diagnostics
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
42)
TestRBAcl ----------------------->
TestQos ------------------------->
TestDQUP ------------------------>
TestL3VlanMet ------------------->
TestIngressSpan ----------------->
TestEgressSpan ------------------>
TestNetflowShortcut ------------->
TestInbandEdit ------------------>
TestFabricInternalSnake --------->
TestFabricExternalSnake --------->
TestFabricVlanLoopback ---------->
TestTrafficStress --------------->
TestL3TcamMonitoring ------------>
TestFibTcam --------------------->
TestAclQosTcam ------------------>
TestEarlMemOnBootup ------------->
TestAsicMemory ------------------>
ScheduleSwitchover -------------->
TestFirmwareDiagStatus ---------->
TestAsicSync -------------------->
TestUnusedPortLoopback:
.
.
.
.
.
.
.
.
.
.
.
U
.
U
U
.
U
U
.
.
Port 1 2 3 4 5
------------------U U U . .
43) TestNonDisruptiveLoopback:
Port 1 2 3 4 5
------------------U U U U U
44) TestFabricFlowControlStatus -----> U
45) TestPortTxMonitoring:
Port 1 2 3 4 5
------------------U U U U U
46) TestOBFL ------------------------> .
47) TestCFRW:
Device 1
--------.
48) TestLtlFpoeMemoryConsistency ----> .
49) TestErrorCounterMonitor ---------> .
50) TestEARLInternalTables ----------> .
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-11
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
This example shows how to display the detailed online diagnostic results for module 6:
Router# show diagnostic result module 6 detail
Current bootup diagnostic level: minimal
Module 6: Supervisor Engine 2T 10GE w/ CTS (Active)
SerialNo : SAD132602A6
Overall Diagnostic Result for Module 6 : PASS
Diagnostic level at card bootup: minimal
Test results: (. = Pass, F = Fail, U = Untested)
___________________________________________________________________________
1) TestTransceiverIntegrity:
Port 1 2 3 4 5
------------------U U U U U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
2) TestLoopback:
Port 1 2 3 4 5
------------------. . . . .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:25
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:25
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
3) TestActiveToStandbyLoopback:
Port 1 2 3 4 5
------------------U U U U U
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-12
3 (DIAG_SKIPPED)
0
n/a
n/a
n/a
n/a
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test pass time ---------> n/a
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
4) TestL2CTSLoopback:
Port 1 2 3 4 5
------------------. . . . .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:29
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:29
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
5) TestL3CTSLoopback:
Port 1 2 3 4 5
------------------. . . . .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:33
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:33
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
6) TestScratchRegister -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 8191
Last test testing type ------> Health Monitoring
Last test execution time ----> May 16 2011 21:42:41
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 16 2011 21:42:41
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
7) TestNewIndexLearn ---------------> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
Last test pass time --------->
Total failure count --------->
0 (DIAG_SUCCESS)
1
Bootup
May 13 2011 21:59:37
n/a
n/a
May 13 2011 21:59:37
0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-13
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Consecutive failure count ---> 0
___________________________________________________________________________
8) TestDontConditionalLearn --------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:37
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:37
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
9) TestBpduTrap --------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:37
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:37
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
10) TestMatchCapture ----------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:37
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:37
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
11) TestProtocolMatchChannel --------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:39
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:39
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
12) TestMacNotification -------------> U
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
Last test pass time --------->
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-14
3 (DIAG_SKIPPED)
0
n/a
n/a
n/a
n/a
n/a
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
13) TestPortSecurity ----------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:41
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:41
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
14) TestIPv4FibShortcut -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
15) TestL3Capture2 ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
16) TestIPv6FibShortcut -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
17) TestMPLSFibShortcut -------------> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
0 (DIAG_SUCCESS)
1
Bootup
May 13 2011 21:59:42
n/a
n/a
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-15
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
18) TestNATFibShortcut --------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
19) TestAclPermit -------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
20) TestAclDeny ---------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
21) TestAclRedirect -----------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
22) TestRBAcl -----------------------> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-16
0 (DIAG_SUCCESS)
1
Bootup
May 13 2011 21:59:42
n/a
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
23) TestQos -------------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
24) TestDQUP ------------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
25) TestL3VlanMet -------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
26) TestIngressSpan -----------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
27) TestEgressSpan ------------------> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
0 (DIAG_SUCCESS)
1
Bootup
May 13 2011 21:59:43
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-17
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
28) TestNetflowShortcut -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:43
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
29) TestInbandEdit ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:43
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
30) TestFabricInternalSnake ---------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:43
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
31) TestFabricExternalSnake ---------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:43
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
32) TestFabricVlanLoopback ----------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-18
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test execution time ----> May 13 2011 21:59:43
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:43
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
33) TestTrafficStress ---------------> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
34) TestL3TcamMonitoring ------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 16382
Last test testing type ------> Health Monitoring
Last test execution time ----> May 16 2011 21:42:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 16 2011 21:42:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
35) TestFibTcam ---------------------> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
36) TestAclQosTcam ------------------> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
37) TestEarlMemOnBootup -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-19
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:44
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:44
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
38) TestAsicMemory ------------------> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
39) ScheduleSwitchover --------------> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
40) TestFirmwareDiagStatus ----------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:44
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:44
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
41) TestAsicSync --------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 16382
Last test testing type ------> Health Monitoring
Last test execution time ----> May 16 2011 21:42:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 16 2011 21:42:42
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
42) TestUnusedPortLoopback:
Port
1
2
3
4
5
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-20
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
------------------U U U . .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 4261
Last test testing type ------> Health Monitoring
Last test execution time ----> May 16 2011 21:41:53
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 16 2011 21:41:53
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
43) TestNonDisruptiveLoopback:
Port 1 2 3 4 5
------------------U U U U U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
___________________________________________________________________________
44) TestFabricFlowControlStatus -----> U
Error code ------------------> 3 (DIAG_SKIPPED)
Total run count -------------> 0
Last test testing type ------> n/a
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
Current run count --------------->: 0
First test execution time ------->:
Last test execution time -------->:
Total FPOE Rate0 Count ---------->: 0
Total FPOE Reduced Rate Count --->: 0
___________________________________________________________________________
45) TestPortTxMonitoring:
Port 1 2 3 4 5
------------------U U U U U
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
0 (DIAG_SUCCESS)
3419
Health Monitoring
May 16 2011 21:42:25
n/a
n/a
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-21
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
Last test pass time ---------> May 16 2011 21:42:25
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
46) TestOBFL ------------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:44
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:44
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
47) TestCFRW:
Device 1
--------.
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 1
Last test testing type ------> Bootup
Last test execution time ----> May 13 2011 21:59:44
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 13 2011 21:59:44
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
48) TestLtlFpoeMemoryConsistency ----> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
Last test pass time --------->
Total failure count --------->
Consecutive failure count --->
0 (DIAG_SUCCESS)
8191
Health Monitoring
May 16 2011 21:42:42
n/a
n/a
May 16 2011 21:42:42
0
0
LTL PARITY
Ltl index -------------------> 0
Rbh value -------------------> 0
FPOE DB
Table size ------------------>
Last entries checked -------->
Total fail count ------------>
Total correction count ------>
Last detection time --------->
Last result ----------------->
Last fail count ------------->
Last correction count ------->
0
0
0
0
May 13 2011 21:58:47
UNKNOWN
0
0
___________________________________________________________________________
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-22
Chapter 6
Online Diagnostics
How to Run Online Diagnostic Tests
49) TestErrorCounterMonitor ---------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 8191
Last test testing type ------> Health Monitoring
Last test execution time ----> May 16 2011 21:42:42
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 16 2011 21:42:42
Total failure count ---------> 0
Consecutive failure count ---> 0
Error Records ---------------> n/a
___________________________________________________________________________
50) TestEARLInternalTables ----------> .
Error code ------------------>
Total run count ------------->
Last test testing type ------>
Last test execution time ---->
First test failure time ----->
Last test failure time ------>
Last test pass time --------->
Total failure count --------->
Consecutive failure count --->
0 (DIAG_SUCCESS)
854
Health Monitoring
May 16 2011 21:38:38
n/a
n/a
May 16 2011 21:38:38
0
0
AGE GROUP
Total CC run count ---------->
Table size ------------------>
Total fail count ------------>
Total correction count ------>
Last completion time -------->
Last result ----------------->
Last fail count ------------->
Last correction count ------->
Last entries checked -------->
Consistency checker --------->
860
16384
0
0
May 16 2011 21:39:30
PASS
0
0
16384
ON
BUNDLE PORT MAP
Total CC run count ---------->
Table size ------------------>
Total fail count ------------>
Total correction count ------>
Last completion time -------->
Last result ----------------->
Last fail count ------------->
Last correction count ------->
Last entries checked -------->
Consistency checker --------->
860
512
0
0
May 16 2011 21:39:12
PASS
0
0
512
ON
BUNDLE EXTENSION MAP
Total CC run count ---------->
Table size ------------------>
Total fail count ------------>
Total correction count ------>
Last completion time -------->
Last result ----------------->
Last fail count ------------->
Last correction count ------->
Last entries checked -------->
Consistency checker --------->
860
256
0
0
May 16 2011 21:39:12
PASS
0
0
256
ON
VLAN ACCESS MODE MEMORY
Total CC run count ----------> 860
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-23
Chapter 6
Online Diagnostics
How to Perform Memory Tests
Table size ------------------> 512
Total fail count ------------> 0
Total correction count ------> 0
Last completion time --------> May 16 2011 21:39:12
Last result -----------------> PASS
Last fail count -------------> 0
Last correction count -------> 0
Last entries checked --------> 512
Consistency checker ---------> ON
___________________________________________________________________________
Router#
This example shows how to display the output for the health checks performed:
Router# show diagnostic health
Non-zero port counters for 6/4 13.
linkChange = 8530
Non-zero port counters for 6/5 13.
linkChange = 8530
Router#
How to Perform 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.
How to Perform a Diagnostic Sanity Check
You can run the diagnostic sanity check in order to see potential problem areas in your network. The
sanity check runs a set of predetermined checks on the configuration with a possible combination of
certain system states to compile a list of warning conditions. The checks are designed to look for
anything that seems out of place and are intended to serve as an aid for maintaining the system sanity.
To run the diagnostic sanity check, perform this task:
Command
Purpose
show diagnostic sanity
Runs a set of tests on the configuration and certain system states.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-24
Chapter 6
Online Diagnostics
How to Perform a Diagnostic Sanity Check
This example displays samples of the messages that could be displayed with the show diagnostic sanity
command:
Router# show diagnostic sanity
Pinging default gateway 10.6.141.1 ....
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.141.1, timeout is 2 seconds:
..!!.
Success rate is 0 percent (0/5)
IGMP snooping disabled please enable it for optimum config.
IGMP snooping disabled but RGMP enabled on the following interfaces,
please enable IGMP for proper config :
Vlan1, Vlan2, GigabitEthernet1/1
Multicast routing is enabled globally but not enabled on the following
interfaces:
GigabitEthernet1/1, GigabitEthernet1/2
A programming algorithm mismatch was found on the device bootflash:
Formatting the device is recommended.
The bootflash: does not have enough free space to accomodate the crashinfo file.
Please check your confreg value : 0x0.
Please check your confreg value on standby: 0x0.
The boot string is empty. Please enter a valid boot string .
Could not verify boot image "disk0:" specified in the boot string on the
slave.
Invalid boot image "bootflash:asdasd" specified in the boot string on the
slave.
Please check your boot string on the slave.
UDLD has been disabled globally - port-level UDLD sanity checks are
being bypassed.
OR
[
The following ports have UDLD disabled. Please enable UDLD for optimum
config:
Gi1/22
The following ports have an unknown UDLD link state. Please enable UDLD
on both sides of the link:
Gi1/22
]
The following ports have portfast enabled:
Gi1/20, Gi1/22
The following ports have trunk mode set to on:
Gi1/1, Gi1/13
The following trunks have mode set to auto:
Gi1/2, Gi1/3
The following ports with mode set to desirable are not trunking:
Gi1/3, Gi1/4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-25
Chapter 6
Online Diagnostics
How to Perform a Diagnostic Sanity Check
The following trunk ports have negotiated to half-duplex:
Gi1/3, Gi1/4
The following ports are configured for channel mode on:
Gi1/1, Gi1/2, Gi1/3, Gi1/4
The following ports, not channeling are configured for channel mode
desirable:
Gi1/14
The following vlan(s) have a spanning tree root of 32768:
1
The following vlan(s) have max age on the spanning tree root different from
the default:
1-2
The following vlan(s) have forward delay on the spanning tree root different
from the default:
1-2
The following vlan(s) have hello time on the spanning tree root different
from the default:
1-2
The following vlan(s) have max age on the bridge different from the
default:
1-2
The following vlan(s) have fwd delay on the bridge different from the
default:
1-2
The following vlan(s) have hello time on the bridge different from the
default:
1-2
The following vlan(s) have a different port priority than the default
on the port gigabitEthernet1/1
1-2
The following ports have recieve flow control disabled:
Gi1/20, Gi1/22
The following inline power ports have power-deny/faulty status:
Gi1/1, Gi1/2
The following ports have negotiated to half-duplex:
Gi1/22
The following vlans have a duplex mismatch:
Gig 1/22
The following interafaces have a native vlan mismatch:
interface (native vlan - neighbor vlan)
Gig 1/22 (1 - 64)
The value for Community-Access on read-only operations for SNMP is the same
as default. Please verify that this is the best value from a security point
of view.
The value for Community-Access on write-only operations for SNMP is the same
as default. Please verify that this is the best value from a security point
of view.
The value for Community-Access on read-write operations for SNMP is the same
as default. Please verify that this is the best value from a security point
of view.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-26
Chapter 6
Online Diagnostics
How to Perform a Diagnostic Sanity Check
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-27
Chapter 6
How to Perform a Diagnostic Sanity Check
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
6-28
Online Diagnostics
CH AP TE R
7
Onboard Failure Logging (OBFL)
Note
•
Prerequisites for OBFL, page 7-1
•
Restrictions for OBFL, page 7-2
•
Information About OBFL, page 7-2
•
Default Settings for OBFL, page 7-8
•
Enabling OBFL, page 7-9
•
Configuration Examples for OBFL, page 7-10
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for OBFL
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-1
Chapter 7
Onboard Failure Logging (OBFL)
Restrictions for OBFL
Restrictions for OBFL
•
Software Restrictions—If a device (router or switch) intends to use linear flash memory as its OBFL
storage media, Cisco IOS software must reserve a minimum of two physical sectors (or physical
blocks) for the OBFL feature. Because an erase operation for a linear flash device is done on
per-sector (or per-block) basis, one extra physical sector is needed. Otherwise, the minimum amount
of space reserved for the OBFL feature on any device must be at least 8 KB.
•
Firmware Restrictions—If a line card or port adapter runs an operating system or firmware that is
different from the Cisco IOS operating system, the line card or port adapter must provide device
driver level support or an interprocess communications (IPC) layer that allows the OBFL file system
to communicate to the line card or port adapter. This requirement is enforced to allow OBFL data to
be recorded on a storage device attached to the line card or port adapter.
•
Hardware Restrictions—To support the OBFL feature, a device must have at least 8 KB of
nonvolatile memory space reserved for OBFL data logging.
Information About OBFL
•
Overview of OBFL, page 7-2
•
Information about Data Collected by OBFL, page 7-2
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.
Information about Data Collected by OBFL
•
OBFL Data Overview, page 7-2
•
Temperature, page 7-3
•
Operational Uptime, page 7-4
•
Interrupts, page 7-7
•
Message Logging, page 7-8
OBFL Data Overview
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-2
Chapter 7
Onboard Failure Logging (OBFL)
Information About OBFL
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.
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
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-3
Chapter 7
Onboard Failure Logging (OBFL)
Information About OBFL
------------------------------------------------------------------------------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.
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-4
Chapter 7
Onboard Failure Logging (OBFL)
Information About OBFL
--------------------------------------------------------------------------------
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 7-1 to translate the numbers displayed.
•
Count is the number of resets that have occurred for each reset reason.
Table 7-1
Reset Reason Codes and Explanations
Reset Reason
Code (in hex)
Component/Explanation
0x01
Chassis on
0x02
Line card hot plug in
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-5
Chapter 7
Onboard Failure Logging (OBFL)
Information About OBFL
Table 7-1
Reset Reason Codes and Explanations
Reset Reason
Code (in hex)
Component/Explanation
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
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
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-6
Chapter 7
Onboard Failure Logging (OBFL)
Information About 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 component’s 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 | Offset | Bit
-------------------------------------------------------------------------------03/06/2007 22:33:06 450
Port-ASIC #2
9
0x00E7
6
--------------------------------------------------------------------------------
To interpret this data:
•
Name is a description of the component including its position in the device.
•
ID is an assigned field for data storage.
•
Offset is the register offset from a component register’s base address.
•
Bit is the interrupt bit number recorded from the component’s internal register.
•
The timestamp shows the date and time that an interrupt occurred down to the millisecond.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-7
Chapter 7
Onboard Failure Logging (OBFL)
Default Settings for OBFL
Message Logging
The OBFL feature logs standard system messages. Instead of displaying the message to a terminal, the
message is written to and stored in a file, so the message can be accessed and read at a later time. System
messages range from level 1 alerts to level 7 debug messages, and these levels can be specified in the
hw module logging onboard command.
Error Message Log Example
-------------------------------------------------------------------------------ERROR MESSAGE SUMMARY INFORMATION
-------------------------------------------------------------------------------Facility-Sev-Name
| Count | Persistence Flag
MM/DD/YYYY HH:MM:SS
-------------------------------------------------------------------------------No historical data to display
--------------------------------------------------------------------------------------------------------------------------------------------------------------ERROR MESSAGE CONTINUOUS INFORMATION
-------------------------------------------------------------------------------MM/DD/YYYY HH:MM:SS Facility-Sev-Name
-------------------------------------------------------------------------------03/06/2007 22:33:35 %GOLD_OBFL-3-GOLD : Diagnostic OBFL: Diagnostic OBFL testing
To interpret this data:
•
A timestamp shows the date and time the message was logged.
•
Facility-Sev-Name is a coded naming scheme for a system message, as follows:
– The Facility code consists of two or more uppercase letters that indicate the hardware device
(facility) to which the message refers.
– Sev is a single-digit code from 1 to 7 that reflects the severity of the message.
– Name is one or two code names separated by a hyphen that describe the part of the system from
where the message is coming.
•
The error message follows the Facility-Sev-Name codes. For more information about system
messages, see the Cisco IOS System and Error Messages guide.
•
Count indicates the number of instances of this message that is allowed in the history file. Once that
number of instances has been recorded, the oldest instance will be removed from the history file to
make room for new ones.
•
The Persistence Flag gives a message priority over others that do not have the flag set.
Default Settings for OBFL
The OBFL feature is enabled by default. Because of the valuable information this feature offers technical
personnel, it should not be disabled.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-8
Chapter 7
Onboard Failure Logging (OBFL)
Enabling OBFL
Enabling OBFL
To enable OBFL, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# hw-module switch switch-number
module module-number logging onboard [message
level {1-7}]
Enables OBFL on the specified hardware module.
Router(config)# end
Ends global configuration mode.
Step 4
Note
By default, all system messages sent to a device are
logged by the OBFL feature. You can define a
specific message level (only level 1 messages, as an
example) to be logged using the message level
keywords.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-9
Chapter 7
Onboard Failure Logging (OBFL)
Configuration Examples for OBFL
Configuration Examples for OBFL
The important OBFL feature is the information that is displayed by the show logging onboard module
privileged EXEC command. This section provides the following examples of how to enable and display
OBFL records.
•
Enabling OBFL Message Logging: Example
•
OBFL Message Log: Example
•
OBFL Component Uptime Report: Example
•
OBFL Report for a Specific Time: Example
Enabling OBFL Message Logging: Example
The following example shows how to configure OBFL message logging at level 3:
Router(config)# hw-module switch 2 module 1 logging onboard message level 3
OBFL Message Log: Example
The following example shows how to display the system messages that are being logged for module 2:
Router# show logging onboard module 2 message continuous
-------------------------------------------------------------------------------ERROR MESSAGE CONTINUOUS INFORMATION
-------------------------------------------------------------------------------MM/DD/YYYY HH:MM:SS Facility-Sev-Name
-------------------------------------------------------------------------------03/06/2007 22:33:35 %SWITCH_IF-3-CAMERR : [chars], for VCI [dec] VPI [dec] in stdby data
path check, status: [dec]
--------------------------------------------------------------------------------
OBFL Component Uptime Report: Example
The following example shows how to display a summary report for component uptimes for module 2:
Router# show logging onboard module 2 uptime
-------------------------------------------------------------------------------UPTIME SUMMARY INFORMATION
-------------------------------------------------------------------------------First customer power on : 03/06/2007 22:32:51
Total uptime
:
0 years
0 weeks
0 days
0 hours 35 minutes
Total downtime
:
0 years
0 weeks
0 days
0 hours
0 minutes
Number of resets
: 1
Number of slot changes : 0
Current reset reason
: 0xA1
Current reset timestamp : 03/06/2007 22:31:34
Current slot
: 2
Current uptime
:
0 years
0 weeks
0 days
0 hours 35 minutes
-------------------------------------------------------------------------------Reset |
|
Reason | Count |
-------------------------------------------------------------------------------No historical data to display
--------------------------------------------------------------------------------
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-10
Chapter 7
Onboard Failure Logging (OBFL)
Configuration Examples for OBFL
OBFL Report for a Specific Time: Example
The following example shows how to display continuous reports for all components during a specific
time period:
Router# show logging onboard module 3 continuous start 15:01:57 1 Mar 2007 end 15:04:57 3
Mar 2007
PID: WS-X6748-GE-TX
, VID:
, SN: SAL09063B85
-------------------------------------------------------------------------------UPTIME CONTINUOUS INFORMATION
-------------------------------------------------------------------------------Time Stamp
| Reset | Uptime
MM/DD/YYYY HH:MM:SS | Reason | years weeks days hours minutes
-------------------------------------------------------------------------------03/01/2007 15:01:57
0xA1
0
0
0
10
0
03/03/2007 02:29:29
0xA1
0
0
0
5
0
--------------------------------------------------------------------------------------------------------------------------------------------------------------TEMPERATURE CONTINUOUS INFORMATION
-------------------------------------------------------------------------------Sensor
|
ID |
-------------------------------------------------------------------------------MB-Out
930201
MB-In
930202
MB
930203
MB
930204
EARL-Out
910201
EARL-In
910202
SSA 1
930301
SSA 2
930302
JANUS 1
930303
JANUS 2
930304
GEMINI 1
930305
GEMINI 2
930306
------------------------------------------------------------------------------Time Stamp
|Sensor Temperature 0C
MM/DD/YYYY HH:MM:SS | 1
2
3
4
5
6
7
8
9
10
11
12
------------------------------------------------------------------------------03/01/2007 15:01:57
26
26
NA
NA
NA
NA
0
0
0
0
0
0
03/01/2007 15:06:57
39
27
NA
NA
NA
NA
39
37
36
29
32
32
03/01/2007 15:11:02
40
27
NA
NA
NA
NA
40
38
37
30
32
32
03/01/2007 17:06:06
40
27
NA
NA
NA
NA
40
38
37
30
32
32
03/01/2007 19:01:09
40
27
NA
NA
NA
NA
40
38
37
30
32
32
03/03/2007 02:29:30
25
26
NA
NA
NA
NA
0
0
0
0
0
0
03/03/2007 02:34:30
38
26
NA
NA
NA
NA
39
37
36
29
31
31
03/03/2007 04:29:33
40
27
NA
NA
NA
NA
40
38
36
30
32
32
03/03/2007 06:24:37
40
27
NA
NA
NA
NA
40
38
36
29
32
32
03/03/2007 08:19:40
40
27
NA
NA
NA
NA
40
38
36
29
32
32
03/03/2007 10:14:44
40
27
NA
NA
NA
NA
40
38
36
30
32
32
03/03/2007 12:09:47
40
27
NA
NA
NA
NA
40
38
36
30
32
32
03/03/2007 14:04:51
40
27
NA
NA
NA
NA
40
38
36
30
32
32
-------------------------------------------------------------------------------------------------------------------------------------------------------------CONTINUOUS INTERRUPT INFORMATION
-------------------------------------------------------------------------------MM/DD/YYYY HH:MM:SS mmm | Name
| ID | Offset | Bit
-------------------------------------------------------------------------------03/01/2007 15:01:59 350
Port-ASIC #0
7
0x00E7
6
03/03/2007 02:29:34 650
Port-ASIC #0
7
0x00E7
6
--------------------------------------------------------------------------------
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-11
Chapter 7
Onboard Failure Logging (OBFL)
Configuration Examples for OBFL
-------------------------------------------------------------------------------ERROR MESSAGE CONTINUOUS INFORMATION
-------------------------------------------------------------------------------MM/DD/YYYY HH:MM:SS Facility-Sev-Name
-------------------------------------------------------------------------------03/01/2007 15:02:15 %GOLD_OBFL-3-GOLD : Diagnostic OBFL: Diagnostic OBFL testing
03/03/2007 02:29:51 %GOLD_OBFL-3-GOLD : Diagnostic OBFL: Diagnostic OBFL testing
--------------------------------------------------------------------------------
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
7-12
CH AP TE R
8
Switch Fabric Functionality
Note
Tip
•
Prerequisites for Switch Fabric Functionality, page 8-1
•
Restrictions for Switch Fabric Functionality, page 8-1
•
Information About the Switch Fabric Functionality, page 8-2
•
Default Settings for Switch Fabric Functionality, page 8-2
•
How to Configure the Switch Fabric Functionality, page 8-3
•
Monitoring the Switch Fabric Functionality, page 8-4
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Switch Fabric Functionality
None.
Restrictions for Switch Fabric Functionality
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-1
Chapter 8
Switch Fabric Functionality
Information About the Switch Fabric Functionality
Information About the Switch Fabric Functionality
•
Switch Fabric Functionality Overview, page 8-2
•
Forwarding Decisions for Layer 3-Switched Traffic, page 8-2
Switch Fabric Functionality Overview
The switch fabric functionality is built into the supervisor engine and creates a dedicated connection
between fabric-enabled modules and provides uninterrupted transmission of frames between these
modules. In addition to the direct connection between fabric-enabled modules provided by the switch
fabric funtionality, fabric-enabled modules also have a direct connection to the forwarding bus.
Forwarding Decisions for Layer 3-Switched Traffic
Either a PFC or a Distributed Feature Card makes the forwarding decision for Layer 3-switched traffic
as follows:
•
A PFC makes all forwarding decisions for each packet that enters the switch through a module
without a DFC.
•
A DFC makes all forwarding decisions for each packet that enters the switch on a DFC-equipped
module in these situations:
– If the egress port is on the same module as the ingress port, the DFC forwards the packet locally
(the packet never leaves the module).
– If the egress port is on a different fabric-enabled module, the DFC sends the packet to the egress
module, which sends it out the egress port.
– If the egress port is on a different nonfabric-enabled module, the DFC sends the packet to the
supervisor engine. The supervisor engine fabric interface transfers the packet to the switching
bus where it is received by the egress module and is sent out the egress port.
Default Settings for Switch Fabric Functionality
Traffic is forwarded to and from modules in one of the following modes:
•
Compact mode—The switch uses this mode for all traffic when only fabric-enabled modules are
installed. In this mode, a compact version of the DBus header is forwarded over the switch fabric
channel, which provides the best possible performance.
•
Truncated mode—The switch uses this mode for traffic between fabric-enabled modules when there
are both fabric-enabled and nonfabric-enabled modules installed. In this mode, the switch sends a
truncated version of the traffic (the first 64 bytes of the frame) over the switch fabric channel.
•
Bus mode (also called flow-through mode)—The switch uses this mode for traffic between
nonfabric-enabled modules and for traffic between a nonfabric-enabled module and a fabric-enabled
module. In this mode, all traffic passes between the local bus and the supervisor engine bus.
Table 8-1 shows the switching modes used with fabric-enabled and nonfabric-enabled modules installed.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-2
Chapter 8
Switch Fabric Functionality
How to Configure the Switch Fabric Functionality
Table 8-1
Switch Fabric Functionality Switching Modes
Modules
Switching Modes
Between fabric-enabled modules (when no nonfabric-enabled Compact
modules are installed)
Note
In show commands, displayed as dcef mode for
fabric-enabled modules with a DFC installed;
displayed as fabric mode for other fabric-enabled
modules.
Between fabric-enabled modules (when nonfabric-enabled
modules are also installed)
Truncated
Between fabric-enabled and nonfabric-enabled modules
Bus
Between non-fabric-enabled modules
Bus
Note
Displayed as fabric mode in show commands.
How to Configure the Switch Fabric Functionality
To configure the switching mode, perform this task:
Command
Purpose
Router(config)# [no] fabric switching-mode allow
{bus-mode | {truncated [{threshold [number]}]}
Configures the switching mode.
When configuring the switching mode, note the following information:
Caution
•
To allow use of nonfabric-enabled modules or to allow fabric-enabled modules to use bus mode,
enter the fabric switching-mode allow bus-mode command.
•
To prevent use of nonfabric-enabled modules or to prevent fabric-enabled modules from using bus
mode, enter the no fabric switching-mode allow bus-mode command.
When you enter the no fabric switching-mode allow bus-mode command, power is removed from any
nonfabric-enabled modules installed in the switch.
•
To allow fabric-enabled modules to use truncated mode, enter the fabric switching-mode allow
truncated command.
•
To prevent fabric-enabled modules from using truncated mode, enter the no fabric switching-mode
allow truncated command.
•
To configure how many fabric-enabled modules must be installed before they use truncated mode
instead of bus mode, enter the fabric switching-mode allow truncated threshold number command.
•
To return to the default truncated-mode threshold, enter the no fabric switching-mode allow
truncated threshold command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-3
Chapter 8
Switch Fabric Functionality
Monitoring the Switch Fabric Functionality
Monitoring the Switch Fabric Functionality
•
Displaying the Switch Fabric Redundancy Status, page 8-4
•
Displaying Fabric Channel Switching Modes, page 8-4
•
Displaying the Fabric Status, page 8-4
•
Displaying the Fabric Utilization, page 8-5
•
Displaying Fabric Errors, page 8-5
Displaying the Switch Fabric Redundancy Status
To display the switch fabric redundancy status, perform this task:
Command
Purpose
Router# show fabric active
Displays switch fabric redundancy status.
Router# show fabric active
Active fabric card in slot 5
No backup fabric card in the system
Router#
Displaying Fabric Channel Switching Modes
To display the fabric channel switching mode of one or all modules, perform this task:
Command
Purpose
Router# show fabric switching-mode [module
{slot_number | all]
Displays fabric channel switching mode of one or all
modules.
This example shows how to display the fabric channel switching mode of all modules:
Router# show fabric switching-mode module all
%Truncated mode is allowed
%System is allowed to operate in legacy mode
Module Slot
5
9
Router#
Switching Mode
DCEF
Crossbar
Bus Mode
Compact
Compact
Displaying the Fabric Status
To display the fabric status of one or all switching modules, perform this task:
Command
Purpose
Router# show fabric status [slot_number | all]
Displays fabric status.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-4
Chapter 8
Switch Fabric Functionality
Monitoring the Switch Fabric Functionality
This example shows how to display the fabric status of all modules:
Router# show fabric status
slot
channel
speed
1
5
6
8
8
9
Router#
0
0
0
0
1
0
module
status
OK
OK
OK
OK
OK
Down- DDRsync
8G
8G
20G
8G
8G
8G
fabric
status
OK
Up- Timeout
Up- BufError
OK
OK
OK
Displaying the Fabric Utilization
To display the fabric utilization of one or all modules, perform this task:
Command
Purpose
Router# show fabric utilization [slot_number | all]
Displays fabric utilization.
This example shows how to display the fabric utilization of all modules:
Router# show fabric utilization all
Lo% Percentage of Low-priority traffic.
Hi% Percentage of High-priority traffic.
slot
5
9
Router#
channel
0
0
speed
20G
8G
Ingress Lo%
0
0
Egress Lo%
0
0
Ingress Hi% Egress Hi%
0
0
0
0
Displaying Fabric Errors
To display fabric errors of one or all modules, perform this task:
Command
Purpose
Router# show fabric errors [slot_number | all]
Displays fabric errors.
This example shows how to display fabric errors on all modules:
Router# show fabric errors
Module errors:
slot
channel
1
0
8
0
8
1
9
0
Fabric errors:
slot
channel
1
0
8
0
8
1
9
0
Router#
crc
0
0
0
0
hbeat
0
0
0
0
sync
0
0
0
0
sync
0
0
0
0
buffer
0
0
0
0
timeout
0
0
0
0
DDR sync
0
0
0
0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-5
Chapter 8
Switch Fabric Functionality
Monitoring the Switch Fabric Functionality
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
8-6
CH AP TE R
9
Cisco IP Phone Support
Note
•
Prerequisites for Cisco IP Phone Support, page 9-1
•
Restrictions for Cisco IP Phone Support, page 9-1
•
Information About Cisco IP Phone Support, page 9-2
•
Default Setting for Cisco IP Phone Support, page 9-4
•
How to Configure Cisco IP Phone Support, page 9-5
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Cisco IP Phone Support
None.
Restrictions for Cisco IP Phone Support
•
The information in this publication may be helpful in configuring support for non-Cisco IP phones,
but we recommend that you see the manufacturer’s documentation for those devices.
•
You must enable the Cisco Discovery Protocol (CDP) on the port connected to the Cisco IP phone
to send configuration information to the Cisco IP phone.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-1
Chapter 9
Cisco IP Phone Support
Information About Cisco IP Phone Support
•
You can configure a voice VLAN only on a Layer 2 LAN port.
•
The following conditions indicate that the Cisco IP phone and a device attached to the
Cisco IP phone are in the same VLAN and must be in the same IP subnet:
– If they both use 802.1p or untagged frames
– If the Cisco IP phone uses 802.1p frames and the device uses untagged frames
– If the Cisco IP phone uses untagged frames and the device uses 802.1p frames
– If the Cisco IP phone uses 802.1Q frames and the voice VLAN is the same as the access VLAN
•
The Cisco IP phone and a device attached to the Cisco IP phone cannot communicate if they are in
the same VLAN and subnet but use different frame types, because traffic between devices in the
same subnet is not routed (routing would eliminate the frame type difference).
•
You cannot use Cisco IOS software commands to configure the frame type used by traffic sent from
a device attached to the access port on the Cisco IP phone.
•
If you enable port security on a port configured with a voice VLAN and if there is a PC connected
to the Cisco IP phone, set the maximum allowed secure addresses on the port to at least 2.
•
You cannot configure static secure MAC addresses in the voice VLAN.
•
Ports configured with a voice VLAN can be secure ports (see Chapter 56, “Port Security”).
•
In all configurations, the voice traffic carries a Layer 3 IP precedence value (the default is 5 for voice
traffic and 3 for voice control traffic).
Information About Cisco IP Phone Support
•
Cisco IP Phone Connections, page 9-2
•
Cisco IP Phone Voice Traffic, page 9-3
•
Cisco IP Phone Data Traffic, page 9-4
•
Other Cisco IP Phone Features, page 9-4
Cisco IP Phone Connections
The Cisco IP phone contains an integrated 3-port 10/100 switch. The ports are dedicated connections to
these devices:
•
Port 1 connects to the switch.
•
Port 2 is an internal 10/100 interface that carries the Cisco IP phone traffic.
•
Port 3 connects to a PC or other device.
Figure 9-1 shows a Cisco IP phone connected between a switch and a PC.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-2
Chapter 9
Cisco IP Phone Support
Information About Cisco IP Phone Support
Figure 9-1
Cisco IP Phone Connected to a Switch
Cisco IP Phone
Phone
ASIC
P2
P1
P3
Access
port
Workstation/PC
192734
Catalyst switch
3-port
switch
Cisco IP Phone Voice Traffic
The Cisco IP phone transmits voice traffic with Layer 3 IP precedence and Layer 2 CoS values, which
are both set to 5 by default. The sound quality of a Cisco IP phone call can deteriorate if the voice traffic
is transmitted unevenly.
You can configure Layer 2 access ports on the switch to send Cisco Discovery Protocol (CDP) packets
that configure an attached Cisco IP phone to transmit voice traffic to the switch in any of the following
ways:
Note
•
In the voice VLAN, tagged with a Layer 2 CoS priority value
•
In the access VLAN, tagged with a Layer 2 CoS priority value
•
In the access VLAN, untagged (no Layer 2 CoS priority value)
In all configurations, the voice traffic carries a Layer 3 IP precedence value (the default is 5 for voice
traffic and 3 for voice control traffic).
To provide more predictable voice traffic flow, you can configure QoS on the switch to trust the Layer 3
IP precedence or Layer 2 CoS value in the received traffic (see Chapter 32, “PFC QoS Overview”).
The trusted boundary device verification feature configures ports on the switch to apply configured QoS
port trust commands only when the Cisco Discovery Protocol (CDP) verifies that the device attached to
the port is a Cisco IP phone. See the “How to Configure Trusted Boundary with Cisco Device Verification”
section on page 36-10.
You can configure a Layer 2 access port with an attached Cisco IP phone to use one VLAN for voice
traffic and another VLAN for data traffic from a device attached to the Cisco IP phone.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-3
Chapter 9
Cisco IP Phone Support
Default Setting for Cisco IP Phone Support
Cisco IP Phone Data Traffic
Note
•
The ability to either trust or mark tagged data traffic from the device attached to the access port on
the Cisco IP phone is called the “trusted boundary (extended trust for CDP devices)” feature.
•
You cannot use Cisco IOS software commands to configure the frame type used by data traffic sent
from a device attached to the access port on the Cisco IP phone.
•
Untagged data traffic from the device attached to the Cisco IP phone passes through the
Cisco IP phone unchanged, regardless of the trust state of the access port on the Cisco IP phone.
To process tagged data traffic (traffic in 802.1Q or 802.1p frame types) from the device attached to the
access port on the Cisco IP phone (see Figure 9-1), you can configure Layer 2 access ports on the switch
to send CDP packets that instruct an attached Cisco IP phone to configure the access port on the
Cisco IP phone to either of these two modes:
•
Trusted mode—All traffic received through the access port on the Cisco IP phone passes through the
Cisco IP phone unchanged.
•
Untrusted mode—All traffic in 802.1Q or 802.1p frames received through the access port on the
Cisco IP phone is marked with a configured Layer 2 CoS value. The default Layer 2 CoS value is 0.
Untrusted mode is the default.
Most IP phones have no ability to notify the switch of link state changes on the IP phone’s access port.
When a device attached to the access port is disconnected or disabled administratively, the switch is
unaware of the change. Some Cisco IP phones can send a CDP message containing a host presence type
length value (TLV) indicating the changed state of the access port link.
Other Cisco IP Phone Features
The switch provides support for authentication, authorization, and accounting (AAA) for
Cisco IP phones, as described in Chapter 54, “IEEE 802.1X Port-Based Authentication.”
The switch also supports automatic tracking for Cisco Emergency Responder (Cisco ER) to help you
manage emergency calls in your telephony network. For further information, see this URL:
http://www.cisco.com/en/US/products/sw/voicesw/ps842/tsd_products_support_series_home.html
Default Setting for Cisco IP Phone Support
•
Cisco IP phone support is disabled by default.
•
When the voice VLAN feature is enabled, all untagged traffic is sent with the default CoS priority
of the port.
•
CoS values are not trusted for 802.1P or 802.1Q tagged traffic.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-4
Chapter 9
Cisco IP Phone Support
How to Configure Cisco IP Phone Support
How to Configure Cisco IP Phone Support
•
Configuring Voice Traffic Support, page 9-5
•
Configuring Data Traffic Support, page 9-6
Configuring Voice Traffic Support
To configure the way in which the Cisco IP phone transmits voice traffic, perform this task:
Command
Purpose
Step 1
Router(config)# interface gigabitethernet
slot/port
Selects the port to configure.
Step 2
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
Note
You must enter the switchport command once
without any keywords to configure the LAN port
as a Layer 2 port before you can enter additional
switchport commands with keywords.
Step 3
Router(config-if)# switchport voice vlan
{voice_vlan_ID | dot1p | none | untagged}
Configures the way in which the Cisco IP phone
transmits voice traffic.
Step 4
Router(config)# end
Exits configuration mode.
When configuring the way in which the Cisco IP phone transmits voice traffic, note the following
information:
•
Enter a voice VLAN ID to send CDP packets that configure the Cisco IP phone to transmit voice
traffic in 802.1Q frames, tagged with the voice VLAN ID and a Layer 2 CoS value (the default is
5). Valid VLAN IDs are from 1 to 4094. The switch puts the 802.1Q voice traffic into the voice
VLAN.
•
Enter the dot1p keyword to send CDP packets that configure the Cisco IP phone to transmit voice
traffic in 802.1p frames, tagged with VLAN ID 0 and a Layer 2 CoS value (the default is 5 for voice
traffic and 3 for voice control traffic). The switch puts the 802.1p voice traffic into the access VLAN.
•
Enter the untagged keyword to send CDP packets that configure the Cisco IP phone to transmit
untagged voice traffic. The switch puts the untagged voice traffic into the access VLAN.
•
Enter the none keyword to allow the Cisco IP phone to use its own configuration and transmit
untagged voice traffic. The switch puts the untagged voice traffic into the access VLAN.
•
In all configurations, the voice traffic carries a Layer 3 IP precedence value (the default is 5).
•
See Chapter 32, “PFC QoS Overview,” for information about how to configure QoS.
•
See the “Configuring a LAN Interface as a Layer 2 Access Port” section on page 11-13 for information
about how to configure the port as a Layer 2 access port and configure the access VLAN.
This example shows how to configure Gigabit Ethernet port 5/1 to send CDP packets that tell the
Cisco IP phone to use VLAN 101 as the voice VLAN:
Router# configure terminal
Router(config)# interface gigabitethernet 5/1
Router(config-if)# switchport voice vlan 101
Router(config-if)# exit
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-5
Chapter 9
Cisco IP Phone Support
How to Configure Cisco IP Phone Support
This example shows how to verify the configuration of Gigabit Ethernet port 5/1:
Router# show interfaces gigabitethernet 5/1 switchport
Name: Gi5/1
Switchport: Enabled
Administrative Mode: access
Operational Mode: access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: off
Access Mode VLAN: 100
Voice VLAN: 101
Trunking Native Mode VLAN: 1 (default)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 900 ((Inactive)) 901 ((Inactive))
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Configuring Data Traffic Support
Note
The trusted boundary feature is implemented with the platform qos trust extend command.
To configure the way in which an attached Cisco IP phone transmits data traffic, perform this task:
Command
Purpose
Step 1
Router(config)# interface gigabitethernet
slot/port
Selects the port to configure.
Step 2
Router(config-if)# platform qos trust extend
[cos cos_value]
Configures the way in which an attached Cisco IP phone
transmits data traffic.
Step 3
Router(config)# end
Exits configuration mode.
When configuring the way in which an attached Cisco IP phone transmits data traffic, note the following
information:
•
To send CDP packets that configure an attached Cisco IP phone to trust tagged traffic received from
a device connected to the access port on the Cisco IP phone, do not enter the cos keyword and CoS
value.
•
To send CDP packets that configure an attached Cisco IP phone to mark tagged ingress traffic
received from a device connected to the access port on the Cisco IP phone, enter the cos keyword
and CoS value (valid values are 0 through 7).
•
You cannot use Cisco IOS software commands to configure whether or not traffic sent from a device
attached to the access port on the Cisco IP phone is tagged.
This example shows how to configure Gigabit Ethernet port 5/1 to send CDP packets that tell the
Cisco IP phone to configure its access port as untrusted and to mark all tagged traffic received from a
device connected to the access port on the Cisco IP phone with CoS 3:
Router# configure terminal
Router(config)# interface gigabitethernet 5/1
Router(config-if)# platform qos trust extend cos 3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-6
Chapter 9
Cisco IP Phone Support
How to Configure Cisco IP Phone Support
This example shows how to configure Gigabit Ethernet port 5/1 to send CDP packets that tell the
Cisco IP phone to configure its access port as trusted:
Router# configure terminal
Router(config)# interface gigabitethernet 5/1
Router(config-if)# platform qos trust extend
This example shows how to verify the configuration on Gigabit Ethernet port 5/1:
Router# show queueing interface gigabitethernet 5/1 | include Extend
Extend trust state: trusted
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-7
Chapter 9
How to Configure Cisco IP Phone Support
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
9-8
Cisco IP Phone Support
CH AP TE R
10
Power over Ethernet (PoE) Support
Note
•
Prerequisites for PoE, page 10-1
•
Restrictions for PoE, page 10-1
•
Information About PoE, page 10-2
•
How to Configure PoE Support, page 10-4
•
For information about switching modules that support PoE, see the Release Notes for Cisco IOS
Release 15.1SY publication at this URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/release_notes.html
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_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
Participate in the Technical Documentation Ideas forum
Prerequisites for PoE
None.
Restrictions for PoE
PoE is supported only on Layer 2 switchports.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-1
Chapter 10
Power over Ethernet (PoE) Support
Information About PoE
Information About PoE
•
Device Roles, page 10-2
•
PoE Overview, page 10-2
•
CPD-Based PoE Management, page 10-3
•
Inline Power IEEE Power Classification Override, page 10-4
•
LLDP Inline Power Negotiation for PoE+ (IEEE 802.3at), page 10-4
•
Power sourcing equipment (PSE)—A device that provides power through a twisted-pair Ethernet
connection. The switch, through switching modules equipped with Power over Ethernet (PoE)
daughtercards, functions in the PSE role.
•
Powered device (PD)—A device powered by a PSE (for example, IP phones, IP cameras, and
wireless access points).
Device Roles
Note
Not all PoE-capable devices are powered from the switch. There are two sources of local power for
PoE-capable devices:
•
A power supply connected to the device.
•
A power supply through a patch panel over the Ethernet connection to the device.
When a locally powered PoE-capable device is present on a switching module port, the switching
module itself cannot detect its presence. If the device supports CDP, the supervisor engine can discover
a locally powered PoE-capable device through CDP messaging with the device. If a locally powered
PoE-capable device loses local power, the switching module can discover and supply power to the IP
phone if the inline power mode is set to auto.
PoE Overview
Cisco PoE daughtercards support one or more PoE implementation:
•
IEEE 802.3at standard, shown in Cisco Feature Navigator as “PoE Plus (PoE+, PoEP) support”.
– Supported only with the PoE daughtercard on the WS-X6148E-GE-45AT switching module.
– These features are supported for IEEE 802.3at-compliant class 4 PDs:
• Class 4: 30.00 W at the PSE (12.95 W to 25.50 W at the PD).
• Optionally, LLDP Inline Power Negotiation for PoE+.
– With releases earlier than Release 15.1(1)SY, maximum 16.8 W at the PSE (ePoE for 45 ports
maximum).
•
IEEE 802.3af standard.
– Supported with the WS-F6K-48-AF PoE daughtercard and the PoE daughtercard on the
WS-X6148E-GE-45AT switching module.
– Maximum 16.80 W at the PSE.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-2
Chapter 10
Power over Ethernet (PoE) Support
Information About PoE
– The IEEE 802.3af PoE standard defines a method to sense a PD and to immediately classify the
power requirement of the PD into these per port power ranges at the PSE:
• Class 0: Up to 15.4 W (0.44–12.95 W at the PD; default classification)
• Class 1: Up to 4 W (0.44–3.84 W at the PD)
• Class 2: Up to 7 W (3.84–6.49 W at the PD)
• Class 3: Up to 15.4 W (6.49–12.95 W at the PD)
•
Cisco prestandard inline power—10 W at the PSE.
With a PoE daughtercard installed, a switching module can automatically detect and provision a
PoE-capable device that adheres to a PoE implementation supported by the PoE daughtercard. The
switching module can supply power to devices supporting other PoE implementations only through
manual configuration.
Only a PD connected directly to the switch port can be powered from the switch. If a second PD is
daisy-chained from the PD that is connected to the switch port, the second PD cannot be powered by the
switch.
Each PD requires power to be allocated from the chassis power budget. Because each PD can have
unique power requirements, more devices can be supported if the system’s power management software
can intelligently allocate the necessary power on a per-port basis.
You can configure ports to allocate power at a level based on the following:
•
If a PD is detected, with auto mode configured:
– Information sensed from the device
– A default level
– A configured maximum level
•
Whether or not a PD is present on the port, with static mode configured:
– A default level
– A configured level
CPD-Based PoE Management
When a switching module port detects an unpowered PD, the default-allocated power is provided to the
port. When the correct amount of power is determined through CDP messaging with the PD, the
supervisor engine reduces or increases the allocated power, up to the hardware limit of the installed PoE
daughtercard.
Caution
When a PD cable is plugged into a port and the power is turned on, the supervisor engine has a 4-second
timeout waiting for the link to go up on the line. During those 4 seconds, if the IP phone cable is
unplugged and a network device is plugged in, the network device could be damaged. We recommend
that you wait at least 10 seconds between unplugging a network device and plugging in another network
device.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-3
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
Inline Power IEEE Power Classification Override
The IEEE 802.3af standard contains no provision for adjustment of the power allocation.
802.3af-compliant PDs that support CDP can use CDP to override the IEEE 802.3af power classification.
The WS-F6K-48-AF PoE daughtercard or the PoE daughtercard on the WS-X6148E-GE-45AT
switching module support these inline power IEEE 802.3af power classification override features:
•
Power use measurement—The ability to accurately measure the power provided by the port to the
powered device.
•
Power policing—The ability to monitor power usage on a port.
With power measurement and policing, you can safely override the IEEE 802.3af power classification
of a device that requires a power level at the lower end of its IEEE power classification range.
PoE monitoring and policing compares the power consumption on ports with the administrative
maximum value (either a configured maximum value or the port’s default value). If the power
consumption on a monitored port exceeds the administrative maximum value, the following actions
occur:
•
A syslog message is issued.
•
The monitored port is shut down and error-disabled.
•
The allocated power is freed.
LLDP Inline Power Negotiation for PoE+ (IEEE 802.3at)
The PoE daughtercard on the WS-X6148E-GE-45AT switching module supports IEEE
802.3at-compliant LLDP PoE power negotiation, which supports additional negotiation that can reduce
power usage.
Note
•
Enabled by default.
•
The LLDP TLV used is DTE Power-via-MDI TLV.
•
When a PD that performs power negotiation using multiple protocols (CDP and LLDP 802.3at) is
connected to a switch, the switch locks to the first protocol packet (CDP or LLDP) that contains the
power negotiation TLV. If you need to use any single protocol for power negotiation each time, you
must administratively disable the other power negotiation protocols on the switch interface.
•
See this publication for other the Link Layer Discovery Protocol (LLDP) configuration procedures:
http://www.cisco.com/en/US/docs/ios/cether/configuration/guide/ce_lldp-med.html
How to Configure PoE Support
•
Displaying PoE Status, page 10-5
•
Configuring Per-Port PoE Support, page 10-5
•
Configuring PoE Power Priority, page 10-6
•
Configuring PoE Monitoring and Policing, page 10-8
•
Disabling LLDP Power Negotiation (IEEE 802.3at), page 10-8
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-4
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
Displaying PoE Status
This example shows how to display the PoE status on switch:
Router# show power auxiliary
system auxiliary power mode = on
system auxiliary power redundancy operationally = redundant
system primary connector power limit =
7266.00 Watts (173.00 Amps @ 42V)
system auxiliary connector power limit = 10500.00 Watts (250.00 Amps @ 42V)
system primary power used =
1407.00 Watts (33.50 Amps @ 42V)
system auxiliary power used =
22.68 Watts ( 0.54 Amps @ 42V)
Inline
Inline-Pwr
Inline-Pwr
VDB
Pwr-Limit
Used-Thru-Pri Used-Thru-Aux Aux-Pwr
Slot Card-Type
Watts
A @42V Watts
A @42V Watts
A @42V Capable
---- ------------------ ------- ------ ------- ------ ------- ------ ------2
WS-F6K-48-AT
1600.20 38.10
23.10 0.55
11.34 0.27 Yes
4
WS-F6K-48-AT
1600.20 38.10
23.10 0.55
11.34 0.27 Yes
---- ------------------ ------- ------ ------- ------ ------- ------ ------Totals:
46.20 1.10
22.68 0.54
Configuring Per-Port PoE Support
To configure per-port PoE support, perform this task:
Command
Purpose
Step 1
Router(config-if)# power inline {auto | static |
never}[max milliwatts]
Configures per-port PoE support and optionally specifies
a maximum inline power level in milliwatts for the port.
Step 2
Router# show power inline {type slot/port |
module slot}[detail]
Verifies the configuration.
When configuring inline power support with the power inline command, note the following information:
•
To configure auto-detection of a PD and PoE auto-allocation, enter the auto keyword.
•
To configure auto-detection of a PD but reserve a fixed PoE allocation, enter the static keyword.
•
To specify the maximum power to allocate to a port, enter either the auto or static keyword followed
by the max keyword and the power level in milliwatts.
•
When the auto keyword is entered and CDP is enabled on the port, a PD that supports CDP can
negotiate a different power level.
•
To disable auto-detection of a PD, enter the never keyword.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-5
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
•
With a WS-F6K-GE48-AF, WS-F6K-48-AF, or the PoE daughtercard on the WS-X6148E-GE-45AT
switching module:
– The configurable range of maximum power using the max keyword is 4000 to 16800 milliwatts.
If no maximum power level is configured, the default maximum power is 15400 milliwatts.
Note
To support a large number of inline-powered ports using power levels above 15400
milliwatts on an inline power card, we recommend using the static keyword so that the
power budget is deterministic.
– When the auto keyword is entered and CDP is enabled on the port, an inline-powered device
that supports CDP can negotiate a power level up to 16800 milliwatts unless a lower maximum
power level is configured.
This example shows how to disable inline power on GigabitEthernet port 2/10:
Router# configure terminal
Router(config)# interface gigabitethernet 2/10
Router(config-if)# power inline never
This example shows how to enable inline power on GigabitEthernet port 2/10:
Router# configure terminal
Router(config)# interface gigabitethernet 2/10
Router(config-if)# power inline auto
This example shows how to verify the inline power configuration on GigabitEthernet port 2/10:
Router# show power inline gigabitethernet 2/10
Interface Admin Priority
Oper
Power(Watts)
Device
Class
(enabled )
From PS To PD
---------------- ---------- ---------- ------- ------- ------------------- ----Gi2/10
auto
low
on
14.5
13.1 Cisco IP Phone 9971
4
Interface AdminPowerMax Police ActConsumption
(Watts)
--------- ------------- ------ -------------Gi2/10
30.0 on
6.7
Configuring PoE Power Priority
You can configure how the switch responds if a power shortage occurs by setting the priority of ports
providing PoE. The priority determines the order in which PoE is removed from ports if a power shortage
occurs: low-priority, then high-priority, with power maintained for critical-priority ports as long as
possible. These sections describe how to configure PoE power priority:
•
Setting the PoE Power Priority Global Enable State, page 10-7
•
Configuring PoE Port Power Priority, page 10-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-6
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
Setting the PoE Power Priority Global Enable State
To disable PoE power priority globally, perform this task:
Command
Purpose
Step 1
Router(config)# no power inline priority enable
Disables PoE power priority globally (default: enabled).
Step 2
Router# show power inline
Verifies the configuration.
This example shows how to disable PoE power priority globally:
Router(config)# no power inline priority enable
The column heading of any show power inline command displays the PoE power priority global state
(“disabled” in this example):
Router# show power inline
Interface Admin Priority
Oper
Power(Watts)
Device
Class
(disabled)
From PS To PD
---------------- ---------- ---------- ------- ------- ------------------- ----...
Configuring PoE Port Power Priority
To configure PoE port power priority, perform this task:
Step 1
Command
Purpose
Router(config-if)# power inline auto priority
{critical | high | low}
Enables PoE port power priority (default: low priority
when power priority is enabled globally).
If a power shortage occurs, PoE is removed from ports in
the following order:
•
Low priority ports
•
High priority ports
PoE is maintained for critical priority ports as long as
possible.
Step 2
Router# show power inline type slot/port [detail]
Verifies the configuration.
This example shows how to configure the PoE port power priority of GigabitEthernet port 2/10 as high:
Router# configure terminal
Router(config)# interface gigabitethernet 2/10
Router(config-if)# power inline auto priority high
This example shows how to verify the PoE port power priority configuration of GigabitEthernet
port 2/10:
Router# show power inline gigabitethernet 2/10 detail | include Priority
Priority: high
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-7
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
Configuring PoE Monitoring and Policing
With the WS-F6K-48-AF PoE daughtercard or the PoE daughtercard on the WS-X6148E-GE-45AT
switching module, to configure PoE monitoring and policing, perform this task:
Command
Purpose
Step 1
Router(config-if)# power inline police
Enables PoE monitoring and policing.
Step 2
Router# show power inline {type slot/port |
module slot}[detail]
Verifies the configuration.
This example shows how to enable monitoring and policing on GigabitEthernet port 1/9:
Router# configure terminal
Router(config)# interface gigabitethernet 2/10
Router(config-if)# power inline police
These examples shows how to verify the power monitoring and policing configuration on
GigabitEthernet port 2/10:
Router# show power inline gigabitethernet
Police: on
Router#
Router# show power inline gigabitethernet
Interface Admin Oper Power (Watts)
From PS To Device
------------ ---- ------- --------Gi2/10
auto
on
17.3
15.4
Interface
--------Gi2/10
Router#
AdminPowerMax (Watts) Police
--------------------- -----15.4
on
2/10 detail | include Police
2/10
Device
Class
------- ----Ieee PD
3
ActualConsumption
----------------5.7
Disabling LLDP Power Negotiation (IEEE 802.3at)
With the WS-X6148E-GE-45AT switching module, LLDP power negotiation is enabled by default. To
disable LLDP power negotiation, perform this task:
Command
Purpose
Router(config-if)# no lldp tlv-select power-management
Disables LLDP power negotiation
(default: enabled).
This example shows how to display the LLDP power negotiation configuration on interface
GigabitEthernet 3/1 when LLDP power negotiation is enabled:
Router# show power inline gigabitethernet 2/10 detail | begin LLDP
LLDP Power Classification
-- Sent to PD -- -- Rcvd from PD -Power Type :
type 2 PSE
type 2 PD
Power Source :
primary
PSE
Power Priority :
low
high
Requested Power (watts):
11.2
11.2
Allocated Power (watts):
11.2
11.2
Power class :
4
4
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-8
Chapter 10
Power over Ethernet (PoE) Support
How to Configure PoE Support
LLDP Legacy
MDI power
pse power
MDI power
MDI TLV
support :
pair :
class :
-- Rcvd from PD -0
0
0
This example shows how to disable LLDP power negotiation on interface GigabitEthernet 2/10:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 2/10
Router(config-if)# no lldp tlv-select power-management
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-9
Chapter 10
How to Configure PoE Support
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
10-10
Power over Ethernet (PoE) Support
PART
2
LAN Switching
CH AP TE R
11
LAN Ports for Layer 2 Switching
Note
•
Prerequisites for Layer 2 LAN Interfaces, page 11-1
•
Restrictions for Layer 2 LAN Interfaces, page 11-2
•
Information About Layer 2 Switching, page 11-2
•
Default Settings for Layer 2 LAN Interfaces, page 11-5
•
How to Configure LAN Interfaces for Layer 2 Switching, page 11-5
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
To configure Layer 3 interfaces, see Chapter 5, “Layer 3 Interfaces.”
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Layer 2 LAN Interfaces
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-1
Chapter 11
LAN Ports for Layer 2 Switching
Restrictions for Layer 2 LAN Interfaces
Restrictions for Layer 2 LAN Interfaces
•
When connecting Cisco switches through an 802.1q trunk, make sure the native VLAN for an
802.1Q trunk is the same on both ends of the trunk link. If the native VLAN on one end of the trunk
is different from the native VLAN on the other end, spanning tree loops might result.
•
Disabling spanning tree on the native VLAN of an 802.1Q trunk without disabling spanning tree on
every VLAN in the network can cause spanning tree loops. We recommend that you leave spanning
tree enabled on the native VLAN of an 802.1Q trunk. If this is not possible, disable spanning tree
on every VLAN in the network. Make sure your network is free of physical loops before disabling
spanning tree.
•
When you connect two Cisco switches through 802.1Q trunks, the switches exchange spanning tree
BPDUs on each VLAN allowed on the trunks. The BPDUs on the native VLAN of the trunk are sent
untagged to the reserved IEEE 802.1d spanning tree multicast MAC address (01-80-C2-00-00-00).
The BPDUs on all other VLANs on the trunk are sent tagged to the reserved Cisco Shared Spanning
Tree (SSTP) multicast MAC address (01-00-0c-cc-cc-cd).
•
Non-Cisco 802.1Q switches maintain only a single instance of spanning tree (the Mono Spanning
Tree, or MST) that defines the spanning tree topology for all VLANs. When you connect a Cisco
switch to a non-Cisco switch through an 802.1Q trunk, the MST of the non-Cisco switch and the
native VLAN spanning tree of the Cisco switch combine to form a single spanning tree topology
known as the Common Spanning Tree (CST).
•
Because Cisco switches transmit BPDUs to the SSTP multicast MAC address on VLANs other than
the native VLAN of the trunk, non-Cisco switches do not recognize these frames as BPDUs and
flood them on all ports in the corresponding VLAN. Other Cisco switches connected to the
non-Cisco 802.1q cloud receive these flooded BPDUs. This allows Cisco switches to maintain a
per-VLAN spanning tree topology across a cloud of non-Cisco 802.1Q switches. The non-Cisco
802.1Q cloud separating the Cisco switches is treated as a single broadcast segment between all
switches connected to the non-Cisco 802.1q cloud through 802.1q trunks.
•
Make certain that the native VLAN is the same on all of the 802.1q trunks connecting the Cisco
switches to the non-Cisco 802.1q cloud.
•
If you are connecting multiple Cisco switches to a non-Cisco 802.1q cloud, all of the connections
must be through 802.1q trunks. You cannot connect Cisco switches to a non-Cisco 802.1q cloud
through access ports. Doing so causes the switch to place the access port into the spanning tree “port
inconsistent” state and no traffic will pass through the port.
Information About Layer 2 Switching
•
Information about Layer 2 Ethernet Switching, page 11-2
•
Information about VLAN Trunks, page 11-4
•
Layer 2 LAN Port Modes, page 11-4
Information about Layer 2 Ethernet Switching
•
Layer 2 Ethernet Switching Overview, page 11-3
•
Building the MAC Address Table, page 11-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-2
Chapter 11
LAN Ports for Layer 2 Switching
Information About Layer 2 Switching
Layer 2 Ethernet Switching Overview
Layer 2 Ethernet ports on Cisco switches support simultaneous, parallel connections between Layer 2
Ethernet segments. Switched connections between Ethernet segments last only for the duration of the
packet. New connections can be made between different segments for the next packet.
Layer 2 LAN switching (hardware-supported bridging) avoids congestion by assigning each connected
device to its own collision domain. Because each LAN port connects to a separate Ethernet collision
domain, attached devices in a properly configured switched environment achieve full access to network
bandwidth.
Building the MAC Address Table
•
Overview of the MAC Address Table, page 11-3
•
Synchronization and Sharing of the Address Table, page 11-3
•
Notification of Address Table Changes, page 11-3
Overview of the MAC Address Table
When stations connected to different LAN ports need to communicate, the switch forwards frames from
one LAN port to the other at wire speed to ensure that each session receives full bandwidth.
To switch frames between LAN ports efficiently, the switch maintains a MAC address table. When a
frame enters the switch, it associates the MAC address of the sending network device with the LAN port
on which it was received.
The MAC address table is built by using the source MAC address of the frames received. When the
switch receives a frame for a destination MAC address not listed in its MAC address table, it floods the
frame to all LAN ports of the same VLAN except the port that received the frame. When the destination
station replies, the switch adds its relevant source MAC address and port ID to the MAC address table.
The switch then forwards subsequent frames to a single LAN port without flooding to all LAN ports.
The MAC address table can store at least 128,000 address entries without flooding any entries. The
switch uses an aging mechanism, configured by the mac address-table aging-time command, so if an
address remains inactive for a specified number of seconds, it is removed from the address table.
Synchronization and Sharing of the Address Table
With distributed switching, each DFC-equipped switching module learns MAC addresses, maintains an
address table, and ages table entries. MAC address table synchronization over the Ethernet Out of Band
Channel (EOBC) synchronizes address tables among the PFC and all DFCs, eliminating the need for
flooding by a DFC for an address that is active on another module. MAC synchronization is enabled by
default.
Notification of Address Table Changes
You can configure the switch to maintain a history of dynamic additions and removals of address table
entries associated with a particular LAN port. The change history can be sent as an SNMP trap
notification or it can be read manually from the SNMP MIB.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-3
Chapter 11
LAN Ports for Layer 2 Switching
Information About Layer 2 Switching
Information about VLAN Trunks
Note
For information about VLANs, see Chapter 16, “Virtual Local Area Networks (VLANs).”
A trunk is a point-to-point link between the switch and another networking device. Trunks carry the
traffic of multiple VLANs over a single link and allow you to extend VLANs across an entire network.
802.1Q, an industry-standard trunking encapsulation, is available on all Ethernet ports.
You can configure a trunk on a single Ethernet port or on an EtherChannel. For more information about
EtherChannel, see Chapter 13, “EtherChannels.”
Ethernet trunk ports support several trunking modes (see Table 11-1 on page 11-4).
The Dynamic Trunking Protocol (DTP) manages trunk autonegotiation on LAN ports.
To autonegotiate trunking, the LAN ports must be in the same VTP domain. Use the trunk or
nonegotiate keywords to force LAN ports in different domains to trunk. For more information on VTP
domains, see Chapter 15, “VLAN Trunking Protocol (VTP).”
Layer 2 LAN Port Modes
Table 11-1
Layer 2 LAN Port Modes
Mode
Function
switchport mode access
Puts the LAN port into permanent nontrunking mode and negotiates to convert the
link into a nontrunk link. The LAN port becomes a nontrunk port even if the
neighboring LAN port does not agree to the change.
switchport mode dynamic desirable
Makes the LAN port actively attempt to convert the link to a trunk link. The LAN
port becomes a trunk port if the neighboring LAN port is set to trunk, desirable, or
auto mode. This is the default mode for all LAN ports.
switchport mode dynamic auto
Makes the LAN port willing to convert the link to a trunk link. The LAN port
becomes a trunk port if the neighboring LAN port is set to trunk or desirable mode.
switchport mode trunk
Puts the LAN port into permanent trunking mode and negotiates to convert the link
into a trunk link. The LAN port becomes a trunk port even if the neighboring port
does not agree to the change.
switchport nonegotiate
Puts the LAN port into permanent trunking mode but prevents the port from
generating DTP frames. You must configure the neighboring port manually as a
trunk port to establish a trunk link.
Note
DTP is a point-to-point protocol. However, some internetworking devices might forward DTP frames
improperly. To avoid this problem, ensure that LAN ports connected to devices that do not support DTP
are configured with the access keyword if you do not intend to trunk across those links. To enable
trunking to a device that does not support DTP, use the nonegotiate keyword to cause the LAN port to
become a trunk but not generate DTP frames.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-4
Chapter 11
LAN Ports for Layer 2 Switching
Default Settings for Layer 2 LAN Interfaces
Default Settings for Layer 2 LAN Interfaces
Feature
Default
Interface mode:
•
Before entering the switchport command Layer 3 (unconfigured)
•
After entering the switchport command
switchport mode dynamic desirable
Allowed VLAN range
VLANs 1 to 4094, except reserved VLANs (see
Table 16-1 on page 16-3)
VLAN range eligible for pruning
VLANs 2 to 1001
Default access VLAN
VLAN 1
Native VLAN (for 802.1Q trunks)
VLAN 1
Spanning Tree Protocol (STP)
Enabled for all VLANs
STP port priority
128
STP port cost
•
100 for 10-Mbps Ethernet LAN ports
•
19 for 10/100-Mbps Fast Ethernet LAN ports
•
19 for 100-Mbps Fast Ethernet LAN ports
•
4 for 1,000-Mbps Gigabit Ethernet LAN ports
•
2 for 10,000-Mbps 10-Gigabit Ethernet LAN
ports
How to Configure LAN Interfaces for Layer 2 Switching
Note
•
Configuring a LAN Port for Layer 2 Switching, page 11-6
•
Enabling Out-of-Band MAC Address Table Synchronization, page 11-6
•
Configuring MAC Address Table Notification, page 11-7
•
Configuring a Layer 2 Switching Port as a Trunk, page 11-8
•
Configuring a LAN Interface as a Layer 2 Access Port, page 11-13
•
Configuring a Custom IEEE 802.1Q EtherType Field Value, page 11-15
Use the default interface {fastethernet | gigabitethernet | tengigabitethernet} slot/port command to
revert an interface to its default configuration.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-5
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
Configuring a LAN Port for Layer 2 Switching
To configure a LAN port for Layer 2 switching, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# shutdown
(Optional) Shuts down the interface to prevent traffic flow
until configuration is complete.
Step 3
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
Note
You must enter the switchport command once
without any keywords to configure the LAN port
as a Layer 2 port before you can enter additional
switchport commands with keywords.
Step 4
Router(config-if)# no shutdown
Activates the interface. (Required only if you shut down
the interface.)
Step 5
Router(config-if)# end
Exits configuration mode.
After you enter the switchport command, the default mode is switchport mode dynamic desirable. If
the neighboring port supports trunking and is configured to allow trunking, the link becomes a Layer 2
trunk when you enter the switchport command.
Note
When using the switchport command, if a port configured for Layer 3 is now configured for Layer 2,
the configuration for Layer 3 is retained in the memory but not in the running configuration and is
applied to the port whenever the port switches back to Layer 3. Also, if a port configured for Layer 2 is
now configured for Layer 3, the configuration for Layer 2 is retained in the memory but not in the
running configuration and is applied to the port whenever the port switches back to Layer 2. To restore
the default configuration of the port in the memory and in the running configuration, use the default
interface command. To avoid potential issues while changing the role of a port using the switchport
command, shut down the interface before applying the switchport command.
Enabling Out-of-Band MAC Address Table Synchronization
To enable the out-of-band MAC address table synchronization feature, perform this task:
Command
Purpose
Router(config)# mac address-table synchronize
[activity-time seconds]
Enables out-of-band synchronization of MAC address tables
among DFC-equipped switching modules.
•
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-6
activity-time seconds—(Optional) Specifies the activity
timer interval.
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
When configuring out-of-band MAC address table synchronization, note the following information:
•
By default, out-of-band MAC address table synchronization is disabled.
•
Out-of-band MAC address table synchronization is enabled automatically if a WS-6708-10G
switching module is installed in the switch.
•
The activity timer interval can be configured as 160, 320, and 640 seconds. The default is 160
seconds.
This example shows how to enable out-of-band MAC address table synchronization:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mac address-table synchronize activity-time 320
Configuring MAC Address Table Notification
Note
•
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
•
To send SNMP trap notifications using this feature, you must also enable the global MAC trap flag,
using the snmp-server enable mac-notification change command.
To configure the MAC address table notification feature, perform this task:
Step 1
Command
Purpose
Router(config)# mac address-table notification
change [interval value]
Enables sending notification of dynamic changes to MAC
address table.
(Optional) Sets the minimum change-sending interval in
seconds.
Note
Step 2
Router(config)# mac address-table notification
change [history size]
The no form of the command reverts to the default
without sending any change information.
Enables sending notification of dynamic changes to MAC
address table.
(Optional) Sets the number of entries in the history buffer.
Note
The no form of the command reverts to the default
without sending any change information.
Step 3
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 4
Router(config-if)# snmp trap mac-notification
change [added | removed]
For MAC addresses that are associated with this LAN
port, enable SNMP trap notification when MAC
addresses are added to or removed from the address table.
(Optional) To notify only when a MAC address is added
to the table, use the added option. To notify only when a
MAC address is removed, use the removed option.
Step 5
Router(config-if)# end
Exits interface configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-7
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
When configuring the notification parameters, note the following information:
•
The interval value parameter can be configured from 0 seconds (immediate) to 2,147,483,647
seconds. The default is 1 second.
•
The history size parameter can be configured from 0 entries to 500 entries. The default is 1 entry.
This example shows how to configure the SNMP notification of dynamic additions to the MAC address
table of addresses on the Gigabit Ethernet ports 5/7 and 5/8. Notifications of changes will be sent no
more frequently than 5 seconds, and up to 25 changes can be stored and sent in that interval:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mac address-table notification change interval 5
Router(config)# mac address-table notification change history 25
Router(config)# interface gigabitethernet 5/7
Router(config-if)# snmp trap mac-notification change added
Router(config-if)# end
Router(config)# interface gigabitethernet 5/8
Router(config-if)# snmp trap mac-notification change added
Router(config-if)# end
Router# exit
Configuring a Layer 2 Switching Port as a Trunk
•
Configuring the Layer 2 Trunk to Use DTP, page 11-8
•
Configuring the Layer 2 Trunk Not to Use DTP, page 11-9
•
Configuring the Access VLAN, page 11-9
•
Configuring the 802.1Q Native VLAN, page 11-10
•
Configuring the List of VLANs Allowed on a Trunk, page 11-10
•
Configuring the List of Prune-Eligible VLANs, page 11-11
•
Completing Trunk Configuration, page 11-12
•
Verifying Layer 2 Trunk Configuration, page 11-12
•
Configuration and Verification Examples, page 11-12
Configuring the Layer 2 Trunk to Use DTP
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
To configure the Layer 2 trunk to use DTP, perform this task:
Command
Purpose
Router(config-if)# switchport mode dynamic {auto |
desirable}
(Optional) Configures the trunk to use DTP.
Note
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-8
The no form of the command reverts to the default
trunk trunking mode (switchport mode dynamic
desirable).
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
When configuring the Layer 2 trunk to use DTP, note the following information:
Note
•
Required only if the interface is a Layer 2 access port or to specify the trunking mode.
•
See Table 11-1 on page 11-4 for information about trunking modes.
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Configuring the Layer 2 Trunk Not to Use DTP
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
To configure the Layer 2 trunk not to use DTP, perform this task:
Command
Purpose
Step 1
Router(config-if)# switchport mode trunk
(Optional) Configures the port to trunk unconditionally.
Step 2
Router(config-if)# switchport nonegotiate
(Optional) Configures the trunk not to use DTP.
Note
The no form of the command enables DTP on the
port.
When configuring the Layer 2 trunk not to use DTP, note the following information:
Note
•
Before entering the switchport mode trunk command, you must configure the encapsulation (see
the “Configuring the Layer 2 Trunk to Use DTP” section on page 11-8).
•
To support the switchport nonegotiate command, you must enter the switchport mode trunk
command.
•
Enter the switchport mode dynamic trunk command. See Table 11-1 on page 11-4 for information
about trunking modes.
•
Before entering the switchport nonegotiate command, you must configure the encapsulation (see
the “Configuring the Layer 2 Trunk to Use DTP” section on page 11-8) and configure the port to trunk
unconditionally with the switchport mode trunk command (see the “Configuring the Layer 2 Trunk
to Use DTP” section on page 11-8).
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Configuring the Access VLAN
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-9
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
To configure the access VLAN, perform this task:
Command
Purpose
Router(config-if)# switchport access vlan vlan_ID
(Optional) Configures the access VLAN, which is used if the
interface stops trunking. The vlan_ID value can be 1 through
4094, except reserved VLANs (see Table 16-1 on page 16-3).
Note
Note
•
If VLAN locking is enabled, enter the VLAN name
instead of the VLAN number. For more information, see
the “VLAN Locking” section on page 16-4.
•
The no form of the command reverts to the default VLAN
(VLAN 1).
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Configuring the 802.1Q Native VLAN
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
To configure the 802.1Q native VLAN, perform this task:
Command
Purpose
Router(config-if)# switchport trunk native vlan
vlan_ID
(Optional) Configures the 802.1Q native VLAN.
Note
If VLAN locking is enabled, enter the VLAN name
instead of the VLAN number. For more information,
see the “VLAN Locking” section on page 16-4.
When configuring the native VLAN, note the following information:
Note
•
The vlan_ID value can be 1 through 4094, except reserved VLANs (see Table 16-1 on page 16-3).
•
The access VLAN is not automatically used as the native VLAN.
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Configuring the List of VLANs Allowed on a Trunk
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-10
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
To configure the list of VLANs allowed on a trunk, perform this task:
Command
Purpose
Router(config-if)# switchport trunk allowed vlan
[add | except | none | remove] vlan
[,vlan[,vlan[,...]]
(Optional) Configures the list of VLANs allowed on the
trunk.
Note
•
If VLAN locking is enabled, enter VLAN names instead
of VLAN numbers. For more information, see the
“VLAN Locking” section on page 16-4.
•
The no form of the command reverts to the default value
(all VLANs allowed).
When configuring the list of VLANs allowed on a trunk, note the following information:
Note
•
The vlan parameter is either a single VLAN number from 1 through 4094, or a range of VLANs
described by two VLAN numbers, the lesser one first, separated by a dash. Do not enter any spaces
between comma-separated vlan parameters or in dash-specified ranges.
•
If VLAN locking is enabled, enter VLAN names instead of VLAN numbers. When entering a range
of VLAN names, you must leave spaces between the VLAN names and the dash.
•
All VLANs are allowed by default.
•
You can remove VLAN 1. If you remove VLAN 1 from a trunk, the trunk interface continues to send
and receive management traffic, for example, Cisco Discovery Protocol (CDP), VLAN Trunking
Protocol (VTP), Port Aggregation Protocol (PAgP), and DTP in VLAN 1.
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Configuring the List of Prune-Eligible VLANs
Note
Complete the steps in the “Configuring a LAN Port for Layer 2 Switching” section on page 11-6 before
performing the tasks in this section.
To configure the list of prune-eligible VLANs on the Layer 2 trunk, perform this task:
Command
Purpose
Router(config-if)# switchport trunk pruning vlan
{none |{{add | except | remove}
vlan[,vlan[,vlan[,...]]}}
(Optional) Configures the list of prune-eligible VLANs on the
trunk (see the “VTP Pruning” section on page 15-7).
Note
The no form of the command reverts to the default
value (all VLANs prune-eligible).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-11
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
When configuring the list of prune-eligible VLANs on a trunk, note the following information:
Note
•
The vlan parameter is either a single VLAN number from 1 through 4094, except reserved VLANs
(see Table 16-1 on page 16-3), or a range of VLANs described by two VLAN numbers, the lesser one
first, separated by a dash. Do not enter any spaces between comma-separated vlan parameters or in
dash-specified ranges.
•
The default list of VLANs allowed to be pruned contains all VLANs.
•
Network devices in VTP transparent mode do not send VTP Join messages. On trunk connections to
network devices in VTP transparent mode, configure the VLANs used by the transparent-mode network
devices or that need to be carried across the transparent-mode network devices as pruning ineligible.
Complete the steps in the “Completing Trunk Configuration” section on page 11-12 after performing the
tasks in this section.
Completing Trunk Configuration
To complete Layer 2 trunk configuration, perform this task:
Command
Purpose
Step 1
Router(config-if)# no shutdown
Activates the interface. (Required only if you shut down
the interface.)
Step 2
Router(config-if)# end
Exits configuration mode.
Verifying Layer 2 Trunk Configuration
To verify Layer 2 trunk configuration, perform this task:
Command
Purpose
Step 1
Router# show running-config interface type slot/port
Displays the running configuration of the interface.
Step 2
Router# show interfaces [type slot/port] switchport
Displays the switch port configuration of the interface.
Step 3
Router# show interfaces [type slot/port] trunk
Displays the trunk configuration of the interface.
Configuration and Verification Examples
This example shows how to configure the Gigabit Ethernet port 5/8 as an 802.1Q trunk. This example
assumes that the neighbor port is configured to support 802.1Q trunking:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 5/8
Router(config-if)# shutdown
Router(config-if)# switchport
Router(config-if)# switchport mode dynamic desirable
Router(config-if)# no shutdown
Router(config-if)# end
Router# exit
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-12
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
This example shows how to verify the configuration:
Router# show running-config interface gigabitethernet 5/8
Building configuration...
Current configuration:
!
interface GigabitEthernet5/8
no ip address
switchport
switchport trunk encapsulation dot1q
end
Router# show interfaces gigabitethernet 5/8 switchport
Name: Gi5/8
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Enabled
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: ALL
Router# show interfaces gigabitethernet 5/8 trunk
Port
Gi5/8
Mode
desirable
Encapsulation
n-802.1q
Status
trunking
Native vlan
1
Port
Vlans allowed on trunk
Gi5/8 1-1005
Port
Vlans allowed and active in management domain
Gi5/8 1-6,10,20,50,100,152,200,300,303-305,349-351,400,500,521,524,570,801-8
02,850,917,999,1002-1005
Port
Vlans in spanning tree forwarding state and not pruned
Gi5/8 1-6,10,20,50,100,152,200,300,303-305,349-351,400,500,521,524,570,801-8
02,850,917,999,1002-1005
Router#
Configuring a LAN Interface as a Layer 2 Access Port
Note
If you assign a LAN port to a VLAN that does not exist, the port is shut down until you create the VLAN
in the VLAN database (see the “Creating or Modifying an Ethernet VLAN” section on page 16-5).
To configure a LAN port as a Layer 2 access port, perform this task:
Command
Purpose
Step 1 Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2 Router(config-if)# shutdown
(Optional) Shuts down the interface to prevent traffic flow
until configuration is complete.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-13
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
Command
Purpose
Step 3 Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
Note
You must enter the switchport command once
without any keywords to configure the LAN port
as a Layer 2 port before you can enter additional
switchport commands with keywords.
Step 4 Router(config-if)# switchport mode access
Configures the LAN port as a Layer 2 access port.
Step 5 Router(config-if)# switchport access vlan vlan_ID
Places the LAN port in a VLAN. The vlan_ID value can
be 1 through 4094, except reserved VLANs (see
Table 16-1 on page 16-3).
Note
If VLAN locking is enabled, enter the VLAN
name instead of the VLAN number. For more
information, see the “VLAN Locking” section on
page 16-4.
Step 6 Router(config-if)# no shutdown
Activates the interface. (Required only if you shut down
the interface.)
Step 7 Router(config-if)# end
Exits configuration mode.
This example shows how to configure the Gigabit Ethernet port 5/6 as an access port in VLAN 200:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 5/6
Router(config-if)# shutdown
Router(config-if)# switchport
Router(config-if)# switchport mode access
Router(config-if)# switchport access vlan 200
Router(config-if)# no shutdown
Router(config-if)# end
Router# exit
This example shows how to verify the configuration:
Router# show running-config interface gigabitethernet 5/6
Building configuration...
!
Current configuration:
interface GigabitEthernet5/6
no ip address
switchport access vlan 200
switchport mode access
end
Router# show interfaces gigabitethernet 5/6 switchport
Name: Gi5/6
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Enabled
Access Mode VLAN: 200 (VLAN0200)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: ALL
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-14
Chapter 11
LAN Ports for Layer 2 Switching
How to Configure LAN Interfaces for Layer 2 Switching
Configuring a Custom IEEE 802.1Q EtherType Field Value
You can configure a custom EtherType field value on a port to support network devices that do not use
the standard 0x8100 EtherType field value on 802.1Q-tagged or 802.1p-tagged frames.
To configure a custom value for the EtherType field, perform this task:
Command
Purpose
Router(config-if)# switchport dot1q ethertype value
Configures the 802.1Q EtherType field value for the port.
When configuring a custom EtherType field value, note the following information:
Caution
•
To use a custom EtherType field value, all network devices in the traffic path across the network
must support the custom EtherType field value.
•
You can configure a custom EtherType field value on trunk ports, access ports, and tunnel ports.
•
You can configure a custom EtherType field value on the member ports of an EtherChannel.
•
You cannot configure a custom EtherType field value on a port-channel interface.
•
Each port supports only one EtherType field value. A port that is configured with a custom
EtherType field value does not recognize frames that have any other EtherType field value as tagged
frames. For example, a trunk port that is configured with a custom EtherType field value does not
recognize the standard 0x8100 EtherType field value on 802.1Q-tagged frames and cannot put the
frames into the VLAN to which they belong.
A port that is configured with a custom EtherType field value considers frames that have any other
EtherType field value to be untagged frames. A trunk port with a custom EtherType field value places
frames with any other EtherType field value into the native VLAN. An access port or tunnel port with a
custom EtherType field value places frames that are tagged with any other EtherType field value into the
access VLAN. If you misconfigure a custom EtherType field value, frames might be placed into the
wrong VLAN.
•
See the Release Notes for Cisco IOS Release 15.1SY for a list of the modules that support custom
IEEE 802.1Q EtherType field values:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/release_notes.html
This example shows how to configure the EtherType field value to 0x1234:
Router (config-if)# switchport dot1q ethertype 1234
Router (config-if)#
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-15
Chapter 11
How to Configure LAN Interfaces for Layer 2 Switching
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
11-16
LAN Ports for Layer 2 Switching
CH AP TE R
12
Flex Links
Note
•
Prerequisites for Flex Links, page 12-1
•
Restrictions for Flex Links, page 12-2
•
Information About Flex Links, page 12-2
•
Default Settings for Flex Links, page 12-4
•
How to Configure Flex Links, page 12-4
•
Monitoring Flex Links, page 12-6
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Flex Links
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-1
Chapter 12
Flex Links
Restrictions for Flex Links
Restrictions for Flex Links
•
You can configure only one Flex Links backup link for any active link, and it must be a different
interface from the active interface.
•
An interface can belong to only one Flex Links pair. An interface can be a backup link for only one
active link. An active link cannot belong to another Flex Links pair.
•
Neither of the links can be a port that belongs to an EtherChannel. However, you can configure two
port channels (EtherChannel logical interfaces) as Flex Links, and you can configure a port channel
and a physical interface as Flex Links, with either the port channel or the physical interface as the
active link.
•
A backup link does not have to be the same type as the active link (Fast Ethernet, Gigabit Ethernet,
or port channel). However, you should configure both Flex Links with similar characteristics so that
there are no loops or changes in operation if the standby link becomes active.
•
STP is disabled on Flex Links ports. If STP is disabled on the switch, be sure that there are no
Layer 2 loops in the network topology.
•
Do not configure any STP features (for example, PortFast, BPDU Guard, and so forth) on Flex Links
ports or the ports to which the links connect.
•
Local administrative shut down or a link that starts forwarding again due to preemption is not
considered a link failure. In those cases, the feature flushes the dynamic hosts and and does not move
them.
•
Static MAC addresses that are configured on the primary link are not moved to the standby link.
•
Static MAC addresses configured on a flex links port are restored when it starts forwarding again.
Information About Flex Links
Flex Links are a pair of Layer 2 interfaces (ports or port channels), where one interface is configured to
act as a backup to the other. Flex Links are typically configured in service-provider or enterprise
networks where customers do not want to run STP. Flex Links provide link-level redundancy that is an
alternative to Spanning Tree Protocol (STP). STP is automatically disabled on Flex Links interfaces.
Release 15.1SY supports a maximum of 16 Flex Links. Flex Links are supported only on Layer 2 ports
and port channels, not on VLANs or on Layer 3 ports.
To configure the Flex Links feature, you configure one Layer 2 interface as the standby link for the link
that you want to be primary. With Flex Links configured for a pair of interfaces, only one of the
interfaces is in the linkup state and is forwarding traffic. If the primary link shuts down, the standby link
starts forwarding traffic. When the inactive link comes back up, it goes into standby mode.
In Figure 12-1, ports 1 and 2 on switch A are connected to uplink switches B and C. Because they are
configured as Flex Links, only one of the interfaces is forwarding traffic and the other one is in standby
mode. If port 1 is the active link, it begins forwarding traffic between port 1 and switch B; the link
between port 2 (the backup link) and switch C is not forwarding traffic. If port 1 goes down, port 2 comes
up and starts forwarding traffic to switch C. When port 1 comes back up, it goes into standby mode and
does not forward traffic; port 2 continues to forward traffic.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-2
Flex Links
Information About Flex Links
Figure 12-1
Flex Links Configuration Example
B
C
Port 1
Port 2
140036
Chapter 12
A
If a primary (forwarding) link goes down, a trap notifies the network management stations. If the standby
link goes down, a trap notifies the users.When a primary link fails, the feature takes these actions:
•
Detects the failure.
•
Moves any dynamic unicast MAC addresses that are learned on the primary link to the standby link.
•
Moves the standby link to a forwarding state.
•
Transmits dummy multicast packets over the new active interface. The dummy multicast packet
format is:
– Destination: 01:00:0c:cd:cd:cd
– Source: MAC address of the hosts or ports on the newly active Flex Link port.
In Figure 12-2, ports 1 and 2 on switch A are connected to switches B and D through a Flex Link
pair. Port 1 is forwarding traffic, and port 2 is in the blocking state. Traffic from the PC to the server
is forwarded from port 1 to port 3. The MAC address of the PC has been learned on port 3 of switch
C. Traffic from the server to the PC is forwarded from port 3 to port 1.
If port 1 shuts down, port 2 starts forwarding traffic. If there is no traffic from the PC to the server
after failover to port 2, switch C does not learn the MAC address of the PC on port 4, and because
of that, switch C keeps forwarding traffic from the server to the PC out of port 3. There is traffic loss
from the server to the PC because port 1 is down. To alleviate this problem, the feature sends out a
dummy multicast packet with the source MAC address of the PC over port 2. Switch C learns the
PC MAC address on port 4 and start forwarding traffic from the server to the PC out of port 4. One
dummy multicast packet is sent out for every MAC address.
Flex links interface preemption specifies one of the ports in a flex links pair as preferred for traffic
forwarding. The preference can be unconditional or it can be based on bandwidth availability. See the
“How to Configure Flex Links” section on page 12-4.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-3
Chapter 12
Default Settings for Flex Links
Figure 12-2
Flexlink Dummy Multicast Packets Example
Server
Switch C
Port 4
Port 3
Switch B
Switch D
Port 1
Port 2
141223
Switch A
PC
Default Settings for Flex Links
•
Flex links: not configured.
•
Flex links interface preemption: not configured.
•
Flex links interface preemption delay: 35 seconds.
How to Configure Flex Links
To configure Flex Links, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(conf)# interface {{type slot/port} |
{port-channel number}}
Specifies a Layer 2 interface.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-4
Flex Links
Chapter 12
Flex Links
How to Configure Flex Links
Step 3
Step 4
Step 5
Step 6
Command
Purpose
Router(conf-if)# switchport backup interface
interface_id
Configures the interface as part of a flex links pair.
Router(conf-if)# switchport backup interface
interface_id preemption mode
[forced | bandwidth | off]
Router(conf-if)# switchport backup interface
interface_id preemption delay delay_time
Router(conf-if)# exit
•
The interface_id specifies can be a physical port or a
port-channel interface.
•
The backup interface must already be configured as a
Layer 2 port.
(Optional) Configures the preferred flex links interface
preemption port in the flex links pair.
•
The interface_id can be a physical port or a
port-channel interface.
•
forced—the active interface always preempts the
backup.
•
bandwidth—the interface with the higher bandwidth
always acts as the active interface.
•
off—no preemption happens from active to backup.
(Optional) Configures the flex links interface preemption
delay time for the flex links pair.
•
The interface_id can be a physical port or a
port-channel interface.
•
The range for delay_time is 1 through 300 seconds.
Exits configuration mode.
This example shows how to configure an interface with a flex links backup interface and how to verify
the configuration:
Router# configure terminal
Router(conf)# interface tengigabitethernet 2/9
Router(conf-if)# switchport backup interface tengigabitethernet 2/12
Router(conf-if)# switchport backup interface tengigabitethernet 2/12 preemption mode
[forced | bandwidth | off]
Router(conf-if)# switchport backup interface tengigabitethernet 2/12 preemption delay 35
Router(conf-if)# exit
Router# show interface switchport backup detail
Switch Backup Interface Pairs:
Active Interface
Backup Interface
State
-----------------------------------------------------------------------Te2/9
Te2/12
Active Up/Backup Standby
Interface Pair
: Te2/9, Te2/12
Preemption Mode : forced
Preemption Delay : 35 seconds (default)
Bandwidth : 10000000 Kbit (Te2/9), 10000000 Kbit (Te2/12)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-5
Chapter 12
Flex Links
Monitoring Flex Links
Monitoring Flex Links
To monitor the Flex Links configuration, perform this task:
Command
Purpose
show interface [{type slot/port} | {port-channel
number}] switchport backup
Displays the Flex Links backup interface configured for an
interface, or displays all Flex Links configured on the switch
and the state of each active and backup interface (up or
standby mode).
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
12-6
CH AP TE R
13
EtherChannels
Note
•
Prerequisites for EtherChannels, page 13-1
•
Restrictions for EtherChannels, page 13-2
•
Information About EtherChannels, page 13-3
•
Default Settings for EtherChannels, page 13-7
•
How to Configure EtherChannels, page 13-7
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for EtherChannels
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-1
Chapter 13
EtherChannels
Restrictions for EtherChannels
Restrictions for EtherChannels
Caution
•
LACP EtherChannels and the 802.1ad provider-bridge mode are mutually exclusive. LACP
EtherChannels cannot transmit traffic when the 802.1ad provider-bridge mode is enabled.
•
LACP 1:1 redundancy must be enabled at both ends of the LACP EtherChannel.
•
LACP does not support half-duplex links. Half-duplex links in an LACP EtherChannel are put in the
suspended state.
Serious traffic problems can result from mixing manual mode with LACP mode, or by connecting an
EtherChannel member port to a port not configured as part of the EtherChannel. For example, if a port
configured in on mode is connected to another port configured in desirable mode, or to a port not
configured as a member of the EtherChannel, a bridge loop is created and a broadcast storm can occur.
If one end uses the on mode, the other end must also.
•
When EtherChannel interfaces are configured improperly, they are disabled automatically to avoid
network loops and other problems.
•
Frames with SAP/SNAP encapsulation are load-balanced as Layer 2 traffic.
•
The commands in this chapter can be used on all Layer 2 Ethernet ports, including the ports on the
supervisor engine and a redundant supervisor engine.
•
All Layer 2 Ethernet ports on all modules, including those on a redundant supervisor engine, support
EtherChannels (maximum of eight LAN ports) with no requirement that the LAN ports be physically
contiguous or on the same module.
•
Configure all LAN ports in an EtherChannel to use the same EtherChannel protocol; you cannot run
two EtherChannel protocols in one EtherChannel.
•
Configure all LAN ports in an EtherChannel to operate at the same speed and in the same duplex
mode.
•
Enable all LAN ports in an EtherChannel. If you shut down a LAN port in an EtherChannel, it is
treated as a link failure and its traffic is transferred to one of the remaining ports in the
EtherChannel.
•
An EtherChannel will not form if any of the LAN ports is a Switched Port Analyzer (SPAN)
destination port.
•
For Layer 3 EtherChannels, assign Layer 3 addresses to the port channel logical interface, not to the
LAN ports in the channel.
•
For Layer 2 EtherChannels:
– Assign all LAN ports in the EtherChannel to the same VLAN or configure them as trunks.
– If you configure an EtherChannel from trunking LAN ports, verify that the trunking mode is the
same on all the trunks. LAN ports in an EtherChannel with different trunk modes can operate
unpredictably.
– An EtherChannel supports the same allowed range of VLANs on all the LAN ports in a trunking
Layer 2 EtherChannel. If the allowed range of VLANs is not the same, the LAN ports do not
form an EtherChannel.
– LAN ports with different STP port path costs can form an EtherChannel as long they are
compatibly configured with each other. If you set different STP port path costs, the LAN ports
are not incompatible for the formation of an EtherChannel.
– An EtherChannel will not form if protocol filtering is set differently on the LAN ports.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-2
Chapter 13
EtherChannels
Information About EtherChannels
– Configure static MAC addresses on the EtherChannel only and not on physical member ports
of the EtherChannel.
•
After you configure an EtherChannel, the configuration that you apply to the port channel interface
affects the EtherChannel. The configuration that you apply to the LAN ports affects only the LAN
port where you apply the configuration.
•
Cisco IOS Release 15.1SY does not support ISL trunk encapsulation. If a non-trunking Layer 2
EtherChannel includes member ports that that are not capable of ISL trunk encapsulation, the
switchport trunk encapsulation dot1q command is added to the port-channel interface. The
command has no affect when the switchport mode is “access” (CSCta45114).
•
When QoS is enabled, enter the no platform qos channel-consistency port-channel interface
command to support EtherChannels that have ports with and without strict-priority queues.
•
On Cisco Catalyst 6500 Series Switches running IOS 15.x, after the physical interfaces are bundled
into a L2 logical port-channel interface, the 'switchport' commands defined on the physical interface
members are replicated to the logical port-channel interface after six seconds. This delay is expected
and the duration does not increase due to factors such as system utilization.
The behavior is expected because Cisco Catalyst 6500 Series Switches have a well separated control
/ data-plane architecture. When you change a system wide configuration attribute, such as the
interface speed or shut/no-shut of an interface, the corresponding actions/attributes need to be
applied to corresponding data-plane elements. This requires pushing certain parameters to the data
path firmware that further updates hardware register and so on as needed.
Information About EtherChannels
•
EtherChannel Feature Overview, page 13-3
•
Information about EtherChannel Configuration, page 13-4
•
Information about Port Channel Interfaces, page 13-7
•
Information about LACP 1:1 Redundancy, page 13-6
•
Information about Load Balancing, page 13-7
EtherChannel Feature Overview
An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate
bandwidth of up to eight physical links.
Cisco IOS Release 15.1SY supports a maximum of 256 EtherChannels in standalone mode and
512 EtherChannels in VVS mode. You can form an EtherChannel with up to eight compatibly configured
LAN ports on any switching module. All LAN ports in each EtherChannel must be the same speed and
must all be configured as either Layer 2 or Layer 3 LAN ports.
Note
The network device to which a switch is connected may impose its own limits on the number of ports in
an EtherChannel.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-3
Chapter 13
EtherChannels
Information About EtherChannels
If a segment within an EtherChannel fails, traffic previously carried over the failed link switches to the
remaining segments within the EtherChannel. When a failure occurs, the EtherChannel feature sends a
trap that identifies the switch, the EtherChannel, and the failed link. Inbound broadcast and multicast
packets on one segment in an EtherChannel are blocked from returning on any other segment of the
EtherChannel.
Information about EtherChannel Configuration
•
EtherChannel Configuration Overview, page 13-4
•
Information about Manual EtherChannel Configuration, page 13-5
•
Information about PAgP EtherChannel Configuration, page 13-5
•
Information about IEEE 802.3ad LACP EtherChannel Configuration, page 13-5
EtherChannel Configuration Overview
You can configure EtherChannels manually or you can use the Port Aggregation Control Protocol
(PAgP) or the Link Aggregation Control Protocol (LACP) to form EtherChannels. The EtherChannel
protocols allow ports with similar characteristics to form an EtherChannel through dynamic negotiation
with connected network devices. PAgP is a Cisco-proprietary protocol and LACP is defined in IEEE
802.3ad.
PAgP and LACP do not interoperate with each other. Ports configured to use PAgP cannot form
EtherChannels with ports configured to use LACP. Ports configured to use LACP cannot form
EtherChannels with ports configured to use PAgP. Neither interoperates with ports configured manually.
Table 13-1 lists the user-configurable EtherChannel modes.
Table 13-2 lists the EtherChannel member port states.
Table 13-1
EtherChannel Modes
Mode
Description
on
Mode that forces the LAN port to channel unconditionally. In the on mode, a usable
EtherChannel exists only when a LAN port group in the on mode is connected to another
LAN port group in the on mode. Because ports configured in the on mode do not negotiate,
there is no negotiation traffic between the ports. You cannot configure the on mode with
an EtherChannel protocol. If one end uses the on mode, the other end must also.
auto
PAgP mode that places a LAN port into a passive negotiating state, in which the port
responds to PAgP packets it receives but does not initiate PAgP negotiation. (Default)
desirable
PAgP mode that places a LAN port into an active negotiating state, in which the port
initiates negotiations with other LAN ports by sending PAgP packets.
passive
LACP mode that places a port into a passive negotiating state, in which the port responds
to LACP packets it receives but does not initiate LACP negotiation. (Default)
active
LACP mode that places a port into an active negotiating state, in which the port initiates
negotiations with other ports by sending LACP packets.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-4
Chapter 13
EtherChannels
Information About EtherChannels
Table 13-2
EtherChannel Member Port States
Port States
Description
bundled
The port is part of an EtherChannel and can send and receive BPDUs and data traffic.
suspended
The port is not part of an EtherChannel. The port can receive BPDUs but cannot send
them. Data traffic is blocked.
standalone
The port is not bundled in an EtherChannel. The port functions as a standalone data port.
The port can send and receive BPDUs and data traffic.
Note
When one end of an EtherChannel has more members than the other, the
unmatched ports enter the standalone state. In a topology that is not protected
from Layer 2 loops by the spanning tree protocol (STP), a port in the standalone
state can cause significant network errors. You can enter the port-channel
standalone-disable interface configuration mode command to put ports into the
suspended state instead of the standalone state. See the “Configuring LACP
Port-Channel Standalone Disable” section on page 13-16.
Information about Manual EtherChannel Configuration
Manually configured EtherChannel ports do not exchange EtherChannel protocol packets. A manually
configured EtherChannel forms only when you configure all ports in the EtherChannel compatibly.
Information about PAgP EtherChannel Configuration
PAgP supports the automatic creation of EtherChannels by exchanging PAgP packets between LAN
ports. PAgP packets are exchanged only between ports in auto and desirable modes.
The protocol learns the capabilities of LAN port groups dynamically and informs the other LAN ports.
Once PAgP identifies correctly matched Ethernet links, it facilitates grouping the links into an
EtherChannel. The EtherChannel is then added to the spanning tree as a single bridge port.
Both the auto and desirable modes allow PAgP to negotiate between LAN ports to determine if they can
form an EtherChannel, based on criteria such as port speed and trunking state. Layer 2 EtherChannels
also use VLAN numbers.
LAN ports can form an EtherChannel when they are in different PAgP modes if the modes are
compatible. For example:
•
A LAN port in desirable mode can form an EtherChannel successfully with another LAN port that
is in desirable mode.
•
A LAN port in desirable mode can form an EtherChannel with another LAN port in auto mode.
•
A LAN port in auto mode cannot form an EtherChannel with another LAN port that is also in auto
mode, because neither port will initiate negotiation.
Information about IEEE 802.3ad LACP EtherChannel Configuration
LACP supports the automatic creation of EtherChannels by exchanging LACP packets between LAN
ports. LACP packets are exchanged only between ports in passive and active modes.
The protocol learns the capabilities of LAN port groups dynamically and informs the other LAN ports.
Once LACP identifies correctly matched Ethernet links, it facilitates grouping the links into an
EtherChannel. The EtherChannel is then added to the spanning tree as a single bridge port.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-5
Chapter 13
EtherChannels
Information About EtherChannels
Both the passive and active modes allow LACP to negotiate between LAN ports to determine if they can
form an EtherChannel, based on criteria such as port speed and trunking state. Layer 2 EtherChannels
also use VLAN numbers.
LAN ports can form an EtherChannel when they are in different LACP modes as long as the modes are
compatible. For example:
•
A LAN port in active mode can form an EtherChannel successfully with another LAN port that is
in active mode.
•
A LAN port in active mode can form an EtherChannel with another LAN port in passive mode.
•
A LAN port in passive mode cannot form an EtherChannel with another LAN port that is also in
passive mode, because neither port will initiate negotiation.
LACP uses the following parameters:
•
LACP system priority—You must configure an LACP system priority on each switch running LACP.
The system priority can be configured automatically or through the CLI (see the “Configuring the
LACP System Priority and System ID” section on page 13-11). LACP uses the system priority with the
switch MAC address to form the system ID and also during negotiation with other systems.
Note
The LACP system ID is the combination of the LACP system priority value and the MAC
address of the switch.
•
LACP port priority—You must configure an LACP port priority on each port configured to use
LACP. The port priority can be configured automatically or through the CLI (see the “Configuring
Channel Groups” section on page 13-9). LACP uses the port priority with the port number to form the
port identifier. LACP uses the port priority to decide which ports should be put in standby mode
when there is a hardware limitation that prevents all compatible ports from aggregating.
•
LACP administrative key—LACP automatically configures an administrative key value equal to the
channel group identification number on each port configured to use LACP. The administrative key
defines the ability of a port to aggregate with other ports. A port’s ability to aggregate with other
ports is determined by these factors:
– Port physical characteristics, such as data rate, duplex capability, and point-to-point or shared
medium
– Configuration restrictions that you establish
On ports configured to use LACP, LACP tries to configure the maximum number of compatible ports in
an EtherChannel, up to the maximum allowed by the hardware (eight ports). If LACP cannot aggregate
all the ports that are compatible (for example, the remote system might have more restrictive hardware
limitations), then all the ports that cannot be actively included in the channel are put in hot standby state
and are used only if one of the channeled ports fails. You can configure an additional 8 standby ports
(total of 16 ports associated with the EtherChannel).
Information about LACP 1:1 Redundancy
The LACP 1:1 redundancy feature supports an EtherChannel configuration with one active link and fast
switchover to a hot standby link. The link connected to the port with the lower port priority number (and
therefore a higher priority) will be the active link, and the other link will be in a hot standby state. If the
active link goes down, LACP performs fast switchover to the hot standby link to keep the EtherChannel
up. When the failed link becomes operational again, LACP performs another fast switchover to revert to
the original active link.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-6
Chapter 13
EtherChannels
Default Settings for EtherChannels
To allow the higher priority port to stabilize when it becomes active again after a higher-priority to
lower-priority switchover, the LACP 1:1 hot standby dampening feature configures a timer that delays
switchover back to the higher priority port after it becomes active.
See the “Configuring LACP 1:1 Redundancy” section on page 13-14.
Information about Port Channel Interfaces
Each EtherChannel has a numbered port channel interface. You can configure a maximum of 512
port-channel interfaces, numbered from 1 to 512 in VSS mode. In the stand-alone, the max number of
port channel interfaces is 256, numbered from 1 to 256. The configuration that you apply to the port
channel interface affects all LAN ports assigned to the port channel interface.
After you configure an EtherChannel, the configuration that you apply to the port channel interface
affects the EtherChannel; the configuration that you apply to the LAN ports affects only the LAN port
where you apply the configuration. To change the parameters of all ports in an EtherChannel, apply the
configuration commands to the port channel interface, for example, Spanning Tree Protocol (STP)
commands or commands to configure a Layer 2 EtherChannel as a trunk.
Information about Load Balancing
An EtherChannel balances the traffic load across the links in an EtherChannel by reducing part of the
binary pattern formed from the addresses in the frame to a numerical value that selects one of the links
in the channel.
EtherChannel load balancing can use MAC addresses or IP addresses. EtherChannel load balancing can
also use Layer 4 port numbers. EtherChannel load balancing can use either source or destination or both
source and destination addresses or ports. The selected mode applies to all EtherChannels configured on
the switch. EtherChannel load balancing can use MPLS Layer 2 information.
Use the option that provides the balance criteria with the greatest variety in your configuration. For
example, if the traffic on an EtherChannel is going only to a single MAC address and you use the
destination MAC address as the basis of EtherChannel load balancing, the EtherChannel always chooses
the same link in the EtherChannel; using source addresses or IP addresses might result in better load
balancing.
Default Settings for EtherChannels
None.
How to Configure EtherChannels
•
Configuring Port Channel Logical Interfaces, page 13-8
•
Configuring Channel Groups, page 13-9
•
Configuring the LACP System Priority and System ID, page 13-11
•
Configuring EtherChannel Load Balancing, page 13-11
•
Configuring the EtherChannel Hash-Distribution Algorithm, page 13-12
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-7
Chapter 13
EtherChannels
How to Configure EtherChannels
Note
•
Configuring the EtherChannel Min-Links Feature, page 13-13
•
Configuring LACP 1:1 Redundancy, page 13-14
•
Configuring Auto Interleaved Port Priority For LACP Port Channels, page 13-15
•
Configuring LACP Port-Channel Standalone Disable, page 13-16
Make sure that the LAN ports are configured correctly (see the “Restrictions for EtherChannels” section
on page 13-2).
Configuring Port Channel Logical Interfaces
Note
To move an IP address from a Layer 3 LAN port to an EtherChannel, you must delete the IP address from
the Layer 3 LAN port before configuring it on the port channel logical interface.
To create a port channel interface for a Layer 3 EtherChannel, perform this task:
Command
Purpose
Step 1
Router(config)# interface port-channel group_number
Creates the port channel interface.
Step 2
Router(config-if)# ip address ip_address mask
Assigns an IP address and subnet mask to the
EtherChannel.
Step 3
Router(config-if)# end
Exits configuration mode.
The group_number can be 1 through 256, up to a maximum of 256 port-channel interfaces in standalone
mode. In VSS-mode the group number can be through 1 through 512, up to a maximum of 512 port
channel-interfaces. This example shows how to create port channel interface 1:
Router# configure terminal
Router(config)# interface port-channel 1
Router(config-if)# ip address 172.32.52.10 255.255.255.0
Router(config-if)# end
This example shows how to verify the configuration of port channel interface 1:
Router# show running-config interface port-channel 1
Building configuration...
Current configuration:
!
interface Port-channel1
ip address 172.32.52.10 255.255.255.0
no ip directed-broadcast
end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-8
Chapter 13
EtherChannels
How to Configure EtherChannels
Configuring Channel Groups
Note
For Cisco IOS to create port channel interfaces for Layer 2 EtherChannels, the Layer 2 LAN ports must
be connected and functioning.
To configure channel groups, perform this task for each LAN port:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects a LAN port to configure.
Step 2
Router(config-if)# no ip address
Ensures that there is no IP address assigned to the LAN
port.
Step 3
Router(config-if)# channel-protocol (lacp | pagp}
(Optional) On the selected LAN port, restricts the
channel-group command to the EtherChannel protocol
configured with the channel-protocol command.
Step 4
Router(config-if)# channel-group group_number
mode {active | auto | desirable | on | passive}
Configures the LAN port in a port channel and specifies
the mode (see Table 13-1 on page 13-4). PAgP supports
only the auto and desirable modes. LACP supports only
the active and passive modes.
Step 5
Router(config-if)# lacp port-priority
priority_value
(Optional for LACP) Valid values are 1 through 65535.
Higher numbers have lower priority. The default is 32768.
Step 6
Router(config-if)# do show interface port-channel
group_number
(Optional) Displays the interface configuration
information of the specified port channel.
Note: The output of this command shows that the newly
created port channel interface will be in shutdown state.
Step 7
Router(config-if)# no shutdown
Brings the port channel and its members up and all the
configuration changes that you apply to the port channel
is applied to every member interface of that port channel.
Step 8
Router(config-if)# end
Exits configuration mode.
This example shows how to configure Gigabit Ethernet ports 5/6 and 5/7 into port channel 2 with PAgP
mode desirable:
Router# configure terminal
Router(config)# interface range gigabitethernet 5/6 -7
Router(config-if)# channel-group 2 mode desirable
Router(config-if)# no shutdown
Router(config-if)# end
Note
See the “How to Configure a Range of Interfaces” section on page 10-2 for information about the range
keyword.
This example shows how to verify the configuration of port channel interface 2:
Router# show running-config interface port-channel 2
Building configuration...
Current configuration:
!
interface Port-channel2
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-9
Chapter 13
EtherChannels
How to Configure EtherChannels
no ip address
switchport
switchport access vlan 10
switchport mode access
end
Router#
This example shows how to verify the configuration of Gigabit Ethernet port 5/6:
Router# show running-config interface gigabitethernet 5/6
Building configuration...
Current configuration:
!
interface GigabitEthernet5/6
no ip address
switchport
switchport access vlan 10
switchport mode access
channel-group 2 mode desirable
end
Router# show interfaces gigabitethernet 5/6 etherchannel
Port state
= Down Not-in-Bndl
Channel group = 12
Mode = Desirable-Sl
Gcchange = 0
Port-channel = null
GC
= 0x00000000
Pseudo port-channel = Po1
2
Port index
= 0
Load = 0x00
Protocol =
PAgP
Flags:
S
A
d
Timers: H
S
-
Device is sending Slow hello.
Device is in Auto mode.
PAgP is down.
Hello timer is running.
Switching timer is running.
C - Device is in Consistent state.
P - Device learns on physical port.
Q - Quit timer is running.
I - Interface timer is running.
Local information:
Port
Gi5/2
Flags State
d
U1/S1
Timers
Hello
Partner PAgP
Interval Count
Priority
1s
0
128
Learning Group
Method Ifindex
Any
0
Age of the port in the current state: 04d:18h:57m:19s
This example shows how to verify the configuration of port channel interface 2 after the LAN ports have
been configured:
Router# show etherchannel 12 port-channel
Port-channels in the group:
---------------------Port-channel: Po12
-----------Age of the Port-channel
= 04d:18h:58m:50s
Logical slot/port
= 14/1
Number of ports = 0
GC
= 0x00000000
HotStandBy port = null
Port state
= Port-channel Ag-Not-Inuse
Protocol
=
PAgP
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-10
Chapter 13
EtherChannels
How to Configure EtherChannels
Configuring the LACP System Priority and System ID
The LACP system ID is the combination of the LACP system priority value and the MAC address of the
switch.
To configure the LACP system priority and system ID, perform this task:
Command
Purpose
Step 1
Router(config)# lacp system-priority value
(Optional for LACP) Valid values are 1 through 65535. Higher
numbers have lower priority. The default is 32768.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to configure the LACP system priority:
Router# configure terminal
Router(config)# lacp system-priority 23456
Router(config)# end
Router(config)#
This example shows how to verify the configuration:
Router# show lacp sys-id
23456,0050.3e8d.6400
Router#
The system priority is displayed first, followed by the MAC address of the switch.
Configuring EtherChannel Load Balancing
To configure EtherChannel load balancing, perform this task:
Command
Purpose
Step 1
Router(config)# port-channel per-module
load-balance
(Optional) Enables the ability to specify the
load-balancing method on a per-module basis.
Step 2
Router(config)# port-channel load-balance
[all | fex fex_number] method [module slot]
Configures the EtherChannel load-balancing method. The
method is globally applied to all port channels.
Optionally, you can configure the load-balancing method
for a specific module. The default method is src-dst-ip.
Note
• If you configure EtherChannel load balancing on a
switch that is not in VSS mode, traffic is disrupted
while the EtherChannel member ports transition
through the shutdown and then no shutdown states.
•
Step 3
Router(config)# end
There is no disruption on switches in VSS mode.
Exits configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-11
Chapter 13
EtherChannels
How to Configure EtherChannels
The load-balancing method keywords indicate the following information:
•
dst-ip—Destination IP addresses
•
dst-mac—Destination MAC addresses
•
dst-mixed-ip-port—Destination IP address and TCP/UDP port
•
dst-port—Destination Layer 4 port
•
mpls—Load balancing for MPLS packets
•
src-dst-ip—(Default) Source and destination IP addresses
•
src-dst-mac—Source and destination MAC addresses
•
src-dst-mixed-ip-port—Source and destination IP address and TCP/UDP port
•
src-dst-port—Source and destination Layer 4 port
•
src-ip—Source IP addresses
•
src-mac—Source MAC addresses
•
src-mixed-ip-port—Source IP address and TCP/UDP port
•
src-port—Source Layer 4 port
•
vlan-dst-ip—VLAN number and destination IP address
•
vlan-dst-mixed-ip-port—VLAN number and destination IP address and TCP/UDP port
•
vlan-src-dst-ip—VLAN number and source and destination IP address
•
vlan-src-dst-mixed-ip-port—VLAN number and source and destination IP address and TCP/UDP port
•
vlan-src-ip—VLAN number and source IP address
•
vlan-src-mixed-ip-port—VLAN number and source IP address and TCP/UDP port
The optional module keyword allows you to specify the load-balancing method for a specific module.
This capability is supported only on DFC-equipped switching modules. You must enable per-module
load balancing globally before configuring the feature on a module.
This example shows how to configure EtherChannel to use source and destination IP addresses:
Router# configure terminal
Router(config)# port-channel load-balance src-dst-ip
Router(config)# end
Router(config)#
This example shows how to verify the configuration:
Router# show etherchannel load-balance
Source XOR Destination IP address
Configuring the EtherChannel Hash-Distribution Algorithm
When you add a port to an EtherChannel or delete a port from an EtherChannel, the fixed algorithm
updates the port ASIC for each port in the EtherChannel, which causes a short outage on each port.
The default adaptive algorithm does not need to update the port ASIC for existing member ports. You
can configure a global value for the adaptive algorithm. You can also specify the algorithm for individual
port channels.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-12
Chapter 13
EtherChannels
How to Configure EtherChannels
When you change the algorithm, the change is applied at the next member link event (link down, link
up, addition, deletion, no shutdown, and shutdown). When you enter the command to change the
algorithm, the command console issues a warning that the command does not take effect until the next
member link event.
Note
•
Some external devices require the fixed algorithm. For example, the service control engine (SCE)
requires incoming and outgoing packets to use the same port.
•
If you change the load-balancing method, EtherChannel ports on DFC-equipped switching modules
or on an active supervisor engine in a dual supervisor engine configuration will flap.
Configuring the Hash-Distribution Algorithm Globally
To configure the load-sharing algorithm globally, perform this task:
Command
Purpose
Step 1
Router(config)# port-channel hash-distribution
{adaptive | fixed}
Sets the hash distribution algorithm to adaptive or
fixed.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to globally set the hash distribution to adaptive:
Router(config)# port-channel hash-distribution adaptive
Configuring the Hash-Distribution Algorithm for a Port Channel
To configure the hash-distribution algorithm for a specific port channel, perform this task:
Command
Purpose
Step 1
Router(config)# interface port-channel
channel-num
Enters interface configuration mode for the port channel.
Step 2
Router(config-if)# port-channel port
hash-distribution {adaptive | fixed}
Sets the hash distribution algorithm for this interface
Step 3
Router(config-if)# end
Exits interface configuration mode.
This example shows how to set the hash distribution algorithm to adaptive on port channel 10:
Router (config)# interface port-channel 10
Router (config-if)# port-channel port hash-distribution adaptive
Configuring the EtherChannel Min-Links Feature
The EtherChannel min-links feature is supported on LACP EtherChannels. This feature allows you to
configure the minimum number of member ports that must be in the link-up state and bundled in the
EtherChannel for the port channel interface to transition to the link-up state. You can use the
EtherChannel min-links feature to prevent low-bandwidth LACP EtherChannels from becoming active.
This feature also causes LACP EtherChannels to become inactive if they have too few active member
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-13
Chapter 13
EtherChannels
How to Configure EtherChannels
ports to supply your required minimum bandwidth. In addition, when LACP max-bundle values are
specified in conjunction with min-links, the configuration is verified and an error message is returned if
the min-links value is not compatible with (equal to or less than) the max-bundle value.
To configure the EtherChannel min-links feature, perform this task:
Command
Purpose
Step 1
Router(config)# interface port-channel group_number
Selects an LACP port channel interface.
Step 2
Router(config-if)# port-channel min-links number
Configures the minimum number of member ports that
must be in the link-up state and bundled in the
EtherChannel for the port channel interface to
transition to the link-up state.
Step 3
Router(config-if)# end
Exits configuration mode.
Note
Although the EtherChannel min-links feature works correctly when configured only on one end of an
EtherChannel, for best results, configure the same number of minimum links on both ends of the
EtherChannel.
This example shows how to configure port channel interface 1 to be inactive if fewer than two member
ports are active in the EtherChannel:
Router# configure terminal
Router(config)# interface port-channel 1
Router(config-if)# port-channel min-links 2
Router(config-if)# end
Configuring LACP 1:1 Redundancy
To configure the LACP 1:1 redundancy feature, perform this task:
Command
Purpose
Step 1
Router(config)# interface port-channel group_number
Selects an LACP port channel interface.
Step 2
Router(config-if)# lacp fast-switchover
Enables the LACP 1:1 redundancy feature on the
EtherChannel.
Step 3
Router(config-if)# lacp max-bundle 1
Sets the maximum number of active member ports
to be one. The only value supported with LACP 1:1
redundancy is “1”.
Step 4
Router(config-if)# lacp fast-switchover dampening
seconds
(Optional) Enables the LACP 1:1 hot standby
dampening feature for this EtherChannel. The
range for the time parameter is 35 through 180
seconds.
Step 5
Router(config-if)# end
Exits configuration mode.
Note
LACP 1:1 redundancy must be enabled at both ends of the LACP EtherChannel.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-14
Chapter 13
EtherChannels
How to Configure EtherChannels
This example shows how to configure an LACP EtherChannel with 1:1 redundancy. Because Gigabit
Ethernet port 5/6 is configured with a higher port priority number (and therefore a lower priority) than
the default of 32768, it will be the standby port.
Router# configure terminal
Router(config)# lacp system-priority 33000
Router(config)# interface range gigabitethernet 5/6 -7
Router(config-if)# channel-protocol lacp
Router(config-if)# channel-group 1 mode active
Router(config)# interface gigabitethernet 5/6
Router(config-if)# lacp port-priority 33000
Router(config)# interface port-channel 1
Router(config-if)# lacp fast-switchover
Router(config-if)# lacp max-bundle 1
Router(config-if)# lacp fast-switchover dampening 30
Router(config-if)# end
Configuring Auto Interleaved Port Priority For LACP Port Channels
To configure auto interleaved port priority for LACP on a port channel, perform this task on the port
channel interface:
Command
Purpose
Step 1
Router(config)# interface port-channel
channel-group
Selects a port channel interface to configure.
Step 2
Router(config-if)# lacp active-port distribution
automatic
Configures the port channel to use interleaved port
priority.
Note
You need to perform a shutdown and no shutdown
for interleaved port priority to be enabled.
Step 3
Router(config-if)# shutdown
Disables the interface.
Step 4
Router(config-if)# no shutdown
Enables the interface.
Step 5
Router(config-if)# end
Exits configuration mode.
Step 6
Router# show etherchannel channel-group
port-channel
Router# show etherchannel channel-group summary
Verifies the configuration.
This example shows how to configure auto interleaved port priority on a port channel:
Router(config)# interface port-channel23
Router(config-if)# lacp active-port distribution automatic
Please shut/no shut the port-channel for configuration to take effect immediately.
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# end
This example shows how to verify the configuration of port channel interface 23:
Router# show running interfaces port-channel23
Building configuration...
Current configuration : 81 bytes
!
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-15
Chapter 13
EtherChannels
How to Configure EtherChannels
interface Port-channel23
no switchport
no ip address
lacp max-bundle 4
lacp active-port distribution automatic
end
This example shows how to verify the configuration of EtherChannel 23:
Router# show etherchannel 23 summary
Flags:
D
I
H
R
U
f
-
down
P - bundled in port-channel
stand-alone s - suspended
Hot-standby (LACP only)
Layer3
S - Layer2
in use
N - not in use, no aggregation
failed to allocate aggregator
M
m
u
d
-
not in use, no aggregation due to minimum links not met
not in use, port not aggregated due to minimum links not met
unsuitable for bundling
default port
w - waiting to be aggregated
Number of channel-groups in use: 9
Number of aggregators:
9
Group Port-channel Protocol
Ports
------+-------------+-----------+--------------------------------------23
Po23(RU)
LACP
Gi1/1/21(P)
Gi1/1/22(P)
Gi1/1/23(H)
Gi1/1/24(H)
Gi2/1/17(P)
Gi2/1/18(P)
Gi2/1/19(H)
Gi2/1/20(H)
Last applied Hash Distribution Algorithm: Fixed
Note
The above example shows that the four bundled ports are distributed 2 per chassis and slot.
Configuring LACP Port-Channel Standalone Disable
To disable the standalone EtherChannel member port state on a port channel (see Table 13-2 on
page 13-5), perform this task on the port channel interface:
Command
Purpose
Step 1
Router(config)# interface port-channel channel-group
Selects a port channel interface to configure.
Step 2
Router(config-if)# port-channel standalone-disable
Disables the standalone mode on the port-channel
interface.
Step 3
Router(config-if)# end
Exits configuration mode.
Step 4
Router# show etherchannel channel-group port-channel
Router# show etherchannel channel-group detail
Verifies the configuration.
This example shows how to disable the standalone EtherChannel member port state on port channel 42:
Router(config)# interface port-channel channel-group
Router(config-if)# port-channel standalone-disable
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-16
Chapter 13
EtherChannels
How to Configure EtherChannels
This example shows how to verify the configuration:
Router# show etherchannel 42 port-channel | include Standalone
Standalone Disable = enabled
Router# show etherchannel 42 detail | include Standalone
Standalone Disable = enabled
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-17
Chapter 13
How to Configure EtherChannels
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
13-18
EtherChannels
CH AP TE R
14
IEEE 802.1ak MVRP and MRP
Note
•
Prerequisites for IEEE 802.1ak MVRP and MRP, page 14-1
•
Restrictions for IEEE 802.1ak MVRP and MRP, page 14-2
•
Information About IEEE 802.1ak MVRP and MRP, page 14-2
•
Default Settings for IEEE 802.1ak MVRP and MRP, page 14-8
•
How to Configure IEEE 802.1ak MVRP and MRP, page 14-8
•
Troubleshooting the MVRP Configuration, page 14-10
•
Configuration Examples for IEEE 802.1ak MVRP and MRP, page 14-11
•
This feature appears in Cisco Feature navigator as “IEEE 802.1ak - MVRP and MRP.”
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for IEEE 802.1ak MVRP and MRP
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-1
Chapter 14
IEEE 802.1ak MVRP and MRP
Restrictions for IEEE 802.1ak MVRP and MRP
Restrictions for IEEE 802.1ak MVRP and MRP
•
In releases where CSCta96338 is not resolved, a physical port with an MVRP configuration and
enable state that differs from what is configured on a port-channel interface cannot become an active
member of that EtherChannel.
•
In releases where CSCta96338 is resolved, a physical port with an MVRP configuration and enable
state that differs from what is configured on a port-channel interface can become an active member
of the EtherChannel because the physical port will use the port-channel interface MVRP
configuration and enable state.
•
A non-Cisco device can interoperate with a Cisco device only through 802.1Q trunks.
•
MVRP runs on ports where it is enabled. VTP pruning can run on ports where MVRP is not enabled.
•
MVRP can be configured on both physical interfaces and EtherChannel interfaces, but is not
supported on EtherChannel member ports.
•
MVRP dynamic VLAN creation is not supported when the device is running in VTP server or client
mode.
•
MVRP and Connectivity Fault Management (CFM) can coexist but if the module does not have
enough MAC address match registers to support both protocols, the MVRP ports on those modules
are put in the error-disabled state. To use the ports that have been shut down, disable MVRP on the
ports, and then enter shutdown and no shutdown commands.
•
802.1X authentication and authorization takes place after the port becomes active and before the
Dynamic Trunking Protocol (DTP) negotiations start prior to MVRP running on the port.
•
Do not enable MVRP automatic MAC address learning on edge switches that are configured with
access ports. Enable MVRP automatic MAC address learning only on core switches where all the
trunk interfaces are running MVRP.
•
MVRP is supported only on Layer 2 trunks. MVRP is not supported on subinterfaces.
Information About IEEE 802.1ak MVRP and MRP
•
Overview, page 14-2
•
Dynamic VLAN Creation, page 14-4
•
MVRP Interoperability with VTP, page 14-4
•
MVRP Interoperation with Non-Cisco Devices, page 14-6
•
MVRP Interoperability with Other Software Features and Protocols, page 14-6
Overview
The IEEE 802.1ak Multiple VLAN Registration Protocol (MVRP) supports dynamic registration and
deregistration of VLANs on ports in a VLAN bridged network. IEEE 802.1ak uses more efficient
Protocol Data Units (PDUs) and protocol design to provide better performance than the Generic VLAN
Registration Protocol (GARP) VLAN Registration Protocol (GVRP) and GARP Multicast Registration
Protocol (GMRP) protocols.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-2
IEEE 802.1ak MVRP and MRP
Information About IEEE 802.1ak MVRP and MRP
A VLAN-bridged network usually restricts unknown unicast, and broadcast traffic to those links that the
traffic uses to access the appropriate network devices. In a large network, localized topology changes
can affect the service over a much larger portion of the network. IEEE 802.1ak replaces GARP with the
Multiple Registration Protocol (MRP), which provides improved resource utilization and bandwidth
conservation.
With the 802.1ak MRP attribute encoding scheme, MVRP only needs to send one PDU that includes the
state of all 4094 VLANs on a port. MVRP also transmits Topology Change Notifications (TCNs) for
individual VLANs. This is an important feature for service providers because it allows them to localize
topology changes. Figure 14-1 illustrates MVRP deployed in a provider network on provider and
customer bridges.
Figure 14-1
MVRP Deployed on Provider and Customer Bridges
CB-3
MVRP
H1
PB-2
MVRP
H2
CB-1
MVRP
PB-1
MVRP
CB-1
MVRP
PB-4
MVRP
H5
PB-3
MVRP
CB-2
MVRP
H3
CB-2
MVRP
H4
H6
MVRP runs on Customer Bridges
MVRP runs on Provider Bridges
H7
274481
Chapter 14
Because most providers do not wish to filter traffic by destination MAC addresses, a pruning protocol
like MVRP is important in a Metro Ethernet provider network, which often uses thousands of VLANs.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-3
Chapter 14
IEEE 802.1ak MVRP and MRP
Information About IEEE 802.1ak MVRP and MRP
Figure 14-2 dispalys redundant links that are configured between the access switch and two distribution
switches on the cloud. When the link with VLAN 104 fails over, MVRP needs to send only one TCN for
VLAN 104. Without MVRP, an STP TCN would need to be sent out for the whole MST region
(VLANs1-1000), which could cause unnecessary network interruption.
STP sets the tcDetected variable to signal MVRP that MVRP must decide whether to send an MVRP
TCN. MVRP can flush filtering database entries rapidly on a per-VLAN basis following a topology
change because when a port receives an attribute declaration marked as new, any entries in the filtering
database for that port and for that VLAN are removed.
Figure 14-2
MVRP TCN Application
MST1
V1-1000
MST2
V2001-3000
V1050
MVRP
Applicant
Redundant links
MVRP TCN for v104
274480
V104
V104
Dynamic VLAN Creation
Virtual Trunking Protocol (VTP) is a Cisco proprietary protocol that distributes VLAN configuration
information across multiple devices within a VTP domain. When VTP is running on MVRP-aware
devices, all of the VLANs allowed on the Cisco bridged LAN segments are determined by VTP.
Only the VTP transparent mode supports MVRP dynamic VLAN creation. When dynamic VLAN
creation is disabled, the MVRP trunk ports can register and propagate the VLAN messages only for
existing VLANs. MVRP PDUs and MVRP messages for the nonexistant VLANs are discarded.
For a switch to be configured in full compliance with the MVRP standard, the switch VTP mode must
be transparent and MVRP dynamic VLAN creation must be enabled.
MVRP Interoperability with VTP
•
Overview, page 14-5
•
VTP in Transparent or Off Mode, page 14-5
•
VTP in Server or Client Mode and VTP Pruning is Disabled, page 14-5
•
VTP in Server or Client Mode and VTP Pruning is Enabled, page 14-5
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-4
Chapter 14
IEEE 802.1ak MVRP and MRP
Information About IEEE 802.1ak MVRP and MRP
Overview
The VLAN Trunking Protocol (VTP) is a Cisco proprietary protocol that distributes VLAN
configuration information across multiple devices within a VTP domain. VTP pruning is an extension
of VTP. It has its own Join message that can be exchanged with VTP PDUs. VTP PDUs can be
transmitted on both 802.1Q trunks and ISL trunks. A VTP-capable device is in one of the VTP modes:
server, client, transparent, or off.
When VTP Pruning and MVRP are both enabled globally, MVRP runs on trunks where it is enabled and
VTP Pruning runs on other trunks. MVRP or VTP pruning can be enabled on a trunk, but not both.
VTP in Transparent or Off Mode
When VTP is in transparent or off mode, VTP pruning is not supported and VTP PDUs are not processed.
When a port receives an MVRP join message for a VLAN, the port transmits broadcast, multicast, and
unknown unicast frames in that VLAN and adds the traffic definition to the MRP Attribute Propagation
(MAP) port configured for that VLAN. The mapping is removed when the VLAN is no longer registered
on the port.
For each interface that is forwarding in each VLAN, MVRP issues a join request to each MRP Attribute
Declaration (MAD) instance and an MVRP Join message is sent out on each corresponding MVRP port.
MVRP dynamic VLAN creation can be enabled in VTP transparent or off mode. If it is enabled and the
VLAN registered by a join message does not exist in the VLAN database in the device, then the VLAN
will be created.
VTP in Server or Client Mode and VTP Pruning is Disabled
MVRP functions like VTP in transparent or off mode, except that MVRP dynamic VLAN creation is not
allowed.
VTP in Server or Client Mode and VTP Pruning is Enabled
MVRP and VTP with pruning disabled can be supported on the same port and these two protocols need
to communicate and exchange pruning information.
When VTP receives a VTP join message on a VTP trunk, MVRP is notified so that join request can be
posted to the MVRP port MAD instances, and MVRP join messages are out on the MVRP ports to the
MVRP network.
When VTP pruning removes a VLAN from a VTP trunk, MVRP sends a leave request to all the MAD
instances and the MAD instances send a leave or empty message from the MVRP ports to indicate that
the VLAN is not configured on the device.
When an MVRP port received an MVRP join message, MVRP propagates the event to other MVRP ports
in the same MAP context, and notifies VTP so that VTP pruning can send a VTP join message from the
VTP trunk ports.
If MVRP learns that a VLAN is no longer declared by the neighboring devices, MVRP sends a
withdrawal event to VTP and then VTP pruning verifies that it should continue sending VTP join
messages.
For VLANs that are configured as VTP pruning non-eligible on the VTP trunks, the VTP pruning state
variables are set to joined for the VLANs. MVRP join requests are sent to those VLANs through the
MVRP ports.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-5
Chapter 14
IEEE 802.1ak MVRP and MRP
Information About IEEE 802.1ak MVRP and MRP
MVRP Interoperation with Non-Cisco Devices
Non-Cisco devices can interoperate with a Cisco device only through 802.1q trunks.
MVRP Interoperability with Other Software Features and Protocols
•
802.1x and Port Security, page 14-6
•
DTP, page 14-6
•
EtherChannel, page 14-7
•
Flex Links, page 14-7
•
High Availability, page 14-7
•
ISSU and eFSU, page 14-7
•
L2PT, page 14-7
•
SPAN, page 14-7
•
Unknown Unicast Flood Control, page 14-7
•
STP, page 14-7
•
UDLR, page 14-7
•
VLANs with MVRP, page 14-8
802.1x and Port Security
802.1x authenticates and authorizes a port after it transitions to the link-up state, but before DTP
negotiation occurs and MVRP runs on a port. Port security works independently of MVRP.
Note
When MVRP is globally enabled, the MVRP MAC address auto detect and provision feature is disabled
by default (mvrp mac-learning auto). In some situations, MVRP MAC address auto detect and
provision can disable MAC address learning and prevent correct port security operation. For example,
on ports where port security is configured, when the number of streams exceeds the configured
maximum number of MAC addresses, no port security violation occurs because MAC address learning
is disabled, which prevents updates to port security about the streams coming into the port. To avoid
incorrect port security operation, use caution when enabling the MVRP MAC address auto detect and
provision feature on ports where port security is configured.
DTP
DTP negotiation occurs after ports transition to the link-up state and before transition to the forwarding
state. If MVRP is administratively enabled globally and enabled on a port, it becomes operational when
the port starts trunking.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-6
Chapter 14
IEEE 802.1ak MVRP and MRP
Information About IEEE 802.1ak MVRP and MRP
EtherChannel
An EtherChannel port-channel interface can be configured as an MVRP participant. The EtherChannel
member ports cannot be MVRP participants. MVRP learns the STP state of EtherChannel port-channel
interfaces. The MAP context applies to the EtherChannel port-channel interfaces, but not to the
EtherChannel member ports.
Flex Links
MVRP declares VLANs on STP forwarding ports but not on ports in the blocking state. On flex links
ports, MVRP declares VLANs on the active ports but not on the standby ports. when a standby port takes
over and an active port transitions to the link-down state, MVRP declares the VLANs on the newly active
port.
High Availability
State Switchover (SSO) and ISSU supports MVRP.
ISSU and eFSU
Enhanced Fast Software Upgrade (EFSU) is an enhanced software upgrade procedure. MVRP is serviced
by the ISSU client identified as ISSU_MVRP_CLIENT_ID.
L2PT
Layer 2 Protocol Tunneling (L2PT) does not support MVRP PDUs on 802.1Q tunnel ports.
SPAN
MVRP ports can be configured as either Switched Port Analyzer (SPAN) sources or destinations.
Unknown Unicast Flood Control
MVRP and the Unknown Unicast Flood Control feature, configured with the switchport block
command, cannot be configured on the same port.
STP
An STP mode change causes forwarding ports to leave the forwarding state until STP reconverges in the
newly configured mode. The reconvergence might cause an MVRP topology change because join
messages might be received on different forwarding ports, and leave timers might expire on other ports.
UDLR
MVRP and unidirectional link routing (UDLR) cannot be configured on the same port.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-7
Chapter 14
IEEE 802.1ak MVRP and MRP
Default Settings for IEEE 802.1ak MVRP and MRP
VLANs with MVRP
•
VLAN Translation, page 14-8
•
802.1Q Native VLAN Tagging, page 14-8
•
Private VLANs, page 14-8
VLAN Translation
VLAN translation and MVRP cannot be configured on the same port.
802.1Q Native VLAN Tagging
Other MVRP participants might not be able to accept tagged MVRP PDUs in the 802.1Q native VLAN.
Compatibility between MVRP and 802.1Q native VLAN tagging depends on the specific network
configuration.
Private VLANs
Private VLAN ports cannot support MVRP.
Default Settings for IEEE 802.1ak MVRP and MRP
None.
How to Configure IEEE 802.1ak MVRP and MRP
•
Enabling MVRP, page 14-8
•
Enabling Automatic Detection of MAC Addresses, page 14-9
•
Enabling MVRP Dynamic VLAN Creation, page 14-9
•
Changing the MVRP Registrar State, page 14-10
Enabling MVRP
MVRP must be enabled globally and on trunk ports. To enable MVRP, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# mvrp global
Globally enables MVRP.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-8
Chapter 14
IEEE 802.1ak MVRP and MRP
How to Configure IEEE 802.1ak MVRP and MRP
Command or Action
Purpose
Step 4
Router(config)# interface type number
Specifies a trunk port and enters interface configuration mode.
Step 5
Router(config-if)# mvrp
Enables MVRP on the interface.
If MVRP is not successfully enabled on the port, the port
is put in the errdisabled state. Enter the no mvrp command
on the interface or the no mvrp global command to clear
the errdisabled state.
Note
This example shows how to enable MVRP globally and on an interface:
Router> enable
Router# configure terminal
Router(config)# mvrp global
Router(config)# interface FastEthernet 2/1
Router(config-if)# mvrp
Enabling Automatic Detection of MAC Addresses
MVRP automatic detection of MAC addresses is disabled by default. To enable MVRP automatic
detection of MAC addresses on VLANs, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# mvrp mac-learning auto
Enables MAC address learning.
This example shows how to enable automatic MAC address learning:
Router> enable
Router# configure terminal
Router(config)# mvrp mac-learning auto
Enabling MVRP Dynamic VLAN Creation
To enable MVRP dynamic VLAN creation, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# vtp mode transparent
Sets VTP mode to transparent.
Step 4
Router(config)# mvrp vlan creation
Note
Required for MVRP dynamic VLAN creation.
Enables MRVP dynamic VLAN creation.
This example shows how to enable MVRP dynamic VLAN creation:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-9
Chapter 14
IEEE 802.1ak MVRP and MRP
Troubleshooting the MVRP Configuration
Router> enable
Router# configure terminal
Router(config)# vtp mode transparent
Router(config)# mvrp vlan create
Changing the MVRP Registrar State
The MRP protocol allows one participant per application in an end station, and one per application per
port in a bridge. To set the MVRP registrar state, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router(config)# interface type number
Specifies and interface and enters interface configuration
mode.
Step 4
Router(config-if)# mvrp registration [normal |
fixed | forbidden]
Registers MVRP with the MAD instance.
This example shows how to set the MVRP registrar state to normal:
Router> enable
Router# configure terminal
Router(config)# interface FastEthernet 2/1
Router(config-if)# mvrp registration normal
Troubleshooting the MVRP Configuration
Use the show mvrp summary and show mvrp interface commands to display configuration
information and interface states, and the debug mvrp command to enable all or a limited set of output
messages related to an interface.
To troubleshoot the MVRP configuration, perform this task:
Command or Action
Purpose
Step 1
Router> enable
Enables privileged EXEC mode (enter your password if
prompted).
Step 2
Router# show mvrp summary
Displays the MVRP configuration.
Step 3
Router# show mvrp interface interface-type
port/slot
Displays the MVRP interface states for the specified
interface.
Step 4
Router# debug mvrp
Displays MVRP debugging information.
Step 5
Router# clear mvrp statistics
Clears MVRP statistics on all interfaces.
The following is sample output from the show mvrp summary command. This command can be used
to display the MVRP configuration at the device level.
Router# show mvrp summary
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-10
Chapter 14
IEEE 802.1ak MVRP and MRP
Configuration Examples for IEEE 802.1ak MVRP and MRP
MVRP global state
MVRP VLAN creation
VLANs created via MVRP
Learning disabled on VLANs
:
:
:
:
enabled
disabled
20-45, 3001-3050
none
The following is sample output from the show mvrp interface command. This command can be used to
display MVRP interface details of the administrative and operational MVRP states of all or one
particular trunk port in the device.
Router# show mvrp interface
Port
Fa3/1
Status
off
Registrar State
normal
Port
Fa3/1
Join Timeout
201 600
Port
Fa3/1
Vlans Declared
none
Port
Fa3/1
Vlans Registered
none
Port
Fa3/1
Vlans Registered and in Spanning Tree Forwarding State
none
Leave Timeout
700
Leaveall Timeout
1000
Configuration Examples for IEEE 802.1ak MVRP and MRP
•
Enabling MVRP, page 14-11
•
Enabling MVRP Automatic Detection of MAC Addresses, page 14-11
•
Enabling Dynamic VLAN Creation, page 14-12
•
Changing the MVRP Registrar State, page 14-12
Enabling MVRP
The following example shows how to enable MVRP:
Router> enable
Router# configure terminal
Router(config)# mvrp global
Router(config)# interface fastethernet2/1
Router(config-if)# mvrp
Enabling MVRP Automatic Detection of MAC Addresses
The following example shows how to enable MAC address learning:
Router> enable
Router# configure terminal
Router(config)# mvrp mac-learning auto
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-11
Chapter 14
IEEE 802.1ak MVRP and MRP
Configuration Examples for IEEE 802.1ak MVRP and MRP
Enabling Dynamic VLAN Creation
The following example shows how to enable dynamic VLAN creation:
Router> enable
Router# configure terminal
Router(config)# vtp mode transparent
Router(config)# mvrp vlan create
Changing the MVRP Registrar State
The following example shows how to change the MVRP registrar state:
Router> enable
Router# configure terminal
Router(config)# mvrp registration normal
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
14-12
CH AP TE R
15
VLAN Trunking Protocol (VTP)
Note
•
Prerequisites for VTP, page 15-1
•
Restrictions for VTP, page 15-1
•
Information About VTP, page 15-2
•
Default Settings for VTP, page 15-9
•
How to Configure VTP, page 15-10
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for VTP
None.
Restrictions for VTP
•
Supervisor engine redundancy does not support nondefault VLAN data filenames or locations. Do
not enter the vtp file file_name command on a switch that has a redundant supervisor engine.
•
Before installing a redundant supervisor engine, enter the no vtp file command to return to the
default configuration.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-1
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
Caution
•
All network devices in a VTP domain must run the same VTP version.
•
You must configure a password on each network device in the management domain when in secure
mode.
If you configure VTP in secure mode, the management domain will not function properly if you do not
assign a management domain password to each network device in the domain.
•
A VTP version 2-capable network device can operate in the same VTP domain as a network device
that runs VTP version 1 if VTP version 2 is disabled on the VTP version 2-capable network device
(VTP version 2 is disabled by default).
•
Do not enable VTP version 2 on a network device unless all of the network devices in the same VTP
domain are version 2-capable. When you enable VTP version 2 on a network device, all of the
version 2-capable network devices in the domain enable VTP version 2.
•
In a Token Ring environment, you must enable VTP version 2 for Token Ring VLAN switching to
function properly.
•
When you enable or disable VTP pruning on a VTP server, VTP pruning for the entire management
domain is enabled or disabled.
•
The pruning-eligibility configuration applies globally to all trunks on the switch. You cannot
configure pruning eligibility separately for each trunk.
•
When you configure VLANs as pruning eligible or pruning ineligible, pruning eligibility for those
VLANs is affected on that switch only, not on all network devices in the VTP domain.
•
VTP version 1 and VTP version 2 do not propagate configuration information for extended-range
VLANs (VLAN numbers 1006 to 4094). You must configure extended-range VLANs manually on
each network device.
•
VTP version 3 supports extended-range VLANs (VLAN numbers 1006 to 4094). If you convert from
VTP version 3 to VTP version 2, the VLANs in the range 1006 to 4094 are removed from VTP control.
•
VTP version 3 supports propagation of any database in a domain by allowing you to configure a
primary and secondary server.
•
The network administrator has to manually configure VTP version 3 on the switches that need to run
VTP version 3.
•
VTP version 3 is not supported on private VLAN (PVLAN) ports.
•
Prior to configuring VTP version 3, you must ensure that the spanning-tree extend system-id
command has been enabled.
•
If there is insufficient DRAM available for use by VTP, the VTP mode changes to transparent.
•
Network devices in VTP transparent mode do not send VTP Join messages. On trunk connections
to network devices in VTP transparent mode, configure the VLANs that are used by the
transparent-mode network devices or that need to be carried across trunks as pruning ineligible. For
information about configuring prune eligibility, see the “Configuring the List of Prune-Eligible
VLANs” section on page 11-11.
Information About VTP
•
VTP Overview, page 15-3
•
VTP Domains, page 15-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-2
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
Note
•
VTP Modes, page 15-4
•
VTP Advertisements, page 15-4
•
VTP Authentication, page 15-5
•
VTP Version 2, page 15-5
•
VTP Version 3, page 15-6
•
VTP Pruning, page 15-7
•
VLAN Interaction, page 15-9
For complete information on configuring VLANs, see Chapter 16, “Virtual Local Area Networks
(VLANs).”
VTP Overview
VTP is a Layer 2 messaging protocol that maintains VLAN configuration consistency by managing the
addition, deletion, and renaming of VLANs within a VTP domain. A VTP domain (also called a VLAN
management domain) is made up of one or more network devices that share the same VTP domain name
and that are interconnected with trunks. VTP minimizes misconfigurations and configuration
inconsistencies that can result in a number of problems, such as duplicate VLAN names, incorrect
VLAN-type specifications, and security violations. Before you create VLANs, you must decide whether
to use VTP in your network. With VTP, you can make configuration changes centrally on one or more
network devices and have those changes automatically communicated to all the other network devices
in the network.
VTP Domains
A VTP domain (also called a VLAN management domain) is made up of one or more interconnected
network devices that share the same VTP domain name. A network device can be configured to be in one
and only one VTP domain. You make global VLAN configuration changes for the domain using either
the command-line interface (CLI) or Simple Network Management Protocol (SNMP).
VTP server mode is the default and the switch is in the no-management domain state until it receives an
advertisement for a domain over a trunk link or you configure a management domain.
If the switch receives a VTP advertisement over a trunk link, it inherits the management domain name
and the VTP configuration revision number. The switch ignores advertisements with a different
management domain name or an earlier configuration revision number.
If you configure the switch as VTP transparent, you can create and modify VLANs but the changes affect
only the individual switch. The valid VLAN ranges are as follows:
•
•
VTP version 1 and version 2 support VLANs 1 to 1000 only.
VTP version 3 supports the entire VLAN range (VLANs 1 to 4094).
•
The pruning of VLANs still applies to VLANs 1 to 1000 only.
•
Extended-range VLANs are supported only in VTP version 3. If converting from VTP version 3 to VTP
version 2, VLANs in the range 1006 to 4094 are removed from VTP control.
By default, all devices come up as secondary servers. You can enter the vtp primary privileged EXEC
mode command to specify a primary server.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-3
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
When using VTP version 1 and version 2, a VTP server is used to back up the database to the NVRAM
and allows you to change the database information.
In VTP version 3, there is a VTP-primary server and a VTP-secondary server. A primary server allows
you to alter the database information and the database updates sent out are honored by all the devices in
the system. A secondary server can only back up the updated VTP configuration received from the
primary server in the NVRAMs. The status of the primary and secondary servers is a runtime status and
is not configurable.
VTP maps VLANs dynamically across multiple LAN types with unique names and internal index
associations. Mapping eliminates excessive device administration required from network administrators.
VTP Modes
You can configure any one of these VTP modes:
Note
•
Server—In VTP server mode, you can create, modify, and delete VLANs and specify other
configuration parameters (such as VTP version and VTP pruning) for the entire VTP domain. VTP
servers advertise their VLAN configuration to other network devices in the same VTP domain and
synchronize their VLAN configuration with other network devices based on advertisements received
over trunk links. VTP server is the default mode.
•
Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete
VLANs on a VTP client.
•
Transparent—VTP transparent network devices do not participate in VTP. A VTP transparent
network device does not advertise its VLAN configuration and does not synchronize its VLAN
configuration based on received advertisements. However, in VTP version 2, a transparent network
device will forward received VTP advertisements from its trunking LAN ports. In VTP version 3, a
transparent network device is specific to an instance.
•
Off—In VTP off mode, a network device functions in the same manner as a VTP transparent device
except that it does not forward VTP advertisements.
The VTP server mode automatically changes from VTP server mode to VTP client mode if the switch
detects a failure while writing configuration to NVRAM. If this happens, the switch cannot be returned
to VTP server mode until the NVRAM is functioning.
VTP Advertisements
Each network device in the VTP domain sends periodic advertisements out each trunking LAN port to a
reserved multicast address. VTP advertisements are received by neighboring network devices, which
update their VTP and VLAN configurations as necessary.
The following global configuration information is distributed in VTP version 1 and version 2
advertisements:
•
VLAN IDs.
•
Emulated LAN names (for ATM LANE).
•
802.10 SAID values (FDDI).
•
VTP domain name.
•
VTP configuration revision number.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-4
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
•
VLAN configuration, including the maximum transmission unit (MTU) size for each VLAN.
•
Frame format.
In VTP version 3, the information distributed in VTP version 1 and version 2 advertisements are
supported, as well as the following information:
•
A primary server ID.
•
An instance number.
•
A start index.
•
An advertisement request is sent by a Client or a Server in these situations:
– On a trunk coming up on a switch with an invalid database.
– On all trunks when the database of a switch becomes invalid as a result of a configuration
change or a takeover message.
– On a specific trunk where a superior database has been advertised.
•
VTP version 3 adds the following fields to the subset advertisement request:
– A primary server ID.
– An instance number.
– A window size.
– A start index.
VTP Authentication
When VTP authentication is not configured, the secret that is used to validate the received VTP updates
is visible in plain text in the show commands and the NVRAM file, const_nvram:vlan.dat. In the event
that a device in a VTP domain is compromised, the administrator must change the VTP secret across all
the devices in the VTP domain.
With VTP version 3, you can configure the authentication password to be hidden using the vtp password
command. When you configure the authentication password to be hidden, it does not appear in plain text
in the configuration. Instead, the secret associated with the password is saved in hexadecimal format in
the running configuration. The password-string argument is an ASCII string from 8 to 64 characters
identifying the administrative domain for the device.
VTP Version 2
VTP version 2 supports the following features not supported in version 1:
•
Token Ring support—VTP version 2 supports Token Ring LAN switching and VLANs (Token Ring
Bridge Relay Function [TrBRF] and Token Ring Concentrator Relay Function [TrCRF]). For more
information about Token Ring VLANs, see the “Information About VLANs” section on page 16-2.
•
Unrecognized Type-Length-Value (TLV) Support—A VTP server or client propagates configuration
changes to its other trunks, even for TLVs that it is not able to parse. The unrecognized TLV is saved
in NVRAM.
•
Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent network device
inspects VTP messages for the domain name and version and forwards a message only if the version
and domain name match. Because only one domain is supported, VTP version 2 forwards VTP
messages in transparent mode without checking the version.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-5
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
•
Consistency Checks—In VTP version 2, VLAN consistency checks (such as VLAN names and
values) are performed only when you enter new information through the CLI or SNMP. Consistency
checks are not performed when new information is obtained from a VTP message, or when
information is read from NVRAM. If the digest on a received VTP message is correct, its
information is accepted without consistency checks.
VTP Version 3
VTP version 3 supports all the features in version 1 and version 2. VTP version 3 also supports the
following features not supported in version 1 and version 2:
•
Enhanced authentication—In VTP version 3, you can configure the authentication password to be
hidden using the vtp password command. When you configure the authentication password to be
hidden, it does not appear in plain text in the configuration. Instead, the secret associated with the
password is saved in hexadecimal format in the running configuration. The password-string
argument is an ASCII string from 8 to 64 characters identifying the administrative domain for the
device.
The hidden and secret keywords for VTP password are supported only in VTP version 3. If
converting to VTP version 2 from VTP version 3, you must remove the hidden or secret keyword
prior to the conversion.
•
Support for extended range VLAN database propagation—VTP version 1 and version 2 support
VLANs 1 to 1000 only. In VTP version 3, the entire VLAN range is supported (VLANs 1 to 4094).
The pruning of VLANs still applies to VLANs 1 to 1000 only. Extended-range VLANs are supported
in VTP version 3 only. Private VLANs are supported in VTP version 3. If you convert from VTP
version 3 to VTP version 2, the VLANs in the range 1006 to 4094 are removed from VTP control.
•
VLANs 1002 to 1005 are reserved VLANs in VTP version 1, version 2, and version 3.
•
Support for propagation of any database in a domain—In VTP version 1 and version 2, a VTP server
is used to back up the database to the NVRAM and allows you to change the database information.
Note
VTP version 3 supports Multiple Spanning Tree (802.1s) (MST) database propagation separate
from the VLAN database only. In the MST database propagation, there is a VTP primary server
and a VTP econdary server. A primary server allows you to alter the database information, and
the database updates sent out are honored by all the devices in the system. A secondary server
can only back up the updated VTP configuration received from the primary server in the
NVRAMs. The status of the primary and secondary servers is a runtime status and is not
configurable.
By default, all devices come up as secondary servers. You can enter the vtp primary privileged
EXEC mode command to specify a primary server.
The primary-server status is needed only when database changes have to be performed and is
obtained when the administrator issues a takeover message in the domain. The primary-server status
is lost when you reload, switch over, or the domain parameters change. The secondary servers back
up the configuration and continue to propagate the database. You can have a working VTP domain
without any primary servers. Primary and secondary servers may exist on an instance in the domain.
In VTP version 3, there is no longer a restriction to propagate only VLAN database information. You
can use VTP version 3 to propagate any database information across the VTP domain. A separate
instance of the protocol is running for each application that uses VTP.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-6
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
Two VTP version 3 regions can only communicate over a VTP version 1 or VTP version 2 region in
transparent mode.
•
CLI to turn off/on VTP on a per-trunk basis—You can enable VTP on a per-trunk basis using the
vtp interface configuration mode command. You can disable VTP on a per-trunk basis using the no
form of this command. When you disable VTP on the trunking port, all the VTP instances for that
port are disabled. You will not be provided with the option of setting VTP to OFF for the MST
database and ON for the VLAN database.
VTP on a global basis—When you set VTP mode to OFF globally, this applies to all the trunking ports
in the system. Unlike the per-port configuration, you can specify the OFF option on a per-VTP instance
basis. For example, the system could be configured as VTP-server for the VLAN database and as
VTP-off for the MST database. In this case, VLAN databases are propagated by VTP, MST updates are
sent out on the trunk ports in the system, and the MST updates received by the system are discarded.
VTP Pruning
VTP pruning enhances network bandwidth use by reducing unnecessary flooded traffic, such as
broadcast, multicast, unknown, and flooded unicast packets. VTP pruning increases available bandwidth
by restricting flooded traffic to those trunk links that the traffic must use to access the appropriate
network devices. By default, VTP pruning is disabled.
In VTP versions 1 and 2, when you enable or disable pruning, it is propagated to the entire domain and
accepted by all the devices in that domain. In VTP version 3, the domain administrator must manually
enable or disable VTP pruning explicitly on each device.
For VTP pruning to be effective, all devices in the management domain must support VTP pruning. On
devices that do not support VTP pruning, you must manually configure the VLANs allowed on trunks.
Figure 15-1 shows a switched network without VTP pruning enabled. Interface 1 on network Switch 1
and port 2 on Switch 4 are assigned to the Red VLAN. A broadcast is sent from the host connected to
Switch 1. Switch 1 floods the broadcast, and every network device in the network receives it, even
though Switches 3, 5, and 6 have no ports in the Red VLAN.
You enable pruning globally on the switch (see the “Enabling VTP Pruning” section on page 15-12). You
configure pruning on Layer 2 trunking LAN ports (see the “Configuring a Layer 2 Switching Port as a
Trunk” section on page 11-8).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-7
Chapter 15
VLAN Trunking Protocol (VTP)
Information About VTP
Figure 15-1
Flooding Traffic without VTP Pruning
Catalyst series
Switch 4
Interface 2
Catalyst series
Switch 5
Catalyst series
Switch 2
Red
VLAN
Catalyst series
Switch 6
Catalyst series
Switch 3
31074
Interface 1
Catalyst series
Switch 1
Figure 15-2 shows the same switched network with VTP pruning enabled. The broadcast traffic from
Switch 1 is not forwarded to Switches 3, 5, and 6 because traffic for the Red VLAN has been pruned on
the links indicated (port 5 on Switch 2 and port 4 on Switch 4).
Figure 15-2
Flooding Traffic with VTP Pruning
Switch 4
Interface 2
Interface 4
Flooded traffic
is pruned.
Switch 2
Red
VLAN
Switch 5
Interface 5
Switch 6
Switch 3
Switch 1
31075
Interface 1
Enabling VTP pruning on a VTP server enables pruning for the entire management domain. VTP pruning
takes effect several seconds after you enable it. By default, VLANs 2 through 1000 are pruning eligible.
VTP pruning does not prune traffic from pruning-ineligible VLANs. VLAN 1 is always pruning
ineligible; traffic from VLAN 1 cannot be pruned.
To configure VTP pruning on a trunking LAN port, use the switchport trunk pruning vlan command
(see the “Configuring a Layer 2 Switching Port as a Trunk” section on page 11-8). VTP pruning operates
when a LAN port is trunking. You can set VLAN pruning eligibility when VTP pruning is enabled or
disabled for the VTP domain, when any given VLAN exists or not, and when the LAN port is currently
trunking or not.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-8
Chapter 15
VLAN Trunking Protocol (VTP)
Default Settings for VTP
VLAN Interaction
This section describes the VLAN interaction between devices with different VTP versions:
•
Interaction Between VTP Version 3 and VTP Version 2 Devices, page 15-9
•
Interaction Between VTP Version 3 and VTP Version 1 Devices, page 15-9
Interaction Between VTP Version 3 and VTP Version 2 Devices
When a VTP version 3 device on a trunk port receives messages from a VTP version 2 device, the VTP
version 3 device sends a scaled-down version of the VLAN database on that particular trunk in a VTP
version 2 format. A VTP version 3 device does not send out VTP version 2-formatted packets on a trunk
port unless it first receives VTP version 2 packets on that trunk. If the VTP version 3 device does not
receive VTP version 2 packets for an interval of time on the trunk port, the VTP version 3 device stops
transmitting VTP version 2 packets on that trunk port.
Even when a VTP version 3 device detects a VTP version 2 device on a trunk port, the VTP version 3
device continues to send VTP version 3 packets in addition to VTP version 3 device 2 packets, to allow
two kinds of neighbors to coexist on the trunk. VTP version 3 sends VTP version 3 and VTP version 2
updates on VTP version 2-detected trunks.
A VTP version 3 device does not accept configuration from a VTP version 2 (or VTP version 1) device.
Unlike in VTP version 2, when you configure the VTP version to be version 3, version 3 does not
configure all the VTP version 3-capable devices in the domain to start behaving as VTP version 3
systems.
Interaction Between VTP Version 3 and VTP Version 1 Devices
When a VTP version 1 device that is capable of VTP version 2 or VTP version 3 receives a VTP
version 3 packet, it will be configured as a VTP version 2 device if VTP version 2 conflicts do not exist.
VTP version 1-only capable devices cannot interoperate with VTP version 3 devices.
Default Settings for VTP
Feature
Default Value
VTP domain name
Null
VTP version 1 and version 2 mode
Server
VTP version 3 mode
The VTP version 3 VLAN database mode is the same as the
VLAN database mode in VTP version 1 or 2 after the
conversion from VTP version 1 or 2 to VTP version 3. For
example, the VTP version 1 or 2 VLAN database mode is
carried over to VTP version 3 VLAN database mode.
MST database mode
Transparent
VTP version 3 server type
Secondary
VTP version 2 state
Version 2 is disabled
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-9
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
Feature
Default Value
VTP password
None
VTP pruning
Disabled
How to Configure VTP
•
Configuring VTP Global Parameters, page 15-10
•
Configuring the VTP Mode, page 15-15
•
Configuring VTP Mode on a Per-Port Basis, page 15-16
•
Displaying VTP Statistics, page 15-17
Configuring VTP Global Parameters
Note
•
Configuring VTP Version 1 and Version 2 Passwords, page 15-10
•
Configuring VTP Version 3 Password, page 15-11
•
Enabling VTP Pruning, page 15-12
•
Enabling VTP Version 2, page 15-13
•
Enabling VTP Version 3, page 15-13
You can enter the VTP global parameters in either global configuration mode or in EXEC mode.
Configuring VTP Version 1 and Version 2 Passwords
To configure the VTP version 1 and version 2 global parameters, perform this task:
Command
Purpose
Router(config)# vtp password password-string
Sets a password, which can be from 8 to 64 characters long,
for the VTP domain.
Router(config)# no vtp password
Clears the password.
This example shows one way to configure a VTP password in global configuration mode:
Router# configure terminal
Router(config)# vtp password WATER
Setting device VLAN database password to WATER.
Router#
This example shows how to configure a VTP password in EXEC mode:
Router# vtp password WATER
Setting device VLAN database password to WATER.
Router#
Note
The password is not stored in the running-config file.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-10
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
Configuring VTP Version 3 Password
To configure the VTP version 3 password, perform this task:
Command
Purpose
Router(config)# vtp password password-string [hidden
| secret]
Configures a password, which can be from 8 to 64 characters
long or in 32-digit hexadecimal format, for the VTP domain.
Note
Router(config)# no vtp password
When entering the secret keyword, the
password-string must be entered in 32-digit
hexadecimal format.
Clears the password.
This example shows one way to configure a VTP password in global configuration mode:
Router# configure terminal
Router(config)# vtp password water
Setting device VTP database password to water.
Router#
Note
If you configure a VTP password in EXEC mode, the password is not stored in the running-config file.
This example shows one way to configure the password with a hidden key saved in hexadecimal format
in the running configuration:
Router# configure terminal
Router(config)# vtp password 82214640C5D90868B6A0D8103657A721 hidden
Setting device VTP password
Router#
This example shows how you configure the password secret key in hexadecimal format:
Router# configure terminal
Router(config)# vtp password 300F060A2B0601035301020107010201 secret
Setting device VTP password
Router#
Configuring VTP Version 3 Server Type
To specify a primary server, perform this task:
Command
Purpose
Router# vtp primary [vlan | mst] [force]
Configure this device as the primary server.
The vtp primary command does not have a no form. To return to the secondary server status, one of the
following conditions must be met:
•
System reload.
•
Switchover between redundant supervisors.
•
Takeover from another server.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-11
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
•
Change in the mode configuration.
•
Any domain configuration change (version, domain name, domain password).
This example shows how to configure this device as the primary server if the password feature is
disabled:
Router# vtp primary
This system is becoming primary server for feature vlan
No conflicting VTP version 3 devices found.
Do you want to continue? [confirm]y
Router#
This example shows how to configure this device as the primary server for the VTP VLAN feature if the
password feature is disabled:
Router# vtp primary vlan
This system is becoming primary server for feature vlan
No conflicting VTP version 3 devices found.
Do you want to continue? [confirm]y
Router#
This example shows how to force this device to be the primary server for the VTP MST feature if the
password feature is disabled:
Router# vtp primary mst force
This system is becoming primary server for feature MST
No conflicting VTP version 3 devices found.
Do you want to continue? [confirm]y
Router#
This example shows how to force this device to be the primary server for the VTP MST feature when the
domain VTP password is set with the hidden or secret keyword:
Router# vtp primary mst force
Enter VTP password: water1
This switch is becoming Primary server for mst feature in the VTP domain
VTP Database Conf Switch ID
Primary Server Revision System Name
------------ ---- -------------- -------------- -------- -------------------VLANDB
Yes 00d0.00b8.1400=00d0.00b8.1400 1
stp7
Do you want to continue (y/n) [n]? y
Router#
Enabling VTP Pruning
To enable VTP pruning in the management domain, perform this task:
Command
Purpose
Router(config)# vtp pruning
Enables VTP pruning in the management domain.
This example shows one way to enable VTP pruning in the management domain:
Router# configure terminal
Router(config)# vtp pruning
Pruning switched ON
This example shows how to enable VTP pruning in the management domain with any release:
Router# vtp pruning
Pruning switched ON
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-12
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
This example shows how to verify the configuration:
Router# show vtp status | include Pruning
VTP Pruning Mode: Enabled
Router#
For information about configuring prune eligibility, see the “Configuring the List of Prune-Eligible
VLANs” section on page 11-11.
Enabling VTP Version 2
VTP version 2 is disabled by default on VTP version 2-capable network devices. When you enable VTP
version 2 on a network device, every VTP version 2-capable network device in the VTP domain enables
version 2.
Caution
Note
VTP version 1 and VTP version 2 are not interoperable on network devices in the same VTP domain.
Every network device in the VTP domain must use the same VTP version. Do not enable VTP version 2
unless every network device in the VTP domain supports version 2.
In a Token Ring environment, you must enable VTP version 2 for Token Ring VLAN switching to
function properly on devices that support Token Ring interfaces.
To enable VTP version 2, perform this task:
Command
Purpose
Router(config)# vtp version 2
Enables VTP version 2.
This example shows one way to enable VTP version 2:
Router# configure terminal
Router(config)# vtp version 2
V2 mode enabled.
Router(config)#
This example shows how to enable VTP version 2 with any release:
Router# vtp version 2
V2 mode enabled.
Router#
This example shows how to verify the configuration:
Router# show vtp status | include V2
VTP V2 Mode: Enabled
Router#
Enabling VTP Version 3
VTP version 3 is disabled by default. You can enable version 3 in global configuration mode only. The
network administrator has to manually configure VTP version 3 on the switches that need to run VTP
version 3.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-13
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
Note
Caution
Prior to configuring VTP version 3, you must ensure that the spanning-tree extend system-id command
has been enabled.
In VTP version 3, both the primary and secondary servers may exist on an instance in the domain.
To enable VTP version 3, perform this task:
Command
Purpose
Router(config)# vtp version 3
Enables VTP version 3.
This example shows one way to enable VTP version 3:
Router# configure terminal
Router(config)# vtp version 3
Router(config)#
This example shows how to verify the configuration:
Router# show vtp status
VTP Version capable
VTP version running
VTP Domain Name
VTP Pruning Mode
VTP Traps Generation
Device ID
:
:
:
:
:
:
1 to 3
3
lab_switch
Disabled
Disabled
0015.c724.0040
Feature VLAN:
-------------VTP Operating Mode
: Server
Number of existing VLANs
: 6
Number of existing extended VLANs : 0
Configuration Revision
: 0
Primary ID
: 0000.0000.0000
Primary Description
:
MD5 digest
: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Feature MST:
-------------VTP Operating Mode
Feature UNKNOWN:
-------------VTP Operating Mode
Router#
: Transparent
: Transparent
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-14
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
Configuring the VTP Mode
To configure the VTP mode, perform this task:
Command
Purpose
Step 1
Router(config)# vtp mode {client | server |
transparent | off} {vlan | mst | unknown}
Configures the VTP mode.
Step 2
Router(config)# vtp domain domain-name
(Optional for server mode) Defines the VTP domain
name, which can be up to 32 characters long. VTP server
mode requires a domain name. If the switch has a trunk
connection to a VTP domain, the switch learns the
domain name from the VTP server in the domain.
Note
Step 3
Exits VLAN configuration mode.
Router(config)# end
Note
You cannot clear the domain name.
When VTP is disabled, you can enter VLAN configuration commands in configuration mode instead of
the VLAN database mode and the VLAN configuration is stored in the startup configuration file.
This example shows how to configure the switch as a VTP server:
Router# configuration terminal
Router(config)# vtp mode server
Setting device to VTP SERVER mode.
Router(config)# vtp domain lab_network
Setting VTP domain name to lab_network
Router(config)# end
Router#
This example shows how to configure the switch as a VTP client:
Router# configuration terminal
Router(config)# vtp mode client
Setting device to VTP CLIENT mode.
Router(config)# exit
Router#
This example shows how to disable VTP on the switch:
Router# configuration terminal
Router(config)# vtp mode transparent
Setting device to VTP TRANSPARENT mode.
Router(config)# end
Router#
This example shows how to disable VTP on the switch and to disable VTP advertisement forwarding:
Router# config terminal
Enter configuration commands, one per line.
Router(config)# vtp mode off
Setting device to VTP OFF mode.
Router(config)# exit
Router#
End with CNTL/Z.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-15
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
This example shows how to verify the configuration:
Router# show vtp status
VTP Version capable
VTP version running
VTP Domain Name
VTP Pruning Mode
VTP Traps Generation
Device ID
:
:
:
:
:
:
1 to 3
3
lab_network
Disabled
Disabled
0015.c724.0040
Feature VLAN:
-------------VTP Operating Mode
: Server
Number of existing VLANs
: 6
Number of existing extended VLANs : 0
Configuration Revision
: 0
Primary ID
: 0000.0000.0000
Primary Description
:
MD5 digest
: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Feature MST:
-------------VTP Operating Mode
: Transparent
Feature UNKNOWN:
-------------VTP Operating Mode
: Transparent
Router#
Configuring VTP Mode on a Per-Port Basis
You can configure VTP mode on a per-port basis. The VTP enable value will be applied only when a
port becomes switched port in trunk mode. Incoming and outgoing vtp pdus are blocked; not forwarded.
In VTP version 3, you can also configure VTP mode on a per-trunk basis. To configure VTP mode,
perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects an interface to configure.
Step 2
Router(config-if)# vtp
Enables VTP on the specified port.
Step 3
Router(config-if)# end
Exits interface configuration mode.
This example shows how to configure VTP mode on a port:
Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 3/5
Router(config-if)# vtp
Router(config-if)# end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-16
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
This example shows how to disable VTP mode on a port:
Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 3/5
Router(config-if)# no vtp
Router(config-if)# end
Router#
This example shows how to verify the configuration change:
Router# show vtp interface gigabitethernet 3/5
Interface
VTP Status
-----------------------------------GigabitEthernet3/5
disabled
Router#
This example shows how to verify the interface:
Router# show vtp interface
Interface
VTP Status
-----------------------------------GigabitEthernet3/1
enabled
GigabitEthernet3/2
enabled
GigabitEthernet3/3
enabled
GigabitEthernet3/4
enabled
GigabitEthernet3/5
disabled
GigabitEthernet3/6
enabled
...
Displaying VTP Statistics
To display VTP statistics, including VTP advertisements sent and received and VTP errors, perform this
task:
Command
Purpose
Router# show vtp counters
Displays VTP statistics.
This example shows how to display VTP statistics:
Router# show vtp counters
VTP statistics:
Summary advertisements received
Subset advertisements received
Request advertisements received
Summary advertisements transmitted
Subset advertisements transmitted
Request advertisements transmitted
Number of config revision errors
Number of config digest errors
Number of V1 summary errors
:
:
:
:
:
:
:
:
:
7
5
0
997
13
3
0
0
0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-17
Chapter 15
VLAN Trunking Protocol (VTP)
How to Configure VTP
VTP pruning statistics:
Trunk
Summary advts received from
non-pruning-capable device
---------------- ---------------- ---------------- --------------------------Gi5/8
43071
42766
5
Tip
Join Transmitted Join Received
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
15-18
CH AP TE R
16
Virtual Local Area Networks (VLANs)
Note
•
Prerequisites for VLANs, page 16-1
•
Restrictions for VLANs, page 16-2
•
Information About VLANs, page 16-2
•
Default Settings for VLANs, page 16-3
•
How to Configure VLANs, page 16-4
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for VLANs
The following recommendations apply to Fabric Extender (FEX) VLANs:
•
FEX-configurable VLAN range—1000 VLANs of any 4K VLANs
•
Total number of VLANs—Not to exceed 20 VLANs per FEX
•
Maximum number of trunks—Not to exceed 4 trunks
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-1
Chapter 16
Virtual Local Area Networks (VLANs)
Restrictions for VLANs
Restrictions for VLANs
•
If the switch is in VTP server or transparent mode (see the “How to Configure VTP” section on
page 15-10), you can configure VLANs in global and config-vlan configuration modes. When you
configure VLANs in global and config-vlan configuration modes, the VLAN configuration is saved
in the vlan.dat files. To display the VLAN configuration, enter the show vlan command.
If the switch is in VLAN transparent mode, use the copy running-config startup-config command
to save the VLAN configuration to the startup-config file. After you save the running configuration
as the startup configuration, use the show running-config and show startup-config commands to
display the VLAN configuration.
•
When the switch boots, if the VTP domain name and the VTP mode in the startup-config file and
vlan.dat files do not match, the switch uses the configuration in the vlan.dat file.
•
You can configure extended-range VLANs only in global configuration mode.
•
Supervisor engine redundancy does not support nondefault VLAN data file names or locations. Do
not enter the vtp file file_name command on a switch that has a redundant supervisor engine.
•
Before installing a redundant supervisor engine, enter the no vtp file command to return to the
default configuration.
•
Before you can create a VLAN, the switch must be in VTP server mode or VTP transparent mode.
For information on configuring VTP, see Chapter 15, “VLAN Trunking Protocol (VTP).”
•
The VLAN configuration is stored in the vlan.dat file, which is stored in nonvolatile memory. You
can cause inconsistency in the VLAN database if you manually delete the vlan.dat file.
•
To do a complete backup of your configuration, include the vlan.dat file in the backup.
Information About VLANs
•
VLAN Overview, page 16-2
•
VLAN Ranges, page 16-2
VLAN Overview
A VLAN is a group of end stations with a common set of requirements, independent of physical location.
VLANs have the same attributes as a physical LAN but allow you to group end stations even if they are
not located physically on the same LAN segment.
VLANs are usually associated with IP subnetworks. For example, all the end stations in a particular IP
subnet belong to the same VLAN. Traffic between VLANs must be routed. LAN port VLAN
membership is assigned manually on an port-by-port basis.
VLAN Ranges
Note
You must enable the extended system ID to use 4096 VLANs (see the “Information about the Bridge ID”
section on page 1-3).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-2
Chapter 16
Virtual Local Area Networks (VLANs)
Default Settings for VLANs
Cisco IOS Release 15.1SY supports 4096 VLANs in accordance with the IEEE 802.1Q standard. These
VLANs are organized into several ranges; you use each range slightly differently. Some of these VLANs
are propagated to other switches in the network when you use the VLAN Trunking Protocol (VTP). The
extended-range VLANs are not propagated, so you must configure extended-range VLANs manually on
each network device.
Table 16-1 describes the VLAN ranges.
Table 16-1
VLAN Ranges
VLANs
Range
Usage
Propagated
by VTP
0, 4095
Reserved
For system use only. You cannot see or use these VLANs.
—
1
Normal
Cisco default. You can use this VLAN but you cannot delete it. Yes
2–1001
Normal
For Ethernet VLANs; you can create, use, and delete these
VLANs.
Yes
1002–1005 Normal
Cisco defaults for FDDI and Token Ring. You cannot delete
VLANs 1002–1005.
Yes
1006–4094 Extended
For Ethernet VLANs only.
No
3968–4031 MET
VLANs
Reserved for internal usage.
—
The following information applies to VLAN ranges:
•
Layer 3 LAN ports, WAN interfaces and subinterfaces, and some software features use internal
VLANs in the extended range. You cannot use an extended range VLAN that has been allocated for
internal use.
•
To display the VLANs used internally, enter the show vlan internal usage command. With earlier
releases, enter the show vlan internal usage and show cwan vlans commands.
•
You can configure ascending internal VLAN allocation (from 1006 and up) or descending internal
VLAN allocation (from 4094 and down).
•
You must enable the extended system ID to use extended range VLANs (see the “Information about
the Bridge ID” section on page 1-3).
Default Settings for VLANs
•
VLAN ID: 1; range: 1–4094
•
VLAN name:
– VLAN 1: “default”
– Other VLANs: “VLANvlan_ID”
•
802.10 SAID: 10vlan_ID; range: 100001–104094
•
MTU size: 1500; range: 1500–18190
•
Translational bridge 1: 0; range: 0–1005
•
Translational bridge 2: 0; range: 0–1005
•
VLAN state: active: active, suspend
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-3
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
•
Pruning eligibility:
– VLANs 2–1001 are pruning eligible
– VLANs 1006–4094 are not pruning eligible
How to Configure VLANs
•
Configurable VLAN Parameters, page 16-4
•
VLAN Locking, page 16-4
•
Creating or Modifying an Ethernet VLAN, page 16-5
•
Assigning a Layer 2 LAN Interface to a VLAN, page 16-6
•
Configuring the Internal VLAN Allocation Policy, page 16-6
•
Configuring VLAN Translation, page 16-7
•
Saving VLAN Information, page 16-9
Configurable VLAN Parameters
Note
•
Ethernet VLAN 1 uses only default values.
•
Except for the VLAN name, Ethernet VLANs 1006 through 4094 use only default values.
•
You can configure the VLAN name for Ethernet VLANs 1006 through 4094.
You can configure the following parameters for VLANs 2 through 1001:
•
VLAN name
•
VLAN type (Ethernet, FDDI, FDDI network entity title [NET], TrBRF, or TrCRF)
•
VLAN state (active or suspended)
•
Security Association Identifier (SAID)
•
Bridge identification number for TrBRF VLANs
•
Ring number for FDDI and TrCRF VLANs
•
Parent VLAN number for TrCRF VLANs
•
Spanning Tree Protocol (STP) type for TrCRF VLANs
VLAN Locking
The VLAN locking feature provides an extra level of verification to ensure that you have configured the
intended VLAN. When VLAN locking is enabled, you need to specify the VLAN name when you change
a port from one VLAN to another. This feature affects switchport commands (in interface configuration
mode) that specify the VLANs or private VLANs for access and trunk ports.
For additional information about how to configure access and trunk ports with VLAN locking enabled,
see the “How to Configure LAN Interfaces for Layer 2 Switching” section on page 11-5.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-4
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
For additional information about how to configure ports in private VLANs with VLAN locking enabled,
see the “How to Configure Private VLANs” section on page 17-10.
By default, the VLAN locking is disabled. To enable VLAN locking, perform this task:
Command
Purpose
Router(config)# vlan port provisioning
Enables VLAN locking.
Creating or Modifying an Ethernet VLAN
User-configured VLANs have unique IDs from 1 to 4094, except for reserved VLANs (see Table 16-1 on
page 16-3). Enter the vlan command with an unused ID to create a VLAN. Enter the vlan command for
an existing VLAN to modify the VLAN (you cannot modify an existing VLAN that is being used by a
Layer 3 port or a software feature).
See the “Default Settings for VLANs” section on page 16-3 for the list of default parameters that are
assigned when you create a VLAN. If you do not specify the VLAN type with the media keyword, the
VLAN is an Ethernet VLAN.
To create or modify a VLAN, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters configuration mode.
Step 2
Router(config)# vlan vlan_ID{[-vlan_ID]|[,vlan_ID])
Creates or modifies an Ethernet VLAN, a range of
Ethernet VLANs, or several Ethernet VLANs specified
in a comma-separated list (do not enter space
characters).
Step 3
Router(config-vlan)# end
Updates the VLAN database and returns to privileged
EXEC mode.
When you create or modify an Ethernet VLAN, note the following information:
•
Because Layer 3 ports and some software features require internal VLANs allocated from 1006 and
up, configure extended-range VLANs starting with 4094.
•
You can configure extended-range VLANs only in global configuration mode. You cannot configure
extended-range VLANs in VLAN database mode.
•
Layer 3 ports and some software features use extended-range VLANs. If the VLAN you are trying
to create or modify is being used by a Layer 3 port or a software feature, the switch displays a
message and does not modify the VLAN configuration.
When deleting VLANs, note the following information:
•
You cannot delete the default VLANs for the different media types: Ethernet VLAN 1 and FDDI or
Token Ring VLANs 1002 to 1005.
•
When you delete a VLAN, any LAN ports configured as access ports assigned to that VLAN become
inactive. The ports remain associated with the VLAN (and inactive) until you assign them to a new
VLAN.
This example shows how to create an Ethernet VLAN in global configuration mode and verify the
configuration:
Router# configure terminal
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-5
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
Router(config)# vlan 3
Router(config-vlan)# end
Router# show vlan id 3
VLAN Name
Status
Ports
---- -------------------------------- --------- ------------------------------3
VLAN0003
active
VLAN Type SAID
MTU
Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ -----3
enet 100003
1500 0
0
Primary Secondary Type
Interfaces
------- --------- ----------------- ------------------------------------------
Assigning a Layer 2 LAN Interface to a VLAN
A VLAN created in a management domain remains unused until you assign one or more LAN ports to
the VLAN.
Note
Make sure you assign LAN ports to a VLAN of the appropriate type. Assign Ethernet ports to
Ethernet-type VLANs.
To assign one or more LAN ports to a VLAN, complete the procedures in the “How to Configure LAN
Interfaces for Layer 2 Switching” section on page 11-5.
Configuring the Internal VLAN Allocation Policy
For more information about VLAN allocation, see the “VLAN Ranges” section on page 16-2.
Note
The internal VLAN allocation policy is applied only following a reload.
To configure the internal VLAN allocation policy, perform this task:
Command
Purpose
Step 1
Router(config)# vlan internal allocation policy
{ascending | descending}
Configures the internal VLAN allocation policy.
Step 2
Router(config)# end
Exits configuration mode.
Step 3
Router# reload
Applies the new internal VLAN allocation policy.
Caution
You do not need to enter the reload command
immediately. Enter the reload command
during a planned maintenance window.
When you configure the internal VLAN allocation policy, note the following information:
•
Enter the ascending keyword to allocate internal VLANs from 1006 and up.
•
Enter the descending keyword to allocate internal VLAN from 4094 and down.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-6
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
This example shows how to configure descending as the internal VLAN allocation policy:
Router# configure terminal
Router(config)# vlan internal allocation policy descending
Configuring VLAN Translation
Note
•
VLAN Translation Guidelines and Restrictions, page 16-7
•
Configuring VLAN Translation on a Trunk Port, page 16-8
•
Enabling VLAN Translation on Other Ports in a Port Group, page 16-9
•
To avoid spanning tree loops, be careful not to misconfigure the VLAN translation feature.
•
On trunk ports, you can translate one VLAN number to another VLAN number, which transfers all
traffic received in one VLAN to the other VLAN.
VLAN Translation Guidelines and Restrictions
When translating VLANs, follow these guidelines and restrictions:
•
A VLAN translation configuration is inactive if it is applied to ports that are not Layer 2 trunks.
•
Do not configure translation of ingress native VLAN traffic on an 802.1Q trunk. Because 802.1Q
native VLAN traffic is untagged, it cannot be recognized for translation. You can translate traffic
from other VLANs to the native VLAN of an 802.1Q trunk.
•
Do not remove the VLAN to which you are translating from the trunk.
•
The VLAN translation configuration applies to all ports in a port group. VLAN translation is
disabled by default on all ports in a port group. Enable VLAN translation on ports as needed.
•
Cisco IOS Release 15.1SY supports only IEEE 802.1Q trunking.
Table 16-2
Module Support for VLAN Translation
Product Number
Number of Ports
Number of
Port Groups
Port Ranges
per Port Group
Translations
per Port Group
VS-S2T-10G-XL
VS-S2T-10G
5
5
1 port in each group
16
WS-X6904-40G-2T
See the Release Notes.
WS-X6908-10GE
8
8
1 port in each group
16
WS-X6816-10T-2T,
WS-X6716-10T
16
16
1 port in each group
16
WS-X6816-10G-2T,
WS-X6716-10GE
16
16
1 port in each group
16
WS-X6704-10GE
4
4
1 port in each group
128
WS-X6848-TX-2T,
WS-X6748-GE-TX
48
4
1–12
13–24
25–36
37–48
128
16
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-7
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
Table 16-2
Note
Module Support for VLAN Translation (continued)
Product Number
Number of Ports
Number of
Port Groups
Port Ranges
per Port Group
Translations
per Port Group
WS-X6848-SFP-2T,
WS-X6748-SFP
48
4
1–23, odd
2–24, even
25–47, odd
26–48, even
128
WS-X6824-SFP-2T,
WS-X6724-SFP
24
2
1–12
13–24
128
To configure a port as a trunk, see the “Configuring a Layer 2 Switching Port as a Trunk” section on
page 11-8.
Configuring VLAN Translation on a Trunk Port
To translate VLANs on a trunk port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the Layer 2 trunk port to configure.
Step 2
Router(config-if)# switchport vlan mapping enable
Enables VLAN translation.
Step 3
Router(config-if)# switchport vlan mapping
original_vlan_ID translated_vlan_ID
Translates a VLAN to another VLAN. The valid range is
1 to 4094.
When you configure a VLAN mapping from the original
VLAN to the translated VLAN on a port, traffic arriving
on the original VLAN gets mapped or translated to the
translated VLAN at the ingress of the switch port, and the
traffic internally tagged with the translated VLAN gets
mapped to the original VLAN before leaving the switch
port. This method of VLAN mapping is a two-way
mapping.
Step 4
Router(config-if)# end
Exits configuration mode.
This example shows how to map VLAN 1649 to VLAN 755 Gigabit Ethernet port 5/2:
Router# configure terminal
Router(config)# interface gigabitethernet 5/2
Router(config-if)# switchport vlan mapping 1649 755
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show interface gigabitethernet 5/2 vlan mapping
State: enabled
Original VLAN Translated VLAN
------------- --------------1649
755
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-8
Chapter 16
Virtual Local Area Networks (VLANs)
How to Configure VLANs
Enabling VLAN Translation on Other Ports in a Port Group
To enable VLAN translation on other ports in a port group, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# switchport vlan mapping enable
Enables VLAN translation.
Step 3
Router(config-if)# end
Exits configuration mode.
This example shows how to enable VLAN translation on a port:
Router# configure terminal
Router(config)# interface gigabitethernet 5/2
Router(config-if)# switchport vlan mapping enable
Router(config-if)# end
Saving VLAN Information
The VLAN database is stored in the vlan.dat file. You should create a backup of the vlan.dat file in
addition to backing up the running-config and startup-config files. If you replace the existing supervisor
engine, copy the startup-config file as well as the vlan.dat file to restore the system. The vlan.dat file is
read on bootup and you will have to reload the supervisor engine after uploading the file. To view the
file location, use the dir vlan.dat command. To copy the file (binary), use the copy vlan.dat tftp
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-9
Chapter 16
How to Configure VLANs
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
16-10
Virtual Local Area Networks (VLANs)
CH AP TE R
17
Private VLANs
Note
•
Prerequisites for Private VLANs, page 17-1
•
Restrictions for Private VLANs, page 17-2
•
Information About Private VLANs, page 17-5
•
Default Settings for Private VLANs, page 17-10
•
How to Configure Private VLANs, page 17-10
•
Monitoring Private VLANs, page 17-16
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Private VLANs
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-1
Chapter 17
Private VLANs
Restrictions for Private VLANs
Restrictions for Private VLANs
•
Secondary and Primary VLANs, page 17-2
•
Private VLAN Ports, page 17-4
•
Limitations with Other Features, page 17-4
Secondary and Primary VLANs
•
After you configure a private VLAN and set VTP to transparent mode, you are not allowed to change
the VTP mode to client or server. For information about VTP, see Chapter 15, “VLAN Trunking
Protocol (VTP).”
•
After you have configured private VLANs, use the copy running-config startup config privileged
EXEC command to save the VTP transparent mode configuration and private VLAN configuration
in the startup-config file. If the switch resets it must default to VTP transparent mode to support
private VLANs.
•
In VTP versions 1 and 2, VTP does not propagate a private VLAN configuration and you must
configure private VLANs on each device where you want private VLAN ports. In VTP version 3,
VTP does propagate private VLAN configurations automatically.
•
You cannot configure VLAN 1 or VLANs 1002 to 1005 as primary or secondary VLANs.
•
A primary VLAN can have one isolated VLAN and multiple community VLANs associated with it.
An isolated or community VLAN can have only one primary VLAN associated with it.
•
When a secondary VLAN is associated with the primary VLAN, the STP parameters of the primary
VLAN, such as bridge priorities, are propagated to the secondary VLAN. However, STP parameters
do not necessarily propagate to other devices. You should manually check the STP configuration to
ensure that the primary, isolated, and community VLANs’ spanning tree topologies match so that
the VLANs can properly share the same forwarding database.
•
If you enable MAC address reduction on the switch, we recommend that you enable MAC address
reduction on all the devices in your network to ensure that the STP topologies of the private VLANs
match.
•
In a network where private VLANs are configured, if you enable MAC address reduction on some
devices and disable it on others (mixed environment), use the default bridge priorities to make sure
that the root bridge is common to the primary VLAN and to all its associated isolated and
community VLANs. Be consistent with the ranges employed by the MAC address reduction feature
regardless of whether it is enabled on the system. MAC address reduction allows only discrete levels
and uses all intermediate values internally as a range. You should disable a root bridge with private
VLANs and MAC address reduction, and configure the root bridge with any priority higher than the
highest priority range used by any nonroot bridge.
•
You cannot apply VACLs to secondary VLANs. (See Chapter 45, “VLAN ACLs (VACLs)”.)
•
You can enable DHCP snooping on private VLANs. When you enable DHCP snooping on the
primary VLAN, it is propagated to the secondary VLANs. If you configure DHCP on a secondary
VLAN, the configuration does not take effect if the primary VLAN is already configured.
•
We recommend that you prune the private VLANs from the trunks on devices that carry no traffic
in the private VLANs.
•
You can apply different quality of service (QoS) configurations to primary, isolated, and community
VLANs. (See Chapter 32, “PFC QoS Overview”.)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-2
Chapter 17
Private VLANs
Restrictions for Private VLANs
•
When you configure private VLANs, sticky Address Resolution Protocol (ARP) is enabled by
default, and ARP entries learned on Layer 3 private VLAN interfaces are sticky ARP entries. For
security reasons, private VLAN port sticky ARP entries do not age out. For information about
configuring sticky ARP, see the “Configuring Sticky ARP” section on page 47-9.
•
We recommend that you display and verify private VLAN interface ARP entries.
•
Sticky ARP prevents MAC address spoofing by ensuring that ARP entries (IP address, MAC
address, and source VLAN) do not age out. You can configure sticky ARP on a per-interface basis.
For information about configuring sticky ARP, see the “Configuring Sticky ARP” section on
page 47-9. The following guidelines and restrictions apply to private VLAN sticky ARP:
– ARP entries learned on Layer 3 private VLAN interfaces are sticky ARP entries.
– Connecting a device with a different MAC address but with the same IP address generates a
message and the ARP entry is not created.
– Because the private VLAN port sticky ARP entries do not age out, you must manually remove
private VLAN port ARP entries if a MAC address changes. You can add or remove private
VLAN ARP entries manually as follows:
Router(config)# no arp 11.1.3.30
IP ARP:Deleting Sticky ARP entry 11.1.3.30
Router(config)# arp 11.1.3.30 0000.5403.2356 arpa
IP ARP:Overwriting Sticky ARP entry 11.1.3.30, hw:00d0.bb09.266e by
hw:0000.5403.2356
•
You can configure VLAN maps on primary and secondary VLANs. (See the “Applying a VLAN
Access Map” section on page 45-4.) However, we recommend that you configure the same VLAN
maps on private VLAN primary and secondary VLANs.
•
When a frame is Layer 2 forwarded within a private VLAN, the same VLAN map is applied at the
ingress side and at the egress side. When a frame is routed from inside a private VLAN to an external
port, the private VLAN map is applied at the ingress side.
– For frames going upstream from a host port to a promiscuous port, the VLAN map configured
on the secondary VLAN is applied.
– For frames going downstream from a promiscuous port to a host port, the VLAN map
configured on the primary VLAN is applied.
To filter out specific IP traffic for a private VLAN, you should apply the VLAN map to both the
primary and secondary VLANs.
•
To apply Cisco IOS output ACLs to all outgoing private VLAN traffic, configure them on the
Layer 3 VLAN interface of the primary VLAN. (See Chapter 43, “MAC Address-Based Traffic
Blocking”.)
•
Cisco IOS ACLs applied to the Layer 3 VLAN interface of a primary VLAN automatically apply to
the associated isolated and community VLANs.
•
Do not apply Cisco IOS ACLs to isolated or community VLANs. Cisco IOS ACL configuration
applied to isolated and community VLANs is inactive while the VLANs are part of the private
VLAN configuration.
•
Although private VLANs provide host isolation at Layer 2, hosts can communicate with each other
at Layer 3.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-3
Chapter 17
Private VLANs
Restrictions for Private VLANs
•
Private VLANs support these Switched Port Analyzer (SPAN) features:
– You can configure a private VLAN port as a SPAN source port.
– You can use VLAN-based SPAN (VSPAN) on primary, isolated, and community VLANs or use
SPAN on only one VLAN to separately monitor egress or ingress traffic.
– For more information about SPAN, see Chapter 27, “Local SPAN, RSPAN, and ERSPAN.”
Private VLAN Ports
•
Use only the private VLAN configuration commands to assign ports to primary, isolated, or
community VLANs. Layer 2 access ports assigned to the VLANs that you configure as primary,
isolated, or community VLANs are inactive while the VLAN is part of the private VLAN
configuration. Layer 2 trunk interfaces remain in the STP forwarding state.
•
Do not configure ports that belong to a PAgP or LACP EtherChannel as private VLAN ports. While
a port is part of the private VLAN configuration, any EtherChannel configuration for it is inactive.
•
Enable PortFast and BPDU guard on isolated and community host ports to prevent STP loops due
to misconfigurations and to speed up STP convergence. (See Chapter 2, “Optional STP Features”.)
When enabled, STP applies the BPDU guard feature to all PortFast-configured Layer 2 LAN ports.
Do not enable PortFast and BPDU guard on promiscuous ports.
•
If you delete a VLAN used in the private VLAN configuration, the private VLAN ports associated
with the VLAN become inactive.
•
Private VLAN ports can be on different network devices if the devices are trunk-connected and the
primary and secondary VLANs have not been removed from the trunk.
•
All primary, isolated, and community VLANs associated within a private VLAN must maintain the
same topology across trunks. You are highly recommended to configure the same STP bridge
parameters and trunk port parameters on all associated VLANs in order to maintain the same
topology.
Limitations with Other Features
•
VTP version 3 is not supported on private VLAN (PVLAN) ports.
•
In some cases, the configuration is accepted with no error messages, but the commands have no
effect.
•
Do not configure fallback bridging on switches with private VLANs.
•
A port is only affected by the private VLAN feature if it is currently in private VLAN mode and its
private VLAN configuration indicates that it is a primary, isolated, or community port. If a port is
in any other mode, such as Dynamic Trunking Protocol (DTP), it does not function as a private port.
•
Do not configure private VLAN ports on interfaces configured for these other features:
– Port Aggregation Protocol (PAgP)
– Link Aggregation Control Protocol (LACP)
– Voice VLAN
•
You can configure IEEE 802.1x port-based authentication on a private VLAN port, but do not
configure 802.1x with port security, voice VLAN, or per-user ACL on private VLAN ports.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-4
Chapter 17
Private VLANs
Information About Private VLANs
•
Do not configure a remote SPAN (RSPAN) VLAN as a private VLAN primary or secondary VLAN.
For more information about SPAN, see Chapter 27, “Local SPAN, RSPAN, and ERSPAN.”
•
A private VLAN host or promiscuous port cannot be a SPAN destination port. If you configure a
SPAN destination port as a private VLAN port, the port becomes inactive.
•
A destination SPAN port should not be an isolated port. (However, a source SPAN port can be an
isolated port.) VSPAN could be configured to span both primary and secondary VLANs or,
alternatively, to span either one if the user is interested only in ingress or egress traffic.
•
If using the shortcuts between different VLANs (if any of these VLANs is private) consider both
primary and isolated and community VLANs. The primary VLAN should be used both as the
destination and as the virtual source, because the secondary VLAN (the real source) is always
remapped to the primary VLAN in the Layer 2 FID table.
•
If you configure a static MAC address on a promiscuous port in the primary VLAN, you must add
the same static address to all associated secondary VLANs. If you configure a static MAC address
on a host port in a secondary VLAN, you must add the same static MAC address to the associated
primary VLAN. When you delete a static MAC address from a private VLAN port, you must remove
all instances of the configured MAC address from the private VLAN.
Note
•
Dynamic MAC addresses learned in one VLAN of a private VLAN are replicated in the
associated VLANs. For example, a MAC address learned in a secondary VLAN is replicated
in the primary VLAN. When the original dynamic MAC address is deleted or aged out, the
replicated addresses are removed from the MAC address table.
Do not configure private VLAN ports as EtherChannels. A port can be part of the private VLAN
configuration, but any EtherChannel configuration for the port is inactive.
Information About Private VLANs
•
Private VLAN Domains, page 17-5
•
Private VLAN Ports, page 17-7
•
Primary, Isolated, and Community VLANs, page 17-7
•
Private VLAN Port Isolation, page 17-8
•
IP Addressing Scheme with Private VLANs, page 17-8
•
Private VLANs Across Multiple Switches, page 17-9
•
Private VLAN Interaction with Other Features, page 17-9
Private VLAN Domains
The private VLAN feature addresses two problems that service providers encounter when using VLANs:
•
The switch supports up to 4096 VLANs. If a service provider assigns one VLAN per customer, the
number of customers that service provider can support is limited.
•
To enable IP routing, each VLAN is assigned a subnet address space or a block of addresses, which
can result in wasting the unused IP addresses and creating IP address management problems.
Using private VLANs solves the scalability problem and provides IP address management benefits for
service providers and Layer 2 security for customers.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-5
Chapter 17
Private VLANs
Information About Private VLANs
The private VLAN feature partitions the Layer 2 broadcast domain of a VLAN into subdomains. A
subdomain is represented by a pair of private VLANs: a primary VLAN and a secondary VLAN. A
private VLAN domain can have multiple private VLAN pairs, one pair for each subdomain. All VLAN
pairs in a private VLAN domain share the same primary VLAN. The secondary VLAN ID differentiates
one subdomain from another (see Figure 17-1).
Figure 17-1
Private VLAN Domain
Private
VLAN
domain
Subdomain
Subdomain
Secondary
isolated VLAN
116083
Secondary
community VLAN
Primary
VLAN
A private VLAN domain has only one primary VLAN. Every port in a private VLAN domain is a
member of the primary VLAN. In other words, the primary VLAN is the entire private VLAN domain.
Secondary VLANs provide Layer 2 isolation between ports within the same private VLAN domain.
There are two types of secondary VLANs:
•
Isolated VLANs—Ports within an isolated VLAN cannot communicate with each other at the
Layer 2 level.
•
Community VLANs—Ports within a community VLAN can communicate with each other but
cannot communicate with ports in other communities at the Layer 2 level.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-6
Chapter 17
Private VLANs
Information About Private VLANs
Private VLAN Ports
There are three types of private VLAN ports:
•
Promiscuous—A promiscuous port belongs to the primary VLAN and can communicate with all
interfaces, including the community and isolated host ports that belong to the secondary VLANs that
are associated with the primary VLAN.
•
Isolated—An isolated port is a host port that belongs to an isolated secondary VLAN. This port has
complete Layer 2 isolation from other ports within the same private VLAN domain, except for the
promiscuous ports. Private VLANs block all traffic to isolated ports except traffic from promiscuous
ports. Traffic received from an isolated port is forwarded only to promiscuous ports.
•
Community—A community port is a host port that belongs to a community secondary VLAN.
Community ports communicate with other ports in the same community VLAN and with
promiscuous ports. These interfaces are isolated at Layer 2 from all other interfaces in other
communities and from isolated ports within their private VLAN domain.
Note
Because trunks can support the VLANs carrying traffic between isolated, community, and
promiscuous ports, isolated and community port traffic might enter or leave the switch
through a trunk interface.
Primary, Isolated, and Community VLANs
Primary VLANs and the two types of secondary VLANs, isolated VLANs and community VLANs, have
these characteristics:
•
Primary VLAN— The primary VLAN carries unidirectional traffic downstream from the
promiscuous ports to the (isolated and community) host ports and to other promiscuous ports.
•
Isolated VLAN —A private VLAN domain has only one isolated VLAN. An isolated VLAN is a
secondary VLAN that carries unidirectional traffic upstream from the hosts toward the promiscuous
ports and the gateway.
•
Community VLAN—A community VLAN is a secondary VLAN that carries upstream traffic from
the community ports to the promiscuous port gateways and to other host ports in the same
community. You can configure multiple community VLANs in a private VLAN domain.
A promiscuous port can serve only one primary VLAN, one isolated VLAN, and multiple community
VLANs. Layer 3 gateways are connected typically to the switch through a promiscuous port. With a
promiscuous port, you can connect a wide range of devices as access points to a private VLAN. For
example, you can use a promiscuous port to monitor or back up all the private VLAN servers from an
administration workstation.
In a switched environment, you can assign an individual private VLAN and associated IP subnet to each
individual or common group of end stations. The end stations need to communicate only with a default
gateway to communicate outside the private VLAN.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-7
Chapter 17
Private VLANs
Information About Private VLANs
Private VLAN Port Isolation
You can use private VLANs to control access to end stations in these ways:
•
Configure selected interfaces connected to end stations as isolated ports to prevent any
communication at Layer 2. For example, if the end stations are servers, this configuration prevents
Layer 2 communication between the servers.
•
Configure interfaces connected to default gateways and selected end stations (for example, backup
servers) as promiscuous ports to allow all end stations access to a default gateway.
You can extend private VLANs across multiple devices by trunking the primary, isolated, and
community VLANs to other devices that support private VLANs. To maintain the security of your
private VLAN configuration and to avoid other use of the VLANs configured as private VLANs,
configure private VLANs on all intermediate devices, including devices that have no private VLAN
ports.
IP Addressing Scheme with Private VLANs
When you assign a separate VLAN to each customer, an inefficient IP addressing scheme is created as
follows:
•
Assigning a block of addresses to a customer VLAN can result in unused IP addresses.
•
If the number of devices in the VLAN increases, the number of assigned addresses might not be
large enough to accommodate them.
These problems are reduced by using private VLANs, where all members in the private VLAN share a
common address space, which is allocated to the primary VLAN. Hosts are connected to secondary
VLANs, and the DHCP server assigns them IP addresses from the block of addresses allocated to the
primary VLAN. Subsequent IP addresses can be assigned to customer devices in different secondary
VLANs, but in the same primary VLAN. When new devices are added, the DHCP server assigns them
the next available address from a large pool of subnet addresses.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-8
Chapter 17
Private VLANs
Information About Private VLANs
Private VLANs Across Multiple Switches
As with regular VLANs, private VLANs can span multiple switches. A trunk port carries the primary
VLAN and secondary VLANs to a neighboring switch. The trunk port deals with the private VLAN as
any other VLAN. A feature of private VLANs across multiple switches is that traffic from an isolated
port in switch A does not reach an isolated port on Switch B. (See Figure 17-2.)
Figure 17-2
Private VLANs Across Switches
Trunk ports
VLAN 100
VLAN 100
Switch B
VLAN 201
VLAN 202
VLAN 201
VLAN 202
Carries VLAN 100,
201, and 202 traffic
116084
Switch A
VLAN 100 = Primary VLAN
VLAN 201 = Secondary isolated VLAN
VLAN 202 = Secondary community VLAN
Because VTP versions 1 and 2 do not support private VLANs, you must manually configure private
VLANs on all switches in the Layer 2 network. If you do not configure the primary and secondary VLAN
association in some switches in the network, the Layer 2 databases in these switches are not merged.
This situation can result in unnecessary flooding of private VLAN traffic on those switches.
VTP version 3 does support private VLANs, so you do not need to manually configure private VLANs
on all switches in the Layer 2 network.
Private VLAN Interaction with Other Features
•
Private VLANs and Unicast, Broadcast, and Multicast Traffic, page 17-10
•
Private VLANs and SVIs, page 17-10
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-9
Chapter 17
Private VLANs
Default Settings for Private VLANs
Private VLANs and Unicast, Broadcast, and Multicast Traffic
In regular VLANs, devices in the same VLAN can communicate with each other at the Layer 2 level, but
devices connected to interfaces in different VLANs must communicate at the Layer 3 level. In private
VLANs, the promiscuous ports are members of the primary VLAN, while the host ports belong to
secondary VLANs. Because the secondary VLAN is associated to the primary VLAN, members of the
these VLANs can communicate with each other at the Layer 2 level.
In a regular VLAN, broadcasts are forwarded to all ports in that VLAN. Private VLAN broadcast
forwarding depends on the port sending the broadcast:
•
An isolated port sends a broadcast only to the promiscuous ports or trunk ports.
•
A community port sends a broadcast to all promiscuous ports, trunk ports, and ports in the same
community VLAN.
•
A promiscuous port sends a broadcast to all ports in the private VLAN (other promiscuous ports,
trunk ports, isolated ports, and community ports).
Multicast traffic is routed or bridged across private VLAN boundaries and within a single community
VLAN. Multicast traffic is not forwarded between ports in the same isolated VLAN or between ports in
different secondary VLANs.
Private VLANs and SVIs
A switch virtual interface (SVI) is the Layer 3 interface of a Layer 2 VLAN. Layer 3 devices
communicate with a private VLAN only through the primary VLAN and not through secondary VLANs.
Configure Layer 3 VLAN SVIs only for primary VLANs. Do not configure Layer 3 VLAN interfaces
for secondary VLANs. SVIs for secondary VLANs are inactive while the VLAN is configured as a
secondary VLAN.
•
If you try to configure a VLAN with an active SVI as a secondary VLAN, the configuration is not
allowed until you disable the SVI.
•
If you try to create an SVI on a VLAN that is configured as a secondary VLAN, and the secondary
VLAN is already mapped at Layer 3, the SVI is not created, and an error is returned. If the SVI is
not mapped at Layer 3, the SVI is created, but it is automatically shut down.
When the primary VLAN is associated with and mapped to the secondary VLAN, any configuration on
the primary VLAN is propagated to the secondary VLAN SVIs. For example, if you assign an IP subnet
to the primary VLAN SVI, this subnet is the IP subnet address of the entire private VLAN.
Default Settings for Private VLANs
None.
How to Configure Private VLANs
•
Configuring a VLAN as a Private VLAN, page 17-11
•
Associating Secondary VLANs with a Primary VLAN, page 17-12
•
Mapping Secondary VLANs to the Layer 3 VLAN Interface of a Primary VLAN, page 17-13
•
Configuring a Layer 2 Interface as a Private VLAN Host Port, page 17-14
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-10
Chapter 17
Private VLANs
How to Configure Private VLANs
•
Note
Configuring a Layer 2 Interface as a Private VLAN Promiscuous Port, page 17-15
If the VLAN is not defined already, the private VLAN configuration process defines it.
Configuring a VLAN as a Private VLAN
To configure a VLAN as a private VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# vlan vlan_ID
Enters VLAN configuration submode.
Step 2
Router(config-vlan)# private-vlan {community |
isolated | primary}
Configures a VLAN as a private VLAN.
Note
Step 3
Router(config-vlan)# end
These commands do not take effect until you exit
VLAN configuration submode.
Exits configuration mode.
This example shows how to configure VLAN 202 as a primary VLAN and verify the configuration:
Router# configure terminal
Router(config)# vlan 202
Router(config-vlan)# private-vlan primary
Router(config-vlan)# end
Router# show vlan private-vlan
Primary Secondary Type
Interfaces
------- --------- ----------------- -----------------------------------------202
primary
This example shows how to configure VLAN 303 as a community VLAN and verify the configuration:
Router# configure terminal
Router(config)# vlan 303
Router(config-vlan)# private-vlan community
Router(config-vlan)# end
Router# show vlan private-vlan
Primary Secondary Type
Interfaces
------- --------- ----------------- -----------------------------------------202
primary
303
community
This example shows how to configure VLAN 440 as an isolated VLAN and verify the configuration:
Router# configure terminal
Router(config)# vlan 440
Router(config-vlan)# private-vlan isolated
Router(config-vlan)# end
Router# show vlan private-vlan
Primary Secondary Type
Interfaces
------- --------- ----------------- -----------------------------------------202
primary
303
community
440
isolated
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-11
Chapter 17
Private VLANs
How to Configure Private VLANs
Associating Secondary VLANs with a Primary VLAN
To associate secondary VLANs with a primary VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# vlan primary_vlan_ID
Enters VLAN configuration submode for the primary
VLAN.
Step 2
Router(config-vlan)# private-vlan association
{secondary_vlan_list | add secondary_vlan_list |
remove secondary_vlan_list}
Associates the secondary VLANs with the primary
VLAN.
Step 3
Router(config-vlan)# end
Exits VLAN configuration mode.
When you associate secondary VLANs with a primary VLAN, note the following information:
•
The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated
items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.
•
The secondary_vlan_list parameter can contain multiple community VLAN IDs.
•
The secondary_vlan_list parameter can contain only one isolated VLAN ID.
•
Enter a secondary_vlan_list or use the add keyword with a secondary_vlan_list to associate
secondary VLANs with a primary VLAN.
•
Use the remove keyword with a secondary_vlan_list to clear the association between secondary
VLANs and a primary VLAN.
•
The command does not take effect until you exit VLAN configuration submode.
This example shows how to associate community VLANs 303 through 307 and 309 and isolated VLAN
440 with primary VLAN 202 and verify the configuration:
Router# configure terminal
Router(config)# vlan 202
Router(config-vlan)# private-vlan association 303-307,309,440
Router(config-vlan)# end
Router# show vlan private-vlan
Primary
------202
202
202
202
202
202
202
Secondary
--------303
304
305
306
307
309
440
308
Type
Interfaces
----------------- -----------------------------------------community
community
community
community
community
community
isolated
community
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-12
Chapter 17
Private VLANs
How to Configure Private VLANs
Mapping Secondary VLANs to the Layer 3 VLAN Interface of a Primary VLAN
Note
Isolated and community VLANs are both called secondary VLANs.
To map secondary VLANs to the Layer 3 VLAN interface of a primary VLAN to allow Layer 3 switching
of private VLAN ingress traffic, perform this task:
Command
Purpose
Step 1
Router(config)# interface vlan primary_vlan_ID
Enters interface configuration mode for the primary
VLAN.
Step 2
Router(config-if)# private-vlan mapping
{secondary_vlan_list | add secondary_vlan_list |
remove secondary_vlan_list}
Maps the secondary VLANs to the Layer 3 VLAN
interface of a primary VLAN to allow Layer 3 switching
of private VLAN ingress traffic.
Router(config-if)# [no] private-vlan mapping
Clears the mapping between the secondary VLANs and
the primary VLAN.
Router(config-if)# end
Exits configuration mode.
Step 3
When you map secondary VLANs to the Layer 3 VLAN interface of a primary VLAN, note the
following information:
•
The private-vlan mapping interface configuration command only affects private VLAN ingress
traffic that is Layer 3-switched.
•
The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated
items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.
•
Enter a secondary_vlan_list parameter or use the add keyword with a secondary_vlan_list
parameter to map the secondary VLANs to the primary VLAN.
•
Use the remove keyword with a secondary_vlan_list parameter to clear the mapping between
secondary VLANs and the primary VLAN.
This example shows how to permit routing of secondary VLAN ingress traffic from private VLANs 303
through 307, 309, and 440 and verify the configuration:
Router# configure terminal
Router(config)# interface vlan 202
Router(config-if)# private-vlan mapping add 303-307,309,440
Router(config-if)# end
Router# show interfaces private-vlan mapping
Interface Secondary VLAN Type
--------- -------------- ----------------vlan202
303
community
vlan202
304
community
vlan202
305
community
vlan202
306
community
vlan202
307
community
vlan202
309
community
vlan202
440
isolated
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-13
Chapter 17
Private VLANs
How to Configure Private VLANs
Configuring a Layer 2 Interface as a Private VLAN Host Port
To configure a Layer 2 interface as a private VLAN host port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
•
You must enter the switchport command once
without any keywords to configure the LAN port as a
Layer 2 interface before you can enter additional
switchport commands with keywords.
•
Required only if you have not entered the switchport
command already for the interface.
Step 3
Router(config-if)# switchport mode private-vlan
{host | promiscuous}
Configures the Layer 2 port as a private VLAN host port.
Step 4
Router(config-if)# switchport private-vlan
host-association primary_vlan_ID
secondary_vlan_ID
Associates the Layer 2 port with a private VLAN.
Router(config-if)# end
Exits configuration mode.
Step 5
Note
If VLAN locking is enabled, enter the VLAN
name instead of the VLAN number. For more
information, see the “VLAN Locking” section on
page 16-4.
This example shows how to configure interface GigabitEthernet 5/1 as a private VLAN host port and
verify the configuration:
Router# configure terminal
Router(config)# interface gigabitethernet 5/1
Router(config-if)# switchport mode private-vlan host
Router(config-if)# switchport private-vlan host-association 202 303
Router(config-if)# end
Router# show interfaces gigabitethernet 5/1 switchport | include private-vlan
Administrative Mode: private-vlan host
Administrative private-vlan host-association: 202 (VLAN0202) 303 (VLAN0303)
Administrative private-vlan mapping: none
Operational private-vlan: none
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-14
Chapter 17
Private VLANs
How to Configure Private VLANs
Configuring a Layer 2 Interface as a Private VLAN Promiscuous Port
To configure a Layer 2 interface as a private VLAN promiscuous port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN interface to configure.
Step 2
Router(config-if)# switchport
Configures the LAN interface for Layer 2 switching:
•
You must enter the switchport command once
without any keywords to configure the LAN interface
as a Layer 2 interface before you can enter additional
switchport commands with keywords.
•
Required only if you have not entered the switchport
command already for the interface.
Step 3
Router(config-if)# switchport mode private-vlan
{host | promiscuous}
Configures the Layer 2 port as a private VLAN
promiscuous port.
Step 4
Router(config-if)# switchport private-vlan
mapping primary_vlan_ID {secondary_vlan_list |
add secondary_vlan_list | remove
secondary_vlan_list}
Maps the private VLAN promiscuous port to a primary
VLAN and to selected secondary VLANs.
Router(config-if)# no switchport private-vlan
mapping
Clears all mapping between the private VLAN
promiscuous port and the primary VLAN and any
secondary VLANs.
Router(config-if)# end
Exits configuration mode.
Step 5
Note
If VLAN locking is enabled, enter the VLAN
name instead of the VLAN number. For more
information, see the “VLAN Locking” section on
page 16-4.
When you configure a Layer 2 interface as a private VLAN promiscuous port, note the following
information:
•
The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated
items. Each item can be a single private VLAN ID or a hyphenated range of private VLAN IDs.
•
If VLAN locking is enabled, enter VLAN names instead of VLAN numbers in the
secondary_vlan_list. When entering a range of VLAN names, you must leave spaces between the
VLAN names and the dash.
•
Enter a secondary_vlan_list value or use the add keyword with a secondary_vlan_list value to map
the secondary VLANs to the private VLAN promiscuous port.
•
Use the remove keyword with a secondary_vlan_list value to clear the mapping between secondary
VLANs and the private VLAN promiscuous port.
This example shows how to configure interface GigabitEthernet 5/2 as a private VLAN promiscuous port
and map it to a private VLAN:
Router# configure terminal
Router(config)# interface gigabitethernet 5/2
Router(config-if)# switchport mode private-vlan promiscuous
Router(config-if)# switchport private-vlan mapping 202 303,440
Router(config-if)# end
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-15
Chapter 17
Private VLANs
Monitoring Private VLANs
This example shows how to verify the configuration:
Router# show interfaces gigabitethernet 5/2 switchport | include private-vlan
Administrative Mode: private-vlan promiscuous
Administrative private-vlan host-association: none ((Inactive))
Administrative private-vlan mapping: 202 (VLAN0202) 303 (VLAN0303) 440 (VLAN0440)
Operational private-vlan: none
Monitoring Private VLANs
Table 17-1 shows the privileged EXEC commands for monitoring private VLAN activity.
Table 17-1
Private VLAN Monitoring Commands
Command
Purpose
show interfaces status
Displays the status of interfaces, including the VLANs to which they
belong.
show vlan private-vlan
[type]
Displays the private VLAN information for the switch.
show interface switchport
Displays private VLAN configuration on interfaces.
show interface
private-vlan mapping
Displays information about the private VLAN mapping for VLAN SVIs.
This is an example of the output from the show vlan private-vlan command:
Switch(config)# show vlan private-vlan
Primary Secondary Type
Ports
------- --------- ----------------- -----------------------------------------10
501
isolated
Gi2/1, Gi3/1, Gi3/2
10
502
community
Gi2/11, Gi3/1, Gi3/4
10
503
non-operational
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
17-16
CH AP TE R
18
Private Hosts
Note
•
Prerequisites for Private Hosts, page 18-1
•
Restrictions for Private Hosts, page 18-1
•
Information About Private Hosts, page 18-4
•
How to Configure Private Hosts, page 18-8
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Private Hosts
None.
Restrictions for Private Hosts
•
General Private Host Restrictions, page 18-2
•
Private Host ACL Restrictions, page 18-2
•
Private Host VLAN on Trunk Port Restrictions, page 18-3
•
Private Host Interaction with Other Features, page 18-3
•
Private Host Spoofing Protection, page 18-3
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-1
Chapter 18
Private Hosts
Restrictions for Private Hosts
•
Private Host Multicast Operation, page 18-4
General Private Host Restrictions
•
Private hosts and private VLANs cannot both be configured on the same port (interface). Both
features can coexist on the switch, but each feature must be configured on different ports.
•
Private hosts is an end-to-end feature. You must enable the feature on all of the switches between
the DSLAMs and an upstream device such as a BRAS or a multicast server.
•
Only trusted ports can be configured as isolated ports.
•
The private hosts feature is supported on Layer 2 interfaces that are configured as trunking switch
ports.
•
The private hosts feature is supported on port-channel interfaces (EtherChannel, Fast EtherChannel,
and Gigabit EtherChannel). You must enable private hosts on the port-channel interface; you cannot
enable the feature on member ports.
•
DAI and DHCP snooping cannot be enabled on a private hosts port unless all of the VLANs on the
port are configured for snooping.
Private Host ACL Restrictions
•
This release of the private hosts feature uses protocol-independent MAC ACLs.
Do not apply IP-based ACLs to any port configured for private hosts or you will defeat the private
hosts feature (because the switch will not be able to apply a private hosts MAC ACL to the port).
•
You can configure the following interface types for protocol-independent MAC ACL filtering:
– VLAN interfaces with no IP address
– Physical LAN ports that support EoMPLS
– Logical LAN subinterfaces that support EoMPLS
•
Protocol-independent MAC ACL filtering applies MAC ACLs to all ingress traffic types (for
example, IPv4 traffic, IPv6 traffic, and MPLS traffic, in addition to MAC-layer traffic).
•
Ingress traffic that is permitted or denied by a protocol-independent MAC ACL is processed by
egress interfaces as MAC-layer traffic. You cannot apply egress IP ACLs to traffic permitted or
denied by a MAC ACL on an interface configured for protocol-independent MAC ACL filtering.
•
Do not configure protocol-independent MAC ACL filtering on VLAN interfaces where you have
configured an IP address.
•
Do not configure protocol-independent MAC ACL filtering with microflow policing when the
permitted traffic would be bridged or Layer 3 switched in hardware by the PFC or a DFC.
•
Protocol-independent MAC ACL filtering supports microflow policing when the permitted traffic is
routed in software.
•
To prevent any existing VLAN ACLs (VACLs) and routing ACLs (RACLs) from interfering with the
PACL on the trunk port, configure the access group mode of the trunk port interface as prefer port
mode. Do not apply any VACLs or RACLs to a port configured for private hosts.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-2
Chapter 18
Private Hosts
Restrictions for Private Hosts
Private Host VLAN on Trunk Port Restrictions
•
You can enable IGMP snooping on VLANs that use trunk ports configured for private hosts.
•
You cannot enable IP multicast on a VLAN that uses a trunk port that is configured for private hosts.
•
Because PACLs operate in override mode on trunk ports, you cannot apply VLAN-based features to
switch ports.
•
The Multicast VLAN Registration (MVR) feature can coexist with private hosts as long as the
multicast source exists on a promiscuous port.
Private Host Interaction with Other Features
•
Private hosts do not affect Layer 2-based services such as MAC limiting, unicast flood
protection (UFP), or unknown unicast flood blocking (UUFB).
•
The private hosts features does not affect IGMP snooping. However, if IGMP snooping is globally
disabled, IGMP control packets will be subject to ACL checks. To permit IGMP control packets, the
private hosts software adds a multicast permit statement to the PACLs for isolated hosts. This
operation occurs automatically and no user intervention is required.
•
Port security can be enabled on isolated ports to provide added security to those ports.
•
When enabled on promiscuous or mixed-mode ports, the port security feature may restrict a change
in source port for an upstream device (such as a BRAS or a multicast server).
•
When enabled on an access port, 802.1X is not affected by the private hosts feature.
Private Host Spoofing Protection
The private hosts feature prevents MAC address spoofing but does not validate the customer MAC or
IP address. To prevent MAC address spoofing, the private hosts feature does the following:
•
Uses a static MAC address for a BRAS or a multicast server.
•
Disables learning in the Layer 2 forwarding table.
•
Alerts the switch software when a BRAS or multicast server moves from one source port to another.
The software then validates the move and updates the Layer 2 forwarding table.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-3
Chapter 18
Private Hosts
Information About Private Hosts
Private Host Multicast Operation
Multicast traffic that originates from an upstream device (such as a BRAS or a multicast server) is always
permitted. In addition, the private hosts PACLs are not applied to multicast control packets (such as
IGMP query and join requests). This operation allows isolated hosts to participate in multicast groups,
respond to IGMP queries, and receive traffic from any groups of interest.
Multicast traffic that originates from a host is dropped by the private hosts PACLs. However, if other
hosts need to receive multicast traffic originating from a host, the private hosts feature adds a multicast
permit entry to the PACLs.
Information About Private Hosts
•
Private Hosts Overview, page 18-4
•
Isolating Hosts in a VLAN, page 18-4
•
Restricting Traffic Flow (Using Private Hosts Port Mode and PACLs), page 18-5
•
Port ACLs, page 18-7
Private Hosts Overview
Service providers typically deliver triple-play services (voice, video, and data) using three different
VLANs over a single physical interface for each end user. The service infrastructure would be simpler
and more scalable if the service provider could deploy a single set of VLANs to multiple end users for
the same set of services, but the service provider must be able to isolate traffic between the users (hosts)
at Layer 2. The private hosts feature provides this isolation, allowing VLAN sharing among multiple end
users.
The private hosts feature provides these key benefits:
•
Isolates traffic among hosts (subscribers) that share the same VLAN ID.
•
Reuses VLAN IDs across different subscribers, which improves VLAN scalability by making better
use of the 4096 VLANs allowed.
•
Prevents media access control (MAC) address spoofing to prevent denial of service (DOS) attacks.
The private hosts feature uses protocol-independent port-based access control lists (PACLs) to provide
Layer 2 isolation between hosts on trusted ports within a strictly Layer 2 domain. The PACLs isolate the
hosts by imposing Layer 2 forwarding constraints on the switch ports.
Isolating Hosts in a VLAN
By isolating the hosts, a service provider can use a single set of VLANs to deliver the same set of
broadband or metro Ethernet services to multiple end users while ensuring that none of the hosts in the
VLAN can communicate directly with each other. For example, VLAN 10 can be used for voice traffic,
VLAN 20 for video traffic, and VLAN 30 for data traffic.
When the switch is used as a Digital Subscriber Line Access Multiplexer (DSLAM) gigabit Ethernet
aggregator, the DSLAM is connected to the switch through a trunk port that can carry data for multiple
VLANs. The service provider uses a single physical port and a single set of VLANs to deliver the same
set of services to different end users (isolated hosts). A separate VLAN is used for each service (voice,
video, and data).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-4
Chapter 18
Private Hosts
Information About Private Hosts
Figure 18-1 shows an example of triple-play services being delivered from the switch to multiple end
users attached to a DSLAM. In the figure, note the following:
•
A single trunk link between the switch and the DSLAM carries traffic for all three VLANs.
•
Virtual circuits (VCs) deliver the VLAN traffic from the DSLAM to individual end users.
Figure 18-1
VC to VLAN Mapping
Cisco 6500 Switch
Trunk
DSLAM
1
2
3
Host Host
Host Host
Phone
TV
PC
1
The trunk link carries:
•
One voice VLAN
•
One video VLAN
•
One data VLAN
182527
Host Host
2
The DSLAM maps voice, video, and data
traffic between VLANs and VCs.
3
Individual VCs carry voice, video, and data
traffic between the DSLAM and each host.
Restricting Traffic Flow (Using Private Hosts Port Mode and PACLs)
The private hosts feature uses PACLs to restrict the type of traffic that is allowed to flow through each
of the ports configured for private hosts. A port’s mode (specified when you enable private hosts on the
port) determines what type of PACL is applied to the port. Each type of PACL restricts the traffic flow
for a different type of traffic (for example, from content servers to isolated hosts, from isolated hosts to
servers, and traffic between isolated hosts).
The following list describes the port modes used by the private hosts feature (see Figure 18-2):
•
Isolated—Ports connected to the DSLAMs that the end users (isolated hosts) are connected to. The
hosts on the VLANs on these ports need to be isolated from each other. Hosts connected through
these ports are allowed to pass unicast traffic to upstream devices only.
•
Promiscuous—Ports that face the core network or the Broadband Remote Access Server (BRAS)
devices and multicast servers that are providing the broadband services.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-5
Chapter 18
Private Hosts
Information About Private Hosts
•
Mixed—Ports that interconnect switches. These ports can function as either isolated ports or
promiscuous ports, depending on Spanning Tree Protocol (STP) topology changes. These ports
allow unicast traffic to upstream devices (such as a BRAS or multicast server) only.
The private hosts feature restricts traffic flow in these ways:
•
Broadcast traffic at the ingress of the service provider network is redirected to BRAS and multicast
servers (such as video servers).
•
All unicast traffic between access switches (switches connected to each other) is blocked except for
traffic directed toward a BRAS or a multicast server.
•
The unknown unicast flood blocking (UUFB) feature is used to block unknown unicast traffic on
DSLAM-facing ports.
Figure 18-2 shows the different types of port modes (isolated, promiscuous, and mixed) used in a private
hosts configuration.
Figure 18-2
Private Hosts Port Types (Modes)
Video servers
Video servers
Access router
(network edge)
BRAS
1
2
Cisco 6500 Switch
Cisco 6500 Switch
3
DSLAM
Host
Host
Host
Host
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-6
Host
Host
Host
182528
Host
DSLAM
Chapter 18
Private Hosts
Information About Private Hosts
1
Promiscuous ports
Permit all traffic from a BRAS to hosts.
2
Mixed ports
Permit broadcast traffic from a BRAS.
Redirect broadcast traffic from hosts to
promiscuous and mixed-mode ports.
Permit traffic from a BRAS to hosts and from
hosts to a BRAS.
Deny all other host to host traffic.
3
Isolated ports
Permit unicast traffic from host to a BRAS only;
block unicast traffic between ports.
Redirect all broadcast traffic from host to a
BRAS.
Deny traffic from a BRAS (to prevent spoofing).
Permit multicast traffic (IPv4 and IPv6).
Note
In this description of port types, the term BRAS represents an
upstream devices such as a BRAS, a multicast server (such as a
video server), or a core network device that provides access to these
devices.
Port ACLs
The private hosts feature creates several types of port ACLs (PACLs) to impose Layer 2 forwarding
constraints on switch ports. The software creates PACLs for the different types of private hosts ports
based on the MAC addresses of the content servers providing broadband services and the VLAN IDs of
the isolated hosts to deliver those services to. You specify the mode in which each private hosts port is
to operate and the software applies the appropriate PACL to the port based on the port’s mode (isolated,
promiscuous, or mixed).
The following are examples of the different types of PACLs that are used by the private hosts feature.
Isolated Hosts PACL
This example shows a PACL for isolated ports:
deny host BRAS_MAC any
permit any host BRAS_MAC
redirect any host FFFF.FFFF.FFFF to LTLIndex 6
permit any 0100.5E00.0000/0000.007F.FFFF
permit any 3333.0000.0000/000.FFFF.FFFF
deny any any
Promiscuous Port PACL
This example shows a PACL for promiscuous ports:
permit host BRAS_MAC any
deny any any
Mixed Port PACL
This example shows a PACL for mixed ports:
permit host BRAS_MAC ffff.ffff.ffff
redirect any host FFFF.FFFF.FFFF to LTLIndex 6
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-7
Chapter 18
Private Hosts
Default Settings for Private Hosts
permit host BRAS_MAC any
permit any host BRAS_MAC
deny any any
Default Settings for Private Hosts
None.
How to Configure Private Hosts
•
Configuration Summary, page 18-8
•
Detailed Configuration Steps, page 18-9
•
Configuration Examples, page 18-10
Configuration Summary
1.
Determine which switch ports (interfaces) to use for the private hosts feature. You can configure the
feature on trunking switch ports or port-channel interfaces. Private hosts must be enabled on the
port-channel interface; you cannot enable the feature on member ports.
2.
Configure each port (interface) for normal, non-private hosts service. Configure the access group
mode of the port as prefer port mode. You can configure the VLANs at this step or later.
3.
Determine which VLAN or set of VLANs will be used to deliver broadband services to end users.
The private hosts feature will provide Layer 2 isolation among the hosts in these VLANs.
4.
Identify the MAC addresses of all of the BRASs and multicast servers that are being used to provide
broadband services to end users (isolated hosts).
If a server is not connected directly to the switch, determine the MAC address of the core
network device that provides access to the server.
Note
5.
6.
Note
7.
(Optional) If you plan to offer different types of broadband service to different sets of isolated hosts,
create multiple MAC and VLAN lists.
•
Each MAC address list identifies a server or set of servers providing a particular type of service.
•
Each VLAN list identifies the isolated hosts to deliver that service to.
Configure promiscuous ports and specify a MAC and VLAN list to identify the server and receiving
hosts for a particular type of service.
You can specify multiple MAC and VLAN combinations to allow different types of services to
be delivered to different sets of hosts. For example, the BRAS at xxxx.xxxx.xxxx could be used
to deliver a basic set of services over VLANs 20, 25, and 30, and the BRAS at yyyy.yyyy.yyyy
could be used to deliver a premium set of services over VLANs 5, 10, and 15.
Globally enable private hosts.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-8
Chapter 18
Private Hosts
How to Configure Private Hosts
8.
Enable private hosts on individual ports (interfaces) and specify the mode in which the port is to
operate. To determine port mode, you need to know if the port faces upstream (toward content
servers or core network), faces downstream (toward DSLAM and isolated hosts), or is connected to
another switch (typically, in a ring topology). See the “Restricting Traffic Flow (Using Private Hosts
Port Mode and PACLs)” section on page 18-5.
After you enable the feature on individual ports, the switch is ready to run the private hosts feature.
The private hosts software uses the MAC and VLAN lists you defined to create the isolated,
promiscuous, and mixed-mode PACLs for your configuration. The software then applies the appropriate
PACL to each private hosts port based on the port’s mode.
Detailed Configuration Steps
To configure the private hosts feature, perform the following steps. These steps assume that you have
already configured the Layer 2 interfaces that you plan for private hosts.
Note
You can configure private hosts only on trunking switch ports or EtherChannel ports. In addition, you
must enable private hosts on all of the switches between the DSLAMs and upstream devices.
Command or Action
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# private-hosts
mac-list mac_list_name mac_address
[remark device-name | comment]
Creates a list of MAC addresses that identify the BRAS and
multicast servers providing broadband services.
•
mac_list_name specifies a name to assign to this list of
content servers.
•
mac_address identifies the BRAS or multicast server
(or set of servers) providing a particular broadband
service or set of services.
•
remark allows you to specify an optional device name
or comment to assign to this MAC list.
Specify the MAC address of every content server being used
to deliver services. If you plan to offer different types of
services to different sets of hosts, create a separate MAC list
for each server or set of servers providing a particular
service.
Note
Step 3
Router(config)# private-hosts vlan-list
vlan-IDs
If a server is not directly connected to the switch,
specify the MAC address of the core network device
that provides access to the server.
Creates a list of the VLANs (vlan-IDs) whose hosts need to
be isolated so that the hosts can receive broadband services.
Create separate VLAN lists if you plan to offer particular
services to different sets of hosts. Otherwise, all of the
broadband services will be delivered to all isolated hosts.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-9
Chapter 18
Private Hosts
How to Configure Private Hosts
Step 4
Command or Action
Purpose
Router(config)# private-hosts promiscuous
mac-list-name [vlan-list vlan-IDs]
Identifies the content servers for broadband services and the
end users (isolated hosts) to which to deliver the services.
•
mac-list-name specifies the name of the MAC address
lists that identifies the BRAS or multicast server (or set
of servers) providing a particular type of broadband
service or set of services.
•
vlan-IDs identifies the VLAN or set of VLANs whose
hosts are to receive services from the above servers.
If no VLAN list is specified, the software uses the
global VLAN list (configured in Step 3).
Note
You can enter this command multiple times to
configure multiple MAC and VLAN combinations,
each defining the server and receiving hosts for a
particular type of service.
Step 5
Router(config)# private-hosts
Globally enables private hosts on the switch.
Step 6
Router(config)# interface interface
Selects the trunking switch port or EtherChannel to enable
for private hosts.
Step 7
Router(config-if)# access-group mode prefer
port
Specifies that any existing VACLs or RACLs on the trunk
port will be ignored.
Step 8
Router(config-if)# private-hosts mode
{promiscuous | isolated | mixed}
Enables private hosts on the port. Use one of the following
keywords to define the mode that the port is to operate in:
•
promiscuous—Upstream-facing ports that connect to
broadband servers (BRAS, multicast, or video) or to
core network devices providing access to the servers.
•
isolated—Ports that connect to DSLAMs.
•
mixed—Ports that connect to other switches, typically
in a ring topology.
Note
Step 9
Router(config-if)# end
You must perform this step on each port being used
for private hosts.
Exits interface and global configuration modes and returns
to privileged EXEC mode. Private Hosts configuration is
complete.
Configuration Examples
The following example creates a MAC address list and a VLAN list and isolates the hosts in VLANs 10,
12, 15, and 200 through 300. The BRAS-facing port is made promiscuous and two host-connected ports
are made isolated:
Router# configure terminal
Router(config)# private-hosts mac-list BRAS_list 0000.1111.1111 remark BRAS_SanJose
Router(config)# private-hosts vlan-list 10,12,15,200-300
Router(config)# private-hosts promiscuous BRAS_list vlan-list 10,12,15,200-300
Router(config)# private-hosts
Router(config)# interface gig 4/2
Router(config-if)# private-hosts mode promiscuous
Router(config-if)# exit
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-10
Chapter 18
Private Hosts
How to Configure Private Hosts
Router(config)# interface gig 5/2
Router(config-if)# private-hosts mode isolated
Router(config-if)# exit
Router(config)# interface gig 5/3
Router(config-if)# private-hosts mode isolated
Router(config-if)# end
Router#
The following example shows the interface configuration of a private hosts isolated port:
Router# show run interface gig 5/2
Building configuration...
Current configuration : 200 bytes
!
interface GigabitEthernet5/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
access-group mode prefer port
private-hosts mode isolated
end
The following example shows the interface configuration of a private hosts promiscuous port:
Router# show run interface gig 4/2
Building configuration...
Current configuration : 189 bytes
!
interface GigabitEthernet4/2
switchport
switchport access vlan 200
switchport mode access
private-hosts mode promiscuous
end
private-hosts
private-hosts vlan-list 200
private-hosts promiscuous bras-list
private-hosts mac-list bras-list 0000.1111.1111 remark BRAS-SERVER
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-11
Chapter 18
How to Configure Private Hosts
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
18-12
Private Hosts
CH AP TE R
19
IEEE 802.1Q Tunneling
Note
•
Prerequisites for 802.1Q Tunneling, page 19-1
•
Restrictions for 802.1Q Tunneling, page 19-1
•
Information About 802.1Q Tunneling, page 19-4
•
Default Settings for 802.1Q Tunneling, page 19-5
•
How to Configure 802.1Q Tunneling, page 19-6
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for 802.1Q Tunneling
None.
Restrictions for 802.1Q Tunneling
•
Use asymmetrical links to put traffic into a tunnel or to remove traffic from a tunnel.
•
Configure tunnel ports only to form an asymmetrical link.
•
Dedicate one VLAN for each tunnel.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-1
Chapter 19
IEEE 802.1Q Tunneling
Restrictions for 802.1Q Tunneling
•
Assign only tunnel ports to VLANs used for tunneling.
•
Trunks require no special configuration to carry tunnel VLANs.
•
Tunnel ports are not trunks. Any commands to configure trunking are inactive while the port is
configured as a tunnel port.
•
Tunnel ports learn customer MAC addresses.
•
We recommend that you use ISL trunks to carry tunnel traffic between devices that do not have
tunnel ports. Because of the 802.1Q native VLAN feature, using 802.1Q trunks requires that you be
very careful when you configure tunneling: a mistake might direct tunnel traffic to a non-tunnel port.
•
By default, the native VLAN traffic of a dot1q trunk is sent untagged, which cannot be
double-tagged in the service provider network. Because of this situation, the native VLAN traffic
might not be tunneled correctly. Be sure that the native VLAN traffic is always sent tagged in an
asymmetrical link. To tag the native VLAN egress traffic and drop all untagged ingress traffic, enter
the global vlan dot1q tag native command.
•
Configure jumbo frame support on tunnel ports:
– See the “Configuring Jumbo Frame Support” section on page 10-6.
– Take note of the modules listed in the “Configuring Jumbo Frame Support” section that do not
support jumbo frames.
•
Jumbo frames can be tunneled as long as the jumbo frame length combined with the 802.1Q tag does
not exceed the maximum frame size.
•
Because tunnel traffic has the added ethertype and length field and retains the 802.1Q tag within the
switch, the following restrictions exist:
– The Layer 3 packet within the Layer 2 frame cannot be identified in tunnel traffic.
– Layer 3 and higher parameters cannot be identified in tunnel traffic (for example, Layer 3
destination and source addresses).
– Because the Layer 3 addresses cannot be identified within the packet, tunnel traffic cannot be
routed.
– The switch can provide only MAC-layer filtering for tunnel traffic (VLAN IDs and source and
destination MAC addresses).
– The switch can provide only MAC-layer access control and QoS for tunnel traffic.
– QoS cannot detect the received CoS value in the 802.1Q 2-byte Tag Control Information field.
•
On an asymmetrical link, the Cisco Discovery Protocol (CDP) reports a native VLAN mismatch if
the VLAN of the tunnel port does not match the native VLAN of the 802.1Q trunk. The 802.1Q
tunnel feature does not require that the VLANs match. Ignore the messages if your configuration
requires nonmatching VLANs.
•
Asymmetrical links do not support the Dynamic Trunking Protocol (DTP) because only one port on
the link is a trunk. Configure the 802.1Q trunk port on an asymmetrical link to trunk unconditionally.
•
The 802.1Q tunneling feature cannot be configured on ports configured to support private VLANs.
•
The 802.1Q tunneling feature cannot be configured on ports configured to support EVCs.
•
The following Layer 2 protocols work between devices connected by an asymmetrical link:
– CDP
– UniDirectional Link Detection (UDLD)
– Port Aggregation Protocol (PAgP)
– Link Aggregation Control Protocol (LACP)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-2
Chapter 19
IEEE 802.1Q Tunneling
Restrictions for 802.1Q Tunneling
•
PortFast BPDU filtering is enabled automatically on tunnel ports.
•
CDP is automatically disabled on tunnel ports.
•
VLAN Trunk Protocol (VTP) does not work between the following devices:
– Devices connected by an asymmetrical link
– Devices communicating through a tunnel
Note
•
VTP works between tunneled devices if Layer 2 protocol tunneling is enabled. See
Chapter 20, “Layer 2 Protocol Tunneling,” for configuration details.
To configure an EtherChannel as an asymmetrical link, all ports in the EtherChannel must have the
same tunneling configuration. Because the Layer 3 packet within the Layer 2 frame cannot be
identified, you must configure the EtherChannel to use MAC-address-based frame distribution.
The following configuration guidelines are required for your Layer 2 protocol tunneling configuration:
•
On all the service provider edge switches, PortFast BPDU filtering must be enabled on the 802.1Q
tunnel ports as follows:
Router(config-if)# spanning-tree bpdufilter enable
Router(config-if)# spanning-tree portfast
Note
PortFast BPDU filtering is enabled automatically on tunnel ports.
•
At least one VLAN must be available for native VLAN tagging (vlan dot1q tag native option). If
you use all the available VLANs and then try to enable the vlan dot1q tag native option, the option
will not be enabled.
•
On all the service provider core switches, tag native VLAN egress traffic and drop untagged native
VLAN ingress traffic by entering the following command:
Router(config)# vlan dot1q tag native
•
On all the customer switches, either enable or disable the global vlan dot1q tag native option.
Note
If this option is enabled on one switch and disabled on another switch, all traffic is dropped;
all customer switches must have this option configured the same on each switch.
The following configuration guidelines are optional for your Layer 2 protocol tunneling configuration:
•
Because all the BPDUs are being dropped, spanning tree PortFast can be enabled on Layer 2
protocol tunnel ports as follows:
Router(config-if)# spanning-tree portfast trunk
•
If the service provider does not want the customer to see its switches, CDP should be disabled on
the 802.1Q tunnel port as follows:
Router(config-if)# no cdp enable
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-3
Chapter 19
IEEE 802.1Q Tunneling
Information About 802.1Q Tunneling
Information About 802.1Q Tunneling
802.1Q tunneling enables service providers to use a single VLAN to support customers who have
multiple VLANs, while preserving customer VLAN IDs and keeping traffic in different customer
VLANs segregated.
A port configured to support 802.1Q tunneling is called a tunnel port. When you configure tunneling,
you assign a tunnel port to a VLAN that you dedicate to tunneling, which then becomes a tunnel VLAN.
To keep customer traffic segregated, each customer requires a separate tunnel VLAN, but that one tunnel
VLAN supports all of the customer’s VLANs.
802.1Q tunneling is not restricted to point-to-point tunnel configurations. Any tunnel port in a tunnel
VLAN is a tunnel entry and exit point. An 802.1Q tunnel can have as many tunnel ports as are needed
to connect customer switches.
The customer switches are trunk connected, but with 802.1Q tunneling, the service provider switches
only use one service provider VLAN to carry all the customer VLANs, instead of directly carrying all
the customer VLANs.
With 802.1Q tunneling, tagged customer traffic comes from an 802.1Q trunk port on a customer device
and enters the service-provider edge switch through a tunnel port. The link between the 802.1Q trunk
port on a customer device and the tunnel port is called an asymmetrical link because one end is
configured as an 802.1Q trunk port and the other end is configured as a tunnel port. You assign the tunnel
port to an access VLAN ID unique to each customer. See Figure 19-1 on page 19-4 and Figure 19-2 on
page 19-5.
Figure 19-1
IEEE 802.1Q Tunnel Ports in a Service-Provider Network
Customer A
VLANs 1 to 100
Customer A
VLANs 1 to 100
802.1Q
802.1Qtrunk
trunkport
port
Service
provider
802.1Q
802.1Q trunk
trunk port
port
Tunnel port
VLAN 30
Tunnel port
VLAN 30
Trunk
ports
802.1Q
802.1Qtrunk
trunkport
port
Tunnel port
VLAN 30
Trunk
ports
Tunnel port
VLAN 40
Tunnel port
VLAN 40
802.1Q
802.1Qtrunk
trunkport
port
74016
802.1Q trunk port
Customer B
VLANs 1 to 200
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-4
Trunk
Asymmetric link
Customer B
VLANs 1 to 200
Chapter 19
IEEE 802.1Q Tunneling
Default Settings for 802.1Q Tunneling
Untagged, 802.1Q-Tagged, and Double-Tagged Ethernet Frames
Source
address
Destination
Length/
address
EtherType
DA
SA
Len/Etype
DA
SA
Etype
DA
SA
Etype
Frame Check
Sequence
Data
Tag
Tag
FCS
Len/Etype
Etype
Tag
Original Ethernet frame
Data
FCS
Len/Etype
802.1Q frame from
customer network
Data
FCS
Double-tagged
frame on trunk
links between
service provider
network devices
79831
Figure 19-2
When a tunnel port receives tagged customer traffic from an 802.1Q trunk port, it does not strip the
received 802.1Q tag from the frame header; instead, the tunnel port leaves the 802.1Q tag intact, adds a
2-byte Ethertype field (0x8100) followed by a 2-byte field containing the priority (CoS) and the VLAN.
The received customer traffic is then put into the VLAN to which the tunnel port is assigned. This
Ethertype 0x8100 traffic, with the received 802.1Q tag intact, is called tunnel traffic.
A VLAN carrying tunnel traffic is an 802.1Q tunnel. The tunnel ports in the VLAN are the tunnel’s
ingress and egress points.
The tunnel ports do not have to be on the same network device. The tunnel can cross other network links
and other network devices before reaching the egress tunnel port. A tunnel can have as many tunnel ports
as required to support the customer devices that need to communicate through the tunnel.
An egress tunnel port strips the 2-byte Ethertype field (0x8100) and the 2-byte length field and transmits
the traffic with the 802.1Q tag still intact to an 802.1Q trunk port on a customer device. The 802.1Q trunk
port on the customer device strips the 802.1Q tag and puts the traffic into the appropriate customer
VLAN.
Note
Tunnel traffic carries a second 802.1Q tag only when it is on a trunk link between service-provider
network devices, with the outer tag containing the service-provider-assigned VLAN ID and the inner tag
containing the customer-assigned VLAN IDs.
Default Settings for 802.1Q Tunneling
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-5
Chapter 19
IEEE 802.1Q Tunneling
How to Configure 802.1Q Tunneling
How to Configure 802.1Q Tunneling
Caution
•
Configuring 802.1Q Tunnel Ports, page 19-6
•
Configuring the Switch to Tag Native VLAN Traffic, page 19-6
Ensure that only the appropriate tunnel ports are in any VLAN used for tunneling and that one VLAN is
used for each tunnel. Incorrect assignment of tunnel ports to VLANs can forward traffic inappropriately.
Configuring 802.1Q Tunnel Ports
To configure 802.1Q tunneling on a port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
•
You must enter the switchport command once
without any keywords to configure the LAN port as
a Layer 2 interface before you can enter additional
switchport commands with keywords.
•
Required only if you have not entered the
switchport command already for the interface.
Step 3
Router(config-if)# switchport mode dot1q-tunnel
Configures the Layer 2 port as a tunnel port.
Step 4
Router(config-if)# no lldp transmit
(Required on PE ports) Disables LLDP.
Note
Step 5
Router(config-if)# end
CDP is automatically disabled.
Exits configuration mode.
This example shows how to configure tunneling on port 4/1 and verify the configuration:
Router# configure terminal
Router(config)# interface gigabitethernet 4/1
Router(config-if)# switchport mode dot1q-tunnel
Router(config-if)# no lldp transmit
Router(config-if)# end
Router# show dot1q-tunnel interface
Configuring the Switch to Tag Native VLAN Traffic
•
Configuring the Switch to Tag Native VLAN Traffic Globally, page 19-7
•
Configuring Ports Not to Tag Native VLAN Traffic, page 19-7
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-6
Chapter 19
IEEE 802.1Q Tunneling
How to Configure 802.1Q Tunneling
Configuring the Switch to Tag Native VLAN Traffic Globally
To configure the switch to tag traffic in the native VLAN globally, perform this task:
Step 1
Command
Purpose
Router(config)# vlan dot1q tag native
Configures the switch to tag native VLAN traffic globally, and admit
only 802.1Q tagged frames on 802.1Q trunks, dropping any untagged
traffic, including untagged traffic in the native VLAN.
Note
Step 2
Router(config)# end
On ports where you enter the no switchport trunk native vlan
tag interface command, the function of the vlan dot1q tag
native global command is disabled.
Exits configuration mode.
This example shows how to configure the switch to tag native VLAN traffic and verify the configuration:
Router# configure terminal
Router(config)# vlan dot1q tag native
Router(config)# end
Router# show vlan dot1q tag native | include globally
dot1q native vlan tagging is enabled globally
Router(config)#
Configuring Ports Not to Tag Native VLAN Traffic
To configure a port not to tag traffic in the native VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
•
You must enter the switchport command once
without any keywords to configure the LAN
port as a Layer 2 interface before you can enter
additional switchport commands with
keywords.
•
Required only if you have not entered the
switchport command already for the port.
Step 3
Router(config-if)# no switchport trunk native vlan tag
When the switch is configured to tag native VLAN
traffic globally, configures the Layer 2 port not to
tag native VLAN traffic.
Step 4
Router(config-if)# end
Exits configuration mode.
Note
The switchport trunk native vlan tag interface command does not enable native VLAN tagging unless
the switch is configured to tag native VLAN traffic globally.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-7
Chapter 19
IEEE 802.1Q Tunneling
How to Configure 802.1Q Tunneling
This example shows how to configure Gigabit Ethernet port 1/4 to tag traffic in the native VLAN and
verify the configuration:
Router# configure terminal
Router(config)# interface gigabitethernet 1/4
Router(config-if)# switchport trunk native vlan tag
Router(config-if)# end
Router# show interface gigabitethernet 1/4 switchport | include tagging
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
19-8
CH AP TE R
20
Layer 2 Protocol Tunneling
Note
•
Prerequisites for Layer 2 Protocol Tunneling, page 20-1
•
Restrictions for Layer 2 Protocol Tunneling, page 20-1
•
Information About Layer 2 Protocol Tunneling, page 20-2
•
Default Settings for Layer 2 Protocol Tunneling, page 20-2
•
How to Configure Layer 2 Protocol Tunneling, page 20-3
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
•
Tip
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Layer 2 Protocol Tunneling
None.
Restrictions for Layer 2 Protocol Tunneling
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-1
Chapter 20
Layer 2 Protocol Tunneling
Information About Layer 2 Protocol Tunneling
Information About Layer 2 Protocol Tunneling
Layer 2 protocol tunneling allows Layer 2 protocol data units (PDUs) (CDP, STP, and VTP) to be
tunneled through a network. This section uses the following terminology:
•
Edge switch—The switch connected to the customer switch and placed on the boundary of the
service provider network (see Figure 20-1).
•
Layer 2 protocol tunnel port—A port on the edge switch on which a specific tunneled protocol can
be encapsulated or deencapsulated. The Layer 2 protocol tunnel port is configured through CLI
commands.
•
Tunneled PDU—A CDP, STP, or VTP PDU.
Without Layer 2 protocol tunneling, tunnel ports drop STP and VTP packets and process CDP packets. This
handling of the PDUs creates different spanning tree domains (different spanning tree roots) for the
customer switches. For example, STP for a VLAN on switch 1 (see Figure 20-1) builds a spanning tree
topology on switches 1, 2, and 3 without considering convergence parameters based on switches 4 and 5. To
provide a single spanning tree domain for the customer, a generic scheme to tunnel BPDUs was created
for control protocol PDUs (CDP, STP, and VTP). This process is referred to as Generic Bridge PDU
Tunneling (GBPT).
Layer 2 Protocol Tunneling Network Configuration
Customer switches
Customer switches
Switch 1
Switch 2
Service provider
network
Switch A
Switch 4
Edge
switches Switch B
Switch 3
Switch 5
77066
Figure 20-1
GBPT provides a scalable approach to PDU tunneling by software encapsulating the PDUs in the ingress
edge switches and then multicasting them in hardware. All switches inside the service provider network
treat these encapsulated frames as data packets and forward them to the other end. The egress edge
switch listens for these special encapsulated frames and deencapsulates them; they are then forwarded
out of the tunnel.
The encapsulation involves rewriting the destination media access control (MAC) address in the PDU.
An ingress edge switch rewrites the destination MAC address of the PDUs received on a Layer 2 tunnel
port with the Cisco proprietary multicast address (01-00-0c-cd-cd-d0). The PDU is then flooded to the
native VLAN of the Layer 2 tunnel port. If you enable Layer 2 protocol tunneling on a port, PDUs of an
enabled protocol are not sent out. If you disable Layer 2 protocol tunneling on a port, the disabled
protocols function the same way they were functioning before Layer 2 protocol tunneling was enabled
on the port.
Default Settings for Layer 2 Protocol Tunneling
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-2
Chapter 20
Layer 2 Protocol Tunneling
How to Configure Layer 2 Protocol Tunneling
How to Configure Layer 2 Protocol Tunneling
Note
•
Encapsulated PDUs received by an 802.1Q tunnel port are transmitted from other tunnel ports in the
same VLAN on the switch.
•
Configure jumbo frame support on Layer 2 protocol tunneling ports:
– See the “Configuring Jumbo Frame Support” section on page 10-6.
– Take note of the modules listed in the “Configuring Jumbo Frame Support” section that do not
support jumbo frames.
To configure Layer 2 protocol tunneling on a port, perform this task:
Command
Purpose
Step 1
Router(config)# interface type slot/port
Selects the LAN port to configure.
Step 2
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
•
You must enter the switchport command once
without any keywords to configure the LAN port as a
Layer 2 interface before you can enter additional
switchport commands with keywords.
•
Required only if you have not entered the switchport
command already for the interface.
Step 3
Router(config-if)# l2protocol-tunnel [cdp | lldp
| stp | vtp]
Configures the Layer 2 port as a Layer 2 protocol tunnel
port for all protocols or only the specified protocol.
Step 4
Router(config-if)# l2protocol-tunnel
drop-threshold {[cdp | lldp | stp | vtp] packets}
(Optional) Configures the port as a Layer 2 protocol
tunnel port and sets a drop threshold for all protocols or
only the specified protocol.
Step 5
Router(config-if)# l2protocol-tunnel
shutdown-threshold {[cdp | lldp | stp | vtp]
packets}
(Optional) Configures the port as a Layer 2 protocol
tunnel port and sets a shutdown threshold for all protocols
or only the specified protocol.
Step 6
Router(config-if)# no lldp transmit
(Required on PE ports) Disables LLDP.
Step 7
Router(config)# end
Note
CDP is automatically disabled.
Exits configuration mode.
When you configure a Layer 2 port as a Layer 2 protocol tunnel port, note the following information:
•
Optionally, you may specify a drop threshold for the port. The drop threshold value, from 1 to 4096,
determines the number of packets to be processed for that protocol on that interface in one second.
When the drop threshold is exceeded, PDUs for the specified protocol are dropped for the remainder
of the one-second period. If a drop threshold is not specified, the value is 0 (drop threshold disabled).
•
Optionally, you may specify a shutdown threshold for the port. The shutdown threshold value, from
1 to 4096, determines the number of packets to be processed for that protocol on that interface in
one second. When the shutdown threshold is exceeded, the port is put in errdisable state. If a
shutdown threshold is not specified, the value is 0 (shutdown threshold disabled).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-3
Chapter 20
Layer 2 Protocol Tunneling
How to Configure Layer 2 Protocol Tunneling
•
Note
If you specify both a drop threshold and a shutdown threshold for the port, packets exceeding the
drop threshold will not be forwarded but will be counted toward the shutdown threshold.
The commands support the l2ptguard keyword:
•
errdisable detect cause
•
errdisable recovery
This example shows how to configure Layer 2 protocol tunneling and drop and shu tdown thresholds on
port 5/1 for CDP, STP, and VTP, and verify the configuration:
Router# configure terminal
Router(config)# interface gigabitethernet 5/1
Router(config-if)# switchport
Router(config-if)# l2protocol-tunnel shutdown-threshold
Router(config-if)# l2protocol-tunnel shutdown-threshold
Router(config-if)# l2protocol-tunnel shutdown-threshold
Router(config-if)# l2protocol-tunnel drop-threshold vtp
Router(config-if)# no lldp transmit
Router(config-if)# end
Router# show l2protocol-tunnel summary
COS for Encapsulated Packets: 5
Drop Threshold for Encapsulated Packets: 0
Port
Protocol
Shutdown
Threshold
(cdp/lldp/stp/vtp)
-------- ------------ ------------------Gi5/1
-- -- -- --- 400/----/ 400/ 400
cdp 400
stp 400
vtp 400
200
Drop
Status
Threshold
(cdp/lldp/stp/vtp)
-------------------- -------------/----/----/ 200
down(trunk)
Router#
This example shows how to display counter information for port 5/1:
Router# show l2protocol-tunnel interface gigabitethernet 5/1
COS for Encapsulated Packets: 5
Port
Protocol Thresholds
Counters
Shutdown Drop
Encap
Decap
Drop
----------- -------- --------- --------- --------- --------- --------Router#
This example shows how to clear the Layer 2 protocol tunneling configuration from port 5/1:
Router(config-if)# no l2protocol-tunnel shutdown-threshold
Router(config-if)# no l2protocol-tunnel shutdown-threshold
Router(config-if)# no l2protocol-tunnel shutdown-threshold
Router(config-if)# no l2protocol-tunnel drop-threshold vtp
Router(config-if)# no l2protocol-tunnel cdp
Router(config-if)# no l2protocol-tunnel stp
Router(config-if)# no l2protocol-tunnel vtp
Router(config-if)# lldp transmit
Router(config-if)# end
Router# show l2protocol-tunnel summary
COS for Encapsulated Packets: 5
Drop Threshold for Encapsulated Packets: 0
Port
Protocol
Shutdown
Threshold
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-4
Drop
Threshold
cdp 400
stp 400
vtp 400
200
Status
Chapter 20
Layer 2 Protocol Tunneling
How to Configure Layer 2 Protocol Tunneling
(cdp/lldp/stp/vtp) (cdp/lldp/stp/vtp)
-------- ------------ ------------------- -------------------- ---------Router#
This example shows how to clear Layer 2 protocol tunneling port counters:
Router# clear l2protocol-tunnel counters
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-5
Chapter 20
How to Configure Layer 2 Protocol Tunneling
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
20-6
Layer 2 Protocol Tunneling
CH AP TE R
1
Spanning Tree Protocols
Note
•
Prerequisites for Spanning Tree Protocols, page 1-1
•
Restrictions for Spanning Tree Protocols, page 1-2
•
Information About Spanning Tree Protocols, page 1-2
•
Default Settings for Spanning Tree Protocols, page 1-25
•
How to Configure Spanning Tree Protocols, page 1-26
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
This chapter describes the Spanning Tree Protocol (STP) and Multiple Spanning Tree (MST)
protocol. For information on configuring the PortFast, UplinkFast, and BackboneFast STP
enhancements, see Chapter 2, “Optional STP Features.”
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Spanning Tree Protocols
None.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-1
Chapter 1
Spanning Tree Protocols
Restrictions for Spanning Tree Protocols
Restrictions for Spanning Tree Protocols
•
The 802.1s MST standard allows up to 65 MST instances. You can map an unlimited number of
VLANs to an MST instance.
•
Rapid PVST+ and MST are supported, but only one version can be active at any time.
•
VTP does not propagate the MST configuration. You must manually configure the MST
configuration (region name, revision number, and VLAN-to-instance mapping) on each switch
within the MST region through the command-line interface (CLI) or SNMP.
•
For load balancing across redundant paths in the network to work, all VLAN-to-instance mapping
assignments must match; otherwise, all traffic flows on a single link.
•
All MST boundary ports must be forwarding for load balancing between a PVST+ and an MST
cloud or between a rapid-PVST+ and an MST cloud. For this to occur, the CIST regional root of the
MST cloud must be the root of the CST. If the MST cloud consists of multiple MST regions, one of
the MST regions must contain the CST root, and all of the other MST regions must have a better
path to the root contained within the MST cloud than a path through the rapid-PVST+ cloud.
•
Partitioning the network into a large number of regions is not recommended. However, if this
situation is unavoidable, we recommend that you partition the switched LAN into smaller LANs
interconnected by non-Layer 2 devices.
•
Adding or removing VLANs to an existing MST instance will trigger spanning tree recalculation for
that MST instance, and the traffic of all the VLANs for that MST instance will be disrupted.
Information About Spanning Tree Protocols
•
Information about STP, page 1-2
•
Information about IEEE 802.1w RSTP, page 1-13
•
Information about MST, page 1-18
•
Detecting Unidirectional Link Failure, page 1-25
Information about STP
•
STP Overview, page 1-3
•
Information about the Bridge ID, page 1-3
•
Information about Bridge Protocol Data Units, page 1-4
•
Election of the Root Bridge, page 1-5
•
STP Protocol Timers, page 1-5
•
Creating the Spanning Tree Topology, page 1-5
•
STP Port States, page 1-6
•
STP and IEEE 802.1Q Trunks, page 1-12
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-2
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
STP Overview
STP, the IEEE 802.1D bridge protocol, is a Layer 2 link-management protocol that provides path
redundancy while preventing undesirable loops in the network. For a Layer 2 Ethernet network to
function properly, only one active path can exist between any two stations. STP operation is transparent
to end stations, which cannot detect whether they are connected to a single LAN segment or a switched
LAN of multiple segments.
In an extension known as per-VLAN spanning tree (PVST), Layer 2 Ethernet ports can use STP on all
VLANs. Rapid-PVST+, enabled by default on each configured VLAN (provided you do not manually
disable it), uses RSTP to provide faster convergence. Independent VLANs run their own RSTP instance.
With rapid-PVST+, dynamic entries are flushed immediately on a per-port basis upon receiving a
topology change. UplinkFast and BackboneFast configurations are ignored in rapid-PVST+ mode; both
features are included in RSTP. Rapid-PVST+ mode supports unidirectional link failure detection as
described in the “Detecting Unidirectional Link Failure” section on page 1-25.
When you create fault-tolerant internetworks, you must have a loop-free path between all nodes in a
network. The STP algorithm calculates the best loop-free path throughout a switched Layer 2 network.
Layer 2 LAN ports send and receive STP frames at regular intervals. Network devices do not forward
these frames, but use the frames to construct a loop-free path.
Multiple active paths between end stations cause loops in the network. If a loop exists in the network,
end stations might receive duplicate messages and network devices might learn end station MAC
addresses on multiple Layer 2 LAN ports. These conditions result in an unstable network.
STP defines a tree with a root bridge and a loop-free path from the root to all network devices in the
Layer 2 network. STP forces redundant data paths into a standby (blocked) state. If a network segment
in the spanning tree fails and a redundant path exists, the STP algorithm recalculates the spanning tree
topology and activates the standby path.
When two Layer 2 LAN ports on a network device are part of a loop, the STP port priority and port path
cost setting determine which port is put in the forwarding state and which port is put in the blocking
state. The STP port priority value represents the location of a port in the network topology and how
efficiently that location allows the port to pass traffic. The STP port path cost value represents media
speed.
Information about the Bridge ID
•
Bridge Priority Value, page 1-3
•
Extended System ID, page 1-3
•
STP MAC Address Allocation, page 1-4
Bridge Priority Value
Each VLAN on each network device has a unique 64-bit bridge ID consisting of a bridge priority value,
an extended system ID, and an STP MAC address allocation. The bridge priority is a 4-bit value when
the extended system ID is enabled (see Table 1-1 on page 1-4 and the “Configuring the Bridge Priority of
a VLAN” section on page 1-34).
Extended System ID
A 12-bit extended system ID field is part of the bridge ID (see Table 1-1 on page 1-4). Chassis that
support only 64 MAC addresses always use the 12-bit extended system ID. On chassis that support 1,024
MAC addresses, you can enable use of the extended system ID.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-3
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
The extended system ID is enabled by default under the following conditions:
•
Chassis that support only 64 MAC addresses
•
When the STP mode is MST
STP uses the VLAN ID as the extended system ID. See the “Enabling the Extended System ID” section
on page 1-28.
Table 1-1
Bridge Priority Value and Extended System ID with the Extended System ID Enabled
Bridge Priority Value
Extended System ID (Set Equal to the VLAN/MST Instance ID)
Bit 16
Bit 15
Bit 14
Bit 13
Bit 12
Bit 11
Bit 10
Bit 9
Bit 8
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
32768
16384
8192
4096
2048
1024
512
256
128
64
32
16
8
4
2
1
STP MAC Address Allocation
The chassis has either 64 or 1024 MAC addresses available to support software features such as STP. To
view the MAC address range on your chassis, enter the show catalyst6000 chassis-mac-address
command.
For chassis with 64 MAC addresses, STP uses the extended system ID plus a MAC address to make the
bridge ID unique for each VLAN.
When the extended system ID is not enabled, STP uses one MAC address per VLAN to make the bridge
ID unique for each VLAN.
If you have a network device in your network with the extended system ID enabled, you should also
enable the extended system ID on all other Layer 2 connected network devices to avoid undesirable root
bridge election and spanning tree topology issues.
When the extended system ID is enabled, the root bridge priority becomes a multiple of 4096 plus the
VLAN ID. With the extended system ID enabled, a switch bridge ID (used by the spanning tree
algorithm to determine the identity of the root bridge, the lowest being preferred) can only be specified
as a multiple of 4096. Only the following values are possible: 0, 4096, 8192, 12288, 16384, 20480,
24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440.
If another bridge in the same spanning tree domain does not have the extended system ID enabled, it
could win root bridge ownership because of the finer granularity in the selection of its bridge ID.
Information about Bridge Protocol Data Units
Bridge protocol data units (BPDUs) are transmitted in one direction from the root bridge. Each network
device sends configuration BPDUs to communicate and compute the spanning tree topology. Each
configuration BPDU contains the following minimal information:
•
The unique bridge ID of the network device that the transmitting network device believes to be the
root bridge
•
The STP path cost to the root
•
The bridge ID of the transmitting bridge
•
Message age
•
The identifier of the transmitting port
•
Values for the hello, forward delay, and max-age protocol timers
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-4
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
When a network device transmits a BPDU frame, all network devices connected to the LAN on which
the frame is transmitted receive the BPDU. When a network device receives a BPDU, it does not forward
the frame but instead uses the information in the frame to calculate a BPDU, and, if the topology
changes, initiate a BPDU transmission.
A BPDU exchange results in the following:
•
One network device is elected as the root bridge.
•
The shortest distance to the root bridge is calculated for each network device based on the path cost.
•
A designated bridge for each LAN segment is selected. This is the network device closest to the root
bridge through which frames are forwarded to the root.
•
A root port is selected. This is the port providing the best path from the bridge to the root bridge.
•
Ports included in the spanning tree are selected.
Election of the Root Bridge
For each VLAN, the network device with the highest-priority bridge ID (the lowest numerical ID value)
is elected as the root bridge. If all network devices are configured with the default priority (32768), the
network device with the lowest MAC address in the VLAN becomes the root bridge. The bridge priority
value occupies the most significant bits of the bridge ID.
When you change the bridge priority value, you change the probability that the switch will be elected as
the root bridge. Configuring a higher-priority value increases the probability; a lower-priority value
decreases the probability.
The STP root bridge is the logical center of the spanning tree topology in a Layer 2 network. All paths
that are not needed to reach the root bridge from anywhere in the Layer 2 network are placed in STP
blocking mode.
BPDUs contain information about the transmitting bridge and its ports, including bridge and MAC
addresses, bridge priority, port priority, and path cost. STP uses this information to elect the root bridge
for the Layer 2 network, to elect the root port leading to the root bridge, and to determine the designated
port for each Layer 2 segment.
STP Protocol Timers
Variable
Description
Hello timer
Determines how often the network device broadcasts hello messages to other
network devices.
Forward delay timer
Determines how long each of the listening and learning states last before the
port begins forwarding.
Maximum age timer
Determines the amount of time protocol information received on an port is
stored by the network device.
Creating the Spanning Tree Topology
In Figure 1-1, Switch A is elected as the root bridge because the bridge priority of all the network devices
is set to the default (32768) and Switch A has the lowest MAC address. However, due to traffic patterns,
number of forwarding ports, or link types, Switch A might not be the ideal root bridge. By increasing
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-5
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
the priority (lowering the numerical value) of the ideal network device so that it becomes the root bridge,
you force an STP recalculation to form a new spanning tree topology with the ideal network device as
the root.
Figure 1-1
Spanning Tree Topology
DP
A
DP
RP
DP
RP
B
D
DP DP
DP
RP
C
S5688
DP
RP = Root Port
DP = Designated Port
When the spanning tree topology is calculated based on default parameters, the path between source and
destination end stations in a switched network might not be ideal. For instance, connecting higher-speed
links to a port that has a higher number than the current root port can cause a root-port change. The goal
is to make the fastest link the root port.
For example, assume that one port on Switch B is a fiber-optic link, and another port on Switch B (an
unshielded twisted-pair [UTP] link) is the root port. Network traffic might be more efficient over the
high-speed fiber-optic link. By changing the STP port priority on the fiber-optic port to a higher priority
(lower numerical value) than the root port, the fiber-optic port becomes the new root port.
STP Port States
•
STP Port State Overview, page 1-6
•
Blocking State, page 1-8
•
Listening State, page 1-9
•
Learning State, page 1-10
•
Forwarding State, page 1-11
•
Disabled State, page 1-12
STP Port State Overview
Propagation delays can occur when protocol information passes through a switched LAN. As a result,
topology changes can take place at different times and at different places in a switched network. When
a Layer 2 LAN port transitions directly from nonparticipation in the spanning tree topology to the
forwarding state, it can create temporary data loops. Ports must wait for new topology information to
propagate through the switched LAN before starting to forward frames. They must allow the frame
lifetime to expire for frames that have been forwarded using the old topology.
Each Layer 2 LAN port using STP exists in one of the following five states:
•
Blocking—The Layer 2 LAN port does not participate in frame forwarding.
•
Listening—First transitional state after the blocking state when STP determines that the Layer 2
LAN port should participate in frame forwarding.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-6
Spanning Tree Protocols
Information About Spanning Tree Protocols
•
Learning—The Layer 2 LAN port prepares to participate in frame forwarding.
•
Forwarding—The Layer 2 LAN port forwards frames.
•
Disabled—The Layer 2 LAN port does not participate in STP and is not forwarding frames.
A Layer 2 LAN port moves through these five states as follows:
•
From initialization to blocking
•
From blocking to listening or to disabled
•
From listening to learning or to disabled
•
From learning to forwarding or to disabled
•
From forwarding to disabled
Figure 1-2 illustrates how a Layer 2 LAN port moves through the five states.
Figure 1-2
STP Layer 2 LAN Interface States
Boot-up
initialization
Blocking
state
Listening
state
Disabled
state
Learning
state
Forwarding
state
S5691
Chapter 1
When you enable STP, every port, VLAN, and network goes through the blocking state and the transitory
states of listening and learning at power up. If properly configured, each Layer 2 LAN port stabilizes to
the forwarding or blocking state.
When the STP algorithm places a Layer 2 LAN port in the forwarding state, the following process
occurs:
1.
The Layer 2 LAN port is put into the listening state while it waits for protocol information that
suggests it should go to the blocking state.
2.
The Layer 2 LAN port waits for the forward delay timer to expire, moves the Layer 2 LAN port to
the learning state, and resets the forward delay timer.
3.
In the learning state, the Layer 2 LAN port continues to block frame forwarding as it learns end
station location information for the forwarding database.
4.
The Layer 2 LAN port waits for the forward delay timer to expire and then moves the Layer 2 LAN
port to the forwarding state, where both learning and frame forwarding are enabled.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-7
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Blocking State
A Layer 2 LAN port in the blocking state does not participate in frame forwarding, as shown in
Figure 1-3. After initialization, a BPDU is sent out to each Layer 2 LAN port. A network device initially
assumes it is the root until it exchanges BPDUs with other network devices. This exchange establishes
which network device in the network is the root or root bridge. If only one network device is in the
network, no exchange occurs, the forward delay timer expires, and the ports move to the listening state.
A port always enters the blocking state following initialization.
Figure 1-3
Interface 2 in Blocking State
Segment
frames
Forwarding
Port 1
Station
addresses
BPDUs
Network
management
and data frames
Filtering
database
System
module
Frame
forwarding
BPDUs
Blocking
S5692
Data
frames
Network
management
frames
Port 2
Segment
frames
A Layer 2 LAN port in the blocking state performs as follows:
•
Discards frames received from the attached segment.
•
Discards frames switched from another port for forwarding.
•
Does not incorporate end station location into its address database. (There is no learning on a
blocking Layer 2 LAN port, so there is no address database update.)
•
Receives BPDUs and directs them to the system module.
•
Does not transmit BPDUs received from the system module.
•
Receives and responds to network management messages.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-8
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Listening State
The listening state is the first transitional state a Layer 2 LAN port enters after the blocking state. The
Layer 2 LAN port enters this state when STP determines that the Layer 2 LAN port should participate
in frame forwarding. Figure 1-4 shows a Layer 2 LAN port in the listening state.
Figure 1-4
Interface 2 in Listening State
All segment
frames
Forwarding
Port 1
Station
addresses
BPDUs
Network
management
and data frames
Filtering
database
System
module
Frame
forwarding
BPDUs
Network
management
frames
S5693
Data
frames
Port 2
Listening
All segment
frames
BPDU and network
management frames
A Layer 2 LAN port in the listening state performs as follows:
•
Discards frames received from the attached segment.
•
Discards frames switched from another LAN port for forwarding.
•
Does not incorporate end station location into its address database. (There is no learning at this
point, so there is no address database update.)
•
Receives BPDUs and directs them to the system module.
•
Receives, processes, and transmits BPDUs received from the system module.
•
Receives and responds to network management messages.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-9
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Learning State
A Layer 2 LAN port in the learning state prepares to participate in frame forwarding. The Layer 2 LAN
port enters the learning state from the listening state. Figure 1-5 shows a Layer 2 LAN port in the
learning state.
Figure 1-5
Interface 2 in Learning State
All segment
frames
Forwarding
Port 1
Station
addresses
BPDUs
Network
management
and data frames
Filtering
database
System
module
Frame
forwarding
Station
addresses
BPDUs
Network
management
frames
S5694
Data
frames
Port 2
Learning
All segment
frames
BPDU and network
management frames
A Layer 2 LAN port in the learning state performs as follows:
•
Discards frames received from the attached segment.
•
Discards frames switched from another port for forwarding.
•
Incorporates end station location into its address database.
•
Receives BPDUs and directs them to the system module.
•
Receives, processes, and transmits BPDUs received from the system module.
•
Receives and responds to network management messages.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-10
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Forwarding State
A Layer 2 LAN port in the forwarding state forwards frames, as shown in Figure 1-6. The Layer 2 LAN
port enters the forwarding state from the learning state.
Figure 1-6
Interface 2 in Forwarding State
All segment
frames
Forwarding
Port 1
Station
addresses
BPDUs
Network
management
and data frames
Filtering
database
System
module
Frame
forwarding
BPDUs
Network
management
and data frames
S5695
Station
addresses
Port 2
Forwarding
All segment
frames
A Layer 2 LAN port in the forwarding state performs as follows:
•
Forwards frames received from the attached segment.
•
Forwards frames switched from another port for forwarding.
•
Incorporates end station location information into its address database.
•
Receives BPDUs and directs them to the system module.
•
Processes BPDUs received from the system module.
•
Receives and responds to network management messages.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-11
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Disabled State
A Layer 2 LAN port in the disabled state does not participate in frame forwarding or STP, as shown in
Figure 1-7. A Layer 2 LAN port in the disabled state is virtually nonoperational.
Figure 1-7
Interface 2 in Disabled State
All segment
frames
Forwarding
Port 1
Station
addresses
BPDUs
Network
management
and data frames
Filtering
database
System
module
Frame
forwarding
Data
frames
S5696
Network
management
frames
Port 2
Disabled
All segment
frames
A disabled Layer 2 LAN port performs as follows:
•
Discards frames received from the attached segment.
•
Discards frames switched from another port for forwarding.
•
Does not incorporate end station location into its address database. (There is no learning, so there is
no address database update.)
•
Does not receive BPDUs.
•
Does not receive BPDUs for transmission from the system module.
STP and IEEE 802.1Q Trunks
802.1Q trunks impose some limitations on the STP strategy for a network. In a network of Cisco network
devices connected through 802.1Q trunks, the network devices maintain one instance of STP for each
VLAN allowed on the trunks. However, non-Cisco 802.1Q network devices maintain only one instance
of STP for all VLANs allowed on the trunks.
When you connect a Cisco network device to a non-Cisco device through an 802.1Q trunk, the Cisco
network device combines the STP instance of the 802.1Q VLAN of the trunk with the STP instance of
the non-Cisco 802.1Q network device. However, all per-VLAN STP information is maintained by Cisco
network devices separated by a cloud of non-Cisco 802.1Q network devices. The non-Cisco 802.1Q
cloud separating the Cisco network devices is treated as a single trunk link between the network devices.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-12
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
For more information on 802.1Q trunks, see Chapter 11, “LAN Ports for Layer 2 Switching.”
Information about IEEE 802.1w RSTP
•
RSTP Overview, page 1-13
•
Port Roles and the Active Topology, page 1-13
•
Rapid Convergence, page 1-14
•
Synchronization of Port Roles, page 1-15
•
Bridge Protocol Data Unit Format and Processing, page 1-16
•
Topology Changes, page 1-17
RSTP Overview
RSTP, which is enabled by default, takes advantage of point-to-point wiring and provides rapid
convergence of the spanning tree. Reconfiguration of the spanning tree can occur in less than 1 second
(in contrast to 50 seconds with the default settings in the 802.1D spanning tree).
Port Roles and the Active Topology
The RSTP provides rapid convergence of the spanning tree by assigning port roles and by learning the
active topology. The RSTP builds upon the 802.1D STP to select the switch with the highest switch
priority (lowest numerical priority value) as the root bridge as described in the “Election of the Root
Bridge” section on page 1-5. The RSTP then assigns one of these port roles to individual ports:
•
Root port—Provides the best path (lowest cost) when the switch forwards packets to the root bridge.
•
Designated port—Connects to the designated switch, which incurs the lowest path cost when
forwarding packets from that LAN to the root bridge. The port through which the designated switch
is attached to the LAN is called the designated port.
•
Alternate port—Offers an alternate path toward the root bridge to that provided by the current root
port.
•
Backup port—Acts as a backup for the path provided by a designated port toward the leaves of the
spanning tree. A backup port can exist only when two ports are connected in a loopback by a
point-to-point link or when a switch has two or more connections to a shared LAN segment.
•
Disabled port—Has no role within the operation of the spanning tree.
A port with the root or a designated port role is included in the active topology. A port with the alternate
or backup port role is excluded from the active topology.
In a stable topology with consistent port roles throughout the network, the RSTP ensures that every root
port and designated port immediately transition to the forwarding state while all alternate and backup
ports are always in the discarding state (equivalent to blocking in 802.1D). The port state controls the
operation of the forwarding and learning processes. Table 1-2 provides a comparison of 802.1D and
RSTP port states.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-13
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Table 1-2
Port State Comparison
Operational Status
STP Port State
(IEEE 802.1D)
RSTP Port State
Is Port Included in the
Active Topology?
Enabled
Blocking
Discarding
No
Enabled
Listening
Discarding
No
Enabled
Learning
Learning
Yes
Enabled
Forwarding
Forwarding
Yes
Disabled
Disabled
Discarding
No
To be consistent with Cisco STP implementations, this guide defines the port state as blocking instead
of discarding. Designated ports start in the listening state.
Rapid Convergence
The RSTP provides for rapid recovery of connectivity following the failure of a switch, a switch port, or
a LAN. It provides rapid convergence for edge ports, new root ports, and ports connected through
point-to-point links as follows:
•
Edge ports—If you configure a port as an edge port on an RSTP switch by using the spanning-tree
portfast interface configuration command, the edge port immediately transitions to the forwarding
state. An edge port is the same as a Port Fast-enabled port, and you should enable it only on ports
that connect to a single end station.
•
Root ports—If the RSTP selects a new root port, it blocks the old root port and immediately
transitions the new root port to the forwarding state.
•
Point-to-point links—If you connect a port to another port through a point-to-point link and the local
port becomes a designated port, it negotiates a rapid transition with the other port by using the
proposal-agreement handshake to ensure a loop-free topology.
As shown in Figure 1-8, switch A is connected to switch B through a point-to-point link, and all of
the ports are in the blocking state. Assume that the priority of switch A is a smaller numerical value
than the priority of switch B. Switch A sends a proposal message (a configuration BPDU with the
proposal flag set) to switch B, proposing itself as the designated switch.
After receiving the proposal message, switch B selects as its new root port the port from which the
proposal message was received, forces all nonedge ports to the blocking state, and sends an
agreement message (a BPDU with the agreement flag set) through its new root port.
After receiving switch B’s agreement message, switch A also immediately transitions its designated
port to the forwarding state. No loops in the network are formed because switch B blocked all of its
nonedge ports and because there is a point-to-point link between switches A and B.
When switch C is connected to switch B, a similar set of handshaking messages are exchanged.
Switch C selects the port connected to switch B as its root port, and both ends immediately transition
to the forwarding state. With each iteration of this handshaking process, one more switch joins the
active topology. As the network converges, this proposal-agreement handshaking progresses from
the root toward the leaves of the spanning tree.
The switch learns the link type from the port duplex mode: a full-duplex port is considered to have
a point-to-point connection and a half-duplex port is considered to have a shared connection. You
can override the default setting that is controlled by the duplex setting by using the spanning-tree
link-type interface configuration command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-14
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Figure 1-8
Proposal and Agreement Handshaking for Rapid Convergence
Switch A
Proposal
Switch B
Root
Agreement
Designated
switch
F
DP
F
RP
Root
F
DP
Proposal
Designated
switch
Agreement
F
RP
Root
F
DP
Designated
switch
F
RP
F
DP
Switch C
F
RP
88760
DP = designated port
RP = root port
F = forwarding
Synchronization of Port Roles
When the switch receives a proposal message on one of its ports and that port is selected as the new root
port, the RSTP forces all other ports to synchronize with the new root information.
The switch is synchronized with superior root information received on the root port if all other ports are
synchronized. An individual port on the switch is synchronized if:
•
That port is in the blocking state.
•
It is an edge port (a port configured to be at the edge of the network).
If a designated port is in the forwarding state and is not configured as an edge port, it transitions to the
blocking state when the RSTP forces it to synchronize with new root information. In general, when the
RSTP forces a port to synchronize with root information and the port does not satisfy any of the above
conditions, its port state is set to blocking.
After ensuring that all of the ports are synchronized, the switch sends an agreement message to the
designated switch corresponding to its root port. When the switches connected by a point-to-point link
are in agreement about their port roles, the RSTP immediately transitions the port states to forwarding.
The sequence of events is shown in Figure 1-9.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-15
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Figure 1-9
Sequence of Events During Rapid Convergence
4. Agreement
1. Proposal
5. Forward
Edge port
3. Block
11. Forward
8. Agreement
7. Proposal
6. Proposal
10. Agreement
Root port
Designated port
88761
2. Block
9. Forward
Bridge Protocol Data Unit Format and Processing
•
BPDU Format and Processing Overview, page 1-16
•
Processing Superior BPDU Information, page 1-17
•
Processing Inferior BPDU Information, page 1-17
BPDU Format and Processing Overview
The RSTP BPDU format is the same as the 802.1D BPDU format except that the protocol version is set
to 2. A new 1-byte Version 1 Length field is set to zero, which means that no Version 1 protocol
information is present. Table 1-3 describes the RSTP flag fields.
Table 1-3
RSTP BPDU Flags
Bit
Function
0
Topology change (TC)
1
Proposal
2–3:
Port role:
00
Unknown
01
Alternate port or backup port
10
Root port
11
Designated port
4
Learning
5
Forwarding
6
Agreement
7
Topology change acknowledgement (TCA)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-16
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
The sending switch sets the proposal flag in the RSTP BPDU to propose itself as the designated switch
on that LAN. The port role in the proposal message is always set to the designated port.
The sending switch sets the agreement flag in the RSTP BPDU to accept the previous proposal. The port
role in the agreement message is always set to the root port.
The RSTP does not have a separate TCN BPDU. It uses the topology change (TC) flag to show the
topology changes. However, for interoperability with 802.1D switches, the RSTP switch processes and
generates TCN BPDUs.
The learning and forwarding flags are set according to the state of the sending port.
Processing Superior BPDU Information
A superior BPDU is a BPDU with root information (such as lower switch ID or lower path cost) that is
superior to what is currently stored for the port.
If a port receives a superior BPDU, the RSTP triggers a reconfiguration. If the port is proposed and is
selected as the new root port, RSTP forces all the other ports to synchronize.
If the BPDU received is an RSTP BPDU with the proposal flag set, the switch sends an agreement
message after all of the other ports are synchronized. If the BPDU is an 802.1D BPDU, the switch does
not set the proposal flag and starts the forward-delay timer for the port. The new root port requires twice
the forward-delay time to transition to the forwarding state.
If the superior information received on the port causes the port to become a backup port or an alternate
port, RSTP sets the port to the blocking state and sends an agreement message. The designated port
continues sending BPDUs with the proposal flag set until the forward-delay timer expires, at which time
the port transitions to the forwarding state.
Processing Inferior BPDU Information
An inferior BPDU is a BPDU with root information (such as higher switch ID or higher path cost) that
is inferior to what is currently stored for the port.
If a designated port receives an inferior BPDU, it immediately replies with its own information.
Topology Changes
These are the differences between the RSTP and the 802.1D in handling spanning tree topology changes:
•
Detection—Unlike 802.1D in which any transition between the blocking and the forwarding state
causes a topology change, only transitions from the blocking to the forwarding state cause a
topology change with RSTP (only an increase in connectivity is considered a topology change).
State changes on an edge port do not cause a topology change. When an RSTP switch detects a
topology change, it deletes the learned information on all of its nonedge ports except on those from
which it received the TC notification.
•
Notification—The RSTP does not use TCN BPDUs, unlike 802.1D. However, for 802.1D
interoperability, an RSTP switch processes and generates TCN BPDUs.
•
Acknowledgement—When an RSTP switch receives a TCN message on a designated port from an
802.1D switch, it replies with an 802.1D configuration BPDU with the TCA bit set. However, if the
TC-while timer (the same as the TC timer in 802.1D) is active on a root port connected to an 802.1D
switch and a configuration BPDU with the TCA set is received, the TC-while timer is reset.
This method of operation is only required to support 802.1D switches. The RSTP BPDUs never have
the TCA bit set.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-17
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
•
Propagation—When an RSTP switch receives a TC message from another switch through a
designated or root port, it propagates the change to all of its nonedge, designated ports and to the
root port (excluding the port on which it is received). The switch starts the TC-while timer for all
such ports and flushes the information learned on them.
•
Protocol migration—For backward compatibility with 802.1D switches, RSTP selectively sends
802.1D configuration BPDUs and TCN BPDUs on a per-port basis.
When a port is initialized, the migrate-delay timer is started (specifies the minimum time during
which RSTP BPDUs are sent), and RSTP BPDUs are sent. While this timer is active, the switch
processes all BPDUs received on that port and ignores the protocol type.
If the switch receives an 802.1D BPDU after the port migration-delay timer has expired, it assumes
that it is connected to an 802.1D switch and starts using only 802.1D BPDUs. However, if the RSTP
switch is using 802.1D BPDUs on a port and receives an RSTP BPDU after the timer has expired,
it restarts the timer and starts using RSTP BPDUs on that port.
Information about MST
•
MST Overview, page 1-18
•
MST Regions, page 1-19
•
IST, CIST, and CST, page 1-19
•
Hop Count, page 1-22
•
Boundary Ports, page 1-22
•
Standard-Compliant MST Implementation, page 1-23
•
Interoperability with IEEE 802.1D-1998 STP, page 1-24
MST Overview
MST maps multiple VLANs into a spanning tree instance, with each instance having a spanning tree
topology independent of other spanning tree instances. This architecture provides multiple forwarding
paths for data traffic, enables load balancing, and reduces the number of spanning tree instances required
to support a large number of VLANs. MST improves the fault tolerance of the network because a failure
in one instance (forwarding path) does not affect other instances (forwarding paths).
The most common initial deployment of MST is in the backbone and distribution layers of a Layer 2
switched network. This deployment provides the kind of highly available network that is required in a
service-provider environment.
MST provides rapid spanning tree convergence through explicit handshaking, which eliminates the
802.1D forwarding delay and quickly transitions root bridge ports and designated ports to the forwarding
state.
MST improves spanning tree operation and maintains backward compatibility with these STP versions:
•
Original 802.1D spanning tree
•
Existing Cisco-proprietary Multiple Instance STP (MISTP)
•
Existing Cisco per-VLAN spanning tree plus (PVST+)
•
Rapid per-VLAN spanning tree plus (rapid PVST+)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-18
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Note
•
IEEE 802.1w defined the Rapid Spanning Tree Protocol (RSTP) and was incorporated into
IEEE 802.1D.
•
IEEE 802.1s defined MST and was incorporated into IEEE 802.1Q.
MST Regions
For switches to participate in MST instances, you must consistently configure the switches with the same
MST configuration information. A collection of interconnected switches that have the same MST
configuration comprises an MST region as shown in Figure 1-10 on page 1-21.
The MST configuration controls to which MST region each switch belongs. The configuration includes
the name of the region, the revision number, and the MST VLAN-to-instance assignment map.
A region can have one or multiple members with the same MST configuration; each member must be
capable of processing RSTP bridge protocol data units (BPDUs). There is no limit to the number of MST
regions in a network, but each region can support up to 65 spanning tree instances. Instances can be
identified by any number in the range from 0 to 4094. You can assign a VLAN to only one spanning tree
instance at a time.
IST, CIST, and CST
•
IST, CIST, and CST Overview, page 1-19
•
Spanning Tree Operation Within an MST Region, page 1-20
•
Spanning Tree Operations Between MST Regions, page 1-20
•
IEEE 802.1s Terminology, page 1-21
IST, CIST, and CST Overview
Unlike other spanning tree protocols, in which all the spanning tree instances are independent, MST
establishes and maintains internal spanning tree (IST), common and internal spanning tree (CIST), and
common spanning tree (CST) instances:
•
An IST is the spanning tree that runs in an MST region.
Within each MST region, MST maintains multiple spanning tree instances. Instance 0 is a special
instance for a region, known as the IST. All other MST instances are numbered from 1 to 4094.
The IST is the only spanning tree instance that sends and receives BPDUs. All of the other
spanning tree instance information is contained in MSTP records (M-records), which are
encapsulated within MST BPDUs. Because the MST BPDU carries information for all instances, the
number of BPDUs that need to be processed to support multiple spanning tree instances is
significantly reduced.
All MST instances within the same region share the same protocol timers, but each MST instance
has its own topology parameters, such as root bridge ID, root path cost, and so forth. By default, all
VLANs are assigned to the IST.
An MST instance is local to the region; for example, MST instance 1 in region A is independent of
MST instance 1 in region B, even if regions A and B are interconnected.
•
A CIST is a collection of the ISTs in each MST region.
•
The CST interconnects the MST regions and single spanning trees.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-19
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
The spanning tree computed in a region appears as a subtree in the CST that encompasses the entire
switched domain. The CIST is formed by the spanning tree algorithm running among switches that
support the 802.1w, 802.1s, and 802.1D standards. The CIST inside an MST region is the same as the
CST outside a region.
For more information, see the “Spanning Tree Operation Within an MST Region” section on page 1-20 and
the “Spanning Tree Operations Between MST Regions” section on page 1-20.
Spanning Tree Operation Within an MST Region
The IST connects all the MST switches in a region. When the IST converges, the root of the IST becomes
the CIST regional root (called the IST master before the implementation of the 802.1s standard) as shown
in Figure 1-10 on page 1-21. The CIST regional root is also the CIST root if there is only one region in
the network. If the CIST root is outside the region, one of the MST switches at the boundary of the region
is selected as the CIST regional root.
When an MST switch initializes, it sends BPDUs that identify itself as the root of the CIST and the CIST
regional root, with both of the path costs to the CIST root and to the CIST regional root set to zero. The
switch also initializes all of its MST instances and claims to be the root for all of them. If the switch
receives superior MST root information (lower switch ID, lower path cost, and so forth) than currently
stored for the port, it relinquishes its claim as the CIST regional root.
During initialization, a region might have many subregions, each with its own CIST regional root. As
switches receive superior IST information from a neighbor in the same region, they leave their old
subregions and join the new subregion that contains the true CIST regional root, which causes all
subregions to shrink except for the one that contains the true CIST regional root.
For correct operation, all switches in the MST region must agree on the same CIST regional root.
Therefore, any two switches in the region only synchronize their port roles for an MST instance if they
converge to a common CIST regional root.
Spanning Tree Operations Between MST Regions
If there are multiple regions or 802.1D switches within the network, MST establishes and maintains the
CST, which includes all MST regions and all 802.1D STP switches in the network. The MST instances
combine with the IST at the boundary of the region to become the CST.
The IST connects all the MST switches in the region and appears as a subtree in the CIST that
encompasses the entire switched domain. The root of the subtree is the CIST regional root. The MST
region appears as a virtual switch to adjacent STP switches and MST regions.
Figure 1-10 shows a network with three MST regions and an 802.1D switch (D). The CIST regional root
for region 1 (A) is also the CIST root. The CIST regional root for region 2 (B) and the CIST regional
root for region 3 (C) are the roots for their respective subtrees within the CIST.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-20
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
Figure 1-10
MST Regions, CIST Regional Roots, and CST Root
A CIST Regional
Root and CST root
D
Legacy 802.1D
MST Region 1
CIST Regional
Root
MST Region 2
C
CIST Regional
Root
MST Region 3
92720
B
Only the CST instance sends and receives BPDUs, and MST instances add their spanning tree
information into the BPDUs to interact with neighboring switches and compute the final spanning tree
topology. Because of this, the spanning tree parameters related to BPDU transmission (for example,
hello time, forward time, max-age, and max-hops) are configured only on the CST instance but affect all
MST instances. Parameters related to the spanning tree topology (for example, switch priority, port
VLAN cost, and port VLAN priority) can be configured on both the CST instance and the MST instance.
MST switches use Version 3 BPDUs or 802.1D STP BPDUs to communicate with 802.1D switches.
MST switches use MST BPDUs to communicate with MST switches.
IEEE 802.1s Terminology
Some MST naming conventions used in the prestandard implementation have been changed to include
identification of some internal and regional parameters. These parameters are used only within an MST
region, compared to external parameters that are used throughout the whole network. Because the CIST
is the only spanning tree instance that spans the whole network, only the CIST parameters require the
external qualifiers and not the internal or regional qualifiers.
•
The CIST root is the root bridge for the CIST, which is the unique instance that spans the whole
network.
•
The CIST external root path cost is the cost to the CIST root. This cost is left unchanged within an
MST region. Remember that an MST region looks like a single switch to the CIST. The CIST
external root path cost is the root path cost calculated between these virtual switches and switches
that do not belong to any region.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-21
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
•
The CIST regional root was called the IST master in the prestandard implementation. If the CIST
root is in the region, the CIST regional root is the CIST root. Otherwise, the CIST regional root is
the closest switch to the CIST root in the region. The CIST regional root acts as a root bridge for the
IST.
•
The CIST internal root path cost is the cost to the CIST regional root in a region. This cost is only
relevant to the IST, instance 0.
Table 1-4 compares the IEEE standard and the Cisco prestandard terminology.
Table 1-4
Prestandard and Standard Terminology
IEEE Standard Definition
Cisco Prestandard Implementation
Cisco Standard Implementation
CIST regional root
IST master
CIST regional root
CIST internal root path cost
IST master path cost
CIST internal path cost
CIST external root path cost
Root path cost
Root path cost
MSTI regional root
Instance root
Instance root
MSTI internal root path cost
Root path cost
Root path cost
Hop Count
MST does not use the message-age and maximum-age information in the configuration BPDU to
compute the spanning tree topology. Instead, they use the path cost to the root and a hop-count
mechanism similar to the IP time-to-live (TTL) mechanism.
By using the spanning-tree mst max-hops global configuration command, you can configure the
maximum hops inside the region and apply it to the IST and all MST instances in that region. The hop
count achieves the same result as the message-age information (triggers a reconfiguration). The root
bridge of the instance always sends a BPDU (or M-record) with a cost of 0 and the hop count set to the
maximum value. When a switch receives this BPDU, it decrements the received remaining hop count by
one and propagates this value as the remaining hop count in the BPDUs it generates. When the count
reaches zero, the switch discards the BPDU and ages the information held for the port.
The message-age and maximum-age information in the RSTP portion of the BPDU remain the same
throughout the region, and the same values are propagated by the region-designated ports at the
boundary.
Boundary Ports
In the Cisco prestandard implementation, a boundary port connects an MST region to one of these STP
regions:
•
A single spanning tree region running RSTP
•
A single spanning tree region running PVST+ or rapid PVST+
•
Another MST region with a different MST configuration
A boundary port also connects to a LAN, the designated switch of which is either a single spanning tree
switch or a switch with a different MST configuration.
There is no definition of a boundary port in the 802.1s standard. The 802.1Q-2002 standard identifies
two kinds of messages that a port can receive: internal (coming from the same region) and external.
When a message is external, it is received only by the CIST. If the CIST role is root or alternate, or if
the external BPDU is a topology change, it could have an impact on the MST instances. When a message
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-22
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
is internal, the CIST part is received by the CIST, and each MST instance receives its respective
M-record. The Cisco prestandard implementation treats a port that receives an external message as a
boundary port, which means a port cannot receive a mix of internal and external messages.
An MST region includes both switches and LANs. A segment belongs to the region of its designated
port. Therefore, a port in a different region from the designated port for a segment is a boundary port.
This definition allows two ports internal to a region to share a segment with a port belonging to a
different region, creating the possibility of receiving both internal and external messages on a port.
The primary change from the Cisco prestandard implementation is that a designated port is not defined
as boundary unless it is running in an STP-compatible mode.
Note
If there is an 802.1D STP switch on the segment, messages are always considered external.
The other change from the prestandard implementation is that the CIST regional root bridge ID field is
now inserted where an RSTP or legacy 802.1s switch has the sender switch ID. The whole region
performs like a single virtual switch by sending a consistent sender switch ID to neighboring switches.
In this example, switch C would receive a BPDU with the same consistent sender switch ID of root,
whether or not A or B is designated for the segment.
Standard-Compliant MST Implementation
Note
•
Changes in Port-Role Naming, page 1-23
•
Spanning Tree Interoperation Between Legacy and Standard-Compliant Switches, page 1-23
The standard-compliant MST implementation includes features required to meet the standard, as well as
some of the desirable prestandard functionality that is not yet incorporated into the published standard.
Changes in Port-Role Naming
The boundary role was deleted from the final MST standard, but this boundary concept is maintained in
the standard-compliant implementation. However, an MST instance (MSTI) port at a boundary of the
region might not follow the state of the corresponding CIST port. The following two situations currently
exist:
•
The boundary port is the root port of the CIST regional root—When the CIST instance port is
proposed and is synchronized, it can send back an agreement and move to the forwarding state only
after all the corresponding MSTI ports are synchronized (and thus forwarding). The MSTI ports now
have a special master role.
•
The boundary port is not the root port of the CIST regional root—The MSTI ports follow the state
and role of the CIST port. The standard provides less information, and it might be difficult to
understand why an MSTI port can be alternately blocking when it receives no BPDUs (M-records).
In this situation, although the boundary role no longer exists, when you enter the show commands,
they identify a port as boundary in the type column of the output.
Spanning Tree Interoperation Between Legacy and Standard-Compliant Switches
Because automatic detection of prestandard switches can fail, you can use an interface configuration
command to identify prestandard ports. A region cannot be formed between a standard and a prestandard
switch, but they can interoperate before using the CIST. Only the capability of load balancing over
different instances is lost in this specific situation. The CLI displays different flags depending on the
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-23
Chapter 1
Spanning Tree Protocols
Information About Spanning Tree Protocols
port configuration when the port receives prestandard BPDUs. A syslog message also appears the first
time a switch receives a prestandard BPDU on a port that has not been configured for prestandard BPDU
transmission.
Figure 1-11 illustrates a standard-compliant switch connected to a prestandard switch. Assume that A is
the standard-compliant switch and B is a prestandard switch, both configured to be in the same region.
A is the root bridge for the CIST, and so B has a root port (BX) on segment X and an alternate port (BY)
on segment Y. If segment Y flaps, and the port on BY becomes the alternate before sending out a single
prestandard BPDU, AY cannot detect that a prestandard switch is connected to Y and continues to send
standard BPDUs. The port BY is fixed in a boundary, and no load balancing is possible between A and
B. The same problem exists on segment X, but B might transmit topology changes.
Figure 1-11
Standard-Compliant and Prestandard Switch Interoperation
Segment X
MST
Region
Switch A
Segment Y
Note
92721
Switch B
We recommend that you minimize the interaction between standard and prestandard MST
implementations.
Interoperability with IEEE 802.1D-1998 STP
A switch running MST supports a built-in protocol migration feature that enables it to interoperate with
802.1D switches. If this switch receives an 802.1D configuration BPDU (a BPDU with the protocol
version set to 0), it sends only 802.1D BPDUs on that port. An MST switch also can detect that a port is
at the boundary of a region when it receives an 802.1D BPDU, an MST BPDU (Version 3) associated
with a different region, or an RSTP BPDU (Version 2).
However, the switch does not automatically revert to the MST mode if it no longer receives 802.1D
BPDUs because it cannot detect whether the 802.1D switch has been removed from the link unless the
802.1D switch is the designated switch. A switch might also continue to assign a boundary role to a port
when the switch to which this switch is connected has joined the region. To restart the protocol migration
process (force the renegotiation with neighboring switches), use the clear spanning-tree
detected-protocols privileged EXEC command.
If all the 802.1D switches on the link are RSTP switches, they can process MST BPDUs as if they are
RSTP BPDUs. Therefore, MST switches send either a Version 0 configuration and topology change
notification (TCN) BPDUs or Version 3 MST BPDUs on a boundary port. A boundary port connects to
a LAN, the designated switch of which is either a single spanning tree switch or a switch with a different
MST configuration.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-24
Chapter 1
Spanning Tree Protocols
Default Settings for Spanning Tree Protocols
Detecting Unidirectional Link Failure
Using the dispute mechanism included in the IEEE 802.1D-2004 RSTP and IEEE 802.1Q-2005 MSTP
standard, the switch checks the consistency of the port role and state in the received BPDUs to detect
unidirectional link failures that could cause bridging loops.
When a designated port detects a conflict, it keeps its role, but reverts to a discarding (blocking) state
because disrupting connectivity in case of inconsistency is preferable to opening a bridging loop.
Figure 1-12 illustrates a unidirectional link failure that typically creates a bridging loop. Switch A is the
root bridge, and its BPDUs are lost on the link leading to switch B. RSTP and MST BPDUs include the
role and state of the sending port. With this information, switch A can detect that switch B does not react
to the superior BPDUs it sends and that switch B is the designated, not root bridge. As a result, switch
A blocks (or keeps blocking) its port, thus preventing the bridging loop.
Detecting Unidirectional Link Failure
Superior
BPDU
Switch
A
Switch
B
Inferior BPDU,
Designated + Learning bit set
92722
Figure 1-12
Default Settings for Spanning Tree Protocols
•
Default STP Configuration, page 1-25
•
Default MST Configuration, page 1-26
Default STP Configuration
Feature
Default Value
Mode
Rapid PVST+
Enable state
Enabled for all VLANs
Bridge priority
32768
STP port priority (configurable on a per-port basis—used on LAN ports
configured as Layer 2 access ports)
128
STP port cost (configurable on a per-port basis—used on LAN ports
configured as Layer 2 access ports)
10-Gigabit Ethernet: 2
STP VLAN port priority (configurable on a per-VLAN basis—used on
LAN ports configured as Layer 2 trunk ports)
Gigabit Ethernet:
4
Fast Ethernet:
19
Ethernet:
100
128
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-25
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Feature
Default Value
STP VLAN port cost (configurable on a per-VLAN basis—used on LAN
ports configured as Layer 2 trunk ports)
10-Gigabit Ethernet: 2
Gigabit Ethernet:
4
Fast Ethernet:
19
Ethernet:
100
Hello time
2 seconds
Forward delay time
15 seconds
Maximum aging time
20 seconds
Default MST Configuration
Feature
Default Setting
Spanning tree mode
Rapid PVST+
(MST is disabled)
Switch priority
(configurable on a per-MST port basis)
32768
Spanning tree port priority
(configurable on a per-MST instance port basis)
128
Spanning tree port cost
(configurable on a per-MST instance port basis)
10-Gigabit Ethernet: 2,000
20,000
Fast Ethernet:
200,000
Ethernet:
2,000,000
Hello time
2 seconds
Forward-delay time
15 seconds
Maximum-aging time
20 seconds
Maximum hop count
20 hops
How to Configure Spanning Tree Protocols
•
Configuring STP, page 1-26
•
Configuring MST, page 1-37
Configuring STP
•
Enabling STP, page 1-27
•
Enabling the Extended System ID, page 1-28
•
Configuring the Root Bridge, page 1-29
•
Configuring a Secondary Root Bridge, page 1-30
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-26
Gigabit Ethernet:
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
•
Configuring STP Port Priority, page 1-31
•
Configuring STP Port Cost, page 1-32
•
Configuring the Bridge Priority of a VLAN, page 1-34
•
Configuring the Hello Time, page 1-35
•
Configuring the Forward-Delay Time for a VLAN, page 1-35
•
Configuring the Maximum Aging Time for a VLAN, page 1-36
•
Enabling Rapid-PVST+, page 1-36
Note
The STP commands described in this chapter can be configured on any LAN port, but they are in effect
only on LAN ports configured with the switchport keyword.
Caution
We do not recommend disabling spanning tree, even in a topology that is free of physical loops. Spanning
tree serves as a safeguard against misconfigurations and cabling errors. Do not disable spanning tree in
a VLAN without ensuring that there are no physical loops present in the VLAN.
Enabling STP
Note
STP is enabled by default on VLAN 1 and on all newly created VLANs.
You can enable STP on a per-VLAN basis. The switch maintains a separate instance of STP for each
VLAN (except on VLANs on which you disable STP).
To enable STP on a per-VLAN basis, perform this task:
Step 1
Step 2
Command
Purpose
Router(config)# spanning-tree vlan vlan_ID
Enables STP on a per-VLAN basis. The vlan_ID value
can be 1 through 4094, except reserved VLANs (see
“Default STP Configuration” section on page 1-25).
Router(config)# default spanning-tree vlan
vlan_ID
Reverts all STP parameters to default values for the
specified VLAN.
Router(config)# no spanning-tree vlan vlan_ID
Disables STP on the specified VLAN; see the following
Cautions for information regarding this command.
Router(config)# end
Exits configuration mode.
Caution
Do not disable spanning tree on a VLAN unless all switches and bridges in the VLAN have spanning
tree disabled. You cannot disable spanning tree on some switches and bridges in a VLAN and leave it
enabled on other switches and bridges in the VLAN. This action can have unexpected results because
switches and bridges with spanning tree enabled will have incomplete information regarding the physical
topology of the network.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-27
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Caution
We do not recommend disabling spanning tree, even in a topology that is free of physical loops. Spanning
tree serves as a safeguard against misconfigurations and cabling errors. Do not disable spanning tree in
a VLAN without ensuring that there are no physical loops present in the VLAN.
This example shows how to enable STP on VLAN 200:
Router# configure terminal
Router(config)# spanning-tree vlan 200
Router(config)# end
Router#
Note
Because STP is enabled by default, entering a show running command to view the resulting
configuration does not display the command you entered to enable STP.
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200
VLAN0200
Spanning tree enabled protocol ieee
Root ID
Priority
32768
Address
00d0.00b8.14c8
This bridge is the root
Hello Time
2 sec Max Age 20 sec
Bridge ID
Priority
32768
Address
00d0.00b8.14c8
Hello Time
2 sec Max Age 20 sec
Aging Time 300
Interface
---------------Gi1/4
Gi1/5
Role
---Desg
Back
Sts
--FWD
BLK
Cost
--------200000
200000
Prio.Nbr
-------128.196
128.197
Forward Delay 15 sec
Forward Delay 15 sec
Status
-------------------------------P2p
P2p
Router#
Note
You must have at least one interface that is active in VLAN 200 to create a VLAN 200 spanning tree. In
this example, two interfaces are active in VLAN 200.
Enabling the Extended System ID
Note
•
The extended system ID is enabled permanently on chassis that support 64 MAC addresses.
•
You must enable the extended system ID to configure extended range VLANs (1006-4094).
•
You must enable the extended system ID if it is enabled on any switches in the VTP domain.
You can enable the extended system ID on chassis that support 1024 MAC addresses (see the
“Information about the Bridge ID” section on page 1-3).
To enable the extended system ID, perform this task:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-28
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Step 1
Command
Purpose
Router(config)# spanning-tree extend system-id
Enables the extended system ID.
Note
Step 2
Router(config)# end
Note
You cannot disable the extended system ID on
chassis that support 64 MAC addresses or when
you have configured extended range VLANs (see
the “VLAN Ranges” section on page 16-2).
Exits configuration mode.
When you enable or disable the extended system ID, the bridge IDs of all active STP instances are
updated, which might change the spanning tree topology.
This example shows how to enable the extended system ID:
Router# configure terminal
Router(config)# spanning-tree extend system-id
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree summary | include Extended
Extended system ID is enabled.
Configuring the Root Bridge
The switches supported by Cisco IOS Release 15.1SY maintain a separate instance of STP for each
active VLAN. A bridge ID, consisting of the bridge priority and the bridge MAC address, is associated
with each instance. For each VLAN, the network device with the lowest bridge ID becomes the root
bridge for that VLAN.
To configure a VLAN instance to become the root bridge, enter the spanning-tree vlan vlan_ID root
command to modify the bridge priority from the default value (32768) to a significantly lower value.
When you enter the spanning-tree vlan vlan_ID root command, the switch checks the bridge priority
of the current root bridges for each VLAN. With the extended system ID enabled, the switch sets the
bridge priority for the specified VLANs to 24576 if this value will cause the switch to become the root
for the specified VLANs.
With the extended system ID enabled, if any root bridge for the specified VLANs has a bridge priority
lower than 24576, the switch sets the bridge priority for the specified VLANs to 4096 less than the
lowest bridge priority. (4096 is the value of the least significant bit of a 4-bit bridge priority value; see
Table 1-1 on page 1-4.)
Note
The spanning-tree vlan vlan_ID root command fails if the value required to be the root bridge is less
than 1.
With the extended system ID enabled, if all network devices in, for example, VLAN 20 have the default
priority of 32768, entering the spanning-tree vlan 20 root primary command on the switch sets the
bridge priority to 24576, which causes the switch to become the root bridge for VLAN 20.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-29
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Caution
The root bridge for each instance of STP should be a backbone or distribution switch. Do not configure
an access switch as the STP primary root.
Use the diameter keyword to specify the Layer 2 network diameter (that is, the maximum number of
bridge hops between any two end stations in the Layer 2 network). When you specify the network
diameter, the switch automatically selects an optimal hello time, forward delay time, and maximum age
time for a network of that diameter, which can significantly reduce the STP convergence time. You can
use the hello keyword to override the automatically calculated hello time.
Note
To preserve a stable STP topology, we recommend that you avoid configuring the hello time, forward
delay time, and maximum age time manually after configuring the switch as the root bridge.
To configure the switch as the root bridge, perform this task:
Step 1
Step 2
Command
Purpose
Router(config)# spanning-tree vlan vlan_ID root
primary [diameter hops [hello-time seconds]]
Configures the switch as the root bridge. The vlan_ID
value can be 1 through 4094, except reserved VLANs (see
“Default STP Configuration” section on page 1-25).
Router(config)# no spanning-tree vlan vlan_ID
root
Clears the root bridge configuration.
Router(config)# end
Exits configuration mode.
This example shows how to configure the switch as the root bridge for VLAN 10, with a network
diameter of 4:
Router# configure terminal
Router(config)# spanning-tree vlan 10 root primary diameter 4
Router(config)# end
Router#
Configuring a Secondary Root Bridge
When you configure a switch as the secondary root, the STP bridge priority is modified from the default
value (32768) so that the switch is likely to become the root bridge for the specified VLANs if the
primary root bridge fails (assuming the other network devices in the network use the default bridge
priority of 32768).
With the extended system ID is enabled, STP sets the bridge priority to 28672.
You can run this command on more than one switch to configure multiple backup root bridges. Use the
same network diameter and hello time values as you used when configuring the primary root bridge.
To configure the switch as the secondary root bridge, perform this task:
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-30
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Step 1
Step 2
Command
Purpose
Router(config)# [no] spanning-tree vlan vlan_ID
root secondary [diameter hops [hello-time
seconds]]
Configures the switch as the secondary root bridge. The
vlan_ID value can be 1 through 4094, except reserved
VLANs (see “Default STP Configuration” section on
page 1-25).
Router(config)# no spanning-tree vlan vlan_ID
root
Clears the root bridge configuring.
Router(config)# end
Exits configuration mode.
This example shows how to configure the switch as the secondary root bridge for VLAN 10, with a
network diameter of 4:
Router# configure terminal
Router(config)# spanning-tree vlan 10 root secondary diameter 4
Router(config)# end
Router#
Configuring STP Port Priority
If a loop occurs, STP considers port priority when selecting a LAN port to put into the forwarding state.
You can assign higher priority values to LAN ports that you want STP to select first and lower priority
values to LAN ports that you want STP to select last. If all LAN ports have the same priority value, STP
puts the LAN port with the lowest LAN port number in the forwarding state and blocks other LAN ports.
The possible priority range is 0 through 240 (default 128), configurable in increments of 16.
Cisco IOS uses the port priority value when the LAN port is configured as an access port and uses VLAN
port priority values when the LAN port is configured as a trunk port.
To configure the STP port priority of a Layer 2 LAN interface, perform this task:
Command
Purpose
Step 1
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel port_channel_number}}
Selects an interface to configure.
Step 2
Router(config-if)# spanning-tree port-priority
port_priority
Configures the port priority for the LAN interface.
The port_priority value can be from 1 to 252 in
increments of 4.
Step 3
Router(config-if)# spanning-tree vlan vlan_ID
port-priority port_priority
Configures the VLAN port priority for the LAN
interface. The port_priority value can be from 1 to
252 in increments of 4. The vlan_ID value can be 1
through 4094, except reserved VLANs (see
Table 16-1 on page 16-3).
Step 4
Router(config-if)# end
Exits configuration mode.
This example shows how to configure the STP port priority of Gigabit Ethernet port 1/4:
Router# configure terminal
Router(config)# interface gigabitethernet 1/4
Router(config-if)# spanning-tree port-priority 160
Router(config-if)# end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-31
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
This example shows how to verify the configuration of Gigabit Ethernet port 1/4:
Router# show spanning-tree interface gigabitethernet 1/4
Vlan
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------VLAN0001
Back BLK 200000
160.196 P2p
VLAN0006
Back BLK 200000
160.196 P2p
...
VLAN0198
Back BLK 200000
160.196 P2p
VLAN0199
Back BLK 200000
160.196 P2p
VLAN0200
Back BLK 200000
160.196 P2p
Router#
Gigabit Ethernet port 1/4 is a trunk. Several VLANs are configured and active as shown in the example.
The port priority configuration applies to all VLANs on this interface.
Note
The show spanning-tree interface command only displays information if the port is connected and
operating. If this condition is not met, enter a show running-config interface command to verify the
configuration.
This example shows how to configure the VLAN port priority of Gigabit Ethernet port 1/4:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/4
Router(config-if)# spanning-tree vlan 200 port-priority 64
Router(config-if)# end
Router#
The configuration entered in the example only applies to VLAN 200. All VLANs other than 200 still
have a port priority of 160.
This example shows how to verify the configuration:
Router# show spanning-tree interface gigabitethernet 1/4
Vlan
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------VLAN0001
Back BLK 200000
160.196 P2p
VLAN0006
Back BLK 200000
160.196 P2p
...
VLAN0199
Back BLK 200000
160.196 P2p
VLAN0200
Desg FWD 200000
64.196 P2p
Router#
You also can display spanning tree information for VLAN 200 using the following command:
Router# show spanning-tree vlan 200 interface gigabitethernet 1/4
Interface
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------Gi1/4
Desg LRN 200000
64.196 P2p
Configuring STP Port Cost
The STP port path cost default value is determined from the media speed of a LAN interface. If a loop
occurs, STP considers port cost when selecting a LAN interface to put into the forwarding state. You can
assign lower cost values to LAN interfaces that you want STP to select first and higher cost values to
LAN interfaces that you want STP to select last. If all LAN interfaces have the same cost value, STP
puts the LAN interface with the lowest LAN interface number in the forwarding state and blocks other
LAN interfaces. The possible cost range is 0 through 200000000 (the default is media specific).
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-32
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
STP uses the port cost value when the LAN interface is configured as an access port and uses VLAN
port cost values when the LAN interface is configured as a trunk port.
To configure the STP port cost of a Layer 2 LAN interface, perform this task:
Command
Purpose
Step 1
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel port_channel_number}}
Selects an interface to configure.
Step 2
Router(config-if)# spanning-tree cost port_cost
Configures the port cost for the LAN interface. The
port_cost value can be from 1 to 200000000.
Router(config-if)# no spanning-tree cost
Reverts to the default port cost.
Router(config-if)# spanning-tree vlan vlan_ID cost
port_cost
Configures the VLAN port cost for the LAN
interface. The port_cost value can be from 1 to
200000000. The vlan_ID value can be 1 through
4094, except reserved VLANs (see Table 16-1 on
page 16-3).
Router(config-if)# no spanning-tree vlan vlan_ID cost
Reverts to the default VLAN port cost.
Router(config-if)# end
Exits configuration mode.
Step 3
Step 4
This example shows how to change the STP port cost of Gigabit Ethernet port 1/4:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/4
Router(config-if)# spanning-tree cost 1000
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree interface gigabitethernet 1/4
Vlan
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------VLAN0001
Back BLK 1000
160.196 P2p
VLAN0006
Back BLK 1000
160.196 P2p
VLAN0007
Back BLK 1000
160.196 P2p
VLAN0008
Back BLK 1000
160.196 P2p
VLAN0009
Back BLK 1000
160.196 P2p
VLAN0010
Back BLK 1000
160.196 P2p
Router#
This example shows how to configure the port priority at an individual port VLAN cost for VLAN 200:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/4
Router(config-if)# spanning-tree vlan 200 cost 2000
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200 interface gigabitethernet 1/4
Interface
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------Gi1/4
Desg FWD 2000
64.196 P2p
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-33
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Note
In the following output other VLANs (VLAN 1 for example) have not been affected by this
configuration.
Router# show spanning-tree vlan 1 interface gigabitethernet 1/4
Interface
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------Gi1/4
Back BLK 1000
160.196 P2p
Router#
Note
The show spanning-tree command only displays information for ports that are in link-up operative state
and are appropriately configured for DTP. If these conditions are not met, you can enter a
show running-config command to confirm the configuration.
Configuring the Bridge Priority of a VLAN
Note
Be careful when using this command. For most situations, we recommend that you enter the
spanning-tree vlan vlan_ID root primary and the spanning-tree vlan vlan_ID root secondary
commands to modify the bridge priority.
To configure the STP bridge priority of a VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree vlan vlan_ID
priority {0 | 4096 | 8192 | 12288 | 16384 | 20480
| 24576 | 28672 | 32768 | 36864 | 40960 | 45056 |
49152 | 53248 | 57344 | 61440}
Configures the bridge priority of a VLAN when the
extended system ID is enabled. The vlan_ID value can be
1 through 4094, except reserved VLANs (see Table 16-1
on page 16-3).
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to configure the bridge priority of VLAN 200 to 33792 when the extended
system ID is disabled:
Router# configure terminal
Router(config)# spanning-tree vlan 200 priority 32768
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200 bridge
Hello Max Fwd
Vlan
Bridge ID
Time Age Delay
---------------- -------------------- ---- ---- ----VLAN200
32768 0050.3e8d.64c8
2
20
15
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-34
Protocol
-------ieee
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Configuring the Hello Time
Note
Be careful when using this command. For most situations, we recommend that you use the
spanning-tree vlan vlan_ID root primary and spanning-tree vlan vlan_ID root secondary commands
to modify the hello time.
To configure the STP hello time of a VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree vlan vlan_ID
hello-time hello_time
Configures the hello time of a VLAN. The hello_time
value can be from 1 to 10 seconds. The vlan_ID value can
be 1 through 4094, except reserved VLANs (see
Table 16-1 on page 16-3).
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to configure the hello time for VLAN 200 to 7 seconds:
Router# configure terminal
Router(config)# spanning-tree vlan 200 hello-time 7
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200 bridge
Hello Max Fwd
Vlan
Bridge ID
Time Age Delay
---------------- -------------------- ---- ---- ----VLAN200
49152 0050.3e8d.64c8
7
20
15
Router#
Protocol
-------ieee
Configuring the Forward-Delay Time for a VLAN
To configure the STP forward delay time for a VLAN, perform this task:
Step 1
Step 2
Command
Purpose
Router(config)# spanning-tree vlan vlan_ID
forward-time forward_time
Configures the forward time of a VLAN. The
forward_time value can be from 4 to 30 seconds. The
vlan_ID value can be 1 through 4094, except reserved
VLANs (see Table 16-1 on page 16-3).
Router(config)# no spanning-tree vlan vlan_ID
forward-time
Reverts to the default forward time.
Router(config)# end
Exits configuration mode.
This example shows how to configure the forward delay time for VLAN 200 to 21 seconds:
Router# configure terminal
Router(config)# spanning-tree vlan 200 forward-time 21
Router(config)# end
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-35
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200 bridge
Hello Max Fwd
Vlan
Bridge ID
Time Age Delay
---------------- -------------------- ---- ---- ----VLAN200
49152 0050.3e8d.64c8
2
20
21
Router#
Protocol
-------ieee
Configuring the Maximum Aging Time for a VLAN
To configure the STP maximum aging time for a VLAN, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree vlan vlan_ID
max-age max_age
Configures the maximum aging time of a VLAN. The
max_age value can be from 6 to 40 seconds. The vlan_ID
value can be 1 through 4094, except reserved VLANs (see
Table 16-1 on page 16-3).
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to configure the maximum aging time for VLAN 200 to 36 seconds:
Router# configure terminal
Router(config)# spanning-tree vlan 200 max-age 36
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show spanning-tree vlan 200 bridge
Hello Max Fwd
Vlan
Bridge ID
Time Age Delay
---------------- -------------------- ---- ---- ----VLAN200
49152 0050.3e8d.64c8
2
36
15
Router#
Protocol
-------ieee
Enabling Rapid-PVST+
Note
•
Rapid-PVST+ Overview, page 1-36
•
Specifying the Link Type, page 1-37
•
Restarting Protocol Migration, page 1-37
Rapid-PVST+ is enabled by default. Use the procedures to reenable Rapid-PVST+.
Rapid-PVST+ Overview
Rapid-PVST+ uses the existing PVST+ framework for configuration and interaction with other features.
It also supports some of the PVST+ extensions.
To enable Rapid-PVST+ mode on the switch, enter the spanning-tree mode rapid-pvst command in
privileged mode. To configure the switch in Rapid-PVST+ mode, see the “Configuring STP” section on
page 1-26.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-36
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Specifying the Link Type
Rapid connectivity is established only on point-to-point links. Spanning tree views a point-to-point link
as a segment connecting only two switches running the spanning tree algorithm. Because the switch
assumes that all full-duplex links are point-to-point links and that half-duplex links are shared links, you
can avoid explicitly configuring the link type. To configure a specific link type, enter the spanning-tree
linktype command.
Restarting Protocol Migration
A switch running both MSTP and RSTP supports a built-in protocol migration process that enables the
switch to interoperate with legacy 802.1D switches. If this switch receives a legacy 802.1D configuration
BPDU (a BPDU with the protocol version set to 0), it sends only 802.1D BPDUs on that port. An MSTP
switch can also detect that a port is at the boundary of a region when it receives a legacy BPDU, or an
MST BPDU (version 3) associated with a different region, or an RST BPDU (version 2).
However, the switch does not automatically revert to the MSTP mode if it no longer receives 802.1D
BPDUs because it cannot determine whether the legacy switch has been removed from the link unless
the legacy switch is the designated switch. A switch also might continue to assign a boundary role to a
port when the switch to which it is connected has joined the region.
To restart the protocol migration process (force the renegotiation with neighboring switches) on the
entire switch, you can use the clear spanning-tree detected-protocols privileged EXEC command. To
restart the protocol migration process on a specific interface, enter the clear spanning-tree
detected-protocols interface interface-id privileged EXEC command.
Configuring MST
•
Default MST Configuration, page 1-26
•
Specifying the MST Region Configuration and Enabling MST, page 1-38 (required)
•
Configuring the Root Bridge, page 1-39 (optional)
•
Configuring a Secondary Root Bridge, page 1-30 (optional)
•
Configuring STP Port Priority, page 1-31 (optional)
•
Configuring Path Cost, page 1-42 (optional)
•
Configuring the Switch Priority, page 1-43 (optional)
•
Configuring the Hello Time, page 1-44 (optional)
•
Configuring the Transmit Hold Count, page 1-45 (optional)
•
Configuring the Maximum-Aging Time, page 1-45 (optional)
•
Configuring the Maximum-Hop Count, page 1-46 (optional)
•
Specifying the Link Type to Ensure Rapid Transitions, page 1-46 (optional)
•
Designating the Neighbor Type, page 1-46 (optional)
•
Restarting the Protocol Migration Process, page 1-47 (optional)
•
Displaying the MST Configuration and Status, page 1-47
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-37
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Specifying the MST Region Configuration and Enabling MST
For two or more switches to be in the same MST region, they must have the same VLAN-to-instance
mapping, the same configuration revision number, and the same MST name.
A region can have one member or multiple members with the same MST configuration; each member
must be capable of processing RSTP BPDUs. There is no limit to the number of MST regions in a
network, but each region can only support up to 65 spanning tree instances. You can assign a VLAN to
only one spanning tree instance at a time.
To specify the MST region configuration and enable MST, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst configuration
Enters MST configuration mode.
Step 3
Router(config-mst)# instance instance_id vlan
vlan_range
Maps VLANs to an MST instance.
•
For instance_id, the range is 0 to 4094.
•
For vlan vlan_range, the range is 1 to 4094.
When you map VLANs to an MST instance, the
mapping is incremental, and the VLANs specified in
the command are added to or removed from the
VLANs that were previously mapped.
To specify a VLAN range, use a hyphen; for example,
instance 1 vlan 1-63 maps VLANs 1 through 63 to MST
instance 1.
To specify a VLAN series, use a comma; for example,
instance 1 vlan 10, 20, 30 maps VLANs 10, 20, and 30
to MST instance 1.
Step 4
Router(config-mst)# name instance_name
Specifies the instance name. The name string has a
maximum length of 32 characters and is case sensitive.
Step 5
Router(config-mst)# revision version
Specifies the configuration revision number. The range is
0 to 65535.
Step 6
Router(config-mst)# show pending
Verifies your configuration by displaying the pending
configuration.
Step 7
Router(config)# exit
Applies all changes, and return to global configuration
mode.
Step 8
Router(config)# spanning-tree mode mst
Enables MST and RSTP.
Caution
Changing the spanning tree mode can disrupt
traffic because all spanning tree instances are
stopped for the previous mode and restarted in
the new mode.
You cannot run both MST and rapid PVST+ at the same
time.
Step 9
Router(config)# end
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-38
Returns to privileged EXEC mode.
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
To return to defaults, do the following:
•
To return to the default MST region configuration, use the no spanning-tree mst configuration
global configuration command.
•
To return to the default VLAN-to-instance map, use the no instance instance_id [vlan vlan_range]
MST configuration command.
•
To return to the default name, use the no name MST configuration command.
•
To return to the default revision number, use the no revision MST configuration command.
This example shows how to enter MST configuration mode, map VLANs 10 to 20 to MST instance 1,
name the region region1, set the configuration revision to 1, display the pending configuration, apply the
changes, and return to global configuration mode:
Router(config)# spanning-tree mst configuration
Router(config-mst)# instance 1 vlan 10-20
Router(config-mst)# name region1
Router(config-mst)# revision 1
Router(config-mst)# show pending
Pending MST configuration
Name
[region1]
Revision 1
Instances configured 2
Instance Vlans Mapped
-------- --------------------0
1-9,21-4094
1
10-20
------------------------------Router(config-mst)# exit
Router(config)#
Configuring the Root Bridge
The switch maintains a spanning tree instance for the group of VLANs mapped to it. A switch ID,
consisting of the switch priority and the switch MAC address, is associated with each instance. For a
group of VLANs, the switch with the lowest switch ID becomes the root bridge.
To configure a switch to become the root bridge, use the spanning-tree mst instance_id root global
configuration command to modify the switch priority from the default value (32768) to a significantly
lower value so that the switch becomes the root bridge for the specified spanning tree instance. When
you enter this command, the switch checks the switch priorities of the root bridges. Because of extended
system ID support, the switch sets its own priority for the specified instance to 24576 if this value will
cause this switch to become the root bridge for the specified spanning tree instance.
If any root bridge for the specified instance has a switch priority lower than 24576, the switch sets its
own priority to 4096 less than the lowest switch priority. (4096 is the value of the least-significant bit of
a 4-bit switch priority value as shown in Table 1-1 on page 1-4.)
If your network consists of switches that both do and do not support the extended system ID, it is unlikely
that the switch with the extended system ID support will become the root bridge. The extended system
ID increases the switch priority value every time the VLAN number is greater than the priority of the
connected switches running older software.
The root bridge for each spanning tree instance should be a backbone or distribution switch. Do not
configure an access switch as the spanning tree primary root bridge.
Use the diameter keyword, which is available only for MST instance 0, to specify the Layer 2 network
diameter (that is, the maximum number of Layer 2 hops between any two end stations in the Layer 2
network). When you specify the network diameter, the switch automatically sets an optimal hello time,
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-39
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
forward-delay time, and maximum-age time for a network of that diameter, which can significantly
reduce the convergence time. You can use the hello keyword to override the automatically calculated
hello time.
Note
With the switch configured as the root bridge, do not manually configure the hello time, forward-delay
time, and maximum-age time with the spanning-tree mst hello-time, spanning-tree mst
forward-time, and spanning-tree mst max-age global configuration commands.
To configure a switch as the root bridge, perform this task:
Command
Purpose
Step 1
Router(config)# configure terminal
Enters global configuration mode.
Step 2
Router(config-config)# spanning-tree mst
instance_id root primary [diameter net_diameter
[hello-time seconds]]
(Optional) Configures a switch as the root bridge.
Step 3
Router(config-config)# end
•
For instance_id, you can specify a single instance, a
range of instances separated by a hyphen, or a series
of instances separated by a comma. The range is 0 to
4094.
•
(Optional) For diameter net_diameter, specify the
maximum number of Layer 2 hops between any two
end stations. The range is 2 to 7. This keyword is
available only for MST instance 0.
•
(Optional) For hello-time seconds, specify the
interval in seconds between the generation of
configuration messages by the root bridge. The range
is 1 to 10 seconds; the default is 2 seconds.
Returns to privileged EXEC mode.
Configuring a Secondary Root Bridge
When you configure a switch with the extended system ID support as the secondary root, the switch
priority is modified from the default value (32768) to 28672. The switch is then likely to become the root
bridge for the specified instance if the primary root bridge fails. This is assuming that the other network
switches use the default switch priority of 32768 and therefore are unlikely to become the root bridge.
You can execute this command on more than one switch to configure multiple backup root bridges. Use
the same network diameter and hello-time values that you used when you configured the primary root
bridge with the spanning-tree mst instance_id root primary global configuration command.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-40
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
To configure a switch as the secondary root bridge, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst instance_id
root secondary [diameter net_diameter [hello-time
seconds]]
(Optional) Configures a switch as the secondary root
bridge.
•
For instance_id, you can specify a single instance, a
range of instances separated by a hyphen, or a series
of instances separated by a comma. The range is 0 to
4094.
•
(Optional) For diameter net_diameter, specify the
maximum number of switches between any two end
stations. The range is 2 to 7. This keyword is
available only for MST instance 0.
•
(Optional) For hello-time seconds, specify the
interval in seconds between the generation of
configuration messages by the root bridge. The range
is 1 to 10 seconds; the default is 2 seconds.
Use the same network diameter and hello-time values
that you used when configuring the primary root bridge.
See the “Configuring the Root Bridge” section on
page 1-39.
Step 3
Router(config)# end
Returns to privileged EXEC mode.
Configuring Port Priority
If a loop occurs, MST uses the port priority when selecting an interface to put into the forwarding state.
You can assign higher priority values (lower numerical values) to interfaces that you want selected first
and lower priority values (higher numerical values) that you want selected last. If all interfaces have the
same priority value, MST puts the interface with the lowest interface number in the forwarding state and
blocks the other interfaces.
To configure the MST port priority of an interface, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel number}}
(Optional) Specifies an interface to configure, and
enters interface configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-41
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Step 3
Command
Purpose
Router(config-if)# spanning-tree mst instance_id
port-priority priority
Configures the port priority.
•
For instance_id, you can specify a single
instance, a range of instances separated by a
hyphen, or a series of instances separated by a
comma. The range is 0 to 4094.
•
For priority, the range is 0 to 240 in increments
of 16. The default is 128. The lower the
number, the higher the priority.
The priority values are 0, 16, 32, 48, 64, 80, 96,
112, 128, 144, 160, 176, 192, 208, 224, and
240. All other values are rejected.
Step 4
Router(config-if)# end
Note
Returns to privileged EXEC mode.
The show spanning-tree mst interface interface_id privileged EXEC command displays information
only if the port is in a link-up operative state. Otherwise, you can use the show running-config interface
privileged EXEC command to confirm the configuration.
Configuring Path Cost
The MST path cost default value is derived from the media speed of an interface. If a loop occurs, MST
uses cost when selecting an interface to put in the forwarding state. You can assign lower cost values to
interfaces that you want selected first and higher cost values that you want selected last. If all interfaces
have the same cost value, MST puts the interface with the lowest interface number in the forwarding state
and blocks the other interfaces.
To configure the MST cost of an interface, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel number}}
(Optional) Specifies an interface to configure, and
enters interface configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-42
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Step 3
Command
Purpose
Router(config-if)# spanning-tree mst instance_id cost
cost
Configures the cost.
If a loop occurs, MST uses the path cost when
selecting an interface to place into the forwarding
state. A lower path cost represents higher-speed
transmission.
Step 4
For instance_id, you can specify a single
instance, a range of instances separated by a
hyphen, or a series of instances separated by a
comma. The range is 0 to 4094.
•
For cost, the range is 1 to 200000000; the
default value is derived from the media speed of
the interface.
Returns to privileged EXEC mode.
Router(config-if)# end
Note
•
The show spanning-tree mst interface interface_id privileged EXEC command displays information
only for ports that are in a link-up operative state. Otherwise, you can use the show running-config
privileged EXEC command to confirm the configuration.
Configuring the Switch Priority
You can configure the switch priority so that it is more likely that a switch is chosen as the root bridge.
Note
Exercise care when using this command. For most situations, we recommend that you use the
spanning-tree mst instance_id root primary and the spanning-tree mst instance_id root secondary
global configuration commands to modify the switch priority.
To configure the switch priority, perform this task:
Step 1
Command
Purpose
Router# configure terminal
Enters global configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-43
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Step 2
Command
Purpose
Router(config)# spanning-tree mst instance_id
priority priority
(Optional) Configures the switch priority.
•
For instance_id, you can specify a single instance, a
range of instances separated by a hyphen, or a series
of instances separated by a comma. The range is 0 to
4094.
•
For priority, the range is 0 to 61440 in increments of
4096; the default is 32768. The lower the number, the
more likely the switch will be chosen as the root
bridge.
Priority values are 0, 4096, 8192, 12288, 16384,
20480, 24576, 28672, 32768, 36864, 40960, 45056,
49152, 53248, 57344, and 61440. All other values
are rejected.
Step 3
Router(config)# end
Returns to privileged EXEC mode.
Configuring the Hello Time
You can configure the interval between the generation of configuration messages by the root bridge by
changing the hello time.
Note
Exercise care when using this command. For most situations, we recommend that you use the
spanning-tree mst instance_id root primary and the spanning-tree mst instance_id root secondary
global configuration commands to modify the hello time.
To configure the hello time for all MST instances, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst hello-time
seconds
(Optional) Configures the hello time for all MST
instances. The hello time is the interval between the
generation of configuration messages by the root bridge.
These messages mean that the switch is alive.
For seconds, the range is 1 to 10; the default is 2.
Step 3
Router(config)# end
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-44
Returns to privileged EXEC mode.
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Configuring the Forwarding-Delay Time
To configure the forwarding-delay time for all MST instances, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst forward-time
seconds
(Optional) Configures the forward time for all MST
instances. The forward delay is the number of seconds a
port waits before changing from its spanning-tree
learning and listening states to the forwarding state.
For seconds, the range is 4 to 30; the default is 15.
Step 3
Returns to privileged EXEC mode.
Router(config)# end
Configuring the Transmit Hold Count
To configure the transmit hold count for all MST instances, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree transmit hold-count
hold_count_value
Configures the transmit hold count for all MST instances.
For hold_count_value, the range is 1 to 20; the default
is 6.
Step 3
Returns to privileged EXEC mode.
Router(config)# end
Configuring the Maximum-Aging Time
To configure the maximum-aging time for all MST instances, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst max-age seconds
(Optional) Configures the maximum-aging time for all
MST instances. The maximum-aging time is the number
of seconds a switch waits without receiving spanning-tree
configuration messages before attempting a
reconfiguration.
Step 3
Router(config)# end
For seconds, the range is 6 to 40; the default is 20.
Returns to privileged EXEC mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-45
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
Configuring the Maximum-Hop Count
To configure the maximum-hop count for all MST instances, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# spanning-tree mst max-hops
hop_count
(Optional) Specifies the number of hops in a region
before the BPDU is discarded, and the information held
for a port is aged.
For hop_count, the range is 1 to 255; the default is 20.
Step 3
Router(config)# end
Returns to privileged EXEC mode.
Specifying the Link Type to Ensure Rapid Transitions
If you connect a port to another port through a point-to-point link and the local port becomes a
designated port, the RSTP negotiates a rapid transition with the other port by using the
proposal-agreement handshake to ensure a loop-free topology as described in the “Rapid Convergence”
section on page 1-14.
By default, the link type is controlled from the duplex mode of the interface: a full-duplex port is
considered to have a point-to-point connection; a half-duplex port is considered to have a shared
connection. If you have a half-duplex link physically connected point-to-point to a single port on a
remote switch running MST, you can override the default setting of the link type and enable rapid
transitions to the forwarding state.
To override the default link-type setting, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel number}}
(Optional) Specifies an interface to configure, and
enters interface configuration mode.
Step 3
Router(config)# spanning-tree link-type point-to-point
Specifies that the link type of a port is
point-to-point.
Step 4
Router(config)# end
Returns to privileged EXEC mode.
Designating the Neighbor Type
A topology could contain both prestandard and 802.1s standard compliant devices. By default, ports can
automatically detect prestandard devices, but they can still receive both standard and prestandard
BPDUs. When there is a mismatch between a device and its neighbor, only the CIST runs on the
interface.
You can choose to set a port to send only prestandard BPDUs. The prestandard flag appears in all the
show commands, even if the port is in STP compatibility mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-46
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
To override the default link-type setting, perform this task:
Command
Purpose
Step 1
Router# configure terminal
Enters global configuration mode.
Step 2
Router(config)# interface
{{fastethernet | gigabitethernet | tengigabitethernet}
slot/port | {port-channel number}}
(Optional) Specifies an interface to configure, and
enters interface configuration mode.
Step 3
Router(config)# spanning-tree mst pre-standard
Specifies that the port can send only prestandard
BPDUs.
Step 4
Router(config)# end
Returns to privileged EXEC mode.
Restarting the Protocol Migration Process
A switch running MST supports a built-in protocol migration feature that enables it to interoperate with
802.1D switches. If this switch receives an 802.1D configuration BPDU (a BPDU with the protocol
version set to 0), it sends only 802.1D BPDUs on that port. An MST switch also can detect that a port is
at the boundary of a region when it receives an 802.1D BPDU, an MST BPDU (Version 3) associated
with a different region, or an RST BPDU (Version 2).
However, the switch does not automatically revert to the MST mode if it no longer receives 802.1D
BPDUs because it cannot detect whether the 802.1D switch has been removed from the link unless the
802.1D switch is the designated switch. A switch also might continue to assign a boundary role to a port
when the switch to which it is connected has joined the region.
To restart the protocol migration process (force the renegotiation with neighboring switches) on the
switch, use the clear spanning-tree detected-protocols privileged EXEC command.
To restart the protocol migration process on a specific interface, use the clear spanning-tree
detected-protocols interface interface_id privileged EXEC command.
Displaying the MST Configuration and Status
To display the spanning-tree status, use one or more of the privileged EXEC commands that are
described in Table 1-5.
Table 1-5
Commands for Displaying MST Status
Command
Purpose
show spanning-tree mst configuration
Displays the MST region configuration.
show spanning-tree mst configuration digest
Displays the MD5 digest included in the current MSTCI.
show spanning-tree mst instance_id
Displays MST information for the specified instance.
show spanning-tree mst interface interface_id
Displays MST information for the specified interface.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-47
Chapter 1
Spanning Tree Protocols
How to Configure Spanning Tree Protocols
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
1-48
CH AP TE R
2
Optional STP Features
Note
•
PortFast, page 2-2
•
Bridge Assurance, page 2-4
•
BPDU Guard, page 2-7
•
PortFast Edge BPDU Filtering, page 2-9
•
UplinkFast, page 2-11
•
BackboneFast, page 2-13
•
EtherChannel Guard, page 2-16
•
Root Guard, page 2-17
•
Loop Guard, page 2-17
•
PVST Simulation, page 2-20
•
Verifying the Optional STP Features, page 2-21
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
For information on configuring the Spanning Tree Protocol (STP), see Chapter 1, “Spanning Tree
Protocols.”
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-1
Chapter 2
Optional STP Features
PortFast
PortFast
•
Information about PortFast, page 2-2
•
Enabling PortFast, page 2-2
Information about PortFast
STP PortFast causes a Layer 2 LAN port configured as an access port to enter the forwarding state
immediately, bypassing the listening and learning states. You can use PortFast on Layer 2 access ports
connected to a single workstation or server to allow those devices to connect to the network immediately,
instead of waiting for STP to converge. Interfaces connected to a single workstation or server should not
receive bridge protocol data units (BPDUs). When configured for PortFast, a port is still running the
spanning tree protocol. A PortFast enabled port can immediately transition to the blocking state if
necessary (this could happen on receipt of a superior BPDU). PortFast can be enabled on trunk ports.
PortFast can have an operational value that is different from the configured value.
You can specifically configure a port as either an edge port, a network port, or a normal port. An edge
port, which is connected to a Layer 2 host, can be either an access port or a trunk port. A network port
is connected only to a Layer 2 switch or bridge.
Enabling PortFast
Tip
•
Configuring the PortFast Default State, page 2-2
•
Enabling PortFast on a Layer 2 Port, page 2-3
Configure STP BPDU Guard along with STP PortFast to shut down STP PortFast-enabled ports if they
receive a BPDU.
Configuring the PortFast Default State
To configure the default PortFast state, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree portfast [edge |
network | normal] default
Configures the default state for all switch access ports to
be edge, network, or normal. Bridge Assurance will be
enabled on all network access ports by default.
Step 2
Router(config)# end
Exits configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-2
Chapter 2
Optional STP Features
PortFast
Note
•
The default spanning tree port type is normal, meaning only that its topology is not specified.
•
If you configure a port connected to a Layer 2 switch or bridge as an edge port, you might create a
bridging loop.
•
If you mistakenly configure a port that is connected to a Layer 2 host as a spanning tree network
port, the port will automatically move into the blocking state.
This example shows how to configure the default switch access port state to be edge:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# spanning-tree portfast edge default
Enabling PortFast on a Layer 2 Port
•
Enabling PortFast on a Layer 2 Access Port, page 2-3
•
Enabling PortFast on a Layer 2 Network Port, page 2-4
Enabling PortFast on a Layer 2 Access Port
Caution
Enter the spanning-tree portfast edge [trunk] command only on ports that are connected to end host
devices that terminate VLANs and from which the port should never receive STP BPDUs, such as:
—Workstations.
—Servers.
—Ports on routers that are not configured to support bridging.
To enable PortFast on a Layer 2 access port, perform this task:
Command
Purpose
Step 1 Router(config)# interface {type slot/port} |
Selects a port to configure.
{port-channel port_channel_number}
Step 2 Router(config-if)# spanning-tree portfast edge [trunk] Enables edge behavior on a Layer 2 access port
connected to a single workstation or server. Enter the
trunk keyword if the link is a trunk.
Step 3 Router(config-if)# end
Exits configuration mode.
This example shows how to enable and verify PortFast on an interface:
Router# configure terminal
Router(config)# interface gigabitethernet 5/8
Router(config-if)# spanning-tree portfast edge
Router(config-if)# end
Router#
Router# show running-config interface gigabitethernet 5/8
Building configuration...
Current configuration:
!
interface GigabitEthernet5/8
no ip address
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-3
Chapter 2
Optional STP Features
Bridge Assurance
switchport
switchport access vlan 200
switchport mode access
spanning-tree portfast edge
end
Router#
Enabling PortFast on a Layer 2 Network Port
To enable PortFast on a Layer 2 network port, perform this task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port} |
{port-channel port_channel_number}
Selects a port to configure.
Step 2
Router(config-if)# spanning-tree portfast network
Configures the port as a network port. Bridge Assurance,
if enabled globally, will be enabled on the port.
Step 3
Router(config-if)# end
Exits configuration mode.
This example shows how to enable and verify PortFast on an interface:
Router# configure terminal
Router(config)# interface gigabitethernet 5/8
Router(config-if)# spanning-tree portfast edge
Router(config-if)# end
Router#
Router# show running-config interface gigabitethernet 5/8
Building configuration...
Current configuration:
!
interface GigabitEthernet5/8
no ip address
switchport
switchport access vlan 200
switchport mode access
spanning-tree portfast edge
end
Router#
Bridge Assurance
•
Information about Bridge Assurance, page 2-4
•
Enabling Bridge Assurance, page 2-7
Information about Bridge Assurance
You can use Bridge Assurance to protect against certain problems that can cause bridging loops in the
network. Specifically, you use Bridge Assurance to protect against a unidirectional link failure or other
software failure and a device that continues to forward data traffic when it is no longer running the
spanning tree algorithm.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-4
Optional STP Features
Bridge Assurance
Bridge Assurance is enabled by default and can only be disabled globally. Also, Bridge Assurance is
enabled only on spanning tree network ports that are point-to-point links. Finally, both ends of the link
must have Bridge Assurance enabled. If the device on one side of the link has Bridge Assurance enabled
and the device on the other side either does not support Bridge Assurance or does not have this feature
enabled, the connecting port is blocked.
With Bridge Assurance enabled, BPDUs are sent out on all operational network ports, including
alternate and backup ports, for each hello time period. If the port does not receive a BPDU for a specified
period, the port moves into an inconsistent state (blocking). and is not used in the root port calculation.
Once that port receives a BPDU, it resumes the normal spanning tree transitions.
Figure 2-1 shows a normal STP topology, and Figure 2-2 demonstrates a potential network problem when
the device fails and you are not running Bridge Assurance.
Figure 2-1
Root
Network with Normal STP Topology
Network
Network
Network
186525
Blocked
Edge
Figure 2-2
Root
Network Problem without Running Bridge Assurance
Loop
Malfunctioning
switch
X
BPDUs
Edge
186410
Chapter 2
Figure 2-3 shows the network with Bridge Assurance enabled, and the STP topology progressing
normally with bidirectional BPDUs issuing from every STP network port. Figure 2-4 shows how the
potential network problem shown in Figure 2-2 does not happen when you have Bridge Assurance
enabled on your network.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-5
Chapter 2
Optional STP Features
Bridge Assurance
Figure 2-3
Root
Network STP Topology Running Bridge Assurance
Network
Network
Network
186526
Blocked
Edge
Figure 2-4
Network Problem Averted with Bridge Assurance Enabled
Stopped receiving
BPDUs
Br1dge assurance
inconsistent
Network
X
Root
Malfunctioning
switch
BPDUs
Network
Network
Bridge assurance inconsistent
%STP-2-BRIDGE_ASSURANCE_BLOCK: Bridge Assurance blocking port Ethernet2/48 VLAN0700.
switch# sh spanning vl 700 | in -i bkn
Eth2/48
Altn BKN*4
128.304 Network P2p *BA_Inc
switch#
186411
Edge
Stopped receiving
BPDUs
When using Bridge Assurance, follow these guidelines:
•
Bridge Assurance runs only on point-to-point spanning tree network ports. You must configure each
side of the link for this feature.
•
We recommend that you enable Bridge Assurance throughout your network.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-6
Chapter 2
Optional STP Features
BPDU Guard
Enabling Bridge Assurance
By default, Bridge Assurance is enabled on all network ports on the switch. Disabling Bridge Assurance
causes all configured network ports to behave as normal spanning tree ports. To enable or disable Bridge
Assurance globally, perform this task:
Command
Purpose
Router(config)# spanning-tree bridge assurance
Enables Bridge Assurance on all network ports on the switch.
This example shows how to enable PortFast Bridge Assurance on all network ports on the switch, and
how to configure a network port:
Router(config)# spanning-tree bridge assurance
Router(config)# interface gigabitethernet 5/8
Router(config-if)# spanning-tree portfast network
Router(config-if)# exit
BPDU Guard
•
Information about BPDU Guard, page 2-7
•
Enabling BPDU Guard, page 2-7
Information about BPDU Guard
When enabled on a port, BPDU Guard shuts down a port that receives a BPDU. When configured
globally, BPDU Guard is only effective on ports in the operational PortFast (edge) state. In a valid
configuration, PortFast Layer 2 LAN interfaces (edge ports) do not receive BPDUs. Reception of a
BPDU by a PortFast Layer 2 LAN interface signals an invalid configuration, such as connection of an
unauthorized device. BPDU Guard provides a secure response to invalid configurations, because the
administrator must manually put the Layer 2 LAN interface back in service. BPDU Guard can be
configured at the interface level. When configured at the interface level, BPDU Guard shuts the port
down as soon as the port receives a BPDU, regardless of the PortFast configuration.
Note
When enabled globally, BPDU Guard applies to all interfaces that are in an operational PortFast (edge)
state.
Enabling BPDU Guard
•
Enabling BPDU Guard Globally, page 2-8
•
Enabling BPDU Guard on a Port, page 2-8
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-7
Chapter 2
Optional STP Features
BPDU Guard
Enabling BPDU Guard Globally
To enable BPDU Guard globally, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree portfast edge bpduguard default
Enables BPDU Guard globally by default
on all edge ports of the switch.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to enable BPDU Guard:
Router# configure terminal
Router(config)# spanning-tree portfast edge bpduguard default
Router(config)# end
This example shows how to verify the configuration:
Router# show spanning-tree summary totals
Root bridge for: Bridge VLAN0025
EtherChannel misconfiguration guard is enabled
Extended system ID
is enabled
PortFast Edge BPDU Guard Default
is enabled
Portfast Edge BPDU Filter Default
is disabled
Portfast Default
is edge
Bridge Assurance
is enabled
Loopguard
is disabled
UplinkFast
is disabled
BackboneFast
is disabled
Pathcost method used is long
Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------2 vlans
0
0
0
3
3
Enabling BPDU Guard on a Port
To enable BPDU Guard on a port, perform this task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port} |
{port-channel port_channel_number}
Selects a port to configure.
Step 2
Router(config-if)# spanning-tree bpduguard enable
Enables BPDU Guard on the port.
Step 3
Router(config-if)# end
Exits configuration mode.
This example shows how to enable BPDU Guard:
Router# configure terminal
Router(config)# spanning-tree portfast edge bpduguard default
Router(config)# end
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-8
Chapter 2
Optional STP Features
PortFast Edge BPDU Filtering
PortFast Edge BPDU Filtering
•
Information about PortFast Edge BPDU Filtering, page 2-9
•
Enabling PortFast Edge BPDU Filtering, page 2-10
Information about PortFast Edge BPDU Filtering
PortFast edge BPDU filtering allows the administrator to prevent the system from sending or even
receiving BPDUs on specified ports.
When configured globally, PortFast edge BPDU filtering applies to all operational PortFast (edge) ports.
Ports in an operational PortFast state are supposed to be connected to hosts, which typically drop
BPDUs. If an operational PortFast port receives a BPDU, it immediately loses its operational PortFast
status and becomes a normal port. In that case, PortFast edge BPDU filtering is disabled on this port and
STP resumes sending BPDUs on this port.
PortFast edge BPDU filtering can also be configured on a per-port basis. When PortFast edge BPDU
filtering is explicitly configured on a port, it does not send any BPDUs and drops all BPDUs it receives.
Caution
Explicitly configuring PortFast edge BPDU filtering on a port that is not connected to a host can result
in bridging loops, as the port will ignore any BPDU it receives and will go to a forwarding state.
When you enable PortFast edge BPDU filtering globally and set the port configuration as the default for
PortFast edge BPDU filtering (see the “Enabling PortFast Edge BPDU Filtering” section on page 2-10),
then PortFast enables or disables PortFast edge BPDU filtering.
If the port configuration is not set to default, then the PortFast configuration will not affect PortFast edge
BPDU filtering. Table 2-1 lists all the possible PortFast edge BPDU filtering combinations. PortFast
edge BPDU filtering allows access ports to move directly to the forwarding state as soon as the end hosts
are connected.
Table 2-1
PortFast Edge BPDU Filtering Port Configurations
Per-Port Configuration Global Configuration PortFast State
PortFast BPDU Filtering State
Default
Enable
Enable
Enable
Note
Default
Enable
Disable
Default
Disable
Not applicable Disable
Disable
Not applicable
Not applicable Disable
Enable
Not applicable
Not applicable Enable
The port transmits at least 10 BPDUs. If this port
receives any BPDUs, then PortFast and PortFast edge
BPDU filtering are disabled.
Disable
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-9
Chapter 2
Optional STP Features
PortFast Edge BPDU Filtering
Enabling PortFast Edge BPDU Filtering
•
Enabling PortFast Edge BPDU Filtering Globally, page 2-10
•
Enabling PortFast Edge BPDU Filtering on a Nontrunking Port, page 2-11
Enabling PortFast Edge BPDU Filtering Globally
To enable PortFast edge BPDU filtering globally, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree portfast edge
bpdufilter default
Enables BPDU filtering globally by default on all edge ports
of the switch. Use the no prefix to disable BPDU filtering by
default on all edge ports of the switch.
Step 2
Router(config)# end
Exits configuration mode.
BPDU filtering is set to default on each edge port. This example shows how to enable PortFast edge
BPDU filtering on the port and verify the configuration in PVST+ mode:
Router(config)# spanning-tree portfast edge bpdufilter default
Router(config)# exit
Router# show spanning-tree summary totals
Root bridge for: Bridge VLAN0025
EtherChannel misconfiguration guard is enabled
Extended system ID
is enabled
PortFast Edge BPDU Guard Default
is disabled
Portfast Edge BPDU Filter Default
is enabled
Portfast Default
is edge
Bridge Assurance
is enabled
Loopguard
is disabled
UplinkFast
is disabled
BackboneFast
is disabled
Pathcost method used is long
Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------2 vlans
0
0
0
3
3
Router#
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-10
Chapter 2
Optional STP Features
UplinkFast
Enabling PortFast Edge BPDU Filtering on a Nontrunking Port
To enable or disable PortFast edge BPDU filtering on a nontrunking port, perform this task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port}
Selects the interface to configure.
Step 2
Router(config-if)# spanning-tree bpdufilter
[enable | disable]
Enables or disables BPDU filtering on the port.
Step 3
Router(config-if)# end
Exits configuration mode.
This example shows how to enable PortFast edge BPDU filtering on a nontrunking port:
Router(config)# interface gigabitethernet 4/4
Router(config-if)# spanning-tree bpdufilter enable
Router(config-if)# ^Z
Router# show spanning-tree interface gigabitethernet 4/4
Vlan
Role Sts Cost
Prio.Nbr Status
---------------- ---- --- --------- -------- -------------------------------VLAN0010
Desg FWD 1000
160.196 Edge P2p
Router# show spanning-tree interface gigabitethernet 4/4 detail
Port 196 (GigabitEthernet4/4) of VLAN0010 is forwarding
Port path cost 1000, Port priority 160, Port Identifier 160.196.
Designated root has priority 32768, address 00d0.00b8.140a
Designated bridge has priority 32768, address 00d0.00b8.140a
Designated port id is 160.196, designated path cost 0
Timers:message age 0, forward delay 0, hold 0
Number of transitions to forwarding state:1
The port is in the portfast mode by portfast trunk configuration
Link type is point-to-point by default
Bpdu filter is enabled
BPDU:sent 0, received 0
Router#
UplinkFast
•
Information about UplinkFast, page 2-11
•
Enabling UplinkFast, page 2-12
Information about UplinkFast
UplinkFast provides fast convergence after a direct link failure and achieves load balancing between
redundant Layer 2 links using uplink groups. An uplink group is a set of Layer 2 LAN interfaces (per
VLAN), only one of which is forwarding at any given time. Specifically, an uplink group consists of the
root port (which is forwarding) and a set of blocked ports, except for self-looping ports. The uplink group
provides an alternate path in case the currently forwarding link fails.
Note
UplinkFast is most useful in wiring-closet switches. This feature may not be useful for other types of
applications.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-11
Chapter 2
Optional STP Features
UplinkFast
Figure 2-5 shows an example topology with no link failures. Switch A, the root bridge, is connected
directly to Switch B over link L1 and to Switch C over link L2. The Layer 2 LAN interface on Switch C
that is connected directly to Switch B is in the blocking state.
Figure 2-5
UplinkFast Example Before Direct Link Failure
Switch A
(Root)
Switch B
L1
L2
L3
11241
Blocked port
Switch C
If Switch C detects a link failure on the currently active link L2 on the root port (a direct link failure),
UplinkFast unblocks the blocked port on Switch C and transitions it to the forwarding state without
going through the listening and learning states, as shown in Figure 2-6. This switchover takes
approximately one to five seconds.
Figure 2-6
UplinkFast Example After Direct Link Failure
Switch A
(Root)
Switch B
L1
L2
L3
Link failure
Switch C
11242
UplinkFast transitions port
directly to forwarding state
Enabling UplinkFast
UplinkFast increases the bridge priority to 49152 and adds 3000 to the STP port cost of all Layer 2 LAN
ports on the switch, decreasing the probability that the switch will become the root bridge. UplinkFast
cannot be enabled on VLANs that have been configured for bridge priority. To enable UplinkFast on a
VLAN with bridge priority configured, restore the bridge priority on the VLAN to the default value by
entering a no spanning-tree vlan vlan_ID priority command in global configuration mode.
Note
When you enable UplinkFast, it affects all VLANs on the switch. You cannot configure UplinkFast on
an individual VLAN.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-12
Chapter 2
Optional STP Features
BackboneFast
To enable UplinkFast, perform this task:
Step 1
Step 2
Command
Purpose
Router(config)# spanning-tree uplinkfast
Router(config)# spanning-tree uplinkfast
[max-update-rate max_update_rate]
Enables UplinkFast.
Router(config)# end
Exits configuration mode.
Enables UplinkFast with an update rate in seconds.
This example shows how to enable UplinkFast:
Router# configure terminal
Router(config)# spanning-tree uplinkfast
Router(config)# exit
This example shows how to enable UplinkFast with an update rate of 400 packets per second:
Router# configure terminal
Router(config)# spanning-tree uplinkfast
Router(config)# spanning-tree uplinkfast max-update-rate 400
Router(config)# exit
This example shows how to verify that UplinkFast is enabled:
Router# show spanning-tree uplinkfast
UplinkFast is enabled
BackboneFast
•
Information about BackboneFast, page 2-13
•
Enabling BackboneFast, page 2-15
Information about BackboneFast
BackboneFast is initiated when a root port or blocked port on a network device receives inferior BPDUs
from its designated bridge. An inferior BPDU identifies one network device as both the root bridge and
the designated bridge. When a network device receives an inferior BPDU, it indicates that a link to which
the network device is not directly connected (an indirect link) has failed (that is, the designated bridge
has lost its connection to the root bridge). Under normal STP rules, the network device ignores inferior
BPDUs for the configured maximum aging time, as specified by the STP max-age command.
The network device tries to determine if it has an alternate path to the root bridge. If the inferior BPDU
arrives on a blocked port, the root port and other blocked ports on the network device become alternate
paths to the root bridge. (Self-looped ports are not considered alternate paths to the root bridge.) If the
inferior BPDU arrives on the root port, all blocked ports become alternate paths to the root bridge. If the
inferior BPDU arrives on the root port and there are no blocked ports, the network device assumes that
it has lost connectivity to the root bridge, causes the maximum aging time on the root to expire, and
becomes the root bridge according to normal STP rules.
If the network device has alternate paths to the root bridge, it uses these alternate paths to transmit a new
kind of Protocol Data Unit (PDU) called the Root Link Query PDU. The network device sends the Root
Link Query PDU out all alternate paths to the root bridge. If the network device determines that it still
has an alternate path to the root, it causes the maximum aging time to expire on the ports on which it
received the inferior BPDU. If all the alternate paths to the root bridge indicate that the network device
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-13
Chapter 2
Optional STP Features
BackboneFast
has lost connectivity to the root bridge, the network device causes the maximum aging times on the ports
on which it received an inferior BPDU to expire. If one or more alternate paths can still connect to the
root bridge, the network device makes all ports on which it received an inferior BPDU its designated
ports and moves them out of the blocking state (if they were in the blocking state), through the listening
and learning states, and into the forwarding state.
Figure 2-7 shows an example topology with no link failures. Switch A, the root bridge, connects directly
to Switch B over link L1 and to Switch C over link L2. The Layer 2 LAN interface on Switch C that
connects directly to Switch B is in the blocking state.
Figure 2-7
BackboneFast Example Before Indirect Link Failure
Switch A
(Root)
Switch B
L1
L2
L3
11241
Blocked port
Switch C
If link L1 fails, Switch C cannot detect this failure because it is not connected directly to link L1.
However, because Switch B is directly connected to the root bridge over L1, it detects the failure and
elects itself the root and begins sending BPDUs to Switch C indicating itself as the root. When Switch C
receives the inferior BPDUs from Switch B, Switch C infers that an indirect failure has occurred. At that
point, BackboneFast allows the blocked port on Switch C to move immediately to the listening state
without waiting for the maximum aging time for the port to expire. BackboneFast then transitions the
Layer 2 LAN interface on Switch C to the forwarding state, providing a path from Switch B to Switch A.
This switchover takes approximately 30 seconds, twice the Forward Delay time if the default Forward
Delay time of 15 seconds is set. Figure 2-8 shows how BackboneFast reconfigures the topology to
account for the failure of link L1.
Figure 2-8
BackboneFast Example After Indirect Link Failure
Switch A
(Root)
Switch B
L1
Link failure
L3
BackboneFast transitions port
through listening and learning
states to forwarding state
Switch C
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-14
11244
L2
Chapter 2
Optional STP Features
BackboneFast
If a new network device is introduced into a shared-medium topology as shown in Figure 2-9,
BackboneFast is not activated because the inferior BPDUs did not come from the recognized designated
bridge (Switch B). The new network device begins sending inferior BPDUs that indicate that it is the
root bridge. However, the other network devices ignore these inferior BPDUs and the new network
device learns that Switch B is the designated bridge to Switch A, the root bridge.
Figure 2-9
Adding a Network Device in a Shared-Medium Topology
Switch A
(Root)
Switch B
(Designated Bridge)
Switch C
Blocked port
11245
Added switch
Enabling BackboneFast
Note
BackboneFast operates correctly only when enabled on all network devices in the network.
BackboneFast is not supported on Token Ring VLANs. This feature is supported for use with third-party
network devices.
To enable BackboneFast, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree backbonefast
Enables BackboneFast.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to enable BackboneFast:
Router# configure terminal
Router(config)# spanning-tree backbonefast
Router(config)# end
This example shows how to verify that BackboneFast is enabled:
Router# show spanning-tree backbonefast
BackboneFast is enabled
BackboneFast statistics
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-15
Chapter 2
Optional STP Features
EtherChannel Guard
----------------------Number of transition via backboneFast (all VLANs)
Number of inferior BPDUs received (all VLANs)
Number of RLQ request PDUs received (all VLANs)
Number of RLQ response PDUs received (all VLANs)
Number of RLQ request PDUs sent (all VLANs)
Number of RLQ response PDUs sent (all VLANs)
:
:
:
:
:
:
0
0
0
0
0
0
EtherChannel Guard
•
Information about EtherChannel Guard, page 2-16
•
Enabling EtherChannel Guard, page 2-16
Information about EtherChannel Guard
EtherChannel guard detects a misconfigured EtherChannel when interfaces on the switch are configured
as an EtherChannel while interfaces on the other device are not or when not all the interfaces on the other
device are in the same EtherChannel.
In response to misconfiguration detected on the other device, EtherChannel guard puts interfaces on the
switch into the errdisabled state.
Enabling EtherChannel Guard
To enable EtherChannel guard, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree etherchannel guard
misconfig
Enables EtherChannel guard.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to enable EtherChannel guard:
Router# configure terminal
Router(config)# spanning-tree etherchannel guard misconfig
Router(config)# end
This example shows how to verify the configuration:
Router# show spanning-tree summary | include EtherChannel
EtherChannel misconfiguration guard is enabled
To display the interfaces that are in the errdisable state, enter the show interface status err-disable
command.
After the misconfiguration has been cleared, interfaces in the errdisable state might automatically
recover. To manually return a port to service, enter a shutdown and then a no shutdown command for
the interface.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-16
Chapter 2
Optional STP Features
Root Guard
Root Guard
•
Information about Root Guard, page 2-17
•
Enabling Root Guard, page 2-17
Information about Root Guard
The STP root guard feature prevents a port from becoming root port or blocked port. If a port configured
for root guard receives a superior BPDU, the port immediately goes to the root-inconsistent (blocked)
state.
Enabling Root Guard
To enable root guard, perform this task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port} |
{port-channel port_channel_number}
Selects a port to configure.
Step 2
Router(config-if)# spanning-tree guard root
Enables root guard.
Step 3
Router(config-if)# end
Exits configuration mode.
To display ports that are in the root-inconsistent state, enter the show spanning-tree inconsistentports
command.
Loop Guard
•
Information about Loop Guard, page 2-17
•
Enabling Loop Guard, page 2-19
Information about Loop Guard
Loop guard helps prevent bridging loops that could occur because of a unidirectional link failure on a
point-to-point link. When enabled globally, the loop guard applies to all point-to-point ports on the
system. Loop guard detects root ports and blocked ports and ensures that they keep receiving BPDUs
from their designated port on the segment. If a loop guard enabled root or blocked port stop a receiving
BPDUs from its designated port, it transitions to the loop-inconsistent blocking state, assuming there is
a physical link error on this port. The port recovers from this loop-inconsistent state as soon as it receives
a BPDU.
You can enable loop guard on a per-port basis. When you enable loop guard, it is automatically applied
to all of the active instances or VLANs to which that port belongs. When you disable loop guard, it is
disabled for the specified ports. Disabling loop guard moves all loop-inconsistent ports to the listening
state.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-17
Chapter 2
Optional STP Features
Loop Guard
If you enable loop guard on a channel and the first link becomes unidirectional, loop guard blocks the
entire channel until the affected port is removed from the channel. Figure 2-10 shows loop guard in a
triangle switch configuration.
Figure 2-10
Triangle Switch Configuration with Loop Guard
A
B
3/1
3/1
3/2
3/2
3/1
3/2
C
Root port
Alternate port
55772
Designated port
Figure 2-10 illustrates the following configuration:
•
Switches A and B are distribution switches.
•
Switch C is an access switch.
•
Loop guard is enabled on ports 3/1 and 3/2 on Switches A, B, and C.
Enabling loop guard on a root switch has no effect but provides protection when a root switch becomes
a nonroot switch.
When using loop guard, follow these guidelines:
•
You cannot enable loop guard on PortFast-enabled ports.
•
You cannot enable loop guard if root guard is enabled.
Loop guard interacts with other features as follows:
•
Loop guard does not affect the functionality of UplinkFast or BackboneFast.
•
Enabling loop guard on ports that are not connected to a point-to-point link will not work.
•
Root guard forces a port to be always designated as the root port. Loop guard is effective only if the
port is a root port or an alternate port. You cannot enable loop guard and root guard on a port at the
same time.
•
Loop guard uses the ports known to spanning tree. Loop guard can take advantage of logical ports
provided by the Port Aggregation Protocol (PAgP). However, to form a channel, all the physical
ports grouped in the channel must have compatible configurations. PAgP enforces uniform
configurations of root guard or loop guard on all the physical ports to form a channel.
These caveats apply to loop guard:
– Spanning tree always chooses the first operational port in the channel to send the BPDUs. If that
link becomes unidirectional, loop guard blocks the channel, even if other links in the channel
are functioning properly.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-18
Chapter 2
Optional STP Features
Loop Guard
– If a set of ports that are already blocked by loop guard are grouped together to form a channel,
spanning tree loses all the state information for those ports and the new channel port may obtain
the forwarding state with a designated role.
– If a channel is blocked by loop guard and the channel breaks, spanning tree loses all the state
information. The individual physical ports may obtain the forwarding state with the designated
role, even if one or more of the links that formed the channel are unidirectional.
Note
•
You can enable UniDirectional Link Detection (UDLD) to help isolate the link failure.
A loop may occur until UDLD detects the failure, but loop guard will not be able to
detect it.
Loop guard has no effect on a disabled spanning tree instance or a VLAN.
Enabling Loop Guard
To enable loop guard globally on the switch, perform this task:
Command
Purpose
Step 1
Router(config)# spanning-tree loopguard default
Enables loop guard globally on the switch.
Step 2
Router(config)# end
Exits configuration mode.
This example shows how to enable loop guard globally:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# spanning-tree loopguard default
Router(config)# exit
Router# show spanning-tree interface gigabitethernet 4/4 detail
Port 196 (GigabitEthernet4/4) of VLAN0010 is forwarding
Port path cost 1000, Port priority 160, Port Identifier 160.196.
Designated root has priority 32768, address 00d0.00b8.140a
Designated bridge has priority 32768, address 00d0.00b8.140a
Designated port id is 160.196, designated path cost 0
Timers:message age 0, forward delay 0, hold 0
Number of transitions to forwarding state:1
The port is in the portfast mode by portfast trunk configuration
Link type is point-to-point by default
Bpdu filter is enabled
Loop guard is enabled by default on the port
BPDU:sent 0, received 0
To enable loop guard on a port, perform this task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port} |
{port-channel port_channel_number}
Selects a port to configure.
Step 2
Router(config-if)# spanning-tree guard loop
Configures loop guard.
Step 3
Router(config)# end
Exits configuration mode.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-19
Chapter 2
Optional STP Features
PVST Simulation
This example shows how to enable loop guard:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 4/4
Router(config-if)# spanning-tree guard loop
Router(config-if)# exit
This example shows how to verify the configuration:
Router# show spanning-tree interface gigabitethernet 4/4 detail
Port 196 (GigabitEthernet4/4) of VLAN0010 is forwarding
Port path cost 1000, Port priority 160, Port Identifier 160.196.
Designated root has priority 32768, address 00d0.00b8.140a
Designated bridge has priority 32768, address 00d0.00b8.140a
Designated port id is 160.196, designated path cost 0
Timers:message age 0, forward delay 0, hold 0
Number of transitions to forwarding state:1
The port is in the portfast mode by portfast trunk configuration
Link type is point-to-point by default
Bpdu filter is enabled
Loop guard is enabled on the port
BPDU:sent 0, received 0
PVST Simulation
•
Information about PVST Simulation, page 2-20
•
Configuring PVST Simulation, page 2-21
Information about PVST Simulation
MST interoperates with Rapid PVST+ with no need for user configuration. The PVST simulation feature
enables this seamless interoperability.
Note
PVST simulation is enabled by default when you enable MST. That is, by default, all interfaces on the
device interoperate between MST and Rapid PVST+.
You may want to control the connection between MST and Rapid PVST+ to protect against accidentally
connecting an MST-enabled port to a port enabled to run Rapid PVST+. Because Rapid PVST+ is the
default STP mode, you may encounter many Rapid PVST+ connections.
Disabling Rapid PVST+ simulation, which can be done per port or globally for the entire device, moves
the MST-enabled port to the PVST peer inconsistent (blocking) state once it detects it is connected to a
Rapid PVST+-enabled port. This port remains in the inconsistent state until the port stops receiving
Shared Spanning Tree Protocol (SSTP) BPDUs, and then the port resumes the normal STP transition
process.
The root bridge for all STP instances must all be in either the MST region or the Rapid PVST+ side. If
the root bridge for all STP instances are not on one side or the other, the software moves the port into a
PVST simulation-inconsistent state.
Note
We recommend that you put the root bridge for all STP instances in the MST region.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-20
Chapter 2
Optional STP Features
Verifying the Optional STP Features
Configuring PVST Simulation
Note
PVST simulation is enabled by default so that all interfaces on the device interoperate between MST and
Rapid PVST+.
To prevent an accidental connection to a device that does not run MST as the default STP mode, you can
disable PVST simulation. If you disable PVST simulation, the MST-enabled port moves to the blocking
state once it detects it is connected to a Rapid PVST+-enabled port. This port remains in the inconsistent
state until the port stops receiving BPDUs, and then the port resumes the normal STP transition process.
To enable or disable PVST simulation globally, enter the command using the global keyword, as shown
in the following task:
Command
Purpose
Router(config)# spanning-tree mst simulate pvst
global
Enables all ports to automatically interoperate with a
connected device that is running in Rapid PVST+ mode. The
default is enabled; all interfaces will operate seamlessly
between Rapid PVST+ and MST.
To override the global PVST simulation setting for a port, enter the command in the interface command
mode, as shown in the following task:
Command
Purpose
Step 1
Router(config)# interface {type slot/port}
Selects a port to configure.
Step 2
Router(config-if)# spanning-tree mst simulate pvst
Enables this interface to automatically interoperate with a
connected device that is running in Rapid PVST+ mode.
This example shows how to prevent the switch from automatically interoperating with a connecting
device that is running Rapid PVST+:
Router(config)# no spanning-tree mst simulate pvst global
This example shows how to prevent a port from automatically interoperating with a connecting device
that is running Rapid PVST+:
Router(config)# interface gi3/13
Router(config-if)# spanning-tree mst simulate pvst disable
Verifying the Optional STP Features
•
Using the show spanning-tree Commands, page 2-22
•
Examples of the show spanning-tree Commands, page 2-22
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-21
Chapter 2
Optional STP Features
Verifying the Optional STP Features
Using the show spanning-tree Commands
You can view spanning tree status and configuration information, both global and port-level, using the
show spanning-tree commands described in this section. To view spanning tree status and configuration
information, enter one of the following commands:
Command
Purpose
Router# show spanning-tree
Displays information about the spanning
tree, including protocol type and port types.
Router# show spanning-tree summary
Displays a summary of the spanning tree
feature settings and the spanning tree states
of the VLANs.
Router# show spanning-tree summary totals
Displays a summary of the spanning tree
feature settings and totals of the VLAN
states.
Router# show spanning-tree interface {type slot/port} detail
Displays the spanning tree status details of
an interface.
Router# show spanning-tree interface {type slot/port} portfast edge
Displays the spanning tree portfast edge
interface operational state for all the
instances.
Examples of the show spanning-tree Commands
This example displays the spanning-tree status with Bridge Assurance enabled but in the inconsistent
state:
Router# show spanning-tree
VLAN0010
Spanning tree enabled protocol rstp
Root ID
Priority
32778
Address
0002.172c.f400
This bridge is the root
Hello Time
2 sec Max Age 20 sec
Bridge ID
Forward Delay 15 sec
Priority
32778 (priority 32768 sys-id-ext 10)
Address
0002.172c.f400
Hello Time
2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface
Role Sts Cost
Prio.Nbr Type
---------------- ---- --- --------- -------- -------------------------------Gi3/14
Desg BKN*4
128.270 Network, P2p *BA_Inc
Router#
The following inconsistency messages can be appended to the Type field:
•
*BA_Inc—Indicates that Bridge Assurance is in the inconsistent state.
•
*PVST_Peer_Inc—Indicates that the port is in a peer type Inconsistent state.
•
Dispute—Indicates that a dispute condition is detected.
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-22
Chapter 2
Optional STP Features
Verifying the Optional STP Features
This example shows the spanning-tree configuration summary:
Router# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: Bridge VLAN0025
EtherChannel misconfiguration guard
Extended system ID
PortFast Edge BPDU Guard Default
Portfast Edge BPDU Filter Default
Portfast Default
Bridge Assurance
Loopguard
UplinkFast
BackboneFast
Pathcost method used is short
PVST Simulation Default
is
is
is
is
is
is
is
is
is
enabled
enabled
disabled
disabled
edge
enabled
disabled
disabled
disabled
is enabled
Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------VLAN0025
0
0
0
1
1
VLAN0030
0
0
0
2
2
---------------------- -------- --------- -------- ---------- ---------2 vlans
0
0
0
3
3
Possible states for the Bridge Assurance field are as follows:
•
is enabled
•
is disabled
•
is enabled but not active in the PVST mode
This example shows the spanning tree summary when PVST simulation is disabled in any STP mode:
Router# show spanning-tree summary
Switch is in mst mode (IEEE Standard)
Root bridge for: MST0
EtherChannel misconfig guard is enabled
Extended system ID
is enabled
Portfast Default
is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default
is disabled
UplinkFast
is disabled
BackboneFast
is disabled
Pathcost method used
is long
PVST Simulation Default
is disabled
Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------MST0
2
0
0
0
2
---------------------- -------- --------- -------- ---------- ---------1 mst
2
0
0
0
2
Possible states for the PVST Simulation Default field are as follows:
•
is enabled
•
is disabled
•
is enabled but not active in rapid-PVST mode
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-23
Chapter 2
Optional STP Features
Verifying the Optional STP Features
This example shows the spanning tree summary totals:
Router# show spanning-tree summary totals
Root bridge for: Bridge VLAN0025
EtherChannel misconfiguration guard is enabled
Extended system ID
is enabled
PortFast Edge BPDU Guard Default
is enabled
Portfast Edge BPDU Filter Default
is disabled
Portfast Default
is edge
Bridge Assurance
is enabled
Loopguard
is disabled
UplinkFast
is disabled
BackboneFast
is disabled
Pathcost method used is long
Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------2 vlans
0
0
0
3
3
Router#
This example shows the spanning-tree configuration details of an edge port:
Router# show spanning-tree interface gi3/13 detail
Port 269 (GigabitEthernet3/13) of VLAN0002 is forwarding
Port path cost 4, Port priority 128, Port Identifier 128.269.
Designated root has priority 32770, address 0002.172c.f400
Designated bridge has priority 32770, address 0002.172c.f400
Designated port id is 128.269, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
Loop guard is enabled by default on the port
The port is in the portfast edge mode by default
BPDU: sent 2183, received 0
This example shows the spanning-tree configuration details of a trunk port:
Router(config-if)# spanning-tree portfast edge trunk
%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
Router(config-if)# exit
Router# show spanning-tree interface gi3/13 detail
Port 269 (GigabitEthernet3/13) of VLAN0002 is forwarding
Port path cost 4, Port priority 128, Port Identifier 128.269.
Designated root has priority 32770, address 0002.172c.f400
Designated bridge has priority 32770, address 0002.172c.f400
Designated port id is 128.269, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
Loop guard is enabled by default on the port
The port is in the portfast edge trunk mode
BPDU: sent 2183, received 0
This example shows the spanning-tree configuration details of an edge port when a dispute condition has
been detected:
Router# show spanning-tree interface gi3/13 detail
Port 269 (GigabitEthernet3/13) of VLAN0002 is designated blocking (dispute)
Port path cost 4, Port priority 128, Port Identifier 128.297.
Designated root has priority 32769, address 0013.5f20.01c0
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-24
Chapter 2
Optional STP Features
Verifying the Optional STP Features
Designated bridge has priority 32769, address 0013.5f20.01c0
Designated port id is 128.297, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 132, received 1
This example shows the spanning tree portfast edge interface operational state for all the instances:
Router# show spanning-tree interface gi3/1 portfast edge
MST0
disabled
MST1
disabled
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
Participate in the Technical Documentation Ideas forum
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-25
Chapter 2
Verifying the Optional STP Features
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
2-26
Optional STP Features
PART
2
IP Switching
CH AP TE R
3
IP Unicast Layer 3 Switching
Note
•
Prerequisites for Hardware Layer 3 Switching, page 3-1
•
Restrictions for Hardware Layer 3 Switching, page 3-1
•
Information About Layer 3 Switching, page 3-2
•
Default Settings for Hardware Layer 3 Switching, page 3-4
•
How to Configure Hardware Layer 3 Switching, page 3-4
•
Displaying Hardware Layer 3 Switching Statistics, page 3-5
•
For complete syntax and usage information for the commands used in this chapter, see these
publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
Tip
•
Cisco IOS Release 15.1SY supports only Ethernet interfaces. Cisco IOS Release 15.1SY does not
support any WAN features or commands.
•
For information about IP multicast Layer 3 switching, see Chapter 14, “IPv4 Multicast Layer 3
Features.”
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
Participate in the Technical Documentation Ideas forum
Prerequisites for Hardware Layer 3 Switching
None.
Restrictions for Hardware Layer 3 Switching
•
IPX traffic is fast switched on the route processor (RP)
Supervisor Engine 2T Software Configuration Guide, Release 15.1SY
3-1
Chapter 3
IP Unicast Layer 3 Switching
Information About Layer 3 Switching
•
Hardware Layer 3 switching supports the following ingress and egress encapsulations:
– Ethernet V2.0 (ARPA)
– 802.3 with 802.2 with 1 byte control (SAP1)
– 802.3 with 802.2 with SNAP
Information About Layer 3 Switching
•
Hardware Layer 3 Switching, page 3-2
•
Layer 3-Switched Packet Rewrite, page 3-2
Hardware Layer 3 Switching
Hardware Layer 3 switching allows the PFC and DFCs, instead of the RP, to forward IP unicast traffic
between subnets. Hardware Layer 3 switching provides wire-speed forwarding on the PFC and DFCs,
instead of in software on the RP. Hardware Layer 3 switching requires minimal support from the RP. The
RP routes any traffic that cannot be hardware Layer 3 switched.
Hardware Layer 3 switching supports the routing protocols configured on the RP. Hardware Layer 3
switching does not replace the routing protocols configured on the RP.
Hardware Layer 3 switching runs equally on the PF3 and DFCs to provide IP unicast Layer 3 switching
locally on each module. Hardware Layer 3 switching provides the following functions:
•
Hardware access control list (ACL) switching for policy-based routing (PBR)
•
Hardware flow-based switching for TCP intercept and reflexive ACL forwarding decisio