Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..
887 views

SNMP discovery issues

Hi

I have switches which I am discovering through host connections by snmp. The two probes are in a cluster and the IP's are getting connected via wrong probe and hence throwing the error . I have tested the connection and all the switches are accesible via 1st probe where the discoveries should also run. Anyone facing the same issue /

</CONNECT>
 <log start="14:03:31" severity="debug">Running test connection queries</log>
 <EXEC start="14:03:32" duration="906" CMD="1.3.6.1.2.1.1.1,1.3.6.1.2.1.1.2,string" RESULT="ROWS_0_COLS_0" />
 <EXEC start="14:03:32" duration="0" CMD="next" RESULT="false" />
 <DISCONNECT start="14:03:32" duration="0" CMD="client_disconnect" RESULT="" IS_NULL="Y" type="snmp" credentialsId="1835_1_CMS" />
 <log start="14:03:32" severity="debug">Unexpected SNMP_AGENT Exception:
Traceback (most recent call last):
  File "SNMP_Connection_Utils", line 1043, in mainFunction
  File "SNMP_Connection_Utils", line 998, in testConnection
Exception: java.lang.Exception: Could not perform snmp connection to *******
</log>
 <log start="14:03:32" severity="debug">try to get snmp agent for: *.*.*.*</log>
 <CONNECT start="14:03:32" duration="0" CMD="client_connect" RESULT="success" type="snmp" credentialsId="1844_1_CMS">
  <ClientProperties>
   <prop name="protocol_index" value="5" />
   <prop name="protocol_timeout" value="300" />
   <prop name="credentialsId" value="1844_1_CMS" />
   <prop name="cm_credential_id" value="1844_1_CMS" />
   <prop name="snmpprotocol_version" value="version 2c" />
   <prop name="protocol_type" value="snmpprotocol" />
   <prop name="snmpprotocol_postfix" value="" />
   <prop name="port" value="161" />
   <prop name="protocol_netaddress" value="DEFAULT" />
   <prop name="ip_address" value="10.86.64.141" />
   <prop name="snmpprotocol_privalg" value="3DES" />
   <prop name="snmpprotocol_authalg" value="MD5" />
   <prop name="protocol_port" value="161" />
   <prop name="snmpprotocol_retry" value="2" />
   <prop name="snmpprotocol_snmpmethod" value="getnext" />
   <prop name="user_label" value="public v2" />
   <prop name="snmpprotocol_authmethod" value="noAuthNoPriv" />
   <prop name="retry" value="2" />
   <prop name="protocol_username" value="" />
   <prop name="protocol_in_use" value="false" />
  </ClientProperties>
 </CONNECT>

0 Likes
13 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

It may sound weird but try to comment temporarly the testConnection call from the Jython script. If the discovery flow continues and retrieves data than we have some options.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: SNMP discovery issues

But why would it connect to the worng probe and not to the one which has the credentials set on it.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

What value has the ProbeName attribute on the IPaddress of the remote node? If it has the wrong probeName than you need to ping it again.
We can have a wrong dispatch also. Can you see the dispatch reaching the probe in WrapperProbeGW logs?

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

I fail to understand how you configured different credentials on the probes, when they are in the same domain. The credentials are configured on domain level, and not on probe one. If you want everything to run on first probe, what ip ranges have you configured on the second probe? Or you use probe clustering, in which case probably you should not, since then the ranges are split automatically across the members of the cluster.

Likes are appreciated!
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

We don't know if the credentials have a custom scope. Maybe they are defined only for certain IPs.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

My 5cents, but if that was the case, the dfp wouldn't have chosen credentials for connecting to 10.86.64.141

<CONNECT start="14:03:32" duration="0" CMD="client_connect" RESULT="success" type="snmp" credentialsId="1844_1_CMS">
....
<prop name="credentialsId" value="1844_1_CMS" /> <prop name="cm_credential_id" value="1844_1_CMS" />

So is this credentials are not setuped correctly, this should be fixed. Or if the DFP02 doesn't have firewall access to SNMP, then the ip ranges setup should be reconsidered. 

Likes are appreciated!
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

Client_connect means that we can reach the IP and the port is open.

Test_connection means that we can retrieve information for OID from globalSettings.xml

 <property name="snmpTestQueries">
        <query>1.3.6.1.2.1.1.1,1.3.6.1.2.1.1.2,string</query>
    </property>

Thatțs why I mentioned to comment the testConnection from the Jython script.

 

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: SNMP discovery issues

Hi

The probes are in cluster, one is a N/w probe and other is unix probe. The IP range is mentioned in Probe 2 and the credentials have a network scope of all. When I test the credentials it shows connection succesful from Probe1.

When I run discovery they go to probe2 and throws an error : SNMP connection failed" I deleted the CI completely from cmdb and ran the ICMP discoveries but it shows the Probe 2 name over there. But this should be correct since the probes are in cluster.

When I run SNMP they fail after going to Probe 2 instaed of Probe1

0 Likes
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: SNMP discovery issues

I trying to connect via Probe 2 and thats why it's getting failed because that does not have the permisssions. How can I have these IP's connect via probe 1  which have the access for the switches .

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

Do I understand correctly that Porbe2 is a Unix machine? If yes, this would explain the behavior why it fails on Probe2. Disocvery isn't possible on Unix probes and it's disabled in the code.

I know, from a Unix machine we could easily do SNMP discovery but RnD blocked discovery on the entire Unix probe.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
Tags (3)
0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: SNMP discovery issues

Just now I saw your second comment.

I think that the design assumes 2 have probes in a cluster  on the same OS platform.

This is an interesting question. I would raise a Support case to get an official point of view from Support or RnD. I never had to work with such a configuration.

Unfortunately the Unix probe has a lot of potential for discovery but since ages it's restricted to integrations only. Actually not even all teh integrations but that's another story.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.