Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.7(5)
Monitoring Event Logs
Downloads: This chapterpdf (PDF - 419.0KB) The complete bookPDF (PDF - 18.67MB) | Feedback

Monitoring Event Logs

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 13-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 13-2.

Figure 13-2 Monitoring > Summary Page

The page includes the information shown in Table 13-1.

Table 13-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.

Global Subnets configured

The number of subnet addresses currently in the subnet-based passthrough list. For more information, see Global Device and Subnet Filtering.

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.

Installed card in the system

Indicates one or both of the following:

For HP-based appliances (NAC-3140, 3310, 3350, and 3390)—whether or not a Cavium accelerator card (like the Cavium 1120) is installed in the appliance.

For FIPS 140-2 compliant next generation appliances (NAC-3315, 3355, and 3395)—Whether a FIPS card is installed and enabled on the system to provide FIPS compliant functions for your deployment and whether or not the System is running in FIPS mode.


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 13-3 shows the Log Viewer pane.

Figure 13-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 13-2 describes the navigation, searching capabilities, and actual syslog displayed on the Log Viewer page.

Table 13-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 13-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 13-3 for an example of Clean Access Server event.

1 Authentication-type entries may include the item "Provider: <provider type>, Access point: N/A, Network: N/A." To continue to provide support for the EOL'ed legacy wireless client (if present and pre-configured in the Manager), the "Access point: N/A, Network: N/A" fields provide AP MAC and SSID information respectively for the legacy client.


Event Log Example

Table 13-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 13-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 13-4 lists common Clean Access Manager and Clean Access Server logs in Cisco NAC Appliance.

Table 13-4 Cisco NAC Appliance Log Files

File
Description
/var/log/messages 

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

/var/log/ha-log

High availability logs (both CAM and CAS)

/var/log/dhcplog 

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)

1 Device Management events for notifications received by the CAM from switches are written only to the logs on the file system (/perfigo/control/tomcat/logs/nac_manager.log). These events are written to disk only when the log level is set to INFO or finer.

2 Perfigo service log files in previous releases of Cisco NAC Appliance reside in the /perfigo/logs/perfigo-log0.log.* or /tmp/perfigo-log0.log.* (pre-release 3.5(5)) directory. For these older logs, 0 instead of * shows the most recent log.


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.

The log file sizes can be controlled by using the following files:

On Clean Access Manager, logging is controlled by the file: /perfigo/control/tomcat/conf/logback.xml

On Clean Access Server, logging is controlled by the file: /perfigo/access/tomcat/conf/logback.xml

In the above xml files, the following parameters can be changed to control the log file size:

<MinIndex> — Determines the minimum index of the log file name extension.

<MaxIndex> —Determines the maximum index of the extension.

The difference between the above two parameters determines the count of files.

<MaxFileSize> — Determines the file size limit of each log file.

The command ls -clt lists the log files available.


Note Cisco recommends to increase the count and limit moderately.

Note Use service perfigo restart to pickup the new logging configuration.

For additional details see also:

Support Logs

Certificate-Related Files.

Backing Up the CAM Database

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 13-4).

Figure 13-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.

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 13-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.