Configuring Cisco Stackwise Virtual
Configuring Cisco Stackwise Virtual
Note This applies to all Layer 3 ports, SVIs, and routed ports. This does not apply to
GigabitEthernet0/0 port.
• On C9500-32C switches, you can configure SVL and DAD only on interfaces numbered 1-16 on the
front panel of the switch.
• On C9500-32QC, you can configure SVL and DAD only on native 100G and 40G interfaces (default
configuration ports). You cannot configure SVL and DAD on converted 100G and 40G interfaces.
• On Cisco Catalyst 9500 Series High Performance Switches, configuring SVL using 1G interfaces is not
supported.
Cisco Catalyst 9500 Series Switches Cisco Catalyst 9500 Series High Performance
Switches
C9500-24Q C9500-32C
C9500-12Q C9500-32QC
C9500-40X C9500-24Y4C
C9500-16X C9500-48Y4C
• You can establish SVLs using 40G or 10G Ethernet connections (downlink connections) on Cisco Catalyst
9500 Series Switches and 100G, 40G, 25G and 10G Ethernet connections on Cisco Catalyst 9500 Series
High Performance Switches.
• You can configure upto 8 SVLs in a Cisco StackWise Virtual solution using Cisco Catalyst 9500 Series
Switches or Cisco Catalyst 9500 Series High Performance Switches.
We recommend Cisco StackWise Virtual model for aggregation layers and collapsed aggregation and core
layers. The stack can be formed over a redundant 100G, 25G, 40G or 10G fiber links to ensure that the
distribution or the aggregation switches can be deployed over a large distance.
Note that STP keeps one of the ports connected to the distribution switches blocked on the access switches.
As a result of this, an active link failure causes STP convergence and the network suffers from traffic loss,
flooding, and a possible transient loop in the network. On the other hand, if the switches are logically merged
into one switch, all the access switches might form an EtherChannel bundle with distribution switches, and
a link failure within an EtherChannel would not have any impact as long as at least one member within the
EtherChannel is active.
Figure 1: Typical Network Design using Cisco StackWise Virtual
Etherchannel in StackWise Virtual is capable of implementing Multi-chassis EtherChannel (MEC) across the
stack members. When access layer and aggregation layer are collapsed into a single StackWise Virtual system,
MEC across the different access layer domain members and across distribution and access layer switches will
not be supported. MEC is designed to forward the traffic over the local link irrespective of the hash result.
Since the control plane, management plane, and data plane are integrated, the system behaves as a single
switch.
The virtualization of multiple physical switches into a single logical switch is from a control and management
plane perspective only. Because of the control plane being common, it may look like a single logical entity
to peer switches. The data plane of the switches is distributed. Each switch is capable of forwarding over its
local interfaces without involving other members. However, when a packet coming into a switch has to be
forwarded over a different member’s port, the forwarding context of the packet is carried over to the destination
switch after ingress processing is performed in the ingress switch. Egress processing is done only in the egress
switch. This provides a uniform data plane behavior to the entire switch irrespective whether of the destination
port is in a local switch or in a remote switch. However, the common control plane ensures that all the switches
have equivalent data plane entry for each forwarding entity.
An election mechanism elects one of the switches to be Cisco StackWise Virtual active and the other switch
to be Cisco StackWise Virtual standby in terms of Control Plane functions. The active switch is responsible
for all the management, bridging and routing protocols, and software data path. The standby switch is in hot
standby state ready to take over the role of active, if the active switch fails over.
The following are the components of the Cisco StackWise Virtual solution:
• Stack members
• StackWise Virtual link: 100G, 25G, 40G or 10G Ethernet connections. SVL is established using the
100G, 25G, 40G or 10G interfaces depending on the switch models. However, a combination of two
different speeds is not supported.
StackWise Virtual link is the link that connects the switches over Ethernet. Typically, Cisco StackWise Virtual
consists of multiple 100G, 25G, 40G or 10G physical links. It carries all the control and data traffic between
the switching units. You can configure a StackWise Virtual link on a supported port. When a switch is powered
up and the hardware is initialized, it looks for a configured StackWise Virtual link before the initialization of
the control plane.
The Link Management Protocol (LMP) is activated on each link of the StackWise Virtual links as soon as the
links are established. LMP ensure the integrity of SVL links and monitors and maintains the health of the
links. The redundancy role of each switch is resolved by the StackWise Discovery Protocol (SDP). It ensures
that the hardware and software versions are compatible to form the SVL and determines which switch becomes
active or standby from a control plane perspective.
Cisco StackWise Virtual Header (SVH) is 64-byte frame header that is prepended over all control, data, and
management plane traffic that traverse over each SVL between the two stack members of the Cisco StackWise
Virtual domain. The SVH-encapsulated traffic operates at OSI Layer 2 and can be recognized and processed
only by Cisco StackWise Virtual-enabled switches. SVL interfaces are non-bridgeable and non-routeable,
and allows non-routeable traffic over L2 or L3 network.
• The Cisco StackWise Virtual active and standby switches perform data traffic forwarding.
Note If the Cisco StackWise Virtual active switch fails, the standby switch initiates a switchover and assumes the
Cisco StackWise Virtual active switch role.
SSO Redundancy
A StackWise Virtual system operates with SSO redundancy if it meets the following requirements:
• Both the switches must be running the same software version, unless they are in the process of software
upgrade.
• StackWise Virtual link-related configuration in the two switches must match.
• License type must be same on both the switch models.
• Both the switch models must be in the same StackWise Virtual domain.
With SSO redundancy, the StackWise Virtual standby switch is always ready to assume control if a fault
occurs on the StackWise Virtual active switch. Configuration, forwarding, and state information are
synchronized from the StackWise Virtual active switch to the redundant switch at startup, and whenever
changes to the StackWise Virtual active switch configuration occur. If a switchover occurs, traffic disruption
is minimized.
If StackWise Virtual does not meet the requirements for SSO redundancy, it will be incapable of establishing
a relationship with the peer switch. StackWise Virtual runs stateful switchover (SSO) between the StackWise
Virtual active and standby switches. The StackWise Virtual determines the role of each switch during
initialization.
The CPU in the StackWise Virtual standby switch runs in hot standby state. StackWise Virtual uses a StackWise
Virtual link to synchronize configuration data from the StackWise Virtual active switch to the StackWise
Virtual standby switch. Also, protocols and features that support high availability synchronize their events
and state information to the StackWise Virtual standby switch.
Nonstop Forwarding
While implementing Nonstop Forwarding (NSF) technology in systems using SSO redundancy mode, network
disruptions are minimized for campus users and applications. High availability is provided even when the
control-plane processing stack-member switch is reset. During a failure of the underlying Layer 3, NSF-capable
protocols perform graceful network topology resynchronization. The preset forwarding information on the
redundant stack-member switch remains intact; this switch continues to forward the data in the network. This
service availability significantly lowers the mean time to repair (MTTR) and increases the mean time between
failure (MTBF) to achieve a high level of network availability.
Multichassis EtherChannels
Multichassis EtherChannel (MEC) is an EtherChannel bundled with physical ports having common
characteristics such as speed and duplex, that are distributed across each Cisco StackWise Virtual system. A
Cisco StackWise Virtual MEC can connect to any network element that supports EtherChannel (such as a
host, server, router, or switch). Cisco StackWise Virtual supports up to 128 MECs deployed in Layer 2 or
Layer 3 modes. EtherChannel 127 and 128 are reserved for SVL connections. Hence, the maximum available
MEC count is 126.
In a Cisco StackWise Virtual system, an MEC is an EtherChannel with additional capability. A multichassis
EtherChannel link reduces the amount of traffic that requires transmission across the StackWise Virtual link
by populating the index port only with the ports local to the physical switch. This allows the switch to give
precedence to the local ports of the multichassis EtherChannel link over those on the remote switch.
Each MEC can optionally be configured to support either Cisco PAgP, IEEE LACP, or Static ON mode. We
recommend that you implement EtherChannel using Cisco PAgP or LACP with a compatible neighbor. If a
remotely connected neighbor such as Cisco Wireless LAN Controller (WLC) does not support this link-bundling
protocol, then a Static ON mode can be deployed. These protocols run only on the Cisco StackWise Virtual
active switch.
An MEC can support up to eight physical links that can be distributed in any proportion between the Cisco
StackWise Virtual active switch and the Cisco StackWise Virtual standby switch. We recommend that you
distribute the MEC ports across both switches evenly.
All MEC Links to the Cisco StackWise Virtual Active Switch Fail
If all the links to the Cisco StackWise Virtual active switch fail, a MEC becomes a regular EtherChannel with
operational links to the Cisco StackWise Virtual standby switch.
Data traffic that terminates on the Cisco StackWise Virtual active switch reaches the MEC by crossing a
StackWise Virtual link to the Cisco StackWise Virtual standby switch. Control protocols continue to run in
the Cisco StackWise Virtual active switch. Protocol messages reach the MEC by crossing a StackWise Virtual
link.
A StackWise Virtual link also transports system data, such as NetFlow export data and SNMP data, from the
Cisco StackWise Virtual standby switch to the Cisco StackWise Virtual active switch.
Traffic on the StackWise Virtual link is load balanced with the same global hashing algorithms available for
EtherChannels (the default algorithm is source-destination IP).
Layer 2 Protocols
The Cisco StackWise Virtual active switch runs the Layer 2 protocols (such as STP and VTP) for the switching
modules on both the switches. Protocol messages that are received on the standby switch ports must traverse
SVL links to reach the active switch where they are processed. Similarly, protocol messages that are transmitted
from the standby switch ports originate on the active switch, and traverse the SVL links to reach the standby
ports.
All the Layer 2 protocols in Cisco StackWise Virtual work similarly in standalone mode. The following
sections describe the difference in behavior for some protocols in Cisco StackWise Virtual.
Note A new PAgP enhancement has been defined for assisting with dual-active scenario detection.
Private VLANs
Private VLANs on StackWise Virtual work the same way as in standalone mode. The only exception is that
the native VLAN on isolated trunk ports must be configured explicitly.
Apart from STP, EtherChannel Control Protocols, SPAN, and private VLANs, the Dynamic Trunking Protocol
(DTP), Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), and Unidirectional Link Detection
Protocol (UDLD) are the additional Layer 2 control-plane protocols that run over the SVL connections.
Layer 3 Protocols
The Cisco StackWise Virtual active switch runs the Layer 3 protocols and features for the StackWise Virtual.
All the Layer 3 protocol packets are sent to and processed by the Cisco StackWise Virtual active switch. Both
the member switches perform hardware forwarding for ingress traffic on their interfaces. When software
forwarding is required, packets are sent to the Cisco StackWise Virtual active switch for processing.
The same router MAC address assigned by the Cisco StackWise Virtual active switch is used for all the Layer
3 interfaces on both the Cisco StackWise Virtual member switches. After a switchover, the original router
MAC address is still used. The router MAC address is chosen based on chassis-mac and is preserved after
switchover by default. Cisco Catalyst 9500 Series High Performance switches support Layer 3 subinterfaces.
The following sections describe the Layer 3 protocols for Cisco StackWise Virtual.
IPv4 Unicast
The CPU on the Cisco StackWise Virtual active switch runs the IPv4 routing protocols and performs any
required software forwarding. All the routing protocol packets received on the Cisco StackWise Virtual standby
switch are redirected to the Cisco StackWise Virtual active switch across the StackWise Virtual link. The
Cisco StackWise Virtual active switch generates all the routing protocol packets to be sent out over ports on
either of the Cisco StackWise Virtual member switches.
Hardware forwarding is distributed across both members on Cisco StackWise Virtual. The CPU on the Cisco
StackWise Virtual active switch sends Forwarding Information Base (FIB) updates to the Cisco StackWise
Virtual standby switch, which in turn installs all the routes and adjacencies into hardware.
Packets intended for a local adjacency (reachable by local ports) are forwarded locally on the ingress switch.
Packets intended for a remote adjacency (reachable by remote ports) must traverse the StackWise Virtual
link.
The CPU on the Cisco StackWise Virtual active switch performs all software forwarding and feature processing
(such as fragmentation and Time to Live exceed functions). If a switchover occurs, software forwarding is
disrupted until the new Cisco StackWise Virtual active switch obtains the latest Cisco Express Forwarding
and other forwarding information.
In virtual switch mode, the requirements to support non-stop forwarding (NSF) match those in the standalone
redundant mode of operation.
From a routing peer perspective, Multi-Chassis EtherChannels (MEC) remain operational during a switchover,
that is, only the links to the failed switch are down, but the routing adjacencies remain valid.
Cisco StackWise Virtual achieves Layer 3 load balancing over all the paths in the Forwarding Information
Base entries, be it local or remote.
IPv6
Cisco StackWise Virtual supports IPv6 unicast and multicast because it is present in the standalone system.
IPv4 Multicast
The IPv4 multicast protocols run on the Cisco StackWise Virtual active switch. Internet Group Management
Protocol (IGMP) and Protocol Independent Multicast (PIM) protocol packets received on the Cisco StackWise
Virtual standby switch are transmitted across a StackWise Virtual link to the StackWise Virtual active switch.
The latter generates IGMP and PIM protocol packets to be sent over ports on either of the Cisco StackWise
Virtual members.
The Cisco StackWise Virtual active switch synchronizes the Multicast Forwarding Information Base (MFIB)
state to the Cisco StackWise Virtual standby switch. On both the member switches, all the multicast routes
are loaded in the hardware, with replica expansion table (RET) entries programmed for only local, outgoing
interfaces. Both the member switches are capable of performing hardware forwarding.
Note To avoid multicast route changes as a result of a switchover, we recommend that all the links carrying multicast
traffic be configured as MEC rather than Equal Cost Multipath (ECMP).
For packets traversing a StackWise Virtual link, all Layer 3 multicast replications occur on the egress switch.
If there are multiple receivers on the egress switch, only one packet is replicated and forwarded over the
StackWise Virtual link, and then replicated to all the local egress ports.
Software Features
Software features run only on the Cisco StackWise Virtual active switch. Incoming packets to the Cisco
StackWise Virtual standby switch that require software processing are sent across a StackWise Virtual link
to the Cisco StackWise Virtual active switch.
Dual-Active Detection
If the standby switch detects a complete loss of the StackWise Virtual link, it assumes the active switch has
failed and will take over as the active switch. However, if the original Cisco StackWise Virtual active switch
is still operational, both the switches will now be Cisco StackWise Virtual active switches. This situation is
called a dual-active scenario. This scenario can have adverse effects on network stability because both the
switches use the same IP addresses, SSH keys, and STP bridge IDs. Cisco StackWise Virtual detects a
dual-active scenario and takes recovery action. Dual-active-detection link is the dedicated link used to mitigate
this.
If a StackWise Virtual link fails, the Cisco StackWise Virtual standby switch cannot determine the state of
the Cisco StackWise Virtual active switch. To ensure that switchover occurs without delay, the Cisco StackWise
Virtual standby switch assumes that the Cisco StackWise Virtual active switch has failed and initiates switchover
to take over the Cisco StackWise Virtual active role. The original Cisco StackWise Virtual active switch
enters recovery mode and brings down all the interfaces except the StackWise Virtual link and the management
interfaces.
Note Do not use the same port for StackWise Virtual link and dual-active detection link.
Note To avoid PAgP flaps and to ensure that dual-active detection functions as expected, the stack MAC persistent
wait timer must be configured as indefinite using the command stack-mac persistent timer 0 .
Recovery Actions
A Cisco StackWise Virtual active switch that detects a dual-active condition shuts down all of its non-SVL
interfaces to remove itself from the network. The switch then waits in recovery mode until the SVLs have
been recovered. You should physically repair the SVL failure and the recovery switch should be manually
reloaded for it to be the standby switch.
An election mechanism that determines which switch is Cisco StackWise Virtual active and which one is a
control plane standby, is available. The active switch is responsible for management, bridging and routing
protocols, and software data path. These are centralized on the active switch supervisor of the Cisco StackWise
Virtual active switch.
Procedure
Device>enable
Device#configure terminal
Device(config)#stackwise-virtual
Note Depending on the switch model, SVL is supported on all 10G interfaces and 40G interfaces of the Cisco
Catalyst 9500 Series switches and on all the 100G, 40G, 25G and 10G interfaces of the Cisco Catalyst 9500
Series High Performance switches. However, a combination of different interface speeds is not supported.
To configure a switch port as an SVL port, perform the following procedure on both the switches:
Procedure
Device>enable
Device#configure terminal
Step 3 Perform one the of the following depending on the switch Enters ethernet interface configuration mode.
that you are configuring.
• If you are configuring a Cisco Catalyst 9500 Series
Switch, use interface
{TenGigabitEthernet|FortyGigabitEthernet}<interface>
• If you are configuring a Cisco Catalyst 9500 Series
High Performance Switch, use interface
{HundredGigE |FortyGigabitEthernet
|TwentyFiveGigE}<interface>
Example:
Device(config)#interface TenGigabitEthernet1/0/2
Step 4 stackwise-virtual link link value Associates the interface with configured SVL.
Example:
Device(config-if)#stackwise-virtual link 1
Procedure
Device>enable
Device#configure terminal
Example:
Device(config)#interface TenGigabitEthernet1/0/40
Step 6 write memory Saves the running-configuration which resides in the system
RAM and updates the ROMmon variables. If you do not
Example:
save the changes, the changes will no longer be part of the
Device#write memory startup configuration when the switch reloads. Note that
the configuration for stackwise-virtual
dual-active-detection is saved only in the
running-configuration and not the startup-configuration.
Procedure
Device>enable
Device#configure terminal
Step 4 channel-group group_ID mode desirable Enables PAgP MEC with channel-group id in the range
of 1 to 126 for 10 GigabitEthernet interfaces.
Example:
Device(config-if)#channel-group 1 mode desirable
Step 10 dual-active detection pagp Enables pagp dual-active detection. This is enabled by
default.
Example:
Device(config-stackwise-virtual)#dual-active
detection pagp
Procedure
Device>enable
Device#configure terminal
Step 3 Perform one the of the following depending on the switch Enters ethernet interface configuration mode.
that you are configuring.
• If you are configuring a Cisco Catalyst 9500 Series
Switch, use interface
{TenGigabitEthernet|FortyGigabitEthernet}<interface>
• If you are configuring a Cisco Catalyst 9500 Series
High Performance Switch, use interface
{HundredGigE |FortyGigabitEthernet
|TwentyFiveGigE}<interface>
Example:
Device(config)#interface TenGigabitEthernet 1/0/41
Step 4 no stackwise-virtual dual-active-detection Dissociates the interface from StackWise Virtual DAD.
Example:
Device(config-if)#no stackwise-virtual
dual-active-detection
Step 5 Repeat step Step 3, on page 20. Enters the interface configuration mode.
Example:
Device(config)#interface TenGigabitEthernet 1/0/5
Step 11 reload Restarts the switch and the configuration takes effect.
Example:
Device#reload
show stackwise-virtual switch number <1-2> Displays information of a particular switch in the stack.
show stackwise-virtual bandwidth Displays the bandwidth available for the Cisco StackWise
Virtual.
MIBs
Technical Assistance
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/support
documentation and tools for troubleshooting and resolving technical issues
with Cisco products and technologies.
To receive security and technical information about your products, you can
subscribe to various services, such as the Product Alert Tool (accessed from
Field Notices), the Cisco Technical Services Newsletter, and Really Simple
Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user
ID and password.
Cisco IOS XE Everest 16.6.1 This feature was introduced on Cisco Catalyst 9500 Series
Switches.
Cisco IOS XE Everest 16.10.1 This feature was introduced on Cisco Catalyst 9500 Series High
Performance Switches.