Configuration Guide User guide

FastIron Configuration Guide 843
53-1002494-02
Basic MCT configuration
22
Use the following command to start the cluster client automatic configuration. Within one minute of
the time that each client is discovered, the client is automatically configured and deployed into the
running configuration.
Make sure that the network connection and configuration are in place before using this command.
Syntax: client-auto-detect start [config-deploy-all]
Use the following command to stop the current running cluster client automatic configuration
process. All auto-detected but unconfigured clients will be cleared.
Syntax: client-auto-detect stop
MCT failover scenarios
The following scenarios describe what happens if specific elements in the MCT configuration fail.
• Client interface on one of the MCT cluster devices goes down.
Traffic switches to the other cluster device with minimal traffic loss.
• MCT cluster device goes down.
When an MCT cluster device goes down (for example, due to a power failure), the traffic will fail
over to the other MCT cluster device.
• Hitless failover occurs.
The MCT CCEPs stay up during hitless switchover, failover, or upgrade. Link protocols such as
UDLD and LACP on CCEPs do not flap. Traffic disruption is minimal (sub-second). The MCT CCP
connection will flap once, and MAC is re-synced between the peer devices.
The CCP will go down and come back up again once the hitless failover is completed.
• ICL interface or CCP goes down (keep-alive configured)
If a keep-alive VLAN is used, the devices in the cluster can communicate even if the ICL goes
down. If the peer device is reachable over the keep-alive VLAN, the MCT peers perform the
master/slave negotiation per client. After negotiation, the slave shuts down its client ports, and
the master client ports continue to forward the traffic.
The master/slave negotiation is performed per MCT client on the basis of RBridgeID and client
Local or Remote reachability. If the client is reachable from both MCT devices, the higher
RBridgeID becomes the master. If the client is reachable from one of the MCT devices only,
then the cluster device on which it is reachable becomes the master.
If the peer device is not reachable over the keep-alive VLAN, then both cluster devices will keep
forwarding.
NOTE
Brocade recommends using keep-alive VLANs with the MCT configurations. This will provide a
alternative reachability if the ICL interface goes down. However, a keep-alive VLAN should not
be configured when bpdu-flood-enable is configured. Refer to “BPDU forwarding” on page 850.
• ICL interface or CCP goes down (keep-alive not configured)
When the keep-alive VLAN is not configured, both cluster devices will keep forwarding. Use the
client-isolation strict command to remove the client interface as soon as the ICL link goes
down and completely isolates the client.