I'm assuming this can work with switches, routers, and controllers. I'm running PI 2.1 and am trying to get the configuration archive functionality working. I have both of these options checked under System Settings > Configuration Archive:
:: Archive configuration out-of-box
:: Archive configuration on receiving configuration change events
On the IOS device, these settings were configured for syslog/snmp:
logging buffered 100000
no logging event link-status
logging trap notifications
logging facility local6
logging source-interface Loopback0
logging <Prime IP>
snmp-server community ***** RW 13
snmp-server enable traps config
snmp-server enable traps syslog
snmp-server host <Prime IP> version 2c *****
I do not see any syslog messages in PI under alarms/alerts and the configuration never gets archived. I haven't run tcpdump yet to determine if PI is receiving these traps but I was hoping it was something simple I was overlooking. Thanks for any assistance that can be provided.
thank you for the hint to the "Archive configuration on receiving configuration change events" feature. Didn't know that.
Are you using the same community to send traps as to poll the device from prime?
Thank you for the reply. To answer your question, yes. Community information matches with PI credentials.
I actually did get it to work yesterday. I did original testing on a 1921 router which is still not working, but when I tried configuring the same information on some switches (3750's) it worked. I thought routers would be configured the same - are there hardware limitations to this?
I look in the built-in CLI template 'Configure Logging' in PI and it only has switches and WLCs as available devices to push out to but I don't know what to make of it.
I found out the issue with the router syslog trap.
The device was originally added into Prime using the loopback0 interface. Logging was configured on the router using this interface as well. What I overlooked was that there was a secondary IP configured on the loopback0 interface. It just so happened that Prime was managing the device via the secondary IP, and syslog will only send out traps on the primary IP. When the device was re-added into Prime using the loopback0 primary address it worked.