HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
BladeSystem Virtual Connect
cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual Connect failover times

 
chuckk281
Trusted Contributor

Virtual Connect failover times

Steve was looking for some advice on "normal" Virtual Connect failover times:

 

*******************

 

I’m looking for any general guidelines or experience for failover times from one VC to another. I have a customer that has a few servers configured with NIC teaming with connections coming from multiple VC modules –as expected these nodes do not lose IP connectivity during VC failover. However, they have more servers that are not configured with NIC teaming and as expected during VC failover they lose IP connectivity until the standby VC can takeover. In these cases, the failover and loss of IP connectivity is taking anywhere from 45 seconds to 2 minutes.

 

Is there a “normal” time for failover in these cases?

 

********************

 

Lionel gave his opinion:

 

***************

 

Really depends on your configuration and the raison of the failure but in all situations NIC teaming is really recommended. A 45s to 2mn is in my opinion something normal during VC FW upgrade operation but if you get such long delays after an uplink failure in an Active/Standby configuration, something else might be the cause of this long delay.

 

************************

 

Cullen also joined in:

 

*********************

 

As I recall, the major cause of long delays is the updating of tables in the upstream switches.  The switches don’t change their MAC address tables until they either receive packet from the system or the existing entry ages out.

 

***********************

 

Share your experiences and what you have seen in failover times.