Cisco 6500 - Catalyst Series 10 Gigabit EN Interface Module... User manual

Cisco Catalyst 6500 Virtual Switching System
Deployment Best Practices
Document ID: 109547
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
VSS Deployment Best Practices
VSS High Availability
Upstream Link Recovery
VSL Link Loss and Recovery
Redundancy with Service Modules
Multicast
Qualtiy of Service
SPAN
Miscellaneous
Frequently Asked Questions
Can dual supervisors be used in each chassis with VSS?
When removing the preempt commands in Catalyst 6500 Series Switches in VSS Mode, will it reload the
switches?
Related Information
Introduction
This document provides best practices for Cisco Catalyst 6500 Virtual Switching System (VSS) 1440
deployment scenarios.
This document provides modular configuration guidance. Therefore, you can read each section independently
and make changes in a phased approach. This document assumes a basic comprehension and familiarity with
the Cisco IOS® Software user interface. The document does not cover overall network design.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.

Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
VSS Deployment Best Practices
The solutions that this document offers represent years of field experience from Cisco engineers who work
with complex networks and many of the largest customers. Consequently, this document emphasizes
configurations that make networks successful. This document offers these solutions:
Solutions that are easy to manage and that network operations teams configure• Solutions that promote high availability and high stability•
VSS High Availability
Non Stop Forwarding• OOB MAC Synchronization•
Non Stop Forwarding
Catalyst 6500 series switches support fault resistance, because it allows a redundant supervisor engine to take
over if the primary supervisor engine fails. Cisco Non Stop Forwarding (NSF) works with Stateful
SwitchOver (SSO) in order to minimize the amount of time a network is unavailable to its users after a
switchover while IP packets continue to be forwarded.
Recommendations
Non Stop Forwarding is required for supervisor switchover convergence at sub−second time.• Use default Hello and Dead timers for EIGRP / OSPF protocols when you run in a VSS environment.• If you run the system with modular Cisco IOS software, it is recommended to go for larger value
OSPF Dead timer.
•
EIGRP
Switch(config)# router eigrp 100
Switch(config−router)# nsf
Switch# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
!−−− part of the output truncated
EIGRP NSF−aware route hold timer is 240s
!−−− indicates that EIGRP is configured to be NSF aware
!−−− part of the output truncated
EIGRP NSF enabled
!−−− indicates that EIGRP is configured to be NSF capable
!−−− rest of the output truncated

OSPF
Switch(config)# router ospf 100
Switch(config−router)# nsf
Switch# show ip ospf
Routing Process "ospf 100" with ID 10.120.250.4
Start time: 00:01:37:484, Time elapsed: 3w2d
!−−− part of the output truncated
Supports Link−local Signalling (LLS)
!−−− indicates that OSPF is configured to be NSF aware
!−−− part of the output truncated
Non−Stop Forwarding enabled, last NSF restart 3w2d ago (took 31 secs)
!−−− indicates that OSPF is configured to be NSF capable
!−−− rest of the output truncated
Refer to Configuring NSF with SSO Supervisor Engine Redundancy for more information on NSF.
OOB MAC Synchronization
In distributed switching, each Distributed Feature Card (DFC) maintains its own CAM table. This means that
each DFC learns the MAC address and ages them, which depends on the CAM aging and traffic matching of
that particular entry. With distributed switching, it is normal that the supervisor engine does not see any traffic
for a particular MAC address for a while, so the entry can expire. There are currently two mechanisms
available to keep the CAM tables consistent between the different engines, such as DFC, which is present in
line modules, and Policy Feature Card (PFC), which is present in supervisor modules:
Flood to Fabric (FF)• MAC Notification (MN)•
When a MAC address entry is aged out on the PFC, the show mac−address address <MAC_Address> all
command displays the DFC or PFC that holds this MAC address. In order to prevent the age out of an entry
on a DFC or PFC, even if there is not traffic for that MAC address, enable the MAC address synchronization.
Issue the mac−address−table synchronize global configuration command and clear mac−address−table
dynamic privileged EXEC command in order to enable the synchronization. This mac−address−table
synchronize command is available from Cisco IOS Software Releases 12.2(18)SXE4 and later. After you
enable it, it is possible to still see entries that are not present in PFC or DFC. However, the module has a way
to learn it from others that use Ethernet Out of Band Channel (EOBC).
Recommendations
Enable Out−of−Band MAC synchronization. It is used in order to synchronize mac−address tables across the
forwarding engines. If WS−6708−10G is present in the VSS system, MAC synchronization is automatically
enabled. If not, it must be enabled manually.
Dist−VSS(config)# mac−address−table synchronize
% Current activity time is [160] seconds

% Recommended aging time for all vlans is atleast three times the activity interval
Dist−VSS# clear mac−address−table dynamic
% MAC entries cleared.
Dist−VSS# show mac−address−table synchronize statistics
MAC Entry Out−of−band Synchronization Feature Statistics:
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Switch [1] Module [4]
−−−−−−−−−−−−−−−−−−−−−
Module Status:
Statistics collected from Switch/Module : 1/4
Number of L2 asics in this module : 1
Global Status:
Status of feature enabled on the switch : on
Default activity time : 160
Configured current activity time : 480
VSS Terminology
Virtual Switch Link (VSL)A special port channel required to bundle two physical switches into
one virtual switch.
•
VSL Protocol (VSLP)Runs between active and standby switch over the VSL, and has two
components: LMP and RRP
Link Management Protocol (LMP)Runs over each individual link in VSL♦ Role Resolution Protocol (RRP)Runs on each side (each peer) of the VSL port channel♦
•
Capacity Planning for VSL
Ideally in dual−homed VSS configuration, no data traffic is sent on the VSL link. Each switch is programmed
to choose its local interfaces for traffic forwarding.
Additional VSL link capacity planning is required for traffic carried by:
Single homed devices• Remote SPAN from one switch to another• Service module traffic â€ FWSM, ACE, etc.•

Refer to Traffic on the VSL for more information.
Recommendations
Always dual−home devices connected to VSS.• Always bundle VSL EtherChannel in the power of 2, because it has better hash results for
optimized traffic load−sharing.
•
Redundancy of the VSL is still critical along with resiliency of VSL links.• The recommendation is to atleast have VSL bandwidth equal to uplinks connected to a single physical
switch.
•

Upstream Link Recovery
The recovery of upstream links (links to the core) can be attained through either MultiChassis EtherChannel
(MEC) or the Equal Cost MultiPath (ECMP) feature.
MEC convergence is consistent and independent of the number of routes. Whereas, ECMP convergence is
dependent on the number of routes. This graph indicates the magnitude of loss in a voice session.
These images show link failure scenarios with MEC and ECMP:

MultiChassis EtherChannel
A MultiChassis EtherChannel is an EtherChannel with ports that terminate on both chassis of the VSS. A VSS
MEC can connect to any network element that supports EtherChannel, such as a host, server, router, or switch.
At the VSS, an MEC is an EtherChannel with additional capability. The VSS balances the load across ports in
each chassis independently. For example, if traffic enters the active chassis, the VSS selects an MEC link
from the active chassis. This MEC capability ensures that data traffic does not unnecessarily traverse the VSL.
L2 MEC enables loop free topology, doubles the uplink bandwidth as no links are blocked and
provides faster convergence than STP.
•
L3 MEC provides reduced neighbor counts, better load−sharing (L2 and L3 for unicast and
multicast), reduced VSL link utilization for multicast flows and faster convergence than ECMP.
•
Refer to Multichassis EtherChannels for more information on MEC.
Recommendations
Always run L2 or L3 MEC.• Do not use on and off options with PAgP or LACP or Trunk protocol negotiation.
PAgP â€ Run Desirable−Desirable with MEC links.♦ LACP â€ Run Active−Active with MEC links.♦ Trunk â€ Run Desirable−Desirable with MEC links.♦
•

VSL Link Loss and Recovery
If the VSL fails, the standby chassis cannot determine the state of the active chassis. In order to ensure that
switchover occurs without delay, the standby chassis assumes the active chassis has failed and initiates
switchover to take over the active role.
If the original active chassis is still operational, both chassis are now active. This situation is called a
dual−active scenario. A dual−active scenario can have adverse affects on network stability, because both
chassis use the same IP addresses, SSH keys, and STP bridge ID. The virtual switching system (VSS) must
detect a dual−active scenario and take recovery action.
The virtual switching system supports these three methods in order to detect a dual−active scenario:
Enhanced PAgP â€ Uses PAgP messaging over the MEC links in order to communicate between the
two chassis through a neighbor switch. Enhanced PAgP is faster than IP BFD, but requires a neighbor
switch that supports the PAgP enhancements.
•

ePAgP Support Table:
Device Series Minimum Cisco IOS Software
Cisco Catalyst 3750 Cisco IOS 12.2(46)SE
Cisco Catalyst 4500 Cisco IOS 12.2(44)SE
Cisco Catalyst 6500 Cisco IOS 12.2(33)SXH
Cisco Catalyst 6500 VSS Cisco IOS 12.2(33)SXH1
IP Bidirectional Forwarding Detection (BFD) â€ Uses BFD messaging over a backup Ethernet
connection. IP BFD uses a direct connection between the two chassis and does not require support
from a neighbor switch. This method is available in Cisco IOS Software Release 12.2(33)SXH1 and
later.
•
VSLP dual−active fast−hello â€ Uses special hello messages over a backup Ethernet connection.
Dual−active fast−hello is faster than IP BFD and does not require support from a neighbor switch.
This method is available only in Cisco IOS Software Release 12.2(33)SXI and later.
•
You can configure all three detection methods to be active at the same time.
These graphs give information on the convergence of some IP routing protocols with regard to VSS dual
active convergence.
EIGRP Convergence with Default timers

OSPF Convergence with Default timers
Recommendations
Enable atleast two links in VSL.• Use MEC with ePAgP or MEC with VSLP Fast Hello for faster VSL link loss convergence results.• Enable ECMP with IP−BFD.• Enable ePAgP to core, if the access layer is not ePAgP capable.• Enable both ePAgP an direct heart beat link based VSLP Fast Hello methods, if possible.• During VSL loss and recovery process do not perform configuration changes.
After atleast one VSL member link is restored, if configuration on old ACTIVE chassis is
unchanged, old ACTIVE reboots itself to boot in VSS hot−standby redundancy state.
*Apr 6 17:36:33:809: %VSLP−SW1_SP−5−VSL_UP: Ready for Role Resolution with
Switch=2, MAC=0013a.30e1.6800 over Te1/5/5
*Apr 6 17:36:36.109: %dualACTIVE−1−VSL_RECOVERED: VSL has recovered during
dual ACTIVE situation: Reloading switch 1
!−−− part of output truncated
♦
•