SNMP inventory bug on Cisco devices

[erique-souza]

SNMP inventory bug on Cisco devices

[g-bougard]

Hi @erique-souza

I can see in your agent log glpi-agent is reporting 0.1.134.160 and 172.16.253.246 as ips during the discovery of just the 172.16.253.246 ip. During the netinventory task, the agent receives to run netinventory on the first ip 0.1.134.160 event if it's not the one related to the ip range configured on the task. And this explains why the agent is reporting a communication error to glpi.

Actually I think glpi-inventory plugin when looking for device ips should only use the ip related to the configured task ip range in the XML sent to the agent. @stonebuzz ? Do you remember if we still discussed about this issue ? This sounds familiar to me.

[stonebuzz]

Yes, we had encountered the problem once.
Here the plugin, when generating the targets, does not remember from which IP range the target is found.

So when I send the information back to the agent, I can't determine the IP based on the IP range provided in the job.

(in addition, it is possible to provide several IP ranges in a job .....)

For the moment I have no idea how to fix it (at least the fork code doesn't allow me to find the information) and it remains a very, very "rare" case.

The easiest thing would be to delete (permanently) this network port (which will delete the offending IP)

The next discovery will not add it because discovery (after asset creation) does not add port information.

Thus, during the SNMP inventory, only the "correct" IP will be given to the agent.

[g-bougard]

I can understand you can provide another ip than the one used during discovery if the reported ones are all in the configured ip range. But in his case, he even has reduced the range to one ip ^^
IMHO why not just checking which ips are in the expected ip range and choose the first ?
To me, this should reduce the chance to use the wrong ip.

[erique-souza]

I can try to contribute a suggestion to separate the first IP that the equipment was inventoried into in an independent field within the computer for network devices and printers, from the IP ranges that it was inventoried the first time with the discovery, perhaps this will help with the task of snmp to avoid bugs of losing which IP the equipment was on instead of trying to use the information in Network Ports

[francisco-vilaca]

hello, It work for me by removing the ip 0.1.134.160. But that ip does not exist in my network not even on my switch config, and i notice that glpi puts that same address to most of the cisco switchs, i don't know why.

Now that I'm able to inventory my switches, the ones that are configured in stack mode, glpi is doubling the number of ports

[trasher]

@francisco-vilaca please open new ticket(s) for issue(s) not directly related to the initial one described here.

[francisco-vilaca]

ok

[trasher]

The easiest thing would be to delete (permanently) this network port (which will delete the offending IP)

The next discovery will not add it because discovery (after asset creation) does not add port information.

Thus, during the SNMP inventory, only the "correct" IP will be given to the agent.

Does this fix the initial issue?

[erique-souza]

The easiest thing would be to delete (permanently) this network port (which will delete the offending IP)
The next discovery will not add it because discovery (after asset creation) does not add port information.
Thus, during the SNMP inventory, only the "correct" IP will be given to the agent.

Does this fix the initial issue?

Yes, removing the extra IP worked as expected with the SNMP task for the device in question.

[trasher]

Great, thank you for the feedback.

I'll close that issue for now since it's resolved, I guess it should be OK now that your data has been redressed.