cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
999
Views
0
Helpful
6
Replies

LMS 3.0 syslog reports

dmitry
Level 1
Level 1

Hi,

Recently noticed an interesting thing with the Unexpected Devices syslog report: sometimes I see in there the syslog messages from the devices that are managed by RME, for instance a device's syslog messages would go into the normal syslog reports (Severity summary, 24-hour) yesterday and today I see the messages from the same device, only in the Unexpected devices report.

Maybe such devices are going between the RME managed / unmanaged states?

6 Replies 6

Joe Clarke
Cisco Employee
Cisco Employee

This would not be possible unless the device is being removed from RME (i.e. some manual intervention). Check the RME audit log under RME > Reports > Report Generator > Audit Trail to see if there are any records pertaining to this device.

Checked this log, there is nothing about the devices that show the strange behavior.

I attached a doc with the syslog fragments for a particular device that shows the problem. This device was added into the LMS about 4 months ago.

Another thought, all the devices added into DCR using the DNS names (diplay name, host name is the same and no domain defined (using the resolv.conf search)). Once a device is added and goes into the Normal state in RME, does RME query the DNS each time it receives a syslog message from that device (it should not really have to)?

How are these messages showing up in syslog_info. What are the DCR attributes for this device?

The source syslog messages for both types (Unexpected and normal) look the same format wise (in the attachment).

When the device was added only the desplay name, hostname, primary username + password, RO community were set (LMS uses TACACS (not ACS mode) to get to Lev 15 without enable).

In the DCR export CSV has also the IP and the domain name (discovered / resolved by DCR). The CSV is in the same attachment

Thanks

SyslogAnalyzer maintains a cache of device lookups. Whenever the inventory changes for a device, the cache is invalidated. This will cause SA to look up the hostname in the message, then iterate through each interface on the devices in inventory looking for a matching IP. This whole thing can fail if the lookup on the hostname fails. This failure can be transient (as it appears to be in your case). The clear workaround is to improve resolver response time. This can be done by adding local hosts entries, or adding multiple DNS servers.

This what I was thinking too, will set a dedicated secondary DNS zone in BIND off of the corporate W2003 DNS servers, see if it fixes the issue

Thanks for helping with this

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco