In order to finish with the user traffic, I would like to mention one more thing. The VSL channel will also transmit traffic that is sent to all devices within the VLAN. Such traffic can include broadcast traffic for which there is no data about the recipient's MAC-address (unknown unicast) and multicast traffic.
So, we have found out that both switches process the traffic and the whole management is focused on one of them. The VSL channel is used as a common connecting bus, through which at least the control and synchronizing information is transmitted. Through the same channel the backup switch learns that the main switch is "dead". But what if this channel breaks, and both switches are working? The answer is simple, the main switch will remain active, but the backup switch will consider that its colleague has failed, and, accordingly, will also become active (everywhere we are talking about control plane). And since these switches have the same configuration, we will get two absolutely identical devices with identical addressing in the network. I think, it is not necessary to speak, to what it will lead. In order to avoid such a situation, at least it is not necessary to break the VSL channel. But it doesn't always depend on us, that's why there's a mechanism that allows minimizing the consequences of the VSL channel breaking. This mechanism uses one of the three methods of detecting a failure:
- Enhanced PAgP
- Fast Hello
- IP BFD
Once it is determined that both switches have become active as a result of a VSL link failure, the following steps are performed:
- A switch that was active before the VSL channel was broken disables all interfaces except for the VSL and interfaces that are manually set to not need to be disabled. This behavior allows the network to continue working further, though on one switch, but without collisions.
- Once the VSL channel is restored, the switch that was initially active will reboot. After the reboot, it will become redundant.
Thus, when the situation with two active switches comes up, the switch that was originally backed up will eventually remain active. Let's see how each of these methods works.
In the case of Enhanced PAgP, an external device is used as the "litmus paper". Each VSS switch sends a special PAgP message through the local ports as part of a single MEC logical channel through which the external switch is connected (Figure 9). This message contains the identifier of the active VSS switch. Having received the ePAgP packet, the remote device sends it back. If everything is fine, both switches send the same identifier of the active VSS switch. If both switches become active, each of them will send messages with its own identifier (Figure 10). And since the remote device sends such messages back, both switches will realize that a failure has occurred.
And how quickly will the failure be detected in this case? As soon as a switch that was originally backed up becomes active, it immediately sends an ePAgP message with its own identifier. Thus, the time of detection of a failure situation is a fraction of a second. Of course, the remote device must also support ePAgP. Such support is available on the switches 2960, 3750 (but not in the stack), etc.
The next mechanism is Fast Hello. In this case, an additional direct L2 channel is made between the VSS switches (without intermediate devices). Within this channel, the switches exchange VSLP Fast Hello messages. And if the VSL channel has fallen, but the VSLP Fast Hello packets are still running, we have a failure situation. The failure detection time is a fraction of a second (VSLP Fast Hello messages are transmitted at 200 ms intervals when the VSL channel is down).
The last detection mechanism is IP BFD (Bidirectional Forwarding Detection). This mechanism is very similar to Fast Hello, but slower (the detection time is counted in seconds). It can work through a direct L3 channel. It is not recommended to use this mechanism because it is slow. Moreover, it is absent in the latest IOS releases.
It is recommended to use two fault detection mechanisms simultaneously (VSL channel breakage).
And so, in general, the main aspects of Cisco VSS technology are considered by us. The recommended design of the VSS is still a small touch - the recommended design of the use of VSS. Let's consider two options:
To use several L3 channels for communication with other equipment
Use one L3 channel on top of the aggregated logical MEC for communication with other equipment.