No fix is required; the system is functioning as designed.
A Virtual Switch (VSW) can be used to connect multiple Virtual Systems (VS) to a single external/DMZ interface. It can also be used to provide connectivity between several Virtual Systems.
As mentioned in the VSX Release Notes (VSX NGX R67, VSX NGX R68) and in Known Limitations (for example, R77.20, R77.30, R80.10 - Limitation 00186960), when using a Virtual Switch only to provide connectivity between Virtual Systems, and using Per Virtual System High Availability, or Virtual System Load Sharing (VSLS) mode, it is mandatory to connect an interface (either physical or VLAN) to the Virtual Switch in VSX R65 / VSX R67 / VSX R68 / R75.40VS / R76 / R77 / R77.10 / R77.20 / R77.30 / R80.10 / R80.20 / R80.30 / R80.40 / R81 / R81.10.
This article comes to explain the rationale in this requirement and considerations about choosing the interface to use.
In a VSX cluster High Availability configuration, all Virtual Systems are "Active" together on a certain cluster member, as shown in the diagram below:
A client sends a packet to Virtual System "A". When the packet is processed by Virtual System "A", it decides to send it to Virtual System "B" via a VSW, to which they are both connected. If so, Virtual System "A" sends the packet on the Warp interface connecting it to the VSW. The VSW looks in its forwarding table, and knows the packet should be sent to Virtual System "B", and so sends the packet on the Warp interface connected to Virtual System "B".
In VSX cluster VSLS configuration, Virtual System "A" may be "Active" on Member #1, and Virtual System "B" may be "Active" on Member #2, as shown in the diagram below:
If that is the case, then when Virtual System "A" needs to send a packet to Virtual System "B", it still sends it on the Warp interface connecting it to the VSW (on Member #1). The VSW needs to pass the packet to Virtual System "B", but it can not send it via the Warp interface connecting it to Virtual System "B" on Member #1, as Virtual System "B" on Member #1 is in "Standby"/"Backup" state, and should not process packets. The VSW on Member #1 needs to pass the packet to the VSW on Member #2, there the packet can be forwarded to Virtual System "B".
For this reason, when using VSLS, an interface needs to connect the Virtual Switches on the different cluster members. In case of several Virtual Switches defined on a single cluster member, each Virtual Switch needs to have a separate interface connecting it to its peers on the other members.
Note that this interface can be either a physical interface, or a VLAN interface. In case of using a VLAN interface, each Virtual Switch needs a unique VLAN tag to pass its traffic. Other VLAN tags on the same physical interfaces can be freely used for other Virtual Devices of all kinds.
The amount of traffic on the interface connected to the Virtual Switch depends on the traffic patterns of the Virtual Systems connected to it, and in the VSLS configuration.
Consider an example where most traffic passing via Virtual System "A" is between the internal and external interfaces belonging to Virtual System "A", and only a small part of the traffic is sent to Virtual System "B".
In such a case, only the small amount of traffic going between Virtual System "A" and Virtual System "B" will pass on the interface connected to the Virtual Switch.
If Virtual System "A" and Virtual System "B" are "Active" on the same cluster member, then virtually no traffic will pass on the interface connected to the Virtual Switch.
If there are groups of Virtual Systems, which are known to pass a large amount of traffic between them, the amount of traffic between the Virtual Switches can be reduced by using the "
vsx_util redistribute_vsls" command on Security Management Server / Domain Management Server to keep these Virtual Systems "Active" on the same cluster member.
However, even in such a configuration, it is still needed to keep the interface of the Virtual Switch. This is important in order to handle traffic in case of a fail-over of one of the Virtual Systems, so that the Virtual Systems will no longer be "Active" on the same cluster member.