This chapter provides help in isolating and correcting problems that may occur during the installation process or during normal operation of the CoreBuilder® 9000 Enterprise Management Engine (EME). This chapter contains the following sections:
If an LED does not illuminate as you expected, and the LED is functional, see the troubleshooting tables within this chapter.
Table 27 lists common problems that can arise when you install your EME and possible solutions. Under normal conditions, when you install the EME, the Status LED lights and the character display shows the EME's operating state.
Table 28 lists some common problems that can occur as you perform an out-of-band download.
Table 29 lists some common problems that can occur as you configure the EME to communicate with a terminal. Follow the directions in Chapter 2, "Installing and Setting Up Your Management System" for more information about how to do this.
This section describes the impact of the EME on the network. It is designed to help you identify the source of packets on the network. Specifically, this section helps identify 3Com-generated packets.
The EME generates packets on the network when:
The EME uses a separate path on the CoreBuilder 9000 backplane to manage the other modules in the chassis.
The EME console receives a trap message when a change is made or an error occurs in a chassis that has an installed EME. The designated trap receiver (for example, a management workstation) also receives a trap if you have entered this information in the EME community table.
For example, if you remove a module from a chassis, the EME sends messages that describe the change to the console:
Message received from this device on 15:58 Fri 09 Jul 99:
Enterprise: 3Com
Enterprise Specific Trap: Module Down
Message Information:
Slot Number: 6
Subslot Number: 1
Module Type Number: 6
Module Description:
Message received from this device on 15:58 Wed 21 Jul 99:
Enterprise: 3Com
Enterprise Specific Trap: Slot Down
Message Information:
Slot Number: 6
Table 30 describes the first two fields in the trap message. The remainder of the fields are dependent upon the type of trap that is received and are self-explanatory.
SNMP traps are sent to the EME console when traps occur. An example of an SNMP trap is when a device attempts to gather information (read) from the EME, but the address of the device was not added to the community table with that access level. The message that appears in this instance is similar to the following example:
Message received from this device on 15:58 Fri 09 Jul 99:
Enterprise: 3Com
SNMP Generic Trap: SNMP Authentication Failure
Message Information:
Authentication Failure Address: 151.104.6.163
Use the servdiag command to run diagnostic tests on the module that you specify. This command is useful if you suspect a problem on the module or if you notice that the module is behaving inconsistently. The syntax for this command is:
servdiag <slot.subslot> <test>
Two types of tests are available:
While the module runs these diagnostic tests, it does not pass network traffic. Do not use this command unless you suspect a problem on the module, and you do not need to use the module in your network.
The following example runs the Boot test on an interface module in
slot 2. This module passes the test.
CB9000> servdiag 2.1 boot
Test may take up to 4 minutes and 0 seconds.
Do you wish to continue (y/n): y
Module 02.01 accepted diagnostic.
Event Received: "Mod Diags: 02.01" Event generated: 18:50:26 Jul 09 1999 Entry: 00002 Slot: 18.02 Id: 01002 Severity: Inform Type: Inform Module Diagnostics: Slot 02, Subslot 01.
CB9000>
Event Received: "Diag: PASSED" Event generated: 18:51:10 19 Jul 09 1999 Entry: 00003 Slot: 02.01 Id: 00103 Severity: Inform Type: Diag Test: 01.00 Loop: 00001
CB9000>
Event Received: "Mod Up: 02.01" Event generated: 18:52:15 19 Jul 09 1999 Entry: 00005 Slot: 18.02 Id: 01002 Severity: Inform Type: Inform Module Up: Slot 02, Subslot 01.
If the servdiag test encounters an error, and if it is set to stop on the error, the module does not function. If this occurs, call your 3Com reseller or 3Com Technical Support immediately to obtain assistance. See Appendix B for information about obtaining Technical Support. See "The cont_mode Characteristic" later in this chapter for information about how to set the servdiag diagnostic tests to stop on different types of errors.
With the set servdiag command, you can specify how the EME executes the diagnostics tests on the module that you specify. The characteristics are:
The cont_mode (continuation mode) of the diagnostic test determines whether the test continues after it encounters an error. The continuation mode can be one of the following:
The following example sets the cont_mode to continue:
CB9000> set servdiag cont_mode continue
The loop_count characteristic determines how many times the EME runs the diagnostic test on the module that you specify. Because the module does not pass network traffic during the tests, do not set a high loop count when you need to use the module in your network.
Valid values for the loop_count characteristic are 0 through 65535. The default loop_count value is 1. A value of zero causes the test to run indefinitely. The following example sets the loop_count to 5:
CB9000> set servdiag loop_count 5
The verbosity characteristic determines the amount of output that the diagnostic test sends to the console. Two options are available:
The following example sets the verbosity to verbose:
CB9000> set servdiag verbosity verbose
Use the show servdiag command to view the characteristics of this option:
CB9000> show servdiag
Verbosity: nonverbose
Loop count: 1
Continue mode: continue
To receive assistance for installing and troubleshooting the EME, call your 3Com reseller or the 3Com Technical Support Organization. Be prepared to supply a representative with the following information:
See Appendix B for Technical Support contact information.