Configuration Guide User guide

828 FastIron Configuration Guide
53-1002494-02
Multi-Chassis Trunking Overview
22
MCT inherits all of the benefits of a trunk group by providing multiple physical links to act as a
single logical link. The new available bandwidth is an aggregate of all the links in the group. The
traffic is shared across the links in the group using dynamic flow-based load balancing and traffic is
moved to a remaining link group in sub-seconds in the event of a failure in one of the links. MCT
eliminates the single point of failure that exists at a device level when all links of a trunk terminate
on the same device without the overhead associated with spanning tree. MCT diverts a subset of
the links to a second device to provide redundancy and sub-second fault detection at the device
level.
How MCT works
Figure 95 shows a basic MCT configuration. The MCT initiates at a single MCT-unaware server or
switch and terminates at two MCT-aware devices.
FIGURE 95 How MCT works
The MCT process involves the following processes:
• Sub-second failover occurs in the event of a link, module, switch fabric, control plane, or device
failure.
• Sub-second failover operates at the physical level.
• Layer 2 and Layer 3 forwarding (when using fast path forwarding) is done at the first hop
regardless of VRRP-E state.
• Load balancing is flow-based (does not involve VLANs sharing across network links).
• Resiliency is supported regardless of the traffic type (Layer 3, Layer 2 or non-IP legacy
protocols).
• Interaction with Metro Ring Protocol (MRP) builds larger resilient Layer 2 domains.
• Device level redundancy is provided in addition to link and modular redundancy.
• Traffic received from an ICL port is not forwarded to the Cluster Client Edge Ports (CCEPs) if the
MCT peer device has the reach ability to the same cluster client.
CEP
MCT Unaware
Switch
Trunk
Group
MCT
Trunk
Group
MCT Cluster Device 2
ICL Trunk Group
MCT Cluster Device 1
CCEP
CCEP
CEP