LMS 2.5.1 RME Inventory RME Collector Help!

[david.santel]

I am unable to get the collection/inventory to work in RME 4.0.4

It gives me error when i check on validation credentials:

---None of the devices have credential verification data.---

When I check the logs it says:

10.20.1.40 Device type not supported.

Job Type: Inventory Collection

Job Owner: admin

Status: Failed

Start Time: Sat Mar 29 15:36:35 PST 2008

End Time: Sat Mar 29 15:36:37 PST 2008

Schedule Type: Immediate

Device Summary

Device Details: 10.20.1.40

Total: 1

Scanned: 1

Pending: 0

Successful: No Changes: 0

Failed: 1

Successful: With Changes: 0

I can see in LMS both my switches setup with SNMP. I can view them in DFM and CS and they were

discover in Common services without issue. I have checked and double checked SNMP read string

and telnet ID and Password. Those are all working.

I have verified SNMP is working and can walk the SNMP tree.

Has anyone ran into this before? Any suggestions?

[david.santel]

Reinstalling from scratch has solved my issue.

Another question:

I have the Data Collection Filter set to VTP Domain. Can I get snmp trap emails with this option checked? Im not receiving any emails with SNMP error info?

Thank gain for the help!

[Joe Clarke]

The Data Collection filters have no bearing on traps or emails. They control which devices will be managed by Campus Manager. Therefore, I don't understand your questions.

[david.santel]

I am now getting only Minor Alarms. But not recieveing Warnings or Critical alarms via email. Any ideas?

Some how I am not getting the syslogs communicating to Cisco Works. All swithces are pointing to our Cisco Works for SNMP traps.

[Joe Clarke]

It sounds like you're moving into DFM and RME syslog analysis. Please start new threads for these questions.

[Joe Clarke]

DFM alert identifiers are meaningless. You would need to drill into the alert to get the individual events and their details.

[Joe Clarke]

This means either the client can't connect to this device via telnet or the client browser is improperly configured to handle telnet:// URLs. Either way, it doesn't explain why config archive is failing.