-
CSS Administration Guide (Software Version 7.10)
-
Index
-
About This Guide
-
Logging In and Getting Started
-
Configuring Interfaces and Circuits
-
Configuring CSS Network Protocols
-
Configuring OSPF
-
Using the CSS Logging Features
-
Configuring User Profiles and CSS Parameters
-
Configuring Simple Network Management Protocol (SNMP)
-
Configuring Remote Monitoring (RMON)
-
Upgrading Your CSS Software
-
Using the Offline Diagnostic Monitor Menu
-
Table Of Contents
Using the CSS Logging Features
Specifying Logging Buffer Size
Specifying Log File Destination
Specifying a Log File on the Disk
Disabling Logging to the sys.log File on Disk
Specifying Host for a Log File Destination
Specifying a Line for a Log File Destination
Enabling Logging on a Subsystem
Disabling Logging for a Subsystem
Configuring a Log Message for a Subsystem at a Logging Level
Sending Log Messages to an Email Address
Copying Log Files to an FTP or TFTP Server
Copying Log Files to an FTP Server
Copying Log Files to a TFTP Server
Interpreting sys.log Log Messages
Frequently Queried Log Messages
Using the CSS Logging Features
This chapter describes how to enable logging, set up the log buffer, determine where to send the activity information, and display and interpret log messages. Information in this chapter applies to all CSS models, except where noted.
This chapter contains the following sections:
•
Specifying Logging Buffer Size
•
•
•
•
•
Logging Overview
The CSS generates log messages to assist you in debugging and monitoring it. By default, the CSS saves boot and subsystem event log messages to log files on its hard or flash disk. The content of these files is recorded in ASCII text. You can also configure the CSS to send log messages to an active CSS session, e-mail address, or another host system.
Note
The boot log messages are the result of the boot process. The CSS saves these messages in the boot.log file.
The subsystem log messages are subsystem events that occur during the operation of the CSS. The CSS saves these messages in the sys.log file. The CSS creates this file when the first loggable subsystem event occurs. The CSS determines which subsystem messages to log by its configured logging level. By default, the CSS logs events on all subsystems with a level of warning. The warning level designates that the CSS logs fatal, alert, critical, error, and warning messages for the subsystem.
You have the option to log subsystem messages at a different level than the default warning level. The level you specify instructs the CSS to log subsystem activity that occurs at that level and the activity greater than that level.
In addition to informational messages, the CSS also logs notice, warning, error, critical, alert, and fatal messages.
Note
The CSS provides logging capabilities for debugging and system monitoring by generating the log files described in Table 5-1.
Logging Quick Start Table
If you are familiar with the CSS logging functions, see Table 5-2 for the commands and command options required to configure and enable logging. For detailed information on the CSS logging functions, see the sections following Table 5-2.
Note
Specifying Logging Buffer Size
The logging buffer size is the amount of information the CSS buffers in memory before outputting the information to disk. The larger you configure the buffer size, the less frequently the CSS outputs the contents to disk. Specifying a buffer size is required only if you configure logging to disk.
To set the disk buffering size, use the logging buffer command. Specify the buffer size from 0 to 64,000 bytes. The default is 0, where the CSS sends the logging output directly to the log file.
To set the buffer size to 1000 bytes, enter:
(config)# logging buffer 1000To send the logging output directly to the log file, enter:
(config)# no logging bufferSpecifying Log File Destination
To specify a destination where the CSS logs subsystem activity, use the logging command. You can specify the following locations for log files:
•
•
•
For information on logging to these destinations, see the following sections.
Note
To prevent excessive writes to the CSS disk, consider disabling logging to the sys.log file on disk (see "Disabling Logging to the sys.log File on Disk"). If desired, you can continue sending CSS log information to the sys.log file at an alternate location. To do this, use either the logging host command to send log information to a syslog daemon on a host system (see "Specifying Host for a Log File Destination") or the logging line command to send (but not save) log information to an active CSS line (see "Specifying a Line for a Log File Destination").
Caution
Specifying a Log File on the Disk
To send log information to specific file on the CSS disk, use the logging disk command and specify a log filename. The filename can be new or existing. Enter a text string from 0 to 32 characters.
For example:
(config)# logging disk stubsWhen you enter this command, the CSS:
•
•
•
You can have only one active log file on the disk at a time. If you wish to send subsystem information to a different log file on the disk, reenter the logging disk command with a different filename.
Caution
To stop logging to the specified file and reenable logging to the sys.log file on the CSS, enter:
(config)# no logging diskDisabling Logging to the sys.log File on Disk
To disable logging to the sys.log file on the CSS disk (hard or flash), use the logging to-disk command. Disabling logging to the sys.log file is useful when you want to prevent excessive writes to the CSS disk (for example, to the flash disk) or to increase the performance of the CSS.
Note
The options for the logging to-disk command are:
•
Note
•
Note
To disable logging to the CSS sys.log file on the CSS disk (flash disk or hard disk), enter:
(config)# logging to-disk disableTo resume logging back to the CSS disk, enter:
(config)# logging to-disk enableSpecifying Host for a Log File Destination
To send log information to a syslog daemon on the host system, use the logging host command and specify:
•
•
•
0 (fatal-0), 1 (alert-1), 2 (critical-2), 3 (error-3), 4 (warning-4), 5 (notice-5), 6 (info-6), and 7 (debug-7) (default).
The logging host log-level number must be equal to or less than the log level you configure for the logging subsystem command (see the "Enabling Logging on a Subsystem" section). If the log-level is less than the logging subsystem level, the CSS only sends the message level specified in the log-level option. If the log-level is greater than the logging subsystem level, the CSS only sends the level of messages specified in the logging subsystem command.
The CSS continues to send log information to the sys.log file on the CSS disk (hard or flash) when the logging host command is entered. To disable logging to the sys.log file on the CSS disk, use the logging to-disk disable command.
For example:
(config)# logging host 192.168.11.1 facility 3 log-level 3To turn off logging to a host, enter:
(config)# no logging hostSpecifying a Line for a Log File Destination
To send log information to an active CSS session, use the logging line command and specify a valid log line on the CSS. Enter the line as a case-sensitive text string with a maximum of 32 characters.
Note
To display a list of active CSS lines, enter the logging line command as shown. The * denotes your current session.
(config)# logging line ?console Login Name: Location:local*vty1 Login Name: admin Location:10.0.3.35To send subsystem information to your monitor, enter:
(config)# logging line vty1To turn off logging, enter the no logging line command.
(config)# no logging line vty1Enabling Logging on a Subsystem
Use the logging subsystem command to select a CSS subsystem and determine which type of activity to log. The level you specify instructs the CSS to log subsystem activity that occurs at that level and the activity greater than that level. For example, if you wish to log info messages, the CSS also logs error, critical, alert, and fatal error levels.
The following example enables logging for the chassis subsystem with a critical-2 error level. The CSS logs all critical, alert, and fatal errors for the chassis.
(config)# logging subsystem chassis level critical-2Table 5-3 defines the CSS subsystems for which you can enable logging.
Table 5-4 defines the logging levels you can set for a CSS subsystem. The logging levels are listed in order of severity with a fatal error being the most severe and info being the least severe error.
Disabling Logging for a Subsystem
To reset logging for a subsystem to the default logging level (warning-4), enter the no version of the logging command. For example:
(config)# no logging subsystem redundancyConfiguring a Log Message for a Subsystem at a Logging Level
Use the cliLogMessage subsystem command to define a log message for a subsystem at a particular logging level. The syntax for this global configuration mode command is:
cliLogMessage subsystem name "message" level level
The variables are:
•
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
To see a list of subsystems, enter:
cliLogMessage subsystem ?•
–
–
–
–
–
–
–
–
Logging ACL Activity
When you configure the CSS to log ACL activity, it logs the event of the packet matching the clause and ACL. The CSS sends log information to the location you specified in the logging command.
Note
To configure logging for an ACL clause:
1.
(config)# acl 7(config-acl[7])#2.
•
(config-acl[7])# clause 1 deny udp any eq 3 destination any eq 3 log•
(config-acl[7])# clause 1 log enableTo disable ACL logging for a specific clause, enter:
(config-acl[7])#) clause 1 log disableTo globally disable logging for all ACL clauses, enter:
(config)# no logging subsystem aclSending Log Messages to an Email Address
To send the log activity of a subsystem to an email address, use the logging sendmail command. The syntax for this global configuration mode command is:
logging sendmail email_address ip_address level
The variables are:
•
•
•
•
To turn off logging to an email address, enter:
(config)# no logging sendmail email_addressLogging CLI Commands
When you want to keep track of all CLI commands entered from the CSS, you can log them to the sys.log file. To log the CLI commands:
1.
(config)# logging subsystem netman info-62.
(config)# logging commands enableTo disable logging CLI commands to the sys.log file, enter:
(config)# no logging commandsShowing Log Files
Use the show log command to display the contents in a log or trap log file. You need SuperUser privileges to use the show log command.
The options for this command are:
•
•
•
Note
Showing Log Activity
Use the show log command and its options to send the log activity to your current session, or to display the contents in a log or trap log file. You need SuperUser privileges to use the show log command. The syntax for the show log command is:
show log {log_filename {tail lines} {line-numbers}}
The options and variables for the show log command include:
•
show log ?•
•
•
–
–
–
–
–
–
All other SNMP traps generate level notice-5 messages.
Note
To send the log activity to your current session, enter:
# show logDisplaying Log events.Press any key to abort...APR 14 16:28:09 5/1 2398 NETMAN-7: HTTPC:HTTPC_Open:ERROR->connect <-1,0> <192.20.1.7> <80>APR 14 16:28:15 5/1 2399 NETMAN-7: HTTPC:HTTPC_Open:ERROR->connect <-1,0> <192.20.1.7> <80>APR 14 16:28:21 5/1 2400 NETMAN-7: HTTPC:HTTPC_Open:ERROR->connect <-1,0> <192.20.1.7> <80>APR 14 16:28:27 5/1 2401 NETMAN-7: HTTPC:HTTPC_Open:ERROR->connect <-1,0> <192.20.1.7> <80>To display information in a specific log file, enter the show log command with a valid log filename. For example:
# show log stubsSEP 22 09:59:18 5/1 918 NETMAN-7: SNMP:SET RSP (3803)SEP 22 09:59:53 5/1 919 NETMAN-7: SNMP:SET (3804)SEP 22 09:59:53 5/1 920 NETMAN-7: SNMP: 1apLogHostIpAddress.[1.2.3.4] VT_IPADDRESS <1.2.3.4>SEP 22 09:59:53 5/1 921 NETMAN-7: SNMP: 2apLogHostIpAddress.[1.2.3.4] VT_IPADDRESS <1.2.3.4>To view the content of the sys.log file, enter:
(config)# show log sys.logTo view the bottom and most recent portion of the file, use the tail option with the show log command. To view the most recent 500 lines in the sys.log file, enter:
(config)# show log sys.log tail 500Showing Log Lists
Use the show log-list command to display a list of all log files. For example:
(config)# show log-listShowing Log State
Use the show log-state command to display the state of logging for CSS facilities. For example:
(config)# show log-stateTable 5-5 describes the fields in the show log-state output.
Copying Log Files to an FTP or TFTP Server
To copy log files from the CSS to a File Transfer Protocol (FTP) or Trivial File Transfer Protocol (TFTP) server, use the copy log command. The copy log command is available at the SuperUser prompt.
The options for this command are:
•
•
To see a list of log files, enter the copy log ? command.
Copying Log Files to an FTP Server
To copy a log file to an FTP server, use the copy log ftp command. Before you copy a log file from the CSS to an FTP server, you must create an FTP record file containing the FTP server IP address, username, and password. For information on configuring an FTP record, refer to Chapter 1, Logging In and Getting Started.
The syntax is:
copy log logfilename ftp ftp_record filename
For example:
# copy log starlog ftp ftpserv1 starlogthursThe variables are:
•
•
•
Copying Log Files to a TFTP Server
To copy a log file to an TFTP server, use the copy log tftp command.
The syntax is:
copy log logfilename tftp IP address or hostname filename
The variables are:
•
•
•
Interpreting sys.log Log Messages
The following is an example of a sys.log message. This section uses this example to describe the parts of a log message.
FEB 16 14:01:13 5/1 2453 VLANMGR-7: Transmit sfm STP BPDU on bPort 1, egressLp 0x1f00 VlanLpSend() ret:0A log message consists of the following components:
•
•
•
•
•
Transmit sfm STP BPDU on bPort 1, egressLp 0x1f00 VlanLpSend() ret:0
Note
Frequently Queried Log Messages
Table 5-6 lists CSS log messages that users frequently query. This table includes information on the possible cause and corrective action, if required. The table lists messages alphabetically. The listed subsystem log messages are listed starting from the subsystem field.
Table 5-6 Log Messages
The disk device driver timed out waiting for a response from the disk drive during its initialization. The message typically means that the disk is absent from the SCM, but could mean that the disk itself is unresponsive.
Make sure that the disk is located in slot 0. If it is, try removing and reinstalling it, then reboot the CSS.
(11500 Series CSS Only)
The power supply lost AC power from the source. A CSS 11501 and CSS 11503 contains one power supply. The CSS 11506 contains up to three power supplies, but requires two functioning power supplies to guarantee service. If the following message appears before these messages, then you can assume that the problem is with the AC power source, not the power supply.
CHMGR: Cannot locate power supply: PSnumber.The PSnumber variable indicates which power supply cannot be found or has failed.
To determine whether the CSS 11500 series power supplies are working properly, both LEDs on the front of each power supply should be lit.
The CSS chassis is not able to find the power supply. A CSS 11501 and CSS 11503 contains one power supply. The CSS 11506 contains up to three power supplies but requires two functioning power supplies to guarantee service. The PSnumber variable indicates which power supply cannot be found or has failed. If you know that the power source is supplied to the chassis and correctly flowing to it, then the problem may be the power supply.
To determine whether the CSS 11500 series power supplies are working properly, both LEDs on the front of each power supply should be lit.
(11000 Series CSS Only)
The power supply lost AC power from the source. If the following message appears before these messages, then you can assume that the problem is with the AC power source, not the power supply.
CHM-1: CHMGR: Cannot locate power supply: PS2.To determine whether both power supplies are working properly, both green LEDs should be lit on the front of the active SCM in the CSS 11506.
The CSS chassis is not able to find the power supply. If you know that the power source is supplied to the chassis and correctly flowing to it, then the problem may be the power supply.
To determine whether both power supplies are working properly, both green LEDs should be lit on the front of the active SCM in the CSS 11506.
Cause codes indicate the status of interfaces within VLANs. The logical port cause and command codes are as follows:
Cause Code
CM_CIRCUIT_CREATED 1
CM_IP_REGISTER 2
CM_IP_NOT_REGISTER 3
CM_IP_MODIFIED 4
CM_LP_STATE_CHG 5
CM_CIRCUIT_REMOVED 6
CM_LP_ADDED 7
CM_LP_REMOVED 8
CM_LP_MODIFIED 9
CM_LP_FAILOVER 10
CM_CIRCUIT_DOWN 11This log message indicates that a port is added to the VLAN. This can occur when the association to a VLAN changes as the port goes up and down.
Use the show circuit command to list the VLANs. Check the status of the ports of the VLAN or determine whether the VLAN is active.
The number of domain names being sent by the peer exceeds the size of the CSS list. You can configure this parameter through the (config) dns-peer command. Cisco Systems recommends that you configure the receive and send slots with the same value. The default slot value is 255.
For a Layer 5 rule, the CSS is trying to establish a connection with the backend server. The CSS sent four SYNs to the backend server and did not get a response.
For the CSS to attempt to establish a connection with the backend server then on the front side, the CSS saw:
SYN->
<-SYN/ACK
ACK->
GET->Only after receipt of the GET, the CSS opens up the backend connection and the log message is generated.
When several of these messages occur, this may indicate a bad server. This could be from keepalives, or from regular TCP HTTP traffic. Make sure that the port 80 sockets are not full on the servers.
One of the ports received an exceeding number of invalid packets and overflowed the fastpath. The flow manager received a control message from the fastpath that was badly formatted. Either it is intermittent hardware and the fastpath is corrupting the packets, or the fastpath is getting streams of invalid packets and some are leaking up to the flow manager.
Use the show ether-errors command to display information for a port with many errors. Try disconnecting the port or changing ports and determine if the errors stop. Note that all code numbers have the same meaning.
A removed circuit is still configured to an ACL or another configuration parameter. Check the CSS configuration.
An mbuf is a data structure in BSD UNIX-based IP stacks (such as the VxWorks stack) that is used for buffering. This indicates that the CSS received a packet that was addressed to one of the CSSs IP addresses, and when attempting to send it up the VxWorks IP stack, it had no buffers left.
Note
If you receive this message, contact Cisco Systems customer support.
An ARP TX task is running on the SFM, receiving packets from the SFM, and transmitting them to the proper egress ports. This message includes the circuit number (2001 in this example). If the circuit number for this ARP was down or inactive while the ARP was still being queued in the SFM, the message would appear in the log. An action caused the circuit to be removed while data for that circuit was still in the buffer.
Determine if either all physical interfaces in a circuit VLAN are going up and down, or a configuration change occurred on the VLAN at the time of the message.
The IPV4 receive task received a packet and the IP version is displayed in the parenthesis (). The CSS discards anything that is not Ipv4 Version 4. In this example, it was version 0. If you see many of these messages, it could be a misconfigured device or a DoS attack.
This message occurs when the CSS is configured with HTTP keepalives (HEAD or GET) and the servers are transitioning between states. The service event (kalSvcEvent) values are:
•
•
•
Check the status of the server.
(11000 Series CSS Only)
EPIF 0 belongs to the first four ports on a FEM. This is usually a problem with the SFM not getting the code to the FEM or the FEM not reading the SFM properly.
In this case, there is a communications problem between the SFP 9/2 and the FEM.
JAN 5 00:31:43 arrowpoint1.com 9/2 385390 SYSSOFT-3: ONDM: Timeout downloading image to EPIF 0 from the switch.JAN 5 00:31:45 arrowpoint1.com 9/2 385407 SYSSOFT-3: ONDM: Timeout downloading image to EPIF 0 from the switch.The recommended course of action is to reseat the SFM in slot 9, and the FEM in slot 13 controlled by the SFM, and then power cycle the CSS.
An information message when the service has transitioned state. Check the status of the server based on the keepalive parameters.
A user on the CLI, either through the console or Telnet, entered a wrong command. A Telnet or console session displays this message stating that the command was incorrect.
The SNMP Enterprise login failure traps are enabled and a user entered an invalid username/password pair. For example, the user typed the wrong username and password three times.
The next hop IP address is no longer reachable. When you configure a static route, a internal service is created such that when the service is up, the static route is included in the routing table. If the service goes down, it is removed from the routing table.
Make sure that all of the routes in the routing table are up. The routes may have transitioned states.
The flow manager tries to reallocate a VC that was already established.
These messages occur when the port is coming up. They do not represent a problem. The messages are also most noticeable at the end of boot time if you connected through the console.
A user is trying to use SNMP to poll the CSS, but they have entered the wrong community string.
An invalid CLI command was entered. In this example, a user enter the dir command in debug mode, and gave an invalid directory. For example:
(debug)# dir d:A valid SNMP agent (community string matched) is trying to set an invalid object. The CSS does not know what it is.
This message is associated with line data moving through the stack after a line has been disconnected (Telnet application disconnect). It is at DEBUG level for developer information purposes only.
These error messages refer to the source group running out of portmappers. Increase the portmappers on the source group so that the message does not appear, and users or services do not see a performance or NATing problem.
This message occurs when a port goes up and down. Check the autonegotiation, which could be a mismatch, bad cable, or bad hardware.
The CSS could not find the image file to load on the disk. There is something wrong with the disk or the file was deleted from the directory.
Contact Cisco Systems customer support.
The "SYSSOFT-4 IMM Message not Deliverable" message appears in the log when a certain queue on the CSS becomes full, overutilized, or needs to state a problem.
All messages of this type look very similar except for the values in the CE, message type, and message queue id field. The easiest way to decipher the message is to look at the CE value.
To determine which message queue is full, take bits 8 to 20 from the CE field and match them to the following message:
OCT 31 21:04:41 7/1 1324 SYSSOFT-4: IMM message not deliverable, message queue full, ce = 0x30202600, message type = 0x370000, message queue id = 0x8229ec60In the CE field for this example, the number is 26.
CE=0xXXXX26XXThen look at the following IMM messages for a similar message.
All the other information is CSS-specific. This field is constant throughout all versions of CSS software.
The ARP transmits queue, which holds 128 entries, is full. These are ARPs that the CSS is generating at bootup or when you assume mastership; it would be all the gratuitous ARPing for the VIPs. When you see this message, that gratuitous ARP packet is lost. The packet will not be resent and the upstream device is not notified about the MAC change in the case of redundancy.
In CSS software, you can configure VIP ranges. With ranges, you could suddenly have thousands of VIPs and these messages would be seen all the time. The CSS automatically rate-limits the number of ARPs that can be sent. The CSS also rate-limits the number of gratuitous ARP requests so that the ARP transmit queue does not overflow.
Note
This IMM message queue error refers to the VLANMGR_SFM_TID task. This is the queue on the SFP that handles spanning tree events from the SCM. The queue holds 128 entries. Each time this message appears, a spanning-tree protocol (STP) age or state change event is being lost. Three types of packets come to this queue:
•
•
•
In a CSS running normally, these events are rare. We suggest you troubleshoot spanning tree.
Note
A queue is getting overrun. This type of log entry occurs when the CSS is receiving a high volume of extraneous traffic. Because the CSS acts as both a router and a bridge, it must examine each packet. This particular queue handles all non-specific and non-IP traffic, including spanning tree BPDU, non-IP bridgeable traffic, ICMP, ARP, UDP fragments, and packets with expired TTL. This should not have any impact on user TCP traffic, because TCP is sent to a different queue.
Under load, especially due to a high number of UDP fragments or different Denial of Service (DoS) attacks, this queue would fill up and the CSS might drop some packets.
If this error appears in the log occasionally, check the show dos command to make sure the site is not under attack. Also, check the network topology to make sure the routing is solid. If the log is filling rapidly with these errors, then a packet capture may be helpful in isolating the cause.
Contact Cisco Systems customer support.
Note
The ASYNC message task processing cannot deliver a message because the queue is full. At bootup time, you can ignore it.
If these are streaming into the log during normal operations, it would warrant more investigation.
Contact Cisco Systems customer support.
Note
The SFM_FW_MAP_PORT_MSG cannot be delivered because the message queue is full. The message is sent when an FTP/RealAudio Control PORT, 227 Entering Passive, O (backspace) command is received and causes the CSS to allocate a portmapper port to be used for the data channel that is about to open.
The port uses this notification message (SFM_FW_MAP_PORT_MSG) to inform all other SFMs to allocate the same portmapper resource. The portmapper resource can then be found and used when the data channel SYN comes in any SFM.
The possible cause of this error could be a large amount of FTP/RealAudio coming into the CSS. Increase the number of portmaps in the source group.
Note
The SFM_FW_UNMAP_PORT_MSG cannot be delivered because the message queue is full. This message is similar to the previous IMM message except in this case, the CSS is trying to inform all other SFMS to unmap the same portmapper resource. The possible cause of this error could be a large amount of FTP/RealAudio coming into the CSS.
Contact Cisco Systems customer support.
Note
This is the IPV4 Receive message queue on the SCM. The only traffic that reaches this queue is destined for one of the circuit addresses. This traffic includes keepalives, Telnet, SSH, FTP, CAPP, SNMP, XML and so forth.
This message indicates a large number of services with individual keepalives. At times, they can overwhelm this queue. A reconfiguration using global keepalives is needed.
It is possible that someone is attacking the site. This message is of concern and should be investigated. Contact Cisco Systems customer support.
Note
This IMM message queue error refers to the IPV4_ARP_TID. This is a 256-entry queue on the SCM that handles route changes, and MAC address events (moved, down, up).
They are also due to a large number of VIPs. Missing a few messages from this queue is not fatal. Contact Cisco Systems customer support.
Note
The task ID 0x39 from the CE field is CSD_SCM_TID. The message type of 0x390003 is a SCM_CNT_CREATE. Each time the SFM sees a new request for content, it sends a message to the SCM. This is for hotlist statistics and the show content command. The SFMs overwhelm the SCM with these messages causing the queues to fill up and then this message occurs.
Lower the logging level for syssoft to critical. Contact Cisco Systems customer support.
Note
The task ID 0x2c or 44 is the VLANMGR_SCM_TID. This message queue is on the SCM and receives the control STP BPDUs from the SFPs. The control message occurs when the port changes state appearing as if the port is being overrun with STP BPDUs. This might occur on a CSS 11800 in the core of a network. Because the queue is full, you would lose some BPDUs, which is probably not critical.
This message may occur during a link up/down when the bridging status changed. Contact Cisco Systems customer support.
Note
There is a bad block on the disk. Either reformat or replace the disk. Disk replacement is recommended.
An informational message, which does not require any further action.
An informational message that an ARP came in on a different port.
Where to Go Next
Chapter 6, Configuring User Profiles and CSS Parameters, provides information on how to configure user profiles and CSS parameters. This chapter also contains information on using the Content API and Command Scheduler features.
