2930F VSF and Failure scenario q?

Community Administrator
Community Administrator

OP: @searching1 

Hi,

Just want to ask this, We do have new two 2930F's switch and this will be my first time to configuring VSF. In my case I do have 2930F 24 ports and i will assign 23,24 for VSF.

I would like to ask the ff.

  1. Is this the complete configuration of the switches? and does the link load balance the traffic?

#Switch 1

vsf member 1 priority 200

vsf member 1 link 1 23,24

vsf enable domain 1

#Switch 2

vsf member 2 priority 150

vsf member 2 link 1 23,24

vsf enable domain 1

2. In this configuration I will achieve active/active switch, So apart of that both switch has single management and data plane but different control plane?

3. Regarding failure scenario.

a. If Switch 1 dies, logically Switch 2 will take over as commander. Then once Switch 1 come back, it will automatically elect switch 1 as commander?

b. If one of the links die (ex port23), this will failure will not create any interruption and the problem only the bandwidth bec. its using 1 active link?

c. If both links dies (ex. 23/24), Switch will be come active active?

d. If both links fails and both link went as active/active separately, If bundled link was configured between switches and server... This might cause a loop? since there no more interconnection between two switches STP will not resolve this? What solution do you think?

Thanks

 

Reply OP: @parnassus 

First of all start with WC.16.06.0006 (latest of WC.16.06 software branch).

Then:

  1. Correct. Eventually you can avoid any configuration on VSF Member 2 if you start with a default configuration for that member: just configure VSF on Member 1 as you wrote and then, after it rebooted, connect the defaulted member that will be auto-joined plug-and-play provisioning method by adopting a symmetrical VSF related port configuration from VSF Member 1 (on port 23 and 24 and there you should connect VSF Link from VSF Member 1 the Commander). Yes VSF Link does balance inter VSF Members traffic.
  2. They share both data and control planes (it's a single virtual Fabric made with two or more Switches, not an High Availability Cluster of two separate Switches). Note: the CPU of one VSF Member (Commander) is Active and acts as the management interface for all other VSF Members (Standby and Members) devices, modules and ports including a central Telnet, SSH, FTP client and server and SNMP agent. The other CPUs act as its backup and they will receive control data plane synchronizations from the Commander.
  3. Once ex-Commander is back online again it will merge by re-joining the VSF and a VSF Master re-election is called, since its VSF Member configured priority is higher than one of the Standby it will win the election and become the new Commander.
  4. Yes, since you have two ports as member ports for VSF Link you will notice only a performance degradation (bandwith is going to be halved) on traffic flowing within involved VSF Members. No VSF Split. No VSF Master re-election.
  5. If VSF Link goes down (you lose an entire side, as example, 2/23 and 2/24 or you lose 1/23 and concurrently 2/24, in both cases you will lose the entire VSF Link) your VSF enters in the so-called Split Brain (Active/Active) since you didn't provide a mitigating mechanism such as MAD (MAD = Multi-Active Detection) by means of setting up OoBM-MAD or LLDP-MAD.
  6. Yes, not having a MAD mechanism that help VSF to decide which ports to shutdown (those of the Standby VSF Member) your multi-homed hosts are going to have some issues. STP, VSF side, is not necessary exactly because when a VSF works correctly it acts, from the standpoint of downlink single/doube-homed peers or switches, just as a single switch. Solution: implementing a MAD mechanism supported by your Aruba 2930F and, eventually, use more ports for each VSF Link (say 21, 22, 23 and 24 instead of only 23 and 24) each side.

Reply @searching1 

 

Hi, First of all, Big thank you for your response. 

 

In addition with your reply i would like to verify again this few things.

 

1. "Once ex-Commander is back online again it will merge by re-joining the VSF and a VSF Master re-election is called, since its VSF Member configured priority is higher than one of the Standby it will win the election and become the new Commander."

 

Q: If re-election occur does it have service interuption?


2. How does switch verify if the commander is still active? does it based on interface status or does it sends keepalive to its peer member?

 

3. "If VSF Link goes down (you lose an entire side, as example, 2/23 and 2/24 or you lose 1/23 and concurrently 2/24, in both cases you will lose the entire VSF Link) your VSF enters in the so-called Split Brain (Active/Active) since you didn't provide a mitigating mechanism such as MAD (MAD = Multi-Active Detection) by means of setting up OoBM-MAD or LLDP-MAD."

 

Q: So to resolve this split bran scenario, what we can do is configure MAD. So in configuring this MAD we need to allocate another interface? 

 

For example SW01-Port19 to SW02-Port19, then assigned a vlan

 

# Configure MAD VLAN

vlan 123 name MAD-VLAN

 #Add untag (only untag supported) port

VLAN 123 untag 1/19 - 2/19 (etc for multiple members in one config)

 # Add VLAN to VSF configuration

vsf vlan-mad 123

 

Is this correct?

 

4. I would like to ask if the basic configuration on the photo is correct?

a. configuring truk with lacp

b. How can we enable the assigned mgmt IP for remote access telnet + how to create local accts?

c. SVI + ACL + DHCP Helper address

Basic.PNG

 

Reply @parnassus 

 

  1. Yes, your stack will suffer of a service interruption particularly because the Standby Member (actually it believes to be a Commander) will be rebooted once the VSF Member with higher VSF priority will rejoin the stack (causing the VSF Commander re-election mechanism to be triggered). Read about it here.
  2. You don't resolve the Split Brain scenario...you mitigate it by shutting down a VSF Member that believe to be the VSF Commander (Active node)...so, Yes, adopting any supported MAD mechanism (AFAIK on Aruba 2930F you need a 3rd MAD device both with LLDP-MAD or VLAN-MAD <- so in terms of ports used both modes requires you to use at least - or at most - one port on each involved VSF Member) is strongly adviseable.
  3. Probably you have already entirely read the Chapter 30 about VSF on Aruba 2930F Management and Configuration Guide for ArubaOS-Switch 16.06 (July 2018), if not...is a good read.
Version history
Revision #:
2 of 2
Last update:
a month ago
Updated by:
 
Contributors
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: