SNMP inventory bug on Cisco devices

[erique-souza]

Describe the bug

In GLPI, I believe we have found a bug involving Cisco equipment. When executing the SNMP Network Discovery task, the device is found as expected using a registered private SNMP v2 credential, as shown in the print below

However, for some reason, this same device, when we tried to perform the SNMP inventory to get as much information as possible from the device, received the "SNMP Communication error" message, but the equipment is connected, the credentials are correct and the network discovery was made. few seconds, as shown in the print below

This is very strange because when trying to perform a snmpwalk through the GLPI Linux server itself, we were able to connect to the device without any problems and get its information, as shown in the print below

Some evidence of the device in question:

Model: SG300-52 52-Port Gigabit Managed Switch

We put the glpi-agent that did the inventory on the same server as GLPI in debug2 for evidence, we also tested it on version 1.7.1 of glpi-agent and on the latest version 1.8 of the nightly build to validate glpi-agent.log

Is there anything we can test to validate if it really is a bug? It may appear that the way to authenticate to the device is different from the network discovery task for SNMP inventory

This was an example, but we have other devices of the same model, and also others from Cisco that are different models that gave the same results, some others are working as they should.

To reproduce

• Network Discovery on Cisco device
• Network Inventory on Cisco device

Expected behavior

The connection to the Cisco equipment and the additional inventory taking the number of ports, manufacturer, model, description, and other data from the SNMP inventory task

Operating system

Linux

GLPI Agent version

Other (See additional context below)

GLPI version

10.0.11

GLPIInventory plugin

1.3.4

Additional context

No response

[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.