In the first case, the channel breakage or failure of the active VSS switch will be performed by means of the dynamic routing protocol. At the same time, since we will have several similar routes (along the route for each L3 channel), the total bandwidth will be aggregated due to Equal Cost Multipath (ECMP). Actually, ECMP will be responsible for traffic distribution on VSS switches. In the second case, the channel breakage or failure of the active VSS switch will be performed hardware-wise due to the Multichassis EtherChannel operation. Thanks to the means of balancing the traffic between the channels (hash functions), the MEC will also be responsible for the traffic distribution among the VSS switches.
The advantages of MEC over ECMP are immediately visible. We have less logical connections with a neighbor (just one connection), less route table (we accept only one copy of routes from one neighbor) and less load in case of failure of one of the channels (in fact, it is not present, because the logical channel will continue to work even if one physical channel is lost). Plus, this configuration is simpler to understand.
What about the switching time? For unicast traffic in both variants this time is the same. But not for multicast. In case of multicast traffic the time of network convergence for ECMP is much longer.
The conclusion from all this is that it is recommended to use a single logical connection (MEC).
I would like to briefly touch upon another solution that uses VSS technology at its core. This solution is Cisco Catalyst Instant Access. The idea is to get one large virtual switch inside the network.
In this case, two 6500E/6800 switches with Sup2T supervisors and specialized line cards are installed in the network core (Instant Access parent), which are combined using VSS technology. Cisco 6800ia or 3560CX switches (up to 42) are used as Instant Access clients. It should be noted that IA clients switches do not have local switching functions and absolutely all packets will be transferred to the kernel switches (IA parent). However, the price of such switches, in my opinion, does not correspond to their functionality. But this is a separate conversation.
- An example of the implementation of VSS technology
- HP Enterprise IRF
The HPE IRF solution is not as detailed as the Cisco VSS solution. This is due to the fact that the information on this technology is not so much and most often it is rather superficial. Although it may be for the best, it is not necessary to "kill" the brain in an attempt to understand the details. On the other hand, there is a feeling that you are working with a black box.
In general, if we're talking about two HPE switches stacked together (the vendor allows this definition), IRF and VSS are very similar. One of the switches is chosen as the main one (Master), the second one becomes a slave (Slave). Both switches handle the traffic (i.e. data plane is active on both devices). Management is performed by the main switch (it will be the active control plane), and its state is synchronized with the slave.
Regular Ethernet ports are used as a "stack bus". On some models even 1 Gbit/s ports can be used for this purpose, but in most cases at least 10 Gbit/s ports are required. An IRF channel (analogous to the VSL channel) is created between the switches. An additional header (IRF tag) is added to all packets.
Since the current state of the control plane is synchronized between the switches inside the stack, the failure of the main switch does not cause the traffic to stop. This behavior is similar to Cisco SSO. Unlike Cisco VSS, synchronization includes routing protocol states as well. And since switching takes a fairly short time (the vendor declared 50 ms), neighboring devices do not have time to detect the failure of one of the switches and break the L3-connection. Therefore, an analogue of Cisco NSF technology is not required.
Just like in VSS technology, the IRF stack supports aggregation of channels connected to different stack switches. The LACP protocol is used to ensure that the logical channel parameters are consistent.
As for the timing, IRF technology has a very good look and feel. For example, those above 50 msec are not average, but maximum. A number of documents indicate that switching will be faster in fact. The same applies to the time of switching traffic flows in case of adding/removing physical channels within the framework of aggregation into one logical one. The value is 2 msec. For Cisco, this value is 200 ms. With such time parameters, no adaptive hash functions are required.