I have an issue with syslog triggered fetch config feature. The problem is that LMS expects Sub-facility to be a part of the syslog message.
I have set the Facility to be SYS and severity 5. Result? Nothing is happening, because none of our devices send Sub-facility and therefore the automated action will never take place.
Name: mail notif
Parameters: TOfirstname.lastname@example.org, SUB=CW RME Syslog AA, TEXT=TEST !
Action Type: Email
I don't understand what you want to do.
You want to get an email when a config is fetched triggered by syslog?
You can compare the the system defined config for config check to see how the syslog message is configured with facility and so on.
No No. All I want is LMS to fetch the config when a syslog message about config change is sent
The devices send "SYS-5-CONFIG_I: Configuration changed" message.
And because LMS expects *-*-*-*:* format, the automated fetch procedure is not executed.
See the difference ? LMS expects 5 variables in the message and the devices send only 4.
Message was edited by: Martin Smid
Is this a custom filter, or the default one that comes out-of-the-box with RME? Either way, the filter in the first post is way too loosely defined. The correct ones (of the default one) are listed in Table 14-2 here:
The filter posted in first post is customized. That does not change the fact that even the default filters do not work.
I mentioned the reason for the failures is that LMS expects something from the devices it will not get.
It looks like my explanation is not being understood.
"SYS-5-CONFIG_I: Configuration ..."
SYS = facility
5 = severity
CONFIG_I = mnemonic
Configuration ... = Description
and this is how it is going through the LMS filter
SYS = facility
5 = sub-facility
CONFIG_I = severity
Configuration ... = mnemonic
LMS needs to skip the check for sub-facility.
The only way how I could get an automated action is to create filter *-*-*-*:* That is the only filter, which resulted with successfully sent email to the recipient.
Maybe I am doing something terribly wrong, but the bottom line is that even the default filters do not work.
Do you have this problem with all your devices or only with one device type?
I checked my default auto action for config fetch:
But there are a lot of other syslog-entries for that action!
What do you mean with "and this is how it is going through the LMS filter"? Where did you see this?
You have the word "configuration" in your syslog message?
Did you try to check the syslog messages from the devices with wireshark on the server?
Here is the syslog message from the device
1045204: Aug 2 07:33:20.021: %SYS-5-CONFIG_I: Configured from console by martin.smid onvty2 (x.x.x.x)
(that's where the "Configured" is from. I just didn't want to write down the whole description and the IP was replaced)
About the LMS filter. I thought if LMS awaits 5 variables it will look for 5 variables. And as you can see in the syslog message, the devices send only 4. (No Sub-Facility)
The syslog messages do arrieve to LMS. You can see it in the screenshot.
And yes, none of the devices trigger automated action.
okay....now I understand :-)
Maybe it is a little bit bad description of syslog messages....but the allocation of the variables is as I wrote before.
Sub-Facility: not present -> so it will be a * in the filter
Description: Configuration..... -> so it will be a * in the filter because I am not sure if there are different descriptions between device types.
I never saw a syslog message with sub-facility, so I can't tell you how this would look like.
Is the default auto action for config fetch enabled?
Do the messages arrive at the LMS server?
I had the same problem with config fetch some times ago.
Please check if the auto action for another syslog message is working? If you have a test device you can create a filter for that single device and filter for a special syslog message and send an email to you.
If this is not working, too, it is possible that you have the same analyser problem then me.
Please check if another auto action is working as I wrote in my last post.
If no, it could be a problem with the queue of SyslogAnalyser.
Please restart the services with "net stop crmdmgtd" and "net start crmdmgtd" so the queue should be empty and the action should work.
This does not work for a long time (3 months roughly) and I found enought time just now. The server was restarted several times and also upgraded. I will wait for Joe to show up or anyone else from Cisco and I will probably have to raise a TAC request.
Thanks for the help though. I will post the solution when we get it
This was fixed by a patch. The bug caused NON-RME devices to affect the response to the RME devices. In other words if you have non-RME devices it could cause troubles with automated syslog actions.