cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1419
Views
0
Helpful
26
Replies

LMS 3.1 CS Discovery Unreachable Devices Not Sending Packets

bruceboardman
Level 1
Level 1

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

26 Replies 26

Joe Clarke
Cisco Employee
Cisco Employee

Please post your NMSROOT/conf/csdiscovery/CSDiscovery-config.xml. As for being able to direct Discovery on which management address to pick, this is decided based on the Preferred DCR Display Name option. For example, you can choose to use the highest loopback IP address as the management address.

I've tried the various global options with seemingly the same results. I just don't get why in this one device I'm focusing on I don't get any packets sent to the IP that's the DNS resolveable IP, and instead the device is discovered on another IP. See attached discover config.

This is how Discovery is configured. You've setup an exclude filter such that everything will be discovered EXCEPT devices which are found to have an interface in 172.*.*.*. You do NOT want to cross any router boundaries. You have a few seed devices, but nothing connected to these devices will be discovered that is more than 2 CDP hops away.

That said, what is the device on which you are focusing? What IP addresses does it have? How is it connected to your seed devices?

It is one of the seed devices 128.230.61.114. In previous attemps to discover it I used it's DNS resolvable address 128.230.61.2. It also has addresses of 128.230.61.210, 128.230.61.18 and 64.132.176.170. - I get the same behavior if I use the DNS IP 61.2 for the seed device, that is unreachable device with no packets sent, and then the device found on 61.114.

Go to Common Services > Device and Credentials > Device Discovery > Discovery Logging Configuration, and enable debugging for the System Module, Neighbor Module, Discovery Framework, and Discovery Deviceinfo, then run a new discovery, and post the ngdiscovery.log.

Here it is and thanks

This is what I see:

c6509r-srv.syr.edu/128.230.61.58 is filtered since it has the IP address 172.30.4.1 configured.

backbone.syr.edu/128.230.93.2 is properly discovered.

128.23.61.2 cannot be discovered due to SNMP timeout on system.

128.23.61.57 cannot be discovered due to SNMP timeout on system.

128.230.61.19 is filtered because it has the IP address 172.20.38.3.

128.230.17.1 is filtered because it has the IP address 172.18.17.1.

128.230.21.1 is filtered because it has the IP address 172.16.19.1.

128.230.61.106 cannot be discovered due to SNMP timeout on system.

128.230.61.122 cannot be discovered due to SNMP timeout on system.

128.230.61.34 cannot be discovered due to SNMP timeout on system.

128.230.93.1 is filtered since it has the IP address 172.20.2.1.

backboneb.syr.edu/128.230.61.2 is properly discovered.

128.230.61.217 is filtered since it contains the IP address 172.20.38.3.

CMbone.syr.edu/128.230.61.146 is properly discovered.

128.230.61.146 is filtered since it has the IP address 172.16.19.1.

128.230.72.7 is properly discovered.

198.36.18.147 cannot be discovered due to SNMP timeout on system.

humerus2.syr.edu/128.230.61.98 is properly discovered.

128.230.72.8 cannot be discovered due to SNMP timeout on system.

128.230.72.9 cannot be discovered due to SNMP timeout on system.

128.230.72.11 cannot be discovered due to SNMP timeout on system.

128.230.72.6 cannot be discovered due to SNMP timeout on system.

128.230.72.4 cannot be discovered due to SNMP timeout on system.

128.230.72.162 cannot be discovered due to SNMP timeout on system.

128.230.72.10 cannot be discovered due to SNMP timeout on system.

10.21.0.137 cannot be discovered due to SNMP timeout on system.

10.21.1.107 cannot be discovered due to SNMP timeout on system.

10.21.8.37 cannot be discovered due to SNMP timeout on system.

10.21.1.169 cannot be discovered due to SNMP timeout on system.

10.21.1.170 cannot be discovered due to SNMP timeout on system.

Your test device, backboneb/128.230.61.114 is properly discovered, and 128.230.61.114 is used as the management IP. This device should now be in DCR.

Yes it is discovered, but it is initially reported as being unreachable without having sent a packet out. It appears to be timing out within the system. This isn't a problem for devices that have multiple interfaces and for whatever reason are eventually discovered. However the concern is what will happen when discovering other single IP addressed devices? It's a reliability concern ya know what I mean?

I don't see any indication of that in the logs. This device is properly discovered with no hint of unreachability. If you can reproduce this, capture a screenshot illustrating what you are seeing with a new ngdiscovery.log.

I should also add that this backbone device is added as backboneb.syr.edu/128.230.61.2 based on the preferred management address scheme. Future management operations will use that IP address.

I run a Wireshark capture on all the addresses on this switch, and get no packets. I see the Rimoute when quering system talbe from deivce, msg in the log, so does that usually mean a packet has been sent? FWIW I ran the discover with only the 61.2 device as a seed and the discovery failed. log attached

I see an SNMP timeout on 61.2. This would indicate that Discovery sent an SNMP request for the system branch. If you're not seeing any packets in wireshark, my guess would be you're looking at the wrong interface, or the filter is too strict. Exactly what filter did you use?

I suppose another explanation would be that this server doesn't have a route to 61.2, and thus the server cannot even encapsulate a packet to that address.

My concerns exactly so I ran a mib browse to each interface from the server and captured all the packets to and from. Now there are two interfaces on the server, but only one is linked. Since the mib browser traffic is captured the assumption is discovery would use the same one and in the earlier attempts with multiple seeds it did find the device. Something is flakey.

Disabled the second interface and reran discovery with the same results.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: