Onboard Administrator (OA) discovery problem

[chuckk281]

Joe was helping a customer:

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

Having a real problem trying to discover the OA’s for a specific enclosure. Note: This is the “first” enclosure on the customers “new” network. We have others (different networks) discovered successfully. The customer has assured us ALL ports are open. The ip address in the screenshot below is the correct one for our primary OA. We have 2 enclosures, both having the same issue.

Successful ping of the OA by ip address

Successful ping of the OA by FQDN

DNS forward lookup successful

No reverse lookup

SNMP walk successful

SNMP get successfully brings in information

Node gets discovered as “unmanaged” device in SIM, so ping works

Deleted and re-added multiple times

Physically reset OA’s

Validated XML reply is checked on the OA

Firmware at 4.01

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

Help from Dave:

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

Joe try unplugging the network cables from OAs and then ping IP to see if it got used elsewhere. ..

Could be a dupe of an IP in the EBIPA, but probably not.

Could be erroneous characters in the OA settings.

                You could backup the OA config, reset to factory and set the OA IP alone to see if you can login/connect then.

I use the attached scripts to reset/clear and configure the OA from a thumbdrive and Insight Display.

The enc1_c7000_config can be modified with site info to configure the OA.

                I add a user ‘hpadmin’ and password ‘password’ in the script for my install login.

I then use the reset OA is run as is to clear out a temporary setup.

Make sure that ‘Disable XML Reply’ is not checked. It is in the ‘Network Access’ under ‘Enclosure Settings’.

I know the IRS disabled this and it messed with SIM discovery.

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

Reply from Joe:

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

Quick update on this. We’re still trying to find the problem but I was able to prove the enclosures are fine. We moved the enclosures from their “new” network to their “internal” network (switched cables) and discoveries work perfectly. They happen to have 2 firewalls inline on their “new” network that 3 of their network experts tell me are not the problem and configured correctly.

Will investigate a bit more today

And finally...

Found the issue. Apparently the customers security group has an appliance on this network, which no one knew about that was squashing any ICMP process/request and of course the first thing the discovery process does is ICMP/ping. The network team was also not aware of this but the issue is now resolved.

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

Questions?