ActivChassis Overview
ActivChassis is a feature in which multiple devices, such as Layer 2 or Layer 3 switches, are connected to create a virtual chassis that can be managed as a single virtual switch. In essence, multiple devices are stacked using ActivChassis ports to create a larger logical device comprised of the individual devices. This feature allows multiple devices to share resources and operate as though they are part of a larger chassis-based system, while allowing configuration and control of the logical device from a single member.
Before Continuing , it is important to understand more about the internal components of ActivChassis. Make sure you are familiar with Configuring ActivChassis in AOS as the following document assumes the reader is ready to or has already set up an ActivChassis.
Below are a few Acronyms and definitions for reference with this document:
- VC - Acronym for ActivChassis
- Master - The switch in the VC that controls the stack.
- Backup - The switch in the VC that will assume control if the Master fails.
- Linecard - A slave member in the stack (neither Master nor Backup).
- VCID - ActivChassis ID number. Given to each individual switch (1-8) as an identifier. In normal operation, Master and Backup will be VCID 1-2 and Linecards will be VCID 3-8.
ActivChassis Design Recommendations
Depending on the amount of units in the ActivChassis, there are thousands of possible interconnections between the switches that can be created using the VC ports. However, many of these can be extremely inefficient and are not recommended. The recommended design for the interconnection between switches in an VC is a Daisy-Chained Ring topology, as shown below. This design scales with the number of switches in the stack and uses the VC resources the most efficiently as well as employing efficient fail-over. The Dual ring shown on the right is fully recommended if possible as it provides full stack fail-over as well as full Ring fail-over.
It is also recommend (as shown in the picture) that the Backup and master are evenly separated by linecards in the ring topology.
Labeling connections at the switch port configuration level is highly recommended for troubleshooting purposes. Being able to quickly trace a connection is vital when troubleshooting, especially if there over 350 interfaces in a stack of eight switches all in the same rack. You can configure an interface description as follows:
Switch(config)#interface gigabit-switchport 2/0/25
Switch(config-giga-swx 2/0/25)#description DNS Server
Along with this description configuration, it is recommended to physically label your switches with their VCID so it is easy to locate them in the rack. For instance, if you notice a problem on gig port 3/0/38, you can simply look at your labels for switch 3, and then look at the connection labels to quickly see which port it is, and what it connects to on the other side. Placing units with similar functions on the same part of the VC can also help this scenario: For instance, VCID 1-4 might have PCs, VCID 5-7 has phones, and VCID 8 has servers.
A VC makes a lot of its calculations and processing decisions with the Master switch's processor. This makes it even more important that all traffic is being forwarded efficiently because now there are up to 8 times more functions being performed by one switch's processor. Normal unicast traffic is forwarded via hardware and won't affect this, but large amounts of Multicast can have an effect on the processor. This makes it very important that units that utilize multicast (like Servers, Cameras, Set Top Boxes) are in their own VLANs so that this traffic is separated from the rest of the network. Also, using the command switchport protected on switchports is highly recommended if possible as shown in this document: Configuring Port Isolation (Protected Ports) in AOS - Quick Configuration Guide
ActivChassis Physical Location Considerations
There are several considerations when planning where VC's members are placed physically in reference to each other. Consider the following:
- A company has two buildings, A (main site with internet connection) and B (user site), which are separated by 300M; The company has a Fiber line installed to connect between the two buildings so they have connectivity to each other.
- The company has 175 users in each building that will connect directly to the switches.
- 4 1638s are purchased and installed for each building.
- The company's administrator would like to utilize ActivChassis for ease of management.
There are 3 basic ways this could be set up:
- Combine all 8 switches into a VC with the Master and Backup at building A.
- This is the least recommended setup. While this may be the easiest to manage, there are several concerns with this setup. Consider if the link between buildings goes down. The switches in building A would continue to work normally, but the switches at bulding B would be stranded without a Master (or an eligible Master replacement). These units would enter a "Locked State" (CAM table and STP state table locks and Broadcasts will are dropped) to prevent broadcast loops/storms. This would require manual intervention just to get that site back on-line.
- Combine all 8 switches into an VC with the Master at building A and the Backup at building B.
- This configuration is not the best, but acceptable. If the link between the buildings fails, building A would continue to work normally as a 4 switch VC without a backup. The backup at building B will become the Master and would control the other 3 switches at the site making a second VC. The only major concern with this is if one of the master switches fails as well, that buildings Linecards will now be stranded as there is not a 3rd and 4th backup. The potential of this happening is fairly low, but can still be considered a major problem if it were to occur.
- Combine the switches at each building into a separate VC of 4 units.
- This is the most highly recommended configuration. If the link between the buildings fails, both sides still have a master and a backup. If the Master fails on either side along with the interconnect link failing, the backups will take over and things will continue to function. This set up has the highest failure resiliency. On top of this, the VC's will run much more efficiently as two separate groups of 4 as there will be less processing load on the Master. The configuration will still be much easier to manage than normal as two switches instead of eight.
Rack placement of the Master and Backup is important as well. Currently, the switch configuration and CLI can only be viewed by the Master's console. Because of this, it is important that at least the Master and Backup switches' console connections are in a more accessible place: For instance, at human height and in a more open area of a switch lab/closet.
ActivChassis Spanning-Tree Recommendations
Once an ActivChassis is formed, all of the spanning-tree calculations are done by the Master of the VC because it is aware of the full topology of the stack. This means that the more calculations the VC has to perform, the more load that will be put on the Master's processor. If the network experiences a major topology change or rapid, consecutive topology changes, it is important to take several steps to make sure the Master will be able to handle all of the calculations without affecting other switch operations. This is why the below are recommended when setting up spanning-tree in your network.
1. Make sure every port connected to a endpoint or non-spanning-tree-participating device is set to edgeport mode.
- (config-giga-swx-1/0/1)#spanning-tree edgeport
- When an endpoint disconnects and reconnects to the network on an edgeport, it will not affect the current spanning-tree topology, reducing the calculations the VC must perform.
2. It is not recommended to make the VC the root of the spanning-tree.
- Though the VC can act as the root in some situations without problem, it is more efficient for another switch in the network to take on this role as there are many extra calculations and responsibilities that come with being the spanning-tree root of the network.
3. It is not recommended to connect more that 32 spanning-tree participating units directly connected to the ActivChassis.
- The more directly connected spanning-tree peers in the network, the more calculations have to be performed by the Master, using more Processor.
ActivChassis Link-Aggregation
An ActivChassis works as though it is a single switch. Port-channels created on a VC can have links from separate switches combined into one port-channel. For any major links to units outside of the VC itself, its recommended to aggregate the links using separate switches in the VC. For example, if port-channeling between two separate VC's, one might be tempted to connect copper between ports 1 and ports 2 on both VC's VCID 3. However, if one of the VCID 3 fails, both links are lost. The better configuration would be to connect VCID 3/port 1 on stack 1 to VCID 3/port 1 on stack 2 and VCID 4/port 1 on stack 1 to VCID 4/port 1 on stack 2. In this scenario, if VCID 3 fails, the link will not be lost.
A recommendation along with this is that any high traffic links between a VC and another entity (be a VC or another switch or router) be connected to a linecard to reduce load on the master.
ActivChassis Limitations
It is important to note that because a VC still acts as 1 switch, most 1638 limits (in terms of feature support, etc.) apply in the same manner to a VC as if it were 1 1638. A list of a few of these:
- Supports 10 port-channels
- Supports 24 ADTRAN Wireless APs
- Supports 256 layer 3 Interfaces
- Supports 2000 Routes
- Supports 32,000 MAC entries
- Supports 4000 ARP entries with 512 max per VLAN IP interface
If you have any questions or concerns, please contact ADTRAN support at 888-423-8726 or at support.adtran.com
