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 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. 

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