MCT Recommendations and Best Practices

The following configurations and settings are recommended for MCT.

• MCT clients must not be physically connected with each other.
• There should be only one MCT client connection to the MCT cluster from each access switch closet to ensure proper load balancing and prevents potential loop issues within the network,
• Ensure that there is no device connectivity to MCT cluster on CEP ports to prevent potential issues with network stability and redundancy; the intended use of CEP ports is for client connections to the MCT cluster, not direct connections between devices and the cluster itself.
• Spanning tree protocols (xSTP) must not be configured on MCT VLAN.
• Enable RSTP only on MCT VLANs in deployments that have only CCEP clients.
• Do not enable RSTP on an MCT cluster in deployments that include both CEP and CCEP.
• A cluster must not be undeployed or removed using the no deploy command (under cluster) or no cluster command while traffic is running, as it may cause traffic disruption. These commands should be executed in the maintenance window.
• Configure cluster peers in loose mode with keepalive.
• Configure the no spanning-tree 802-1wcommand under LAG interface on MCT clients connected to the cluster.
• Set the hello timer for VRRP-E to 20 seconds.
• If a device is connected to both cluster nodes on CEP ports making it a triangle topology, set icl-fwd-delay to 10 seconds under cluster.
• Configure the ccep-up-delay setting to 300 seconds under cluster.
• Configure the VE delay notification setting to 15 seconds.
• Layer 2 multicast traffic may drop for a longer time (approximately 2 minutes and 27 seconds) after an active controller unit is added to an MCT peer stack.
• In an MCT configuration with stacking rings, after a standby controller goes down and comes back up, traffic loss may occur, including on ports from stack units other than the standby controller.
• In an MCT configuration with ICX 7550 or ICX 7850 peer stacks that includes a static LAG connection through a copper GBIC, traffic loss of up to 12 seconds may occur when any unit rejoins the stack following a failover or unit reload.
• In a scaled MCT configuration, Layer 2 traffic spikes may occur when one of the MCT peers rejoins after a reload.
• When a core link flap or peer reload occurs and uplink traffic is being received via a cluster, a significant delay may occur before CR MAC entries are changed to CL MAC entries.