-
Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2
-
Index
-
Title Page
-
Preface
-
Chapter 1: Understanding the ACNS 5.2 Network
-
Chapter 2: Using the Content Distribution Manager GUI
-
Chapter 3: Getting Started
-
Chapter 4: Setting Up Content Request Routing in the ACNS Network
-
Chapter 5: Configuring the ACNS Network for Content Distribution
-
Chapter 6: Configuring the ACNS Network for Content Acquisition
-
Chapter 7: Creating and Managing Programs
-
Chapter 8: Configuring Caching Services
-
Chapter 9: Configuring Streaming Media Services
-
Chapter 10: Working with Device Configurations
-
Chapter 11: Configuring Network Interfaces
-
Chapter 12: Configuring Request Processing Services
-
Chapter 13: Configuring Request Authentication and Authorization
-
Chapter 14: Configuring Login Authentication and Authorization
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring Platform and System Settings
-
Chapter 17: Upgrading and Downgrading the Software
-
Chapter 18: Monitoring the ACNS Network
-
Chapter 19: Backup and Recovery Procedures
-
Appendix A: Creating Manifest Files
-
Appendix B: Configuring Disk Space
-
Appendix C: IP Multicast Addressing
-
Appendix D: Advanced Routing Configurations
-
Appendix E: Mapping ACNS Software CLI Commands to the Content Distribution Manager GUI
-
Table Of Contents
Monitoring and Troubleshooting the ACNS Network
Troubleshooting Devices Using the System Status Bar
Using the Content Distribution Manager GUI show Command Tool
Troubleshooting Content Replication Issues Using the System Status Bar
Viewing Content Engine Statistics
Viewing Device Group Statistics
Bandwidth Efficiency Gain Report
Monitoring Content Replication Status
Viewing the System-Wide Replication Status by Channel
Viewing the Replication Status for a Specific Channel
Viewing the Detailed Replication Status of Content Items for a Specific Channel
Viewing the Detailed Replication Status of Content Items for a Channel by Device
Viewing the Detailed Replication Status of Content Items Across All Content Engines in a Channel
Viewing the System-Wide Replication Status by Content Engine
Viewing the Replication Status for a Specific Content Engine
Viewing the Detailed Replication Status of Content Items for a Selected Channel by Content Engine
Using CLI Commands for Replication Status
Configuring System Event Logging Using the Content Distribution Manager GUI
About Multiple Hosts for System Logging
Configuring System Event Logging Using CLI Commands
Viewing the System Message Log
Understanding Transaction Log Formats
Squid-Style Transaction Logging
Apache-Style Transaction Logging
Custom Format Transaction Logging
Transaction Logging and NTLM Authentication
Usage Guidelines for Log Files
Exporting Transaction Logs to External FTP Servers
Exporting Transaction Logs to External SFTP Servers
Enabling Transaction Logging with the Content Distribution Manager GUI
Log Formats Accepted by Windows Media Services 9
Configuring WMT Transaction Logging
Using Real-Time Transaction Logging
Configuring Real-Time Transaction Logging
About Specifying the Transaction Log Entry Type when Logging to a Remote Syslog Host
Configuring SNMP General Settings
Configuring SNMP Community Settings
Configuring SNMP Group Settings
Configuring SNMP User Settings
Configuring SNMPv2 View Settings
Configuring SNMP Host Settings
Configuring SNMP Asset Tag Settings
Configuring SNMP Traps Using the CLI
Monitoring and Troubleshooting the ACNS Network
This chapter provides information on monitoring and troubleshooting devices and content replication in the ACNS network, and on using the system message logs, transaction logs, and SNMP.
This chapter contains the following sections:
•
Monitoring Content Replication Status
Monitoring System Status
The ACNS 5.2 Content Distribution Manager GUI displays the system status in a system status bar that is located above the navigation tabs in every window. The system status bar presents the overall device and content health of the system. You can use this feature to monitor devices and content replication in your ACNS network. The system status bar helps you immediately identify any problems on the network, allowing you to act and respond to problems quickly. (See Figure 18-1.)
Figure 18-1 System Status Bar
The system status reporting mechanism uses four alarm lights to identify problems that need to be resolved. Each light represents a different alarm level, as follows:
•
•
•
•
When you roll your mouse over an alarm light in the system status bar, a popup message provides further details about the device or channel status (see Figure 18-2). When you click the alarm light, a troubleshooting window opens (Troubleshooting Devices or Troubleshooting Content), listing the individual devices or channels that need attention.
Figure 18-2 Status Details
When you roll your mouse over an item under the Alarm Information column in the Troubleshooting Devices or Troubleshooting Content window, a contextual popup menu appears. The popup menu provides links to all the diagnostic tools, troubleshooting tools, logs, and monitoring applications for troubleshooting and resolving the problem. Figure 18-3 shows the troubleshooting tools menu for device alarms.
Figure 18-3 Troubleshooting Tools Menu
Device Alarms
Device alarms are associated with device objects and pertain to applications and services running on Content Engines, Content Routers, and Content Distribution Managers. Device alarms are defined by the reporting application or service. Device alarms can also reflect reporting problems between the device and the Content Distribution Manager. (See Table 18-1.)
Troubleshooting Devices Using the System Status Bar
To troubleshoot a device from the system status bar, follow these steps:
Step 1
Step 2
Step 3
Using the Content Distribution Manager GUI show Command Tool
To use the Content Distribution Manager GUI show command tool, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Content Alarms
Content alarms pertain to content replication problems and are associated with channels. Content alarms are raised by the Content Distribution Manager based on replication status reports. To view the content alarms, click the Content alarm light or click the Channels link next to the alarm light in the status bar. The Troubleshooting Content window pops up. (See Figure 18-4.) Table 18-3 lists the content alarms.
Figure 18-4 Troubleshooting Content—Content Alarms
Troubleshooting Content Replication Issues Using the System Status Bar
To troubleshoot content replication issues from the system status bar, follow these steps:
Step 1
Step 2
Step 3
Monitoring Device Status
The Device Home window provides device and alarm status for individual devices. (See Figure 18-5.)
Figure 18-5 Monitoring Device Status
Monitoring Device Statistics
It is often useful to be able to assess the performance of Content Engines across your network. You can do this using the Content Engine statistics feature in the Content Distribution Manager GUI. The System Home window displays system-wide statistics in a graphical form and enables you to view, at a glance, which Content Engines are online, as well as assess their available resources, the volume of traffic being routed to them, and their performance in serving requests. (See Figure 18-6.)
Figure 18-6 System Home
The information displayed is based on a snapshot of your ACNS network that represents the state of your Content Engines at the end of every two polling periods. You can configure the interval between polls in the Content Distribution Manager GUI (System > System Configuration > System.datafeed.pollRate). The default polling rate is 300 seconds (5 minutes).
The Content Distribution Manager GUI also allows you to view statistics for Content Engines, device groups, and Content Routers in tabular form based on the type of server. (See the next three sections.)
Viewing Content Engine Statistics
To view Content Engine statistics in tabular form, follow these steps:
Step 1
Step 2
•
•
•
•
Table 18-5 explains the meaning of each Content Engine statistic presented in the GUI.
Step 3
Viewing Device Group Statistics
To view device group statistics for your ACNS network, follow these steps:
Step 1
Step 2
•
•
•
•
Statistics for device groups are the same as for Content Engines. See Table 18-5 for an explanation of the meaning of each device group statistic presented in the GUI.
Step 3
Viewing Routing Statistics
To view routing statistics for Content Routers and routing Content Engines, follow these steps:
Step 1
Step 2
•
•
Table 18-6 explains the meaning of each Content Router statistic presented in the GUI.
Step 3
You can also view additional content routing statistics through the Content Distribution Manager GUI using the show command tool (see the "Using the Content Distribution Manager GUI show Command Tool" section). The show commands are further documented in the Cisco ACNS Software Command Reference, Release 5.2 publication.
Configuring Report Options
The Content Distribution manager GUI provides four different monitoring reports. Report data is available in both tabular and graphical form.
Bytes Served Report
The Bytes Served report allows you to view Content Engine usage over time, and to identify usage trends. To view the Bytes Served report and configure the reporting options, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Bandwidth Efficiency Gain Report
After a Content Engine has been in use for some time and has collected statistics, the bandwidth efficiency gain report can demonstrate the value of the Content Engine in terms of bandwidth savings.
To view the Bandwidth Efficiency Gain report and configure the reporting options, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Streaming Sessions Report
The Streaming Sessions report lists the total number of streaming sessions in progress at the collection time. It allows you to plan for future hardware provisioning and licensing requirements based on utilization data.
To view the Streaming Sessions report and configure the reporting options, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
CPU Utilization Report
To view the CPU Utilization report and configure the reporting options, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Monitoring Content Replication Status
The replication status feature allows you to view the status of content replication using the Content Distribution Manager GUI, output from CLI commands, or an API file.
In the Content Distribution Manager GUI, replication status is provided under the Content tab and the Devices tab. You can view the replication status by channel or by device. The Content Distribution Manager GUI also allows you to obtain a detailed view for a specific Content Engine or channel. You can also view detailed replication status for a particular content item in a channel.
Under the Content tab, you can obtain the following views:
•
•
•
•
•
Under the Devices tab, you can obtain the following views:
•
•
•
Note
Viewing the System-Wide Replication Status by Channel
The Channels window lists all channels on the system and displays the replication status information for each channel. This display summarizes the replication status of all Content Engines associated with a specific channel in a given state.
To view system-wide replication status for each channel, follow these steps:
Step 1
Figure 18-7 Channels Window—System-Wide Replication Status by Channel
Step 2
Table 18-7 System-Wide Replication Status by Channel—Channels Window
Channel
Name of the channel.
Type
Type of channel. The channel types are Live and Content.
Website
Name of the website assigned to the channel.
Status
Graphical display indicating acquisition, replication, and device errors. Status lights represent the highest level of errors encountered:
Green—No errors encountered
Yellow—Only minor errors encountered
Red—At least one critical error encountered, such as an acquisition failure, a content replication failure, or a failed or nonresponding Content Engine
For details of the errors, click the status light for a particular channel, which takes you to the Replication Status for Channel window. See Table 18-8 for a description of status errors and their corresponding status lights.
State
State of the channel. States are reported for the root Content Engine and for receiver Content Engines. See Table 18-9 for a definition of the different channel states.
The state is also a link to the Replication Status for Channel window that provides a more detailed view of the replication status for the channel. (See Figure 18-9.)
Manifest State
State of the manifest file. States reported are as follows:
Fetching—The manifest file is being fetched.
Fail Fetching—The manifest file has failed to be fetched.
Parsing—The manifest file is being parsed.
Fail Parsing—The manifest file has failed to be parsed.
Completed—The manifest file was successfully fetched and parsed.
No Status Reported—Root Content Engine is in a Pending or Disabled state.
Table 18-9 Channel States in Replication Status for Channel Window
Completed
All receiver Content Engines are in the Completed state, and the root Content Engine is either in the Completed, Re-checking, Retrieving Manifest, or Processing Manifest state. (See Table 18-12 for a description of Content Engine states.)
When the root Content Engine in the Re-checking state determines that new content needs to be acquired, the channel state changes to In Process.
In Process
In Process can mean:
•
•
•
Failed
Failed can mean:
•
•
•
•
Viewing the Replication Status for a Specific Channel
To view the replication status for a particular channel, follow these steps:
Step 1
Figure 18-8 Channels Window
Step 2
Table 18-10 describes the acquisition status information that is displayed in this window, and Table 18-11 describes the replication status information for individual devices that is displayed in this window.
Note
Figure 18-9 Replication Status for Channel Window
This window also allows you to do the following:
•
•
Table 18-10 Acquisition Status for a Channel
User Selected Root CE
Name of the user-selected root Content Engine.
Current Root CE
Name of the current root Content Engine. The current root Content Engine will be the same as the user-selected root Content Engine as long as the user-selected root is active; if it fails for any reason, the temporary root Content Engine becomes the current root Content Engine.
Disk Quota Used
Amount of available disk space used for the channel.
Status
State of the root Content Engine. For a description of root Content Engine states, see Table 18-12.
Manifest Last Modified Time
Time when the manifest file was last saved, as recorded on the Content Engine.
Manifest Last Checked Time
Time when the root Content Engine last checked the manifest file for changes.
Table 18-11 Replication Status for Devices Assigned to a Channel
Device
Name of the Content Engine assigned to the channel.
Type
Type of Content Engine: root, receiver, or temporary root.
Status
Graphical display indicating acquisition, replication, and device errors. Status lights represent the highest level of errors encountered:
Green—No errors encountered
Yellow—Only minor errors encountered
Red—At least one critical error encountered, such as an acquisition failure, a content replication failure, or a failed or nonresponding Content Engine
For details of the errors, click the status light. A dialog box pops up, listing the errors. See Table 18-8 for a description of status errors and their corresponding status lights.
State
State of either the root Content Engine or receiver Content Engines. See Table 18-12 for a description of Content Engine states.
Last Report Time
Time when the last report from the Content Engine was received by the Content Distribution Manager. This time stamp uses the Content Distribution Manager clock.
File Count
Completed
Number of files that the Content Engine has successfully acquired or received.
In Process
Number of new files to be acquired or replicated. Includes only files for which no acquisition or replication attempts have previously been made.
Failed
For the root Content Engine: Number of files that failed to be acquired in at least 1 attempt.
For receiver Content Engines: Number of files that failed to be replicated in at least 1 attempt.
Note
Total
Total number of Completed, In Process, and Failed files.
Viewing the Detailed Replication Status of Content Items for a Specific Channel
To view the detailed replication status of content items for a channel, follow these steps:
Step 1
Step 2
Step 3
Step 4
The criteria are matched against the relative cdn-url attribute specified in the <item> tag in the manifest file. It is recommended that you start the search criteria by specifying wildcards such as *.htm or *clip.mpeg.
Step 5
Figure 18-10 Replication Status for Content Items for a Specific Channel
Viewing the Detailed Replication Status of Content Items for a Channel by Device
Queries to determine the detailed replication status of a content item trigger extensive CPU cycles and high consumption of memory, because all the Content Engines assigned to a channel need to be polled, and the retrieved replication status is cached in the memory of the Content Distribution Manager. This results in performance degradation. To optimize the use of memory resources without compromising the need to obtain detailed replication status of a particular content item, you can choose a Content Engine assigned to a channel and generate a query.
To view the detailed replication status for a channel by device, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
a.
b.
c.
For example, enter Get replicated content items using Search Criteria *.bin for selected Device.
Note
The Replication Items window for the selected device appears. (See Figure 18-11.) Table 18-14 describes the fields displayed in this window.
Figure 18-11 Replication Items for a Selected Device
Note
Step 6
a.
b.
c.
Step 7
Viewing the Detailed Replication Status of Content Items Across All Content Engines in a Channel
You can choose the URL of the origin server and request a detailed replication status of content items across all Content Engines to trigger an aggregated replication status request. The detailed item replication status window shows a time stamp indicating the time in Greenwich mean time (GMT) at which the replication status was last cached to provide information about the freshness of the detailed content replication status.
To view the detailed replication status of an item across all Content Engines in a channel, follow these steps:
Step 1
Step 2
Step 3
Step 4
The criteria are matched against the relative cdn-url attribute specified in the <item> tag in the manifest file. We recommend that you start the search criteria by specifying wildcards such as *.htm or *clip.mpeg.
Step 5
Step 6
Figure 18-12 Replication Status of the Content Item for All Content Engines in the Channel
Note
Step 7
Viewing the System-Wide Replication Status by Content Engine
To view the system-wide replication status by device, follow these steps:
Step 1
This window summarizes the replication status of all channels associated with a specific Content Engine in a given state. (See Figure 18-13.)
Figure 18-13 Device Replication Status Window
Step 2
Table 18-16 Device Replication Status Window
Device
Name of the Content Engine.
Status
Graphical display indicating acquisition, replication, and device errors. Status lights represent the highest level of errors encountered:
Green—No errors encountered
Yellow—Only minor errors encountered
Red—At least one critical error encountered, such as an acquisition failure, a content replication failure, or a failed or nonresponding Content Engine
See Table 18-8 for a description of status errors and their corresponding status lights.
Channel Count
Number of channels reporting Content Engines in a particular state. (See Table 18-12 for a description of Content Engine states.)
Completed
Number of channels reporting this Content Engine in a Completed state.
In Process
In Process can mean:
•
•
Failed
Number of channels reporting this Content Engine in the Failed or Failed Update state.
Unknown
Number of channels reporting this Content Engine in the No Status Reported state.
Step 3
Viewing the Replication Status for a Specific Content Engine
To view the replication status for a particular Content Engine, follow these steps:
Step 1
Step 2
Step 3
The Replication Status for Device window displays the replication status of individual channels assigned to a particular Content Engine. You can filter the information by channels or by any of the other categories displayed in this window. (See Figure 18-14.)
Table 18-11 describes the status information that is displayed in this window with the exception that the first column in this window displays the names of the channels to which the Content Engine is assigned rather than the names of the devices in the channel, as described in Table 18-11.
Figure 18-14 Replication Status for Device Window
Step 4
Step 5
Viewing the Detailed Replication Status of Content Items for a Selected Channel by Content Engine
A request for a detailed replication status triggers an aggregated replication status update request. This ensures that the cache status is refreshed on both the Content Engine and the Content Distribution Manager simultaneously.
To view the status of replication of content items for a selected channel by Content Engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Note
Figure 18-15 Replication Items - Channel: Content Engine Window
Step 8
Step 9
Step 10
Step 11
Using CLI Commands for Replication Status
You can use the Content Engine CLI to view the content replication status for a channel by using the following commands:
•
ContentEngine# show distribution channel channel-id 158Channel ID: 158Channel Name: sz300Website Name: website3Channel Priority: 500ID of Configured Root CE: 140Name of Configured Root CE: sz590bIP of Configured Root CE: 10.1.1.170This CE's Role: Not a Root CEIn Full Reload: NoMcast Receiving: NoMcast Sending: NoMetadata-Forwarder ID: 140Metadata-Forwarder Name: sz590bMetadata-Forwarder IP: 10.1.1.170Ucast-Forwarder ID: 140Ucast-Forwarder Name: sz590bUcast-Forwarder IP: 10.1.1.170Last gen-id Switch: NeverID of Effective Root CE: 140Current root-ce-uid: 1042665163Current low-water-marker: 1Current max-gen-id: 300Current max-del-gen-id: 0Has Unfinished Job: No
Note
•
The following sample output is from the Content Distribution Manager show statistics replication command.
CDM# show statistics replication channels selected-channel ws1 ch1cChannel: ch1cState: CompletedStatus: GreenUser Selected Root CE: ce-s4Current Root CE: ce-s4Receiver CEs Completed: 1Receiver CEs In Progress: 0Receiver CEs Failed: 0Receiver CEs Not Responding: 0Displaying Device Acquisition Replication StatusDevice: ce-s4 (CE ID: 92)Channel: ch1c (Channel ID: 246)Website: ws1Type: RootState: CompletedStatus: GreenCompleted: 1To Do: 0Failed: 0Total: 1Last Report Time: Mon Apr 19 20:37:43 GMT 2004Disk Quota Used: 281.171 KBManifest Last Modified: Mon Sep 29 14:59:01 GMT 2003Manifest Last Check: Wed Apr 14 18:19:12 GMT 2004Manifest State: CompletedDisplaying Device Distribution Replication StatusDevice: CE2 (CE ID: 97)Channel: ch1c (Channel ID: 246)Website: ws1Type: ReceiverState: CompletedStatus: GreenCompleted: 1To Do: 0Failed: 0Total: 1Last Report Time: Mon Apr 19 20:32:16 GMT 2004Detailed Error for CE2The following sample output shows the replication status for the Content Engines of a selected channel.
CDM# show statistics replication content-engines selected-channel ws1 ch1cDisplaying Device Acquisition Replication StatusDevice: ce-s4 (CE ID: 92)Channel: ch1c (Channel ID: 246)Website: ws1Type: RootState: CompletedStatus: GreenCompleted: 1To Do: 0Failed: 0Total: 1Last Report Time: Mon Apr 19 20:42:38 GMT 2004Disk Quota Used: 281.171 KBManifest Last Modified: Mon Sep 29 14:59:01 GMT 2003Manifest Last Check: Wed Apr 14 18:19:12 GMT 2004Manifest State: CompletedDisplaying Device Distribution Replication StatusDevice: CE2 (CE ID: 97)Channel: ch1c (Channel ID: 246)Website: ws1Type: ReceiverState: CompletedStatus: GreenCompleted: 1To Do: 0Failed: 0Total: 1Last Report Time: Mon Apr 19 20:42:12 GMT 2004Detailed Error for CE2The following sample output is from the Content Engine show statistics replication command.
ContentEngine# show statistics replication channels selected-channel ws1 ch1cDisplaying Device Acquisition Replication StatusDevice: ce-s4 (CE ID: 92)Channel: 5001Item (Channel ID: 412)Website: ws1Type: RootState: Re-checking ContentStatus: GreenCompleted: 5001To Do: 0Failed: 0Total: 5001Last Report Time: Mon May 03 14:09:45 GMT 2004Disk Quota Used: 1.340 GBManifest Last Modified: Wed Dec 18 15:15:49 GMT 2002Manifest Last Check: Thu Apr 29 12:02:45 GMT 2004Manifest State: CompletedDisplaying Device Acquisition Replication StatusDevice: ce-s4 (CE ID: 92)Channel: syntaxError (Channel ID: 280)Website: ws1Type: RootState: Processing ManifestStatus: RedCompleted: 0To Do: 0Failed: 0Total: 0Last Report Time: Mon May 03 14:09:45 GMT 2004Disk Quota Used: 0 BytesManifest Last Modified: Thu Oct 03 11:00:19 GMT 2002Manifest Last Check: Mon May 03 14:08:13 GMT 2004Manifest Error: Syntax Error: Parser Error at (line 5, char 35): Datatype error: Type:InvalidDatatypeValueException, Message:The unary operation node had a binary node type.Manifest State: Fail Parsing Manifest7.3.4.2 Get selected channelCE#sh statistics replication channels selected-channel ws1 ch1cDisplaying Device Acquisition Replication StatusDevice: ce-s4 (CE ID: 92)Channel: ch1c (Channel ID: 246)Website: ws1Type: RootState: CompletedStatus: GreenCompleted: 1To Do: 0Failed: 0Total: 1Last Report Time: Mon May 03 14:08:50 GMT 2004Disk Quota Used: 281.171 KBManifest Last Modified: Mon Sep 29 14:59:01 GMT 2003Manifest Last Check: Wed Apr 14 18:19:12 GMT 2004Manifest State: CompletedUsing the System Message Log
Use the ACNS system logging feature to set specific parameters for the system log file (syslog). This file contains authentication entries, privilege level settings, and administrative details. System logging is always enabled. The system log file is located on the system file system (sysfs) partition as /local1/syslog.txt.
You can use either of the following methods to configure the Content Engine to send varying levels of event messages to disk, console, or host.
•
•
Configuring System Event Logging Using the Content Distribution Manager GUI
To enable system logging, follow these steps:
Step 1
Step 2
Step 3
Figure 18-16 Syslog Settings Window
Step 4
Step 5
Step 6
You can enable sending syslog files to the console, disk, or a host.
To enable syslog files to be sent to the console, follow these steps under Console Settings:
Step 1
Step 2
Step 3
To enable syslog files to be sent to disk, follow these steps under Disk Settings:
Step 1
Step 2
Step 3
Step 4
Whenever the current log file size surpasses the recycle size, the log file is rotated. (The default recycle size for the log file is 10,000,000 bytes.) The log file cycles through at most five rotations, and each rotation is saved as log_file_name.[1-5] under the same directory as the original log.
The rotated log file is configured in the File Name field (or using the logging disk filename command).
Step 5
To enable syslog files to be sent to a host, follow these steps under Host Settings:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
About Multiple Hosts for System Logging
Each syslog host can receive different priority levels of syslog messages. Therefore, you can configure different syslog hosts with a different syslog message priority code to enable the Content Engine to send varying levels of syslog messages to the four external syslog hosts. For example, the Content Engine can be configured to send messages that have a priority code of "error" (level 3) to the remote syslog host that has an IP address of 172.31.2.160 and messages that have a priority code of "warning" (level 4) to the remote syslog host that has an IP address of 172.31.2.161.
However, if you want to achieve syslog host redundancy or failover to a different syslog host, you must configure multiple syslog hosts on the Content Engine and assign the same priority code to each configured syslog host (for example, assigning a priority code of "critical" (level 2) to sylog host 1, sylog host 2, and syslog host 3).
In addition to configuring up to four logging hosts, you can also configure the following for multiple syslog hosts:
•
•
Configuring System Event Logging Using CLI Commands
Use the logging command to set specific parameters for the system log file (syslog). This file contains authentication entries, privilege level settings, and administrative details. System logging is always enabled. The system log file is located in the system file system (sysfs) storage area as /local1/syslog.txt.
Logging can be configured to send messages to the console, to disk, or to an external syslog host. See Table 18-18 for a list of the key system logging parameters, descriptions, and CLI commands.
Logging can be configured to send various levels of messages to disk, console, or host using the priority option of the logging command. Table 18-19 lists the different priority levels of detail to send to the recipient of the syslog messages for a corresponding event.
Viewing the System Message Log
Using the system message log feature of the Content Distribution Manager GUI, you can view information about events that have occurred in your ACNS network.
To view logged information for your ACNS network, follow these steps.
Note
Step 1
Figure 18-17 System Message Log (Showing All Messages)
Step 2
•
•
•
•
A table listing and describing each message is displayed.
Step 3
Note
Step 4
Note
Transaction Logging
Transaction logs allow administrators to view the traffic that has passed through the Content Engine. Typical fields in the transaction log are the date and time when a request was made, the URL that was requested, whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the source IP address.
Understanding Transaction Log Formats
In ACNS 5.x software, the user can choose among Squid, Extended Squid, Apache, or customized log formats for the transaction log.
Squid-Style Transaction Logging
The Squid-style log format is the default format for transaction logging in the Content Engine. The Squid log file format used is the native log file format associated with the Squid-1.1 access.log file format. For details on the Squid-1.1 native log file format, refer to the Squid documentation "Frequently Asked Questions," section 6.6, access.log heading at the following URL:
http://www.squid-cache.org/doc/FAQ/FAQ.html
The Squid log file format is:
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type
A Squid log format example looks like this:
1012429341.115 100 172.16.100.152 TCP_REFRESH_MISS/304 1100 GET http://www.cisco.com/images/homepage/news.gif - DIRECT/www.cisco.com -
Extended Squid Log Format
The Extended Squid format logs the associated username for each record in the log file in addition to the fields logged by the Squid-style format, and is used for billing purposes. In this format the Rfc931 field associated with the Squid format is used to log the authorized user. This field always contains a "-" (dash) if no user information is available.
An Extended Squid-style log format example looks like this:
1012429341.115 100 172.16.100.152 TCP_MISS/302 184 GET http://www.cisco.com myloginname DIRECT/www.cisco.com
Apache-Style Transaction Logging
The Apache format is the Common Log File (CLF) format defined by the World Wide Web Consortium (W3C) working group. This format is compatible with many industry-standard log tools. For more information, see the W3C Common Log Format website at the following URL:
http://www.w3.org/Daemon/User/Config/Logging.html.
The Apache-style log file format is:
remotehost rfc931 authuser date request status bytes
An Apache-style log file format example looks like this:
172.16.100.152 - - [Wed Jan 30 15:26:26 2002] "GET/http://www.cisco.com/images/homepage/support.gif HTTP/1.0" 200 632
Custom Format Transaction Logging
The transaction-logs format custom command allows you to use a log format string to log additional fields that are not included in the predefined native Squid or Extended Squid formats, or the Apache CLF format. The log format string is a string which can contain the tokens listed in Table 18-20 and which mimics the Apache log format string. The log format string can contain literal characters that are copied into the log file. Double backslashes (\\) can be used to represent a literal backslash, and a backslash followed by a single quote (\') can be used to represent a literal single quote. A literal double quote cannot be represented as part of the log format string. The control characters \t and \n can be used to represent a tab and a new line character, respectively.
Table 18-20 lists the acceptable format tokens for the log format string. The "..." portion of the format tokens shown in this table represents an optional condition. This portion of the format token can be left blank, as in %a. If an optional condition is included in the format token and the condition is met, then what is shown in the Value column of Table 18-20 is included in the transaction log output. If an optional condition is included in the format token but the condition is not met, the resulting transaction log output is replaced with a hyphen (-). The form of the condition is a list of HTTP status codes, which may or may not be preceded by an exclamation point (!). The exclamation point is used to negate all of the status codes that follow it, meaning that the value associated with the format token is logged if none of the status codes listed after the ! match the HTTP status code of the request. If any of the status codes listed after the ! match the HTTP status code of the request, then a hyphen (-) is logged.
For example, "%400,501{User-Agent}i" logs the User-Agent header value on 400 errors and 501 errors (Bad Request, Not Implemented) only, whereas "%!200,304,302{Referer}i" logs the Referer header value on all requests that did not return a normal status.
The custom format currently supports the following request headers:
•
•
•
•
The output of each of the following Request, Referer, and User-Agent format tokens specified in the custom log format string is always enclosed in double quotation marks in the transaction log entry:
%r
%{Referer}i
%{User-Agent}i
The %{Cookie}i format token is generated without the surrounding double quotation marks, because the Cookie value itself can contain double quotes. The Cookie value can contain multiple attribute-value pairs that are separated by spaces. For this reason, it is recommended that when the Cookie format token is used in a custom format string, it be positioned as the last field in the format string. This positioning of the Cookie format token allows it to be more easily parsed by transaction log reporting tools. Alternatively, if you use the format token string "\'%{Cookie}i\'", the Cookie header can be surrounded by single quotes.
The following command can be entered to generate the well-known Apache Combined Log Format:
transaction-logs format custom "[%{%d}t/%{%b}t/%{%Y}t:%{%H}t:%{%M}t:%{%S}t %{%z}t] %r %s %b %{Referer}i %{User-Agent}i"
The following transaction log entry example in the Apache Combined Format is configured using the preceding custom format string:
[11/Jan/2003:02:12:44 -0800] "GET http://www.cisco.com/swa/i/site_tour_link.gif HTTP/1.1" 200 3436 "http://www.cisco.com/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
Table 18-20 Custom Format Log Format String Values
%...a
IP address of the requesting client.
%...A
IP address of the Content Engine.
%...B
%...bBytes sent, excluding HTTP headers.
%...c
Connection status when response is completed, where:
X = Connection was aborted before the response was completed.
+ = Connection can be kept alive after the response is sent.
- = Connection is closed after the response is sent.%...f
Filename.
%...h
Remote host (IP address of the requesting client is logged).
%...H
Request protocol.
%...{Foobar}i
Contents of Foobar: header lines in the request that is sent to the server. The value of Foobar can be one of the following headers: User-Agent, Referer, Host, or Cookie.
%...l
Remote log name. Not implemented on the Content Engine, so a hyphen (-) is logged.
%...m
Request method.
%...p
Canonical port of the server servicing the request. Not applicable on the Content Engine, so a hyphen (-) is logged.
%...P
Process ID of the child that serviced the request.
%...q
Query string (which is preceded by a ? if a query string exists; otherwise, it is an empty string).
%...r
First line of the request.
%...s
Status. The translog code always returns the HTTP response code for the request.
%...t
Time in common log time format (or standard English format).
%...{format}t
Time in the form given by the format token specified in Table 18-21.
%...T
Time consumed to serve the request in seconds (a floating point number with 3 decimal places).
%...u
Remote user.
%...U
URL path requested, not including query strings.
%...v
%...VValue of the host request header field reported if the host appeared in the request. If the host did not appear in the host request header, the IP address of the server specified in the URL is reported.
Table 18-21 specifies the format token for the date and time of the format token %...{format}t listed in Table 18-20.
Transaction Logging and NTLM Authentication
If your device is configured for NT LAN Manager (NTLM) authentication and uses Apache-style or Extended Squid-style format, you can record the Windows domain name and username in the "authenticated username" field of the transaction log. If the domain name is available, both the domain name and the username are recorded in the "authenticated username" field, in the form domain\username. If only the username is available, only the username is recorded in the "authenticated username" field. If neither a domain name nor a username is available, a "-" (hyphen) is recorded in the field.
Usage Guidelines for Log Files
This section provides some guidelines for working with log files.
Understanding Working Logs
Depending upon where the sysfs is mounted, transactions are logged to a working log on the local disk in one of these files:
•
•
Depending upon where the sysfs is mounted, the following log files are logged to a working log on the local disk as follows:
•
–
–
•
–
–
•
–
–
•
–
–
Archive Working Log
You can specify the interval at which the working log should be cleared by moving the data to an archive log. The archive log files are located on the local disk in the directory /local1/logs/ or /local2/logs/, depending upon where the sysfs is mounted.
Because multiple archive files are saved, the filename includes the time stamp when the file was archived. Because the files can be exported to an FTP/SFTP server, the filename also contains the IP address of this Content Engine.
The archive file name format is:
celog_IPADDRESS_YYYYMMDD_HHMMSS.txt.
Sanitizing Transaction Logs
You can disguise the IP address and usernames of clients in the transaction log file. The default is that transaction logs are not sanitized. A sanitized transaction log disguises the network identity of a client by changing the IP address in the transaction logs to 0.0.0.0.
Exporting Log Files
In order to facilitate the postprocessing of cache log files, it is possible to export transaction logs to an external host. This feature allows log files to be automatically exported by FTP to an external host at configurable intervals. The username and password used for FTP are configurable, as is the directory to which the log files are uploaded.
The log files automatically have a filename of:
<type>_<ipaddr>_yyyymmdd_hhmmss.txt
where
•
•
•
Note
Exporting Transaction Logs to External FTP Servers
To export transaction logs to an FTP server, you must first enable exporting of transaction logs and then configure the FTP or secure FTP (SFTP) server parameters. This feature can support up to four FTP servers. The following information is required for each target FTP server:
•
The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.
•
•
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
You can also compress archived log files into gzip format before exporting them to external FTP servers. The compressed filename has a .gz extension in the filename. This compression feature uses less disk space than that required for noncompressed archived files on both the Content Engine and the FTP export server and also requires less bandwidth during export because of the smaller size of the files to be exported.
Restarting Export After Receiving a Permanent Error from the External FTP Server
When an FTP server returns a permanent error to the Content Engine, the archive transaction logs are no longer exported to that server. You must reenter the Content Engine transaction log export parameters for the misconfigured server to clear the error condition.
A permanent error (Permanent Negative Completion Reply, RFC 959) occurs when the FTP command to the server cannot be accepted, and the action does not take place. Permanent errors can be caused by invalid user logins, invalid user passwords, and attempts to access directories with insufficient permissions or directories that do not exist.
Exporting Transaction Logs to External SFTP Servers
You can also export transaction logs to an SFTP server. You must first enable the feature and configure the SFTP server parameters. The following information is required for each target SFTP server:
•
The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.
•
•
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
Enabling Transaction Logging with the Content Distribution Manager GUI
To enable transaction logging, follow these steps:
Step 1
Step 2
From the Contents pane, choose General Settings > Notification and Tracking > Transaction Logs. The Transaction Logs settings window appears. (See Figure 18-18.) Table 18-22 describes the fields in this window and provides the corresponding CLI global configuration commands.
Figure 18-18 Transaction Log Settings Window—General Settings
Step 3
Step 4
Step 5
Step 6
Note
Step 7
Step 8
Alternatively, click the Log Format Custom radio button if you want to use a custom format for the transaction log. Then enter a custom format string in the field provided. (See the "Custom Format Transaction Logging" section.)
Step 9
This is the value of the maximum size of the archived file to be maintained on the local disk.
Figure 18-19 Transaction Log Settings Window—Archive Settings
Step 10
Step 11
If you want to enable exporting to an FTP server, follow these steps:
Step 1
Step 2
Step 3
Step 4
Figure 18-20 Transaction Log Settings Window—Export Settings
Step 5
Step 6
Note
Step 7
Step 8
Step 9
Note
Step 10
Step 11
Using WMT Transaction Logging
For certain companies, streaming media is a source of revenue and therefore needs to be tracked closely. Because these companies charge their customers to stream on-demand content and live broadcasts, they must rely on logged information to track what content a particular customer viewed, how long they viewed it, and what their viewing quality was. Consequently, the accuracy and reliability of transaction logging is very important to these companies.
The Windows Media Services 9 Series provides a more robust logging model than Windows Media Services Version 4.1. ACNS 5.2 software supports Windows Media Services 9 logging.
Note
In ACNS 5.2 software, the following logging formats are supported for WMT transaction logging:
•
•
•
•
The extended versions of the logging formats contain additional fields that are Content-Engine specific (for example, the CE-action field specifies a cache hit or miss, and the CE-bytes field specifies the number of bytes that were sent from the Content Engine).
The Content Engine's transaction logging format for WMT streaming is consistent with that of the Windows Media Services and the World Wide Web Consortium (W3C)-compliant log format. A log line is written for every stream accessed by the client. The location of the log is not configurable. These logs can be exported using FTP. When transaction logging is enabled, daemons create a separate working.log file in /local1/logs/export for WMT transactions.
All client information in the transaction logs is sent to the origin server by default.
Log Formats Accepted by Windows Media Services 9
Windows Media Players connect to a Windows Media server using the following protocols:
•
•
Depending on the version of the Windows Media Player, logs are sent in different formats, such as text, binary, or Extensible Markup Language (XML). Table 18-24 describes the log formats accepted by Windows Media Services 9.
Note
Configuring WMT Transaction Logging
To configure WMT transaction logging, follow these steps:
Step 1
a.
b.
c.
Step 2
Figure 18-21 Transaction Log Settings Window—WMT and Logging Settings
Step 3
To configure WMT transaction logging from the CLI, use the following global configuration command:
wmt transaction-logs format {extended {wms-41 | wms-90} | wms-41 | wms-90}
Using Real-Time Transaction Logging
You can monitor transaction logs in real-time for particular errors such as authentication errors. By sending HTTP transaction log messages to a remote syslog server, you can monitor the remote syslog server for HTTP request authentication failures in real-time. This real-time transaction log feature allows you to monitor transaction logs in real-time for particular errors such as HTTP request authentication errors. The existing transaction logging to the local file system remains unchanged.
For this purpose, you must configure the Content Engine to send transaction log messages to a remote syslog server using UDP as the transport protocol. Because UDP is an unreliable transport protocol, message transport to remote syslog host is not reliable and you must monitor the syslog messages received at the remote syslog server. You can limit the rate at which the transaction logging module is allowed to send messages to the remote syslog server. The format of the syslog message is in standard syslog message format with the transaction log message as the payload of the syslog message.
Real-time transaction logging to a remote syslog server uses the standard syslog message format with the message payload as the transaction log entry. A new syslog error identifier is defined for this type of real-time transaction log message. You can configure the Content Engine to send transaction log messages in real-time to one remote syslog host. The message format of the transaction log entry to the remote syslog host is the same as in the transaction log file and prepended with Cisco's standard syslog header information.
The following is an example of the format of the real-time syslog message sent from the transaction logging module (Content Engine) to the remote syslog host:
fac-pri Apr 22 20:10:46 ce-host cache: %CE-TRNSLG-6-460012: translog formatted msg
The fields in the message are described as follows:
•
The facility parameter used by the transaction logging module when a real-time transaction log message is logged to the remote syslog host is "user". The same facility is sent to the remote syslog host unless you configure a different facility parameter for transaction logging. The priority field is always set to LOG_INFO for real-time transaction log messages.
In the above example, the default value of fac-pri is 14 (0x000E) where facility = user (LOG_USER (1)) and priority = LOG_INFO (6).
•
•
•
•
Note
•
Note
To include the username and domain name in the transaction log, check the Log Windows Domain check box or use the transaction-logs log-windows-domain global configuration command.When the remote syslog server logs this message to a file, the format appears as follows:
Apr 22 20:10:46 ce-host cache: %CE-TRNSLG-6-460012: translog formatted msg
where ce-host is the host name of the Content Engine that sent the real-time transaction log message to the remote syslog server.
The configuration of host settings for transaction logs is identical to the configuration settings for syslog messages except that you need not specify the priority level of the message for real time transaction logs. All messages are associated with the priority level of 6 (LOG_INFO). Therefore, it is not required to filter messages based on priority levels.
Configuring Real-Time Transaction Logging
To configure real-time transaction logging, follow these steps:
Step 1
a.
b.
c.
Step 2
Note
Step 3
This drop-down list is set to an initial value of Do not set. This denotes that the facility sent to the syslog host will be the facility on the local host that is sending the syslog message, which in the case of the transaction logging module that sends the real-time transaction log message is the "user" facility.
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
About Specifying the Transaction Log Entry Type when Logging to a Remote Syslog Host
You can configure the Content Engine to send only the transactions associated with HTTP request authentication failures, or to send all of the transactions.
Typically, organizations are interested in only HTTP request authentication failures for security purposes. By monitoring these types of authentication failures in real time, it enables organizations to identify which end users failed to be authenticated through the Content Engine.
Note that only the authentication failure transaction that is associated with an end user who is attempting to contact the authentication server is logged. The "pending" transactions that are waiting for a response from the transaction that contacted the authentication servers are not logged. This approach provides you with the information needed to determine which user fails to authenticate with the Content Engine and minimizes the traffic to the syslog host. In order for you to track which users failed to authenticate, you must configure a transaction log format that logs the username by configuring either Extended Squid-style format or the custom log format with the custom format token %u . For more information about specifying the format of the transaction log, see the "Understanding Transaction Log Formats" section and the "Custom Format Transaction Logging" section.
When you check the Enable check box to enable real-time transaction logging (or specify the transaction-logs logging enable global configuration command), the logging of only HTTP request authentication failures is the default. If you want to change this default and log all transactions, then you must choose all from the Entry Type drop-down list (or enter the transaction-log logging entry-type all global configuration command on the Content Engine). However, if you log all transactions, there may be a significant UDP drop rate if your syslog host cannot handle the rate of incoming traffic.
Monitoring with SNMP
ACNS 5.x software supports Simple Network Management Protocol (SNMP), which is an interoperable standards-based protocol that allows external monitoring of the Content Engine through an SNMP agent. ACNS 5.x software supports the following versions of SNMP:
•
•
•
SNMPv1 and SNMPv2c do not have any security (that is, authentication or privacy) mechanisms to keep SNMP packet traffic on the wire confidential. As a result, packets on the wire can be detected and SNMP community strings compromised.
To solve the security shortcomings of SNMPv1 and SNMPv2c, SNMPv3 provides secure access to Content Engines by authenticating and encrypting packets over the network. In ACNS 5.x software, SNMPv3 features are added to the SNMP agent in addition to SNMPv1 and SNMPv2c features.
Note
Each Cisco device running ACNS 5.x software contains the software necessary to communicate information about device configuration and activity using the SNMP protocol. Before you can begin logging SNMP data, you must acquire and deploy an SNMP manager application for use with the ACNS network.
This section contains the following Content Distribution Manager GUI procedures for configuring SNMP traps, recipients, community strings and group associations, user security model groups, and user access permissions:
•
•
•
•
•
•
•
Configuring SNMP General Settings
To enable the Content Engine to send SNMP traps, follow these steps:
Step 1
Step 2
Step 3
Figure 18-22 SNMP General Settings Window
Step 4
Step 5
A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.
Configuring SNMP Community Settings
Note
To enable the SNMP agent and configure a community string to permit access to the SNMP agent, follow these steps:
Step 1
Step 2
Step 3
Step 4
Table 18-27 SNMP Community Settings
Community*1
Community string used as a password for authentication when you access the SNMP agent of the Content Engine. The "Community Name" field of any SNMP message sent to the Content Engine must match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent. You can enter a maximum of 256 characters in this field.
Groupname/rw*
Group to which the community string belongs. The rw option allows a read or write group to be associated with this community string. The rw option permits access to only a portion of the MIB subtree. Choose one of the following three options from the drop-down list:
•
•
•
Group Name*
Name of the group to which the community string belongs. You can enter a maximum of 256 characters in this field. This field is available only if you have chosen the group option in the previous field.
1 * = Required field.
Step 5
Step 6
To enable the SNMP agent and configure a community string from the CLI, use the following global configuration command:
snmp-server community string [group groupname | rw]
Configuring SNMP Group Settings
Note
To define a user security model group, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
To define a user security model group from the CLI, use the following global configuration command:
snmp-server group name {v1 [notify name] [read name] [write name] | v2c [notify name] [read name] [write name] | v3 {auth [notify name] [read name] [write name] | noauth [notify name] [read name] [write name] | priv [notify name] [read name] [write name]}}
Configuring SNMP User Settings
Note
To define a user who can access the SNMP engine, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
To define a user who can access the SNMP engine from the CLI, use the following global configuration command:
snmp-server user name group [auth {md5 password [priv password] | sha password [priv password]} | remote octetstring [auth {md5 password [priv password] | sha password [priv password]}]]
Configuring SNMPv2 View Settings
Note
To define a Version 2 SNMP (SNMPv2) MIB view, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Configuring SNMP Host Settings
Note
To configure SNMP host settings, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Configuring SNMP Asset Tag Settings
To configure SNMP asset tag settings, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
To configure SNMP asset tag settings from the CLI, use the asset tag global configuration command.
Supported MIBs
The SNMP agent supports the following MIBs:
•
•
•
•
•
•
•
•
The EVENT-MIB can set the threshold on any MIB variables supported by ACNS 5.x software and store the threshold permanently on disk. The HOST-RESOURCES-MIB provides statistics on system resources.
The CISCO-CONTENT-ENGINE-MIB is extended to incorporate MIB objects related to streaming. The WMT, Cisco Streaming Engine, and RealProxy MIB groups incorporate statistics about the WMT server or proxy, Cisco Streaming Engine, and Real Proxy. For each 64-bit counter MIB object, a 32-bit counter MIB object is implemented so that SNMP clients using the SNMPv1 protocol can retrieve data associated with 64-bit counter MIB objects. The MIB objects of each of these groups are read-only.
•
•
•
Use the following link to access these MIBs:
ftp://ftp.cisco.com/pub/mibs/v2/
Key SNMP CLI Commands
Use the snmp-server group global configuration command to select one of the three SNMP versions, SNMPv1, SNMPv2c, or SNMPv3. Use the no form of this command to remove the specified version. Refer to the Cisco ACNS Software Command Reference, Release 5.2 for more information on how to use this and other SNMP commands.
The snmp-server community string command provides view-based access control for SNMPv1, SNMPv2c, and SNMPv3 but also continues to provide backward compatibility between different versions. The previous version of this command did not have an option to create a community string that allows SNMP messages to execute a set operation on a MIB object. An rw option has been introduced for this purpose. Also, the previous version of the SNMP agent did not provide selective access control to MIB objects. Access to any MIB object was denied or granted based on authentication of the SNMP community string. With the introduction of view-based access control, it is now possible to configure a community string that grants access to only part of the MIB subtree. To provide backward compatibility with the previous version of this command, a default read group or default write group (if the rw option is specified on the command line) is associated with the community string if no group name is specified. Both of these default groups are hidden from users and not displayed in the configuration file or in the show snmp group command, but are created during initialization of the SNMP agent.
Note
The following example enables the SNMP agent and assigns the community string comaccess to SNMP:
507-1(config)# snmp-server community comaccessThe preceding example defines a community string comaccess used as a password for authentication when you access the SNMP agent of the Content Engine. Any SNMP message sent to the Content Engine must have the "Community Name" field of the message match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent.
The following example disables the SNMP agent and removes the previously defined community string.
507-1(config)# no snmp-server communityConfiguring SNMP Traps Using the CLI
To enable the Content Engine to send SNMP traps, use the snmp-server enable traps global configuration command. If you do not enter the snmp-server enable traps command, no traps are sent. Use the no form of this command to disable all SNMP traps or only SNMP authentication traps.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which hosts or hosts receive SNMP traps. To send traps, you must configure at least one host.
For a host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be used.
In addition, SNMP must be enabled with the snmp-server community command.
To disable the sending of the MIB-II SNMP authentication trap, you must enter the command no snmp-server enable traps snmp authentication.
The following example enables the Content Engine to send all traps to the host 172.31.2.160 using the community string public:
ContentEngine(config)# snmp-server enable trapsContentEngine(config)# snmp-server host 172.31.2.160 publicThe following example disables all traps:
Content Engine (config)# no snmp-server enable traps
