Discovery not completing

Sorry to hear you're having problems. This could be due to a couple of things. It looks like the device is connecting fine initially, but then gets hung up during the iControl calls.

 

 

First thing you can check is your firewall. It sounds like you might have the port blocked. iControl typically uses port 443, so a quick check would be to try and log into the web-interface for the BigIP you are trying to discover from the Ops Manager box.

 

If you are able to pull up the web interface, you may check our httpd.conf file and see if you have iControl listening on a port other than 443. If so, check this port against your firewall as well.

 

 

Hopefully this resolves the issue, but if it continues, please let us know and also attach a copy of the "trace.log" file that is in your C:\Program Files\F5 Networks\Management Pack\Logs directory, that would be even more helpful. That will provide us with the most information to help troubleshoot your situation.

 

 

Thanks!

 

Dave

I am able to connect to the web gui from the Ops Manager RMS, but I'm still having the same problem. I most recently tried a discovery on our lab LTM at about 06:15am.

 

I've never used any iControl stuff, so I'm not sure where I would have changed it. Here's what I'm seeing in the /config/httpd/conf/httpd.conf file. I'll attach it as well.

 

Allowing http connections from the localhost only. This was opened

 

specifically for iControl SOAP messages from clients on the same

 

system.

 

Listen localhost:80

 

 

iControl may be accessed from the 127 network without authentication.

 

This allows clients on the same system to call iControl without authentication.

 

 

 

Satisfy any means that a connection may satisfy either the address access

 

restriction or the authentication restriction in order to be authorized to

 

access this directory.

 

Satisfy any

 

Access is restricted to traffic from 127.*.*.*

 

Order Deny,Allow

 

Deny from all

 

Allow from 127

 

This is an exact copy of the authentication settings of the document root.

 

If a connection is attempted from anywhere but 127.*.*.*, then it will have

 

to be authenticated.

 

AuthType Basic

 

AuthName "BIG-IP"

 

AuthPAM_Enabled on

 

AuthPAM_CacheTimeout 86400

 

require valid-user

 

It looks like the OpsMgr Health Service is not started, or the F5 Monitoring Service can't connect to it.

 

 

Are you sure that an administrative user is running the F5 Monitoring Service?

 

 

Can you double-check that the OpsMgr Health Service is started properly?

 

From the trace log, it looks like our custom data source is not getting loaded by the Operations Manager Health Service. The first thing to try would be to restart the Health Service on the RMS, and also make sure the SDK and Config services are running. Then restart the "F5 Monitoring Service" and try discovery again.

 

 

If it still hangs during discovery, can you please post your Operations Manager event log?

 

 

Thanks and good luck,

 

-Dave

So it looks like iControl is having a communication problem. I've attached a built application that will just grab your device information. This will be a good test to see if the SOAP calls are getting through. You can also download the iControl SDK and build any of the samples and try those.

 

The SDK is located here: Click here

 

 

To use the application you should type something similar to this in a cmd window:

 

iControlSystemInfo.exe 148.126.88.9 443 admin password

 

 

If the program stalls or comes back with an error, my guess is there's a problem with the device itself or there is a network failure somewhere (port blocked, wrong subnet, etc).

I'm editing this post because I found the problem. It was a Proxy authentication error.

 

Your icontrol sysinfo tester worked when I used the DNS name of the device, but not the raw IP address. My 'Internet Options' were set to skip the proxy server for local addresses, but it didn't recognize the raw IP adderss as local. I saw in the trace.log file that the discovery process was using the IP address so I tried that in the iControl sysinfo program and saw the error.

 

I stopped the server from sending traffic to the proxy and it completed discovery fine.

 

 

also, (this is especially for those using Active Directory user account mapping to log onto your Big-IP's) make sure you first log onto the F5 devices (either through the GUI or SSH) with the credential you'll be using for discovery. The discovery process uses the cached credential on the device so you need to make sure the password is up to date.

 

 

thanks for the help!

Wow, that's great news! And good catch on the proxy issue. I'll have to add that to the documentation. We're also doing a bug fix against this to make the issue more visible. Thank you for your help and patience with solving this problem.

 

 

As for the certificate issue, did you happen to change the password in an attempt to fix the iControl communication issue? This could explain why you had to reconnect to the box before discovery.

We have two HA pairs and I hadn't had a need to connect to the stand-by members since I had changed my password in AD. So the cached credentials on the Big-IP had an out of date password. Logging in to the GUI updated it.