Wired Intelligent Edge

Hi there,

I would like to have three switches configured as VSF, for easy of management, but make the data-plane work like they are standalone. So, VSF link would never be used for data, just management.

I would have the 3 switches cabled in a VSF loop, but then each of them would have a connection to my distribution switch. I do not want to use MCLAG, as that can create traffic on the VSF link (ex: switch 1 receiving traffic for a client on switch 3).

Is it possible to do it? Or will the VSF link create a loop?

(Aruba CX)

Regards.

Hi! Quite strange request...it seems you want VSF (which is a virtualization technology with shared data plane) but you don't really want it...so it seems you would require something like VSX (no way to have three members) but you aren't planning to use VSX LAGs (you're scared about possible traffic crossing VSX ISL)...so the only reasonable request looks like having a sort of cluster for just management purposes...so why not implement just that forgetting VSF?

The point is that having three switches to which your distribution layer switches connect is the ideal starting point to exactly implement/deploy a VSF virtualization technology (on ArubaOS-Switch or on ArubaOS-CX based switch series).

Say I have three switches connected to core with a 3-interface port-channel (one per switch). Switch 3 want to communicate with some device connected to the core, and LACP makes it use the port from switch. The traffic will traverse the VSF link. VSF lacks the optimization VSX has, where the traffic is processed by the same switch that receives it. VSX does not have this problem.

I would like to make sure traffic from each switch travels to the core using the local interfaces, and never traverse the VSF link.

I can do that by dropping VSF altogether. But then, I will lose the single point of management, and will also have to triple the ArubaOS controller licenses (1 per stack vs 1 per switch).

Unfortunately that "some sort of cluster" doesn't seem to exist for CX.

The question is:

- If I cable a link for each switch from the core without doing mclag, will it create a loop with the VSF link? Or is the VSF link independent in a way that it will not close the loop?

---

@ricardoduarte wrote: If I cable a link for each switch from the core without doing mclag, will it create a loop with the VSF link? Or is the VSF link independent in a way that it will not close the loop?

---

Say you have a VSF made of 3 VSF Members (remember this is seen as a single logical entity by peer switches)...you connect the first link (say VSF Member 1 to Core)...all is OK, you then connect the second link from the VSF Member 2 (and it is not part of any LACP or Static LAG) to the Core...you have a loop on the spanning tree...thus STP on the Core should immediately stop this scenario to avoid you a broadcast storm. The third link will end with the same event because will be another attempt to create a loop since there is already the very first link correctly setup to the Core. The loop is not "with the VSF Link(s)" but with the Core.

Note: associating MC-LAG (Multi Chassis - LAG) terminology with VSF (and to some extents to current VSX implementation too) is incorrect...VSF uses normal Ports Trunking logical interfaces (Static or LACP) while VSX uses VSX LAGs logical interfaces (pre-ArubaOS-CX 10.1 MC-LAGs terminology was initially used but since ArubaOS-CX 10.1 the MC-LAGs became de-facto VSX LAGs).

Core ----> Sw01

        \___> Sw02

          \___> Sw03

If no VSF is setup, traffic will stay local to each switch. No loop will be created. No spanning tree involved. This is straight forward.

Now say I want to manage all three switches as one. I create a VSF and add the VSF links (Ring). I connect Sw01 to Sw02 and Sw03; Sw02 to Sw01 and Sw03; Sw03 to Sw01 and Sw02. But I don't LAG the uplinks.

Core ----> Sw01-------+--+

        \___> Sw02 -----+   |

          \___> Sw03 ---+--+

I keep everything the same.  So, if there is a loop, it is closed by the VSF links.

The traffic will stay local to the switch if I don't LAG all the three links? Or what will happen?

The loop doesn't close on the VSF Link(s)...it closes between the entire Core and the entire VSF Stack...that's because multiple links between the Core and the VSF Stack are not aggregated in a Non Protocol (Static) or LACP (Dynamic) ports trunking indeed each link is connected as single link (as per you first example scenario).

I can see now what happens, thanks. If I set the VSF, the stack will work like a single switch (duh) and effectively will create the loop. (In reality it will be physically closed by the VSF link).

I was not thinking clearly about this.

---

@ricardoduarte wrote: I can see now what happens, thanks. If I set the VSF, the stack will work like a single switch (duh) and effectively will create the loop. (In reality it will be physically closed by the VSF link).

---

But the real point is that once you plan to migrate three standalone switches into a VSF Stack...you're going to enter in a new scenario and necessarily it requires you to re-think existing standalone links eventually connecting your involved (future) VSF Members to any other peer of your network...not the contrary...in other terms is the newly created VSF that is urging you to re-think the connections which are in place...thinking to adapt the VSF keeping things around it totally unchanged is - IMHO - a wrong approach.

---

@ricardoduarte wrote: Say I have three switches connected to core with a 3-interface port-channel (one per switch). Switch 3 want to communicate with some device connected to the core, and LACP makes it use the port from switch. The traffic will traverse the VSF link. VSF lacks the optimization VSX has, where the traffic is processed by the same switch that receives it. VSX does not have this problem.

When you write "Switch 3 want to communicate with some device connected to the core"...I stop and reply: Switch 3 wants nothing.

LACP, by applying its balancing algorithm using L4, L3 or L2 information about Source/Destination, will select the egress port to be used...so the Core can only receive messages transferred by the originating distribution on the port where that particular link terminates (a message can be outputted using say port 1/1 or 2/1 or 3/1...so that message will be received on the corresponding interfaces on the Core). Vice-versa the reply back would happen again used the algorithm used by the LACP LAG on the Core...so it would be quite difficult to force a message to exit on a particular port (and, at the same time, to desire a message doesn't cross the VSF Link to egress on a port of another VSF Member...)...it's quite "out of user control" IMHO.

The VSX Link Local mechanism is related to the traffic it replies back...not about the traffic a connected peer switch generates against the VSX (indeed this type of traffic will be governed by the LAG algorithm of the peer switch)...so the VSF can be compared to VSX but the issue you're presenting has its root origin on the source device not on the destination device. Is it right?