02-07-2008 05:39 PM
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?
02-07-2008 10:28 PM
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.
02-08-2008 07:47 AM
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)?
02-08-2008 12:09 PM
How are these messages showing up in syslog_info. What are the DCR attributes for this device?
02-08-2008 02:23 PM
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
02-08-2008 03:38 PM
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.
02-08-2008 04:21 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide