Solved: Devices showing as unconnected since LMS2.6 upgrade

paul_levitt · ‎02-27-2007

After upgrading from LMS 2.51 to 2.6, the majority of our branch network shows as unconnected in Topology Services.

The sites showing as unconnected have been set as seed devices, and can see our service providers on-site routers, via CDP.

The switches used to show as connected to an un-managed device

It was all working prior to the upgrade. Sites that have two switches can still be seen, but the edge device cannot.

Thanks

Martin Ermel · ‎03-21-2007

I just try summarise what Joe and Michel said before and try to bring light to the terms and dependencies:

DISCOVERY:

LMS process that needs a minimum of one start device (seed) and the snmp RO communities;

it tries to access a device via snmp;

it roams around in your networks gathering device information of all devices it can find through CDP

it DOES NOT DRAW your topology!!

DCR - Device Credential Repository

if a device is discovered by campus AND SNMP reachable it will be automatically added to DCR

Data Collection:

LMS process that collects detailed Device Information with SNMP;

ONLY with THIS information ANI server can map your network and you will see devices in your topology (e.g 'Layer 2 view', or 'unconnected devices')

to add interconnection between devices in topology; BOTH sides of a link must be verified by the process ( both devices must be snmp RO accessable for the process )

Both, discovery and data collection are scheduled by default;

Again, please

1) Verify the devices in question are listed in the DISCOVERY report:

Campus > Reports > Discovery Reports

=> Your device must be listed here, with status REACHABLE!

if it is not in this list, Campus cannot detect it with CDP

try to bypass this issue by adding it as a seed device

=> now, at least, it must appear in the 'Discovery Report'

->if it is listed, check reachability;

->if it is not listed, check Discovery filters ( and/or enable debug);

Reachability (if a device is discovered AND reachable it will be automatically added to DCR)

->if it is reachable, goto 2)

->it it is unreachable, check SNMP communication from *LMS SERVER* to device (keep in mind wrong credentials and access-lists; and/or debugging deiscovery)

2) Verify if these devices are listed in the DATA COLLECTION report:

Campus > Reports > Data Collection Metrics

in the report that opens, click on the number listed in the column 'Total Devices' of the latest report

=> your device must be in this list

->if it is in the list, it should be in any view of Topology Services (e.g. layer 2 view; unconnected devices,..)

->if it is not in the list, check 'data collection filters'

if the filters does not drop the device

enable debugging as Joe mentioned

If devices are shown as 'unconnected' in the Topology, it is mostly, that campus is unable to access one side of the link;

what is about name resolution for the devices and the preferred management IP LMS has choosen for the device on both sides of the link ??

=> open the map, right click on the device and check the management IP!

I hope with this guide you can find the point you have to put the focus on...

(and I hope that I didn?t made a mistake...)

regards,

MArtin

View solution in original post

ayganesa · ‎02-27-2007

Pls check if your device discovery is still up showing all devices correctly with its neighbors. And if you are having devices in more than a site, check the discovery setting is enabled with jump router boundaries option.

paul_levitt · ‎02-28-2007

Thanks for you reply. To clarify :-

Example of the problem. Take two sites, we have 1x2950 at one branch, 2x2950 at the second. In both instances we are connected to our 3rd party network providers 2600 router.

Both instances we can see the router in CDP

Both instances before the upgrade, we could see the router connected as an un-managed device.

Both instances since the upgrade, we have lost visibility of our providers router, therefore losing 'connected' status of our single switch branches.

There has been no change to the providers equipment/configuration.

Thanks

edit - Also we cannot see un-managed devices on our LAN, as we could before the upgrade. Example is our network providers main router. We could see it as an un-managed (red) device

Joe Clarke · ‎02-27-2007

Do you have a screenshot showing the way things used to look? I am thinking that at one time the provider router was SNMP accessible, and a link was built. Does the provider router still show up in the Unconnected Devices view?

paul_levitt · ‎02-28-2007

Sorry, dont have a screenshot.

We do have SNMP R/O to the devices, although unused.

There are no un-managed devices in the unconnected devices view, only disconnected.

I will try a manual add of a device into the D&C repository and see if it works that way.

Thanks

paul_levitt · ‎03-05-2007

Any assistance would be greatly appreciated, thanks

Joe Clarke · ‎03-05-2007

I don't understand these stamtements. What do you mean by "SNMP R/O to the devices, although unsed?" What is unused? Which devices (the branch devices or the provider devices)?

Does the provider devices show up anywhere in Campus Manager? If not, and if you cannot get any SNMP management from this device, then you will not see links to this device in Campus Manager, and your branch [edge] devices will appear unconnected.

paul_levitt · ‎03-06-2007

Sorry, I'll try to clarify.

Before the upgrade, on Topology services, we used to see one or two green(managed) Cat2950s and a red(unmanaged) 2620 router, for each branch.

The main service-provider router at our Head Office also showed as unmanaged, but connected.

Since the upgrade, none of the unmanaged devices show at all, and the sites with only one Cat2950 only appear in the un-connected devices view.

I have since received an snmp read-only string from our service-provider, and added a couple of routers into the device repository as a test, but it has made no difference. The devices do not show as managed nor connected.

Thanks

Joe Clarke · ‎03-06-2007

If you have entered the provider's devices into DCR with the correct SNMP credentials, you have a run a new full Campus Data Collection, and you are still not seeing the provider's devices in Topology Services, check your Data Collection filters under Campus Manager > Admin > Campus Data Collection > Data Collection Filters, and make sure those devices are either explicitly included, or not explicitly excluded.

paul_levitt · ‎03-15-2007

Devices are not explicitly excluded.

If I was to explicitly include the devices, what would be the point of having a device discovery feature. I want to discover the attached devices, not input what they all are are.

No devices are seen at all - I have even removed any snmp details to try and see them as un-managed connected devices.

Thanks

Joe Clarke · ‎03-15-2007

Discovery and Data Collection are two different things. In this case, we need to focus on Data Collection (i.e. having Campus Manager manage devices, and add them to the Topology Map). If you do not have any Data Collection filters, then all devices in DCR will be added to the Topology Map in some form.

If you do not have any SNMP credentials in DCR, then these devices will never show as connected. Campus Manager must be able to validate links details at both ends of the link.

Re-add the SNMP credentials to DCR for the unconnected devices, and enable core, corex, and topo debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options. then run another full Data Collection. Trace the IP address of one of the unconnected devices through the ani.log, and look for any errors.

paul_levitt · ‎03-20-2007

It is not data collection that I am trying to achieve, it is the discovery.

For example, we have a switch connected to our core CAT6509. The CAT is set as a seed device, and is directly connected. All the SNMP settings are correct.

The device has not been discovered, therefore not added to RME, not managed and no data has been collected.

The previous version would 'learn' what was connected, associate it with the SNMP settings. The device would be seen on Topology Services and also be managed

miheg · ‎03-20-2007

You got something wrong there.

Any discovered device needs to have it credentials completed before RME can do it's thing.

Anyway from what I read your discovery fails all over the place. Even directly connected devices don't get discovered.

You have establish somehow that SNMP works on these devices so the only remaining thing that could fail is CDP?

Are you sure there haven't been some changes in the config of the devices.

You mention some "unmanaged" devices being connected. This can only happen if they were managed once otherwise the connection would never have been made.

I guess community strings may have changed, or CDP settings.

It doesn't sound like a problem with ciscoworks to me.

Cheers,

Michel

paul_levitt · ‎03-20-2007

As I understood it, to discover your network, you configure your seed devices, the snmp strings and click discover.

What you are saying is I have to manually add all my devices, IP and all, then run discover to tell me what I have just input.

Next, I physically add a device to my network, the SNMP stings are correct, and CDP shows the device to and from its neighbours. All links are working.

You are saying that to get it into the DCR I have to add it manually. If so, what is the use of the discovery? Just to draw the links.

On the previous version, to learn the network and populate RME etc I ran a discovery from the core switches and discovered the whole of my three main sites, and the connectivity.

I must be doing something wrong at such a basic level, if I cant discover a device I have connected to the network that is a copy of an existing device, except the IP address

Joe Clarke · ‎03-20-2007

Discovery does not require all devices to be seeds. Discovery requires, at the very least, one device, and correct SNMP credentials for all the devices you want to be discovered.

Then assuming that CDP (or ILMI) is enabled throughout the network, discovery will find all of the devices. If this device is directly connected to your Cat6509, and "show cdp nei" shows the neighbor device on the Cat6509, then discovery should find the neighbor device provided your SNMP settings are correct.

For debugging discovery problems, enable devdiscovery debugging under Campus Manager > Admin > Device Discovery > Debugging Options, then run a new discovery. Trace the IP address/hostname of a missing device through the resulting discovery.log. Also, trace its neighbor (seed 6509 in this case) device. There should be some indication of why the neighbor device is not being detected.