{"id":115,"date":"2026-09-23T11:32:27","date_gmt":"2026-09-23T11:32:27","guid":{"rendered":"https:\/\/trace-it.info\/?p=115"},"modified":"2026-09-23T11:32:27","modified_gmt":"2026-09-23T11:32:27","slug":"cisco-stackwise-virtual","status":"publish","type":"post","link":"https:\/\/trace-it.info\/en\/it-netzwerke\/cisco-stackwise-virtual\/","title":{"rendered":"Cisco StackWise Virtual"},"content":{"rendered":"

Two switches, one logical switch<\/h2>\n\n\n\n

Anyone who relies on redundancy in the access or aggregation layer is familiar with the problem: Two switches usually mean two management points, a Spanning Tree between them, and uplinks that must be painstakingly secured using routing protocols or VRRP\/HSRP. Cisco StackWise Virtual (SVL) solves this by merging two physical chassis\u2014usually from the Catalyst 9000 series\u2014into a single logical switch. Externally, the pair appears as a single device with one IP address, one configuration, and one MAC address table. Internally, however, it remains a cluster of two independent hardware chassis that are kept in sync via dedicated links.<\/p>\n\n\n\n

The basic principle: One of the two switches acts as the active switch, while the other acts as the standby switch. Only the active switch operates the entire control plane (routing protocols, STP, SNMP, CLI access). The data plane\u2014that is, the actual forwarding of packets\u2014runs in parallel on both chassis, since both have their own ASICs and forwarding tables, which are kept in sync via the internal connection.<\/p>\n\n\n\n

It's worth taking a closer look here, because StackWise Virtual requires not just one, but typically two different types of links between the chassis.<\/p>\n\n\n\n

The Connections in Detail<\/h2>\n\n\n\n

It's worth taking a closer look here, because StackWise Virtual requires not just one, but typically two different types of links between the chassis.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Fig. 1: SVL and DAD connections between the two chassis<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

The StackWise Virtual Link (SVL)<\/h3>\n\n\n\n

The SVL is the backbone of the solution. Three things happen simultaneously through it:<\/p>\n\n\n\n

    \n
  • internal control communication between the two chassis (status, configuration synchronization, heartbeats)<\/li>\n\n\n\n
  • Synchronizing the forwarding tables so that both chassis know how to forward packets<\/li>\n\n\n\n
  • Productive data traffic that must be routed between chassis, such as when a client on Chassis 1 wants to communicate with a server whose port is connected to Chassis 2<\/li>\n<\/ul>\n\n\n\n

    Technically speaking, an SVL can consist of multiple physical ports that are bundled into a single logical link. For redundancy reasons, Cisco recommends at least two physical connections on different modules or ASICs, so that a single hardware failure does not completely disable the SVL. There are a few fixed rules that often become pitfalls in practice more often than one might think: All ports used for an SVL must have the same speed\u2014a mix of 10G and 40G ports in the same link is not permitted. Furthermore, only Cisco-proprietary transceiver modules are supported for SVL and Dual-Active-Detection links; third-party optics are not supported here.<\/p>\n\n\n\n

    Internally, StackWise Virtual also reserves a fixed VLAN ID for its own control communications: All inter-chassis system communications between stack members take place over the reserved VLAN ID 4094 from the global VLAN range, which is why this VLAN ID must not be used in the rest of the network. This is one of the classic mistakes made when migrating an existing network to SVL\u2014if VLAN 4094 is already in use elsewhere, it will conflict with the internal control plane.<\/p>\n\n\n\n

    The Dual Active Detection Link (DAD)<\/h3>\n\n\n\n

    The second, often underestimated component is the DAD link. It is intentionally designed separately from the SVL and has only one function: to detect whether a so-called \u201csplit-brain\u201d situation has occurred\u2014that is, a state in which both chassis believe they are the active one.<\/p>\n\n\n\n

    Why is this even possible? If the standby switch detects a complete failure of the SVL, it assumes that the active switch has failed and assumes the active role itself. However, if the original active switch is still operational, both switches are active at the same time. The problem with this is that both switches then use the same IP addresses, SSH keys, and STP bridge IDs, which can cause significant instability in the network.<\/p>\n\n\n\n

    That is exactly why the DAD link exists as an independent, additional communication path\u2014it does not run over the same hardware as the SVL, so that a total SVL failure does not automatically cripple split-brain detection as well. It can be implemented either as a direct point-to-point connection between the two chassis or via a third device (Fast-Hello mechanism). In practice, a 1G port is often sufficient in terms of bandwidth, since only small Hello packets are exchanged\u2014but how quickly the split-brain detection is supposed to react determines how this link is sized.<\/p>\n\n\n\n

    If the system actually detects a dual-active state, a clearly defined mechanism is triggered: The active switch that detects the dual-active situation shuts down all of its non-SVL and non-DAD interfaces to remove itself from the network, and then waits in recovery mode until the SVL is restored. Only after the SVL connection has been physically repaired does the affected switch automatically reboot and rejoin the network as a standby.<\/p>\n\n\n\n

    Can you turn off a switch while it's running?<\/h2>\n\n\n\n

    That is the question that makes StackWise Virtual so appealing in practice\u2014and the answer varies depending on whether it is a planned maintenance or an unplanned outage.<\/p>\n\n\n\n

    Unplanned Outage: If the active switch fails unexpectedly (power outage, hardware failure), the standby switch automatically assumes the active role. Since both chassis continuously keep their forwarding tables synchronized, this transition is very fast from a data-layer perspective\u2014the new active switch no longer has to go through a complete network convergence, as would be the case with two independent switches using STP or routing protocols. Important for practical implementation: Downstream devices should be connected to both chassis via Multichassis EtherChannel (MEC). Only then will their uplinks remain active in the event of a chassis failure, because the EtherChannel simply continues to operate using the remaining links instead of having to converge anew.<\/p>\n\n\n\n

    Scheduled maintenance, such as a software update: This is where In-Service Software Upgrade (ISSU) comes into play. ISSU is supported on all Catalyst 3850 and Catalyst 9000 switches that support StackWise Virtual, as well as on standalone Catalyst 9400\/9600 chassis with dual supervisors. The process: First, only the standby switch is rebooted with the new software version, while the active switch continues to handle all network traffic. Once the standby switch is back online and synchronized, a controlled switchover is triggered\u2014the previous standby switch assumes the active role, and the former active switch then reboots itself and adopts the new software. In the end, both chassis are running the same version without any continuous interruption for connected clients. An important detail here: ISSU only works if both switches are booted in Install mode\u2014the process is denied in Bundle mode. This is one of the most common reasons why a planned ISSU fails in practice before it even begins.<\/p>\n\n\n\n

    Even without ISSU, one of the two switches can be selectively taken out of service\u2014for example, to replace hardware: A manual reload or shutting down the standby chassis does not interrupt operation, because the active switch handles the entire control plane anyway and maintains full connectivity to the connected devices via MEC. If, on the other hand, the active chassis is shut down, the standby chassis takes over\u2014functionally identical to the unplanned failover scenario described above, only deliberately initiated.<\/p>\n\n\n\n

    Pitfalls to Avoid<\/h2>\n\n\n\n

    As described above, the two switches are closely interlinked via SVL and DAD. Important to know: These connections should never be disconnected without proper oversight. If both types of links are disconnected simultaneously, one of the switches\u2014or even both\u2014may enter recovery mode, causing all switch ports to shut down. The result is not a smooth failover, but a total failure.<\/p>\n\n\n\n

    If the physical connection between the two chassis must ever be completely disconnected\u2014for example, because one of the switches is to be serviced or moved to another location\u2014there is a clear procedure to follow: The affected switch must first be completely powered down\u2014only then may the cables be disconnected; never the other way around.<\/p>\n\n\n\n

    Before performing such a procedure, it\u2019s worth checking the current status of the system to ensure that both chassis are synchronized and to determine what role each is currently playing:<\/p>\n\n\n\n

      \n
    • show stackwise-virtual \u2013 displays whether StackWise Virtual is enabled, as well as the domain number and the assigned ports.<\/li>\n\n\n\n
    • show switch \u2013 displays the roles (Active and Standby) of both physical chassis in the cluster.<\/li>\n\n\n\n
    • show stackwise-virtual link \u2013 displays details and status of the SVL.<\/li>\n\n\n\n
    • show stackwise-virtual dual-active-detection \u2013 displays information about the detection of an activated dual-active state.<\/li>\n<\/ul>\n\n\n\n

      A Word About the Design's Fault Tolerance<\/h2>\n\n\n\n

      What sets StackWise Virtual apart from a traditional solution with two independent switches and a first-hop redundancy protocol is the speed and smoothness of the transition: There is no STP reconvergence process, no ARP rediscovery, and no redistribution of HSRP priorities\u2014from the perspective of the rest of the network, it remains the same logical switch the entire time. The trade-off is complexity elsewhere: SVL and DAD must be carefully planned, sized, and cabled separately, and an error in VLAN 4094 reservation or transceiver selection is often not noticed until it\u2019s already too late.<\/p>\n\n\n\n

      <\/p>\n\n\n\n

      \n\n\n\n

      <\/p>\n\n\n\n

      References:<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst9500\/software\/release\/17-17\/configuration_guide\/ha\/b_1717_ha_9500_cg\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst9500\/software\/release\/17-9\/configuration_guide\/ha\/b_179_ha_9500_cg\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst9500\/software\/release\/17-15\/configuration_guide\/ha\/b_1715_ha_9500_cg\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst9400\/software\/release\/17-8\/configuration_guide\/ha\/b_178_ha_9400_cg\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst9600\/software\/release\/17-15\/configuration_guide\/ha\/b_1715_ha_9600_cg\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/c9000\/ha\/c9610\/svl-configuration-guide\/configuring_cisco_stackwise_virtual.html<\/p>\n\n\n\n

      https:\/\/www.cisco.com\/c\/en\/us\/support\/docs\/switches\/catalyst-9500-series-switches\/214406-in-service-software-upgrade-issu-on-ca.html<\/p>\n\n\n\n

      https:\/\/community.cisco.com\/t5\/switching\/catalyst-9500-dad\/td-p\/4786426<\/p>\n\n\n\n

      https:\/\/community.cisco.com\/t5\/switching\/9500-stackwise-virtual-reload-issue\/m-p\/4089424<\/p>\n\n\n\n

      <\/p>","protected":false},"excerpt":{"rendered":"

      Zwei Switches, ein logischer Switch Wer im Access- oder Aggregation-Layer auf Redundanz setzt, kennt das Problem: Zwei Switches bedeuten meist auch zwei Managementpunkte, Spanning Tree zwischen ihnen und Uplinks, die man m\u00fchsam \u00fcber Routing-Protokolle oder VRRP\/HSRP absichern muss. Cisco StackWise Virtual (SVL) l\u00f6st das, indem es zwei physische Chassis \u2013 meist aus der Catalyst-9000-Serie \u2013 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-115","post","type-post","status-publish","format-standard","hentry","category-it-netzwerke"],"_links":{"self":[{"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/posts\/115","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/comments?post=115"}],"version-history":[{"count":6,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/posts\/115\/revisions"}],"predecessor-version":[{"id":131,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/posts\/115\/revisions\/131"}],"wp:attachment":[{"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/media?parent=115"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/categories?post=115"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/trace-it.info\/en\/wp-json\/wp\/v2\/tags?post=115"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}