Trivial file transfer protocol (TFTP) is a protocol used for transferring trivial files between clients and servers in the TCP/IP suite. It provides low-cost and simple file transfer service. Carried over UDP, TFTP provides only the unreliable traffic transmission without any access authorization and authentication mechanism. It ensures data will reach destinations with the approach of timeout retransmission. At present, TFTP Version 2 (RFC 1350) is the most popular version.

The VG can provide TFTP client service. That is, the VG serves as a TFTP client, while the file server as the TFTP server. You can enter the corresponding commands on the VG to upload its configuration files or main program files to the file server or download these files from the file server into the Flash of the local VG.

Before using TFTP, you should purchase and install a TFTP server application on your own, for H3C VG is not accompanied with the software.

The application program of TFTP server can run on Windows 95/98/NT.

I. Preparations for using TFTP server

1) Running TFTP Server program

Step 1: Enable the TFTP server program. Select a PC installed with the Windows 95/98/NT operating system and start the TFTP server program on the PC. (Alternatively, a PC running HyperTerminal) As the H3C VG is not accompanied with the TFTP server software, TFTPD32 in a Windows 98 environment will be taken as an example for describing the procedure. The following figure illustrates a TFTPD32 interface.

Figure 1-1 TFTPD32 interface

Step 2: Set the directory for the TFTP server files. After enabling the TFTP server, redefine a TFTP file directory and copy the desired main program files into this directory. Alternatively, set the directory containing the VG main program files as the directory for TFTP server files. Specifically, click <Settings> in the TFTPD32 interface, and the Tftpd32: Settings interface pops up.

Figure 1-2 TFTPD32 settings

Enter the file directory in the field of “Base Directory, and click <OK> for acknowledgement.

& Note:

The setting interface may vary with different TFTP server program.

2) Connecting the VG

Connect the Ethernet 0 interface to the TFTP Server machine with Ethernet cable.

& Note:

If you want to upgrade the VG through Boot ROM, you must use ethernet 0. But this condition is not required after the VG is started.

II. Upgrading through TFTP upon VG Start

This approach implements upgrading by executing the get command to load the main program files of VG from the TFTP server after the VG is booted.

Make preparations (necessary connection and booting TFTP Server) properly and run the following command in the system view.

Table 1-1 Download main program files from TFTP server

Operation	Command
Download main program files from TFTP server	get ip-addr file-name system

1.2.2 Upgrading through FTP

As an application layer protocol in the TCP/IP suite, File Transfer Protocol (FTP) is mainly used for file transfer between remote hosts. Carried over TCP, FTP can provide reliable and connection-oriented data stream transmission and access authorization and authentication mechanisms.

After a client originates a control connection to a server and uses a randomly assigned FTP port to establish the control link with port 21 on the server, the link will be in place until there is no data waiting for transmission. The server uses port 20 to establish data link with the client for data transmission.

The VG provides the FTP server service. That is, the VG serves as a TFTP server, and a subscriber can run the FTP client application to log in the VG for accessing the files on the VG.

Before using FTP, you should purchase and install a FTP client application on your own, for H3C VG is not attached with the software.

I. Preparations for using FTP server

1) Running FTP server program

The FTP service can be enabled after configuring the authentication and authorization on the FTP server. The FTP server supports one-user access. A remote FTP user sends a request to the FTP server, and the server will perform actions accordingly and return the execution result to the subscriber.

Perform the following configurations in system view.

Table 1-2 Enable FTP server

Operation	Command
Enable FTP server	ftp-server enable
Disable FTP server	undo ftp-server enable

2) Adding authorized FTP username and password

Perform the following configurations in system view.

Table 1-3 Add authorized FTP username and password

Operation	Command
Add authorized FTP username and password	local-user username service-type ftp password {simple \| cipher } password
Delete FTP user	undo local-user username

3) Setting FTP authentication

You may not enable Authorization, Administration and Accounting (AAA) or just enable AAA without FTP authentication. By default, AAA adopts local authentication.

II. Upgrading VG main program using FTP

Step 1: Assign an IP address to the interface on the VG for connection to the host running the FTP client program.

Step 2: Take the FTP client program of Windows 98 as an example for illustration. Upload the target files to a specified directory (say C:\temp) on the FTP client.

Step 3: Open the DOS window, enter “FTP A.B.C.D” (A.B.C.D representing the IP address of the VG), and enter the user name and password as prompted:

C:\WINDOWS> ftp 10.110.27.1

Connected to 10.110.27.1.

220 FTP service ready on VG at

User (10.110.27.1:(none)): cjj

331 Password required for cjj.

Password:

230 User cjj logged in .

ftp>

Step 4: After the authentication is passed, the FTP client displays the prompt “ftp>”. Enter “binary” behind the prompt, and set the upload directory on the FTP client.

ftp> binary

200 Type set to I.

ftp> lcd c:\temp

Local directory now C:\temp.

Step 5: At the prompt of “ftp>”, set a directory for the FTP server (the VG). By default, the file name of the VG main program is “system”, which is case sensitive.

ftp> dir

200 Port command okay.

150 okay.

config 1007 Bytes

system 5802368 Bytes

226 Data transmit over.

ftp: 76 bytes received in 0.00Seconds 76000.00Kbytes/sec.

Step 6: At the prompt of “ftp>”, enter the put LocalFile [ RemoteFile ] command to upload the specified file to the VG. RemoteFile must be the name of the system file on the VG.

ftp> put VG system

200 Port command okay.

150 Server okay , now receive file.

226 file transmit success.

ftp: 5802263 bytes sent in 80.74Seconds 71.86Kbytes/sec.

Step 7: When the file uploading is completed, enter at the prompt of “ftp>” the dir command for displaying the file name and size on the VG. If the uploading operation is successful, the program or configuration file on the VG and the uploaded file on the host should have the same size.

Step 8: At the prompt of “ftp>”, enter the quit command to exit the FTP client program.

Step 9: After receiving all of them, the VG prompts whether to replace the system file, and writes the files into the Flash if Y is selected,, and the following information appears on the terminal:

Now saving the program file.

Please wait for a while

Receive 5802263 Bytes from client

Writing program code to FLASH...

Do you really want to replace the system file?(Y/N)y

Please waiting, it may take a few minutes

####################################################################################################################################

Write success, please reboot Voice Gateway!

The upgraded software cannot take effect until the VG is rebooted.

1.2.3 Backing up VG Main Program

I. TFTP backup

In this mode, you can use the copy command to copy the main program of VG to the TFTP server for redundancy (copy the VG main program to the PC), after booting the VG.

Make preparations (necessary connection and booting TFTP Server) properly and run the following command in the system view.

Table 1-4 Copy the VG main program to the TFTP server

Operation	Command
Back up VG main program from TFTP server	copy { ip-addr \| host-name } file-name system

II. FTP backup

Its procedure is similar to that for loading the software with FTP. Refer to section 1.2.2 “Upgrading through FTP” for details. Only in Step 6, at the prompt of “ftp>”, use the get RemoteFile [LocalFile] command to download the specified file to the FTP client. RemoteFile should use the name of the system file on the VG, and the name is case sensitive.

ftp> dir

200 Port command okay.

150 okay.

config 1045 Bytes

vgd009.bin 5910114 Bytes

226 Data transmit over.

ftp: 76 bytes received in 0.02Seconds 4.75Kbytes/sec.

ftp> get vgd009.bin

200 Port command okay.

150 Server okay , now transmit file .

226 file transmit success.

ftp: 5910114 bytes received in 80.74Seconds 71.86Kbytes/sec.

& Note:

You can upgrade through the BootROM menu the main software of the VG when the VG is starting. For detailed operation, refer to the corresponding H3C VG voice gateway installation manual.

1.3 Configuration File Management

1.3.1 Contents and Format of the Configuration File

The configuration file is a text file, in the following format:

l Saved in command format.

l To save space, only the parameters are saved but not the default values (Please refer to the following chapters for the default values of configuration parameters.).

l Commands are organized by views. Commands in the same view are organized together, forming a section, and sections are separated with a blank line or a comment line (beginning with “!”).

l Sections are usually arranged in the following order: global configuration, physical interface configuration, logical interface configuration, routing protocol configuration, etc.

l Ended with “return”.

1.3.2 Loading the Configuration File

You can edit the configuration files offline following the specified format and then load them onto the VG. Three modes are available for loading configuration files:

l XModem loading

l TFTP loading

l FTP loading

I. XModem loading

In this mode, configuration files can be loaded using the download config command in the terminal emulation program after the VG is booted. This command can only be executed in the terminal emulation program. If executing the command in Telnet, the following prompt will be displayed:

The command can only be executed by console user client.

Perform the following configuration in the system view.

Table 1-5 Load configuration files

Operation	Command
Load configuration files	download config

Follow these steps to run the terminal emulation program:

l Enter the command and make acknowledgement.

[VG] download config

Do you really want to download the config file?(Y/N)y

l Set the binary transmission protocol to XModem/CRC.

Change protocol to xmodem,then send the selected file...

l Transfer the configuration files to the VG in the binary format.

Press CTRL-C to break.

Downloading...CCC

l Select [Transmit/Send files] in HyperTerminal of Windows, and load the correct configuration to the VG.

l Save the loaded files into the Flash, if the loading operation is successful.

Writing to flash memory,Please wait...

DOWNLOAD SUCCESSFULLY

& Note:

When performing offline editing and loading of configuration files, you are recommended to do it under the guidance of technical support personnel. If a wrong configuration file is loaded, restore the default configuration by erasing the configuration file in the Flash.

II. TFTP loading

In this mode, you can use the get command to download the configuration files from the TFTP server after booting the VG.

Make preparations properly before running the get command: run TFTP server application program on the PC, set correct transfer path for downloading configuration files, IP address for the server machine and port ID in use. For more information, refer to section 1.2.1 “Upgrading through TFTP upon VG Power-on”.

Perform the following configuration in system view.

Table 1-6 Download configuration files from TFTP server

Operation	Command
Download configuration files from TFTP server	get { ip-addr \| host-name } file-name config

III. FTP loading

Its procedure is similar to that for loading the software with FTP. Refer to section 1.2.2 Upgrading through FTP” for details. Only in Step 6, at the prompt of “ftp>”, use the get RemoteFile [LocalFile] command to upload the specified file to the VG. RemoteFile should use the name of the config file on the VG, and the name is case sensitive.

ftp> put config1 config

200 Port command okay.

150 Server okay , now receive file.

226 file transmit success.

ftp: 1007 bytes sent in 0.00Seconds 1007000.00Kbytes/sec.

1.3.3 Backing up the Configuration File

You can back up configuration files in the following ways:

l Backup with the display current-configuration command

l TFTP backup

l FTP backup

I. Backup with the display current-configuration command

Display all configuration files (except default configuration files) with the display current-configuration command. Copy all configuration output into a text file as backup.

You can back up configuration files by copying and saving the contents displayed below “Current configuration” into a text file.

II. TFTP backup

First, start TFTP server application program on a PC (the VG should be connected to the PC directly or indirectly, and ping operation can be performed between them), then set a path and use the copy command in the system view. Then you can upload the configuration files from the VG to the TFTP server. The method is often used in remote maintenance. Refer to section 1.2.1 “Upgrading through TFTP upon VG Power-on” for more details.

Perform the following configuration in system view.

Table 1-7 Upload configuration files to a TFTP server

Operation	Command
Upload configuration files to a TFTP server	copy { ip-addr \| host-name } file-name config

III. FTP backup

Its procedure is similar to that for loading the software with FTP. Refer to section 1.2.2 “Upgrading through FTP” for details. Only in Step 6, at the prompt of “ftp>”, use the get RemoteFile [LocalFile] command to upload the specified file to the VG. RemoteFile should use the name of the config file on the VG, and the name is case sensitive.

ftp> get config config.bak

200 Port command okay.

150 Server okay , now transmit file .

226 file transmit success.

ftp: 735 bytes received in 0.06Seconds 12.25Kbytes/sec.

1.3.4 Display the Current Configuration and Initial Configuration of VG

During power-on, the VG reads the configuration files from Flash for its initialization. Therefore, the configuration file in Flash is called initial configuration. If there is no configuration file in Flash, the VG will use default parameters for initialization. Corresponding to initial configuration, the configuration which becomes effective immediately in the running process of the VG is called current configuration.

In general, the initial configuration and current configuration should be the same. In the case of upgrading (such as upgrading the host software version or board software), the initial configuration might be different from the current configuration. Then you should save the initial configuration in time to avoid the loss of some configuration commands.

Perform the following configurations in any views.

Table 1-8 View initial and current configurations

Operation	Command
Views the initial configuration of the VG	display saved-configuration
Views the current configuration of the VG	display current-configuration
Views the current system configuration of the VG	display current-configuration global
Views all the current interface configuration of the VG	display current-configuration interface type [ number ]
Views the current IP routing of the VG	display current-configuration ip { route }
Views the current voice configuration of the VG	display current-configuration voice [ aaa \| access-number \| acct-method \| cdr ] }

1.3.5 Modifying and Saving the Current Configuration

Users can modify the current configuration of the VG via the command line interface (CLI). To save the current configuration as initial configuration for the next power-on, use the save command to save the current configuration in Flash.

Perform the following configuration in system view.

Table 1-9 Save current configuration

Operation	Command
Saves current configuration	save

1.3.6 Erasing the Configuration File in Storage Media

The delete command can be used to delete the configuration files in Flash of the VG. After deleting the configuration files, the VG will use the default configuration parameters for initialization in the next power-on. The configuration files in Flash or NVRAM may be deleted in the following cases:

l If the VG software after upgrading does not match the configuration files.

l The configuration files in Flash are not correct, for example, wrong configuration files are loaded.

Perform the following configuration in the system view.

Table 1-10 Erase the configuration files in storage media.

Operation	Command
Erases the configuration file in storage media	delete

1.4 VG as FTP Server

1.4.1 Configuring FTP Server

FTP configuration tasks include:

l Starting FTP server

l Configuring FTP service parameters

l Terminating FTP process

l Configuring FTP server authentication and authorization

I. Configuring FTP parameters

Configure FTP service parameters according to system running status, so as to make proper use of system resources.

1) Setting a filename for the BootROM program and its extended segment on FTP server.

2) Before uploading the filenames of the BootROM program and its extended segment, you need first to set the filenames on the VG.

Perform the following configurations in system view.

Table 1-11 Set a filename for the BootROM program and its extended segment on FTP server

Operation	Command
Configure a filename for the BootROM extended segment	ftp-server bootrom-name bootrom-name
Configure a filename for the whole BootROM program	ftp-server bootromfull-name bootromfull-name

By default, the filename of the BootROM extended segment is “bootrom”, and that of the whole BootROM program is “bootromfull”.

3) Setting FTP upgrade mode

When logging onto the FTP Server from a PC, you can use the put command to upload the files. The FTP Server adopts two upgrade modes: fast upgrade mode and normal upgrade mode.

l Fast upgrade mode: In this mode, after the FTP Server has received the files uploaded from the user, it will write the files into Flash. Even when the power is disconnected during the period of transmitting the files, the existing files in the VG will not be destroyed.

l Normal upgrade mode: In this mode, the FTP Server writes the files uploaded from the user into Flash as it receives the files. The existing files in the VG may be destroyed due to power disconnection. Compared with fast update mode, in normal upgrade mode the system demands less empty memory in the VG.

Perform the following configuration in system view.

Table 1-12 Set FTP upgrade mode

Operation	Command
Set FTP upgrade mode	ftp-server update { fast \| normal }

By default, the FTP server is in fast upgrade mode.

4) Setting time limit for FTP connection

To prevent illegal access by unauthorized users, if no service request is received from the FTP client within a certain period, connection with this FTP client will be terminated.

Perform the following configuration in system view.

Table 1-13 Set time limit for FTP connection

Operation	Command
Set time limit for FTP connection	ftp-server timeout seconds

By default, the time limit for FTP connection is 600 seconds.

II. Starting FTP server

The FTP server can be started after configuring the authentication and authorization of the FTP server. The FTP server supports simultaneous one-user access. The remote FTP user sends a request to the FTP server, which will execute a corresponding action and return the execution result to the user.

Perform the following configurations in system view.

Table 1-14 Start FTP server

Operation	Command
Start FTP server	ftp-server enable
Disable FTP server	undo ftp-server enable

III. Terminating FTP process

In some cases (malicious access of the FTP user), the administrator logging in from the Console port can use kill ftp command to disconnect the link from the FTP user to the VG. Take caution in executing this command.

Perform the following configuration in system view.

Table 1-15 Terminate FTP process

Operation	Command
Terminates FTP process	kill ftp

IV. Configuring FTP authentication and authorization

1) Setting FTP authentication

The authorization information of the FTP server is the top-level working directory to FTP users. Only authenticated and authorized users can access the FTP server. The VG configures authentication and authorization of the FTP user using AAA. If no AAA is configured, the local user authentication is adopted by default.

When using AAA, the VG does not support local accounting. Therefore, when using local authentication, you need to enable the accounting switch. When there is no available RADIUS accounting server or the connection with the RADIUS accounting server fails, you can continue to employ the network resources to achieve the authentication without accounting.

Perform the following configuration in system view.

Table 1-16 Set FTP authentication

Operation	Command
Enables AAA server	aaa-enable
Enables local login authentication	aaa authentication-scheme login default local

2) Adding authorized FTP username and password

Perform the following configuration in the system view.

Table 1-17 Add authorized FTP username and password

Operation	Command
Adds authorized FTP username and password	local-user username service-type ftp password {simple \| cipher } password
Deletes FTP user	undo local-user username

1.4.2 Displaying and Debugging FTP Server

Perform the following configuration in any views.

Table 1-18 Display and debug FTP server

Operation	Command
Displays current configuration of the FTP server	display ftp-server

1.5 Configuring Terminal Service Attributes

For the terminal users connecting to Console port, the idle-timeout time is set to 5 minutes. Use the undo idle-timeout command to disable the function, which keeps the connection always on for terminal users.

Perform the following configuration in system view.

Table 1-19 Configure terminal service attributes

Operation	Command
Enable the idle-timeout disconnection with the terminal users	idle-timeout
Disable the idle-timeout disconnection with the terminal users	undo idle-timeout

By default, the idle-timeout disconnection function is enabled.

1.6 Other System Management Commands

Perform the following configuration in system view.

Table 1-20 Force disconnection of Telnet

Service	Feature
Log in from the current VG to another device	telnet { ip-address \| host-name } [ service-port ]
Force disconnection of Telnet	kill telnet { all \| user-id id }
Make a user to exit from current login connection	logout
Erase the configuration files loaded to a device when it is starting	reset saved-configuration
Erase log statistics	reset syslog

Chapter 2 User Management

2.1 User Management Overview

A VG is not configured with a user name and password when it is powered on for the first time. In that condition, any user can perform configuration on the VG as long as connecting his PC with the VG through a Console port. The remote user can also access the VG via Telnet if the VG has been configured with an IP address of the Ethernet interface, the user name and the password. It is possible for the remote user to access the network by establishing PPPoE connection with the VG. To ensure the network security, it is necessary to configure a user and a password for the VG to facilitate the management of the user.

2.1.1 User Classification

According to the service for a user, the user of a VG can be classified into the following types:

l HyperTerminal user, accessing the VG through a Console port or AUX port;

l Telnet user, accessing the VG via Telnet command;

l FTP user, establishing FTP connection with the VG to transmit packets;

A user can have several services at the same time. In this way, one user can execute multiple functions.

2.1.2 User Authentication Schemes

The system authenticates users at login. There are three types of authentication schemes: non-authentication, local authentication, and AAA server authentication. Non-authentication is not preferred, because a user can log onto the VG without user name and password when it applies. When local authentication or AAA server authentication applies, however, a login user must provide the username and password that are the same as the ones configured on the VG or the AAA server. Dialup users are often authenticated through AAA servers whereas telnet and terminal users are authenticated at the local.

2.1.3 VG User Planning

Perform the VG user planning according to actual requirement. Usually, at least one HyperTerminal user (Console user) must be established on a VG, and it is needed to configure a Telnet user to meet the remote access requirement. You can configure an FTP user to enable the user to upload or download files on the VG from the remote.

This section focuses on the configuration of Telnet and HyperTerminal users. For the configuration of FTP users, refer to Chapter 1 “System Management”.

2.2 User Management Configuration

The user management configuration includes:

l Configure user name and password

l Configure user authentication mode

l Configure authentication scheme

The purpose of user authentication is to only enable the legitimate users to log on and use the VG.

& Note:

For related commands, refer to H3C VG Series Voice Gateways Command Manual – Security.

2.2.1 Configuring User Name and Password

Configure the user and the local authentication password in the local database.

Table 2-1 Configure username and password for local authentication

Operation	Command
Configure user name and password	local-user user-name [ password { simple \| cipher } password ]
Delete the user	undo local-user user-name

Authorized username in the range of 1 to 32 characters and the password can be in the range from 1 to 16 characters or numbers.

2.2.2 Authorizing Users to Use the Types of Services

You can configure the following four types of services available for the authorized users:

l Administrator: Authorizes the user as the administrator to log onto the VG via Telnet or other means (such as Console port) for configuration.

l guest: Authorizes the user as the guest.

l operator: Authorizes the user as the operator.

l ftp: FTP is available to authorized users.

When a single type of service is authorized in the operation, configure after service-type one parameter from administrator, guest, operator, and ftp. But to authorize a user with two service types, you need to configure two continuous parameters (for the three parameters administrator, operator, and guest, you can select only one.) after service-type instead of executing this command twice for this user. When using the command to a user repeatedly, new service will overwrite the old one.

If the service type is first configured as administrator, operator or guest, only FTP service is available as a consequent parameter. If the service type is configured as FTP, a consequent parameter can be administrator, operator or guest.

Table 2-2 Authorize users to use the types of services

Operation	Command
Authorize users to use the types of services	local-user username service-type { administrator \| guest \| operator \| ftp }
Delete the types of services available for users	undo local-user user-name

2.2.3 Configure User Authentication Mode

Perform the following configuration in system view.

Table 2-3 Configure the login authentication of AAA

Operation	Command
Configure the login authentication scheme	aaa authentication-scheme login { default \| scheme-name } { method [ method ] ... }
Delete the login authentication scheme	undo aaa authentication-scheme login { default \| scheme-name }

By default, the command aaa authentication-scheme login default local takes effect.

One to two Authentication scheme lists can be configured by the following:

l local: Perform the local authentication.

l radius: Perform the RADIUS authentication.

l none: Perform no authentication, that is, users can access the VG without being authenticated.

If you do not specify any authentication scheme list for a login type, the default list will be used.

2.2.4 Specifying Authentication Scheme

Specifying an authentication scheme starts the login authentication at the same time. Different authentication schemes apply to different login types.

VG supports the following login types: console (Console port), telnet (Telnet), ftp and http. Each login type uses different authentication scheme.

& Note:

If the type of administrator is not configured on the VG, the system performs the authentication for the login except that from the Console port or by HTTP.

Perform the following configuration in system view.

Table 2-4 Specify authentication scheme

Operation	Command
Specify authentication scheme for login users.	login-method authentication-mode login-type { default \| scheme-name }
Disable the authentication	undo login-method authentication-mode login-type

By default, the system authenticates all the login users using the default authentication scheme.

2.3 Displaying Local User Information

After configuring the user account, you can execute the following commands to display the user information.

Perform the following configuration in any view.

Table 2-5 Display user information

Operation	Command
Display the local user information	display local-user { command-history [ all \| brief \| index number \| username name ] \| level \| login-history [ all \| username name ] \| online }
Display the login user	display aaa user
View the online Telnet users	display client
Display the current login user	display level

For more information, refer to “Security” Part in Command Manual.

2.4 Clearing User Operation Information

The system administrator and operator can clear the commands which the log off user used to operate the VG in the past.

Table 2-6 Clear user operation information

Operation	Command
Clear user operation information	reset local-user history username

For the usage method, refer to “Security” Part in Command Manual.

2.5 Example of User Management

2.5.1 Configuring a Telnet Administrator account

I. Network requirements

Administrator can manage the VG by Telneting onto the VG.

II. Network diagram

Figure 2-1 Network diagram for the local authentication to the login user

III. Configuration procedure

# Enable AAA.

[VG] aaa-enable

# Configure a login user.

[VG] local-user admin service-type administrator password cipher admin

# Configure the VG to authenticate the login user.

[VG] aaa authentication-scheme login default local

[VG] login-method authentication-mode telnet default

Chapter 3 HTTP Server Configuration

3.1 HTTP Server Configuration

3.1.1 Introduction to HTTP Server

A VG can serve as an HTTP server, on which you can configure web pages. To configure and maintain the VG, you only need to use the browser on a PC to log into the VG in the HTTP manner, consequently reducing maintenance difficulty and cost.

3.1.2 HTTP Server Configuration

The following sections describe the HTTP server configuration tasks.

l Enabling/disabling HTTP server function

l Configuring a default language for the web login page

l Configuring a port number for the HTTP server

l Configuring sleeptime for the HTTP server

l Configuring timeout time for the HTTP server

I. Enabling/disabling HTTP server function

Perform the following configuration in system view.

Table 3-1 Enable/disable HTTP server function

Operation	Command
Enable HTTP server function	http-server enable
Disable HTTP server function	http-server disable

By default, the system enables HTTP server function.

II. Configuring a default language for the web login page

The default language for the web login page refers to the default language used on the user interface after a user logs in to the VG in the HTTP manner. You can change the user interface language through the Web interface.

Perform the following configuration in system view.

Table 3-2 Configure a default language for the web login page

Operation	Command
Configure a default language for the web login page	http-server language { chinese \| english }
Restore the default language for the web login page	undo http-server language

The factory language is english.

III. Configuring a port number for the HTTP server

Perform the following configuration in system view.

Table 3-3 Configure a port number for the HTTP server

Operation	Command
Configure a port number for the HTTP server	http-server port number
Restore the default port number for the HTTP server	undo http-server port

By default, the port number for the HTTP server is 80.

IV. Configuring sleeptime for the HTTP server

Perform the following configuration in system view.

Table 3-4 Configure sleeptime for the HTTP server

Operation	Command
Configure sleeptime for the HTTP server	http-server sleeptime { busy \| idle } time
Restore the default sleeptime for the HTTP server	undo http-server sleeptime { busy \| idle }

By default, in the case of connection, the sleeptime for the HTTP server is 5 seconds; in the case of disconnection, the sleeptime for the HTTP server is set to 80 seconds.

V. Configuring timeout time for the HTTP server

Perform the following configuration in system view.

Table 3-5 Configure timeout time for the HTTP server

Operation	Command
Configure timeout time for the HTTP server	http-server timeout { authen \| recv \| send } time
Restore the default timeout time for the HTTP server	undo http-server timeout { authen \| recv \| send }

By default, the timeout time of the HTTP server is 30 seconds.

3.2 Debugging HTTP Server

Execute the following command in any view.

Table 3-6 Display and debug HTTP Server

Operation	Command
Enable Web debugging	debugging web { error \| info \| memory \| warning }

Chapter 4 Network Management Configuration

4.1 SNMP Configuration

4.1.1 SNMP Overview

I. Introduction to SNMP

Simple network management protocol (SNMP), a widely accepted industry standard, is the most dominant network management protocol in computer networks by far. It is developed to ensure transmission of management information between any two nodes, which will facilitate network administrators to search for information at any node on the networks for the purpose of modifying, locating faults, troubleshooting, planning capacity and generating reports. Adopting the polling mechanism, SNMP provides essential functionality, and is suitable for a networking environment requiring small size, high speed and low cost. Since it uses the transport layer protocol UDP (User Datagram Protocol) which requires no acknowledgement, it gains wide support in many products.

SNMP system comprises NMS (network management station) and Agent. NMS is the workstation running the client application. It sends various request packets to the managed network devices, receives the response and trap packets from the managed devices, and displays status information of the managed devices. The Agent is a process running on the managed equipment. It receives and processes the request packets from NMS, and responds to NMS by returning the corresponding management variables obtained from the protocol module of the managed equipment. Whenever the Agent detects the occurrence of emergency events on the managed device, such as a change in the interface status a failed call, it will send traps to notify the NMS. The relationship between NMS and agent is shown in the following figure:

Figure 4-1 Relationship between NMS and agent

SNMP is the most widely applied communication protocol between NMS and Agent in the computer network.

II. Development of SNMP

SNMP experiences three versions: SNMPv1, SNMPv2c and SNMPv3. SNMPv3 defines a series of access control management functions for network security, in addition to the functions defined in SNMPv2c and SNMPv1. In other words, SNMPv3 develops SNMPv2c by adding security and management functions.

SNMPv1 and SNMPv2c lack security functions, especially in the aspect of authentication and privacy. SNMPv1 defines only a type of community representing a group of managed devices. Each NMS controls access to the devices through the community name list. However, agents do not verify whether the community names used by the senders are authorized, and they even do not check the IDs of administrators. Besides that, transmission of SNMP messages without encryption, which exposes the community name, brings potential threats to security. Even though some security mechanisms, like digest authentication, timestamp authentication, encryption and authorization, have been considered at the early stage of proposing SNMPv2c, only the “community name” similar to SNMPv1 is used in the final criterion of RFC 1901 through 1908. SNMPv2c is only a transitional version between SNMPv1 and SNMPv3. To avoid the lack of security in SNMPv1 and SNMPv2c, IETF develops the SNMPv3 protocol, which is described in RFC2271 through 2275 and RFC2570 through RFC2575 in details.

RFC2570 through RFC2575 supplements and subdivides SNMPv3 on the basis of RFC2271 through RFC2275, giving a complete and exact description of the processing of abnormal errors and the message processing procedure. The SNMPv3 framework thus defined has become a feasible standard.

Security of SNMPv3 is mostly represented by data security and access control.

1) Data security features provided in SNMPv3

Message-level data security provided in SNMPv3 includes the following three aspects:

l Data integrity. It ensures that data will not be tampered with by means of unauthorized modes and the data sequence will only be changed within the permitted range.

l Data origin authentication. It confirms which user the received data is from. Security defined in SNMPv3 is user-based. Hence, it authenticates the users that generate messages instead of the particular applications that are used to generate the messages.

l Data confidentiality. Whenever a NMS or agent receives a message, it will verify when the message is generated. If the difference between the generating time of message and the current system time exceeds the specified time range, the message will be rejected. Thereby, it ensures that the message has not been tampered with in-transit on the network and prevents processing of received malicious messages.

2) Access control in SNMPv3

As a security measure, access control defined in SNMPv3 implements a security check on the basis of protocol operations, thereby to controlling access to the managed objects.

MIB accessible to a SNMP entity is defined by the particular context. For security reasons, different groups and corresponding authorities probably need to be defined on one entity. The authorities are specified by the MIB view. A MIB view specifies a collection of managed object types in the context. The MIB view takes the form of a “view sub-tree” to define objects because MIB adopts the tree structure. If the flag of the object to be accessed belongs to the MIB sub-tree, the network administrator can access the device with read or write authority. Otherwise, the operations will be rejected.

III. SNMP architecture

An SNMP entity comprises one SNMP engine and multiple SNMP applications. The SNMP engine is the core of the SNMP entity. It transceives and authenticates SNMP messages, extracts PDU (Protocol Data Unit), reassembles messages, and communicates with the SNMP applications. SNMP applications process PDUs, implement protocol operations, and stores/gets MIB.

The SNMP engine comprises the scheduler, message processing sub-system, security sub-system, and access control sub-system. SNMP applications include the command generator, command responder, indication generator, indication receiver, and proxy transponder. The SNMP entity that owns the command generator or indication receiver is called the SNMP manager, and the SNMP entity that owns the command responder, indication generator or proxy transponder is called the SNMP agent. Nevertheless, an SNMP entity can have functions of both manager and agent.

4.1.2 Configuring SNMP

The following sections describe SNMP configuration tasks.

l Configuring network management agent on a VG

l Configuring SNMP version and related tasks

l Configuring information of VG administrator

l Configuring traps to be sent by the VG

l Configuring the maximum size of SNMP packets that the VG can send/receive

I. Configuring network management agent on a VG

Perform the following configurations in system view.

Table 4-1 Configure network management agent on a VG

Operation	Command
Enable SNMP service	snmp-agent
Disable SNMP service	undo snmp-agent
Set an engine ID for the equipment	snmp-agent local-engineid engineid
Restore the engine ID of equipment to the default value	undo snmp-agent local-engineid

By default, the system disables SNMP service.

Engine ID is the unique ID of individual VGs on the overall network. It is a string of 5 to 32 bytes in hexadecimal format. By default, the SNMP engine ID is “Corporation code of H3C + Equipment information”. Equipment information can be the IP address, MAC address or self-defined hexadecimal digit string.

& Note:

You can skip these two operations when you begin to configure SNMP for a VG because SNMP service will be enabled once you configure any related SNMP commands (except for the display commands). It is equivalent to configuring the snmp-agent command. Furthermore, the default engine ID can generally ensure the uniqueness of the VG on the network.

II. Configuring SNMP version and related tasks

The H3C series VGs support SNMPv1, SNMPv2c and SNMPv3.

SNMPv1 and SNMPv2c adopt a community name for authentication, and the SNMP packets that are not compliant with the community name authorized by the equipment will be discarded. Different groups can have either the read-only or read-write access authority. A group with the read-only authority can only query equipment information, whereas a group with read-write authority can configure the equipment. The authorities are specified by MIB views.

Security defined in SNMPv3 is user-based hence an SNMP user inherits the authority of the SNMP group to which it belongs. Different NMS have different access authority. An SNMP group can have read-only, read-write or notifying authority. The authorities of the SNMP group are also determined by MIB views.

Perform the following configurations in system view.

Table 4-2 Configure SNMP version and related tasks

Operation	Command
Select an SNMP version for NMS	snmp-agent sys-info version { v1 \| v2c \| v3 \| all }
Define the SNMP version(s) that NMS are not permitted to use	undo snmp-agent sys-info version { v1 \| v2c \| v3 \| all }
Create or update MIB view information	snmp-agent mib-view { included \| excluded } viewname subtree subtree
Delete a view	undo snmp-agent mib-view view-name
Set name and access authority for a community	snmp-agent community { read \| write } community_name [ mib-view view-name ] [ acl number ]
Remove the previous community name	undo snmp-agent community community_name
Set an SNMP group	snmp-agent group { v1 groupname \| v2c groupname \| v3 groupname { authentication \| noauthentication \| privacy } } [ read-view readview ] [ write-view writeview ] [ notify-view notifyview ] [acl number ]
Delete an SNMP group	undo snmp-agent group { v1 groupname \| v2c groupname \| v3 groupname { authentication \| noauthentication \| privacy } }
Add a new user to an SNMP group and specify the SNMP version as well as the authentication/encryption mode	snmp-agent usm-user { v1 username groupname \| v2c username groupname \| v3 username groupname [ authentication-mode { md5 \| sha } auth-password [ privacy-mod des56 priv-password ] ] } [ acl number ]
Delete a user from the SNMP group	undo snmp-agent usm-user { v1 username groupname \| v2c username groupname \| v3 username groupname }

By default, SNMPv3 is used. The default view name in the system is ViewDefault, and OID of which is 1.3.6.1. The view information “ViewDefault included 1.3.6.1 excluded 1.3.6.1.6.3.15 1.3.6.1.6.3.16 1.3.6.1.6.3.18” means the 1.3.6.1MIB subtree is included, but the three subtrees 1.3.6.1.6.3.15, 1.3.6.1.6.3.16 and 1.3.6.1.6.3.18 are excluded. SNMP group has only the read-only authority by default.

& Note:

l If SNMPv1/SNMPv2c is used, the community name or SNMPv1/SNMPv2c groups and users should be configured. If SNMPv3 is used, SNMPv3 groups and users should be configured.

l Before configuring an SNMP group, you should first define a view, which will be used for configuring the SNMP group (or you may use the system default view ViewDefault if you do not define the view). If you do not specify a view, the system will use the view ViewDefault. When configuring the community name, however, specifying a view is optional.

III. Configuring information of VG administrator

You should correctly configure information describing location and management of the local equipment so that the network administrator contact with the equipment administrator.

Perform the following configurations in system view.

Table 4-3 Configure information of VG administrator

Operation	Command
Set the administrator ID and the contact method	snmp-agent sys-info contact string
Restore the default administrator ID and the contact method	undo snmp-agent sys-info contact
Set VG location information	snmp-agent sys-info location string
Restore the default VG location	undo snmp-agent sys-info location

IV. Configuring traps to be sent by the VG

Traps are unsolicited messages that a managed device sends to an NMS for reporting some urgent and significant events. When a VG works as a managed device, you should configure the destination and source addresses of the trap that it will send. The destination address is the IP address of the NMS receiving the trap packet, and the source address is the address of the local VG, that is, the address of an interface on the local VG.

Perform the following configuration in system view.

Table 4-4 Configure the traps to be sent by the VG

Operation	Command
Enable the VG to send traps	snmp-agent trap enable [ trap-type ]
Disable the VG to send traps	undo snmp-agent trap enable [ trap-type ]
Specify the interface whose address is bound as the source address in the trap messages	snmp-agent trap source interface-type interface-number
Remove the interface whose address is bound as the source address in the trap messages	undo snmp-agent trap source
Set the address of host receiving the traps	snmp-agent target-host trap address host-addr [ port port ] [ parameters { v1 \| v2c \| v3 { authentication \| noauthentication \| privacy } } ] securityname name
Remove the address of host receiving the traps	undo snmp-agent target-host trap address host-addr [ port port ] securityname name
Set the message queue length of traps destined to a host	snmp-agent trap queue-size length
Restore the default message queue length	undo snmp-agent trap queue-size
Set the timeout time for traps	snmp-agent trap life timeout
Restore the default timeout time for traps	undo snmp-agent trap life

By default, the VG is disabled to send traps.

V. Configuring the maximum size of SNMP packets that the VG can send/receive

Set the Max SNMP messages that can be received/sent by the Agent according to the network loading capacity.

Perform the following configurations in system view.

Table 4-5 Configure the maximum size of SNMP packets that the agent can send/receive

Operation	Command
Set the maximum size of SNMP packets that the agent can receive/send	snmp-agent packet max-size byte-count
Restore the default maximum size of SNMP packets	undo snmp-agent packet max-size

The maximum size of SNMP packets ranges from 484 to 17,940 (in bytes). By default, the maximum size is 1,500 bytes.

4.1.3 Displaying and Debugging SNMP

Execute the following commands in any view.

Table 4-6 Display and debug SNMP

Operation	Command
Display the statistics of SNMP packets	display snmp-agent statistics
Display the current equipment engine ID	display snmp-agent local-engineid
Display information of system location	display snmp-agent sys-info location
Display system contact information	display snmp-agent sys-info contact
Display information of SNMP groups on the router	display snmp-agent group
Display information of all SNMP V3 users in the group user name list	display snmp-agent usm-user
Display the group names that have been configured	display snmp-agent community
Display information of the MIB views that have been configured	display snmp-agent mib-view
Enable SNMP debugging	debugging snmp { headers \| packets \| trap \| process }

4.1.4 SNMP Configuration Example

I. Example 1: Configuring network management of SNMPv1

1) Network requirements

Take the following diagram as an example. NMS and a VG are connected through the Ethernet. The IP addresses of NMS and the Ethernet interface on the VG are respectively 129.102.149.23 and 129.102.0.1.

2) Network diagram

Figure 4-2 Network diagram for SNMP configuration

3) Configuration procedure

# Enable the VG to support SNMP and select an SNMP version.

[VG] snmp-agent

[VG] snmp-agent sys-info version v1

# Set the community name and access authority.

[VG] snmp-agent community read public

[VG] snmp-agent community write private

# Set the ID of administrator, contact method and physical location of the router.

[VG] snmp-agent sys-info contact Mr.Wang-Tel:3306

[VG] snmp-agent sys-info location telephone-closet,3rd-floor

# Enable the VG to send traps to NMS (129.102.149.23) and use the community name “public”, and set the source address in the traps to be the IP address of the interface ethernet 0.

[VG] snmp-agent trap enable

[VG] snmp-agent target-host trap address 129.102.149.23 securityname public

[VG] snmp-agent trap source ethernet 0

# Configure an IP address for the Ethernet interface ethernet 0.

[VG] interface ethernet 0

[VG-Ethernet0] ip address 129.102.0.1 255.255.0.0

II. Example 2: Configuring network management of SNMPv3

1) Network requirements

l According to the networking of Example 1, NMS is connected to the VG through the Ethernet, and their IP addresses are respectively 129.102.149.23 and 129.102.0.1.

l SNMPv3 is required. Three SNMP groups will be configured and respectively authorized with read-only writing and notifying rights. Three SNMP users are respectively belong to the three groups respectively, and three MIB views are used as read, write and notify views respectively.

l Information of the network administrator is required to be configured.

l Requires if traps are to be sent, that the IP address of the interface ethernet 0 is the source address of the traps, and the address of the NMS is the destination address.

2) Network diagram

Refer to the network diagram of Example 1.

3) Configuration procedure

# Enable the VG to support SNMP and select an SNMP version.

[VG] snmp-agent

[VG] snmp-agent sys-info version v3

# Set SNMP groups, users and views.

[VG] snmp-agent mib-view included read_view subtree 1.3.6.1

[VG] snmp-agent mib-view included write_view subtree 1.3.6.1.4

[VG] snmp-agent mib-view excluded notify_view subtree 1.3.6.1.2.1.47

[VG] snmp-agent group v3 group_read noauthentication read-view read_view

[VG] snmp-agent group v3 group_write privacy write-view write_view

[VG] snmp-agent group v3 group_notify authentication notify-view notify_view

[VG] snmp-agent usm-user v3 user_read group_read

[VG] snmp-agent usm-user v3 user_write group_write authentication md5 123 privacy-mod des56 asdf

[VG] snmp-agent usm-user v3 user_notify group_notify authentication md5 qwer

# Configure information of equipment administrator

[VG] snmp-agent sys-info contact Mr.Wang-Tel:3306

[VG] snmp-agent sys-info location telephone-closet,3rd-floor

# Configure the VG to send Traps to the host whose IP address is 129.102.149.23.

[VG] snmp-agent trap enable

[VG] snmp-agent target-host trap address 129.102.149.23 securityname user_notify parameters v3 auth

[VG] snmp-agent trap source ethernet 0

# Configure an IP address for the Ethernet interface ethernet 0

[VG] interface ethernet 0

[VG-Ethernet0] ip address 129.102.0.1 255.255.0.0

4.2 Minimum MIB of VG

4.2.1 Introduction to Minimum MIB of VG

The VG provides minimum MIB to enable users to implement basic management through SNMP when the VG is in default configuration.

Table 4-7 Minimum MIB of VG

Minimum MIB	Function
RFC1213, RFC2233	NMS can manage and inquire the Ethernet interface information.
RFC2737	NMS can draw accurately the device panel under its management.
h3c-sys-man, h3c-flash-man	NMS can back up and upgrade the version files and configuration files on a device and specify a start policy for the device.
h3c-entity-ext	NMS can inquire and set the CPU and memory utilization and other information of a device.

4.2.2 Configuring the Minimum MIB of VG

Configuring the minimum MIB of VG involves:

l Enabling the Trap for sending the minimum MIB

l Configuring a CPU threshold

l Configuring a memory threshold

I. Enabling sending of the minimum MIB Trap packets

To make the VG send a Trap alarm packet to the preset Trap host whenever the CPU and memory occupancies exceed the designated thresholds, you must first enable sending of the minimum MIB Trap.

Perform the following configuration in system view.

Table 4-8 Enabling sending of the minimum MIB Trap packets

Operation	Command
Enable sending of the minimum MIB Trap packets	snmp trap enable mmib
Disable sending of the minimum MIB Trap packets	undo snmp trap enable mmib

By default, sending of the minimum MIB Trap packets is disabled.

II. Configuring a CPU threshold

When the CPU occupancy exceeds the preset threshold, the VG will send a Trap alarm packet to the NMS.

Perform the following configuration in system view.

Table 4-9 Configuring a CPU threshold

Operation	Command
Configure a CPU threshold	mmib-set-thread CPU-Threshold value

The CPU threshold value ranges from 0 to 100, with a default value of 80, namely 80% of the CPU capacity.

III. Configuring a memory threshold

When the memory occupancy exceeds the preset threshold, the VG will send a Trap alarm packet to the NMS.

Perform the following configuration in system view.

Table 4-10 Configuring a memory threshold

Operation	Command
Configure a memory threshold	mmib-set-thread Memory-Threshold value

The CPU threshold value ranges from 0 to 100, with a default value of 80, namely 80% of the memory capacity.

4.3 IAD Configuration

4.3.1 Introduction to IADMS

IADMS provides supports for MIBs that comply with IAD standard. By extending a standard MIB, it can also support HCMS. This enables HCMS to manage H323-enabled VG as IAD devices through SNMP.

IADMS is designed to deal with:

l Function requirements concerning the basic system information of devices

l Function requirements concerning management and registration rules for devices that are to be under the management of HCMS to comply with

l Function requirements concerning H323 related configuration of devices

4.3.2 IADMS Configuration

The following sections describe IADMS configuration tasks:

l Entering IAD configuration view

l Assigning IP addresses to primary IADMS

l Configuring an IADMS register key for an IAD device

l Configuring an IADMS operator key for an IADMS device

l Enabling an IAD device to send registering packets regularly

l Enabling a VG to send handshaking packets regularly

l Setting the interval to send handshaking packets

l Enabling IAD mode

1) Entering IAD configuration view

To perform IADMS command related configuration, you need to enter IAD configuration view first.

Perform the following configuration in system view.

Table 4-11 Enter IAD configuration view

Operation step	Command
Enter IAD configuration view	iad

2) Assigning IP addresses to primary IADMS

To manage IAD devices, an IADMS device must be assigned an IP address first. You can assign IP addresses to IADMS devices through an IAD device. And an IAD device can be managed by the primary IADMS device.

Perform the following configuration in IAD configuration view.

Table 4-12 Assign an IP address to the primary IADMS device

Operation	Command
Assign an IP address to the primary IADMS device	iadms-address master ip-address
Remove the IP address of the primary IADMS device	undo iadms master

A primary IADMS device is not assigned an IP address by default.

3) Configuring an IADMS register key for an IAD device

To register with IADMS successfully, the registering packet sent by an IAD device must carry an IADMS register key with it.

Perform the following configuration in IAD configuration view.

Table 4-13 Configure an IADMS register key for an IAD device

Operation	Command
Configure an IADMS register key	registerKey { cipher \| simple } word
Remove the IADMS registration key	undo registerKey

An IAD device is not configured with an IADMS registration key by default.

4) Configuring an IADMS operator key for an IADMS device

To modify a specific setting of an IAD device, IADMS must send packets with the IADMS operator keys carried in the packets.

Perform the following configuration in IAD view.

Table 4-14 Configure an IADMS operator key for ADMS

Operation	Command
Configure an IADMS operator key for IADMS	operatorKey { cipher \| simple } word
Remove the IADMS operator key	undo operatorKey

IADMS is not configured with an IADMS operator key by default.

5) Enabling an IAD device to send registering packets regularly to IADMS

After initiating, an IAD device sends registering packets to IADMS regularly for the IAD device to be under the management of IADMS. Disabling an IAD device from sending registering packets causes it not being under the management of IADMS.

Perform the following configuration in IAD view.

Table 4-15 Enable an IAD device to send registering packets regularly to IADMS

Operation	Command
Enable an IAD device to send registering packets regularly to IADMS	registering enable
Disable an IAD device from sending registering packets	registering disable

A VG sends registering packets to IADMS regularly by default.

6) Enabling a VG to send handshaking packets regularly

After an IAD device registers with IADMS successfully, you can enable it to send handshaking packets regularly to IADMS, through which the state of the IAD device can be known to IADMS.

Perform the following configuration in IAD view.

Table 4-16 Enable a VG to send handshaking packets regularly

Operation	Command
Enable a VG to send handshaking packets regularly to IADMS	handshake send enable
Disable a VG from sending handshaking packets regularly	handshake send disable

By default, A VG sends handshaking packets regularly to IADMS.

7) Setting the interval to send handshaking packets

After an IAD device registers with IADMS successfully, you can enable it to send handshaking packets to IADMS regularly, through which the state of the IAD device can be known to IADMS. You can also set the interval for the IAD device to send handshaking packets according to the operating state of the network. The default interval is 60 seconds.

Perform the following configuration in IAD view.

Table 4-17 Set the interval to send handshaking packets

Operation	Command
Set the interval to send handshaking packets	handshake interval number

By default, A VG sends handshaking packets regularly to IADMS with a default interval of 60 seconds.

8) Enabling IAD mode

With IAD mode enabled, an IAD device checks to see if the required configuration is correct. If yes, it then sends registering packets to IADMS.

Perform the following configuration in IAD view.

Table 4-18 Enable IAD mode

Operation	Command
Enable IAD mode	iadmode-on
Disable the IAD device from sending registering packets to IADMS	undo iadmode-on

IAD mode is disabled by default.

Chapter 5 Display and Debugging Tools

5.1 display Command Set

Using the display commands, you can view system status and system information. In terms of function, theses commands can be grouped as

l Commands to display system configuration information

l Commands to display system running status

l Commands to display system statistics

Execute the display command in any views to query system information. As for the commands to display the information associated with various protocols and interfaces, refer to other chapters in this manual.

Execute the following commands in any view.

Table 5-1 Display system information

Operation	Command
Display current terminal user	display client
Display the system clock	display clock
Display status of the debugging switches	display debugging
Display history record of the command input	display history-command
Display VG name	display systname
Display current system configuration information	display current-configuration
Display initial system configuration information stored in VG Flash	display saved-configuration
Display basic system configuration information	display base-information [ page ]
Display system version information	display version

5.2 debugging Command Set

The VG provides abundant debugging commands, almost for all protocols and functions available in the VG, to assist network fault diagnosis and troubleshooting.

Two switches control the output of the debugging information:

l Debugging switch, which controls whether to test a certain function /module /protocol.

l Syslog output switch, which controls whether to output the debugging information to the console, Telnet terminal or internal buffer or log host.

For more specific debugging commands related to various protocols functions, please see other chapters in this manual.

The large amount of debugging information generated when the debug switch is enabled may result in low efficiency of the system. Especially, when all debug switches are enabled with the debugging all command, the system may down. So it is not recommended to use the debugging all command. You can also use the undo debugging all command to disabled all debug switches at one time.

The VG provides a shortcut <Ctrl+D> to close the huge amount of debugging information output from the terminal, which functions the same as the command undo debugging all.

In addition, when any terminal user enables or disables the debugging, the debugging information output on other users’ terminals will be affected.

As for all link layer protocols, the debugging can be controlled according to interfaces, so that the interference of a huge amount of redundant information can be avoided effectively and it makes troubleshooting more convenient.

On the VG, Syslog manages the output of debugging information and other prompt information. Before obtaining the debugging information, you need to open the Syslog switch. Firstly, you must use the info-center enable command to enable Syslog function, then you can use the info-center console or info-center monitor command to enable debugging according to the different type of the terminal, or use the info-center console debugging command on the Console terminal, or use info-center monitor debugging on the telnet terminal. Refer to subsequent sections for introduction and detailed descriptions and commands of Syslog.

& Note:

Since debugging information output shall affect the running efficiency of the VG, do not enable debugging switches unless necessary, especially using the debugging all command. After completing debugging, please disable all debugging switches.

5.3 Network Interconnection Diagnostic Tool

5.3.1 ping Command

Using the ping command in any views, you can check whether the destination host is reachable.

Table 5-2 ping

Operation	Command
ping available in IP protocol	ping [ -a ip-address ] [ -c count ] [ -d ] [ -f ] [ -n ] [ -o ] [ -p pattern ] [ -q ] [ -R ] [ -r ] [ -s packetsize ] [ -t timeout ] [ -v ] [ -i TTL ] { ip-address \| host }

Please see relevant chapters in this manual for details of various options and parameters.

For each ping message sent, if the response message has not been received when the waiting time crosses the threshold, then “Request time out” is output. Otherwise, the data byte number, message sequence number, TTL, and response time in the response message will be displayed.

Finally, the statistic information will be output, including the sent message number, received response message number, percentage of messages not being responded , and the minimum, average, and maximum values of the response time.

[VG] ping 202.38.160.244

ping 202.38.160.244 : 56 data bytes, press CTRL_C to break

Reply from 202.38.160.244 : bytes=56 sequence=1 ttl=255 time = 1ms

Reply from 202.38.160.244 : bytes=56 sequence=2 ttl=255 time = 2ms

Reply from 202.38.160.244 : bytes=56 sequence=3 ttl=255 time = 1ms

Reply from 202.38.160.244 : bytes=56 sequence=4 ttl=255 time = 3ms

Reply from 202.38.160.244 : bytes=56 sequence=5 ttl=255 time = 2ms

--202.38.160.244 ping statistics--

5 packets transmitted

5 packets received

0% packet loss

round-trip min/avg/max = 1/2/3 ms

5.3.2 tracert Command

The trace route Command helps to trace the current network path to a destination. With tracert command, all gateways by which the test packet passes from the source address to the destination address can be displayed. It can mainly be used to check network connection and locate fault.

The tracert command is executed as follows: first, send a packet with TTL 1, and the first hop returns an ICMP error message, indicating that this packet cannot be sent (for TTL timeout). Then, this packet is re-sent with TTL added by 1 (namely 2). Similarly, the next hop returns TTL timeout. In this way, the procedure continues till the destination is reached. The purpose of these procedures is to record the source address of each ICMP TTL timeout message, so as to provide the path by which an IP packet has to pass to reach the destination address.

Perform the following configuration in any views.

Table 5-3 tracert

Operation	Command
Display the path from the source address to the destination address	tracert [ -a ipaddress \| -f first_TTL \| -m max_TTL \| -p port \| -q number \| -w timeout ]* { ip-address \| host }

5.4 Information Center

5.4.1 Information Center Overview

As an indispensable part of the VG, Information center serves as the information junction of system software module. The information center is responsible for most of the information output and can perform detailed classification so as to filter information effectively. In combination with the debugging command, the system provides powerful support for the network administrator and development staff to monitor the network running state and diagnose the network faults.

The following are the features of VG information center:

l Support log output in four directions, i.e. to the Console, to the telnet terminal (Monitor), to the internal buffer (Buffer), and to the log host (Loghost).

l Log information is divided into eight levels by importance and the filtering is based on these levels.

l Information is classified by source module and the filtering is based on these modules.

5.4.2 Configuring Information Center

The information center configuration tasks include

l Setting information output direction

l Setting information severity

l Filtering information

l Enabling/disabling information center

I. Setting information output direction

As aforementioned, the VG can output information to four directions:

l To Console Via Console port

l To Telnet terminal (Monitor), for remote maintenance

l To internal buffer, for information recording

l To log host (stored in text format), for future review

Perform the following configurations in system view.

Table 5-4 Set information output direction

Operation	Command
Enable to output information to local Console	info-center console
Disable to output information to local Console	undo info-center console
Enable to output information to the terminal	info-center monitor
Disable to output information to the terminal	undo info-center monitor [ all ]
Enable to output information to internal buffer	info-center logbuffer
Disable to output information to internal buffer	undo info-center logbuffer
Define internal buffer size for information output	info-center logbuffer size
Enable to output information to all directions	info-center loghost
Disable to output information to the log host	undo info-center loghost

By default, information is output to the Console and Monitors.

& Note:

l The setting of information output direction will not be effective unless the information center is enabled.

l The settings to output information to four directions are independent. Disabling to output information in a direction will not affect the output to other directions.

l When there are multiple Telnet users simultaneously, they can share the same configuration parameters, which include the filtering information by module, Chinese/English switching and severity threshold. When a user changes the values of these parameters, other user terminals will also be affected. At this time, the undo info-center monitor command can only disable information output on a specific terminal. To disable information output on all Telnet terminals, use the undo info-center monitor all command.

II. Setting information severity

The information in the information center is grouped into eight severity levels. The rule to filter the information by severity is: the more urgent the log information is, the less severe it will be. The information with severity higher than the set threshold is forbidden to be output. Only the information with severity no higher than this threshold can be output.

Perform the following configuration in system view.

Table 5-5 Enable to output information of certain priority level

Operation	Command
Enable to output information of certain priority level to the local Console	info-center console [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 ] ]
Disable to output information of certain priority level to the local Console	undo info-center console [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter ] ]
Enable to output information of certain priority level to the terminal	info-center monitor [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 facility2 … ] ]
Disable to output information of certain priority level to the terminal	undo info-center monitor [ all ] [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 facility2 … ] ]
Enable to output information of certain priority level to internal buffer	info-center logbuffer [ size ] [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 facility2… ] ]
Disable to output information of certain priority level to internal buffer	undo info-center logbuffer [ size ] [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 facility2 … ] ]
Enable to output information of certain priority level to the log host	info-center loghost loghost-number ip-address [ port [ emergencies \| alerts \| critical \| errors \| warnings \| notifications \| informational \| debugging ] [ filter [ facility1 facility2 …] ] ]
Disable to output information of certain priority level to the log host	undo info-center loghost [ loghost-number [ port \| filter ] ]
Disable the output information of certain priority level to all the directions	undo info-center { console \| monitor \| logbuffer \| loghost}

The following table defines the severity levels defined in the information center:

Table 5-6 Severity levels defined in the information center

Severity level	Description
emergencies (0)	Most severe/emergent fault
alerts (1)	Fault needs to be corrected immediately
critical (2)	Major fault
errors (3)	Noticeable but not major fault
warnings (4)	Cautions, it's possible there may be a fault
notifications (5)	Information needs to pay attention to
informational (6)	Ordinary prompt information:
debugging (7)	Debugging information

III. Filtering information

In different output modes, the Filter can be set according to the source of log information. Only the log information complying with the Filter definition can be output.

Perform the following configuration in system view.

Table 5-7 Filtering information

Operation	Command
Set Filter of the Console	info-center console filter module
Delete Filter of the Console	undo info-center console filter
Set terminal Filter	info-center monitor filter module
Delete terminal Filter	undo info-center monitor filter
Set Filter of internal buffer	info-center logbuffer filter module
Delete Filter of terminal buffer	undo info-center logbuffer filter
Set Filter of log host	info-center loghost loghost-number ip-address port-number filter module
Delete Filter of log host	undo info-center loghost loghost-number { port-number } filter

Here, module stands for the module name. Only the log information related to a specified module can be filtered and output.

IV. Enabling/disabling information center

Perform the following configurations in system view.

Table 5-8 Enable/disable information center

Operation	Command
Enable information center	info-center enable
Disable information center	undo info-center enable

& Note:

When info-center is enabled, the system performance may be affected due to the information classification and output - especially when processing a large amount of information.

V. Enabling/disabling all system logs

Perform the following configuration in system view.

Table 5-9 Enable/disable all system logs

Operation	Command
Enable all system logs	info-center syslog
Disable all system logs	undo info-center syslog

VI. Erasing log statistics

Perform the following configuration in system view.

Table 5-10 Erase log statistics

Operation	Command
Erase log statistics	reset syslog

5.4.3 Displaying and Debugging Information Center

Perform the display commands in any views.

Table 5-11 Display and debug information center

Operation	Command
Display basic configuration information of the information center	display info-center
Display internal buffer information of the information center	display info-center logbuffer

5.4.4 Information Center Configuration Example

I. Configuring log host

The configuration, implemented on SunOS 4.0, is almost the same as that performed on the Unix operating system of other manufacturers.

1) Execute following commands as root (superuser)

# mkdir /var/log/H3C

# touch /var/log/H3C/config

# touch /var/log/H3C/security

2) As root, edit the file /etc/syslog.conf and add the following selector/action pairs.

# H3C configuration messages

Local4.crit /var/log/H3C/config

& Note:

When editing /etc/syslog.conf, pay attention to the following:

l The comments can only be in separate lines, beginning with character #.

l The selector/action pairs must be separated with one Tab instead of a space.

l There must not be redundant spaces behind the file name.

3) When log files like config and security are created and /etc/syslog.conf file is modified, an HUP will be sent to the system daemon, Syslogd, by executing the following commands to make Syslogd re-read its configuration file /etc/syslog.conf.

# ps -ae | grep syslogd

147

# kill -HUP 147

After the above operations, the VG can record information in relevant log files.

& Note:

Comprehensive configuration of Facility (device name), Severity (severity threshold), Filter, and syslog.conf file can make a detailed classification of information, for information filtering.

II. Configuring information center

1) Configuring information output of the Console

# Enable information center.

[VG] info-center enable

# Configure the log information output of the control console, severity ranging between emergencies ~ debugging, and not filtering the log information output of PPP module.

[VG] info-center console

[VG] info-center console debugging

# Enable PPP module debugging.

[VG] degugging ppp all

2) Configuring log host on a VG.

# Enable information center.

[VG] info-center enable

# Use the host with IP address of 10.110.12.119 as the log host, and set the severity threshold to informational.

[VG] info-center loghost 0 10.110.12.119 514 informational

Refer to section 5.4.4 I. Configuring log host for the host-end configuration.

TOP

H3C reserves the right to modify its collaterals without any prior notice. For the latest information of the collaterals, please consult H3C sales or call 400 hotline.