03-Device Management Configuration
Chapters Download (128.42 KB)
Table of Contents
Device Management Configuration Task List
Configuring the Exception Handling Method
Configuring the Scheduled Automatic Execution Function
Upgrading the Boot ROM Program Through Command Lines
Upgrading the Boot File Through Command Lines
Configuring Temperature Alarm Thresholds for a Device
Clearing the 16-bit Interface Indexes Not Used in the Current System
Identifying and Diagnosing Pluggable Transceivers
Introduction to pluggable transceivers
Identifying pluggable transceivers
Diagnosing pluggable transceivers
Displaying and Maintaining Device Management Configuration
Device Management Configuration Examples
Remote Scheduled Automatic Upgrade Configuration Example
When configuring device management, go to these sections for information you are interested in:
l Device Management Configuration Task List
l Configuring the Exception Handling Method
l Configuring the Scheduled Automatic Execution Function
l Configuring Temperature Alarm Thresholds for a
l Clearing the 16-bit Interface Indexes Not Used in the Current System
l Identifying and Diagnosing Pluggable Transceivers
l Displaying and Maintaining Device Management Configuration
l Device Management Configuration Examples
Through the device management function, you can view the current working state of a device, configure running parameters, and perform daily device maintenance and management.
Complete these tasks to configure device management:
Task |
Remarks |
Optional |
|
Optional |
|
Optional |
|
Optional |
|
Optional |
|
Optional |
|
Clearing the 16-bit Interface Indexes Not Used in the Current System |
Optional |
Optional |
When the system detects any software abnormality, it handles the situation with one of the following two methods:
l reboot: The system recovers itself through automatic reboot.
l maintain: The system maintains the current situation, and does not take any measure to recover itself. Therefore, you need to recover the system manually, such as reboot the system. Sometimes, it is difficult for the system to recover, or some prompts that are printed during the failure are lost after the reboot. In this case, you can use this method to maintain the abnormal state to locate problems and recover the system.
Follow these steps to configure the exception handling method:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Configure the exception handling method |
system-failure { maintain | reboot } |
Optional By default, the system adopts the reboot method to handle exceptions. |
When a fault occurs to a running device, you can remove the fault by rebooting the device, depending on the actual situation.
You can reboot a device following any of the three methods:
l Power on the device after powering it off, which is also called hard reboot or cold start. This method impacts the device a lot. Powering off a running device will cause data loss and hardware damages. It is not recommended.
l Trigger the immediate reboot through command lines.
l Enable the scheduled reboot function through command lines. You can set a time at which the device can automatically reboot, or set a delay so that the device can automatically reboot within the delay.
The last two methods are command line operations. Reboot through command lines is also called hot start, which is equal to powering on the device after powering it off. It is mainly used to reboot a device in remote maintenance, without performing hardware reboot of the device.
Follow the step below to reboot a device through command lines immediately:
To do… |
Use the command… |
Remarks |
Reboot the whole system immediately |
reboot |
Required Available in user view |
Follow these steps to reboot a device at a time through command lines:
To do… |
Use the command… |
Remarks |
Enable the scheduled reboot function and specify a specific reboot time and date |
schedule reboot at hh:mm [ date ] |
Required Use either approach. The scheduled reboot function is disabled by default. Available in user view. |
Enable the scheduled reboot function and specify a reboot waiting time |
schedule reboot delay { hh:mm | mm } |
l Device reboot may result in the interruption of the ongoing services. Use these commands with caution.
l Before device reboot, use the save command to save the current configurations. For details about the save command, refer to File System Configuration in the System Volume.
l Before device reboot, use the commands of display startup and display boot-loader to check if the configuration file and boot file for the next boot are configured. (For details about the display startup command, refer to File System Configuration in the System Volume.
l The precision of the rebooting timer is 1 minute. One minute before the rebooting time, the device will prompt “REBOOT IN ONE MINUTE” and will reboot in one minute.
l If a main boot file fails or does not exist, the device cannot be rebooted with the reboot command. In this case, you can re-specify a main boot file to reboot the device, or you can power off the device then power it on and the system automatically uses the backup boot file to restart the device.
l If you are performing file operations when the device is to be rebooted, the system does not execute the command for the sake of security.
The scheduled automatic execution function enables the system to automatically execute a specified command at a specified time in a specified view. This function is used for scheduled system upgrade or configuration.
Follow these steps to configure the scheduled automatic execution function:
To do… |
Use the command… |
Remarks |
Automatically execute the specified command at the specified time |
schedule job at time [ date ] view view command |
Optional Use either command. Available in user view. |
Automatically execute the specified command after the specified delay |
schedule job delay time view view command |
Note that:
l At present, you can specify user view and system view only. To automatically execute the specified command in another view or automatically execute multiple commands at a time, you can configure the system to automatically execute a batch file at the specified time (note that you must provide a complete file path for the system to execute the batch file.).
l The system does not check the values of the view and command arguments. Therefore, ensure the correctness of the command argument (including the correct format of command and the correct relationship between the command and view arguments).
l After the specified automatic execution time is reached, the system executes the specified command in the background without displaying any information except system information such as log, trap and debug.
l The system does not require any interactive information when it is executing the specified command. If there is information for you to confirm, the system automatically inputs Y or Yes; if characters need to be input, the system automatically inputs a default character string, or inputs an empty character string when there is no default character string.
l For the commands used to switch user interfaces, such as telnet, ftp, and ssh2, the commands used to switch views, such as system-view, quit, and the commands used to modify status of a user that is executing commands, such as super, the operation interface, command view and status of the current user are not changed after the automatic execution function is performed.
l If the system time is modified after the automatic execution function is configured, the scheduled automatic execution configuration turns invalid automatically.
l Only the last configuration takes effect if you execute the schedule job command repeatedly.
Device software consists of the Boot ROM program and the system boot file. After the device is powered on, the device runs the Boot ROM program, initializes the hardware, and displays the hardware information. Then the device runs the boot file. The boot file provides drivers and adaption for hardware, and implements service features. The Boot ROM program and system boot file are required for the startup and running of a device. Figure 1-1 illustrates their relationship.
Figure 1-1 Relationship between the Boot ROM program and the system boot file
The Boot ROM program and system boot file can both be upgraded through the Boot ROM menu or command lines. The following sections describe the upgrading through command lines. For instructions about how to upgrade them through the Boot ROM menu, refer to the installation menu of your device.
Follow these steps to upgrade the Boot ROM program:
1) Copy the Boot ROM program to the root directory of the device's storage medium using FTP or TFTP.
2) Use a command to specify the Boot ROM program for the next boot.
3) Reboot the device to make the specified Boot ROM program take effect.
Follow these steps to upgrade the Boot ROM program:
To do… |
Use the command… |
Remarks |
upgrade the Boot ROM program on devices |
bootrom update file file-url { main | backup } |
Required Available in user view. |
Follow the steps to upgrade the boot file:
1) Save the boot file to the root directory of the device's storage medium using FTP, TFTP, or other approaches.
2) Use a command to specify the boot file for the next boot of the device.
3) Reboot the device to make the boot file take effect.
When multiple Boot ROM files are available on the storage media, you can specify a file for the next device boot by executing the following command. A main boot file is used to boot a device and a backup boot file is used to boot a device only when a main boot file is unavailable.
Follow the step below to upgrade the boot file:
To do… |
Use the command… |
Remarks |
Specify a boot file for the next boot |
boot-loader file file-url { main | backup } |
Required Available in user view. |
l You must save the file for the next device boot under the root directory of the device. You can copy or move a file to change the path of it to the root directory.
l You can’t to specify the boot file for the next boot of the USB device.
You can set temperature alarm thresholds for a device by using the following command. When the temperature of a device exceeds the threshold, the device will generate alarm signals.
Follow these steps to configure temperature alarm thresholds for a device:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Configure temperature alarm thresholds for a device |
temperature-limit slot slot-num hotspot sensor-number lowerlimit warninglimit [ alarmlimit ] |
Optional By default: l Lower limit: 5 l Warning limit: 70 l Alarm limit: 80 |
In practical networks, the network management software requires the device to provide a uniform, stable 16-bit interface index. That is, a one-to-one relationship should be kept between the interface name and the interface index in the same device.
For the purpose of the stability of an interface index, the system will save the 16-bit interface index when a card or logical interface is removed.
If you repeatedly insert and remove different subcards to create or delete a large number of logical interfaces, the interface indexes will be used up, which will result in interface creation failures. To avoid such a case, you can clear all 16-bit interface indexes saved but not used in the current system in user view.
After the above operation,
l For a re-created interface, the new interface index may not be consistent with the original one.
l For existing interfaces, their interface indexes remain unchanged.
Follow these steps to clear the 16-bit interface indexes not used in the current system:
To do… |
Use the command… |
Remarks |
Clear the 16-bit interface indexes saved but not used in the current system |
reset unused porttag |
Required Available in user view. |
At present, four types of pluggable transceivers are commonly used, as shown in Table 1-1. They can be further divided into optical transceivers and electrical transceivers based on transmission medium.
Table 1-1 Commonly used pluggable transceivers
Transceiver type |
Application environment |
Whether can be an optical transceiver |
Whether can be an electrical transceiver |
SFP (Small Form-factor Pluggable) |
Generally used for 100M/1000M Ethernet interfaces or POS 155M/622M/2.5G interfaces |
Yes |
Yes |
GBIC (Gigabit Interface Converter) |
Generally used for 1000M Ethernet interfaces |
Yes |
Yes |
XFP (10-Gigabit small Form-factor Pluggable) |
Generally used for 10G Ethernet interfaces |
Yes |
No |
XENPAK (10-Gigabit Ethernet Transceiver Package) |
Generally used for 10G Ethernet interfaces |
Yes |
Yes |
As pluggable transceivers are of various types and from different vendors, you can use the following commands to view the key parameters of the pluggable transceivers, including transceiver type, connector type, central wavelength of the laser sent, transfer distance and vendor name or name of the vendor who customizes the transceivers to identify the pluggable transceivers.
Follow these steps to identify pluggable transceivers:
To do… |
Use the command… |
Remarks |
Display key parameters of the pluggable transceiver(s) |
display transceiver interface [ interface-type interface-number ] |
Available for all pluggable transceivers. |
Display part of the electrical label information of the anti-spoofing transceiver(s) customized by H3C |
display transceiver manuinfo interface [ interface-type interface-number ] |
Available for anti-spoofing pluggable transceiver(s) customized by H3C only. |
l You can use the Vendor Name field in the prompt information of the display transceiver command to identify an anti-spoofing pluggable transceiver customized by H3C. If the field is H3C, it is considered an H3C-customized pluggable transceiver.
l Electrical label information is also called permanent configuration data or archive information, which is written to the storage component of a card during device debugging or testing. The information includes name of the card, device serial number, and vendor name or name of the vendor who customizes the transceiver.
The system outputs alarm information for you to diagnose and troubleshoot faults of pluggable transceivers. Optical transceivers customized by H3C also support the digital diagnosis function, which monitors the key parameters of a transceiver, such as temperature, voltage, laser bias current, TX power, and RX power. When these parameters are abnormal, you can take corresponding measures to prevent transceiver faults.
Follow these steps to diagnose pluggable transceivers:
To do… |
Use the command… |
Remarks |
Display the current alarm information of the pluggable transceiver(s) |
display transceiver alarm interface [ interface-type interface-number ] |
Available for all pluggable transceivers. |
Display the currently measured value of the digital diagnosis parameters of the anti-spoofing optical transceiver(s) customized by H3C |
display transceiver diagnosis interface [ interface-type interface-number ] |
Available for anti-spoofing pluggable optical transceiver(s) customized by H3C only. |
l Centralized device
To do… |
Use the command… |
Remarks |
Display information of the boot file |
display boot-loader |
Available in any view |
Display the statistics of the CPU usage |
display cpu-usage [ entry-number [ offset ] [ verbose ] [ from-device ] ] |
Available in any view |
Display history statistics of the CPU usage in a chart |
display cpu-usage history [ task task-id ] |
Available in any view |
Display information about USB or hardware on the device |
display device usb [ verbose ] |
Available in any view |
Display electrical label information of the device |
display device manuinfo |
Available in any view |
Display the temperature information of devices |
display environment [ slot slot-number ] |
Available in any view |
Display the operating state of fans in a device |
display fan [ fan-id ] |
Available in any view |
Display the usage of the memory of a device |
display memory |
Available in any view |
Display the power state of a device |
display power [ power-id ] |
Available in any view |
Display the reboot type of a device |
display reboot-type |
Available in any view |
Display the reboot time of a device |
display schedule reboot |
Available in any view |
Display detailed configurations of the scheduled automatic execution function |
display schedule job |
Available in any view |
Display the exception handling method |
display system-failure |
Available in any view |
l As shown in Figure 1-2, the current software version is soft-version1 for Device. Upgrade the software version of Device to soft-version2 and configuration file to new-config at a time when few services are processed (for example, at 3 am) through remote operations.
l The latest application soft-version2.bin and the latest configuration file new-config.cfg are both saved under the aaa directory of the FTP server.
l The IP address of Device is 1.1.1.1/24, the IP address of the FTP server is 2.2.2.2/24, and the FTP server is reachable.
l User can log in to Device via Telnet and a route exists between User and Device.
Figure 1-2 Network diagram for remote scheduled automatic upgrade
1) Configuration on the FTP server (Note that configurations may vary with different types of servers)
l Set the access parameters for the FTP client (including enabling the FTP server function, setting the FTP username to aaa and password to hello, and setting the user to have access to the flash:/aaa directory).
<FTP-Server> system-view
[FTP-Server] ftp server enable
[FTP-Server] local-user aaa
[FTP-Server-luser-aaa] password cipher hello
[FTP-Server-luser-aaa] service-type ftp
[FTP-Server-luser-aaa] authorization-attribute work-directory flash:/aaa
l Use text editor on the FTP server to edit batch file auto-update.txt. The following is the content of the batch file:
return
startup saved-configuration new-config.cfg
boot-loader file soft-version2.bin main
reboot
2) Configuration on Device
# Log in to the FTP server (note that the prompt may vary with servers.)
<Device> ftp 2.2.2.2
Trying 2.2.2.2 ...
Press CTRL+K to abort
Connected to 2.2.2.2.
220 WFTPD 2.0 service (by Texas Imperial Software) ready for new user
User(2.2.2.2:(none)):aaa
331 Give me your password, please
Password:
230 Logged in successfully
[ftp]
# Download file auto-update.txt on the FTP server.
[ftp] ascii
[ftp] get auto-update.txt
# Download file new-config.cfg on the FTP server.
[ftp]get new-config.cfg
# Download file soft-version2.bin on the FTP server.
[ftp] binary
[ftp] get soft-version2.bin
[ftp] bye
<Device>
# Modify the extension of file auto-update.txt as .bat.
<Device> rename auto-update.txt auto-update.bat
To ensure correctness of the file, you can use the more command to view the content of the file.
# Execute the scheduled automatic execution function to enable the device to be automatically upgraded at 3 am.
<Device> schedule job at 03:00 view system execute auto-update.bat
Info: Command execute auto-update.bat in system view will be executed at 03:00 12/11/2007(in 12 hours and 0 minutes).
After the device reboots, use the display version command to check if the upgrade is successful.