Table of Contents

Understanding Fault Management
Displaying System Information Using Show Commands
Receiving Automatic Warning Messages
Receiving the Automatic Shutdown Message
Test Network Connectivity

Set Up the TCP Keepalive Packet Service
Test Connections with the Ping Command
Trace Packet Routes

Test Memory and Interfaces

Test Flash Memory
Test System Memory
Test Interfaces

Log System Error Messages

Enable Message Logging
Enable Message Logging for a Slave Card
Set the Error Message Display Device
Configure Synchronization of Logging Messages
Enable Timestamps on Log Messages
Define the Error Message Severity Level and Facilities
Define the UNIX System Logging Facility
Display Logging Information
Log Errors to a UNIX Syslog Daemon
Set the Syslog Source Address

Use Field Diagnostics
Troubleshooting Specific Line Cards
Store Line Card Crash Information
Specifying Core Dump Files
Enable Debug Operations
Enable Conditionally Triggered Debugging

Enable Protocol-Specific Debug Commands
Enable Conditional Debugging Commands

Display Messages for One Interface
Display Messages for Multiple Interfaces
Limit Messages Based on Conditions

Specify Multiple Conditions
Conditionally Triggered Debugging Configuration Examples

Troubleshooting the Router

This chapter describes basic tasks that you can perform to troubleshoot your router and network. For detailed troubleshooting procedures and a variety of scenarios, see the Internetwork Troubleshooting Guide. For complete details on all debug commands, see the Cisco IOS Debug Command Reference.

For a complete description of the troubleshooting commands in this chapter, refer to the "Troubleshooting Commands" chapter  in "Cisco IOS System Management Commands" part of the Cisco IOS Configuration Fundamentals Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference index or search online.

Understanding Fault Management

To manage network faults, you need to discover, isolate, and fix the problems. You can discover problems with the system's monitoring commands, isolate problems with the system's test commands, and resolve problems with other commands, including debug commands.

• Displaying System Information Using Show Commands

• Receiving Automatic Warning Messages

• Receiving the Automatic Shutdown Message

• Test Network Connectivity

• Test Memory and Interfaces

• Log System Error Messages

• Use Field Diagnostics

• Troubleshooting Specific Line Cards

• Store Line Card Crash Information

• Enable Debug Operations

• Enable Conditionally Triggered Debugging

In addition, some chapters in the Cisco IOS software configuration guides include fault management tasks in a monitoring and maintaining section.

Displaying System Information Using Show Commands

To provide information about system processes, the Cisco IOS software includes an extensive list of EXEC commands that begin with the word show, which, when executed, display detailed tables of system information. Following is a partial list of system management show commands. Use these commands in EXEC mode to display the information described:

Receiving Automatic Warning Messages

Some routers have an environmental monitor which monitors the physical condition of the router. If a measurement exceeds acceptable margins, a warning message is printed to the system console. The system software collects measurements once every 60 seconds, but warnings for a given test point are printed at most once every four hours. If the temperature measurements are out of specification more than the shutdown margin, the software shuts the router down but the fan will stay on. The router has to be manually turned off and on after such a shutdown. You can query the environmental monitor using the show environment command at any time to determine whether a measurement is out of tolerance. Refer to the System Error Messages publication for a description of environmental monitor warning messages.

Receiving the Automatic Shutdown Message

On routers with an environmental monitor, if the software detects that any of its temperature test points have exceeded maximum margins, it performs the following steps in this order:

1. Saves the last measured values from each of the six test points to internal nonvolatile memory.

2. Interrupts the system software and causes a shutdown message to be printed on the system console.

3. Shuts off the power supplies after a few milliseconds of delay.

The following is the message the system displays if temperatures exceed maximum margins, along with a message indicating the reason for the shutdown:

Router#
%ENVM-1-SHUTDOWN: Environmental Monitor initiated shutdown
%ENVM-2-TEMP: Inlet temperature has reached SHUTDOWN level at 64(C)
 

Refer to the hardware installation and maintenance publication for your router for more information about environmental specifications.

Test Network Connectivity

Use the commands in the following sections to test basic network connectivity:

• Set Up the TCP Keepalive Packet Service

• Test Connections with the Ping Command

• Trace Packet Routes

Set Up the TCP Keepalive Packet Service

The TCP keepalive capability allows a router to detect when the host with which it is communicating experiences a system failure, even if data stops being transmitted (in either direction). This is most useful on incoming connections. For example, if a host failure occurs while talking to a printer, the router might never notice, because the printer does not generate any traffic in the opposite direction. If keepalives are enabled, they are sent once every minute on otherwise idle connections. If five minutes pass and no keepalives are detected, the connection is closed. The connection is also closed if the host replies to a keepalive packet with a reset packet. This will happen if the host crashes and comes back up again.

To set up the TCP keepalive packet service, use the following command in global configuration mode:

Command	Purposes
service {tcp-keepalives-in | tcp-keepalives-out}	Generate TCP keepalive packets on idle network connections, either incoming connections initiated by a remote host, or outgoing connections initiated by a user.

Test Connections with the Ping Command

As an aid to diagnosing basic network connectivity, many network protocols support an echo protocol. The protocol involves sending a special datagram to the destination host, then waiting for a reply datagram from that host. Results from this echo protocol can help in evaluating the path-to-host reliability, delays over the path, and whether the host can be reached or is functioning.

Trace Packet Routes

To discover the routes that packets will actually take when traveling to their destinations, use the following command in either user or privileged EXEC mode:

Test Memory and Interfaces

You can test the status of the following items:

• Flash memory

• System memory

• Interfaces

Caution We do not recommend using these test commands; they are intended to aid manufacturing personnel in checking system functionality.

Test Flash Memory

To test the status of Flash memory, use the following command in privileged EXEC mode:

Command	Purposes
test flash	Test Flash memory on MCI and envm Flash EPROM interfaces.

Test System Memory

To test the status of system memory, use the following command in privileged EXEC mode:

Command	Purposes
test memory	Diagnose Multibus memory, including nonvolatile memory.

Test Interfaces

Caution  Do not use this test to diagnose problems with an operational server.

To test the status of the interfaces, use the following command on a nonoperational server in privileged EXEC mode:

Command	Purposes
test interfaces	Check network interfaces.

Log System Error Messages

By default, routers send the output from the debug EXEC command and system error messages to a logging process. The logging process controls the distribution of logging messages to the various destinations, such as the logging buffer, terminal lines, or a UNIX syslog server, depending on your configuration. The process also sends messages to the console. When the logging process is on, the messages are displayed on the console after the process that generated them has finished.

---

Note   The syslog format is compatible with 4.3 BSD UNIX.

---

When the logging process is disabled, messages are sent only to the console. The messages are sent as they are generated, so error and debug output will be interspersed with prompts or output from the command.

You can set the severity level of the messages to control the type of messages displayed for the console and each of the destinations. You can timestamp log messages or set the syslog source address to enhance real-time debugging and management.

Refer to the System Error Messages publication for information on possible error messages.

Enable Message Logging

Message logging is enabled by default. It must be enabled in order to send messages to any destination other than the console.

To disable message logging, use the no logging on command. Disabling the logging process can slow down the router because a process must wait until the messages are written to the console before continuing.

To reenable message logging after it has been disabled, use the following command in global configuration mode:

Command	Purposes
logging on	Enable message logging.

Enable Message Logging for a Slave Card

To enable slave Versatile Interface Processor (VIP) cards to log important messages to the console, use the following command in global configuration mode:

Command	Purposes
service slave-log	Enable slave message logging.

Set the Error Message Display Device

If message logging is enabled, you can send messages to specified locations, in addition to the console.

To specify the locations that receive messages, use one or more of the following commands in global configuration mode:

Command	Purposes
logging buffered [size]	Log messages to an internal buffer.
terminal monitor	Log messages to a nonconsole terminal.
logging host	Log messages to a UNIX syslog server host.

The logging buffered command copies logging messages to an internal buffer. The buffer is circular, so newer messages overwrite older messages after the buffer is full. To display the messages that are logged in the buffer, use the show logging EXEC command. The first message displayed is the oldest message in the buffer. To clear the current contents of the buffer, use the clear logging privileged EXEC command.

Configure Synchronization of Logging Messages

You can configure the system to synchronize unsolicited messages and debug command output with solicited device output and prompts for a specific line. You can identify the types of messages to be output asynchronously based on the level of severity. You can also determine the maximum number of buffers for storing asynchronous messages for the terminal after which messages are dropped.

Enable Timestamps on Log Messages

By default, log messages are not timestamped. You can enable timestamping of log messages by using the following command in global configuration mode:

Define the Error Message Severity Level and Facilities

You can limit messages displayed to the selected device by specifying the severity level of the error message. To do so, use one of the following commands in global configuration mode:

Command	Purposes
logging console level	Limit messages logged to the console.
logging monitor level	Limit messages logged to the terminal lines.
logging trap level	Limit messages logged to the syslog servers.

If you have enabled syslog messages traps to be sent to an SNMP network management station with the snmp-server enable trap command, you can also change the level of messages sent and stored in a history table on the router. You can also change the number of messages that get stored in the history table.

Messages are stored in the history table because SNMP traps are not guaranteed to reach their destination. By default, one message of the level warning and above (see Table 20) is stored in the history table even if syslog traps are not enabled.

To change the level and table size defaults, use the following commands in global configuration mode:

	Command	Purposes
Step 1	logging history level	Change the default level of syslog messages stored in the history file and sent to the SNMP server.
Step 2	logging history size number	Change the number of syslog messages that can be stored in the history table.

Note   Table 20 lists the level keywords and severity level. For SNMP usage, the severity level values use +1. For example, emergency equals 1 not 0 and critical equals 3 not 2.

The logging console command limits the logging messages displayed on the console terminal to messages with a level number at or below the specified severity level, which is specified by the level argument. Table 20 lists the error message level keywords and corresponding UNIX syslog definitions in order from the most severe level to the least severe level.

Table 20: Error Message Logging Keywords

Level Keyword	Level	Description	Syslog Definition
emergencies	0	System unusable	LOG_EMERG
alerts	1	Immediate action needed	LOG_ALERT
critical	2	Critical conditions	LOG_CRIT
errors	3	Error conditions	LOG_ERR
warnings	4	Warning conditions	LOG_WARNING
notifications	5	Normal but significant condition	LOG_NOTICE
informational	6	Informational messages only	LOG_INFO
debugging	7	Debugging messages	LOG_DEBUG

To display logging messages on a terminal, use the terminal monitor EXEC command.

Current software generates four categories of error messages:

Define the UNIX System Logging Facility

You can log messages produced by UNIX system utilities. To do this, enable this type logging and define the UNIX system facility from which you want to log messages. Table 21 lists the UNIX system facilities supported by the Cisco IOS software. Consult theoperators manual for your UNIX operating system for more information about these UNIX system facilities.

Define UNIX system facility message logging by using the following command in global configuration mode:

Command	Purposes
logging facility facility-type	Configure system log facilities.

Table 21: Logging Facility Type Keywords

Facility Type Keyword	Description
auth	Indicates the authorization system.
cron	Indicates the cron facility.
daemon	Indicates the system daemon.
kern	Indicates the Kernel.
local0-7	Reserved for locally defined messages.
lpr	Indicates line printer system.
mail	Indicates mail system.
news	Indicates USENET news.
sys9	Indicates system use.
sys10	Indicates system use.
sys11	Indicates system use.
sys12	Indicates system use.
sys13	Indicates system use.
sys14	Indicates system use.
syslog	Indicates the system log.
user	Indicates user process.
uucp	Indicates UNIX-to-UNIX copy system.

Display Logging Information

To display logging information, use the following command in EXEC mode:

	Command	Purposes
Step 1	show logging show controllers vip slot-number logging	Display the state of syslog error and event logging, including host addresses, whether console logging is enabled, and other logging statistics.
Step 2	show logging history	Display information in the syslog history table such as the table size, the status of messages, and the text of the messages stored in the table.

Log Errors to a UNIX Syslog Daemon

To set up the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the /etc/syslog.conf file:

local7.debugging /usr/adm/logs/cisco.log
 

The debugging keyword specifies the syslog level; see Table 20 for a general description of other keywords. The local7 keyword specifies the logging facility to be used; see Table 21 for a general description of other keywords.

The syslog daemon sends messages at this level or at a more severe level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.

Set the Syslog Source Address

By default, a syslog message contains the IP address of the interface it uses to leave the router. To require that all syslog messages contain the same IP address, regardless of which interface they use, use the following command in global configuration mode:

Use Field Diagnostics

Each line card on the Cisco 12000 series can perform field diagnostic testing to isolate faulty hardware without disrupting normal operation of the system. However, performing field diagnostic testing on a line card does halt all activity on the line card for the duration of the testing. After successful completion of the field diagnostic testing, the Cisco IOS software is automatically reloaded on the line card.

---

Note   The field diagnostic diag command must be executed from the GRP main console port.

---

To perform field diagnostic testing on a line card, perform the following commands in privileged EXEC mode:

	Command	Purposes
Step 1	diag slot-number [previous | post | verbose | wait]	Specify the line card that you want to perform diagnostic testing on. Optionally, specify that previous test results are displayed, that only extended power-on self-tests (POST) be performed, that the maximum messages are displayed, or that the Cisco IOS software not be reloaded on the line card after successful completion of the tests. The following prompt is displayed. Running Diags will halt ALL activity on the requested slot. [confirm] At the prompt, press Return to confirm that you want to perform field diagnostic testing on the specified line card, or type no to stop the testing.

To stop field diagnostic testing on a line card, use the following commands in privileged EXEC mode:

Command	Purpose
diag slot-number halt or no diag slot-number	Specify the line card that you want to stop perform diagnostic testing on.

---

Note   When you stop the field diagnostic test, the line card remains down (that is, in an unbooted state). In most cases, you stopped the testing because you need to remove the line card or replace the line card. If that is not the case and you want to bring the line card back up (that is, on-line), you must use the microcode reload global configuration command or power cycle the line card.

---

Troubleshooting Specific Line Cards

Cisco IOS provides the execute-on command to allow you issue IOS commands (such as show commands) to a specific line card for monitoring and maintaintanance. For example, you could show what Cisco IOS image is loaded on the card in slot 3 of a Cisco 12012 GSR by issuing the command execute-on slot 3 show version. You can also use this command for troubleshooting cards in the dial shelf of Cisco Access Servers. For complete documentation of this command see the "Troubleshooting" chapter of the Cisco IOS Configuration Fundamentals Command Reference.

Store Line Card Crash Information

This section explains how to enable storing of crash information for a line card and optionally specify the type and amount of information stored. Technical support representatives need to be able to look at the crash information from the line card to troubleshoot serious problems on the line card. The crash information contains all the line card memory information including the main memory and transmit and receive buffer information.

---

Caution Use the exception linecard global configuration command only when directed by a technical support representative and only enable options that the technical support representative requests you to enable.

---

To enable and configure the crash information options for a line card, use the following command in global configuration mode:

Command	Purpose
exception linecard {all | slot slot-number} [corefile filename | main-memory size [k | m] | queue-ram size [k | m] | rx-buffer size [k | m] | sqe-register-rx | sqe-register-tx | tx-buffer size [k | m]]	Specify the line card that you want crash information for when a line card resets. Optionally, specify the type and amount of memory to be stored.

Specifying Core Dump Files

When your router crashes, you need to specify a core dump filename to save on the server to retrieve information about the nature of the crash. The exception core-file global configuration command enables you to specify the name of the core dump file. To specify a filename of a core dump file to be dumped to a server when the router crashes, use the following command in global configuration mode:

Command	Purpose
exception core-file name	Specifies the name of the core dump file when your router has generated a core dump file after crashing.

Enable Debug Operations

Your router includes hardware and software to aid in tracking down internal problems and problems with other hosts on the network. The privileged debug EXEC commands start the console display of several classes of network events. The following commands describe in general the system debug message feature. Refer to the Debug Command Reference for all information regarding debug commands. Also refer to the Internetwork Troubleshooting Guide publication for additional information.

Command	Purposes
show debugging	Display the state of each debugging option.
debug ?	Display a list and brief description of all the debug command options.
debug command	Begin message logging for the specified debug command.
no debug command	Turn message logging off for the specified debug command.

---

Caution The system gives high priority to debugging output. For this reason, debugging commands should be turned on only for troubleshooting specific problems or during troubleshooting sessions with technical support personnel. Excessive debugging output can render the system inoperable.

---

You can configure timestamping of system debug messages. Timestamping enhances real-time debugging by providing the relative timing of logged events. This information is especially useful when customers send debugging output to your technical support personnel for assistance. To enable timestamping of system debug messages, use the following command in global configuration mode:

Normally, the messages are displayed only on the console terminal. See the section "Set the Error Message Display Device" earlier in this chapter to change the output device.

Enable Conditionally Triggered Debugging

When the Conditionally Triggered Debugging feature is enabled, the router generates debugging messages for packets entering or leaving the router on a specified interface; the router will not generate debugging output for packets entering or leaving through a different interface. You can specify the interfaces explicitly. For example, you may only want to see debugging messages for one interface or subinterface. You can also turn on debugging for all interfaces that meet specified condition. This feature is useful on dial access servers, which have a large number of ports.

• debug aaa {accounting | authorization | authentication}

• debug dialer {events | packets}

• debug isdn {q921 | q931}

• debug modem {oob | trace}

• debug ppp {all | authentication | chap | error | negotiation | multilink events | packet}

• Enable Protocol-Specific Debug Commands

• Enable Conditional Debugging Commands

• Specify Multiple Conditions

Enable Protocol-Specific Debug Commands

In order to generate any debugging output, the protocol-specific debug command for the desired output must be enabled. Use the show debugging command to determine which types of debugging are enabled. Use the show debug condition command to display the current debug conditions. Use the following commands in privileged EXEC mode to enable the desired protocol-specific debug commands:

Enable Conditional Debugging Commands

If no debug condition commands are enabled, all debugging output, regardless of the interface, will be displayed for the enabled protocol-specific debug commands.

• Display Messages for One Interface

• Display Messages for Multiple Interfaces

• Limit Messages Based on Conditions

Display Messages for One Interface

To disable debugging messages for all interfaces except one, use the following command in privileged EXEC mode:

Command	Purpose
debug condition interface interface	Disable debugging messages for all interfaces except one.

If you enter the debug condition interface command, the debugging output will be turned off for all interfaces except the specified interface. To reenable debugging output for all interfaces, use the no debug interface command.

Display Messages for Multiple Interfaces

To enable debugging messages for multiple interfaces, use the following commands in privileged EXEC mode:

Command	Purpose
debug condition interface interface	Disable debugging messages for all interfaces except one.
debug condition interface interface	Enable debugging messages for additional interfaces. Repeat this task until debugging messages are enabled for all desired interfaces.

If you specify more than one interface by entering this command multiple times, debugging output will be displayed for all of the specified interfaces. To turn off debugging on a particular interface, use the no debug interface command. If you use the no debug interface all command or remove the last debug interface command, debugging output will be reenabled for all interfaces.

Limit Messages Based on Conditions

The router can monitor interfaces to see if any packets contain the specified value for one of the following conditions:

• username

• calling party number

• called party number

If you enter a condition, such as calling number, debug output will be stopped for all interfaces. The router will then monitor every interface to see if a packet with the specified calling party number is sent or received on any interfaces. If the condition is met on an interface or subinterface, debug command output will be displayed for that interface. The debugging output for an interface is "triggered" when the condition has been met. The debugging output continues to be disabled for the other interfaces. If, at some later time, the condition is met for another interface, the debug output will become enabled for that interface as well.

Once debugging output has been triggered on an interface, the output will continue until the interface goes down. However, the session for that interface might change, resulting in a new username, called party number, or calling party number. Use the no debug interface command to reset the debug trigger mechanism for a particular interface. The debugging output for that interface will be disabled until the interface meets one of the specified conditions.

To limit debugging messages based on a specified condition, use the following command in privileged EXEC mode:

Command	Purpose
debug condition {username username | called dial-string | caller dial-string}	Enable conditional debugging. The router will only display messages for interfaces that meet this condition.

To reenable the debugging output for all interfaces, enter the no debug condition all command.

Specify Multiple Conditions

To limit debugging messages based on more than one condition, use the following commands in privileged EXEC mode:

Command	Purpose
debug condition {username username | called dial-string | caller dial-string}	Enable conditional debugging and specify the first condition.
debug condition {username username | called dial-string | caller dial-string}	Specify the second condition. Repeat this task until all conditions are specified.

If you enter multiple debug condition commands, debugging output will be generated if an interface meets at least one of the conditions. If you remove one of the conditions, using the no debug condition command, interfaces that meet only that condition will no longer produce debugging output. However, interfaces that meet a condition other than the removed condition will continue to generate output. Only if no active conditions are met for an interface will the output for that interface be disabled.

Conditionally Triggered Debugging Configuration Examples

In this example, four conditions have been set by the following commands:

• debug condition interface serial 0

• debug condition interface serial 1

• debug condition interface virtual-template 1

• debug condition username fred

The first three conditions have been met by one interface. The fourth condition has not yet been met.

Router# show debug condition
 
Condition 1: interface Se0 (1 flags triggered)
        Flags: Se0
Condition 2: interface Se1 (1 flags triggered)
        Flags: Se1
Condition 3: interface Vt1 (1 flags triggered)
        Flags: Vt1
Condition 4: username fred (0 flags triggered)
 

When any debug condition command is entered, debugging messages for conditional debugging are enabled. The following debugging messages show conditions being met on different interfaces as the serial 0 and serial 1 interfaces come up. For example, the second line of output indicates that serial interface 0 meets the username fred condition.

*Mar  1 00:04:41.647: %LINK-3-UPDOWN: Interface Serial0, changed state to up
*Mar  1 00:04:41.715: Se0 Debug: Condition 4, username fred triggered, count 2
*Mar  1 00:04:42.963: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
*Mar  1 00:04:43.271: Vi1 Debug: Condition 3, interface Vt1 triggered, count 1
*Mar  1 00:04:43.271: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Mar  1 00:04:43.279: Vi1 Debug: Condition 4, username fred triggered, count 2
*Mar  1 00:04:43.283: Vi1 Debug: Condition 1, interface Se0 triggered, count 3
*Mar  1 00:04:44.039: %IP-4-DUPADDR: Duplicate address 172.27.32.114 on Ethernet 0, sourced by 00e0.1e3e.2d41
*Mar  1 00:04:44.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
*Mar  1 00:04:54.667: %LINK-3-UPDOWN: Interface Serial1, changed state to up
*Mar  1 00:04:54.731: Se1 Debug: Condition 4, username fred triggered, count 2
*Mar  1 00:04:54.735: Vi1 Debug: Condition 2, interface Se1 triggered, count 4
*Mar  1 00:04:55.735: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
 

After a period of time, the show debug condition command displays the revised list of conditions.

Router# show debug condition
 
Condition 1: interface Se0 (2 flags triggered)
        Flags: Se0 Vi1
Condition 2: interface Se1 (2 flags triggered)
        Flags: Se1 Vi1
Condition 3: interface Vt1 (2 flags triggered)
        Flags: Vt1 Vi1
Condition 4: username fred (3 flags triggered)
        Flags: Se0 Vi1 Se1
 

Next, the serial 1 and serial 0 interfaces go down. When an interface goes down, conditions for that interface are cleared.

*Mar  1 00:05:51.443: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar  1 00:05:51.471: Se1 Debug: Condition 4, username fred cleared, count 1
*Mar  1 00:05:51.479: Vi1 Debug: Condition 2, interface Se1 cleared, count 3
*Mar  1 00:05:52.443: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
*Mar  1 00:05:56.859: %LINK-3-UPDOWN: Interface Serial0, changed state to down
*Mar  1 00:05:56.887: Se0 Debug: Condition 4, username fred cleared, count 1
*Mar  1 00:05:56.895: Vi1 Debug: Condition 1, interface Se0 cleared, count 2
*Mar  1 00:05:56.899: Vi1 Debug: Condition 3, interface Vt1 cleared, count 1
*Mar  1 00:05:56.899: Vi1 Debug: Condition 4, username fred cleared, count 0
*Mar  1 00:05:56.903: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
*Mar  1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
*Mar  1 00:05:57.907: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
 

The final show debug condition output is the same as the output before the interfaces came up.

Router# show debug condition
 
Condition 1: interface Se0 (1 flags triggered)
        Flags: Se0
Condition 2: interface Se1 (1 flags triggered)
        Flags: Se1
Condition 3: interface Vt1 (1 flags triggered)
        Flags: Vt1
Condition 4: username fred (0 flags triggered)

Posted: Fri Aug 18 09:13:18 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.