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 - General
cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual Connect module failover

 
jearnshawplainfield.k12
Occasional Advisor

Virtual Connect module failover

I have two Ethernet Virtual Connect modules in the chasis and I'm trying to fail from one to the other. (my test is yanking the first module) All port failing works as well as switch failing..just not the entire module fail. I have ports 7,8 in mod 1 plugged into seperate switches and ports 7,8 in mod 2 with the same physical switch connections as mod 1. I can yank port 7 in mod 1 all is good, same with port 8 in mod 1. However pulling the mod out doesn't make 7,8 in mod 2 kick in. Documentation seems to read that the 2nd mod just "fails over" when the first is gone. I'm not sure how to setup the ports via the OA as when I setup all 4 port on the same LAN on "auto" it doesn't work, and when I set them up as 7,8 mod 1 as primary and mod 2 7,8 as failover still nothing. I'm sure I'm just missing something simple, but I can't seem to find basic documentation about how the 2nd mod fails over.
6 REPLIES
David Claypool
Honored Contributor

Re: Virtual Connect module failover

Assuming a blade with 2 network interfaces, NIC0 and NIC1, and an enclosure with 2 Virtual Connect modules, VC-A and VC-B, and ports mapped so that NIC0-->VC-A and NIC1-->VC-B, you would use the HP NIC drivers to team NIC0 and NIC1. If traffic is being conducted currently over NIC1 and VC-B disappears, the team will fail over the traffic to NIC0 and use VC-A. This is a much different scenario than what you have had success with.

There is a cross-link between your VC-A and VC-B. Given an active NIC0 mapped to VC-A and subsequently VC-A's uplinks failed, the traffic can pass between VC-A to VC-B and use its uplinks. This scenario doesn't require teaming, but you can see how it's a different situation when the whole switch disappears.
HEM_2
Honored Contributor

Re: Virtual Connect module failover

Are all the uplink ports in the same network? If so, and you are not forming LACP channels, then only 1 link should be active and the other 3 in standby. If you yank the module where the active link is located, one of the standby links on the other module should go active. From what you're describing it appears this isn't happening.

Make sure you are at VC firmware version 1.15:

http://h18023.www1.hp.com/support/files/server/us/download/26846.html
jearnshawplainfield.k12
Occasional Advisor

Re: Virtual Connect module failover

The attached picture is what I'm trying to do. I'm not really worried about the NIC bonding on the blade (although that would be great.) I want port level failover at VC-A and SAN (which I have) I want switch failover (which I have) However I can't seem to fail the entire VC-A and have VC-B keep connection. (I'm hooked into ports 7,8 on both modules) I have placed them all in the same "iSCSI_LAN" network and tried them all on "auto" and also with VC-B set on "failover" setting. I am probably missing something simple here I'm sure but the vconnect stuff is new to me.

So basically port 7, VC-A dies then 8 kicks in and the other way. However if VC-A dies then VC-B kicks in with the same 7,8 combo which could then port level fail just like VC-A. Thanks again for the suggestions. (I do have the latest software on the vconnect which acutally seemed to help out the iSCSI boot connection / login time too.)
Jan Mietle
Occasional Advisor

Re: Virtual Connect module failover

We've just tested the same thing and we are seing the same problem. Pulling the module out seems to break the stacking link and it is detected that module is missing/broken. However on the server profile, it still shows the network connections that are going through the "broken" module as being up (even though they aren't). As a result the Blade keeps passing traffic to that network and those ports, even though they are down.... (Yes we are running FW 1.15a and the smartlink option is enabled)..

Jan
Jeff Allen_5
Valued Contributor

Re: Virtual Connect module failover

The key to making this work is indeed Teaming. There is a physical mapping of NIC ports to I/O bays that cannot be changed - regardless of I/O module in use. So, in a HH blade, 1 NIC is routed to VC-A and one to VC-B. If you pull VC-A out, and it is currently the module being used to transmit traffic, VC-B is your only option to get traffic out of the enclosure (assuming it has been setup in the same networks). That means that the NIC attached to VC-B has to have the same configuration as the NIC attached to VC-A - the only way to do that is NIC teaming. The teaming sw will detect the ded NIC on VC-A and start uing the NIC attached to VC-B. If VC-A is missing, it's NICs are dead and cannot be routed over to VC-B.

Smartlink only works if you pull the UPLINK cable - not if you remove the whole module.

Hope that helps.
jearnshawplainfield.k12
Occasional Advisor

Re: Virtual Connect module failover

Thanks for the reply. All I have to do now is check into the "teaming" stuff :) It gives me someplace to start anyway. Thanks again.