The status of some devices is unreachable on device discovery and i have set the proper/correct SNMP community strings and therefore they can't be collected on Campus Data Collection and hence can't be managed by the rest of the modules on ciscoworks. What could be the problem. Kindly assist.
Having the correct community string is only half of the battle. The device needs to be IP and UDP reachable as well. That means no access-lists or firewalls that are blocking SNMP communication, and no access-lists or views on the device that could limit which hosts can poll certain objects. The LMS server should have full SNMP access to all devices you wish to manage.
You can use "debug snmp packet" on a device that is showing as unreachable to confirm that the SNMP requests are making it to the device. If not, then work backwards to find out where they are being dropped. If the requests do make it, the debug should give you some indication of why Discovery says the device is unreachable.
Thanks for the advice. I have the exact same issue. I did what you said and SNMP debug shows nothing. What I did was put the unreachable device as the seed device. When I did so it was discovered and entered into the DCR. I pointed CM back to the seed device I prefer. It will still get discovered and show as reachable. Now if I delete it from the DCR, it will no longer get discovered!! This is a problem for me becuase there are several devices on my network that show as unreachable. It would be very painful to have to enter each as a seed device. Then everytime I put a new device on the network, I have to babysit CW. Thanks for any further help!
Adding devices as seeds has no bearing on their reachability. If the device is not configured as a seed nor is it in DCR, and you see no SNMP traffic running a debug when Discovery is running, then the device is not appearing as a CDP neighbor of another discovered device. Verify that one of the device's CDP neighbors is properly discovered (and is reachable), then check that this neighbor device shows the missing device as a CDP neighbor.
If all of that checks out, enable devdiscovery debugging under Campus Manager > Device Discovery > Debugging Options, run a new Discovery, and post the discovery.log.
The map is built based on Campus Manager Data Collection. If devices are not appearing on the map, this could be due to Data Collection filters, or the devices have become unreachable since adding them into DCR. We have also seen some bugs in Campus prior to 5.0.2 and 4.0.10 where new devices may not be put on the map. If you haven't upgraded to one of those versions, you should do so.
Correct. Discovery has nothing to do with what appears on the Topology Map. That is decided by Campus Data Collection. Discovery only sends reachable devices to DCR. From there, Campus pulls devices out of DCR, applies Data Collection filters, then attempts to build the Topology data using CDP and other information. This has not changed since LMS 2.5 was first released.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...