Stacking Feature Overview Guide
Stacking Feature Overview Guide
Stacking Feature Overview Guide
Introduction
Virtual Chassis Stacking—VCStackTM —is the name given to two or more Allied Telesis switches that
are configured to operate as a single switch. From a configuration and management point of view, it
is as though the switches are just one device with a seamless transition from the ports of one stack
member to the ports of the next.
VCStack provides a highly available system where network resources are spread out across stacked
units, reducing the impact if one of the units fails. Aggregating switch ports on different units across
the stack provides excellent network resiliency.
When configuring a VCStack, there are no limitations on how the ports of one stack member can
interact with the ports of another stack member—they can belong to VLANs together, they can
belong to port aggregations together, they can mirror to each other, and port-range configuration
can span multiple stack members. The stack member ports truly operate as though they all belong
to one virtual switch.
The same applies with Layer 2 and Layer 3 switching (both unicast and multicast). The stack
operates as a single device and is not perceived by end users, or the traffic itself, to be any more
than a single network node.
There are some limitations to the seamlessness of virtual chassis stacking; for example, the file
systems on the individual stack members remain discrete.
This guide explains the physical creation of a VCStack, the configuration required on stack
members, and how to monitor the operation of the VCStack. It also provides an understanding of
how the stack behaves when a stack member stops responding.
These documents are available from the above links on our website at alliedtelesis.com.
Feature support may change in later software versions. For the latest information, see the above
documents.
Some switches described in this guide are not supported by the most recent software versions. The
following table lists product series and their last supported software release:
x600 5.4.2-3.6
x610 5.4.7-0.x
x900 5.4.4-4.x
SBx908 5.4.8-1.x
DC2552XS 5.4.8-0.x
C613-22075-00 REV V Products and software version that apply to this guide | Page 2
Virtual Chassis Stacking (VCStack)
Content
Introduction .........................................................................................................................................1
Products and software version that apply to this guide ...............................................................2
C613-22075-00 REV V Products and software version that apply to this guide | Page 3
Virtual Chassis Stacking (VCStack)
Provisioning.......................................................................................................................................58
Provisioning a bay.......................................................................................................................59
Provisioning a switch ..................................................................................................................62
Licensing ...........................................................................................................................................65
C613-22075-00 REV V Products and software version that apply to this guide | Page 4
Virtual Chassis Stacking (VCStack)
C613-22075-00 REV V Products and software version that apply to this guide | Page 5
Virtual Chassis Stacking (VCStack)
High availability
Link aggregation across stack members
Aggregated links from access switches to the VCStack can terminate on different stack members. If
a link in the aggregation is removed or fails, there is little network disruption.
Rolling reboot
A major benefit of the VCStack solution is that it provides unit resiliency - if one unit in the stack
goes down, the other members of the stack continue to forward data. It is desirable for this
continuity of service to persist even when the stack is being rebooted. Rolling reboot maintains
continuous service by rebooting the stack in a rolling sequence, so that there is at least one unit
actively forwarding data at all times during the stack reboot sequence.
Resiliency link
The dedicated stacking link is backed up by a further resiliency link. If the stacking link fails,
communications between the stack members is maintained to enable graceful reconfiguration, and
to avoid the problems caused by ‘split brain'.
The resiliency-link feature with disabled-master-monitoring provides a backup mechanism for VCS
to prevent dual active masters if the stack separates.
Fast failover
In a VCStack environment, one of the stack members acts as the master switch, and provides
decision making for the virtual chassis. All of the other VCStack members are in active standby, also
having learnt routing and forwarding information for the network to ensure that if the master were to
fail, another member is able to seamlessly assume control of the virtual chassis with absolutely
minimal network downtime. Synchronization of hardware forwarding tables, VLAN state tables, and
port state tables is maintained across stack members for the following protocols:
Coupled with link aggregation across stack members, to ensure rapid recovery of Layer 2
forwarding, this full synchronization of IPv4 and IPv6 unicast and multicast forwarding tables
ensures almost no packet loss upon failover.
Moreover, non-stop forwarding techniques like Graceful restart and protocol packet replication are
used to ensure that the software routing processes return rapidly to an operational state, ready to
handle neighbors' updates, after a failover.
Additionally, state information for other features is shared across stack members, to enable a
seamless transition upon failover.
Virtual MAC
When a VCStack is central to network design, this virtual chassis uses a virtual MAC address for
communication with other devices. As this single virtual MAC address is used for the complete
VCStack, there is no change of MAC address if a new stack member is required to become master.
Therefore, there is no need for other devices in the network to learn a new MAC address into their
MAC or ARP tables.
License distribution
When a feature license installed on the master switch, it will be copied across to the other stack
members.
Occasionally however, it can be desirable to login to a specific member of the stack. Remote login
facilitates this by allowing a user on the master switch to log into the CLI of another stack member.
Consequently, the management interface into the VCStack provides the best of both worlds - the
VCStack can be managed as a single unit, or as individual units, depending on which is more
convenient for the task at hand.
Extensive statistics
Extensive statistics available from a VCStack virtual chassis provide a wealth of information about
data throughput on a per-port, per-resource, or traffic type basis.
The basic form of virtual chassis stacking consists of a set of Pizza Boxes or mini-chassis
stacked together in close physical proximity (typically less than a metre apart). VCStack provides
a highly available system where network resources are spread out cross stacked units, reducing
the impact if one of the units fails. Aggregating switch ports on different units across the stack
provides excellent network resiliency.
Long-distance stacking allows a VCStack to be created over longer distances, perfect for a
distributed network environment. The increased distance provided by fiber stacking connectivity
means that members of the virtual chassis do not have to be collocated, but can be kilometres
apart. All of the benefits and powerful features of VCStack remain exactly the same – Allied
Telesis long distance stacking provides a genuine distributed virtual network core.
There is no restriction on the distance over which long distance stacking can operate. The only
limitation on the distance between members of a long distance stack is the distance over which
the SFP+ modules can operate.
0S
800
80
00
S
80
00
610
S
0x
x6
x61
0x
61
0
Campus Building A
VCStack link
1 Gigabit link
10/100 link
Link Aggregation
The network diagram above shows a campus where the VCStack network core is distributed across
two separate buildings. By having two stack members in each location, the benefits of using link
aggregation between the core and edge switches remain. The complete distributed virtual chassis
provides a solution with no single point of failure, and a single management entity.
The very high level of resiliency provided by stacking together two SBx8100 chassis is termed
VCStack Plus. In this form of stacking, there is component redundancy within each chassis, as
well as resiliency between the chassis.
SBx908 2 No 160Gbps
x900 2 No 60Gbps
x600 4 No 48Gbps
x310 4 No 4Gbps
CentreCOM GS900MX/MPX 4 No 40Gbps
One switch controls all switch management on a stack. Which stack member does this is discussed
in "The roles of each switch in a stack" on page 11. The software version, startup configuration, and
running configuration are exactly the same on each member of a stack. For information on how the
stack synchronizes the files, see the section "Software and configuration file synchronisation" on
page 66.
The internal communication between stack members is carried out using IP packets sent over the
stacking links. This stack management traffic is tagged with a specific VLAN ID and uses IP
addresses in a specified subnet.
VLAN 4094
Subnet 192.168.255.0/28
The management traffic is queued to egress queue 7 on the stack link. The section "Configuring the
stack" on page 63 discusses the minor restrictions necessary when configuring VLANs, IP subnets,
and QoS on the stack.
The stack master performs a number of tasks that a stack member does not perform:
All routing protocol packets are processed by the stack master. The stack master then transfers
any requisite table updates to the stack members.
When you Telnet or SSH to the stack, you connect to a process running on the stack master.
When you connect to the asyn port on a stack member, this automatically creates an SSH session
to the master. This connection will behave as if you were connected to the asyn port on the
master.
The stack master handles SNMP interactions. It gathers MIB statistics from the stack members,
and delivers these statistics in response to SNMP Get requests.
You can still execute some specific commands and manage files on an individual switch in the
stack. See the section "Executing commands and managing files on stack members" on page 76 for
more information. When a VCStack is operating normally, the stack master acts as the active
master.
However during some failover and resiliency situations, when a stack member cannot contact the
active master, it may act as either a disabled master, or fallback master. See the section "Failover
and recovery" on page 70 for more information about the differences between these stack master
roles.
For each of these criteria, a lower number indicates a higher priority. The active master is the switch
with the lowest priority value. If multiple switches share the lowest priority value, then the switch
with the lowest MAC address becomes the active master.
The stack ID is a unique identifier that is assigned to each switch in the stack. See the section
"Identifying each switch with Stack IDs" on page 13 for more information.
If a switch is already part of a stack, you can still set the priority value on each switch in the stack
through the active master. However, if you set the priority value on a stack member lower than the
active master’s priority value, the active master does not immediately relinquish its role as master.
The stack member with the lowest priority will take over as active master only if the current active
master leaves the stack (this includes any reboot by the stack master).
If a switch has not yet joined a stack, you can still use the stack priority command to change the
priority value before connecting it to the stack. However, even if the new stack member has a lower
priority value than the active master, it will not take over as active master unless the current active
master is removed or rebooted.
The ID number of a stack member is an important identifier. All commands that are port or switch
specific need to use the stack ID to identify which stack member the commands apply to.
The stack ID is also used to manage specific stack members. When you Telnet or SSH to the stack,
your login session terminates on the active master. Similarly, if you connect to the console port of
any stack member, your console login session is sent through to the active master. The active
master switch is the automatic point of contact for any management session on the stack. If you
want to examine something that physically resides on one of the other stack members, such as files
in a stack member's Flash, or voltage levels on a stack member's power supply, then you can do
this by specifying the stack ID of the stack member in commands.
The stack IDs are used frequently in the stack configuration scripts. For example, any command in
the configuration script that refers to a physical port will include a stack ID in the port number. The
section "Port numbering" on page 64 explains the port numbering scheme used in stacks.
For these reasons, the stack IDs on each switch within a stack are unique and a switch’s stack ID
normally does not change without user intervention.
The only exception to this is when a new switch is connected to a stack and the switch has the
same stack ID number as another stack member–the new switch's ID will be automatically
renumbered.
Note: There is no connection between stack ID and active master status. The active master switch
does not have to be the switch with a Stack ID of 1.
install XEM2s If you have purchased feature licences to enable certain features to operate on the stack, then all
(on SBx908 GEN2)
stack members need to have the licences installed. If some stack members have licences for
features that will not be used on the stack, and other switches do not have those licences, then
assign stack IDs remove those unnecessary licences.
See the Licensing Feature Overview and Configuration Guide for more information.
reboot
Step 2: If you are stacking SBx908 GEN2 switches, install the XEM2s
enable stacking
(on SBx908 GEN2) Do this before you enter stacking commands. The switches will reject some stacking commands
unless the XEM2s are installed.
set priority on master Step 3: Give each of the backup switches the stack ID you want them to have
The master switch will have a stack ID of 1 by default. Number your backup switches in the order
specify the stack ports
you want the cable them up. The command is:
Step 4: After setting each switch’s stack ID, reboot each switch
cable switches together
Step 5: If you are stacking SBx908 GEN2 switches, enable stacking on each switch
Step 6: On the switch that will be the active master, set the stack priority to 0
This ensures it becomes the active master. Unless the switch has been stacked before it will have
the default stack ID of 1. The command is:
If you see an error message about stacking not being enabled, you can ignore the message. The
switch may display such errors until after you reboot it.
C613-22075-00 REV V SBx908 GEN2, x550 Series and XS900MX Series switches | Page 14
Virtual Chassis Stacking (VCStack)
awplus# write
Before powering any of the switches up, cable them together into the stack. Before cabling the
stack, consult "Connecting switches into a stack" on page 25 for information about your product.
Step 11: Power the switches up, starting with the master switch
Turn on each switch, starting with the master switch. It does not matter what order you power the
backup switches up in. Note that an SBx908 GEN2 switch may take up to 10 minutes to form a
stack.
Check that the stack links have all come up successfully with the expected Stack IDs. You can do
this by:
using the show stack detail command. This command provides a snapshot of the stack status.
See the section "Checking stack status" on page 82 for more information about LEDs and the show
stack detail command.
If there is another switch that you want to be the one that takes over as active master, if the active
master goes down, then set its priority to a value lower than the other switches:
You are now ready to configure the stack with port channels, VLANs, IP addresses, and so on.
Once you are happy with the stack configuration, make a backup copy of the configuration file.
C613-22075-00 REV V SBx908 GEN2, x550 Series and XS900MX Series switches | Page 15
Virtual Chassis Stacking (VCStack)
Other switches
This section applies to all stackable AlliedWare Plus switches except the SBx8100 Series,
SBx908GEN2, x550 Series, and XS900MX Series.
There are no set rules regarding the order in which stack configuration tasks need to be carried out.
However, these steps provide a guideline to help ensure that the stack creation process goes
smoothly.
Ensure that all the switches have the same feature licences installed. If you have purchased
feature licences to enable certain features to operate on the stack, then all stack members need
to have the licences installed. If some stack members have feature licences installed for features
that will not be used on the stack, and other switches do not have those licences installed, then
remove those unnecessary licences.
If you are stacking an SBx908 switch and stacking through XEM modules, install the XEMs into
the switches before you can enter stacking commands. The switches will reject stacking
commands until the XEM is installed.
Specify the stacking ports, on switches that allow stacking through user-selectable stack ports.
Decide which stack member will be the active master and set its priority to 0, to ensure it becomes
the active master. The command is:
(The switch, if it has not been stacked before, should have the default stack ID of 1.)
Install and power up the master switch. It will detect that there are no other members in the stack, so
it will elect itself master. At bootup, it will output the following messages:
Then, after the switch has booted, the show stack command will show a stack with only one
member:
awplus#show stack
Virtual Chassis Stacking summary information
Install the next switch, connecting the stacking cable from that switch to the master. Stack cabling
varies between products. Before connecting the stack, consult "Connecting switches into a
stack" on page 25 for information about your product.
Power up the switch—it will detect that there is already an active master, and so will come up as a
backup member. The active master will assign it the first available stack ID.
After bootup, the show stack command will show that there are two switches in the stack:
awplus#show stack
Virtual Chassis Stacking summary information
The active master will check that the new stack member has the same software version as itself. If
the software versions are different, the active master will use the software auto-synchronization
mechanism to force the new stack member to run the same software version.
Repeat step 3 for each of the other switches in the stack, following the cabling scheme described in
"Connecting switches into a stack" on page 25 for your switch. For the last switch added to the
stack, connect this switch to the first installed switch.
Check that the stack links have all come up successfully. This can be done by:
See the section "Checking stack status" on page 82 for more information about LEDs and the show
stack detail command.
If you are not satisfied with the stack IDs that the switches have been automatically assigned, then
this is the right moment to remedy that. To change a stack ID, use the command:
It is usually a good idea to give the stack ID 1 to the active master, as it is quite natural to associate
the lowest ID with the active master switch.
Reboot all the stack members, and check that they all come up with the stack IDs that you are
expecting. You can use the command show stack detail to check the stack IDs and the status of
the neighbor connections.
If there is another switch that you want to be the one that takes over as active master, if the active
master goes down, then set its priority to a value lower than the other switches:
You are now ready to configure the stack with port channels, VLANs, IP addresses, and so on. For
example, to create a port channel that aggregates ports from two different stack members, you
would configure as follows:
Once you are happy with the stack configuration, make a backup copy of the configuration file.
Introduction
To achieve excellent resiliency and simplified management, two SwitchBlade x8100s can be
connected together to form a single stacked unit. This is only possible using the CFC960 controller
cards, which have 4 x 10 GB SFP+ ports. Because the stacking connections are via fiber SFP+
ports, each SBx8100 switch can be located long distances apart, even kilometers apart if required.
The stacking connections must use fiber links, and can be terminated by any Allied Telesis branded
SFP+ modules. For cabling information, see "Stacking on SwitchBlade x8100 switches" on page 26.
For information on setting up a resiliency link, see "The resiliency link feature" on page 70.
Enabling stacking
Stacking is disabled by default on the SBx8100. When stacking is enabled, with the stack enable
command, all of the CFC960 SFP+ ports will be reserved for stacking use - they will not be
configurable as normal network switchports.
When stacking is enabled via the CLI, the stack Virtual-MAC feature will automatically be enabled as
well.
Each stack member must have a unique stack ID. This is set with the command:
stack <existing stack-ID> renumber <new stack-ID>. The current stack ID of each switch can be
seen with the show stack command. The SBx8100 must be manually renumbered via the CLI
before it is connected in a stack.
Once the stack has formed, the show stack command will show the Active CFC.
ID 1.5 refers to Stack member 1, the CFC in bay 5
ID 1.6 refers to Stack member 1, the CFC in bay 6
ID 2.5 refers to Stack member 2, the CFC in slot 5
ID 2.6 refers to Stack member 2, the CFC in slot 6
awplus#show stack
Virtual Chassis Stacking summary information
The show stack detail command displays a 'Last role change' date/time. Normally if all cards
booted up at the same time, the date/time is the same for all cards.
If one card rebooted (or was inserted later), it will have a more recent date/time. If a master (Active
CFC) failover occurred, then the stack master will have a more recent date/time than the other
backup member CFCs.
Stack Status:
------------------------------------------------------------------
Operational Status Normal operation
Management VLAN ID 4094
Management VLAN subnet address 192.168.255.0
Virtual Chassis ID 97 (0x61)
Virtual MAC address 0000.cd37.0061
Card 1.5:
------------------------------------------------------------------
ID 1.5
Pending ID -
MAC address eccd.6db3.586a
Last role change Thu Apr 10 23:38:47 2014
Product type AT-SBx81CFC960
AT-SBx81CFC960 Stacking Ports Enabled
Role Active CFC
Status Ready
Priority 128
Host name stk_a_1340_3001
Stack port1.5.1 status Learnt neighbor 2.5
Stack port1.5.2 status Learnt neighbor 2.6
Stack port1.5.3 status Learnt neighbor 2.5
Stack port1.5.4 status Learnt neighbor 2.6
Card 1.6:
------------------------------------------------------------------
ID 1.6
Pending ID -
MAC address eccd.6db3.5919
Last role change Thu Apr 10 23:38:48 2014
Product type AT-SBx81CFC960
AT-SBx81CFC960 Stacking Ports Enabled
Role Backup Member
Status Ready
Priority 128
Host name stk_a_1340_3001-1.6
Stack port1.6.1 status Learnt neighbor 2.5
Stack port1.6.2 status Learnt neighbor 2.6
Stack port1.6.3 status Learnt neighbor 2.5
Stack port1.6.4 status Learnt neighbor 2.6
Card 2.5:
------------------------------------------------------------------
ID 2.5
Pending ID -
MAC address eccd.6db3.5892
Last role change Thu Apr 10 23:38:47 2014
Product type AT-SBx81CFC960
AT-SBx81CFC960 Stacking Ports Enabled
Role Backup Member
Status Ready
Priority 128
Host name stk_a_1340_3001-2.5
Stack port2.5.1 status Learnt neighbor 1.5
Stack port2.5.2 status Learnt neighbor 1.6
Stack port2.5.3 status Learnt neighbor 1.5
Stack port2.5.4 status Learnt neighbor 1.6
Card 2.6:
------------------------------------------------------------------
ID 2.6
Pending ID -
MAC address eccd.6db3.58f6
Last role change Thu Apr 10 23:38:47 2014
Product type AT-SBx81CFC960
AT-SBx81CFC960 Stacking Ports Enabled
Role Backup Member
Status Ready
Priority 128
Host name stk_a_1340_3001-2.6
Stack port2.6.1 status Learnt neighbor 1.6
Stack port2.6.2 status Learnt neighbor 1.5
Stack port2.6.3 status Learnt neighbor 1.5
Stack port2.6.4 status Learnt neighbor 1.6
In order to stack, both chassis also need to have their own VCStack-Plus license installed
(specific to SBx8100 stacking).
Both chassis also need to have the same feature licenses installed (this is the same as VCStack
on other platforms).
Under normal circumstances, CFC card 5 should end up the master of each chassis. One of these
CFCs will be elected stack master.
If CFC card 6 becomes master, rather than card 5, then it is likely that card 5 failed to boot or was
significantly delayed in booting. There is a limit to how long the switch waits, and it will not change
mastership if there is already a master present.
CFC operation
When two SBx8100s are stacked together, one CFC card will become the Active CFC for both
chassis and the other three CFCs will be in Backup.
In the chassis that does not contain the Active CFC - i.e. just two backup CFCs - one of these
backup CFCs becomes the H/W master for that chassis. The H/W master relates to how the
SBx8100 hardware is designed - only one CFC on the chassis can access the
H/W information for that chassis.
In a VCStack Plus stack, the H/W master doesn't have a lot of extra duties to do - the stack master
(Active CFC) handles most things. In the backup chassis, the only things the H/W master would do
differently to the H/W backup member would be:
controlling the bootup of the LIFs (Line Interface Fabric/cards) i.e. serving out BOOTP IP and
TFTP release.
PoE power allocation (as each chassis has its own power to distribute).
The Active CFC will do all of the CPU processing for the stack.
You can infer which CFC is the H/W master in the backup chassis from the highest uptime
displayed in the show card command output.
LIF operation
All cards communicate with all other cards in the stack, regardless of what chassis they are in,
depending on the actual communication.
For example:
the BOOTP client on the LIFs only communicates with the local H/W master.
The insertion or removal of LIF cards in either chassis is controlled by the Active CFC.
The maximum number of supported ports in the SBx8112 stack is 400 switchports in a fully-
populated SBx8112 stack with 24 cards in total.
File synchronization
VCStack SW auto-sync makes sure the same software release is used across the stack, and
auto-upgrades the software if needed.
VCStack file replication makes sure necessary files on the master get synchronized with the
backup member.
If you are combining CFC960v2 and earlier CFC960 cards, you may need to synchronize the
AlliedWare Plus software manually. See "Stacking with a mixture of CFC960 v2 and earlier CFC960
in an SBx8100 system" on page 67.
Stack failover
A single CFC960 will be elected as the stack master or 'Active CFC' for the entire SBx8100
VCStack. When the Active CFC is removed or rebooted, the backup CFC on the same chassis will
take over as master. However, if the backup CFC on the same chassis is not in the equivalent of the
VCStack 'Ready' state, then a 'Ready' CFC on the peer chassis will take over as master.
When the entire SBx8100 containing the Active CFC is failed over (e.g. power-cycled), the CFC960
that has H/W mastership on the peer SBx8100 will take over as master. In other words, when an
entire SBx8100 chassis is failed, the CFC with the longest system up-time will become the Active
CFC.
Failing over any CFC960 in the stack will temporarily halve the available stacking backplane
bandwidth. This may cause network disruption if traffic across the stacking backplane exceeds
40Gbps.
CFC failover
When a single Active CFC failover occurs (i.e. the new master CFC is still in the same chassis), the
interruption to traffic will not be significantly different from CFC failover on a standalone SBx8100.
Chassis failover
When a entire SBx8100 failover occurs (i.e. the new master CFC is in a different chassis), the
interruption to static Layer 2 and Layer 3 unicast traffic forwarding will be < 3 seconds. Interruption
to other protocol traffic, such as multicast, will be best effort, however disruption may be
significantly higher. Failing over both CFCs in the same chassis at the same time will result in all LIFs
in that chassis rebooting as well.
Troubleshooting
The command show counter stack | grep Master (note the capital ‘M’) will show you any failovers
or conflicts (duplicate masters) that have occurred. Check show reboot history and look for any
unexpected reboots (note that this will include any times the chassis has been power-cycled). Use
the show stack detail command to check the 'Last role change' date/time.
"Stacking on the x510, IE510, x510L, IX5, GS980MX, x530 and x530L Series switches" on
page 33
If both SBx8100s have two CFC960 controller cards installed, then the cabling is as shown on the
left.
If both SBx8100s only have a single CFC960 controller card installed, then the cabling is as
shown on the right:
Note: Any number of cables can be used to interconnect the CFCs, but reducing the number of
cables will mean: reduced bandwidth between VCStack Plus members and reduction in
resiliency capabilities.
up to eight 10G ports per switch, using the range of 10G XEM2 modules. This means linking each
unit together with up to four cables. You can combine ports from different 10G XEM2 modules;
the modules do not have to be the same.
up to four 40G ports per switch, using the XEM2-4QS. This means linking each unit together with
up to two cables.
two 100G ports per switch, using the XEM2-1CQ. This means linking each unit together with one
cable.
You do not have to have all your stacking ports on the same XEM. However, all stack ports must be
of the same speed.
To see how to set up a stack, see "Steps to set up a VCStack" on page 14. The following figure
shows how to cable four switches into a stack using one 40G link between each stack member.
1. Software version 5.4.7-2.x only supports 2-unit stacking over 40G ports
The following figure shows how to cable three switches into a stack using two 40G links between
each stack member.
If you use multiple cables to connect the stack members together, please be aware that:
You need to change all the ports to stacking ports, using the stackport command.
The switch automatically aggregates the stacking ports together. You do not have to create link
aggregation groups.
All stack ports must be of the same speed. You cannot build a stack using some 40G ports and
some 10G ports. However, you can combine ports from the different 10G XEM2 modules.
You must have the same number of stack ports on each link. For example, you cannot have two
cables connecting switches 1 and 2 and three cables connecting switches 2 and 3.
You must connect the switches in a ring, with each switch connected to two stack neighbors
(except in a two-unit stack, which can only have one neighbor).
up to eight 10G ports per switch. This means linking each unit together with up to four cables.
up to four 40G ports per switch. This means linking each unit together with up to two cables.
two 100G ports per switch. This means linking each unit together with one cable.
To see how to set up a stack, see "Steps to set up a VCStack" on page 14. The following figure
shows how to cable four switches into a stack using one 40G link between each stack member.
The following figure shows how to cable three switches into a stack using two 40G links between
each stack member.
If you use multiple cables to connect the stack members together, please be aware that:
You need to change all the ports to stacking ports, using the stackport command.
The switch automatically aggregates the stacking ports together. You do not have to create link
aggregation groups.
All stack ports must be of the same speed. You cannot build a stack using some 40G ports and
some 10G ports.
You must have the same number of stack ports on each link. For example, you cannot have two
cables connecting switches 1 and 2 and three cables connecting switches 2 and 3.
You must connect the switches in a ring, with each switch connected to two stack neighbors
(except in a two-unit stack, which can only have one neighbor).
Front-port stacking
Front-port stacking on the x930 Series provides 40Gbps connectivity. The x930 Series have 4 x
10GbE SFP+ ports, two of which may be used for stacking instead of network connectivity. The
stacking cables must form a ring, as shown in the diagram below.
If the switch does not have a StackQS module installed, then the front-panel ports S1 and S2 will be
set up as the stacking ports by default when VCStacking is enabled by the stack enable command.
If a StackQS module is installed, and you still want to use the front ports for stacking, then you need
to explicitly set the front ports as the stacking ports by using the command stack enable builtin-
ports.
If the S1 and S2 ports are not configured as stacking ports, then they operate as normal network
ports. The numbers assigned to these ports are simply the sequential numbers beyond those of the
other ports on the switch, i.e. ports 1.0.27 and 1.0.28 on a 28-port switch and ports 1.0.51 and
1.0.52 on a 52-port switch.
Stacking cables
Cables that can be used for x930 Series front-port stacking:
In addition, Allied Telesis SFP+ modules can be inserted and connected by cables of whatever
length the SFP+ modules can support.
C613-22075-00 REV V Front-port and back-port stacking on x930 Series switches | Page 31
Virtual Chassis Stacking (VCStack)
Rear-port stacking
Rear-port stacking on the x930 Series provides 160Gbps connectivity using the StackQS module
and direct attached cables. The stacking cables must form a ring, in the same manner as when
using front-port stacking.
AT-QSFPLR4 Transceiver (has a duplex LC connector): 2 meter to 10 km single mode fiber (SMF).
By default, if a StackQS module is installed in the switch, then its ports will be chosen as the
stacking ports if stacking is enabled. If the configuration has been changed so that the front-panel
ports are set up as the stacking ports, the role of stacking ports can be changed back to the
StackQS ports by using the command stack enable expansion-ports.
If the ports on the AT-StackQS card are not configured as stacking ports, then they operate as
40Gbps network switch ports. The ports are numbered port1.1.1 and port1.1.5.
C613-22075-00 REV V Front-port and back-port stacking on x930 Series switches | Page 32
Virtual Chassis Stacking (VCStack)
Stacking on the x510, IE510, x510L, IX5, GS980MX, x530 and x530L
Series switches
This section specifies which stacking components to use with x510, x510L, IE510, IX5, GS980MX,
x530 and x530L Series switches to correctly form Virtual Chassis Stacking. The x510, GS980MX,
x530 and x530L Series Switches come with two stacking ports. These are the last two SFP+ slots
on the switches and are labeled S1/27 and S2/28 on the 28-port switches, and S1/51 and S2/52 on
the 52-port switches.
The ports have two functions. You may use them as stacking ports when VCStack is enabled by the
stack enable command (the default state).
Or on the other hand, by disabling the VCStack feature, using the no stack enable command, you
may also use them with regular SFP or SFP+ transceivers as additional networking ports.
Although these ports are labeled S1/27, S2/28, S1/51 and S2/52 on the front panel, on the CLI they
are referred to as port1.0.27, port1.0.28, port1.0.51 and port1.0.52.Local stacking using direct
attach cables
When creating a VCStack of units that are all located within a meter of each other, use local
stacking components.
Requirements
For switches running AlliedWare Plus software version 5.4.5 or later, any Allied Telesis Twinax
cable will work.
GS980MX, For GS980MX, x530 and x530L switches running AlliedWare Plus software version 5.4.9 or later,
x530 and any Allied Telesis Twinax cable will work.
x530L
Series
C613-22075-00 REV V Stacking on the x510, IE510, x510L, IX5, GS980MX, x530 and x530L Series switches | Page 33
Virtual Chassis Stacking (VCStack)
Figure 1 below shows three direct attach cables forming a VCStack of three switches.
1 meter max
Requirements
On switches running AlliedWare Plus 5.4.5 or later, you can use any Allied Telesis SFP+ module.
Fiber cable.
GS980MX, On switches running AlliedWare Plus 5.4.9 or later, you can use any Allied Telesis SFP+ module.
x530 and
x530L Fiber cable.
Series
If Figure 1 on page 34 was configured using long-distance stacking components, then six SFP+
modules and three fiber cables would be required.
Note that a mix of local and long-distance stacking components can be used. This is useful if two
groups of devices are separated by some distance. Figure 2 below shows this scenario.
C613-22075-00 REV V Stacking on the x510, IE510, x510L, IX5, GS980MX, x530 and x530L Series switches | Page 34
Virtual Chassis Stacking (VCStack)
Building 1
Building 2
From software version 5.5.1-2.1 onwards, VCStack on 1G copper ports and SFP ports, is supported
on the x930 Series.
You can form a stack with up to four members using VCStack on 1G copper and SFP ports, and up
to eight 1G ports can be used for stacking between VCS members.
Note: For any two directly linked stack members, all stackports must originate from a single packet
processor and go to a single packet processor. For 52 port models, this means all 1G
stackports to another member must be in the port range 1-24 or 25-52 (excluding 41-48 on
models with 5G ports in that range).
C613-22075-00 REV V Stacking over 1G ports on the x930, x530 and GS980MX Series switches | Page 35
Virtual Chassis Stacking (VCStack)
To use mixed-mode VCStacking, you must have a mixed-mode license installed on each device in
the stack. To see the available licenses, check your device’s datasheet, which is available at
alliedtelesis.com. To purchase the license, contact your Allied Telesis representative. You will need to
supply the device serial number.
Note: When in mixed-mode, the table limits (routing limits) on ALL units in the VCStack will be
aligned to the base license of the x530L.
Once you have downloaded your license, you can transfer it onto the device’s Flash storage
by any preferred method. For example, you can use the copy command to copy the file from
a USB device to your Flash storage.
Step 4. Re-boot
Re-boot.
Once the command is removed from the configuration file, the license should also be removed but it
is not mandatory to do so.
C613-22075-00 REV V Mixed-mode VCStacking between x530 and x530L Series switches | Page 36
Virtual Chassis Stacking (VCStack)
The CentreCOM XS900MX Series consists of the following switches: XS916MXS and XS916MXT.
From software version 5.4.7 onwards, the CentreCOM XS900MX Series switches allow two units to
be stacked using any of their ports. As the units house a mix of copper and fiber ports, this provides
flexibility in which ports are used for stacking, and which remain available for network connectivity.
If stacking is enabled, all ports except ports 15 and 16 are network ports by default, and ports 15
and 16 are stacking ports by default. If stacking is disabled, all ports are network ports.
When changing a port to or from a stacking port, you must first configure the desired ports as
stacking ports on each switch, using the stackport command. Then save the configuration file on
each switch, restart both switches, and cable the switches together.
Stacking cables
Use one of the following cables to stack CentreCOM XS900MX Series switches. To connect:
The stacking cables must form a ring, for example as shown in the diagram below, which shows
stacking through RJ-45 ports 1 and 2:
The CentreCOM GS900MX/MPX Series consists of the following switches: GS924MX, GS924MPX,
GS948MX, GS948MPX.
Stacking cables
Use the following cable to stack GS900MX/MPX Series switches:
The stacking cables must form a ring, as shown in the diagram below:
From software release 5.4.7 onwards, the CentreCOM FS980M Series switches allow up to 4 units
to be stacked using front-port stacking, providing 4Gbps bandwidth. The CentreCOM FS980M
Series have four 1GbE SFP ports, two of which may be used for stacking instead of network
connectivity.
Stacking cables
Use the following cable to stack CentreCOM FS980M Series switches:
The stacking cables must form a ring. For example, in a stack of two FS980M/28, stacking
port1.0.28 needs to be connected to port2.0.27 and port1.0.27 needs to be connected to
port2.0.28, as shown in the diagram below:
For software version 5.4.7 onwards, up to four units may be used to form a VCStack. For example,
in a stack of four FS980M/28, the cables are connected as follows:
The stacking ports S1 and S2 can be used as network ports, when stacking has been disabled by
the no stack enable command, and the switch has been rebooted.
The port numbers allocated to the stacking ports when stacking has been disabled are the
sequential numbers beyond the end of the rest of the port numbers, i.e. port1.0.27 and port1.0.28
on the 28-port switches, and port1.0.51 and port1.0.52 on the 52-port switches.
2. Use two QSFP+ ports, to provide 160Gbps connectivity and still provide redundancy.
Note: When VCStack is configured on the DC255XS/L3 Series switch, all four QSFP+ ports become
stacking ports, and none are available for network connections, even if only one or two ports
are used for stacking.
Unlike the SwitchBlade and x-Series switches, the stacking cables on the DC2552XS/L3 must
connect ports of the same number. A stack will form regardless of which port numbers are used for
linking, as long as the same numbers are linked together.
For example, connecting port 1.0.57 on switch 1 to port 2.0.57 on switch 2 and port 1.0.61 on
switch 1 to port 2.0.61 on switch 2, as shown below, is a valid option:
Whereas, connecting port 1.0.57 on switch 1 to port 2.0.61 on switch 2 and port 1.0.57 on switch 1
to port 2.0.61 on switch 2, would not work.
Back port stacking requires a specific cable. The product code is AT-HS-STK-CBL650.
You can stack two SwitchBlade x908 switches together using these ports and cables.
Note that the cables are crossed over—port 1 of the top switch is connected to port 2 of the bottom
switch, and vice versa.
The LED number on the front of the XEM-STK shows the stack ID of the switch that the XEM-STK is
installed in. See the section "Identifying each switch with Stack IDs" on page 13 for more
information about stack IDs.
The specific cable type that connects these XEMs are purchased individually as either 350mm or 2
meter long cables. The product codes are:
AT-XEM-STK-CBL350
AT-XEM-STK-CBL2.0
With these XEMs and cables, you can create a stack of two x900 Series switches.
C613-22075-00 REV V Front-port stacking using XEM-STKs on x900 Series switches | Page 43
Virtual Chassis Stacking (VCStack)
In two switch stacks, this means that the connection consists of just a crossed pair of cables. You
may also use only one cable to connect the switches, but you will halve the bandwidth between
stack members.
C613-22075-00 REV V Front-port stacking using XEM-STKs on x900 Series switches | Page 44
Virtual Chassis Stacking (VCStack)
The stacking cables must form a ring, as shown in the diagram below.
Expansion modules
The x610 Series switches use the following two expansion modules:
AT-x6EM/XS2-00 —Expansion module (2 x SFP+) for long-distance stacking or for use as two
additional 10GbE ports.
If the AT-x6EM/XS2 module is installed in the switch, and stacking is enabled, with the command
stack enable (enabled by default), then the two ports on the AT-x6EM/XS2 module will operate as
stacking ports.
If stacking is disabled using the command no stack enable (followed by saving the configuration
and rebooting the switch), then the two ports on the AT-x6EM/XS2 module are re-purposed as
normal 10Gbps network ports. The port numbers assigned to the ports are 1.1.1 and 1.1.2.
AT-StackXG-00—Expansion module with two full-duplex, 12 Gbps stacking ports, one AT-
StackXG/0.5-00 cable included. This is exactly the same module as is used in x600 Series
switches.
Stacking cables
A variety of stacking cables are available for use with the x610 Series switches.
In addition, standard SFP+ units can be inserted into the x6EM/XS2-00, and connected by cables of
whatever length the SFP+ modules can support.
The specific cable type that connects the AT-StackXG are purchased as either 0.5 or 1 meter long
cables. The product codes are:
You can stack up to four x600 switches using the AT-StackXG cables.
Like the other stacking methods, the connections are crossed-over–port 1 on one switch is
connected to port 2 on its neighbor and the switches are connected in a ring. The following figure
shows how to connect a 4 switch stack of x600 Series switches. Once again, you could connect the
switches without one of the cables, but you would halve the bandwidth between stack members.
SwitchBlade x908 compatible stack partners A SwitchBlade x908 GEN2 switch can only stack with another
GEN2 SwitchBlade x908 GEN2 switch.
maximum stack size 4 switches (Version 5.4.7-2.x only supports 2-unit stacking over
40G ports).
cable type For 100G ports:
■ AT-QSFP28 modules
For 40G ports:
■ AT-QSFPLR4, AT-QSFPSR modules
■ AT-QSFP1CU, AT-QSFP3CU: 1m and 3m direct attach cable
■ AT-MTP12-1, AT-MTP12-5: 1m and 5m MTP optical cable for
AT-QSFPSR
For 10G ports:
■ Allied Telesis 10GbE SFP+ modules
■ AT-SP10TW1, AT-SP10TW3, AT-SP10TW7: 1m, 3m and 7m
direct attach cable
DC2552XS/L3 compatible stack partners DC2552XS/L3 switches can only stack with other DC2552XS/L3
switches.
maximum stack size 2 switches.
SwitchBlade x8100 compatible stack partners A SwitchBlade x8100 switch can only stack with another
Series SwitchBlade x8100 switch.
maximum stack size 2 switches.
SwitchBlade x908 compatible stack partners A SwitchBlade x908 switch can only stack with another
SwitchBlade x908 switch.
maximum stack size 2 switches.
x950 Series compatible stack partners x950 Series switches can only stack with other x950 Series
switches.
You can create a VCStack of up to eight units:
■ Front port stacking (10G, 40G, 100G) - long distance with any
SFP+, QSFP+, QSFP28 module.
maximum stack size Eight switches
x930 Series compatible stack partners x930 Series switches can only stack with other x930 switches.
Within the x930 Series:
You can create a VCStack of up to eight units:
■ Front port stacking (40G) - long distance with any SFP+
module.
■ Rear port stacking (160G) - StackQS module,1 meter cables
maximum stack size 8 switches.
x900 Series compatible stack partners x900 Series switches can only stack with other x900 switches.
Within the x900 Series:
■ x900-12XT/S switches can only stack with x900-12XT/S
switches
■ x900-24XS and x900-24XT can stack together
maximum stack size 2 switches.
x610 Series compatible stack partners x610 Series switches can stack with x600 switches, but the x600
stack restrictions will apply, so the whole stack is at the level of the
x600.
Within the x610 Series, you can stack any model with another
model.
This means that all the switches in the x610 Series can stack
together without restriction.
maximum stack size 8 switches.
x600 Series compatible stack partners x600 Series switches can stack with x610 switches, but the x600
stack restrictions will apply, so the whole stack is at the feature
level of the x600. Within the x600 Series, you can stack any model
with another model.
This means that all the switches in the x600 Series can stack
together without restriction.
maximum stack size 4 switches.
x510 and IX5 Series compatible stack partners x510 Series switches can stack with other x510 switches. They
can also stack with x510L and IX5 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables or
SFP+ modules can be used to stack x510 Series switches.
For local stacking:
■ For switches running AlliedWare Plus prior to 5.4.5:
AT-StackXS/1.0 —1 meter stacking cable
■ For switches running AlliedWare Plus 5.4.5 or later:
■ AT-SP10TW1—1 meter SFP+ direct attach cable
x530 Series compatible stack partners x530 Series switches can stack with other x530 switches. This
means that all the switches in the x530 Series can stack together
without restriction.
x530 switches can also be stacked with x530L switches. In this
case, the x530L stack restrictions will apply, so the whole stack is
at the level of the x530L. This is known as mixed-mode stacking.
For more information, see "Mixed-mode VCStacking between
x530 and x530L Series switches" on page 36.
maximum stack size 8 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables or
SFP+ modules can be used to stack x530 switches.
For local stacking:
■ AT-SP10TW1—1 meter SFP+ direct attach cable
cable type Standard Allied Telesis branded Twinax direct attach cables or
SFP+ modules can be used to stack x530L switches.
For local stacking:
■ AT-SP10TW1—1 meter SFP+ direct attach cable
x550 Series compatible stack partners x550 Series switches can only stack with other x550 switches.
maximum stack size 4 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables can
be used to stack x550 switches.
For local stacking:
■ AT-StackXS/1.0 —1 meter stacking cable.
For long distance stacking:
■ Fiber cable
x310 Series compatible stack partners x310 Series switches can only stack with other x310 switches,
(currently available in 10-100 switches only).
maximum stack size 4 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables can
be used to stack x310 switches.
For local stacking:
■ AT-StackXS/1.0 —1 meter stacking cable.
CentreCOM compatible stack partners The CentreCOM XS900MX Series switches can only stack
XS900MX Series with other CentreCOM XS900MX Series switches.
maximum stack size 2 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables
can be used to stack CentreCOM XS900MX Series switches.
For local stacking, use one of the following cables:
■ AT-SP10TW1-1 meter SFP+ direct attach cable.
■ RJ-45 cable - copper cable Cat 6a or above
CentreCOM compatible stack partners CentreCOM GS900MX/MPX Series switches can only stack
GS900MX/MPX with other CentreCOM GS900MX/MPX Series switches.
Series
maximum stack size 4 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables
can be used to stack CentreCOM GS900MX/MPX Series
switches.
For local stacking:
■ AT-SP10TW1—1 meter SFP+ direct attach cable.
CentreCOM compatible stack partners CentreCOM GS980MX Series switches can only stack with
GS980MX Series other CentreCOM GS980MX Series switches.
maximum stack size 4 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables
can be used to stack CentreCOM GS980MX Series switches.
For local stacking:
■ AT-SP10TW1—1 meter SFP+ direct attach cable.
CentreCOM compatible stack partners CentreCOM FS980M Series switches can only stack with
FS980M Series other CentreCOM FS980M Series switches.
maximum stack size 4 switches.
cable type Standard Allied Telesis branded Twinax direct attach cables
can be used to stack CentreCOM FS980M Series switches.
For local stacking:
■ AT-SP10TW1—1 meter SFP+ direct attach cable.
Alternatively, to see the stack ID on a switch before it is connected to a stack, use the command:
awplus#show stack
The output will show the current stack ID and any pending change to the stack ID.
awplus#show stack
Virtual Chassis Stacking summary information
You can also use this command to see the stack numbers on a two-switch stack. To match the
physical switch with the right stack ID number, look for the active master LED on the front panel.
Then use the show stack command to show all members of the stack. You can match the LED
status to the show command output.
awplus#show stack
Virtual Chassis Stacking summary information
The show stack command is available on all stacking switches running the AlliedWare Plus
operating system.
On SBx908 and x900 Series switches, on the front of the XEM-STK there is an indicator that
displays the stack ID of the switch that the XEM is installed in.
On x600 and x610 Series switches, you can use the command:
This causes the master LED on the switch to flash in a sequence which indicates the stack ID
number. The pattern will be a number of flashes in quick succession followed by a longer pause;
where the number of flashes equals the stack member ID.
For example, on a four-switch stack with the stack IDs 1, 2, 3, and 4, the switch with stack ID:
You can extend the time that the master LEDs will flash by up to 500 seconds to give you more time
to reach the stack’s location, by using the optional time parameter with the command. By default
the LEDs will flash for 5 seconds.
For details of how this is implemented on the SBx8100, under VCStack Plus, please see "Monitoring
and troubleshooting" on page 82
You can assign stack IDs to switches before they are part of a stack:
To assign stack IDs once the stack is created, you can use the following methods:
"Renumbering the whole stack using the XEM Select button" on page 56
If your switch has never had a stack ID assigned to it, it will have the stack ID of 1. You can assign it
a new stack ID with the command:
If the switch has previously been in a stack and was assigned a stack ID, it keeps that stack ID with
it, even if it is removed from the stack. The stack ID has become an inherent property of the switch.
If you wish to renumber it you will need to specify the current stack ID.
The stack ID renumbering does not take effect until the switch is rebooted, so you will receive the
following warning as shown in the next figure.
awplus(config)#stack 1 renumber 2
Warning: the new ID will not become effective until the stack-member reboots.
Warning: the boot configuration may now be invalid.
Until the reboot occurs, the new stack ID value is noted as the 'pending' stack ID, as shown in the
next figure.
awplus#show stack
Virtual Chassis Stacking summary information
You can issue this command from the active master to renumber any switch in the stack. To avoid
duplicate IDs, a warning message appears if you assign to a stack member the same ID that is
currently assigned to another stack member. However, you can continue to renumber the stack
member IDs and fix potential ID duplications. Once you have removed any duplicate IDs, you can
reboot the switches with ID changes to implement your changes.
If you do not remove the duplications, then when the stack reboots, the switch with the highest
stack priority (the lowest priority value) is allocated this ID, and the competing switch is
automatically assigned another ID.
This starts the stack numbering on the switch that currently has Stack ID 3 and gives that switch
Stack ID 1. The other switches in the stack are renumbered sequentially based on their connection
to the switch that now has the stack ID 1.
The following diagram shows the numbering change from this command:
2 3
4 2
3 1
If the second stack ID parameter is not supplied in the command, then the numbering begins from 1.
When the numbering process hits the maximum existing stack ID value, it assigns the value 1 to the
next switch in the stack.
We recommend using this command to ensure the switches are sequentially numbered, if you did
not manually assign the switches with stack IDs before connecting them to the stack. Use the
command straight after the stack is first connected.
For example, if switch A in the stack currently has stack ID 2, then any commands in the
configuration script that refer to stack ID 2 are applied to switch A. If the stack IDs are renumbered,
so that stack ID 2 is now allocated to switch B, then the commands in the configuration script that
refer to stack ID 2 will now be applied to switch B. If switch A is given a stack ID which is not in the
configuration script, than it will not have any configuration applied. We recommend that you only
renumber the stack when it is initially configured, or during a time of major stack reconfiguration.
Prepare the replacement switch by configuring it with the same stack ID as the switch that you are
replacing.
awplus#reboot
Ensure that the replacement switch has the same set of feature licences as the existing stack
members.
On an SBx908 GEN2 switch, you need to enable stacking. Use the command:
Step 5: On an XS900MX, x950, x550, or SBx908 GEN2 switch, configure the stack ports
Configure the required ports as stack ports. For example, if ports 3 and 4 are the stack ports, use
the commands:
If replacing an XS900MX switch, only do this step if you are not using the default ports 15 and 16 for
stacking.
awplus# write
Connect the stacking cables to the replacement switch. Power up the replacement switch. It will
detect that there is already an active master, and so will come up as a stack member.
The active master will check that the new stack member has the same software version as itself.
If the software versions are different, the active master will use the software auto-synchronization
mechanism to force the new stack member to run the same software version.
The new switch will also receive the startup configuration from the active master. As the
replacement switch has been configured with the same stack ID as the replaced switch, it will
receive exactly the same configuration as the replaced switch, and will operate exactly as that
switch had.
Provisioning
Provisioning provides the ability to pre-configure ports that are not yet present in a switch or in a
stack. If you know that a unit is going to be added to a stack, you can pre-configure that new switch
in anticipation of its addition to the stack.
Similarly, if a switch can have XEM2 or XEM modules hot-swapped into it, then provisioning allows
the ports of those yet-to-be-inserted modules to be preconfigured ready for the arrival of the XEM2/
XEMs.
With provisioning you can configure stack members and their ports, even though they are not
currently physically present, and configure them ready for future addition. This means that you can
either pre-configure ports belonging to a bay or switch that has not yet been installed, or load a
configuration that references these ports.
Provisioning also automatically keeps track of the configuration that was present on XEM2/XEMs
that have been hot-swapped out of a switch, or on units that have been removed from a stack.
Provisioning keeps a 'placeholder' for a XEM2/XEMs or switch which has been hot-swapped out.
If you provision a switch or bay, then decide later to change the stack member ID or bay number
before it has been installed, you must unprovision (no switch <stack ID> bay/switch) the switch or
bay first.
Provisioning a bay
With the show system command we can see that the stack member 2— the x900-24XT switch—
does not have a XEM in bay 2:
awplus#show sys
Stack System Status Wed May 05 00:04:16 2015
Stack member 1:
Stack member 2:
We can see that Stack member 1 is the master, and we are connected to the console
port on this switch:
awplus#show stack
Virtual Chassis Stacking summary information
On the Stack master (stack member 1) we can provision a XEM-12 for Stack member 2 in bay 2
(which is currently empty):
Note that the switch automatically provisions all currently installed switches and XEMs as it boots up
(it does not provision the actual stacking XEMs).
We can see above that we now have ports 2.2.1-2.2.12 available for configuration in the running-
config, even though stack member 2 does not actually have a 12 port XEM (XEM-12) physically
installed in bay 2 yet.
This means that these ports can now be configured, ready for when the XEM-12 is installed.
Commands can refer to ports on that provisioned XEM as though it were already present:
Once a XEM is hot-swapped into bay 2 the switch 2 bay 2 provision XEM-12 will still show in the
running configuration, along with the other installed switches and XEMs.
If the XEM is removed, the provisioning for it will remain along with the configuration for the ports
associated with it.
We can see that the configuration associated with this port is still in the running configuration:
interface port1.1.1
switchport
switchport mode trunk
switchport trunk allowed vlan all
switchport trunk native vlan none
!
We can see above that port1.1.1 has had its configuration updated from the running configuration.
We can see that the provisioning has been modified to reflect the actual hardware installed, and the
running configuration now has ports1.1.1-1.1.12, which are the 12 ports belonging to the XEM-12T
in bay 1.
Provisioning a switch
We have a standalone switch that we will be adding another switch to in the future to form a stack:
awplus#show sys
Switch System Status Wed May 05 14:34:12 2015
awplus#show stack
Virtual Chassis Stacking summary information
We can provision stack member 1 so that we can configure the future stack member's ports before
we actually have the second switch connected:
awplus(config)#switch 1 provision ?
x600-24 Provision an x610-24 switch
x600-48 Provision an x610-48 switch
x900-12 Provision an x900-12 switch
x900-24 Provision an x900-24 switch
x908 Provision an x908 switch
Select the model of switch that will be connected in the future (note that you can only stack, and
therefore provision, switches of the same basic model).
If we try to provision an x900-24Ts/X switch for stack member 1, and the existing switch (stack
member 2) is an x900-12XT/S, we get the following error message:
The running-config shows that we can now configure the ports (1.0.1-1.0.12) on provisioned stack
member 1:
Note that the configuration applied to ports1.0.1-1.012 is just the default port configuration. The port
trunk configuration that had been provisioned for the XEM-1XP is completely discarded when the
XEM-12S is hot-swapped in instead.
For information about how the stack synchronizes the startup configuration and running
configuration between stack members, see the section "Software and configuration file
synchronisation" on page 66.
Port numbering
In the AlliedWare Plus operating system, switch port interfaces are always referenced as portx.y.z.
The first number, or 'x', in the three number port identifier is the Stack ID.
For a stand-alone switch that has never been in a stack, the ports are always numbered 1.y.z. When
configuring a stack, however, there will be stack members with other stack ID values. To configure
ports on these switches, use the stack ID to refer to each physical switch, for example 2.0.1, 2.0.2,
2.0.3, for the first 3 ports on a switch with stack ID 2.
Please note that when a switch is removed from a stack, it maintains its stack ID number. If it is
configured as a stand-alone switch, you will need to either change the stack ID back to 1, or use the
current stack ID when configuring its ports.
VLAN 4094
Subnet 192.168.255.0/28
You may need to change these values if they clash with a VLAN ID or subnet that is already in use in
the network. Use the commands:
It is important that the settings for management subnet and management vlan are the same for all
the switches in a stack. If a switch is added to a stack, and its setting for management vlan and/or
management subnet differ from those on the other stack members, the new switch will not be
joined to the stack and a log message similar to the following will be created:
We recommend that you avoid sending any user traffic into queue 7 on a VCStack. In any QoS
configuration on a stack, prioritize traffic only into queues 0-6. Moreover, you should ensure that the
CoS-to-Queue map does not automatically use queue 7 for the transmission of packets that are
received with a CoS value of 7. To ensure this, change the cos-to-queue map to put packets with a
CoS value of 7 into queue 6. Use the command:
Stacking triggers
There are five trigger types defined for particular stack events. Any scripts that you configure for
triggers are copied from the active master to all stack members. The triggers are:
Licensing
On a stack, the license command will activate the license on all the current stack members. If other
members are subsequently added to the stack, the license will not be automatically installed into
them. They will connect to the stack successfully, even though they have a different license status to
the other stack members. A log message warning you that a license mismatch now exists will be
generated, but you must manually install the required license(s) into the new member(s). It is
important to bring the new member(s) up to the same license level as the existing master. If this is
not done, then if a license-lacking member becomes master at some point, then the whole stack will
revert to the license level of that master.
Just as the license command applies a license to all current stack members, so too does the no
license command remove a license from all current stack members.
"Scripts" on page 68
The sequence of events that occurs at startup is shown in the output below:
Restarting system
The software auto-synchronization feature is enabled on all switches by default. You can enable or
disable it using the command:
If you disable software auto-synchronization, you may disrupt a stack forming if the stack members
have different software releases.
If a new member joins the stack, and is running a software version that is different to the active
master, the active master will reject the new member from the stack if it cannot synchronize the
software releases.
Note: This feature can result in the new stack member downgrading its software release if the active
master is running an older software version.
Occasionally you will find that the software version running on the existing stack members and the
software version on the new stack member are sufficiently incompatible that the stack will not be
able to auto synchronize the software version on the new member.
On these occasions, the log on the stack master may contain a message:
Also, the internal stacking log on the stack master may contain similar messages, that can be seen
by using the command show stack full-debug | include version.
2. manually upgrade the software on that switch to the same version as is running on the existing
stack members
Auto-synchronization will not update the software on the earlier CFC960 cards.
Note that this requirement only applies to CFC960 v2 cards that are labeled “SBx81CFC960 v2” on
the front panel of the card. For the purposes of this requirement, all cards that are labeled
“SBx81CFC960” are referred to as earlier cards, even if some of them are version 2 as indicated by
their documentation.
If you do combine cards that are running different software, then you need to remove the CFC960 v2
card or cards, update the software on the other cards, and re-install the CFC960 v2 cards.
This means that the running configuration on each stack member is exactly the same, and contains
the configuration information for all stack members. For example, on a two-switch stack, switch A
with stack ID 1 will show the configuration for switch B with stack ID 2, as well as its own
configuration. If the running configuration on switch B with stack ID 2 is examined, the output will be
exactly the same as that produced by switch A.
Every time the startup configuration script on the active master is changed, for example when the
running config is copied to the startup config, the updated startup script is copied to all the other
stack members.
It is important that you take this behavior into account when you first create a stack. If you have
carefully crafted a startup configuration on the switch that you intend to be the active master, but
some mistake results in a different switch becoming the active master when the stack forms, then
the intended startup configuration will be over written by something else (assuming the same
filename was used for both configurations).
take care when first installing the VCStack to ensure that you configure the stack priority values
correctly. If you do not, the wrong stack member may become the active master on first boot, and
overwrite the stack with the wrong startup configuration.
backup the startup configuration of the intended active master before connecting the switch to
the stack. You can make another copy on the switch's Flash file system with the command:
As well as the running configuration and startup configuration, the stack synchronizes the boot
backup configuration file, and the fallback configuration file. Like the startup configuration file,
these are synchronized from the active master’s file system, so the same recommendations apply.
Scripts
Script files stored on the active master’s file system are copied to the stack members.
Rolling reboot
A major benefit of Virtual Chassis Stacking is that it provides unit resiliency—if one unit in the stack
goes down, the other members of the stack will continue to forward data. It is highly desirable for
this continuity of service to persist even when the stack is being rebooted. The purpose of the
reboot rolling command is to reboot a stack in a manner that maintains continuity of service.
Occasionally there are restrictions on rolling reboot when upgrading from some software versions on
some switch models. Check the Release Note for the new release before using rolling reboot.
The reboot rolling command allows a stack to be rebooted in a rolling sequence so that no more
than one unit of the stack is in reboot at any given time. First, the stack master is rebooted causing
the remaining stack members to failover and elect a new master.
awplus#show stack
Virtual Chassis Stacking summary information
awplus#reboot rolling
The stack master will reboot immediately and boot up with the configuration file
settings. The remaining stack members will then reboot once the master has
finished re-configuring.
As soon as the rebooted Active master has reloaded, it becomes the Active master again. While it is
rebooting, another switch in the stack will assume the Active master role. Immediately after the
Active master has reloaded and assumed its role again, all of the other switches in the stack are
rebooted at the same time.
done!
Received event network.configured
Rolling reboot, rebooting all other stack members, please wait for stack to
reform.
You can see in the Active master's log that the other stack members (1 and 3) have rebooted:
2015 May 10 22:12:11 user.crit awplus-4 VCS[995]: Member 4 (0015.77c9.73cb) has become
the Active master
2015 May 10 22:12:37 local6.notice awplus VCS[995]: Link down event on stack link 4.0.2
2015 May 10 22:12:37 local6.notice awplus VCS[995]: Link down event on stack link 4.0.1
2015 May 10 22:13:32 local6.notice awplus VCS[995]: Link up event on stack link 4.0.1
2015 May 10 22:13:32 local6.notice awplus VCS[995]: Link down event on stack link 4.0.1
2015 May 10 22:13:32 local6.notice awplus VCS[995]: Link up event on stack link 4.0.2
2015 May 10 22:13:33 local6.notice awplus VCS[995]: Link down event on stack link 4.0.2
2015 May 10 22:13:36 local6.notice awplus VCS[995]: Link up event on stack link 4.0.1
2015 May 10 22:13:36 user.crit awplus VCS[995]:Member 3 (0015.77e8.a892)has joined stack
2015 May 10 22:13:36 user.notice awplus VCS[995]: Link between members 4 and 3 is up
2015 May 10 22:13:37 local6.notice awplus VCS[995]: Link up event on stack link 4.0.2
2015 May 10 22:13:37 user.crit awplus VCS[995]:Member 1(0015.77c2.4b7d) has joined stack
2015 May 10 22:13:37 user.notice awplus VCS[995]: Link between members 4 and 1 is up
2015 May 10 22:13:37 user.notice awplus VCS[995]: Link between members 3 and 1 is up
This problem is particularly important when a stack has multiple connections to edge switches in the
network. In this network scenario, if a stack splits into two active sections that are operating
independently, then the edge switches will continue to treat their uplink ports as aggregated and
share traffic across the links.
However, the broken stack link could mean that traffic arriving at some of the stack members cannot
reach the intended destination.
links no longer
aggregated at
stack end
aggregated
link
Backup
member
TM
aggregated VCStack
link
It is necessary to have a backup mechanism through which stack members can check if the active
master is still active in case the stack link communication to the active master is lost.
The mechanism provided in Allied Telesis VCStack is called the resiliency link, which may be either
the eth0 port (on SwitchBlade x908 or x900 Series switches) or a dedicated VLAN (resiliencylink
VLAN) to which switch ports may become members. These resiliency ports are connected together,
and the stack members all listen for periodic (one per second) Health Check messages from the
master. As long as the active master sends Health Check messages, the other stack members know
that the active master is still active.
This means that the stack members can know whether the active master is still operating if they lose
contact with the active master through the stacking links.
The out-of-band Ethernet port is configured as a resiliency port with the command:
Note that even if you configure the eth0 port as a resiliency port, you can still use it for out-of-band
management. A VLAN, and switch port are configured for resiliency link connection with the
commands:
Note also that this VLAN is dedicated to the resiliency link function and must not be the stack
management VLAN or a customer data VLAN.
In the situation where a stack member loses contact through the stacking links, but continues to
receive health check messages via the resiliency link, the stack member becomes a disabled
master. It runs the same configuration as the active master, but it has its links shutdown.
There is a trigger that can be configured when a switch becomes a disabled master with the
commands:
awplus(config)# trigger 82
awplus(config-trigger)# type stack disabled master
awplus(config-trigger)# script 1 flash:/disabled.scp
Although this command could activate any trigger script, the intention here is that the script will re-
activate the links from their previously shutdown state, to enable the user to manage the switch.
SBx8100 SBx8100
VCStack Plus Long Distance Stacking (LDS)
CFC960 CFC960 CFC960 CFC960
eth0 eth0 eth0 eth0
The show command show stack detail displays the resiliency link information on the SBx8100
CFC960.
The interface port command switchport resiliencylink is not supported the SBx8100 CFC960.
Note: The resiliency link feature is not supported on the SBx8100 standalone chassis.
Virtual MAC
To minimize data loss if a new stack member is required to become the master, enable a Virtual
MAC. The VCStack then uses the virtual MAC address for communication with other devices. As
this single virtual MAC address is used for the complete VCStack, there is no change of MAC
address if a new stack member is required to become master. In conjunction with Fast Failover, this
ensures maximum continuity of network service, as there is no need for other devices in the network
to learn a new MAC address into their MAC or ARP tables.
You can configure the virtual MAC address manually by specifying a VCStack virtual chassis ID. Or
the VCStack can use its default virtual chassis ID. The ID selected will determine which virtual MAC
address the stack will use. The MAC address assigned to a stack must be unique within its network.
Enter the chassis ID in decimal format. The virtual chassis ID entered will form the last 12 bits of a
pre-selected MAC prefix component; that is, 0000.cd370xxx.
For example:
When a stack detects a duplicate master, a debug snapshot file is created and stored in Flash. The
file is called debug-duplicate-master-<time & date>.tgz.
The debug snapshot does not contain a .core file, as is produced when a process unexpectedly
terminates on a switch. Instead, it contains a snapshot of various pieces of information within the
software at the time when the stack detected the duplicate master.
Disabled master
A properly functioning VCStack contains an (active) master and one (backup) member. Under fault
conditions it is possible for the stack member to lose connectivity with the stack master. In this
situation the stack member without master connectivity will become a “disabled master”. Once in
this state the disabled master will disable all of its own ports.
Apart from this, the operation and “look and feel” of a disabled master is very similar to an active
master. The active master’s ports are unaffected by this change, and they will continue to forward
traffic normally.
By disabling all the stub’s switchports, the disabled master avoids potential network connectivity
problems that could result from by having two stack masters using the same configuration, or two
switches in separated stubs trying to share the same “logical” communications paths such as a non
functioning aggregated links. The active master’s ports are unaffected by this, and they will continue
to forward traffic normally. Note that status information for members of the stack stub can be
accessed by logging into the disabled master, in the same way as obtaining status information for a
normal stack.
The DMM feature avoids this situation by continuing to monitor the status of the original stack
master (the active master) via the stack resiliency link. When the DMM feature is enabled, the
disabled master can detect a failure of the original stack master within a few seconds.
If a failure is detected, the disabled master transitions to the active master state and automatically
re-enables all its switchports. This allows traffic forwarding via the stack to continue.
STACK BEHAVIOR WITH DMM DISABLED STACK BEHAVIOR WITH DMM ENABLED
■ The VCStack breaks with the Stack Resiliency ■ The VCStack breaks with the Stack Resiliency
Link configured and enabled. Link configured and enabled.
■ The separated stack member becomes a ■ The separated stack member becomes a
disabled master. disabled master.
■ The disabled master does not monitor the active ■ The disabled master monitors the active master.
master.
STACK BEHAVIOR WITH DMM DISABLED STACK BEHAVIOR WITH DMM ENABLED
■ If the active master fails then the disabled master ■ If the active master fails then the disabled master
does not become the active master (no state becomes the active master (disabled to active
transition). transition).
■ No switchports are re-enabled on the disabled ■ Switchports on the disabled master are re-
master. No traffic is forwarded. enabled. Traffic is still forwarded.
To apply a trigger upon transition from active master state to disabled master state, use the
command:
To apply a trigger upon transition from disabled master state to active master state, use the
command:
Note: A disabled master trigger allows you to specify a script to reconfigure the disabled master on
the fly, should a catastrophic failure separate the stack. This is useful to configure an alternate
IP address so you can still log in to the disabled master via an SSH or a Telnet connection.
The trigger script should use the no shutdown command to re-enable any switchports
needed for an SSH or a Telnet management connection.
You set the Stack ID on the replacement device to the same ID as the device being replaced.
The replacement device is installed with the same licenses as the other stack members.
Once these requirements are met, insert the new stack member, reconnect the stacking ports and
power-up the new stack member.
Executing commands
You can use the reload command to reboot an individual switch, or use show commands to see
the individual physical state of a switch and its file system. Show commands that relate to the
ports, counters, or configuration are applicable for the stack only.
Managing files
You can manage files on an individual switch. Note that some files are synchronised between
switches. See the "Software and configuration file synchronisation" on page 66 section for more
information.
You can also delete files off all stack members simultaneously, see "Deleting files from all stack
members" on page 77.
Executing commands
Many monitoring commands display information about all stack members, including commands like
show system and show system environment.
For a number of other commands, you can display information from a specific stack member by
specifying the stack ID number in the syntax. For example, you can run the following commands on
the Master to see information about a specific stack member:
Additionally, the reload command can take a stack ID as an extra parameter. To reboot just the
stack member with stack ID 4, use the command:
awplus#reload stack-member 4
stack#reload stack-member 4
reboot stack member 4 system? (y/n):
Managing files
If you wish to perform an action on another stack member's file system, the syntax is:
awplus# <stack-member-name>/flash:[/]<filename>
The stack-member-name is not the stack ID, but is an extended hostname formed as:
awplus# <hostname>-<stack-ID>
If the hostname of the stack is BlueCore, then the stack-member-name for switch 2 in the stack
is:
BlueCore-2
If you do not use the stack-member-name prefix, then the command refers to a file that resides on
the stack master.
You can also use the stack-member-name syntax for the directory command. To view the contents
of the Flash file system on a specific stack member, you can use the syntax:
Examples To show files in the current directory across all stack members, use the command:
Use the wildcard with caution, because this command is non-interactive and does not ask for
confirmation before deleting files. This is indicated by the mandatory force parameter.
For example, to delete a file that is located in Flash memory on all stack members, use the following
command:
To remove directories ouput1 and output2 from an external card on all stack members, use the
command:
Remote login
Occasionally it can be desirable to login to a specific member of the stack (for example, to manage
feature licences per individual unit). Remote login facilitates this by allowing a user on the master
switch to log into the CLI of another stack member.
In most respects, once you are logged into the other stack member, the result of entering
commands will be is as if you were logged into the stack master, i.e. the command show ip
interface will show all IP interfaces configured on all switches in the stack - not just those on the
stack member that you have connected to with the remote-login command. Configuration
commands are still broadcast to all stack members.
Some show commands that display physical attributes of the switch, and commands that access
the file system, are executed locally. Also, commands related to feature licences are executed
locally.
To login from the stack master (stack member 1 in this case) to stack member 2:
awplus#remote-login ?
<1-8> A specific stack member ID
awplus#remote-login 2
Type 'exit' to return to awplus.
awplus-2>en
awplus-2#
Notice that the prompt has changed to reflect the stack member (2) that we are currently connected
to. A directory listing will now show the files on stack member 2 only:
awplus-2#dir *.cfg
948 -rw- May 4 2015 20:59:48 flash:/default.cfg
677 -rw- May 3 2015 18:39:04 flash:/zz.cfg
2944 -rw- Mar 23 2015 12:55:40 flash:/ospfv3.cfg
We can delete a file from stack member 2 as if we were directly connected to it:
awplus-2#del zz.cfg
Delete flash:/zz.cfg? (y/n)[n]:y
Deleting..
Successful operation
awplus-2#
awplus-2#exit
awplus#
awplus#remote-login 2
Type 'exit' to return to awplus.
awplus-2>en
awplus-2#
The show license command displays the current feature licenses on stack member 2:
awplus-2#show license
Software Feature Licenses
-----------------------------------------------------------------------------
Index : 0
License name : Base License
Customer name : Base License
Quantity of licenses : 1
Type of license : Full
License issue date : 10-May-2015
License expiry date : N/A
Features include : VRRP OSPF-64 RADIUS-100 Virtual-MAC
Index : 1
License name : Base License
Customer name : Base License
Quantity of licenses : 1
Type of license : Full
License issue date : 11-Aug-2014
License expiry date : N/A
Features include : BGP-64 PIM RIPNG VRRP OSPF-FULL VlanDT OSPF-64
BGP-FULL IPv6Basic MLDSnoop BGP-5K RADIUS-100 RADIUS-FULL PIM-100 ACCESS LAG-
128 Virtual-MAC
Use the license command to apply the required feature license to the VCStack, as shown in the
following output example.
The license command will add a license to all stack members and the no license command will
remove a license from all stack members.
awplus-2#license IPv6
Qd0NvZJ8DutyLAYbsM8pCpY1d8Ho9mzygweBp+paBqVu7By1bTZ+Jipo57
1 license installed.
awplus-2#show license
Index : 1
License name : Base License
Customer name : Base License
Quantity of licenses : 1
Type of license : Full
License issue date : 11-Aug-2014
License expiry date : N/A
Features include : BGP-64 PIM RIPNG VRRP OSPF-FULL VlanDT OSPF-64
BGP-FULL IPv6Basic MLDSnoop BGP-5K RADIUS-100
RADIUS-FULL PIM-100 ACCESS LAG-128 Virtual-MAC
Index : 1
License name : Base License
Customer name : Base License
Quantity of licenses : 1
Type of license : Full
License issue date : 09-May-2014
License expiry date : N/A
Features include : RADIUS-FULL
1. Shut down all stacking links to the switch you wish to remove from the stack. This is optional but
recommended, especially if someone other than you will do the step of physically uncabling the
switch.
4. Log into the disconnected device and run the command no stack <stack-id> enable.
5. If you want to use the switch as a standalone switch, reset its stack ID to 1. Use the command
stack <old-id> renumber 1
using the show stack detail command, see "Show stack detail command" on page 85
The tables following describe the LED state and functions for each switch series.
LEDs
SBx908 The stacking LED on the SwitchBlade x908 GEN2 and the x950, x930, x550, x530, x530L, x510,
GEN2, x310, XS900MX, GS980MX, and GS900MX/MPX Series is a 7-segment LED that displays the
x950, x930,
actual stack ID number. This LED is on the front panels of the units.
x550, x530,
x530L,
x510, x310, In addition, there is a link activity LED associated with each transceiver socket. The table below
XS900MX, shows the LED states when the socket is used for stacking.
GS980MX,
and
LED STATE MEANING
GS900MX/
MPX Link activity Off The slot is empty, the transceiver has not established a link to a
network device, or the LEDs are turned off.
To turn on the LEDs, use the eco-friendly button.
Solid green The transceiver has established a link at full speed to another switch
in the stack.
SBx8100 The front panel of the SwitchBlade x8100 CFC960 control card indicates the control card’s status
within the stack.
x610 The front panel of the x610 Series switch has the following LEDs for monitoring stacking:
MSTR Off The switch is not part of a stack or is a member unit of the stack.
L/A 1 Off Stack port 1 has not established a link to a stacking port on
another VCStack stacking module.
Solid Green Stack Port 1 has established a link to a stacking port on another
VCStack stacking module.
Flashing Green Stack Port 1 has established a link to a stacking port on another
VCStack stacking module and is sending or receiving packet
traffic.
L/A 2 Off Stack port 2 has not established a link to a stacking port on
another VCStack stacking module.
Solid Green Stack Port 2 has established a link to a stacking port on another
VCStack stacking module.
Flashing Green Stack Port 2 has established a link to a stacking port on another
VCStack stacking module and is sending or receiving packet
traffic.
SBx908 The front panel of the SwitchBlade x908 has LEDs for monitoring back-port stacking:
back-port
stacking
LED STATE MEANING
x600 The front panel of the x600 Series switch has the following LEDs for monitoring stacking:
Stack member 1:
------------------------------------------------------------------
ID 1
Pending ID -
MAC address 0000.cd29.95f7
Last role change Thu Mar 16 08:31:49 2017
Product type SwitchBlade x908
Role Active Master
Status Ready
Priority 128
Host name awplus
S/W version auto synchronization On
Resiliency link status Not configured
Stack port1.0.1 status Learnt neighbor 2
Stack port1.0.2 status Learnt neighbor 2
Stack member 2:
------------------------------------------------------------------
ID 2
Pending ID -
MAC address 0000.cd28.5377
Last role change Thu Mar 16 08:33:22 2017
Product type SwitchBlade x908
Role Backup Member
Status Ready
Priority 128
Host name awplus-2
S/W version auto synchronization On
Resiliency link status Not configured
Stack port2.0.1 status Learnt neighbor 1
Stack port2.0.2 status Learnt neighbor 1
awplus#
-------------------------------------------------------------------
You must enter the parameter VCS in uppercase letters when you enter this command. This
command enables you to receive a record of stack link and communication events.
For example if a stack port goes down, and then comes up again, the series of messages output is:
awplus#conf t
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)#conf tlog console program VCS
awplus(config)#exit
awplus#
awplus#08:37:01 awplus VCS[670]: Link down event on stack link port1.0.2
08:37:01 awplus VCS[670]: STK TRACE: Xbar update event is queued.
08:37:01 awplus VCS[670]: STK TRACE: Link port1.0.1: --> 2 (0000.cd28.5377)
08:37:01 awplus VCS[670]: STK TRACE: Link port1.0.2: N/A
08:37:01 awplus VCS[670]: STK TRACE: Stack topology has changed - updating stac
k H/W routes for L2 connectivity
08:37:02 awplus VCS[670]: STK TRACE: stack H/W route update complete
awplus#
If stack-link communication to a stack member is completely lost, the series of messages output is:
BlueCore#
BlueCore#01:04:55 BlueCore VCS[994]: STK TRACE: < Rxd Link-down msg on L2: 4 (00
15.77c9.
73cb) <--> 2 (0015.77e8.a87d)
01:04:55 BlueCore VCS[994]: Link between members 4 and 2 is down
01:04:55 BlueCore VCS[994]: STK TRACE: Link 1.0.1: --> 4 (0015.77c9.73cb)
01:04:55 BlueCore VCS[994]: STK TRACE: Link 1.0.2: --> 3 (0015.77e8.a892) --> 2
(0015.77e8.a87d)
01:04:55 BlueCore VCS[994]: STK TRACE: Stack topology has changed - updating st
ack H/W routes for L2 connectivity
01:04:55 BlueCore-3 VCS[996]: Link down event on stack link 3.0.2
01:04:56 BlueCore VCS[994]: STK TRACE: stack H/W route update complete
01:04:55 BlueCore-4 VCS[995]: Link down event on stack link 4.0.1
01:04:56 BlueCore VCS[994]: STK TRACE: < Rxd Link-down msg on L2: 3 (0015.77e8.
a892) <--> 2 (0015.77e8.a87d)
01:04:56 BlueCore VCS[994]: Link between members 3 and 2 is down
01:04:56 BlueCore VCS[994]: STK TRACE: Link 1.0.1: --> 4 (0015.77c9.73cb)
01:04:56 BlueCore VCS[994]: STK TRACE: Link 1.0.2: --> 3 (0015.77e8.a892)
01:04:56 BlueCore VCS[994]: Member 2 (0015.77e8.a87d) is leaving the stack (unr
eachable via stack links)
01:04:56 BlueCore VCS[994]: STK TRACE: Shutting down access to member 2's file
system
01:04:56 BlueCore VCS[994]: STK TRACE: Member 2 (0015.77e8.a87d) state Backup M
ember --> Leaving
01:04:56 BlueCore VCS[994]: Member 2 (0015.77e8.a87d) has left stack
01:04:56 BlueCore VCS[994]: STK TRACE: Stack topology has changed - updating st
ack H/W routes for L2 connectivity
01:04:56 BlueCore VCS[994]: STK TRACE: stack H/W route update complete
01:04:56 BlueCore VCS: Updating stack file system access...
01:04:57 BlueCore VCS: Shutting down access to member-2's file system
01:04:59 BlueCore VCS[994]: HA monitoring detected member-1 no change
01:04:59 BlueCore VCS[994]: HA monitoring detected member-3 no change
01:04:59 BlueCore VCS[994]: HA monitoring detected member-4 no change
01:04:59 BlueCore VCS[994]: HA monitoring detected member-2 left stack
01:04:59 BlueCore NSM[997]: Removal event on unit 2.0 has been completed
To see a very detailed log of stacking related events after they have occurred, and other VCStack
debug information, use the command:
Even if you had not been capturing stack log output at the moment an event occurred, you can still
retrospectively obtain the logging information by using this command. If you do not specify a stack
ID, then each stack member’s output is displayed, one after the other.
This command produces a large amount of output, as shown in the following figure. The "Stack
debug output" on page 86 section contains the detailed log information.
Link <multicast-link>
Window:20 packets
RX packets:102 fragments:0/0 bundles:0/0
TX packets:42244 fragments:0/0 bundles:0/0
RX naks:118 defs:2 dups:115
TX naks:4 acks:5 dups:231
Congestion bearer:0 link:0 Send queue max:18 avg:5
Link <1.1.1:vlan4094-1.1.2:vlan4094>
ACTIVE MTU:1500 Priority:10 Tolerance:3000 ms Window:50 packets
RX packets:261 fragments:0/0 bundles:0/0
TX packets:236 fragments:0/0 bundles:0/0
TX profile sample:28 packets average:42 octets
0-64:93% -256:7% -1024:0% -4096:0% -16354:0% -32768:0% -66000:0%
RX states:115 probes:29 naks:0 defs:0 dups:0 tos:0
TX states:130 probes:41 naks:0 acks:1 dups:0
Congestion bearer:0 link:0 Send queue max:1 avg:0
Link <1.1.1:vlan4094-1.1.3:vlan4094>
ACTIVE MTU:1500 Priority:10 Tolerance:3000 ms Window:50 packets
RX packets:1401 fragments:0/0 bundles:0/0
TX packets:1368 fragments:0/0 bundles:0/0
TX profile sample:86 packets average:43 octets
0-64:98% -256:2% -1024:0% -4096:0% -16354:0% -32768:0% -66000:0%
RX states:7745 probes:1234 naks:0 defs:0 dups:0 tos:0
TX states:10440 probes:3858 naks:0 acks:1 dups:0
Congestion bearer:0 link:0 Send queue max:5 avg:0
Link <1.1.1:vlan4094-1.1.4:vlan4094>
ACTIVE MTU:1500 Priority:10 Tolerance:3000 ms Window:50 packets
RX packets:187 fragments:0/0 bundles:0/0
TX packets:179 fragments:0/0 bundles:0/0
TX profile sample:48 packets average:42 octets
0-64:98% -256:2% -1024:0% -4096:0% -16354:0% -32768:0% -66000:0%
RX states:7994 probes:1333 naks:0 defs:0 dups:0 tos:0
TX states:10532 probes:4009 naks:0 acks:0 dups:0
Congestion bearer:0 link:0 Send queue max:5 avg:0
VCS management traffic
------------------------------------------------------------
Mon May 17 01:09:05 UTC 2015
Pkts Bytes
Non-VCS Q7: 0 0
Rx AIS: 21173 2559494
Rx mcast: 1912
EPSR 0 0 0
LACP 0 0 0
Mcast 0 0 0
sflow 0 0 0
BcExc 0 0 0
Other 0 0 0
PortAuth 0 0 0
TxBuff min: 952 86268ms ago
TxBuff cur: 1008
Last Rx: 11ms ago
Last Tx: 14ms ago
CPU0
16: 4135 IPIC Level Enabled 0 serial
17: 186739 IPIC Level Enabled 0 linux-kernel-bde
22: 0 IPIC Level Enabled 0 LM81 1
23: 0 IPIC Level Enabled 0 LM81 2
24: 287 IPIC Level Enabled 0 mpc83xx_spi
25: 749 IPIC Level Enabled 0 i2c-mpc
26: 0 IPIC Level Enabled 0 i2c-mpc
74: 0 IPIC Edge Enabled 0 GPIO
75: 0 IPIC Edge Enabled 0 GPIO
BAD: 0
VCS debug
------------------------------------------------------------
2015 May 16 23:39:23 kern.info awplus kernel: TIPC: Activated (version 1.6.4 com
piled May 4 2010 11:45:08)
2015 May 16 23:39:23 kern.info awplus kernel: TIPC: Started in single node mode
2015 May 16 23:39:25 user.info awplus VCS[960]: Parsing 'stack' commands from co
nfig file /flash/default.cfg
2015 May 16 23:39:25 kern.info awplus kernel: TIPC: Started in network mode
2015 May 16 23:39:25 kern.info awplus kernel: TIPC: Own node address <1.1.1>, ne
twork identity 4711
2015 May 16 23:39:31 user.debug awplus VCS[994]: SFL: Base feature license alloc
ated
2015 May 16 23:39:31 user.info awplus VCS[994]: SFL: [stackd] LicenceCheck: Virt
ual-MAC is active
2015 May 16 23:39:31 user.info awplus VCS[994]: SFL: [stackd] LicenceCheck: retu
rns Success.
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-topo-event sess
Pt=0x100696e8, addr=0x4800e000
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-port-1 sessPt=0
x10067480, addr=0x4800f000
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-port-2 sessPt=0
x10069c90, addr=0x48010000
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-topo-msg sessPt
=0x10069b40, addr=0x48011000
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-topo-error sess
Pt=0x10069b58, addr=0x48012000
2015 May 16 23:39:31 user.debug awplus VCS[994]: 2. init app stk-resiliency-link
sessPt=0x10066418, addr=0x48013000
2015 May 16 23:39:31 user.debug awplus VCS[994]: STK DEV : Stacking Resiliency
Link counters register is successful.
2015 May 16 23:39:45 user.debug awplus VCS[994]: STK DISC : Member-1 XEMs presen
t: Bay 0: XEM-STK,
2015 May 16 23:39:45 user.info awplus VCS[994]: Parsing 'stack resiliencylink vl
an' commands from config file /flash/default.cfg
2015 May 16 23:39:45 user.info awplus VCS[994]: Stacking Ports were discovered o
n the mainboard of member 1
Counters
You can obtain detailed counters relating to stack events and signaling packets with the show
counter stack command. You can use these for tracking down whether signaling packets are being
lost, by checking if there are discrepancies between the number sent from one switch and the
number received by its neighbor. The event counters make it possible to see if unexpected events
have been occurring on the stack. The following few pages contain some example output from the
show counter stack command:
Stack member 1:
Rx Reinitialise ......... 0
Rx Port 1 ......... 2
Rx Port 2 ......... 2
Rx 1-hop transport ......... 4
Rx Layer-2 transport ......... 14
Stack member 4:
This command is available on SBx908 and x950 Series. It is accessed in global configuration mode,
and is therefore savable. This means you can power off a XEM bay to stay across a hot swap of the
associated bay or a reboot.
C613-22075-00 REV V Disabling a faulty XEM on SBx908 GEN2 and x950 Series switches | Page 94
Virtual Chassis Stacking (VCStack)
x610 Series
Reconfiguring x6EM/XS2 stacking module ports as network ports
The Stack module x6EM/XS2 contains two 10 GbE SFP+ ports. By default, these ports are
configured for stacking. However, you can reconfigure them as network switch ports. To do this,
reconfigure the switch as a non-stacked switch, using the command no stack <stack-ID> enable,
then reboot to apply this configuration.
In the non-stacked mode these ports will appear as configurable switch ports, even without the
SFP+ Stack module being inserted within the switch. When configuring these ports, you can identify
them by their value 1 in the middle address component of the port number triplet. For example the
port number 1.1.2 has the components:
1 (stack member identifier; always a 1 in non-stack mode) .1 (the board identifier; always a 1 for the
Stack module) .2 (the port number on the Stack module: can have the value 1 or 2).
x930 Series
Reconfiguring StackQS stacking module ports as network ports
On x930 Series switches, you can configure each port on the StackQS card as:
a stacking port, or
The ports are configured as stacking ports by default. When converted to network switch ports, they
operate as 40 Gbps ports by default.
To convert the ports to network switch ports, you need to disable VCStack on the ports. There are
two options for doing this:
use the 10 Gbps front-panel SFP+ ports for stacking, by running the command:
stack enable builtin-ports
For example, to change both the stacking ports into 10 Gbps ports, use the commands:
awplus#configure terminal
awplus(config)#no stack 1 enable
awplus(config)#platform portmode int port1.1.1,port1.1.5 10gx4
When changing the portmode setting, you must also remove any interface and channel-group
configuration from the specified ports, and then reboot the switch. Note that the StackQS ports can
only operate as four 10 Gbps network switch ports on 28-port switch models, not on 52-port switch
models.
DC2552XS/L3 Series
Reconfiguring the front QSFP+ ports as network ports
On DC2552XS/L3 series switches, the front 4 QSFP+ ports can be configured as stacking ports or
network ports. By default, the ports are configured as stacking ports. Note that when stacking is
enabled, all four QSFP+ ports become stacking ports, even if you only use one or two ports for
stacking.
To convert stacking ports to network ports, VCStack needs to be disabled using the following
command:
Stack 1
Port 1.0.49, 1.0.53, 1.0.57, 1.0.61
the QSFP+ port must be configured for 10 Gbps mode using the following command:
PORT BECOMES
C613-22075-00 REV V
NETWORK SMARTER
North America Headquarters | 19800 North Creek Parkway | Suite 100 | Bothell | WA 98011 | USA | T: +1 800 424 4284 | F: +1 425 481 3895
Asia-Pacific Headquarters | 11 Tai Seng Link | Singapore | 534182 | T: +65 6383 3832 | F: +65 6383 3830
EMEA & CSA Operations | Incheonweg 7 | 1437 EK Rozenburg | The Netherlands | T: +31 20 7950020 | F: +31 20 7950021
alliedtelesis.com
© 2021 Allied Telesis, Inc. All rights reserved. Information in this document is subject to change without notice. All company names, logos, and product designs that are trademarks or registered trademarks are the property of their respective owners.