Layer 3 Traffic Forwarding From MCT Clients

Per Orlando for the first sentence below...I don't think this is accurate, I tested in my lab with static LAG in the MCT client and the L3 forwarding was still working.

For Layer 3 forwarding to work on MCT devices, a dynamic trunk must be configured on the MCT client.

Routes must be statically configured or dynamically learned on the MCT cluster devices.

The client routes the traffic towards its next hop, which can be either one of the MCT devices. If ECMP is deployed on the client, each MCT device can be a possible next hop. In such a deployment, the traffic can be load balanced at a Layer 3 level over the next two hops. Because a LAG is deployed at the client, this traffic is further subjected to load balancing at the Layer 2 level over the physical ports in the LAG. Thus, the traffic being sent out with the next hop as one of the MCT devices can either reach it directly or through the cluster peer (where it gets Layer 2 switched towards the intended next hop).

Therefore, almost 50 percent of traffic being forwarded from MCT clients (and as much as 100 percent of traffic in the worst case) can pass through the ICL. This fact should be considered when designing the ICL capacity in the network.

Parent topic: Layer 3 Unicast Forwarding over MCT