LMS 3.1 CS Discovery Unreachable Devices Not Sending Packets

[bruceboardman]

Device specified as unreachable is not queried by server running CS discovery. A single LMS 3.1 server discoviering via CDP, with seed devies, and two globaly defined community strings. Community strings verified through successful discovery of other devices sharing same community and manual mib browse from server using 3rd parth browser. Mib walk using Trouble Shooting>Device Center>MIB Walk fails. Device is eventual found and named on a different interface. Are there controls for directing discover to particular interfaces, and why would discover declare a device unreachable when no packets are sent to the IP address. Thanks

[Joe Clarke]

I'd like to see your wireshark rules because the log gives every indication that SNMP is timing out (which implies at least one packet is sent to the device).

[bruceboardman]

Wireshard filter:

"ip.addr == 128.230.61.2 || ip.addr == 128.230.61.114 || ip.addr ..." etc.

The rule works for every address specificed when I MIB browse the target device from the CS server. I don't think it's the server, ACL, firewalls, etc. But I will say that in my experience when something gets this arcane the problem is usually something simple. I'm just not seeing it.

[Joe Clarke]

You could connect to the device in question, and enable debug snmp packet. This would indicate whether or not any SNMP is arriving from the server. Also, do you have Cisco Security Agent installed on this server?

[bruceboardman]

no Cisco Security Agent installed

[Joe Clarke]

What about the basics? Can you ping this IP from the server? In your first post, you mentioned SNMP Walk from Device Center is not working. Is this still the case?

[Joe Clarke]

There is some additional debugging you can enable which may also help narrow down the problem. Enable Data Collector debugging, and run a new discovery for this device. Post the new ngdiscovery.log.

[bruceboardman]

Ran it again, for just this one device and after having tried the defined community strings, and failing the log has this line:

"ug 21 12:42:45] INFO [LoggingOutputStream : Thread-2 flush] : Io error while closing SnmpSocket : Cannot assign requested address: Datagram send failed"

Does this square with not seeing any packets leaving the NIC?

[Joe Clarke]

This is a standard error everyone typically sees at the end of Discovery. It doesn't point to any specific problem. However, the whole log may be useful. In particular, a timeout error will be thrown for more problems than just a timeout. The extra debugging should pinpoint exactly why the timeout is seen.

[bruceboardman]

here is another discovery log with all debug on. Only the one device is setup for discovery.

[Joe Clarke]

The error points to a standard SNMP timeout, and not any other exotic communication problem. At least six packets should have been sent (three for each Discovery community string). The only thing that would prevent them from going out is a missing route on the server (and no default route defined) or something like the Windows Firewall Service blocking the packet.

[Joe Clarke]

I figured it out. Turns out, you have a service request opened for this issue which I was working on. You mistyped your device address in Discovery. The device you want is 128.230.61.2. The device you added is 128.23.61.2. You're missing a 0. That explains why your sniffer trace shows no packets, and why the device is unreachable.

It wasn't until I actually saw your sniffer trace that I noticed this.

[bruceboardman]

Thats it! Not only had I mis-typed that address, but there were other devices in the seed file simularly mis-typed. When the problem gets arcane, it's usually the simple. Thanks for your help on this