Please login to access that KB Article

Configuring MCT Cluster

Summary

This document provides a detailed guide on configuring a Multi-Chassis Trunking (MCT) cluster using two ICX switches to operate as a logical cluster for enhanced redundancy and resiliency. It includes topology details, VLAN configurations, and step-by-step commands for setting up the cluster peers and verifying the configuration. •MCT cluster overview: MCT enables two independent ICX switches to function as a single logical cluster, providing active-active forwarding, link redundancy, and device-level resiliency for downstream devices through synchronized cluster peers connected by an Inter-Chassis Link (ICL). •Topology and VLAN roles: The setup involves two ICX 7850-48F switches as peers with specific interfaces assigned for the ICL, Keep Alive VLAN, and client connections. The ICL is a static LAG for cluster communication, and the MCT Session VLAN is dedicated for control traffic, separate from client VLANs.

Question

How do I configure the MCT Session VLAN and Keepalive VLAN?
How do I con

Customer Environment

Peer A: ICX 7850-48F Peer B: ICX 7850-48F Client A: ICX 7550-24P Firmware Version (all devices): 10.0.10g_cd6

Symptoms

Users need guidance to configure and verify an MCT cluster and downstream MCT client on RUCKUS ICX switches.
 

 

Root Cause

This KB was created to provide configuration guidance for deploying an MCT cluster and downstream MCT client, including the ICL, Session VLAN, Keepalive VLAN, client/member VLAN, and verification steps.Show more lines

Troubleshooting Steps

Configuring Multi-Chassis Trunk MCT

Purpose

This KB explains how to configure the initial Multi-Chassis Trunking MCT Reference :

Multi-Chassis Trunking

 

MCT allows two independent ICX switches to operate as a logical cluster for downstream devices, providing active-active forwarding, link redundancy, and device-level resiliency. The RUCKUS MCT design guide explains that MCT provides an active-active topology where client devices can connect to both cluster peers using LAGs, while the two cluster peers synchronize through the ICL.

 

2. Topology  used

 

Based on the provided topology:

Device

Role

Interfaces Used

Peer-A

MCT Cluster Peer A

1/1/1 and 1/1/2 for ICL

Peer-A

Keep Alive Vlan

1/1/3

Peer-A

Client

1/1/5

Peer-B

Keep Alive Vlan

1/1/3

Peer-B

MCT Cluster Peer B

1/1/1 and 1/1/2 for ICL

Peer-B

Client

1/1/6 and 1/1/8

 

 

 

 

Topology Information:

  • Peer A: ICX 7850-48F
  • Peer B: ICX 7850-48F
  • Client A: ICX 7550-24P
  • Firmware Version (all devices): 10.0.10g_cd6

3. What Is the ICL?

 

The Inter-Chassis Link ICL is the connection between the two MCT peer switches. This link is required for the peers to exchange MCT control information and maintain the cluster state.

The RUCKUS MCT design guide explains that the two cluster switches are connected using a single link or LAG called the Inter-Chassis Link ICL, and that CCP runs on the ICL to establish the MCT cluster.

 

Why it is needed

The ICL is used for:

  • Cluster communication between Peer-A and Peer-B.
  • Synchronization between both MCT peers.
  • Maintaining the correct forwarding behavior when downstream clients are attached.
  • Allowing both switches to operate as one logical MCT cluster from the client perspective.

Requirement

The ICL must be configured as a static LAG.

 

4. What Is the MCT Session VLAN?

 

The MCT Session VLAN is the VLAN used for MCT control communication between the two cluster peers.

This VLAN provides the control path for packet exchanges between the two MCT cluster switches.

 

Important note The Session VLAN should be dedicated to MCT control communication. It should not be used as a normal client VLAN or production user VLAN.

 

5. Important Design Notes Before Configuration

Before configuring MCT, validate the following:

  1. Both switches should be running a compatible FastIron version.
  2. The same MCT-related VLANs must exist on both peers.
  3. The ICL must be a static LAG.
  4. The Session VLAN must be tagged on the ICL LAG.
  5. Each peer must have a unique RBridge ID.
  6. The peer IP address must point to the remote peer MCT session interface.
  7. The cluster should only be deployed after both sides are configured correctly.

5. MCT Keepalive VLAN

The Keepalive VLAN is a separate backup peer-reachability path between both MCT switches the Keepalive VLAN uses the dedicated physical link on port between the peers

 

6. Configuration

 

Peer A

 

6.1 Configure the static ICL LAG

 

Peer-A(config)#lag MCT-ICL static id 2

Peer-A(config-lag-MCT-ICL)#ports ethernet 1/1/1 to 1/1/2

LAG MCT-ICL deployed successfully!

 

6.2 Session VLAN

 

Peer-A(config)#vlan 3000 name MCT-SESSION by port

Peer-A(config-vlan-3000)#tagged lag 2

Added tagged port(s) lag lg2 to port-vlan 3000.

 

6.3 Session VE Interface

 

Peer-A(config)#interface ve 3000

Peer-A(config-vif-3000)#ip address 1.1.1.1 255.255.255.252

 

6.4 Keepalive VLAN

 

Peer-A(config)#vlan 3001 name MCT-KEEPALIVE by port

Peer-A(config-vlan-3001)#untagged ethernet 1/1/3

Added untagged port(s) ethe 1/1/3 to port-vlan 3001.

 

Peer B

 

7.1 Configure the static ICL LAG

 

Peer-B(config)# lag MCT-ICL static id 2

Peer-B(config-lag-MCT-ICL)#ports ethernet 1/1/1 to 1/1/2

LAG MCT-ICL deployed successfully!

 

7.2 Session VLAN

 

Peer-B(config)#vlan 3000 name MCT-SESSION by port

Peer-B(config-vlan-3000)#tagged lag 2

Added tagged port(s) lag lg2 to port-vlan 3000.

 

7.3 Session VE Interface

Peer-B(config)#interface ve 3000

Peer-B(config-vif-3000)#ip address 1.1.1.2 255.255.255.252

 

7.4 Keepalive VLAN

 

Peer-B(config)#vlan 3001 name MCT-KEEPALIVE by port

Peer-B(config-vlan-3001)#untagged ethernet 1/1/3

Added untagged port(s) ethe 1/1/3 to port-vlan 3001.

 

Important Note: On both peers, VLAN 1 must be removed from the ICL LAG configuration because it is the default VLAN on the switch and is not required for MCT control communication. The ICL should only carry the dedicated MCT Session VLAN, VLAN 3000, as a tagged VLAN.

 

Peer A

Peer-A(config)#vlan 1

Peer-A(config-vlan-1)#no untagged lag 2

Peer B

Peer-B(config)#vlan 1

Peer-B(config-vlan-1)#no untagged lag 2

 

8.  Cluster Configuration

 

8.1 Peer A

 

Peer-A(config)#cluster MCT-CLUSTER 1

dPeer-A(config-cluster-MCT-CLUSTER)# rbridge-id 1

Peer-A(config-cluster-MCT-CLUSTER)# session-vlan 3000

Info - IP addresses configured on VE 3000 will not be advertised as connected route by any routing protocol as it is configured as session-vlan.

Peer-A(config-cluster-MCT-CLUSTER)# keep-alive-vlan 3001

Peer-A(config-cluster-MCT-CLUSTER)# icl MCT-ICL lag 2

1.1.1.2 rbridge-id 2 icl MCT-ICL

 deployPeer-A(config-cluster-MCT-CLUSTER)# peer 1.1.1.2 rbridge-id 2 icl MCT-ICL

Peer-A(config-cluster-MCT-CLUSTER)# deploy

 

8.2 Peer B

 

Peer-B(config)#cluster MCT-CLUSTER 1

sePeer-B(config-cluster-MCT-CLUSTER)# rbridge-id 2

Peer-B(config-cluster-MCT-CLUSTER)# session-vlan 3000

Info - IP addresses configured on VE 3000 will not be advertised as connected route by any routing protocol as it is configured as session-vlan.

Peer-B(config-cluster-MCT-CLUSTER)# keep-alive-vlan 3001

Peer-B(config-cluster-MCT-CLUSTER)# icl MCT-ICL lag 2

l MCT-ICL

 deployPeer-B(config-cluster-MCT-CLUSTER)# peer 1.1.1.1 rbridge-id 1 icl MCT-ICL

Peer-B(config-cluster-MCT-CLUSTER)# deploy

 

Important note: We already execute deploy command in the cluster, so the cluster is currently active. If we need to make any configuration changes or add new settings, we first need to access the cluster configuration then run the no deploy command. After that, apply the required changes and then perform a deploy again. Otherwise, the cluster will not allow configuration changes while it is in the active state.

 

9. Verification 

 

You can use the following commands to verify the MCT cluster status:

 

show cluster MCT-CLUSTER config

show cluster MCT-CLUSTER ccp peer

show cluster MCT-CLUSTER peer

show cluster

 

Once the MCT cluster is deployed successfully, the cluster status should look similar to the following:

 

 

Configuring MCT Client-A on RUCKUS ICX

 

This section explains how to configure the downstream MCT client after the MCT cluster has already been created between Peer-A and Peer-B.

The client device connects to both MCT peers using a LAG. From the client perspective, several physical links are bundled into one logical LAG. From the MCT cluster perspective, the LAG is split across both peers to provide redundancy and active-active forwarding.

 

1. Topology Reference for Client-A

 

Based on the topology, Client-A is connected as follows:

 

Device

Interface

Connected To

Purpose

Peer-A

1/1/5

Client-A 1/1/6

MCT client LAG member

Peer-B

1/1/6

Client-A 1/1/5

MCT client LAG member

Peer-B

1/1/8

Client-A 1/1/8

MCT client LAG member

 

Important Design Notes Before Configuring the Client

 

Before adding Client-A to the MCT cluster, verify the following:

 

  1. The MCT cluster must already be deployed and stable.
  2. The ICL LAG must be up between Peer-A and Peer-B.
  3. The Session VLAN must be working over the ICL.
  4. The Keepalive VLAN must be configured and reachable.
  5. The client-facing LAG should use LACP/dynamic LAG.
  6. The same client LAG ID should be referenced under the cluster on both peers.
  7. The same client VLANs should be configured on both peers.
  8. VLAN 1 should not be carried unnecessarily across the ICL or client uplinks unless the design specifically requires it.

RUCKUS documentation explains that the ICL supports only static ports, while client LAGs can be static or dynamic

 

2. Peer-A Client Configuration

 

2.1 Client LAG on Peer-A

 

Peer-A(config)#lag CLIENT-A-LAG dynamic id 21

Peer-A(config-lag-CLIENT-A-LAG)#ports ethernet 1/1/5

LAG CLIENT-A-LAG deployed successfully!

 

2.2 Client VLAN

 

Peer-A(config)#vlan 10 name MCT-CLIENT-VLAN by port

Peer-A(config-vlan-10)# tagged lag 21

Added tagged port(s) lag lg21 to port-vlan 10.

Peer-A(config-vlan-10)# tagged lag 2

Added tagged port(s) lag lg2 to port-vlan 10.

 

Reference:

  • lag 21, which is the client-facing LAG
  • lag 2, which is the ICL LAG

 

Also remove the LAG from VLAN 1

 

Peer A

Peer-A(config)#vlan 1

Peer-A(config-vlan-1)#no untagged lag 21

 

Note : Client/Member VLAN Tagging Requirement: The client/member VLAN must be added to the ICL LAG and to the client-facing LAG on both MCT peers. This is required because the MCT member VLAN is associated with the VLANs carried across the ICL. On the client side, the VLAN can be configured as either tagged or untagged depending on the design requirements and how the connected device expects to receive the traffic.

 

3.3 For this example, an IP address will be assigned to the client VLAN 10. This allows VLAN 10 to be used as a Layer 3 interface for validation, management, or routing purposes, depending on the network design.

 

Peer-A(config)#interface ve 10

Peer-A(config-vif-10)#ip address 192.168.10.2/24

 

3.4 Client Deployment Under the Cluster

 

Peer-A(config-cluster-MCT-CLUSTER)#cluster MCT-CLUSTER 1

rbridgePeer-A(config-cluster-MCT-CLUSTER)# client Client-A

Peer-A(config-cluster-MCT-CLUSTER-client-Client-A)# rbridge-id 3

Peer-A(config-cluster-MCT-CLUSTER-client-Client-A)# client-interface lag 21

Peer-A(config-cluster-MCT-CLUSTER-client-Client-A)#  deploy

 

Note : The client RBridge ID identifies that downstream client inside the MCT cluster, so Peer-A and Peer-B must reference the same client’s name and the same client RBridge ID when they are configuring the same Client-A.

 

4. Peer-B Client Configuration

 

4.1 Client LAG on Peer-B

 

Peer-B(config)#lag CLIENT-A-LAG dynamic id 21

ports ethernet 1/1/6

 ports ethernet 1/1/8Peer-B(config-lag-CLIENT-A-LAG)# ports ethernet 1/1/6

LAG CLIENT-A-LAG deployed successfully!

Peer-B(config-lag-CLIENT-A-LAG)# ports ethernet 1/1/8

 

5. Client VLAN

 

Peer-B(config)#vlan 10 name MCT-CLIENT-VLAN by port

Peer-B(config-vlan-10)#tagged lag 21

Added tagged port(s) lag lg21 to port-vlan 10.

Peer-B(config-vlan-10)#tagged lag 2

Added tagged port(s) lag lg2 to port-vlan 10.

 

Reference:

 

  • lag 21, which is the client-facing LAG
  • lag 2, which is the ICL LAG 

Also remove the LAG from VLAN 1 

 

Peer B

Peer-B(config)#vlan 1

Peer-B(config-vlan-1)#no untagged lag 21

 

5.2   For this example, an IP address will be assigned to the client VLAN 10. This allows VLAN 10 to be used as a Layer 3 interface for validation, management, or routing purposes, depending on the network design.

 

Peer-B(config)#interface ve 10

Peer-B(config-vif-10)#ip address 192.168.10.1/24

 

5.3 Client Deployment Under the Cluster

 

Peer-B(config)#cluster MCT-CLUSTER 1

rbridge-Peer-B(config-cluster-MCT-CLUSTER)# client Client-A

Peer-B(config-cluster-MCT-CLUSTER-client-Client-A)# rbridge-id 3

Peer-B(config-cluster-MCT-CLUSTER-client-Client-A)# client-interface lag 21

Peer-B(config-cluster-MCT-CLUSTER-client-Client-A)#  deploy

 

 

6.  Client-A Local Configuration

 

On Client-A, all uplinks going to Peer-A and Peer-B must be bundled into the same LACP LAG.

 

Client-A port mapping:

 

Client-A Port

Connected To

1/1/6

Peer-A 1/1/5

1/1/5

Peer-B 1/1/6

1/1/8

Peer-B 1/1/8

 

6.1 Client-Facing LAG on the MCT Peers

 

Client-A(config)#lag MCT-UPLINK dynamic id 21

Client-A(config-lag-MCT-UPLINK)#ports ethernet 1/1/5 ethernet 1/1/6 ethernet 1/1/8

LAG MCT-UPLINK deployed successfully!

 

6.2 Client VLAN

 

Client-A(config)#vlan 10 name MCT-CLIENT-VLAN by port

Client-A(config-vlan-10)# tagged lag 21

Added tagged port(s) lag lg21 to port-vlan 10.

 

 

Also remove the LAG from VLAN 1 

 

Client-A(config)#vlan 1

Client-A(config-vlan-1)#no untagged lag 21

 

6.3 Create a VE interface on the client VLAN to validate connectivity.

 

Client-A(config)#interface ve 10

Client-A(config-vif-10)#ip address 192.168.10.10/24

 

Client-A#ping 192.168.10.1

Sending 1, 16-byte ICMP Echo to 192.168.10.1, timeout 5000 msec, TTL 64

Type Control-c to abort

Reply from 192.168.10.1    : bytes=16 time=6ms TTL=64

Success rate is 100 percent (1/1), round-trip min/avg/max=6/6/6 ms.

 

Client-A#ping 192.168.10.2

Sending 1, 16-byte ICMP Echo to 192.168.10.2, timeout 5000 msec, TTL 64

Type Control-c to abort

Reply from 192.168.10.2    : bytes=16 time=3ms TTL=64

Success rate is 100 percent (1/1), round-trip min/avg/max=3/3/3 ms.

 

6.4 For reference, all client-facing ports should be in an up state, as shown in the screenshot below.

 

Download
(95.8 KB)

Attachment 2

Client-A
rtf
Download
(63.5 KB)

Attachment 3

Peer-B
rtf
Download
(98.6 KB)

Article Number:
000015488

Updated:
July 31, 2026 01:16 PM (about 1 month ago)

Answer Attachment 1
Peer-A
rtf
Download
(95.8 KB)

Answer Attachment 2
Client-A
rtf
Download
(63.5 KB)

Answer Attachment 3
Peer-B
rtf
Download
(98.6 KB)

Tags:
Configuration, Ruckus ICX Switches

Votes:
0

This article is:
helpful
not helpful

Working...Please wait

This is here to prevent you from accidentally submitting twice.

The page will automatically refresh.

Alert!!

Close