Please read the recent post for details.
I have 6 campus mgr servers that are now all set to generate syslog messages to 3 different syslog servers that have the RSAC software installed. The 3 RME servers are, in turn, set to pull these syslog messages from the syslog servers and it works well. What I have is a number of automated actions to generate an email. This works very good.
Here's the issue: I set an automated action to generate an email with messages that have a facility of 'CISCOWORKS-CampusManager'. It doesn't appear this is working and I have a feeling it has to do with the fact that the Campus servers are unknown to RME. It looks like the only way these messages can be viewed at this time is by accessing the Unexpected Device report where they are showing up.
Can I have an automated email action to email on events from these Campus Mgr servers? I certainly hope so because logging into 3 RME servers and looking at the unexpected device report is not a good solution.
Please let me know.
Solved! Go to Solution.
If the messages appear under unexpected device report then they aren't truly managed messages in RME and you won't be able to generate automated actions based upon them.
If there are messages from Campus Manager then most likely there is an issue on the device itself that should generate a syslog message. For example if you have a duplex mismatch reported in Campus then the switch should also see this and then send the message.
The Campus Manager generate syslog is an extra tool to help identify problems in the topology, but doesn't have the full functionality of normal syslog messages.
Take this message for example: This is a message that shows up in the unexpected device report: CISCOWORKS-CampusManger-5-DCRP_STPENABLE_ONACCESSPORT
"nmsccm06.kp.org","12 Jul 2006 07:42:57 EDT","CISCOWORKS-CampusManager","5","DCRP_STPENABLED_ONACCESSPORT","[lcamilc2.ca.kp.org],Fa2/48,Fa2/47,Fa2/46,Fa2/45,Fa2/44,Fa2/43,Fa2/42,Fa2/41,Fa2/40,Fa2/39,Fa2/38,Fa2/37,Fa2/36,Fa2/35,Fa2/34,Fa2/33,Fa2/31,Fa2/30,Fa2/29,Fa2/28,Fa2/27,Fa2/26,Fa2/25,Fa2/24,Fa2/23,Fa2/22,Fa2/21,Fa2/20,Fa2/19,Fa2/18,Fa2/17,Fa2/16,Fa2/15,Fa","*"
This is a an instance where spanning-tree port fast is enabled on a trunk port and it shouldn't be. I don't see where a logged message is present for this condition.
Is it possible an enhancement or patch could be written to allow the functionality for RME to be able to create an automated email action on this?
It wouldn't be so bad if there were only a few hundred devices and 1 or 2 CiscoWorks servers but this network has close to 14,000 devices w/ 3 RME servers and 6 Campus servers....
You could probably get with your account team to file an enhancement request for the issue. There most likely won't be anymore patches for RME 3.5 as support for new issues is in RME 4.x
I just tested this in CM/RME 4.x and was able to get it working in a standard report. The devices did show up again in unexpected, but I added 127.0.0.1 as a device to DCR.
This will make the syslog messages coming from loopback address appear in standard report.
I added the loopback address with the read community for the CiscoWorks server. It's now one of the managed devices and RME is performing automated actions on the syslog messages from it (CM Network
This is not really a supported device in the DCR or method, but got it working as a bit of a trick this way.
I will relay this information to Rick (the TAC guy that took the case I opened) and see if he can help me get an enhancment request through.
Thanks for your help on this!
Most likely the TAC will point you to the Acct team or help get you the right contact as the acct team handles enhancement requests. They can they create a business case and work with the BU to get the feature added
If I'm able to get my Acct team to push the right buttons, any idea if this will be something development could easily write or will it be an extremely complicated fix?
This might take a while to do as I would say its not really a bug, but the way it was designed. It could mean something down the road in a future release, but doesn't look like something that's patchable.
I'm hoping a workaround or fix can be written for RME 3.5...
There are some valuable messages coming from the Campus servers that don't necessarily show in the log of the devices and to the syslog servers. For example, trunk ports that have spanning-tree port fast enabled and I can see some other valuable trunk messages that I can't see any other way we are currently monitoring them. If I can't send an automated email action, the customer will complain #1 that it's not a real time or near real time solution and #2 I will get tired of checking the unexpected device reports every day.
I haven't heard back from Rick today. I'm hoping he can somehow help me hunt my acct team down because I have no idea who they are.....
I doubt there will be anything done for RME 3.5 as development is focusing on RME 4.x now. The last IDU for RME 3.5 was released and in order to get future device support and enhancements things will have to be rolled into current (LMS 2.5.1) or future releases.
If they're unable to write me a fix, I could try to put a cron-ed script in place that greps througth the /var/log/rtrlog syslog file on the customer's syslog server...I have access to it.
A problem w/ this approach is my scripting skills are weak at best.
What I could do is cron the script to run the next day and look for messages on the date minus 1 day (ever how that's done) or I could try running something every hour on the hour to grep through the syslog file then write all messages w/ a facility of CISCOWORKS-CampusManager to another file then somehow try to send only messages that have not been emailed yet. I do know that I can use the mail command on that box because I have another script running that emails me if a process stops.