- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- Onboard Administrator (OA) discovery problem
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-02-2014 11:19 AM
05-02-2014 11:19 AM
Onboard Administrator (OA) discovery problem
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?