08-14-2008 10:27 AM
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
08-19-2008 02:07 PM
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).
08-20-2008 03:40 AM
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.
08-20-2008 07:33 AM
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?
08-20-2008 08:38 AM
no Cisco Security Agent installed
08-20-2008 08:42 AM
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?
08-20-2008 08:52 AM
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.
08-22-2008 05:25 AM
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?
08-22-2008 08:13 AM
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.
08-22-2008 08:30 AM
08-22-2008 08:39 AM
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.
08-22-2008 10:47 AM
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.
09-18-2008 10:57 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide