Cisco Cisco 1700 2600 3600 3700 Series VPN Module White Paper
© 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 20 of 55
For traffic that must be flooded on the VLAN (broadcasts, multicasts, and unknown unicasts), a copy is sent across
the VSL to be sent out any single-homed ports belonging to the VLAN. Because the first chassis will have sent a
copy out one of the multichassis Cisco EtherChannel ports, packets received from the VSL are not sent out of
another multichassis Cisco EtherChannel port. If all of the multichassis Cisco EtherChannel ports on a given
chassis are removed because of a failure, management control, or other issue, the Cisco EtherChannel link is no
longer a multichassis Cisco EtherChannel link. Instead it becomes a regular Cisco EtherChannel link, and hence,
flooded packets will be sent out of this EtherChannel link from the VSL.
Although the data traffic is spread across the two chassis, the active supervisor engine must terminate control
traffic for the multichassis Cisco EtherChannel link on the active virtual switch, including most of the Layer 2
protocols such as Spanning Tree Protocol, Port Aggregation Protocol (PAgP), VLAN Trunking Protocol (VTP), etc.
All multichassis Cisco EtherChannel links have their control protocols terminated on the active supervisor engine.
Any control protocols received by multichassis Cisco EtherChannel link ports on the standby virtual switch are
redirected to the active supervisor engine through the VSL. Because the Cisco EtherChannel link is terminated in
one chassis, PAgP and LACP have the same device identifier on all the member links, regardless of the chassis on
which the link resides.
Multichassis Cisco EtherChannel Link Management Protocols
Multichassis Cisco EtherChannel links support both the Cisco proprietary Port Aggregation Protocol (PAgP) and
the LACP, both of which run on the active supervisor engine on the active virtual switch. Protocol frames that the
standby virtual switch receives are relayed to the active supervisor engine on the active virtual switch through the
VSL.
Virtual Switch Mode
With the first release of software supporting the Cisco Virtual Switching System, you can run the switches in either
standalone mode or virtual mode. The default configuration is for the individual chassis to operate in standalone
mode. In order to migrate to virtual mode, you must perform a conversion procedure, outlined as follows.
After the chassis reloads and is operating in virtual mode, it begins the VSL initialization sequence. Additionally, the
interface naming convention is changed to allow for the specification of a chassis identifier as part of the interface
name. Please refer to the section “Operational Management” for more information.
name. Please refer to the section “Operational Management” for more information.
Switch Identifier
Each chassis within the Cisco Virtual Switching System is allocated a unique chassis identifier upon conversion to
virtual switch mode. This identifier is known as the switch identifier, or switch ID. This number is used as part of the
interface naming, to help ensure that the interface name remains the same, regardless of the active or standby
virtual switch roles.
As mentioned previously, this variable is set during the conversion phase. If a replacement supervisor engine is
required, it is set with an enable-mode command-line interface (CLI) command. The variable that has been set is
stored as a variable in ROMmon, so it is locally significant to the individual supervisor engine. If you need to alter
the switch ID, use the following CLI:
VSS#switch set switch_num 1
Set rommon’s switch_num to 1
VSS#switch read switch_num
Read switch_num from rommon is 1