Onboard Administrator Communication Failed on Virtual Connect

[chuckk281]

Gary was working with a customer:

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

                Team,

                I have a customer that is having this issue and wants to know what are his options for resetting the VC from DHCP to Static, he was told that it will automatically switch when the lease expires, but couldn’t wait and so they tried doing OA reset from the OA and this caused multiple packet losses which caused a lot of VM Ware Hosts to disconnect. Is there a way to make the switch without the packet losses?

Thanks,

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

Mark had some great info:

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

VC Interconnect modules do not have a Static option. Are you referring to setting EBIPA for the Interconnect Bays / VC Modules? If so, that is still DHCP, the difference is the OA (DHCP Server) will process the DHCP Request from the VC Module and respond with the IP Address / Settings that was configured in EBIPA.

With that, if the VC modules have a lease from a external DHCP Server, those leases will have to expire before they will attempt a "DHCPRequest" and receive the EBIPA configured address. Rebooting the OA has no effect here.

Rebooting or resetting the VC Module is the only thing you can do to flush/clear the IP address from the module immediately and allow it to request a new address and receive the EBIPA configured address.

Rebooting the VC Modules interrupt data traffic.

Here is a quick scenario to help understand it.

Lets say you have EBIPA Disabled for the Interconnect Bays and are using an External DHCP Server to provide IP address to those modules.

VC Ethernet Bay 1 - recevied a lease for 15.1.1.1 at 10:00am - The lease is for 4 hours.

VC Ethernet Bay 2 - received a lease for 15.1.1.2 at 11:00am - The lease is for 4 hours.

At 11:30 you login to OA and change IC Bays's to receive an IP Address from the EBIPA and Apply

You configured in EBIPA:

VC Ethernet Bay 1 - 15.100.100.1

VC Ethernet Bay 2 - 15.100.100.2

At 2:00pm, VC Ethernet Bay 1 will expire (because it was unable to renew at 50% lease) and will send out a DHCP Request which OA/EBIPA will process and provide the module with 15.100.100.1

At 3:00pm, VC Ethernet Bay 2 will expire (because it was unable to renew at 50% lease) and will send out a DHCP Request which OA/EBIPA will process and provide the module with 15.100.100.2

The only way VC Ethernet Bay 1 and Bay 2 would have been able to receive the new IP Address instead of waiting would have been to Reboot the VC module. That interrupts traffic for that module.

Rebooting the OA will do nothing to cause the new IP lease to take effect on the VC modules.

Did I misunderstand what you were asking?

Make sense?

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

Any other input for Gary?

[chuckk281]

There was additional discussion regarding this point.

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

Steve added in to the conversation:

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

But, I would expect that the DCHP address received from the infrastructure DHCP servers (and not EBIPA) would not correct this issue, as those server would most likely have DNS configuration info.

Mark could you confirm the above assumption?

I think at this point the best solution appears to continue with EBIPA, but simply remove the DNS info for the VC modules.

The reason they saw an outage when they made changes, may have been the result of pending VC config changes that could not be applied while the enclosure was in a NO-COMM state.

Here is something I put together for one of my customers to describe the possible outcome of removing the DNS config info from OA/EBIPA, he made this change this morning and was successful, as in his case no changes were pending.  It appears there is no way to confirm whether changes are pending, as modules are no-comm.

If the enclosure is in a NO-COMM state and then remove the DNS config info from EBIPA, one of two this will happen, depending on whether a change in VC is pending.  A change could be something as simple as a server being inserted/removed, powered off etc…

1 – when the EBIPA DNS change is applied, assuming no changes are pending, the no-comm error will go away and all will be back to normal.

2 – when the EBIPA DNS change is applies, assuming changes are pending, the config may be reloaded causing a restart of the VC modules, which may result in a network outage as the module restarts. 

Important to note, the VC-FC modules will simply accept the change as applied, and will NOT restart.

Hope this helps.

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

Mark joined back in:

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

The DHCP Addresses received from DHCP Servers would not correct the issue if they had the DNS configuration.

I took Gary's question to mean they are currently using an external DHCP server and wanted to switch to EBIPA without DNS entries.

In that case changing to EBIPA without DNS entries, you will have to wait for the IP Address that was assigned to VC Interconnects to expire or reset the module for it to receive the EBIPA entries.

Does that make sense?

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

There may be more, so stay tuned, or join in with your comments and suggestions!