Aruba & ProVision-based
cancel
Showing results for 
Search instead for 
Did you mean: 

Help with ProCurve 3500 SysLog Configuration

 
Highlighted
swaitch
Occasional Collector

Help with ProCurve 3500 SysLog Configuration

Hello,

 

I am running a graylog server to collect syslogs from multiple servers and am now playing with the idea of adding our ProCurve switches to the mix.

 

Here is what I have done so far:

 

logging facility syslog

logging x.x.x.x

logging severity debug (which I assumed would include this level and above. ??)

debug destination logging

debug all (sans ip, ipv6, lldp to eliminate too much data as I am new to this and alone in this endeavor so I can only handle so much)

 

The graylog server is receiving syslog messages from the switch but it really isn't giving me much to work with . Examples:

 

auth: User 'X' logout

mgr: Startup configuration changed by CLI. New seq. number 77

 

What would be nice is to see such things as entered commands, e.g., wr mem, static route changes, etc.

 

I am working with a ProCurve 3500yl, software version K.15.13.0005

 

Any suggestions would be appreciated.

1 REPLY 1
Highlighted
Michael Patmon
Trusted Contributor

Re: Help with ProCurve 3500 SysLog Configuration

Logging of config changes can be done via the Radius Accounting subsystem:
(config)# aaa accounting commands stop-only syslog

 

Sorta buried, I'll admit...

 

Syslog server output:
Aug 21 11:09:52 128.44.120.1 acct: Acct-Session-ID='0x086800000007',Acct-Status-Type='Stop',NAS-Identifier='mike',User-Name='mpatmon',Acct-Authentic='RADIUS',Calling-Station-Id='128.44.120.100',HP-Command-String='ip route 1.1.1.1/32 10.1.1.1'
Aug 21 11:10:06 128.44.120.1 03125 mgr: Startup configuration changed by CLI. New seq. number 848
Aug 21 11:10:06 128.44.120.1 acct: Acct-Session-ID='0x086800000008',Acct-Status-Type='Stop',NAS-Identifier='mike',User-Name='mpatmon',Acct-Authentic='RADIUS',Calling-Station-Id='128.44.120.100',HP-Command-String='write memory'

 

I would not enable the other debug types you mentioned unless you are debugging a problem. Some of the debug output is extremely frequent and verbose and can induce a significant burden on system resources. "Debug event" plus the command logging is all you really need for what you stated.

 

You can also see the Access Security Guide for more info. Hope that helps.