Onboard Administrator subnet question

[chuckk281]

Mark had an Onboard Administrator question:

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

Trying to get my head around this situation:

First, I've enabled EBIPA, enclosure-wide.

Now, I've configured my Active OA to be on the HP 16.x.x.x network.

And, I've configure my Standby OA to be on a private 192.168.200.x network, hosted by a local server.

Why is it that following this, I am now able to `CONNECT` via serial in OA CLI to some resources, but not all?

I can successfully connect to the following:

- bl465c

- bl870c i2 (both blades)

- Brocade interconnect

But, I am now unable to connect to the following:

- bl860c

- GbE2c interconnect

- Cisco interconnect

Could it be a fault in the firmware, or is there a design limitation with having two OAs on different networks?

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

Monty replied:

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

You didn't indicate what EBIPA IP address assignments you made to the servers nor interconnects.

When you place the OA and blades or interconnects in different IP subnets - I imagine your intent is isolating different admins from other servers or other interconnects?

If so - it sounds like you succeeded J!

We added OA management VLAN feature to allow customers to provide 802.1Q tagged VLANs to provide isolation between connections to various components in the enclosure and admins outside the enclosure.  This is the reason we extended EBIPA to allow different IP subnets / gateway / DNS on each device bay or interconnect bay in OA v3.00.

However, you must be mindful of dependencies within each product when you enable the OA VLAN feature – or configure device bays or interconnects in different subnets.

For instance – Virtual Connect requires that all VC Ethernet and VC FC modules plus all OA modules (active and standby) be configured in the same IP subnet – or VC Manager will be unable to control those modules and unable to contact the OA.

The OA CLI connect interconnect command works differently than the connect server command.

The OA CLI connect interconnect command requires that the interconnect module supports a serial link between the module and the OA (as shown on interconnect info).   When the admin logs into the OA CLI with interconnect bay permission and administrator or operator privilege level – they can use the connect interconnect command to communicate with that module, typically after logging in with the proper credentials for that module.  This feature requires:

• That the client has network access to the active OA including access to the OA VLAN if the VLAN feature is enabled
  • Alternatively the user is using the OA serial port to access the OA CLI
• OA SSH or telnet is enabled
• User logs into the OA CLI with proper credentials to access the desired interconnect bay
• Interconnect module supports serial connection to the OA
• User provides proper credentials to log into the interconnect module

The OA CLI connect server command actually involves the OA connecting to the iLO Virtual Serial Port over the internal management network.  This feature works independent of IP subnet differences or VLAN differences (except the original OA VLAN release 3.00 did not support connect server to an iLO in a different VLAN – this feature was restored in OA v3.10 and later).  Requirements:

• That the client has network access to the active OA including access to the OA VLAN if the VLAN feature is enabled
  • Alternatively the user is using the OA serial port to access the OA CLI
• OA SSH or telnet is enabled
• User logs into the OA CLI with proper credentials to access the desired server (device) bay
• Server iLO supports Virtual Serial Port – limited to all ProLiant server blades and Integrity i2 server blades
• SSO is provided based on the user permissions in the OA login

Hope that helps,

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

Comments?