Understanding Traffic Flow Through a Virtual Chassis Fabric

Smart Trunking Algorithm for Unicast Traffic Forwarding

A Virtual Chassis Fabric (VCF) forwards unicast traffic using a smart trunking algorithm that sends all traffic across multiple paths based on end-to-end available bandwidth. The smart trunking algorithm avoids unnecessary congestion due to improper traffic allocation while optimizing fabric bandwidth utilization because traffic is forwarded through the VCF relative to available bandwidth.

The smart trunking algorithm works by considering the overall available path bandwidth of each path in the VCF when making traffic-forwarding decisions, and then forwarding traffic across the paths relative to available path bandwidth. If a VCF with two spine devices, for instance, has one path from leaf device 1 to leaf device 4 that contains two 40-Gbps QSFP+ links and a second path from leaf device 1 to leaf device 4 that contains two 10-Gbps SFP+ links, the algorithm tries to balance traffic sent on the paths so that four times more packets are sent on the first path with 40 Gbps of available bandwidth across the entire path than are sent on the second path with 10 Gbps of total bandwidth.

You can optimize how traffic is forwarded through the VCF by adding spine devices to maximize the number of available paths between all leaf devices, and by using as many 40-Gbps QSFP+ interfaces as Virtual Chassis ports (VCPs) as possible.

Multicast Distribution Trees for Broadcast, Unknown Unicast, and Multicast Traffic

A VCF creates bidirectional, shared multicast distribution trees (MDTs) to choose forwarding paths for broadcast, unknown unicast, and multicast (BUM) traffic between the members of the VCF. By default, one MDT is rooted at the source for each VCF member—the VCF creates the same number of MDTs as members in the VCF, and each MDT has one of the members as its root node. The VCF topology, application of load balancing, and VCF member availability can influence how traffic is forwarded along these paths.

Starting in Junos OS Release 14.1X53-D35 and 15.1R3, you can preempt default MDT behavior and form MDTs only with specific members as root nodes. If you are familiar with traffic patterns and load conditions in your VCF and want more control over how VCF MDTs are created, you can use the fabric-tree-root configuration statement to have the VCF form MDTs only with specific members as root nodes (called fabric tree roots.) If at least one device in the VCF is available that was configured as a fabric tree root, instead of the default behavior, the VCF will form MDTs with configured fabric tree roots only. The VCF will revert to the default behavior if there are no available VCF members configured as fabric tree roots.

If you use this option to configure specific members to be fabric tree roots, we recommend that you configure all spine members and only the spine members in the VCF as fabric tree roots, for the following reasons:

• Configuring multiple spine devices as MDT root nodes prevents member switches from inadvertently returning to the default behavior (where all members become MDT root nodes) if a spine node becomes unavailable.

• In a VCF with many leaf nodes, the default MDT algorithm results in many MDTs being used when balancing traffic within the VCF. When a leaf node goes offline or is reset, the MDT with that root leaf node is no longer available, triggering interruptions in VCF traffic flow to rebalance the load based on the remaining MDTs. When the VCF is configured with only spine devices as MDT root nodes, if a leaf node becomes unavailable, the VCF continues using the same spine root MDTs without traffic disruption.

The recommendation to configure all and only spine devices as MDT root nodes is due to how spine devices are connected in the VCF spine-and-leaf topology, and is not influenced by the roles of the spine devices (whether a spine device is acting as a Routing Engine or line card) in the VCF.

Adaptive Load Balancing

Starting in Junos OS Release 14.1X53-D10, a VCF supports adaptive load balancing (ALB).

ALB enables the VCF smart trunking and multicast distribution algorithms to use dynamic load information on interfaces and traffic queues to make forwarding decisions within the VCFWhen ALB is implemented using flowlets, traffic flows that enter the VCF are spliced into smaller flows—flowlets—and individually forwarded across the VCF to the same destination device over different paths when the inactivity time between packet bursts on the sending interface exceeds the user-configurable inactivity interval. When ALB is implemented using per-packet mode, the sending interface actively monitors all paths available between two member devices and forwards traffic through the VCF using the best available path at the moment. You use the fabric-load-balance configuration statement to enable ALB using flowlets or per-packet mode.

Implementing ALB using flowlets is effective in environments that periodically experience extremely large traffic flows—elephant flows—that are substantially larger than the majority of other traffic flowing through the VCF. The VCF is better able to manage the elephant flows by splicing them into smaller flowlets using ALB.

ALB is supported on a non-mixed VCF composed entirely of QFX5100 switches only. You should enable ALB using flowlets in non-mixed VCFs in environments where a small number of traffic flows are disproportionately larger than the majority of the other traffic flows.