Best Practice Recommendations for the Catalyst 6500 Series Switch
Available Languages
Table Of Contents
Quick Reference to Best Practices for Cisco IOS on Catalyst 6500 Series Switches
1. Best Practices for Layer 2 Features
1.1 Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
1.2 Best Practices for STP PortFast
1.3 Best Practices for STP BPDU Guard
1.4 Best Practices for STP EtherChannel Guard
1.5 Best Practices for STP Root Guard
1.6 Best Practices for STP Loop Guard
1.7 Best Practices for Extended System ID
1.8 Best Practices for UniDirectional Link Detection (UDLD)
1.9 Best Practices for Autonegotiation and Link Negotiation
1.10 Best Practices for Flow Control
1.11 Best Practices for EtherChannel
1.12 Best Practices for VLAN Trunking Protocol (VTP)
1.13 Best Practices for Dynamic Trunking Protocol (DTP)
1.14 Best Practices for Traffic Storm Control
1.15 Best Practices for Unknown Unicast Flood Blocking (UUFB)
1.16 Best Practices for the Port Debounce Timer
1.17 Best Practices for MAC Address Aging
2. Best Practices for Health Monitoring
2.1 Best Practices for GOLD Bootup Online Diagnostics Level
2.2 Best Practices for GOLD Health-Monitoring Tests
2.3 Best Practices for Verifying the System Configuration
2.4 Best Practices for GOLD Tcl Script Template
2.5 Best Practices for Smart Call Home
2.6 Best Practices for Monitoring System Resource Usage
2.7 Best Practices for Error Counter Monitoring
3. Best Practices for Switch Management
3.1 Recommended Switch Management Feature and Command List
3.2 Best Practices for Hostname Configuration
3.3 Best Practices for the Login Banner
3.4 Best Practices for System Logging
3.5 Best Practices for Simple Network Management Protocol (SNMP)
3.6 Best Practices for Software and Configuration Backup
3.7 Best Practices for NetFlow Data Export (NDE)
3.8 Best Practices for the Time Domain Reflectometer (TDR)
3.9 Best Practices for Management Connections
3.10 Best Practices for Switched Port Analyzer (SPAN)
4. Best Practices for Multicast
4.2 Benefits of the Multicast Best Practices
4.3 Features Incompatible with Multicast
4.4 Guidelines and Restrictions for Multicast
4.5 Recommended Multicast Configuration
4.6 Documentation for Multicast
4.7 Related Features and Best Practices
5. Best Practices for Denial of Service (DoS) Protection and Security
5.1 Best Practices for Unicast Reverse Path Forwarding (uRPF) Check
5.2 Best Practices for Port Security
5.3 Best Practices for Control Plane Policing (CoPP)
5.4 Best Practices for CoPP Support for ISIS
5.5 Best Practices for Attack Protection
5.6 Best Practices for Controlling Management Session Access
5.7 Best Practices for NetFlow Data Export (NDE) for Security
5.8 Best Practices for Private VLANs (PVLANs) for Servers
6. Best Practices for Virtual Switching System (VSS)
6.1 Best Practices for VSS Standby Console Usage
6.2 Best Practices for VSS Image Upgrade
6.3 Best Practices for VSL Capacity Planning
6.4 Best Practices for Migration From Non-VSS to VSS
6.5 Best Practices for VSS Power Management
6.6 Best Practices for VSS CPU Protection
6.7 Best Practices for VSS NAM Service Module Integration
6.8 Best Practices for VSS VSLP Timers
6.9 Best Practices for Matching PFC and DFC
6.10 Best Practices for VSS Domain-ID
6.11 Best Practices for VSS Priority/Preemption
6.12 Best Practices for VSS Router MAC Address
6.13 Best Practices for VSS Standby Port Bringup/Delay
6.14 Best Practices for VSS IP Connectivity Management
6.15 Best Practices for VSS Dual-Active Detection
6.16 Best Practices for VSS VSLP Timers
6.17 Best Practices for VSS STP features
6.18 Best Practices for VSS in a Layer 2 Campus Environment
6.19 Best practices for SPAN on VSL
6.20 Best Practices for MAC Synchronization on VSS
6.21 Best Practices for Multicast on VSS
6.22 Best Practices for VSS QoS
6.23 Best Practices for Supervisor Engine 720-10G VSS for VSL
6.24 Best Practices for Layer 2 QoS on the VSS
6.25 Best Practices for VSS Etherchannel Load Distribution
6.26 Best Practices for Etherchannel Min-Links in VSS
6.27 Best Practices for LACP Port-Channel Port-Priority in VSS
6.28 Best Practices for VSS L3
Quick Reference to Best Practices for Cisco IOS on Catalyst 6500 Series Switches
This document is a quick reference to the best practices that have been developed by Cisco for the features in Cisco IOS software on the Catalyst 6500 Series Switches. This document supplements, but does not replace, IOS software documentation.
Note
Best Practice recommendations in this document have been tested and verified in Cisco's Data Center Test Lab (DCTL) at RTP, NC.
This document consists of feature-specific sections that follow a consistent pattern, making the type of information in each subsection easily recognizable. Best practices do not need to be implemented simultaneously, but sections are cross referenced to related best practices, making it easier to implement all related best practices at the same time.
To use this document, you should be familiar with the following:
•
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/ffun_c.html
•
–
–
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html
Note
•
This document provides best practices for these features:
•
•
•
•
•
1. Best Practices for Layer 2 Features
Cisco Catalyst 6500 best practices are defined for the following layer 2 technologies:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1.1 Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
These sections describe best practices for RPVST:
•
•
•
•
•
1.1.1 Description of RPVST
RPVST is a Layer 2 link-management protocol that supports path redundancy and prevents undesirable loops in the network. For a Layer 2 Ethernet network to function properly, only one active Layer 2 path can exist between any two network devices.
RPVST 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.
1.1.2 Benefits of the RPVST Best Practices
Without RPVST, or one of the other spanning tree protocols, when there is a physical Layer 2 loop, Layer 2 frames could loop indefinitely and consume all the bandwidth of the network.
1.1.3 Features Incompatible with RPVST
RPVST obsoletes BackboneFast and UplinkFast as it has built in mechanisms that achieve the same.
1.1.4 Guidelines and Restrictions for RPVST
•
•
•
–
–
1.1.5 Recommended RPVST Configuration
The following sections describe the recommended RPVST configuration.
1.1.5.1 Recommended Global Configuration
Enable RPVST
Enable Rapid Per-VLAN Spanning Tree protocol (RPVST):
Router(config)# spanning-tree mode rapid-pvstConfigure Root Bridge Ports
Plan the Layer 2 topology of your network and configure the root bridge port of each VLAN. Use the procedures in the "Configuring the Root Bridge" section of the customer documentation and the "Configuring a Secondary Root Bridge" section.
Note
1.1.5.2 Recommended General Port Configuration
None; use the specific port-type recommendations.
1.1.5.3 Recommended Access Port Configuration
If the port on the far-end device is configured to participate in STP and if the ports are connected by a point-to-point link, enter this command to support the most rapid convergence:
Router(config-if)# spanning-tree link-type point-to-point
Note
1.1.5.4 Recommended Layer 2 Trunk Port Configuration
If the port on the far-end device is configured to participate in STP, enter this command to support the most rapid convergence:
Router(config-if)# spanning-tree link-type point-to-point1.1.5.5 Recommended Layer 3 Port Configuration
Not applicable.
1.1.5.6 Recommended SVI Configuration
Not applicable.
1.1.6 Documentation for RPVST
See the "Understanding RSTP" section of the customer documentation for more information about RPVST.
1.1.7 Related Features and Best Practices
•
•
•
•
•
•
1.2 Best Practices for STP PortFast
These sections describe best practices for STP PortFast:
•
•
•
•
•
•
1.2.1 Description of STP PortFast
STP PortFast causes a Layer 2 LAN port to enter the forwarding state immediately, bypassing the listening and learning states.
1.2.2 Benefits of the STP PortFast Best Practices
STP PortFast skips the normal listening and learning states of STP, which is 30 seconds with the ForwardDelay time set to the default value of 15 seconds.
STP PortFast prevents the generation of STP Topology Change Notifications (TCNs), which are not meaningful from ports that do not receive STP BPDUs. For example, enabling STP PortFast on access ports prevents the TCNs that would otherwise occur when the connected computer is turned on.
1.2.3 Features Incompatible with STP PortFast
Loopguard has no affect on portfast enabled ports.
1.2.4 Guidelines and Restrictions for STP PortFast
•
–
–
–
•
1.2.5 Recommended STP PortFast Configuration
The following sections describe the recommended STP PortFast configuration.
1.2.5.1 Recommended Global Configuration
None.
1.2.5.2 Recommended General Port Configuration
None; use the recommendation for each port type.
1.2.5.3 Recommended Access Port Configuration
Access Ports that Terminate VLANs
On any access port that connects to a device that terminates VLANs (for example, a port that connects to an end station), enable STP PortFast:
Router(config-if)# spanning-tree portfastAccess Ports that Propagate VLANs
On any access port that connects to a device that propagates VLANs (for example, a port that connects to another switch or a port that connects to a router that is configured to support bridging), disable STP PortFast:
Router(config-if)# spanning-tree portfast disable1.2.5.4 Recommended Layer 2 Trunk Port Configuration
Trunk Ports that Terminate VLANs
On any trunk port that connects to a device that terminates VLANs (for example, a port that connects to an end station), enable STP PortFast:
Router(config-if)# spanning-tree portfast trunkTrunk Ports that Propagate VLANs
On any trunk port that connects to a device that propagates VLANs (for example, a port that connects to another switch or a port that connects to a router that is configured to support bridging), disable STP PortFast:
Router(config-if)# no spanning-tree portfast enable1.2.5.5 Recommended Layer 3 Port Configuration
Not applicable.
1.2.5.6 Recommended SVI Configuration
Not applicable.
1.2.6 Documentation for STP PortFast
See the "Understanding How PortFast Works" section of the customer documentation for more information about STP PortFast.
1.2.7 Related Features and Best Practices
Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
Best Practices for STP BPDU Guard
1.3 Best Practices for STP BPDU Guard
These sections describe best practices for STP BPDU Guard:
•
•
•
•
•
•
•
1.3.1 Description of STP BPDU Guard
STP BPDU Guard shuts down ports that receive BPDUs.
1.3.2 Benefits of the STP BPDU Guard Best Practices
STP BPDU Guard complements the functionality of STP PortFast. On STP PortFast-enabled ports, STP BPDU Guard provides the protection against Layer 2 loops that STP cannot provide when STP PortFast is enabled.
1.3.3 Features Incompatible with STP BPDU Guard
1.3.4 Guidelines and Restrictions for STP BPDU Guard
None.
1.3.5 Recommended STP BPDU Guard Configuration
The following sections describe the recommended STP BPDU Guard configuration.
1.3.5.1 Recommended Global Configuration
The following global command enables STP BPDU Guard on all ports where STP PortFast is enabled:
Router(config)# spanning-tree portfast bpduguard default1.3.5.2 Recommended General Port Configuration
Not applicable.
1.3.5.3 Recommended Access Port Configuration
Not applicable.
1.3.5.4 Recommended Layer 2 Trunk Port Configuration
Not applicable.
1.3.5.5 Recommended Layer 3 Port Configuration
Not applicable.
1.3.5.6 Recommended SVI Configuration
Not applicable.
1.3.6 Documentation for STP BPDU Guard
See the "Understanding How BPDU Guard Works" section of the customer documentation for more information about STP BPDU Guard.
1.3.7 Related Features and Best Practices
Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
Best Practices for STP PortFast
1.4 Best Practices for STP EtherChannel Guard
These sections describe best practices for STP EtherChannel Guard:
•
•
•
•
•
•
•
1.4.1 Description of STP EtherChannel Guard
EtherChannel guard detects a misconfigured EtherChannel where interfaces on the Catalyst 6500 series switch are configured as an EtherChannel while interfaces on the other device are not, or 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 Catalyst 6500 series switch into the errdisabled state.
1.4.2 Benefits of the STP EtherChannel Guard Best Practices
Use the default enabled state of STP EtherChannel Guard to avoid an EtherChannel misconfiguration that could cause a Layer 2 loop and allow Layer 2 frames to loop indefinitely.
1.4.3 Features Incompatible with STP EtherChannel Guard
None.
1.4.4 Guidelines and Restrictions for STP EtherChannel Guard
None.
1.4.5 Recommended STP EtherChannel Guard Configuration
The following sections describe the recommended STP EtherChannel Guard configuration.
1.4.5.1 Recommended Global Configuration
Ensure STP EtherChannel Guard is enabled globally:
Router(config)# spanning-tree etherchannel guard misconfig1.4.5.2 Recommended General Port Configuration
None; use the global configuration.
1.4.5.3 Recommended Access Port Configuration
None; use the global configuration.
1.4.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
1.4.5.5 Recommended Layer 3 Port Configuration
None; use the global configuration.
1.4.5.6 Recommended SVI Configuration
None; use the global configuration.
1.4.6 Documentation for STP EtherChannel Guard
See the "Understanding How EtherChannel Guard Works" section of the customer documentation for more information about STP EtherChannel Guard.
1.4.7 Related Features and Best Practices
Best Practices for EtherChannel
1.5 Best Practices for STP Root Guard
These sections describe best practices for STP Root Guard:
•
•
•
•
•
•
•
1.5.1 Description of STP Root Guard
Root guard prevents ports from becoming STP root ports.
1.5.2 Benefits of the STP Root Guard Best Practices
Use STP Root Guard to prevent unsuitable ports from becoming STP root ports. An example of an unsuitable port is a port that link to a device that is outside direct network administrative control.
1.5.3 Features Incompatible with STP Root Guard
Loopguard has no affect on portfast enabled ports.
1.5.4 Guidelines and Restrictions for STP Root Guard
None.
1.5.5 Recommended STP Root Guard Configuration
The following sections describe the recommended STP Root Guard configuration.
1.5.5.1 Recommended Global Configuration
None.
1.5.5.2 Recommended General Port Configuration
On any port that should never be an STP root port, enable STP root guard:
Router(config-if)# spanning-tree guard root1.5.5.3 Recommended Single-VLAN Access Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.5.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.5.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.5.5.6 Recommended SVI Configuration
Not applicable.
1.5.6 Documentation for STP Root Guard
See the "Understanding How Root Guard Works" section of the customer documentation for more information about STP Root Guard.
1.5.7 Related Features and Best Practices
Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
1.6 Best Practices for STP Loop Guard
These sections describe best practices for loop guard:
•
•
•
•
•
•
•
1.6.1 Description of STP Loop Guard
Loop guard is a Cisco proprietary optimization for the spanning tree protocol (STP). Loop guard protects Layer 2 networks from loops that occur when something prevents the normal forwarding of BPDUs on point-to-point links (for example, a network interface malfunction or a busy CPU).
1.6.2 Benefits of the STP Loop Guard Best Practices
Loop guard complements the protection against unidirectional link failures provided by UDLD. Loop guard isolates failures and lets STP converge to a stable topology with the failed component excluded from the STP topology.
1.6.3 Features Incompatible with STP Loop Guard
1.6.4 Guidelines and Restrictions for STP Loop Guard
Loop guard operates as a component of STP. There are no compatibility issues between loop guard and the version of STP configured on the network or with the configuration applied to STP timers in the network.
1.6.5 Recommended STP Loop Guard Configuration
The following sections describe the recommended loop guard configuration.
1.6.5.1 Recommended Global Configuration
Enable loop guard globally:
Router(config)# spanning-tree loopguard default1.6.5.2 Recommended General Port Configuration
Not applicable; use the recommended global configuration.
1.6.5.3 Recommended Single-VLAN Access Port Configuration
Not applicable; use the recommended global configuration.
1.6.5.4 Recommended Layer 2 Trunk Port Configuration
Not applicable; use the recommended global configuration.
1.6.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended global configuration.
1.6.5.6 Recommended SVI Configuration
Not applicable.
1.6.6 Documentation for STP Loop Guard
See the "Understanding How Loop Guard Works" section of the customer documentation for more information about loop guard.
1.6.7 Related Features and Best Practices
Best Practices for the Rapid Per-VLAN Spanning Tree Protocol (RPVST)
1.7 Best Practices for Extended System ID
These sections describe best practices for Extended System ID:
•
•
•
•
•
•
•
1.7.1 Description of Extended System ID
A 12-bit extended system ID field is part of the STP bridge ID. Chassis that have only 64 MAC addresses always use the 12-bit extended system ID. On chassis that have 1024 MAC addresses, you can enable use of the extended system ID. STP uses the VLAN ID as the extended system ID.
1.7.2 Benefits of the Extended System ID Best Practices
You must enable the extended system ID to configure extended range VLANs (1006-4094).
You must enable the extended system ID if any switches in the VTP domain have it enabled.
1.7.3 Features Incompatible with Extended System ID
None.
1.7.4 Guidelines and Restrictions for Extended System ID
The extended system ID is enabled permanently on chassis that support 64 MAC addresses.
1.7.5 Recommended Extended System ID Configuration
The following sections describe the recommended Extended System ID configuration.
1.7.5.1 Recommended Global Configuration
Enable the extended system ID:
Router(config)# spanning-tree extend system-id1.7.5.2 Recommended General Port Configuration
No port configuration required; use the global configuration.
1.7.5.3 Recommended Access Port Configuration
No port configuration required; use the global configuration.
1.7.5.4 Recommended Layer 2 Trunk Port Configuration
No port configuration required; use the global configuration.
1.7.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended global configuration.
1.7.5.6 Recommended SVI Configuration
Not applicable.
1.7.6 Documentation for Extended System ID
See the "Extended System ID" section of the customer documentation for more information.
1.7.7 Related Features and Best Practices
None.
1.8 Best Practices for UniDirectional Link Detection (UDLD)
These sections describe best practices for UniDirectional Link Detection (UDLD):
•
•
•
•
•
1.8.1 Description of UDLD
The Cisco-proprietary UDLD protocol monitors the physical configuration of the links between devices and ports that support UDLD. UDLD detects the existence of unidirectional links. When a unidirectional link is detected, UDLD puts the affected port into the errdisabled state and alerts the user. UDLD can operate in either normal or aggressive mode.
Normal-mode UDLD classifies a link as unidirectional if the received UDLD packets do not contain information that is correct for the neighbor device. In addition to the functionality of normal mode UDLD, aggressive-mode UDLD puts ports into the errdisabled state if the relationship between two previously synchronized neighbors cannot be reestablished.
1.8.2 Benefits of the UDLD Best Practices
Configure UDLD to prevent problems from these situations:
•
•
•
•
•
1.8.3 Features Incompatible with UDLD
None.
1.8.4 Guidelines and Restrictions for UDLD
•
•
•
•
1.8.5 Recommended UDLD Configuration
The following sections describe the recommended UDLD configuration.
1.8.5.1 Recommended Global Configuration
Enable enable aggressive mode UDLD globally:
Router(config)# udld aggressive
Note
1.8.5.2 Recommended General Port Configuration
In a well designed redundant network, enable aggressive mode UDLD on non-fiber LAN ports that connect to devices that support UDLD:
Router(config-if)# udld port aggressive1.8.5.3 Recommended Single-VLAN Access Port Configuration
No specific port-type configuration required; use the general port configuration.
1.8.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the general port configuration.
1.8.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.8.5.6 Recommended SVI Configuration
Not applicable.
1.8.6 Documentation for UDLD
See this publication for more information about UDLD:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/udld.html
1.8.7 Related Features and Best Practices
These sections describe features that are recommended for use with UDLD:
•
•
1.9 Best Practices for Autonegotiation and Link Negotiation
These sections describe best practices for autonegotiation and link negotiation:
•
•
•
•
•
•
•
1.9.1 Description of Autonegotiation and Link Negotiation
Autonegotiatation configures the speed and duplex settings on 10/100-Mbps or 10/100/1000-Mbps Ethernet ports. Link negotiation exchanges flow-control parameters and remote fault information on Gigabit and 10-Gigabit Ethernet ports.
1.9.2 Benefits of the Autonegotiation and Link Negotiation Best Practices
Retain the default autonegotiatation configuration (auto) on 10/100-Mbps or 10/100/1000-Mbps Ethernet ports and allow both speed and duplex to be autonegotiated.
Retain the default link negotiation configuration (auto) on Gigabit and 10-Gigabit Ethernet ports and allow link negotiation to exchange flow-control parameters and remote fault information.
Configure a non-default setting only when connecting to ports that do not support autonegotiation or link negotiation.
1.9.3 Features Incompatible with Autonegotiation and Link Negotiation
None.
1.9.4 Guidelines and Restrictions for Autonegotiation and Link Negotiation
•
•
•
1.9.5 Recommended Autonegotiation and Link Negotiation Configuration
The following sections describe the recommended link negotiation configuration.
1.9.5.1 Recommended Global Configuration
Not applicable.
1.9.5.2 Recommended General Port Configuration
On ports that are connected to devices that also support autonegotiation or link negotiation, retain the default autonegotiation or link negotiation state (enabled), as applicable to each port.
•
Router(config-if)# speed auto•
Router(config-if)# no speed nonegotiateOn ports that are connected to devices that do not support autonegotiation or link negotiation:
•
•
1.9.5.3 Recommended Single-VLAN Access Port Configuration
No specific port-type configuration required; use the general port configuration.
1.9.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the general port configuration.
1.9.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.9.5.6 Recommended SVI Configuration
Not applicable.
1.9.6 Documentation for Autonegotiation and Link Negotiation
See the "Configuring Ethernet Interface Speed and Duplex Mode" section of the customer documentation for more information about autonegotiation and link negotiation.
1.9.7 Related Features and Best Practices
These sections describe features that are recommended for use with autonegotiation and link negotiation:
•
1.10 Best Practices for Flow Control
These sections describe best practices for flow control:
•
•
•
•
•
•
1.10.1 Description of Flow Control
All Ethernet ports can be configured to respond to IEEE 802.3x pause frames from other devices. Gigabit Ethernet or 10-Gigabit Ethernet ports can be configured to transmit pause frames, but ports on the switch should never need to send pause frames.
1.10.2 Benefits of the Flow Control Best Practices
On ports that connect to a far-end device that might need to send pause frames because of the volume of traffic, you can decide whether it is best to drop traffic at the Catalyst 6500 switch port or to let the far-end device drop the traffic.
To drop the traffic at the Catalyst 6500 switch port, configure the port to respond to pause frames.
To drop the traffic at the far-end device, retain the default flow control configuration (the port will not respond to pause frames).
1.10.3 Features Incompatible with Flow Control
None.
1.10.4 Guidelines and Restrictions for Flow Control
You cannot configure how WS-X6502-10GE 10-Gigabit Ethernet ports respond to pause frames. WS-X6502-10GE 10-Gigabit Ethernet ports are permanently configured to respond to pause frames.
1.10.5 Recommended Flow Control Configuration
The following sections describe the recommended flow control configuration.
1.10.5.1 Recommended Global Configuration
None.
1.10.5.2 Recommended General Port Configuration
If you have decided to drop frames at the Catalyst 6500 switch port instead of on the far-end device, configure the port to respond to pause frames:
•
Router(config-if)# flowcontrol receive•
Router(config-if)# flowcontrol receive desired1.10.5.3 Recommended Single-VLAN Access Port Configuration
None; use the recommended general port configuration.
1.10.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the recommended general port configuration.
1.10.5.5 Recommended Layer 3 Port Configuration
None; use the recommended general port configuration.
1.10.5.6 Recommended SVI Configuration
Not applicable.
1.10.6 Documentation for Flow Control
See the "Configuring IEEE 802.3x Flow Control" section of the customer documentation for more information about flow control.
1.10.7 Related Features and Best Practices
None.
1.11 Best Practices for EtherChannel
These sections describe best practices for EtherChannel:
•
•
•
•
•
•
1.11.1 Description of EtherChannel
An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of the member links.
Cisco IOS Software Release 12.2SX supports a maximum of 128 EtherChannels per switch. You can form an EtherChannel with up to eight compatibly configured LAN ports on any switching module. All member ports in each EtherChannel must be the same speed and must all be configured as either Layer 2 or Layer 3 LAN ports.
1.11.2 Benefits of the EtherChannel Best Practices
Using an EtherChannel protocol avoids configuration errors. By default, EtherChannel frame distribution uses IP addresses. For EtherChannels that carry traffic to or from a small number of IP addresses, select one of the other frame distribution options.
1.11.3 Features Incompatible with EtherChannel
None.
1.11.4 Guidelines and Restrictions for EtherChannel
•
–
–
–
–
–
–
•
http://www.cisco.com/en/US/ts/fn/610/fn61935.html
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
–
•
•
•
Caution
1.11.5 Recommended EtherChannel Configuration
Layer 3 EtherChannels of all types and single-module non-DEC EtherChannels offer the highest throughput.
CSCti23324 is resolved in Release 12.2(33)SXJ1 and later releases. In releases where CSCti23324 is not resolved, Layer 2 DECs have lower throughput because Layer 2 DEC traffic uses packet recirculation. If possible, configure nondistributed Layer 2 EtherChannels or Layer 3 DECs.
When the switch is in bus mode (also called flow-through mode), Layer 2 multi-module EtherChannels have lower throughput because Layer 2 multi-module EtherChannel traffic uses packet recirculation. If possible, configure single-module EtherChannels or upgrade the installed hardware so that the switch does not operate in bus mode.
Note
1.11.5.1 Recommended Global Configuration
To support DECs on switches equipped with DFCs, ensure that MAC address aging is at least three times as long as the activity time of MAC address synchronization.
•
Router# show mac-address-table synchronize statistics | include Status of feature Status of feature enabled on the switch : off•
Router(config)# mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval
Note
•
Router# show mac-address-table synchronize statistics | include activity time Default activity time : 160 Configured current activity time : 160 ...•
Router(config)# mac-address-table aging-time 480
Note
Note
1.11.5.2 Recommended General Port Configuration
To configure a port as a member in an LACP EtherChannel:
Router(config-if)# channel-protocol lacp Router(config-if)# channel-group group_number mode activeTo configure a port as a member in an PAgP EtherChannel:
Router(config-if)# channel-protocol pagp Router(config-if)# channel-group group_number mode desirable1.11.5.3 Recommended Single-VLAN Access Port Configuration
No specific port-type configuration required; use the global configuration.
1.11.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the global configuration.
1.11.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended global configuration.
1.11.5.6 Recommended SVI Configuration
Not applicable.
1.11.6 Documentation for EtherChannel
See this publication for more information about EtherChannel:
1.11.7 Related Features and Best Practices
Best Practices for STP EtherChannel Guard
1.12 Best Practices for VLAN Trunking Protocol (VTP)
These sections describe best practices for VTP:
•
•
•
•
•
1.12.1 Description of VTP
A VTP domain, which is also called a VLAN management domain, consists of one or more trunk-connected switches that have the same VTP domain name. VTP allows users to make VLAN configuration changes centrally on one or more switches, which are then communicated to all the other switches in the VTP domain.
VTP has three operating modes:
•
•
•
•
1.12.2 Benefits of the VTP Best Practices
VTP minimizes configuration inconsistencies that can cause 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 switches and have those changes automatically communicated to all the other switches in the network, and put into effect on all switches in the VTP domain.
1.12.3 Features Incompatible with VTP
None, but note that Private VLANs are only be supported in VTP transparent or off modes.
1.12.4 Guidelines and Restrictions for VTP
When implementing VTP in your network, follow these guidelines and restrictions:
•
Adoption of a new VLAN database might delete VLANs and cause a outage in the network. To ensure that client or server switches always have a configuration revision number that is lower than that of the server, change the client VTP domain name to something other than the standard name, and then revert back to the standard. This action sets the configuration revision on the client to 0.
•
–
–
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1.12.5 Recommended VTP Configuration
To avoid the possibility of a network outage, configure switches as VTP servers and clients only if you have strict control over the introduction of new hardware and only if all personnel involved in software and hardware maintenance, including network management systems, thoroughly understand the danger of accidentally introducing a new client or server switch that has a VLAN database with a revision number higher than the current database.
Switches operating in VTP transparent mode are safe from propagated accidental VLAN database changes, but all VLAN configuration must be done individually on each switch.
The following sections describe the recommended VTP configuration.
1.12.5.1 Recommended Global Configuration
Configure the VTP password:
Router(config)# vtp password your_passwordConfigure a VTP domain name, or ensure that no domain name is entered on any switch:
Router(config)# vtp domain domain_name
Note
VTP Mode
Decide if your switches are going to operate in VTP transparent mode or in server and client modes.
•
Router(config)# vtp mode transparent•
Router(config)# vtp mode clientAdditional Global Configuration for VTP Server Mode
•
Router(config)# vtp version 2•
Router(config)# vtp pruning1.12.5.2 Recommended General Port Configuration
None.
1.12.5.3 Recommended Access Port Configuration
None.
1.12.5.4 Recommended Layer 2 Trunk Port Configuration
Configure the list of prune-eligible VLANs on a Layer 2 trunk:
switchport trunk pruning vlan {none |{{add | except | remove} vlan[,vlan[,vlan[,...]]}}1.12.5.5 Recommended Layer 3 Port Configuration
None.
1.12.5.6 Recommended SVI Configuration
Not applicable.
1.12.6 Documentation for VTP
See this publication for more information about VTP:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vtp.html
1.12.7 Related Features and Best Practices
Best Practices for Dynamic Trunking Protocol (DTP)
1.13 Best Practices for Dynamic Trunking Protocol (DTP)
These sections describe best practices for DTP:
•
•
•
•
•
1.13.1 Description of DTP
The Dynamic Trunking Protocol (DTP) manages trunk autonegotiation on Layer 2 LAN ports. DTP supports ISL and 802.1Q trunks within a VTP domain.
1.13.2 Benefits of the DTP Best Practices
The use of DTP to automatically configure trunks prevents misconfigurations and avoids incorrect traffic flooding that might be caused by a misconfiguration.
1.13.3 Features Incompatible with DTP
None.
1.13.4 Guidelines and Restrictions for DTP
When configuring Layer 2 LAN ports, follow these guidelines and restrictions:
•
–
–
–
•
–
–
–
–
–
–
–
1.13.5 Recommended DTP Configuration
The following sections describe the recommended DTP configuration.
1.13.5.1 Recommended Global Configuration
Not applicable.
1.13.5.2 Recommended General Port Configuration
None; use the recommendation for each port type.
1.13.5.3 Recommended Access Port Configuration
Not applicable.
1.13.5.4 Recommended Layer 2 Trunk Port Configuration
•
•
•
Note
•
1.13.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended global configuration.
1.13.5.6 Recommended SVI Configuration
Not applicable.
1.13.6 Documentation for DTP
See the "Understanding How Layer 2 Switching Works" section of the customer documentation for more information about DTP.
1.13.7 Related Features and Best Practices
None.
1.14 Best Practices for Traffic Storm Control
These sections describe best practices for traffic storm control:
•
•
•
•
•
•
•
1.14.1 Description of Traffic Storm Control
The traffic storm control feature prevents LAN ports from being disrupted by a broadcast, multicast, or unicast traffic storm. A traffic storm occurs when excessive traffic floods the network, which degrades network performance. Excessive broadcast traffic frequently contains repeated transmissions of the same packets, which makes it acceptable to suppress some of them. With some of the broadcast packets suppressed, enough are transmitted to support normal network operation.
1.14.2 Benefits of the Traffic Storm Control Best Practices
Traffic storm control is implemented in hardware and does not affect the overall performance of the switch. Typically, end-stations such as PCs and servers are the source of broadcast traffic that can be suppressed. To avoid unnecessary processing of excess broadcast traffic, enable traffic storm control for broadcast traffic on access ports that connect to end stations and on ports that connect to key network nodes.
1.14.3 Features Incompatible with Traffic Storm Control
None.
1.14.4 Guidelines and Restrictions for Traffic Storm Control
When configuring traffic storm control, follow these guidelines and restrictions:
•
–
–
–
–
–
–
–
–
•
•
•
•
–
–
–
–
–
–
–
When multicast suppression is enabled on the listed modules, do not configure traffic storm control on STP-protected ports that need to receive BPDUs.
Except on the listed modules, traffic storm control does not suppress BPDUs.
Note
1.14.5 Recommended Traffic Storm Control Configuration
All routers in a VLAN see copies of all broadcast traffic. To avoid high RP CPU utilization caused by a high volume of broadcast traffic, the threshold is typically set to a very low value; for example, less than 1 percent on a Gigabit Ethernet port.
You can use the Top N feature to periodically measure the peak broadcast traffic levels of the selected ports, or if you have a specific required broadcast traffic level (for example, from an application) you could use that requirement as the basis of the threshold.
Base the suppression threshold on your data, plus some additional capacity. For example, if the peak broadcast traffic that is acceptable for a port is 1 percent, a threshold of 1.5 percent might be appropriate. The faster the port speed, the less additional capacity is required.
Use the show interfaces counters storm-control command to monitor the effect of the values that you configure, and increase the configured threshold if the TotalSuppDiscards column shows non-zero values.
The following sections describe the recommended traffic storm control configuration.
1.14.5.1 Recommended Global Configuration
Not applicable.
1.14.5.2 Recommended General Port Configuration
On selected ports, configure traffic storm control to suppress broadcast traffic:
Router(config-if)# storm-control broadcast level acceptable_broadcast_percentage1.14.5.3 Recommended Access Port Configuration
No specific port-type configuration required; use the general port configuration.
1.14.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the general port configuration.
1.14.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.14.5.6 Recommended SVI Configuration
Not applicable.
1.14.6 Documentation for Traffic Storm Control
See this publication for more information about traffic storm control:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/storm.html
1.14.7 Related Features and Best Practices
None.
1.15 Best Practices for Unknown Unicast Flood Blocking (UUFB)
These sections describe best practices for UUFB:
•
•
•
•
•
1.15.1 Description of UUFB
Normal Layer 2 switching floods unknown unicast traffic to all Layer 2 ports in a VLAN. You can use UUFB to restrict this behavior on a per-port basis. UUFB permits only egress unicast traffic with known MAC addresses and denies unknown unicast traffic.
1.15.2 Benefits of the UUFB Best Practices
Processing flooded unknown unicast traffic consumes resources on end-stations. To avoid transmitting unnecessary traffic to the end station, enable UUFB on ports to which critical end-stations, like servers, are directly connected.
1.15.3 Features Incompatible with UUFB
None.
1.15.4 Guidelines and Restrictions for UUFB
This recommendation assumes that the end-station's MAC address is always learned on its port. If there is insufficient traffic to ensure that the end-station's MAC address is always learned, configure a static MAC address.
1.15.5 Recommended UUFB Configuration
The following sections describe the recommended UUFB configuration.
1.15.5.1 Recommended Global Configuration
Not applicable.
1.15.5.2 Recommended General Port Configuration
To configure UUFB:
Router(config-if)# switchport block unicast1.15.5.3 Recommended Access Port Configuration
No specific port-type configuration required; use the global configuration.
1.15.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the global configuration.
1.15.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended global configuration.
1.15.5.6 Recommended SVI Configuration
Not applicable.
1.15.6 Documentation for UUFB
See this publication for more information about UUFB:
1.15.7 Related Features and Best Practices
None.
1.16 Best Practices for the Port Debounce Timer
These sections describe best practices for the Port Debounce Timer:
•
•
•
•
•
•
•
1.16.1 Description of the Port Debounce Timer
If the status of a link changes quickly from up to down and then back to up, the port debounce timer suppresses the link status notification. If the link transitions from up to down, but does not come back up, the port debounce timer delays the link status notification.
1.16.2 Benefits of the Port Debounce Timer Best Practices
Suppressing the link status notification allows a quick port status change and recovery to occur without triggering any of the changes that are necessary when a port stays down. The normal operation of DWDM switches sometimes includes quick port status changes and recoveries.
Debounce can also be used to mitigate link flaps because of bad cabling.
1.16.3 Features Incompatible with the Port Debounce Timer
None.
1.16.4 Guidelines and Restrictions for the Port Debounce Timer
Note
Implement the port debounce timer with these default values:
1.16.5 Recommended the Port Debounce Timer Configuration
The following sections describe the recommended the Port Debounce Timer configuration.
1.16.5.1 Recommended Global Configuration
Not applicable; use the recommended general port configuration.
1.16.5.2 Recommended General Port Configuration
Enable the port debounce timer on all physical ports that connect to a DWDM switch:
Router(config-if)# link debounce1.16.5.3 Recommended Access Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.16.5.4 Recommended Layer 2 Trunk Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.16.5.5 Recommended Layer 3 Port Configuration
No specific port-type configuration required; use the recommended general port configuration.
1.16.5.6 Recommended SVI Configuration
Not applicable.
1.16.6 Documentation for the Port Debounce Timer
See the "Configuring the Port Debounce Timer" section of the customer documentation for more information.
1.16.7 Related Features and Best Practices
None.
1.17 Best Practices for MAC Address Aging
These sections describe best practices for MAC address aging:
•
•
•
•
•
•
•
1.17.1 Description of MAC Address Aging
MAC address aging is the process that deletes infrequently-used MAC addresses from the MAC address table.
1.17.2 Benefits of the MAC Address Aging Best Practices
When asymmetric routing occurs, to avoid unicast flooding, increase the MAC address aging time (300 seconds by default) to a value greater than or equal to the ARP timeout (14400 seconds by default).
Note
1.17.3 Features Incompatible with MAC Address Aging
None.
1.17.4 Guidelines and Restrictions for MAC Address Aging
None.
1.17.5 Recommended MAC Address Aging Configuration
•
Router# show running-config | include arp timeout•
•
Router(config)# mac-address-table aging-time 14400 [vlan vlan_id]1.17.6 Documentation for MAC Address Aging
See the Command References for more information about the MAC address aging commands:
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html
1.17.7 Related Features and Best Practices
None.
2. Best Practices for Health Monitoring
Cisco Catalyst 6500 best practices are defined for the following health monitoring technologies:
Note
•
•
•
•
•
•
•
•
•
2.1 Best Practices for GOLD Bootup Online Diagnostics Level
These sections describe best practices for the Generic Online Diagnostics (GOLD) bootup online diagnostics level:
•
•
•
•
•
•
•
2.1.1 Description of the GOLD Bootup Online Diagnostics Level
There are three bootup diagnostics levels:
•
•
•
2.1.2 Benefits of the GOLD Bootup Online Diagnostics Level Best Practices
If the added boot time is acceptable, configure the complete bootup diagnostics level to provide the most complete verification of the switch. In all cases, boot the switch with the complete bootup diagnostics level configured at least once to verify the hardware; if possible, boot the switch periodically with the complete bootup diagnostics level configured to reverify the hardware.
2.1.3 Features Incompatible with GOLD Bootup Online Diagnostics Level
None.
2.1.4 Guidelines and Restrictions for the GOLD Bootup Online Diagnostics Level
With the complete bootup diagnostics level configured, the bootup time for each module will increase by about 10 seconds compared to the default minimal level. If switch bootup time must be as short as possible, you might not be able to implement this best practice.
2.1.5 Recommended GOLD Bootup Online Diagnostics Level Configuration
The following sections describe the recommended GOLD bootup online diagnostics level configuration.
2.1.5.1 Recommended Global Configuration
Configure the complete bootup diagnostics level:
Router(config)# diagnostic bootup level complete2.1.5.2 Recommended General Port Configuration
None; use the global configuration.
2.1.5.3 Recommended Access Port Configuration
None; use the global configuration.
2.1.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
2.1.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global configuration.
2.1.6 Documentation for the GOLD Bootup Online Diagnostics Level
See the "Setting Bootup Online Diagnostics Level" section of the customer documentation for more information.
2.1.7 Related Features and Best Practices
None.
2.2 Best Practices for GOLD Health-Monitoring Tests
These sections describe best practices for the Generic Online Diagnostics (GOLD) health-monitoring tests:
•
•
•
•
•
•
•
2.2.1 Description of the GOLD Health-Monitoring Tests
Health-monitoring tests monitor critical system functionality, and they detect and trigger error-recovery in case of test failure.
2.2.2 Benefits of the Health-Monitoring Tests Best Practices
Operating with the health monitoring tests enabled ensures notification of any problem that occurs.
2.2.3 Features Incompatible with the GOLD Health-Monitoring Tests
None.
2.2.4 Guidelines and Restrictions for the GOLD Health-Monitoring Tests
None.
2.2.5 Recommended GOLD Health-Monitoring Tests Configuration
The following sections describe the recommended GOLD health-monitoring tests configuration.
2.2.5.1 Recommended Global Configuration
•
•
Router(config)# diagnostic monitor interval module supervisor_engine_slot test TestSPRPInbandPing 00:00:05 0 0Use the default interval for other tests.
•
–
–
–
Router(config)# show diagnostic description module slot_number test test_numberFor more information, see either the Release 12.2(18)SXF and rebuilds or the Release 12.2(33)SXH and rebuilds Online Diagnostic Tests appendix.
–
Router(config)# diagnostic monitor interval module slot_number test test_name 00:00:15 0 0 Router(config)# diagnostic monitor module slot_number test test_name
Note
2.2.5.2 Recommended General Port Configuration
None; use the global configuration.
2.2.5.3 Recommended Access Port Configuration
None; use the global configuration.
2.2.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
2.2.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global configuration.
2.2.6 Documentation for the GOLD Health-Monitoring Tests
See the "Configuring Health-Monitoring Diagnostics" section of the customer documentation for more information.
2.2.7 Related Features and Best Practices
None.
2.3 Best Practices for Verifying the System Configuration
These sections describe best practices for verifying the system configuration:
•
•
•
•
•
•
•
2.3.1 Description of Verifying the System Configuration
The show diagnostic sanity command checks the features configured on the switch against a list of known configuration requirements and displays a list of any conflicts that it finds.
2.3.2 Benefits of the Verifying the System Configuration Best Practices
The show diagnostic sanity command identifies problems that exist with the switch configuration. The command output will tell you the following:
•
•
–
–
•
–
–
–
–
•
–
–
•
–
–
· If the maximum aging time is other than the default.
· If the forward delay time is other than the default.
· If the hello time is other than the default.
–
· If the maximum aging time is other than the default.
· If the forward delay time is other than the default.
· If the hello time is other than the default.
•
–
–
–
–
Note
•
•
•
•
•
•
Note
•
•
•
•
•
•
•
2.3.3 Features Incompatible with Verifying the System Configuration
None.
2.3.4 Guidelines and Restrictions for Verifying the System Configuration
None.
2.3.5 Recommended Verifying the System Configuration Procedure
Enter this command:
Router# show diagnostic sanity2.3.6 Documentation for Verifying the System Configuration
See the command reference for more information about verifying the system configuration:
2.3.7 Related Features and Best Practices
None.
2.4 Best Practices for GOLD Tcl Script Template
These sections describe best practices for GOLD Tcl Script Template:
Note
These sections describe best practices for the GOLD Tcl script template:
•
•
•
•
•
•
•
2.4.1 Description of GOLD Tcl Script Template
In the following template, name_of_test can be one of the following:
•
•
•
•
•
•
•
•
•
•
•
•
::cisco::eem::event_register_gold card all testing_type monitoring \ test_name name_of_test \ consecutive_failure number_of_failures \ platform_action 0 queue_priority last namespace import ::cisco::eem::* namespace import ::cisco::lib::* # 1. query the information of latest triggered eem event array set arr_einfo [event_reqinfo] if {$_cerrno != 0} { set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \ $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str] error $result } set card $arr_einfo(card) # 2. execute the user-defined config commands if [catch {cli_open} result] { error $result $errorInfo } else { array set cli1 $result } if [catch {cli_exec $cli1(fd) "en"} result] { error $result $errorInfo} if [catch {cli_exec $cli1(fd) \ "diagnostic action mod $card test name_of_test default"} result] { error $result $errorInfo } else { set cmd_output $result } if [catch {cli_close $cli1(fd) $cli1(tty_id)} result] { error $result $errorInfo }2.4.2 Benefits of the GOLD Tcl Script Template Best Practices
The template shown above has hyperlinks to the relevant sections of the customer documentation.
2.4.3 Features Incompatible with the GOLD Tcl Script Template
None.
2.4.4 Guidelines and Restrictions for the GOLD Tcl Script Template
None.
2.4.5 Recommended GOLD Tcl Script Template Configuration
Follow the procedures in this publication:
2.4.6 Documentation for GOLD Tcl Script Template
See this publication for more information about Tcl scripts:
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_tcl.html
2.4.7 Related Features and Best Practices
None.
2.5 Best Practices for Smart Call Home
These sections describe best practices for Smart Call Home:
Note
These sections describe best practices for Smart Call Home:
•
•
•
•
•
•
•
2.5.1 Description of Smart Call Home
Call Home provides e-mail-based and web-based notification of critical system events. If you have a service contract directly with Cisco Systems, you can register your devices for the Smart Call Home service.
2.5.2 Benefits of the Smart Call Home Best Practices
•
•
•
2.5.3 Features Incompatible with Smart Call Home
None.
2.5.4 Guidelines and Restrictions for Smart Call Home
None.
2.5.5 Recommended Smart Call Home Configuration
See the following publication for procedures:
2.5.6 Documentation for Smart Call Home
See this publication for more information about Smart Call Home:
2.5.7 Related Features and Best Practices
None.
2.6 Best Practices for Monitoring System Resource Usage
These sections describe best practices for monitoring system resource usage.
Note
•
•
•
•
•
MIB Locator
http://tools.cisco.com/ITDIT/MIBS/servlet/index
2.6.1 Description of Monitoring System Resource Usage
Displays the current utilization of the hardware resources and displays a list of the currently available hardware capacities.
2.6.2 Benefits of the Monitoring System Resource Usage Best Practices
Issue the show platform hardware capacity command periodically to monitor system resource usage. Any system resource with usage of 90% or greater should be addressed.
2.6.3 Features Incompatible with Monitoring System Resource Usage
None.
2.6.4 Guidelines and Restrictions for Monitoring System Resource Usage
None.
2.6.5 Recommended Monitoring System Resource Usage Procedure
Enter this command:
Router# show platform hardware capacity2.6.6 Documentation for Monitoring System Resource Usage
See the "Determining System Hardware Capacity" section of the customer documentation for more information.
2.6.7 Related Features and Best Practices
None.
2.7 Best Practices for Error Counter Monitoring
These sections describe best practices for error counter monitoring:
Note
These sections describe best practices for error counter monitoring:
•
•
•
•
•
•
•
2.7.1 Description of Error Counter Monitoring
This procedure uses the TestErrorCounterMonitor, which monitors the errors and interrupts on each module in the system by periodically polling the module's error counters. If the errors exceed their thresholds, a syslog is displayed with detailed information, which includes the error counter identifier, port number, total failures, consecutive failures, and the severity of the error-counter.
2.7.2 Benefits of the Error Counter Monitoring Best Practices
This procedure allows you to identify errors that need to be submitted to the Cisco TAC for further analysis.
2.7.3 Features Incompatible with Error Counter Monitoring
None.
2.7.4 Guidelines and Restrictions for Error Counter Monitoring
None.
2.7.5 Recommended Error Counter Monitoring Procedure
Step 1
Router# show diagnostic events | include Time|-----|TestErrorCounterMonitor|DVTime Stamp ET [Card] Event Message------------------ -- ------ --------------------------------------------------10/06 06:26:03.967 E [5] TestErrorCounterMonitor: ID:26 IN:0 PO:0 RE:199 RM:255 DV:440 EG:3 CF:1 TF:110/06 06:26:03.971 E [5] TestErrorCounterMonitor: ID:26 IN:0 PO:1 RE:199 RM:255 DV:440 EG:3 CF:1 TF:110/06 06:26:03.971 E [5] TestErrorCounterMonitor: ID:26 IN:0 PO:2 RE:199 RM:255 DV:440 EG:3 CF:1 TF:110/06 06:26:03.971 E [5] TestErrorCounterMonitor: ID:26 IN:0 PO:3 RE:199 RM:255 DV:440 EG:3 CF:1 TF:110/06 06:29:03.971 E [5] TestErrorCounterMonitor: ID:26 IN:0 PO:0 RE:199 RM:255 DV:1000 EG:3 CF:1 TF:2Step 2
Step 3
2.7.6 Documentation for Error Counter Monitoring
See the show diagnostic events command for more information.
2.7.7 Related Features and Best Practices
None.
3. Best Practices for Switch Management
Cisco Catalyst 6500 best practices are defined for the following switch management technologies:
•
•
•
•
•
•
•
•
•
•
3.1 Recommended Switch Management Feature and Command List
Use the following features and commands to configure and manage your switch:
•
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf002.html#Using_Setup
•
–
router#show history–
router(config)#do show history•
–
–
•
•
•
•
•
http://www.cisco.com/en/US/docs/ios-xml/ios/config-mgmt/configuration/12-2sx/cm-config-rollback.html
•
A common use of the NTP-synchronized time is in debug and log time-stamps, configured with these commands:
Router(config)# service timestamps debug datetime msec localtime show-timezone Router(config)# service timestamps log datetime msec localtime show-timezoneSee this publication for NTP configuration procedures:
•
router(config)# config-register 0x2102
Note
•
Router(config)# boot system flash device_name:image_nameOr:
Router(config)# boot system flash device_name:image_nameIf the switch cannot boot the image specified in the first command, it will boot the image specified in the second command.
See this publication for more information about boot configuration:
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_rebooting.html
•
–
–
Note
See the "Determining System Hardware Capacity" section of the customer documentation for more information.
3.2 Best Practices for Hostname Configuration
These sections describe best practices for hostname configuration:
•
•
•
•
•
•
•
3.2.1 Description of Hostname Configuration
The host name is used in prompts.
3.2.2 Benefits of the Hostname Configuration Best Practices
Configure a meaningful hostname. Choose a name that means something to the people managing the switch, for example, location or function. A well-thought-out naming convention will prove helpful for administrators when using network management software and when troubleshooting the network.
3.2.3 Features Incompatible with Hostname Configuration
None.
3.2.4 Guidelines and Restrictions for Hostname Configuration
See the hostname command Usage Guidelines.
3.2.5 Recommended Hostname Configuration
The following sections describe the recommended hostname configuration.
3.2.5.1 Recommended Global Configuration
Configure the hostname:
Router(config)# hostname selected_nameFor example:
Router(config)# hostname 6K-LV2-CL3 6K-LV2-CL3(config)#After the hostname is entered, the CLI prompt changes to reflect the entered name. The hostname is derived from the device type (Catalyst: "6K"), floor location (Level 2), and wiring closet location (Closet 3). Sometimes the name can also incorporate the supervisor type or other relevant information (for example, S720B-LV2-CL3).
3.2.5.2 Recommended General Port Configuration
None; use the global configuration.
3.2.5.3 Recommended Access Port Configuration
None; use the global configuration.
3.2.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
3.2.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global configuration.
3.2.6 Documentation for Hostname Configuration
See the Configuring the System Name section in this publication for more information about hostname configuration:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf012.html#wp1039289
3.2.7 Related Features and Best Practices
None.
3.3 Best Practices for the Login Banner
These sections describe best practices for the login banner:
•
•
•
•
•
•
•
3.3.1 Description of the Login Banner
The login banner is displayed after the MOTD banner and before the login prompt.
In some legal jurisdictions it can be impossible to prosecute and illegal to monitor malicious users unless they have been notified that they are not permitted to use the switch. The login banner can provide this notice.
Legal notification requirements are complex, vary by jurisdiction and situation, and should be discussed with legal counsel. Even within jurisdictions, legal opinions can differ. In cooperation with counsel, a banner can provide some or all of the this information:
•
•
•
•
For security purposes, rather than legal, a login banner should not contain any specific information about the switch name, model, software, or ownership. Such information can be abused by malicious users.
3.3.2 Benefits of the Login Banner Best Practices
The configuration of the login banner provides a way to display a message to anyone who accesses the switch. Login banners can be useful to reemphasize the potential law infringement represented by the unauthorized access to the device in question. It can also be used to provide information about the location of the device, the contact details of the administrator, or a message of the month.
For example, the message could be:
Access to this device or the attached networks is prohibited without express permission from the network administrator. Violators will be prosecuted to the fullest extent of both civil and criminal law.3.3.3 Features Incompatible with the Login Banner
None.
3.3.4 Guidelines and Restrictions for the Login Banner
The login banner cannot be disabled on a per-line basis. To globally disable the login banner, enter the no banner login command.
3.3.5 Recommended Login Banner Configuration
The following sections describe the recommended the Login Banner configuration.
3.3.5.1 Recommended Global Configuration
Enter this command:
Router(config)# banner login d message_text dAny character that does not appear in message_text can be used as the delimiting (d) character, including control characters, except ^z (Control-Z).
3.3.5.2 Recommended General Port Configuration
None; use the global configuration.
3.3.5.3 Recommended Access Port Configuration
None; use the global configuration.
3.3.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
3.3.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global configuration.
3.3.6 Documentation for the Login Banner
See this publication for more information about the login banner:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf004.html#wp1001446
3.3.7 Related Features and Best Practices
None.
3.4 Best Practices for System Logging
These sections describe best practices for system messages:
•
•
•
•
•
•
•
3.4.1 Description of System Logging
System logging (syslog) forwards messages from the syslog sender (the switch) to various destinations, such as the logging buffer, terminal lines, or a UNIX syslog server.
3.4.2 Benefits of the System Logging Best Practices
The recommended configuration increases the usability of administrative connections (console of SSH) and optimizes the syslog configuration.
3.4.3 Features Incompatible with System Logging
None.
3.4.4 Guidelines and Restrictions for System Logging
None.
3.4.5 Recommended System Logging Configuration
The following sections describe the recommended system logging configuration.
3.4.5.1 Recommended Global Configuration
Disable Console Logging
By default, all system messages are sent to the system console. Console logging is a high-priority task in Cisco IOS Software. Disable console logging to avoid a situation in which the switch might hang while waiting for a response from a terminal.
Router(config)# no logging console
Note
Disable Logging on Other Administrative Connections
This command disables logging for terminal lines other than the system console.
Router(config)# no logging monitor
Note
Enable Message Buffering
Buffered messages can be displayed with the show logging command. The logging buffer is circular. Once the logging buffer is filled, older entries are overwritten by newer entries. The size of the logging buffer is user-configurable and is specified in bytes. 16384 provides adequate logging in most cases.
Router(config)# logging buffered 16384Filter Noncritical Messages
Filter by severity the messages sent to the syslog servers. The default logging level for all destinations (console, monitor, buffer, and traps) is "debugging" (level 7). If you leave the trap logging level at 7, many noncritical messages are sent to the syslog servers. Set the default logging level for traps to "notifications" (level 5).
Router(config)# logging trap notificationsConfigure the UNIX Logging Server Address
Configure the IP address of the UNIX logging server:
Router(config)# logging host ip_address
Note
Configure the Message Source
To make identification of the messages from a particular switch easier, select the interface from which the messages will be sent. The IP address of the interface will be the source address of the messages. This example configures the loopback 0 interface as the source of messages:
Router(config)# logging source-interface loopback 0
Note
Enable Timestamped Messages
Enable timestamps on log messages:
Router(config)# service timestamps log datetime localtime show-timezone msecEnable timestamps on system debug messages:
Router(config)# service timestamps debug datetime localtime show-timezone msecEnable Module Messages
Enable messages from the installed modules:
Router(config)# service slave-log3.4.5.2 Recommended General Port Configuration
Enable logging for link status and bundle status on all switch-to-switch links:
Router(config-if)# logging event link-statusRouter(config-if)# logging event bundle-status
Note
3.4.5.3 Recommended Access Port Configuration
None; use the global and general port configurations.
3.4.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global and general port configurations.
3.4.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global and general port configurations.
3.4.6 Customer Documentation for System Logging
See this publication for more information about system logging:
3.4.7 Related Features and Best Practices
None.
3.5 Best Practices for Simple Network Management Protocol (SNMP)
These sections describe best practices for SNMP:
•
•
•
•
•
•
3.5.1 Description of SNMP
The Simple Network Management Protocol (SNMP) is used by network management systems to both get information from the switch and also to make configuration changes.
3.5.2 Benefits of the SNMP Best Practices
With SNMP enabled, configure the SNMP descriptive components to provide a clearer description of the switch and to better identify it as the origin of SNMP alerts.
3.5.3 Features Incompatible with SNMP
None.
3.5.4 Guidelines and Restrictions for SNMP
None.
3.5.5 Recommended SNMP Configuration
The following sections describe the recommended SNMP configuration.
3.5.5.1 Recommended Global Configuration
Enter these commands:
Router(config)# snmp-server contact contact_id Router(config)# snmp-server location switch_location Router(config)# snmp-server chassis-id id_string
Note
3.5.5.2 Recommended General Port Configuration
None; use the global configuration.
3.5.5.3 Recommended Access Port Configuration
None; use the global configuration.
3.5.5.4 Recommended Layer 2 Trunk Port Configuration
None; use the global configuration.
3.5.5.5 Recommended Layer 3 Port or SVI Configuration
None; use the global configuration.
3.5.6 Customer Documentation for SNMP
See this publication for more information about SNMP:
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_cfg_snmp_sup.html
3.5.7 Related Features and Best Practices
None.
3.6 Best Practices for Software and Configuration Backup
These sections describe best practices for software and configuration backup:
•
•
•
•
•
•
•
3.6.1 Description of Software and Configuration Backup
Local copies of software images and configuration files provide the quickest replacement for any damaged or deleted files.
3.6.2 Benefits of the Software and Configuration Backup Best Practices
Store copies of the software images and configuration files so that you can quickly replace any damaged or deleted files. Store the copies on other non-removable flash devices, on removal media that is not kept in the switch's slot, or on a TFTP, HTTP, or RCP server. Store a copy of the configuration files on the RP bootflash: device.
3.6.3 Features Incompatible with Software and Configuration Backup
None.
3.6.4 Guidelines and Restrictions for Software and Configuration Backup
None.
3.6.5 Recommended Software and Configuration Backup Procedures
Use this command to copy files:
Router# copy file_name destinationfile_name is:
•
•
•
destination is:
•
•
•
•
•
3.6.6 Customer Documentation for Software and Configuration Backup
See this publication for more information about software and configuration backup:
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_config-files.html
3.6.7 Related Features and Best Practices
None.
3.7 Best Practices for NetFlow Data Export (NDE)
These sections describe best practices for NDE:
•
•
•
•
•
•
3.7.1 Description of NDE
NetFlow collects traffic statistics by monitoring the traffic that flows through the switch and storing the statistics in the NetFlow table. The statistics can be analyzed for management, traffic analysis, and security purposes.
3.7.2 Benefits of the NDE Best Practices
Use NDE for troubleshooting. Except in carefully planned topologies, NDE consumes too many switch and network resources to enable permanently.
3.7.3 Features Incompatible with NDE
None.
3.7.4 Guidelines and Restrictions for NDE
•
•
•
3.7.5 Recommended NDE Configuration
The following sections describe the recommended NDE configuration.
3.7.5.1 Recommended Troubleshooting Procedure
Set the NetFlow Mask
Router(config)# mls flow ip interface-fullEnable NDE From the PFC
Router(config)# mls nde senderDisplay Statistics
Router(config)# show mls netflow ip3.7.6 Customer Documentation for NDE
See these publications for more information about NetFlow and NDE:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nde.html
3.7.7 Related Features and Best Practices
Best Practices for Switched Port Analyzer (SPAN)
3.8 Best Practices for the Time Domain Reflectometer (TDR)
These sections describe best practices for the TDR:
•
•
•
•
•
3.8.1 Description of the TDR
The TDR detects a cable fault by sending a signal through the cable and reading the signal that is reflected back to it.
3.8.2 Benefits of the TDR Best Practices
If you cannot establish a link, use the TDR to conduct in-place testing that determines if the cabling is at fault.
3.8.3 Features Incompatible with the TDR
None.
3.8.4 Guidelines and Restrictions for the TDR
•
•
–
–
–
–
–
–
–
–
–
–
–
3.8.5 Recommended TDR Procedure
Enter this command to run the TDR:
Router# test cable-diagnostics tdr interface interface_type slot/port3.8.6 Customer Documentation for the TDR
See this publication for more information about the TDR:
3.8.7 Related Features and Best Practices
None.
3.9 Best Practices for Management Connections
These sections describe best practices for management connections:
•
•
•
•
•
•
•
3.9.1 Description of Management Connections
Management connections to interfaces on the Catalyst 6500 switch fall into two categories:
•
•
The serial link to the console port is inherently an out-of-band management connection, but it is quite common to use a terminal server that provides network access to the serial link, so that the aggregate link (network plus serial) can be either in-band or out-of-band.
Catalyst 6500 switches do not have management-only Ethernet ports, but any port can be configured for for management-only use, and depending on the network topology, it can be either in-band or out-of-band.
3.9.2 Benefits of the Management Connections Best Practices
•
Note
•
–
–
•
3.9.3 Features Incompatible with Management Connections
None.
3.9.4 Guidelines and Restrictions for Management Connections
None.
3.9.5 Recommended Management Connections Configuration
Loopback Interface
Router(config)# interface loopback loopback_numberRouter(config-if)# ip address ip_address subnet_maskLayer 3 Interface
Router(config)# interface interface_type slot/portRouter(config-if)# ip address ip_address subnet_mask3.9.6 Customer Documentation for Management Connections
See these publications for more information about management connections:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/ffun_c.html
http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/finter_c.html
3.9.7 Related Features and Best Practices
None.
3.10 Best Practices for Switched Port Analyzer (SPAN)
These sections describe best practices for SPAN:
•
•
•
•
•
3.10.1 Description of SPAN
SPAN copies traffic from any of these:
•
•
•
•
SPAN sends the copied traffic to one or more destinations for analysis by a network analyzer.
Note
•
•
•
3.10.2 Benefits of the SPAN Best Practices
Use SPAN for troubleshooting. Except in carefully planned topologies, SPAN consumes too many switch and network resources to enable permanently.
Exercise all possible care when enabling and configuring SPAN. The traffic copied by SPAN can impose a significant load on the switch and the network.
To minimize the load, configure SPAN to copy only the specific traffic that you want to analyze. Select sources that carry as little unwanted traffic as possible. For example, a port as a SPAN source might carry less unwanted traffic than a VLAN.
Note
Before enabling SPAN, carefully evaluate the SPAN source traffic rates, and consider the performance implications and possible oversubscription points, which include these:
•
•
•
•
To avoid disrupting traffic, do not oversubscribe any of these points in your SPAN topology. Some oversubscription and performance considerations are:
•
•
•
•
Note
Release 12.2(33)SXH and later releases support distributed egress SPAN, which reduces the load on the supervisor engine.
•
3.10.3 Features Incompatible with SPAN
See the "Feature Incompatibilities" section of the customer documentation.
3.10.4 Guidelines and Restrictions for SPAN
See the "Local SPAN, RSPAN, and ERSPAN Configuration Guidelines and Restrictions" section of the customer documentation.
3.10.5 Recommended SPAN Configuration
See the "Configuring Local SPAN, RSPAN, and ERSPAN" section of the customer documentation.
3.10.6 Documentation for SPAN
See this publication for more information about SPAN:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/span.html
3.10.7 Related Features and Best Practices
None.
4. Best Practices for Multicast
These sections describe Cisco Catalyst 6500 best practices for multicast technology:
•
•
•
•
•
4.1 Description of Multicast
Multicast is a one-to-many communication method that delivers network traffic from a single source to a group of destinations, with the traffic passing over each link of the connecting network topology only once. Multicast creates copies of the traffic only when the links to the destinations diverge.
4.2 Benefits of the Multicast Best Practices
Multicast is a feature that must be configured compatibly across a network. These best practices focus on the configuration requirements, recommendations, and restrictions that apply to Catalyst 6500 switches in the network.
4.3 Features Incompatible with Multicast
None.
4.4 Guidelines and Restrictions for Multicast
•
–
–
•
•
•
•
Note
4.5 Recommended Multicast Configuration
These sections describe the recommended multicast configuration:
•
•
•
•
•
4.5.1 Platform Independent Configuration
Follow the recommendations in this publication:
4.5.2 Replication Mode
Note
•
•
Use the automatically detected replication mode. If possible, the switch will use egress replication mode.
•
Router(config)# no mls ip multicast replication-mode ingress•
Router(config)# no mls ip multicast replication-mode egress4.5.3 Local Egress Replication Mode
If the switch is operating in egress replication mode, enable local egress replication mode.
Router(config)# mls ip multicast egress local4.5.4 Non-RPF Traffic
The switch uses the NetFlow table to drop non-RPF traffic.
•
Router(config)# mls ip multicast non-rpf aging fast Router(config)# mls ip multicast non-rpf aging global•
Router(config)# mls rate-limit multicast ipv4 non-rpf pps [packets_in_burst]
Note
4.5.5 Partially and Completely Switched Flows
•
Router(config-if)# ip multicast boundary access_list [filter-autorp]•
Router(config)# mls rate-limit multicast ipv4 partial 5000 100Router(config)# mls rate-limit multicast ipv4 fib-miss 5000 100Modify the packets-per-second and burst values based on the convergence requirements of your network and the available CPU capacity.
Note
•
4.5.6 Multicast Consistency Checker
Enable the multicast consistency checker:
Router(config)# mls ip multicast consistency-check Router(config)# mls ip multicast consistency-check type scan-mrouteUse the following command as needed for troubleshooting:
Router(config)# mls ip multicast consistency-check type rp-sp
Note
•
4.5.7 Rate Limit Traffic from Directly Connected Sources
If you have PIM sparse mode configured, enter this command:
Router(config)# mls rate-limit multicast ipv4 connected packets_per_secondSet a packets-per-second value between 150 and 1000 and modify the packets-per-second and burst values based on the convergence requirements of your network.
4.5.8 Directly Connected Subnets
If the switch is not the first hop router for any multicast sources, disable installation of directly connected subnet entries:
Router(config)# no mls ip multicast connected
Note
4.5.9 Multicast Redundancy and SSO
•
Router(config)# no mls ip multicast sso convergence-time 1 Router(config)# no mls ip multicast sso leak interval 1 Router(config)# no mls ip multicast sso leak percent 1
Note
•
Note
•
4.5.10 PIM snooping
•
Router(config)# interface vlan vlan_ID Router(config-if)# no ip pim snooping•
Router(config)# ip pim snooping Router(config)# ip pim snooping dr-flood Router(config)# interface vlan vlan_ID Router(config-if)# ip pim snooping
Note
•
–
–
–
If DR flooding is not required on the switch, disable it to reduce bandwidth usage:
Router(config)# no ip pim snooping dr-flood•
This situation lasts only briefly because the PIM-ASSERT mechanism stops the extraneous flow, but this cycle repeats again when the next (*,G) join (S,G) RPT bit prune message is sent by one of the receivers.
If the switch is in a topology that has the problem, take one of these actions:
–
Router(config)# ip pim snooping suppress sgr-prune–
Router(config)# interface vlan vlan_ID Router(config-if)# no ip pim snooping
Note
•
4.5.11 IGMP Snooping
•
Router(config)# ip igmp snooping source-only-learning limit {1000 | 2000}–
–
Modify the value based on the requirements of your network.
•
Router(config)# mls rate-limit multicast ipv4 igmp 5000 100Modify the packets-per-second and burst values based on the requirements of your network and the available CPU capacity.
Note
Note
4.6 Documentation for Multicast
See these publications for more information about multicast:
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_basic_cfg.html
http://www.cisco.com/en/US/tech/tk828/tech_white_papers_list.html
4.7 Related Features and Best Practices
None.
5. Best Practices for Denial of Service (DoS) Protection and Security
Cisco Catalyst 6500 best practices are defined for the following DoS Protection and Security technologies:
•
•
•
•
•
•
•
•
Note
•
•
•
•
5.1 Best Practices for Unicast Reverse Path Forwarding (uRPF) Check
These sections describe best practices for uRPF:
•
•
•
•
•
For CLI modifications in IOS release SXI, refer to SXI configuration guidelines:
http://www.cisco.com/en/US/products/ps6017/products_installation_and_configuration_guides_list.html
5.1.1 Description of uRPF Check
The uRPF check verifies that the source address of received IP packets is reachable. The uRPF check discards IP packets that lack a verifiable IP source prefix (route), which helps mitigate problems that are caused by traffic with malformed or forged (spoofed) IP source addresses.
5.1.2 Benefits of the uRPF Best Practices
Implement the recommended configuration to take advantage of the PFC3 hardware support for the uRPF check of received IP packets.
5.1.3 Features Incompatible with uRPF
The PFC does not provide hardware-supported uRPF check for policy-based routing (PBR) traffic. (CSCea53554)
5.1.4 Guidelines and Restrictions for uRPF
•
•
•
–
Received IP traffic that is sourced from a prefix that exists in the routing table passes the uRPF check if the prefix is reachable through the input interface. If a default route is configured, any IP packet with a source prefix that is not in the routing table passes the uRPF check if the ingress interface is a reverse path for the default route.–
If a default route is configured, any IP packet passes the uRPF check.•
–
–
Note
•
5.1.5 Recommended uRPF Configuration
The following uRPF configuration is recommended.
•
PFC2 Configuration Options
The PFC2 supports the uRPF check for packets that have a single reverse-path interface. If, on any number of interfaces, the switch receives valid IP packets that have one reverse path interface per source prefix, configure uRPF strict mode.
To ensure that no more than one reverse-path interface exists in the routing table for each prefix, enter the maximum-paths 1 command in config-router mode when configuring OSPF, EIGRP, or BGP.
Note
PFC3 Configuration Options
•
–
This option requires you to identify the source prefixes and the interfaces that serve as reverse paths for the source prefixes and to configure interface groups for those reverse path interfaces. All of the reverse-path interfaces for each source prefix must be in the same interface group. You can configure four interface groups, with each group containing up to six reverse-path interfaces. There is no limit on the number of source prefixes that an interface group can support.
To ensure that no more than six reverse-path interfaces exist in the routing table for each prefix, enter the maximum-paths 6 command in config-router mode when configuring OSPF, EIGRP, or BGP.
IP traffic with one or two reverse-path interfaces that is received on uPPF-check enabled interfaces outside the interface groups passes the uRPF check if the ingress interface and at most one other interface are reverse paths.
With maximum paths set to six, IP traffic with more than two reverse-path interfaces that is received on uPPF-check enabled interfaces outside the interface groups always pass the uRPF check.
–
To ensure that no more than two reverse-path interfaces exist in the routing table for each prefix, enter the maximum-paths 2 command in config-router mode when configuring OSPF, EIGRP, or BGP.
•
Maximum Paths
Router(config-router)# maximum-paths [1 | 2 | 6]uRPF Check Strict Mode
Router(config-if)# ip verify unicast source reachable-via rxuRPF Check Pass Global Mode
Router(config)# mls ip cef rpf multipath passuRPF Check Group-Interface Global Mode
Router(config)# mls ip cef rpf multipath interface-groupuRPF Check Interface Groups
Router(config)# mls ip cef rpf interface-group [0 | 1 | 2 | 3] interface1 [interface2 [interface3 [interface4]]]5.1.6 Documentation for uRPF
See these publications for more information about uRPF:
http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html
5.1.7 Related Features and Best Practices
None.
5.2 Best Practices for Port Security
These sections describe best practices for port security:
•
•
•
•
•
•
5.2.1 Description of Port Security
Port security allows only a configured number of MAC addresses to send traffic into a port.
5.2.2 Benefits of the Port Security Best Practices
•
•
5.2.3 Features Incompatible with Port Security
•
•
•
•
•
•
5.2.4 Guidelines and Restrictions for Port Security
•
•
•
•
•
•
•
5.2.5 Recommended Port Security Configuration
The following sections describe the recommended port security configuration.
Note
5.2.5.1 Recommended Global Configuration
Not applicable.
5.2.5.2 Recommended General Port Configuration
None; use the recommendation for each port type.
5.2.5.3 Recommended Access Port Configuration
For All Port Security-Enabled Ports
Router(config)# interface type slot/portRouter(config-if)# switchportRouter(config-if)# switchport mode accessRouter(config-if)# switchport port-securityRouter(config-if)# switchport port-security maximum number_of_addressesSet the number_of_addresses value to a number appropriate for the connection.
For Ports with Stable Connections
Router(config-if)# switchport port-security mac-address stickyFor Ports with Flexible Connections
Router(config-if)# switchport port-security aging type inactivity5.2.5.4 Recommended Layer 2 Trunk Port Configuration
Not applicable.
5.2.5.5 Recommended Layer 3 Port or SVI Configuration
Not applicable.
5.2.6 Documentation for Port Security
See this publication for information about port security:
5.2.7 Related Features and Best Practices
None.
5.3 Best Practices for Control Plane Policing (CoPP)
These sections describe best practices for CoPP:
•
•
•
•
•
5.3.1 Description of CoPP
The control plane policing (CoPP) feature protects the route processor from unnecessary traffic, including DoS traffic.
5.3.2 Benefits of the CoPP Best Practices
CoPP provides increased security.
5.3.3 Features Incompatible with CoPP
None.
5.3.4 Guidelines and Restrictions for CoPP
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
5.3.5 Recommended CoPP Configuration
Follow these procedures to develop your CoPP configuration:
•
•
•
•
Analyze Traffic
Analyze the existing control and management plane access requirements to determine the exact traffic profile for the filtering lists.
Step 1
•
•
•
•
•
Step 2
access-list 120 remark CoPP ACL for critical traffic! allow BGP from a known peer to this router's BGP TCP port! Initial ACEaccess-list 120 permit any any eq bgpaccess-list 121 remark CoPP Important traffic! permit return traffic from TACACS host! Initial ACEaccess-list 121 permit any any established! ssh access to the router from a subnet!Initial ACEaccess-list 121 permit any any eq 22! telnet access to the router from a subnet!Initial ACEaccess-list 121 permit any any eq telnet! SNMP access from the NMS host to the router!Initial ACEaccess-list 121 permit any any eq snmp! Allow the router to receive NTP packets from a known clock source!Initial ACEaccess-list 121 permit any any eq ntpaccess-list 122 remark CoPP normal traffic! permit router originated tracerouteaccess-list 122 permit icmp any any ttl-exceededaccess-list 122 permit icmp any any port-unreachable! permit receipt of responses to router originated pingsaccess-list 122 permit icmp any any echo-reply! allow pings to routeraccess-list 122 permit icmp any any echoaccess-list 123 remark explicitly defined "undesirable" traffic! permit, for policing, all traffic destined to UDP 1434access-list 123 permit udp any any eq 1434!This ACL identifies all other trafficaccess-list 124 remark rest of the IP traffic for CoPPaccess-list 124 permit ip any anyStep 3
class-map CoPP-criticalmatch access-group 120class-map CoPP-importantmatch access-group 121class-map CoPP-normalmatch access-group 122class-map CoPP-undesirablematch access-group 123class-map CoPP-all-other-ip-trafficmatch access-group 124Step 4
policy-map CoPPclass CoPP-criticalpolice 31500000 conform-action transmit exceed-action dropclass CoPP-importantpolice 125000 3906 3906 conform-action transmit exceed-action dropclass CoPP-normalpolice 64000 2000 2000 conform-action transmit exceed-action drop! This policy drops all traffic categorized as undesirable, regardless of rate.class CoPP-undesirablepolice 32000 1500 1500 conform-action drop exceed-action dropStep 5
Note
Ideally, you will have identified all required traffic destined to the router. Realistically, not all required traffic will be identified prior to deployment. Some extra analysis will be required to determine the unclassified packets. This extra classification step can be accomplished using several techniques: general ACL classification as described in Characterizing and Tracing Packet Floods Using Cisco Routers or packet analyzers. Once classified, modify the ACLs as necessary. Use the show policy-map control-plane command to collect data (packet count and rate information) about the policies, which will support development of increasingly granular policies.
Filter Traffic by Protocol Type
Step 1
Note
Step 2
Enter the show access-lists command to determine which ACEs in the ACLs are in use (the ACEs each identify a protocol). Enter the show map command to display the rate data.
Filter Traffic by Protocol Type and Source Address Ranges
Step 1
Note
For example:
access-list 120 remark CoPP ACL for critical traffic! allow BGP from a known peer to this router's BGP TCP portaccess-list 120 permit tcp host 47.1.1.1 host 10.9.9.9 eq bgp! allow BGP from a peer's BGP port to this routeraccess-list 120 permit tcp host 47.1.1.1 eq bgp host 10.9.9.9access-list 120 permit tcp host 10.86.183.120 host 10.9.9.9 eq bgpaccess-list 120 permit tcp host 10.86.183.120 eq bgp host 10.9.9.9access-list 121 remark CoPP Important traffic! permit return traffic from TACACS hostaccess-list 121 permit tcp host 1.1.1.1 host 10.9.9.9 established! ssh access to the router from a subnetaccess-list 121 permit tcp 10.0.0.0 0.0.0.255 host 10.9.9.9 eq 22! telnet access to the router from a subnetaccess-list 121 permit tcp 10.86.183.0 0.0.0.255 any eq telnet! SNMP access from the NMS host to the routeraccess-list 121 permit udp host 1.1.1.2 host 10.9.9.9 eq snmp! Allow the router to receive NTP packets from a known clock sourceaccess-list 121 permit udp host 1.1.1.3 host 10.9.9.9 eq ntpStep 2
This step provides data about traffic from outside the CIDR block.
Filter Traffic by Protocol Type and Source Address
Narrow the ACL permit statements to only allow known authorized source addresses.
Filter Traffic by Protocol Type, Source Address, and Destination Address
Configure destination addresses in the ACEs.
Caution
5.3.6 Documentation for CoPP
See this publication for more information about CoPP, including complete CoPP configuration procedures:
5.3.7 Related Features and Best Practices
None.
5.4 Best Practices for CoPP Support for ISIS
These sections describe best practices for CoPP Support for ISIS:
•
•
•
•
•
•
•
5.4.1 Description of CoPP Support for ISIS
The control plane policing (CoPP) feature increases security on the switch by protecting the RP from unnecessary or DoS traffic and giving priority to important control plane and management traffic.
Currently the control plane policing (CoPP) feature does not support non-IP classes except for the default non-IP class (class-default). This means that if CoPP is used, since ISIS CLNS packets are non-IP they will end up in the default non-IP class. If the system is subject to a DoS attack and a policy is applied to the default class, ISIS adjacencies could flap or could go down. For this reason it is recommended not to configure a policy under the default class if ISIS is running in the system.
5.4.2 Benefits of CoPP Support for ISIS
ISIS control-plane protection.
5.4.3 Features Incompatible with CoPP Support for ISIS
Not Applicable
5.4.4 Guidelines and Restrictions for CoPP Support for ISIS
For a list of CoPP restrictions, please see the guidelines and restrictions section in "Configuring Control Plane Policing (CoPP)"
5.4.5 Recommended CoPP Support for ISIS Configuration
If the system is under an IP packet DoS attack and ISIS is running, the following configuration could be used.
ip access-list extended MATCH-IP-ONLY class-map MATCH-IP-ONLY match access-group name MATCH-IP-ONLY policy-map CoPP !--- Critical applications class CRITICAL police cir 10000000000 bc 312500000 conform-action transmit exceed-action transmit !--- To mitigate IP based DoS class MATCH-IP-ONLY police cir 8000 bc 1500 conform-action transmit exceed-action drop class class-defaultIf the system is under a non-IP packet DoS attack, ACLs can be used to drop the non-IP traffic.
5.4.6 Configuration Guide for CoPP Support for ISIS
See "Configuring Control Plane Policing (CoPP)" for more details on CoPP configuration.
5.4.7 Related Features and Best Practices
5.5 Best Practices for Attack Protection
Protect the switch from TCP SYN flooding attacks and other advanced attacks with one or more of the these:
•
•
•
5.5.1 Firewall Services Module (FWSM)
See this publication:
Note
5.5.2 Traffic Anomaly Detector Service Module
See this publication:
5.5.3 Anomaly Guard Module
See this publication:
5.5.4 IOS Access Control Lists (ACLs)
See these publications:
•
•
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html
5.5.5 VLAN ACLs (VACLs)
See this publication:
5.5.6 Port ACLs (PACLs)
Supported in Release 12.2(33)SXH and later releases—See this publication:
5.5.7 QoS ACLs
See this publication:
5.5.8 Hardware Rate-Limiters
Rate limiting is used to control the rate of traffic sent or received on a network interface. Traffic that is less than or equal to the specified rate is sent, whereas traffic that exceeds the rate is dropped or delayed. It is performed by policing (discarding excess packets), queuing (delaying packets in transit), or congestion control (manipulating the protocol's congestion mechanism). Policing and queuing can be applied to any network protocol.
Note
When CoPP is not an option, you can configure hardware rate limiters to protect the switch control plane and limit CPU utilization:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
See these publications:
Note
•
•
5.5.9 Optimized ACL Logging (OAL)
Optimized ACL Logging (OAL) provides PFC3 hardware support for ACL logging. See this publication:
5.5.10 AutoSecure
Note
The AutoSecure feature automatically secures the switch. See this publication for information about AutoSecure:
5.5.11 DHCP Snooping
Note
DHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers. DHCP snooping provides a valuable security function and is required to support IP Source Guard. See this publication for information about DHCP Snooping:
5.5.12 IP Source Guard
Note
IP Source Guard provides source IP address filtering on a Layer 2 port to prevent a malicious host from impersonating a legitimate host by assuming the legitimate host's IP address. IP Source Guard is an effective means of spoofing prevention at Layer 2. See this publication for information about IP Source Guard:
5.5.13 Dynamic ARP Inspection (DAI)
Note
Dynamic ARP Inspection (DAI) mitigates ARP poisoning attacks. See this publication for information about DAI:
5.6 Best Practices for Controlling Management Session Access
These sections describe best practices for controlling management session access:
•
•
•
•
•
•
•
5.6.1 Description of Controlling Management Session Access
By default, anyone who knows an IP address on the switch can attempt to open a management session. Similarly, if there is a terminal server configured to provide network access to the console connection, anyone who knows an IP address on the terminal server can attempt to make a console connection.
When all the switch or terminal server VTY lines are in use, new management sessions cannot be established, which creates a DoS condition for management session access to the switch.
Controlling management session access can help ensure that all connections are valid.
5.6.2 Benefits of the Controlling Management Session Access Best Practices
•
•
5.6.2.1 Use Secure Shell (SSH) and Secure Copy Protocol (SCP)
Secure Shell (SSH) is a network protocol that supports encrypted data exchange between two devices. SSH supports authentication with public-key cryptography.
Instead of Telnet, use SSH to encrypt management session traffic, which prevents access of the data being transmitted by a malicious user. Cisco IOS software supports SSH Version 1.0 (SSHv1) or SSH Version 2.0 (SSHv2).
Cisco IOS software also supports the Secure Copy Protocol (SCP), which supports encrypted connections for copying configuration files or software images. SCP relies on SSH. Use secure file transfer protocols (for example, Secure Copy Protocol (SCP) instead of FTP or TFTP), when you copy configuration data.
5.6.2.2 Configure VTY Lines to Maintain Sessions
Use the exec-timeout command to logout idle sessions. Use the service tcp-keepalive-in command to enable TCP keepalives, which ensures that the device on the remote end of the connection is still accessible and that half-open or orphaned connections are closed.
5.6.2.3 Limit Access to VTY Lines
If you can predict the networks or IP addresses from which you wish to allow management sessions, use access control lists (ACLs) to deny traffic from unknown sources.
5.6.3 Features Incompatible with Controlling Management Session Access
None.
5.6.4 Guidelines and Restrictions for Controlling Management Session Access
See the customer documentation for the guidelines and restrictions of the features used to control management session access.
5.6.5 Recommended Management Session Access Control Configuration
This example configuration enables management session access control:
!service tcp-keepalives-in!hostnameselected_name /* For SSHip domain nameexample.com /* For SSH!crypto key generate rsamodulus 2048/* For SSH!ip sshversion 2ip sshtime-out 60ip sshauthentication-retries 3ip sshsource-interface type slot/port!linevty 0 4transport inputsshno transportoutputexec-timeout15 0loginlocalaccess-class101 inexitaccess-list101 remark VTY SSH Access ACL! Configure an appropriate permit statementaccess-list101 permit tcp ... eq 22 log-inputaccess-list101 deny ip any any log-input!This configuration example enables SCP services:
!ip scp server enable!5.6.6 Documentation for Controlling Management Session Access
See this publication for more information about Secure Shell (SSH):
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_secure_shell.html
See this publication for more information about Secure Copy:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_ssh/configuration/12-2sx/sec-secure-copy.html
See this publication for more information about configuring VTY lines:
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_terminals.html
See this publication for more information about configuring ACLs:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_acl_ov_guideline.html
5.6.7 Related Features and Best Practices
None.
5.7 Best Practices for NetFlow Data Export (NDE) for Security
Data Export (NDE) is also covered in the "Best Practices for NetFlow Data Export (NDE)" section. This section describes the security applications of NDE.
Use NDE to monitor for unusually heavy data-traffic. NDE allows you to see traffic as it traverses the network in real time. NDE allows you to quickly identify and trace network traffic, especially during incident response. NDE can provide visibility into all traffic on the network.
NetFlow data can be viewed and analyzed through the command line interface (CLI) or the data can be exported to a NetFlow collector for aggregation and analysis.
These sections, earlier in this document, describe the best practices for NDE:
•
•
•
•
•
•
5.8 Best Practices for Private VLANs (PVLANs) for Servers
These sections describe best practices for PVLANs:
•
•
•
•
•
5.8.1 Description of PVLANs
Private VLANs (PVLANs) limit connectivity between ports in a VLAN.
5.8.2 Benefits of the PVLANs Best Practices
Networking topologies exist where security can be improved by limiting communication between devices on a single VLAN. For example, PVLANs are often used to prevent communication between servers in a publicly accessible subnet. If one of the servers is compromised, the lack of connectivity to other servers due to the application of PVLANs may help limit the problem to just one server.
5.8.3 Features Incompatible with PVLANs
•
•
•
5.8.4 Guidelines and Restrictions for PVLANs
There are extensive guidelines and restrictions for PVLANs. See this publication:
5.8.5 Recommended PVLANs Configuration
See the "Configuring Private VLANs" section of the customer documentation.
5.8.6 Documentation for PVLANs
See this publication for more information about PVLANs:
5.8.7 Related Features and Best Practices
None.
6. Best Practices for Virtual Switching System (VSS)
Cisco Catalyst 6500 best practices are defined for the following Virtual Switching System (VSS) technologies:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
6.1 Best Practices for VSS Standby Console Usage
These sections describe best practices for VSS standby console usage:
Description of VSS Standby Console Usage
Benefits of VSS Standby Console Usage
Features Incompatible with VSS Standby Console Usage
Guidelines and Restrictions for VSS Standby console usage
Recommended VSS Standby Console Usage Configuration
Configuration Guide for VSS Standby Console Usage
Related Features and Best Practices
6.1.1 Description of VSS Standby Console Usage
VSS converts two physical chassis into one logical device. Hence it is generally recommended to use standby console only during dual-active troubleshooting, if and when the VSL is down. For other information that is needed from the Standby switch, it is recommended to use "remote command" on Active switch.
6.1.2 Benefits of VSS Standby Console Usage
In dual-active scenario, it may be necessary for the administrator to troubleshoot on both chassis consoles. Once the VSL is brought back up, the VSS will be in operation.
6.1.3 Features Incompatible with VSS Standby Console Usage
None.
6.1.4 Guidelines and Restrictions for VSS Standby console usage
Use console line to troubleshoot both chassis if in dual-active scenario.
6.1.5 Recommended VSS Standby Console Usage Configuration
None.
6.1.6 Configuration Guide for VSS Standby Console Usage
None.
6.1.7 Related Features and Best Practices
•
6.2 Best Practices for VSS Image Upgrade
These sections describe best practices for VSS Image Upgrade:
•
•
•
•
•
•
•
6.2.1 Description of VSS Image Upgrade
Upgrading an image provides most up to date bug fixes, as well as a set of new features. Specific image upgrade steps should be followed to have optimal uptime in VSS.
6.2.2 Benefits of the VSS Image Upgrade Best Practices
Following the steps listed below for VSS image upgrade would provide optimal uptime during upgrade process. The downtime during the image upgrade will be the same as RPR switchover time.
6.2.3 Features Incompatible with VSS Image Upgrade
None.
6.2.4 Guidelines and Restrictions for VSS Image Upgrade
The following steps should be followed while performing image upgrade in VSS:
1.
2.
3.
4.
5.
6.
6.2.5 Recommended VSS Image Upgrade Configuration
None.
6.2.6 Configuration Guide for VSS Image Upgrade
Configuring RPR Supervisor Engine Redundancy
6.2.7 Related Features and Best Practices
None.
6.3 Best Practices for VSL Capacity Planning
These sections describe best practices for VSL Capacity Planning:
•
•
•
•
•
•
•
6.3.1 Description of VSL Capacity Planning
VSL is the most critical link for VSS that carries control traffic, as well as data traffic between two redundant chassis. It is important that enough VSL ports are being connected to reserve enough bandwidth and provide high availability in case of link breakage. It is recommended at minimum that both of the Sup4 uplink ports to be connected between both chassis, and used for VSL. As control and data traffic grows across VSL, additional VSL ports (up to 6 in total, not counting the Sup4 uplinks) can be added on 6708-10GE.
6.3.2 Benefits of VSL Capacity Planning
This will ensure maximum up time and high availability.
6.3.3 Features Incompatible with VSL Capacity Planning
None.
6.3.4 Guidelines and Restrictions for VSL Capacity Planning
None.
6.3.5 Recommended VSL Capacity Planning Configuration
None.
6.3.6 Configuration Guide for VSS Capacity Planning
None.
6.3.7 Related Features and Best Practices
None.
6.4 Best Practices for Migration From Non-VSS to VSS
These sections describe best practices for Migration From Non-VSS to VSS:
•
•
•
•
•
•
•
6.4.1 Description of Migration From Non-VSS to VSS
In a production network, some migration steps are recommended while converting from non-VSS to VSS. See link in the recommended configuration section for reference to the detailed steps.
6.4.2 Benefits of the Migration From Non-VSS to VSS Best Practices
This achieves the maximum uptime for the production network during the migration.
6.4.3 Features Incompatible with Migration From Non-VSS to VSS
None.
6.4.4 Guidelines and Restrictions for Migration From Non-VSS to VSS
None.
6.4.5 Recommended Migration From Non-VSS to VSS Configuration
Migrate Standalone Cisco Catalyst 6500 Switch to Cisco Catalyst 6500 Virtual Switching System
6.4.6 Configuration Guide for Migration From Non-VSS to VSS
Configuring Virtual Switching Systems
6.4.7 Related Features and Best Practices
None.
6.5 Best Practices for VSS Power Management
These sections describe best practices for VSS Power Management:
•
•
•
•
•
•
•
6.5.1 Description of VSS Power Management
In VSS, two physical chassis is needed, hence power supplies are needed for each of the chassis. It is recommended to have dual power supply in each of the chassis. Power redundancy mode can be configured separately on each of the chassis. It is recommended that the two chassis are exact replica of each other, to provide full redundancy and achieve minimal downtime in case one of the switch gone down. Also it is recommended that both chassis are configured with the same power redundancy mode, specifically redundant mode
6.5.2 Benefits of the VSS Power Management Best Practices
This achieves the maximum uptime with redundant power supplies in case one of the power supplies has hardware failure.
6.5.3 Features Incompatible with VSS Power Management
None.
6.5.4 Guidelines and Restrictions for VSS Power Management
None.
6.5.5 Recommended VSS Power Management Configuration
The following configuration is needed to configure power redundancy mode as redundant in VSS:
Router(config)# power redundancy-mode redundant switch 1 Router(config)# power redundancy-mode redundant switch 26.5.6 Configuration Guide for VSS Power Management
•
6.5.7 Related Features and Best Practices
None
6.6 Best Practices for VSS CPU Protection
These sections describe best practices for VSS CPU Protection:
•
•
•
•
•
•
•
6.6.1 Description of VSS CPU Protection Recommendation
In VSS, Active SP and RP are responsible for many control plane decision and calculations, hence it is important that the Active CPUs are protected with hardware rate-limiters and Control Plane Policing. For a smooth operation, we would like the CPU to be as idle as possible since the bulk of forwarding is handled by hardware. A less busy CPU reacts to events quickly and become more responsive to network operation. There are few features in layer 3 routing might cause busy CPU. We should provide the right implementation to avoid unnecessary CPU hog.
•
•
ACL and QOS classifications are implemented in hardware using TCAM. Although TCAM implementation provides constant lookup rates regardless of size of ACL and QOS entries, optimal use of TCAM resources are still important. Because, when a link flaps, software has to recalculate ACL and QOS entries then reprogram TCAM again, contributing to converging delays.
6.6.2 Benefits of the VSS CPU Protection Recommendation
With CPU being protected, it would help to ensure VSS to be in healthy state.
6.6.3 Features Incompatible with VSS CPU Protection Recommendation
User should be aware of any software switched features that would be software switched by the CPU.
6.6.4 Guidelines and Restrictions for VSS CPU Protection Recommendation
None.
6.6.5 Recommended VSS CPU Protection Configuration
User should configure hardware rate-limiters to protect the CPU, as specified in the reference of the configuration guide section.
6.6.6 Configuration Guide for VSS CPU Protection Recommendation
•
•
•
6.6.7 Related Features and Best Practices
None.
6.7 Best Practices for VSS NAM Service Module Integration
These sections describe best practices for VSS NAM Service Module Integration:
•
•
•
•
•
•
6.7.1 Description of VSS Network Analysis Module (NAM) Integration
NAM is a service module that is supported in VSS. It is a tool that helps network administrators to monitor traffic flow, and perform statistical analysis. It is recommended to have NAM in each of the Active and Standby chassis to provide redundancy.
6.7.2 Benefits of the VSS NAM Service Module Integration Best Practices
With NAM installed in redundant fashion, it provides high availability network monitoring.
6.7.3 Features Incompatible with VSS NAM Service Module Integration
None.
6.7.4 Guidelines and Restrictions for VSS NAM Service Module Integration
Same restrictions as SPAN in VSS.
6.7.5 Recommended VSS NAM Service Module Integration Configuration
The following sections describe the recommended NAM configuration.
•
Router(config)# analysis switch 1 module 1 management-port access-vlan 100•
Router# session switch 1 slot 1 root@nam# ip address 10.100.1.26.7.6 Configuration Guide for NAM
6.7.7 Related Features and Best Practices
Best Practices for Switched Port Analyzer (SPAN)
6.8 Best Practices for VSS VSLP Timers
These sections describe best practices for VSS VSLP timers:
•
•
•
•
•
•
•
6.8.1 Description of VSS VSLP Timers
VSLP Timers control the hello messages that traverse between each end of the VSL links.
6.8.2 Benefits of the VSS VSLP Timers
VSLP timers can be configured to change the transmission interval between hello messages as well as receiving interval timeout across VSL links.
6.8.3 Features Incompatible with VSS VSLP Timers
None.
6.8.4 Guidelines and Restrictions for VSS VSLP Timers
Configuring VSLP Timers
6.8.5 Recommended VSS VSLP Timers Configuration
It is recommended to leave VSLP Timers at default values.
6.8.6 Configuration Guide for VSS VSLP Timers
6.8.7 Related Features and Best Practices
None.
6.9 Best Practices for Matching PFC and DFC
These sections describe best practices for matching PFC and DFC:
•
•
•
•
•
•
•
6.9.1 Description of matching PFC and DFC
In VSS, since the switch fabric extends over VSL between two physical chassis, it is recommended that both switches are operating in the same PFC mode. In order to do so, it is recommended to keep all of the PFC and DFC to be the same type. i.e. all 3CXL, or all 3C, but no mix and match.
6.9.2 Benefits of the matching PFC and DFC
This ensures complete redundancy and consistent hardware within VSS.
6.9.3 Features Incompatible with matching PFC and DFC
None.
6.9.4 Guidelines and Restrictions for matching PFC and DFC
None.
6.9.5 Recommended matching PFC and DFC configuration
Default configuration is recommended. In case of PFC/DFC mismatch, it is recommended to force the system into PFC3C mode by issuing the following command:
Switch (config)# platform hardware vsl pfc mode pfc3c6.9.6 Configuration Guide for Matching PFC and DFC
6.9.7 Related Features and Best Practices
None.
6.10 Best Practices for VSS Domain-ID
These sections describe best practices for VSS domain-ID:
•
•
•
•
•
6.10.1 Description VSS Domain-ID
VSS converts two physical chassis into one logical device as known as VSS Domain, each Domain-ID represents a unique node within the network.
6.10.2 Benefits of VSS Domain-ID
A VSS domain share a single point of management, single gateway IP address, and single routing instance and eliminates the dependence on First Hop Redundancy Protocols (FHRP) and Spanning Tree Protocol.
6.10.3 Features Incompatible with VSS Domain-ID
None.
6.10.4 Guidelines and Restrictions for VSS Domain-ID
None.
6.10.5 Recommended VSS Domain-ID Configuration
Use a unique domain-ID ranging from 1 to 255 within the network.
6.10.6 Configuration Guide for VSS Domain-ID
Assigning Virtual Switch Domain and Switch Numbers
6.10.7 Related Features and Best Practices
None.
6.11 Best Practices for VSS Priority/Preemption
These sections describe best practices for VSS Priority/Preemption:
•
•
•
•
•
•
•
6.11.1 Description of VSS Priority/Preemption
VSS Priority allow switch that has higher priority configured to boot up as Active chassis if both chassis are brought up at the same time or if the other one has not assumed as an active role.
VSS Preemption allow switch with higher priority configured to initiate a switchover to become active if it comes up in standby state after a reload or a switchover.
6.11.2 Benefits of the VSS Priority/Preemption
None.
6.11.3 Features Incompatible with VSS Priority/Preemption
None.
6.11.4 Guidelines and Restrictions for VSS Priority/Preemption
The switch with the higher priority assumes the active role.
The priority range is 1 to 255; the default is 100.
The new priority value only takes effect after you save the configuration and perform a reload of the VSS.
6.11.5 Recommended VSS Priority/Preemption Configuration
It is recommend NOT configuring switch preemption since identical hardware setup between Active/Standby chassis is recommended with virtual router-mac address configured and that all links connected to Neighbor switch through MEC links. Preempt ensures that one particular switch will always be active in the end. However, forcing preemption transitions requires a reload and potential traffic outage.
6.11.6 Configuration Guide for VSS Priority/Preemption
Configuring VSL Switch Priority
6.11.7 Related Features and Best Practices
None.
6.12 Best Practices for VSS Router MAC Address
These sections describe best practices for VSS Router MAC Address:
•
•
•
•
•
•
•
6.12.1 Description of VSS Router MAC Address
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.
6.12.2 Benefits of VSS Router MAC Address
In rare case where both chassis later become inactive and then start up with the second or different supervisor engine becoming the initial active supervisor engine, the VSS will start up with a router MAC address from that respective chassis.
Other Layer 2 hosts that do not respond to GARP (Generic Attribute Registration Protocol) and are not directly connected to the VSS will retain the earlier router MAC address of the VSS, and will not be able to communicate with the VSS.
To avoid this possibility, a virtual router MAC address can be assigned from a reserved pool of addresses with the domain ID encoded in the last octet of the MAC address, or a specific router MAC address can be configured manually.
6.12.3 Features Incompatible with VSS Router MAC Address
None.
6.12.4 Guidelines and Restrictions for VSS Router MAC Address
None.
6.12.5 Recommended VSS Router MAC Address Configuration
Use virtual router MAC address for the VSS:
Router(config)# switch virtual domain 1 Router(config-vs-domain)# mac-address use-virtual6.12.6 Configuration Guide for VSS Router MAC Address
Configuring the Router MAC Address Assignment
6.12.7 Related Features and Best Practices
None.
6.13 Best Practices for VSS Standby Port Bringup/Delay
These sections describe best practices for VSS Standby Port Bringup/Delay:
•
•
•
•
•
•
•
6.13.1 Description of VSS Standby Port Bringup/Delay
When a failed chassis is restarted as the standby chassis, rather than allowing all ports to be activated simultaneously, you can configure the system to defer activation of non-VSL ports and then to activate the ports in groups over a period of time.
6.13.2 Benefits of the VSS Standby Port Bringup/Delay
By delaying standby port bring up, CPU utilization can be lower on the Active chassis.
6.13.3 Features Incompatible with VSS Standby Port Bringup/Delay
None.
6.13.4 Guidelines and Restrictions for VSS Standby Port Bringup/Delay
Only non-VSL ports can be configured
6.13.5 Recommended VSS Standby Port Bringup/Delay Configuration
It is recommended to set the delay time to 300 seconds, and port bring up at 1 port per 1 second.
Router(config-vs-domain)# standby port delay 300 Router(config-vs-domain)# standby port bringup 1 16.13.6 Configuration Guide for VSS Standby port bringup/delay
Configuring Deferred Port Activation During Standby Recovery
6.13.7 Related Features and Best Practices
None.
6.14 Best Practices for VSS IP Connectivity Management
These sections describe best practices for VSS IP Connectivity Management:
•
•
•
•
•
•
•
6.14.1 Description of VSS IP Connectivity Management
VSS converts two physical chassis into one logical device. Hence from the management perspective (in addition or in lieu of the console port), the management from the IP approach need to be common for both physical switches. It is recommended that L3 MEC be used to provide the IP connectivity for management purpose.
6.14.2 Benefits of VSS IP Connectivity Management
IP connectivity for management will be guarantee whenever the VSS is in operation and the IP address is NOT dependent on which chassis (switch ID 1 or switch ID 2) is the Active switch. Additionally, common IP address for management provide a deterministic origination source IP address and source interface for applications such as (but not limited to) NTP, Radius, SNMP.
6.14.3 Features Incompatible with VSS IP Connectivity Management
None.
6.14.4 Guidelines and Restrictions for VSS IP Connectivity Management
Interfaces used in the MEC for the VSS IP Connectivity Management should NOT be included in the VSS Dual Active Exclusion Interface list.
6.14.5 Recommended VSS IP Connectivity Management Configuration
None.
6.14.6 Configuration Guide for VSS IP Connectivity Management Configuration
interface g1/8/1channel-group101 mode activeinterface g2/8/2channel-group101 mode activeinterface port-channel 101description: VSS Network IP Accessip address172.20.1.2 255.255.255.2526.14.7 Related Features and Best Practices
•
6.15 Best Practices for VSS Dual-Active Detection
These sections describe best practices for VSS Dual-Active Detection:
•
•
•
•
•
•
•
6.15.1 Description of VSS Dual-Active Detection
The virtual switching system supports two methods for detecting a dual-active scenario. One method uses enhanced PAgP or PAgP+ messaging over the MEC links to communicate between the two chassis. The other method uses IP BFD messaging over a backup Ethernet connection
6.15.2 Benefits of the VSS Dual-Active Detection
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 dual-active scenario. Additionally, during this scenario, all the interfaces from the original active chassis will be suspended/shut-down. It is recommended if troubleshooting is required is to leverage the console port. If this is not available, it is recommended that non-MEC ports residing on the both switches be configured as L3 port for IP connectivity.
6.15.3 Features Incompatible with VSS Dual-Active Detection
Dual-Active Detection Using PAGP+
Cisco-proprietary protocol for managing EtherChannels. The VSS MEC must have at least one port on each chassis of the VSS and terminates to a Cisco switch.
Dual-Active Detection Using IP BFD
Requires direct connection between the two switches, Regular Layer 3 ping will not function correctly on this connection, the VSS instead uses the Bidirectional Forwarding Detection (BFD) protocol.
6.15.4 Guidelines and Restrictions for VSS Dual-Active Detection
6.15.5 Recommended VSS Dual-Active Detection Configuration
General Configuration Recommendations
•
•
•
Configuration for Troubleshooting VSS Dual-Active on IP Connectivity and Interface Exclusion
interface GigabitEthernet1/1/24no switchportip address101.1.24.1 255.255.255.0interface GigabitEthernet2/3/24ip address102.3.24.1 255.255.255.0Router(config)# switch virtual domain 1Router(config-vs-domain)# dual-active exclude interface g1/1/24WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purposeRouter(config-vs-domain)# dual-active exclude interface g2/3/24WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purposeRouter(config)# ip route 198.2.1.0 255.255.255 101.1.24.2 254Router(config)# ip route 198.2.1.0 255.255.255 102.3.24.2 254
Note
6.15.6 Configuration Guide for VSS Dual-Active Detection Configuration
Configuring Dual-Active Detection
6.15.7 Related Features and Best Practices
None.
6.16 Best Practices for VSS VSLP Timers
These sections describe best practices for VSS VSLP Timers:
•
•
•
•
•
•
•
6.16.1 Description of VSS VSLP Timers
VSLP Timers are the hello messages that traverse between each end of the VSL links.
6.16.2 Benefits of the VSS VSLP Timers
VSLP timers can be configured to change the transmission interval between hello messages across VSL links.
6.16.3 Features Incompatible with VSS VSLP Timers
None.
6.16.4 Guidelines and Restrictions for VSS VSLP Timers
6.16.5 Recommended VSS VSLP Timers Configuration
It is recommended to leave VSLP Timers at default values.
6.16.6 Configuration Guide for VSS VSLP Timers
6.16.7 Related Features and Best Practices
None.
6.17 Best Practices for VSS STP features
These sections describe best practices for VSS STP features:
•
•
•
•
•
•
6.17.1 Description of STP on VSS
Spanning-Tree Protocol (STP) is a 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 Layer 2 path can exist between any two network devices.
A Virtual Switching System (VSS) is composed of two independent Catalyst 6500 switches. The two switches are combined using a special port-channel called Virtual Switch Link (VSL).
The STP algorithm is operational only on the active switch. Any BPDU (Bridge Protocol Data Unit) received on the standby port is redirected to the active switch via the VSL.
Although STP is not essential for a VSS to function, it is recommended to enable the protocol in case a loop is introduced in a Layer 2 domain by some other network device.
6.17.2 Benefits of the STP Best Practices for VSS
Since all the BPDUs are redirected to the active switch, there are implications for VSS because the port density is higher for it compared with a non-VSS switch. It is therefore important to follow the best practices for a STP deployment on VSS.
A VSS has the same restriction in terms of the virtual port (VP) instances that can be created per line card and per VSS as does a non-VSS setup. To check the VP instances currently in use please refer to show vlan virtual-port.
It is recommended to have MST (Multiple Spanning Tree) STP protocol for VSS. 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.
If the number of VLANs are not significant on the VSS then Rapid PVST (Per-VLAN Spanning Tree) can be implemented. The virtual port instances for VSS while running PVST should not exceed 1800 per linecard and 10000 combined.
6.17.3 Features Incompatible with STP on VSS
Flexlink interfaces
6.17.4 Guidelines and Restrictions for STP on VSS
Same as non-VSS
6.17.5 Recommended Configuration for STP on VSS
Same as non-VSS
6.17.6 Configuration Guide for STP on VSS
See the "Configuring MST" section for more information.
See the "Enabling Rapid PVST" section for more information.
6.17.7 Related Features and Best Practices
Configuring Optional STP Features
6.18 Best Practices for VSS in a Layer 2 Campus Environment
These sections describe best practices for VSS in a Layer 2 Campus Environment:
•
•
•
•
•
•
•
6.18.1 Description of Layer 2 Campus on VSS
VSS is recommended to be positioned as a distribution-layer switch. Multi Chassis Etherchannel (MEC) is one of the primary features now available with the implementation of VSS. It is recommended to use layer 2 MEC from the access-layer switches to the VSS. This will reduce the migration planning required to move from non-VSS infrastructure to one with VSS.
The VSS should be designated the spanning-tree root for the configured STP protocol.
6.18.2 Benefits of VSS in a Layer 2 Campus Environment
Any spanning-tree loop in a non-VSS infrastructure may cause impact to the network infrastructure because non-VSS network relies on STP to determine a loop free environment. A VSS on the other hand only uses STP as a mechanism to prevent loops. A VSS therefore makes it is easier for a network designer to derive a more robust network.
6.18.3 Features Incompatible with Layer 2 Campus on VSS
None.
6.18.4 Guidelines and Restrictions for Layer 2 campus on VSS
Same as non-VSS.
6.18.5 Recommended Configuration for Layer 2 campus on VSS
Please refer to Virtual Switching System Key Concepts section.
6.18.6 Configuration Guide for Layer 2 campus on VSS
See the "Configuring MST" section for more information.
6.18.7 Related Features and Best Practices
Configuring Optional STP Features
6.19 Best practices for SPAN on VSL
These sections describe best practices for SPAN on VSL:
•
•
•
•
•
6.19.1 Description of SPAN on VSS
Local SPAN, RSPAN, and ERSPAN sessions allow you to monitor traffic on one or more ports, or one or more VLANs, and send the monitored traffic to one or more destination ports.
In a VSS system, there are restrictions specifically on VSL ports. Since the number of SPAN sessions is same as a non-VSS system, carefully planning will be required to ensure that span traffic does not overwhelm the VSL links. These points will require the user to carefully select the number of ports to use as SPAN source and SPAN destination. Estimate the Minimum and Maximum amount of traffic that would be flowing through the VSL from the sources to the destinations, thus helping to maintain a controlled ratio of SPAN traffic and VSL capacity.
The selection of Centralized and Distributed mode of forwarding plays an important role. As in centralized mode the amount of traffic passing through the VSL depends on the which switch is the active switch. Considering the above points, the user should limit the number of vlan or ports as SPAN source and destination. One single destination port would simplify the design and would have more predictable traffic rate across the VSL. It is also recommended to have the Destination port as PO port, so that the SPAN traffic forwarded to the Destination port would not have to cross the VSL link.
6.19.2 Benefits of VSS best practices for SPAN
If carefully planning is done to monitor the high-bandwidth traffic using SPAN such that the inter-chassis monitoring is minimized, VSL will not be oversubscribed. It is also recommended to use SPAN only while troubleshooting and to be turned off when it is not required.
6.19.3 Features Incompatible
None.
6.19.4 Guidelines and Restrictions for SPAN on VSS
For details refer to the VSS SPAN restrictions.
6.19.5 Recommended Configuration for SPAN on VSS
It is recommended to use the default egress SPAN operating mode for Local SPAN, RSPAN and ERSPAN.
6.19.6 Configuration Guide for VLAN distribution on VSS
See the "Configuring Local SPAN, RSPAN, and ERSPAN" chapter for more information about the commands shown.
6.19.7 Related Features and Best Practices
None.
6.20 Best Practices for MAC Synchronization on VSS
These sections describe best practices for MAC Synchronization on VSS:
•
•
•
•
•
•
•
6.20.1 Description of MAC Synchronization on VSS
Any new MAC address learnt on any DFC based line card will be propagated to all other DFCs through hardware. This is required to keep MAC tables in sync and to enable L2 forwarding.
6.20.2 Benefits of MAC Synchronization Best Practices for VSS
In virtual switch, frames need to be sent over the VSL to the other core to have MACs learnt in all the DFCs across both cores.
6.20.3 Features Incompatible with MAC Synchronization
None.
6.20.4 Guidelines and Restrictions for MAC Synchronization on VSS
Under high MAC address table utilization in a virtual switch, there are excessive MAC Notification's generated thereby increasing VSL utilization. It is therefore recommended to set the MAC address synchronization timer to 480 seconds.
6.20.5 Recommended Configuration for MAC Synchronization on VSS
! mac-address-table synchronize activity-time 480 !6.20.6 Configuration Guide for MAC Synchronization on VSS
See mac-address-table synchronize in the Command Reference for more information.
6.20.7 Related Features and Best Practices
None.
6.21 Best Practices for Multicast on VSS
These sections describe best practices for Multicast on VSS:
•
•
•
•
•
•
•
6.21.1 Description of Multicast on VSS
The majority of Multicast-related technologies operate the same on VSS, as they already do on non-VSS Catalyst 6500. This section attempts to highlight only the differences and / or additions, which are specific to the VSS architecture.
Because the "Virtual Switch" is comprised of two Catalyst 6500 chassis (VS Active & VS Standby), IPv4 Multicast forwarding support also needs to be extended to the VS Standby.
Both of the VS chassis are connected together by an inter-chassis Virtual Switch Link (VSL), which is shared by both internal control traffic and data traffic, between the two chassis. Multicast routing-protocols and software-switching operate only on the VS Active Route-Processor.
Hence, IGMP & PIM protocol packets received on the VS Standby chassis MUST be redirected to the VS Active chassis, via the VSL. This also applies to VS Standby SP & DFC Statistics, "Partial-Shortcuts" (e.g. Multicast NAT), as well as "Exception-Packets (e.g. non-RPF failures).
In addition, IGMP & PIM protocol packets are redirected to both the VS Active & Standby Switch-Processors, in order to provide IGMP & PIM snooping and L2 SSO capabilities.
6.21.2 Benefits of Multicast on VSS Best Practices
Multicast data forwarding is intended to distribute packets to multiple destinations, without the inefficiencies associated with broadcast and / or multiple (mesh) unicast forwarding designs.
However, the state-driven nature of Multicast coupled with poor network and / or configuration design, can actually lead to inefficient data forwarding, or even loss of data and other system resources.
This is particularly applicable to Catalyst 6500 VSS, because the overall number of modules, interfaces, and the related configuration and routing protocols, are potentially much higher than non-VSS designs.
Thus, utilizing Best Practices will help you to insure a consistent and stable behavior of Multicast data forwarding, when deployed on VSS.
6.21.3 Features Incompatible with Multicast on VSS
•
•
•
6.21.4 Guidelines and Restrictions for Multicast on VSS
Note
Due to the (possible) large number of available modules and interfaces in VSS mode, the current guidelines & restrictions will apply:
•
•
•
Other then the general scalability guidelines listed above, Multicast on VSS should operate in the same way as it does on non-VSS Catalyst 6500 systems.
6.21.5 Recommended Multicast on VSS Configuration
Note
These sub-sections describe the recommended configuration for Multicast on VSS:
•
•
•
6.21.5.1 Platform Independent Multicast Configuration
All of the existing Platform Independent Multicast Configurations also apply to VSS.
6.21.5.2 Platform Dependent (non-VSS) Multicast Configuration
All of the existing Platform Dependent (non-VSS) Multicast Configurations also apply to VSS.
6.21.5.3 Multicast Replication Mode
Use the default Multicast replication mode.
Note
6.21.5.4 Multicast Redundancy (NSF/SSO)
Use the default Multicast NSF convergence timers.
Note
6.21.5.5 Multicast Timers
Note
If you have > 50 PIM neighbors, use the default (30 seconds) PIM query-interval.
If your topology has < 50 neighbors, use (non-default) > or = 10 second PIM query-interval.
Use the default IGMP related timers.
Use the default Multicast Flow Statistics Interval (1/4 every 25 seconds).
6.21.5.6 Multicast over MEC
Use the default Etherchannel load-balancing algorithm.
Note
Wherever possible, you should utilize > or = 2 port Multi-chassis Ether-Channels (MECs) to connect to all of your PIM (or PIM Snooping) neighbors, L2 (IGMP Snooping-capable) switches, and LACP-capable Network Interface Cards (NICs).
This will provide additional bandwidth (via load-balancing), and will insure minimal Multicast traffic loss, during an individual link or module failure, and/or during SSO, without the need for unicast and/or spanning-tree re-convergence.
Refer to the MEC Best Practices documentation for additional information.
6.21.6 Configuration Guide for Multicast on VSS
Note
Refer to the following URLs for additional Multicast configuration information:
•
•
6.21.7 Related Features and Best Practices
6.22 Best Practices for VSS QoS
These sections describe best practices for VSS QoS:
•
•
•
•
•
•
6.22.1 Description of Routing Protocol Prioritization traversing VSL
All routing protocol packets need to reach the Active RP to be processed. When the routing protocol packets ingress the Standby switch, they need to traverse the VSL links in order for them to reach the Active RP on the Active Switch.
If PFC QoS is enabled globally, all ports in the VSS will be set to untrusted, except for the VSL links which are always QoS enabled regardless of the global PFC QoS setting. This will cause routing protocol packets ingressing the VSS to lose their precedence marking.
Since the routing protocol packets are not marked, if the VSL links are oversubscribed, the routing protocol packets would not be prioritized while traversing the VSL links and could get dropped, this could cause routing protocol flaps.
This best practice includes recommendations that will keep the routing protocol packets from losing their markings when ingressing the Standby switch so they can be prioritized while traversing the VSL links.
6.22.2 Benefits of Routing Protocol Prioritization traversing VSL
By enabling Routing Protocol Prioritization, the routing protocol packets will be treated with higher priority while traversing the VSL links.
6.22.3 Features Incompatible with Routing Protocol Prioritization traversing VSL
None.
6.22.4 Guidelines and Restrictions for Routing Protocol Prioritization traversing VSL
•
•
6.22.5 Recommended Configuration for Routing Protocol Prioritization traversing VSL
•
!--- Precedence of 6 is recommended Router(config)# mls qos protocol protocol_name precedence 6
Note
•
Router(config-if)# mls qos trust ip-precOr:
Router(config-if)# mls qos trust dscp6.22.6 Configuration Guide for QoS
See the "Configuring PFC QoS" chapter for more information about the commands shown.
6.22.7 Related Features and Best Practices
None.
6.23 Best Practices for Supervisor Engine 720-10G VSS for VSL
These sections describe best practices for Supervisor Engine 720-10G VSS for VSL:
•
•
•
•
•
•
•
6.23.1 Description of 10G-Only Mode for VSL
The 10 Gigabit Ethernet uplink ports on the Supervisor Engine 720-10G VSS can be used to form a VSL. By default, the queue structure of the three Gigabit Ethernet uplink ports & the two 10 Gigabit Ethernet uplink ports is 2q4t on receive and 1p3q4t on transmit, however, these queue structures can be optimized for the 10 Gigabit Ethernet uplink ports to an 8q4t queue structure on receive and 1p7q4t queue structure on transmit by enabling 10g-only mode.
6.23.2 Benefits of 10G-Only Mode for VSL
By enabling 10G-only mode, the queue structures of the 10 Gigabit Ethernet uplink ports on the Supervisor Engine 720-10G VSS are increased from 2q4t on receive and 1p3q4t on transmit to 8q4t on receive and 1p7q4t on transmit. A higher number queues implies a higher number of traffic classifications that can be treated differently. In other words, more options will exist for classifying important traffic to ensure that it is not dropped if the VSL links are oversubscribed.
The queue structures in 10G-only mode for the Supervisor Engine 720-10G VSS 10 Gigabit Ethernet uplink ports are exactly the same as the ports on the 8-port 10 Gigabit Ethernet line card (WS-X6708-10G-3C/XL).
6.23.3 Features Incompatible with 10G-Only Mode for VSL
IP-BFD dual-active detection cannot be configured on the Supervisor Engine 720-10G VSS Gigabit Ethernet uplink ports in 10G-only mode. IP-BFD dual-active detection is only supported on Gigabit Ethernet ports and the three Gigabit Ethernet uplink ports on the Supervisor Engine 720-10G VSS have to be shutdown to enable 10G-only mode.
6.23.4 Guidelines and Restrictions for 10G-Only Mode for VSL
To enable 10G-only mode, the Gigabit Ethernet uplink ports on the Supervisor Engine 720-10G VSS have to be shutdown.
6.23.5 Recommended 10G-Only Mode for VSL Configuration
•
Router# show mls qos | include 10g QoS 10g-only mode supported: Yes [Current mode: Off] Router#•
Router# show queueing interface t1/5/4 | include type Transmit queues [type = 1p3q4t]: Receive queues [type = 2q4t]: Router#•
Router(config)# mls qos 10g-only Error: following ports have to be shut to enable 10g-only mode: Gi1/5/1 Gi1/5/2 Gi1/5/3 Gi2/5/1 Gi2/5/2 Gi2/5/3 Command Rejected! Router(config)# interface range g1/5/1-3 , g2/5/1-3 Router(config-if-range)# shutdown Router(config-if-range)# exit Router(config)# mls qos 10g-only HWIF-QOS: Queuing qos cfg (wrr-queue/rcv-queue/priority-queue) will be reset to default on Supervisor Switch 1 slot 5 interfaces! HWIF-QOS: Queuing qos cfg (wrr-queue/rcv-queue/priority-queue) will be reset to default on Supervisor Switch 2 slot 5 interfaces! Router(config)# endRouter# show mls qos | include 10g QoS 10g-only mode supported: Yes [Current mode: On] Router#•
Router# show queueing interface t1/5/4 | include type Transmit queues [type = 1p7q4t]: Receive queues [type = 8q4t]: Router#6.23.6 Configuration Guide for 10G-only mode for VSL
See the "Configuring PFC QoS" chapter for more information about the commands shown.
6.23.7 Related Features and Best Practices
None.
6.24 Best Practices for Layer 2 QoS on the VSS
These sections describe best practices for Layer 2 QoS on the VSS:
•
•
•
•
•
•
•
6.24.1 Description of Layer 2 QoS on the VSS
In a Cisco Virtual Switching System, application of QoS service policies (port-based QoS) on physical Layer 2 interfaces (switchport mode access and trunk) is prohibited. This is due to a limitation where only a limited number of interfaces can be indexed uniquely for QoS purposes. QoS service policies can only be applied on Layer 2 Cisco EtherChannel links or multichassis EtherChannel (MEC) and on Layer 3 interfaces (SVIs, physical interfaces, port channels, etc.).
If a policy needs to be set for physical layer 2 interfaces, since Port Based QoS is not supported, VLAN Based QoS can be used instead. All that is required is for ports to be marked indicating they are part of a VLAN QoS policy and to apply the policy on the SVI.
6.24.2 Benefits of VLAN Based QoS on the VSS
To overcome the Port-based QoS limitation on physical interfaces, VLAN Based QoS can be used instead.
6.24.3 Features Incompatible with VLAN Based QoS on the VSS
None.
6.24.4 Guidelines and Restrictions for Layer 2 QoS on the VSS
Port Based QoS is not supported in current software releases.
6.24.5 Recommended VLAN Based QoS Configuration on the VSS
mls qos vlan-based needs to be configured on all physical ports where the policy needs to be applied:
Router(config-if)# interface g1/3/1 Router(config-if)# switchportRouter(config-if)# mls qos vlan-based Router(config-if)# exitRouter(config)# interface vlan 100 Router(config)# service-policy input test
Note
6.24.6 Configuration Guide for VLAN Based QoS
See the "Configuring PFC QoS" chapter for more information about the commands shown.
6.24.7 Related Features and Best Practices
None.
6.25 Best Practices for VSS Etherchannel Load Distribution
These sections describe best practices for VSS Etherchannel Load Distribution:
•
•
•
•
•
•
6.25.1 Description of VSS Etherchannel Load Distribution
When a member is added or removed from the EtherChannel bundle, the load register has to be reprogrammed for all the member ports, resulting in packet loss in a window of approximately 0.03 seconds. This reprogramming is done using the "fixed" load distribution algorithm.
Although the window of 0.03 seconds may seem small, it translates to a large loss on a high bandwidth 10GE port such as the Virtual Switch Link (VSL).
To alleviate this problem, the "adaptive" load distribution algorithm was formulated. This new algorithm allows this RBH reprogramming to be done exclusively on each port, and will result in lower packet loss during the port addition or removal.
6.25.2 Benefits of Adaptive Load Distribution Algorithm
The main benefit of this feature usage is lower packet loss on high bandwidth bundle interfaces, when the port-channel's member interfaces join or leave the bundle.
6.25.3 Features Incompatible with Adaptive Load Distribution Algorithm
None.
6.25.4 Guidelines and Restrictions for Adaptive Load Distribution Algorithm
None.
6.25.5 Recommended Configuration
•
Router(config)# port-channel hash-distribution adaptive•
Router(config)# interface port-channel channel_number Router(config-if)# port-channel port hash-distribution adaptive6.25.6 Configuration Guide for VSS Etherchannel Load Distribution
Configuring Virtual Switching Systems
6.25.7 Related Features and Best Practices
None.
6.26 Best Practices for Etherchannel Min-Links in VSS
These sections describe best practices for Etherchannel Min-Links in VSS:
•
•
•
•
•
•
•
6.26.1 Description for EtherChannel Min-Links in VSS
LACP minlinks (minimum links) feature allows certain number of configurable ports within a port-channel bundle, thereby guaranteeing a fixed bandwidth. When the number of member ports in the EtherChannel fall below the configured value, the port-channel is deemed unusable, allowing traffic to use an alternate route, and hence guaranteeing bandwidth, if configured.
In Virtual Switch, this feature has been enhanced for Multi-chassis EtherChannel, where the "minimum links" requirement is enforced per chassis.
6.26.2 Benefits of Etherchannel Min-Links Best Practices
This feature in Virtual Switch allows traffic to egress a port-channel, in each chassis, with configurable guaranteed bandwidth.
It is recommended to have multiple member interfaces (2+) in each chassis for the selected EtherChannel bundle.
6.26.3 Features Incompatible with Etherchannel Min-Links
None.
6.26.4 Guidelines and Restrictions for Etherchannel Min-Links
This feature is restricted for EtherChannel bundles running LACP (802.1ad). It is not supported for EtherChannel bundles running PAgP.
Minimum configurable value for min-links is 2, hence a minimum of 2 links in each chassis are required for the MEC to remain effective.
Following examples illustrate the min-links feature:
•
interface Port-channel25no switchportport-channel min-links2end•
vip-vs1# show etherchannel 25 summaryFlags: D - down P - bundled in port-channelI - stand-alone s - suspendedH - Hot-standby (LACP only)R - Layer3 S - Layer2U - in use N - not in use, no aggregationf - failed to allocate aggregatorM - not in use, no aggregation due to minimum links not metm - not in use, port not aggregated due to minimum links not metu - unsuitable for bundlingd - default portw - waiting to be aggregatedNumber of channel-groups in use: 125Number of aggregators: 125Group Port-channel Protocol Ports------+-------------+-----------+-----------------------------------------------25 Po25(RU) LACP Gi1/3/1(D) Gi1/3/2(m) Gi2/2/25(P)Gi2/2/26(P)Last applied Hash Distribution Algorithm: Adaptive•
vip-vs1# show etherchannel 25 summaryFlags: D - down P - bundled in port-channelI - stand-alone s - suspendedH - Hot-standby (LACP only)R - Layer3 S - Layer2U - in use N - not in use, no aggregationf - failed to allocate aggregatorM - not in use, no aggregation due to minimum links not metm - not in use, port not aggregated due to minimum links not metu - unsuitable for bundlingd - default portw - waiting to be aggregatedNumber of channel-groups in use: 125Number of aggregators: 125Group Port-channel Protocol Ports------+-------------+-----------+-----------------------------------------------25 Po25(RM) LACP Gi1/3/1(D) Gi1/3/2(D) Gi2/2/25(D)Gi2/2/26(w)Last applied Hash Distribution Algorithm: Adaptive6.26.5 Recommended Etherchannel Min-Links Configuration
Router# configure terminalRouter(config)# interface gigabitethernet 1/3/1Router(config-if)# channel-group 25 mode activeRouter(config-if)# exitRouter(config)# interface gigabitethernet 1/3/2Router(config-if)# channel-group 25 mode activeRouter(config-if)# exitRouter(config)# interface gigabitethernet 2/2/25Router(config-if)# channel-group 25 mode activeRouter(config-if)# exitRouter(config)# interface gigabitethernet 2/2/26Router(config-if)# channel-group 25 mode activeRouter(config-if)# exitRouter(config)# interface port-channel 25Router(config-if)# port-channel min-links 2Router(config-if)# end6.26.6 Configuration Guide for Etherchannel Min-Links
Configuring Virtual Switching Systems
6.26.7 Related Features and Best Practices
None.
6.27 Best Practices for LACP Port-Channel Port-Priority in VSS
These sections describe best practices for LACP Port-Channel Port-Priority in VSS:
•
•
•
•
•
•
•
6.27.1 Description of LACP Port-Channel Port-Priority in VSS
LACP port-priority feature allows LACP system manager switch to prioritize the port aggregation within a port-channel.
For Virtual Switch Systems, LACP port priority plays significant role in Multi-Chassis Etherchannel (MEC) as to which ports are added/removed or put in hot standby within the bundle.
6.27.2 Benefits of LACP Port-Channel Port-Priority in VSS
In VSS system, when multiple (2+) interfaces off Switch-ID 1 and Switch-ID 2 are aggregated in a MEC, it is recommended to configure the port priority in an interleaved fashion across Switch-id chassis.
6.27.3 Features Incompatible with LACP Port-Channel Port-Priority in VSS
None.
6.27.4 Guidelines and Restrictions for LACP Port-Channel Port-Priority in VSS
This feature is restricted for LACP (802.1ad) EtherChannel bundles.
It is recommended to set the LACP system priority on VSS to higher value than the connected peer, to allow the VSS to manage the aggregation of the ports in the EtherChannel bundle.
6.27.5 Recommended LACP Port-Channel Port-Priority in VSS
Following examples illustrate the recommendation for inter-leaving port-priority in MEC member interfaces when used along with LACP max-bundle feature.
•
interface Port-channel25no switchport•
interface GigabitEthernet1/3/1channel-group25 mode activelacp port-priority1!interface GigabitEthernet1/3/2channel-group25 mode activelacp port-priority3!interface GigabitEthernet2/2/25channel-group25 mode activelacp port-priority2!interface GigabitEthernet2/2/26channel-group25 mode activelacp port-priority4end•
Router# show etherchannel 25 summaryFlags: D - down P - bundled in port-channelI - stand-alone s - suspendedH - Hot-standby (LACP only)R - Layer3 S - Layer2U - in use N - not in use, no aggregationf - failed to allocate aggregatorM - not in use, no aggregation due to minimum links not metm - not in use, port not aggregated due to minimum links not metu - unsuitable for bundlingd - default portw - waiting to be aggregatedNumber of channel-groups in use: 125Number of aggregators: 125Group Port-channel Protocol Ports------+-------------+-----------+--------------------------------------------------25 Po25(RU) LACP Gi1/3/1(P) Gi1/3/2(H) Gi2/2/25(P)Gi2/2/26(H)Last applied Hash Distribution Algorithm: Adaptive
Note
Router# configure terminalRouter(config)# lacp system-priority 32000Router(config)# interface gigabitethernet 1/3/1Router(config-if)# channel-group 25 mode activeRouter(config-if)# lacp port-priority 1Router(config-if)# exitRouter(config)# interface gigabitethernet 1/3/2Router(config-if)# channel-group 25 mode activeRouter(config-if)# lacp port-priority 3Router(config-if)# exitRouter(config)# interface gigabitethernet 2/2/25Router(config-if)# channel-group 25 mode activeRouter(config-if)# lacp port-priority 2Router(config-if)# exitRouter(config)# interface gigabitethernet 2/2/26Router(config-if)# channel-group 25 mode activeRouter(config-if)# lacp port-priority 4Router(config-if)# exitRouter(config)# interface port-channel 25Router(config-if)# lacp max-bundle 2Router(config-if)# end6.27.6 Configuration Guide for LACP Port-Channel Port-Priority in VSS
None.
6.27.7 Related Features and Best Practices
None.
6.28 Best Practices for VSS L3
These sections describe best practices for VSS L3:
•
•
•
•
•
•
•
6.28.1 Preference of MEC over FHRP protocols
The fundamental purpose of FHRP protocols like HSRP and VRRP is to provide first hop redundancy for the hosts. To which GLBP provides additional feature to load balance the traffic between the available redundant first hope links. Both the above features are taken care of by Multi-Ether channel Configuration between the hosts and VSS, as VSS setup provide the necessary Chassis level redundancy. Thus it is recommended instead of FHRP protocols, MEC be implemented wherever possible.
6.28.2 Benefits of MEC over FHRP protocols
The inherit characteristic of MEC provides the necessary redundancy for the hosts to forward the traffic.
FHRP protocols take a heavy toll on the CPU due to the periodic hello messages (Control Plane). Thus getting rid of FHRP protocols will reduce CPU usages.
6.28.3 Features Incompatible
None.
6.28.4 Guidelines and Restrictions
None.
6.28.5 Recommended Configuration
Routing Protocol Timers Configuration
Benefits of Having Default Timer Configuration
L3 MEC Preference Between Distribution and Core Layer
Routing Protocols Design on VSS
6.28.5.1 Routing Protocol Timers Configuration
Currently, IOS provides aggressive routing protocol timers to help network converged very fast under fault situation. However, it is counter-productive if a router has hardware redundancy built-in. The basic idea is that we do not want layer 3 protocols being too sensitive to hardware fault. We have a better fault handling mechanism in MEC.
Traffic interruption lasts only from the time upstream switch detect link down event until upstream switch select alternate ether-channel member. This interruption is much short than any routing protocol able to perform. Therefore, we recommend not changing routing protocol timers, and we would like to enable NSF on all routing protocols.
6.28.5.2 Benefits of Having Default Timer Configuration
Having a default timer setting would make the system more robust in responding to the changes in the topology.
Features Incompatible
None.
Guidelines and Restrictions
The neighboring devices should be NSF aware.
Recommended Configuration
To enable NSF on the routing protocol like OSPF following configuration is needed:
router ospf6nsfConfiguration Guide
None.
6.28.5.3 L3 MEC Preference Between Distribution and Core Layer
When placing virtual switch in core layer, or when MEC linking to core switch, these MEC links should be configured as layer-3 port-channels. Although, we can use SVI and layer 2 MEC implementation. A layer-3 port-channel implementation enables routing protocols responding to link down events a lot faster. Here is the logic. If we use SVI and deploy OSPF. There are MEC link and some other links belonged to this SVI, when MEC goes down, however, this SVI being a virtual interface is still up because there is at least one link active. OSPF will re-converge only when dead timer expires. However, if we use layer-3 ether-channels, soon as the link goes down, link down event will trigger OSPF re-convergence.
On the other end, it is recommended when placing virtual switch in distribution layer, MEC linking to access switches are better setup as trunk ports and use SVIs to terminate VLANs. This way, a VLAN domain can spread multiple switches. Enable flexibility to topology changes.
Benefits of Best Practices
Having L3 MEC will have more quick and robust response to the change in the network topology.
Features Incompatible
None.
Guidelines and Restrictions
None.
Recommended Configuration
None.
Configuration Guide
None.
6.28.5.4 Routing Protocols Design on VSS
It is recommended to avoid routing protocol peering on a single routed port. As apart from the routing resiliency issues such a design encourages traffic flow through the VSL links which is not recommended. Also, it is not a good design to have routing protocol peering with both active and standby switch to achieve routing resiliency for the traffic. This is because in case of failure of one of the link, the time taken for the traffic to converge is equal to the convergence time for protocol. (That directly depends on hold-down time of dynamic routing protocol). If L3 MEC is used, the traffic convergence is instant. The other disadvantages are having multiple routing protocol neighbors means increase in control traffic thus increase in CPU utilization.
Benefits of have good Routing Protocol Design on VSS
Proper Routing protocol design have numerous benefits that helps in keeping check on CPU utilization, traffic flowing across the VSL link, convergence and predictable flow of traffic.
Features Incompatible
None.
Guidelines and Restrictions
None.
Recommended Configuration
None.
Configuration Guide
None.
Feedback