Onboard Administrator (OA) and Virtual Connect (VC ) relationship...

[chuckk281]

Louie needed some information and clarification:

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

I was of the understanding that the VC uplinks (data path) had nothing to do with OA (management path) and that VC only contacts the OA internally to get enclosure/interconnect/server status.

My customer is telling me that he is finding that updates/resets to the primary OA cause temporary network outages – they are running 3.10 of VC firmware and 3.11 of OA – of the 10 or so enclosures they updated, about half lost NIC connectivity (mixed hosts = RHEL, ESX + Windows).

Aside from any “bugs”, does the OA make VC “pause” if VC is not able to contact the OA?

I’ve tested this and I am able to maintain network connectivity, through a ping to the servers in the chassis – however, customer is saying that their NIC team/driver invokes a failover when connectivity is lost for more than 100ms – he believes the OA failover causes the NICs to lose connectivity for more than this and hence their NICs failover even though the VC modules are fine.

If the primary OA fails, the secondary should become active and hence VC should not be alerted to any changes in the environment.

I need to understand what the relationship is between VC and OA to correctly answer these and other questions – can someone point me to some information that would assist?

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

Steve replied:

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

OA is not in the data path for VC.  The OA can be removed and VC should continue to forward frames.  If this is not happening, I would suggest that a case be opened with support and have them work the case.

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

Then Sam provided some info:

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

Louie, I suspect the customer saw this problem when upgrading from a pre-VC 3.10 to VC 3.10?

From a design perspective, OA fw updates should not impact VC LAN/SAN connectivity.  However, there was a bug that was fixed in VC 3.10.  See excerpt from 3.10 release notes below.

 

There was a narrow timing window that would cause VC to read a NULL enclosure serial # from an OA that just restarted from a FW upgrade.  The bug was VC accepting the NULL serial # which obviously is not good, because now the VC module is considered ‘rogue’ as it has a different enclosure serial # than VCM thinks it should have.  Thus causing VCM to ‘reject’ the VC module(s) and break any stacking links with the ‘rogue’ VC modules.

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

Thanks Sam! Any other comments or suggestions?