Feature Description - Basic Configurations (Nonx1x2) (V600R003C00 - 02)

HUAWEI NetEngine80E/40E Router
V600R003C00
Feature Description - Basic

Configurations
Issue 02
Date 2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2011-09-10) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Feature Description - Basic Configurations About This Document
About This Document
Purpose
This document describes the basic configurations in terms of its overview, principles, and
applications.
This document together with other types of documents helps intended readers get a deep
understanding of the basic configurations.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine80E/40E V600R003C00

Router
Intended Audience
This document is intended for:
l Network planning engineers
l Commissioning engineers
l Data configuration engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Issue 02 (2011-09-10) Huawei Proprietary and Confidential ii

Feature Description - Basic Configurations About This Document
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
DANGER
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which if not

avoided, could result in equipment damage, data loss,
CAUTION
performance degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save
time.
NOTE Provides additional information to emphasize or supplement

important points of the main text.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 01 (2011-09-10)

The second commercial release has the following updates:
There is no update compared with the previous issue.
Changes in Issue 01 (2011-05-30)

Initial field commercial release.
Issue 02 (2011-09-10) Huawei Proprietary and Confidential iii

Feature Description - Basic Configurations Contents
Contents
About This Document.....................................................................................................................ii

1 VRP Overview................................................................................................................................1
1.1 Overview............................................................................................................................................................2
1.1.1 VRP Introduction.......................................................................................................................................2
1.1.2 Development of the VRP...........................................................................................................................2
1.2 VRP Architecture...............................................................................................................................................4
1.2.1 NOS Model................................................................................................................................................4
1.2.2 System Plane..............................................................................................................................................5
1.2.3 SCP............................................................................................................................................................6
1.2.4 DFP............................................................................................................................................................6
1.2.5 GCP...........................................................................................................................................................7
1.2.6 SMP...........................................................................................................................................................8
1.2.7 SSP.............................................................................................................................................................8
1.3 VRP System Features.........................................................................................................................................8
1.3.1 Componentized Structure..........................................................................................................................8
1.3.2 License.......................................................................................................................................................9
1.3.3 HA.............................................................................................................................................................9
2 Basic Configuration.....................................................................................................................10
2.1 Introduction to Basic Configuration.................................................................................................................11
2.2 References........................................................................................................................................................11
2.3 Principles..........................................................................................................................................................13
2.3.1 FTP..........................................................................................................................................................13
2.3.2 TFTP........................................................................................................................................................17
2.3.3 Introduction to Telnet..............................................................................................................................18
2.3.4 SSH..........................................................................................................................................................24
2.3.5 User Management....................................................................................................................................30
2.3.6 Virtual File System..................................................................................................................................33
2.3.7 Pipe Character..........................................................................................................................................35
2.3.8 Daylight Saving Time..............................................................................................................................36
2.3.9 Timing Restart.........................................................................................................................................36
2.3.10 MIB Interface Is Used to Optimize System Upgrade............................................................................36
2.3.11 NAP.......................................................................................................................................................37
Issue 02 (2011-09-10) Huawei Proprietary and Confidential iv

Feature Description - Basic Configurations Contents
2.4 Applications......................................................................................................................................................42
2.4.1 Applications of FTP.................................................................................................................................42
2.4.2 Applications of TFTP..............................................................................................................................42
2.4.3 Applications of Telnet.............................................................................................................................43
2.4.4 Applications of SSH................................................................................................................................43
2.5 Terms and Abbreviations..................................................................................................................................47
3 Fast Startup...................................................................................................................................49
3.1 Introduction to Fast Startup..............................................................................................................................50
3.2 References........................................................................................................................................................50
3.3 Principles..........................................................................................................................................................50
3.3.1 Fast Startup After a Software Fault.........................................................................................................51
3.3.2 Fast Startup After a Hardware Fault........................................................................................................51
3.3.3 Upgrade and Cold Startup.......................................................................................................................51
3.3.4 Performance Statistics for Software-based Fast Startup..........................................................................51
3.4 Applications......................................................................................................................................................51
4 Clock Synchronization...............................................................................................................53
4.1 Introduction......................................................................................................................................................54
4.2 References........................................................................................................................................................54
4.3 Principles..........................................................................................................................................................54
4.3.1 Basic Concepts........................................................................................................................................54
4.3.2 Clock Protection Switching.....................................................................................................................57
4.3.3 Synchronization Mode and Issues of Concern........................................................................................59
4.3.4 Networking Mode for Clock Synchronization........................................................................................61
4.4 Application.......................................................................................................................................................62
Issue 02 (2011-09-10) Huawei Proprietary and Confidential v

Feature Description - Basic Configurations 1 VRP Overview
1 VRP Overview
About This Chapter
This chapter introduces the features of the VRP.
1.1 Overview
This section describes the primary functions and the evolution of the VRP.
1.2 VRP Architecture
This section describes the structure and functions of the VRP system plane.
1.3 VRP System Features
This section covers three system-level features.
Issue 02 (2011-09-10) Huawei Proprietary and Confidential 1

1.1 Overview
This section describes the primary functions and the evolution of the VRP.
1.1.1 VRP Introduction

The Versatile Routing Platform (VRP) is a Network Operating System (NOS) of the data
communication products developed by Huawei Technologies Co., Ltd.
Before introducing the VRP, we present a brief definition of the NOS.
NOS
NOS is a type of system software used to realize network access and provide interconnection
services.
The primary functions of the NOS are as follows:
l Allocating and transferring system resources
l Providing network communication services
l Providing user access control and system security management
l Providing application management
With the expansion of network scale and the rapid development of Internet technologies, an
efficient and stable NOS becomes the key to guarantee network services and service quality.
VRP
Similar to the NOS, the VRP is the nerve center to Huawei products, ranging from low-end to
core routers, Ethernet switches to service gateway.
The VRP has the following functions:
l Unified user interface and management interface: the unified kernel of real-time operating
system, IP forwarding engine, IP routing, and configuration management plane.
l Control plane, interface criterion on the forwarding plane, interaction between link layer
of various products and the VRP control plane
l Shielding link layer discrepancy from the network layer through the network interface layer
1.1.2 Development of the VRP

In line with the rapid growth of network technologies and applications, the VRP is constantly
improved in processing mechanism, service capability, and product supporting.
Figure 1-1 illustrates the main VRP versions in the history.

Figure 1-1 VRP evolving history

Feature
OAM,
Reliability
Switching
feature
IPv6 Multicast
MAN access
Multi-chassis VRP5.10 VRP5.30 VRP5.50 VRP5.60 VRP5.70
cascading
Distributed VRP3.0 VRP3.x
Centralized VRP1.x
Time
The features of each version are described as follows:
l VRP1.x
Centralized bus-shared structure
Centralized CPU forwarding
All the softwares running on the Main Processing Unit (MPU)
l VRP3.0 to 3.x
Distributed bus-shared structure
Distributed forwarding (CPU/NP)
Routing protocols and other management softwares running on the MPU
Forwarding table on interface card
l VRP5.10
Componentized structure
IPv6 Protocol
High availability: system level hot standby (HSB) and Graceful Restart (GR)
l VRP5.30
Distributed plus switching structure
Network operation-supported features: MPLS OAM and BFD
MAN access and switching features: RPR, MSTP, VPLS, and L2VLAN
Newly added services: PWE3 and multicast Inter-AS VPN
l VRP5.50
Enhancement of VRP5.30 operation and support features
Enhancement of the MAN access and switching features of VRP5.30
Newly added service: IPv6 Multicast
l VRP5.60
Multi-chassis cascading

Support features of network operation: HGMP, SNMP for IPv6, binary logs, and regular
expressions in display commands
MAN access and switching features: EVRRP, DHCP snooping over VPLS, VPLS/
HVPLS supporting ECMP, DHCP relay supporting multiple secondary addresses, DS-
TE, and unequal cost load balancing
Newly added service: multicast CAC
l VRP5.70
Optimized VRP architecture: improved route convergence performance, shortened
startup period of the device, preferential iteration of IGP routes, restriction on the
number of BGP routes in a BGP VPN instance, next-hop separation supported by BGP/
VPN routes, independent selection of routes, dynamic update peer-groups, and next-
hop-based label allocation for VPN routes on ASBRs
Scheme of flexible access to VPNs and complete FMC
Improved IPv6 and more IPv6 solutions: BFD6 for IS-IS, BFD6 for OSPFv3, BFD6
for static routes/RM/BGP4+, and BFD6 for PIM6.
Newly added layer 2 features to support switches.
High reliability: multicast GR, multicast load balancing, IS-IS/BGP NSR, BGP auto
FRR, and enhanced IS-IS FRR.
Supportive features of network operation: The multi-language mechanism is supported.
NOTE
This chapter describes VRP5.70. Unless otherwise stated, VRP in this document refers to VRP5.70.
1.2 VRP Architecture

This section describes the structure and functions of the VRP system plane.
1.2.1 NOS Model

The NOS models of VRP are divided to the centralized model and the distributed model, which
are shown in Figure 1-2 and Figure 1-3, respectively.
Figure 1-2 Centralized NOS model of VRP
Routing Engine Main Processing Unit

(CPU-based)
FIB
VRP
FIB
Packet Forwarding ASIC/
Engine NP
(CPU/ASIC/NP-based)
I/O I/O
Card Card

Figure 1-3 Distributed NOS model of VRP
Main Processing Unit
VRP FIB
Routing Engine Line Processing Unit

(CPU-based)
FIB
VRP
Packet Forwarding FIB

Engine
ASIC/NP
(CPU/ASIC/NP-based)
I/O I/O
Card Card
1.2.2 System Plane

The VRP is divided into five system planes, as shown in Figure 1-4.
Figure 1-4 VRP architecture
Service Control Plane

(SCP) System Management
General Control Plane
Plane
(GCP)
Data Forwarding Plane (SMP)
(DFP)
System Service Plane (SSP)

1.2.3 SCP
Figure 1-5 SCP architecture
Service Control Plane (SCP)

Proto Client
AAA LocalM
CM
The primary functions of the SCP are listed as follows:

l Connection management
l User authentication, authorization and accounting
l User administration
1.2.4 DFP
Figure 1-6 DFP architecture
Data Forwarding Plane (DFP)
FE API
FEC
FE DRV
The primary functions of the DFP are listed as follows:

l Forwarding packets
l Applying QoS policy
l Applying security policy
l Maintaining forwarding information

1.2.5 GCP
Figure 1-7 GCP architecture
General Control Plane(GCP)
Multicast Subsystem Routing Subsystem VPN Subsystem
OSPFv2 IS-IS RIP L2VPN L3VPN

GMP4/6 MSDP
OSPFv3 BGP RIPng VPDN IPSec VPN
PIM-SM4/6 PIM-DM4/6
RM4/6 VPN IFM
PIM-SSM4/6
MRM4/6
Net Interface Subsystem MPLS Subsystem
IFNET TunnelM MPLS IFM
IP Stack Subsystem LSPM LDP CSPF

PPP ETH ATM Tunn
IP Application 4/6 RSVP-TE TEDB
Link Manager
LSP Agent
Socket Layer
TCP4/6 UDP4/6 Security Subsystem QoS Subsystem

ICMP4/6 IP4/6 IPSec Firewall ACL BW-M SAA
NAT CA DecSec QoSM RSVP
The primary functions of the GCP are listed as follows:

l Sockets
l TCP protocol stack
l IP protocol stack
l Network interface layer
l Link layer protocols
l Routing protocols
l QoS
l VPN
l MPLS

1.2.6 SMP
Figure 1-8 SMP architecture
System Management Plane (SMP)

Config Management Information Management Device Management
Subsystem Subsystem Subsystem
WebUI CLI MML IM BoardM HeartBeat
SNMP BINA TRACE State CFG-RS SwitchOver
CMO Multi-Language Hot Plug Alarm Proc
The primary functions of the SMP are listed as follows:

l System configuration
l Output management
1.2.7 SSP
Figure 1-9 SSP architecture
System Service Plane (SSP)
System Function
Kernel
Operating System
The primary functions of the SSP are listed as follows:

l Shielding low-layer operating system from the upper application layer
l Kernel management: management of tasks, memory, messages, time, timers, semaphore,
events, message queue, socket interface, and file systems
l System functions: online patch, command line, storage protection, and system monitoring
1.3 VRP System Features

This section covers three system-level features.
1.3.1 Componentized Structure

Adopting the componentized structure, the VRP can provide applications-based tailorability and
scalability besides abundant features.
To put it specific, in the VRP:

l All the protocols and features are componentized and can be dynamically controlled
through the License.
l Core components are separated from the hardware platforms, and thus can provide better
adaptability and cross-platform application.
1.3.2 License
The License furnishes the VRP with high flexibility.
The License manages the following items:
l Features: A user can use only the features allowed by the License.
l Resources: For example, the License sets limit on the number of reserved routes, number
of LSPs, and number of VPN instances.
Generally, the product price increases along with the quantity of functions it can provide. Taking
use of the License, functions not required can be removed to save the customer expenditure.
1.3.3 HA
High availability (HA) guarantees the availability of 99.999% to devices applying the VRP. It
means in a year, the unavailable period is less than 5 minutes.
To realize HA, the VRP adopts multiple mechanisms as follows:
l System level hot standby (HSB)
l System level GR
l Protocol level GR
l Fast reroute (FRR)

Feature Description - Basic Configurations 2 Basic Configuration
2 Basic Configuration
About This Chapter
2.1 Introduction to Basic Configuration

2.2 References
2.3 Principles
2.4 Applications
2.5 Terms and Abbreviations

2.1 Introduction to Basic Configuration

Definition
In configuration management, the terminal service provides the access interface and human-
machine interfaces (HMIs) for users to configure devices.
The login mode includes:
l Login through the console port

l Remote login through the AUX port
l Telnet server/client
l Login through Secure Shell (SSH), with password and Revest-Shamir-Adleman Algorithm
(RSA) authentication
l Login through customized user interfaces providing multiple user authentications and
authorization modes
The file transfer provides transmission control for system files and configuration files, and
simple remote management for the file system.
The file transfer mode includes:
l FTP client/server
l TFTP client
l SSH FTP (SFTP) client/server
This document describes the principles of every protocol feature according to the protocol type.
It includes the following parts:
l FTP
l TFTP
l Telnet
l SSH
l User management
l Virtual file system
l Daylight saving time
l Timing restart
Purpose
The terminal service provides the access interface and HMIs for users to configure devices. The
file transfer provides transmission control for system files and configuration files, and simple
remote management for the file system.
2.2 References
The references of this feature are as follows:

Document Description Remarks
RFC 775 Directory oriented FTP commands -
RFC 959 File Transfer Protocol -
RFC 1635 How to Use Anonymous FTP -
RFC 1350 The TFTP Protocol (Revision 2) -
RFC 698 Telnet Extended ASCII Option -
RFC 775 Directory oriented FTP commands -
RFC 854 Telnet Protocol Specification -
RFC 855 Telnet Option Specification -
RFC 930 Telnet Terminal Type Option -
RFC 1091 Telnet Terminal-Type Option -
RFC 2119 Key words for use in RFCs to Indicate -

Requirement Levels
RFC 4250 The Secure Shell (SSH) Protocol -

Assigned Numbers
RFC 4251 The Secure Shell (SSH) Protocol -

Architecture
RFC 4252 The Secure Shell (SSH) -

Authentication Protocol
RFC 4253 The Secure Shell (SSH) Transport This protocol supports neither
Layer Protocol compression nor the ssh-dss public
key format.
RFC 4254 The Secure Shell (SSH) Connection This protocol does not support some
Protocol packets and functions, such as X11
forwarding, Env channel request
packets, xon-xoff channel request
packets, signal channel request
packets, exit-status channel request
packets, exit-signal channel request
packets, and port forwarding.
RFC 4344 The Secure Shell (SSH) Transport -

Layer Encryption Modes
RFC 4345 Improved Arcfour Modes for the -

Secure Shell (SSH) Transport Layer
draft-ietf- Authentication Mechanism that Is -

secsh- Based on Public Keys
publickey-
subsystem-0
1

2.3 Principles
2.3.1 FTP
As a protocol in the TCP/IP protocol suite, the File Transfer Protocol (FTP), running at the
application layer, is used for transferring files between local and remote hosts over the Internet.
FTP, which is implemented based on the file system, has been widely used during version
upgrade, log downloading and configuration saving.
FTP is built on the client-server architecture, as shown in Figure 2-1.
Figure 2-1 FTP client/server architecture
IP Network
Server Client
The NE80E/40E provides the following FTP functions:
l FTP server: indicates that the router functions as an FTP server to which users can log in
to access files by running the FTP client program.
l FTP client: indicates that the router functions as an FTP client that can access files saved
on a remote server. After running the terminal emulation program or using the Telnet
program on a PC to set up a connection to the router, a user can set up a connection to a
remote FTP server by using the FTP commands and access files saved on the remote server.
In addition to file transfer, FTP supports interactive access, format specifications, and
authentication control.
FTP provides common file operation s to help users perform simple management over the file
system as well as supporting file transfer between hosts. Users can use a PC running the FTP
client program to upload files, download files, and access file directories on the router that
functions as an FTP server, or, use the FTP client program on the router that functions as an FTP
client to transfer files to an FTP server.
At present, an FTP client can access the IPv6 address of an FTP server, and an FTP server
supports IPv6 connections.
Basic Concepts of FTP

Before learning FTP, familiarize yourself with the following basic concepts about file transfer:
l File type
ASCII mode

This mode is used for text. Data is converted from the sender's character representation
to "8-bit ASCII" before transmission, and to the receiver's character representation.
Extended Binary-Coded Decimal Interchange Code (EBCDIC) mode
This mode requires that both ends use the EBCDIC character set.
Binary mode
This mode requires that the sender sends each file byte for byte. This mode is often used
to transfer image files and program files.
Local mode
This mode allows two hosts using different file systems to send files in binary bit
streams. The bit stream of each byte is defined by the sender.
NOTE
The NE80E/40E supports the ASCII mode and the binary mode. Differences between these two
modes are as follows:
l In ASCII mode, ASCII characters are used to separate carriage returns from line feeds.
l In binary mode, characters can be transferred without format converting.
The client can select an FTP transmission mode. By default, the ASCII mode is used. The client can
use a mode switch command to switch between the ASCII mode and the binary mode.
l File structure
Byte stream structure
It is also called the file structure. A file is considered as a continuous byte stream.
Record structure
It is used only for text files in either ASCII or EBCDIC mode.
Page structure
Files are transferred page for page with a page number on each page so that the receiver
can save pages randomly.
NOTE
The NE80E/40E supports the record structure and the byte stream structure.
l Transfer mode
Stream mode
Data is sent as a continuous stream. For the file structure, the sender sends an End-Of-
File (EOF) indicator at the end of file transfer to prompts the receiver to close the data
connection. For the record structure, a two-byte sequence number is used to indicate
the end of the record and file.
Block mode
FTP breaks a file into several blocks and each block starts with a block header.
Compressed mode
FTP compresses the bytes that are the same and consecutively sent.
NOTE
The NE80E/40E supports the stream mode.
l port command
The port command enables an interface. The command format is port a,b,c,d,e,f. a,b,c,d
specifies the IP address of an interface, in dotted decimal notation; e,f, which consists of
two decimal numbers, specifies the interface number calculated based on the formula of
e x 256 + f. For example:

ftp> debug
Debugging On .
ftp> ls
---> PORT 10,164,9,96,5,28
Here, 10.164.9.96 is an IP address; the values 5 and 28 are used to calculate the interface
number 1308 (5 x 256 + 28 = 1308).
FTP Connections
Figure 2-2 shows the process of file transfer through FTP.
Figure 2-2 File transfer through FTP
User User Interface
Control
User Protocol Connection Server Protocol
Interpreter Interpreter
User Data Data Server Data

File Connection File
Transfer Transfer
System System
Function Function
Client Server
FTP uses two TCP connections to transfer files. They are:
l Control connection
A control connection is set up between the FTP client and the FTP server. The server enables
common port 21 and then waits for a connection request from the client; the client enables
common port 21 and then sends a request for setting up a connection to the server.
A control connection always waits for communication between the client and the server,
transmits related commands from the client to the server, and then responses from the server
to the client.
l Data connection
The server uses port 20 for data connections. Generally, the server can either open or close
a data connection actively. For files sent from the client to the server in the form of streams,
however, only the client can close a data connection.
FTP transfers each file in streams, using an EOF indicator to identify the end of a file.
Therefore, a new data connection is required for each file or directory list to be transferred.
When a file is being transferred between the client and the server, it indicates that a data
connection is set up.

FTP
In the current system, FTP manages the control connection by using User Protocol Interpretation
(User-PI) and Server Protocol Interpretation (Server-PI) and transfers files by using the User
Data Transport Process (User-DTP) and Server Data Transport Process (Server-DTP).
l FTP client
The FTP User Interface (UI) provides an interactive command line interface (CLI) for users,
which receives and interprets command lines input by users and offers help information.
After receiving a command on the UI, FTP triggers User-PI to convert the command into
a standard FTP command, and then manages the control connection to the FTP client.
After a login command is input, User-PI creates a control connection between the client
and the server.
After a directory operation command is input, User-PI sends and receives control data
between the client and the server.
After a file transfer command is input, User-PI enables User-DTP to transfer files
between the client and the server. User-DTP is responsible for creating a data connection
to the FTP server for data exchange. The data connection is temporarily set up. That is,
a data connection is set up when files or directory lists need to be transferred and
disconnected when the transfer process is complete or a disconnection request is
received.
l FTP server
Server-PI listens to FTP standard port 21 to wait for connection requests from the FTP
client. After receiving a login connection request from the FTP client, the FTP server
handles the request and sends a reply.
After a login command is received, the login authentication process is triggered. If the
login authentication succeeds, a control connection to the FTP client is set up.
After files are received, Server-DTP and User-DTP are triggered to create a data
connection to transfer files.
Server-DTP supports both active and passive data connection requests. By default, Server-
DTP is in the active state.
When Server-DTP is transferring data, a user can forcibly disconnect the connection. Upon
receiving a disconnection request, Server-DTP stops transferring data and disconnects the
connection. Normally, a data connection is automatically disconnected when file transfer
is complete.
Process of Setting Up an FTP Connection

The process of setting up an FTP data connection by using active mode is as follows:
1. The server enables port 21 to wait for a connection request from the client.
2. The client sends a connection request to the server.
3. After the request is received, a control connection is set up between the temporary port on
the client and port 21 on the server.
4. The client sends a command for setting up a data connection to the server.
5. The client chooses a temporary port for the data connection and sends the port number by
using the port command to the server over the control connection.
6. The server sends a request to the client for setting up a data connection to the temporary
port on the client.

7. After the request is received by the client, the data connection between the temporary port
on the client and port 20 on the server is set up.
The process of setting up an FTP data connection by using passive mode is as follows:
1. The server enables port 21 to wait for a connection request from the client.
2. The client sends a connection request to the server.
3. After the request is received, a control connection is set up between the temporary port on
the client and port 21 on the server.
4. The client sends a command for setting up a data connection to the server.
5. The client sends a command string PASV to the server to request the port number.
6. The server chooses a temporary port for the data connection and sends the port number to
the client over the control connection.
7. The server sends a request to the client for setting up a data connection.
8. The data connection between the temporary port on the client and the temporary port for
the data connection on the server is set up.
Figure 2-3 Process of setting up an FTP connection

PORT 10,168,2,45,9,42->
Port 2345 Port 21
Port 2346 Port 20

<-Port 2346
FTP Client FTP Server

10.168.2.45/32
Figure 2-3 shows the process of setting up an FTP connection, assuming that the number of the
temporary port for the control connection is 2345 and the number of the temporary port for the
data connection is 2346.
2.3.2 TFTP
The Trivial File Transfer Protocol (TFTP) is a simple protocol for file transfer.
The TFTP client supports file upload and download by using TFTP. To ensure simple
implementation, TFTP uses the User Datagram Protocol (UDP) as its transport protocol.
Compared with FTP, TFTP does not require complicated interaction interfaces and
authentication control. Thus, TFTP is applicable in a networking environment without
complicated interactions between the client and the server. For example, you can obtain the
memory image of the system through TFTP when the system is started up. To retain the small
size of TFTP packets, TFTP is realized based on UDP.
Presently, the NE80E/40E implements the TFTP client rather than the TFTP server. The TFTP
client can upload and download files.

Basic Concepts of TFTP

l Operation code
TFTP packet header contains a two-byte operation code, with values defined as follows:
1: Read request (RRQ): indicates a read request (RRQ).
2: Write request (WRQ): indicates a write request (WRQ).
3: Data (DATA): indicates data packets.
4: Acknowledgment (ACK): indicates a positive reply packet.
5: Error (ERROR): indicates error packets.
l File type
TFTP supports the following file types:
Binary type: is used to transfer program files.
ASCII type: is used to transfer text files.
Currently, the NE80E/40E can act only as the TFTP client and only the binary transfer type is
available.
Basic Principle of TFTP

l The user name and password are not required.
This is because TFTP is designed for the bootstrap process.
l TFTP transfer
The client initiates the TFTP transfer.
To download files, the client sends an RRQ to the server. The server then accepts the
request and sends a data packet to the client. After receiving the data packet, the client
sends an ACK packet to the server.
To upload files, the client sends an WRQ to the server. After the server accepts the
request, the client sends a data packet to the server and waits for an ACK packet from
the server.
l Support for IPv6
At present, the TFTP client supports the access to the IPv6 host address.
2.3.3 Introduction to Telnet

The Telecommunication Network Protocol (Telnet) is derived from ARPANET, which is one
of the earliest Internet applications released in 1969. Telnet enables a terminal to remotely log
in to a server and provides an interactive operation interface. Through Telnet, a login user of
one host can log in to other hosts to configure and manage them without being physically
connected to each of them.
Basic Concepts of Telnet

l NVT
The Network Virtual Terminal (NVT) is a virtual device from which both ends of a Telnet
connection, the client and the server, map their real terminal to and from. By using the
NVT, Telnet can operate between any hosts (any operating systems) or terminals.
That is, the client operating system must map whatever type of terminal the user is on to
the NVT. The server must then map the NVT to whatever terminal type the server supports.

Figure 2-4 shows conversion between physical terminals and the NVT.
Figure 2-4 Conversion between physical terminals and the NVT
Terminal Telnet client Telnet server Terminal driver
Internet
Local NVT Remote

character set character set character set
l NVT ASCII
NVT ASCII is a 7-bit ASCII character set. Each 7-bit character is sent as an 8-bit byte,
with the high-order bit set to 0. The Internet protocol suite including FTP and the Simple
Mail Transfer Protocol (SMTP) uses NVT ASCII.
l IAC
Telnet uses in-band signaling in both directions. The byte 0xff is called the Interpret As
Command (IAC). The next byte is the command byte.
Commands and their meanings are listed as follows:
SE: suboption end
SB: suboption begin
WILL: option negotiation
WONT: option negotiation
DO: option negotiation
DONT: option negotiation
IAC: data byte 255
Table 2-1 Telnet command set defined in RFCs
Name Code (Decimal Notation) Description
EOF 236 End of file
SUSP 237 Suspend current process (job

control)
ABORT 238 Abort process
EOR 239 End of record
SE 240 Suboption end
NOP 241 No operation
DM 242 Data mark
BRK 243 Break
IP 244 Interrupt process

Name Code (Decimal Notation) Description
AO 245 Abort output
AYT 246 Are you there?
EC 247 Escape character
EL 248 Erase line
GA 249 Go ahead
SB 250 Suboption begin
WILL 251 Option negotiation
WONT 252 Option negotiation
DO 253 Option negotiation
DONT 254 Option negotiation
IAC 255 Data byte 255
l Telnet connection
A Telnet connection is a TCP connection used to transmit data with Telnet control
information.
l Telnet client/server mode
Telnet adopts the client/server mode. Figure 2-5 shows the schematic diagram of the Telnet
client/server mode.
Figure 2-5 Schematic diagram of the Telnet client/server mode
Telnet server Telnet client
TCP
Pseudo connection Terminal
TCP/IP TCP/IP
terminal driver driver
Kernel Kernel
User at a
Login shell
terminal
The preceding diagram shows that:

Telnet uses TCP.
All echo messages of the Telnet connection are output to the terminal.
The server directly interacts with the pseudo terminal.

Commands and data are transmitted between the server and the client through the TCP
connection.
The client logs in to the server.
Principle of Telnet
Telnet is designed to operate between any two hosts or terminals. The client operating system
maps whatever type of terminal the user is on to the NVT. The server then maps the NVT to
whatever terminal type the server supports. The types of clients and terminals are ignored.
Communication ends are simply assumed as being connected to the NVTs.
NOTE
Telnet adopts the symmetric mode. Theoretically, there must be an NVT at each of the two ends of a Telnet
connection.
The two ends of a Telnet connection send WILL, WONT, DO, or DONT requests for option
negotiation. The options to be negotiated include echo, character set of command change, and
line mode.
This section describes the operating principles of Telnet from the following aspects:
l Requests in a Telnet connection
Either end of a Telnet connection can initiate a request to the other end. Table 2-2 shows
different requests and their meanings.
Table 2-2 Description of requests for a Telnet connection

Request Description Response
WILL WONT DO DONT
WILL Sender wants to - - Receiver Receiver

enable option says OK says NO
WONT Sender wants to - - - Receiver

disable option must say
OK(1)
DO Sender wants Receiver Receiver - -

receiver to enable says OK says NO
option
DONT Sender wants - Receiver - -

receiver to must say
disable option OK(1)

NOTE
When the sender sends an "option disable" request, such as WONT and DONT, the receiver must
accept the request.
When the sender sends an "option enable" request, such as WILL and DO, the receiver can either
accept or reject the request.
l If the receiver accepts the request, the option is enabled immediately.
l If the receiver rejects the request, the option remains disabled, but the sender can retain the
features as the NVT.
l Option negotiation
Option negotiation requires three bytes:
The IAC type, the byte for WILL, DO, WONT or DONT, and the option ID.
The following example illustrates the process of option negotiation.
The server needs to enable the "remote traffic control" with the option ID 33, and the client
grants the request. The commands exchanged between the server and client are as follows:
On the server: <IAC,WILL,33>
On the client: <IAC,DO,33>
l Suboption negotiation
Certain options require more information than the option ID. For example, if the sender
requires the receiver to specify the terminal type, the receiver must respond with an ASCII
string to specify the terminal type.
The format of the commands for suboption negotiation is as follows:
< IAC, SB, option code, contents of suboption, IAC, SE >
A complete process of suboption negotiation is as follows:
The sender sends a DO or WILL command carrying an option ID to request that the
option be enabled.
The receiver returns a WILL or DO command carrying the option ID to accept the
request.
After the preceding two steps, both ends agree to enable the option.
One end of the connection starts suboption negotiation by sending a request composed
of the SB, suboption ID, and SE in sequence.
The opposite end responds to the request for suboption negotiation by sending a
command composed of the SB, suboption ID, related negotiation information, and SE
in sequence.
The receiver returns a DO or WILL command to accept the negotiation information
about the suboption.
If there are no additional suboptions to be negotiated, the negotiation ends.
NOTE
In the preceding process, the receiver is assumed to accept the request from the sender. In practice,
the receiver can reject requests from the sender at any time as required.
The following example illustrates the process of terminal type negotiation.
The client needs to enable the "terminal type" with the option ID 24. The server grants the
request and sends a request for querying the terminal type of the client. The client then
sends another request carrying its terminal type "DELL PC" to the server. The commands
exchanged between the server and client are as follows:
On the client: <IAC, WILL, 24>

On the server: <IAC, WILL, 33>

On the server: <IAC, SB, 24, 1, IAC, SE>
On the client: <IAC, SB, 24, 0, "D", "E", "L", "L", "P", "C", IAC, SE>
NOTE
l Only the sender that sends the DO command can request terminal type information.
l Only the sender that sends the WILL command can provide terminal type information.
Terminal type information cannot be sent automatically but only in request-response mode.
The terminal type is an NVT ASCII string of case insensitive characters.
l Operating modes
Telnet has the following operating modes:
Half-duplex
Character at a time
Line at a time
Linemode
IPv6 Telnet Features Supported by the router

At present, the Telnet client can access hosts with IPv6 addresses; the Telnet server can receive
requests for connections from hosts with IPv6 addresses.
Telnet Services Provided by the router

The router provides the following Telnet services:
l Telnet server
A user runs the Telnet client application on a PC to log in to the router to configure and
manage the router.
The standard port number for a Telnet server is 23. If attackers access the standard port
continuously, the bandwidth is consumed and the performance of the server is degraded.
As a result, legitimate users cannot access the port.
In this case, you can configure another port number to replace the standard port number
for the Telnet server. Attackers who do not know the new port number still send requests
for socket connections to the standard port 23. The Telnet server will reject the requests
after detecting the wrong port number carried in the requests. This effectively prevents
bandwidth consumption and waste of system resources caused by attack on the standard
Telnet server port.
l Telnet client
After running the emulation terminal program or Telnet client application on a PC to
connect to the router, a user runs the telnet command to log in to the device and manage
it. As shown in Figure 2-6, Router A can function as both a Telnet server and a Telnet
client.

Figure 2-6 Router A functioning as a Telnet client

Telnet Session 1 Telnet Session 2
Telnet Server
PC RouterA RouterB
l Terminal redirection
As shown in Figure 2-7, a user runs the Telnet client application and logs in to the router
through a specified port, and then sets up connections with the devices connected to the
router through asynchronous serial interfaces. The typical application is that the devices
directly connected to the router through asynchronous serial interfaces are remotely
configured and maintained.
Figure 2-7 Terminal redirection

PC
Ethernet
Router
Async0 Async8/16
Async1
Async2
Router 1 Lan Switch Modem Router 2
NOTE
Only the routers having asynchronous serial interfaces support terminal redirection.
2.3.4 SSH
SSH is short for Secure Shell. Its standard port number is 22.
Data transmission in Telnet mode is prone attacks, because it does not have a secure
authentication mode and use TCP to transmit data in plain text. Simple Telnet access is
vulnerable to Denial of Service (DoS) attacks, IP address spoofing, and route spoofing.

With the increasing emphasis on network security, data transmission in plain text used by
traditional Telnet and FTP becomes unacceptable. SSH is a network security protocol. It provides
the secure remote access and other secure network services on an insecure network by encrypting
network data.
SSH uses TCP to exchange data and builds a secure channel based on TCP. In addition to standard
port 22, SSH supports access through other service ports to prevent attacks.
SSH supports password authentication and Revest-Shamir-Adleman Algorithm (RSA)
authentication. It uses DES, 3DES, and AES encryption to prevent password interception, thus
ensuring the integrity and reliability of the data and guarantee the secure data transmission. In
particular, RSA authentication supports the combined use of symmetric encryption and
asymmetric encryption. This implements secure key exchange and finally secures the session
process.
By virtue of data encryption in transmission and more secure authentication, SSH is widely used
and has become one of the important network protocols.
SSH has two versions: SSH1 (SSH 1.5) and SSH2 (SSH 2.0). Both are different and
incompatible. SSH2.0 is superior to SSH 1.5 in security, functions, and performance.
Devices that can function as the STelnet client and server and SFTP client and server support
both SSH1 (SSH 1.5) and SSH2 (SSH 2.0).
Secure Telnet (STelnet) enables users to remotely and securely log in to the device, and provides
the interactive configuration interface. All data exchanges based on STelnet are encrypted. This
ensures the security of sessions.
The SSH File Transfer Protocol (SFTP) enables users to log in to the device securely for file
management from a remote device. This improves the security of data transmission for the
remote system update. Meanwhile, the client function provided by SFTP enables users to log in
to the remote device for the secure file transmission.
Basic Concepts of SSH

l SFTP
SFTP guarantees secure file transfer over an insecure network by authenticating the client
and encrypting data in bidirectional mode.
l STelnet
STelnet ensures secure Telnet services. It guarantees secure file transfer on a traditional
insecure network by authenticating the client and encrypting data in bidirectional mode.
l RSA authentication
RSAauthentication is based on the private key of the client. It is a public key encryption
architecture and an asymmetric encryption algorithm. Based on the problem of factoring
large numbers, RSA is mainly used to transmit the keys of the symmetric encryption
algorithm, which can improve encryption efficiency and simplify key management.
The server checks whether the SSH user, public key, and digital user signature are valid.
If all of them are valid, the user is permitted to access the server; if any of them is invalid,
the authentication fails and the user is denied to access the server.
l Password authentication
Password authentication is based on the user name and password.
On the server, the AAA module assigns a login password to each authorized user . The
server has the mappings between user names and passwords. When a user requests to access

the server, the server authenticates the user name and password of the user. If either of them
fails to pass the authentication, the access request of the user is denied.
l RSA-password authentication
The server can authenticate the client by checking both the public key and the password.
It allows user to access only when both public key and password are consistent with those
configured on the server.
l ALL authentication
The server can authenticate the client by checking both the public key and the password.
It allows user to access when either the public key or the password is consistent with those
configured on the server.
SSH Features Supported by the Device

l Basic SSH functions
Different encryption algorithms for incoming and outgoing data
Different MAC algorithms for incoming and outgoing data
Encryption algorithms of 3DES-cbc, DES, and Advanced Encryption Standard
(AES128)
HMAC-sha1 authentication algorithm
diffie-hellman-group1-sha1 algorithm for key exchange
Public key format of SSH-RSA
Key re-exchange (It indicates renegotiation of the key. During this process, the
algorithm and the key used for the algorithm are negotiated.)
Public key authentication and password authentication
l SSH client function
The SSH client function allows users to establish SSH connections with a UNIX host or
the device supporting the SSH server. Figure 2-8 and Figure 2-9 show the establishment
of an SSH connection in the Local Area Network (LAN) and in the Wide Area Network
(WAN) respectively.
Figure 2-8 Establishing an SSH connection in a LAN
WorkStation Router
Ethernet 100BASE-TX
Server LapTop PC
PC running SSH client

Figure 2-9 Establishing an SSH connection in a WAN
Local LAN Remote LAN
WAN
Router SSH Router
PC run SSH client PC
l SSH for SFTP

SFTP is based on SSH2.0. It guarantees secure file transfer on a traditional insecure network
by authenticating the client and encrypting data in bidirectional mode.
An SFTP-enabled device can provide the following functions:
Acting as the SFTP client or the SFTP server
Being enabled with or disabled from SFTP services (By default, SFTP services are
disabled.)
Setting the default directory that the SFTP client is allowed to access
l SSH for STelnet
An STelnet-enabled device can provide the following functions:
Acting as the STelnet client or the STelnet server
Being enabled with or disabled from STelnet services. (By default, STelnet services are
disabled.)
l SSH for non-standard ports
The standard SSH listening port number is 22. When attackers continuously access the port,
the bandwidth and performance of the server is reduced and authorized users are prevented
from accessing this port. This is known as a DoS attack.
To address the problem, you can change the listening port to another port on the SSH server
so that attackers cannot know the actual listening port. This prevents attackers from
consuming bandwidth and system resources during their continuous accesses to the
standard port. Authorized users can access the SSH server through non-standard ports to
decrease DoS attacks.
Applications of this function are as follows:
The STelnet client can access the server using a non-standard port.
The listening port can be set on the SSH server.
l SSH for IPv6
At present, the SSH client can access an IPv6 host address and the SSH server can set up
an IPv6 connection.
Principles of SSH
SSH uses the traditional client/server (C/S) application model. Its security is guaranteed by using
the following modes:

Data encryption: Through the negotiation between the client and the server, an encryption key
is generated and used in data symmetric encryption. This ensures the confidentiality during data
transmission.
Data integrity: Through the negotiation between the client and the server, an integrity key is
generated and used to uniquely identify a session link. All session packets are identified by the
integrity key. Any modifications made by the third party during transmission can be discovered
by the receiver based on the integrity key. The receiver can thus discard these modified packets
to ensure the data integrity.
Authority authentication: There are multiple authentication modes. Authority authentication

allows only valid users to have session with the server, thus improving system security and
safeguarding the benefits of valid users.
Establishment of an SSH Connection

The SSH connection goes through six phases in the whole communication process, as shown in
Figure 2-10. The SSH connection is established through negotiation. The following is the whole
SSH negotiation procedure.
Figure 2-10 Establishment of an SSH connection
Version Negotiation
Algorithm Negotiation
Key Exchange
User Authentication
Session request
Interactive session
1. Version negotiation
In the version negotiation phase, the SSH client sends a request for setting up a TCP
connection to the SSH server. After the TCP connection is set up, the SSH server and SSH
client negotiate the SSH version. After a matched version protocol is obtained, different
version protocols correspond to different state machine processes. If the version of the client
matches that of the server, the key negotiation starts; otherwise, the SSH server tears down
the TCP connection.
2. Algorithm negotiation
In the algorithm negotiation phase, the sender sends algorithm negotiation messages to the
receiver, together with their parameters, such as the random cookie, key exchange
algorithm, host key algorithm, Message Authentication Code (MAC) method, and
supported language.

After receiving algorithm negotiation messages, the receiver compares the received
algorithm list set with the local algorithm list set. If the key exchange algorithm, public key
encryption algorithm, or MAC algorithm is not found, the receiver tears down the
connection with the sender and the algorithm negotiation fails.
3. Key exchange
After algorithm negotiation is completed, key exchange begins. The client and the server
begin to calculate the session ID. The client randomly generates a 32-byte session key. The
first 16 bytes of the session key are used to perform the Exclusive-OR (XOR) operation
with the 16 bytes of the session ID with the last 16 bytes of the session key unchanged. The
result is arrayed into an MP integer by MSB. The public key with the smaller analog is
selected from host public keys and server public keys to perform encryption. The encryption
result is arrayed into an MP integer in the sequence of MSB first. Then, the public key with
the larger analog is selected to perform encryption. The encryption result along with the
encryption algorithm selected by the client, the 8-byte cookie transmitted by the server,
and the protocol flag of the client is sent to the server.
During the session, massive data transmission must use the fast-speed symmetrical key
algorithm. The symmetrical encryption and decryption need to share keys. The key
exchange process implements key's secure transmission over an insecure channel.
The server is in the waiting state. When receiving a key generation message from the client,
the server returns a key generation message to the client, which indicates that key exchange
is completed and a new key should be used for communications. If the server fails to receive
a key generation message from the client, it returns a key exchange failure message and
tears down the connection.
4. User authentication
After obtaining the session key, the SSH server authenticates the SSH client. The SSH
client sends the identity information to the SSH server. After a certain authentication mode
is configured on the SSH server, the client sends an authentication request to the server. If
the authentication succeeds or the connection with the server expires, the client is cut off
from the server.
The SSH server authenticates a user in one of the following methods:
l In RSA authentication, the client generates an RSA key pair and sends the public key
to the server. When a user initiates an authentication request, the client randomly
generates a text encrypted with the private key and sends it to the server. The server
decrypts it by using the public key. If decryption succeeds, the server considers this user
trustable and grants this user access rights. If decryption fails, the server tears down the
connection.
l Password authentication is implemented based on AAA. Like Telnet and FTP, SSH
supports local database authentication and remote RADIUS server authentication. The
SSH server compares the user name and password of an SSH client with the pre-
configured ones. If both are matched, authentication succeeds.
5. Session request
After user authentication is completed, the client sends a session request to the server. The
session requests include the running of Shell and commands. At the same time, the server
waits to process the request from the client. In this phase, the server responds to the client
with an SSH_SMSG_SUCCESS message after successfully processing a request from the
client. If the server fails to process or identify the request, it responds with an
SSH_SMSG_FAILURE message.
Possible causes for the authentication failure are as follows:
l The server fails to process the request.

l The server cannot identify the request.

6. Interactive session
After the session request is accepted, the SSH connection enters the interactive session
mode. In this phase, data is transmitted bidirectionally.
(1) The client sends a packet with the encrypted command to the server.
(2) After receiving the packet, the server decrypts the packet and runs the command..
Then, the server packages encrypted command execution results and sends the packet
to the client.
(3) Upon receiving the packet, the client decrypts it and displays command execution
results on the terminal.
2.3.5 User Management

Users can log in to the device to configure, monitor, and maintain local or remote network devices
only after user interfaces, user management, and terminal services are configured. User
interfaces provide the login place; user management ensures login security; terminal services
offer login protocols.
The device supports the following login modes:
l Login through the console port

l Local or remote login through the AUX port
l Local or remote login through Telnet or SSH
User management, consisting of user interface configurations, user view configurations, and
terminal services, provides users' secure login and operations, thus implementing unified
management over different user interfaces.
User Interface
A User Interface (UI), which is presented in the form of a user interface view, enables users to
log in to the device. Through a user interface, you can configure the parameters on all physical
and logical interfaces that work in asynchronous and interactive modes. In this manner, you can
manage, authenticate, and authorize the login users.
l The system supports the following user interfaces:

Console port: It is a linear port that is provided by the main control board of the device.
Each main control board provides a console port that conforms to the EIA/TIA-232
standard and whose type is DCE. The serial port of the user terminal can directly connect
to the console port of the device to implement local configurations of the device.
AUX port
AUX port: It is also a linear port that is provided by the main control board of the device.
Each main control board provides an AUX port that conforms to the EIA/TIA-232
standard and whose type is DCE. The terminal can perform remote access to the device
through the Modem on the AUX port.
Virtual Terminal (VTY)
It is a kind of virtual interface indicating a logical terminal line.

When you set up a Telnet or SSH connection with the device through a terminal, you
set up a VTY. You can also perform the local or remote access to the device through
the virtual connection established through VTY.
l Numbering of user interfaces
You can number a user interface in the following manners:
Relative numbering
The format of relative numbering is: user interface type + number.
Relative numbering indicates that the interfaces of the same type are numbered. Relative
numbering uniquely specifies a user interface of the same type. Relative numbering
must comply with the following rules:
Number of the CON port: CON 0
Number of the AUX port: AUX 0
Number of the VTY: The first VTY is 0, the second VTY is 1, and so on
Absolute numbering
Absolute numbering uniquely specifies a user interface or a group of user interfaces.
Absolute numbers start with 0 and are allocated in the sequence of the CON port, the
AUX port, and the VTY.
On a main control board, only one CON port or AUX port is present but a maximum
of 20 VTYs are present. (The VTYs ranging from 1 to 14 are provided for ordinary
Telnet or SSH users and those ranging from 16 to 20 are reserved for Network
Management System (NMS) users.) In the system view, the allowable maximum
number of user interfaces can be set. The default value is 5.
By default, the absolute numbering of the CON port, the AUX port, and the VTY is
shown in Table 2-3.
Table 2-3 Example for the absolute numbering of user interfaces
Absolute User Interface

Numbering
0 CON0
33 AUX0
34 VTY0: the first VTY
35 VTY1: the second VTY
36 VTY2: the third VTY
37 VTY3: the fourth VTY
38 VTY4: the fifth VTY
NOTE
Different devices may have different absolute numbering for AUX ports and VTYs. In the previous
examples, the numbers ranging from 1 to 32 are reserved for VTYs. TTY is a synchronous or
asynchronous terminal line, which is related to specific physical devices. Currently, the commands
for viewing absolute numbering and relative numbering have been provided.

User Login
When the device is started up the first time, no username or password is set.
In the absence of user authentication, any user can configure the device after the PC is connected
to the device through the console port.
After the IP address is assigned to the main control board or the interface board, any remote user
can use Telnet or SSH to log in to the device, or set up the PPP connection with the device to
access the network.
Thus, the device and network are vulnerable to attacks. In this case, users should be created for
the device and passwords should be set for users so that the device can manage users. SSH users
are configured with RSA authentication and other users are configured with AAA. For more
information, refer to the AAA Feature Description.
User Classification
The users of the device can be classified into the following types based on the types of services
that users enjoy.
l HyperTerminal users: indicate the users who log in to the device through the console port
or AUX port.
l Telnet users: indicate the users who log in to the device through Telnet.
l FTP users: indicate the users who transfer files by setting up the FTP connection with the
device.
l PPP users: indicate the users who access the network by setting up the PPP connection,
such as dialup and PPPoA, with the device.
l SSH users: indicate the users who perform the remote access to the network by setting up
the SSH connection with the device, including the STelnet mode and the SFTP mode.
l NMS users: indicate the users who set up the connection with the device through SNMP
or Telnet to manage devices in machine-to-machine mode.
One user can obtain multiple services simultaneously to perform multiple functions. VTY users,
namely, Telnet or SSH users, need be bound to admission protocols in the user interface view
before they log in.
User Priorities
The system supports hierarchical management over HyperTerminal users and VTY users.
Command levels are increased from 4 to 16. Similar to command levels, users are classified into
16 levels numbered 0 to 15. The greater the number, the higher the user level. The level of the
command that a user can run is determined by the level of this user.
l In the case of non-authentication or password authentication, the level of the command that
the user can run depends on the level of the user interface.
l In the case of AAA authentication, the command the user can run depends on the level of
the local user specified in AAA configuration.
A user can run the commands whose levels are equal to or lower than the user level. For example,
the level 2 user can access the commands at levels 0, 1, and 2. The level 3 user can access the
commands at levels 0, 1, 2, and 3.

Through the super command, the user can be switched from a lower level to a higher level. The
switched user level is determined by the level of the command configured by the super
command.
NOTE
The one-to-one mapping exists between user levels and command lines.
User Authentication
After users are configured, the system authenticates the users when they log in to the device.
Three authentication modes are available: non-authentication, password authentication, and

Authentication, Authorization, and Accounting (AAA) authentication.
l Non-authentication: In this mode, users can log in to the device without entering usernames
or passwords. For security considerations, this mode is not recommended.
l Password authentication: In this mode, users can log in to the device by entering the
passwords rather than the usernames. This mode is configured based on the terminal line.
A password can be configured for a terminal line or a group of terminal lines.
l AAA authentication: It includes AAA local authentication and AAA remote authentication.
In AAA local authentication, users need enter both the usernames and passwords on the
local device. If necessary, users also need enter user attributes, such as user rights and FTP
paths of users. In AAA remote authentication, user information need be configured on the
AAA server. In general, AAA server authentication is used for VTY users; AAA local
authentication or non-authentication is used for console users. For more information, refer
to the AAA Feature Description.
Planning Users
The network administrator can plan the users of the device as required.
l Usually, at least a HyperTerminal user need be created on the device.

l Telnet or SSH users need be configured to implement remote login to the device through
Telnet or SSH.
l FTP or SFTP users need be configured to enable remote users to upload or download files
to or from the device.
l PPP users need be configured to enable users to access the network through the PPP
connection established with the device.
2.3.6 Virtual File System

The file system has two functions, namely, managing the storage device and managing the files
that are stored in the storage device. A file system manages the files and directories in the storage
device. In the file system, users can create, delete, modify, and rename a file or a directory, and
view contents of a file. To manage mass storage devices more effectively and ignore the
differences of bottom-layer storage devices, the device supports the virtual file system that is
easy-to-use and tailorable.
Basic Concepts
l Storage device: a hardware device used to store data

Different products support different storage devices. Currently, the device supports the
flash memory, hard disk, and the CF card.
l File: a mechanism used for the system to store and manage information
l Directory: a mechanism used for the system to integrate and organize files and a logical
container of files
Managing Storage Devices

l Repairing the storage device with the abnormal file system
When the file system on a certain storage device fails, the terminal of the device prompts
that the fault should be rectified.
l Formatting the storage device
When the fault of the file system fails to be rectified or the data on the storage device is
needless, the storage device can be formatted.
After the command for formatting the storage device is run, if the storage device is still
unavailable, a physical fault may occur.
Managing File Directories

When transmitting files between the client and the server, directories need be set in the file
system. The specific operations are as follows:
l Display the current directory.

l Change the current directory.
l Display directories or file information.
l Create a directory.
l Delete a directory.
NOTE
Either the absolute path or relative path is applicable.
Managing Files
You can perform the following operations for files:
l Display file contents.

l Copy files. The size of the file to be copied must be larger than 0 byte; otherwise, it cannot
be copied.
l Move files. It refers to changing the file storage location.
l Rename files. It refers to changing the names of existing files.
l Delete files. It refers to deleting existing files and actually placing files to the recycle bin.
This operation is reversible. The wildcard (*) can be used to delete multiple files at a time.
l Delete files from the recycle bin. This operation is irreversible.
l Restore deleted files. It refers to restoring files from the recycle bin. Restoring deleted files
is a reverse operation of deleting files.
Miscellaneous
l Executing batch files

After a batch file is created, you can execute this batch file to implement automatization
of fixed tasks.
This operation need edit batch files on the client and upload batch files to the device.
l Configuring the prompt mode of the file system
If data is lost or damaged in operating files, the system should provide prompts.
CAUTION
If the prompt mode is set as quiet, the system does not provide prompts when data is lost because
of user misoperations such as the operation of deleting files. Therefore, this prompt mode should
be used with caution.
2.3.7 Pipe Character

The pipe character is used to filter the output of display commands according to the rules set by
a user and then display the filtration results.
During device maintenance, a display command may output a lot of information, only a part of
which, such as the status of interfaces, status of OSPF peers, and Cyclic Redundancy Check
(CRC) statistics of interfaces, the user uses to determine or locate a fault. If all the output of a
display command is displayed, users cannot rapidly obtain the desired information. Using the
pipe character, users can filter out irrelevant information of the command output. This makes
the desired information stand out and helps users rapidly obtain the information.
Filtration rules of the pipe character are as follows:
l include + regular expression

In this mode, the lines that contain user-specified contents are displayed.
l begin + regular expression
In this mode, the lines from the first line that contains user-specified contents are displayed.
l exclude + regular expression
In this mode, the lines that do not contain user-specified contents are displayed.
l count
In this mode, the lines to be output after the command is run are counted and only the line
numbers are displayed.
Special Processing of the Table-form Output

The output of certain display commands contain tables such as FIB tables and ARP tables. A
table is composed of the table heading, table tail, and table text (entries). If the table heading
and table tail participate in the filtration through the pipe character, they are probably filtered
out. It is not convenient for users to view entries after the filtration. In the pipe character filtration,
it is required that table headings and table tails not participate in the filtration. That is, they keep
unchanged through the filtration.
Generally, all display commands need to support the pipe character. The display commands
that meet the following requirements, however, do not necessarily support the pipe character:
l Commands whose output information is stable, can be displayed in current screen.

l Commands whose output information does not vary with configurations, dynamic data,
and specifications.
l Commands used in the hidden view or the diagnosis view, such as commands used to collect
information.
2.3.8 Daylight Saving Time

Daylight Saving Time (DST), also referred to as summer time, is a convention established by
people for saving resources.
In high latitude areas, it is earlier in summer than in winter at sunrise. To reduce evening usage
of incandescent lighting and save energy, clocks are adjusted forward one hour. At present, about
110 countries adopt DST all over the world.
Users can customize the DST zone according to their countries' or regions' convention. In
addition, users can set how long clocks are adjusted forward, usually an hour. With DST enabled,
when it is time to start DST, the system time is adjusted according to user-specified DST; when
it is time to end DST, the system time automatically returns to original time.
2.3.9 Timing Restart

The system supports timing restart. Device upgrade need be performed at the exact right time.
After timing restart is configured, maintenance personnel just need prepare software packages,
system image files, and set the time and files for device restart without wait. At the specified
restart time, the system automatically restarts and updates system files.
2.3.10 MIB Interface Is Used to Optimize System Upgrade

In a cluster, the version upgrade becomes complex. A user needs to download the system startup
file to the master board of the system, and then copy it to the master and slave boards of other
chassis. After copying the system startup file, the user needs to configure the startup settings for
each chassis. This brings a lot of workload to the user.
During the system upgrade, how the device processes the MIB is optimized and what the NMS
operates on the device is simplified.
When the user downloads the startup file to the master board through the NMS, the device
directly synchronizes the file to the slave board or the master and slave boards on other chassis
if in a cluster. The system provides the function of querying the file index according to the file
type and file name (including the startup file, PAF&License files, configuration file, and patch).
The NMS then sets the file for the next startup according to the file index. This setting is
automatically synchronized to the slave boards. In a cluster, this setting can also be synchronized
to the master and slave boards of other chassis without additional configurations. This greatly
reduces the user's workload on configuring and uploading startup-related files during the system
upgrade.
Before downloading version-related files (including the startup file, PAF&License files,
configuration file, and patch) from the FTP server, the device checks the remaining memory of
the master and slave boards in each chassis. If the available memory is insufficient, the earliest
created system file is automatically deleted to ensure sufficient memory. In the case that the
device contains only files for the current and next startup and does not have enough memory to
save the file to be downloaded, an error message is returned and the download operation is
canceled.
When the system upgrade is simplified through the MIB interface, the following functions are
emphasized:

l The device checks the memory usage to ensure that the remaining memory is enough to
store at least one system file for the upgrade.
An object hwFlhOperMemSize is added to huaweiFlhOpTable of HUAWEI-FLASH-
MAN-MIB. The value of this object is used to specify the size of the reserved memory (in
KB). If the value is 0, it indicates that no more memory needs to be reserved. This object
is optional during file uploading, and its default value is 0. If the value of this object is not
0, files are deleted when available memory is insufficient. There must be two system files,
namely, the currently-used system file and the rollback file. The earlier created system file
is first deleted. After the system file is deleted, if the available memory is still insufficient,
an error message is returned. In this case, the user needs to manually delete remaining files
until the available memory is sufficient.
l The needed file is downloaded and synchronized between the master and slave boards of
the system and between chassis.
After the file is successfully downloaded to the master board of the system, the file is
automatically synchronized to the slave board of the system as well as the master and slave
boards of other chassis. If the file already exists and is not the file for the current startup,
the file will be directly overwritten. If the file already exists and is the file for the current
startup, an error message is returned.
l The index of the specified file is queried.
The system provides a MIB table for querying the index of a specified file. The NMS can
obtain the index of a file through the operation of obtaining file indexes in real time. The
NMS sets the file for the next startup of the device according to the index.
l The file for the next startup is set and synchronized between the master and slave boards
of the system and other chassis.
The NMS sets the file for next startup through hwSysReloadScheduleTable. After the
master board of the system is specified, the system automatically synchronizes the file for
the next startup to the slave board of the system as well as the master and slave boards of
other chassis.
2.3.11 NAP
As a Layer 3 protocol, the Neighbor Access Protocol (NAP) helps users to remotely log in to a
device with default configurations and configure the device. A NAP connection can be
established as long as the device to be configured and the local device are physically connected.
As shown in Figure 2-11, Router A and Router B are devices on the current network, and
Router C is a device with default configurations. Router B and Router C are connected via a
single hop, both supporting NAP.

Figure 2-11 Establishing a NAP connection

1
2
Network
PC RouterA RouterB 3 RouterC

Master device Slave device
Master interface
Slave interface
1
NAP negotiation
2
IP address allocation
3
Remote login
The process of establishing a NAP connection is divided into the following phases:
1. NAP negotiation
2. IP address allocation
3. Remote login
During NAP negotiation and IP address allocation, the device on the current network and the
device with default configurations act as the master device and slave device respectively, and
thus the two physical interfaces connecting the two devices are called the master interface (on
the master device) and the slave interface (on the slave device). During remote login, the master
device and slave device act as the client and server respectively.
Format of a NAP packet

NAP packets are encapsulated into UDP packets, thus using the UDP port 53535. The destination
IP address of NAP packets is the reserved multicast address 224.0.0.128, and the source IP
address is the address configured for the sending interface. If the sending interface has no IP
address, 0.0.0.0 is used as the source IP address of NAP packets. The TTL of NAP packets is 1.
Figure 2-12 shows the format of a NAP packet.

Figure 2-12 Format of a NAP packet

0 1 2 3 4
Version Protocol Type TLV Number Reserved
Length Checksum
TLV1 (n byte)
TLV2 (n byte)
...
TLVn (n byte)
Major fields in a NAP packet are described as follows:

l Version: indicates the version number of NAP. The value is 01.
l Type: indicates the type of a NAP packet. There are five types of NAP packets. Table
2-4 lists these five types and corresponding values.
Table 2-4 Description of the Type field in a NAP packet

Value Type
01 Detect packet
02 Response packet
03 Establish packet (confirming the establishment of a neighbor

relationship)
04 Hello packet
05 Close packet
l TLVn: indicates the variable-sized TLV data area. This filed consists of three parts: data
type, data length, and user data.
Table 2-5 lists the TLV data types and the corresponding types of user data.

Table 2-5 Mappings between data types and user data in the variable-sized TLV data area of
the NAP packet
Type Number Value
01 Primary IP address of the local interface
02 Secondary IP address of the local interface
03 Primary IP address of the remote interface
04 Secondary IP address of the remote interface
05 Subnet mask of the IP address
06 Hello interval
07 Name of the local interface
08 Type of the local device
09 ID of the local device
NAP Negotiation
By default, a NAP-supporting device is a slave device and the interface on the device is a slave
interface, responsible for listening to rather than sending packets. After the NAP master and
slave devices are configured, the listening function is enabled on the slave interface by default.
After NAP is enabled on the master interface on the master device, the master device sends a
Detect packet to discover neighbors, and enters the NAP negotiation phase. The NAP negotiation
process is shown in Figure 2-13.
Figure 2-13 NAP negotiation

Master device Slave device
Proto
cal pa
cket
Analyzing
ACK
ACK
1. The NAP slave device starts, and the listening function is enabled on the slave interface by
default. Then, the slave device waits for a Detect packet from the master device.

2. The master device sends a Detect packet through the master interface to discover neighbors.
3. After receiving the Detect packet, the slave device analyzes the packet.
4. The master and slave devices enter the NAP negotiation phase.
5. The slave device sends a Response packet through the slave interface. After receiving the
packet, the master device replies with an Establish packet to the slave device. Then, the
NAP neighbor relationship is established.
IP Address Allocation
The master and slave interfaces need to be configured with IP addresses to facilitate subsequent
service IP address configurations without interrupting NAP connections.
In the current system, no secondary IP address can be configured without a primary IP address,
which determines whether NAP is Up. Therefore, the master and slave interfaces need to be
configured with primary IP addresses first. Note that if the master device uses the primary IP
address to communicate with the slave device, the primary IP address cannot be changed during
the Telnet operation. This means that primary IP addresses cannot be changed to meet the actual
networking requirements.
Therefore, both master and slave interfaces are configured with two IP addresses, namely, a
primary IP address and a secondary IP address. Primary IP addresses are used to ensure that
NAP is Up, whereas secondary IP addresses are used for communication and NAP-based remote
login.
By default, NAP automatically allocates IP addresses in the IP address pool 10.167.253.0/24 to
interfaces. In the case of IP address conflicts, IP addresses can be manually configured for
interfaces. That is, you can specify a NAP IP address pool and obtain IP addresses calculated
by the NAP address allocation algorithm, or, directly specify four IP addresses on the same
network segment.
Remote Login
l After IP address allocation, the master device logs in to the slave device through Telnet,
enters the interactive interface, and initializes the slave device.
l If the slave device has only default configurations, the master device can log in to the slave
device without a user name and a password.
l If the slave device is configured with a user name and a password, the master device has
to pass the authentication before remotely logging in to the slave device through NAP.
NOTE
The slave device with default configurations checks the source address of a remote Telnet connection. If
the Telnet source address is the NAP address of the master device, the slave device considers that the master
device has the highest user level, the same as that of the console interface, and allows the master device to
directly log in without being authenticated. If the Telnet source address is not the NAP address of the master
device, the remote login is bound to fail. This ensures the system security of the device with default
configurations.
When the NAP-based connection is logged out, temporary primary and secondary IP addresses
allocated to the master and slave devices are automatically released. After configuring a device
with default configurations, you can globally disable the slave interface attribute on the device
to reject other NAP negotiation requests. In addition, the existing neighbor relationships are torn
down and allocated IP addresses are released automatically. After the slave interface attribute
is globally disabled on a slave device, interfaces on the slave device can function as only master
interfaces to initiate connections to other devices with default configurations. In this manner,
the system security is guaranteed.

2.4 Applications
2.4.1 Applications of FTP

l Device functioning as an FTP client
A user logs in to the FTP server from the device acting as an FTP client and then downloads
files from the server to the storage device of the client.
In Figure 2-14, the device with the IP address of 172.16.105.111 acts as the FTP client.
The user then can log in to the FTP server from the client through FTP.
Figure 2-14 Networking diagram of the device functioning as an FTP client
GE2/0/0
IP Network
Server Router
172.16.105.110/24 172.16.105.111/24
l Device functioning as an FTP server

A user logs in to the client from a HyperTerminal. The device functions as an FTP server,
and downloads files from the FTP server. In Figure 2-15, the device with the IP address
of 172.16.104.110 acts as the FTP server.
Figure 2-15 Networking diagram of the device functioning as an FTP server

Server
172.16.104.110/24
console cable
2.4.2 Applications of TFTP

Downloading or Uploading Files Through TFTP
A user can use TFTP to upload or download files to or from the server in a simple interaction
environment. Currently, the device acts only as a TFTP client.
Figure 2-16 shows the networking of downloading or uploading files through TFTP.

Figure 2-16 Networking diagram of uploading or downloading files through TFTP
Server Router PC
TFTP Client
10.111.16.160/24
2.4.3 Applications of Telnet

Telnet applies to remote login to configure, monitor, and maintain the remote or local devices
running device.
As shown in Figure 2-17, the user on Router A logs in to the remote Router B through Telnet.
Figure 2-17 Networking diagram of login through Telnet

GE1/0/0 GE1/0/0
1.1.1.1/24 1.1.1.2/24
RouterA RouterB
2.4.4 Applications of SSH

l SSH for STelnet
The STelnet client is based on SSH2 and the STelnet server is based on SSHv1.x and
SSHv2. The client and the server set up a secure connection through negotiation. The client
can then log in to the server using Telnet. Figure 2-18 shows the networking of SSH for
STelnet.
Figure 2-18 Networking diagram of SSH for STelnet
Stelnet Client SSH Server
A device can function as the STelnet server. Alternatively, it can function as the STelnet
client to access other STelnet servers.
STelnet services can be enabled or disabled as required. By default, STelnet services
are disabled. Enabling or disabling of STelnet services must be configured in global
mode.
l SSH for SFTP
Attackers cannot pass the authentication because they cannot provide the correct private
key or password.. In addition, they cannot obtain the session key between another client

and the server. Only the server and the related client can decrypt packets exchanged between
them. Even if attackers intercept packets exchanged between the server and the client, they
cannot decrypt the packets. In this manner, the secure data transmission on the network is
guaranteed.
SFTP is based on SSH2.0, which supports two authentication modes: password
authentication and RSA authentication. To access the server using a client, an authorized
user needs to enter the correct user name, password, and private key to pass the
authentication of the server. After that, the user can use SFTP that is similar to FTP to
manage remote file transfer on the network. The system uses the negotiated session key to
encrypt user's data.
A device can function as the SFTP server. Alternatively, it can function as the SFTP
client to access other SFTP servers.
SFTP services can be enabled or disabled as required. By default, SFTP services are
disabled. Enabling or disabling of SFTP services must be configured in global mode.
Different users are allowed to use SFTP to access different file directories. Users can
access only the set SFTP directories. Available files for different users are isolated from
each other.
Figure 2-19 Networking diagram of SSH for SFTP
SFTP Client
legal user
Network SFTP Server
SSH Client
setting port
VPN
SFTP Server
SFTP Client
attacker
l SSH for the private network

A device can function as the STelnet client, SFTP client.. So that the client (device) on the
public network can set up a Socket connection with the server in a VPN:
The STelnet client can access the SSH server on the private network.
The SFTP client can access the SSH server on the private network.

Figure 2-20 Networking diagram of SSH for the private network
SSH Client
legal user
Network
SSH Client
setting port SSH Server VPN
SSH Client
attacker
l SSH for non-standard ports

The standard SSH listening port number is 22. If attackers continuously access this port,
the available bandwidth and the performance of the server are reduced and authorized users
cannot access this port.
To address this problem, you can change the listening port on the SSH server to a non-
standard port. The port change is invisible to attackers, so they continue to send socket
connection requests to the standard listening port 22. If the SSH server detects that the
connection requests are not forwarded to the actual listening port, it denies the requests.
Only authorized clients can set up socket connections with the SSH server using non-
standard ports on the server. The client and the server then negotiate the SSH version,
algorithms and session keys. User authentication, session request, and interactive session
are performed subsequently.
SSH can be used on intermediate switching devices or edge devices on a network to secure
the user access and device management.

Figure 2-21 Networking diagram of SSH for non-standard ports
SSH Client
legal user
Network
SSH Client
setting port
SSH Server
SSH Client
attacker
l SSH for RADIUS

If password authentication is required, SSH calls the interface provided by AAA in the
same manner as FTP and Telnet. After user authentication is configured as RADIUS in
AAA, when SSH authentication is enabled, the SSH server sends the authentication
information (user name and password) to the RADIUS server (compatible with the
HWTACACS server). The RADIUS server then sends the authentication result (pass or
fail) to the SSH server for the SSH server to determine whether to establish a connection
with the SSH client.
Figure 2-22 SSH for RADIUS
SSH Client SSH Server RADIUS Server
l SSH for ACLs

The SSH server uses ACLs to limit the call-in and call-out rights of SSH users. This prevents
unauthorized users from establishing TCP connections or entering the SSH negotiation
phase, thus improving the security of the SSH server.
Figure 2-23 Networking diagram of SSH for ACLs

ACL
SSH Client SSH Server


Terms
Terms Description
FTP In the TCP/IP protocol suite, the File Transfer Protocol (FTP) is applied
to the application layer. It is used to transfer files between local hosts and
remote hosts. FTP is implemented based on the file system.
TFTP TFTP is short for Trivial File Transfer Protocol.
Telnet The Telecommunication Network Protocol (Telnet) is applied to the

application layer in the TCP/IP protocol suite. Telnet enables a terminal
to remotely log in to a server, presenting an interactive operation interface.
NVT The Network Virtual Terminal (NVT) is a bidirectional virtual device, to

and from which both ends of the connection, the client and the server, map
their physical terminals. Because of the use of uniformed NVT, Telnet
can operate between any two hosts (any operating system) or terminals.
SSH Secure Shell (SSH) uses multiple encryption modes and authentication
modes to solve the problem of data encryption and user authentication in
traditional services. In virtue of its mature public key or private key
system, SSH provides an encryption channel for the session between the
client and the server. This solves the problem of insecurity that is caused
when data, such as passwords, are transmitted over the network in plain
text. SSH also supports multiple authentication modes, such as CA and
the smart card, which solves the authentication problem and eliminates
such insecurity factors as the man-in-the-middle attack.
SFTP The Secure File Transfer Protocol (SFTP) is an SSH-based upper-layer

application, which provides secure file transmission.
STelnet The Secure Shell Telnet (STelnet) is an SSH-based upper-layer

application, which provides secure login operations.
TLS TLS is a protocol and is based on the Netscape's SSL 3.0 protocol. TLS
replaces the vulnerability of SSL, which was vulnerable to man-in-the-
middle attack and uses a weak MAC construction. The successors of SSL
are TLS 1.0 and TLS 1.1, which are defined by IETF. HTTPS, LDAP and
SNMP are some of the protocols that use SSL.
Abbreviation
Abbreviation Full Spelling
FTP File Transfer Protocol
FTPS FTP Secure

Abbreviation Full Spelling
IETF Internet Engineering Task Force
TFTP Trivial File Transfer Protocol
SSL Secure Socket Layer
Telnet Telecommunication network protocol
NVT Network Virtual Terminal
SSH Secure Shell
SFTP Secure File Transfer Protocol
AES Advanced Encryption Standard
ACL Access control list
MAC Message Authentication Code
RSA Revest, Shamir and Adleman
TACACS Terminal Access Controller Access Control System
VPN Virtual Private Network
TTY Terminal controller (A/S or SA)
CON Console, Primary terminal line
AAA Authentication, Authorization, Accounting
VRP Versatile router platform
NAP Neighbor Access Protocol

Feature Description - Basic Configurations 3 Fast Startup
3 Fast Startup
About This Chapter
3.1 Introduction to Fast Startup

3.2 References
3.3 Principles
3.4 Applications

3.1 Introduction to Fast Startup

Purpose
As the Internet develops, the demands for fast fault recovery are increasing. When faults occur
and devices must be restarted, the restart must be completed as quickly as possible in order to
minimize fault recovery time.
Because devices have appropriate fast startup routines for all types of fault recovery scenarios,
the startup routine a device uses depends on the type of fault. The system software restart decision
making center on a device chooses an appropriate startup routine based on different kinds of
fault recovery configurations, as shown in Figure 3-1 .
Figure 3-1 Startup modes
Enable fast restart
Configuration file
Cold Startup Startup normally
Restarting
Hardware Fault Fast startup
judgement center
Software-based fast
Software Fault
startup
Benefits
This feature brings the following benefits to operators:
l Service down time caused by device faults is reduced.

l Enhanced network reliability improves an operator's competitive position.
This feature brings the following benefits to users:
N/A.
3.2 References
None.
3.3 Principles

3.3.1 Fast Startup After a Software Fault

After a software fault occurs, the device monitoring process reports a software exception and
instructs the device management module to restart the device using the software-based fast
startup routine.
The Basic Input/Output System (BIOS) is not restarted during the process and this reduces
overall startup time. Before the restart, the forwarding engine on the data forwarding plane stops
forwarding traffic. Applications on the control plane are restarted without fault detection. After
the restart, the forwarding engine on the data forwarding plane starts to forward traffic again.
3.3.2 Fast Startup After a Hardware Fault

After a hardware fault occurs, the device is restarted in hot startup mode. BootLoad restart is
not part of the startup process, reducing startup time.
3.3.3 Upgrade and Cold Startup

After a software or hardware upgrade, system firmware needs to be re-loaded. When the device
is powered on, the power-on-self-test is performed on all components simultaneously. As
components do not have to perform the self-test one by one, overall startup time is reduced.
3.3.4 Performance Statistics for Software-based Fast Startup

No. Item Performance Statistics (in
Seconds)
1 Entire system 120
2 MPU 120
3 LPUF-10 120
4 LPUF-20 120
5 LPUF-40 120
6 SFU 120
3.4 Applications
None.

Terms
None.

Abbreviations
None.

Feature Description - Basic Configurations 4 Clock Synchronization
4 Clock Synchronization
About This Chapter
4.1 Introduction
4.2 References
4.3 Principles
4.4 Application

4.1 Introduction
Definition
Frequency synchronization, also called clock synchronization, allows a clock signal to pulse at
the same frequency as another clock signal, ensuring that all the devices on a communication
network share the same global time.
Purpose
Clock synchronization is a technology that limits the clock frequencies of network elements
(NEs) on a digital network to a tolerable error range. If the clock frequency of an NE is beyond
the tolerable error range, bit errors and jitter may occur, deteriorating networking transmission
performance.
4.2 References
The following table lists the references of this feature.
Document No. Description
ITU-T G.813 Timing characteristics of SDH equipment slave clocks (SEC)

(1996)
ITU-T O.172 Jitter and wander measuring equipment for digital systems which
are based on the synchronous digital hierarchy (SDH)
ITU-T G.781 Synchronization layer functions
ITU-T G.783 Characteristics of synchronous digital hierarchy (SDH) equipment

functional blocks
ITU-T G.8264 Distribution of timing information through packet switch networks
ANSI T.101 Specifications for interface synchronization
4.3 Principles
4.3.1 Basic Concepts
Ethernet Clock Synchronization Technology

Ethernet clock synchronization technology is used to transmit clock signals over the physical
layer on the Ethernet network. A device has multiple Ethernet links and any Ethernet link can
provide clock signals for the device. The device can either select the manually specified Ethernet
link or select an Ethernet link by using the algorithm for selecting the reference clock source.

The clock whose clock signals are transmitted over the selected Ethernet link is the reference
clock source for the device. The clock phase-locked loop (PLL) traces the reference clock source
to generate the system clock. The device transmits clock signals of the system clock to its
downstream devices over Ethernet links.
Timing Loop
In most situations, all devices on a network synchronize their clocks with the same reference
clock source, which is imported by a certain device on the network. The device transmits a clock
signal to its downstream devices, and the downstream devices transmit the clock signal to their
downstream devices until the clock signal reaches every device on the network. When the clock
signal is sent to the device that imports the reference clock source and the device synchronizes
its clock with the clock signal, a timing loop occurs. As a result, the precision of clocks on the
network gradually decreases. Therefore, preventing timing loops must be considered during
network design.
Clock Source
A device that provides clock signals to a local device is called a clock source. A local device
may have multiple clock sources.
Clock sources are classified into the following types:
l External clock source

The local device uses the clock interface provided by its clock board to trace a higher level
clock. External clock sources are classified into BITS0, BITS1, and PTP clock sources,
and support four types of signals: 2 MHz, 2 Mbit/s, dcls, and 1 pps.
l Line clock source
The local device uses the clock board to extract clock signals from Synchronous Transport
Module Level N (STM-N) or Ethernet line signals.
l Internal clock source
The local device uses its own clock (for example, the clock provided by its clock board) as
the working clock for an interface.
SSM
The Synchronization Status Message (SSM), also called the synchronization quality message,
directly reflects the level of a synchronous timing signal transmitted on a synchronous timing
link.
SSMs can indicate clock source quality and are transmitted over Ethernet synchronization
messaging channels (ESMCs). The reference clock source of a device is determined by the SSM
clock source selection algorithm.
If SSMs are used for selecting a reference clock source, quality levels (QLs) of clock sources
are first compared. If the quality levels of two or more clock sources are the same, the priorities
of these clock sources are compared. If SSMs are not used, the priorities of clock sources are
compared directly.
Clock Working Mode

The working modes of clocks are classified into the following types:

l Tracing state
The slave clock traces clock signals provided by the clock of the higher level. The clock
signals may be provided by either the master clock or the internal clock of the higher-level
network element (NE).
l Free running state
After losing all the external reference clock sources, the slave clock loses the clock
reference memory or remains in the hold-in state for a long time. As a result, the oscillator
inside the slave clock works in the free running state.
l Hold-in state
After losing all reference clock sources, the slave clock enters the hold-in state. The slave
clock uses the last lost reference clock source as its reference clock source. In addition, the
slave clock adopts the timing frequency similar to that of the last lost reference clock source
to ensure that there is only a small difference between the frequencies of the provided clock
signals and that of the reference clock source.
Priorities of Clock Sources

Priority order of information for reference clock source selection: SSM > Priority of clock source
> Clock source type
l Priority order of SSM information for reference clock source selection: PRC > SSUA >
SSUB > SEC > DNU
Candidate reference clock sources must be configured with priorities. A clock source whose
quality level is DNU cannot be a candidate reference clock source.
l Priority order of clock sources for reference clock source selection: 1 > 2 > ... > 254 > 255
The smaller the priority value of a clock source, the higher the priority of the clock source.
l Priority order of clock source types for reference clock source selection: BITS clock source
> Interface clock source > PTP clock source
l Priority order of interface information for reference clock source selection: Slot ID > Card
ID > Interface ID
The interface name is in the format of slot ID/card ID/interface ID. The smaller the slot ID,
the higher the priority of the interface clock source. If slot IDs are the same, the smaller
the card ID, the higher the priority of the interface clock source. If card IDs are also the
same, the smaller the interface ID, the higher the priority of the interface clock source.
Threshold of SSM Levels of Clock Signals That a BITS External Clock Source
Outputs
The SSM level output by the external clock source BITS0 is the SSM level of the clock source
that the 2M-1 PLL traces.
The SSM level output by the external clock source BITS1 is the SSM level of the clock source
that the 2M-2 PLL traces.
The threshold for SSM levels output by a BITS external clock refers to the lowest SSM level
that can be output by the BITS external clock. If the BITS external clock outputs an SSM level
that is below the threshold, the clock signal will be blocked and an alarm will be reported.

Selection of Clock Sources in Frequency Offset Detection and Non-frequency

Offset Detection Modes
A clock source can be selected in either frequency offset detection or non-frequency offset
detection mode.
l In frequency offset detection mode, frequency offset detection results are used for reference
clock source selection.
l In non-frequency offset detection mode, frequency offset detection is not performed on
clock sources.
Frequency offset detection results affect the selection of a system reference clock source, but do
not affect the selection of a reference clock source from a 2 M interface.
4.3.2 Clock Protection Switching
Overview
On a synchronization network, each device traces the same reference clock source level by level
through certain clock synchronization paths to implement clock synchronization on the entire
network. Usually, one device has more than one path for tracing clock sources, and has multiple
available clock sources. These clock sources may originate from either the same master clock
or reference clock sources of different qualities.
On a synchronization network, it is very important to keep the clocks of all devices synchronous.
Automatic protection switching of synchronous clocks can be configured to prevent the entire
synchronization network from becoming faulty because of a faulty clock synchronization path.
Implementation
l Manually or forcibly specifying a reference clock source
Manually specifying the reference clock source and forcibly specifying the reference clock
source differ in the following aspects.
When a clock source is in the following situations, you cannot manually specify it to be a
reference clock source:
The clock source is disabled.
The clock source is in the Abnormal state.
The quality level (QL) of the clock source is DNU or is not highest among all clock
sources.
When a clock source is disabled, you cannot forcibly specify it to be the reference clock
source. When the reference clock source is in the Abnormal state or its QL is DNU, the
system clock enters the hold-in state.
This method is used to designate a particular and fixed clock source for a clock board to
trace. The active and standby clock boards can be configured to trace different clock
sources.
As shown in Figure 4-1, on the master clock Router A, the active clock board has been
manually set to trace the BITS1 external clock and the standby clock board has been set to
trace the BITS2 external clock. Under normal circumstances, the master clock traces the
BITSI external clock. If the active clock board is faulty, a switchover occurs between the
active and standby clock boards. After the switchover, Router A traces the BITS2 external
clock, Router B traces the clock of Router A, and Router C traces the clock of Router B.

The problem with this method is that all of the router on the network are set to trace the
clock of Router A. If Router A is faulty, the entire network has no reference clock. All of
the router are in the free oscillation state.
Figure 4-1 Networking diagram for manually specifying the reference clock source
BITS1
CLK-IN
POS ATM
Router A
CLK-IN Router B Router C
BITS2
NOTE
Clock signals can be extracted only from Ethernet, packet over SDH/SONET (POS), Asynchronous
Transfer Mode (ATM), and resilient packet ring (RPR) links.
l Protection switching based on the SSM level
The SSM is a group of codes used to indicate the quality level of clocks on a synchronization
network. At present, ITU-T specifies four bits for coding. These four bits are called the
Synchronous Status Message Byte (SSMB). Table 4-1 describes the SSM level codes
defined by the ITU-T. These codes specify 16 levels of quality for synchronized sources.
Table 4-1 SSM Level Codes
QL Coding
PRC 0100
SSUA 0100
SSUB 1000
SEC 1011
DNU 1111
The SSM levels are arranged in descending order as follows:

Primary Reference Clock (PRC) > Primary level SSU (SSU-A) > Second level SSU (SSU-
B) > SDH Equipment Clock (SEC) > Do not use for synchronization (DNU)
Candidate reference clock sources must be configured with SSM levels. A clock source
whose quality level is DNU cannot be a candidate reference clock source.
The SSM level of a line clock source can be extracted from a line processing unit (LPU)
and reported to the main processing unit (MPU). The MPU then sends the SSM level to
the clock board. The MPU can also forcibly set the SSM level of the line clock source.

NOTE
BITS clocks fall into two types: 2.048 Mbit/s and 2.048 MHz. If the BITS clock is 2.048 Mbit/s, the
clock module can extract the SSM level from clock signals. If the BITS clock is 2.048 MHz, you
need to manually specify the SSM level.
l Protection switching based on prioritized clock sources
When there are multiple lines of clock sources, you can configure different priorities for
them.
In normal situations, SSMs are not used for reference clock source selection, and a clock
board uses the clock source with the highest priority as the reference clock source. If the
clock source with the highest priority fails, the clock board uses the clock source with the
second highest priority as the reference clock source. By default, priorities of clock sources
are not set and therefore not used for reference clock source selection.
Boards Participating in Clock Protection Switching

Clock protection switching involves the following boards:
l LPU
An LPU inserts and extracts the S1 byte. The S1 byte sent by the clock board is inserted
into the section overhead of the LPU. The S1 byte extracted from the section overhead of
the LPU is sent to the clock board for processing.
l Clock board
A clock board extracts the SSM level from an external clock and implements protection
switching for the clock source. After receiving the SSM level sent by an LPU, the clock
board determines which clock source to trace based on the SSM level. The LPU implements
clock protection switching and sends the SSM level of the current clock source to other
LPUs.
Clock Source Selection in Either Recovery or Non-recovery Switching Mode

A clock source can be selected in either recovery switching or non-recovery switching mode.
l In the recovery switching mode, the selector selects the optimal clock source as the
reference clock source by using the reference clock source selection algorithm.
l In non-recovery switching mode, the slave reference clock source is selected. If this
reference clock source cannot be not found, the non-recovery switching mode changes to
the recovery switching mode.
4.3.3 Synchronization Mode and Issues of Concern

There are two ways to synchronize digital communications networks:
l Pseudo synchronization
l Master/slave synchronization
Pseudo Synchronization
Pseudo synchronization refers to situations in which each switching site has its own highly
accurate and highly stable independent clock. The clocks of the switching sites are not
synchronized. Differences in clock frequency and phasing between different switching sites are,
however, very small. They do not affect data transmissions and can be ignored.

Pseudo synchronization is generally used when digital communications networks from different
countries interact. Most countries make use of caesium clocks on their networks.
Master/Slave Synchronization
Master/slave synchronization refers to situations in which a highly accurate clock is set as the
internal master clock for a network. Clocks at all sites within the network trace the master clock.
Each sub-site traces a higher level clock until the highest level network element is reached.
There are two types of master/slave synchronization:
l Direct master/slave synchronization
l Level-based master/slave synchronization
Figure 4-2 shows direct master/slave synchronization. All of the slave clocks synchronize
directly with the primary reference clock. Direct master/slave synchronization is used on
networks with relatively simple structures.
Figure 4-2 Direct master/slave synchronization

Primary
reference clock
Slave clock Slave clock Slave clock
Figure 4-3 shows level-based master/slave synchronization. Devices on the network are divided
into three levels. Level two clocks synchronize with the level one reference clock. Level three
clocks synchronize with level two clocks. Level-based master/slave synchronization is used on
networks that are larger scale and have more complicated structures.
Figure 4-3 Level-based master/slave synchronization
Level-1 reference clock
Level-2 slave clock
Level-3 slave clock

Master/slave synchronization is generally used to synchronize a country's domestic digital

communications network or internal regional networks. The national digital communications
network or regional network has a highly accurate master clock. Other network elements on the
national or regional network use the master clock as the reference clock.
To improve the reliability of master/slave synchronization, two master clocks are set on the
network. There is an active master clock and a standby master clock. Both are caesium clocks.
Under normal circumstances, each network element traces the master clock The standby master
clock also traces the master clock. If the active master clock is faulty, the standby master clock
takes over and becomes the reference clock for the entire network. After the fault is repaired and
the master clock recovers, there is a switchover. The original active master clock becomes active
again and serves as the reference clock.
4.3.4 Networking Mode for Clock Synchronization
Transmitting Clock Signals Through a Clock Interface

A clock interface provided by a clock board exports the clock of the network element where the
board is located to other SDH network elements.
The MPU of the NE80E/40E provides two BITS input clocks. A clock board has four clock
interfaces:
l Two input clock interfaces: obtain clock signals by connecting to the synchronized network.
l Two output clock interfaces: provide downstream devices with clock signals by connecting
to downstream input clock interfaces.
As shown in Figure 4-4, Router A traces the BITS clock and uses clock cables to connect the
clock output interface of Router A with that of Router B. Router B and Router C are also
connected through clock cables. Router C traces the clock of Router B and, finally, all three
router are synchronized with the BITS clock.
Figure 4-4 Transmitting clock signals through a clock interface
BITS
CLK-IN
CLK-IN CLK-IN
CLK-OUT CLK-OUT
Router A Router B Router C
The networking previously described can only be used to connect devices at the same site. The
distance between the router cannot exceed 200 meters.
Transmitting Clock Signals Through an Ethernet Link

A synchronized Ethernet network can transmit clock signals. The system uses a clock module
(clock board) to transmit a high-precision system clock to all Ethernet interface cards. The

Ethernet interfaces then use this high-precision clock as the basis for data transmissions. On the
receiver side, the Ethernet interface decodes the synchronized clock information and, after
frequency division, sends it to the clock board. The clock board judges the quality of the clocks
reported by the interfaces, selects the most precise one, and synchronizes the system clock to
that clock.
To select the source correctly and perform clock link protection, SSMs must be transmitted along
with clock information. On SDH networks, clock levels are differentiated by the outband
overhead byte in the SDH. An Ethernet network has no outband channel, so the SSM domain
of Ethernet OAM is used to provide downstream devices with clock level information.
As shown in Figure 4-5, Router A traces the BITS clock. There is a link connecting Router A
and Router B. Router B and Router C are connected through Ethernet links. Router C traces the
clock of Router B. Finally, clocks of all three router synchronize with the BITS clock.
Figure 4-5 Transmitting clock signals through an Ethernet link
BITS
CLK-IN
Ethernet Ethernet
Router A Router B Router C
4.4 Application
Link Network Topology

As shown in Figure 4-6, Router B and the external clock device are connected. Router B serves
as the master clock station for the network. The external clock of Router B serves as the reference
clock for this station and for the network. Router B stores clock information in code streams on
Ethernet lines.
Figure 4-6 Networking diagram of a link network topology
External clock
E W E W E W
Router A Router B Router C Router D

NOTE
In all of the networking diagrams for this chapter, W represents the westbound interface, and E represents
the eastbound interface.
The clock board on Router A serves as the local clock source for its network element (NE),
extracting clock information from code streams on Ethernet lines received at the eastbound
interface. The clock board on Router C also acts as the local clock source for its NE, extracting
clock information from code streams on Ethernet lines received at the westbound interface. At
the same time, clock information is attached to code streams on Ethernet lines and these code
streams are transmitted downstream to Router D. Router D receives these code streams at the
westbound interface and uses the clock information extracted as a reference point to complete
clock synchronization with the master clock station Router B.
Performance degradation of the clock on Router A will not affect the clocks on Router C and
Router D, but performance deterioration of the clock on Router C can affect the Router D clock
because Router D traces its clock through the higher level device, Router C.
Lower level NEs trace clock information stored in Ethernet through higher-level NEs, regardless
of the working modes being used by the higher level devices. If the performance of clocks on
Router B deteriorates, clock performance for the whole network will deteriorate.
If a link is very long, clock signals transmitted to a slave clock station must be transmitted a long
distance or divided into several transmissions. To ensure that slave clock stations receive high
quality clock signals, two master clocks can be set on the network to act as reference clocks.
NEs can trace either of these reference clocks. The two reference clocks must maintain
synchronization and be at the same quality level.
Ring Network Topology

As shown in Figure 4-7, Router A is the master clock station in this topology. It uses an external
clock source as its local clock and as the reference clock for this network. Other NEs trace the
clock from Router A. Clock tracing method of the slave clock station is the same as that of the
link network. The difference lies in that the slave clock station can extract clock information
from the code streams on Ethernet lines received by two interfaces. It is recommended that the
slave clock station extract clock information from the interface with the shortest route and least
transfer times. For example, Router E traces the clock through the westbound interface and
Router C traces the clock through the eastbound interface.

Figure 4-7 Networking diagram of a ring network topology
External clock source
W E
E Router A W
Router B Router F
W E
E W
Router C Router E
W E
Router D
E W
Mixed Topology
As shown in Figure 4-8, Router A, Router B, Router C, and Router D form a ring network
topology. Router D and Router E form a link network topology.
Serving as the master clock station, Router E uses an external clock source as the reference clock
for all the router on the network. Router E and Router D are connected by means of a low-speed
link.
Figure 4-8 Networking diagram of a mixed topology

W E
Router A
STM-N
E W
W
Router B Router D
W E Router E
Router C
E W

Router A, Router B, and Router C use both eastbound and westbound interfaces to trace and
lock the clock of Router D. This Router D clock traces the clock transmitted by the master clock
station Router E. Router D extracts clock information from the STM-N signals transmitted by
Router E and uses this information to synchronize with the downstream router.

Abbreviation English Full Spelling
SSM Synchronization Status Message
AIS Alarm Indication Signal
DNU Do Not Use
PRC Primary Reference Clock
SSU Synchronization Supply Unit
SEC SDH Equipment Clock
QL Quality Level
SF Signal Fail


Feature Description - Basic Configurations (Nonx1x2) (V600R003C00 - 02)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Feature Description - Basic Configurations (Nonx1x2) (V600R003C00 - 02)

Hochgeladen von

Copyright:

Verfügbare Formate

HUAWEI NetEngine80E/40E Router

Feature Description - Basic

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2011-09-10) Huawei Proprietary and Confidential i

About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R003C00

Issue 02 (2011-09-10) Huawei Proprietary and Confidential ii

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Indicates a potentially hazardous situation, which if not

NOTE Provides additional information to emphasize or supplement

Changes in Issue 01 (2011-09-10)

Changes in Issue 01 (2011-05-30)

Issue 02 (2011-09-10) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

Issue 02 (2011-09-10) Huawei Proprietary and Confidential iv

Issue 02 (2011-09-10) Huawei Proprietary and Confidential v

About This Chapter

This chapter introduces the features of the VRP.

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 1

1.1.1 VRP Introduction

1.1.2 Development of the VRP

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 2

Figure 1-1 VRP evolving history

Distributed VRP3.0 VRP3.x

The features of each version are described as follows:

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 3

1.2 VRP Architecture

1.2.1 NOS Model

Figure 1-2 Centralized NOS model of VRP

Routing Engine Main Processing Unit

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 4

Figure 1-3 Distributed NOS model of VRP

Main Processing Unit

Routing Engine Line Processing Unit

Packet Forwarding FIB

1.2.2 System Plane

Figure 1-4 VRP architecture

Service Control Plane

System Service Plane (SSP)

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 5

Service Control Plane (SCP)

The primary functions of the SCP are listed as follows:

Data Forwarding Plane (DFP)

The primary functions of the DFP are listed as follows:

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 6

Multicast Subsystem Routing Subsystem VPN Subsystem

OSPFv2 IS-IS RIP L2VPN L3VPN

IFNET TunnelM MPLS IFM

IP Stack Subsystem LSPM LDP CSPF

TCP4/6 UDP4/6 Security Subsystem QoS Subsystem

The primary functions of the GCP are listed as follows:

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 7

System Management Plane (SMP)

SNMP BINA TRACE State CFG-RS SwitchOver

CMO Multi-Language Hot Plug Alarm Proc

The primary functions of the SMP are listed as follows:

The primary functions of the SSP are listed as follows:

1.3 VRP System Features

1.3.1 Componentized Structure