Table Of Contents
Monitoring Event Logs
Overview
Interpreting Event Logs
View Logs
Event Log Example
Limiting the Number of Logged Events
Configuring Syslog Logging
Cisco NAC Appliance Log Files
Log File Sizes
SNMP
Enable SNMP Polling/Alerts
Add New Trapsink
Monitoring Event Logs
This chapter describes the Monitoring module of Cisco NAC Appliance. Topics include:
•
Overview
•
Interpreting Event Logs
•
Configuring Syslog Logging
•
Cisco NAC Appliance Log Files
•
SNMP
Overview
Figure 14-1 Monitoring Module
The Monitoring pages provide operational information for your deployment, including information on user activity, syslog events, network configuration changes. The Monitoring module also provides basic SNMP polling and alerts. The Monitoring Summary status page summarizes several important statistics, shown in Figure 14-2.
Figure 14-2 Monitoring > Summary Page
The page includes the information shown in Table 14-1.
Table 14-1 Monitoring > Summary Page
Item
|
Description
|
Current Windows NAC Agent Version
|
The current Windows version of the Agent installed with the CAM software or manually uploaded (reflects the contents of the Version field).
|
Current Macintosh Clean Access Agent
|
The current version of the Mac OS X Clean Access Agent installed with the CAM software or manually uploaded (reflects the contents of the Version field).
|
Current Cisco NAC Web Agent Version
|
The current version of the Cisco NAC Web Agent installed with the CAM software or manually uploaded (reflects the contents of the Version field).
|
Clean Access Servers configured
|
The number of Clean Access Servers configured in the CAS management pages for the Clean Access Manager domain.
|
Global MAC addresses configured (addresses/ranges)
|
The number of addresses and ranges currently in the MAC/IP device filter passthrough list. For details on MAC passthrough lists, see Global Device and Subnet Filtering, page 3-10.
|
Global Subnets configured
|
The number of subnet addresses currently in the subnet-based passthrough list. For more information, see Global Device and Subnet Filtering, page 3-10.
|
Online users (In-Band / Out-of-Band)
|
These entries list:
• Total number of IB and/or OOB online user names
• Total number of IB and/or OOB online MAC addresses
• Number of IB and OOB online users per user role
Note Per-role user tallies are links to the Monitoring > Online Users > View Online Users page. Clicking a link displays the IB or OOB online user list for the particular role.
For more information, see Online Users List, page 12-18.
|
Interpreting Event Logs
Click the Event Logs link in the Monitoring module to view syslog-based event logs in the admin console. There are three Event Logs tabs: Log Viewer, Logs Settings, and Syslog Settings.
View Logs
Figure 14-3 shows the Log Viewer pane.
Figure 14-3 Log Viewer Pane
The Log Viewer tab includes the following information:
•
System statistics for Clean Access Servers (generated every hour by default)
•
User activity, with user logon times, log-off times, failed logon attempts, and more.
•
Network configuration events, including changes to the MAC or IP passthrough lists, and addition or removal of Clean Access Servers.
•
Device management events (for OOB), including when linkdown traps are received, and when a port changes to the Auth or Access VLAN.
•
Changes or updates to Cisco NAC Appliance checks, rules, and Supported AV/AS Product List.
•
Changes to Clean Access Server DHCP configuration.
System statistics are generated for each CAS managed by the Clean Access Manager every hour by default. See Configuring Syslog Logging to change how often system checks occur.
Note
The most recent events appear first in the Events column.
Table 14-2 describes the navigation, searching capabilities, and actual syslog displayed on the Log Viewer page.
Table 14-2 Log Viewer Page
| |
Column
|
Description
|
Navigation
|
First Page/Previous Page/ Previous Entry/Specific Page/Next Entry/Next Page/Last Page
|
These navigation links page through the event log. The most recent events appear first in the Events column. The Last link shows you the oldest events in the log.
|
Page Size
|
The number of log entries displayed in the window. (You can specify 10, 25, or 100 entries per page.)
|
Column
|
Click a column heading (e.g. Type or Category) to sort the Event log by that column.
|
Search criteria
|
Type
|
Search by Type column criteria (then click Filter):
• Any Type
• Failure
• Information
• Success
|
Category
|
Search by Category column criteria (then click Filter):
• Authentication 1
• Administration
• Client
• Clean Access Server
• Clean Access
• SW_Management (if OOB is enabled)
• DHCP
• Guest Registration
• SSL Communication
• Miscellaneous
|
Time
|
Search by the following Time criteria (then click Filter):
• Within one hour
• Within one day
• Within two days
• Within one week
• Anytime
• One hour ago
• One day ago
• Two days ago
• One week ago
|
| |
Search in log text
|
Type desired search text and click Filter
|
Controls
|
Filter
|
After selecting the desired search criteria, click Filter to display the results.
|
Reset
|
Clicking Reset restores the default view, in which logs within one day are displayed.
|
Delete
|
Clicking Delete removes the events filtered through the search criteria across the number of applicable pages. Clicking Delete removes filtered events from Clean Access Manager storage. Otherwise, the event log persists through system shutdown. Use the filter event indicator shown in Figure 14-3 to view the total number of filtered events that are subject to being deleted.
|
Status Display
|
Type
|
• Red flag ( ) = Failure; indicates error or otherwise unexpected event.
• Green flag ( ) = Success; indicates successful or normal usage event, such as successful login and configuration activity.
• Yellow flag ( ) = Information; indicates system performance information, such as load information and memory usage.
|
Category
|
Indicates the module or system component that initiated the log event. (For a list, see Category.) Note that system statistics are generated for each Clean Access Server managed by the Clean Access Manager every hour by default.
|
Time
|
Displays the date and time (hh:mm:ss) of the event, with the most recent events appearing first in the list.
|
Event
|
Displays the event for the module, with the most recent events listed first. See Table 14-3 for an example of Clean Access Server event.
|
Event Log Example
Table 14-3 explains the following typical Clean Access Server health event example:
CleanAccessServer 2007-04-05 09:03:31 10.201.15.2 System Stats: Load factor 0 (max
since reboot: 2) Mem (bytes) Total: 528162816 Used: 295370752 Free: 232792064 Shared:
0 Buffers: 41537536 Cached: 179576832 CPU User: 0% Nice: 0% System: 1% Idle: 99%
Table 14-3 Event Column Fields
Value
|
Description
|
CleanAccessServer
|
A Clean Access Server is reporting the event
|
2007-04-05 09:03:31
|
Date and time of the event
|
10.201.15.2
|
IP address of reporting Clean Access Server
|
System Stats:
|
System statistics are generated for each Clean Access Server managed by the Clean Access Manager every hour by default.
|
Load factor 0
|
Load factor is a number that describes the number of packets waiting to be processed by the Clean Access Server (that is, the current load being handled by the CAS). When the load factor grows, it is an indication that packets are waiting in the queue to be processed. If the load factor exceeds 500 for any consistent period of time (e.g. 5 minutes), this indicates that the Clean Access Server has a steady high load of incoming traffic/packets. You should be concerned if this number increases to 500 or above.
|
(max since reboot: <n>)
|
The maximum number of packets in the queue at any one time (i.e. the maximum load handled by the Clean Access Server).
|
Mem Total: 528162816 bytes
|
These are the memory usage statistics. There are 6 numbers shown here: total memory, used memory, free memory, shared memory, buffer memory, and cached memory.
|
Used: 295370752 bytes
|
Free: 232792064 bytes
|
Shared: 0 bytes
|
Buffers: 41537536 bytes
|
Cached: 179576832 bytes
|
CPU User: 0%
|
These numbers indicate CPU processor load on the hardware, in percentages. These four numbers indicate time spent by the system in user, nice, system, and idle processes.
Note Time spent by the CPU in system process is typically < 90% on a Clean Access Server. This indicates a healthy system.
|
Nice: 0%
|
System: 1%
|
Idle: 99%
|
Limiting the Number of Logged Events
The event log threshold is the number of events to be stored in the Clean Access Manager database. The maximum number of log events kept on the CAM, by default, is 100,000. You can specify an event log threshold of up to 200,000 entries to be stored in the CAM database at a time. The event log is a circular log. The oldest entries will be overwritten when the log passes the event log threshold.
To change the maximum number of events:
1.
Click the Logs Setting tab in the Monitoring > Event Logs pages.
2.
Type the new number in the Maximum Event Logs fields.
3.
Click Update.
Configuring Syslog Logging
System statistics are generated for each Clean Access Server managed by the Clean Access Manager every hour by default. By default, event logs are written to the CAM. You can redirect CAM event logs to another server (such as your own syslog server).
Additionally, you can configure how often you want the CAM to log system status information by setting the value in the Syslog Health Log Interval field (default is 60 minutes).
To configure Syslog logging:
Step 1
Go to Monitoring > Event Logs > Syslog Settings.
Step 2
In the Syslog Server Address field, type the IP address of the Syslog server (default is 127.0.0.1).
Step 3
In the Syslog Server Port field, type the port for the Syslog server (default is 514).
Step 4
Specify a Syslog Facility from the dropdown list. This setting enables you to optionally specify a different Syslog facility type for Syslog messages originating from the CAM. You can use the default "User-Level" facility type, or you can assign any of the "local use" Syslog facility types defined in the Syslog RFC ("Local use 0" to "Local use 7"). This feature gives you the ability to differentiate Cisco NAC Appliance Syslog messages from other "User-Level" Syslog entries you may already generate and direct to your Syslog server from other network components.
Step 5
In the System Health Log Interval field, specify how often you want the CAM to log system status information, in minutes (default is 60 minutes). This setting determines how frequently CAS statistics are logged in the event log.
Step 6
In the CPU Utilization Interval field, specify how often, in seconds, you want the CAM to record CPU utilization statistics. You can configure the CAM to record CPU status information up to nearly every minute and the default is every 3 seconds.
Step 7
Click the Update button to save your changes.
Note
After you set up your Syslog server in the CAM, you can test your configuration by logging off and logging back into the CAM admin console. This will generate a Syslog event. If the CAM event is not seen on your Syslog server, make sure that the Syslog server is receiving UDP 514 packets and that they are not being blocked elsewhere on your network.
Note
You can only forward to one syslog server. You can have that syslog server forward to another if required.
Cisco NAC Appliance Log Files
Table 14-4 lists common Clean Access Manager and Clean Access Server logs in Cisco NAC Appliance.
Table 14-4 Cisco NAC Appliance Log Files
File
|
Description
|
|
Startup
|
/perfigo/control/tomcat/logs/nac_manager.log
|
Perfigo service logs for release 4.5 and later 1 ,2
|
/perfigo/control/data/details.html
/perfigo/control/data/upgrade.html
|
CAM upgrade logs
|
/var/nessus/logs/nessusd.messages
|
Nessus plugin test logs
|
/perfigo/control/apache/logs/*
|
SSL (certificates), Apache error logs
|
/perfigo/control/tomcat/logs/catalina.out
|
Tomcat initialization logs
|
|
High availability logs (both CAM and CAS)
|
|
DHCP relay, DHCP logs (CAS)
|
/perfigo/access/data/details.html
/perfigo/access/data/upgrade.html
|
CAS upgrade logs
|
/perfigo/access/tomcat/logs/nac_server.log
|
Certificate-related CAM/CAS connection errors (CAS)
|
Log File Sizes
•
There are 10 logs with a maximum size of 20 MB for the /perfigo/control/tomcat/logs/nac_manager.log log file.
•
There are 20 logs with maximum size of 20 MB for each log file under /perfigo/(control | access)/apache/logs.
For additional details see also:
•
Support Logs, page 15-42
•
Certificate-Related Files, page 15-23.
•
Backing Up the CAM Database, page 15-55
SNMP
You can configure the Clean Access Manager to be managed/monitored by an SNMP management tool (such as HP OpenView). This feature provides minimal manageability using SNMP (v1). It is expected that future releases will have more information/actions exposed via SNMP.
You can configure the Clean Access Manager for basic SNMP polling and alerting through Monitoring > SNMP. Note that SNMP polling and alerts are disabled by default. Clicking the Enable button under Monitoring > SNMP activates the following features:
•
SNMP Polling—If an SNMP rocommunity ("Read-only community") string is specified, the Clean Access Manager will respond to snmpget and snmpwalk requests with the correct community string.
•
SNMP Traps—The Clean Access Manager can be configured to send traps by adding trap sinks. A trap sink is any computer configured to receive traps, typically a management box. All traps sent are version 1 (v1) traps. A copy of each trap will be sent to each trapsink.
When enabled, the SNMP module monitors the following processes:
•
SSH Daemon
•
Postgres Database
•
Clean Access Manager
•
Apache Web Server
The Clean Access Manager also sends traps in the following cases:
•
When the Clean Access Manager comes online.
•
When the Clean Access Manager shuts down.
•
When the Clean Access Manager gains or loses contact with any Clean Access Servers it manages.
•
When the SNMP service starts (a Cold Start Trap is sent).
This section describes the following:
•
Enable SNMP Polling/Alerts
•
Add New Trapsink
Enable SNMP Polling/Alerts
1.
Go to Monitoring > SNMP to bring up the SNMP configuration page (Figure 14-4).
Figure 14-4 Monitoring > SNMP Page
2.
Click the Enable button to activate SNMP polling and SNMP traps.
3.
Specify values for the following fields:
•
Read-Only Community String:
Specify a string to enable the Clean Access Manager to respond to snmpget and snmpwalk requests with the correct community string.
Leave blank to disable all Clean Access Manager responses to SNMP polling of the Clean Access Manager.
•
Disk Trap Threshold%: (default is 50%)
A trap will be sent when root partition free space falls below specified percentage.
•
One-Minute Load Average Threshold: (default is 3.0)
A trap will be sent when the one-minute load average exceeds the threshold set here. Enter load averages as per standard unix definition. For example, a one-minute load average of 1.0 means on average over a full minute there were at least three processes blocked due to lack of CPU time.
•
Five-Minute Load Average Threshold: (default is 2.0)
A trap will be sent when the 5-minute load average exceeds the threshold set here. Enter load averages as per standard unix definition.
•
Fifteen-Minute Load Average Threshold: (default is 1.0)
A trap will be sent when the 15-minute load average exceeds the threshold set here. Enter load averages as per standard unix definition.
4.
Click Update to update the SNMP configuration with new thresholds.
5.
Click Download to download the SNMP MIB archive in .tar.gz form.
Add New Trapsink
The Clean Access Manager can be configured to send traps by adding trap sinks. All traps sent are version 1 (v1) traps. A copy of each trap will be sent to each trapsink.
1.
Click the Add New Trapsink link in the upper-right-hand corner of the pane to bring up the Add New Trapsink form.
2.
Enter a Trapsink IP.
3.
Enter a Trapsink Community string.
4.
Enter an optional Trapsink Description.
5.
Click Update to update the SNMP Trapsink table.
Figure 14-5 Add New Trapsink
Once trapsink configuration is complete, the Clean Access Manager will send DISMAN-EVENT style traps which refer to UCD table entries. The Clean Access Manager also sends traps if the root partition falls below a configured amount of space remaining (which defaults to 50%), and if the CPU load is above the configured amount for 1, 5 or 15 minutes.
A trap will contain the following contents:
Trap Contents
|
Description
|
Type: Enterprise-Specific(1)
|
|
SNMP Trap OID (1.3.6.1.6.3.1.1.4.1.0)
|
Set to DISMAN-EVENT-MIB 2.0.1 (1.3.6.1.2.1.88.2.0.1)
|
The contents of a DISMAN mteObjectsEntry:
|
|
| |
mteHotTrigger (OID 1.3.6.1.2.1.88.2.1.1)
|
Generally: "process table" for processes "laTable" for load average alerts "dskTable" for disk capacity alerts "memory" for virtual memory alerts
|
| |
mteHotTargetName (OID 1.3.6.1.2.1.88.2.1.2)
|
Always blank.
|
| |
mteHotContextName (OID 1.3.6.1.2.1.88.2.1.3)
|
Always blank.
|
| |
mteHotOID (OID 1.3.6.1.2.1.88.2.1.4)
|
Set to the OID of the UCD table that contains the data that triggered the event.
|
| |
mteHotValue (OID 1.3.6.1.2.1.88.2.1.5)
|
Set to 0 if the trap is not an error Set to non-zero if an error condition is being reported (generally 1).
|
| |
mteFailedReason (OID 1.3.6.1.2.1.88.2.1.6)
|
Set to a string describing the reason the alert was sent.
|