Highlighted
Honored Contributor.
Honored Contributor.
640 views

SNMP request-id impacting config polls ?

Running NNMi 10.50 linux

I have a scenario where periodically devices will stop being able to config poll while still being able to snmpwalk from the command line.

What I know:
1. The same device can be config polled successfully from a different NNMi server.
2. I beleive it is not High Random Port(HRP) related based on the fact that if you unmanage the device for several minutes, it works with the same HRP source port.
3. the packet capture shows that when it fails, the SNMP request-id is "48578543",  and then after being
unmanaged for several minutes and remanaged, the request-id is "1" and the config poll succeeds.

I don't know if the request-Id is actually the issue, but its all I have to go on at the moment.

Barring any better information (which, as always, will be greatly appreciated!!!)
When/How does the SNMP request-id get incremented by NNMi and is there a way to reset it
and or avoid it getting to big?

0 Likes
5 Replies
Highlighted
Honored Contributor.
Honored Contributor.

Re: SNMP request-id impacting config polls ?

Apparently I failed to fully vet this line of thinking.

additional packet captures showed even larger request-id's working just fine.

I did notice that the multiple failed requests used the same request-ID.   Don't know if it could be that the device

decides it may be a duplicate and discards it.

I'll still take any thoughts on what may be the issue....

Thanks!!!

 

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: SNMP request-id impacting config polls ?

Hi,

does it happen for SNMP1/2 or SNMPv3  devices or both?

Do you looked into nnm-trace.log ?  You may want to enable higher level of discovery tracing and then chack what's will occur in the log. Run nnmsetlogginglevel.ovpl  com.hp.ov.nms.disco FINEST
As an alternative you can try   /opt/OV/support/nnmtracenode.ovpl for some particular node tracing.

my 2 cents,
Gedas

 

Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: SNMP request-id impacting config polls ?

Hello,

 

as you might know NNMi uses the same source port for all SNMP requests. Some devices in the network (I think we have seen HP switches) decide to block such packets after some time. If it is SNMPv1/SNMPv2 you can check the SNMP communication independant from NNMi but from the NNMi server with the command nnmsnmpwalk in the NnmInstall/support directory (not the nnmsnmpwalk.ovpl script in bin directory). When it works and the requests from NNMi (e.g. config poll) don't you might have this problem. I think that there is a KB article about this.

 

HTH and kind regards

 

Allessandro

Highlighted
Honored Contributor.
Honored Contributor.

Re: SNMP request-id impacting config polls ?

The only ones I have found so far have been snmp v3.  since I haven't found a way to duplicate the issue, I will have to wait for the next one and set the logging level to FINEST and try /nnmtracenode.ovp as well.  I am beginning to wonder if there is a heuristic security device somewhere in the path that is flagging the snmp request but as soon as it is unmanaged in NNMi and then re-managed (within 15 minutes), the issue goes away for that devices.

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: SNMP request-id impacting config polls ?

Hi, again

well, snmpv3 could add  a new twist to the (detective) story and also narrow down your search area.. I'd  suggest you to work closer  with devices administrators. There are a few v3 security enforcement  features like multiple  reboot of the node's SNMP agent,  time sychronisation i.e. max.  90 seconds difference between SNMP requestor (NNMI) and receiver (node) etc.  what could stop v3 communication.. Devices adminstrators' could look to their devices logs and tell you what is wrong.

regards,
Gedas

 

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.