Unreachable means that Discovery could not contact the device via SNMP. So you will have to double-check your SNMP credentials in Discovery (not in DCR, but under Discovery Settings). I recommend you start a sniffer trace when running discovery, and filter on udp/161 traffic to one affected 1900. Also, make sure you have properly configured the 1900 to allow the LMS server to poll it.
I added the device in manually and put the same SNMP credentials in LMS 3.0 and the 1900 and it still comes back unreachable. I did notice that LMS 3.0 has entries to input SNMPv2/3. LMS 2.6 has entries for SNMPv1/2. I assume the device is coming back as unreachable for the 1900s because LMS3.0 does not seem to use SNMPv1 and the 1900s only use SNMPv1. Is it possible to get LMS 3.0 to use SNMPv1 or the 1900s to use SNMPv2?
LMS 3.0 will use SNMPv1 if that's all the device supports. The version is not your problem. The problem is either the community string, routing, or the access configuration on the switch. Make sure your string does not end in a number, make sure you can actually ping the switch from the LMS server, and check the switch's config to see that the LMS server address can poll it.
We are able to ping the switch from the LMS server. I believe we have correctly configured the switch for the LMS server to be able to poll it. We've also tried different community strings to check if that was the issue. I failed to mention earlier that all of the devices were reachable on our LMS 2.6 server. I am attempting to discover all of our devices on our new 3.0 server and only the 1900s seem to be unreachable. In case I am missing something, what should I be looking for in the switch's config other then the community strings?
I was thinking of set-host when I was thinking of access. Something like:
snmp-server community COMMUNITY ro
Should be sufficient. Something else to check is to make sure there are no firewalls or other access-lists that are blocking SNMP traffic between the LMS server and the 1900s. You can put a sniffer on the 1900 side to make sure the SNMP traffic is getting to the switch.
The above command is what we have listed in the 1900s. I haven't attempted to place the sniffer on but the SNMP traffic is able to get to the devices because our LMS 2.6 server that is being replaced is able to touch the 1900s and both the LMS 2.6 and our new LMS 3.0 are on the same switch and subnet.
The servers may be on the same subnet, but you have have ACLs applied for the 2.6 IP address which don't include the 3.0 IP. The sniffer trace would be very important for figuring out what LMS is seeing when it tries to contact the switches.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...