Firewall All PDF

H3C SecPath Series Security Products
Operation Manual
Hangzhou H3C Technologies Co., Ltd.

http://www.h3c.com
Manual Version: T2-08162P-20070625-C-1.03

Copyright © 2006-2007, Hangzhou H3C Technologies Co., Ltd. and its licensors
All Rights Reserved
No part of this manual may be reproduced or transmitted in any form or by any means
without prior written consent of Hangzhou H3C Technologies Co., Ltd.
Trademarks
H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot,

Neocean, NeoVTL, SecPro, SecPoint, SecEngine, SecPath, Comware, Secware,
Storware, NQA, VVG, V2G, VnG, PSPT, XGbus, N-Bus, TiGem, InnoVision and
HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd.
All other trademarks that may be mentioned in this manual are the property of their
respective owners.
Notice
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.
To obtain the latest information, please access:
http://www. h3c.com
Technical Support
customer_service@h3c.com
http://www. h3c.com
About This Manual
Related Documentation
In addition to this manual, each H3C SecPath Series Security Products documentation
set includes the following:
Manual Description
It introduces all commands available in
the configuration and operation on the
H3C SecPath series security
H3C SecPath Series Security Products
gateways/firewalls. The details include
Command Manual
command name, complete command
form, parameter, operation view, usage
guide and operation example.
It instructs users how to perform their
H3C SecPath Series Security Products Web-based configuration on the
Web-Based Configuration Manual SecPath series security
gateways/firewalls.
Organization
H3C SecPath Series Security Products Operation Manual is organized as follows:
Part Contents
Profiles the characteristics and functions of the security
gateway and firewall. Basic VPN configuration includes
introduction to user-defined interfaces (CLIs), system
maintenance and management, auto detect configuration,
HWPing configuration, SNMP configuration, RMON
configuration, BIMS configuration, terminal service, Modem
configuration and interface configuration. In the user-defined
interface section, we discuss configuration environment
setup, CLI characteristics and basic configurations. In the
1 Fundamental system maintenance and management section, we describe
Configuration logs and debugging information center, file system and file
operation, user interface, user management system and NTP
configuration. In SNMP configuration section, we present the
settings required when the security gateway/firewall serves
as NMS agent. In the terminal service section, we list the
access methods of the Console terminals which can be
accessed into the security gateway and firewall. The interface
configuration section involves the configuration of several
types of physical and logical interfaces on the security
gateway and firewall.
Part Contents
Gives several approaches for user access into the security
gateway/firewall, including PPP configuration, PPPoE
2 User Access configuration and VLAN configuration. In PPPoE
configuration section, we present PPPoE server configuration
and PPPoE client configuration.
Includes overview and configuration of IP address, IP
application configuration, IP performance configuration and
3 Network Layer IP unicast policy routing configuration, as well as the
Protocol configuration when the security gateway/firewall serves as
DHCP server, DHCP client, and DHCP relay configuration,
BOOTP configuration, UDP Helper configuration.
Introduces overview and configuration of IP unicast routing
4 Routing Protocol protocols, including for static routes, RIP, OSPF, BGP, and
routing policy.
Introduces the basic principle and application, and the
5 MPLS
configuration of MPLS basic functions.
Focuses on technical principles and application categories of
VPNs. The configuration details include L2TP and GRE
6 VPN configuration, dynamic VPN configuration, IPsec and IKE
configuration. This part also briefs the configuration of
BGP/MPLS VPN.
Describes the configuration on hierarchical command
protection, RADIUS/HWTACACS-based AAA, packet filtering
firewall, ASPF and NAT, SSL and PKI, transparent firewall,
7 Security
hybrid mode, object-oriented management, Web and E-mail
filtering, attack prevention and packet statistics, IDS
cooperation, log maintenance, as well as ACL.
Focuses on technical principles and configuration of VRRP
8 Reliability
and dual-system hot backup.
Presents the configuration for traffic classification, traffic
policing and traffic shaping, congestion management,
9 QoS congestion avoidance and MPLS QoS. The congestion
management configuration includes that for such queuing
mechanisms as FIFO, PQ, CQ, WFQ, CBQ and RTPQ.
10 Appendix Lists abbreviations and acronyms involved in this manual.
Conventions
The manual uses the following conventions:
I. Command conventions
Convention Description
Boldface The keywords of a command line are in Boldface.
italic Command arguments are in italic.
Items (keywords or arguments) in square brackets [ ] are
[]
optional.
Alternative items are grouped in braces and separated by
{ x | y | ... }
vertical bars. One is selected.
Optional alternative items are grouped in square brackets
[ x | y | ... ]
and separated by vertical bars. One or none is selected.
Alternative items are grouped in braces and separated by
{ x | y | ... } * vertical bars. A minimum of one or a maximum of all can be
selected.
Optional alternative items are grouped in square brackets
[ x | y | ... ] * and separated by vertical bars. Many or none can be
selected.
The argument(s) before the ampersand (&) sign can be
&<1-n>
entered 1 to n times.
# A line starting with the # sign is comments.
II. GUI conventions
Button names are inside angle brackets. For example, click
<>
<OK>.
Window names, menu items, data table and field names
[] are inside square brackets. For example, pop up the [New
User] window.
Multi-level menus are separated by forward slashes. For
/
example, [File/Create/Folder].
III. Symbols
Means reader be extremely careful. Improper operation
Warning may cause bodily injury.
Means reader be careful. Improper operation may cause

Caution data loss or damage to equipment.
Note Means a complementary description.

Fundamental Configuration
Operation Manual – Fundamental Configuration
H3C SecPath Series Security Products Table of Contents
Table of Contents
Chapter 1 Security Products Overview ....................................................................................... 1-1

1.1 Introduction to the Security Gateway................................................................................. 1-1
1.2 Introduction to the Firewall................................................................................................. 1-2
1.3 Features............................................................................................................................. 1-3
1.3.1 Security ................................................................................................................... 1-3
1.3.2 Supporting Abundant VPN Services ....................................................................... 1-4
1.4 Functionality of H3C SecPath Security Products .............................................................. 1-9
Chapter 2 User Configuration Interface ...................................................................................... 2-1

2.1 Setting up Configuration Environments ............................................................................. 2-1
2.1.1 Setup through the Console Port.............................................................................. 2-1
2.1.2 Setup through Telnet............................................................................................... 2-3
2.1.3 Setup through the AUX Port.................................................................................... 2-5
2.1.4 Setup through SSH ................................................................................................. 2-7
2.2 CLI ..................................................................................................................................... 2-8
2.2.1 Command Line Views ............................................................................................. 2-8
2.2.2 Online Help with Command Lines......................................................................... 2-11
2.2.3 Command Line Error Information.......................................................................... 2-12
2.2.4 History Command ................................................................................................. 2-13
2.2.5 Edit Features ......................................................................................................... 2-14
2.2.6 Display Features ................................................................................................... 2-14
2.2.7 Regular Expressions ............................................................................................. 2-15
2.3 Hot Keys .......................................................................................................................... 2-18
2.3.1 Classifying Hot Keys ............................................................................................. 2-18
2.3.2 Usage of the Hot Keys .......................................................................................... 2-19
2.3.3 Examples of Hot Keys in Use................................................................................ 2-20
2.3.4 Configuring Command Alias ................................................................................. 2-20
Chapter 3 Comware Basic Configurations ................................................................................. 3-1

3.1 Entering/Exiting System View............................................................................................ 3-1
3.2 Configuring the Gateway Name......................................................................................... 3-1
3.3 Configuring the System Clock ........................................................................................... 3-1
3.4 Configuring a Banner......................................................................................................... 3-2
3.5 User Level Switching ......................................................................................................... 3-2
3.6 Locking User Interfaces ..................................................................................................... 3-3
3.7 Configuring Command Levels ........................................................................................... 3-3
3.8 Displaying System Information .......................................................................................... 3-4
Chapter 4 System Maintenance and Management..................................................................... 4-1

4.1 Maintenance and Debugging Function .............................................................................. 4-1
i
4.1.1 Testing Network Connection ................................................................................... 4-1

4.1.2 Debugging the System............................................................................................ 4-3
4.1.3 Rebooting the System............................................................................................. 4-5
4.1.4 Upgrading BootROM............................................................................................... 4-5
4.1.5 Configuring Hot Swap ............................................................................................. 4-6
4.2 Information Center ............................................................................................................. 4-7
4.2.1 Introduction.............................................................................................................. 4-7
4.2.2 Configuring the Information Center ......................................................................... 4-8
4.2.3 Setting Display Terminal ....................................................................................... 4-13
4.2.4 Syslog Overview.................................................................................................... 4-14
4.2.5 Displaying and Debugging Information Center ..................................................... 4-16
4.2.6 Information Center Configuration Example........................................................... 4-16
4.3 Configuring HTTP Server ................................................................................................ 4-18
4.3.1 Enabling HTTP server........................................................................................... 4-18
4.3.2 Configuring Access Limit on HTTP Server ........................................................... 4-18
Chapter 5 Auto Detect Configuration .......................................................................................... 5-1

5.1 Introduction to Auto Detect ................................................................................................ 5-1
5.2 Basic Auto Detect Configuration........................................................................................ 5-1
5.2.1 Basic Auto Detect Configuration Tasks .................................................................. 5-1
5.2.2 Auto Detect Configuration Example ........................................................................ 5-2
5.3 Application of Auto Detect in Static Routing ...................................................................... 5-4
5.3.1 Configuring Auto Detect for Static Routing ............................................................. 5-4
5.3.2 Using Auto Detect with Static Routing .................................................................... 5-4
5.4 Application of Auto Detect in VRRP................................................................................... 5-5
5.4.1 Configuring Auto Detect for VRRP.......................................................................... 5-5
5.4.2 Using Auto Detect with VRRP................................................................................. 5-6
Chapter 6 HWPing Configurations .............................................................................................. 6-1

6.1 Introduction to HWPing...................................................................................................... 6-1
6.2 HWPing Configurations ..................................................................................................... 6-1
6.2.1 Configuring HWPing Server .................................................................................... 6-1
6.2.2 Configuring HWPing Client ..................................................................................... 6-2
6.3 Executing Test ................................................................................................................. 6-13
6.4 Displaying and Debugging HWPing................................................................................. 6-14
6.5 Typical HWPing Configuration Example.......................................................................... 6-14
6.5.1 ICMP Test ............................................................................................................. 6-14
6.5.2 DHCP Test ............................................................................................................ 6-15
6.5.3 FTP Test................................................................................................................ 6-16
6.5.4 HTTP Test ............................................................................................................. 6-18
6.5.5 Jitter Test............................................................................................................... 6-18
6.5.6 SNMP Test ............................................................................................................ 6-20
6.5.7 TCP Test of a Specified Port................................................................................. 6-21
6.5.8 UDP Test of a Specified Port ................................................................................ 6-22
ii
Chapter 7 File Management.......................................................................................................... 7-1

7.1 File System ........................................................................................................................ 7-1
7.1.1 Brief Introduction ..................................................................................................... 7-1
7.1.2 Directory Operations ............................................................................................... 7-1
7.1.3 File Operations ........................................................................................................ 7-1
7.1.4 Detaching Web Files ............................................................................................... 7-2
7.1.5 Storage Device Operation....................................................................................... 7-2
7.1.6 File System Prompt Mode....................................................................................... 7-3
7.1.7 Example for the File System Usage........................................................................ 7-3
7.2 FTP Configuration.............................................................................................................. 7-4
7.2.2 Startup..................................................................................................................... 7-4
7.2.3 Configuring the Authentication and Authorization................................................... 7-5
7.2.4 Configuring Operating Parameters of FTP Server.................................................. 7-5
7.2.5 Displaying and Debugging ...................................................................................... 7-7
7.2.6 Introduction to FTP Client ....................................................................................... 7-7
7.2.7 Configuration Example 1: Upgrading the Comware Application Program with
FTP .................................................................................................................................. 7-9
7.2.8 Configuration Example 2: Upgrading the Comware Application Program with
FTP ................................................................................................................................ 7-11
7.3 TFTP Configuration ......................................................................................................... 7-12
7.3.1 TFTP Overview ..................................................................................................... 7-12
7.3.2 TFTP Protocol Configuration................................................................................. 7-12
7.4 Configuration File Management....................................................................................... 7-14
7.4.1 Overview ............................................................................................................... 7-14
7.4.2 Naming Configuration Files and Setting Their Selection Order at Boot................ 7-17
7.4.3 Backing up Configuration Files ............................................................................. 7-18
Chapter 8 User Interface Configuration ...................................................................................... 8-1

8.1 User Interface Overview .................................................................................................... 8-1
8.1.2 Numbering User Interfaces ..................................................................................... 8-1
8.2 User Interface Configuration.............................................................................................. 8-2
8.2.1 Entering User Interface View .................................................................................. 8-2
8.2.2 Configuring the Current User Interface to Support the Protocol(s)......................... 8-3
8.2.3 Configuring Asynchronous Interface Attributes....................................................... 8-3
8.2.4 Configuring Terminal Attributes............................................................................... 8-5
8.2.5 Configuring Modem Attributes................................................................................. 8-8
8.2.6 Configuring the auto-execute command ................................................................. 8-8
8.2.7 Configuring Inbound/Outbound Call Restriction on the VTY User Interface........... 8-9
8.3 Displaying and Debugging............................................................................................... 8-10
8.3.1 Displaying Use Information ................................................................................... 8-10
8.3.2 Displaying Physical Attributes and Some Configurations ..................................... 8-10
iii
Chapter 9 User Management........................................................................................................ 9-1

9.1 User Management Overview ............................................................................................. 9-1
9.1.1 User Classification................................................................................................... 9-1
9.1.2 User Priority............................................................................................................. 9-2
9.1.3 User Authentication................................................................................................. 9-2
9.1.4 Firewall User Planning ............................................................................................ 9-3
9.2 User Management Configuration....................................................................................... 9-3
9.2.1 Configuring User Authentication Mode ................................................................... 9-3
9.2.2 Configuring Username and Password .................................................................... 9-4
9.2.3 Configuring User Priority ......................................................................................... 9-5
9.2.4 Setting accounting according to command lines..................................................... 9-6
9.3 Displaying User Information............................................................................................... 9-6
9.4 Typical Example of User Management.............................................................................. 9-7
9.4.1 Performing Password Authentication ...................................................................... 9-7
9.4.2 Performing User Authentication Using the Local User Database ........................... 9-7
Chapter 10 NTP Configuration ................................................................................................... 10-1

10.1 Brief Introduction............................................................................................................ 10-1
10.2 NTP Configuration ......................................................................................................... 10-3
10.2.1 Configuring NTP Operation Mode....................................................................... 10-3
10.2.2 Configuring NTP ID Authentication ..................................................................... 10-6
10.2.3 Setting the Interface for the Local to Transmit NTP Messages .......................... 10-8
10.2.4 Setting Local Clock as NTP Master Clock .......................................................... 10-8
10.2.5 Configuring an Interface to Receive NTP Messages .......................................... 10-9
10.2.6 Setting Access Control Authority of the Local Firewall Services ........................ 10-9
10.2.7 Setting Number of Sessions Allowed to be Established Locally....................... 10-10
10.3 Displaying and debugging ........................................................................................... 10-10
10.4 NTP Typical Configuration Examples .......................................................................... 10-11
10.4.1 NTP Server Configuration Example .................................................................. 10-11
10.4.2 NTP Peer Configuration Examples ................................................................... 10-13
10.4.3 Configuring NTP Broadcast Mode .................................................................... 10-14
10.4.4 Configuring NTP Broadcast Mode with ID Authentication ................................ 10-16
10.4.5 Configuring NTP Multicast Mode ...................................................................... 10-18
10.4.6 Configuring NTP Server Mode with ID Authentication ...................................... 10-19
Chapter 11 SNMP Configuration................................................................................................ 11-1

11.1 Protocol Introduction...................................................................................................... 11-1
11.1.1 Brief Introduction ................................................................................................. 11-1
11.1.2 SNMP Versions and Its Supported MIB.............................................................. 11-1
11.2 SNMP Configuration ...................................................................................................... 11-2
11.2.1 Setting the SNMP Agent Service ........................................................................ 11-2
11.2.2 Setting the Corresponding Versions of SNMP.................................................... 11-3
11.2.3 Setting the Community Name ............................................................................. 11-3
11.2.4 Setting the SNMP Group..................................................................................... 11-4
iv
11.2.5 Setting the SNMP User ....................................................................................... 11-4

11.2.6 Setting the System Contact................................................................................. 11-5
11.2.7 Setting the Sending Trap .................................................................................... 11-5
11.2.8 Setting the Engine ID of a Local Device ............................................................. 11-6
11.2.9 Setting the Address of the Trap Target Host ...................................................... 11-6
11.2.10 Set the interface to send Trap packets ............................................................. 11-7
11.2.11 Setting the Firewall’s Location (sysLocation).................................................... 11-7
11.2.12 Setting the Source Address for Sending Traps................................................. 11-7
11.2.13 Setting the MIB View......................................................................................... 11-8
11.2.14 Setting the Maximum Size of SNMP Packets ................................................... 11-8
11.2.15 Setting the Packet Queue Length of Trap Packet............................................. 11-9
11.2.16 Setting the Saving Time of Trap Packets.......................................................... 11-9
11.3 Displaying and Debugging........................................................................................... 11-10
11.4 Example of Typical Configuration ................................................................................ 11-10
Chapter 12 BIMS Configuration ................................................................................................. 12-1

12.1 Introduction to BIMS ...................................................................................................... 12-1
12.2 Configuring BIMS........................................................................................................... 12-2
12.2.1 Enabling BIMS on a Device ................................................................................ 12-2
12.2.2 Configuring the Unique ID of the Device............................................................. 12-3
12.2.3 Configuring the IP Address and Port number of the BIMS Center ..................... 12-3
12.2.4 Configure the Source IP Address of the Packet Sent by the BIMS Device ........ 12-4
12.2.5 Configuring the Shared Key Between the Device and the Center...................... 12-4
12.2.6 Enabling/Disabling the Device to Access the Center Once Powered on............ 12-4
12.2.7 Enabling/Disabling the Device to Access the Center at Regular Intervals ......... 12-5
12.2.8 Enabling/Disabling the Device to Access the Center at Specific Time ............... 12-5
12.2.9 Enabling the Device to Access the Center Immediately ..................................... 12-6
12.3 Displaying and Debugging BIMS ................................................................................... 12-6
12.4 BIMS Configuration Example......................................................................................... 12-6
12.4.1 Enable the Device to Access the BIMS Center Once Powered on..................... 12-6
12.4.2 Enable the Device to Periodically Access the BIMS Center in a Time Range ............ 12-8
12.5 Troubleshooting BIMS ................................................................................................... 12-9
12.5.1 Device Cannot Access BIMS Server Successfully ............................................. 12-9
12.5.2 New Files Cannot Be Downloaded to Device ..................................................... 12-9
12.5.3 Device Cannot Obtain BIMS Configuration Through DHCP............................. 12-10
12.5.4 The Access Interval Is Changed for Accessing BIMS Server........................... 12-10
Chapter 13 RMON Configuration ............................................................................................... 13-1

13.1 Introduction .................................................................................................................... 13-1
13.2 RMON Configuration ..................................................................................................... 13-2
13.2.1 Adding/Removing an Event Entry ....................................................................... 13-2
13.2.2 Adding/Removing an Alarm Entry ....................................................................... 13-2
13.2.3 Adding/Removing a Prialarm Entry ..................................................................... 13-3
13.2.4 Adding/Removing a History Control Entry .......................................................... 13-4
v
13.2.5 Adding/Removing a Statistics Entry .................................................................... 13-4

13.2.6 Displaying and Debugging RMON ...................................................................... 13-5
13.3 RMON Configuration Example ...................................................................................... 13-5
Chapter 14 Terminal Services .................................................................................................... 14-1

14.1 Terminal Services Overview .......................................................................................... 14-1
14.2 Console Terminal Services............................................................................................ 14-1
14.3 Remote Terminal Services on AUX interface ................................................................ 14-1
14.3.1 Function Description ........................................................................................... 14-1
14.3.2 Terminal Service Characteristics of the Remote Config on AUX Interface................. 14-2
14.4 Telnet Terminal Services ............................................................................................... 14-3
14.4.1 Telnet Service Types .......................................................................................... 14-3
14.4.2 Establishing Telnet Connection........................................................................... 14-4
14.4.3 Specifying a Source Interface/IP Address for the Telnet Server ........................ 14-5
14.4.4 Displaying and Debugging .................................................................................. 14-6
14.5 SSH Configuration ......................................................................................................... 14-7
14.5.1 SSH Introduction ................................................................................................. 14-7
14.5.2 SSH Server Configuration................................................................................. 14-10
14.5.3 SSH Client Configuration .................................................................................. 14-17
14.5.4 Displaying and Debugging ................................................................................ 14-19
14.5.5 SSH Server Configuration Example.................................................................. 14-20
14.5.6 SSH Client Configuration Example ................................................................... 14-23
14.6 SFTP Service............................................................................................................... 14-24
14.6.1 Introduction to SFTP ......................................................................................... 14-24
14.6.2 Configuring the SFTP Server ............................................................................ 14-24
14.6.3 Configuring the SFTP Client ............................................................................. 14-26
14.6.4 SFTP Configuration Example............................................................................ 14-29
14.7 Dumb Terminal Service ............................................................................................... 14-32
14.7.1 Description on Dumb Terminal Functions......................................................... 14-32
14.7.2 Dumb Terminal Service Features ..................................................................... 14-32
14.7.3 Typical Application of Dumb Terminal .............................................................. 14-32
14.7.4 Configuring Dumb Terminal Service ................................................................. 14-33
14.7.5 Timely Disconnecting Dumb Terminals ............................................................ 14-35
Chapter 15 Modem Configuration.............................................................................................. 15-1

15.1 Overview of Modem....................................................................................................... 15-1
15.1.1 Modem Functions Provided by Comware ........................................................... 15-1
15.1.2 Modem Script ...................................................................................................... 15-1
15.2 Modem Configuration .................................................................................................... 15-3
15.2.1 Configuring Modem Call-In and Call-Out ............................................................ 15-4
15.2.2 Configuring a Modem Script................................................................................ 15-4
15.2.3 Executing a Modem Script Manually................................................................... 15-4
15.2.4 Configuring the Modem Answer Mode................................................................ 15-5
15.3 Modem Display and Debug ........................................................................................... 15-5
vi
15.4 Typical Modem Configuration Example......................................................................... 15-6

15.4.1 Managing Modem through Modem Script........................................................... 15-6
15.4.2 Dialing Directly with the Script............................................................................. 15-7
15.5 Troubleshooting ............................................................................................................. 15-7
Chapter 16 Interface Configuration ........................................................................................... 16-1

16.1 Interface Configuration Overview .................................................................................. 16-1
16.1.1 Interface Introduction .......................................................................................... 16-1
16.1.2 Interface Configuration........................................................................................ 16-1
16.1.3 Displaying and Debugging Interfaces ................................................................. 16-3
16.2 Ethernet Interface .......................................................................................................... 16-4
16.2.1 Ethernet Interface Introduction............................................................................ 16-4
16.2.2 Ethernet Interface Configuration ......................................................................... 16-5
16.2.3 Displaying and Debugging Ethernet Interface .................................................... 16-9
16.2.4 Ethernet Configuration Example ....................................................................... 16-10
16.2.5 Troubleshooting ................................................................................................ 16-10
16.3 AUX interface............................................................................................................... 16-12
16.3.1 Introduction to AUX interface ............................................................................ 16-12
16.3.2 Configuring AUX interface................................................................................. 16-12
16.4 Logical Interface........................................................................................................... 16-14
16.4.1 Dialer Interface .................................................................................................. 16-14
16.4.2 Loopback Interface............................................................................................ 16-16
16.4.3 Null Interface ..................................................................................................... 16-17
16.4.4 Subinterface ...................................................................................................... 16-18
16.4.5 Virtual-Template and Virtual Interface .............................................................. 16-20
vii
H3C SecPath Series Security Products Chapter 1 Security Products Overview
Chapter 1 Security Products Overview
Note:
z SecPath series security products include SecPath series security gateway devices
and SecPath series firewall devices. This manual takes the SecPath series firewall
devices as examples in configuration operations, which are also applicable to the
security gateway devices.
z Please refer to the products for the functions and command lines they support.
1.1 Introduction to the Security Gateway

The H3C SecPath Security Gateway (hereinafter referred to as security gateway) is a
new network security device developed for enterprise users. It can be used for
convergence and network access. The security gateway supports:
z Packet filtering firewall, AAA (Authentication, Authorization, Accounting), NAT
(Network Address Translation), and QoS (Quality of Service) technologies;
therefore, it can ensure safety and reliability for private networks in the open
Internet.
z Multiple Virtual Private Network (VPN) services, such as Layer 2 Tunneling
Protocol (L2TP) VPN, IP security (IPsec) VPN, Generic Routing Encapsulation
(GRE) VPN, and Dynamic VPN, thus allowing users to build various VPNs, like
Intranet, Extranet and Access VPNs using customized remote-user access
approaches, including dial-up, leased line, Virtual LAN (VLAN), and tunneling.
z A comprehensive encryption solution. It realizes high-speed IPsec/ Secure Socket
Layer (SSL) using encrypted chips.
z Basic routing features, including Routing Information Protocol (RIP) / Open
Shortest Path First (OSPF) / Border Gateway Protocol (BGP) routing policy and
policy routing, also it provides abundant QoS features, such as traffic classification,
traffic policing, traffic shaping and queue scheduling.
1-1
1.2 Introduction to the Firewall

The H3C SecPath Firewall (hereinafter referred to as firewall) supports all the above
features of the security gateway. In addition, the firewall supports various security
features, which include:
z Attack defense. With this feature, the firewall can detect various network attacks,
such as IP address spoofing, address and port scanning, SYN Flood, and Ping of
Death attacks, and then take measures to protect the internal network against
malicious attacks and maintain the normal operation of your network.
z Web and E-mail filtering. With this feature, you can inhibit internal users from
accessing illegal websites or accessing web pages containing illegal contents, and
inhibit them from sending E-mails to illegal E-mail addresses in external networks
or sending work-independent E-mails outside. Besides, this function blocks
E-mails from outside.
z Blacklist. With this feature, the firewall can filter packets with high speed to
efficiently screen out the packets received from particular IP addresses.
z MAC/IP addresses binding, a method used to prevent IP address spoofing attack.
z IDS (Intrusion Detect System) cooperation. With this feature, the firewall can
cooperate with external IDS device (making use of the deep detect capability of
the device) to resist the intrusion from hackers and network viruses.
Caution:
z SecPath series firewall uses the concept of security zone to represent the network
connected to it. You should add the corresponding interface of the firewall to a
security zone first to achieve the interconnection between the firewall and other
devices.
z By default, SecPath series firewall enables the packet filtering function. The default
filtering function blocks all packets passing through. To achieve the interconnection
between the firewall and other devices, you should disable the packet filtering
function of the firewall first, or change the default filtering function into permitting the
packets to pass through, or enable the Access Control List (ACL) on the interface to
permit the corresponding packets to pass through.
Refer to Security part in this manual for detailed description of the above contents.
1-2
1.3 Features
1.3.1 Security
I. Firewall
Firewall supports packet filtering technologies. It uses packet priority, Type of Service
(ToS), User Datagram Protocol (UDP), or Transport Control Protocol (TCP) port as
filtering items, and adopts basic or advanced access control rules on the incoming or
outgoing interface. In addition, it supports filtering in different time ranges, which not
only protects internal network from external attack, but also effectively control the
internal access to external networks. As the rules are automatically sorted, the
configuration is simplified.
Firewall supports Application Specific Packet Filter (ASPF). This is a superior
communication filter, which checks the TCP/UDP based application-layer protocols
(including FTP, HTTP, SMTP, RTSP and H.323 currently), monitors the status of the
connection-oriented application-layer protocols, maintains the status information of
each connection, and dynamically determines whether a packet is permitted to pass
through the firewall.
II. Authentication
Firewall provides the following authentication functions.

z User level management. Firewall grants different access authorities to users of
different levels, so that it can prevent low-level users to obtain or modify
configuration information illegally. There are four user levels: visit, monitor, config,
and management.
z Hierarchical view protection. Users are divided into four levels and granted
different configuration authorities. The users of a lower level are not permitted to
access the views for high-level users.
z Supporting CHAP and PAP on the PPP line.
z Supporting RADIUS-based and HWTACACS-based ( HUAWEI Terminal Access
Controller Access Control System ) AAA. Firewall works with the RADIUS server
and TACACS server to implement AAA, so as to prevent illegal access.
z Supporting OSPF and RIPv2 that can perform MD5 authentication, which ensures
the reliability of the switched routing information.
III. NAT
NAT, also called address proxy, replaces the IP addresses and port numbers of internal
hosts with external addresses and port numbers, which effectively controls the
accessibility between internal and external networks. It not only saves the valuable IP
address resource, but also protects the privacy of internal hosts.
1-3
Firewall currently provides several NAT modes, such as one-to-one, many-to-one,

address pool, and ACL, and multiple NAT modes are supported on one interface. So it
can provide FTP, Telnet, and WWW services to external users by using the internal
server, as well as a solution to combine addresses of public and private networks.
1.3.2 Supporting Abundant VPN Services
I. L2TP VPN
L2TP supports tunneling transmission for datagram on the PPP link layer. Firewall
implements PAP and CHAP provided by PPP according to L2TP, and supports
authentication by RADIUS server, internal addresses allocation, and flexible
accounting service at both ends of the tunnel. In addition, it integrates technologies like
firewall and IPsec to ensure information security. L2TP is good for mobile users to build
Access VPN through the tunnel..
There are two typical L2TP tunneling modes:
1) Tunneling initiated by remote dial-in users
The system dials LAC via PSTN/ISDN/ADSL, and LAC requests LNS to set up a tunnel
via the Internet. LNS allocates addresses to dial-in users. Both the proxies at LAC side
and LNS side can perform authentication and accounting for remote dial-in users.
2) Tunneling initiated directly by LAC clients (users that support L2TP locally)
After the public network address is allocated to the LAC client, the LAC client can make
a request for tunnel establishment to LNS directly without using LAC. LNS allocates
private addresses to LAC clients.
II. GRE VPN
GRE is a layer 3 protocol. It uses a technology called Tunnel between protocol layers to
encapsulate and decapsulate datagram at both ends of a tunnel. Tunnel is a virtual
point-to-point connection, and in fact can be regarded as a virtual interface supporting
only point-to-point connection. This interface provides a path on which the
encapsulated datagram can travel. When the datagrams of the network layer protocols
(such as IP, IPX, and AppleTalk) are encapsulated in this approach, they can be
transmitted in another network layer protocol. As this mechanism is simple, the CPUs
of the devices at both ends of the tunnel have small loads. GRE neither provides data
encryption, nor authenticates data source, nor guarantees correct data destination,
hence it is usually used with IPsec to build Intranet/Extranet VPN.
III. IPsec VPN
IPsec protocol suite is established by Internet Engineering Task Force (IETF). It

ensures reliable, interoperable, and encryption-based security. Both parties in
communication can assure privacy, integrality, authenticity, and anti-replay of datagram
transmitted on a network by using encryption and data-source authentication on the IP
1-4
layer. This can be achieved by IPsec using Authentication Header (AH) and
Encapsulating Security Payload (ESP). You can manually set up a security association
(SA) for IPsec; or configure Internet Key Exchange (IKE) to automatically provide key
for IPsec by auto-negotiation and to set up and maintain the SA. IPsec provides a safe
VPN solution for the users requiring high information security. Generally, IPsec is used
with L2TP and GRE.
1) Operational modes of IPsec
IPsec has two operational modes: transport and tunnel, which are specified by SA.
In transport mode, AH or ESP is inserted between the IP header and the transport layer
protocols. In tunnel mode, AH or ESP is put in front of the original IP header or; a new
header is generated and put in front of AH or ESP. The following figure shows the data
encapsulation formats of different security protocols in transport and tunnel modes
(transport protocols are represented by TCP).
Mode
transport tunnel
Protocol
AH IP TCP new IP raw IP TCP

AH data data
Header Header Header AH Header Header
ESP IP TCP data ESP ESP new IP raw IP TCP ESP ESP
ESP ESP Header Header data
Header Header Tail Auth data Header Tail Auth data
AH-ESP IP TCP data ESP ESP new IP raw IP TCP ESP ESP
AH ESP AH ESP Header Header data
Header Header Tail Auth data Header Tail Auth data
Figure 1-1 Data encapsulation formats of security protocols
In terms of security, the tunnel mode takes precedence of the transport mode. Because
it can authenticate and encrypt the original IP datagram thoroughly, and use the IP
address of an IPsec peer to hide the client’s IP address. In terms of performance,
however, the tunnel mode occupies more bandwidth than the transport mode, as it has
an extra IP header. Therefore, you should balance the security and performance before
you make a decision.
2) Authentication algorithm
Both AH and ESP can check the integrity of an IP message, so as to judge whether it
has been changed during transmission. The authentication algorithm is based on the
hashing function. The hashing function is an algorithm that accepts input messages of
any length and produces fixed-sized output messages, which are called message
summaries. The IPsec peer calculates the summaries; if both summaries are the same,
the message is unchanged. Generally speaking, IPsec uses two types of algorithms:
z MD5: it receives messages of any length and produces message summaries of
128 bits.
z SHA-1: it receives messages of less than 264 bits and produces message
summaries of 160 bits.
1-5
Compared with MD5, SHA-1 produces longer message summary; so it is safer.

3) Encryption algorithm
ESP encrypts IP messages and protects them against eavesdropping. Encryption
algorithm utilizes symmetry key system, which uses the same key to encrypt and
decrypt data. Comware IPsec offers three encryption algorithms:
z DES: it encrypts a 64-bit plain text using a 56-bit key.
z 3DES: it encrypts a plain text using three 56-bit DES keys (equal to a 168-bit key).
3DES offers higher security, but it encrypts data much slower than DES.
z AES (Advanced Encryption Standard): Comware offers AES algorithm with
128-bit, 192-bit and 256-bit key length.
4) Negotiation
You can set up an SA manually or using IKE auto-negotiation (isakmp). The first
method is more complicated: you have to configure all the required information
manually, and some advanced features of IPsec, such as changing the key regularly,
are not supported. But it can implement IPsec independent of IKE. The second method
is easier: you just need to configure the IKE negotiation policy and IKE auto-negotiation
can set up and maintain the SA.
It is feasible to configure the SA manually if there are a small number of peer devices,
or in small and static networks. For medium or large dynamic networks, you are
recommended to use IKE negotiation to set up the SA.
5) IKE
When implementing IPsec, you can use IKE to set up an SA, which is based on the
framework defined by Internet Security Association and Key Management Protocol
(ISAKMP). IKE provides services like key exchange and AS establishment for IPsec
through auto-negotiation. Therefore, it can distribute keys, authenticate identity, and
set up IPsec SA safely on insecure networks, which simplifies the use and
management of IPsec and further ensures data security. The security mechanism of
IKE includes:
z DH (Diffie-Hellman) exchange and key distribution
DH is a common key algorithm. It calculates the shared key when both parties in
communication exchange some data without giving the keys to each other. The
prerequisite to encryption is that the two parties exchanging encrypted data must have
a shared key. The soul of IKE is that it calculates the key shared by both parties by
using the exchanged data, instead of transferring the key directly on an insecure
network. Hence even if a third party, such as a hacker, captures the exchanged data, he
cannot calculate the real key.
z Perfect Forward Secrecy (PFS)
PFS provides a security feature: when one key is decrypted, the secrecy of other keys
is not threatened, because there is no derivative relation between these keys. IPsec is
implemented by adding one key exchange during IKE negotiation phase II.
1-6
z Authentication
Authentication confirms the identities of both parties. For the authentication method
using pre-shared key, authenticators are input to produce a key. It is impossible for two
parties to have the same key if their authenticators are not the same. Authenticator is
fundamental to authentication between two parties.
z Identity protection
The data of identity is encrypted and transmitted after the key is created, so that the
identity-related data is protected.
z Negotiation modes in IKE phase
In the widely used ADSL-based VPN construction solution, there is the possibility that
the devices at the central office use fixed IP addresses and the devices at the user end
use dynamic IP addresses. In order to make IKE support this special case, IKE
aggressive mode is added as a negotiation mode in IKE phase. This mode can find the
corresponding authenticator according to the negotiation initiator’s the IP address or ID,
and finally complete the negotiation. IKE aggressive mode is more flexible than the
main mode; it works even if the negotiation initiator uses a dynamic IP address.
z NAT traversal
In the VPN tunnel built by IPsec/IKE, if there is a NAT gateway, which translates the
network addresses of VPN data streams, you must configure NAT traversal for
IPsec/IKE. The NAT traversal module disables to authenticate the UDP port number
during IKE negotiation and discovers the NAT gateway in the VPN tunnel. If it discovers
the NAT gateways, it uses the UDP encapsulation in future IPsec data transmission
(that is, it encapsulates IPsec messages in the UDP connection tunnel used by IKE
negotiation), so as to prevent NAT gateway from changing IPsec messages (NAT
gateway can only change the IP and UDP message headers but cannot change the
IPsec messages encapsulated in UDP messages). Therefore, the integrality of IPsec
messages is ensured (IPsec data encryption, decryption and authentication processes
require that messages transmitted to the receiver remain intact).
IV. Dynamic VPN
Dynamic VPN (DVPN) introduces NBMA (NonBroadcast MultiAccess) tunneling

mechanism and adopts client and server to solve the problems in traditional VPNs.
With this technology, you can use the backbone network to connect multiple private
networks into a VPN. Its features include the following:
1) Tunneling in GRE and UDP modes
DVPN supports tunneling in both GRE and UDP modes, and therefore can traverse
NAPT gateway, making it possible for the IP address of the private network to establish
VPN network with other firewalls through NAPT gateway.
2) VPN establishment based on dynamic IP addresses
1-7
When a DVPN sets up tunnels within the same VPN, it only requires the IP address of
the corresponding server, without concerning its own IP address. So it is more
applicable to the network applications in which dynamic IP addresses are used, such
as xDSL dial-up.
3) Auto-tunneling technologies
Each node in a DVPN maintains a public–private network address mapping table, and
the tunnel between any two nodes is set up automatically. Each firewall, as a client,
only needs its own configuration information, such as the local IP address, port number
used in UDP mode, the VPN where it is located, and the server, and can communicate
with other clients without requiring any information. Hence it not only relieves the
burden of maintenance and management, but also reduces the possibility of errors.
4) Authentication and encryption
DVPN uses authentication and encryption technologies, ensuring data and network
security to the full extent. DVPN provides registration authentication mechanism, by
which a client must be authenticated by the server before it joins a specific VPN domain.
DVPN also provides mutual authentication when two clients set up a tunnel between
them.
5) Multiple domains supported
DVPN allows a firewall to support multiple VPN domains. That is, a firewall can belong
to both VPN A and VPN B; in addition, it can be the client in VPN A and the server in
VPN B. This feature significantly enhances networking flexibility, helps to make full use
of network resources, and decreases investment.
1-8
1.4 Functionality of H3C SecPath Security Products

Table 1-1 Feature of H3C SecPath Security Products
Feature Description
z RADIUS
z HWTACACS
AAA
z CHAP authentication
z PAP authentication
z Packet filtering
Interface-based ACL
Time range-based ACL
z Firewall
Packet filter
ASPF
Transparent firewall (supported only by SecPath
F100-C and F100-S series firewalls)
Hybrid mode (supported only by SecPath F1000-A,
F1000-S, F100-A, F100-M, and F100-E series
firewalls)
Network Black list (supported only by SecPath series firewalls)
security Firewall MAC and IP address binding (supported only by
SecPath series firewalls)
Web and E-mail filtering (supported only by SecPath
series firewalls)
Attack prevention (supported only by SecPath series
firewalls)
IDS cooperation (supported only by SecPath series
firewalls)
Object oriented management (supported only by
SecPath F1000-A, F1000-S, F100-A, F100-M, F100-E
series firewalls, and SecPath V1000-A series security
gateways)
Firewall flow log (supported only by SecPath F1000-A,
F1000-S, F100-A, F100-M, and F100-E series
firewalls)
z Terminal access security
Data
z IPsec
security
z IKE
1-9
Feature Description
z Supports users in the LAN to use IP addresses in
the address pool to access external networks.
z Supports the association between ACL and
address pool.
z Supports the association between ACL and
NAT interfaces.
z Supports hosts in external networks to access the
server of internal network.
z Configures valid time for NAT.
z Supports multiple application layer gateways
(ALG).
Connects to the specified LNS according to full user
name, user domain name of a VPN user.
L2TP VPN Allocates addresses for VPN users.
Supports LCP renegotiation and twice CHAP
authentication
Supports AH and ESP protocols.
Allows user to set up security association manually or
by IKE.
ESP supports DES and 3DES encryption algorithms.
Supports MD5 and SHA-1 authentication algorithms.
IPsec/IKE
Supports IKE main mode and aggressive mode.
Supports NAT traversal.
(All security products support IPsec hardware
encryption except the SecPath F100-C series
firewalls.)
VPN Encrypts and decrypts packets at both end of the
GRE VPN tunnel respectively using virtual point-to-point tunnel
technology.
Provides two tunnels: GRE and UDP (SecPath Series
Firewalls only supports UDP tunnel)
Supports access authentication of client terminals and
encryption authentication between nodes
Build VPN based on dynamic IP addresses.
DVPN Supports one node to belong to different VPN
domains.
Supports multiple VPN domains
Supports NAT traversal
DVPN tunnels can bear IPsec encryption
Establishes tunnels dynamically to save bandwidth
MPLS L3 Supports MPLS L3 VPN (only SecPath V1000-A
VPN security gateways support MPLS and VPN instance)
1-10
Feature Description
Ethernet_II
LAN
Ethernet_SNAP
Network protocols
interconne VLAN
ction
Link-layer PPP
protocols PPPoE
ARP
Static domain name resolution
IP unnumbered
IP services
DHCP relay
DHCP server
DHCP client
Network
protocols z Static route management
z Dynamic routing protocols
RIP-1/RIP-2
IP routing OSPF
BGP
z Routing policy
z Policy routing
Provides standby solutions to failure in network
communication or equipments in order to ensure
VRRP
smooth data transmission, thus to enhance the
network stability and reliability.
Network Implements status backup between two firewalls in
reliability order to ensure service continuity. This feature helps to
Dual-syste
compensate the disadvantages of traditional networks
m hot
(VRRP, for example). (This feature is supported only
backup
by SecPath F1000-A, F1000-S, F100-A, F100-M,
F100-E series firewalls.)
Traffic
Traffic policing
policing
Congestion
manageme FIFO, PQ, CQ, WFQ, CBQ/LLQ, RTPQ
nt
Congestion
RED and WRED
Quality of avoidance
Service Traffic
(QoS) TS
shaping
Interface
rate LR
limitation
Deeper DAR (supported only by SecPath F1000-A, F1000-S,
application F100-A, F100-M, F100-E series firewalls, and
recognition SecPath V1000-A security gateways)
1-11
Feature Description
Local configuration via Console port.
Remote configuration via AUX port.
Local or remote configuration using Telnet or SSH.
Hierarchical protection to configuration commands
prevents unauthorized users from modifying the
device.
Detailed debugging information helps to troubleshoot
the network.
Command Network test tools, such as tracert and ping, help to
line determine whether the network is in normal conditions.
Configurati interface Logs onto other devices using Telnet and performs
on management.
manageme FTP server/client. Downloads and uploads
nt configuration files and applications using FTP.
Downloads and uploads files using TFTP.
Supports log function.
File system management.
User-interface configuration provides multiple
authentication and authorization methods.
Supports SNMPV3 and is compatible with SNMP V2C, SNMP V1.
Supports BIMS.
Supports VPN Manager.
Supports NTP time synchronization.
1-12
H3C SecPath Series Security Products Chapter 2 User Configuration Interface
Chapter 2 User Configuration Interface
2.1 Setting up Configuration Environments

The system supports both local and remote configuration. The following subsections
tell you how to set up the configuration environments.
2.1.1 Setup through the Console Port
Step 1: To set up a local configuration environment, connect the serial port on a PC (or
terminal) to the console port on the firewall using a standard RS-232 cable, as shown in
Figure 2-1.
Console Console
Cable
SecPath
RS-232 serial port PC
Figure 2-1 Set up a local configuration environment through the console port
Step 2: Run the terminal emulation program (Windows9X/Windows XP/Windows 2000

HyperTerminal for example) on the PC, and set the terminal communication
parameters as follows:
Bits per second: 9600
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None
Terminal Type: VT100
See Figure 2-2 through Figure 2-4.
2-1
Figure 2-2 New connection
Figure 2-3 Set the connection port
2-2
Figure 2-4 Set the port communication parameters
Step 3: The firewall runs Power-On Self-Test (POST), and upon its completion prompts
you to press <Enter> until the command line prompt (such as <H3C>) appears.
Step 4: Enter commands to configure the firewall or view its running state. Whenever
you need help, enter "?” For more information about the commands, see the chapters
coming later.
2.1.2 Setup through Telnet
You may telnet to the firewall through a LAN or WAN, provided that:
1) This is not the first power-on of the firewall.
2) You have correctly configured the IP addresses of the interfaces on the firewall.
3) You have appropriately configured authentication at login and access control
rules.
4) At least a reachable route exists between the console terminal and the firewall.
Follow these steps to set up a configuration environment:
Step 1: Connect the Ethernet port on the PC to the Ethernet port on the firewall through
the LAN for a local environment as shown in Figure 2-5 or through the WAN for a
remote environment as shown in Figure 2-6.
2-3
SecPath
Workstation
Ethernet
Laptop
Serv er pc
Telnet-enabled local PC
Figure 2-5 Set up a local configuration environment through the LAN
SecPath
Workstation Local LAN Ethernet
Laptop WAN line
Server PC
WAN
Telnet enabledlocal
- PC
Remote LAN Ethernet

Workstation
SecPath
Laptop
PC
Server
Figure 2-6 Set up a configuration environment through the WAN
Step 2: Run the Telnet program on the PC, as shown in Figure 2-7.
2-4
Figure 2-7 Run the Telnet program and set up Telnet connection with the firewall
Note:
The Telnet connection interface may differ in various operating systems. The above
figure is just for reference.
Step 3: Enter the IP address of the firewall’s Ethernet port on the local PC (or the IP
address of the firewall’s WAN port on the remote PC) to connect with the firewall. If the
authentication succeeds, the system will display the command line prompt (<H3C> for
example).The message "All user interfaces are used, please try later!” means that
system can permit no more Telnet users, please wait until the network is released, then
try again.
Step 4: Enter commands to configure the firewall or view its running state. Whenever
you need help, enter "?” For more information about the commands, see the chapters
coming later.
Note:
When you telnet to the firewall to configure it, take cautions in modifying its IP address,
as such modification may result in disconnection of the Telnet link. If you must make
modification, enter the new IP address of the firewall and try for a new connection.
2.1.3 Setup through the AUX Port
To set up a configuration environment by connecting the AUX port on the firewall

through modem dial, you need to attach a modem to the serial port on the PC and a
modem to the AUX port on the firewall, as shown in Figure 2-8.
Step 1: Attach a modem to the AUX port.
2-5
Serial port
PC
Telephone line Modem

SecPath
PSTN
AUX
Modem
Figure 2-8 Set up a remote configuration environment
Step 2: Dial to connect the firewall remotely by using a terminal emulation program
(such as Windows9X HyperTerminal). In the HyperTerminal, select the RS-232 serial
port of the PC for connection, and set the terminal communication parameters similar to
those used for setting up connection through the console port:
Bits per second: 9600
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None or hardware control
Terminal Type: VT100
See Figure 2-9 and Figure 2-10.
2-6
Figure 2-9 Set the number to be dialed
Figure 2-10 Dial on the remote PC
Step 3: Enter the correct username and password. When you see the command line
prompt (<H3C> for example) in the HyperTerminal, configure or manage the firewall.
2.1.4 Setup through SSH
Secure Shell (SSH) provides high information security and powerful authentication to
protect your firewall from attacks such as IP address spoofing, plain text password
interception. These attacks are likely to happen when users log onto the firewall from
an insecure remote network. The firewall can be connected to multiple SSH clients for
setting up connections with firewalls or UNIX hosts that run SSH server. The
environment configuration procedures are similar to those with Telnet.
Step 1: To set up a local configuration environment, connect the Ethernet port of the PC
to that on the firewall through the LAN, or construct network layer interconnection
2-7
through a Hub or Ethernet switch. To set up a remote configuration environment,

connect the PC and the firewall over the WAN.
Step 2: Configure SSH parameters on the firewall. For more information, refer to
Chapter 14 “Terminal Services”.
Step 3: Run SSH client program on the PC; and set the parameters including the IP
address of the remote firewall, SSH version, and RSA key file. Then establish a
connection to the firewall for configuration.
2.2 CLI
The system provides rich configuration commands and the CLI through which users
can configure and manage their firewalls. The CLI supports:
z Local and remote configuration through the AUX port.
z Local configuration through the console port.
z Local and remote configuration through Telnet and SSH.
z User interface view for managing the particular configurations of different terminal
users.
z Hierarchical command protection where users can only execute the commands at
their own or lower levels.
z Local, password, and AAA authentication modes to safeguard the firewall against
intrusion.
z Easy access to on-line help by entering “?”
z Quick network test tools such as tracert and ping.
z Abundant debugging information for fault diagnosis.
z Telneting to other devices for management.
z FTP and TFTP services for easy file uploading and downloading.
z Saving and executing commands that have be executed.
z Multiple intelligent command parsing methods (provided by command line
descriptor) such as fuzzy match and context association for convenience of input.
2.2.1 Command Line Views
For hierarchical protection, system commands are divided into four levels:
z Visit: involves commands for network diagnosis (such as ping and tracert),
commands for accessing an external device (such as Telnet client, SSH client,
RLOGIN). Saving the configuration file is not allowed at this level.
z Monitor: includes the display and debugging commands for system maintenance,
service fault diagnosis. Saving the configuration file is not allowed at this level.
z System: provides service configuration commands, including routing and
commands at each level of the network for providing services.
z Manage: influences the basic operation of the system and the system support
modules for service support. Commands at this level involves file system, FTP,
2-8
TFTP, configuration file switch, power control, standby board control, user
management, level setting, as well as parameter setting within a system (the last
case involves those non-protocol or non RFC provisioned commands).
Login users are also classified into four levels that correspond to the four command
levels. After users at different levels log in, they can only use commands at their own, or
lower levels.
To fence off intrusion of illegitimate users, users are required to provide the correct
super password, if one has been configured using the super password [ level
user-level ] { simple | cipher } text command, when they switch from a lower level to a
higher level. For privacy sake, the entered password is not displayed on the screen.
Users have three chances to provide the correct password. Only after the correct
password is entered can they switch to the higher level. Otherwise, the original user
level remains unchanged.
The command views are implemented according to configuration requirements which
are related to one other. For example, after logging onto the firewall, you enter user
view where you can only view state and statistic information. In user view, key in
system-view to enter system view, where you can key in different configuration
commands to enter their views.
Command lines are associated with the views described in the following table.
Table 2-1 Command views
Category Views
User view ––
System view ––
ospf (OSPF view), rip (RIP view), bgp (BGP view),
Routing protocol view
and so on.
ethernet (FE), gigabitethernet (GE), ethernet

subinterface, encryption card interface,
Interface view virtual-template (virtual template), dialer (dialer
interface), loopback (loopback interface), null (null
interface), tunnel (tunnel interface).
User interface view ––
L2TP group view ––
Routing Policy view ––
Table 2-2 shows the functionality of each command view and the commands for
entering them.
2-9
Table 2-2 Command view functionality
Command command to Command to

Function Prompt
view enter exit
Display basic quit
Enter right
information
after disconnects
User view about <H3C>
connecting to from the
operation and
the firewall firewall
statistics
Configure Key in quit

System view system [H3C] system-view returns to user
parameters in user view view
Manage the
Key in quit
asynchronous
User interface user-interfac
and logical [H3C-ui0] returns to
view e 0 in system
interfaces on system view
view
the firewall
Configure quit
OSPF Key in ospf in
OSPF [H3C-ospf] returns to
view system view
parameters system view
quit
RIP Configure RIP Key in rip in
[H3C-rip] returns to
view parameters system view
system view
Configure quit
BGP Key in bgp 1
BGP [H3C-bgp] returns to
view in system view
Ethernet Ethernet [H3C-Ethernet Interface
interface view interface 1/0/0] ethernet 1/0/0 returns to
parameters in system view system view
Key in
Configure interface quit
Subinterface [H3C-Ethernet
subinterface Ethernet returns to
view 1/0/0.1]
parameters 1/0/0.1 in system view
system view
Key in quit
Configure
interface aux
Auxiliary port auxiliary port [H3C-aux0] returns to
0 in system
view
Key in
Configure the interface quit
Virtual [H3C-virtual-t
virtual-templat virtual-templ returns to
template view emplate0]
e parameters ate 0 in system view
system view
Loopback loopback [H3C-Loopba interface
interface view interface ck2] loopback 2 in returns to
parameters system view system view
2-10
Command command to Command to

Function Prompt
view enter exit
Configure null Key in quit

NULL interface null
interface [H3C-NULL0] returns to
interface view 0 in system
parameters view system view
Key in quit
L2TP group Configure the
[H3C-l2tp1] l2tp-group 1 returns to
view L2TP group
in system view system view
Key in
route-policy quit
Configure the
Route-policy [H3C-route-po test node
BGP returns to
view licy] permit node
route-policy system view
10 in system
view
Note:
The command line prompts take firewall name as prefix (which defaults to H3C), view
name as suffix, a pair of parentheses to denote the current view, a pair of point brackets
(<>) to denote user view, and a pair of square brackets (“[]”) to denote system view or
any other configuration views.
2.2.2 Online Help with Command Lines
The following are the types of online help available with the CLI:
z Full help
z Fuzzy help
To obtain the desired help information, you can:
1) Enter “?” in any view to access all the commands in this view and brief description
about them as well.
<H3C> ?
2) Enter a command and a “?” separated by a space. If "?" is at the position of a
keyword, all the keywords are given with a brief description.
<H3C> display ?
3) Enter a command and a “?” separated by a space. If "?" is at the position of a
parameter, the description about these parameters is given.
[H3C] interface ethernet ?
<3-3> Slot number
[H3C] interface ethernet 3?
/
[H3C] interface ethernet 3/?
2-11
<0-0>
[H3C] interface ethernet 3/0?
/
[H3C] interface ethernet 3/0/?
<0-0>
[H3C] interface ethernet 3/0/0 ?
<cr>
Where, <cr> indicates that there is no parameter at this position. Press <Enter> to
execute the current command.
4) Enter a character string followed by a “?”. All the commands starting with this
string are displayed.
<H3C> d?
debugging delete dir display
5) Enter a command followed by a character string and “?”. All the keywords starting
with this string are listed.
<H3C> display h?
history-command hotkey
6) Press <Tab> after entering the first several letters of a keyword to display the
complete keyword. If these letters can not uniquely identify the keyword, system
will display all the keywords starting with these letters.
7) Execute language-mode Chinese command to switch the description information
of all the commands into Chinese version.
Note:
If a command does not match the current view, it finds other views with higher level to
match. If the match succeeds, the command is processed in the corresponding view. In
the following example, because the interface command does not match the OSPF
view, the command is processed in a view with higher level (the system view) and
enters the corresponding interface view.
[H3C] ospf
[H3C-ospf-1] interface Ethernet 0/0/0
[H3C-Ethernet0/0/0]
2.2.3 Command Line Error Information
The commands are executed only if they have no syntax error. Otherwise, error
information is reported. Table 2-3 lists some common errors.
2-12
Table 2-3 Common command line errors
Error information Cause

The command was not found
The keyword was not found
Unrecognized command
Parameter type error
The parameter value is beyond the allowed range
Incomplete command Incomplete command
Too many parameters Too many parameters
Ambiguous command Ambiguous parameters
2.2.4 History Command
The CLI can automatically save the commands that have been entered. You can invoke
and repeatedly execute them as needed. By default, the CLI can save up to ten
commands for each user. Table 2-4 lists the operation that you can perform.
Table 2-4 Access history commands
Operation Key Result

View the history display Displays the commands
commands. history-command that you have entered
Displays the earlier
Access the last history history command, if there
Up-arrow key or <Ctrl+P>
command. is any. Otherwise, the
system rings alarm.
Displays the next history
command, if there is any.
Access the next history Down-arrow key or
Otherwise, the system
command <Ctrl+N>
clears the commands and
rings alarm.
Note:
You may use arrow keys to access history commands in Windows 3.X Terminal or
Telnet. However, the up-arrow key is invalid in Windows 9X HyperTerminal, because it
is defined in a different way. You can use <Ctrl+P> instead.
2-13
2.2.5 Edit Features
The CLI provides the basic command edit functions and supports multi-line editing. The
maximum length of each command is 256 characters. Table 2-5 lists these functions.
Table 2-5 Edit functions
Key Function
If the editing buffer is not full, insert the character at
Common Keys the position of the cursor and move the cursor to the
right. Otherwise, the alarm rings.
Delete the character to the left of the cursor and
move the cursor back one character. If the cursor
Backspace key
gets to the beginning of the command line, the alarm
rings.
The cursor moves one character space to the left,
Left-arrow key or <Ctrl+B> and the alarm rings when the cursor gets to the
beginning of the command line.
The cursor moves one character space to the right,
Right-arrow key or <Ctrl+F> and the alarm rings when the cursor gets to end of
the command line.
Pressing <Tab> after entering part of a keyword
enables the fuzzy help function. If finding a unique
match, the system will substitute the complete
Tab key keyword for the incomplete one and display it in the
next line. If there are several matches or no match at
all, the system will not modify the incomplete
keyword and display it again in the next line.
2.2.6 Display Features
I. Language selection
Your firewall offers both English and Chinese help information. You can toggle between
them.
Perform the following configuration in user view.
Table 2-6 Toggle between languages
Operation Command
Toggle to English. language-mode english
Toggle to Chinese. language-mode chinese
2-14
II. Display pause
When the information displayed exceeds one screen, you can pause using one of the
methods shown in Table 2-7 .
Table 2-7 Display functions
Action Function
Enter <Ctrl+C> when information Stops the display and the command
display pauses execution.
Enter <Space> when information display Continues to display information of the
pauses next screen page
Enter <Enter> when information display Continues to display information of the
pauses next line.
III. Information output
Many display commands are available for showing system status information. When
outputting information, you can add "|" in the command to filter information. Three
options are available:
z begin text: to display information starting from the line with "text"
z exclude text: to display information of the lines with no "text"
z include text: to display information of the lines with "text"
For example, if you enter the display current-configuration | include ip command,
the configuration information of the line with "ip" are displayed.
2.2.7 Regular Expressions
I. Introduction to regular expressions
Regular expressions are a powerful and flexible tool for pattern matching and
substitution. They are not restricted to a language or system and have been widely
accepted.
When using a regular expression, you need to construct a matching pattern according
to certain rule, and then compare the matching pattern with the target object. The
simplest regular expressions exclude all metacharacters. For example, you can specify
a regular expression “hello” to match only the character string “hello”.
For flexible matching mode construction, regular expressions are allowed to contain
some special characters, called metacharacters, to define how other characters appear
in the target object. The following table describes the metacharacters.
2-15
Table 2-8 Metacharacters
Metacharacter Meaning
\ Escape Character
. Matches any single character except for “\n”, including spaces.
The character to the left of the asterisk in the expression should
*
match zero or more times.
There should be at least one match of the character to the left of
+
the plus sign in the expression.
Allows either expression on the side of the pipe character
|
(vertical bar) to match the target object.
The characters following the ^ sign must appear at the
^
beginning of the target object.
The characters before the dollar sign must appear at the end of
$
the target object.
Any of the characters in the square brackets may match the
[xyz]
target character.
Any characters other than those in the square brackets may
[^xyz]
match the target character.
Any of the characters within the specified range may match the
[a-z]
target character.
Any of the characters beyond the specified range may match
[â-z]
the target character.
The “n” in the brace brackets is a non-negative integer,
{n}
indicating that there are consecutive n matches.
The “n” in the brace brackets is a non-negative integer,
{n,}
indicating that there are inconsecutive n matches.
The “m” and “n” in the brace brackets are non-negative integers,
with n<=m. It indicates that the consecutive matches are in the
{n,m}
range n to m. Note that no space is allowed on either side of the
comma.
For example:
îp: to match the target object starting with the character string “ip”
ip$: to match the target object ending with the character string “ip”
II. Benefits of regular expressions
You can use regular expressions to filter out uninterested information when a large
amount of information is present.
1) Specify filtering mode in the command
2-16
In filtering output, you can choose from three kinds of filtering modes. In a command
that supports regular expressions, they are presented as | { begin | exclude | include }
regular-expression:
z begin: to output all lines starting with the line that matches the specified regular
expression.
z exclude: to output all lines except for those matching the specified regular
expression.
z include: to output only the lines that match the specified regular expression.
2) Specify filtering mode between screens
If enormous information is present and output in multiple screens, you can filter
information after the prompt ”---- More ----” between screens appears by entering a
regular expression in one of the following forms:
z /regular-expression: to output all lines starting with the line that matches the
specified regular expression.
z -regular-expression: to output all lines except for those matching the specified
regular expression.
z +regular-expression: to output only the lines that match the specified regular
expression.
For example, you can use the following command to view the current configuration
information:
<H3C> display current-configuration
#
sysname H3C
#
interface Ethernet0/2/0
description Don't change the configuration please
ip address 10.110.98.137 255.255.255.0
#
#
#
interface NULL0
When the prompt “---- More ----” appears, you can enter a regular expression to filter
information to be displayed. To output only the lines that contain the character string
“interface”, for example:
---- More ----
+interface Manually entered by the user
filtering...
interface LoopBack0
2-17
user-interface con 0
user-interface vty 0 14
<H3C>
2.3 Hot Keys

2.3.1 Classifying Hot Keys
The hot keys in the system fall into two types user-configurable and system.
The user-configurable shortcut keys include CTRL_G, CTRL_L, CTRL_O, CTRL_T and
CTRL_U. You can associate these shortcut keys with any commands for automatic
execution.
The system shortcut keys have fixed functions and do not allow free customization, as
shown in the following table:
Table 2-9 System hot keys
Keys or commands Function

CTRL_A Moves the cursor to the beginning of current line.
CTRL_B Moves the cursor one character space leftward.
CTRL_C Terminates the running function.
CTRL_D Deletes the character at the cursor.
CTRL_E Moves the cursor to the end of current line.
CTRL_F Moves the cursor one character rightward.
CTRL_H Deletes the character to the left of the cursor.
CTRL_K Terminates the outbound connections.
Displays the next command in the history command
CTRL_N
buffer.
Displays the previous command in the history
CTRL_P
command buffer.
CTRL_R Refreshes the information of current line
CTRL_W Deletes the word to the left of the cursor
CTRL_X Deletes all the characters to the left of the cursor
CTRL_Y Delete all the characters to the right of the cursor
CTRL_Z Returns to user view
CTRL_] Terminates the inbound or re-directional connections
ESC_B Moves the cursor one word leftward
ESC_D Deletes the word to the right of the cursor
2-18
Keys or commands Function

ESC_F Moves the cursor one word rightward
Sets the cursor's location to the beginning of the
ESC_<
clipboard
ESC_> Sets the cursor's location to the end of the clipboard
2.3.2 Usage of the Hot Keys
z You can press a combined hot key wherever you are allowed to enter a command.
Then the system displays the corresponding command as if you have entered the
complete command.
z If you have input part of a command without pressing <Enter>, you can delete the
input characters and enter a complete command simply by pressing the hot key for
this new command.
z Similar to executing a command, after a hot key is executed, its corresponding
command prototype is retained in the history command buffer and log for retrieve
and problem addressing.
Note:
The function of a hot key may be restricted by its definition on the user terminal. If the
same hot key is associated with different functions on the IP PBX and the user terminal,
it is to be captured by the terminal program when executed and as such, cannot
execute the associated command line on the firewall.
Perform the following configuration in system view.
Table 2-10 Define hot keys
Operation Command
hotkey { CTRL_G | CTRL_L | CTRL_O
Define a hot key.
| CTRL_T | CTRL_U } command_text
undo hotkey { CTRL_G | CTRL_L |
Restore the default values in the system.
CTRL_O | CTRL_T | CTRL_U }
By default, the system assigns defaults to the hot keys of CTRL_G, CTRL_L and
CTRL_O as follows:
CTRL_G: display current-configuration
CTRL_L: display ip routing-table
2-19
CTRL_O: undo debugging all

The default values of the other two hot keys are void by default.
Perform the following configuration in any view.
Table 2-11 Display the hot keys and their functions
Operation Command
Display the hot keys and their functions. display hotkey
2.3.3 Examples of Hot Keys in Use
# Assign the hot key CTRL_U to the display ip routing-table command and execute it.
[H3C] hotkey ctrl_u display ip routing-table
[H3C] Press <Ctrl_u>
[H3C] display ip routing-table
Routing Table: public net
Destination/Mask Proto Pre Cost Nexthop Interface
127.0.0.0/8 DIRECT 0 0 127.0.0.1 InLoopBack0
2.3.4 Configuring Command Alias
The command alias function allows you to replace some common commands available
with Comware with the command forms you prefer. The following are the command
alias use conventions:
1) The system retains and displays alias-included commands that you entered in its
prototype when you execute commands to save configurations or to view
command history or current configurations.
2) You can input a command by inputting its conflict-free portion. When the
command alias function is enabled, the likelihood exists that this incomplete
portion is a fuzzy match of both a command alias and a command, however. In this
case, the system considers the portion as the alias and outputs its associated
command. To have the system output the intended command, you need to input
the command completely. In the event that the character string you input is a fuzzy
match of multiple aliases, the system prompts that the alias is ambiguous and
asks you to input the complete keyword.
3) If you press <Tab> after inputting a unique alias, the system displays its
associated keyword.
4) Full replacement of command lines is not supported. You can only map an alias
with the first keyword in a command. The system can only replace this alias with
the first keyword in the command and the second keyword in its undo form.
2-20
I. Enabling command alias
Table 2-12 Enable command alias
Operation Command
Enable command alias command-alias enable
Disable command alias undo command-alias enable
By default, the command alias function is disabled.

Mapping an alias with a command
Table 2-13 Map an alias with a command keyword
Operation Command
Map an alias with a command keyword. command-alias mapping cmdkey alias
Cancel the map. undo command-alias mapping alias
By default, no command alias is configured.
II. Displaying and Debugging
Table 2-14 Display and debug
Operation Command
Display the current alias settings. display command-alias
2-21
H3C SecPath Series Security Products Chapter 3 Comware Basic Configurations
Chapter 3 Comware Basic Configurations
3.1 Entering/Exiting System View

When logging onto the firewall from the console port, you enter user view and see the
prompt <H3C> on the screen. To enter or exit system view, use the following
commands.
Table 3-1 Enter/exit system view
Operation Command
Enter system view from user view. system-view
Return to user view from system view. quit
Return to user view from any other view. return
With the quit command, you can return to the previous view or exit the system from
user view. The hot key <Ctrl+Z> is equivalent to the return command.
3.2 Configuring the Gateway Name

The command prompt contains a gateway name that can be configured as needed.
Table 3-2 Configure the gateway name
Operation Command
Configure the gateway name sysname sysname
3.3 Configuring the System Clock

Table 3-3 Configure system clock
Operation Command
Set the standard time. clock datetime time date
clock timezone time-zone-name { add | minus }
Set the time zone.
time
Cancel the time zone setting. undo clock timezone
3-1
Operation Command
clock summer-time summer-time-zone-name
Import a daylight saving time
{ one-off | repeating } start-time start-date
scheme.
end-time end-date add-time
Cancel the daylight saving time
undo clock summer-time
scheme.
3.4 Configuring a Banner

A banner shows information displayed at login, login authentication, or configuration.
Table 3-4 Configure a banner
Operation Command
Configure the banner to be displayed at
header incoming text
login.
Configure the banner to be displayed at
header login text
login authentication.
Configure the banner to be displayed
header shell text
when a user enters user view.
undo header { incoming | login |
Cancel the banner setting.
shell }
3.5 User Level Switching

I. Configuring password for user level switching
You may set user level switching passwords. After that, a user that logs onto the firewall
with a lower user level is required to provide the password before operating on higher
level commands.
Table 3-5 Configure a user level switching password
Operation Command
Configure a user level switching super password [ level user-level ]
password. { simple | cipher } password
undo super password [ level
Delete the configured password
user-level ]
By default, if not specified, the password switches to level 3.
3-2
II. Switching user levels
You must provide the correct password before you can become a higher level user.
Table 3-6 Switch the user level
Operation Command
Switch the user level. super [ level ]
By default, if not specified, the password switches to level 3.

For more information on user level configuration, refer to Chapter 9 “User
Management”.
3.6 Locking User Interfaces

When you want to leave for a while, you may lock the user interface, to prevent it from
being accessed by illegitimate users. When locking the interface, you need to configure
and confirm a password, which is required in unlocking the interface.
Table 3-7 Lock the user interface
Operation Command
Lock the user interface. lock
3.7 Configuring Command Levels

All the commands are administratively assigned to different views and categorized into
four levels: visit, monitor, system, and manage, identified respectively by 0 through 3.
Table 3-8 Configure command privilege level
Operation Command
Assign a level to the commands in the command-privilege level level view
specified view. view command-key
undo command-privilege view view
Restore the default.
command-key
The following table describes the default level of the commands.
3-3
Table 3-9 Default command levels
Level Privilege Command

0 Visit ping, tracert, telnet
1 Monitor display, debugging
2 System All configuration commands except for those at manage level
FTP, TFTP, SNMP, XModem, and file system operation
3 Manage
commands
Note:
All commands have default views and privilege levels. Generally no configuration is
required.
3.8 Displaying System Information

In terms of function, you may collect these types of system status information with the
display command:
z Configuration information
z Operating information
z Statistics
The following table just lists the system-related display commands. Refer to other
chapters for those associated with protocols and interfaces.
Table 3-10 Display system status information
Operation Command
Display information on system version. display version [ slot-id ]
Display software version details. vrbd
Display information on the system clock. display clock
Display information on terminal users. display users [ all ]
Display the initial configurations. display saved-configuration

Display the current configurations. display current-configuration
display debugging [ interface
Display debugging status. interface-type interface-number ]
[ module-name ]
Display diagnostic information. display diagnostic-information
3-4
Operation Command
Display clipboard information. display clipboard
Display the current status of the memory
display memory [ limit ]
in the system.
display cpu-usage [ configuration |
Display statistics about CPU usage. number [ offset ] [ verbose ]
[ from-device ] ]
cpu-usage cycle { 5sec | 1min | 5min |
Set the CPU usage statistic interval.
72min }
Display the history of the CPU usage display cpu-usage history [ task
statistics in graphics. task-id ]
When troubleshooting or servicing the system, you can use the display
diagnostic-information command to collect operating information about active
modules in the system.
The display diagnostic-information command can at a stroke collect the information
displayed at the terminal after executing the commands such as display clock,
display version, vrbd, display current-configuration, display
saved-configuration, display interface, display ip interface, display ip statistics,
and display logbuffer.
3-5
H3C SecPath Series Security Products Chapter 4 System Maintenance and Management
Chapter 4 System Maintenance and Management
4.1 Maintenance and Debugging Function

4.1.1 Testing Network Connection
I. ping
The ping command is mainly used to check a network connection and test whether the
host is reachable.
Table 4-1 The ping command
Operation Command
ping [ -a X.X.X.X ] [ -c count ] [ -d ][ -f ] [ -h ttl_value ] [ -i
{interface-type interface-number } ][ ip ] [ -n ] [ -p pattern ]
Support ping of IP
[ -q ] [ -r ] [ -s packetsize ] [ -t timeout ] [-tos] [ -v ]
[ -vpn-instance vpn-instance-name ] host
For more information about the options and parameters, refer to the section introducing
the ping command in the Command Manual.
The information output upon the execution of the command includes:
z The response to each ping packet. If receiving no response packet upon the
expiration of the timeout setting, the system will output “Request time out”.
Otherwise, the system will output the information of the response packet in bytes,
sequence number, TTL, and response time.
z Sum information of the statistics, including transmitted packets, number of
received packets, percentage of lost packets to all transmitted packets, and
minimum, mean and maximum response times.
For example:
<H3C> ping 202.38.160.244
ping 202.38.160.244 : 56 data bytes, press CTRL_C to break
Reply from 202.38.160.244 : bytes=56 sequence=1 ttl=255 time = 1ms
--202.38.160.244 ping statistics--
5 packets transmitted
5 packets received
4-1
0.00% packet loss

round-trip min/avg/max = 1/2/3 ms
II. tracert
tracert is used to test the gateways that a packet sent by the host will pass by in order
to reach the destination. It is mainly used to test whether a network connection is
reachable and to locate the position where faults occur on the network.
The tracert command is executed following this procedure: The system first sends a
packet with TTL as 1 and the first hop returns an ICMP error message indicating that
the packet cannot be transmitted due to TTL timeout. Then the system transmits the
packet again with TTL being set to 2 and the second hop returns TTL timeout message
similarly. This process continues until the packet reaches its destination. The purpose
of such a process is to record the source addresses from which these ICMP TTL
timeout messages are sent to outline the path along which the IP packet can reach the
destination.
Table 4-2 The tracert command
Operation Command
Test the gateways in between tracert [-a X.X.X.X ] [ -f first_TTL ] [ -m max_TTL ]
the source and destination that [-p port ] [ -q nqueries ] [ vpn-instance
a packet travels vpn-instance-name ] [ -w timeout ] * host
For more information about the options and parameters of the command, refer to the
section introducing the tracert command in the Command Manual.
Following are examples of using tracert for network analysis.
Example 1:
<H3C> tracert 35.1.1.48
traceroute to nis.nsf.net(35.1.1.48) 30 hops max,40 bytes packet
Press CTRL_C to break
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
4 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms
5 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
6 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
7 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms
8 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
9 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
10 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
4-2
The information displayed above gives the GWs between the source host and the
destination, which is very helpful in network analysis.
Example 2:
<H3C> tracert 18.26.0.115
traceroute to allspice.lcs.mit.edu(18.26.0.115) 30 hops max,40 bytes packet
Press CTRL_C to break
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms
The information displayed above gives the GWs between the source host and the
destination, as well as the failed GWs.
4.1.2 Debugging the System
CLI of the system provides a variety of debugging functions for helping the users
diagnose and isolate faults. The debugging functions are available for almost all the
protocols and functions supported by the firewall.
The output of debugging information can be controlled by two switches:
z Protocol debugging switch determining whether the debugging information output
of a protocol is allowed
z Screen output switch determining whether the debugging information output on
the screen of a user is allowed
The relationship of the two switches is displayed in the following diagram.
4-3
Debugging information 1 2 3
Protocol Debugging switches
ON OFF ON
3 3
1 1
Screen output switches
OFF ON
1
3
Figure 4-1 Debugging information output diagram
The protocol debugging switch is controlled by the debugging command. Perform the
following configuration in user view.
Table 4-3 Enable, disable, and display the debugging switches
Operation Command
debugging { all | module-name
Enable protocol debugging switches
[ debug-option1 ] [ debug-option2 ] …}
undo debugging { all | module-name
Disable protocol debugging switches
[ debug-option1 ] [ debug-option2 ] … }
display debugging [ interface
Display the enabled debugging switches { interface-type interface-number } ]
[ module-name ]
For the use of specific debugging commands and the format of debugging information,
refer to the relevant sections.
The screen output switch is controlled by the information center. For more information
about it, refer to the next section.
4-4
4.1.3 Rebooting the System
Sometimes, it is required to reset the firewall to upgrade the file system, or for any other
reasons. There is a special command “reboot” that allows the user to reboot the firewall.
Alternatively, you can simply turn off the power of the firewall and then turn it on to
produce the same effect.
Table 4-4 Reboot the system
Operation Command
Reboot the firewall reboot
Enable scheduled reboot function and
schedule reboot at time [ date ]
set the date and time for reboot
Enable scheduled reboot function and schedule reboot delay { time |
set the time waiting for reboot minutes }
Cancel the scheduled reboot function undo schedule reboot
Display settings related to scheduled
display schedule reboot
reboot configuration
Caution:
z Do not reboot the system often for the operation will render the network unusable for
a short period. Before rebooting the system, remember to save the configuration file
if necessary.
z After you configure the schedule reboot at command, tuning system time with the
clock command or through NTP will void the scheduled reboot setting you made.
z After the configuration of the schedule reboot at command, a timer starts. This
timer is cyclic and measured in minutes. For example, if you set at 12:05:26 to have
the system reboot at 12:06:00, the system will reboot at 12:06:26 instead of
12:06:00.
4.1.4 Upgrading BootROM
The BootROM program in flash memory can be used to upgrade the running BootROM
on the firewall. You can use FTP or TFTP at remote end to upload BootROM to a
firewall first, and then use the following command to upgrade the BootROM.
4-5
Table 4-5 Upgrade BootROM
Operation Command
Upgrade BootROM boot bootrom file-url
4.1.5 Configuring Hot Swap
In a highly secure environment, the hot swap feature enables you to replace the card of
a network device without disturbing the service on the device.
If the hot swap feature is not supported, you need to start the device with the card
plugged in and do not remove the card while the device is running. You need to stop the
current service and restart the system if abnormality occurs on the card or different
services are required (such as the card needs to be replaced); however, this case is not
applicable if continuous service must be ensured. With the hot swap feature, you can
plug in or plug out the card as needed while the system is running, and thus the normal
running of other services is ensured. The hot swap feature can help restore services for
cards of the same type.
Perform the following configuration in user view, and then you can plug out and replace
the card.
Table 4-6 Configure to have the system do some pre-processing work before plugging
out an interface card
Operation Command
Configure to have the system do some
pre-processing work before plugging out the remove slot slot-id
interface card from a slot
Cancel the configuration undo remove slot slot-id
Display information of the device and card (in any
display device [ slot-id ]
view)
By default, this operation before plugging out a card is not performed.
4-6
Caution:
z Before you plug out an interface card, abnormality may occur on the device if you
have not executed the remove slot command.
z Do not plug in or plug out the card during system’s booting process.
z The current static route does not support hot swap. That is, after you plug out the
card, the static route still exists, which needs to be manually deleted.
z The following commands still exist on the device after the card is plugged out, so
you need to delete the corresponding configurations manually. Those commands
are, namely, ftp source-interface, ftp-server source-interface, tftp
source-interface, telnet source-interface, telnet-server source-interface,
ssh-server source-interface, ssh2 source-interface, sftp source-interface, the
source command in Tunnel interface view, source-interface command in HWPing
test group view, peer connect-interface command for BGP, if-match interface
command and apply output-interface command in routing policy view.
z Currently, the following types of cards are supported by hot swap, including 1FE,
2FE, 4FE, 1GBE, 2GBE, 1GEF and 2GEF, while encryption cards and other types
of PCI cards are not supported by hot swap.
4.2 Information Center

4.2.1 Introduction
Information center is an indispensable part of the main software of the firewall and
exists as an information hub in firewalls. The information center manages most
information outputs, sorts the information carefully, and hence can screen the
information in an efficient way. Combined with the debug program, it can provide
powerful support for the network administrators and developers in network operation
monitor and fault diagnosis.
The information center of the system has the following features:
z Available with three types of information, which are log information, trap
information, and debug information.
z The information is sorted into eight levels by severity and can be filtered by level.
z The system can support ten channels. The first six channels, or Channels 0
through 5, have their default channel names and are associated with six output
directions by default. Both the names of the channel names and the associations
between the channels and output directions can be changed through the
commands.
z Support six information output directions, including the Console, Telnet terminal
and console terminal (monitor), logbuffer, loghost, trapbuffer and SNMP.
4-7
z The system is composed of a variety of protocol modules, board drivers, and

configuration modules. The information can be classified and filtered by source
module.
z Each information header consists of several fixed parts, which are time stamp,
information source module, information level, slot number of the information
source, and the information digest.
To sum up, the major task of the information center is to output the three types of
information of the modules onto the ten channels in terms of the eight severity levels
and according to the user’s settings, and then redirect the ten information channels to
the six output directions.
4.2.2 Configuring the Information Center
I. Enabling/Disabling the information center
Table 4-7 Enable/Disable the information center
Operation Command
Enable the information center info-center enable
Disable the information center undo info-center enable
Note:
By default, the information center is enabled. An enabled information center will affect
the system performance in some degree due to the work in information sorting and
output. Such impact becomes more obvious in the event that there is enormous
information waiting for processing.
II. Naming a information channel
Table 4-8 Name an information channel
Operation Command
Name the information channel
info-center channel channel-number
numbered channel-number as
name channel-name
channel-name
4-8
The parameter channel-number is ranging from 0 to 9, corresponding to the ten

channels of the system. The parameter channel-name is a channel name that may
comprises up to 30 characters but '-‘, ‘/’ and ’\’.
The system specifies the default names for Channels 0 through 5, which are listed in
the following table.
Table 4-9 Default channel names
Channel-number Channel-name
0 Console
1 monitor
2 loghost
3 trapbuffer
4 logbuffer
5 snmpagent
III. Information severity
The information center classifies the information into eight levels by severity or
emergency. If filtered by severity, the information of a severity level greater than the
defined threshold will be filtered out for output. A more emergent packet has a smaller
severity level. The parameter “emergencies” represents the severity level 0 and
debugging represents the severity level 7. Therefore, all the information will be output if
the severity threshold is set to debugging.
Table 4-10 Severities defined in syslog
Severity Description
emergencies Fatal errors
alerts Errors requiring immediate correction
critical Critical errors
errors Errors requiring attention but not quite critical
warnings Warnings indicating the possible existence of errors
notifications Information requiring attention
informational Common prompt information
debugging Debugging information
# Enable outputting log information of IP module and allow outputting only the
information with the severity of warnings and lower levels.
4-9
[H3C] info-center source IP channel snmpagent log level warnings
IV. Defining the contents of an information channel
Table 4-11 Define the contents of an information channel
Operation Command
info-center source { module-name | default } { channel
Add a record to an { channel-number | channel-name} } [ log { state { on | off }
information channel | level severity }* | trap { state { on | off } | level severity } *
| debug { state { on | off } | level severity }* ]*
Delete a record from
undo info-center source { module-name | default }
an information
{ channel { channel-number | channel-name }
channel
module-name specifies a module name and default stands for the default record in the
information channel. level is the severity level of information and the information at a
level greater than severity is prohibited to output. severity is the setting of information
level. channel-number and channel-name are the information channel number and
name to be set.
Each information channel has a default record for which the module name is default.
But for different channels, the record may have different default settings for logging
information, trapping information, and debugging information. If a module has no
explicit configuration record in the channel, the default configuration record will be
used.
Caution:
When there are multiple Telnet users at the same time, they can share some
configuration parameters, including setting of filtering by module, language selection,
and the severity threshold. The changes that one user made on these settings will also
be shown on other user terminals.
V. Information output
By far, the information center of the gateway’s main software can output the information
to six directions.
z Output the information to a local Console via the Console port.
z Output the information to a remote Telnet terminal in support of remote
maintenance.
4-10
z Allocate a logbuffer of proper size inside the firewall for recording information.
z Configure the loghost, to which the information center will directly send the
information and on which the information will be stored in files for future retrieval.
z Allocate a trapbuffer of proper size inside the firewall for recording information
z Output information to the SNMP Agent.
Each output direction will be specified with a desired channel by using a configuration
command and all the information will be sent to the associated directions after filtered
by the specified channels. By configuring the channel for each output direction and the
filtering information of the channel as required, the user could complete the filtration
and redirection of different types of the information.
Table 4-12 Output information
Operation Command
info-center console channel
Output information to a Console
{ channel-number | channel-name }
Disable the information output to the
undo info-center console channel
Console
info-center monitor channel

Output information to a telnet terminal
undo info-center monitor channel
telnet terminal
info-center snmp channel

Output information to SNMP
Disable the information output to SNMP undo info-center snmp channel
Set the channel for information output to info-center logbuffer [ channel
the logbuffer and the size of the { channel-number | channel-name } |
logbuffer size buffersize ] *
Disable logbuffer or restore the default undo info-center logbuffer [ channel |
value max-size ]
info-center loghost X.X.X.X [ channel

Set the channel for information output to { channel-number | channel-name } |
the loghost and other parameters facility local-number | language
{ chinese | english } ] *
undo info-center loghost X.X.X.X
loghost
Set the source address in the packets info-center loghost source
destined to the log host interface-type interface-number
Delete the source address in the
undo info-center loghost source
packets destined to the log host
4-11
Operation Command
Set the channel for information output to info-center trapbuffer [ channel
the trapbuffer and the size of the { channel-number | channel-name } |
trapbuffer max-size buffersize ] *
Disable the trapbuffer or restore the undo info-center trapbuffer [ channel
default value | size ]
By default, the system sets six information channels as shown in the following table:
Table 4-13 Default information channels assigned to each direction
Output direction Information channel No. Default channel name

Console 0 console
Monitor terminal 1 monitor
Log host 2 loghost

Trap buffer 3 trapbuffer
Log buffer 4 logbuffer
SNMP 5 snmpagent
Note:
The settings of the six output directions are independent but you must enable the
information center first before the settings can become valid.
VI. Sending source address for logging information
Table 4-14 Send source address for logging information
Operation Command
Send source address for logging info-center loghost source
information interface-type interface-number
Cancel the setting undo info-center loghost source
VII. Setting the Format of Time Stamp
4-12
Table 4-15 Set the format of time stamp
Operation Command
Set the format of the time stamp of the
info-center timestamp { trap |
debugging/trap/log information output to
debugging | log } { boot | date | none }
the terminal and buffer
Restore the default format of the time
stamp of the debugging/trap/log undo info-center timestamp { trap |
information output to the terminal and debugging | log }
buffer
Set the format of the time stamp of the info-center timestamp loghost { date |
log information output to the loghost no-year-date | none }
Restore the default format of the time
stamp of the log information output to undo info-center timestamp loghost
the loghost
By default, buffer and debugging information which are output in the terminal use boot
time stamp, other information use date time stamp. The of log information output to
loghost use date time stamp format.
4.2.3 Setting Display Terminal
Setting a display terminal is to control whether the debug/log/trap information from the
information center will be output to a user’s screen.
Table 4-16 Set a display terminal
Operation Command
Enable the terminal information display function terminal monitor
Enable the terminal logging information display
terminal logging
function
Enable the terminal trapping information display
terminal trapping
function
Enable the terminal debugging information display
terminal debugging
function
Disable the terminal information display function undo terminal monitor
Disable the terminal logging information display
undo terminal logging
function
Disable the terminal trapping information display
undo terminal trapping
function
Disable the terminal debugging information display
undo terminal debugging
function
4-13
These commands can only affect the current terminal at which the commands are
input.
The execution of the command undo terminal monitor (for disabling the display
terminal), is equivalent to that of the commands of undo terminal debugging, undo
terminal logging, and undo terminal trapping, that is, all the debugging, log, and
trap information will not be displayed at the current terminal. Given that the terminal
monitor has been enabled, using the terminal debugging/undo terminal debugging,
terminal logging/undo terminal logging, terminal trapping/undo terminal
trapping commands can respectively enable and disable the output of
debugging/logging/trapping information.
By default, the terminal display is enabled for the console user, and all prompts can be
displayed on the terminal; the terminal display is disabled for the other terminal users
(AUX, and VTY users), and all prompts can be displayed on the terminal only after the
terminal monitor command is configured.
4.2.4 Syslog Overview
The syslog function is implemented through the information center module. It is a

sub-function possessed by the information center module. This section mainly
describes the format of the system information (including log, debug and trap) output to
the log host. The port ID 514 is adopted in the log host output.
This format is stipulated according to the BSD syslog Protocol (RFC 3164) and
performs extension to the message header.
The format of the system information is shown in Figure 4-2:
Feb419:59:19:3352005Quidway %%10SHELL/5/CMD:-DevIP=10.10.10.1;
Source IP
Time stamp Sysname
Vendor id Module Digest address
name
Syslog
Severity
version
task:co0 ip:1.1.1.1 user:root command:display this
Message body
Figure 4-2 Format of system information
The following subsections describe the major fields of system information.
I. Timestamp
You can use the info-center timestamp loghost command to set a time stamp format
for the system information output to the log host. The following options are available:
z date: Timestamp format with year date, in the format of MM DD hh:mm:ss YYYY,
and provides year information.
4-14
z no-year-date: Timestamp format without year date, in the format of MM DD

hh:mm:ss, and does not provide year information.
z none: No timestamp. No time information in the system information.
"YYYY" is year field.
"MM" is month field, such as: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
Dec.
"DD" is day field. Numbers less than 10 are prefixed by a space, such as " 7".
"hh:mm:ss" is the local time, where "hh" ranges from 00 to 23, and "mm" and "ss" from
00 to 59.
The time stamp field is separated from the sysname field by a space.
II. Sysname
The sysname is the host name, being "H3C" by default.

The user can change the host name through the sysname command.
The sysname field is separated from the vendor ID field by a space.
III. Vendor ID
The Vendor ID of our company is “%%".
IV. Syslog version
The syslog version of the system information, which is 10 in this example.
V. Module name
The module name is the name of the module creating this logging information. You can
view the module list by executing the info-center source ? command in system view.
There is a slash (/) between module name and severity.
VI. Severity
There are eight severity levels, from zero to seven. For the definition and description,
see Table 4-10.
There is a slash (/) between severity and digest.
VII. Digest
The digest is abbreviation, representing the abstract of contents.

There is a colon between digest and content.
VIII. Source IP address
This field indicates the source address of the message sent to the log host. It is
displayed only when the loghost source command is configured.
4-15
The source IP address field is separated from the message body field by a semicolon
(;).
IX. Message body
Message body is created by the sending module. For example, “task:co0 ip:** user:root
command:display this” indicates that a console user named root input the display this
command.
4.2.5 Displaying and Debugging Information Center
After the above configuration, execute the display command in any view to display the
running of the information center after configuration, and to verify the effect of the
configuration.
Execute the debugging command in user view for the debugging of the information
center.
Table 4-17 Display and debug information center
Operation Command
Display information in the information
display info-center
center
display logbuffer [ size size-value |
Display information in log buffer summary ] [ level level-number ] [ |
{ begin | include | exclude } string ]
Display information on the specified
display channel [ channel-number |
information channel or all information
channel-name ]
channels
Display information in trap buffer display trapbuffer[ size size-value ]
4.2.6 Information Center Configuration Example
I. Console information output
1) Enable the info-center.

[H3C] info-center enable
2) Configure Console log output, permitting the log output of PPP module and setting
the severity level to be in the range of emergencies to debugging.
[H3C] info-center console channel console
[H3C] info-center source ppp channel console log level debugging
3) Enable debugging of the PPP module.
<H3C> debugging ppp all
4-16
II. Outputting log information to the loghost (UNIX workstation)
Step 1: Configure the firewall

1) Enable the info-center
2) Use the UNIX workstation at 202.38.1.10 as the loghost and set the severity
threshold to informational and output language to English, and allow PPP and IP
modules to output information using the UNIX device local4.
[H3C] info-center loghost 202.38.1.10 language english
[H3C] info-center loghost 202.38.1.10 facility local4
[H3C] info-center source ppp channel loghost log level informational
[H3C] info-center source ip channel loghost log level informational
Step 2: Configure the loghost

To implement the above functions, some configurations should also be made on the
UNIX host. The configuration procedure described below is completed on SunOS 4.0
and the similar procedure is followed if the UNIX OS of some other vendor is adopted.
3) Execute the following commands as the root user.
# mkdir /var/log/H3C
# touch /var/log/H3C/information
4) Edit the file /etc/syslog.conf and add the following selector/action pairs as the root.
# H3C configuration messages
local4.info /var/log/H3C/information
Note:
When editing the file /etc/syslog.conf, you should note that
z Remarks must be in independent lines and begin with the character #.
z Use a tab rather than space as the delimiter between selector/action pairs.
z Do not leave unwanted space behind a file name.
The device name and the permitted log information level specified in /etc/syslog.conf
should keep in consistence with the info-center loghost and info-center loghost
a.b.c.d facility that have been configured on the firewall, in case of the incorrect output
of log information to the loghost.
After the log files ‘config’ has been established and the file "/etc/syslog.conf" has been
modified, the following command should be executed to send a HUP signal to the
system daemon ‘syslogd’ to have it reread its configuration file "/etc/syslog.conf".
# ps -ae | grep syslogd
147
# kill -HUP 147
4-17
Upon the completion of the above operations, the firewall can output the related
information to the corresponding log files.
The configuration made above permits outputting only the informational and higher
level log information, i.e., the information of severity levels 1 to 7, to the log host.
The lowest level of the logging information is debugging. The setting of debugging will
cause all the logging information being output to the loghost and this may lower the
system performance. Therefore, it is not recommended to set the log information level
to debugging in normal circumstances.
Note:
For purpose of filtering, you can sort the information taking into account the facilities,
severities, filters, and the syslog.conf files.
4.3 Configuring HTTP Server

4.3.1 Enabling HTTP server
SecPath series security products support login to system through HTTP, and provide
web management interface to implement system configuration and management. You
need to enable the HTTP server first before logging into the system through Web
interface.
Table 4-18 Enable/disable HTTP server
Operation Command
Enable HTTP server undo ip http shutdown
Disable HTTP server ip http shutdown
By default, the HTTP server is enabled.

Only the users with telnet service type (service-type telnet) are allowed to log in the
HTTP server. The configuration options in the web interface differ according to the
levels of users.
4.3.2 Configuring Access Limit on HTTP Server
After the access limit is configured on HTTP server, only the users with specific IP
addresses can access the HTTP server to implement device configuration and
management.
4-18
Table 4-19 Configure access limit on HTTP server
Operation Command
Configure access limit on HTTP server ip http acl acl-number
Cancel the access limit on HTTP server undo ip http acl
By default, no access limit is configured.

Only those IP addresses allowed in ACL can access the HTTP server.
4-19
H3C SecPath Series Security Products Chapter 5 Auto Detect Configuration
Chapter 5 Auto Detect Configuration
5.1 Introduction to Auto Detect

Auto detect is a function for checking the connectivity of a network regularly by sending
ICMP Request/Reply packets. It works by checking a group of destination IP addresses
to see whether the hosts are reachable or unreachable. Based on the result, the firewall
can discover presence of problems and take appropriate actions.
The result of auto detect can be used by other features to control whether the
configurations for the features can take effective. These features include:
z Static routing
z Virtual router redundancy protocol (VRRP)
An auto detect group can be referenced simultaneously by multiple application
instances.
Note:
For a detailed description of static routing, refer to the “Routing Protocol” part of this
manual.
For a detailed description of VRRP, refer to the “Reliability” part of this manual.
5.2 Basic Auto Detect Configuration

5.2.1 Basic Auto Detect Configuration Tasks
The following table describes the basic auto detect configuration tasks.
Table 5-1 Auto detect configuration tasks
No. To do… Use the command… Remarks

1 Enter system view <H3C> system-view —
Create a detect group and enter [H3C] detect-group
2 Required
detect group view group-number
Add an IP address to the detect [H3C-detect-group-X]
group. You may use the detect-list list-number
3 Required
command multiple times to add ip address ip-address
up to 100 IP addresses. [ nexthop ip-address ]
5-1

Specify the relationship Optional.
[H3C-detect-group-X]
4 between the addresses in the Defaults to
option { and | or }
detect group and.
Optional.
Specify the auto detect interval [H3C-detect-group-X]
5 Defaults to
of a detect group timer loop seconds
15 seconds.
Specify the maximum number
[H3C-detect-group-X] Optional.
6 of probing retries during each
retry retry-times Defaults to 2.
auto detect interval
Optional.
Specify the timeout period of a [H3C-detect-group-X]
7 Defaults to 2
probing attempt timer wait seconds
seconds.
<H3C> display Optional.
Display configurations of a
8 detect-group Available in
specified or all detect groups
[ group-number ] any view.
Note:
z The prompt of detect group view depends on your configuration.
z For information about the parameters and the related undo commands, refer to the
command manual.
5.2.2 Auto Detect Configuration Example
I. Network requirements
z Create a detect group numbered 10 on SecPath A and add two IP addresses:

10.1.1.4 and 192.168.2.2.
z Specify the relationship between the addresses to be probed as logical OR.
z Set the auto detect interval to 60 seconds, the number of probing retries during
each detect interval to three, and the timeout period of each probing attempt to
three seconds.
z The routes between SecPath A, B, and C are reachable.
5-2
II. Network diagram
192.168.1.2/24 10.1.1.3/24
Ethernet 1/0/1: 10.1.1.4/24

192.168.1.1 SecPathB
SecPathA SecPathC
SecPathD
Ethernet 2/0/1:
192.168.2.1
192.168.2.2/24 20.1.1.2/24
Figure 5-1 Network diagram for basic auto detect configurations
III. Configuration procedure
Configure SecPath A:
# Enter system view.
<H3C> system-view
# Create a detect group numbered 10 and enter its view.

[H3C] detect-group 10
# Add IP address 10.1.1.4 with sequence number 1 to the detect group, taking
192.168.1.2 as the next hop IP address.
[H3C-detect-group-10] detect-list 1 ip address 10.1.1.4 nexthop 192.168.1.2
# Add IP address 192.168.2.2 with sequence number 2 to the detect group.

[H3C-detect-group-10] detect-list 2 ip address 192.168.2.2
# Specify the relationship between the two addresses in the detect group as logical OR.
[H3C-detect-group-10] option or
# Set the auto detect interval to 60 seconds.

[H3C-detect-group-10] timer loop 60
# Set the maximum number of probing retries during each auto detect interval to 3.
[H3C-detect-group-10] retry 3
# Set the timeout period of a probing attempt to 3 seconds.

[H3C-detect-group-10] timer wait 3
[H3C-detect-group-10] quit
# Display the configurations of detect group 10.

[H3C] display detect-group 10
5-3
5.3 Application of Auto Detect in Static Routing

You may reference a detect group in a static route to control validity of the static route
according to the result of auto detect as follows:
z When the detect group is reachable, the static route is valid.
z When the detect group is unreachable, the static route is invalid.
5.3.1 Configuring Auto Detect for Static Routing
Note:
Before proceeding with the following configurations, you must define a detect group.
Table 5-2 Configure auto detect for static routing

[H3C] ip route-static ip-address
{ mask | mask-length }
Reference a detect { interface-type interface-number |
2 Required
group in a static route nexthop } [ preference
preference-value ] detect-group
group-number
For information about the parameters, refer to the command manual.
5.3.2 Using Auto Detect with Static Routing
z Create a detect group numbered 8 on SecPath A.

z Configure a static route between SecPath A and SecPath C.
z Validate the static route when detect group 8 is reachable.
II. Network diagram
Ethernet 1/0/1:
192.168.1.1/24 192.168.1.2/24 10.1.1.3/24 10.1.1.4/24
SecPathA SecPathB SecPathC
Figure 5-2 Network diagram for application of auto detect in static routing
5-4
<H3C> system-view

# Add an IP address of 10.1.1.4 with sequence number 1 to the detect group, taking
192.168.1.2 as the next hop IP address.
[H3C-detect-group-8] detect-list 1 ip address 10.1.1.4 nexthop 192.168.1.2
# Reference the detect group in a static route, having the route validated when the
detect group is reachable.
[H3C] ip route-static 10.1.1.4 24 192.168.1.2 detect-group 8
5.4 Application of Auto Detect in VRRP

You may reference a detect group in a VRRP standby group to control the preference
levels of the standby interface in the standby group, implementing automatic switching
between the master and backup firewalls as follows:
z When the detect group is unreachable, decrease the preference value of the
standby interface in the standby group.
z When the detect group is reachable, restore the preference value of the standby
interface in the standby group.
5.4.1 Configuring Auto Detect for VRRP
Note:
Before proceeding with the following configurations, you must define a detect group
and complete necessary VRRP configuration tasks.
Table 5-3 Configure auto detect for VRRP

[H3C] interface interface-type
2 Enter interface view —
interface-number
5-5

[H3C-InterfaceX] vrrp vrid
Reference an auto virtual-router-ID track
3 Required
detect group in VRRP detect-group group-number
[ reduced value-reduced ]
Note:
z The prompt of Ethernet interface view depends on your configuration.
z For information about the parameters and the related undo commands, refer to the
command manual.
5.4.2 Using Auto Detect with VRRP
z Configure dynamic routing on SecPath A, B, C, and D, ensuring the routes

between SecPath A, B, and C are reachable, and the routes between SecPath A,
D, and C are reachable.
z SecPath B and SecPath D form a VRRP standby group numbered 1, whose virtual
IP address is 192.168.1.100.
z Normally, data from SecPath A passes through SecPath B to reach SecPath C.
z When the link between SecPath B and SecPath C fails, SecPath D becomes the
master in standby group 1 automatically and the data from SecPath A passes
through SecPath D to reach SecPath C.
II. Network diagram
Eth1/0/0: Eth0/0/0:
192.168.1.2/24 192.168.2.1/24
192.168.1.1/24 SecPathB 192.168.2.2/24
vrid1:192.168.1.100/24 SecPathC
SecPathA 192.168.3.2/24
Eth0/0/0:
Eth1/0/0: 192.168.3.1/24
192.168.1.3/24 SecPathD
Figure 5-3 Network diagram for application of auto detect in VRRP
5-6
1) Configure SecPath B:
<H3C> system-view

# Add IP address 192.168.2.2 with the sequence number 1 to the detect group.
[H3C-detect-group-9] detect-list 1 ip address 192.168.2.2
[H3C-detect-group-9] quit
# Assign an IP address to Ethernet 1/0/0.

[H3C] interface ethernet1/0/0
[H3C-Ethernet1/0/0] ip address 192.168.1.2 24
# Create a VRRP standby group and assign a virtual IP address to it.

[H3C-Ethernet1/0/0] vrrp vrid 1 virtual-ip 192.168.1.100
# Set the standby group preference value of SecPath B to 110, making this value
decrement by 20 when detect group 9 is unreachable.
[H3C-Ethernet1/0/0] vrrp vrid 1 priority 110
[H3C-Ethernet1/0/0] vrrp vrid 1 track detect-group 9 reduced 20
# Configure interface Ethernet0/0/0.

[H3C-Ethernet1/0/0] interface Ethernet0/0/0
[H3C-Serial0/0/0] ip address 192.168.2.1 24
# Configure dynamic routing. (Omitted)

2) Configure SecPath D:
# Assign an IP address to Ethernet1/0/0, create a VRRP standby group on the interface,
and assign a virtual IP address to the standby group.
<H3C> system-view
# Set the standby group preference value of SecPath D to 100.

# Configure dynamic routing. (Omitted)

Here, only the auto detect and VRRP configurations on SecPath B and D are given.
5-7
H3C SecPath Series Security Products Chapter 6 HWPing Configurations
Chapter 6 HWPing Configurations
6.1 Introduction to HWPing

HWPing is a tool used for testing performance of the protocols operating on a network.
It is an enhancement to the ping function. You may set parameters of HWPing
operations by making use of the network management software and enable HWPing to
view the results of the operations. Alternatively, you may execute the display hwping
results command to view statistics about the HWPing operations.
SecPath1 SecPath2
HWPing client HWPing server
Figure 6-1 Relationship between HWPing client and server
6.2 HWPing Configurations

Before using the HWPing function, you must first configure HWPing server and
HWPing client.
6.2.1 Configuring HWPing Server
Perform the following tasks to configure HWPing server:

z Enable HWPing server
z Configure the services in which HWPing server listens
I. Enabling HWPing Server
Some testing operations of the HWPing function require the cooperation between
server and client, such as jitter test (analysis on the delay variations in UDP datagram
transmission) and UDP/TCP test on a specified port. HWPing server is responsible for
handling the test packets sent from HWPing client, but it can work only if it has been
enabled on the firewall.
You may enable both HWPing client and server on the same firewall. In other words, a
security can provide both services of HWPing server and client.
6-1
Table 6-1 Enable server
Operation Command
Enable HWPing server. hwping-server enable
Disable HWPing server. undo hwping-server enable
By default, HWPing server is disabled.
II. Configuring the listening service
With respect to TCP or UDP HWPing test, HWPing server responds to the test initiated
by a client via the listening function. HWPing server only responds to some particular
clients, that is, the clients whose addresses and port numbers have been configured on
the server.
You may create multiple TCP and UDP listening services on HWPing server, each for a
combination of destination address and port.
Table 6-2 Configure listening port
Operation Command
hwping-server udpecho ip-address
Configure a UDP listening service
port-num
undo hwping-server udpecho
Disable the UDP listening service
ip-address port-num
hwping-server tcpconnect ip-address
Configure a TCP listening service
port-num
undo hwping-server tcpconnect
Disable the TCP listening service
ip-address port-num
By default, no UDP or TCP listening service is configured.
Note:
If a port configured for a UDP listening service is the one that the system listens, the
UDP test fails, but the configuration still exists.
6.2.2 Configuring HWPing Client
Perform the following tasks to configure HWPing client:

z Enable client
6-2
z Create a test group

z Configure the maximum number allowed for concurrent test requests
z Enable trapping
I. Enabling Client
Only after the function of HWPing client has been enabled can various types of tests be
set and carried out.
Table 6-3 Enable HWPing client
Operation Command
Enable HWPing client. hwping-agent enable
Disable HWPing client. undo hwping-agent enable
By default, HWPing client is disabled.
II. Creating a test group
HWPing test group is a set of HWPing test items. Each test group includes several test
items and is uniquely identified by an administrator name plus a test tag.
You may perform HWPing test after creating a test group and configuring all the
parameters.
Table 6-4 Create a test group
Operation Command
Create a test group. hwping administrator-name test-tag
Remove the test group. undo hwping administrator-name test-tag
By default, no test group is configured.

Following are the configurations included in an HWPing test group:
1) Configuring a destination address
Destination address is the IP address of HWPing server, which is equal to the
destination address in a ping command. It must be the IP address where TCP or UDP
listening service has been configured.
Perform the following configuration in HWPing test group view.
6-3
Table 6-5 Configure a destination address
Operation Command
Configure a destination address. destination-ip ipaddress
Deletes the destination address. undo destination-ip
By default, no destination address is configured.

2) Configuring destination port
You must specify the port number of HWPing server when making a TCP or UDP test.
The port number must be the number of the port on which TCP or UDP listing service
has been configured.
Table 6-6 Configure a destination port
Operation Command
Configure a destination port. destination-port port-number
Delete the destination port. undo destination-port
By default, no destination port number is configured.

3) Configuring a source interface
When carrying out a DHCP test, you must specify a source interface for sending a
DHCP request. The system will directly use it to send the DHCP request. In addition,
the source IP address carried in the DHCP request will be the IP address of the
specified interface.
When carrying out other tests, you may specify a source interface for sending packets.
If the source interface has been specified, the system will directly use it rather than
determining an outputting interface via routing
Table 6-7 Bind a source interface
Operation Command
Bind a source interface. source-interface interface-type interface-number
Remove the source interface. undo source-interface
By default, source interface is not configured.

4) Configuring source address
6-4
When carrying out a test other than DHCP test, you may specify a source IP address
for sending a packet. The server will use this IP address as the destination address in
the response packet. The parameter discussed in this subsection is equal to the
parameter “-a” in a ping command of the firewall..
Table 6-8 Configure a source address
Operation Command
Configure a source address. source-ip ipaddress
Delete the source address. undo source-ip
By default, source IP address is not specified. FTP test must be configured with this
command.
5) Configuring a source port
When doing a HWPing test, you may specify a source port for sending a packet. The
server will use this port number as the destination port number in the response packet.
Table 6-9 Configure a source port
Operation Command
Configure a source port source-port port-number
Delete the configuration of the source port undo source-port
By default, source port is not specified.
Note:
As for TCP tests, if you specify a source port using this command, only the first TCP
test succeeds (use the count command to configure the number of probes in a test),
while the following TCP tests fail. If no source port is specified, the system
automatically selects an unused port to forward packets, and all the tests succeed.
6) Configuring test type

You may test various connections by using the HWPing function, but only one type at
each time. In other words, a test group can serve only one type of HWPing test.
The test types provided by HWPing include icmp, udppublic, udpprivate, tcppublic,
tcpprivate, jitter, dhcp, snmpquery, ftp, and http.
6-5
Table 6-10 Configure a test type
Operation Command
Configure a test type. test-type type
By default, test type is set to ICMP.
Note:
udppublic and tcppublic tests are used to test the number 7 port of UDP and TCP
connections respectively. When carrying out these two tests, you must execute
hwping-server udpecho ip-address 7 and hwping-server tcpconnect ip-address 7
commands to configure the port with listening function; otherwise, the tests fail.
7) Configuring the number of probes in a test

Suppose that the number of probes in a test is set greater than 1. After the first probe,
the system probes for the second time upon the receipt of the RESPONSE packet. In
the case that it does not receive any RESPONSE packet, the system waits for the
expiration of the test timer, then it probes for the second time. In this way, the system
finishes all the probes as configured. The parameter discussed in this subsection is
equal to the parameter “-n” in a ping command of the firewall.
Table 6-11 Configure the number of probes in a test
Operation Command
Configure the number of probes in a test. count times
Restore the default number of probes in a test. undo count times
By default, there is one probe in a test.

8) Configuring segment size
When carrying out ICMP, UDP and jitter tests, you may set the size of the segments. In
an ICMP test, ICMP datagram size refers to the size of the ECHO-REQUEST message
transmitted for an ICMP test, excluding the IP and the ICMP headers. The parameter
discussed in this subsection is equal to the parameter “-s” in a ping command of the
firewall.
6-6
Table 6-12 Configure segment size
Operation Command
Configure segment size. datasize size
Restore the default segment size. undo datasize
The size of a segment defaults to 56 bytes for an ICMP test, 100 bytes for an UDP test,
and 68 to 100 bytes for a jitter test. The size of a segment for a jitter test can only take
a value in the range 68 to 100 bytes.
Only in ICMP, UDP and jitter tests can you set the size of the segment.
9) Configuring auto-test interval
Configured with the auto-test feature, the system will automatically test the connection
of a specified type at a regular interval.
Table 6-13 Configure auto-test interval
Operation Command
Configure an auto-test interval. frequency interval
Disable auto-test. undo frequency
By default, auto-test interval is set to 0, i.e., only one test is performed.

10) Configuring test timeout time
Test timeout time refers to the period that the system waits for ECHO-RESPONSE after
sending an ECHO-REQUEST message, upon the expiration of which the system will
regard the destination unreachable. The parameter discussed in this subsection is
equal to the parameter “-t” in a ping command of the firewall, but in a different time unit.
Table 6-14 Configure a test timeout time
Operation Command
Configure a test timeout time. timeout time
Restore the default setting of test timeout time. undo timeout
By default, test timeout time is set to three seconds.

11) Configuring TTL
The configured TTL refers to the TTL of test messages. It is equal to the parameter “-h”
in a ping command of the firewall.
6-7
Table 6-15 Configure a TTL value
Operation Command
Configure a TTL value. ttl number
Remove the configured TTL. undo ttl
By default, the value of TTL is set to 20.
Note:
This command is applicable to test types other than DHCP test type. Command ttl will
be disabled when sendpacket passroute command is configured.
12) Configuring Type of Service

Type of Service is set in the ToS field of IP header. It is equal to the argument “-tos” in a
ping command of the firewall.
Table 6-16 Configure ToS
Operation Command
Set the ToS field. tos value
Restore the default ToS setting. undo tos
By default, ToS is set to 0.

13) Configuring packet padding character string
In ICMP, UDP and jitter tests, the system should stuff the data field of each transmitted
packet. If the size of a test packet is smaller than that of the configured padding
character string, only a portion of the string will be used for padding. If the size of the
test packet is larger, the string will be used cyclically for padding. Suppose a padding
string, “abcd” is configured. If the test packet size is 3, only “abc” will be used for
padding; if it is 6, the string “abcdab" will be used.
6-8
Table 6-17 Configure packet padding character string
Operation Command
Configure a padding character string. datafill string
Remove the padding character string. undo datafill
By default, the numbers between 0 and 255 are stuffed into datagrams in a cyclically
way.
Only in ICMP, UDP and jitter tests can you configure the packet padding character
string.
14) Configuring HTTP operations type
You may configure the type of operations that HWPing client performs in the HTTP
interaction with HWPing server.
Perform this configuration task only for an HTTP test.
Table 6-18 Configure an HTTP operations type
Operation Command
Configure an HTTP operations type. http-operation { get | post }
By default, operations type is set to get.

15) Configuring FTP operations type
You may configure the type of operations that HWPing client performs in the FTP
interaction with HWPing server.
You can perform this configuration task only for an FTP test.
Table 6-19 Configure an FTP operations type
Operation Command
Configure an FTP operations type ftp-operation { get | put }
By default, FTP operations type is get.

16) Configuring username and password used in FTP operations
You must provide the proper username and password before you can perform FTP
operations.
This configuration task can be performed only in an FTP test.
6-9
Table 6-20 Configure username and password for FTP operations
Operation Command
Configure a username. username name
Remove the username. undo username
Configure a password. password password
Remove the password. undo password
By default, no username or password is configured.

17) Configuring FTP operation file name
This configuration task is used for specifying name of the file at the server end, on
which FTP operations will be performed.
This configuration task can be performed only in an FTP test.
Table 6-21 Configure FTP operation file name
Operation Command
Configure a file name. filename file-name
Remove the file name. undo filename
By default, no file name is configured.

18) Configuring the number of test packets sent for a jitter test
Jitter test is carried out for analyzing delay variations in UDP packet transmission. In
the test, the source sends some datagrams at a regular interval (which is configurable),
upon the receipt of which the destination stamps and returns them to the source. The
source can thus work out the jitter delay with these datagrams carrying timestamps. For
this purpose, multiple test packets must be sent for each test. The analysis result of a
test is in direct proportion to the sent test packets. Naturally, the more the test packets
are sent, the longer the test duration will be.
This configuration task can be performed only in a jitter test.
Table 6-22 Configure the number of packets sent for a jitter test
Operation Command
Configure the number of packets sent for a jitter test. jitter-packetnum number
Restore the default setting. undo jitter-packetnum
6-10
By default, 10 packets are sent for each jitter test.

19) Configuring the packet transmission interval in a jitter test
You may configure a packet transmission interval in a jitter test. A smaller transmission
interval means a faster testing speed. If the interval is set too small, however, there will
be some impact on the network.
This configuration task can be performed only in a jitter test.
Table 6-23 Configure packet transmission interval in a jitter test
Operation Command
Configure packet transmission interval for a jitter test. jitter-interval interval
Restore the default setting. undo jitter-interval
By default, packets are sent at an interval of 20 milliseconds in a jitter test.

20) Configuring the maximum number of retained history records
You may specify the maximum number of history records that may be retained for a test
group. The system will discard the earlier test results if the number of records to be
retained is greater than the specified one.
Table 6-24 Configure the maximum number of retained history records
Operation Command
Configure the maximum number of
history-records number
retained history records.
Restore the default setting. undo history-records
By default, up to 50 history records can be retained for a test group.

21) Configuring routing table bypass
With routing table bypass, a remote host can bypass the normal routing tables and
send ICMP packets directly to a host on an attached network. If the host is not on a
directly-attached network, an error is returned. You can use this function when pinging
a local host on an interface that has no route defined.
6-11
Table 6-25 Configure routing table bypass
Operation Command
Enable routing table bypass. sendpacket passroute
Disable routing table bypass. undo sendpacket passroute
By default, routing table bypass is disabled.

22) Configuring VPN instance information
Table 6-26 Configuring VPN instance information
Operation Command
Configure the VPN instance information of ICMP. vpninstance name
Cancel the VPN instance information. undo vpninstance
By default, the VPN instance information is not configured for ICMP.

23) Configuring test group description
You may make a simple description on a test group, usually from the aspects of its test
items or test purpose.
Table 6-27 Configure test group description
Operation Command
Configure a test description. description string
Remove the test description. undo description
By default, no description information is configured.

24) Configuring trapping
An HWPing test generates trap information regardless of whether it fails or succeeds.
You may configure to send or not to send the trap information to the NMS by making
use of the following command and its undo form.
You can configure HWPing test as well as the number of consecutive probe failures for
the system to send a trap for the test.
If send-trap is enabled, a trap is sent for each probe or test failure.
6-12
Table 6-28 Enable/disable trap-sending
Operation Command
send-trap { all | { probefailure |
Enable trap sending.
testcomplete | testfailure } * }
undo send-trap { all | { probefailure |
Disable trap sending.
testcomplete | testfailure } * }
Configure the number of consecutive
test failures for HWPing test to send a test-failtimes times
trap.
Configure the number of consecutive
probe failures for HWPing test to send a probe-failtimes times
trap.
By default, the system does not send trap information to the NMS.
III. Configuring the maximum number of concurrent tests
You may use the command in this subsection to set the maximum number of
concurrent tests allowed on a firewall (HWPing client).
Table 6-29 Configure the maximum number of concurrent tests
Operation Command
Set the maximum number of concurrent
hwping-agent max-requests number
tests.
Restore the default maximum number of
undo hwping-agent max-requests
concurrent tests.
By default, five concurrent tests are allowed.
6.3 Executing Test

After creating a test group and configuring the required test parameters, you may
perform an HWPing test in the test group by executing the test-enable command.
Table 6-30 Test
Operation Command
Execute test test-enable
Cancel test undo test-enable
6-13
Note:
After you execute the test-enable command, the system does not display the test
result. You may view the test result information by executing the display hwping
command.
6.4 Displaying and Debugging HWPing

You may view the test history and the last test information respectively by executing the
command display hwping in any view.
The history information includes the result that the system retains for each test.
The last test information includes the information of the last test retained.
You can debug HWPing by performing the following operations in user view.
Table 6-31 Display and debug HWPing
Operation Command
display hwping { history | results |jitter }
Display the test information
[ administrator-name test-tag ]
Enable the HWPing debugging debugging hwping { all | error | event }
undo debugging hwping { all | error |
Disable the HWPing debugging
event }
6.5 Typical HWPing Configuration Example
Note:
You need to enable the HWPing client before test.
6.5.1 ICMP Test
I. Introduction
Like ping test, ICMP test in HWPing determines the roundtrip delay of a packet by
making use of ICMP.
6-14
II. Configuration procedure
Note:
Steps 1 through 3 and 6 are required for an ICMP test and the remaining three steps
are optional.
# Enable HWPing client.

[H3C] hwping-agent enable
# Step 1: Create an HWPing test group, given an administrator name “administrator”

and a test operations is “icmp”.
[H3C] hwping administrator icmp
# Step 2: Set the test type to ICMP.

[H3C-hwping-administrator-icmp] test-type icmp
# Step 3: Configure a destination IP address 169.254.10.2.

[H3C-hwping-administrator-icmp] destination-ip 169.254.10.2
# Step 4: Configure the number of probes in a test.

[H3C-hwping-administrator-icmp] count 10
# Step 5: Configure the timeout time.

[H3C-hwping-administrator-icmp] timeout 3
# Step 6: Enable a test.

[H3C-hwping-administrator-icmp] test-enable
# Step 7: View the test result.

[H3C-hwping-administrator-icmp] display hwping results administrator icmp
[H3C-hwping-administrator-icmp] display hwping history administrator icmp
6.5.2 DHCP Test
I. Introduction
HWPing DHCP test is used for testing the time required for obtaining an IP address
from a DHCP server.
6-15
Note:
Steps 1 through 3 and 6 are required for a DHCP test and the remaining three steps are
optional.


and a test operations tag “dhcp”.
[H3C] Hwping administrator dhcp
# Step 2: Set the test type to DHCP.

[H3C-hwping-administrator-dhcp] test-type dhcp
# Step 3: Configure a source interface. This interface must be an Ethernet interface and
the tested DHCP server must locate on the network attached to the interface.
[H3C-hwping-administrator-dhcp] source-interface ethernet1/0/0

[H3C-hwping-administrator-dhcp] count 10
# Step 5: Configure a test timeout time.

[H3C-hwping-administrator-dhcp] timeout 3

[H3C-hwping-administrator-dhcp] test-enable

[H3C-hwping-administrator-dhcp] display hwping results administrator dhcp
[H3C-hwping-administrator-dhcp] display hwping history administrator dhcp
6.5.3 FTP Test
I. Introduction
FTP test is used for testing the time required for setting up a connection with a specified
FTP server and finishing the transmission of a file over it. You may choose to get a file
from the FTP server or put a file on the FTP server.
6-16
Note:
Steps 1 through 6 and step 9 are required for an FTP test and the remaining three steps
are optional.


and a test operations tag “ftp”.
[H3C] hwping administrator ftp
# Step 2: Set the test type to FTP.

[H3C-hwping-administrator-ftp] test-type ftp
# Step 3: Configure the IP address of an FTP server, 169.254.10.2 for example.

[H3C-hwping-administrator-ftp] destination-ip 169.254.10.2
# Step 4: Configure the username.

[H3C-hwping-administrator-ftp] username administrator
# Step 5: Configure a password.

[H3C-hwping-administrator-ftp] password hwping
# Step 6: Configure name of the file to be gotten.

[H3C-hwping-administrator-ftp] filename config.txt

[H3C-hwping-administrator-ftp] count 10

[H3C-hwping-administrator-ftp] timeout 30
# Step 9: Configure the source address.

[H3C-hwping-administrator-ftp] source-ip 169.254.0.1

[H3C-hwping-administrator-ftp] test-enable

[H3C-hwping-administrator-ftp] display hwping results administrator ftp
[H3C-hwping-administrator-ftp] display hwping history administrator ftp
At the opposite end, you only need to enable FTP server and configure the
corresponding user.
6-17
6.5.4 HTTP Test
I. Introduction
HWPing HTTP test is used for testing the time required for setting up a connection with
a specified HTTP server and obtaining a file from it over the connection.
Note:
Steps 1 through 3 are required for a HTTP test and the remaining four steps are
optional.


and a test operations tag “http”.
[H3C] Hwping administrator http
# Step 2: Set the test type to HTTP.

[H3C-hwping-administrator-http] test-type http
# Step 3: Configure the IP address of an HTTP server, 169.254.10.2 for example.

[H3C-hwping-administrator-http] destination-ip 169.254.10.2

[H3C-hwping-administrator-http] count 10

[H3C-hwping-administrator-http] timeout 30

[H3C-hwping-administrator-http] test-enable

[H3C-hwping-administrator-http] display hwping results administrator http
[H3C-hwping-administrator-http] display hwping history administrator http
6.5.5 Jitter Test
I. Introduction
HWPing Jitter test is performed to test the jitter delay in UDP packet transmission
between the local end (HWPing client) and a specified destination (HWPing server).
6-18
Note:
Steps 1 through 4 and 8 are required for a jitter test and the remaining three steps are
optional. These operations are performed on the HWPing client.


and a test operations tag “jitter”.
[H3C] Hwping administrator jitter
# Step 2: Set the test type to jitter.

[H3C-hwping-administrator-jitter] test-type jitter
# Step 3: Configure the IP address of an HWPing server, 169.254.10.2 for example.

[H3C-hwping-administrator-jitter] destination-ip 169.254.10.2
# Step 4: Configure the destination port.

[H3C-hwping-administrator-jitter] destination-port 9000

[H3C-hwping-administrator-jitter] count 10

[H3C-hwping-administrator-jitter] timeout 30

[H3C-hwping-administrator-jitter] test-enable

[H3C-hwping-administrator-jitter] display hwping results administrator
jitter
[H3C-hwping-administrator-jitter] display hwping history administrator
jitter
[H3C-hwping-administrator-jitter] display hwping jitter administrator jitter
6-19
Caution:
At the destination, you must perform the following configuration:

[H3C] hwping-server enable
[H3C] hwping-server udpecho 169.254.10.2 9000
The address and port number configured using the hwping-server udpecho
command on the HWPing server for handling UDP test packets must be the same IP
address and port number configured in steps 3 and 4 described above.
6.5.6 SNMP Test
I. Introduction
HWPing SNMP test is performed to test the duration between the transmission of an
SNMP query and the receipt of the acknowledgement.
Note:
Steps 1 through 3 and 6 are required for an SNMP test and the remaining three steps
are optional. These operations are performed on the HWPing client.
# Enable SNMP client.

[H3C] snmp-agent trap enable


and a test operations tag “snmp”.
[H3C] Hwping administrator snmp
# Step 2: Set the test type to SNMP.

[H3C-hwping-administrator-snmp] test-type snmpquery
# Step 3: Configure a destination IP address, 169.254.10.2 for example.

[H3C-hwping-administrator-snmp] destination-ip 169.254.10.2

[H3C-hwping-administrator-snmp] count 10
6-20
[H3C-hwping-administrator-snmp] timeout 30

[H3C-hwping-administrator-snmp] test-enable

[H3C] display hwping results administrator snmp
[H3C] display hwping history administrator snmp
Caution:
You must enable the network management function on the device specified by the
destination address configured in Step 3; otherwise, it will be unable to receive
RESPONSE packet. If that device is SecPath firewall, you may enable the network
management function on it using the snmp-agent command. For more information
about that, see the part concerning SNMP configuration in this manual.
6.5.7 TCP Test of a Specified Port
I. Introduction
TCP test on a specified port is performed to test the time required for setting up a TCP
connection between the local end and a specified destination.
Note:
Steps 1 through 4 and 7 are required for a TCP test and the remaining three steps are
optional.

# Step 1: Create an HWPing test group, setting the administrator name to administrator
and test operation tag to tcpprivate.
[H3C] Hwping administrator tcpprivate
# Step 2: Set the test type to TCP-private.

[H3C-hwping-administrator-tcpprivate] test-type tcpprivate
6-21
[H3C-hwping-administrator- tcpprivate] destination-ip 169.254.10.2
# Step 4: Configure a destination port.

[H3C-hwping-administrator- tcpprivate] destination-port 9000

[H3C-hwping-administrator- tcpprivate] count 10

[H3C-hwping-administrator- tcpprivate] timeout 3

[H3C-hwping-administrator- tcpprivate] test-enable

[H3C] display hwping results administrator tcpprivate
[H3C] display hwping history administrator tcpprivate
Caution:
At the destination end, you must enable HWPing server and create an HWPing TCP
listening service by making the following configurations:
[H3C] hwping-server tcpconnect 169.254.10.2 9000
The address and port number configured using the hwping-server tcpconnect
command on the HWPing server must be the same IP address and port number
configured in steps 3 and 4 described above.
6.5.8 UDP Test of a Specified Port
I. Introduction
HWPing UDP test on a specified port is performed to test the roundtrip time of a UDP
packet.
Note:
Steps 1 through 4 and 7 are required for a UDP test and the remaining three steps are
optional.
6-22

# Step 1: Create an HWPing test group, setting administrator name to administrator

and test operation tag to udpprivate.
[H3C] Hwping administrator udpprivate
# Step 2: Set the test type to UDP-private.

[H3C-hwping-administrator-udpprivate] test-type udpprivate

[H3C-hwping-administrator-udpprivate] destination-ip 169.254.10.2
# Step 4: Configure a destination port.

[H3C-hwping-administrator-udpprivate] destination-port 9000

[H3C-hwping-administrator-udpprivate] count 10

[H3C-hwping-administrator-udpprivate] timeout 3

[H3C-hwping-administrator-udpprivate] test-enable

[H3C] display hwping results administrator udpprivate
[H3C] display hwping history administrator udpprivate
Caution:
At the destination end, you must perform the following configuration:

[H3C] hwping-server udpecho 169.254.10.2 9000
The address and port number configured using the hwping-server udpecho
command on the HWPing server must be the same IP address and port number
configured in steps 3 and 4 described above.
6-23
H3C SecPath Series Security Products Chapter 7 File Management
Chapter 7 File Management
7.1 File System

7.1.1 Brief Introduction
The major function of the file system is to manage storage devices and store files in
these devices. Currently, the storage devices supported by the firewall includes
FLASH.
The file system manages files and directories, such as to establish the file system, to
establish, delete, modify, to rename a file and a directory, and to display the contents of
a file.
7.1.2 Directory Operations
The file system can establish and delete a directory and display the current working
directory, and display the files or directories in a specified directory.
Table 7-1 Directory operations
Operation Command
Make a directory mkdir directory
Remove a directory rmdir directory
Display the current working directory pwd
Display the files or directories dir [ /all ] [ file-url | flash: ]
Change the current directory cd directory
7.1.3 File Operations
The file system can delete a file (dump into the recycle bin), restore a deleted file,
delete a file or files in the recycle bin, display the contents of a file, rename a file, copy
a file, move a file, execute the batch, display the information of specified files (even
including private files) , as displayed in Table 7-2.
Perform the following configuration in user view, (and the execute command can be
performed in system view).
7-1
Table 7-2 File operations
Operation Command
Delete a file delete [ /unreserved ] { file-url | flash: }
Restore a deleted file Undelete { file-url | flash: }
Empty the recycle bin reset recycle-bin [ filename | flash: ] [ /force ]
Display the contents of a file more file-url
Rename a file or directory rename source-name new-name
Copy a file copy fileurl_source fileurl_dest
Move a file move fileurl_source fileurl_dest
Display files or directories dir [ / all ] [ file-url | flash: ]
Execute the batch file execute { filename | flash: }
7.1.4 Detaching Web Files
You need to detach web files in the system.

Table 7-3 Detach web files
Operation Command
Detach web files detach web-bind-filename [ http-filename ]
If finding no web file to be detached, the system prompts there is no web file to be
detached. If you have not specified the name of the web file to be detached, the default
web file name is http.zip.
7.1.5 Storage Device Operation
The file system can format a specified storage device.

Perform the following configuration in the user view.
Table 7-4 Storage device operation
Operation Command
Format a storage device format device-name
7-2
7.1.6 File System Prompt Mode
The user can use the command to modify the prompt mode of the current file system.
Table 7-5 Set the prompt mode of the file system
Operation Command
Set the prompt mode of the current file system. file prompt { alert | quiet }
7.1.7 Example for the File System Usage
# Display the current files under root directory and the test directory.
<H3C> dir
Directory of flash:/
1 -rw- 2145123 Jul 12 2001 12:28:08 system
2 -rw- 595 Jul 12 2001 10:47:50 config.cfg
3 drw- - Jul 12 2001 19:41:20 test
6477 KB total (2144 KB free)
<H3C> dir flash:/test/
Directory of flash:/test/
1 drw- - Jul 12 2001 20:23:37 subdir
2 -rw- 595 Jul 12 2001 20:13:19 config.cfg
3 -rw- 50 Jul 12 2001 20:08:32 sample.txt
# Move the file from flash:/test/sample.txt to flash:/sample.txt.

<H3C> move flash:/test/sample.txt flash:/sample.txt
Move flash:/test/sample.txt to flash:/sample.txt ?[Y/N]:y
% Moveded file flash:/test/sample.txt flash:/sample.txt
# Display the current information after moving the file.

<H3C> dir
1 -rw- 2145123 Jul 12 2001 12:28:08 ne80.bin
2 -rw- 595 Jul 12 2001 10:47:50 config.cfg
3 drw- - Jul 12 2001 19:41:20 test
4 -rw- 50 Jul 12 2001 20:26:48 sample.txt
<H3C> dir flash:/test/
Directory of flash:/test/
1 drw- - Jul 12 2001 20:23:37 subdir
2 -rw- 595 Jul 12 2001 20:13:19 config.cfg
7-3
7.2 FTP Configuration

FTP is an application layer protocol in the TCP/IP protocol suite and provides users
with file transfer services between different hosts. The implementation of FTP relies on
the special file system it runs on.
FTP services provided by a firewall include:
z FTP server service, that is, the user can run the FTP client program to log on to the
firewall to access the files in the firewall.
z FTP client service, that is, the user can directly input the ftp command in the user
view to establish a connection with a remote FTP server to access the files in the
remote host.
FTP server Configuration includes:
z Start up the FTP server
z Configure the authentication and authorization of the FTP server
z Configure operating parameters of the FTP server
z Display and debug the FTP server
7.2.2 Startup
Only after the FTP server function is enabled can the FTP client login the server and
access the files on the firewall.
Table 7-6 Start up the FTP server
Operation Command
Start up the FTP server ftp server enable
Shut down the FTP server undo ftp server
The FTP server is disabled by default.
7-4
7.2.3 Configuring the Authentication and Authorization
The authorizing information of the FTP server includes the working directory path
provided for the FTP user. Only those who have passed the authentication and been
authorized successfully can gain the service of the FTP server. Before a user can use
the FTP service, you must configure the user type and FTP working directory on the
firewall.
Table 7-7 Configure the authentication and authorization
Operation Command
Create a local FTP user and enter the
local-user user-name
local user view (in system view)
Delete a specified local user undo local-user { user-name | all }
Configure the password of the FTP user
password { cipher | simple } password
(in local user view)
Cancel the password of the FTP user (in
undo password
local user view)
Configure the authorization information service-type ftp [ ftp-directory
of the FTP user (in local user view) directory ]
Restore the default authorized working
undo service-type ftp [ ftp-directory ]
directory of the FTP user
Below is an example of configuring the authentication and authorization of the FTP

server.
For example, set the name of a FTP user to ftpuser with the password pwd (in plain text)
and the authorized working directory flash:/ftp/ftpuser (which is a path name supported
by the file system of the firewall).
# Configure authentication and the related information of the FTP users.
[H3C] local-user ftpuser
[H3C-luser-ftpuser] password simple pwd
[H3C-luser-ftpuser] service-type ftp ftp-directory flash:/ftp/ftpuser
7.2.4 Configuring Operating Parameters of FTP Server
I. Configuring the upgrading mode with FTP server
The FTP server updates the data of files in its flash memory in two modes: normal and
fast, when receiving files transferred by the user using the FTP command PUT. Each of
two modes is demonstrated respectively as follows:
Fast mode: The FTP server writes the data to the flash memory after the completion of
the file transfer. This can safeguard that the files in the flash memory of the firewall will
not be damaged even at abnormal occasions such as power failure.
7-5
Normal mode: The FTP server writes the data to the flash memory during the file
transfer. This means that the occurrence of some abnormal conditions such as power
failure might cause the damage of the files in the flash memory of the firewall. But the
normal updating mode consumes less memory.
Table 7-8 Configure the update of the FTP server
Operation Command
Configure the update of the FTP server ftp update { fast | normal }
Restore the update of the FTP server to
undo ftp update
the default value
The updating mode of FTP server defaults to fast.
II. Configuring idle-timeout disconnection of FTP
To prevent illegal access, the connection with a FTP client will be disconnected if no
service request from the client has been received for a certain period.
Table 7-9 Configure the timeout of the FTP server
Operation Command
Configure the timeout of the FTP server. ftp timeout minutes
Restore the timeout of the FTP server to
undo ftp timeout
the default value.
The default idle-timeout is 30 minutes.
III. Specifying a source interface/IP address for the FTP server
Table 7-10 Specify a source interface or source IP address for the FTP server
Operation Command
Specify a source interface for the FTP ftp-server source-interface
server interface-type interface-number
Delete the source interface specified for
undo ftp-server source-interface
the FTP server
7-6
Operation Command
Specify a source IP address for the
ftp-server source-ip ip-address
packets sent by the FTP server
Delete the source IP address specified
undo ftp-server source-ip
for the FTP server
By default, the source IP address in each packet sent by the FTP server is the IP
address of the interface where the packet is sent out.
Note:
You may specify a source IP address for the packets sent by the FTP server with the
ftp-server source-interface command or with the ftp-server source-ip command. If
both commands are configured, the one configured later overrides the other.
7.2.5 Displaying and Debugging
running of the FTP server after configuration, and to verify the effect of the
configuration.
Table 7-11 Commands for monitoring and maintaining the FTP server
Operation Command
Display the FTP server display ftp-server
Display the source IP of the FTP server display ftp-server source-ip
Display log-on FTP users display ftp-user
The display ftp-server command will display the configuration of the current FTP
server, including maximum number of users that the server can support and timeout.
The display ftp-user command will display the specific information of log-on FTP
users.
7.2.6 Introduction to FTP Client
FTP client is an additional function offered to users. It allows your firewall to operate as
an FTP client to connect to an FTP server and to perform operations with FTP client
commands. At present, only one FTP client is supported.
7-7
Caution:
z When using Windows Internet Explorer as FTP client, it is recommended to login

using specified user name and password, that is, in the form
“ftp://username:password@ftp_server_ip”. If logging with the specified FTP server
IP address only, that is, in the form “ftp://ftp_server_ip”, the system gives
unsuccessful prompt because the Comware FTP does not support anonymous
login.
z It is recommended to use the FTP client software of the third party to perform the
FTP operation.
I. Operation commands available with the FTP client
The commands available with the FTP client include operations such as creating FTP
connections and creating/deleting directories. For the use of specific commands, refer
to the section of “FTP client command” in H3C SecPath Series Security Products
Command Manual.
Note:
When using FTP client for file transfer, if there already exists a file with the same name,
you should first delete the file and then enable file transfer. Otherwise, the FTP client
may time out in response and the connection will be released.
II. Specifying a source interface/IP address for the FTP client
Table 7-12 Specify a source interface or source IP address for the FTP client
Operation Command
Specify a source interface for the FTP ftp source-interface interface-type
client interface-number
undo ftp source-interface
the FTP client
ftp source-ip ip-address
packets sent by the FTP client
undo ftp source-ip
for the FTP client
7-8
Note:
ftp source-interface command or with the ftp source-ip command. If both commands
are configured, the one configured later overrides the other.
III. Displaying FTP client
You can use the display command in any view after completing the above
configuration.
Table 7-13 Display FTP client
Operation Command
Display the current source IP of the FTP server. display ftp source-ip
7.2.7 Configuration Example 1: Upgrading the Comware Application

Program with FTP
Upgrade Comware main software through FTP, with the firewall being the client. IP
address of the FTP server is 172.16.104.110; FTP username is ftpuser and its
password is pwd.
II. Network diagram
FTP Server Console Console

Console cable
Server
172.16.104.110
Ethernet SecPath
RS-232 serial port

PC
Figure 7-1 Smooth upgrade through FTP client
7-9
Follow these steps to upgrade Comware main software through FTP:

# (Prompt) Delete the redundant files in the memory device on the firewall to allow
enough space for storing new system files.
<H3C> dir
1 -rw- 939 Nov 29 2004 15:08:44 config.cfg

2 -rw- 8985472 Dec 19 2004 14:52:08 main.bin
3 -rw- 969 Oct 29 2004 16:10:20 sip.cfg

<H3C> delete /unreserved sip.cfg
# Log onto the FTP server, get the main software of the system and store it in the root
directory of the memory device on the firewall.
# The obtained system file must be stored in the root directory of the firewall memory
device, that is flash:, and named system.
<H3C> ftp 172.16.104.110
Trying 172.16.104.110 ...
Connected to 172.16.104.110.
220 WFTPD 2.0 service (by Texas Imperial Software) ready for new user
User(172.16.104.110:(none)):ftpuser
331 Give me your password, please
Password:xxxxxxx
230 Logged in successfully
[ftp] binary
[ftp] get comware3.cc system
200 PORT command okay
150 "D:\ftpuser\system\comware3.cc" file ready to send (5805100 bytes) in
IMAGE / Binary mode
226 Transfer finished successfully.
FTP: 5805100 byte(s) received in 19.898 second(s) 291.74Kbyte(s)/sec.
[ftp] bye
Reboot the firewall to run the upgraded program after the upgrade is completed.
7-10
Note:
If the connection to the firewall (as FTP client) is released during the upgrade due to
FTP server faults or other causes, you can exit the upgrade by force by pressing
<Ctrl+K>.
7.2.8 Configuration Example 2: Upgrading the Comware Application

Program with FTP
Upgrade Comware main software through FTP, with the firewall being the server. IP
address of the Ethernet interface on the firewall is 172.16.104.110; FTP username is
ftpuser and its password is pwd.
II. Network diagram
Console
Console
Console cable
FTP client
172.16.104.110
SecPath
Ethernet
FTP server
RS-232
-232 serial port
PC
Figure 7-2 Smooth upgrade through FTP server
1) Configure the firewall

# Add an authorized FTP username and password.
# Enable FTP server.

[H3C] ftp server enable
# (Prompt) Delete the redundant files in the memory device on the firewall to allow
enough space for storing new system files.
<H3C> dir
7-11
1 -rw- 939 Nov 29 2004 15:08:44 config.cfg

2 -rw- 8985472 Dec 19 2004 14:52:08 system
3 -rw- 969 Oct 29 2004 16:10:20 sip.cfg

<H3C> delete /unreserved sip.cfg
2) Configure the PC
# Log onto the firewall through FTP, upload the Comware software, and save it in the
root directory of the memory device on the firewall.
<ftp> put comware3.cc system
Reboot the firewall upon completion of the upgrade to run the upgraded software
version.
Note:
You can upgrade configuration files through FTP following the same procedures of
upgrading the main software. Note that the obtained configuration file config.cfg also
needs to be saved under the root directory (flash:).
7.3 TFTP Configuration

7.3.1 TFTP Overview
TFTP (Trivial File Transfer Protocol) is a kind of simple file transfer protocol. Compared
with another file transfer protocol FTP, TFTP has no complex interactive access
interface and authentication control, which is applicable in the environment in which no
complex interaction is needed between the client and the server. For example, the
TFTP protocol is used to obtain the memory image of the system when the system is
started. Generally, the TFTP protocol is performed based on UDP.
The transfer of the TFTP is originated by the client end. When it is necessary to
download files, the client end will send a reading request packet to the TFTP server,
receive the respond packet from the server, and send acknowledgement to the server.
When it is necessary to upload files, the client will send writing request packet to the
TFTP server and then send packet to the server and receive confirmation from the
server. The firewall works as a TFTP client.
7.3.2 TFTP Protocol Configuration
7-12
I. Using TFTP to download files
Table 7-14 Use TFTP to download files
Operation Command
tftp host [ source-interface interface-type
Use TFTP to download files interface-number | source-ip ip-address ] { get |
sget } source-filename [ destination-filename ]
Caution:
z If you choose the safe mode, you must make sure that the current system has
adequate memory and Flash memory to save the files to be downloaded.
z Do not download system application program in safe mode.
II. Using TFTP to upload files
Table 7-15 Use TFTP to upload files
Operation Command
tftp host [ source-interface interface-type
Use TFTP to upload files interface-number | source-ip ip-address ] put
source-filename [ destination-filename ]
III. Setting relevant access control list
This task is used to set TFTP server access control list, which associates with that set
by the acl command to implement the access control over the remote TFTP server
address.
Table 7-16 Set access control list
Operation Command
Specify the accessible access control
tftp-server acl acl-number
list of TFTP server
Delete the set access control list undo tftp-server acl
IV. Specifying a source interface/IP address for the TFTP client
7-13
Table 7-17 Specify a source interface or source IP address for the TFTP client
Operation Command
Specify a source interface for the TFTP tftp source-interface interface-type
undo tftp source-interface
the TFTP client
tftp source-ip ip-address
packets sent by the TFTP client
undo tftp source-ip
for the packets sent by the TFTP client
Note:
tftp source-interface command or with the tftp source-ip command. If both
commands are configured, the one configured later overrides the other.
V. Displaying TFTP client
You can use the display command in any view after completing the above
configuration.
Table 7-18 V. Display TFTP client
Operation Command
Display the current source IP of the TFTP server. display tftp source-ip
7.4 Configuration File Management

7.4.1 Overview
I. Contents and format of the configuration file
The configuration file is a text file in the following format:

z Saved in a format of commands.
z Only non-default parameters are saved for space economy (For the default values
of the configuration parameters, refer to the following sections).
7-14
z Command mode is the basic frame for organizing these commands. All
commands of the same command mode are grouped into a section and blank
lines or comment lines (which begin with “#”), are used to separate these sections.
Blank lines or comment lines can be one line or multiple lines.
z In general, these sections are arranged in the sequence of global configuration,
physical interface configuration, logical interface configuration, and routing
protocol configuration.
z Ends with “return”.
II. Displaying the current and initial configurations of the firewall
When the firewall is powdered on, it reads out a configuration file in the default storage
path to execute the initialization. So the configuration file in the default storage path is
called startup configuration. If there is no configuration file in the default storage path,
the firewall will use default parameters to execute the initialization. Compared with the
startup configuration, the valid configuration of the firewall during running is called
current configuration.
Table 7-19 Display the firewall configuration
Operation Command
Display the configuration file loaded for display saved-configuration
the next booting [ by-linenum ]
Display the configuration files for the
display startup
current and next booting.
Display the configurations in the current
display this
view.
display current-configuration
[ interface interface-type
[ interface-number ] | configuration
Display the current configurations of the
[ isp | zone | interzone |
firewall.
radius-template | system |
user-interface ] ] [ by-linenum ] [ |
{ begin | include | exclude } string ]
Note:
The format used for displaying the configuration file is the same as that for saving the
file.
7-15
III. Saving the current configuration
The user can modify the current configuration of the firewall through the command line
interface. In order to make the current configuration as the startup configuration of the
firewall at the next power-on, the save command is required to save the current
configuration into the default storage device.
Table 7-20 Save the current configuration
Operation Command
Save the current configuration save [ file-name | safely ]
If no filename is specified, the system saves the configuration file to the one loaded for
the next booting.
Executing this command without the safely keyword can make the speed of saving
configuration files fast, but these files cannot survive a reboot or power-off during the
saving process; executing this command with the safely keyword, however, makes the
saving speed slower, but these files can survive a reboot or power-off during the saving
process.
By default, fast saving applies, which is recommended in an environment where stable
power supplies are available. In an environment where stable power supplies are not
available or in the case of remote maintenance, however, you are recommended to
execute the command with the safely keyword.
Note:
You are recommended to save the configurations using the save command before
rebooting the firewall so that the firewall can keep exactly the same configurations after
its reboot.
IV. Erasing the configuration file in the current storage device
Using the reset saved-configuration command, you can erase the configuration files
loaded for the next booting which are sorted in the Flash memory. After the
configuration file is erased, the default or predefined configuration file will be used for
the initialization at the next power-on of the firewall. The configuration file in the flash
memory can be erased in the following cases:
z After the software of the firewall has been upgraded, it may cause the mismatch
between the software and the configuration file.
7-16
z It is found that the configuration file in the Flash Memory has been damaged, for
example, a wrong configuration file being loaded.
After erasing the configuration files, you can use the save command to save the
configuration files newly configured.
Table 7-21 Erase the configuration file in the storage devices
Operation Command
Erase the configuration file loaded for
reset saved-configuration
the next booting
V. Setting the configuration file to be used at the next boot
Table 7-22 Set the configuration file to be used at the next boot
Operation Command
Set the configuration file to be used at
startup saved-configuration filename
the next boot.
7.4.2 Naming Configuration Files and Setting Their Selection Order at Boot
I. Naming configuration files
config.cfg: Default name for the configuration file to be saved. It is manufacturer

specified, but you can modify the contents.
II. Selecting the configuration file
Following are how configuration files are selected at a system boot:

1) If you do not set to ignore configuration file booting, configuration files are selected
in the order described in 2) and 3). Otherwise, the system boots with empty
configuration.
2) If you specify a boot configuration file, the system selects its boot configuration file
in this order:
z If the specified configuration file exists, the system selects it as boot configuration
file.
z If the specified configuration file does not exist, the system boots with empty
configuration.
3) If you do not specify a boot configuration file, the configuration file is selected in
this order:
7-17
z If the config.cfg configuration file exists, the system selects it as boot configuration
file.
z If the config.cfg configuration file does not exist, the system boots with empty
configuration.
7.4.3 Backing up Configuration Files
You can back up configuration files by:

z Backing up the display information of the display current-configuration
command;
z Using FTP
z Using TFTP
I. Backing up the display information of the current-configuration command
Executing the display current-configuration command can displays all the

configurations in the firewall except for the defaults. In the HyperTerminal, you can back
up them by copying all the display information into a text file.
II. Backing up using FTP
You can use FTP to backup configuration files by two means:

One option is to take the firewall as the FTP server to FTP the configuration files from
the firewall to the PC (the FTP client).
After the firewall boots, perform the following configuration:
Then create an FTP connection on the PC connected to the firewall and back up the
configuration files:
C:\>ftp x.x.x.x
<ftp> get remotefile localfile
200 Port command okay.
150 Server okay , now transmit file .
226 file transmit success.
ftp: 735 bytes received in 0.06Seconds 12.25Kbytes/sec.
Where, remotefile is a configuration file on the firewall.

Alternatively, you can take the firewall as the FTP client to FTP its configuration files to
the PC (the FTP server).
Enable the FTP server and configure authorization information on the PC connected to
the firewall. Then execute the following commands on the firewall:
<H3C> ftp x.x.x.x
7-18
[ftp] put localfile remotefile
Where, localfile is a configuration file on the firewall.
III. Backing up using TFTP
The firewall is operating as TFTP client.

To upload the configuration file from the firewall to TFTP server, a PC, execute the
following command:
<H3C> tftp x.x.x.x put localfile [remotefile]
Where, localfile specifies the name of the configuration file on the firewall and
remotefile specifies the name of the uploaded configuration file to be saved on TFTP
server.
7-19
H3C SecPath Series Security Products Chapter 8 User Interface Configuration
Chapter 8 User Interface Configuration
8.1 User Interface Overview

User interface view is a new feature provided by the system. Like interface view
managing interfaces, the main purpose of this kind of view is the management of
asynchronous interfaces working in the flow mode. The emergence of this kind of view
allows the user to configure the login parameters of various users in a similar way, for
these different kinds of interfaces are usually used for system configuration
management.
So far, the system supports:
z Local configuration via the Console port
z Local/Remote configuration via the AUX interface
z Local/Remote configuration through Telnet or SSH
There are three types of user interfaces commensurate with these configuration modes.
They are:
z Console port (CON)
Console port is a kind of line device port. On a firewall, a Console port of EIA/TIA-232
DCE type is provided for users to make configuration.
z AUX interface (AUX)
AUX interface is also a kind of line device port. On a firewall, an AUX interface of
EIA/TIA-232 DTE type is provided for the dialup access via modem.
z Virtual line (VTY)
Virtual port is a logical terminal line that is used for Telnet access to the firewall and is
generally known as VTY (Virtual Type line).
8.1.2 Numbering User Interfaces
User interfaces can be numbered in two ways, that is, absolute numbering and relative
numbering.
I. Absolute numbering
There are three categories of user interfaces in the system and they are ordered in
certain sequence, specifically, CON, AUX, and VTY.
8-1
z There is only one Console interface and one AUX interface, but there can be
several VTY user interfaces, with the interfaces of each type being numbered
separately in sequence. With the absolute numbering approach, user interfaces
are numbered starting at ui0 (Console interface) and in ascending order. The
Console and AUX interfaces each have one number while for the VTY interfaces,
different products can have multiple numbers and you can use the display
user-interface command to view the number. An absolute number can uniquely
specify a user interface or a group of user interfaces.
II. Relative numbering
A relative number is in the form of user interface type + number. This number is
significant only inside the user interfaces of each type. In other words, such a number
can only specify one user interface or a user interface group among the same type of
user interfaces rather than among all the user interfaces in a unique way. Following is
the relative numbering rules:
z CON is numbered con 0.
z AUX is numbered aux 0.
z VTYs are numbered starting at 0 and in an ascending order.
8.2 User Interface Configuration

Perform the following tasks to configure a user interface:
z Enter user interface view
z Configure the protocol supported by the current user interface
z Configure the attributes of asynchronous interface
z Configure terminal attributes
z Configure user management
z Set modem attributes
z Configure the auto-execute command
z Configure incoming and outgoing call restriction on VTY user interface
8.2.1 Entering User Interface View
Access a user interface view by entering the corresponding command in system view.
You can access a single-user interface view to configure one user interface or access a
multi-user interface view to configure several user interfaces at the same time.
Table 8-1 Access user interface view
Operation Command
Access a single-user or multi-user user-interface [ type-keyword ] number
interface view [ ending-number ]
8-2
For example: Access the view of the user interface aux.

[H3C] user-interface aux 0
[H3C-ui-aux0]
In user interface view, you can configure and manage the attributes of interface,
including
1) Set the asynchronous attributes in speed, flow control, parity, stop bits and data
bits.
2) Configure terminal attributes including enabling terminal service (shell), setting
timeout disconnection (idle-timeout) of terminal user, setting the screen length
(screen-length) of the terminal screen, configuring authentication, and setting the
size of the history command buffer.
3) Set privilege including assigning privilege to the users accessing the system via
user interfaces, etc.
4) Configure modem attributes including configuring modem and its script.
8.2.2 Configuring the Current User Interface to Support the Protocol(s)
You can configure the current user interface to support the protocol(s) using the
following command. By default, the user interface supports all the protocols: Telnet, and
SSH.
Perform the following configuration in VTY user interface view:
Table 8-2 Configure the current user interface to support the protocol(s)
Operation Command
Configure the current user interface to
protocol inbound { all | ssh | telnet }
support the protocol(s)
8.2.3 Configuring Asynchronous Interface Attributes
You can configure the asynchronous attributes of a user interface in the view for it. The
following configuration commands are valid only when the interface is working in
asynchronous flow mode.
Perform the following configuration in user interface view.
8-3
I. Configuring transmission speed
Table 8-3 Configure transmission speed
Operation Command
Set a transmission speed speed speed-value
Restore the default transmission speed undo speed
Asynchronous interfaces support the transmission at the speed of

z 1200bps
z 2400bps
z 4800bps
z 9600bps
z 19200bps
z 38400bps
z 57600bps
z 115200bps
The transmission rate of an asynchronous interface defaults to 9600bps.
II. Configuring flow control mode
Table 8-4 Configure flow control mode
Operation Command
flow-control { none | software |
Configure a flow control mode
hardware }
Restore the default flow control mode undo flow-control
By default, AUX interface uses hardware flow control.

The following are descriptions of the parameters.
none: No flow control
software: Software flow control
hardware: Hardware flow control, which is only effective for AUX interface
III. Setting parity bit
Table 8-5 Set parity bit
Operation Command
Set parity bit parity { none | even | odd | mark | space }
Set parity bit to the default value undo parity
8-4
Following are the descriptions of the parameters.

none: No parity check
even: Even parity check
odd: Odd parity check
mark: Mark parity check
space: Space parity check
The parity check defaults to none, that is, no parity.
IV. Setting stop bits
Table 8-6 Set stop bits
Operation Command
Set stop bits stopbits { 1.5 | 1 | 2 }
Restore the default stop bit setting undo stopbits
The stop bit setting defaults to 1.
V. Setting databits
Table 8-7 Set data bits
Operation Command
Set data bits databits { 5 | 6 | 7 | 8 }
Restore the default data bit setting undo databits
The data bits supported by an asynchronous interface are 5, 6, 7, and 8.

The databits defaults to 8.
8.2.4 Configuring Terminal Attributes
I. Starting the terminal service
Table 8-8 Enable the terminal service
Operation Command
Enable the shell service shell
Disable the shell service undo shell
8-5
Caution:
By default, the terminal service is enabled on all user interfaces.
For example:
[H3C] user-interface vty 0 4
[H3C-ui-vty0-4] undo shell
After you configure the undo shell command, no connection can be set up. This,
however, does not affect those users that have telnetted onto the firewall; while other
users are forced to go offline. Suppose two telnet users log on to vty1 and vty2
respectively; when vty1 user executes undo shell command in vty2 view, the vty2 user
will be forced to go offline.
II. Setting idle-timeout disconnection of a terminal user
Table 8-9 Set the idle-timeout disconnection function for terminal users
Operation Command
Set the idle-timeout disconnection
idle-timeout minutes [ seconds ]
function for the users.
Restore the default idle-timeout
undo idle-timeout
disconnection setting for the users.
By default, the idle-timeout disconnection function is enabled and the timeout time is
set to 10 minutes. Configuring idle-timeout 0 will disable the idle-timeout
disconnection function.
III. Configuring user interface locking function
This configuration is used to lock the current terminal line and remind you to enter the
password, in case any other person operates on the terminal line without your
presence.
Table 8-10 Configure user interface locking function
Operation Command
Lock user interface. lock
8-6
# For example, you have accessed the firewall via VTY1, and you lock the
user-interface vty 1 now because you will leave for a while.
<H3C> lock
Password: xxxx
Again: xxxx
IV. Setting screen-length of terminal screen
Table 8-11 Set screen-length of terminal screen
Operation Command
Set screen-length of terminal screen screen-length screen-length
Restore the default screen-length of
undo screen-length
terminal screen
By default, the full screen-length of terminal screen is 24 lines.

screen-length 0 disables screen split.
undo screen-length restores the default setting.
V. Setting the size of the history command buffer
Table 8-12 Set the size of the buffer for the history command
Operation Command
Set the size of the buffer for the history
history-command max-size size-value
commands
Restore the default size of the buffer for
undo history-command max-size
the history commands
The parameter size-value is the history command buffer size which defaults to 10, that
is, the buffer is allowed to restore a maximum of ten history commands.
VI. Enabling message transfer between user interfaces
8-7
Table 8-13 Enable message transfer between user interfaces
Operation Command
Enable message transfer between user send { all | number | type-name
interfaces. number }
8.2.5 Configuring Modem Attributes
In the event of dial-in via a modem into an asynchronous interface, you can manage
and configure the modem-concerned parameters in user interface view. You should
note that the configuration commands in this case are only valid for the AUX interface.
Table 8-14 Make modem configurations
Operation Command
Set the time interval that the system
waits for the CD_UP signal after modem timer answer seconds
receiving the RING signal
Restore the default time interval that the
system waits for the CD_UP signal after undo modem timer answer
receiving the RING signal
Set the answer mode to auto-answer modem auto-answer
Set the answer mode to manual answer undo modem auto-answer
Enable the modem to dial in and dial out modem [ both | call-in | call-out ]
Disable the modem to dial in or dial out undo modem [ both | call-in | call-out ]
For example, set modem auto-answer on the AUX interface.

[H3C-ui-aux0] modem auto-answer
8.2.6 Configuring the auto-execute command
You should be aware of the following restrictions before using the auto-execute
command command:
z CON does not support auto-execute command.
z If there is only AUX but no CON on a firewall (AUX and CON shares the same
port), the AUX will not support auto-execute command as well.
z These constraints do not apply to other types of user interfaces.
When a user logs on, some command configured using auto-execute command on
the terminal will automatically be executed. The user line will be disconnected
automatically once the execution of the command is finished.
8-8
A common approach is to configure the Telnet command using the auto-execute

command command on the terminal so that the user may automatically connect to the
specified host.
Caution:
You should use this command with cautions because it will probably make you unable
to make the regular configurations for the system via the terminal line to which the
command is applied. Before configuring the auto-execute command command and
saving the configuration (by executing the save command), you should make sure that
you can access the system to remove the configuration by other means.
Table 8-15 Set the auto-execute command
Operation Command
Set the automatic execution of a
auto-execute command command
command
Disable automatic command execution undo auto-execute command
The auto-execute command that a user has configured will be automatically executed
when the user makes a new accessing attempts.
# For example, the telnet command will be executed automatically for the user to
access the destination host.
The steps to be executed are:
1) Execute the auto-execute command command in user interface view.
[H3C-ui4] auto-execute command telnet 10.110.100.1
2) Exit the system view and log on again. The telnet 10.110.100.1 command will be
executed automatically.
8.2.7 Configuring Inbound/Outbound Call Restriction on the VTY User

Interface
You can configure the inbound/outbound call restriction on the VTY (Telnet) user
interface through referencing an ACL.
8-9
Table 8-16 Configure the inbound/outbound call restriction on the VTY user interface
Operation Command
Configure the inbound/outbound call
acl acl-number { inbound | outbound }
restriction on the VTY user interface
Cancel the inbound/outbound call
undo acl { inbound | outbound }
restriction on the VTY user interface
8.3 Displaying and Debugging

user interface configuration, and to verify the effect of the configuration.
8.3.1 Displaying Use Information
Table 8-17 Display the information of users on all user interfaces
Operation Command
Display the use information on all the user interfaces display users [ all ]
8.3.2 Displaying Physical Attributes and Some Configurations
Table 8-18 Display the physical attributes and some configurations on a user interface
Operation Command
Display the physical attributes and some display user-interface [ [ type-name ]
configurations on a user interface number ] [summary]
8-10
H3C SecPath Series Security Products Chapter 9 User Management
Chapter 9 User Management
9.1 User Management Overview

A firewall is not configured with a user password when it is powered on for the first time.
In that condition, any user can perform configuration on the firewall as long as
connecting his PC with the firewall via a Console port. The remote user can also access
the firewall via Telnet if the interface of firewall has been configured with IP address,
and it is possible for the remote user to access the network by establishing PPP
connection with the firewall. To ensure the network security, it is necessary to configure
a user and user password for the firewall to facilitate the management of the user.
Note:
This chapter focuses on the authentication management over terminal users and
Telnet users. Refer to the Security part in this manual for the related information on the
authentication of other users and AAA RADIUS/HWTACACS
9.1.1 User Classification
According to the service for a user, the user of a firewall can be classified into the
following types:
z HyperTerminal user, accessing the firewall via a Console port or AUX interface;
z Telnet user, accessing the firewall via Telnet command;
z FTP user, establishing FTP connection with the firewall to transmit packets;
z PPP user, establishing PPP connections (such as dialing and PPPoE) with the
firewall to access the network.
z SSH user, establishing SSH connection to log onto the firewall;
A user can have several services at the same time. In this way, only one user can
execute multiple functions.
9-1
9.1.2 User Priority
The system manages HyperTerminal and Telnet users hierarchically. According to this
hierarchy, users are sorted into four levels: visit, monitor, system and manage,
identified by 0 through 3. After users at different levels log in, they can only use
commands at their own, or lower, levels. If password authentication or no
authentication applies, the command level that a user can access depends on the level
of the user interface where he logs in.
For example, if the priority level of a user is 2, he can access the command levels 0
through 2. The user with the priority level 3 can access all the commands. The
commands that the user of each level can access are shown in Table 9-1.
Table 9-1 User priority
User Priority Name Command

ping, tracert, telnet, rsh, nslookup, super,
0 Visit
language-mode, ,display, quit
Command with the priority level 0, reboot, reset,
1 Monitor
send, terminal, undo, upgrade, debugging
All configuration commands (except the Manage
2 System command) and the commands with the priority
level 0 and 1.
3 Manage All commands
Note:
The Manage command refers to the file system command,, the setting of authentication
method of user interface and user access level, FTP command, or TFTP command.
9.1.3 User Authentication
The system authenticates users at login. There are four types of authentication
schemes: local authentication, AAA server authentication, password authentication,
and non-authentication. Non-authentication is not preferred, because a user can log
onto the firewall without username and password when it applies. Password
authentication is somewhat securer, because it requires each login user to provide the
password even though without the username. When local authentication or AAA server
authentication applies, however, a login user must provide the username and password
that are the same as the ones configured on the firewall or the AAA server. Dialup users
are often authenticated through AAA servers whereas telnet and terminal users are
authenticated at the local.
9-2
9.1.4 Firewall User Planning
Firewall user planning can be performed according to actual requirement. Usually, at

least one HyperTerminal user (Console user) can be established on a firewall, and it is
needed to configure a Telnet user to meet the remote access requirement. A FTP user
can upload or download files on the firewall from the remote, and a PPP user can
access the network via the PPP connection with the firewall.
The configuration of Telnet/HyperTerminal user will be introduced in this section. For
the configuration of FTP users, refer to the section 7.2 “FTP Configuration” of this
module. For the configuration of PPP users, refer to User Access Operation and
Security Operation part in this manual.
9.2 User Management Configuration

The user management configuration includes:
z Configure user authentication mode
z Configure username and password
z Configure user priority
z Configure user accounting by command line
The purpose of user authentication is to enable the legal users to log on and use the
firewall and prevent the illegal users from passing the authentication and using the
firewall.
9.2.1 Configuring User Authentication Mode
By configuring the use authentication mode, you can set the authentication method
when a user accesses the firewall from the user interface specified in the view.
Table 9-2 Configure the user authentication method
Operation Command
authentication-mode { password |
Enable user authentication.
scheme [ command-authorization ] }
Disable user authentication. authentication-mode none
none indicates not to authenticate users. password indicates to authenticate the

password but not the username. scheme indicates to authenticate using an AAA
authentication scheme (a local authentication scheme or RADIUS/HWTACACS
authentication scheme) as specified by the scheme command.
By default, the authentication mode is password for VTY (Telnet and SSH users), and
AUX user interfaces and is none for other user interfaces.
9-3
Telnet and terminal user authentication usually uses the local authentication scheme.
Refer to “Security” Part of this manual.
9.2.2 Configuring Username and Password
I. Setting password for password authentication
If you choose password authentication when configuring the authentication mode, you
need to set the password.
Table 9-3 Set password for password authentication
Operation Command
Set password for password set authentication password { cipher |
authentication simple } password
Cancel password for password
undo set authentication password
authentication
simple indicates to configure the password in plain text, while cipher indicates to
configure the password in encrypted text.
II. Configuring username and password for local authentication
If you choose local authentication when configuring the authentication mode, you need
to set a username and password.
Table 9-4 Configure username and password for AAA local authentication
Operation Command
Configure a username (in system view). local-user user-name
Remove the user (in system view). undo local-user { user-name | all }
Set a password for the local user (in
password { cipher | simple } password
local user view).
Cancel the password of the local user (in
undo password
local user view).
Where, simple indicates to configure the password in plain text, while cipher indicates
to configure the password in ciphertext.
Then configure the user to adopt local authentication scheme.
9-4
Table 9-5 Configure the user in the domain to adopt local authentication scheme
Operation Command
Create an ISP domain or enter the view
domain { isp-name | default { disable |
of an existing ISP domain (in system
enable isp-name } }
view)
Delete a specified ISP domain (in
undo domain isp-name
system view)
Configure the user in the current ISP
domain to adopt local authentication scheme local
scheme (in ISP domain view)
9.2.3 Configuring User Priority
The priority configuration of the user interface and the user determines the system
commands that can be accessed.
I. Setting the priority of the user interface
You can set the priority of each user interface. Perform the following configuration in
user interface view.
Table 9-6 Set the priority of the user interface
Operation Command
Set the priority of the user interface user privilege level level
Restore the default priority of the user interface undo user privilege level
By default, the priority of the Console port is 3 and that of other user interfaces is 0.
# Set the priority of the Console port to 3 and that of VTY 0 user interface to 2.
[H3C-ui-console0] user privilege level 3
[H3C-ui-vty0] user privilege level 2
Suppose that it need not authentication for a user to log on via the two user interfaces.
The commands that can be accessed are different when a user logs on from the
Console port and VTY 0 respectively. He can access all the commands when logging
on from the Console port, and he can only access the command with the priority level
less than 2 when logging on from the VTY 0.
II. Setting the priority of the user
Perform the following configuration in local user view.
9-5
Table 9-7 Set the priority of the user
Operation Command
Set the priority of the user. level level
Restore the default priority of the user. undo level
level indicates the priority of the user, ranging from 0 to 3. 0 indicates the lowest level
and 3 the highest. The default priority is 0 after the user configuration.
Note:
If password authentication or no authentication applies, the command level that a user
can access depends on the level of the user interface where he logs in. If authentication
requires username and password, user priority determines which priority of commands
the login user can access.
9.2.4 Setting accounting according to command lines
Table 9-8 Set accounting according to command lines
Operation Command
Configure accounting according to
command lines after terminal users log accounting commands scheme
into the user interface
Remove the configuration undo accounting commands scheme
By default, accounting according to command lines is not set.
9.3 Displaying User Information

Using the following command, you can view the information of the configured user,
local user and on-line user.
9-6
Table 9-9 Display user information
Operation Command
Display the information of all users display users [ all ]
Display the information of local user display local-user
9.4 Typical Example of User Management

9.4.1 Performing Password Authentication
The user need enter the password pwd when logging on the system from the VTY 0 by
password authentication. The user priority is 3. The operation commands are shown as
follows:
<H3C> system-view
[H3C] user-interface vty 0
[H3C-ui-vty0] authentication-mode password
[H3C-ui-vty0] set authentication password simple pwd
[H3C-ui-vty0] user privilege level 3
9.4.2 Performing User Authentication Using the Local User Database
The user need enter the configured username myuser and password pwd when logging
on the system from the VTY 0. The operation commands are shown as follows:
<H3C> system-view
[H3C] user-interface vty 0
[H3C-ui-vty0] authentication-mode scheme
[H3C-ui-vty0] quit
[H3C] local-user myuser
[H3C-luser-myuser] password simple pwd
[H3C-luser-myuser] service-type telnet
[H3C-luser-myuser] level 3
[H3C] domain system
[H3C-isp-system] scheme local
9-7
H3C SecPath Series Security Products Chapter 10 NTP Configuration
Chapter 10 NTP Configuration
10.1 Brief Introduction

Network time protocol is a TCP/IP protocol intended for advertising precise time
throughout a network. Its transmission is based on UDP. The basic principle is
illustrated in the following figure:
NTP packets 10:00:00am
Netw ork
1. SecPath A SecPathB
NTP packets 10:00:00am 11:00:01am
Netw ork
2. SecPathA SecPathB
NTP packets 10:00:00am11:00:01am11:00:02am
Netw ork
3. SecPathA SecPathB
NTP Packet received at 10:00:03
Netw ork
4. SecPathA
SecPathB
Figure 10-1 NTP basic principle diagram
The above figure displays NTP basic operating principle. SecPath A and SecPath B are
connected via the network. Both of them have their own independent system clock. To
implement automatic synchronization of their system clocks, suppose:
z Before the system clocks of SecPath A and SecPath B are synchronized, the clock
of SecPath A is set to 10:00:00am and the clock of SecPath B is set to
11:00:00am.
z SecPath B acts as the NTP time server. That is, SecPath A will synchronize its
clock with that of SecPath B.
z One-way transmission of data packets between SecPath A and SecPath B needs
1 second.
The operating procedure of the system clocks synchronization includes:
z SecPath A transmits an NTP packet to SecPath B. The packet carries the
timestamp when it leaves SecPath A, which is 10:00:00am (T1).
10-1
z When the NTP packet reaches SecPath B, SecPath B adds its timestamp to it,
which is 11: 00:01am (T2).
z When the NTP packet leaves SecPath B, SecPath B adds its timestamp to it again,
which is 11:00:02am (T3).
z When SecPath A receives the response packet, it adds a new timestamp to it,
which is 10:00:03am (T4).
Until now, SecPath A has enough information to calculate the following two important
parameters:
z Time delay for the NTP message cycle: Delay = (T4-T1)-(T3-T2).
z Time offset of SecPath A relative to SecPath B: offset = ((T2-T1)+(T3-T4))/2.
In this case, SecPath A can set its own clock according to the information to
synchronize with the clock of SecPath B. This is only a simple description of the NTP
operating principle. In RFC1305, NTP uses complex algorithm to ensure the precise of
clock synchronization.
Depending on network structure and position of the firewall on the network, the firewall
can operate in one of these six modes (the first two also called unicast mode):
z Client mode, where the remote server is operating as the local time server. In this
mode, the local client can synchronize to the remote server but not conversely.
z Symmetric active mode, where the remote server is a peer. In this mode, the local
server can synchronize or be synchronized by the peer. If both of them have
reference clock, the one with lower stratum has priority.
z Broadcast server mode, where an interface on the firewall is configured to
broadcast NTP messages.
z Broadcast client mode, where an interface on the firewall is configured to receive
NTP broadcast messages.
z Multicast server mode, where an interface on the firewall is configured to multicast
NTP messages.
z Multicast client mode, where an interface on the firewall is configured to receive
NTP multicast messages.
The first two modes are unicast. They support NTP multi-instances and can
synchronize time on an MPLS VPN, allowing network devices (CEs and PEs) located
on different physical network segments to synchronize so long as they belong to the
same VPN. The following are the available functions:
z The NTP client on a CE synchronizes to the NTP server on a PE.
z The NTP client on a PE synchronizes to the NTP server on a CE through the
specified VPN instance.
z The NTP server on a PE can synchronize the NTP clients on multiple CEs.
10-2
10.2 NTP Configuration

NTP is used for time synchronization in the entire network. NTP configuration includes:
z Configure NTP operation mode
z Set NTP ID authentication
z Set the interface for the local to transmit the NTP messages
z Set the local clock to be the NTP master clock
z Enable/disable the interface to receive the NTP messages
z Set the access control authority of the local server service
z Set the number of sessions allowed to be established locally
10.2.1 Configuring NTP Operation Mode
The operation mode of the local firewall in the NTP protocol can be configured
according to the position of the firewall in the network and the network structure.
z Configure NTP server mode
z Configure NTP peer mode
z Configure NTP broadcast server mode
z Configure NTP broadcast client mode
z Configure NTP multicast server mode
z Configure NTP multicast client mode
I. Configuring NTP server mode
The following configuration is used to set the remote server specified by X.X.X.X or
server-name as the local time server. The X.X.X.X is a host address and cannot be the
address of the broadcast, multicast or reference clock. The local firewall operates in
client mode. In this mode, the local client device can be synchronized to the remote
server and the remote server cannot be synchronized to the local client device. After
you specify the vpn-instance-name argument on the PE, the NTP client on the PE can
synchronize to the NTP server on the CE, but the server does not synchronize to the
local clients.
Table 10-1 Configure NTP server mode
Operation Command
ntp-service unicast-server [ vpn-instance
vpn-instance-name ] {X.X.X.X | server-name }
Configure NTP server mode. [ version number | authentication-keyid keyid |
source-interface interface-type
interface-number | priority ] *
undo ntp-service unicast-server {X.X.X.X |
Remove NTP server mode
server-name }
10-3
The range of the NTP version number is 1 to 3. It is 3 by default. The range of the
authentication key ID number is 1 to 4294967295. The interface-type interface-number
specifies an interface, whose IP address will be used as the source IP address in the
NTP packets sent to the time server. The parameter priority specifies that the time
server is the preferred one.
II. Configuring NTP peer mode
The following configuration is used to set the remote server specified by the X.X.X.X as
the peer of the local firewall. The local firewall is run in symmetric active mode. The
X.X.X.X is a host address and cannot be the address of the broadcast, multicast or
reference clock. In this configuration, the local firewall can be synchronized to the
remote server and vice versa. After you specify the vpn-instance-name argument on
the PE, the NTP server on the PE can synchronize to the NTP server on the CE, and
the NTP server on the CE can synchronize to the NTP server on the PE.
Table 10-2 Configure NTP peer mode
Operation Command
ntp-service unicast-peer [ vpn-instance
Configure NTP peer vpn-instance-name ] {X.X.X.X | server-name } [ version
mode number | authentication-key keyid | source-interface
interface-type interface-number | priority ] *
undo ntp-service unicast-peer { X.X.X.X |
Remove NTP peer mode
server-name }
authentication key ID number is 1 to 4294967295. The interface-type interface-number
specifies an interface whose IP address will be used as the source IP address in the
NTP packets sent to the time server. The parameter priority specifies that the time
server is the preferred one.
III. Configuring NTP broadcast server mode
The following configuration specifies an interface on the local firewall to broadcast NTP
messages. The local firewall is running in broadcast server mode to broadcast
messages periodically to the broadcast clients.
Perform the following configuration in interface view.
10-4
Table 10-3 Configure NTP broadcast server mode
Operation Command
ntp-service broadcast-server
Configure NTP broadcast server [ authentication-keyid keyid | version
number ] *
Remove NTP broadcast server mode undo ntp-service broadcast-server
authentication keyid is 1 to 4294967295. This command must be configured on the
interface that is to transmit NTP broadcast packets.
IV. Configuring NTP broadcast client mode
The following configuration is used to specify the local interface on the local firewall to
receive the NTP broadcast packets. The local firewall is run in broadcast client mode. It
first listens discreetly to the broadcast packets from the server. When the first broadcast
packet is received, the local firewall starts a short client/server process to exchange
messages with the remote server in order to estimate network delay. Then it enters the
broadcast client mode to listen discreetly to the broadcast packets and synchronize the
local clock according to the coming broadcast packets.
Table 10-4 Configure NTP broadcast client mode
Operation Command
Configure NTP broadcast client
ntp-service broadcast-client
(interface view)
Remove NTP broadcast server mode undo ntp-service broadcast-client
This command must be configured on the interface that is to receive NTP broadcast
packets.
V. Configuring NTP multicast server mode
This configuration specifies an interface on the local firewall to transmit NTP multicast
packets. The local firewall is running in broadcast mode to multicast periodically to the
multicast clients.
10-5
Table 10-5 Configure NTP multicast server mode
Operation Command
ntp-service multicast-server
Configure NTP multicast server mode [ X.X.X.X ] [ authentication-keyid keyid
| ttl ttl-number | version number ] *
Remove NTP multicast server mode undo ntp-service multicast-server
The range of the NTP version number is 1 to 3. It is 3 by default. The range of the ID
authentication keyid is 1 to 4294967295. The range of the ttl-number of the multicast
packets is 1 to 255. The default multicast IP address is 224.0.1.1.
This command must be configured on the interface that is to transmit NTP multicast
packets.
VI. Configuring NTP multicast client mode
The following configuration is used to specify an interface on the local firewall to receive
the NTP multicast packets. The local firewall is run in multicast client mode. It first
listens discreetly to the multicast packets from the server. When the first multicast
packet is received, the local firewall starts a short client/server process to exchange
messages with the remote server in order to estimate network delay. Then it enters the
multicast client mode to listen discreetly to the multicast packets and synchronize the
local clock according to the coming multicast packets.
Table 10-6 Configure NTP multicast client mode
Operation Command
Configure NTP multicast client mode ntp-service multicast-client [ X.X.X.X ]
undo ntp-service multicast-client
Remove NTP multicast client mode
[ X.X.X.X ]
By default, the multicast X.X.X.X is 224.0.1.1. This command must be configured on

the interface that is to receive NTP multicast packets.
10.2.2 Configuring NTP ID Authentication
When configuring NTP ID authentication, you must configure it at both ends of server
and client and make sure that the same key is configured on them. To ensure a
successful authentication, you must also make sure that the key is reliable.
I. Enabling NTP ID authentication
10-6
Table 10-7 Configure NTP ID authentication
Operation Command
Enable NTP ID authentication ntp-service authentication enable
Disable NTP ID authentication undo ntp-service authentication enable
II. Setting NTP Authentication Key
The following configuration is used to set NTP authentication key.

Table 10-8 Configure NTP authentication key
Operation Command
ntp-service authentication-keyid number
Set NTP authentication key
authentication-mode md5 value
undo ntp-service authentication-keyid
Remove NTP authentication key
number
The range of the key number is 1 to 4294967295. The key value is 1 to 32 ASCII
characters.
III. Setting the Specified Key to Be Reliable
The following configuration is used to declare or deny that the key is reliable.
Table 10-9 Set the specified key to be reliable
Operation Command
ntp-service reliable
Specify the key to be reliable
authentication-keyid key-number
undo ntp-service reliable

Remove the specified reliable key
authentication-keyid key-number
The range of the key number is 1 to 4294967295.
IV. Associating the authentication key with the NTP Server
For server and peer modes, you must associate the specified key with the NTP server
at the client. This is because in either mode, the client may be configured with multiple
servers and therefore need an authentication key to decide which one to use.
10-7
Table 10-10 Associate the specified key with the NTP server
Operation Command
ntp-service unicast-server { X.X.X.X |
In server mode, associate the specified
server-name } authentication-keyid
key with the NTP server.
keyid
ntp-service unicast-peer { X.X.X.X |
In peer mode, associate the specified
server-name } authentication-key
key with the NTP server.
keyid
For broadcast and multicast server modes, you must associate the specified key with
the server at the server.
Table 10-11 Associate the specified key with the NTP server
Operation Command
In broadcast server mode, associate the ntp-service broadcast-server
specified key with the NTP server. authentication-keyid keyid
In multicast server mode, associate the ntp-service multicast-server
specified key with the NTP server. authentication-keyid keyid
10.2.3 Setting the Interface for the Local to Transmit NTP Messages
When specifying the local to transmit all the NTP messages, the source IP addresses in
all the packets use only one specified IP address, which is obtained from the specified
interface.
Table 10-12 Set the interface for the local to transmit NTP messages
Operation Command
Set the interface for the local to transmit ntp-service source-interface
NTP messages interface-type interface-number
Remove the interface for the local to
undo ntp-service source-interface
transmit NTP messages
The interface is determined by the interface-type interface-number arguments. The

source IP addresses in the packets obtain primary IP addresses from the interface. If
the command ntp-service unicast-server or ntp-service unicast-peer has specified
the transmitting interface, it will be taken as the transmitting interface.
10.2.4 Setting Local Clock as NTP Master Clock
The following configuration is used to set the local clock to be the NTP master clock.
10-8
Table 10-13 Set local clock as NTP master clock
Operation Command
ntp-service refclock-master
Set local clock as NTP master clock
[ X.X.X.X ] [ layers-number ]
undo ntp-service refclock-master
Remove NTP master clock
[ X.X.X.X ]
The parameter X.X.X.X is the IP address of the reference clock, which is 127.127.1.u,
with u ranging from 0 to 3. The stratum number of the NTP master clock can be
specified. layers-number is used to specify the stratum number of the local clock, which
is in the range of 1 to 15 and defaults to 8. When no IP address is specified, the local
clock is the NTP master clock by default.
10.2.5 Configuring an Interface to Receive NTP Messages
The following configuration is used to enable or disable an interface to receive the NTP
messages.
Table 10-14 Enable/disable an interface to receive NTP messages
Operation Command
Disable an interface to receive NTP
ntp-service in-interface disable
messages
Enable an interface to receive NTP
undo ntp-service in-interface disable
messages
These configurations must be configured on the interface disabled/enabled to receive

NTP messages.
10.2.6 Setting Access Control Authority of the Local Firewall Services
The following configuration is used to set the access authority of the NTP service of the
local firewall. This is only a low level security approach. The more secure approach is to
perform ID authentication. When there is an access request, this command can be
used to make the matches in sequence in a way of from the minimum access authority
to the maximum authority. All matches are based on the first match. The match order is
peer, server, server only (synchronization), and query only.
10-9
Table 10-15 Set the access authority of the NTP service of the local firewall
Operation Command
ntp-service access { query |
Set the access authority of the NTP
synchronization | server | peer }
service of the local firewall
acl-number
Remove the access authority of the NTP undo ntp-service access { query |
service of the local firewall synchronization | server | peer }
The range of the access-list-number is 2000 to 2999. Meanings of other access

authorities include:
query : Query can be performed only on the local NTP service.
synchronization: Time request can be performed only on the local NTP service.
Server: Time request and query can be performed on the local NTP service but the
local clock can not be synchronized to the remote server.
Peer: Time request and query can be performed on the local NTP service and the local
clock can be synchronized to the remote server.
10.2.7 Setting Number of Sessions Allowed to be Established Locally
The following configuration is used to set the number of sessions allowed to establish
locally.
Table 10-16 Set the number of sessions allowed to be established locally
Operation Command
Set the number of sessions allowed to ntp-service max-dynamic-sessions
be established locally number
Restore the default number of sessions undo ntp-service
allowed to be established locally max-dynamic-sessions
The number of the sessions allows to be established locally is in the range of 0 to 100.
It is 100 by default.
10.3 Displaying and debugging

running of the NTP, and to verify the effect of the configuration.
Perform the configuration of the debugging command in user view.
10-10
Table 10-17 NTP monitoring and maintenance
Operation Command
Display the state information of the NTP
display ntp-service status
service
Display the association state of the NTP display ntp-service sessions
service maintenance [ verbose ]
Display the summary information of
each NTP time server from the local
display ntp-service trace
device tracing to the reference clock
source
debugging ntp-service { all |
adjustment |authentication | event |
Enable NTP debugging switch
filter | packet | parameter | refclock |
selection | synchronization | validity }
10.4 NTP Typical Configuration Examples

10.4.1 NTP Server Configuration Example
SecPath1 sets the local clock as the NTP master clock and the stratum number is 2.
SecPath2 takes SecPath1 as the time server and set it to server mode. SecPath2 sets
itself as client mode.
II. Network diagram
Figure 10-2 Network diagram for NTP configuration
10-11
1) Configure SecPath1
# Enter the system view.
<H3C> system-view
# Set the local clock as the NTP master clock and the stratum number is 2.
[H3C] ntp-service refclock-master 2
<H3C> system-view
# Set SecPath1 as the time server.

[H3C] ntp-service unicast-server 1.0.1.11
The above configurations synchronize the time of SecPath2 and SecPath1.

The state of SecPath2 before synchronization includes:
[H3C] display ntp-service status
Clock status: unsynchronized
Clock stratum: 16
Reference source: none
Nominal frequency: 99.8562 Hz
Actual frequency: 99.8562 Hz
Clock precision: 2^7
Clock offset: 0.0000 ms
Root delay : 0.00 ms
Root dispersion: 0.00 ms
Peer dispersion: 0.00 ms
Reference time: 00:00:00.000 UTC Jan 1 1900 (00000000.00000000)
The state of SecPath2 after synchronization includes:

Clock status: synchronized
Clock stratum: 3
Reference source: 1.0.1.11
Reference time: 17:03:32.022 UTC Sep 6 2001 (BF422AE4.05AEA86C)
10-12
Now SecPath2 is synchronized with SecPath1. Its stratum number is 3, which is 1

number larger than that of SecPath1.
The association state of SecPath2 displays that SecPath2 has established connection
with SecPath1.
[H3C] display ntp-service sessions
source reference stra reach poll now offset delay disper
********************************************************************
[12345]1.0.1.11 LOCL(0) 2 377 64 1 199.53 26.1 9.7
Total associations : 1
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
10.4.2 NTP Peer Configuration Examples
SecPath4 sets SecPath3 as the time server and set it to server mode. SecPath4 sets
itself as client mode. SecPath5 sets SecPath4 as the peer.
II. Network diagram
See Figure 10-2.
III. Configuration Procedure
<H3C> system-view
<H3C> system-view
# Set SecPath3 as the time server and the stratum number is 3 after synchronization.
[H3C] ntp-service unicast-server 3.0.1.31
3) Configure SecPath5 (after SecPath4 is synchronized with SecPath3)
<H3C> system-view
# Set the local clock as the NTP master clock and stratum number is 1.
# Set SecPath4 peer after the local is synchronized.
10-13
[H3C] ntp-service unicast-peer 3.0.1.32
The above configurations make SecPath4 and SecPath5 as peers. SecPath5 is in

active peer mode and SecPath4 is in passive peer mode. Because the stratum number
of SecPath5 is 1 and that of SecPath4 is 3, SecPath4 is synchronized to SecPath5.
Clock stratum: 2

with SecPath5.
**************************************************************************
[25]3.0.1.31 127.127.1.0 2 31 64 55 466670.4 1.0 0.9

[1234]3.0.1.33 127.127.1.0 1 7 64 59 -2771.6 -0.1 0.5
10.4.3 Configuring NTP Broadcast Mode
SecPath3 sets the local clock as the NTP master clock and the stratum number is 2. It
transmits broadcast packets from Ethernet 1/0/0. SecPath4 and SecPath1 are set to
listen to the broadcast message from their interfaces respectively.
II. Network diagram
See Figure 10-2.
10-14
<H3C> system-view
# Enter the interface Ethernet 1/0/0 view.

[H3C] interface ethernet 1/0/0
# Set the broadcast server.

[H3C-Ethernet1/0/0] ntp-service broadcast-server
<H3C> system-view

[H3C-Ethernet1/0/0] ntp-service broadcast-client
<H3C> system-view

In the above configuration, SecPath4 and SecPath1 are configured to listen to

broadcast messages from Ethernet 1/0/0 and SecPath3 is configured to transmit
broadcast packets from Ethernet 1/0/0. Because SecPath1 and SecPath3 are on
different network segment, SecPath1 cannot receive the broadcast packets transmitted
by SecPath3. SecPath4 is synchronized with SecPath3 after receiving the broadcast
packets transmitted by SecPath3.
Clock stratum: 3
10-15


with SecPath3.
********************************************************************
[1234]3.0.1.31 LOCL(0) 2 377 64 1 199.53 26.1 9.7
10.4.4 Configuring NTP Broadcast Mode with ID Authentication
transmits broadcast packets from Ethernet1/0/0. SecPath4 is set to listen to the
broadcast message from Ethernet1/0/0.
II. Network diagram
See Figure 10-2.
<H3C> system-view
# Enable the authentication function.

[H3C] ntp-service authentication enable

[H3C] ntp-service authentication-keyid 88 authentication-mode md5 123456
# Set the local authentication key as reliable.

[H3C] ntp-service reliable authentication-keyid 88

10-16
# Set the local firewall as NTP broadcast server and specify authentication ID.
[H3C-Ethernet1/0/0] ntp-service broadcast-server authentication-id 88
<H3C> system-view
# Enable the authentication function.


[H3C] ntp-service authentication-keyid 88 authentication-mode md5 123456
# Set the local authentication key as reliable.


# Set the local firewall as NTP broadcast client.

In the above configuration, SecPath4 is configured to listen to broadcast messages

from Ethernet1/0/0 and SecPath3 is configured to transmit broadcast packets from
Ethernet1/0/0. SecPath4 is synchronized with SecPath3 after receiving the broadcast
<H3C> display ntp-service status
Clock stratum: 4
Reference time: 17:03:32.022 UTC Sep 6 2003(BF422AE4.05AEA86C)

10-17
10.4.5 Configuring NTP Multicast Mode
transmits multicast packets from Ethernet 1/0/0. SecPath4 and SecPath1 are set to
listen to the multicast message from their interfaces respectively.
II. Network diagram
See Figure 10-2.
<H3C> system-view

# Set the broadcast server.

[H3C-Ethernet1/0/0] ntp-service multicast-server
<H3C> system-view

[H3C] interface Ethernet 1/0/0
# Set the firewall in broadcast client mode

[H3C-Ethernet1/0/0] ntp-service multicast-client
<H3C> system-view

# Set the firewall in broadcast client mode

[H3C-Ethernet1/0/0] ntp-service multicast-client
In the above configuration, SecPath4 and SecPath1 are configured to listen to

broadcast messages from Ethernet 1/0/0 and SecPath3 is configured to transmit
broadcast packets from Ethernet 1/0/0. Because SecPath1 and SecPath3 are on
10-18
different network segment, SecPath1 cannot receive the broadcast packets transmitted
by SecPath3. SecPath4 is synchronized with SecPath3 after receiving the broadcast
The state of SecPath4 includes:
Clock stratum: 3

with SecPath3.
[SecPath4] display ntp-service sessions
********************************************************************
[1234]3.0.1.31 LOCL(0) 2 377 64 1 199.53 26.1 9.7
10.4.6 Configuring NTP Server Mode with ID Authentication
SecPath2 sets SecPath1 as the time server and sets it to server mode. SecPath2 sets
itself as client mode and adds ID authentication to it.
II. Network diagram
See Figure 10-2.
<H3C> system-view
10-19
[H3C] ntp-service refclcok-master 2
<H3C> system-view
# Enable NTP service authentication.

# Set an authentication key.

[H3C] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey
# Specify reliable authentication key

# Set SecPath1 as the time server and set the authentication key.
[H3C] ntp-service unicast-server 1.0.1.11 authentication-keyid 42
The above configurations synchronize the time of SecPath2 and SecPath1. Because
SecPath1 does not enable ID authentication, SecPath2 cannot be synchronized to
SecPath1. Now the following configurations are added to SecPath1.
# Enable NTP service authentication.
# Set an authentication key.

[H3C] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey
# Specify reliable authentication key

[SecPath] ntp-service reliable authentication-keyid 42
Now SecPath2 can request synchronization with SecPath1. When they are
synchronized, SecPath2 is in this state:
Clockstratum: 3
10-20

greater than that of SecPath1.
10-21
H3C SecPath Series Security Products Chapter 11 SNMP Configuration
Chapter 11 SNMP Configuration
11.1 Protocol Introduction

Currently, the most widely used network management protocol in computer network is
Simple Network Management Protocol, in short, SNMP, which is an applicable
industrial standard adopted widely. Its purpose is to ensure the transmission of
management information between any two points so that the network administrator can
retrieve the information at any point on the network and perform appropriate
modification, troubleshooting, fault diagnosis, and volume planning and reporting. It
adopts a polling mechanism and offers an underlying function set, which is appropriate
especially in a small environment in need of high speed and low cost. It only requires
connectionless transport layer protocol UDP and is widely supported by a variety of
products.
Structurally, SNMP can be divided into two parts, NMS and Agent. The NMS (Network
Management Station) is a workstation on which the client program is running. Currently,
commonly used network management platforms are Sun NetManager and IBM
NetView while the Agent is a server-side software running on a network device. The
NMS can send packets of GetRequest, GetNextRequest, GetbulkRequest, or
SetRequest to the Agent. Once the Agent receives request packets from the NMS, it
will perform Read or Write operations on variables being managed according to the
type of the packets and generate a Response packet to return to the NMS. On the other
hand, if any exception happens to the device, like a hot or cold start, the Agent also can
send a Trap packet to the NMS on its own initiative, reporting the event happened.
11.1.2 SNMP Versions and Its Supported MIB
In order to identify a management variable uniquely in the SNMP packets, SNMP uses
a hierarchical naming convention to distinguish different managed objects and the
hierarchical structure is like a tree with its nodes representing managed objects.
Displayed in the diagram below, a managed object can be identified uniquely by the
path from the root to the node representing it.
11-1
1 2
1 2
1 2
B
5 6
A
Figure 11-1 MIB tree structure
In the diagram above, the managed object B can be uniquely determined by a string of
digits {1.2.1.1}, which is the Object Identifier of the managed object. While the MIB
(Management Information Base) is used to describe the hierarchical structure of the
tree and is a collection of the definitions of standard variables on monitored network
devices.
Currently, the SNMP Agent in firewall system supports SNMP V3 and is compatible with
SNMP V1 and SNMP V2C. For related MIB information, refer to MIB companion.
11.2 SNMP Configuration

The SNMP configuring includes:
z Set the SNMP Agent service
z Set the corresponding versions of SNMP
z Set the community name
z Set the SNMP group
z Set the SNMP user
z Set sysContact
z Set the sending Trap
z Set the engine ID of a local device
z Set the address of the Trap target host
z Set sysLocation
z Set the source address for sending Traps
z Set the MIB view
z Set packet queue length of Trap sent to destination host
z Set the saving time of Trap packets
z Set the maximum size of SNMP packets that an agent can receive or send
11.2.1 Setting the SNMP Agent Service
This configuration is used to enable the SNMP Agent service, which is disabled by
default.
11-2
Table 11-1 Set the SNMP Agent service
Operation Command
Enable the SNMP Agent service snmp-agent
Disable the SNMP Agent service undo snmp-agent
11.2.2 Setting the Corresponding Versions of SNMP
This configuration is used to enable the corresponding version of SNMP and the SNMP
V3 is enabled by default. Therefore the command needs to be configured to enable
SNMP V1 and SNMP V2C.
Table 11-2 Set the corresponding version of SNMP
Operation Command
Enable the corresponding version of snmp-agent sys-info version { { v1 |
SNMP v2c | v3 } * | all }
Disable the corresponding version of undo snmp-agent sys-info version
SNMP { { v1 | v2c | v3 } * | all }
"*" indicates to select several versions from v1, v2c and v3, with one at least and all
three at most.
Example: Enable version SNMP V2C and SNMP V3.
[H3C] snmp-agent sys-info version v3 v2c
Example: Disable version SNMP V2C and SNMP V1.

[H3C] undo snmp-agent sys-info version v1 v2c
11.2.3 Setting the Community Name
SNMPV1, SNMPV2C use community names for authentication and SNMP packets that
do not match the authenticated community name of the device will be dropped. A
SNMP community is named with a character string called Community Name. Different
communities can have read or write access mode. A community with the privilege of
read can only perform queries on device information and a community with the
privilege of write can configure the devices additionally.
11-3
Table 11-3 Set the Community Name
Operation Command
snmp-agent community { read | write }
Set a community name and its access
community-name [ mib-view view-name
privilege
| acl acl-number ]*
Remove a community name previously undo snmp-agent community
set community-name
If you perform configuration on a community name more than once, the attribute last
configured will be adopted.
# Set the public community to read privilege.
[H3C] snmp-agent community read public
# Set the private community to write privilege.

[H3C] snmp-agent community write private
11.2.4 Setting the SNMP Group
This configuration can be used to set and delete a SNMP group.

Table 11-4 Set the SNMP group
Operation Command
snmp-agent group { v1 | v2c } group-name
[ read-view read-view ] [ write-view write-view ]
[ notify-view notify-view ] [ acl acl-number ]
Set a SNMP group
snmp-agent group v3 group-name [ authentication |
privacy ] [ read-view read-view ] [ write-view
write-view ] [ notify-view notify-view ] [ acl acl-number ]
undo snmp-agent group { v1 | v2c } group-name
Delete a SNMP group undo snmp-agent group v3 group-name
[ authentication | privacy ]
11.2.5 Setting the SNMP User
This configuration can be used to add or delete a new user to the SNMP group.
11-4
Table 11-5 Set the SNMP user
Operation Command
snmp-agent usm-user { v1 | v2c } user-name group-name
[ acl acl-number ]
Add a new user to
the SNMP group snmp-agent usm-user v3 user-name group-name
[ authentication-mode { md5 | sha } auth-password
[ privacy des56 priv-password ] ] [ acl acl-number ]
undo snmp-agent usm-user { v1 | v2c } user-name
Delete a user from group-name
the SNMP group undo snmp-agent usm-user v3 user-name group-name
{ engineid engine-id | local }
# Add a user “John” to SNMP group “Johngroup”, with security level being
authentication required, the specified authentication protocol being “HMAC-MD5-96”,
and the authentication password being “hello”.
[H3C] snmp-agent usm-user v3 John Johngroup authentication-mode md5 hello
11.2.6 Setting the System Contact
System contact is a management variable of the group system in MIB II and it contains
the ID and contact of relevant administrator of the managed devices (firewall). Through
configuring this parameter, the user can store the important information in the firewall
so as to query when emergency occurs.
Table 11-6 Set the ID and contact of the administrator
Operation Command
Set the ID and contact of the snmp-agent sys-info contact
administrator sysContact
Restore the ID and contact of the
undo snmp-agent sys-info contact
administrator to default values
For example,
[H3C] snmp-agent sys-info contact Mr.zhang 13800138002
11.2.7 Setting the Sending Trap
Traps are pieces of information sent to the NMS by the agent without being solicited,
reporting some emergent and significant events.
11-5
Table 11-7 Set the sending Trap
Operation Command
Enable sending Trap snmp-agent trap enable [ trap-type [ trap-list ] ]
Disable sending Trap undo snmp-agent trap enable [ trap-type [ trap-list ] ]
By default, trap sending is allowed.

The command snmp-agent trap enable without parameter indicates allowing sending
Trap of all types in all modules.
11.2.8 Setting the Engine ID of a Local Device
This configuration can be used to set the engine ID of a local device. The ID is a string
of 10 to 64 hexadecimal numbers and its default value is the company’s enterprise
number plus the device information, which can be an IP address, an MAC address or a
self-defined text.
Table 11-8 Set the engine ID of a local device
Operation Command
Set the engine ID of a device snmp-agent local-engineid engineid
Set the engine ID of a device to the
undo snmp-agent local-engineid
default value
11.2.9 Setting the Address of the Trap Target Host
Table 11-9 Set/remove the address of the destination host for receiving Trap packets
Operation Command
snmp-agent target-host trap address

udp-domain X.X.X.X [ udp-port
Set the address of the destination host
port-number ] params securityname
for receiving Trap packets
security-string [ v1 | v2c | v3
[ authentication | privacy ] ]
Remove the address of the destination undo snmp-agent target-host X.X.X.X
host for receiving Trap packets securityname security-string
For example, to set the address of the Trap target host to 202.38.160.6, using the
community name public.
11-6
[H3C] snmp-agent target-host trap address udp-domain 202.38.160.6 udp-port

5000 params securityname public
11.2.10 Set the interface to send Trap packets
When the interface state changes (for example, up state changes to down state), the
Trap packet is sent from the interface to the destination host.
Table 11-10 Set the interface to send Trap packets
Operation Command
Set the interface to send Trap packets enable snmp trap updown
Disable the interface to send Trap
undo enable snmp trap updown
packets
By default, the Trap packet is sent from the interface.
11.2.11 Setting the Firewall’s Location (sysLocation)
sysLocation is a management variable of the system group in MIB and stands for the
location of a managed device.
Table 11-11 Set the location of a firewall
Operation Command
snmp-agent sys-info location
Set the location of the firewall
sysLocation
Restore the location of the firewall to the
undo snmp-agent sys-info location
default value
For example, to set the physical location of the firewall to hwbj.

[H3C] snmp-agent sys-info location hwbj
11.2.12 Setting the Source Address for Sending Traps
This configuration can be used to specify the source address for sending Traps.
11-7
Table 11-12 Set the source address for sending Trap packet
Operation Command
Specify the source address for sending snmp-agent trap source interface-type
Traps interface-number
Remove the source address for sending
undo snmp-agent trap source
Traps
For example, to take the IP address of the Ethernet interface 1/0/0 as the source
address of the Trap packet.
[H3C] snmp-agent trap source ethernet 1/0/0
11.2.13 Setting the MIB View
These configurations can be used to establish, update or delete the view information.
Table 11-13 Set the SNMP view
Operation Command
Establish or update view snmp-agent mib-view { included | excluded }
information view-name oid-tree
Delete a view undo snmp-agent mib-view view-name
For example, to establish a view named mib1 containing all the objects of Internet.
[H3C] snmp-agent mib-view included myview 1.3.6.1
11.2.14 Setting the Maximum Size of SNMP Packets
This configuration can be used to set the maximum size of SNMP packets, which an
Agent can receive or send.
Table 11-14 Set the maximum size of SNMP packets that an Agent can receive or
send
Operation Command
Set the maximum size of SNMP packets snmp-agent packet max-size
that an Agent can receive or send byte-count
Restore the maximum size of SNMP
undo snmp-agent packet max-size
packets to the default value
11-8
The range of the maximum size of SNMP packets that an Agent can receive or send is
484 to 17940 bytes and the default size is 1500 bytes.
# Set the maximum size of SNMP packets that an Agent can receive or send as 1042
bytes.
[H3C] snmp-agent packet max-size 1042
11.2.15 Setting the Packet Queue Length of Trap Packet
The configuration can be used to set the packet queue length of the Trap packets sent
to the destination host.
Table 11-15 Set the packet queue length of Trap sent to destination host
Operation Command
Set the packet queue length of the Trap
snmp-agent trap queue-size size
packets sent to the destination host
Restore to the default value of the
undo snmp-agent trap queue-size
packet queue length
The range of the packet queue length is 1 to 1000 with the default value as 100.
# Sets the packet queue length of the host sending the Trap packets as 200.
[H3C] snmp-agent trap queue-size 200
11.2.16 Setting the Saving Time of Trap Packets
The configuration is used to set the saving time of Trap packets, and all the Trap
packets exceeding this time will be deleted.
Table 11-16 Set the saving time of Trap packets
Operation Command
Set the saving time of Trap packets snmp-agent trap life seconds
Restore to the default value of Trap
undo snmp-agent trap life
packets saving time
The range of Trap packets saving time is 1 to 2592000, with the default value as 120
seconds.
# Sets the saving time of Trap packets as 60 seconds.
[H3C] snmp-agent trap life 60
11-9

running of the SNMP configuration, and to verify the effect of the configuration, but the
debugging command should be performed in the user view.
Table 11-17 Monitoring and maintenance of SNMP
Operation Command
Display the versions enabled by SNMP display snmp-agent sys-info version
Display the statistics of SNMP packets display snmp-agent statistics
Display the engine ID of the current display snmp-agent { local-engineid |
device remote-engineid }
Display the group name, security mode,
display snmp-agent group
status of views, and storage modes of
[ group-name ]
groups
display snmp-agent usm-user
Display all the SNMP user names in a
[ engineid engineid | username
group user name list
user-name | group group-name ] *
Display the community name of the display snmp-agent community
current configuration [ read | write ]
display snmp-agent mib-view

Display the MIB view of the current
[ exclude | include | viewname
configuration
view-name ]
Display the character string of system
display snmp-agent sys-info contact
contact
Display the character string of system
display snmp-agent sys-info location
location
debugging snmp-agent { header |
Enable SNMP debugging
packet | trap | process }
Note:
In the current version, nothing is shown for the display snmp-agent remote-engineid
command.
11.4 Example of Typical Configuration

A network management station with the IP address of 129.102.149.23 is connected to

the firewall with the IP address of 129.102.0.1 via an Ethernet.
11-10
II. Network diagram
NMS SecP ath
129.102.149.23 129.102.0.1
Figure 11-2 Network diagram for SNMP configuration
Step 1: Enable SNMP version V1.

<H3C> system-view
[H3C] snmp-agent
[H3C] snmp-agent sys-info version v1
Step 2: Set the community name and its access privilege.

Step 3: Set the ID and contact of the administrator and the physical location of the
firewall.
[H3C] snmp-agent sys-info contact Mr.Wang-Tel:3306
[H3C] snmp-agent sys-info location telephone-closet,3rd-floor
Step 4: Permit to send trap messages to the Network Management Station (NMS)
129.102.149.23, using public as the community name, 5000 as the number of the port
that receives the trap on the NMS, and v1 as the format of trap message sending.
[H3C] snmp-agent target-host trap address udp-domain 129.102.149.23 udp-port
5000 params securityname public
11-11
H3C SecPath Series Security Products Chapter 12 BIMS Configuration
Chapter 12 BIMS Configuration
12.1 Introduction to BIMS

When you manually manage network devices through SNMP, Telnet, or some other
method, you must first know the IP addresses of these devices. This brings difficulty to
you when you manage the devices which dynamically gain their IP addresses through
DHCP and the devices behind NAT. The Branch Intelligent Management System (BIMS)
is designed to resolve this problem, by allowing the devices to automatically update
configuration files and application programs.
The BIMS is composed of two components, one at the BIMS center side and the other
at the BIMS device side) and operates as follows: first, according to some policy, the
BIMS devices send particular requests to the BIMS center when starting up, or sends
requests to the center once at a specific time or regularly at specific intervals after
starting up; then, according to some policy set by the administrator, the BIMS center
exchanges information with the devices. During the information exchanging, the
system, according to the requirement of the administrator, performs various
management (such as updating the old software or configuration, recording
configuration and state information for the query of the administrator) on the devices, in
such a way, the administrator can implement uniform management on the devices.
The component at the center side is a service software (for example, the BIMS service
component of Quidview NMS V3.10) running on a PC or a server. And the component
at the device side is integrated into the software system on BIMS devices. The BIMS
devices automatically update their configuration files and application programs through
accessing the PC or server at the center.
The main function of the BIMS is to allow the BIMS devices to gain new configuration
files or application programs through:
z Immediately accessing the BIMS center as a response to the command you
issued.
z Immediately accessing the BIMS center when the devices starts up.
z Regularly access the BIMS center at specific intervals.
z Access the BIMS center at a specific time.
The procedure that a device updates its configuration files or application programs
through BIMS is as follows:
1) Enable the BIMS function on the device such that it can access the BIMS center.
Then configure the unique ID of the device, the IP address of the center, and the
shared key between the device and the center.
2) Being triggered by some reasons, the device sends a request to the center, asking
for the center to check if it is necessary to update the files on the device.
12-1
3) The center receives the request, and then determines (according to the file
information contained in the request) whether the files need an update. If yes, the
center responds with a message, which carries the update configuration file or the
URL path and characters of the update device software, or the commands and
parameters need to be executed by the device.
4) The device receives the response message. It parses the message and then gains
the URL for the software, the encrypted configuration file, or the commands and
parameters.
5) The device executes and saves the configuration file it gained.
6) The device downloads the device software from the center through the URL it
gained.
7) The device verifies the device software it downloaded. Then update the old one
and sends a confirmation message to the center.
8) The center receives and logs the confirmation message and then returns an
answer.
12.2 Configuring BIMS

The BIMS provides an intelligent configuration file and application program updating
function to ease your management. The following sections describe the related
configuration tasks at the device side:
z Enabling BIMS on a Device
z Configuring the Unique ID of the Device
z Configuring the IP Address and Port number of the BIMS Center
z Configure the Source IP Address of the Packet Sent by the BIMS Device
z Configuring the Shared Key Between the Device and the Center
z Enabling/Disabling the Device to Access the Center Once Powered on
z Enabling/Disabling the Device to Access the Center at Regular Intervals
z Enabling/Disabling the Device to Access the Center at Specific Time
z Enabling the Device to Access the Center Immediately
Where, it is necessary to enable the BIMS, configure the unique ID of the device, the IP
address and port number of the center, and the share key; and it is for your
convenience to select the method used by the device to access the center.
12.2.1 Enabling BIMS on a Device
Execute the following command in system view.
12-2
Table 12-1 Enable BIMS on a device
Operation Command
Enable BIMS on a device bims enable
Disable BIMS on the device undo bims enable
By default, BIMS function is disabled.
12.2.2 Configuring the Unique ID of the Device
You can use the command here to configure the unique ID of the device, which will be
used by the BIMS center to uniquely distinguish the device from other devices.
Table 12-2 Configure the unique ID of the device
Operation Command
Configure the unique ID of the device bims device-id string
Delete the unique ID of the device undo bims device-id
The maximum length of the ID is 30 characters. by default, no such ID is configured for

the device.
12.2.3 Configuring the IP Address and Port number of the BIMS Center
You can use the command here to configure the IP address and port number of the
BIMS center.
Table 12-3 Configure the IP address and port number of the BIMS center
Operation Command
Configure the IP address and port bims ip address ip-address [ port
number of the BIMS center portnumber ]
Delete the IP address and port number
undo bims ip address
of the BIMS center
When you configure the IP address of the BIMS center without inputting a port number,
the system default to use port 80 for the BIMS center.
By default, the IP address of the BIMS center is not configured.
12-3
12.2.4 Configure the Source IP Address of the Packet Sent by the BIMS
Device
You can use the IP address of a certain interface as the source IP address of the packet
sent by the BIMS device.
Table 12-4 Configure the source IP address of the packet sent by the BIMS device
Operation Command
Configure the source IP address of the
bims source ip-address ip-address
packet sent by the BIMS device
Delete the source IP address configured undo bims source ip-address
By default, the source IP address is not configured.
12.2.5 Configuring the Shared Key Between the Device and the Center
You can use the command here to configure the shared key between the device and
the center.
Table 12-5 Configure the shared key between the device and the center
Operation Command
Configure the shared key between the bims sharekey { simple | cipher }
device and the center sharekey
Configure the shared key between the
undo bims sharekey
device and the center
By default, no shared key is available.
12.2.6 Enabling/Disabling the Device to Access the Center Once Powered on
After executing the bims boot request command, the device will access the BIMS
center once it is powered on.
12-4
Table 12-6 Enabling/disabling the device to access the center once powered on
Operation Command
Enable the device to access the center
bims boot request
once powered on
Disable the device to access the center
undo bims boot request
once powered on
By default, the device accesses the center immediately when powered on.
12.2.7 Enabling/Disabling the Device to Access the Center at Regular

Intervals
After you execute the bims interval command, the device regularly accesses the BIMS
center at the intervals you specified.
Table 12-7 Enabling/disabling the device to access the center at regular intervals
Operation Command
Enable the device to access the center
bims interval number
at regular intervals
undo bims interval
at regular intervals
The number parameter ranges from 10 to 10080 minutes. By default, no interval is

configured.
12.2.8 Enabling/Disabling the Device to Access the Center at Specific Time
You can use the command here to enable the device to access the BIMS center at a
specific time. In addition, you can also enable the device to access the center at
specific time in specific cycle and stop the accessing at specific end time.
Table 12-8 Enabling/disabling the device to access the center at specific time
Operation Command
Enable the device to access the center bims specify-time hh:mm yyyy/mm/dd
at specific time in specific cycle and stop [ [ hh:mm yyyy/mm/dd ] period-days
the accessing at specific end time numberdays ]
undo bims specify-time
at specific time
12-5
12.2.9 Enabling the Device to Access the Center Immediately
Once you execute this command, the device immediately accesses the BIMS center.
Execute the following configuration in system view.
Table 12-9 Enable the device to access the center immediately
Operation Command
Enable the device to access the center immediately bims request
12.3 Displaying and Debugging BIMS

After performing the above configuration, you can use the display
current-configuration command in any view to check the operation of the BIMS, and
thus verify the result of the configuration.
In addition, you can execute the debugging command to enable the debugging for the
BIMS and use the debugging output to monitor and maintain the BIMS configuration.
Table 12-10 Enable the debugging for the BIMS
Operation Command
Enable the debugging for the BIMS debugging bims all
Disable the debugging for the BIMS undo debugging bims
12.4 BIMS Configuration Example

12.4.1 Enable the Device to Access the BIMS Center Once Powered on
The device accesses the BIMS center immediately after it is powered on and then
accesses the center at the intervals of 48 hours. The IP address of the center is
10.153.21.97, and the port number is 80.
z Configuring the BIMS center

Generally, the BIM center applies the BIMS component of Quidview NMS. You should
perform the following configuration for this component:
1) Set the shared key in the parameter setting interface on the center to the same
one as that on the device.
2) Add the device to the NMS manually by entering the name of the device. Or open
the auto-adding switch to let the system automatically add the device when the
12-6
device accesses the BIMS center (in such a way, you must first set the shared
key).
3) Specify the update files (including the configuration files and application software)
for the device. After that, when the device accesses the center, the system judges
whether the files on the device need an update. If they need, the update files are
downloaded to the files and update the corresponding files on the device.
Note:
For detailed instructions about the BIMS component of Quidview NMS, refer to the user
manual of the Quidview NMS BIMS component.
z Configuring the device

<H3C> system-view
# Enable the BIMS on the device.

[H3C] bims enable
bims is enable
# Configure the unique ID of the device to secpath-20-907.

[H3C] bims device-id secpath-20-907
# Configure the shared key between the BIMS device and center.
[H3C] bims sharekey simple 1122334455667788
# Configure the IP address of the BIMS center to 10.153.21.97, and use the default port
number 80.
[H3C] bims ip address 10.153.21.97
# Enable the device to access the center once powered on.

[H3C] bims boot request
# Enable the device to access the center at regular intervals of 48 hours.

[H3C] bims interval 2880
After the above configuration, the device accesses the BIMS center immediately after
powered on, and then accesses the center once every 48 hours. Every time the device
accesses the center, the center judge (according to the update file list for the device)
whether the files on the device need to be updated and then, if need, sends the update
files to the device to update the corresponding files it.
12-7
12.4.2 Enable the Device to Periodically Access the BIMS Center in a Time
Range
The device accesses the BIMS center at 12:10 2005/05/01 and from that time on
periodically accesses the center every two days till 23:50 2005/10/01. The IP address
of the center is 10.153.21.97, and the port number is 80.
# Refer to the above example to configure the BIMS center. The following only
describes the configuration on the device.
<H3C> system-view
# Enable the BIMS on the device.

[H3C] bims enable
bims is enable
# Configure the unique ID of the device to secpath-20-907.

[H3C] bims device-id secpath-20-907
# Configure the shared key between the BIMS device and center.
[H3C] bims sharekey simple 1122334455667788
# Configure the IP address of the BIMS center to 10.153.21.97, and use the default port
number 80.
[H3C] bims ip address 10.153.21.97
# Enable the device to periodically access the BIMS center at 12:10 every two days
from 12:10 2005/05/01 to 23:50 2005/10/01.
[H3C] bims specify-time 12:10 2005/05/01 23:50 2005/10/01 period 2
After the above configuration, the device accesses the BIMS center at the specific time
and then periodically accesses the center in the specified time range in the specified
cycle. Every time the device accesses the center, the center judge (according to the
update file list for the device) whether the files on the device need to be updated and
then, if need, sends the update files to the device to update the corresponding files on
it.
12-8
12.5 Troubleshooting BIMS

12.5.1 Device Cannot Access BIMS Server Successfully
I. BIMS basic configuration on device is incomplete or incorrect
Incomplete or incorrect BIMS basic configuration may cause a device unable to access
the BIMS server. Therefore, before accessing a BIMS server, you need to check
whether the bims device-id, bims ip address and bims sharekey command are
correctly configured on a device, and make sure BIMS function is enabled.
1) The IP address or port number of the server is not correctly configured
In this case, a device may fail to connect to a BIMS server. Configured with incorrect IP
address or port number of the BIMS server, a device may be unable to access the
BIMS server due to a timed out connection between them.
2) The BIMS shared key on the device is inconsistent with that on the BIMS server
In this case, BIMS server cannot resolve messages, which results in communication
failure. The device can receive packets from the peer; however, packets cannot be
resolved because the shared keys on the two ends are different.
II. No boot image on device
The device checks its boot image files when accessing a BIMS server. If the boot image
does not exist, BIMS services will be affected. However, you can solve this problem by
upgrading BIMS version for the device.
III. Device boots with no configuration
The device checks its boot configuration file when accessing a BIMS server. If the
configuration files do not exist, BIMS services will be affected. However, you can solve
this problem by upgrading BIMS version for the device.
12.5.2 New Files Cannot Be Downloaded to Device
I. No enough storage space on device
The device automatically stops downloading files through BIMS server if the storage
space of the device is not enough. To solve this problem, you can delete certain unused
files from the storage components until the storage space becomes enough, and then
access the BIMS server.
II. No enough memory on device
The file upgrade of a device, especially the software image file upgrade implemented
by BIMS takes much device memory. When a device handles lots of services and
upgrades files through BIMS at the same time, a download failure may occur due to
12-9
insufficient memory. In such cases, a message prompting memory shortage is

outputted.
At this time, you may wait until other services are finished with more memory available
to perform the upgrade operation, or you can expand the device memory.
12.5.3 Device Cannot Obtain BIMS Configuration Through DHCP
BIMS supports a device to obtain BIMS configuration through DHCP. This feature aims
at implementing management on multiple devices with no BIMS configuration.
The IP address obtained from DHCP server has a lease time. When the lease time
expires, DHCP server sends IP address, as well as BIMS configurations again to the
device.
z Without BIMS function enabled, the device accepts the BIMS configurations sent
by DHCP server.
z With BIMS function enabled, the device discards the BIMS configurations sent by
DHCP server. If you want the device to obtain BIMS configurations through DHCP,
make sure that the BIMS function on the device is disabled.
12.5.4 The Access Interval Is Changed for Accessing BIMS Server
To implement management on devices, you can adjust the interval at which a device
accesses a BIMS server according to the service volume on the BIMS server to ease its
workload.
A device obtains a new polling interval from a BIMS server each time when it accesses
the BIMS server. The current interval will be updated by the newly obtained one. This
mechanism provides flexibility for management through BIMS.
12-10
H3C SecPath Series Security Products Chapter 13 RMON Configuration
Chapter 13 RMON Configuration
13.1 Introduction
Remote monitoring (RMON) is a kind of management information base (MIB) defined
by Internet Engineering Task Force (IETF); it is the most important enhancement to
MIB-II. RMON MIBs comprise sets of statistics data, analyzing data, and diagnostic
data. Unlike a standard MIB which only provides the raw data about the managed
objects for a port, RMON MIBs provide the statistics and resultant data about the entire
network segment. RMON thus allows you to monitor traffic over a network segment and
even the entire network.
RMON is implemented fully based on SNMP architecture, allowing for compatibility with
the current simple network management protocol (SNMP) framework.
RMON comprises two parts: network management system (NMS) and the agents
running on network devices. On the network monitor or probe for an interface, the
RMON agent monitors the traffic over the segment connected to the interface. It can
provide statistics about the traffic on the segment, such as the total number of packets
over a specified period, and the number of correct packets to a specific host.
RMON enables SNMP to monitor remote network devices more effectively and
proactively, increasing subnet monitoring efficiency. In addition, RMON decreases the
traffic between network management stations and agents, simplifying the management
of your network, especial when it is a large-scale internet.
RMON allows the presence of multiple managers. It provides two ways of data
collection:
z Using RMON probes. An NMS can obtain management information from RMON
probes directly and control the network resources. You can obtain all information
in the RMON MIB by using this method.
z Embedding RMON agents in network devices such as firewalls, routers, switches,
or Hubs to have them provide the RMON probe function. When collecting network
management information, RMON NMSs use basic SNMP commands to exchange
data with SNMP agents. The amount of information collected is limited by the
resources of network devices however. Instead of obtaining all data of RMON MIB,
RMON NMSs only collect four groups of information in most cases: alarm, event,
history, and statistics.
Comware implements RMON in the second way. Through the RMON-capable SNMP
agents on monitors, an NMS obtains information about the network segments
connected to the interfaces on the administered network devices, such as the overall
traffic, and statistics about errors and performance. Thus, it can administer the entire
network.
13-1
13.2 RMON Configuration
Note:
To allow an NMS to administer your firewall, you must configure SNMP Agent before
configuring RMON on the firewall. Then, you can retrieve alarms and logs about the
firewall on the NMS.
RMON configuration tasks are described in the following sections:

z Adding/Removing an Event Entry
z Adding/Removing an Alarm Entry
z Adding/Removing a History Control Entry
z Adding/Removing a Prialarm Entry
z Adding/Removing a Statistics Entry
13.2.1 Adding/Removing an Event Entry
You can set an event entry and specify the action taken when the event is triggered by
an alarm.
z Generate a log entry.
z Send a trap to the NMS.
z Generate a log entry and send a trap to the NMS.
Table 13-1 Add/remove an event entry
Operation Command
rmon event event-entry [description string ] { log |
Add an event entry trap trap-community | log-trap log-trapcommunity |
none } [ owner text]
Remove an event entry undo rmon event event-entry
13.2.2 Adding/Removing an Alarm Entry
The alarm group of RMON can monitor the specified alarm variables such as statistics
about an interface. When the value of the monitored variable exceeds the specified
threshold, an alarm is triggered. The alarm in turns triggers an event, which is defined
in the event group.
13-2
Note:
Before adding an alarm entry, you need to define its associated event with the rmon
event command.
Table 13-2 Add/remove an alarm entry
Operation Command
rmon alarm entry-number alarm-variable
sampling-time { delta | absolute } rising_threshold
Add an alarm entry
threshold-value1 event-entry1 falling_threshold
threshold-value2 event-entry2 [ owner text ]
Remove an alarm entry undo rmon alarm entry-number
After you set the alarm entry, the system does the following:
z Sample the defined alarm variables at the specified interval.
z Compare each sample with the thresholds: if the value of the sample exceeds the
rising threshold or is below the falling threshold, trigger the associated event.
13.2.3 Adding/Removing a Prialarm Entry
Prialarm entries can operate on the samples of the monitored variables according to
the defined calculating formula and compare the resultant values with the predefined
thresholds. You can thus obtain more alarm functions.
Note:
Before adding a prialarm entry, you need to define its associated event with the rmon
event command.
Table 13-3 Add/remove a prialarm entry
Operation Command
rmon prialarm entry-number prialarm-formula

prialarm-des sampling-timer { delta | absolute |
changeratio } rising_threshold threshold-value1
Add a prialarm entry
event-entry1 falling_threshold threshold-value2
event-entry2 entrytype { forever | cycle
cycle-period } [ owner text ]
13-3
Operation Command
Remove a prialarm entry undo rmon prialarm entry-number
After you set the alarm entry, the system does the following:
z Sample the defined alarm variables at the specified interval.
z Operate on each sample according to the defined calculating formula.
z Compare the result with the thresholds: if the value of the sample exceeds the
rising threshold or is below the falling threshold, trigger the associated event.
13.2.4 Adding/Removing a History Control Entry
The history group of RMON can collect historical data and periodically collect and save
data on interfaces, providing information such as utilization, number of errors, and total
number of packets for later retrieval.
Perform the following configuration in Ethernet interface view.
Table 13-4 Add/remove a history control entry
Operation Command
rmon history entry-number buckets
Add a history control entry number interval sampling-interval
[ owner text-string ]
Remove a history control entry undo rmon history entry-number
History control entries record periodic statistical samples. To view information about the
history table of RMON or a specified history entry, use the display rmon history
command.
13.2.5 Adding/Removing a Statistics Entry
The statistics group of RMON monitors the use of an interface and count the errors,
providing statistics about collision, CRC and queues, undersize and oversize packets,
timeout, fragments, broadcast, multicast, and unicast, and bandwidth utilization.
Table 13-5 Add/remove a statistics entry
Operation Command
Add a statistics entry rmon statistics entry-number [ owner text-string ]
Remove a statistics entry undo rmon statistics entry-number
13-4
A statistics entry holds the accumulative value since the corresponding event is defined.
You can check information about the statistics table of RMON or the specified statistics
entry with the display rmon statistics command.
13.2.6 Displaying and Debugging RMON
After completing the above configuration, you can execute the display command in
any view to display information about RMON’s statistics table, history control table,
alarm table, prialarm table, event table, and event table.
Table 13-6 Display and debug RMON
Operation Command
display rmon statistics [interface-type
Display the statistics table of RMON
interface-number]
Display the history control table of display rmon history [interface-type
RMON interface-number]
Display the alarm table of RMON display rmon alarm [ alarm-entry ]
display rmon prialarm

Display the prialarm table of RMON
[ prialarm-entry ]
Display the event table of RMON display rmon event [ event-entry ]
Display the log table of RMON display rmon eventlog [ event-entry ]
13.3 RMON Configuration Example

The firewall SecPath is connected to a console terminal through its console port and to
an NMS installed with Quidview system through Ethernet. You can view the operating
state of the firewall on the NMS.
Do the following:
z Set a RMON alarm entry, which can trigger two Trap events respectively when the
sample increment of the 1.3.6.1.2.1.16.1.1.1.4.1 node exceeds the rising and
falling threshold;
z Monitor the performance of the Ethernet interface;
z View the statistics about the monitored interface on the console terminal with the
display rmon statistics command.
13-5
II. Network diagram
Ethernet
e0/0/0:
129.1.1.100/24
Console
SecPath
NMS Console terminal
129.1.1.111/24
Figure 13-1 Network diagram for RMON
# Configure SNMP, using the same read/write community and version configured on
Quidview.
[H3C] snmp-agent
[H3C] snmp-agent sys-info version v1
[H3C] snmp-agent target-host trap address udp-domain 129.1.1.111 params
securityname secpath
# Configure a RMON alarm entry.

[H3C] rmon event 1 description rising trap gateway owner secpath-rmon
[H3C] rmon event 2 description falling trap gateway owner secpath-rmon
[H3C] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.4.1 5 delta rising_threshold 100 1
falling_threshold 50 2
# Assign an IP address to interface Ethernet 0/0/0.

[H3C-Ethernet0/0/0] ip address 129.1.1.100 255.255.255.0
# Set a RMON statistics entry for the Ethernet interface.

[H3C-Ethernet0/0/0] rmon statistics 1 owner secpath-rmon
[H3C-Ethernet0/0/0] quit
# Display information about RMON alarm entry 1 and statistics about the Ethernet
interface.
<H3C> display rmon alarm 1
<H3C> display rmon statistics ethernet 0/0/0
When the alarm event is triggered, you can find its record in the fault management
module of Quidview.
13-6
H3C SecPath Series Security Products Chapter 14 Terminal Services
Chapter 14 Terminal Services
14.1 Terminal Services Overview

System provides three types of terminal services entering the command line interface:
z Local configuration through the Console
z Local or remote configuration through AUX interface
z Local or remote configuration through Telnet or SSH.
14.2 Console Terminal Services

The local configuration environment can be set up through the Console. Refer to 2.1.1
“Setup through the Console Port” for the setup of local configuration environment.
For the characteristics of the Console terminal service, see the following table.
Table 14-1 Console terminal service characteristics
Service Characteristics
Echo mode Without local echo
Terminal type VT100
Baud rate 9600

Data bit 8
Parity check None
Stop bit 1 bit
Flow control None
Binary transport protocol XModem
14.3 Remote Terminal Services on AUX interface

14.3.1 Function Description
Besides performing the local configurations as the Console interface, the AUX interface
can also perform the remote configuration. Please refer to the former section for the
methods of local configuration. The remote terminal services will be described in this
section.
System supports remote configuration through the AUX interface. The serial interface
of PC and the AUX interface of the firewall are installed with Modems which are
connected through PSTN so that the user can establish the connection between PC
14-1
and the remote firewall by dial-up on the PC. After the dial-up is successful, the user
can set the working parameters of the remote firewalls through entering the
configuration commands on the terminal. The configuration environment is displayed in
Figure 14-1.
Terminal
Modem
SecPath
PSTN
Asynchronous
Serial interface
Modem
Figure 14-1 Establish remote configuration environment through AUX interface
14.3.2 Terminal Service Characteristics of the Remote Config on AUX Interface
System terminal service characteristics of the remote configuration are listed in the
following table.
Table 14-2 Terminal service characteristics of the remote configuration
Terminal type VT100
Baud rate Consistent with the interface configuration, 9600bps by default
Data bit Consistent with the interface configuration, 8bits by default
Parity check Consistent with the interface configuration, none by default
Stop bit Consistent with the interface configuration, 1 bit by default
Consistent with the interface configuration, hardware flow
Flow control
control by default
The terminal program running on PC should accord with parameters set in the above
table. The baud rate, data bit, parity check and flow control should be consistent with
the corresponding configurations on the AUX interface of the firewall.
14-2
14.4 Telnet Terminal Services

14.4.1 Telnet Service Types
The Telnet protocol belongs to application layer protocol in the TCP/IP protocol suite,
which provides the function of remote logon and virtual terminal through the network.
The Telnet services provided by system include:
I. Telnet Server
Telnet server services as shown in the following figure. The user can run the Telnet
client program on a computer to log on the firewall for configuration and management
of the firewall.
SecPath
Telnet Client
Figure 14-2 Provide the Telnet server services
Note:
When log in the firewall using Linux operating system, use <Backspace> to delete the
character next to the cursor; use <Ctrl + H> to delete the character followed by the
cursor.
II. Telnet Client
The Telnet client services as shown in the following figure. After setting up connection
with the firewall by running the terminal emulation program or the Telnet program on the
computer, the user can input the Telnet command to log on other firewalls for
configuration and management of them.
Telnet / terminal SecPath SecPath

(Telnet Client) (Telnet Server)
Figure 14-3 Provide the Telnet client services
Refer to the following table for the Telnet service characteristics of the system.
14-3
Table 14-3 Telnet service characteristics
Input mode Character mode
Terminal type VT100
14.4.2 Establishing Telnet Connection
I. Establishing a Telnet connection
Table 14-4 Establish Telnet connection
Operation Command
telnet host-ip-address [ service-port ]
Telnet to another firewall for
[ source-interface interface-type
management.
interface-number | source-ip ip-address ]
For example, a PC is connected to the console interface on the firewall SecPath1. You
may then use the following command to telnet to the firewall SecPath2 at 129.102.0.1.
<SecPath1> telnet 129.102.0.1
Trying 129.102.0.1 ...
Connected to 129.102.0.1 ...
<SecPath2>
II. Configuring idle timeout for a Telnet connection
Table 14-5 Configure idle timeout for the Telnet connection
Operation Command
Specify the amount of time that the
Telnet connection allowed to be idle.
Restore the default idle timeout. undo idle-timeout
The idle timeout for the Telnet connection defaults to 10 minutes.
III. Configuring source interface/address in a telnet
14-4
Table 14-6 Configure source interface/address in a telnet
Operation Command
Specify the source interface when telnet source-interface interface-type
connecting with the Telnet client interface-number
Remove the specified source interface. undo telnet source-interface
Specify the source IP address when
telnet source-ip source-address
connecting with the Telnet client
Remove the specified source IP
undo telnet source-ip
address.
When both source interface and source IP address are configured, the latter takes
effect.
Usually this command is used in conjunction with ACL. For example, if a loopback
interface is specified as the source interface at the telnet client, the source IP in the
Telnet connection is the main IP address of the loopback interface. Thus, the access
control policy configured at the Telnet server only involves one IP address.
Note:
The telnet source-ip and telnet source-interface commands are exclusive, and the
one configured later overrides the other.
14.4.3 Specifying a Source Interface/IP Address for the Telnet Server
Table 14-7 Specify a source interface or source IP address for the Telnet server
Operation Command
Specify a source interface for the Telnet telnet-server source-interface
undo telnet-server source-interface
the Telnet server
Specify a source IP address for the telnet-server source-ip
packets sent by the Telnet server source-address
Delete the source IP address for the
undo telnet-server source-ip
packets sent by the Telnet server
14-5
By default, the source IP address in each packet sent by the Telnet server is the IP
Note:
The telnet-server source-ip and telnet-server source-interface commands are
exclusive, and the one configured later overrides the other.
After completing the above configurations, execute the display commands in any view
to view information on Telnet and to verify effect of the configurations.
Execute the debugging command in user view to debug Telnet.
Table 14-8 Display and debug information on Telnet connections
Operation Command
Display the connection status of the
display users
current LINE
Display the connection status of each
display users all
LINE
Display all current established TCP
display tcp status
connections
Display the current source IP address of
display telnet-server source-ip
the Telnet server
display telnet source-ip
the Telnet client
Enable Telnet connection debugging. debugging telnet
Disable Telnet connection debugging. undo debugging telnet
The display users command can only be used to display which interface the Telnet
user in connection with the firewall has to pass. To check the IP address of the Telnet
server in connection with the firewall, execute the display tcp status command. All
TCP connections with the port number as 23 belong to Telnet connection, which include
the connection between the Telnet client and the Telnet server.
During Telnet connection, shortcut can be used to interrupt the connection. As shown in
following figure, through Telnet SecPath A connects to SecPath B, then connects to
SecPath C. In this way, a multileveled connection structure is formed. In this case,
SecPath A is the client of SecPath B and SecPath B is the client of SecPath C. The
structure simply illustrates the usage of shortcuts.
14-6
Figure 14-4 Use Telnet shortcuts
z Shortcut <Ctrl+]>
When the network connection is normal, to press <Ctrl+]> is to notify Telnet server to
interrupt the current Telnet login. Its effect is the same as the quit command, that is, the
server interrupts the connection initiatively. If the network is disconnected for some
reason, the instruction of the shortcut cannot be sent to the server, and the input is
invalid.
<SecPathC> (Press <Ctrl+]> and return to the prompt of SecPath B.)
<SecPathB> (Press <Ctrl+]> and return to the prompt of SecPath A.)
<SecPathA>
z Shortcut <Ctrl+K>
In the event that the server fails but the client cannot tell this, you will be unable to
receive any reply from the server for instructions that you input. You may however,
press <Ctrl+K> to disconnect and quit the Telnet connection:
<SecPathC> (Press <Ctrl+k> and interrupt the connection directly and return
to the device SecPathA initiating Telnet connection.
<SecPathA>
14.5 SSH Configuration

14.5.1 SSH Introduction
SSH is the abbreviation of secure shell. When the user telnets to the firewall through
one network environment not guaranteeing security, the SSH feature can provide
secure information guarantee and powerful authentication function to protect the
firewall from such attacks as IP address spoofing and the intercepting of plain text
password. As an SSH server, the firewall can accept connections of multiple SSH
clients; as an SSH client, the firewall can be connected to the firewall, router, UNIX host
which serves as the SSH server. Currently, the firewall supports SSH server with
version SSH 1.5 and SSH 2.0; SSH client with version SSH 2.0. As shown in Figure
14-5 and Figure 14-6, SSH channel can be established to build local connection and
WAN (Wide Area Network) connection.
14-7
Workstation
SecPath
Ethernet
Laptop
Server PC
Figure 14-5 Establish SSH channel in LAN
Workstation Local LAN

Ethernet
Router
Laptop WAN line

Serv er PC
Local PC running SSH WAN
Remote LAN
Workstation
Ethernet
SecPath
Laptop
PC
Serv er
Figure 14-6 Establish SSH channel through WAN
In the whole communication process, the server and client pass through the following
five steps to establish a security SSH connection:
1) Version number negotiation
z The client starts a TCP connection to the server.
z After the TCP connection is established, the server and the client negotiate a
version number.
z If the negotiation succeeds, the key algorithm negotiation phase starts; otherwise,
the server tears down the TCP connection.
2) Key algorithm negotiation
z The server generates an RSA key pair and an 8-byte random number, and sends
the public key portion of the key pair and the random number to the client.
14-8
z Both the server and the client use the public key of the server and the 8-byte
number as parameters to calculate a 16-byte session ID with the same algorithm.
z The client uses the public key from the server and a random number generated
locally as parameters to calculate a session key.
z Using the public key from the server, the client encrypts the random number
generated locally for session key calculation and sends the result to the server.
z Using the local private key, the server decrypts the data sent by the client and
obtains the random number generated by the client.
z Using the local public key and the random number sent by the client as
parameters, the server calculates the session key with the same algorithm used
by the client.
Thus, the server and the client obtain the same session key. During the session, both
ends use the same session key to perform encryption and decryption, thereby
guaranteeing the security of data transfer.
3) Authentication mode negotiation
z The client sends its username information to the server.
z The server initiates a process to authenticate the user. If the user needs no
authentication, the server proceeds to session request phase directly.
z The client adopts an authentication mode to authenticate the server till the
authentication succeeds or the server tears down the connection because of
timeout.
Note:
SSH provides two authentication modes: password and RSA.
1) Password authentication procedure
z The client sends the username and password to the server.
z The server compares the received username and password with the local
configuration. If it finds an exact match, the authentication succeeds.
2) RSA authentication procedure
z The server configures the RSA public key of the client.
z The client sends its RSA public key member modulo to the server.
z The server verifies the member modulo. If the member modulo is valid, the server
generates a random number, encrypts it using the RSA public key from the client,
and sends the encrypted information back to the client.
z The server and the client use the random number and the session ID as parameters
to calculate authentication data.
z The client sends the authentication data it generated to the server.
z The server compares the received authentication data with that locally calculated. If
they match, the authentication succeeds.
14-9
4) Session request:
If the authentication succeeds, the client sends a session request to the server. When
the server has successfully processed the request, SSH enters the interactive session
phase.
5) Interactive session:
The client and the server exchange data until the session is over.
Caution:
When the firewall serves as SSH server, and the SecureCRT as client software, you
cannot log on the SSH server normally if the client end is configured with “Enable
OpenSSH agent forwarding”.
14.5.2 SSH Server Configuration
SSH server configuration includes:

z Set the protocols supported by system in user interface
z Configure local RSA key pair
z Configure authentication mode for SSH user
z Set the update time of server key
z Set the time-out time of SSH authentication
z Set the re-try times of SSH authentication
z Enter public key view
z Enter public key edit view to edit the key
z Quit public key edit view
z Assign public key for SSH user
z Configure a service type for an SSH user
z Set SSH version compatibility (optional)
z Specify a source interface or source IP address for the SSH server
I. Setting the protocols supported by system in user interface
This configuration is used to specify the protocols supported by the system in user
interface view. By default, the system supports Telnet and SSH. If SSH is enabled but
the local RSA key is not configured, the user cannot login through SSH. The
configuration will take effect in next login.
Perform the following configuration in user interface view of VTY type.
14-10
Table 14-9 Set the protocols supported by system in user interface
Operation Command
Set the protocols supported by system in
protocol inbound { all | ssh | telnet }
user interface
Caution:
If the protocol supported by the user interface is set to SSH, you must set the
authentication mode to authentication-mode scheme to ensure a successful login; if
you use authentication-mode password or authentication-mode none, the
configuration of the protocol inbound ssh command fails. Likewise, an SSH-enabled
user interface does not allow the configuration of authentication-mode password or
authentication-mode none.
II. Configuring local RSA key pair
This configuration is used to generate the local server and host key pair. If there has
been RSA now, the system will ask whether to replace the former key. The naming
modes of generated key pairs go as follows respectively: firewall name +server and
firewall name +host. The server key differs in 128 digits at least from host key. The
minimum length of server and host key is 512 bits and the maximum length is 2048 bits.
Table 14-10 Configure and remove local RSA key pair
Operation Command
Generate local RSA key pair rsa local-key-pair create
Remove local RSA key pair rsa local-key-pair destroy
14-11
Caution:
z The primary operation to accomplish SSH login is to configure and generate local
RSA key pair. Before performing other SSH configurations, you must accomplish
the configuration of the rsa local-key-pair create command to generate local key
pair. It is necessary to execute this command only once and it is unnecessary to
execute again after the firewall resets.
z When the SecPath firewall serves as both server and client, the key pair generated
by executing this command at the server side should be at least 768 bits. If the RSA
authentication is needed for the client when the firewall serves as SSH2.0 server,
the key pair generated at the client side should be at least 768 bits.
III. Configuring authentication mode for SSH user
This configuration is used to specify the authentication mode for SSH user. The new
configured authentication mode will take effect in the next login.
Table 14-11 Configure authentication mode for SSH user
Operation Command
ssh user username
Configure authentication mode for SSH
authentication-type { password | RSA
users
| all }
Restore the default system
undo ssh user username
authentication mode that login will be
authentication-type
denied always.
ssh authentication-type default

Specify a default authentication mode
{ password | rsa | all |
for SSH users
password-publickey }
Clear the default authentication mode undo ssh authentication-type default
The differences between the above two commands are:

ssh user username authentication-type command is used to configure an
authentication mode for a user, while ssh authentication-type default command is
used to configure the default authentication mode for all users.
When these two commands are executed at the same time, and the authentication
modes are different, the ssh user username authentication-type command applies.
14-12
Note:
The username parameter should be consistent with the valid username defined by AAA
during password authentication configuration; when you configure RSA authentication,
the parameter is SSH user name, and you do not need to configure the local user in
AAA.
IV. Adding an SSH user
When the default authentication mode is specified by executing ssh

authentication-type default command, you can use the ssh user command to add an
SSH user. The authentication mode of the user is the default authentication mode.
Table 14-12 Add an SSH user
Operation Command
Add an SSH user ssh user username
Delete an SSH user undo ssh user username
Note:
The username parameter should be consistent with the valid username defined by AAA
during password authentication configuration; when you configure RSA authentication,
the parameter is SSH local user name, and you do not need to configure the local user
in AAA.
When the default authentication mode is password, and using AAA local authentication,
you need to execute local-user command to set the username and password in the
local database. In this case, you can log onto the SSH server directly by inputting the
username and password specified by local-user command. (Configure the
service-type to ssh). Thus you do not need to use the ssh user command.
V. Setting the update time of server key
This configuration is used to set the update time of server key to ensure the security of
SSH connection farthest.
14-13
Table 14-13 Set update time of server key
Operation Command
Set the update time of server key ssh server rekey-interval hours
Restore the default update time undo ssh server rekey-interval
By default, the server key is not updated.
VI. Setting the time-out time of SSH authentication
This configuration is used to set the time-out time of SSH authentication.

Table 14-14 Set the time-out time of SSH authentication
Operation Command
Set the time-out time of SSH
ssh server timeout seconds
authentication
Restore the default time-out time of SSH
undo ssh server timeout
authentication
By default, the time-out time is 60 seconds.
VII. Setting the re-try times of SSH authentication
This configuration is used to set re-try times of authentication for SSH user request for
connection to prevent from such illegal operation as malicious guess.
Table 14-15 Set the re-try times of SSH authentication
Operation Command
Set the re-try times of SSH ssh server authentication-retries
authentication times
Restore default re-try times of SSH undo ssh server
authentication authentication-retries
By default, the re-try times are 3.
VIII. Entering public key chain view
This configuration is used to enter the public key view to configure the client key. At that
time, the client key is generated by client software supporting SSH1.5 in stochastic
mode.
14-14
Table 14-16 Public key configuration
Operation Command
Enter public key chain view rsa peer-public-key key-name
Return to system view from public key
peer-public-key end
view
IX. Entering public key edit mode to edit the key
This configuration is used to enter public key edit view and input public key data that
must be generated by client software. Before editing public key, you must specify one
key name with the rsa peer-public-key command in public key chain view.
When the key data are input, the space can exist between characters and you can
press enter key to continue the data input. The public key configured must be the hex
character string coded according to public key format.
Perform the following configuration in public key view.
Table 14-17 Edit public key
Operation Command
Enter public key edit mode public-key-code begin
X. Quitting public key edit mode
This configuration is used to quit public key edit view to public key view and save the
input key data.
Perform the following configuration in public key edit view.
Table 14-18 Quit public key edit mode
Operation Command
Quit public key edit mode public-key-code end
XI. Assigning public key for SSH user
This configuration is used to assign one existing public key for the SSH user.
Table 14-19 Assign public key for SSH user
Operation Command
ssh user username assign rsa-key
Assign public key for SSH user
keyname
14-15
Operation Command
Delete the corresponding relationship undo ssh user username assign
between the user and public key rsa-key
XII. Configuring a service type for an SSH user
Perform the following configuration in system view to configure a service type for an
SSH user.
Table 14-20 Configure a service type for an SSH user
Operation Command
Configure a service type for an SSH ssh user username service-type
user { stelnet | sftp | all }
Restore the default service type for an
undo ssh user username service-type
SSH user
The default service type for an SSH user is stelnet.
XIII. Setting SSH version compatibility
Perform the following configuration in system view to enable/disable the SSH server to
work with SSH1.X clients.
Table 14-21 Enable/disable the SSH server to work with SSH1.X clients
Operation Command
Enable the SSH server to work with
ssh server compatible-ssh1x enable
SSH1.X clients
Disable the SSH server to work with
undo ssh server compatible-ssh1x
SSH1.X clients
By default, the SSH server does not work with SSH1.X clients.
XIV. Specifying a source interface/IP address for the SSH server
Table 14-22 Specify a source interface or source IP address for the SSH server
Operation Command
Specify a source interface for the SSH ssh-server source-interface
14-16
Operation Command
undo ssh-server source-interface
the SSH server
ssh-server source-ip ip-address
packets sent by the SSH server
undo ssh-server source-ip
packets sent by the SSH server
By default, the source IP address in each packet sent by the SSH server is the IP
Note:
You may specify a source IP address for the packets sent by the Telnet server with the
ssh-server source-interface command or with the ssh-server source-ip command.
If both commands are configured, the one configured later overrides.
14.5.3 SSH Client Configuration
SSH server configuration includes:

z Enable the SSH client
z Configure public key to server associations
z Configure SSH server first-time authentication
z Specify a source interface/IP address for the SSH client
I. Enabling the SSH client
When enabling the SSH client to SSH to the server, you need to specify the preferred
key exchange algorithm, encryption algorithm and HMAC algorithm between the client
and the server.
Table 14-23 Enable the SSH client
Operation Command
ssh2 { host-ip | host-name } [ port-num ] [ prefer_kex
{ dh_group1 | dh_exchange_group } ] [ prefer_ctos_cipher
Enable the SSH { des | 3des | aes128 } ] [ prefer_stoc_cipher { des | 3des |
client aes128 } ] [ prefer_ctos_hmac { sha1 | sha1_96 | md5 |
md5_96 } ] [ prefer_stoc_hmac { sha1 | sha1_96 | md5 |
md5_96 } ]
14-17
II. Configuring public key to server associations
You need to associate an SSH server with the name assigned to its public key. When
connecting to this server, the client verifies its trustworthiness based on this
association.
Table 14-24 Associate an SSH server with a public key
Operation Command
Associate an SSH server with its public ssh client server assign rsa-key
key keyname
Remove an SSH server to public key undo ssh client server assign rsa-key
association keyname
III. Configuring SSH server first-time authentication
The configuration of first-time authentication decides the action taken by the SSH client
when it accesses a server in the absence of the server’s public key:
z With first-time authentication enabled, the SSH client can attempt to access the
server and get the server’s public key through negotiation. Then this public key
could be saved on the client for next access.
z With first-time authentication disabled, the SSH client rejects to access a server.
To access the server, you must save its public key on the SSH client beforehand.
Table 14-25 Configure first-time authentication
Operation Command
Enable SSH server first-time authentication ssh client first-time enable
Disable SSH server first-time authentication undo ssh client first-time
By default, first-time authentication is enabled on the SSH client.
IV. Specifying a source interface/IP address for the SSH client
14-18
Table 14-26 Specify a source interface or source IP address for the SSH client
Operation Command
Specify a source interface for the SSH ssh2 source-interface interface-type
client server interface-number
undo ssh2 source-interface
the SSH client
ssh2 source-ip ip-address
packets sent by the SSH client
undo ssh2 source-ip
packets sent by the SSH client
By default, the source IP address in each packet sent by the SSH client is the IP
Note:
You may specify a source IP address for the packets sent by the SSH client with the
ssh2 source-interface command or with the ssh2 source-ip command. If both
commands are configured, the one configured later overrides.
After the above configuration, execute display command in any view to display the
running of the SSH configuration, and to verify the effect of the configuration.
You can debug SSH by executing debugging command in user view.
The task of displaying and debugging SSH is used to view the configuration of various
SSH users to utilize the system resource better and accomplish the secure information
connection.
Execute the following display command in any view.
Execute the following debugging command in user view.
Table 14-27 View relevant information about SSH
Operation Command
View the pubic key of host and server
display rsa local-key-pair public
key pair
display rsa peer-public-key [ brief |
Display the RSA public key of client
name keyname ]
14-19
Operation Command
Display SSH status information and
display ssh server { status | session }
session information
display ssh user-information
Display SSH user information
[ username ]
Display SSH server information display ssh server-info
display ssh-server source-ip
the SSH server
display ssh2 source-ip
the SSH client
Execute the debugging command in user view.
Table 14-28 Debug information on SSH
Operation Command
Enable the debugging of SSH server debugging ssh server { vty index | all }
undo debugging ssh server { vty
Disable the debugging of SSH server
index | all }
Enable the debugging of SSH client debugging ssh client
Disable the debugging of SSH client undo debugging ssh client
14.5.5 SSH Server Configuration Example
The console terminal (the SSH client) is directly connected to the firewall through an
Ethernet interface. Run SSH1.5-supported client software on the terminal for securely
logging onto the firewall for configuration and management. The username of the SSH
client is client001 and the password is pwd.
II. Network diagram
ethernet:169.254.0.5 ethernet:169.254.0.1
SSH Client
SecPath
Figure 14-7 Network diagram for SSH local configuration
14-20

The following introduces the different configuration steps respectively according to
authentication mode of login. But the following operation must be performed first before
starting any one kind of configuration:
[H3C] rsa local-key-pair create
Note:
If there exist local key pairs, you can skip this step.
z Set the authentication method for SSH user to password.

[H3C-ui-vty0-4] authentication-mode scheme
[H3C-ui-vty0-4] protocol inbound ssh
[H3C-ui-vty0-4] quit
[H3C] local-user client001
[H3C-luser-client001] password simple pwd
[H3C-luser-client001] service-type ssh
[H3C-luser-client001] quit
[H3C] ssh user client001 authentication-type password
The default value for authentication time-out time, re-try times and update time of
server key of SSH can be adopted. After these configurations, you can run the client
software supporting SSH1.5 on other terminals connected to firewall. You can access
the firewall with username client001 and password pwd.
z Set the authentication method for SSH user to RSA.
[H3C-ui-vty0-4] protocol inbound ssh
[H3C-ui-vty0-4] quit
[H3C] ssh user client002 authentication-type RSA
Then, use the SSH1.5 client software to randomly generate the RSA key pairs
(including public and private keys) and synchronize the public key to the specified rsa
peer-public-key on the SSH server. The RSA public key discussed here is a
hexadecimal string coded using the software SSHKEY.EXE provided by our company
according to the PKCS standard.
[H3C] rsa peer-public-key secpath002
[H3C-rsa-public] public-key-code begin
[H3C-key-code] 308186028180739A291ABDA704F5D93DC8FDF84C427463
14-21
[H3C-key-code] 1991C164B0DF178C55FA833591C7D47D5381D09CE82913
[H3C-key-code] D7EDF9C08511D83CA4ED2B30B809808EB0D1F52D045DE4
[H3C-key-code] 0861B74A0E135523CCD74CAC61F8E58C452B2F3F2DA0DC
[H3C-key-code] C48E3306367FE187BDD944018B3B69F3CBB0A573202C16
[H3C-key-code] BB2FC1ACF3EC8F828D55A36F1CDDC4BB45504F020125
[H3C-key-code] public-key-code end
[H3C-rsa-public] public-key-code end
[H3C] ssh user client002 assign rsa-key secpath002
2) Configure the SSH client
z When password authentication applies, you need to specify at the client the IP
address of a reachable interface on the SSH server or the firewall, 169.254.0.1 in
this example, set the protocol type to SSH, use SSH version 1. After opening the
SSH connection, enter the user name and password to access the firewall
configuration interface.
login as: client001
Sent username "client001"
client001@169.254.0.1's password:
**************************************************************************
* Copyright(c) 2004-2007 Hangzhou H3C Technologies Co., Ltd. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
**************************************************************************
<H3C>
z When RSA authentication applies, you must specify an RSA private key file, which
is generated randomly by the client software in addition to the configuration tasks
done with password authentication. After opening the SSH connection, enter the
user name to access the firewall configuration interface.
login as: client002
Sent username "client002"
Trying public key authentication.
No passphrase required.
**************************************************************************
**************************************************************************
<H3C>
14-22
14.5.6 SSH Client Configuration Example
SecPathB is working as the SSH client with user name client003.

SecPathA is working as the SSH server with IP address 10.165.87.136.
II. Network diagram
SecPathA
SSH Server
10.165.87.136
SecPathB
SSH Client
PC
Figure 14-8 Network diagram for SSH client configuration
1) Configure the SSH server (SecPathA)

Refer to the configuration procedure in section 14.5.5 “SSH Server Configuration
Example”.
2) Configure the SSH client (SecPathB)
# Enable SSH server first-time authentication.
[H3C] ssh client first-time enable
# Enable the SSH client.

The configuration varies depending on the adopted authentication mode.
z When password authentication and the default algorithms are adopted, do the
following:
[H3C] ssh2 10.165.87.136
Username: client003
Trying 10.165.87.136
Press CTRL+K to abort
Connected to 10.165.87.136...
The Server is not authenticated.Do you continue access it?(Y/N):y
Do you want to save the server's public key?(Y/N):y
14-23
Enter password:
**************************************************************************
**************************************************************************
<H3C>
z When RSA authentication is adopted, do the following:
[H3C] ssh2 10.165.87.136 22 perfer_kex dh_group1 perfer_ctos_cipher des
perfer_stoc_cipher 3des perfer_ctos_hmac md5 perfer_stoc_hmac md5
Please input the username: client003
Trying 10.165.87.136...
Press CTRL+K to abort
Connected to 10.165.87.136...
The Server is not authenticated.Do you continue access it?(Y/N):y
Do you want to save the server's public key?(Y/N):y
**************************************************************************
**************************************************************************
<H3C>
14.6 SFTP Service

14.6.1 Introduction to SFTP
Secure FTP (SFTP) is a new feature introduced in SSH 2.0.

SFTP is established on SSH connections to provide secured data transfer.
Your firewall may work as both SFTP server and client. As an SFTP server, it allows a
remote user to securely log onto it to manage and transfer files for example, when
upgrading the system. As an SFTP client, it allows you to securely log onto another
device to transfer files.
14.6.2 Configuring the SFTP Server
The following table describes the SFTP server configuration tasks:
14-24
Table 14-29 Configure the SFTP server
Use the
No. To do… View Remarks
command…
ssh user username
Configure a service type
1 service-type System view Optional
for an SSH user
{ stelnet | sftp | all }
2 Enable the SFTP server sftp server enable System view Required
I. Configuring a service type for a user
Perform the following configuration in system view to set a service type for an SSH
user.
Table 14-30 Set a service type for an SSH user
Operation Command
ssh user username service-type
Set a service type for an SSH user
undo ssh user username service-type

Restore the default service type
The default service type for an SSH user is stelnet.
II. Enabling the SFTP server
Table 14-31 Enable the SFTP server
Operation Command
Enable the SFTP server sftp server enable
Disable the SFTP server undo sftp server
By default, the SFTP server is disabled.
Note:
The SFTP server of the firewall supports PSFTP client with PuTTY as the third-party
software.
14-25
14.6.3 Configuring the SFTP Client
The following table describes the SFTP client configuration tasks:
Table 14-32 Configure the SFTP client
No. To do… Use the command… In… view Remarks

SFTP
1 Enable the SFTP client sftp Required
client view
bye
System
2 Disable the SFTP client exit Optional
view
quit
Change the
current cd
directory
Exit to the
upper cdup
directory
Display the
Directory- current pwd
directory SFTP
3 related Optional
operations Display the client view
dir
with SFTP list of the
files in a
directory ls
Create a
new mkdir
directory
Delete a
rmdir
directory
14-26
No. To do… Use the command… In… view Remarks

Rename a
file on the
rename
SFTP
server
Download a
file from the
remote get
SFTP
server
File- Upload a file
related from the SFTP
4 Optional
operations remote put client view
with SFTP SFTP
server
Display the dir
list of the
files in a
ls
directory
Delete a file delete
from the
SFTP
remove
server
Get help information about SFTP
5 help Optional
SFTP client commands client view
I. Enabling the SFTP client
To log onto and operate on an SFTP server, enable the SFTP client and enter SFTP
client view.
Table 14-33 Enable the SFTP client
Operation Command
sftp { host-ip | host-name } [ port-num ] [ prefer_kex
{ dh_group1 | dh_exchange_group } ]
[ prefer_ctos_cipher { des | 3des | aes128 } ]
Enable the SFTP client [ prefer_stoc_cipher { des | 3des | aes128 } ]
[ prefer_ctos_hmac { sha1 | sha1_96 | md5 |
md5_96 } ] [ prefer_stoc_hmac { sha1 | sha1_96 |
md5 | md5_96 } ]
II. Disabling the SFTP client
Execute the following command in SFTP view to disable the SFTP client.
14-27
Table 14-34 Disable the SFTP client
Operation Command
bye
Disable the SFTP client exit
quit
III. Operating with SFTP directories
Execute the following commands in SFTP client view.
Table 14-35 Operate with SFTP directories
Operation Command
Change the current directory cd remote-path
Exit to the upper directory cdup
Display the current directory pwd
dir [ remote-path ]
Display the list of the files in a directory
ls [ remote-path ]
Create a directory on the SFTP server mkdir remote-path
Delete a directory from the SFTP server rmdir remote-path
IV. Operating with files
Execute the following command in SFTP client view.
Table 14-36 Operate with SFTP files
Operation Command
Change the name of a file on the remote
rename old-name new-name
SFTP server
Download a file from the remote SFTP server get remote-file [ local-file ]
Upload a file to the remote SFTP server put local-file [ remote-file ]

dir [ remote-path ]
Display the list of the files in a directory
ls [ remote-path ]
delete remote-file
Delete a file from the SFTP server
remove remote-file
14-28
V. Specifying a source interface/IP address for the SFTP client
Table 14-37 Specify a source interface or source IP address for the SFTP client
Operation Command
Specify a source interface for the SFTP sftp source-interface interface-type
undo sftp source-interface
the SFTP client
sftp source-ip ip-address
packets sent by the SFTP client
undo sftp source-ip
packets sent by the SFTP client
By default, the source IP address in each packet sent by the SFTP client is the IP
Note:
You may specify a source IP address for the packets sent by the Telnet server with the
sftp source-interface command or with the sftp source-ip command. If both
commands are configured, the one configured later overrides.
VI. Displaying help information
Execute the following command in SFTP client view to get help information about SFTP
client commands.
Table 14-38 Display help information about SFTP client commands
Operation Command
Display help information about SFTP
help [ command-name ]
client commands
14.6.4 SFTP Configuration Example
As shown in Figure 14-9.

z An SSH connection is present between SecPathA and SecPathB.
14-29
z Use SecPathA as an SFTP server with IP address 10.111.27.91.

z Use SecPathB as an SFTP client.
z Create an SSH user account ftpuser with password pwd.
II. Network diagram
SecPathB
SFTP Server
IP address ： 10.111.27.91
SecPathA
SFTP Client
PC
Figure 14-9 Network diagram for SFTP
1) Configure SecPathB (the SFTP server)

# Enable the SFTP server.
[H3C] sftp server enable
# Specify SFTP service for SSH user ftpuser.

[H3C] ssh user ftpuser service-type sftp
2) Configure SecPathA (the SFTP client)
# Establish a connection to the SFTP server and enter SFTP client view.
[H3C] sftp 10.111.27.91
# Display the current directory on the SFTP server, delete file z and verify the operation.
sftp-client> dir
-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg
-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2
drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new
-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub
-rwxrwxrwx 1 noone nogroup 0 Sep 01 08:00 z
sftp-client> delete z
Remove this File?(Y/N)
flash:/zy
14-30
File successfully Removed

sftp-client> dir
# Create directory new1 and verify the operation.

sftp-client> mkdir new1
New path created
sftp-client> dir
drwxrwxrwx 1 noone nogroup 0 Sep 02 06:30 new1
# Change the name of directory new1 to new2 and verify the operation.
sftp-client> rename new1 new2
sftp-client> dir
# Download file pubkey2 and rename it to pu.

sftp-client> get pubkey2 pu
Downloading file successfully ended
# Upload file pu to the SFTP server and rename it to puk. Verify the operations.
sftp-client> put pu puk
Uploading file successfully ended
sftp-client> dir
-rwxrwxrwx 1 noone nogroup 283 Sep 02 06:35 pu
-rwxrwxrwx 1 noone nogroup 283 Sep 02 06:36 puk
14-31
sftp-client>
# Disconnect from the SFTP server.

sftp-client> quit
Bye
<H3C>
14.7 Dumb Terminal Service

14.7.1 Description on Dumb Terminal Functions
When the asynchronous interface (e.g. sync/asynchronous interface, AUX interface or

8-asynchronous interface) of the firewall works in flow mode, you can directly connect it
with the serial interface of the computer (or terminal) to enter the command-line
interface and to configure the firewall, this mode is called dumb terminal working mode.
You can establish other applications based on dumb terminal, for example, executing
the Telnet to log in to other devices.
A user can log in to and manage the firewall by running the super-terminal on his/her
PC to connect with the asynchronous interface on a firewall, as shown inTable 14-10.
RS-232 serial port
SecPath
PC
AUX
Figure 14-10 Dumb terminal connection mode
14.7.2 Dumb Terminal Service Features
See Table 14-2. They are consistent with those of remote terminal service.
14.7.3 Typical Application of Dumb Terminal
Typical applications:
z In flow mode, the asynchronous interface is connected via the dedicated line to
directly enter the command-line interface of a firewall. This application provides
another terminal service except Console port and Telnet.
z In flow mode, the asynchronous interface directly logs in to the command-line
interface of a firewall via the async dedicated line, and then boots Telnet client
program to log in to other remote systems.
14-32
14.7.4 Configuring Dumb Terminal Service
The following table shows the configuration commands related to dumb terminal.
Perform the configurations of the async mode command in interface view, and of the
auto-execute command command in user interface view.
Table 14-39 Related commands for establishing dumb terminal connection
Operation Command
Set the asynchronous interface to work
async mode flow
in flow mode
Disable the asynchronous interface to
async mode protocol
work in flow mode
Auto-execute the configuration
command on the asynchronous auto-execute command command
interface
Disable to auto-execute the
configuration command on the undo auto-execute command
asynchronous interface
I. Dumb terminal configuration
# Configure the asynchronous interface connected with the terminal.

Configure AUX interface as follows:
[H3C-ui-aux0] undo modem
[H3C-Aux0] async mode flow
After the above operations, press <Enter> on the external terminal of the asynchronous
interface to enter the configuration interface of the firewall. During the configuration, if
you execute quit to exit from the command-line interface and want to enter again, you
must press <Enter>.
Note:
Set the asynchronous interface to disable Modem dial-in in the relevant user interface
view. For more details, see the User Interface Configuration chapter.
II. auto-execute command configuration
If the asynchronous interface of the firewall is configured with the auto-execute

command command, and a user presses <Enter> on its external terminal, the firewall
will automatically execute some commands to directly enter the operating state.
There are some restrictions in using the auto-execute command command.
14-33
z If the firewall has only one Console port or AUX interface (Console port and AUX
interface share one port), the port will not support the auto-execute command
command.
z If the firewall has one Console and one AUX interface (two ports), the former will
not support the auto-execute command command, while the latter will support it.
z No restriction on other types of interfaces.
The system will automatically execute a certain command configured by the
auto-execute command command on the terminal at login, and disconnect user
connection after the command terminates. In practice, Telnet is configured by the
auto-execute command command on the terminal to enable a user to automatically
connect to the specified host. Using the command will result in disabling the terminal to
configure the system. Be cautious in use.
Caution:
Before configuring the auto-execute command command and saving its configuration
(execute save), make sure that you can log in to the system to change this
configuration back by other means.
The most typical application of the auto-execute command command is that after a
user establishes connection with the firewall via dumb terminal mode, he/she can
remotely log in to other firewalls via the Telnet specified by the auto-execute
command. In this way, the firewall is transparent to the end user, as shown in the
following figure:
10.110.164.45
SCO UNIX Workstation

Ethernet
10.110.164.44
SecPath
PC
Figure 14-11 auto-execute command configuration diagram
Configuration procedure is as follows:
14-34
# Configure the AUX interface to work in dumb terminal mode, see the configuration in
the preceding section.
# Configure the auto-execute command command.
In user interface view, enter:
[H3C-ui] auto-execute command telnet 10.110.164.45
After configuration, press <Enter> on the terminal connected with the AUX interface of
the firewall to log in to the destination host. If you want to log in again after exiting, press
<Enter>.
Note:
To cancel the auto-execute command function, execute the undo auto-execute
command command in the relevant user interface view.
14.7.5 Timely Disconnecting Dumb Terminals
Table 14-40 Timely disconnect the dumb terminal
Operation Command
Enable timely disconnecting dumb
terminal connection
Restore its default value undo idle-timeout
If a user has set the idle-timeout and does not receive the entry from a dumb terminal
user within this time, the system will disconnect this connection to prevent the illegal
intrusion of unauthorized users after 10 minutes. If a user executes the idle-timeout 0
command to disable this function in the relevant user interface view, dumb terminal
users will not be disconnected all the time.
# Disable timely disconnecting dumb terminal connection.
[H3C-ui-aux0] idle-timeout 0
14-35
H3C SecPath Series Security Products Chapter 15 Modem Configuration
Chapter 15 Modem Configuration
15.1 Overview of Modem

15.1.1 Modem Functions Provided by Comware
Modem is a network device that is widely used. It is important for a firewall to properly
manage and control the use of modem in a network. However, there are many modem
manufacturers and various modem models. Even though all of them support the AT
command set and are compliant with the industry standard, each type of modem differs
somewhat on the implementations and command details.
To offer the optimal flexibility, SecPath series Firewalls:
1) Provide the scripts (hereinafter refer to as modem script) for modem management,
hence to enable the user to well control the modems connected to the firewall. A
modem script can be executed by the following two means:
z Execute a modem script directly through the start-string command to initialize the
modem or other configurations.
z Trigger the modem script with some special events, such as firewall startup,
modem dial-in connection, etc.
2) Use the script along with the related commands can enhance the remote
configuration function of firewall. If the asynchronous interface works in flow mode,
the user can establish a remote connection to the interface via the dumb terminal
or modem dialup, so as to configure and administer the firewall.
3) Intercommunicate with the equipment of other vendors. The asynchronous
interfaces of the participating parties are working in flow mode interconnected via
modems.
4) Provide rich debugging information for modem maintenance and monitoring.
15.1.2 Modem Script
I. Usage of Modem script
SecPath series Firewalls provide the modem scripts for:

z Flexibly controlling the modems of different models. For example, using different
initialization AT command strings can make the modems of different
manufacturers or models to better interoperate with the SecPath series Firewalls.
z Implementing the interactive login to remote systems. Interactive negotiation of
the scripts can enable the system enters different link states. For example, after
the asynchronous interfaces on the two firewalls set up a connection via the
modem, the firewalls can negotiate the protocol to be encapsulated with the
physical link and its operating parameters.
15-1
II. Syntax description of modem script
The modem script format in common use is as follow:

receive-string1 send-string1 receive-string2 send-string2......
Where:
z Normally, receive-string and send-string appear in pairs, and the script must begin
with a receive-string. For example, “receive-string1 send-string1” represents the
execution flow: Expect to receive receive-string1, and send send-string1 to the
modem if the received string matches receive-string1 before timing out. Otherwise,
the execution of the subsequent script will be terminated.
z If the last string is a send-string, it indicates that the execution of the script will be
terminated after the string is sent without waiting for any receive-string.
z If it is unnecessary to receive a string at the beginning of a script, and the system
can directly wait for the send-string, then the user can set the first receive string to
"", which will be explained later.
z Except for ending with “\c”, the send-string will be automatically added with an
additional return character to its end when it is sent.
z A receive-string is matched via the location-independent matching method. That is,
the match is considered successful as long as the received contents contain the
expected string.
z The match operation on a receive-string will be considered successful if the
receive-string is matched with any expected receive-strings which are separated
with “-“.
z By default, the timer times out five seconds later while waiting for a receive-string.
TIMEOUT seconds can be inserted into the script at anytime to adjust the timeout
time waiting for the receive-string, which is valid till a new TIMEOUT is set in the
same script.
z All the strings and keywords in a script are case sensitive.
z Both the strings and keywords are separated by spaces. If a space is contained in
a string, it should be put in the double quotation marks (" "). A pair of empty
quotation marks (that is, "") has two meanings. Being a leading "" in a script, it
means that no string is expected from the modem and the system will directly send
the strings to the modem. If "" locates in any other locations, the string content will
be regarded to be "".
z ABORT receive-string can be inserted at any point in a script to change the script
execution flow. Its presence in the script indicates that the script execution will be
terminated if a received string is fully matched the receive-string set by ABORT
receive-string. Multiple ABORT entries can be defined in a script, and they will
take effect concurrently. Once a received string matches any of them, the script
execution will be terminated. Regardless of where the ABORT receive-string is
placed, it will take effect in the whole script execution process.
15-2
z Escape characters can be inserted in a script for the purpose of better controlling
the script and increasing its flexibility. In addition, all the escape characters also
play the role of delimiters in the string as well.
Table 15-1 Script keywords
Keyword Description
The string following ABORT will be compared with the
strings sent from a modems or remote DTE device for a
ABORT receive-string match. The match mode is full match. Multiple ABORT
entries can be configured for a script, and all of them take
effect in the whole script execution period.
The digit following TIMEOUT is used to set the timeout
interval that the device waits for receiving strings. If no
TIMEOUT seconds expected strings are received within the interval, the
execution of the script will be failed. Once being set, the
setting will be valid till a new TIMEOUT is set.
In which, seconds defaults to 180 and is in the range of 0 to 180.
Table 15-2 Script escape characters
Escape
Description
character
It means that only the specified string can be sent and the character
\c "Enter" will not be sent. The character of "\c" must be at the end of the
sending strings. Otherwise, it is invalid at other location.
\d Represents pausing 2 seconds.
\n Represents the character "new line".
\r Represents the character "Enter".
\s Represents the character "Space".
\t Represents the character "Tab".
\\ Represents the character "\".
\T Represents telephone number.
15.2 Modem Configuration

Modem Configuration includes to:
z Configure the modem dial-in and dial-out permission
z Configure a modem script
z Execute the modem script manually
z Configure modem answer mode
15-3
15.2.1 Configuring Modem Call-In and Call-Out
Table 15-3 Configure modem call-in and call-out
Operation Command
Enable modem call-in or call-out. modem [ call-in | call-out ]
Enable modem call-in and call-out. modem both
Disable modem call-in and call-out. undo modem both
Disable modem call-in or call-out. undo modem [ call-in | call-out ]
By default, modem call-in and call-out are denied.
Note:
When enabling the modem, the undo detect dsr-dtr command is disabled
automatically by the system. When executing the undo detect dsr-dtr command, the
modem is disabled automatically.
15.2.2 Configuring a Modem Script
Table 15-4 Configure a modem script
Operation Command
Define a modem script script-string script-name script-content
Delete the modem script undo script-string script-name
For the format of script, refer to the modem script syntax description.
15.2.3 Executing a Modem Script Manually
When necessary, you can use the start-script command to execute the designated
modem script to manage the external modem connected to the interface.
15-4
Table 15-5 Execute modem script manually
Operation Command
Execute modem script manually start-script script-name number
15.2.4 Configuring the Modem Answer Mode
Use the modem auto-answer command depending on the answer state of the
connected external modem. When the modem is in auto-answer mode (AA LED of the
modem lights), configure the modem auto-answer command to prevent the firewall
from sending an answer instruction after the modem answers automatically. If the
modem is in non-auto answer mode, configure the undo modem auto-answer
command.
Note:
If the configuration of this command is not consistent with the current answer state of
the connected modem, anomalies may occur.
Table 15-6 Configure the answer mode for the modem
Operation Command
Configure the modem to work in auto-answer mode modem auto-answer
Configure the modem to work in non-auto answer undo modem
mode auto-answer
By default, the modem works in non-auto answer mode.
15.3 Modem Display and Debug

Execute the debugging command in all views for the debugging.
Table 15-7 Display and debug modem
Operation Command
Enable modem debugging debugging modem
15-5
15.4 Typical Modem Configuration Example

15.4.1 Managing Modem through Modem Script
I. Configuring a modem adaptation baud rate
1) Network requirements
On the asynchronous interface connected to the modem, use a standard AT command
to configure the modem baud rate, and send the “AT” command to the modem. If “OK”
is received from the modem, it indicates that the modem can automatically adapt to the
corresponding baud rate. Then, write the configuration into the modem for conservation,
and the corresponding AT command is “AT&W”.
2) Network diagram
PSTN
Modem
PC SecPach
Figure 15-1 Network of the configuration for the gateway to manage the modem
3) Configuration procedure
# Configure a Modem script.
[H3C] script-string baud "" AT OK AT&W OK
# Execute the corresponding script in use view, supposing the modem is connected
with the interface aux0. With the display command, you can see the number of this
interface.
<H3C> start-script baud 1
II. Restoring the ex-factory modem settings
1) Configuration requirement
To restore the ex-factory modem settings, use the “AT&F” command.
[H3C] script-string factory "" AT OK AT&F OK
# Execute the corresponding script in user view, supposing the modem is connected
interface.
<H3C> start-script factory 1
15-6
15.4.2 Dialing Directly with the Script
I. Configuration requirement
Configure a Modem script to dial directly.
[H3C] script-string dial "" AT OK ATDT8810058 CONNECT
# Execute the corresponding script in user view, supposing the modem is connected
interface.
<H3C> start-script dial 1
15.5 Troubleshooting
Fault: Modem is in abnormal status (such as the dial tone or busy tone keeps humming
for a long time).
Troubleshooting:
z Execute the commands shutdown and undo shutdown on the gateway physical
interface connected to the Modem to check whether the Modem has been
restored to normal status.
z If the Modem is still in abnormal status, you can re-power on the Modem.
15-7
H3C SecPath Series Security Products Chapter 16 Interface Configuration
Chapter 16 Interface Configuration
16.1 Interface Configuration Overview

16.1.1 Interface Introduction
Firewall interface refers to the part through which a firewall system exchanges data and
interacts with other devices on the network. It functions to accomplish the data
exchange between the firewall and other network devices.
Comware supports physical and logical interfaces on firewalls.
Physical interfaces are those that physically exist and have the supported components,
such as Ethernet interfaces.
Logical interface refers to the interface that can implement data exchange but does not
physically exist and needs to be set up through configuration. It can be a dialer
interface, subinterface, or virtual-template interface.
SecPath Series Firewalls only provides Ethernet and AUX interfaces currently.
16.1.2 Interface Configuration
I. Interface View
Interface view is designed in the Comware software for the convenience of

configuration and maintenance. All the commands related to an interface can become
valid only when they are used in the view of the interface.
1) Entering interface view
Perform the following configuration in system view to enter the specified interface view.
Table 16-1 Enter the specified interface view
Operation Command
Enter specified interface view interface type number
2) Exiting interface view

Return to system view by executing the quit command in interface view.
II. Configuring Interface Description
In Comware, there is an interface description configuration entry for each physical

interface on firewalls for identifying the function of the interface.
16-1
Table 16-2 Configure interface description
Operation Command
Configure interface description description interface-description
Restore the default interface description undo description
Display the default interface description by executing display interface command.
III. Configuring an Average Interface Rate Measurement Period
Perform the following configuration in system view to configure the interval for
measuring the average rage of the interfaces.
Table 16-3 Configure an average interface rate measurement period
Operation Command
Configure an average interface rate
flow-interval seconds
measurement period.
Restore the default average interface
undo flow-interval seconds
rate measurement period.
The default statistic interval is 300 seconds.
IV. Configuring MTU
The MTU (Maximum Transmission Unit) parameter affects the IP packet fragmentation
and reassembly.
Table 16-4 Configure MTU
Operation Command
Configure MTU mtu size
Restore MTU to default undo mtu
The MTU of Ethernet interface ranges from 46 to 1500 bytes. Dialer interface MTU
ranges from 128 to 1500 bytes. Virtual-Template MTU ranges from 128 to 1500 bytes.
Tunnel interface MTU ranges from 100 to 64000 bytes.
QoS queue has limited length, and if the MTU size is small, packets of big size may be
over fragmented and thus be discarded. To avoid this, you can extend the length of the
QoS queue. The interface of SecPath firewall uses FIFO system by default, so you can
change the queue length by executing command qos fifo queue-length in interface
view. Refer to the QoS Operation part in this manual for detailed information.
16-2
V. Configuring an Interface
Before configuring an interface, you should make sure that you have fully understood
the network requirements and the network diagram. Configuring an interface includes
the following tasks:
z If the interface is a physical one, you should specify its connection state, operating
mode, and the relevant operating parameters.
z Assign a network protocol (such as IP) address to the interface
z Configure the static routing of the destination network reachable through the
interface, or configure the working parameters of the dynamic routing protocol on
the interface.
z If you want to set up a firewall on the interface, you should configure the
parameters in packet filtering, address translation and so on.
Many parameters need to be configured in interface view. This part mainly introduces
some specific parameter configurations of physical interfaces and makes a simple
introduction to logical interfaces. For the sake of simplicity and clarity, this part will not
cover the configuration in link layer and network layer protocols, their relevant
parameters, and some special functions (such as routing, and firewall) that have been
discussed in other parts of the manual.
16.1.3 Displaying and Debugging Interfaces
Table 16-5 Display and debug interfaces
Operation Command
Display the current operating state and
display interface [type [ number ] ]
statistics of interfaces in any view
display brief interface [ type
Display the major configuration
[ number ] ] [ | { begin | include |
information of interfaces in any view
exclude} text ]
Display the interface IP information in
display ip interface [ type number ]
any view
Clear the interface statistic information reset counters interface [ type
in any view [ number ] ]
Shut down an interface in interface view shutdown
Re-enable the interface in interface view undo shutdown
debugging physical { all | error | event
Enable debugging on the specified | packet { all | input | output } }
interface. [ interface interface-type
interface-number ]
16-3
Operation Command
undo debugging physical { all | error |
Disable debugging on the specified event | packet { all | input | output } }
interface. interface interface-type
interface-number
Note:
When a physical interface on the firewall has no cable connection, shut down it with the
shutdown command to prevent anomalies caused by interferences.
16.2 Ethernet Interface

16.2.1 Ethernet Interface Introduction
I. Ethernet interface types
Fast Ethernet (FE) interfaces supported by SecPath Firewalls include electrical and
optical interfaces, complying with 100Base-TX and 100Base-FX physical layer criteria
respectively. The supported Gigabit Ethernet (GE) interfaces also include electrical and
optical interfaces. GE electrical interfaces comply with 1000Base-T criterion, and GE
optical interfaces comply with 1000Base-LX and 1000Base-SX criteria.
II. Operating speed and mode
FE electrical interfaces can work at the speeds of 10Mbps and 100Mbps; GE electrical
interfaces can work at the speeds of 10Mbps, 100Mbps, and 1000Mbps.
In terms of operating modes, both FE and GE electrical interfaces support half and full
duplex modes.
To simplify system configuration and management, both FE and GE electrical
interfaces support auto-negotiation, allowing them to negotiate with other network
devices for the optimum working modes and rates.
Optical interfaces can only work in full duplex modes and their speeds cannot be
changed. FE optical interfaces can only work at the speed of 100Mbps and GE optical
interfaces can only work at 1000Mbps.
III. Supported frame formats
Both FE and GE interfaces support the Ethernet frames in Ethernet_II or

Ethernet_SNAP format, and can automatically identify their formats. They send frames
in Ethernet_II format.
16-4
16.2.2 Ethernet Interface Configuration
Ethernet Interface configuration includes:

z Enter specified Ethernet interface view
z Set the network protocol address
z Select the operating speed of Ethernet interface
z Select the operating mode of Ethernet interface
z Enable or disable loopback
z Configure flow-control mode of Ethernet interface
z Configure the operating mode of Ethernet interface
z Configure Ethernet interface isolation
The specified Ethernet interface cannot be configured unless you enter its interface
view. It is necessary to configure IP address. You are recommended not to enable other
configuration tasks of Ethernet interface, as their default settings are enough for the
normal operation of the system in most circumstances.
I. Entering specified Ethernet interface view
Table 16-6 Enter the specified Ethernet interface view
Operation Command
Enter the specified Ethernet interface view interface ethernet number
interface gigabitethernet
Enter GE interface view
interface-number
II. Setting network protocol address
Table 16-7 Assign an IP address to the interface
Operation Command
Assign an IP address to the interface ip address ip-address mask [ sub ]
undo ip address [ ip-address mask ]
Remove the IP address of the interface
[ sub ]
When an Ethernet interface is configured with two or more IP addresses, use the
keyword "sub" to identify the second one and those behind it (that is, the secondary IP
addresses).
16-5
III. Selecting operating speed of Ethernet interface
Ethernet interfaces support multiple speeds. FE electrical interfaces support 10Mbps

and 100Mbps. FE optical interfaces only support 100Mbps. GE electrical interfaces
support 10Mbps, 100Mbps, and 1000Mbps. GE optical interfaces can only work at
1000Mbps. Thus, you only need to configure Ethernet electrical interfaces while do not
need to configure optical interfaces.
Table 16-8 Select an operating speed for an Ethernet interface
Operation Command
Select an operating speed for the FE
speed { 10 | 100 | negotiation }
interface
Configure the operating speed for a GE
speed { 10 | 100 | 1000 | negotiation }
electrical interface
Restore the default operating speed undo speed
By default, negotiation is selected, i.e., the system automatically chooses an optimum

operating speed.
Note:
z By default, both operating speeds and modes of FE and GE electrical interfaces are
negotiation. You can force to change the operating speeds and modes, but should
keep the speed and mode the same as those of the peer end.
z If you force to execute the duplex negotiation or speed negotiation command,
the Ethernet electrical interfaces are set to the negotiation mode, and negotiate
speed and duplex mode.
z In terms of GE electrical interfaces, the operating speed 1000Mbps and half-duplex
mode are mutually exclusive. Thus, you cannot set these two values at the same
time.
IV. Selecting an operating mode for an Ethernet interface
As mentioned earlier, an Ethernet interface can work at both full-duplex mode and
half-duplex mode. Connected to a hub, the Ethernet interface on a firewall must be
specified to work in half-duplex mode. Connected to a LAN Switch, however, it must be
specified to work in full-duplex mode. Both FE and GE electrical interfaces support
these two modes, whereas FE and GE optical interfaces can only work in full-duplex
mode.
16-6
Perform the following configuration in Ethernet interface view to select an operating

mode.
Table 16-9 Select an operating mode for the Ethernet interface
Operation Command
Select an operating mode for the
duplex { negotiation | full | half }
Ethernet interface
Restore the operating mode for the
undo duplex
Ethernet interface to the default
By default, negotiation is set on both FE and GE electrical interfaces. That is, the
system automatically negotiates an optimum operating mode.
Note:
z In terms of GE electrical interfaces, the operating speed 1000Mbps and half-duplex
mode are mutually exclusive. Thus, you cannot set these two values at the same
time.
z The WAN interface on SecPath 10F firewall does not support auto-negotiation.
V. Enabling or disabling loopback
Sometimes, you need to enable local loop on an interface for testing some special
functions. Perform the following configuration in Ethernet interface view to enable an
interface to make local loopback.
Table 16-10 Enable or disable local loopback
Operation Command
Enable local loopback loopback
Disable local loopback undo loopback
By default, local loop is disabled.
VI. Configuring flow control on an Ethernet interface
16-7
Table 16-11 Configure flow control on the Ethernet interface
Operation Command
Enable flow control on the Ethernet interface. flow-control
Restore the default. undo flow-control
By default, flow control is disabled. Flow control can take effective only when it is
enabled at both ends.
When flow control is enabled, the system cannot enter normal UP state if negotiation
fails. If flow control is enabled on the local interface, you are recommended to execute
the shutdown command and then the undo shutdown command to restart the
interface when the configuration of the peer end changes, to keep the flow control
mode the same on both ends.
VII. Configuring the operating mode of an Ethernet interface
Table 16-12 Configure the operating mode of the Ethernet interface
Operation Command
Set the operating mode of the Ethernet
promiscuous
interface to promiscuous.
Disable the Ethernet interface to operate
undo promiscuous
in promiscuous mode.
By default, the Ethernet interface is operating in non-promiscuous mode.

When the Ethernet interface is operating in promiscuous mode, it receives all correct
Ethernet packets without checking their MAC addresses, This mode is configured when
network listening applies.
After you enable the bridging function on an Ethernet interface and adds it to a
bridge-set, the interface enters promiscuous mode automatically. After removed from
the bridge-set, the interface enters non-promiscuous mode automatically.
VIII. Configuring Ethernet interface isolation
LAN Ethernet interfaces can operate in either isolated or in non-isolated mode. In

isolated mode, LAN Ethernet interfaces operate at Layer 3, that is, they can be used as
routable interfaces and can be configured with Layer 3 attributes (such as IP
addresses). When in non-isolated mode, LAN Ethernet interfaces operate in Hub mode,
that is, they operate at the physical layer. You cannot configure Layer 3 attributes, such
as IP addresses, for them. In this case, you can configure a management IP address
16-8
for management or enabling it to provide network services (Telnet, SNMP and NAT for
example).
Table 16-13 Configure Ethernet interface isolation
Operation Command
Configure Ethernet interface isolation. insulate
Remove Ethernet interface isolation. undo insulate
By default, LAN Ethernet interfaces are isolated from each other.

Only SecPath 100F firewall and SecPath 100V/100N security gateway support this
function.
Note:
z When isolated, all LAN Ethernet interfaces are visible and their Layer 3 attributes,
such as IP addresses, can be configured independently.
z When isolation configuration is removed, only the management interface, instead of
all interfaces, is visible and you can configure IP address for the management
interface, which is used as management IP address.
z Due to interface attributes, only the first LAN interface (the one with the smallest
number) can be configured with subinterfaces. The other three LAN interfaces in
isolated mode cannot be configured with subinterfaces, and the subinterface of the
first LAN interface can only work in non-isolated mode.
16.2.3 Displaying and Debugging Ethernet Interface
Table 16-14 Display the state of a specified Ethernet interface
Operation Command
display interface ethernet number
Display the state of a specified Ethernet
interface display interface gigabitethernet
number
16-9
16.2.4 Ethernet Configuration Example
As shown in the following figure, the Ethernet interface on firewall is connected to the IP
network 192.168.0.0. The computers on the LAN are connected to the Internet via
firewall. Set the MTU on the Ethernet interface to 1492 bytes.
II. Network diagram
LAN Interface Address

192.168.0.1
E0/0/0
Internet
Network Address
192.168.0.0 SecPath
Figure 16-1 Network diagram of Ethernet configuration example
# Assign the IP address 192.168.0.1 to Ethernet 0/0/0, given the mask is 255.255.0.0.
# Set the MTU on the interface to 1492 bytes.

[H3C-Ethernet0/0/0] mtu 1492
16.2.5 Troubleshooting
You can perform the following operations to determine the correctness of the Ethernet
interface.
z Ping the Ethernet interface on the firewall from a host locating on the same LAN,
anticipating that all the packets can be correctly returned.
z Look up the statistics of the connected two parties (firewall and switch for
example), anticipating that the received error frames have not rapidly increased.
If the test result of either item is incompliance with the anticipation, you can conclude
that the Ethernet interface or its connection is not properly working.
After confirming the existence of a fault, you can isolate it following these steps:
Step 1: Check that the LAN connection between the host and the firewall is correct.
If the Ethernet is connected to a hub or LAN Switch, check the ON/OFF status of the
LEDs for the link to the hub or LAN Switch. ON LEDs mean that the Ethernet interface
between the host and the firewall and the network cable are physically normal.
16-10
Otherwise, please replace such physical devices as the network adapter, network
cable, firewall or the relevant interface module.
If the Ethernet is connected using Unshielded Twisted Pair (UTP) and if at least one of
the connection parties supports 100Base-TX, rate matching must be taken into
consideration. An operating rate mismatch between the two parties, i.e., one is working
at 100 Mbps and the other at 10 Mbps, will cause faults. From the perspective of the
one working at 100 Mbps, no connection can be set up. From the perspective of the one
working at 10 Mbps, the connection can be set up but the physical layer activity LED
(ACTIVE) will keep blinking quickly and data transmission and receipt cannot be carried
out properly.
When looking for the connection problems of FE interface on SecPath Series Firewalls,
there are two prompt messages that are very helpful. These two messages are
displayed on the Console screen upon your operation of selecting speed or connecting
network.
Ethernet 0/0/0: Warning--the link partner do not support 100M mode
Ethernet 0/0/0: Warning--the link partner may not support 10M mode
The first prompt message indicates that the Ethernet interface on the SecPath Series
Firewalls have detected that the remote end does not support 100Mbps operating
speed, but the local end is forced to work at 100Mbps. In this case, you should ensure
the remote end to make the same configuration so that it can work at 100 Mbps. The
second prompt message indicates that the Ethernet interface on the SecPath Series
Firewalls have detected that the remote end does not support 10Mbps operating speed,
but the local end is forced to work at 10 Mbps. In this case, the user should ensure that
the remote end could work at 10 Mbps. However, when the FE interface on firewall is
connected to the 10/100 Mbps adaptive port of the hub, this information does not mean
setting is incorrect.
Step 2: View whether IP addresses of the Ethernet interfaces of the host and firewall
are in the same subnet. In other words, they must use the same network address but
different host addresses. If they are not in the same subnet, please set a new IP
address.
Step 3: Check that the operating mode of the Ethernet interface is correct. When the
Ethernet is connected using UTP or fiber, 10Base-T/100Base-TX/100Base-FX
standard provisions two operating modes, that is, full duplex and half duplex. When a
hub is used for connecting the Ethernet, the interface should work in half-duplex mode.
When a LAN Switch working in half duplex mode is used, the Ethernet interface of the
firewall must also work in half duplex mode. If the LAN Switch is working in full duplex
mode, the Ethernet interface of the firewall must also work in full duplex mode. If the
operating mode is incorrect, i.e. one party of the connection is working in full duplex
mode while the other party in half duplex mode, fault will occur. That is, when the
network traffic increases, the party operating in half duplex mode shows frequent
network collisions. For example, if Hub is connected, all the other devices in the whole
16-11
network segment will have serious network collisions. The party operating in full duplex
mode will receive a large amount of error messages, accompanied with serious
message losses at both parties. In this case, use display interface command to view
the error ratio of transmitting and receiving messages on the Ethernet interface. Usually,
the collision can be observed through the state LEDs of the Ethernet interface.
Step 4: Check that flow-control mode of Ethernet interface is correct.
By default, negotiation flow-control is adopted in Ethernet interface. If forced
flow-control mode is used at the peer end, the interface might not be able to go up. In
this case, please keep the flow-control mode the same at both ends. Restart the
interface using the shutdown and undo shutdown commands.
Contact our technical support engineers if you still cannot locate the problem by using
the above methods.
16.3 AUX interface

16.3.1 Introduction to AUX interface
AUX interface is a fixed interface provided by SecPath Firewalls. It can work as a

regular asynchronous interface at a speed up to 115200 bps. With this interface, you
can make remote configuration, implement line backup and some other functions on
the firewalls.
16.3.2 Configuring AUX interface
Perform the following tasks to configure the AUX interface:

z Set link setup method
z Set level detection
z Set local loop
z Set link layer protocol type
I. Setting link setup method
There are two link setup approaches available for the AUX interface. They are:
z Protocol mode, with which the local end directly adopts the configured link layer
protocol parameters to set up a link with the remote end after setting up a physical
link.
z Flow mode, which is also known as interactive mode. With this approach, the two
ends set up a link by interacting with each other upon the setup of a physical link.
Specifically, the calling party sends the configuration commands to the called
party (it is equal to the operation of manually inputting configuration commands at
the remote end), sets the link layer protocol operating parameters of the called
party, and then sets up the link. This approach is normally adopted in the event of
16-12
man-machine interaction in dial access. Users in interactive mode are also called
EXEC users.
Perform the following configuration in AUX interface view.
Table 16-15 Set a link setup mode on an AUX interface
Operation Command
Configure the AUX interface to set up
async mode protocol
links with the protocol approach
Configure the AUX interface to set up
async mode flow
links with the flow approach
The link setup mode defaults to flow mode.
II. Setting level detection
If level detection is disabled on the AUX interface, the system automatically reports that
the state of the serial interface is up with both DTR and DSR being up without detecting
whether a cable is connected. If level detection is enabled on the interface, the system
detects the DSR signal in addition to the external cable. The interface is regarded up
only when the detected DSR signal is valid. Otherwise, it is regarded down.
Table 16-16 Set the level detection function on the AUX interface
Operation Command
Enable the AUX interface to make level detection detect dsr-dtr
Disable the AUX interface to make level detection undo detect dsr-dtr
By default, level detection is enabled.
III. Setting local loop
You may enable the AUX interface to make local loop for testing some special
functions.
Table 16-17 Enable/disable the AUX interface to make local loop
Operation Command
Enable the AUX interface to make local loop loopback
Disable the AUX interface to make local loop undo loopback
By default, local loop is disabled.
16-13
IV. Setting link layer protocol type
Table 16-18 Set the link layer protocol of the AUX interface
Operation Command
Set the link layer protocol of the AUX interface to PPP link-protocol ppp
The other configurations of the AUX interface (e.g., rate, stop bit, parity and flow control)
should be performed in user-interface view. See the User Interface Configuration
section in System Management Module of this manual.
16.4 Logical Interface

16.4.1 Dialer Interface
I. Introduction to dialer interface
Dialer interface is used in configuring PPPoE client.
II. Dialer interface configuration
1) Configuring dialup ACL

Table 16-19 Configure dialup ACL
Operation Command
dialer-rule dialer-number { protocol-name { permit |
Configure a dialup ACL
deny } | acl acl-number }
Remove a dialup ACL undo dialer-rule dialer-number
2) Creating Dialer interface

Table 16-20 Create Dialer interface
Operation Command
Create a Dialer interface and enter the
interface dialer number
corresponding view
Remove the configuration on the interface undo interface dialer number
3) Specifying dialer user

Perform the following configuration in Dialer interface view.
16-14
Table 16-21 Specify Dialer user
Operation Command
Specify a Dialer user dialer user username
4) Enabling Dialer bundle function on the Dialer interface

Table 16-22 Enable Dialer bundle function on the Dialer interface
Operation Command
Enable Dialer bundle function on the
dialer bundle number
Dialer interface
Disable Dialer bundle function on the
undo dialer bundle
Dialer interface
5) Configuring dialup group on the Dialer interface

Table 16-23 Configure dialup group on the Dialer interface
Operation Command
Configure a dialup group on the Dialer interface dialer bundle number
Delete the Dialer interface from the specified dialup
undo dialer bundle
group
6) Configuring virtual baud rate for the Dialer interface

The virtual baud rate of the interface can inform the correct baud rate of the interface to
the upper layer protocol (such as the OSPF routing protocol) and keep the upper layer
protocol running normally.
Table 16-24 Configure dialup group on the Dialer interface
Operation Command
Configure a dialup group on the Dialer interface dialer-group group-number
Delete the Dialer interface from the specified
undo dialer-group
dialup group
By default, the virtual baud rate is not configured for the interface.
16-15
You need to use the shutdown command to shut down the interface after you execute
the virtualbaudrate command. Then, use the undo shutdown command to enable
the interface. In this way, the configuration takes effect for the upper layer protocol.
16.4.2 Loopback Interface
I. Introduction to loopback interface
The TCP/IP suite provisions that the addresses in the 127.0.0.0 segment are loopback
addresses. The interfaces at such addresses are called loopback interfaces. As far as
a SecPath firewall is concerned, the interface Loopback0 is the loopback interface for
receiving all the packets sent to the local firewalls.
In some applications (such as configuring local peers in an SNA), there is often the
need to assign a fixed IP address to a local interface without affecting the physical
interface configuration. To save the scarce IP address resources, this IP address must
be an address of 32-bit mask and must be advertised through a routing protocol. The
Loopback interface is introduced for satisfying such a need.
II. Configuring a loopback interface
Perform the following tasks to configure a loopback interface:

z Create a loopback interface
z Configure the operating parameters of the interface
1) Creating a loopback interface
Table 16-25 Create/delete a loopback interface
Operation Command
Create a loopback interface and enter
interface loopback number
the loopback interface view
Delete the specified loopback interface undo interface loopback number
2) Configuring the operating parameters of the interface

You can configure the parameters like IP address and IP routing for a loopback
interface. For details, refer to other parts in this manual.
16-16
Caution:
You can configure a 32-bit subnet mask for a loopback interface. that is, the subnet
mask can be 255.255.255.255. In addition, the IP address with the 32-bit mask can be
advertised through a routing protocol.
You are recommended to assign a host address of 32-bit mask to a loopback interface.
In this way, you can not only save the address resources but also use the interface as
an unnumbered interface.
You can use the shutdown command to disable the loopback interface.
16.4.3 Null Interface
I. Introduction to Null Interface
Configuring a Null interface is to create a Null interface.

SecPath Series Firewalls support the Null interface. Such an interface is always UP but
cannot forward packets. In addition, no IP address or other link layer protocols can be
configured on it.
Null interface is the logical interface of pure software property. Therefore, all the
network specific packets sent to the interface will be dropped.
II. Configuring a Null Interface
Perform the following configuration in system view to create the interface Null 0 on a
SecPath firewall.
Table 16-26 Create/delete a Null interface
Operation Command
Create a Null interface and enter the Null interface view interface null 0
Delete the Null interface undo interface null 0
As a Null interface drops all the packets reaching it, it provides you with a means of
packet filtering. You can simply make the configuration to send all the undesired
network traffic to the interface Null0 rather than bothering yourself with the complex
work of configuring ACL (Access Control List).
For example, you can drop all the packets destined to the segment 192.101.0.0 by
configuring the static routing command ip route-static 192.101.0.0 255.255.0.0 null 0.
16-17
16.4.4 Subinterface
I. Introduction to Subinterface
Comware supports subinterface and allows the users of Firewalls of high flexibility as
the users can configure multiple subinterfaces on a single physical interface in this
case.
Subinterfaces are the logical virtual interfaces configured on a physical interface. They
share the physical layer parameters of the physical interface and can be separately
configured with the link layer and network layer parameters. As they can be associated
with a physical interface, they are often called “subinterfaces”.
On SecPath Series Firewalls, support the Ethernet subinterface.
II. Configuring an Ethernet Subinterface
Perform the following tasks to configure an Ethernet subinterface:

z Create/delete an Ethernet subinterface
z Configure encapsulation and VLAN ID on the subinterface
z Configure the maximum number of packets processed per second for a VLAN
(optional)
1) Creating/deleting an Ethernet subinterface
Table 16-27 Create/delete an Ethernet subinterface
Operation Command
Create an Ethernet subinterface interface ethernet number.sub-number
and enter the Ethernet
subinterface view interface gigabitethernet number.sub-number
undo interface ethernet number.sub-number

Delete the specified Ethernet
subinterface undo interface gigabitethernet
number.sub-number
If the Ethernet subinterface (the same as sub-number) that you intend to create has
existed, the system will directly enter the view of the subinterface. Otherwise, the
system will create the Ethernet subinterface assigned with sub-number before entering
its view.
The system can support up to 1024 Ethernet subinterfaces.
2) Configuring the VLAN-related parameters
Perform the following configuration in system view or Ethernet subinterface view.
16-18
Table 16-28 Configure the VLAN-related parameters
Operation Command
Set the encapsulation type of an Ethernet subinterface
or a gigabit Ethernet subinterface and the associated vlan-type dot1q vid vid
VLAN ID (in interface view)
Cancel the encapsulation type of an Ethernet
undo vlan-type dot1q
subinterface or a gigabit Ethernet subinterface and the
vid
associated VLAN ID (in interface view)
Set the maximum number of packets processed by a max-packet-process
VLAN per second (in system view) count vid
Restore the default maximum number of packets undo
processed for a VLAN per second (in system view) max-packet-process vid
By default, the Ethernet subinterface is not configured with any encapsulation or

associated with any VLAN ID. In addition, the maximum number of processed packets
is not limited.
After you configure encapsulation on the Ethernet subinterface, it allows VLAN trunk.
3) Configuring other operating parameters
As an Ethernet subinterface that has not been assigned with VLAN ID can only support
IPX, you can only assign an IPX address to such an Ethernet subinterface and
configure the IPX operating parameters. But the configuration procedure is similar to
that for configuring an Ethernet interface. An Ethernet subinterface that has been
assigned with VLAN ID can support both IP and IPX. For the related configurations,
refer to Network Layer Protocol part in this manual.
4) Displaying/debugging Ethernet subinterfaces
After completing the above configurations, execute the display commands in any view
to verify how the Ethernet subinterface is operating after it is associated with a VLAN
ID.
Execute the reset command in user view to clear information about the subinterface.
Table 16-29 Display and debug Ethernet
Operation Command
Display the maximum number of processed packets display vlan
configured on a specified VLAN max-packet-process vid
Display the packet statistics of the specified VLAN, display vlan statistics vid
including the received and sent packet numbers vid
Display the VLAN configuration information on an display vlan interface
interface interface-type interface-num
Clear the packet statistics of specified VLAN reset vlan statistics vid vid
16-19
16.4.5 Virtual-Template and Virtual Interface
I. Introduction to Virtual-Template and Virtual Interface
Virtual-Template is primarily applied in the application environments like VPN and MP.
After setting up a VPN session, the system needs to create a virtual interface for
exchanging data with the remote end. For this purpose, the system will choose a
virtual-template according to the user’s configuration, and dynamically create a virtual
interface based on the configuration parameters of the template. For VPN configuration
details, refer to the related sections of VPN Configuration in this manual..
Likewise, after bundling multiple PPP links into an MP, the system also needs to create
a virtual interface for exchanging data with the remote end. In this case, you can select
a virtual-template for the purpose of dynamic creation of virtual interface.
II. Configuring a Virtual-Template
In VPN and MP application environments, the system automatically creates and

deletes virtual interfaces, which is completely transparent to the user. The user only
needs to configure VPN or MP on the involved physical interface, creates and
configures a virtual-template, and finally associates the virtual-template with the
physical interface.
Perform the following tasks to configure a virtual-template:
z Create/Delete a virtual-template
z Set operating parameters of virtual-template
z Associate the virtual-template with the involved physical interface
1) Creating/Deleting a virtual-template
Table 16-30 Create/delete a virtual-template
Operation Command
Create a virtual-template and
interface virtual-template number
enter the virtual-template view
Delete the virtual-template undo interface virtual-template number
If the virtual-template that you intend to create by using the interface virtual-template
command has existed, the system will directly enter the view of the virtual-template.
Otherwise, the system will create the virtual-template assigned with specified number
before entering its view.
In deleting a virtual-template, make sure that all of its derived virtual interfaces have
been removed and this virtual-template is not in use any more.
2) Setting operating parameters of virtual-template
16-20
Compared with a regular physical interface, virtual-templates only support PPP in

terms of link layer protocol and IP in terms of network protocol. Accordingly, you can
perform the following tasks to set the following operating parameters:
z Set PPP operating parameters
z Assign an IP address to the virtual interface
z Set the IP address (or IP address pool) assigned to the PPP peer
Setting these parameters on a virtual-template is the same as setting them on a regular
interface.
3) Associating the virtual-template with the involved physical interface
You are required to associate an L2TP group with the virtual-template in a VPN
environment and MP user with the virtual-template in an MP environment.
For details, refer to VPN part in this manual.
III. Displaying and Debugging Virtual-Template and Virtual Interface
When needed, the system can automatically create a virtual interface and operate it
with the parameters of the associated virtual-template. Therefore, manual creation and
configuration are not needed. A virtual interface can be deleted due to the
disconnection of the bottom layer link or the interruption of the user.
Execute the following command in any view to display the state of a specified
virtual-template.
Table 16-31 Display the state about the specified virtual-template
Operation Command
Display the state about the specified display interfaces virtual-template
virtual-template number
display virtual-access { dialer number
Display the state about the specified or
| vt vt-number | user user-name | peer
all virtual access interfaces.
peer-address | va-number }*
You cannot use this command to view the virtual access interface generated by Dialer
interface on PPPoE client.
IV. Troubleshooting
Before isolating the faults of a virtual-template, you must make sure the application
environment, specifically, whether the virtual-template is used for creating a VPN virtual
interface or for creating an MP virtual interface.
Fault 1: The system failed to create a virtual interface.
Problem solving: Such a problem may arise because:
z The virtual-template had not been assigned with an IP address. Therefore, the
virtual interface failed to pass the PPP negotiation and hence could not go up.
16-21
z The virtual-template had not been configured with the IP address (or IP address
pool) intended for the peer. Therefore, if it is necessary to allocate address for the
peer, the associated virtual interface could not satisfy the requirements of the peer
and hence could not go up.
z PPP authentication parameters were incorrectly set. When the peer was not a
user defined on the firewall, PPP negotiation would also fail.
16-22
User Access
Operation Manual – User Access
Table of Contents
Chapter 1 PPP Configuration ....................................................................................................... 1-1

1.1 Introduction to PPP ............................................................................................................ 1-1
1.1.1 Introduction to PPP ................................................................................................. 1-1
1.2 Configuring PPP ................................................................................................................ 1-2
1.2.1 Configuring PPP Encapsulation on the Interface.................................................... 1-3
1.2.2 Configuring the Polling Interval ............................................................................... 1-3
1.2.3 Configuring PPP Authentication Mode and Username and User Password .......... 1-4
1.2.4 Configuring PPP Negotiation Parameters............................................................... 1-7
1.2.5 Configuring PPP Link Quality Control ................................................................... 1-12
1.2.6 Displaying and Debugging PPP ............................................................................ 1-12
1.3 Configuring PPP Link Efficiency Mechanism................................................................... 1-13
1.3.1 Configuring IPHC .................................................................................................. 1-14
1.3.2 Configuring PPP STAC-LZS Compression........................................................... 1-16
1.3.3 Configuring VJ TCP Header Compression for PPP Packets................................ 1-16
1.3.4 Displaying and Debugging PPP Link Efficiency Mechanism ................................ 1-16
1.4 Typical PPP Configuration Example................................................................................ 1-17
1.4.1 PAP Authentication ............................................................................................... 1-17
1.4.2 CHAP Authentication ............................................................................................ 1-18
1.5 Troubleshooting PPP....................................................................................................... 1-19
Chapter 2 PPPoE Server Configuration ...................................................................................... 2-1

2.1 Introduction to PPPoE ....................................................................................................... 2-1
2.2 PPPoE Server Configuration ............................................................................................. 2-1
2.2.1 Creating a Virtual Template .................................................................................... 2-1
2.2.2 Enabling/Disabling PPPoE Server .......................................................................... 2-2
2.2.3 Configuring PPPoE Server Parameters.................................................................. 2-2
2.2.4 Enabling/Disabling the PPPoE Server to Output PPP-Related Log ....................... 2-3
2.3 Displaying and Debugging PPPoE Server ........................................................................ 2-3
2.4 PPPoE Configuration Example.......................................................................................... 2-4
Chapter 3 PPPoE Client Configuration ....................................................................................... 3-1

3.1 Introduction to PPPoE Client ............................................................................................. 3-1
3.2 Configuring the PPPoE Client............................................................................................ 3-2
3.2.1 Configuring a Dialer Interface ................................................................................. 3-2
3.2.2 Configuring a PPPoE Session ................................................................................ 3-3
3.2.3 Resetting/Deleting a PPPoE Session ..................................................................... 3-4
3.3 Displaying and Debugging the PPPoE Client.................................................................... 3-5
3.4 Typical PPPoE Client Configuration Example ................................................................... 3-5
3.4.1 Typical PPPoE Client Configuration Example ........................................................ 3-5
i
3.4.2 Connecting a LAN to the Internet Through an ADSL Modem................................. 3-7
Chapter 4 VLAN Configuration .................................................................................................... 4-1

4.1 Introduction to VLAN.......................................................................................................... 4-1
4.2 Basic VLAN Configuration ................................................................................................. 4-3
4.3 Displaying and Debugging VLAN ...................................................................................... 4-3
4.4 Typical VLAN Configuration Example................................................................................ 4-4
ii
H3C SecPath Series Security Products Chapter 1 PPP Configuration
Chapter 1 PPP Configuration
1.1 Introduction to PPP

1.1.1 Introduction to PPP
The Point-to-Point Protocol (PPP) is one of link layer protocols that bearing network
layer packets over point-to-point link. It has found wide application since it can provide
user authentication, support synchronous/asynchronous communication and, can be
expanded easily.
PPP defines a whole set of protocols, including Link Control Protocol (LCP), Network
Control Protocol (NCP) and authentication protocols Password Authentication Protocol
(PAP) and CHAP (Challenge Handshake Authentication Protocol). Where,
z LCP is responsible for establishing, removing and monitoring data links.
z NCP is used to negotiate the format and type of the packets over data links.
z Authentication protocol suite used for network security
1) PAP authentication
PAP is a 2-way handshake authentication protocol and it sends the password in plain
text. The process of PAP authentication is as follows:
z The requester sends its username and password to the authenticating party.
z The authenticator will check if the username and password are correct according
to local user list and then return different responses (Acknowledge or Not
Acknowledge).
2) CHAP authentication
CHAP (Challenge-Handshake Authentication Protocol) is a 3-way handshake
authentication protocol and the password is sent encrypted. The process of CHAP
authentication is as follows:
z The authenticator actively initiates an authentication request by sending some
randomly generated packets (Challenge) to the authenticatee, carrying its own
username in the packets.
z When the authenticatee receives the authentication request initiated by the
authenticator, it looks up the user passwords in the local user database for a
match with the authenticator’s username in the received packet. If it finds a match,
the authenticatee will use the MD5 algorithm to encrypt this random packet with
packet ID and user’s key (password) and then send the generated ciphertext and
its own username back to the authenticator (Response); if the authenticator does
not find any match, it checks whether the ppp chap password command is
configured on its interface. If this command is configured, the authenticatee will
use the MD5 algorithm to encrypt this random packet with packet ID and user’s
1-1
key (password) and then send the generated cipher text and its own user name
back to the authenticator (Response).
z The authenticator encrypts the original random packet with the authenticatee
password that it has saved and the MD5 algorithm, compares the encryption result
with the received ciphertext, and returns a commensurate response (either
Acknowledge or Not Acknowledge) depending on the comparison result.
Following is how PPP operates (see Figure 1-1):
1) Before setting up a PPP link, enter the Establish phase.
2) Carry out LCP negotiation in the Establish phase, which includes the negotiation in
operating mode (SP or MP), authentication mode and MRU. If the negotiation is
successful, LCP will enter the Opened status, indicating the setup of the bottom
layer link.
3) If the authentication (the remote verifies the local or the local verifies the remote) is
configured, it enters the Authenticate phase and starts the CHAP/PAP
authentication
4) If the authentication fails, it will enter the Terminate phase to remove the link and
the LCP will go down. If the authentication succeeds, it will proceed to start the
network negotiation (NCP). In this case, the LCP state is still Opened, while the
state of IP control protocol (IPCP) is changed from Initial to Request.
5) NCP negotiation supports the negotiation of IPCP, which primarily refers to the
negotiation of the IP addresses of the two parties. NCP negotiation is conducted
for the purpose of selecting and configuring a network layer protocol. Only the
network layer protocol that has been agreed upon by the two parties in the NCP
negotiation can send packets over the PPP link.
6) The PPP link will remain for communications until an explicit LCP or NCP frame
close it or some external events take place (for example, the intervention of the
user).
Dead UP Establish OPENED Authenticate
FAIL FAIL
SUCCESS/NONE
DOWN CLOSING
Terminate Network
Figure 1-1 PPP operation flow chart
For the details of PPP, refer to RFC1661.
1.2 Configuring PPP

Fundamental PPP configuration tasks include:
1-2
z Configure the data link protocol encapsulated on the interface to be PPP

z Configure the polling interval
z Configure PPP authentication mode, user name and user password
Advanced PPP configuration tasks include:
z Configure PPP negotiation parameters
z Configure PPP link quality control (LQC)
The fundamental configuration is the parameter setting that must be performed for
running PPP on the firewall, whereas the advanced configurations are the options that
can be configured as needed.
1.2.1 Configuring PPP Encapsulation on the Interface
Table 1-1 Configure PPP encapsulation on the interface
Operation Command
Configure PPP encapsulation on the interface. link-protocol ppp
The link layer protocol encapsulated on the dialer and virtual-template interfaces
defaults to PPP.
1.2.2 Configuring the Polling Interval
Data link protocols such as PPP, FR and HDLC use a timer to monitor the status of the
link periodically. The polling interval must be exactly equal at the two ends of the link for
properly working.
Table 1-2 Configure polling interval on the interface
Operation Command
Set the polling interval. timer hold seconds
Reset polling interval undo timer hold
The polling interval defaults to 10 seconds. The cyclic polling operation will be closed if
the polling interval is set to 0.
Elongate this time to prevent net fluctuation for long-delay and high-congestion
network.
1-3
1.2.3 Configuring PPP Authentication Mode and Username and User

Password
The local and the peer support both CHAP and PAP authentication approaches
between them. The configuration procedures in both approaches will be described in
the following subsections. This chapter only discusses local authentication. For
information about the remote AAA authentication, refer to the Security module in this
manual.
I. Configuring the local to authenticate the peer using PAP
Table 1-3 Configure the local to authenticate the peer with the PAP approach
Operation Command
Configure the local to authenticate the ppp authentication-mode pap
peer in PAP mode (in interface view). [[ call-in ] domain isp-name]
Disable the configured PPP
authentication mode, i.e. performing no undo ppp authentication-mode
PPP authentication (in interface view).
Create a local user and enter the
local-user username
corresponding view (in system view)
Configure the password for the local
password { simple | cipher } password
user (in local user view)
undo password
local user view)
service-type ppp [ callback-nocheck |
Set the callback and caller number
callback-number callback-number |
attributes of the PPP user (in local user
call-number call-number
view)
[ :subcall-number ] ]
Restore the default callback and caller undo service-type ppp
number attributes of the PPP user (in [ callback-nocheck | callback-number
local user view) | call-number ]
Create an ISP domain or enter the view domain { isp-name | default { disable |
of a created domain (in system view) enable isp-name } }
Configure the user in the domain to use
the local authentication scheme (in scheme local
domain view)
By default, PPP authentication is disabled.

If you configure the ppp authentication-mode { pap | chap } command without
specifying a domain, the system-default domain applies by default, adopting local
authentication. The address pool configured in the domain must be used. If a domain is
specified, you must configure an address pool in the specified domain.
1-4
If a received username includes a domain name, this domain name is used for
authentication (if the name does not exist, authentication is denied). Otherwise, the
domain name configured for PPP authentication applies.
II. Configuring the local to authenticate the peer using CHAP
Table 1-4 Configure the local to authenticate the peer with the CHAP approach
Operation Command
Configure the local to authenticate the ppp authentication-mode chap
peer in CHAP mode (in interface view) [ [ call-in] domain isp-name ]
Disable the configured PPP
authentication, i.e. performing no PPP undo ppp authentication-mode
authentication (in interface view)
Configure the local username (in
ppp chap user username
interface view)
Delete the configured local username (in
undo ppp chap user
interface view)
Create a local user and enter the
local-user username
corresponding view (in system view)
Configure the password for the local password { simple | cipher }
user (in local user view) password
undo password
local user view)
service-type ppp [ callback-nocheck |
Set the callback and caller number
callback-number callback-number |
attributes of the PPP user (in local user
call-number call-number
view)
[ :subcall-number ] ]
Restore the default callback and caller undo service-type ppp
number attributes of the PPP user (in [ callback-nocheck | callback-number
local user view) | call-number ]
of a created domain (in system view) enable isp-name } }
Configure the user in the domain to use
the local authentication scheme (in scheme local
domain view)
By default, PPP authentication is disabled.

For authentication on a dial interface, you are recommended to configure
authentication on both the physical interface and the dialer interface. When the
physical interface receives a DCC call request, it first initiates PPP negotiation and
authenticates the dial-in user, and then it passes the call to the upper layer protocol.
1-5
III. Configuring the local to be authenticated by the peer using PAP
Table 1-5 Configure the local to be authenticated by the peer with the PAP approach
Operation Command
Configure PAP username and password
that the local will send when ppp pap local-user username
authenticated by the peer in PAP mode password { simple | cipher } password
(in interface view)
Delete the PAP username and
password that the local will send when
undo ppp pap local-user
authenticated by the peer in PAP mode
(in interface view)
By default, when the local firewall is authenticated by the peer in PAP mode, both the
username and password sent by the local firewall are null.
IV. Configuring the local to be authenticated by the peer using CHAP
Table 1-6 Configure the local to be authenticated by the peer with the CHAP approach
Operation Command
Create a local user and enter the local
local-user username
user view (system view)
Set a password for the local user in local password { simple | cipher }
user view password
Cancel the password for the local user in
undo password
local user view
Configure the local name (in interface
ppp chap user username
view)
Delete the configured local name (in
undo ppp chap user
interface view)
Set the default CHAP authentication
password in interface view (use this ppp chap password { simple | cipher }
password when the local user name and password
password are not configured)
Delete the default CHAP authentication
undo ppp chap password
password in interface view
In the above table, simple means to send password in plain text and cipher in
ciphertext.
1-6
Note:
When configuring CHAP authentication, you should configure the same username with
the local-user command executed as that with the ppp chap user command executed
for the peer. You should also configure the same password for both sides. If the peer
does not use the local-user command to configure the local user, the peer
encapsulates the received authentication request from all PPP users using the key (the
key is configured by the ppp chap password command) and responds to the local user.
1.2.4 Configuring PPP Negotiation Parameters
The following PPP negotiation parameters can be configured:

Time interval between negotiation timeout. During PPP negotiation, if the response
message of the peer is not received within this time interval, PPP will retransmit the
message. The timeout interval ranges from 1 to 10 seconds.
For some negotiation parameters of NCP such as the configuration of local IP address
and the IP address assigned to the peer, refer to the “Network Protocol Configuration”
part in this manual. For example, the ip address ppp-negotiate command can be
used to ask the peer to assign IP address for the local, while the remote address
command can be used to designate the local to assign IP address for the peer.
I. Configuring the time interval of PPP negotiation timeout
Table 1-7 Configure the time interval of PPP negotiation timeout
Operation Command
Configure the time interval of negotiation timeout ppp timer negotiate seconds
Restore the default value of time interval of
undo ppp timer negotiate
negotiation timeout
The timeout interval defaults to 3 seconds.
II. Negotiating IP address using PPP
1) Configure client
Suppose PPP has been encapsulated on local and remote interfaces. If the local
interface has no IP address while the remote interface has one, you may configure the
local interface to allow it to negotiate an IP address using PPP and accept the IP
1-7
address thus assigned by the remote interface. When accessing the Internet via an ISP,
you may make this configuration to get an IP address from the ISP.
Table 1-8 Configure an interface to negotiate IP address using PPP
Operation Command
Configure an interface to negotiate IP
ip address ppp-negotiate
address using PPP.
Disable PPP negotiation. undo ip address ppp-negotiate
By default, the system does not allow the interface to negotiate the IP address.
Caution:
z Because PPP supports IP address negotiation, you can configure the interface to
negotiate the IP address only when PPP is encapsulated on the interface. When
PPP is disabled, the negotiated IP address will be deleted.
z If the interface has an IP address, the original IP address is deleted after you
configure the interface to negotiate IP addresses.
z After you configure the interface to negotiate IP addresses, you are not allowed to
assign an IP address for the interface. The negotiation can generate an IP address.
z After you configure the interface to negotiate IP addresses twice, the IP address
generated by the first negotiation is deleted, and the IP address generated by the
second negotiation is used.
z After the IP address generated by the negotiation is deleted, the interface has no IP
address.
2) Configure server
If a firewall is functioning as server to assign IP address for a client, you can use the
following three methods to assign IP address for a PPP user:
Method1: Assign directly the specified IP address for the peer on the interface without
configuring an address pool.
1-8
Table 1-9 Assign directly the specified IP address for the peer on the interface
Operation Command
Assign an IP address for the PPP user remote address ip-address
Remove the configuration undo remote address
By default, if the remote address pool command and the domain address pool are not
configured, the specified IP address is not assigned for the peer on the interface.
Method 2: Assign an IP address for the peer using a global address pool
Define a global address pool in system view first, and then use the remote address
pool command on the interface to specify a global address pool number (only one
number can be specified).
Table 1-10 Assign an IP address for the peer using a global address pool
Operation Command
ip pool pool-number low-ip-address
Define a global IP address pool
[ high-ip-address ]
Remove the configuration undo ip pool pool-number
Use the global address pool to assign an
remote address pool [ pool-number ]
IP address for the PPP user
configured, the IP address is not assigned for the peer. When you configure the remote
address pool command but do not configure the pool-number parameter, the system
uses global address pool 0 by default.
If you do not authenticate the PPP user, you can use methods 1 and 2. If you need to
authenticate the PPP user, you should use method 3 as follows:
Method 3: Assign an IP address for the peer using the address pool for the domain
Define a address pool for the domain in domain view first, and then use the remote
address pool command to specify the address pool number for the domain (you can
specify only one number); if you do not configure the remote address pool command,
use the address pools of the corresponding domains in turn to assign IP addresses for
users during authentication negotiation.
1-9
Table 1-11 Assign an IP address for the PPP user using the address pool for the
domain
Operation Command
ip pool pool-number low-ip-address
Define a global IP address pool
[ high-ip-address ]
Remove the configuration undo ip pool pool-number
Assign an IP address for the PPP user
remote address pool [ pool-number ]
using the global IP address pool
configured, the IP address is not assigned for the peer.
The following section describes how to assign an IP address for the PPP user:
1) For the domain user (including userid and userid@isp-name), assign the IP
address as follows:
z In the case of RADIUS or TACACS authentication and authorization, when the
server delivers an IP address for the PPP user, the delivered IP address is used.
z If the server delivers an IP address pool instead of an IP address, the system
searches for the IP address pool in turn in domain view, and assigns an IP address
for the PPP user.
z If the system assigns no IP address using the above two methods, or the local
authentication is adopted, the system searches for the address pool in turn in
domain view, and assigns an IP address for the PPP user.
2) For users not to be authenticated, the system uses the specified global address
pool (the address pool defined in system view) on the interface to assign an IP
address for the PPP user.
When directly specifying the IP address for the peer on the interface or uses the global
address pool to assign the IP address, the system allows the peer to use its
self-configured IP address after the remote address command is configured; if the
system does not want (or allow) the peer to use its self-configured IP address, and
orders the peer to receive the IP address assigned by the local user, you must
configure the peer IP address assigned by negotiation and execute the following
commands in interface view on server side.
1-10
Table 1-12 Enable/disable forced IP address assignment with PPP IPCP negotiation
Operation Command
Forbid the peer to use a self-configured
ppp ipcp remote-address forced
fix IP address in PPP IPCP negotiation.
Disable forced address assignment in undo ppp ipcp remote-address
PPP IPCP negotiation. forced
By default, the peer can use its self-configured IP address in PPP IPCP negotiation. If
the peer explicitly requests this end for an address, this end acts as requested; if the
peer already has a self-configured IP address, this end does not allocate one to the
peer.
III. Configuring DNS address negotiation
While negotiating PPP address, the firewall can negotiate DNS server address as a
DNS server address provider or recipient, depending on the connected device.
When a PC connects to the firewall using PPP, through dialup for example, the firewall
should allocate a DNS server address to the PC so that the PC can use its domain
name to access the Internet.
When connected using PPP to the network access server (NAS) of the service provider,
the firewall should be able to request the NAS for a DNS server address or accept the
unsolicited DNS server address for revolving domain names.
Table 1-13 Configure DNS address negotiation
Operation Command
Enable the firewall to accept the
ppp ipcp dns admit-any
unsolicited DNS server address
Disable the firewall to accept the
undo ppp ipcp dns admit-any
unsolicited DNS server address
Enable the firewall to allocate a DNS ppp ipcp dns primary-dns-address
server address to the peer [ secondary-dns-address ]
undo ppp ipcp dns

Disable the firewall to allocate a DNS
primary-dns-address
server address to the peer
[ secondary-dns-address ]
Enable the firewall to request for a DNS
ppp ipcp dns request
server address
Disable the firewall to request for a DNS
undo ppp ipcp dns request
server address
By default, DNS address negotiation is disabled.
1-11
1.2.5 Configuring PPP Link Quality Control
You may use PPP link quality control (LQC) to monitor quality of PPP links. The system
shuts down a link when its quality decreased below the forbidden-percentage and
brings it up when its quality ameliorates exceeding the resumptive-percentage. When
re-enabling the link, PPP LQC experiences a delay to avoid link flapping.
Table 1-14 Configure PPP link quality control
Operation Command
Enable PPP LQC ppp lqc forbidden-percentage [ resumptive-percentage ]
Disable PPP LQC undo ppp lqc
By default, the arguments resumptive-percentage and forbidden-percentage are equal.
Note:
Before you enable LQC, the PPP interface sends keepalive packets to the peer
regularly. After you enable LQC on the interface, the PPP interface sends link quality
reports (LQRs) instead for monitoring the link.
When the quality of the link is normal, the system calculates link quality based on each
LQR and shuts down the link if the results of two consecutive calculations are below the
forbidden-percentage. After shutting down the link, the system calculates link quality
every ten LQRs, and brings the link up again if the results of three consecutive
calculations are higher than the resumptive-percentage. That means a disabled link
must experience 30 keepalive periods before it can go up again. If a large keepalive
period is specified, it may take long time for the link to go up.
1.2.6 Displaying and Debugging PPP
When finishing the above configuration, execute display commands in all views to
view running status after the PPP configuration and to verify the effect of the
configuration. And you can debug PPP by executing debugging command in user
view.
Table 1-15 Displaying and debugging
Operation Command
Display the PPP
configuration and status display interface interface-name
of a interface
1-12
Operation Command
debugging ppp { chap { all | event | error | packet |
Enable part of debug state }| pap { all | event | error | packet | state }|
switches of PPP vjcomp packet } [ interface interface-type
interface-number ]
Enable part of debug debugging ppp compression iphc { rtp | tcp } { all |
switches of PPP context_state | error | full_header | general_info }
debugging ppp { core event | ip packet| ipcp { all |
Enable part of debug event | error | packet | state } | lcp { all | event | error
switches of PPP | packet | state } | lqc packet | mp { all | event | error |
packet } } [ interface interface-type interface-number ]
debugging ppp { all | cbcp packet | ccp { all | event |
Enable part of debug
error | packet | state } | scp packet } [ interface
switches of PPP
interface-type interface-number ]
1.3 Configuring PPP Link Efficiency Mechanism

Four mechanisms are available for improving transmission efficiency on PPP links.
They are IP header compression (IPHC), STAC Lempel-Ziv standard (STAC-LZS)
compression on PPP packets, V. Jacobson Compressing TCP/IP Headers (VJ TCP
header compression), and link fragmentation and interleaving (LFI).
I. IP header compression
IPHC is a host-to-host protocol that applies to transmit multimedia services such as

voice and video over IP networks. To decrease the bandwidth consumed by headers,
you may enable IP header compression on PP links to compress RTP (including IP,
UDP, and RTP) headers or TCP headers. The following describes how compression
operates taking RTP header compression for example.
The real-time transport protocol (RTP) is virtually a UDP protocol using fixed port
number and format. Since its publication as RFC 1889, there has been growing interest
in using RTP as one step to achieve interoperability among different implementations of
network audio/video applications. However, there is also concern that 40-byte
IP/UDP/RTP header containing a 20-byte IP header, 8-byte UDP header and 12-byte
RTP header, is too large an overhead for 20-byte or 160-byte payloads.
To reduce overhead, you can use IPHC to compress headers. In many cases, all three
headers can be compressed to 2 to 5 bytes. The effect of the header compression
proves considerable that a payload of 40 bytes can be compressed to 5 bytes through
the process with the compression ratio as (40+40) / (40+5), about 1.78. The process of
IPHC is illustrated in the following figure.
1-13
RTP header
incoming packets cpmpression
Sending queue
queue
Traffic classifying
Non RTP traffic
Figure 1-2 IP header compression
II. STAC-LZS compression
STAC-LZS compression is a link-layer data compression standard developed by Stac

Electronics. STAC-LZS is a Lempel-Ziv-based algorithm that compresses only packet
payloads. It replaces a continuous data flow with binary code that can accommodate to
the change of data. While allowing for more flexibility, this requires more CPU
resources.
III. VJ TCP header compression
VJ TCP header compression was defined in RFC1144 for use on low-speed links.
Each TCP/IP packet transmitted over a TCP connection contains a typical 40-byte
TCP/IP header containing an IP header and a TCP header that are 20-byte long each.
The information in some fields of these headers, however, is unchanged through the
lifetime of the connection and needs sending only once, while the information in some
other fields changes but regularly and within a definite range. Based on this idea, VJ
TCP header compression may compress a 40-byte TCP/IP header to 3 to 5 bytes. It
can significantly improve the transmission speed of some applications, such as FTP, on
a low-speed serial link like PPP.
1.3.1 Configuring IPHC
IPHC configuration tasks are described in the following sections:

z Enabling/disabling IPHC
z Configuring maximum number of compression-enabled TCP connections
z Configuring maximum number of compression-enabled RTP connections
I. Enabling/disabling IPHC
Executing the command in the following table can enable the IP header compression
on some interface. Enabling IP header compression enables the system to compress
the TCP packets for RTP session setup. Likewise, disabling IP header compression
disables the system to compress the TCP packets for RTP session setup.
1-14
You must configure IP header compression at the endpoints of a link.

Table 1-16 Enable/disable IPHC
Operation Command
Enable IPHC. ppp compression iphc [ nonstandard ]
Disable IPHC. undo ppp compression iphc
II. Configuring maximum number of compression-enabled TCP connections
You can configure maximum number of compression-enabled TCP connections.

Table 1-17 Configure maximum number of compression-enabled TCP connections
Operation Command
Configure maximum number of compres ppp compression iphc
sion-enabled TCP connections tcp-connections number
undo ppp compression iphc
Restore the default
tcp-connections
The parameter number indicates the maximum connection number (from 3 to 256) of
TCP compression mode on the interface. It is 16 by default.
III. Configuring maximum number of compression-enabled RTP connections
You can configure maximum number of compression-enabled RTP connections.

Table 1-18 Configure maximum number of compression-enabled RTP connections
Operation Command
Configure maximum number of compres ppp compression iphc
sion-enabled RTP connections rtp-connections number
undo ppp compression iphc
Restore the default
rtp-connections
The number argument specifies the maximum number of compression-enabled RTP

connections (in the range 3 to 1000) on the interface. It defaults to 16.
1-15
1.3.2 Configuring PPP STAC-LZS Compression

The current system version supports the Stac compression described in RFC 1974.
Table 1-19 Configure PPP STAC-LZS compression
Operation Command
Enable Stac LZS compression on the interface. ppp compression stac-lzs
undo ppp compression
Disable Stac LZS compression on the interface.
stac-lzs
By default, compression is disabled.
1.3.3 Configuring VJ TCP Header Compression for PPP Packets
Table 1-20 Configure VJ TCP header compression
Operation Command
Enable VJ TCP header compression on
ip tcp vjcompress
the PPP interface.
Disable VJ TCP header compression on
undo ip tcp vjcompress
the PPP interface.
By default, VJ TCP header compression is disabled on the PPP interface.
1.3.4 Displaying and Debugging PPP Link Efficiency Mechanism
Table 1-21 Display and debug PPP link efficiency mechanism
Operation Command
Display statistics about TCP header display ppp compression iphc tcp
compression [ interface-type interface-number ]
Display statistics about RTP header display ppp compression iphc rtp
Display statistics about stac-lzs header display ppp compression stac-lzs
debugging ppp compression iphc rtp

Enable TCP header compression
{ all | context_state | error |
debugging
full_header | general_info }
debugging ppp compression iphc tcp

Enable RTP header compression
{ all | context_state | error |
debugging
full_header | general_info }
1-16
Operation Command
Clear all statistics about IP header reset ppp compression iphc
Clear all statistics about Stac-lzs header reset ppp compression stac-lzs
1.4 Typical PPP Configuration Example

1.4.1 PAP Authentication
I. Configuration requirements
As shown in Figure 1-3, the firewalls SecPath 1 and SecPath 2 are interconnected on
Ethernet1/0/0. SecPath 1 authenticates SecPath 2 with the PAP approach.
II. Network diagram
Ethernet1/0/0 Ethernet1/0/0
SecPath1 SecPath 2
Figure 1-3 Network diagram of PAP and CHAP authentication
# Add a PPPoE user.
[H3C] local-user secpath2
[H3C-luser-secpath2] password simple pwd
[H3C-luser-secpath2] service-type ppp
# Configure virtual template parameters on SecPath1.

[H3C] interface virtual-template 1
[H3C-Virtual-Template1] ppp authentication-mode pap
[H3C-Virtual-Template1] ip address 1.1.1.1 255.0.0.0
[H3C-Virtual-Template1] remote address 1.1.1.2
# Configure the PPPoE parameter on the SecPath1.

[H3C-Ethernet1/0/0] pppoe-server bind virtual-template 1
2) Configure SecPath2.
[H3C] dialer-rule 1 ip permit
[H3C] interface dialer 1
[H3C-Dialer1] dialer user secpath1
1-17
[H3C-Dialer1] dialer-group 1
[H3C-Dialer1] dialer bundle 1
[H3C-Dialer1] ip address ppp-negotiate
[H3C-Dialer1] ppp pap local-user secpath2 password simple pwd
# Configure PPPoE session.

[H3C-Ethernet1/0/0] pppoe-client dial-bundle-number 1
1.4.2 CHAP Authentication
In Figure 1-3, SecPath 1 authenticates SecPath 2 with the CHAP approach.
II. Network diagram
See Figure 1-3.
# Add a PPPoE user.
# Configure virtual template parameters on SecPath1.

[H3C-Virtual-Template1] ppp authentication-mode chap
[H3C-Virtual-Template1] ppp chap user secpath1
# Configure the PPPoE parameter on SecPath1.

[H3C-Dialer1] ppp chap user secpath2
1-18
# Configure PPPoE session.

1.5 Troubleshooting PPP

Fault 1: The link never turns into the up state.
Problem solving: This problem may arise from the PPP authentication failure due to the
incorrect configuration of PPP authentication parameters.
Enable the debugging of PPP, and you will see the information describing that LCP
went up with a successful LCP negotiation but went down after the PAP or CHAP
negotiation.
Fault 2: The physical link fails to go up.
Problem solving: Execute the display interface type number command to view the
current interface status.
1-19
H3C SecPath Series Security Products Chapter 2 PPPoE Server Configuration
Chapter 2 PPPoE Server Configuration
2.1 Introduction to PPPoE

Point-to-Point Protocol over Ethernet (PPPoE) establishes a network comprising a
large number of hosts by making use of the Ethernet, and makes the hosts access the
Internet through a remote access device while performing access control and
accounting on each host. Due to its attractive performance-to-price ratio, PPPoE is
widely adopted in applications like community network constructions.
PPPoE is divided into two distinct phases, that is, Discovery phase and PPP Session
phase. Specifically:
When a host wants to start a PPPoE process, it must first identify the MAC address of
the Ethernet on the access end and create the SESSION ID of PPPoE. This is the very
purpose of the Discovery phase.
After entering the Session phase of PPPoE, the system can encapsulate the PPP
packet as the payload of PPPoE frame into an Ethernet frame and then send the
Ethernet frame to the peer. In the frame, the SESSION ID must be the one determined
at the Discovery phase, MAC address must be the address of the peer, and the PPP
packet section begins with the Protocol ID. In the Session phase, either the host or the
server may send PADT packets in order to notify the other to end this Session.
For more information about PPPoE, refer to RFC2516.
2.2 PPPoE Server Configuration

PPPoE server configurations include:
Fundamental configuration task of PPPoE server includes:
z Create a virtual template and configure the related parameters
z Enable/disable PPPoE server
Advanced configuration task of PPPoE includes:
z Configure other PPPoE server parameters
2.2.1 Creating a Virtual Template
I. Creating a virtual template
2-1
Table 2-1 Create/delete a virtual template
Operation Command
Create a virtual template and enter its view. interface virtual-template number
undo interface virtual-template
Delete the specified virtual template.
number
II. Setting the operating parameters of a virtual template
Compared with physical interfaces, virtual templates only support PPP at the link layer
and IP and IPX at the network layer. When configuring a virtual template, you need to
perform the following tasks:
Set the operating parameters of PPP
Assign an IP address to the virtual template
Configure the IP address or address pool for address allocation
2.2.2 Enabling/Disabling PPPoE Server

The commands in the following table concern Ethernet interfaces and are only valid for
corresponding Ethernet interfaces. More specifically, While PPPoE is enabled on an
Ethernet interface, it is not accordingly enabled on other Ethernet interfaces. Likewise,
when PPPoE is disabled on an Ethernet interface, it is not necessarily disabled on
other Ethernet interfaces.
Note: Before beginning the configuration in Table 2-1, you have to finish the
configuration of the virtual template interface. For detailed description of the
virtual-template, please refer to the section of Virtual Interface Configuration.
Table 2-2 Enable/disable PPPoE
Operation Command
pppoe-server bind virtual-template
Enable PPPoE on Ethernet interface
number
Disable PPPoE on Ethernet interface undo pppoe-server bind
Where, number is the number of virtual-template.

By default, PPPoE is disabled.
2.2.3 Configuring PPPoE Server Parameters
You may configure PPPoE server parameters as needed. Normally, you can use the
default settings.
2-2
Table 2-3 Configure PPPoE server parameters
Operation Command
pppoe-server max-sessions
PPPoE sessions allowed to be set up
remote-mac number
with a remote MAC address
undo pppoe-server max-sessions
PPPoE sessions allowed to be set up
remote-mac
with a remote MAC address
pppoe-server max-sessions
PPPoE sessions that a local MAC
local-mac number
address is allowed to set up
PPPoE sessions that a local MAC
local-mac
address is allowed to set up
pppoe-server max-sessions total
PPPoE sessions that the current system
number
is allowed to set up
PPPoE sessions that the current system
total
is allowed to set up
2.2.4 Enabling/Disabling the PPPoE Server to Output PPP-Related Log
To avoid decreased device performance due to excessive log output, you can disable
the PPPoE server to output log information.
Table 2-4 Disable/enable the PPPoE server to output PPP-related log information
Operation Command
Disable the PPPoE server to output
pppoe-server log-information off
PPP-related log information
Enable the PPPoE server to output undo pppoe-server log-information
PPP-related log information off
By default, the PPPoE server output the PPP-related information.
2.3 Displaying and Debugging PPPoE Server

After finishing the above configuration, execute the display commands in all views to
view the running state of the PPPoE configuration and to verify the effect of the
configuration.
2-3
Table 2-5 Displaying and debugging PPPoE server
Operation Command
Display the status and statistics of display pppoe-server session { all |
PPPoE sessions packet }
In the table, the parameter all indicates to display all information of each session,
packet indicates to display packet statistics of each session.
2.4 PPPoE Configuration Example

In Figure 2-1, the hosts access the Internet through the firewall SecPath by making use
of PPPoE.
II. Network diagram
Firewall SecPath is connected to the Ethernet through the interface Ethernet 1/0/0 and
the Internet through Serial3/0/0.
Ethernet 1/0/0
Host
Internet
Ethernet 3/0/0
SecPath
Host
Figure 2-1 PPPoE network diagram
# Add a PPPoE user.

[H3C] local-user NE
[H3C-luser-NE] password simple pwd
[H3C-luser-NE] service-type ppp
# Configure PPPoE parameters on the firewall.

2-4
# Configure virtual-template parameters on the firewall.

[H3C-Virtual-Template1] ppp authentication-mode chap domain system
[H3C-Virtual-Template1] ppp chap user NE
[H3C-Virtual-Template1] remote address pool 1
# Configure the users in the domain to use the local authentication scheme.
[H3C] domain system
# Add a local IP address pool containing nine IP addresses.

[H3C-isp-system] ip pool 1 1.1.1.2 1.1.1.10
When installed with PPPoE client software and configured with user name and
password, every host on the Ethernet can access the Internet through the firewall with
PPPoE.
If radius-scheme or hwtacacs-scheme is configured for authentication, the SecPath
firewall may also be configured with RADIUS/HWTACACS parameters, thus enabling
the system to charge. For detailed configuration procedures, please refer to the
Chapter “Security” in this manual.
2-5
H3C SecPath Series Security Products Chapter 3 PPPoE Client Configuration
Chapter 3 PPPoE Client Configuration
3.1 Introduction to PPPoE Client

I. Overview
PPPoE is the abbreviation for Point-to-Point Protocol over Ethernet. It connects an

Ethernet host to a remote access concentrator via a simple bridging device. Through
PPPoE, a remote access device can realize control and accounting over each
accessing user. Compared with traditional access method, PPPoE has higher
performance-price ratio and is therefore widely assumed in applications like community
networking. It is also adopted in the currently popular broadband access mode ADSL.
PPPoE employs a client/server mode, in which it encapsulates PPP packets into
Ethernet frames to provide point-to-point connections over the Ethernet.
PPPoE has two different phases: Discovery phase and PPP Session phase.
z Discovery phase
To initiate a PPP session, a host must first enter the Discovery phase to acknowledge
the peer's Ethernet MAC address and create a PPPoE Session ID. Whereas PPP
establishes a peer correlation, PPPoE however establishes a client/server correlation
in the Discovery phase. During the Discovery phase, a host (client) can discover an
access concentrator (server). After the Discovery phase, the host and the concentrator
can establish PPPoE session via the MAC address and session ID.
z PPP Session phase
At the beginning of the PPP Session phase, the host and access concentrator transmit
PPP data and perform various PPP negotiations and data transfer over PPP. PPP
packets, as the payload of PPPoE frames, are encapsulated into Ethernet frames and
sent to the peer of a PPPoE link. In this case, all Ethernet frames are transmitted by
unicast.
For more information about PPPoE, refer to RFC2516.
II. Introduction to the PPPoE client
PPPoE is widely used in ADSL broadband access applications. Generally speaking, a

host must be installed with PPPoE client dialing software in order to access the Internet
via ADSL. SecPath series firewalls perform the PPPoE client function (namely the
PPPoE client dialing function), by which the user can access the Internet without
installing any client dialing software on his PC. Moreover, all PCs on the same LAN can
share the same ADSL account.
3-1
PC PC
Ethernet
PPPoE C lient
ADSL M odem
PPPoE Session
PPPoE Serv er
Figure 3-1 Typical PPPoE network diagram
In the above figure, the PCs are connected to a SecPath firewall running the PPPoE
client. On-line data reach the firewall before being encapsulated via PPPoE. The ADSL
Modem attached to the firewall reaches the ADSL access server and finally access the
Internet. In this way, the Internet accessing is realized without additionally installing
PPPoE client dialing software by the user.
3.2 Configuring the PPPoE Client

Fundamental PPPoE configuration tasks include:
z Configure a dialer interface
z Configure a PPPoE session
Advanced PPP configuration task includes:
z Terminate a PPPoE session
3.2.1 Configuring a Dialer Interface
Before configuring PPPoE session, you should first configure a dialer interface and
configure a dialer bundle on the interface. Each PPPoE session uniquely corresponds
to a dialer bundle and each dialer bundle uniquely corresponds to a dialer interface.
Thus, a PPPoE session can be created via a dialer interface.
Execute the dialer-rule and interface dialer commands in system view, and execute
other commands below in dialer interface view.
3-2
Table 3-1 Configuring a Dialer interface
Operation Command
dialer-rule dialer-group { protocol-name
Configure a Dialer Rule
{ permit | deny } | acl acl-number }
Create a dialer interface interface dialer number
Set a remote user name dialer user username
ip address { address mask |
Configure IP address of the interface.
ppp-negotiate }
Configure the Dialer Bundle on an
dialer bundle bundle-number
interface
Configure the Dialer Group on an
dialer-group group-number
interface
PPPoE only supports Resource-Shared DCC. As needed, such parameters as PPP

authentication may also be necessarily configured on a dialer interface. For more
information on how to configure a dialer interface, refer to the chapter discussing DDD
configurations in the “Dial-up” part of this manual.
3.2.2 Configuring a PPPoE Session
PPPoE session can be configured on a physical Ethernet interface or a virtual Ethernet

(VE) interface created on an ADSL interface. When a firewall is to be linked to the
Internet through an ADSL interface, it is necessary to configure PPPoE session on the
virtual Ethernet interface; when a firewall is to be linked to an ADSL Modem and then
the Internet via an Ethernet interface, it is necessary to configure the PPPoE session
on the Ethernet interface.
Configure a virtual Ethernet interface in system view and PPPoEoA mapping in PVC
view.
Table 3-2 Configuring a virtual Ethernet interface
Operation Command
Create a virtual Ethernet interface interface virtual-ethernet number
Delete the virtual Ethernet interface undo interface virtual-ethernet number
Perform the following configuration in Ethernet interface view or virtual Ethernet

interface view.
3-3
Table 3-3 Configuring a PPPoE session
Operation Command
Configure PPPoE session (always-on pppoe-client dial-bundle-number
mode) number [ no-hostuniq ]
pppoe-client dial-bundle-number
Configure PPPoE session (packet
number [ no-hostuniq ] idle-timeout
triggering mode)
seconds [ queue-length packets ]
undo pppoe-client
Delete PPPoE session
dial-bundle-number number
SecPath Series Firewalls support two kinds of PPPoE connection mode: always-on
mode and packet triggering mode.
z Always-on mode: When the physical line is UP, the firewall will quickly initiate
PPPoE call to create a PPPoE session. The PPPoE session will always exist
unless the user deletes it via the undo pppoe-client command.
z Packet triggering mode: When the physical line is UP, the firewall will not
immediately initiate PPPoE call. Only when there is data transmission requirement
will the firewall initiate PPPoE call to create a PPPoE session. If the free time of a
PPPoE link exceeds the value set by user, the firewall will automatically terminate
the PPPoE session.
3.2.3 Resetting/Deleting a PPPoE Session
Execute the reset pppoe-client command and the reset pppoe-server command in
user view and the undo pppoe-client command in Ethernet interface view or virtual
Ethernet interface view.
Table 3-4 Reset/delete a PPPoE session
Operation Command
Terminate a PPPoE session at the client reset pppoe-client { all |
end and recreate the session later dial-bundle-number number }
reset pppoe-server { all |
Terminate a session at the PPPoE
virtual-template number | interface
server end
interface-type interface-num }
Terminate a PPPoE session at the client undo pppoe-client
end and never recreate it again dial-bundle-number number
The difference between the reset pppoe-client command and the undo pppoe-client
command lies in: The former only temporarily terminates a PPPoE session, while the
latter permanently deletes a PPPoE session.
3-4
When a PPPoE session works in permanent on-line mode, if it is terminated by the

reset pppoe-client command, the firewall will automatically recreate a PPPoE session
in 16 seconds. When a PPPoE session works in packet triggering mode, if it is
terminated via the reset pppoe-client command, the firewall will recreate a PPPoE
session only upon data transmission.
No matter a PPPoE session works in permanent on-line mode or in packet triggering
mode, it will be deleted permanently by the undo pppoe-client command. If it is
necessary to recreate a PPPoE session, the user must reconfigure it.
3.3 Displaying and Debugging the PPPoE Client

Execute the display command in all views and the debugging command in user view.
Table 3-5 Displaying and Debugging the PPPoE client
Operation Command
display pppoe-client session
Display the status and statistics of a
{ summary | packet }
PPPoE session
[ dial-bundle-number number ]
debugging pppoe-client { all | data |
Enable the PPPoE client debugging error | event | packet | verbose }
[ interface type number ]
3.4 Typical PPPoE Client Configuration Example

3.4.1 Typical PPPoE Client Configuration Example
SecPath1 and SecPath2 are connected using interface Ethernet1/0/0. SecPath1

authenticates SecPath2 using PAP or CHAP.
II. Network diagram
e1/0/0 e1/0/0
SecPath1 SecPath2
Figure 3-2 Network diagram for PPPoE client
When PAP authentication applies, configure the firewalls as follows:

3-5
# Add a PPPoE user.

# Configure the parameters of the virtual template.

[H3C-Virtual-Template1] ppp authentication-mode pap
# Configure PPPoE server.

[H3C-Dialer1] ppp pap local-user secpath2 password simple pwd
# Configure a PPPoE session.

When CHAP authentication applies, configure the firewalls as follows:

# Add a PPPoE user.
# Configure the parameters of the virtual template.

[H3C-Virtual-Template1] ppp authentication-mode chap
[H3C-Virtual-Template1] ppp chap user secpath1
# Configure PPPoE server.

3-6

[H3C-Dialer1] ppp chap user secpath2
[H3C-Dialer1] ppp chap password simple pwd
[H3C-Dialer1] quit

3.4.2 Connecting a LAN to the Internet Through an ADSL Modem
The PCs in the LAN access the Internet through SecPath A, which connects to the
DSLAM using an ADSL line in always-on mode. The ADSL account has a username of
"adsluser" and a password of 123456". As the PPPoE server, SecPath B connects to
DSLAM through the Eth2/0/0 interface and provides RADIUS authentication and
accounting function. Enable the PPPoE client on the firewall and all hosts in the LAN
can access to the Internet without having to install any PPPoE client software.
II. Network diagram
PC PC PC
LAN
1 9 2 .1 6 8 .1 .1 Eth 0 /0 /0
Se cPa th A
Eth 2 /0 /0
AD SL Mo d e m
Se cPa th B
Eth 2 /0 /0
Inte r n et
Figure 3-3 Connecting a LAN to the Internet through ADSL
3-7
1) Configure SecPath A
# Configure a Dialer interface.
[H3C-Dialer1] dialer user secpathb
[H3C-Dialer1] ppp pap local-user adsluser password cipher 123456

# Configure a LAN interface and the default route.

[H3C] ip route-static 0.0.0.0 0 dialer 1
If the IP addresses of the PCs in the LAN are private addresses, it is necessary to
configure NAT (Network Address Translation) on the firewall. The NAT configuration
will not be elaborated here. For details, refer to the part about NAT configuration in the
Security module of this manual.
2) Configure SecPath B
# Add a PPPoE user
[H3C] local-user adsluser
[H3C-luser-adsluser] password simple 123456
[H3C-luser-adsluser] service-type ppp
# Configure virtual template parameters on the SecPath B:

[H3C-Virtual-Template1] ppp authentication-mode pap scheme default
# Configure the PPPoE parameter on the SecPath B:

# Configure domain users to use the local authentication scheme

[H3C] domain system
[H3C-isp-domain] scheme radius-scheme cams
3-8
# Add a local IP address pool with nine IP addresses

[H3C] ip pool 1 1.1.1.2 1.1.1.10
# Configure RADIUS scheme

[H3C] radius scheme cams
[H3C-radius-cams] primary authentication 10.110.91.146 1812
[H3C-radius-cams] primary accounting 10.110.91.146 1813
[H3C-radius-cams] key authentication expert
[H3C-radius-cams] key accounting expert
[H3C-radius-cams] server-type extended
[H3C-radius-cams] user-name-format with-domain
[H3C-radius-cams] quit
See related materials for detailed configuration of RADIUS server.
3-9
H3C SecPath Series Security Products Chapter 4 VLAN Configuration
Chapter 4 VLAN Configuration
4.1 Introduction to VLAN

Ethernet is a kind of data network communication technology, which is based on the
shared communication medium of CSMA/CD (Carrier Sense Multiple Access with
Collision Detection). Under CSMA/CD, each node will use the shared medium to send
out frames in turn. Thus, in one moment, only one host can send out frames while other
hosts can only receive frames.
When many hosts are connected to the hub (with star architecture) through the twisted
pairs, or connected together by the coaxial cables (with bus architecture), all the hosts
interconnected to the shared physical media forms a physically collision domain, which
is usually considered as a LAN segmentation. According to the Ethernet principles
mentioned above, it can be concluded that the following problem exists in connecting
LAN through hub: excessive hosts can cause severe collision, broadcast storm and
affect the performance of the net or even make the net unusable.
The above problems can be solved by using the transparent bridge or LAN Switch to
interconnect the LANs. The switch establishes a MAC-PORT mapping table with the
source MAC addresses of frames received. For the received data frames, the switch
will look up their destination MAC addresses in the mapping table. If it can find a match,
it will only send the frames to the corresponding ports; if not, it will forward them to all
ports except for the receiving port. In this way, the collision domains are separated in
their own ports and will not extend to other ports. The switch, as a kind of transparent
device, does not change the source and destination addresses of the Ethernet frames,
but forwards them to the proper LAN segmentations. The switch usually uses the
special ASIC chip to implement the bridge switching. Although the switch has solved
the problem of severe collision from hub adoption, it still cannot separate the broadcast.
In fact, all the hosts (perhaps including many switches) interconnected by switches are
in one broadcast domain. For the broadcast packets with full "F" (0xffffff) as their
destination MAC address, such as ARP request packet, the switch will forward them to
all the ports. In this case, the broadcast storm will be caused and the performance of
the entire network will deteriorate.
The technology of VLAN (Virtual Local Area Network) comes into being to solve the
problem of broadcast restriction that switches cannot achieve in performing LAN
interconnection. By use of VLAN technology, one LAN is divided into several logical
"LANs" (VLANs), each indicating a broadcast domain. In each VLAN, the hosts can
communicate with each other just as they are in a LAN, but the VLANs cannot interact
with one another directly. Therefore, the broadcast packets are restricted in one VLAN,
as shown in the following figure:
4-1
VLAN A
LAN Switch
VLAN B
VLAN A
LAN Switch VLAN A

VLAN B
VLAN B
SecPath
Figure 4-1 Example of VLAN
The buildup of VLAN is not restricted by physical locations, that is to say, one VLAN can
spread within one switch or across switches, or even across routers.
VLAN can be classified in several ways, such as the classifications based on the port,
on MAC address, on protocol type, on IP address mapping, on multicast, and on the
policy. At present, the generally accepted classification method is based on the port. In
this manual, the VLANs are all based on the port except otherwise noted.
The advantages of using VLAN are:
z It can restrict broadcast packets (broadcast storm), save the bandwidth and thus
improve the processing ability of the network. The Broadcast Domain is restricted
in one VLAN and the switch would not directly send frames from one VLAN to
another except that it is a layer-3 switch.
z It can enhance the security of LAN. VLANs cannot directly communicate with one
another, that is, the users in one VLAN cannot directly access those in other
VLANs. They need help of such layer 3 devices as routers or Layer 3 switches to
fulfill the access.
z It provides virtual workgroups. VLAN can be used to group different users to
different workgroups. When the workgroups change, the users need not change
their physical locations. In the practical application, users of the same workgroup
usually cooperate with each other at the same place, and rarely at different places.
On a switch, the common ports can only belong to one VLAN, that is, they can only
identify and send packets of the VLAN they belong to. However when the VLAN is
across switches, it is necessary that the ports (links) among the switches can
concurrently identify and send packets of several VLANs. The same problem exists
among the switches and routers that support VLAN. The link of this type is called Trunk,
which has two meanings: one meaning is "relay", i.e., transparently transmitting the
4-2
VLAN packets to the interconnected switches or routers so as to extend the VLAN; the
other meaning is "main line", i.e., transmitting the data of several VLANs on one link.
The common protocol used to implement Trunk is IEEE802.1Q (dot1q), a standard
protocol of IEEE. It identifies the VLAN through adding a 4-byte VLAN TAG to the end
of the source address field in the original Ethernet packet.
VLANs cannot directly interconnect with each other and routers supporting VLAN must
be used to connect each VLAN to implement the interconnection among VLANs.
Usually, this is a kind of layer 3 (IP layer) interconnection.
SecPath series firewall support the VLAN application.
4.2 Basic VLAN Configuration

Perform the following configuration in system view or Ethernet subinterface view.
Table 4-1 Basic VLAN configuration
Operation Command
Create an Ethernet subinterface and interface subinterface-type
enter its view (in system view) interface-number
Set the IP address of an Ethernet
ip address ip-address ip-mask
subinterface (in interface view)
Set the encapsulation type of an
Ethernet subinterface or a gigabit
vlan-type dot1q vid vid
Ethernet subinterface and related VLAN
ID (in interface view)
Set the maximum number of packets
processed by a VLAN per second (in max-packet-process count vid
system view)
packets processed by a VLAN per undo max-packet-process vid
second (in system view)
By default, there is no encapsulation mode on the system subinterface, nor is there

VLAN ID associated with the subinterface, nor the limit of maximum number of
processed packets.
4.3 Displaying and Debugging VLAN

After finishing the above configurations, execute the display commands in any view to
view the running state information of the VLAN configuration for verifying the effect of
the configuration.
Execute the reset command in user views to clear the running statistics.
4-3
Table 4-2 Displaying and debugging VLAN
Operation Command
Display the maximum number of
processed packets configured on a display vlan max-packet-process vid
specified VLAN
Display the packet statistics of the
specified VLAN, including the received display vlan statistics vid vid
and sent packet numbers
Display the VLAN configuration display vlan interface interface-type
information on an interface interface-num
Clear the packet statistics of specified
reset vlan statistics vid vid
VLAN
4.4 Typical VLAN Configuration Example

The following is a configuration example of layer-3 transmission (via subinterfaces). As

shown in the following figure, the VLAN attributes of ports are specified on Switch 1 and
Switch 2, thus the workstations A, B, C and D connected to these Switches belong to
VLAN 10 or VLAN 20. The following is required:
z The addresses of subinterfaces Ethernet 3/0/0.1, Ethernet3/0/0.2, Ethernet4/0/0.1,
and Ethernet4/0/0.2 are 1.0.0.1, 2.0.0.1, 3.0.0.1, and 4.0.0.1 respectively.
z Communication is available between workstations A and B as well as between C
and D, that is, workstations in different VLANs can communicate with each other
through the same Switch.
z Communication is available between workstations A and C, as well as between B
and D, that is, workstations in the same VLAN can communicate with each other
through different Switches.
z Communications can be carried out between workstations A and D, and between
B and C, that is, different switches and different VLANs can communicate with
each other.
4-4
II. Network diagram
Internet
eth 4/0/0.2
4.0.0.1/8 LAN Sw itch
SecPath VLAN 20
eth 4/0/0.1
3.0.0.1/8
eth3/0/0.1
1.0.0.1/8 eth3/0/0.2 VLAN 10
2.0.0.1/8 C D
VLAN 10
VLAN 20 VLAN10 VLAN 20
3.3.3.3/8 4.4.4.4/8
LAN Sw itch
A B
VLAN10 VLAN 20
1.1.1.1/8 2.2.2.2/8
Figure 4-2 VLAN network diagram of L3 switching mode
Configure the firewall.

# Create Ethernet subinterfaces (Ethernet 3/0/0.1, Ethernet 3/0/0.2, Ethernet 4/0/0.1,
and Ethernet 4/0/0.2 as shown in the figure) and enter their views to configure their IP
addresses. Set the encapsulation type of each subinterface (The encapsulation type of
the Ethernet subinterface must keep consistent with what configured on the switch port)
and the associated VLAN ID.
Note: After configuring the encapsulation type of the Ethernet subinterface, the
subinterface is set as permitted trunk.
<H3C> system-view
[H3C] interface ethernet 3/0/0.1
[H3C-Ethernet3/0/0.1] ip address 1.0.0.1 255.0.0.0
[H3C-Ethernet3/0/0.1] vlan-type dot1q vid 10
4-5
# Set the maximum number of packets that VLAN10 can process into 100000 per
second and that VLAN20 can process into 200000 per second.
[H3C] max-packet-process 100000 10
[H3C] max-packet-process 200000 20
4-6
Network Layer Protocol
Operation Manual – Network Layer Protocol
Table of Contents
Chapter 1 IP Address Configuration ........................................................................................... 1-1

1.1 IP Address Overview ......................................................................................................... 1-1
1.2 IP Address Configuration................................................................................................... 1-4
1.2.1 Configuring IP Address for an Interface.................................................................. 1-4
1.2.2 Configuring IP Address Unnumbered for an Interface ............................................ 1-7
1.2.3 Displaying and Debugging IP Address ................................................................... 1-8
1.2.4 Displaying and Debugging IP Address Unnumbered.............................................. 1-8
1.2.5 IP Address Configuration Example ......................................................................... 1-9
Chapter 2 IP Application Configuration ...................................................................................... 2-1

2.1 ARP Configuration ............................................................................................................. 2-1
2.1.1 Brief Introduction to Dynamical ARP....................................................................... 2-1
2.1.2 Brief Introduction to Static ARP............................................................................... 2-1
2.1.3 Static ARP Configuration ........................................................................................ 2-1
2.1.4 Enabling/Disabling ARP Entry Check ..................................................................... 2-1
2.1.5 Enabling/Disabling ARP Request in the Scope of Natural Network Segments ...... 2-2
2.1.6 Proxy ARP Configuration ........................................................................................ 2-2
2.1.7 Configuring Gratuitous ARP.................................................................................... 2-4
2.1.8 Displaying and Debugging ARP.............................................................................. 2-5
2.2 Domain Name Resolution Configuration ........................................................................... 2-6
2.2.1 DNS Overview......................................................................................................... 2-6
2.2.2 Configuring Static Domain Name Resolution.......................................................... 2-7
2.2.3 Displaying and debugging domain name resolution table ...................................... 2-7
2.3 DNS Client Configuration................................................................................................... 2-7
2.3.1 Configuring the DNS Client ..................................................................................... 2-9
2.3.2 Displaying and Debugging DNS Client Information .............................................. 2-10
2.3.3 Typical DNS Configuration Example..................................................................... 2-11
2.3.4 Troubleshooting..................................................................................................... 2-12
2.4 DNS Proxy Configuration................................................................................................. 2-12
2.4.1 Overview ............................................................................................................... 2-12
2.4.2 DNS Proxy Configuration ...................................................................................... 2-13
2.4.3 DNS Proxy Configuration Example ....................................................................... 2-13
2.5 URPF Configuration......................................................................................................... 2-15
2.5.1 URPF Overview..................................................................................................... 2-15
2.5.2 URPF Configuration .............................................................................................. 2-16
2.5.3 URPF Display and Debugging .............................................................................. 2-16
Chapter 3 UDP Helper Configuration .......................................................................................... 3-1

3.1 Introduction to UDP Helper................................................................................................ 3-1
i
3.2 UDP Helper Configuration ................................................................................................. 3-1

3.2.1 Enabling/Disabling UDP Helper .............................................................................. 3-1
3.2.2 Specifying by UDP Port Number which UDP Broadcasts are forwarded ............... 3-2
3.2.3 Configuring Destination Servers ............................................................................. 3-3
3.3 Displaying and Debugging the UDP Helper Configuration ................................................ 3-3
Chapter 4 BOOTP Client Configuration ...................................................................................... 4-1

4.1 Introduction to BOOTP Client ............................................................................................ 4-1
4.2 BOOTP Client Configuration.............................................................................................. 4-1
4.2.1 Configuring an Ethernet Interface to Obtain IP Address Using BOOTP................. 4-1
4.3 Displaying and Debugging BOOTP Client Configuration .................................................. 4-2
Chapter 5 DHCP Configuration .................................................................................................... 5-1

5.1 DHCP Overview................................................................................................................. 5-1
5.1.1 DHCP ...................................................................................................................... 5-1
5.1.2 DHCP Server........................................................................................................... 5-2
5.1.3 Introduction to DHCP Accounting ........................................................................... 5-5
5.1.4 BIMS Option for DHCP Server................................................................................ 5-7
5.1.5 Option 184 for DHCP Server................................................................................... 5-8
5.1.6 DHCP Relay ............................................................................................................ 5-9
5.2 DHCP Common Configuration......................................................................................... 5-11
5.2.1 Enabling/Disabling DHCP ..................................................................................... 5-11
5.2.2 Configuring Pseudo-DHCP Server Detection ....................................................... 5-11
5.3 Configuring DHCP Server................................................................................................ 5-12
5.3.1 Setting Interfaces to Operate in DHCP Server Mode ........................................... 5-13
5.3.2 Adding Global DHCP Address Pool ...................................................................... 5-14
5.3.3 Defining Allocation Mode of DHCP Address Pool................................................. 5-15
5.3.4 Excluding IP Address from Auto Allocation........................................................... 5-17
5.3.5 Defining IP Address Lease Expiry Limit................................................................ 5-17
5.3.6 Configuring Domain Name for DHCP Client ......................................................... 5-18
5.3.7 Configuring DNS IP Address for DHCP Client...................................................... 5-19
5.3.8 Configuring NetBIOS IP Address for DHCP Client ............................................... 5-20
5.3.9 Defining NetBIOS Node Type for DHCP Client .................................................... 5-21
5.3.10 Configuring DHCP Customization Items............................................................. 5-23
5.3.11 Configuring Egress Gateway for DHCP Client.................................................... 5-23
5.3.12 Configuring ping Packet Transfer in DHCP Server............................................. 5-24
5.3.13 Configuring DHCP Server Accounting ................................................................ 5-25
5.3.14 Configuring BIMS Option for DHCP Server ........................................................ 5-26
5.3.15 Configuring Option 184 for DHCP Server ........................................................... 5-27
5.3.16 Clearing DHCP Information................................................................................. 5-31
5.4 DHCP Client Configuration .............................................................................................. 5-32
5.5 DHCP Relay Configuration .............................................................................................. 5-32
5.5.1 Setting Interfaces to Operate in DHCP Relay Mode............................................. 5-33
5.5.2 Specifying External DHCP Servers....................................................................... 5-34
ii
5.5.3 Configuring DHCP Server Load Balancing by DHCP Relay................................. 5-34

5.5.4 Releasing Client IP Address by DHCP Relay ....................................................... 5-35
5.5.5 Clearing DHCP Relay Statistics Information......................................................... 5-35
5.6 Displaying and Debugging DHCP.................................................................................... 5-36
5.7 DHCP Configuration Examples ....................................................................................... 5-38
5.7.1 DHCP Server Configuration Examples ................................................................. 5-38
5.7.2 DHCP Relay Configuration Examples .................................................................. 5-39
5.7.3 DHCP Client Configuration Examples .................................................................. 5-40
5.7.4 DHCP Accounting Configuration Example............................................................ 5-42
5.7.5 Configuration Example of IP Phone’s Request for Option 184............................. 5-43
Chapter 6 IP Performance Configuration.................................................................................... 6-1

6.1 Configuring Maximum Transmission Unit (MTU)............................................................... 6-1
6.2 Configuring TCP Packet Fragmentation............................................................................ 6-1
6.3 Configuring TCP Attributes ................................................................................................ 6-1
6.4 Configuring ICMP to Send Redirection Packets................................................................ 6-2
6.5 Displaying and Debugging IP Performance....................................................................... 6-3
6.6 Configuring Fast Forwarding ............................................................................................. 6-5
6.6.1 Brief Introduction to Fast Forwarding ...................................................................... 6-5
6.6.2 Configuring Fast Forwarding................................................................................... 6-5
6.6.3 Displaying and Debugging Fast Forwarding ........................................................... 6-7
6.7 IP Performance Configuration Troubleshooting ................................................................ 6-7
Chapter 7 IP Unicast Policy Routing Configuration .................................................................. 7-1

7.1 IP Unicast Policy Routing Overview .................................................................................. 7-1
7.2 IP Unicast Policy Routing Configuration ............................................................................ 7-2
7.2.1 Establishing a Route-Policy .................................................................................... 7-2
7.2.2 Defining the if-match Clause of Policy Routing....................................................... 7-3
7.2.3 Defining the apply Clause of Policy Routing ........................................................... 7-3
7.2.4 Enabling or Disabling Local Policy Routing ............................................................ 7-4
7.2.5 Enabling or Disabling Policy Routing on the Interface ............................................ 7-4
7.3 Displaying and Debugging IP Unicast Policy Routing ....................................................... 7-4
7.4 Typical Configuration of IP Unicast Policy Routing ........................................................... 7-5
7.4.1 Configuring Policy Routing Based on Source Address........................................... 7-5
7.4.2 Configuring Policy Routing Based on Packet Size ................................................. 7-7
iii
H3C SecPath Series Security Products Chapter 1 IP Address Configuration
Chapter 1 IP Address Configuration
1.1 IP Address Overview

IP addresses are unique 32-bit addresses assigned to hosts connected to Internet. An
IP address is composed of two parts: network ID and host ID. Its structure enables
convenient addressing on Internet. IP addresses are assigned by Network Information
Center (NIC) of American National Defense Data Network.
IP address consists of the following fields:
z Network ID field (net-id), among which the former bits are called the category field
(or category bits) used to distinguish the types of IP addresses.
z Host ID field (host-id). Since host number with all 1s or 0s has special usage, it is
specified that the host number should not be all 1s or 0s.
For easy IP address management and convenient networking, IP address of Internet is
divided into five classes. As shown in the following diagram:
01234 8 16 24 31
0 net-id host-id
Class A
Class B 1 0 net-id host-id
Class C 1 10 net-id host-id
Class D 1 110 Multicast address
Class E 1 1 1 10 Reserved for future use
net-id — Network number host-id — Host number
Figure 1-1 Classification of IP address
Address of class D is a multicast address, mainly used by IAB (Internet Architecture

Board). Address of class E is reserved for future use. At present, most IP addresses are
class A, class B and class C.
When using IP addresses, it should also be noted that some of them are reserved for
special uses, and are seldom used. The IP addresses you can use are listed in the
following table.
1-1
Table 1-1 IP address classes and ranges
Network class Address range IP network range Description

Network ID with
the format of
127.X.Y.Z is
reserved for
self-loop test and
the packets sent to
0.0.0.0 to 1.0.0.0 to this address will
A
127.255.255.255 126.0.0.0 not be output to
the line. The
packets are
processed
internally and
regarded as input
packets.
128.0.0.0 to 128.0.0.0 to
B —
191.255.255.255 191.254.0.0
192.0.0.0 to 192.0.0.0 to
C —
223.255.255.255 223.255.254.0
Addresses of class
224.0.0.0 to
D None D are multicast
239.255.255.255
addresses.
255.255.255.255
is used as LAN
broadcast
240.0.0.0 to
E None address. The other
255.255.255.255
addresses are
reserved for future
use.
Important features of IP address:

z IP addresses are not in a hierarchical structure, which is different from the
structure of telephone number. In other words, IP addresses cannot reflect any
geographical information about the host position.
z When a host is connected to two networks at the same time, it must have two IP
addresses with different net-ids corresponding to two different networks. Such
host is called multi-homed host.
z According to Internet concept, several LANs connected via transceiver or bridge
are still in the same network, so these LANs have the same net-id.
z With respect to IP address, all networks with a net-ids are equal (no matter it is a
small LAN or a huge WAN).
Since 1985, only the net-id of IP address is assigned by NIC, while the host-id is
controlled by the enterprise. The IP address assigned to an enterprise is only a network
ID: net-id. The specific host Ids, the host-ids for respective hosts, shall be assigned by
1-2
the enterprise independently, so long as there is no repetition of host IDs within its
network.
If there are many enterprise hosts widely scattered, the host IDs may be further divided
into internal sub-nets to facilitate management. Note that the division of sub-nets is
completely internal to the enterprise itself, and seen from the outside, the enterprise
only has one net-id. When an external packet enters this enterprise network, the
internal device can route according to the sub-net number, and finally reach the
destination host.
The following figure shows the sub-net classification of a Class B IP address, in which a
sub-net mask consists of a string of continuous "1" s and a string of continuous "0" s.
The 1s corresponds to the network ID field and the sub-net number field, while the 0s
correspond to the host ID field.
Local distribution
net-id host-id
Class B address
(a)
Subnet ID Host ID
Add subnet
net-id Subnet-id
- host-id
number field
(b)
Subnet mask 11111111 11111111 111111 00 00000000
(c)
Figure 1-2 Sub-net classification of IP address
Classification of one more sub-net number field is at a price. For example, an IP

address of class B originally consists of 65534 (216-2) host IDs. However, after a
6-bit-long sub-net field is classified, there may be at most 64 sub-nets. Each sub-net
has 10-bit host ID, i.e., each sub-net has 1022 host IDs at most. There are 64 x
1022=65408 host IDs in total, 126 less than the sum before sub-net classification.
If there is no sub-net division in an enterprise, then its sub-net mask is the default value
and the length of "1" indicates the net-id length. Therefore, for IP addresses of classes
A, B and C, the default values of corresponding sub-net mask are 255.0.0.0,
255.255.0.0 and 255.255.255.0 respectively.
A firewall used to connect multiple sub-nets together will have multiple sub-net IP
addresses.
The IP addresses mentioned above cannot be directly used in communication,
because:
z An IP address is only an address of a host in the network layer. To send the data
packets transmitted through the network layer to the destination host, physical
1-3
address of the host is required. So the IP address must be first resolved into a
physical address.
z IP address is hard to remember, but a host domain name will be much easier to
remember and is also more popular. So the host domain name must also be
resolved into an IP address.
The following figure illustrates relations among host name, IP address and physical
address.
net-id=209.0.0.0
Host name PC
host-a

IP=209.0.05
Host name
host-b host-b

Destination
host name
DNS IP=209.0.06
Destination Network adapter

host IP address
209.0.0.6 08002B00EE 0A
ARP
Destination
host physical address
08002B00EE0A
Figure 1-3 Relation between host name, IP address, and physical address
1.2 IP Address Configuration

IP Address Configuration includes:
z Configure IP Address for an Interface
z Configure Unnumbered IP Address for an Interface
1.2.1 Configuring IP Address for an Interface
Each interface of a firewall can have several IP addresses, among which one is the
master IP address and the others are slave IP addresses.
The configuration of IP addresses supports the following applications:
z Father interfaces and sub-interfaces must not reside on the same network
segment.
z Peer interfaces must not reside on the same network segment.
z Master and slave IP addresses can be in the same network segment.
1-4
I. Configuring master IP address of an interface
For each interface, multiple IP addresses can be configured, among which one is the
master IP address and the rest are slave IP addresses. In the interface view, the
following commands can be used to modify the master IP address of the interface and
the subnet mask.
Table 1-2 Configure master IP address of an interface
Operation Command
Configure master IP address of an interface ip address ip-address net-mask
Use a mask net-mask to identify the network ID contained in an IP address. Example:

the IP address of an Ethernet interface of a firewall is 129.9.30.42, and the mask is
255.255.0.0. Logic AND the IP address with the mask, the network ID of the firewall's
Ethernet interface will be given out: 129.9.0.0.
When configuring a master IP address, if an IP address has already been configured on
the interface, the original master IP address will be replaced by the new one.
An interface can have only one master IP address. When deleting IP addresses of an
interface, if no IP address is specified, then all its IP addresses (including all slave IP
addresses) are deleted, otherwise only the specified IP address is deleted.
When there is at least one slave IP address, the master IP address cannot be deleted.
Before the master IP address is deleted, all the slave IP addresses must be deleted.
II. Configuring slave IP address of an interface
Besides the master IP address, several slave IP addresses can be configured on an

interface. The purpose of assigning slave IP addresses is to have the same interface
located in different sub-nets, to create network routes with the same interface as the
output port, and set up connection via the same interface to multiple sub-nets.
Table 1-3 Configure a subaddress on an interface
Operation Command
Configure a subaddress on an interface. ip address ip-address net-mask sub
By default, no subaddress is configured.

You can configure up to 32 addresses on an interface, including the main IP address
and subaddresses.
III. Deleting IP addresses on an interface
1-5
Table 1-4 Delete IP addresses on the interface
Operation Command
undo ip address [ ip-address net-mask
Delete IP addresses on the interface.
[ sub ] ]
To delete all IP addresses on the interface, execute this command without specifying
any argument.
To delete the main IP address, use the undo ip address ip-address net-mask
command.
To delete subaddresses, use the undo ip address ip-address net-mask sub
command.
Before you can delete the main IP address, you must delete all subaddresses.
IV. Setting negotiable attribute of an IP address for an interface
If a PPP-encapsulated interface is not assigned an IP address while its peer has been
assigned one, you may configure PPP address negotiation with the ip address
ppp-negotiate command to have it accept the address assigned by the peer. On the
peer, you must configure the remote address command. For example, when
accessing the Internet through an ISP, you may use the ip address ppp-negotiate
command to accept the addresses assigned by the ISP.
Table 1-5 Set negotiable attribute of IP address for an interface
Operation Command
Set negotiable attribute of IP address for
ip address ppp-negotiate
an interface
Cancel negotiable attribute of IP
undo ip address ppp-negotiate
address for an interface
Configure to assign IP address for the remote address { ip-address | pool
peer interface [ pool-number ] }
Disable to assign IP address for the peer
undo remote address
interface
1-6
Note:
z Because PPP supports IP address negotiation, IP address negotiation of an
interface can be set only when the interface is encapsulated with PPP. When the
PPP link is down, the IP address originated from negotiation will be deleted.
z If the interface has original address, then after setting IP address of the interface to
negotiable, the original IP address will be deleted.
z After setting IP address of an interface to negotiable, it is unnecessary to configure
IP address for the interface, as negotiation will automatically originate an IP
address.
z After setting IP address of an interface to negotiable, if the interface is set to
negotiable again, then the IP address originated from the original negotiation will be
deleted, and the interface obtains IP address through the re-negotiation.
z The interface will have no address after the negotiation address is deleted.
z The address of loopback interface can be borrowed by other interfaces, but it cannot
borrow the addresses of other interfaces.
1.2.2 Configuring IP Address Unnumbered for an Interface
I. Introduction to IP Address Unnumbered
The main purpose of borrowing IP address is to save IP address resource.

If an interface has no IP address, it can neither generate any route nor forward any
packet. "IP Address Unnumbered" is used when you want to use an interface with no IP
address. In such case, an IP address will be borrowed from another interface. If the
lending interface has multiple IP addresses, then only the master one can be borrowed.
However, if the lending interface has no IP address, then the IP address of the
borrowing interface is 0.0.0.0. This function is implemented through the command ip
address unnumbered.
The following should be noted:
1) The borrower cannot be an Ethernet interface.
2) The address of the lending interface cannot be an unnumbered address.
3) The lending interface can lend its address to multiple interfaces.
4) The loopback interface can lend its address to other interfaces, but it cannot
borrow the addresses from other interfaces.
II. Activating/deactivating IP Address Unnumbered
The configuration of IP Address Unnumbered can be performed in the interface view.

Encapsulated with PPP, the dialer interface, virtual template interface and tunnel
interface can borrow the IP address of Ethernet interface and other kinds of interfaces.
1-7
Table 1-6 Configure IP address unnumbered
Operation Command
ip address unnumbered interface
Activate IP Address Unnumbered
interface-type interface-number
Deactivate IP Address Unnumbered undo ip address unnumbered
By default, IP address unnumbered is not configured.
Caution:
After configuring the IP address unnumbered attribute on a tunnel interface, you need
to manually configure a static route to the peer interface of the tunnel and you are
recommended to configure the mask of this route to 32 bits to prevent packets from
being mistakenly routed.
1.2.3 Displaying and Debugging IP Address
After the above configuration, execute display command in all views to display the
running of the IP Address, and to verify the effect of the configuration.
Table 1-7 Display and debug IP address
Operation Command
Display IP-related information about the display ip interface [ interface-type
specified or all interfaces interface-number ]
Display IP-related summary about the display ip interface brief
specified or all interfaces [ interface-type interface-number ]
1.2.4 Displaying and Debugging IP Address Unnumbered
running of the IP Address Unnumbered, and to verify the effect of the configuration.
Table 1-8 Display and debug IP Address Unnumbered
Operation Command
Display information of IP Address display interface [ interface-type
Unnumbered [ interface-number ] ]
1-8
1.2.5 IP Address Configuration Example
To configure IP addresses for interface Ethernet1/0/1 of the firewall, it is required that

the primary IP address is 129.2.2.1, and the secondary IP address is 129.1.3.1.
II. Network diagram
Primary IP address: 129.2.2.1

Secondary IP address: 9.1.3.1
Internet
Ethernet1/0/1
SecPathA SecPathB
Figure 1-4 Configure the primary and secondary IP address for an interface of the
firewall
# Configure the primary and secondary IP address for interface Ethernet1/0/1 of the
firewall.
[H3C] interface Ethernet1/0/1
[H3C-Ethernet1/0/1] ip address 129.1.3.1 255.255.255.0 sub
1-9
H3C SecPath Series Security Products Chapter 2 IP Application Configuration
Chapter 2 IP Application Configuration
2.1 ARP Configuration

2.1.1 Brief Introduction to Dynamical ARP
ARP (Address Resolution Protocol) is mainly used for resolution from IP address to
Ethernet MAC address. Normally, dynamical ARP is used to resolute the mapping
relation from the IP address to the Ethernet MAC address. The resolution is completed
automatically without interference of the administrator.
2.1.2 Brief Introduction to Static ARP
Static ARP applies to:

z Bind packets destined to an address beyond this segment to a network adapter, so
that they can be forwarded through this gateway
z Filter out invalid IP addresses by binding them to a MAC address that does not
exist.
2.1.3 Static ARP Configuration
The static ARP configuration includes:

z Manually add/delete static ARP mapping table item.
Table 2-1 Manually add/delete static ARP mapping table item
Operation Command
Manually add static ARP mapping table arp static ip-address ethernet-address
item [ vpn-instance-name ]
Manually delete static ARP mapping undo arp ip-address
table item [ vpn-instance-name ]
Static ARP mapping items are and will be valid constantly as long as the firewall works
normally, but dynamic ARP mapping items are valid for only 20 minutes.
By default, the address mapping is obtained through dynamic ARP.
2.1.4 Enabling/Disabling ARP Entry Check
You can enable or disable the device to learn the ARP entries with broadcast MAC
addresses.
2-1
Table 2-2 Enable/disable ARP entry check
Operation Command
Enable ARP entry check to have the device not learn the
arp check enable
ARP entries with broadcast MAC addresses.
Disable ARP entry check to have the system learn the ARP undo arp check
entries with broadcast MAC addresses. enable
By default, ARP entry check is enabled. The device does not learn the ARP entries with
broadcast MAC addresses.
2.1.5 Enabling/Disabling ARP Request in the Scope of Natural Network

Segments
ARP request is usually restricted only in subnets, but you are allowed to enable ARP
request in the scope of natural segments.
Table 2-3 Enable/disable ARP request in the scope of natural network segments
Operation Command
Enable ARP request in the scope of
naturemask-arp enable
natural segments.
Disable ARP request in the scope of
undo naturemask-arp enable
natural segments.
By default, ARP request in the scope of natural network segments is not supported.
2.1.6 Proxy ARP Configuration
I. Introduction
You can assign physically distributed computers and routers to the same network
segment by assigning them IP addresses in the same network segment. Proxy ARP
allows them to communicate with each other as they would in the same physical
network.
The late 1980s witnessed an explosive growth of LANs along with the development of
network applications. A good example is that even the Ethernet of a university could be
connected to as many as hundreds of hosts. This increased the likelihood of collisions
on the Ethernet. In addition, to implement new applications, a LAN must be expanded,
for example, by using repeaters to connect new computers. This however, might cause
2-2
overload and decrease network performance because of presence of heavy collisions.

To solve the problem, proxy ARP was thus introduced.
II. Application Environments for Proxy ARP
Proxy ARP functions to connect two networks that are physically separated but on the
same IP network segment at the same.
192.38.162.2/16
192.38.160.2/16 PSTN
PSTN
PC PC
192.38.162.
192.38.160. 3/16
3/16
PC PC
192.38.160.1/24 192.38.162.1/24
192.38.160. RA: ip route RB: ip route 192.38.162.

4/16 192.38.162.0 24.dialer 0192.38.160.0 24.dialer 0 4/16
PC PC
192.38.160. 192.38.162
X/16 .X/16
PC LAN A LAN B PC
Figure 2-1 Application environment for proxy ARP
The scenario in the above figure illustrates that:

z LAN A and LAN B are connected each to an Ethernet interface on a router.
z All hosts on the LANs belong to network segment 192.38.0.0, with LAN A using
192.38.160.0 and LAN B using 192.38.162.0.
z For both LANs, the host mask is 16 bits. As the result, all hosts on the LANs
consider that they are located on the network segment 192.38.0.0.
z On the two routers, the involved interfaces are assigned to the 192.38.0.0
segment and enabled with proxy ARP.
z The two routers are connected through PSTN and each configured with a static
route to the network segment of the opposite end.
Assume that the IP address of Host A on LAN A is 192.38.160.2, and the IP address of
Host B on LAN B is 192.38.162.2. The following is how ARP works when Host A
accesses Host B:
z Host A sends an ARP request for reaching Host B.
z Router A receives the request and looks up its routing table. If finding a routing
entry, 192.38.162.0 for example, for reaching Host B, the router sends back an
ARP response with its own MAC address included.
z After receiving the ARP response, Host A sends IP packets to Router A.
z After receiving the IP packets, Router A forwards them to Router B.
2-3
z Router B forwards the received IP packets to Host B.

To send responses to Host A, Host B undergoes the same procedure.
Thus, these two physically separated hosts can access each other as they would on the
same physical network.
III. Configuring Proxy ARP
Table 2-4 Enable/disable proxy ARP
Operation Command
Enable proxy ARP function arp-proxy enable
Disable proxy ARP function undo arp-proxy enable
By default, proxy ARP is disabled.
2.1.7 Configuring Gratuitous ARP
I. Introduction to Gratuitous ARP
Gratuitous ARP means a network device sends gratuitous ARP packets to check
whether the IP addresses of other devices conflict with its IP address. If the MAC
address of the sender changes (you possibly turn off the sender, replace an interface
card for it, and then reboot it), the receiver updates its original MAC address in its cache.
For example, after receiving a gratuitous ARP packet from the sender, a device finds its
ARP entry has the IP address of the sender. The receiver replaces its original MAC
address with the MAC address of the sender. Because the gratuitous ARP packet is
broadcast on the network, all the receivers on the network perform the above
operation.
Feature of gratuitous ARP packets:
The IP address of the local device is the source and destination IP addresses of the
packet. The MAC address of the local device is the source MAC address of the packet.
After receiving gratuitous ARP packets, other devices return ARP acknowledgements
to the sender if the IP addresses of the sender and receiver are the same.
II. Configuration of learning gratuitous ARP information
2-4
Table 2-5 Enable/disable to learn gratuitous ARP information
Operation Command
Enable to learn gratuitous ARP packets gratuitous-arp-learning enable
Disable to learn gratuitous ARP packets undo gratuitous-arp-learning enable
By default, the function of learn gratuitous ARP information is disabled.
III. Enabling the device to acknowledge the ARP request packet from different
network segments
Table 2-6 Enable the device to acknowledge the ARP request packet from different
network segments
Operation Command
Enable the device to acknowledge the ARP request gratuitous-arp-sending
packet from different network segments enable
undo
Disable the device to acknowledge the ARP request
gratuitous-arp-sending
packet from different network segments
enable
By default, the system disables the device to acknowledge the ARP request packet
from different network segments.
IV. Enabling the device to send gratuitous ARP packets periodically and
setting the interval
Table 2-7 Enable the device to send gratuitous ARP packets and set the interval
Operation Command
Enable the device to send gratuitous ARP
arp send-gratuitous-arp seconds
packets periodically and set the interval
Disable the device to send gratuitous ARP
undo arp send-gratuitous-arp
packets periodically
By default, an interface does not send gratuitous ARP packets periodically.
2.1.8 Displaying and Debugging ARP
running of the ARP configuration, and to verify the effect of the configuration.
2-5
In user view, execute the reset command to clear the running.

Execute the debugging command in user view for the debugging of ARP configuration.
Table 2-8 Display and debug ARP
Operation Command
Display the ARP mapping table display arp [ static | dynamic | all ]
reset arp [ all | dynamic | static |
Clear the ARP entries in the ARP
interface interface-type
mapping table
interface-number ]
Enable the ARP information debugging debugging arp packet
Disable the ARP information debugging undo debugging arp packet
2.2 Domain Name Resolution Configuration

2.2.1 DNS Overview
TCP/IP not only provides IP address to specify devices, but also specially designs a
kind of host naming mechanism called DNS (Domain Name System) in the form of
character string. Adopting a hierarchical naming system, the DNS designates a
meaningful name for the device in the Internet and associate the domain name with IP
address with the help of the domain name resolution server. In this way, the user can
use domain names that are easy to memorize and meaningful, and never needs to
keep obscure IP addresses in mind.
There are two kinds of domain name resolutions, namely static domain name resolution
and dynamic domain name resolution, which supplement each other in real application.
On resolving a domain name, use the static resolution first. If it fails, use the dynamic
resolution method. Some common domain names can be put into the static domain
name resolution table to raise the domain name resolution efficiency greatly.
z Static resolution: To create the corresponding relationship between domain name
and the IP address manually. When the client needs the IP address related to the
domain name, it will search the specific domain name in the static domain name
resolution table to obtain the corresponding IP address.
z Dynamic resolution: To receive the domain name resolution request lodged by the
client with special domain name resolution server. The server first performs
resolution within the local database. If it judges that the domain name does not
belong to the local domain, it will forward the request to the upper level domain
name resolution server until the resolution is finished. The resolution results, being
either IP address or non-existed domain name, will be returned to the client.
2-6
2.2.2 Configuring Static Domain Name Resolution
I. Introduction to static domain name resolution
Static domain resolution is performed by the static domain name resolution table, which
is something like the hosts file under Windows operation system. The firewall can
obtain the IP address of common domain name by inquiring this table. Moreover, the
user can use host names that are easy to memorize rather than abstract IP addresses
to access the related devices.
The domain name resolution configuration includes:
z Add or delete mapping entry in static domain name resolution table
z Display and debug domain name resolution table
II. Adding or deleting mapping entry in static domain name resolution table
Execute the following commands in system view to add or delete mapping entry in
static domain name resolution table.
Table 2-9 Add or delete mapping entry in static domain name resolution table
Operation Command
Add the mapping between domain name
ip host hostname ip-address
and IP address
Delete the mapping between domain
undo ip host hostname [ ip-address ]
name and IP address
2.2.3 Displaying and debugging domain name resolution table
After the above configuration, execute the display command in all views to display the
running of domain name resolution table, and to verify the effect of the configuration.
Table 2-10 Display and debug domain name resolution table
Operation Command
Display static domain name resolution table display ip host
2.3 DNS Client Configuration

IP addresses, 202.112.131.109 for example, are 32 bits long and as such are difficult
for human beings to memorize. To make it easier to memorize addresses, most
organizations replace IP addresses with domain names, that is, abbreviations or
meaningful names, http://www.sina.com.cn/ for example. To map a domain name to an
IP address, you need a resolver or domain name system (DNS) server.
2-7
DNS is a distributed database that applies to TCP/IP application programs. It functions

to resolve between hostnames and IP addresses and provide email routing information.
In applications, access to the DNS server is provided by an address resolver. The DNS
client can accomplish the function of a resolver by translating between IP addresses
and domain names of hosts.
This is how DNS operates:
1) First, a user program sends a request to the DNS client.
2) Upon receipt of this request, the DNS client looks up the local database; if no
match is found, it sends a query to the name server.
3) After receiving the response sent back by the name server, the DNS client
resolves the response packet and based on the packet contents decides its
operation.
Figure 2-2 DNS system components
Figure 2-2 illustrates the process of DNS resolving:

1) The user program queries the resolver for a domain name or IP address.
2) Upon receipt of the query, the resolver first looks up the local cache. If the
requested map entry is found, it directly replies. If not, it assembles a query packet
appropriate to the query type, that is, whether IP address or domain name is
needed. This packet can take TCP or UDP format, but in this program UDP is
adopted.
3) Then, based on its DNS configuration, the resolver sends the query packet to port
53 on the default DNS server (the foreign name server in this scenario).
4) After receiving the response, the resolver resolves the response packet and
replies to the user.
In this scenario, resolver and its cache are called DNS client and as a whole function to
accept and respond to the DNS queries of user programs. Normally, the user program
and resolver are on the same host whereas the foreign name server can be located on
that same host or more likely on a different one.
2-8
2.3.1 Configuring the DNS Client
Following are the DNS client configuration tasks:

z Enable DNS resolving
z Configure IP address of the DNS server
z Configure the DNS domain name searching list
Where, you must enable DNS resolving and provide IP address of the DNS server. You
need only to enable DNS resolving, however, if the interfaces on the device use IP
addresses assigned by a DHCP client and the address of the DNS server and the
domain name are included in the information that the DHCP server issues to the
device.
I. Enabling DNS Resolving
To use the DNS client function, enable DNS resolving on the device first.
Table 2-11 Enable/disable DNS resolving
Operation Command
Enable DNS resolving. dns resolve
Disable DNS resolving. undo dns resolve
By default, DNS resolving is disabled.
II. Configuring IP Address of the DNS Server
To resolve domain names, the DNS client must know the domain server address where
it can send queries.
Table 2-12 Configure IP address of the DNS server
Operation Command
Configure IP address of the DNS server. dns server ip-address
Delete IP address of the DNS server. undo dns server [ip-address ]
DNS server is not assigned with IP address by default.
III. Configuring the DNS Domain Name Searching List
Some of the websites that you access may have the same domain name, such as
sina.com.cn, h3c.com.cn, and sohu.com.cn.
2-9
To facilitate website searching of users, you can set a domain name to com.cn for
example. Thus, to search for the IP address mapped with "sina.com.cn", a user only
needs to enter the command ping sina. If no response is received, the DNS client
sends a request to query the IP address mapped with “sina”.
You can configure a DNS domain name searching list by using the following command
repeatedly.
Table 2-13 Configure a DNS domain name
Operation Command
Configure a DNS domain name. dns domain domain-name
Delete one or all DNS domain names. undo dns domain [domain-name]
Note:
RFC1034, however, uses a different searching approach: when you input the ping sina
command, the DNS client first queries the IP address mapped to “sina”. And if no
response is received, it then queries the IP address mapped to “sina.com.cn”.
2.3.2 Displaying and Debugging DNS Client Information
I. Displaying the DNS client information
Table 2-14 Display the DNS client information
Operation Command
View whether DNS resolving is enabled display current-configuration
Display the configurations of the DNS server display dns server [dynamic]
Display the configurations of the DNS
display dns domain [dynamic]
domain name searching list
Display contents of the dynamic domain
display dns dynamic-host
name buffer
Display the domain name or IP address
nslookup type { ptr ip-address | a
resolved from the specified IP address or
domain-name }
domain name
2-10
Note:
Execute the display dns server dynamic command to view DNS server addresses
that are dynamically obtained through DHCP or by other means.
II. Clearing the domain name cache
The DNS client retains the result of each successful domain name resolution in its
cache. If it receives the same resolving request later, it first looks up the cache for a
match. And if no match is found, it sends a domain name resolving request to the DNS
server.
You can clear the current cache using the following command.
Table 2-15 Clear the dynamic domain name cache
Operation Command
Clear the dynamic domain name cache. reset dns dynamic-host
III. Debugging the DNS client
Table 2-16 Debug the DNS client
Operation Command
Enable DNS client debugging. debugging dns
Disable DNS client debugging. undo debugging dns
By default, DNS client debugging is disabled.
2.3.3 Typical DNS Configuration Example
Enable DNS resolving on the firewall with the IP address 10.110.10.1. IP address of the
DNS server is 10.110.10.66.
2-11
II. Network diagram
Ethernet0/0/0
10.110.10.1/24 10.110.10.66/24
SecPath DNS Server
Figure 2-3 Network diagram

# Enable DNS resolving.
[H3C] dns resolve
# Configure IP address of the DNS server.

[H3C] dns server 10.110.10.66
# Configure IP address of Ethernet0/0/0.

2.3.4 Troubleshooting
Symptom: Domain name resolving failed.

Solution:
1) Check the software, making sure that:
z IP address of the domain name server is correctly configured.
z The device and the domain name server have routes between them.
z DNS resolving is enabled.
2) Check the hardware, making sure the network connection cable is in good
condition and securely connected.
2.4 DNS Proxy Configuration

2.4.1 Overview
I. Introduction to DNS proxy
You can enable DNS proxy on the firewall. Then the clients inside the LAN can be
connected to the outside DNS server if no DNS server is available inside, and access
the Internet after getting correct DNS resolution results.
2-12
II. DNS proxy principles
z A DNS client sends a DNS request packet to the DNS proxy, and the destination of
the packet is the IP address of the DNS proxy.
z After receiving the request packet, the DNS proxy replaces the packet destination
with the IP address of the DNS server and then forwards the packet to the DNS
server. If multiple DNS server addresses are configured, the DNS proxy first
forwards the packet to the first DNS server. If the first DNS server does not
respond, the DNS client sends another request packet till the timeout of waiting for
response and the DNS proxy then forwards the packet received to the second
DNS server. The DNS proxy continues this process till a response is received.
z When receiving a response packet, the DNS proxy replaces the source IP address
of the packet with its own IP address and then forwards the packet to the DNS
client. Therefore, the DNS client can access the Internet through the IP address
resolved.
2.4.2 DNS Proxy Configuration
I. Configuration prerequisites
The following configuration must be completed before you configure DNS proxy
function.
z The IP addresses of the real DNS servers are configured on the DNS proxy.
z The IP address of the DNS server configured on the client is the IP address of the
DNS proxy.
z Guarantee that the DNS proxy and DNS client/server are reachable.
II. Configuring DNS proxy
Configure the DNS proxy function on the firewall.
Table 2-17 Configure DNS proxy
Operation Command Remarks

Enter system view system-view —
Enable DNS proxy dns-proxy enable Required
2.4.3 DNS Proxy Configuration Example
No DNS sever is available on the LAN, and inside PCs (on network segment
10.1.1.0/24) can resolve domain names through the outside DNS server.
z The firewall supports DNS proxy.
2-13
z The IP address of the outside DNS server is 10.72.66.36/24.
II. Network diagram
Client Client
SecPath
10.72.66.36/24
LAN Internet
Ethernet1/0/0 Ethernet1/0/1 DNS Server

10.1.1.1/24 10.1.2.1/24
Client Client
Figure 2-4 Network diagram for DNS proxy configuration
1) Configure the firewall.

# Configure the IP address of the Ethernet 1/0/0 interface.
# Enable NAT server to enable the client to access the Internet through the DNS proxy.
[H3C] acl number 2000
[H3C-acl-basic-2000] rule 0 permit source 10.1.1.0 0.0.0.255
[H3C-acl-basic-2000] quit
[H3C-Ethernet1/0/1] nat outbound 2000
# Enable the DNS proxy function.

[H3C] dns-proxy enable
# Configure the DNS server IP address.

[H3C] dns server 10.72.66.36
# Configure a route.
Guarantee the route between the firewall, client and DNS server reachable.
z Configure the client.
Specify the IP addresses of the firewall and DNS server as 10.1.1.1.
2-14
2.5 URPF Configuration

2.5.1 URPF Overview
Unicast Reverse Path Forwarding (URPF) serves as a safeguard against source

address based network attacks.
In source address spoofing attacks, attackers create a series of packets with forged
source addresses. For applications using IP address based authentication method, this
type of attack allows unauthorized users to access the system in the name of other
users. Even the response packets cannot reach the attackers; it is disruptive to the
attacked target.
There are generally two types of URPF check: strict check and loose check. It also
supports ACL and default route check.
The procedures of the URPF check are as follows:
1) Sources address validity check: The packet with its source address not being a
valid host address will be discarded.
2) When the packet’s source address is in the security gateway’s FIB table, and the
outbound interface in the forwarding entry and the inbound interface of the packet
are the same:
z If the forwarding entry is found to be a default route, and the allow-default-route
argument is configured, packets can pass through; if the allow-default-route
argument is not configured, ACL check for the packets will be performed.
z If the forwarding entry is not a default route, packets can pass after passing URPF
check.
3) When the packet’s source address is in the security gateway’s FIB table, but the
outbound interface in the forwarding entry and the inbound interface of the packet
are not the same:
z For strict checks, ACL check for packets will be performed directly.
z For loose checks, the procedure is the same as in Step 2.
4) If the packet’s source address is not in the security gateway’s FIB table, or the
forwarding entry is found to be Blackhole or Reject, ACL check will be performed.
5) ACL check
z If ACL is configured, packets can pass through if they are permitted by ACL, and
will be discarded if they are denied by ACL.
z If ACL is not configured, packets will be discarded directly.
Note:
URPF does not support fast forwarding, which means packets that have not passed the
URPF check can be further forwarded if the fast forwarding list has been set up.
2-15
2.5.2 URPF Configuration
Table 2-18 Enable/disable URPF check
Operation Command
ip urpf { strict | loose } [ allow-default-route ] [ acl
Enable URPF check
acl-number ]
Disable URPF check undo ip urpf
By default, URPF check is disabled.
2.5.3 URPF Display and Debugging
Table 2-19 Display URPF discarded packets
Operation Command
debugging ip urpf discards [ interface
Display URPF discarded packets
undo debugging ip urpf discards

Cancel the display of URPF discarded
packets
interface-number ]
2-16
H3C SecPath Series Security Products Chapter 3 UDP Helper Configuration
Chapter 3 UDP Helper Configuration
3.1 Introduction to UDP Helper

UDP Helper functions to relay UDP broadcast packets to the specified server after
converting them to unicast packets.
With UDP Helper enabled, the firewall decides whether to forward a received UDP
broadcast packet based on its port number. If forwarding is required, the firewall
modifies the destination IP address in the IP header and then relays the packet to the
specified destination server. If not, the firewall passes the packet to the upper layer
module. When relaying a BOOTP/DHCP response message, the firewall broadcasts it
if the client requests that a broadcast response is desired; otherwise, the firewall
unicasts it.
3.2 UDP Helper Configuration

UDP Helper configuration tasks are described in the following sections:
z Enabling/Disabling UDP Helper
z Specifying by UDP Port Number which UDP Broadcasts are forwarded
z Configuring Destination Servers
3.2.1 Enabling/Disabling UDP Helper
You can enable UDP helper to have the firewall forward the received UDP broadcast
packets. As soon as this function is enabled, the firewall forwards the broadcast
packets with the UDP port number 69, 53, 37, 137, 138, or 49 by default. In addition to
these port numbers, you can configure the firewall to forward the broadcast packets
with the specified UDP port number. Disabling this function disables the firewall to
forward the broadcast packets with one of these UDP port numbers (specified or
default).
Table 3-1 Enable/disable UDP Helper
Operation Command
Enable UDP Helper udp-helper enable
Disable UDP Helper undo udp-helper enable
By default, UDP Helper is disabled.
3-1
3.2.2 Specifying by UDP Port Number which UDP Broadcasts are forwarded
With UDP Helper enabled, the system by default unicasts the broadcast packets with
the UDP ports listed in the following table. You can configure up to 256 UDP ports with
UDP Helper.
Table 3-2 Default UDP ports
Protocol UDP port number

Trivial file transfer protocol (TFTP) 69
Domain name system (DNS) 53
Time service 37
NetBIOS name server (NetBIOS-NS) 137
NetBIOS datagram server (NetBIOS-DS) 138
Terminal access controller access control system (TACACS) 49
Table 3-3 Configure/disable the system to forward the UDP broadcasts with the
specified UDP port number
Operation Command
Configure the system to forward the udp-helper port { port | dns |
UDP broadcasts with the specified UDP netbios-ds | netbios-ns | tacacs | tftp |
port number time }
Disable the system to forward the UDP undo udp-helper port { port | dns |
broadcasts with the specified UDP port netbios-ds | netbios-ns | tacacs | tftp |
number time }
Note that:
z Before you can specify by UDP port number which UDP broadcasts are forwarded,
you must enable UDP Helper.
z The dns, netbios-ds, netbios-ns, tacacs, tftp, and time keywords represents
the six default ports which can be configured in two ways: configuring the specified
port number and configuring the specified parameter. When specifying a default
port, DNS for example, you can specify its port number 53 directly or specifying
the keyword dns.
z When displaying the information about UDP helper, the display
current-configuration command displays the default UDP port numbers only
when they are disabled to use UDP Helper.
3-2
3.2.3 Configuring Destination Servers
After enabling UDP helper in system view, you can configure one or multiple (up to 20)
servers on an Ethernet interface to have the UDP broadcasts received on the interface
forwarded to the server or servers.
Table 3-4 Configure/delete the server to which UDP broadcasts are forwarded
Operation Command
Configure the destination server to which the UDP udp-helper server
broadcasts received on the interface are forwarded ip-address
Delete the destination server to which the UDP undo udp-helper server
broadcasts received on the interface are forwarded [ip-address ]
By default, no destination server is available.
3.3 Displaying and Debugging the UDP Helper Configuration

After completing the above configuration tasks, execute the display command in any
view to view the destination servers available with UDP Helper and to verify the effect of
the configurations.
Execute the debugging command in user view to debug UDP helper.
Table 3-5 Display and debug UDP Helper
Operation Command
Display the destination servers associated display udp-helper server
with the specified or all Ethernet interfaces [ interface number ]
debugging udp-helper { event |
Enable UDP Helper debugging
packet [ receive | send ] }
undo debugging udp-helper
Disable UDP Helper debugging
{ event | packet [ receive | send ] }
3-3
H3C SecPath Series Security Products Chapter 4 BOOTP Client Configuration
Chapter 4 BOOTP Client Configuration
4.1 Introduction to BOOTP Client

The bootstrap protocol (BOOTP) adopts the client/server model where the BOOTP
client requests the server for an IP address. The two main tasks for the BOOTP client
are:
z Sending BOOTP request packet to the server.
z Processing the BOOTP response packet from the server.
The following is how the BOOTP client obtains an IP address from the BOOTP server:
z The BOOTP client sends a BOOTP request.
z Upon receipt of the request, the BOOTP server sends back a reply with the
allocated IP address.
z The BOOTP client obtains the IP address.
BOOTP messages are encapsulated in UDP. To ensure transmission reliability, the
timeout retransmission mechanism is adopted. When the BOOTP client sends a
request, a retransmission timer starts. If no reply is received when the timer times out,
the client retransmits the request. The retransmission occurs every five seconds and up
to three transmission attempts are allowed.
4.2 BOOTP Client Configuration

BOOTP client configuration includes only one task, which is described in the following
subsection.
4.2.1 Configuring an Ethernet Interface to Obtain IP Address Using BOOTP
Table 4-1 Configure the Ethernet interface to obtain IP address using BOOTP
Operation Command
Configure the Ethernet interface to
ip address bootp-alloc
obtain IP address using BOOTP
Disable the Ethernet interface to obtain
undo ip address bootp-alloc
IP address using BOOTP
By default, the Ethernet interface does not use BOOTP to obtain IP address.
4-1
H3C SecPath Series Security Products Chapter 4 BOOTP Client Configuration
4.3 Displaying and Debugging BOOTP Client Configuration

After completing the above configuration, execute the display command in any view to
display and verify your BOOTP configuration.
Table 4-2 Display and debug the BOOTP client configuration
Operation Command
display bootp client [ interface
Display BOOTP client information
4-2
H3C SecPath Series Security Products Chapter 5 DHCP Configuration
Chapter 5 DHCP Configuration
5.1 DHCP Overview

5.1.1 DHCP
I. Introduction to DHCP
We are in a world where the scales of networks are ever-growing and their
configurations are more and more complex, computers (such as laptop computers and
wireless networks) are likely to move, and the available IP addresses are far from
adequate for the ever-increasing number of computers. Dynamic Host Configuration
Protocol (DHCP) was introduced in such a background.
Like Bootstrap Protocol (BOOTP), DHCP adopts the client/server communications
model. In this model, it is client that requests the server for configurations, such as the
assigned IP address, subnet mask, and default gateway (GW). The server will return
the configuration information appropriate to the request in accordance with the
configured policy. Both BOOTP and DHCP packets are encapsulated with UDP and in
the structures that are highly similar.
BOOTP is running in a relatively static environment in which each host has a fixed
network connection and, for each host, administrators configure a BOOTP file that will
keep the same for a relatively long time.
Compared to BOOTP, DHCP is improved in two aspects. Firstly, DHCP allows
computers to obtain all the desired configuration information by using only one
message; secondly, it allows computers to rapidly and dynamically obtain IP addresses
rather than statically specifying an address for each host.
II. IP address allocation in DHCP
1) IP address allocation policy

The time durations different types of hosts occupying IP addresses are different. For
example, servers are more likely to use fixed IP addresses for a long time, some hosts
perhaps need to use some dynamic IP addresses for a long period of time too, but
some individuals only need to use temporarily assigned IP addresses for a short period
of time.
Commensurate with these demands, a DHCP server provides three types of IP
address allocation policies:
z Manual allocation, with which fixed IP addresses are assigned to a small amount
of special hosts such as World Wide Web (WWW) servers.
5-1
z Auto-allocation, with which fixed IP addresses are assigned to some hosts

connected to networks for the first time and these hosts are allowed to use the
addresses for a long period of time.
z Dynamic allocation, with which some addresses are “leased” to client hosts. In this
case, the clients need to request for new addresses upon the expiration of the
leases. In fact, the addresses assigned to most client hosts are dynamic
addresses.
2) IP address allocation order
A DHCP server selects an IP address for a client in the following order:
z The static IP address bound to the MAC address of the client in the database of
the DHCP server.
z The client’s previous IP address, i.e., the address requested in the “Requested IP
Addr Option” carried in the DHCP-REQUEST packet sent by the client.
z A new address allocated from the server's DHCP pool of available addresses. This
address is the one found first in the address pool.
z If the DHCP server does not find an available address, it will look outdated leased
IP address and then ever conflicting IP address to find a valid one for assignment.
If the attempt fails, the server will report error.
5.1.2 DHCP Server
I. Application environment for DHCP server
DHCP servers are well-suited to the network where:

z The network size is large, manual configuration is not an easy job, and it is hard to
centralize the management on the entire network.
z The number of IP addresses available to the hosts on the network is far from
adequate and it is impossible to assign a fixed IP address to each host. So the
hosts, being too many, have to obtain dynamic IP addresses from a DHCP server
in this case. In addition, limitation is placed on the number of concurrent users.
z On networks, most hosts are not assigned fixed IP addresses except of a few of
them.
II. Fundamentals of DHCP server
As shown in the following figure, a typical DHCP application network usually comprises
a DHCP server and multiple clients (such as PCs and laptop computers).
5-2
DHCP Client DHCP Client
LAN
DHCP Server
DHCP Client DHCP Client
Figure 5-1 Network diagram for a DHCP server application
In order to obtain a valid dynamic IP address, a DHCP client should exchange different
information with the server in different stages, three usual situations are.
1) First network access of DHCP client
In this case, the DHCP client should undergo four stages in order to set up a connection
with a DHCP server.
z Discover stage where the DHCP client is searching for a DHCP server. In this
stage, the client broadcast a DHCP_Discover packet on the network and only
DHCP servers respond to it.
z Offer stage where DHCP servers offer IP addresses to the client. Upon receipt of
the DHCP_Discover packet from the client, each DHCP server sends a
DHCP_Offer packet carrying an unassigned IP address selected from its IP
address pool to the client with other settings. To guarantee that the offered IP
address is unique, each of them does an ARP probe before that.
z Selecting stage where the DHCP client picks one IP address out of all the offers. If
the client receives offers from multiple DHCP servers, it will only accept the one
reaching first. Then, it will broadcast a DHCP_Request packet containing the IP
address, which was assigned and wrapped in the DHCP_Offer packet by DHCP
server, to all the DHCP servers.
z Final check stage where the DHCP client checks the offered IP address. After
receiving the DHCP_ACK message, the client broadcasts an ARP packet destined
to the offered IP address. If no response is received after a specified period of time,
the client uses the IP address.
z Except for the selected DHCP server, all other DHCP servers can allocate their
offered IP addresses to other requesting clients.
2) Non-first network access of DHCP client
If it is not the first time for the DHCP client to access the network, it should undergo the
following procedure in order to set up a connection with a DHCP server.
5-3
z When a DHCP client that has accessed the network correctly accesses the
network again, it only needs to broadcast a DHCP_Request packet containing the
IP address assigned to it the last time instead of sending a DHCP_Discover
packet.
z Upon the receipt of the DHCP_Request packet, the DHCP server will send back a
DHCP_ACK packet that allows the client to use the requested address if it is still
unallocated.
z If the DHCP server has allocated that IP address to some other DHCP client or it is
not available for the client for some other reasons, the DHCP server will send back
a DHCP_NAK packet. Upon the receipt of the packet, the client may send a new
DHCP_Discover packet requesting a new IP address.
3) Renew the IP address lease
DHCP server will take back the dynamic IP address allocated to DHCP client when the
lease expires. If DHCP client still wants to use this address, it should renew the IP
address lease.
In practice, when the DHCP client starts or is at the half of the lease limit, DHCP client
will initiate DHCP_Request packet to DHCP server to complete lease renewal. If the
current IP address is still valid, DHCP server returns DHCP_ACK packet to notify
DHCP client that it has renewed the IP address lease.
4) Configure PC (take Windows XP as an instance)
Use the ipconfig/release command under DOS environment to release an existing IP
address. Then the user PC sends DHCP_Release packet to DHCP server. Use the
ipconfig /renew command under DOS environment to request for new IP address.
Now the user PC sends the DHCP_Discover packet to DHCP server.
You can also use the ipconfig/renew command on the user PC to renew the IP
address lease.
Refer to Figure 5-2 for the above procedures.
5-4
DHCPNAK/
Discard offer INIT
-/Send DHCPDISCOVER
DHCPACK DHCPNAK,
(not accept.)/ Lease expired/
Send DECLINE Halt network
SELECTING
DHCPOFFER
/Collect
Select offer/ replies
send DHCPREQUEST
REQUESTING
DHCPOFFER/
Discard
DHCPACK/ REBINDING
Record lease, set
timers T1, T2 DHCPACK/
Record lease, set
timers T1,T2
BOUND T2 expires/
DHCPOFFER, Broadcast
DHCPACK, DHCPACK/ DHCPREQUEST
DHCPNAK/ Record lease, set
T1 expires/
Discard timers T1, T2
Send DHCPREQUEST
DHCPNAK/
to leasing server
Halt network
RENEWING
Figure 5-2 DHCP client state transition diagram
5.1.3 Introduction to DHCP Accounting
DHCP Accounting notifies the RADIUS server to start or to stop accounting when the
DHCP server is assigning and releasing the lease. Working with RADIUS, DHCP
server enables network accounting function and helps to ensure network security.
I. DHCP Accounting Packet Structure
DHCP server and RADIUS server communicate with each other by sending Accounting
Start and Accounting Stop request packets. These two packets share almost the same
structure except for a little difference in the Attribute field. The structure of the packets
is as follows:
5-5
Figure 5-3 Accounting packet structure
z Code: Code field, using 1 byte of the packet, represents the type of RADIUS
packet. The packet is discarded when the code field in it is illegal. When the value
of Code is 4, the packet is Accounting start; when the value of Code is 5, the
packet is Accounting stop.
z Identifier: Identifier field uses 1 byte of the packet. It is used to match request and
response packets. With the help of the identifier field, the RADIUS server checks
the repeating request packets sent from the same IP address and UDP port of the
same client.
z Length: Length field uses 2 bytes of the packet. It identifies the length of the whole
Accounting packet.
z Authenticator: Authenticator field uses 16 bytes of the packet. It authenticates
information transmitted between clients and RADIUS accounting servers.
II. Working Mechanism of DHCP Accounting
Configure AAA authentication and RADIUS to the firewall which enables DHCP server
function, then DHCP server becomes the client of RADIUS. Refer to security part in this
manual for the authentication procedure. Here, we mainly introduce the accounting
communication procedure between DHCP server and RADIUS server.
z After sending IP configuration information in the DHCP ACK packet to the DHCP
client, DHCP server sends Accounting start request packet to a specified RADIUS
server, who accordingly processes the request and records it. Then, RADIUS
server sends response packet to DHCP server at the same time.
z Due to some reasons, after the lease of DHCP server is released, DHCP server
notifies RADIUS server to stop recording by sending Accounting stop request
packet immediately. Then, the RADIUS server processes the packet and stops
recording. Meanwhile, RADIUS server sends the response packet to DHCP server.
The reason of releasing the lease may include lease expiration, release request
received from users or manual deletion of the lease or address pool.
5-6
In the case that the RADIUS server of a specified domain may not be reached, the
Accounting start packet will be forwarded three times within a certain period. After this
period, DHCP server will not send the packet any more even if it does not receive the
corresponding packet.
5.1.4 BIMS Option for DHCP Server
I. Introduction to BIMS Option for DHCP Server
BIMS option for DHCP server enables a DHCP server to notify a DHCP client of the
information about the branch intelligent management system (BIMS) server when
assigning an IP address, making the DHCP client be able to use the BIMS server for
software backup and upgrade after obtaining an IP address. The number of the BIMS
option is 217.
II. Structure of the BIMS Option Packet
The BIMS option is added into the Options field of a response generated by the DHCP
server for a DHCP client. Since DHCP clients from different manufacturers process
DHCP responses differently, the DHCP server adds the BIMS option to both
DHCP_OFFER and DHCP_ACK packets. The structure of the BIMS option packet is as
follows:
Code Len IP:port:sharekey

+-------+------+------+------+------+------+--...-+------+
| 217 | N | i1 | i2 | i3 | i4 | …| iN |
+-------+------+------+------+------+------+--...-+------+
Figure 5-4 Structure of the BIMS option packet
The BIMS option packet has a structure similar to those of other option packets. It also
contains the Code field for identifying the number of the option and the Len field for
identifying the length of the option packet.
The i1 to iN fields mainly carry the IP address, protocol port, and shared key of the
BIMS server, which are represented by a string. For example, if the IP address of the
BIMS server is 192.168.1.1, the port number is 80, and the shared key is abcdefg, then
these fields carry the string of 192.168.1.1.80.abcdefg.
III. Fundamental of BIMS Option for DHCP Server
1) A DHCP client sends a request to the DHCP server for an IP address and
configuration parameters.
2) When receiving a request, the DHCP server checks the locally configured address
pools. You can enable the BIMS option feature for a global address pool or
interface address pool of the DHCP server. If the address to be assigned to the
5-7
client is from an address pool for which BIMS option is enabled, the DHCP server
encapsulates the IP address, protocol port, and shared key of the BIMS server
together with the IP configuration parameters in the response.
When receiving the response with the BIMS option information from the DHCP server,
the DHCP client resolves the BIMS option information to obtain the IP address, protocol
port, and shared key of the BIMS server. After that, the client periodically sends
connection requests to the BIMS server for software backup and upgrade.
5.1.5 Option 184 for DHCP Server
I. Introduction to Option 184 for DHCP Server
Option 184 is a reserved option in RFC, and you can define the information borne in it.
H3C defines four proprietary sub-options for this option, so that the DHCP server can
bear necessary information for the client in responses. The sub-options of in Option
184 mainly bear voice information. The following are the details:
z Sub-option 1: Network call processor IP address (NCP-IP).
z Sub-option 2: Alternate server IP address (AS-IP).
z Sub-option 3: Voice VLAN configuration.
z Sub-option 4: Fail-over call routing.
1) Meaning of the sub-options in Option 184
z NCP-IP
It bears the IP address of the network call processor. It must be used as the first
sub-option (sub-option 1) if you use it in option 184.
The NCP-IP address borne can identify the server used as the network call control
source and the application download server.
z AS-IP
It bears the IP address of the alternate server. It must be used as the second sub-option
(sub-option 2). That is, to make it function, you must first define the NCP-IP sub-option.
The AS-IP address borne, as the backup of the NCP-IP, is used when the NCP-IP
borne is unreachable or invalid.
z Voice VLAN configuration
It bears the flag of if to enable voice VLAN and the VLAN ID, and is the third sub-option
(sub-option 3) in Option 184.
The voice VLAN configuration sub-option consists of two parts: the flag of if to enable
voice VLAN and the VLAN ID. When the flag is set to 0, the voice VLAN is disabled and
the VLAN ID will be ignored even if it is borne. When the flag is set to 1, the voice VLAN
is enabled.
2) Fail-over call routing
5-8
It bears the IP address of the fail-over call routing and the related dialer string, and is
the fourth sub-option of Option 184 (sub-option 4).
The IP address of the fail-over call routing and the related dialer string borne here are
the IP address and call number of the peer for the communication between SIP
(session initiation protocol) users. When the NCP server is unreachable, a SIP user can
set up a connection to and communicate with the peer using the IP address and call
number borne.
Note:
You must first configure sub-option 1 before configuring sub-option 2, sub-option 3
and/or sub-option 4. Otherwise, sub-option 2, sub-option 3 and sub-option 4 cannot
take effect.
3) Fundamentals of Option 184 for DHCP server

The Option 184 information for the DHCP serve is borne in the response packet to the
client. We assume DHCP server and client are in the same network segment in the
following description about the working principle of Option 184.
z The DHCP client sends a request packet to the DHCP server to apply for Option
184 borne in packets. The configuration parameters for Option 184 are also
included.
z The DHCP server checks the request list in the request packet, adds Option 184
and related sub-options in the Options field in the response packet and returns the
packet to the client.
Note:
The DHCP server returns Option 184 only when the request for Option 184 is specified
in Option 55 of the request packet.
5.1.6 DHCP Relay
I. Application environment of DHCP relay
The early Dynamic Host Configuration Protocol (DHCP) is only applicable to the case
where DHCP server and client are in the same sub-net, but not to the trans-segment
case. To achieve dynamic host configuration, it is required to configure a DHCP server
for every segment, as obviously uneconomical.
5-9
DHCP relay can solve this problem. With DHCP relay, the client in an LAN can
communicate with the DHCP server in another sub-net and get IP address successfully.
That is, DHCP clients in several sub-nets can share one DHCP server, as is significant
for saving cost and centralized management.
In general, either a host, a firewall, or a router can server DHCP relay. It works as long
as DHCP relay agent program is started on it.
II. Principle of DHCP relay
The following figure illustrates DHCP relay network.
DHCP client DHCP client
LAN Internet
DHCP Relay

DHCP Serv er
Figure 5-5 Network diagram for DHCP relay
DHCP relay works on this principle:

z When DHCP client starts and runs DHCP initialization, it broadcasts configuration
request packets to the local network.
z If there is a DHCP server in the local network, it begins DHCP configurations
without DHCP relay.
z If not, the local network processes the packet and forwards it to the specified
DHCP server in another sub-net.
z The DHCP server undertakes configurations according to the information from the
client and sends the configuration information through DHCP relay back to the
client. Till now, dynamic configuration for the client ends is completed. In practice,
multiple message exchange processes may be required to finish client
configuration.
DHCP relay supports transparent transmission of DHCP broadcast messages and can
transmit broadcast messages from DHCP client (or server) transparently to the DHCP
server (or client) in another sub-net.
In real network, DHCP relay function is often implemented at a specific interface of a
firewall. So you should configure IP relay address for the interface to specify a target
DHCP server.
5-10
5.2 DHCP Common Configuration

DHCP common configurations refer to those configurations suitable for both DHCP
server and DHCP relay. The configuration tasks include
z Enable/disable DHCP services
z Configure pseudo-DHCP server detection
5.2.1 Enabling/Disabling DHCP
For both DHCP server and DHCP relay, you must first enable DHCP before starting
DHCP configurations.
Table 5-1 Enable/disable DHCP
Operation Command
Enable DHCP. dhcp enable
Disable DHCP. undo dhcp enable
By default, DHCP is enabled.
Note:
DHCP can operate normally only after you correctly set the system clock.
5.2.2 Configuring Pseudo-DHCP Server Detection
Pseudo-DHCP servers are unauthorized DHCP servers. Upon the request for IP
address from a DHCP client, a pseudo-DHCP server might communicate with the client
and may allocate incorrect IP address to the client.
You can configure pseudo-DHCP server detection to record IP address and interface
information of DHCP server. Then the administrator can easily find and deal with the
pseudo-DHCP server.
5-11
Table 5-2 Configure pseudo-DHCP server detection
Operation Command
Enable pseudo-DHCP server detection. dhcp server detect
Disable pseudo-DHCP server detection. undo dhcp server detect
By default, pseudo-DHCP server detection is disabled.
5.3 Configuring DHCP Server

DHCP server configuration tasks include
z Setting interfaces to operate in DHCP server mode
z Adding DHCP address pool
z Defining allocation mode of DHCP address pool
z Excluding IP address from auto allocation
z Defining IP address lease expiry limit
z Configuring domain name for DHCP client
z Configuring DNS (Domain Name Server) IP address for DHCP client
z Configuring NetBIOS IP address for DHCP client
z Defining NetBIOS node type for DHCP client
z Configuring DHCP customization items
z Configuring egress gateway for DHCP client
z Configuring ping packet transfer in DHCP server
z Configuring DHCP server accounting
z Configuring BIMS option for DHCP server
z Configuring option 184 for DHCP server
z Clearing DHCP information
Note:
Differences between global address pool and interface address pool:
z The global address pool is created with dhcp server ip-pool command in system
view and it is effective in the entire firewall.
z The interface address pool is established automatically when the Ethernet interface
is configured with valid unicast IP address and it is effective only in the interface. Its
address segment range is the segment for the Ethernet interface.
5-12
5.3.1 Setting Interfaces to Operate in DHCP Server Mode
When the local device receives a DHCP packet with itself being the destination, the
device handles the packet depending on the specified operating mode. When
operating in server mode, the device forwards the packet to the local DHCP server;
when operating in relay mode, the device forwards the packet to an external DHCP
server.
Perform the following configuration in interface view to have the current interface
operate in DHCP server mode.
Table 5-3 Set the current interface to operate in DHCP server mode
Operation Command
Send DHCP packets to the local DHCP server and dhcp select global
allocate addresses from the global address pool [ subaddress ]
Send DHCP packets to the local DHCP server and
dhcp select interface
allocate addresses from the interface address pool
Restore the default undo dhcp select
Perform the following configuration in system view to have the specified interfaces
operate in DHCP server mode.
Table 5-4 Set multiple interfaces to operate in DHCP server mode
Operation Command
Send DHCP packets to the local DHCP dhcp select global [ subaddress ]
server and allocate addresses from the { interface ethernet-subinterface-range
global address pool | all }
Send DHCP packets to the local DHCP
dhcp select interface { interface
server and allocate addresses from the
ethernet-subinterface-range | all }
interface address pool
undo dhcp select { interface
Resets the default
By default, dhcp select global applies.
5-13
Note:
z To use interface address pools for address allocation, you must configure the dhcp
select interface command.
z subaddress enables the secondary address allocation function on DHCP server.
That is, the IP address the server allocates to the client is the IP address belongs to
the secondary address segment on the Ethernet interface of the server. This IP
address is allocated from the global address pool. Meantime, you are required to
configure the secondary IP address on the Ethernet interface of the server.
Additionally, the secondary IP address should be on the same network segment
with the global address pool.
z Configured with the subaddress allocation function, the system allocates addresses
from the address pool of the secondary IP address when no address can be
allocated from the address pool of the main IP address. When multiple secondary
addresses are configured to the interface, the system searches addresses
according to the order that the secondary addresses are configured. That is, the
system searches the address pool of the first-configured secondary address; if no
address can be allocated, it searches the secondary address configured secondly.
5.3.2 Adding Global DHCP Address Pool
DHCP server allocates IP addresses from the address pool. When DHCP client
originates DHCP requests to DHCP server, the server will choose a proper address
pool according to a certain algorithm and select a free IP address, which, along with
other parameters (for example DNS IP address, address lease limit), is sent to the
client. A DHCP server by far can be configured with multiple address pools. Comware
supports 128 global address pools currently.
The address pools in DHCP server is in tree structure: the native segment address as
root, sub-net addresses as branch, addresses bound to the clients as leaf nodes. This
structure guarantees configuration inheritance: the sub-net (son node) inherits the
configurations of the native segment (father node); the client (grandson node) inherits
the configurations of the sub-net. For those common parameters, for example domain
name, you can just configure them at the native segment or sub-net. You can view the
structure of the address pools with the display dhcp server tree command. The order
for those address pools at the same level is defined by creation time.
5-14
Table 5-5 Add global DHCP address pool
Operation Command
Adds DHCP address pool or enter
dhcp server ip-pool pool-name
DHCP address pool view
Deletes DHCP address pool undo dhcp server ip-pool pool-name
By default, no global DHCP address pool is created.
5.3.3 Defining Allocation Mode of DHCP Address Pool
You can select static address binding or dynamic address binding accordingly, but you
can only choose one of them for a given DHCP address pool.
For dynamic address allocation mode, you should specify address range. Static
address binding can be deemed as a special DHCP address pool with only one
address.
I. Configuring statistic address binding
Some DHCP clients may require a fixed IP address, i.e., binding the client MAC
address or identifier to an IP address. Then when the DHCP client with this MAC
address or identifier requests for an IP address, DHCP server will find and allocate the
bound IP address to the client.
Perform the following configuration in DHCP address pool view.
Table 5-6 Configure static address binding
Operation Command
static-bind ip-address ip-address
Configures static IP address binding
[ mask netmask ]
Deletes static IP address binding undo static-bind ip-address
static-bind { mac-address
Configures static client MAC address
mac-address | client-identifier
binding
client-identifier }
Deletes static client MAC address undo static-bind { mac-address |
binding client-identifier }
By default, no binding is configured and the client MAC address or identifier is set as
Ethernet.
5-15
Note:
z The static-bind { mac-address | client-identifier } and static-bind ip-address
commands must be used in pairs. If you use the commands repeatedly, the new
settings will overwrite the previous one.
z When the firewall is used as a DHCP client to dynamically obtain IP addresses, you
need to bind the identifier, instead of interface MAC address, to the IP address when
configuring static binding on the DHCP server, since the DHCP client packets from
the firewall contain the identifier field.
z Each MAC address or identifier can only be bound to one IP address.
II. Configuring static address binding for interface address pool
Table 5-7 Configure static address binding for interface address pool
Operation Command
dhcp server static-bind ip-address
Configures statistic address binding for
ip-address { mac-address mac-address
the address pool of the current interface
| client-identifier client-identifier }
undo dhcp server static-bind
{ ip-address ip-address | mac-address
Deletes static address binding
mac-address | client-identifier
client-identifier }
III. Configuring dynamic address allocation
For the dynamic addresses (including permanent ones or those lease limit dynamic
ones), you should configure them with address pool range. Currently only one address
segment can be set to an address pool, which is define by the mask.
Table 5-8 Configure IP address range for dynamic allocation
Operation Command
Configures IP address range for
network ip-address [ mask netmask ]
dynamic allocation
Delete dynamic IP address range undo network
By default, no DHCP address pool is available for dynamic allocation.

If you use the command repeatedly, the new configurations will overwrite the previous
ones.
5-16
5.3.4 Excluding IP Address from Auto Allocation
In configuring address allocation by DHCP server, you should exclude those in-use IP
addresses. Otherwise, one IP address may be allocated to two hosts, which will cause
address conflict.
Table 5-9 Exclude IP address from auto allocation
Operation Command
dhcp server forbidden-ip
Forbids auto allocation of an IP address
low-ip-address [ high-ip-address ]
undo dhcp server forbidden-ip

Allows auto allocation of the IP address
low-ip-address [ high-ip-address ]
By default, all addresses in the DHCP address pool will be automatically allocated.
Using this command repeatedly, you can exclude multiple IP addresses from being
allocated.
5.3.5 Defining IP Address Lease Expiry Limit
DHCP server can assign different lease duration limit for different address pools, but
the same lease duration limit for the addresses in the same address pool.
Address lease duration limit cannot be renewed automatically.
The system provides different configuration modes for different types of address pools.
I. Global DHCP address pool
Table 5-10 Configure lease expiry limit for global DHCP address pool
Operation Command
Configures expiry limit for dynamic IP expired { day day [ hour hour [ minute
address lease minute ] ] | unlimited }
Resets the lease expiry limit to the
undo expired
default value
II. Interface DHCP address pool
5-17
Table 5-11 Configure lease expiry limit for interface DHCP address pool
Operation Command
Configures expiry limit for dynamic IP dhcp server expired { day day [ hour
address lease hour [ minute minute ] ] | unlimited }
Resets the lease expiry limit to the
undo dhcp server expired
default value
III. Multiple interface DHCP address pools
You can also configure lease limit for DHCP address pool on multiple interfaces at one
blow.
Table 5-12 Configure lease expiry limit for DHCP address pool on multiple interfaces
Operation Command
dhcp server expired { day day [ hour hour
Configures expiry limit for dynamic
[ minute minute ] ] | unlimited } { interface
IP address lease
Resets the lease expiry limit to the undo dhcp server expired { interface
default value ethernet-subinterface-range | all }
By default, an IP address lease expires after one day.
Note:
For some DHCP configuration items, the system provides different configuration
modes for different types of DHCP address pools. You can configure these items
respectively in the global DHCP address pool, interface DHCP address pool and
multiple interface DHCP address pools. Typically, the last configuration mode is useful
to reduce the configuration repetition in some applications.
These configuration tasks include: Configuring domain name for DHCP client,
configuring DNS IP address for DHCP client, configuring NetBIOS IP address for
DHCP client, defining NetBIOS node type for DHCP client and configuring DHCP
customization items.
5.3.6 Configuring Domain Name for DHCP Client
You can specify a domain name to each DHCP client at DHCP server.
5-18
Perform the following configuration in DHCP address pool view to configure the global
DHCP address pool.
Table 5-13 Configure DHCP client domain name in global DHCP address pool
Operation Command
Configures a domain name to DHCP
domain-name domain-name
client
Delete the domain name to DHCP client undo domain-name
Perform the following configuration in interface view to configure the interface DHCP
address pool.
Table 5-14 Configure domain name to DHCP client in interface DHCP address pool
Operation Command
Configures a domain name to DHCP dhcp server domain-name
client domain-name
Delete the domain name to DHCP client undo dhcp server domain-name
Perform the following configuration in system view to configure multiple interface DHCP
address pools.
Table 5-15 Assign domain name to DHCP client in multiple interface DHCP address
pools
Operation Command
Configures a domain name to dhcp server domain-name domain-name
DHCP client { interface ethernet-subinterface-range | all }
Delete the domain name to undo dhcp server domain-name { interface
DHCP client ethernet-subinterface-range | all }
By default, no domain name is allocated to DHCP client.
5.3.7 Configuring DNS IP Address for DHCP Client
When the host accesses the Internet through domain name, it should translate the
domain name into IP address, which is implemented by Domain Name System (DNS).
To access DHCP client successfully into the Internet, DHCP server ought to assign
DNS IP address at the time allocating IP address to the client.
A maximum of eight DNS addresses by far can be configured in a DHCP address pool.
Perform the following configuration in DHCP address pool view to configure global
DHCP address pool.
5-19
Table 5-16 Configure DNS IP address in global DHCP address pool
Operation Command
Configures a DNS IP address to DHCP
dns-list ip-address [ ip-address ]
client
Delete the DNS IP address to DHCP
undo dns-list { ip-address | all }
client
Perform the following configuration in interface view to configure interface DHCP

address pool.
Table 5-17 Configure DNS IP address in interface DHCP address pool
Operation Command
Configures a DNS IP address to DHCP dhcp server dns-list ip-address
client [ ip-address ]
Delete the DNS IP address to DHCP undo dhcp server dns-list { ip-address
client | all }
address pools.
Table 5-18 Configure DNS IP address in multiple interface DHCP address pools
Operation Command
dhcp server dns-list ip-address
Configures a DNS IP address to DHCP
[ ip-address ] { interface
client
undo dhcp server dns-list { ip-address
Deletes the DNS IP address to DHCP
| all } { interface
client
By default, no DNS IP address is configured to DHCP client.
5.3.8 Configuring NetBIOS IP Address for DHCP Client
For those clients running on Microsoft operating system, WINS (Windows Internet
Naming Service) server is required to translate host name into IP address for the hosts
using NetBIOS protocol. So most Windows client may require WINS settings.
A maximum of eight NetBIOS addresses currently can be configured in a DHCP
address pool.
DHCP address pool.
5-20
Table 5-19 Configure NetBIOS IP address in global DHCP address pool
Operation Command
Configures a NetBIOS address to DHCP
nbns-list ip-address [ ip-address ]
client
Deletes the NetBIOS address to DHCP
undo nbns-list { ip-address | all }
client

address pool.
Table 5-20 Configure NetBIOS IP address to DHCP client in interface
Operation Command
Configures a NetBIOS address to DHCP dhcp server nbns-list ip-address
client [ ip-address ]
Deletes the NetBIOS address to DHCP undo dhcp server nbns-list
client { ip-address | all }
address pools.
Table 5-21 Configure NetBIOS IP address to DHCP client in multiple interface DHCP
address pools
Operation Command
dhcp server nbns-list ip-address
Configures a NetBIOS address to DHCP
[ ip-address ] { interface
client
undo dhcp server nbns-list

Deletes the NetBIOS address to DHCP
{ ip-address | all } { interface
client
By default, no NetBIOS IP address is configured to DHCP client.
5.3.9 Defining NetBIOS Node Type for DHCP Client
Mapping must be established between the host name and IP address when DHCP
client uses NetBIOS protocol for communications over Wide Area Network (WAN). In
terms of mapping establishment mode, NetBIOS node can be divided as
z b-node: b here stands for broadcast, that is, the node gets mapping through
broadcast.
z p-node: p here stands for peer-to-peer. The node gets mapping by communicating
with the NetBIOS server.
5-21
z m-node: m here stands for mixed. It is the p-node embraces part of the broadcast
attributes.
z h-node: h here stands for hybrid. It is b-node for which peer-to-peer
communication is available.
Perform the following configuration in DHCP address pool view to configure DHCP
address pool.
Table 5-22 Define NetBIOS node type in global DHCP address pool
Operation Command
Defines NetBIOS node type for DHCP netbios-type { b-node | h-node |
client m-node | p-node }
Resets NetBIOS node type to the default
undo netbios-type
value

address pool.
Table 5-23 Define NetBIOS node type in interface DHCP address pool
Operation Command
Defines NetBIOS node type for DHCP dhcp server netbios-type { b-node |
client h-node | m-node | p-node }
undo dhcp server netbios-type
value
Perform the following configuration in interface view to configure multiple interface

DHCP address pools.
Table 5-24 Define NetBIOS node type in multiple interface DHCP address pools
Operation Command
dhcp server netbios-type { b-node |
Defines NetBIOS node type for DHCP
h-node | m-node | p-node } { interface
client
undo dhcp server netbios-type

{ interface ethernet-subinterface-range
value
| all }
By default, h-node is configured for DHCP client.
5-22
5.3.10 Configuring DHCP Customization Items
With further development of DHCP technology, new optional configuration items may
arise. Then you can add in custom way these items into DHCP server attribute table.
DHCP address pool.
Table 5-25 Configure customization items of global DHCP address pool
Operation Command
option code { ascii ascii-string | hex
Adds DHCP customization items
hex-string | ip-address ip-address }
Deletes DHCP customization items undo option code

address pool.
Table 5-26 Configure customization items of interface DHCP
Operation Command
dhcp server option code { ascii
Adds DHCP customization items ascii-string | hex hex-string | ip-address
ip-address }
Deletes DHCP customization items undo dhcp server option code
Perform the following configuration in interface view to configure multiple interface

DHCP address pools.
Table 5-27 Configure customization items of multiple interface DHCP
Operation Command
dhcp server option code { ascii ascii-string |
Adds DHCP customization items hex hex-string | ip-address ip-address }
{ interface ethernet-subinterface-range | all }
undo dhcp server option code { interface
Deletes DHCP customization items
code is a legal option value, in the range 2 to 254, in which number 3, 6, 15, 44, 46, 50
through 55, 57 through 61, 184 and 217 are retained by the system.
5.3.11 Configuring Egress Gateway for DHCP Client
DHCP client must use an egress gateway for data transmission and receiving when
accessing the server or host with the IP address not in the segment.
5-23
Table 5-28 Configure egress gateway for DHCP client
Operation Command
Configures egress gateway for DHCP
gateway-list ip-address [ ip-address ]
client
Deletes the egress gateway undo gateway-list { ip-address | all }
By default, no egress gateway is configured to DHCP client.

A maximum of eight egress gateway addresses currently can be configured in a DHCP.
Note:
To configure multiple egress gateway addresses, give out the ip-address parameter
one by one.
5.3.12 Configuring ping Packet Transfer in DHCP Server
To prevent IP address conflict, DHCP server will check whether an address has been
allocated before allocating it to the client.
You can initiate IP address check with the command ping. If no response is sent back,
then continue to send ping packets till the maximum ping packets allowed are sent. If
there is still no response sent back with the preset time limit, then you can conclude that
this IP address is free. This ensures the client a unique IP address.
Table 5-29 Configure ping packet transfer in DHCP server
Operation Command
Configures maximum number of ping
dhcp server ping packets number
packet for transfer in DHCP server
Resets the maximum number of ping
undo dhcp server ping packets
packet to the default value
Configures time limit to receive ping
dhcp server ping timeout milliseconds
response
Resets time limit to receive ping
undo dhcp server ping timeout
response to the default value
5-24
By default, two ping packets can be transferred and 500 milliseconds are set for DHCP
server to receive ping response.
DHCP server detects address conflict by sending ping packets, while DHCP client
sends ARP packets.
5.3.13 Configuring DHCP Server Accounting
The function of DHCP server accounting is used to send accounting packets to the
RADIUS accounting server in the specified domain when the DHCP server distributes
and releases lease.
When a user applies for an IP address, the DHCP server with DHCP server accounting
configured assigns the user the lease containing IP addresses, lease time limit and
other configuration information. After assigning lease successfully, the DHCP server
immediately notifies the RADIUS accounting server in the specified domain and sends
RADIUS START. When the lease is overdue, or the DHCP server receives a release
request from the user, or lease is deleted manually, or the address pool is deleted
manually, or others, the DHCP server lease is released. The DHCP server notifies the
RADIUS accounting server in the specified domain immediately and sends RADIUS
STOP. The RADIUS server records the used IP addresses, and does not account
really.
You can specify a domain used for accounting for every address pool in the DHCP
server.
Table 5-30 Configure the domain used for accounting in global DHCP address pool
Operation Command
Configure the domain used for DHCP
accounting domain domain-name
server accounting
Disable DHCP server accounting undo accounting domain
Table 5-31 Configure the domain used for accounting in interface DHCP address pool
Operation Command
Configure domain used for DHCP server dhcp server accounting domain
accounting domain-name
Disable DHCP server accounting undo dhcp server accounting domain
address pool.
5-25
Table 5-32 Configure the domain used for accounting in multiple interface DHCP
address pool
Operation Command
dhcp server accounting domain
Configure domain used for
domain-name { interface
DHCP server accounting
undo dhcp server accounting domain

Disable DHCP server accounting
{ interface ethernet-subinterface-range | all }
By default, DHCP server accounting is disabled.

For RADIUS server and domain configuration, refer to “Security” Part in this manual.
5.3.14 Configuring BIMS Option for DHCP Server
Before configuring the feature of BIMS option for DHCP server, complete the following
tasks:
z Enable the DHCP server function and configure the address pools on the firewall.
z Configure the DHCP clients.
z Ensure that the DHCP clients, DHCP server, and BIMS server are reachable.
II. Configuring BIMS option
The following table describes the BIMS option configuration tasks.
Table 5-33 Configure BIMS option

Enter system
system-view —
view
dhcp server bims-server Required.

ip ip-address port
Enable and port-number sharekey key You can configure this command
configure BIMS { interface interface-type in system view or the
option interface-number to bims-server command in global
interface-type DHCP address pool view, but not
interface-number | all } both.
5-26

dhcp server ip-pool
—
Enter global pool-name
DHCP address Required.
pool view
bims-server ip ip-address You can configure this command
Enable and in global DHCP address pool view
configure BIMS port port-number
sharekey key or the dhcp server bims-server
option command in system view, but not
both.
Note:
z If you configure BIMS option for a global address pool, the DHCP server sends the
BIMS option information together with the lease when assigning an IP address from
the global address pool to a DHCP client.
z If you configure BIMS option for an interface, the DHCP server sends the BIMS
option information together with the lease when assigning an IP address from the
interface address pool to a DHCP client.
z If you specify the all keyword in the dhcp server bims-server ip command, the
DHCP server sends the BIMS option information together with the lease when
assigning an IP address from any of the interface address pools to a DHCP client.
5.3.15 Configuring Option 184 for DHCP Server
You can configure the sub-options of Option 184 for the DHCP server in system view,
interface view or DHCP address pool. Interface address pool is required for the
configuration in system view and interface view.
Before configuring the feature of Option 184 for DHCP server, complete the following
tasks:
z Network parameters, address pool, address allocation lease and other allocation
policies are configured for the DHCP server.
z The DHCP server and client are reachable.
Refer to the DHCP section of “Network Layer Protocol” part in this manual for detailed
configurations.
5-27
II. Configuring Option 184 in system view
Table 5-34 Configure Option 184 in system view

Configure the interface to dhcp select interface
work in DHCP server { all | interface
mode and to allocate interface-type
Required
addresses from the interface-number [ to
specified interface interface-type
address pool interface-number ] }
dhcp server
voice-config ncp-ip
ip-address { all |
Configure the NCP-IP
interface interface-type Required
sub-option
interface-number [ to
interface-type
interface-number ] }
dhcp server
voice-config as-ip Optional
ip-address { all |
Configure the AS-IP You can configure it only
sub-option after the NCP-IP
interface-type sub-option is configured.
dhcp server
voice-config voice-vlan
vlan-id { enable | Optional
Configure the voice VLAN disable } { all | interface You can configure it only
configuration sub-option interface-type after the NCP-IP
interface-number [ to sub-option is configured.
interface-type
dhcp server
voice-config fail-over
ip-address dialer-string Optional
Configure the fail-over { all | interface You can configure it only
routing sub-option interface-type after the NCP-IP
interface-number [ to sub-option is configured.
interface-type
5-28

Enter the corresponding interface interface-type To create the interface
interface view interface-number address pool, you must
Configure interface IP ip address ip-address first configure the IP
address net-mask address of the interface.
Note:
This mode is applicable to the case where IP addresses are allocated from the interface
address pool.
Interface range can be defined in this mode, so you can configure Option 184 for DHCP
server on multiple interfaces simultaneously.
III. Configuring Option 184 in interface view
Table 5-35 Configuring Option 184 in interface view

Enter interface view —
interface-number
Configure interface IP ip address ip-address
—
address net-mask
Configure the interface to
work in DHCP server
mode and to allocate dhcp select interface Required
addresses from the
interface address pool
dhcp server
Configure the NCP-IP
voice-config ncp-ip Required
sub-option
ip-address
Optional
dhcp server
Configure the AS-IP You can configure it only
voice-config as-ip
sub-option after the NCP-IP
ip-address
sub-option is configured.
dhcp server Optional

Configure the voice VLAN voice-config voice-vlan You can configure it only
configuration sub-option vlan-id { enable | after the NCP-IP
disable } sub-option is configured.
5-29

Optional
dhcp server
Configure the fail-over You can configure it only
voice-config fail-over
routing sub-option after the NCP-IP
ip-address dialer-string
Note:
This mode is applicable to the case where IP addresses are allocated from the interface
address pool. You can configure Option 184 for DHCP server on a single interface in
this mode.
IV. Configuring Option 184 in global DHCP address pool view
Table 5-36 Configure Option 184 in global DHCP address pool view

dhcp select global

Configure the interface to
[ subaddress ] { all |
work in DHCP server
mode and to allocate Required
addresses from the global
interface-type
DHCP address pool
Enter DHCP address pool dhcp server ip pool
—
view pool-name
Configure IP address
network ip-address
range for dynamic Required
[ mask netmask ]
allocation
Configure the NCP-IP voice-config ncp-ip
Required
sub-option ip-address
Optional
Configure the AS-IP voice-config as-ip You can configure it only
sub-option ip-address after the NCP-IP
Optional
voice-config voice-vlan
Configure the voice VLAN You can configure it only
vlan-id { enable |
configuration sub-option after the NCP-IP
disable }
5-30

Optional
Configure the fail-over voice-config fail-over You can configure it only
routing sub-option ip-address dialer-string after the NCP-IP
Note:
This mode is applicable to the case where IP addresses are allocated from the global
DHCP address pool.
5.3.16 Clearing DHCP Information
Use the display dhcp server ip-in-use command in any views to display dynamic
address binding information of the address pool. You can delete the information using
the corresponding command.
Use the display dhcp server conflict command in any views to display DHCP
address conflict information. You can delete the information using the corresponding
command.
Use the display dhcp server statistics command in any views to display DHCP
server information. You can delete the information using the corresponding command.
Table 5-37 Clear DHCP information
Operation Command
Clear binding information of a specific IP reset dhcp server ip-in-use ip
address ip-address
Clear dynamic address binding reset dhcp server ip-in-use pool
information of the global address pool [ pool-name ]
Clear dynamic address binding reset dhcp server ip-in-use interface
information of the interface address pool [interface-type interface-number ]
Clear binding information of all address
reset dhcp server ip-in-use all
pools
Clear conflict information of a specific IP reset dhcp server conflict ip
address ip-address
Clear conflict information of all address
reset dhcp server conflict all
pool
5-31
Operation Command
Clear statistical information in DHCP
reset dhcp server statistics
server
5.4 DHCP Client Configuration

The configuration of DHCP client is simple to perform, only by configuring Ethernet
interface to get IP address from DHCP
Perform the following configuration in Ethernet interface view (including sub-interfaces)
Table 5-38 Configure DHCP client
Operation Command
Configures the interface to get IP address from
ip address dhcp-alloc
DHCP
Cancel the interface getting IP address from
undo ip address dhcp-alloc
DHCP
By default, the interface is not configured as getting IP address from DHCP.
Note:
z You cannot configure secondary IP address for an interface on which DHCP
dynamic IP address is enabled. That is, you cannot use the ip address dhcp-alloc
and ip address ip-address mask sub commands concurrently on the interface.
z If you use the gateway-list command on DHCP server, the firewall will have the
default route with the specified gateway as the next hop in its routing table when it
obtains the interface IP address and the interface goes up. If the firewall obtains
multiple gateway addresses through DHCP server, the firewall will create a default
route using the first gateway address after it obtains the interface IP address and the
interface goes up. For example:
[H3C] display ip routing-table
Destination/Mask Protocol Pre Cost Nexthop Interface
0.0.0.0/0 DHCPDEF 255 0 23.23.0.2 Ethernet1/0/0
The priority and cost for the default route are 255 and 0 respectively.
5.5 DHCP Relay Configuration

DHCP relay configuration tasks include:
5-32
z Setting interfaces to operate in DHCP relay mode

z Specifying external DHCP server addresses
z Configuring DHCP server load distribution by DHCP relay
z Releasing DHCP client IP address by DHCP relay
z Clearing DHCP relay statistics information
5.5.1 Setting Interfaces to Operate in DHCP Relay Mode
When the local device receives a DHCP packet with itself being the destination, the
device handles the packet depending on the specified operating mode. When
operating in DHCP server mode, the device forwards the packet to the local DHCP
server; when operating in relay mode, the device forwards the packet to an external
DHCP server.
Perform the following configuration in interface view to have the current interface
operate in DHCP relay mode.
Table 5-39 Set the current interface to operate in DHCP relay mode
Operation Command
Relay DHCP packets to an external
dhcp select relay
DHCP server for address allocation
Restore the default undo dhcp select
Perform the following configuration in system view to have the specified interfaces
operate in DHCP relay mode.
Table 5-40 Set multiple interfaces to operate in DHCP relay mode
Operation Command
Relay DHCP packets to an external dhcp select relay { interface
DHCP server for address allocation ethernet-subinterface-range | all }
undo dhcp select { interface
Resets the default
By default, dhcp select global applies.
Note:
When an Ethernet subinterface is used to provide the DHCP relay function, the DHCP
client must use a subinterface as well. If the client is a PC in this case, it cannot obtain
an IP address.
5-33
5.5.2 Specifying External DHCP Servers
When receiving a DHCP broadcast, the interface with DHCP relay enabled relays the
DHCP broadcast to the specified external DHCP server.
Perform the following configuration in interface view to specify an external DHCP
server address to which the received DHCP broadcasts are to be forwarded.
Table 5-41 Specify an external DHCP server address on the current interface
Operation Command
Specify an external DHCP server
ip relay address ip-address
address on the current interface
Delete one or all external DHCP server undo ip relay address { ip-address |
addresses on the current interface all }
Perform the following configuration in system view to specify an external DHCP server
address to which the DHCP broadcasts received on the specified interfaces are to be
forwarded.
Table 5-42 Configure an external DHCP server address for multiple interfaces
Operation Command
Specify an external DHCP server
ip relay address ip-address { interface
address for the interfaces in the
specified range
Remove an external DHCP server undo ip relay address { ip-address |
address for the interfaces in the all } { interface
specified range ethernet-subinterface-range | all }
Note:
Since the packets sent by the DHCP client are broadcast in some stages, the
corresponding interface must support broadcast.
Up to 20 external DHCP server addresses can be configured on an interface.
5.5.3 Configuring DHCP Server Load Balancing by DHCP Relay
You can use DHCP relay to configure several DHCP servers and balance traffic load
between them.
When multiple DHCP servers are configured, the DHCP Relay can distribute among
them requests from the clients from the clients using the HASH algorithm and thus
achieve load balancing.
5-34
Table 5-43 Configure DHCP server load balancing
Operation Command
Configure DHCP server load balancing ip relay address cycle
Cancel DHCP server load balancing undo ip relay address cycle
By default, no load balancing between DHCP servers is available.
5.5.4 Releasing Client IP Address by DHCP Relay
Sometimes you may release the IP address of a client by DHCP relay.

Perform the following configuration in interface view or system view.
Table 5-44 Release client IP address by DHCP relay
Operation Command
Requests DHCP server to release client dhcp relay release client-ip
IP address mac-address
Requests a specific DHCP server to dhcp relay release client-ip
release client IP address mac-address server-ip
If no DHCP server is specified, in system view, the release request will be sent to all
DHCP servers; while in interface view, the release request will be sent to the current
interface.
Note:
After you configure the DHCP relay to release an IP address, the system notifies the
DHCP server to release the IP addresses in the DHCP ip-in-use address pool. The
released address is then put in the lease-expired queue. Normally, it will experience
some time before participating in allocation again. The released addresses are from the
DHCP ip-in-use address pool. The client does not release the IP address till the lease
expires.
5.5.5 Clearing DHCP Relay Statistics Information
Use the command display dhcp relay statistics in any views to view DHCP relay
information. The information can certainly be cleared out.
5-35
Table 5-45 Clear DHCP relay statistics information
Operation Command
Clears DHCP relay information reset dhcp relay statistics
5.6 Displaying and Debugging DHCP

When the aforementioned configurations are completed, use the display command in
any views to show DHCP running status, for purpose of checking configuration
information.
Using the debugging command in user view, you can enable DHCP debugging.
I. Displaying and debugging DHCP server
Table 5-46 Display and debug DHCP
Operation Command
Display free address information in
display dhcp server free-ip
DHCP address pool
Display in-conflict DHCP address display dhcp server conflict { ip
information ip-address | all }
display dhcp server expired { ip
Display expired leases in DHCP address ip-address | pool [ pool-name ] |
pool interface [ interface-type
interface-number ] all }
display dhcp server ip-in-use { all | ip
Display DHCP address binding ip-address | pool [ pool-name ] |
information interface [ interface-type
Display DHCP server information display dhcp server statistics
display dhcp server tree { pool
Display tree architecture information
[ pool-name ] | interface [interface-type
about DHCP address pool
interface-number ] | all }
debugging dhcp server { error | event
Enable DHCP server debugging
| packet |all}
undo debugging dhcp server { event |
Disable DHCP server debugging
packet | error |all}
reset dhcp server ip-in-use { ip

Delete the information of DHCP dynamic ip-address | pool [ pool-name ] |
address binding interface [interface-type
interface-number ] | all }
Delete the statistics of DHCP address reset dhcp server conflict { ip-address
conflict | all }
5-36
Operation Command
Delete the statistics of the DHCP server reset dhcp server statistics
Note:
The lease information is not saved in the DHCP server’s Flash when you execute the
save command. So there is not any lease information in the configuration files when the
system restarts or when you use the reset dhcp server ip-in-use command to delete
the lease information. If a client requests lease renewal at this time, the system will not
permit it but require the client to apply for the IP address again.
II. Displaying and debugging DHCP relay
Table 5-47 Display and debug DHCP relay
Operation Command
Display the IP information of the display ip interface [ interface-type
interface of DHCP relay interface-number ]
Display the statistics of DHCP relay display dhcp relay statistics
Display the DHCP relay address of the display dhcp relay address { interface
interface interface-type interface-num | all }
debugging dhcp relay { all | error |
Enable the DHCP relay debugging event | packet [ client mac
mac-address ] }
undo debugging dhcp relay { all |
Disable the DHCP relay debugging error | event | packet [ client mac
mac-address ] }
III. Displaying and debugging DHCP client
Table 5-48 Display and debug DHCP client
Operation Command
Display the statistics of DHCP client display dhcp client [ verbose ]
debugging dhcp client { error | event |
Enable the DHCP client debugging
packet | all }
undo debugging dhcp client { error |
Disable the DHCP client debugging
event | packet | all }
5-37
5.7 DHCP Configuration Examples

5.7.1 DHCP Server Configuration Examples
There are two common types of DHCP networking modes: one is that both DHCP
server and DHCP client are in the same subnet and they exchange signals using DHCP.
The second is that DHCP server and DHCP client are in different subnets, which
requires DHCP relay agent to perform IP address allocation. The configuration details
are the same in both networking modes.
The DHCP server allocates dynamic IP address to the DHCP client which is in the
same subnet. The address pool segment 10.1.1.0/24 is divided into two sub-segments:
10.1.1.0/25 and 10.1.1.128/25. The two Ethernet interface of DHCP server are with the
addresses 10.1.1.1/25 and 10.1.1.129/25.
For the segment 10.1.1.0/25, the address lease limit is 10 days and 12 hours; the
domain name is h3c.com; the DNS address is 10.1.1.2; no NetBIOS is configured; the
egress gateway address is 10.1.1.126. For the segment 10.1.1.128/25, the address
limit is 5 days; the DNS address is 10.1.1.2; the NetBIOS address is 10.1.1.4; the
egress gateway address is 10.1.1.254.
II. Network diagram
NetBIOS Server Client Client Client
LAN LAN
RouterA SecPath RouterB

DHCP Server
DNS Server Client Client Client
Figure 5-6 DHCP server and client reside in the same subnet
# Enable DHCP services.

[H3C] dhcp enable
# Forbid auto-allocation of IP addresses (including DNS address, NetBIOS address

and egress gateway address)
[H3C] dhcp server forbidden-ip 10.1.1.2
5-38
# Configure common attributes for DHCP address pool 0 (address pool range and DNS
address).
[H3C] dhcp server ip-pool 0
[H3C-dhcp-0] network 10.1.1.0 mask 255.255.255.0
[H3C-dhcp-0] dns-list 10.1.1.2
# Configure attributes for DHCP address pool 1 (address pool range, domain name,
egress gateway address and address lease limit)
[H3C-dhcp-1] domain-name h3c.com
[H3C-dhcp-1] gateway-list 10.1.1.126
[H3C-dhcp-1] expired day 10 hour 12
# Configure attributes for DHCP address pool 2 (address pool range, egress gateway
address, NetBIOS address and address lease limit).
[H3C-dhcp-2] gateway-list 10.1.1.254
[H3C-dhcp-2] nbns-list 10.1.1.4
[H3C-dhcp-2] expired day 5
5.7.2 DHCP Relay Configuration Examples
The segment for DHCP client is 10.110.0.0 and that for DHCP server is 202.38.0.0. A
firewall which supports DHCP relay function is required for forwarding DHCP
messages, so that DHCP client can request configuration information (for example IP
address) successfully from DHCP server.
The DHCP server is configured with an IP address pool whose segment is 10.110.0.0,
so the IP addresses can be allocated to the DHCP clients on this segment. DHCP
server is also configured with routes to the segment 10.110.0.0.
5-39
II. Network diagram
DHCP Server
202.38.1.2
10.110.0.0
Ethernet
10.110.1.1
202.38.1.1
SecPath
IP Network Ethernet
DHCP Relay
202.38.0.0
Figure 5-7 DHCP relay configuration
Configure the firewall:

# Enable DHCP services
[H3C] dhcp enable
# Enter an interface where DHCP relay function has been enabled, configure IP
address and mask for it, and ensure that the interface and DHCP client are in the same
segment.
# Configure IP relay address for the interface to specify the target DHCP server.
[H3C-Ethernet6/0/0] dhcp select relay
[H3C-Ethernet6/0/0] ip relay address 202.38.1.2
Configurations on DHCP server will not be mentioned here.
5.7.3 DHCP Client Configuration Examples
We will introduce two types of DHCP client configurations here: one is that the Ethernet
gets dynamic IP addresses, the other is that the Ethernet sub-interface gets dynamic IP
addresses (supporting VLAN).
I. Ethernet interface serving as the DHCP client
Two Ethernet interfaces Ethernet1/0/0 and Ethernet2/0/0 on firewall SecPath A access
LAN 1 and LAN 2 respectively. LAN1 has a DHCP server, server 1, and LAN 2 has a
server 2. Both of them are firewalls. LAN1 resides at the segment 200.254.0.0/16 and
LAN 2 resides at the segment 172.10.0.0/16. We intend to configure the above two
Ethernet interfaces on SecPath A to acquire addresses through DHCP.
5-40
2) Network diagram
SecPathB
PC DHCP Server1
LAN1
E1/0/0
SecPathA
DHCP Client
E2/0/0
LAN2
SecPathC
DHCP Server2
Figure 5-8 Master interface serving as the DHCP client
The following are configurations on both DHCP server and client.
# Configure server 1.
[H3C] dhcp enable
[H3C-dhcp1] network 200.254.0.0 mask 255.255.0.0
# Configure server 2.
[H3C] dhcp enable
[H3C-dhcp2] network 172.10.0.0 mask 255.255.0.0
# Configure Ethernet1/0/0 of GW A to dynamically acquire addresses through DHCP.

[H3C-Ethernet1/0/0] ip address dhcp-alloc
# Configure Ethernet2/0/0 of GW A to dynamically acquire addresses through DHCP.

[H3C-Ethernet2/0/0] ip address dhcp-alloc
5-41
II. Ethernet sub-interface dynamically acquire IP addresses
DHCP servers 1 and 2 are respectively in VLAN 10 and VLAN 20. The configuration
task is to create sub-interfaces and configure getting dynamic IP addresses
respectively from the two DHCP servers.
2) Network diagram
DHCP Server 1 Eth0/0/0
Eth0/0/0
SecPath
(DHCP Client)
Eth0/0/0
DHCP Server 2
Figure 5-9 Sub-interface serves as DHCP client
Configure LAN Switch first (it is not detailed here) and make sure that DHCP servers 1
and 2 can be respectively connected into VLAN 10 and VLAN 20. Then configure RTA
interface as Trunk interface which enables transparent transmission of messages for
VLAN 10 and VLAN 20.
The configurations of DHCP server 1 and server 2 are similar to those in above
example, so we will give the configurations of DHCP client below.
# Configure the sub-interface which gets IP addresses from DHCP server 1.
[H3C] interface ethernet0/0/0.1
[H3C-Ethernet0/0/0.1] ip addr dhcp-alloc
# Configure the sub-interface which gets IP addresses from DHCP server 2.

[H3C] interface ethernet0/0/0.2
[H3C-Ethernet0/0/0.2] ip addr dhcp-alloc
5.7.4 DHCP Accounting Configuration Example
z The DHCP server is connected to the DHCP client and the RADIUS server
through interfaces Ethernet1/0/0 and Ethernet1/0/1 respectively.
z The IP address of the RADIUS server is 10.1.2.2/24.
5-42
z DHCP accounting is enabled on the DHCP server. The global DHCP address pool
is 10.1.1.0. As a RADIUS client, the DHCP server employs AAA for authentication.
II. Network diagram
10.1.1.1/24 10.1.2.1/24
DHCP Server RADIUS Server

10.1.2.2/24
DHCP Client
Figure 5-10 Network diagram for DHCP accounting configuration
# Configure DHCP server network parameters.

<H3C> system-view
# Configure the domain, create the RADIUS scheme, and configure the association
between them.
[H3C] radius scheme 123
[H3C-radius-123] primary authentication 10.1.2.2
[H3C-radius-123] primary accounting 10.1.2.2
[H3C] domain 123
[H3C-isp-123] scheme radius-scheme 123
[H3C-isp-123] quit
# Configure an address pool for the DHCP server.

[H3C] dhcp server ip-pool test
[H3C-dhcp-pool-test] network 10.1.1.0 mask 255.255.255.0
# Configure DHCP accounting.

[H3C-dhcp-pool-test] accounting domain 123
5.7.5 Configuration Example of IP Phone’s Request for Option 184
As a DHCP client, the IP phone requests for all sub-options configuration of Option 184
from the DHCP server, which is the firewall. Configure Option 184 in global address
5-43
pool view, with NCP-IP as 3.3.3.3, AS-IP as 2.2.2.2, voice VLAN enable, VLAN ID as 1,
fail-over IP as 1.1.1.1 and dialer string as 99*.
II. Network diagram
Client Client
DHCP Server
LAN
Ethernet1/0/0
10.1.1.1/24
Client IP phone
Figure 5-11 Network diagram for Option 184 configuration
1) Configure the DHCP client

IP phone enables DHCP client function and is configured all sub-options of Option 184
as requested. The configuration procedure is omitted.
2) Configure the DHCP server.
<H3C>
<H3C> system-view
[H3C] dhcp select global interface ethernet 1/0/0
[H3C-dhcp-pool-123] network 10.1.1.1 mask 255.255.255.0
[H3C-dhcp-pool-123] voice-config as-ip 2.2.2.2
[H3C-dhcp-pool-123] voice-config ncp-ip 3.3.3.3
[H3C-dhcp-pool-123] voice-config voice-vlan 1 enable
[H3C-dhcp-pool-123] voice-config fail-over 1.1.1.1 99*
[H3C-dhcp-pool-123] quit
5-44
H3C SecPath Series Security Products Chapter 6 IP Performance Configuration
Chapter 6 IP Performance Configuration
6.1 Configuring Maximum Transmission Unit (MTU)

MTU size of the interface decides whether the IP packets on the interface need to be
fragmented.
Table 6-1 Configure MTU of the interface
Operation Command
Configure MTU of the interface mtu mtu-size
Restore to the default value of the interface MTU undo mtu
The default value of the interface MTU is 1500 bytes when using Ethernet_II frame
format.
6.2 Configuring TCP Packet Fragmentation

The parameter of TCP packet fragmentation determines whether the TCP packets are
to be fragmented.
Perform these commands in interface view.
Table 6-2 Configure TCP packets fragmentation
Operation Command
Enable TCP packet fragmentation tcp mss value
Disable the TCP packet fragmentation undo tcp mss
By default, TCP packets are not fragmented.
6.3 Configuring TCP Attributes

TCP attributes that can be configured include:
z synwait timer: When sending the synwait packets, TCP starts the synwait timer. If
response packets are not received before synwait timeout, the TCP connection
will be terminated. The range of synwait timer timeout time is 2 to 600 seconds,
and the default is 75 seconds.
z finwait timer: When the TCP connection state turns from FIN_WAIT_1 to
FIN_WAIT_2, finwait timer will be started. If FIN packets are not received before
6-1
finwait timer timeout, the TCP connection will be terminated. The range of finwait
is 76 to 3600 seconds and the default of finwait is 675 seconds.
z The receiving/sending buffer size of connection-oriented Socket: The range is 1 to
32 KB and the default is 8 KB.
Table 6-3 Configure TCP attributes
Operation Command
Configure synwait timer time for TCP
tcp timer syn-timeout time-value
connection establishment
Restore synwait timer time for TCP
connection establishment to default undo tcp timer syn-timeout
value
Configure FIN_WAIT_2 timer time of
tcp timer fin-timeout time-value
TCP
Restore FIN_WAIT_2 timer time of TCP
undo tcp timer fin-timeout
to default value
Configure Socket receiving/sending
tcp window window-size
buffer size of TCP
Restore Socket receiving/sending buffer
undo tcp window-
size of TCP to default value
By default, TCP finwait timer is 675 seconds, TCP synwait timer defaults to 75 seconds
and the receiving/sending buffer size of the connection-oriented Socket defaults to 8
KB.
6.4 Configuring ICMP to Send Redirection Packets
ip route-static 192.168.0.1 16
10.153.72.117 192.168.0.1
gateway Router
10.153.72.125 10.153.72.117
10.153.72.130
PC
Figure 6-1 Network diagram for ICMP to send redirection packets
6-2
As shown in the above figure, the PC sends a packet to the gateway before sending the
packet to the router, and then the gateway forwards the packet to the router. Therefore
you need to enable ICMP to send redirection packets on the gateway, and then the
gateway can send redirection packets to the PC, making the PC forward the packet to
the router directly.
Table 6-4 Configure ICMP to send redirection packets
Operation Command
Enable ICMP to send redirection packets icmp redirect send
Disable ICMP to send redirection packets undo icmp redirect send
By default, the system enables ICMP to send redirection packets.
6.5 Displaying and Debugging IP Performance

running of the IP Performance, and to verify the effect of the configuration.
Execute the reset command in user views to clear the running statistic information.
Execute the debugging command in user view for the debugging of IP Performance.
Table 6-5 Display and debug of IP performance
Operation Command
Show TCP connection state display tcp status
Show TCP traffic statistic information display tcp statistics
Show UDP traffic statistic information display udp statistics
Show information on all the current display ip socket [ socktype
socket interfaces in the system. sock_type ] [ task_id socket_id ]
Show information on the IP layer display ip interface [ interface-type
interface table. interface-number ]
Show information on the FIB of interface
display fib
cards.
Output rows that include the string
display fib | { begin | include |
defined by text from the cache in regular
exclude } text
expressions.
Show the filtered FIB information. display fib acl acl-number
Show FIB entries by destination display fib dest-addr1 [ dest-mask1 ]
address. [ longer ]
6-3
Operation Command
Show FIB entries with destination
display fib dest-addr1 dest-mask1
addresses in the range dest-addr1
dest-addr2 dest-mask2
dest-mask1 to dest-addr2 dest-mask2.
Show in certain format FIB entries that
are filtered in by the rules in the specified display fib ip-prefix listname
IP-prefix list.
Show the total number of FIB entries. display fib statistics
Enable IP packet information debugging debugging ip packet [ acl acl-number ]
Disable IP packet information debugging undo debugging ip packet
Enable ICMP debugging. debugging ip icmp
Disable ICMP debugging undo debugging ip icmp
Enable TCP packet information debugging tcp packet [ task_id
debugging socket_id ]
Disable TCP packet information undo debugging tcp packet [ task_id
Enable UDP packet information debugging udp packet [ task_id
Disable UDP packet information undo debugging udp packet [ task_id
debugging. socket_id ]
debugging tcp event [ task_id
Enable TCP event debugging
socket_id ]
undo debugging tcp event [ task_id
Disable TCP event debugging.
socket_id ]
Enable TCP MD5 authentication
debugging tcp md5
debugging
Disable TCP MD5 authentication
undo debugging tcp md5
debugging
Clear IP statistics reset ip statistics
Clear TCP traffic statistics reset tcp statistics
Clear UDP traffic statistics. reset udp statistics
Note:
You cannot view FIB information in the current version simultaneously using multiple
filtering methods.
6-4
6.6 Configuring Fast Forwarding

6.6.1 Brief Introduction to Fast Forwarding
Message forwarding efficiency is a key feature evaluating firewall performance.

According to regular flow, when a message arrives, the firewall will copy it from the
interface memory to the main CPU. The CPU specifies the network ID from the IP
address, consults with the routing table to get the best path to forward the message,
and creates MAC frame suitable for output of the message. The created MAC frame is
copied to the output queue via DMA (Direct Memory Access), and during this process
the main system bus is passed twice. This process can be repeated for message
forwarding.
In the Fast forwarding, cache is used to process messages based on data flow. As we
know, data on the Internet are all transmitted based on data flow. A data flow is a
specific application used to provide services between two hosts on the network, such
as to transmit a file using FTP. Generally, we describe a data flow in five elements,
namely, source IP address, source port number, destination IP address, destination
port number and protocol number. After the first message is forwarded by searching
routing table, corresponding exchange information is generated in the cache, and
forwarding of the following same messages can be realized by directly searching the
cache. This practice simplifies the queuing of IP messages, and cuts down the route
finding time and improves forwarding throughput of IP messages. Since the forwarding
table in the cache has been optimized, much quicker searching speed can be obtained.
The fast forwarding implemented by Comware provides:
z Fast forwarding on all types of high-speed link interfaces (including subinterfaces),
such as Ethernet, synchronous PPP, frame relay, and HDLC.
z Fast forwarding in presence of normal firewall.
z Fast forwarding in presence of ASPF firewall.
z Fast forwarding when NAT is configured.
z Fast forwarding when GRE is in use.
z Significantly improved forwarding efficiency.
The performance of Fast forwarding sometimes will be affected by some characteristics
such as message queue management and message header compression. Fast
forwarding is not conducted for fragmented messages.
6.6.2 Configuring Fast Forwarding
You can disable fast-forwarding as needed. For example, if load balance is required
when forwarding packets, fast-forwarding should be disabled in the forwarding direction
of the interface.
6-5
Table 6-6 Enable/disable fast-forwarding on an interface
Operation Command
Enable fast-forwarding in both directions
ip fast-forwarding
of the interface
Enable fast-forwarding on the inbound
ip fast-forwarding inbound
interface
Enable fast-forwarding on the outbound
ip fast-forwarding outbound
interface
undo ip fast-forwarding [ inbound |
Disable fast-forwarding on the interface
outbound ]
By default, fast-forwarding is enabled in the inbound/outbound directions of the

interface.
Caution:
z In non-fast-forwarding mode, load balance based on packet is supported.

z If fast-forwarding is configured on an interface, the interface will not send any ICMP
redirection packets.
z If fast-forwarding is configured on an interface, the debugging information of the IP
packets on the interface will not be displayed, that is, the debugging ip packet
command does not work.
z If fast-forwarding is configured and packet filtering is applied on an interface, ACL
only checks the first packet of the data flow (containing packets with the same
quintuple). If it is permitted to pass, a fast-forwarding entry is set up. Then, packets
that match this fast-forwarding entry will not be checked by ACL, but more values
will be added to the ACL count. If the packets in the same data flow (packets with the
same quintuple) have other different field values (ToS, DSCP, for example), they are
still be regarded as in the same data flow, and will be forwarded according to the
fast-forwarding entry. Therefore, you need to disable the fast-forwarding function if
you have configured ACL rules requiring different operations on packets in the same
data flow according to field values other than quintuple.
6-6
6.6.3 Displaying and Debugging Fast Forwarding
Table 6-7 Display and debug fast forwarding
Operation Command
display ip fast-forwarding cache
Display IP fast-forwarding cache
[ ip-address ]
Clear contents in the fast forwarding cache reset ip fast-forwarding cache
6.7 IP Performance Configuration Troubleshooting

Fault 1: The problem is that TCP and UDP cannot work normally.
Troubleshooting: You can enable the corresponding debugging information output to
view the debugging information.
z Use the command debugging udp packet to enable the UDP debugging
information output to trace the UDP packet. When the firewall sends or receives
UDP packets, the content format of the datagram can be displayed in real time.
You can locate the problem from the contents of the datagram.
The following are the UDP packet formats:
*0.348541898-SOCKET-8-UDPINI:UDP packet information :
Incoming UDP datagram:
source IP address: 172.16.101.70
source port: 138
destination IP address: 172.16.255.255
destination port: 138
The length of UDP packet: 209
z Use the command debugging tcp packet to enable the TCP debugging
information output to trace the TCP packets. Two TCP packet formats are
available for selection. One is to debug and trace the receiving and sending of all
the TCP packets of the TCP connection that take this device as one end. The
operations are as follows:
[H3C] quit
<H3C> debugging tcp packet
Then the TCP packets received or sent can be checked in real time. Specific packet
formats are as follows:
*0.348623498-SOCKET-8-OUTBAND:TCP packet information :
TCP output packet:
source IP address: 172.16.201.1
source port: 23
6-7
destination IP address: 172.16.105.148

destination port: 1031
packet sequence number: 4818317
ACK sequence number: 3644122
The packet flags: ACK PUSH
The total length of IP packet: 436
The length of TCP header: 20
The other is to debug and trace the packets with SYN, FIN or RST flags being set.
Operations are as follows:
[H3C] quit
<H3C> debugging tcp event
Then the TCP packets received or sent can be checked in real time, and the formats
are similar to those mentioned above.
6-8
H3C SecPath Series Security Products Chapter 7 IP Unicast Policy Routing Configuration
Chapter 7 IP Unicast Policy Routing Configuration
7.1 IP Unicast Policy Routing Overview

IP policy routing is a mechanism in which packets are transmitted and forwarded by
strategy without going through the routing table. It is a more flexible routing mechanism,
compared with routing according to the destination address of data packet. The policy
routing of this system allows to flexibly route in accordance with the source address
and address length of an arrived packet.
Two tasks are involved in configuring the policy routing of this system: One is to define
the packets requiring policy routing; the other is to designate routes for these packets
by defining a route-policy. The configuration of a route-policy is composed of a group
of if-match clauses and a group of apply clauses. The if-match clauses define which
packets require the use of policy routing. When some packets fully satisfy the if-match
clauses, the apply clauses in the route-policy will be executed to complete the packet
forwarding.
A route-policy is composed of several nodes. Each node is composed of some
if-match and apply clauses. The if-match clause defines the matching rule for the
node, while the apply clause defines the packet operation after the packet matches the
rule.
The if-match clauses are in “AND” filtering relation. That is, the apply clause can be
executed only when the packet satisfies all if-match clauses for the node. At present,
two if-match clauses (if-match packet-length and if-match acl) are provided. There
are five apply clauses: apply ip-precedence, apply output-interface, apply
ip-address next-hop, apply default output-interface, and apply ip-address default
next-hop. When all if-match clauses are satisfied, the apply clause is executed as
follows:
z Use the apply ip-precedence command to configure IP precedence. The
command can be executed after you configure the command.
z Use the apply output-interface and apply ip-address next-hop commands to
configure the outgoing interface and next hop. The priority of the former command
is higher than that of the latter. When the two commands are configured
simultaneously and take effect, the system only executes the apply
output-interface command.
z Use the apply default output-interface and apply ip-address default next-hop
commands to configure the default outgoing interface and next hop. The priority of
the former command is higher than that of the latter. When the two commands are
configured simultaneously and take effect, the system only executes the apply
default output-interface command. When outgoing interface or next hop is not
7-1
configured for the packet in the policy route (or the configured outgoing interface
and next hop do not take effect), and no route in the routing table matches the
packet, the default outgoing interface or next hop is used. In other cases, the
default outgoing interface or next hop is not used.
There are two kinds of policy routings: interface policy routing and local policy routing.
The former is configured in interface view and performs strategic routing for packets
coming through this interface, while the latter is configured in system view and
performs policy routing for packets generated by this device. Generally, for the request
about forwarding and security, in most cases, interface policy route will be used.
The policy routing can be used for security and load sharing.
7.2 IP Unicast Policy Routing Configuration

IP unicast policy routing configuration includes:
z Establish a Route-policy
z Define match clause of policy routing
z Define apply clause of policy routing
z Enable/disable local policy routing
z Enable/disable policy routing on the interface
7.2.1 Establishing a Route-Policy
The strategy specified with the strategy name may have multiple strategy nodes, each
with a sequence-num. The smaller the sequence-num, the higher the priority is, so the
defined policy will be executed first. The policy can be used to redistribute route and
perform policy routing when IP packets are forwarded. The contents of the policy will be
specified by the if-match and apply clauses.
Table 7-1 Establish a route-policy
Operation Command
route-policy policy-name { permit |
Establish a route-policy or a policy node
deny } node sequence-number
undo route-policy policy-name

Delete a route-policy or a policy node [ permit | deny | node
sequence-number ]
permit means applying policy routing for the packets meeting the conditions, and deny
means not applying policy routing for the packets meeting the conditions.
By default, no route-policy and the related node configuration is defined.
7-2
7.2.2 Defining the if-match Clause of Policy Routing
Use the if-match clause to match the packet needing policy route. IP unicast policy
routing provides two if-match clauses, if-match packet-length clause and if-match
acl clause, i.e. determining which policy to be used according to IP packet length and
IP address. One policy node can include multiple if-match clauses, which are in “AND”
relation.
Perform the following configuration in route-policy view.
Table 7-2 Define if-match clause of policy routing
Operation Command
Specify matching to be IP packet the if-match packet-length min-len
length max-len
Specify matching to be IP address if-match acl acl-number
By default, no if-match clause is defined.
7.2.3 Defining the apply Clause of Policy Routing
IP unicast policy routing provides 5 apply clauses, such as apply ip-precedence,

apply output-interface, apply ip-address next-hop, apply default output-interface,
apply ip-address default next-hop. One strategy node can include multiple apply
clauses. The system executes these apply clauses in the configured order (the system
skips invalid clauses and continue to execute the next clause); when an effective
clause is executed, the policy is implement.
Table 7-3 Define apply clause of policy routing
Operation Command
Set packet precedence apply ip-precedence precedence
apply output-interface interface-type
Set packet transmitting interface interface-number [ interface-type
interface-number ]
apply ip-address next-hop ip-address [ ip
Set packet next-hop
address ]
apply default output-interface interface-type

Set packet default transmitting
interface-number [ interface-type
interface
interface-number ]
apply ip-address default next-hop ip-address

Set packet default next-hop
[ ip address ]
7-3
The user can specify multiple next hops or set several outbound interfaces. In this case,
the forwarding of packets will be shared among multiple parameters, namely, each
packet is sent on each next hop or outbound interface in turn. This is only applicable to
multiple parameters configured of one kind. If the outbound interfaces and next hops
are both configured, only the outbound interface is set to perform the load sharing.
By default, no apply clause is defined.
7.2.4 Enabling or Disabling Local Policy Routing
Enable or disable local policy routing in the system view. Only one local policy can be
configured.
Table 7-4 Enable/disable local policy routing
Operation Command
Enable local policy routing ip local policy route-policy policy-name
Disable local policy routing undo ip local policy route-policy policy-name
By default, the local policy routing is disabled.
7.2.5 Enabling or Disabling Policy Routing on the Interface
Enable or disable policy routing on a specified interface. At most one policy can be
configured on each interface.
Table 7-5 Enable/disable policy routing on the interface
Operation Command
Enable policy routing on the interface ip policy route-policy policy-name
undo ip policy route-policy
Disable policy routing on the interface
policy-name
By default, the policy routing is disabled on the interface.
7.3 Displaying and Debugging IP Unicast Policy Routing

running of the IP Unicast Policy Routing configuration, and to verify the effect of the
configuration.
Execute the debugging command in user view for the debugging of IP Unicast Policy
Routing.
7-4
Table 7-6 Display and debug IP unicast policy routing
Operation Command
Show local policy routing and interface
display ip policy
policy routing
Show the setting of the local policy
display ip policy setup local
routing
Show the setting of the interface policy display ip policy setup interface
routing interface-type interface-number
Show the packet statistics of the local
display ip policy statistic local
policy routing
Show the packet statistics of the display ip policy statistic interface
interface policy routing interface-type interface-number
enable the debugging of the policy
debugging ip policy
routing
7.4 Typical Configuration of IP Unicast Policy Routing

7.4.1 Configuring Policy Routing Based on Source Address
Enable a policy named aaa, which controls all TCP packets received from Ethernet
2/0/0 to be sent via the interface of Ethernet1/0/0, whereas other packets to be
forwarded based on routing table.
Node 5 denotes that Ethernet packets matched with ACL 3101 will be sent to the next
hop address 1.1.1.2.
Node 10 denotes that any packets matched with ACL 3102 will not be processed by
policy routing.
The packets from Ethernet 2/0/0 will try to match the if-match clauses of nodes 5 and 10
in turn. If nodes in permit mode are matched, execute corresponding apply clauses. If
nodes in deny mode are matched, exit from policy routing.
7-5
II. Network diagram
LAN A 10.110.0.0/255.255.0.0
E2/0/0
1.1.1.1
E1/0/0
E3/0/0
SecPath Path
1.1.1.2
Internet
Figure 7-1 Network diagram for configuring policy routing based on source address
III. Configure procedure
# Define access control list:

[H3C-acl-adv-3101] rule permit tcp
[H3C-acl-adv-3101] quit
[H3C-acl-adv-3102] rule permit ip
# Define acl 5 node to make any TCP packet matching ACL 3101 be sent to the next
hop address 1.1.1.2.
[H3C] route-policy aaa permit node 5
[H3C-route-policy] if-match acl 3101
[H3C-route-policy] apply ip-address next-hop 1.1.1.2
[H3C-route-policy] quit
# Define acl 10 node not to apply the policy routing to the packet matching ACL 3102.
[H3C] route-policy aaa deny node 10
# Apply policy aaa on the Ethernet interface

[H3C-Ethernet2/0/0] ip policy route-policy aaa
7-6
7.4.2 Configuring Policy Routing Based on Packet Size
SecPath A sends the packets of 64 to 100 bytes long through Ethernet 2/0/0, packets of
101 to 1000 bytes long through Ethernet 2/0/1 and those of other size should be routed
normally.
Apply IP unicast policy routing lab1 on E1/0/0 of SecPath A. This strategy will set
packet of 64 to 100 bytes long to 150.1.1.2 as the IP address of next hop and set packet
of 101 to 1000 bytes long to 151.1.1.2 as the IP address of next hop. All packets of
other size should be routed in the method based on the destination address
II. Network diagram
64 - 100 bytes
SecPath B
E2/0/0 E1/0/0
150.1.1.1 150.1.1.2
SecPath A
E2/0/1 E1/0/1
151.1.1.1 151.1.1.2
Apply strategy E1/0/0 101 - 1000 bytes

on E1/0/0 192.1.1.1
Figure 7-2 Network diagram for configuring policy routing based on packet size
III. Configure procedure
# Configure SecPath A:
[H3C-Ethernet1/0/0] ip policy route-policy lab1
[H3C] rip
[H3C-rip] network 192.1.1.0
[H3C] route-policy lab1 permit node 10
[H3C-route-policy] if-match packet-length 64 100
[H3C] route-policy lab1 permit node 20
[H3C-route-policy] if-match packet-length 101 1000
# Configure SecPath B:
7-7

[H3C] rip
Use the debugging ip policy command to monitor policy routing on SecPath A. Note:
the packets of 64 bytes long match the entry item whose id number is 10 as shown in
the route policy lab1, therefore they are forwarded to 150.1.1.2.
<H3C> debugging ip policy
*0.483448-POLICY-8-POLICY-ROUTING:IP Policy routing success : next-hop :
150.1.1.2
On SecPath A, change the packet size to 101 bytes and monitor policy routing with the
debugging ip policy command. Note: the packets of 101 bytes match the entry item
whose serial number is 20 as shown in the route policy lab1. They are forwarded to
151.1.1.2.
<H3C> debugging ip policy
*0.483448-POLICY-8-POLICY-ROUTING:IP Policy routing success : next-hop :
151.1.1.2
On SecPath A, change the packet size to 1001 bytes, and then use the debugging ip
policy command to monitor policy routing. Note that this packet does not match any
entry item in lab1, so it is forwarded in regular mode. The policy routing debugging does
not output information of the forwarding packets.
7-8
Routing Protocol
Operation Manual – Routing Protocol
Table of Contents
Chapter 1 IP Routing Protocol Overview .................................................................................... 1-1

1.1 IP Route and Routing Table Overview .............................................................................. 1-1
1.1.1 IP Route and Route Segment ................................................................................. 1-1
1.1.2 Routing by Routing Table........................................................................................ 1-2
1.2 Routing Management Policy.............................................................................................. 1-3
1.2.1 Routing Protocols and Route Discovery Preference............................................... 1-3
1.2.2 Load Balancing and Route Backup......................................................................... 1-4
1.2.3 Routes Sharing between Routing Protocols ........................................................... 1-5
Chapter 2 Static Route Configuration ......................................................................................... 2-1

2.1 Static Route Overview ....................................................................................................... 2-1
2.1.1 Static Route............................................................................................................. 2-1
2.1.2 Default Route .......................................................................................................... 2-1
2.2 Static Route Configuration................................................................................................. 2-2
2.2.1 Configuring a Static Route ...................................................................................... 2-2
2.2.2 Configuring the Default Route................................................................................. 2-3
2.2.3 Deleting All the Static Routes.................................................................................. 2-4
2.3 Displaying and Debugging the Routing Table ................................................................... 2-4
2.4 Typical Example of Static Route Configuration ................................................................. 2-5
2.5 Troubleshooting Static Route ............................................................................................ 2-6
Chapter 3 RIP Configuration ........................................................................................................ 3-1

3.1 RIP Overview ..................................................................................................................... 3-1
3.1.1 Mechanism of RIP................................................................................................... 3-1
3.1.2 RIP Startup and Operation...................................................................................... 3-2
3.1.3 RIP Features Available in Comware ....................................................................... 3-3
3.2 RIP Configuration............................................................................................................... 3-3
3.2.1 Enabling RIP ........................................................................................................... 3-4
3.2.2 Enabling RIP on a Network Segment ..................................................................... 3-4
3.2.3 Configuring Unicast of a Packet.............................................................................. 3-5
3.2.4 Configuring Split Horizon ........................................................................................ 3-5
3.2.5 Configuring Additional Metrics ................................................................................ 3-6
3.2.6 Configuring the Route Redistribution of RIP ........................................................... 3-6
3.2.7 Configuring Route Filtering ..................................................................................... 3-7
3.2.8 Disabling Host Route .............................................................................................. 3-8
3.2.9 Configuring Route Aggregation............................................................................... 3-8
3.2.10 Configuring Route Exchange of Indirectly Connected RIP Neighbors.................. 3-9
3.2.11 Configuring Traffic Sharing Across RIP Interfaces ............................................. 3-10
3.2.12 Configuring the RIP Preference .......................................................................... 3-11
i
3.2.13 Configuring RIP Timers....................................................................................... 3-11

3.2.14 Configuring Zero Field Check of an Interface Packet ......................................... 3-12
3.2.15 Specifying the RIP Version of an Interface ......................................................... 3-12
3.2.16 Configuring RIP Packet Authentication............................................................... 3-13
3.2.17 Specifying the Operating State of the Interface .................................................. 3-14
3.2.18 Resetting RIP Parameters .................................................................................. 3-14
3.2.19 Configuring Multi-Instance of RIP ....................................................................... 3-14
3.3 Displaying and Debugging RIP........................................................................................ 3-15
3.4 RIP Configuration Example ............................................................................................. 3-16
3.4.1 Configuring the Operating State of the Specified Interface .................................. 3-16
3.4.2 Adjusting the Convergence Time of RIP Network................................................. 3-17
3.4.3 Configuring Route Exchange of Indirectly Connected RIP Neighbors.................. 3-19
3.5 Troubleshooting RIP ........................................................................................................ 3-21
Chapter 4 OSPF Configuration .................................................................................................... 4-1

4.1 OSPF Overview ................................................................................................................. 4-1
4.1.1 Introduction to OSPF............................................................................................... 4-1
4.1.2 Process of OSPF Route Calculation ....................................................................... 4-1
4.1.3 Basic Concepts Related to OSPF ........................................................................... 4-2
4.1.4 OSPF Packets......................................................................................................... 4-4
4.1.5 LSA Types Available in OSPF ................................................................................ 4-5
4.1.6 OSPF Features Available in Comware ................................................................... 4-6
4.2 OSPF Configuration........................................................................................................... 4-6
4.2.1 Configuring Router ID ............................................................................................. 4-8
4.2.2 Enabling OSPF Process ......................................................................................... 4-8
4.2.3 Entering the OSPF Area View................................................................................. 4-9
4.2.4 Specifying a Network Segment to Run OSPF ........................................................ 4-9
4.2.5 Configuring a OSPF Virtual Link ........................................................................... 4-10
4.2.6 Configuring the Network Type of an OSPF Interface............................................ 4-11
4.2.7 Configuring the Adjacent Point.............................................................................. 4-12
4.2.8 Configuring OSPF to Redistribute Routes ............................................................ 4-13
4.2.9 Configuring OSPF to Create the Default Route .................................................... 4-15
4.2.10 Configuring OSPF Route Filtering....................................................................... 4-16
4.2.11 Configuring Route Aggregation by OSPF ........................................................... 4-17
4.2.12 Setting OSPF Route Preference ......................................................................... 4-19
4.2.13 Configuring OSPF Timers ................................................................................... 4-19
4.2.14 Setting the Interface Priority for DR Election ...................................................... 4-21
4.2.15 Configuring the Cost for Sending Packets on an Interface................................. 4-22
4.2.16 Setting a Shortest Path First (SPF) Calculation Interval for OSPF..................... 4-22
4.2.17 Configuring an Interval Required for Sending LSU Packets............................... 4-23
4.2.18 Configuring if Filling in the MTU Field When Transmitting DD Packets.............. 4-23
4.2.19 Configuring Maximum Number of Equal-Cost Routes ........................................ 4-23
4.2.20 Configuring OSPF Authentication ....................................................................... 4-24
ii
4.2.21 Configuring the Operating State of the Interface ................................................ 4-25

4.2.22 Configuring OSPF STUB Area............................................................................ 4-25
4.2.23 Configuring NSSA Parameters of OSPF ............................................................ 4-26
4.2.24 Configuring OSPF in Concert with Network Management System..................... 4-29
4.2.25 Resetting an OSPF Process ............................................................................... 4-30
4.3 Displaying and Debugging OSPF .................................................................................... 4-30
4.4 OSPF Configuration Example.......................................................................................... 4-32
4.4.1 OSPF Configuration Example ............................................................................... 4-32
4.4.2 Configuring OSPF Multi-process........................................................................... 4-33
4.4.3 Configuring DR Election Based on OSPF Priority ................................................ 4-35
4.4.4 Configuring Virtual Link of the OSPF .................................................................... 4-37
4.4.5 Configuring OSPF Peer Authentication ................................................................ 4-38
4.4.6 Configuring OSPF STUB Areas ............................................................................ 4-40
4.5 Troubleshooting OSPF .................................................................................................... 4-42
Chapter 5 BGP Configuration ...................................................................................................... 5-1

5.1 BGP Overview ................................................................................................................... 5-1
5.2 BGP Configuration ............................................................................................................. 5-2
5.2.1 Enabling BGP.......................................................................................................... 5-3
5.2.2 Configuring the Network Routes for BGP to Advertise ........................................... 5-3
5.2.3 Configuring a BGP Peer/Peer Group ...................................................................... 5-4
5.2.4 Configuring Routing Policy for BGP Peer/Peer Group.......................................... 5-10
5.2.5 Removing the Route Synchronization between IGP and IBGP ............................ 5-12
5.2.6 Configuring BGP Timers ....................................................................................... 5-12
5.2.7 Configuring the Local Preference Attribute ........................................................... 5-13
5.2.8 Configuring the MED Attribute for an AS .............................................................. 5-14
5.2.9 Comparing the MED Values of Routes from Peers in Different ASs .................... 5-14
5.2.10 Configuring the BGP Community Attributes........................................................ 5-15
5.2.11 Configuring BGP Route Aggregation .................................................................. 5-16
5.2.12 Configuring the BGP Preference......................................................................... 5-16
5.2.13 Configuring the BGP Route Reflector ................................................................. 5-17
5.2.14 Configuring BGP AS Confederation Attribute ..................................................... 5-19
5.2.15 Configuring BGP Route Dampening ................................................................... 5-21
5.2.16 Configuring the Interaction between BGP and IGP ............................................ 5-21
5.2.17 Configuring the Repeating Times of Local AS Number ...................................... 5-22
5.2.18 Defining ACL, AS Path List, and route-policy ..................................................... 5-22
5.2.19 Configuring BGP Route Filtering......................................................................... 5-23
5.2.20 Resetting BGP Connection ................................................................................. 5-24
5.2.21 Configuring BGP Route Refreshing .................................................................... 5-25
5.3 Displaying and Debugging BGP ...................................................................................... 5-25
5.4 BGP Configuration Example............................................................................................ 5-28
5.4.1 Configuring the BGP AS Confederation Attribute ................................................. 5-28
5.4.2 Configuring BGP Route Reflector ......................................................................... 5-29
iii
5.4.3 Configuring BGP Routing...................................................................................... 5-31

5.5 Troubleshooting BGP ...................................................................................................... 5-35
5.6 MBGP Overview .............................................................................................................. 5-35
5.6.1 Introduction to MBGP............................................................................................ 5-35
5.6.2 MBGP Extension Attributes................................................................................... 5-36
5.6.3 MBGP Applied on the Firewall .............................................................................. 5-36
5.7 MBGP Configuration........................................................................................................ 5-36
5.7.1 Configuring the Address Family ............................................................................ 5-37
5.7.2 Enabling Peer/Peer Group .................................................................................... 5-37
5.8 MBGP Configuration Examples ....................................................................................... 5-38
5.8.1 Configuring MBGP Route Reflector ...................................................................... 5-38
Chapter 6 IP Routing Policy Configuration ................................................................................ 6-1

6.1 IP Routing Policy Overview ............................................................................................... 6-1
6.2 Configuring IP Routing Policy ............................................................................................ 6-3
6.2.1 Configuring Route Filtering ..................................................................................... 6-3
6.2.2 Implementing Routing Policy by route-policy .......................................................... 6-6
6.3 Displaying and Debugging the Routing Policy................................................................. 6-10
6.4 Routing Policy Configuration Example ............................................................................ 6-11
6.4.1 Configuring to Import Routing Information of Other Protocols.............................. 6-11
6.4.2 Configuring to Filter the Advertised Routing Information ...................................... 6-12
6.4.3 Configuring to Filter the Received Routing Information ........................................ 6-13
6.4.4 Configuring the BGP cost Attribute to Select Path................................................ 6-14
6.4.5 Configuring Routing Policy Based on next-hop/as-path/origin/
local-preference ........................................................................................................... 6-18
6.5 Troubleshooting Routing Policy ....................................................................................... 6-21
Chapter 7 Route Capacity Configuration .................................................................................... 7-1

7.1 Route Capacity Configuration Overview............................................................................ 7-1
7.1.1 Introduction to Route Capacity Configuration ......................................................... 7-1
7.1.2 Route Capacity Limitation ....................................................................................... 7-1
7.2 Route Capacity Configuration............................................................................................ 7-1
7.2.1 Configuring the Lower Limit and the Safety Value of the Memory.......................... 7-2
7.2.2 Disabling Automatic Recovery Function of the Firewall.......................................... 7-2
7.2.3 Enabling Automatic Recovery Function of the Firewall........................................... 7-3
7.3 Displaying and Debugging Route Capacity ....................................................................... 7-3
iv
H3C SecPath Series Security Products Chapter 1 IP Routing Protocol Overview
Chapter 1 IP Routing Protocol Overview
1.1 IP Route and Routing Table Overview

1.1.1 IP Route and Route Segment
Routers are adopted for route selection on the Internet. According to the destination
address of a received packet, a router selects an appropriate route (via a network) and
forwards the packet to the next router. The last router is responsible for forwarding the
packet to the destination host.
For example, in Figure 1-1, from host A to host C, there are totally three networks and
two routers. If a node is connected to another node through a network, there will be a
route segment between these two nodes. They are thus deemed as adjacent in the
Internet. Similarly, adjacent routers refer to two routers connected to the same network.
The number of route segments between a router and certain host in the same network
is taken as zero. In the following figure, the bold arrows represent these route segments.
A router does not concern about which physical links constitute this route segment.
A
R R
Route segment
R
R
C
R
B

Figure 1-1 Route segment
As the sizes of the networks may differ greatly, the actual "length" of the route
segments may be different from each other. Therefore, for different networks, the
number of route segments multiplies a weighted coefficient can measure the actual
length of the path.
If a router in a network is regarded as a node in the network and a route segment in the
Internet is regarded as a link in the Internet, routing in the Internet is similar to routing in
a simple network. Routing through the shortest route is not always the most ideal way.
For example, routing through 3 high-speed LAN route segments may be much faster
than that through 2 low-speed WAN route segments.
1-1
1.1.2 Routing by Routing Table
The key for a router to forward packets is the routing table. Each router saves a routing
table in its memory, and each entry of this table specifies the physical port of the router
through which the packet to a subnet or a host should be sent. Therefore, it can reach
the next router in this path or reach the very destination host in the directly connected
network.
A routing table has the following key entries:
z Destination address: It is used to identify the destination address or the destination
network of an IP packet.
z Network mask: Along with destination address, it identifies the address of the
network segment where a destination host or a router resides. After performing
“logical AND” between destination address and network mask, you can get the
address of the network segment where a destination host or a router resides. For
example, if the destination address is 129.102.8.10, the address of the network
where the host or the router with the mask 255.255.0.0 is located will be
129.102.0.0. A mask consists of several consecutive “1”, represented either by
dotted decimal notation or by the number of consecutive “1” in the mask.
z Output interface: It indicates through which interface an IP packet should be
forwarded.
z Next hop address: It indicates the next router that an IP packet will pass through.
z Precedence added to the IP routing table for a route: There may be different next
hops to the same destination. These routes may be discovered by different routing
protocols, or they can be the manually configured static routes. The one with the
highest precedence (the smallest numerical value) will be selected as the current
optimal route.
According to different destinations, the routes fall into the following groups:
z Subnet route: Its destination is a subnet.
z Host route: Its destination is a host
In addition, according to whether the network where the destination locates is directly
connected to the router, routes can be divided into the following categories:
z Direct route: The router is directly connected to the network where the destination
locates.
z Indirect route: The router is not directly connected to the network where the
destination locates.
In order to avoid a too huge routing table, you can set a default route. All the packets
that fail to find the suitable routing entry will be forwarded through this default route.
In a complicated Internet as shown in Figure 1-2, the numbers in each network indicate
its network address. The router R8 is connected with three networks, so it has three IP
addresses and three physical ports. Its routing table is shown in the figure below:
1-2
16.0.0.1 16.0.0.3
16.0.0.0
15.0.0.2 R7 10.0.0.2 Routing table of Router R8
R6
Destination Next hop· Interface
16.0.0.2
R5 10.0.0.0 network
15.0.0.0
13.0.0.3 10.0.0.0 10.0.0.0 2
13.0.0.2 2
15.0.0.1 10.0.0.1 11 .0.0.0 11.0.0.0 1
3 R8
R2 13.0.0.0 12 .0.0.0 11.0.0.2 1
14.0.0.2 11.0.0.1 1
13.0.0.4 1 3.0.0.0 13.0.0.0 3
13.0.0.1 11.0.0.0 1 4.0.0.0 13.0.0.2 3
14.0.0.0 1 5.0.0.0
R3 10.0.0.2 2
12.0.0.2 1 6.0.0.0 10.0.0.2 2

R1 11.0.0.2
14.0.0.1
12.0.0.0 R4
12.0.0.3
12.0.0.1
Figure 1-2 Routing table
A firewall supports the configuration of static route as well as a series of dynamic

routing protocols such as RIP, OSPF and BGP. Moreover, a firewall in operation can
automatically obtain some direct routes according to interface state and user
configuration.
1.2 Routing Management Policy

You can manually configure a static route to a certain destination, or configure the
interaction between dynamic routing protocol and other routers in the network and find
route via routing algorithm. The static routes configured by the user are managed
together with the dynamic routes discovered by the routing protocol in the router.
1.2.1 Routing Protocols and Route Discovery Preference
Different routing protocols (including static routes) may discovery different routes to the
same destination, but not all these routes are optimal. In fact, at a certain moment, only
one routing protocol can determine the current route to a specific destination. Thus,
each of these routing protocols (including static routes) is assigned with a preference.
When there are multiple routing information sources, the route learned by the routing
protocol with the highest preference will become the current route. Table 1-1 lists the
routing protocols and the default preferences (the smaller the value, the higher the
preference is) of the routes discovered by them.
In the table, “0” represents a directly connected route, and “255” represents a route
from an unknown source.
1-3
Table 1-1 Routing protocols and route discovery preferences
The Preference of the Corresponding

Routing Protocol or Route Type
Route
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 256
EBGP 256
UNKNOWN 255
Except for direct routing, the preferences of various dynamic routing protocols can be
manually configured to meet the user requirements. In addition, the preferences for
individual static routes can be different.
1.2.2 Load Balancing and Route Backup
I. Load balancing
Load balancing supports multi-route mode, permitting to configure multiple routes that
reach the same destination and use the same precedence. The same destination can
be reached via multiple different paths, whose precedence is equal. When there is no
route that can reach the same destination with a higher precedence, the multiple routes
will be adopted. The packets are forwarded to the destination through these paths, thus
implementing load balancing. This feature can however apply to the equal-cost routes
of the same routing protocol. For example, you cannot balance load among static
routes and OSPF routes.
Load balancing is supported by routing protocols like: static routing, RIP, OSPF, BGP,
and IS-IS. Two load balancing implementations are available:
z Traffic-based load balancing. When fast forwarding is enabled on the router, load
balancing can only be traffic-based. Suppose two equal-cost routes are available
on the router. When one data stream arrives, the router forwards it on one route.
When two data streams arrive, the router forwards each on one route. Likewise,
the fast forwarding-enabled subinterfaces implement traffic-based load balancing.
1-4
z Packet-based load balancing, implemented when fast forwarding is disabled and

the router has multiple equal-cost routes to the same destination. The router then
distributes the arrived packets equally on the participating routes.
II. Route backup
When main route failed, the system will automatically switch to a backup route to
improve the network reliability. In order to achieve route backup, the user can configure
multiple routes to the same destination according to actual situation. One of the routes
has the highest precedence and is called as main route. The other routes have
descending precedence and are called as backup routes. Normally, the router sends
data via main route. When the line is in failure, the router will choose one route whose
precedence is higher than others from the left routes as a path to send data. In this way,
the switchover from the main route to the backup route is realized. When the main route
recovers, the router will restore it and re-select route. As the main route has the highest
precedence, the router will choose the main route to send data. This process is the
automatic switchover from the backup route to the main route.
1.2.3 Routes Sharing between Routing Protocols
As the algorithms of various routing protocols are different, different routing protocols
may learn different routes, causing the problem of how to share the learned routes
between the routing protocols. A router can redistribute the route discovered by one
routing protocol to another routing protocol. Each protocol has its own route
redistribution mechanism. For details, please refer to the description about
"Redistributing an External Route" in the operation manual of the corresponding routing
protocol.
1-5
H3C SecPath Series Security Products Chapter 2 Static Route Configuration
Chapter 2 Static Route Configuration
Note:
For the parameter explanation in VPN instance, refer to the VPN part of this manual.
2.1 Static Route Overview

2.1.1 Static Route
Static route is a special kind of route manually configured by an administrator. You can
set up an interconnecting network with the static route configuration. The problem for
such configuration is when a fault occurs to the network, the static route cannot change
automatically to keep itself away from the node causing the fault, if without the help of
the administrator.
In a relatively simple network, you only need to configure the static routes to make the
router work normally. The proper configuration and usage of static routes can improve
the network performance and ensure the bandwidth of important applications.
Static route also features the following attributes:
z Reachable route: A normal route is of this type. That is, an IP packet is sent to the
next hop via the route marked by the destination. It is a common type of static
routes.
z Unreachable route: When a static route to a destination has the "reject" attribute,
all the IP packets to this destination will be discarded, and the originating host will
be informed destination unreachable.
z Blackhole route: When a static route to a destination is of the "blackhole" attribute,
all the IP packets to this destination will be discarded, and the originating host will
not be informed.
The attributes "reject" and "blackhole" are usually used to control the range of
reachable destinations of this router, and help troubleshooting the network.
2.1.2 Default Route
A default route is a kind of special route, configured by static route or some dynamic
routing protocols such as OSPF.
Simply put, a default route is a route used only when no suitable route is matched. That
is to say, only when no proper route is found, will the default route be used. In a routing
2-1
table, the default route is in the form of the route to the network 0.0.0.0 (with the mask
0.0.0.0). You can see whether it has been set via the output of the display ip
routing-table command. If the destination address of a packet fails in matching any
entry of the routing table, the router will select the default route to forward this packet. If
there is no default route, this packet will be discarded, and an Internet Control Message
Protocol (ICMP) packet will be sent to the originating host to inform that the destination
host or network is unreachable.
2.2 Static Route Configuration

Static route configuration includes:
z Configure a static route
z Configure the default route
z Configure the priority of a static route
z Delete a static route
2.2.1 Configuring a Static Route
Table 2-1 Configure a static route
Operation Command
ip route-static ip-address { mask | mask-length }
{ interface-type interface-number | nexthop-address }
[ preference value ] [ reject | blackhole ] [ detect-group
group-number ] [ description text ]
ip route-static vpn-instance { vpn-instance-name1
Add a static route vpn-instance-name2 … ip-address } { mask | mask-length }
[ interface-type interface-number [ nexthop-address ] |
vpn-instance vpn-nexthop-name nexthop-address |
nexthop-address [ public ] ] [ preference preference-value ]
[ reject | blackhole ] [ detect-group group-number ]
[ description text ]
undo ip route-static ip-address {mask | mask-length }
[ interface-name | nexthop-address ] [ preference value ]
Delete a static undo ip route-static vpn-instance { vpn-instance-name1
route vpn-instance-name2 … ip-address } { mask | mask-length }
[ interface-type interface-number | vpn-instance
vpn-nexthop-name nexthop-address | nexthop-address
[ public ] ] [ preference preference-value ]
The parameters are explained as follows:

1) VPN instance name
2) IP address and mask
2-2
An IP address is in dotted decimal format. As the “1” in a 32-bit mask is required to be

consecutive, a mask can be represented either by dotted decimal notation or by mask
length (namely the bits of “1” in a mask).
3) Transmitting interface or next-hop address
To configure a static route, you can either specify the interface-name of a sending
interface or the gateway-address of a next-hop address. It depends on specific
situation.
Virtually, it is necessary to specify the next-hop addresses of all route entries. During
packet forwarding over IP, a router first finds matched route from the routing table
according to the destination address of a packet. Only when the next-hop is specified,
can the link layer finds corresponding link layer address via the next-hop IP address
and forward the packet according to the address.
A sending interface can be specified in the following cases:
z For a point-to-point interface, when a sending interface is specified, it implicates
that the next-hop address is also specified. In this case, the peer interface address
connected with the interface is regarded as the next-hop address of the route. For
example, in the case that SERIAL interface is encapsulated with PPP, the peer IP
address can be obtained via PPP negotiation. It is unnecessary to specify the
next-hop address but specifying the sending interface.
z For an NBMA interface (such as an ATM interface), which supports
point-to-multipoint, it is necessary to create reroute at link layer, namely the
mapping from an IP address to a link layer address, besides configuring IP routes.
To configure static route in this case, you should configure the next-hop IP address
rather than specify the sending interface.
4) Precedence
The preference can be configured differently by flexibly applying route management
policies.
5) Other parameters
The attributes reject and blackhole respectively indicate the unreachable route and
the blackhole route. The attribute detect-group is used to check the validity of a static
route based on the result returned from a detect group (reachable or unreachable). The
attribute description is used to add description information for a static route.
2.2.2 Configuring the Default Route
2-3
Table 2-2 Configure the default route
Operation Command
ip route-static 0.0.0.0 { 0.0.0.0 | 0 } {interface-type
interface-number | nexthop-address } [ preference value ]
Configure the default
route ip route-static vpn-instance vpn-instance-name 0.0.0.0
{ 0.0.0.0 | 0 } {interface-type interface-number |
nexthop-address } [ preference value ]
undo ip route-static 0.0.0.0 { 0.0.0.0 | 0 } {interface-type
interface-number | nexthop-address} [ preference value ]
Delete the default
route undo ip route-static vpn-instance vpn-instance-name
0.0.0.0 { 0.0.0.0 | 0 } {interface-type interface-number |
nexthop-address } [ preference value ]
The meanings of parameters in the command are the same as those of the static route.
2.2.3 Deleting All the Static Routes
Table 2-3 Delete all the static routes
Operation Command
Delete all the static routes delete static all
This command can be used to delete all the static routes configured, including default
routes.
2.3 Displaying and Debugging the Routing Table

running of the static route configuration, and to verify the effect of the configuration.
Table 2-4 Display and debug routing table
Operation Command
View routing table summary display ip routing-table
View routing table details display ip routing-table verbose
View the route of a specified destination display ip routing-table ip-address
address [ mask ] [ longer-match ] [ verbose ]
View the routes within specified range of display ip routing-table ip-address1
destination addresses mask1 ip-address2 mask2 [ verbose ]
View the routes passing the filtering of a display ip routing-table acl
specified basic ACL acl-number [ verbose ]
2-4
Operation Command
View the routes filtered by specified IP display ip routing-table ip-prefix
prefix list ip-prefix-number [ verbose ]
display ip routing-table protocol
View the routes discovered by the
protocol [ inactive | verbose ]
specified protocol
[ vpn-instance vpn-instance-name ]
View the tree routing table display ip routing-table radix
display ip routing-table
View the statistics in a routing table [ vpn-instance vpn-instance-name ]
statistics
View the summary information of the display ip routing-table vpn-instance
private network routing table vpn-instance-name [ ip-address ]
display ip routing-table vpn-instance

View routing table details vpn-instance-name [ ip-address ]
verbose
reset ip routing-table [ vpn-instance
Clear the routing table vpn-instance-name ] statistics
protocol protocol-type
2.4 Typical Example of Static Route Configuration

In the following figure, it is required to configure static routes so as to realize

interworking between any two hosts or firewalls.
II. Network diagram
Host3: 1.1.5.1/24
ethernet1/0/0:
1.1.5.2/24
ethernet1/0/1: ethernet1/0/2:
1.1.2.2/24 1.1.3.1/24
SecPathC
Host1: 1.1.1.1/24 1.1.3.2/24 Host2: 1.1.4.2/24
1.1.2.1/24
1.1.1.2/24 1.1.4.1/24
SecPathA SecPathB
Figure 2-1 Network diagram of the static route configuration
2-5
# Configure the static route of SecPath A.

[H3C] ip route-static 1.1.3.0 255.255.255.0 1.1.2.2
Or just configure the default route.

# Configure the static route of SecPath B.

Or just configure the default route.

# Configure the static route of SecPath C.

Configure the default gateway of Host 1 to be 1.1.1.2.

Configure the default gateway of the Host 2 to be 1.1.4.1.
Configure the default gateway of the Host 3 to be 1.1.5.2.
By now, all the hosts or firewalls in Figure 2-1 can interconnect with each other.
2.5 Troubleshooting Static Route

Symptom 1: The firewall is not configured with dynamic routing protocol. Both the
physical status of the interface and the link layer protocol are in UP status, but the IP
packet cannot be forwarded normally.
Troubleshooting:
z Use the display ip routing-table protocol static command to view whether the
corresponding static route is correctly configured.
z Use the display ip routing-table command to view whether the static route is
valid.
2-6
H3C SecPath Series Security Products Chapter 3 RIP Configuration
Chapter 3 RIP Configuration
Note:
For the parameter explanation of VPN instance, refer to the VPN part of this manual.
3.1 RIP Overview

RIP (Routing Information Protocol) is a relatively simple interior gateway protocol (IGP),
and it is primarily applied to relatively small networks.
Since the implementation of RIP is comparatively simple, the impact of the cost of the
protocol itself on the performance of networks is relatively small, and the configuration
and maintenance of RIP is easier than that of OSPF and IS-IS, RIP is still widely used in
practice.
3.1.1 Mechanism of RIP
I. Introduction to RIP
RIP is a kind of Distance-Vector (D-V) algorithm-based protocol and exchanges routing

information via UDP packets. It employs Hop Count to measure the distance to the
destination host, which is called Routing Cost. In RIP, the hop count from a router to its
directly connected network is 0, and that to a network which can be reached through
another router is 1, and so on. To restrict the time to converge, RIP prescribes that the
cost is an integer ranging from 0 and 15. The hop count equal to or exceeding 16 is
defined as infinite, that is to say, the destination network or the host is unreachable.
To improve performance and avoid the creation of routing loops, RIP supports both Split
Horizon and Poison Reverse. Besides, RIP can also redistribute routes from other
routing protocols.
II. Route database of RIP
Each router running RIP manages a route database, which contains routing entries to
all the reachable destinations in the network. These routing entries contain the
following information:
z Destination address: IP address of a host or a network.
z Next hop address: The address of the next router that a router will pass through for
reaching the destination.
z Interface: The interface through which the IP packet should be forwarded.
3-1
z Cost: The cost for the router to reach the destination, which should be an integer in
the range of 0 to 15.
z Timer: Duration from the last time that the routing entry is modified till now. The
timer is reset to 0 whenever a routing entry is modified.
z Route flag: A label distinguishing routes of internal routing protocols from those of
external routing protocols.
III. Timer of RIP
In RFC1058, RIP is described as controlled by three timers, Period update, Timeout

and Garbage-collection,
z Timer Period update is to send all RIP routing information to all neighbors;
z If a RIP route is not updated within the time period configured on timer Timeout
(namely, the local router does not receive the route update packet from the
neighbor), the route will be regarded as unreachable;
z If the local router still does not receive any route update packet from the neighbor,
that is, if the unreachable route is still not updated, the route will be removed from
the routing table.
3.1.2 RIP Startup and Operation
The whole process of RIPv1 startup and running can be described as follows:
z When RIP is just enabled on a router, request packet is forwarded to a neighbor
router in broadcast mode. After the neighbor router receives the packet, it will
respond to the request and resend a response packet containing information in the
local routing table.
z When the former router receives the response packet, it will modify its local routing
table and send a modification packet to the neighbor router and broadcast the
route modification information. Upon receiving the modification packet, the
neighbor router will send it to all its neighbor routers. After a series of modification
broadcast, each router can get and keep the updated routing information.
z At the same time, RIP broadcasts its routing table to the adjacent routers every 30
seconds. The adjacent routers will maintain their own routing tables after receiving
the packets and will select an optimal route, and then advertise the modification
information to their respective adjacent networks so as to make the updated route
globally reachable. Furthermore, RIP uses the timeout mechanism to handle the
timeout routes so as to ensure the real time and validity of the routes.
The startup and running of RIPv2 is almost the same as RIPv2. However, RIPv2 sends
the modification packet to multicast address 224.0.0.9. According to different
requirements, you can configure RIPv2 to broadcast the modification packet to make it
compatible backwardly to RIPv1.
3-2
RIP is adopted by most of IP router suppliers. It can be used in most of the campus
networks and the regional networks that are simple yet extensive. For larger and more
complicated networks, RIP is not recommended.
3.1.3 RIP Features Available in Comware
Currently, SecPath Series Firewalls support PRI-1 and RIP-2 protocols.
3.2 RIP Configuration

Following is the general introduction to RIP configuration.
1) Basic RIP configuration
Basic RIP configuration includes:
z Enable RIP
z Enable RIP on a network segment
In the event of running RIP on the links that do not support broadcast/multicast packets,
unicast mode should be configured for RIP packet transmission so that RIP neighbors
can be set up successfully.
With respect to NBMA link networking that adopts Frame Relay subinterfaces, split
horizon should even be disabled to assure the correct routing information transmission.
2) RIP route management
RIP configuration on advertising and receiving routing information is described as
follows:
z Configure additional metrics
z Configure the route redistribution of RIP
z Configure route filtering
z Disable host route
z Configure route aggregation
z Configure route exchange of indirectly connected RIP neighbors
z Configure traffic share across RIP interfaces
3) RIP parameters configuration
z Configure the RIP preference
z Configure RIP timer
z Configure zero field check for RIP
z Specify RIP version of an interface
4) Security issues
In order to improve RIP security during routing information exchange as well as to
control the spreading area of RIP packets, following configuration is necessary.
z Configure RIP packet authentication
z Specify the operating state of the interface
5) RIP support for MPLS VPN
3-3
z Configure multi-instance of RIP
3.2.1 Enabling RIP
After RIP is enabled, you can enter the RIP view.

Table 3-1 Enable RIP and enter the RIP view
Operation Command
Enable RIP and enter the RIP view rip
Disable RIP undo rip
By default, RIP is not enabled.

Most of RIP features are configured in RIP view and a few are configured in interface
view. The features pre-configured in interface view will not take effect until RIP is
enabled. You should note that once undo rip command is executed to disable RIP, the
RIP related features configured on the interface will also be deleted.
3.2.2 Enabling RIP on a Network Segment
To flexibly control RIP operation, you can specify some interfaces and configure the
network where they are located into RIP networks, so that these interfaces can send
and receive RIP packets.
Perform the following configuration in RIP view.
Table 3-2 Enable RIP network
Operation Command
Enable RIP on the specified network network network-address
Disable RIP on the specified network undo network network-address
Note that the operating network segment must be specified after RIP is enabled. RIP
only operates on the specified network segment. For an interface not on the specified
network segment, RIP neither receives and send routes on it nor forwards its interface
route, just as the interface does not exist. The network-address is an enabled or
disabled network address, or an IP network address on each interface.
When the command network is used for an address, the interface of the network with
this address is enabled. For example, for network 129.102.1.1, you can see network
129.102.0.0 either using display current-configuration or using display rip
command.
If RIPv1 applies, note that:
3-4
z If the destination address of the current route and the address of the sending
interface do not belong to the same network (natural network segment), the route
is not sent to the neighbors if it is a supernet route. If it is a subnet route, it is sent
after being summarized.
z If the destination address of the current route and the address of the sending
interface belong to the same network, the route is sent to the neighbors unless the
destination address of the route and the interface mask are unequal.
By default, RIP is disabled on all networks.
3.2.3 Configuring Unicast of a Packet
Generally, RIP forwards packets in broadcast addresses. To exchange routing

information on a link not supporting broadcast packets, you must adopt unicast
transmission.
Table 3-3 Configuring unicast of an RIP packet
Operation Command
Configure unicast of a packet peer ip-address
Disable unicast of a packet undo peer ip-address
By default, RIP does not send any packet to any unicast address.
It should be noted that peer is also restricted by rip work, rip output, rip input and
network commands.
3.2.4 Configuring Split Horizon
Split horizon means that the route received on an interface will not be sent from this
interface again. It avoids the creation of routing loops to some extent. But in some
special cases, split horizon must be disabled so as to get correct advertising. Disabling
the split horizon has no effect on the point-to-point connected links but is applicable on
the Ethernet.
Table 3-4 Configuring split horizon
Operation Command
Enable split horizon rip split-horizon
Disable split horizon undo rip split-horizon
By default, split horizon of the interface is enabled.
3-5
3.2.5 Configuring Additional Metrics
Additional metrics is the input or output metrics added to an RIP route. It does not
change the metric value of the route in the routing table, but adds a specified metric
value when the interface receives or sends a route.
Table 3-5 Configure additional metrics
Operation Command
Set the additional metrics of the route when the
rip metricin value
interface receives an RIP packet
Disable the additional metrics of the route when the
undo rip metricin
interface receives an RIP packet
Set the additional metrics of the route when the
rip metricout value
interface sends an RIP packet
Disable the additional metrics of the route when the
undo rip metricout
interface sends an RIP packet
By default, the additional metrics added to the route when RIP sends the packet is 1.
The additional routing metrics when RIP receives the packet is 0 by default.
3.2.6 Configuring the Route Redistribution of RIP
RIP allows routes from other routing protocols to be redistributed into the RIP. It also
allows to set the default metrics used for redistribution.
RIP can redistribute the routing protocols or route types such as Direct, Static, OSPF
and BGP.
Table 3-6 Configure the route redistribution of RIP
Operation Command
import-route protocol [ allow-ibgp ]
Redistribute routes from other protocols [ cost value ] [ route-policy
route-policy-name ]
Cancel the redistribution of routes from
undo import-route protocol
other protocols
Configure the default routing cost default cost value
Restore the default routing cost undo default cost
By default, RIP does not redistribute the route information of other protocols.
3-6
When the protocol argument is set to BGP, the keyword allow-ibgp is optional.
Whereas the import-route bgp command redistributes only EBGP routes, the
import-route bgp allow-ibgp command redistributes IBGP routes in addition and as
such, must be used with cautions.
If no metrics is specified for redistributing a route, the default metrics will be used. The
default value is 1.
3.2.7 Configuring Route Filtering
RIP provides the route filtering function. You can configure the filter policy rules through
specifying the ACL and IP-prefix for route receiving and distribution.
You can also specify to receive only the routes from a neighbor during route receiving.
I. Configuring RIP to filter the received routes
Table 3-7 Configure RIP to filter the received routes
Operation Command
Filter the received routing information filter-policy gateway ip-prefix-name
redistributed by the specified address import
Disable RIP to filter the routing
undo filter-policy gateway
information received from the specified
ip-prefix-name import
address
filter-policy { acl-number | ip-prefix
Filter the received global routing
ip-prefix-name [ gateway
information
ip-prefix-name ] } import
Disable RIP to filter the received global
ip-prefix-name [ gateway
routing information.
Filter the received global routing filter-policy route-policy
information by routing policy. route-policy-name import
Disable RIP to filter the received global undo filter-policy route-policy
routing information by routing policy. route-policy-name import
II. Configuring RIP to filter the redistributed routes
Table 3-8 Configure RIP to filter the redistributed routes
Operation Command
Filter the redistributed routing
ip-prefix-name | route-policy
information
route-policy-name } export [ routing-protocol ]
3-7
Operation Command
undo filter-policy { acl-number | ip-prefix
Cancel the filtering of the
ip-prefix-name | route-policy
redistributed routing information
route-policy-name } export [ routing-protocol ]
By default, RIP will not filter the received and redistributed routing information.
You can choose the routing-protocol parameter to filter the routes redistributed from the
specified route protocol.
For more information, refer to 6.2.1 “Configuring Route Filtering”.
3.2.8 Disabling Host Route
In some special cases, the firewall can receive a lot of host routes from the same
segment, and these routes are of little help in route addressing but consume a lot of
network resources. After host route is disabled, a firewall can refuse a host route it
receives.
Table 3-9 Disable host route
Operation Command
Enable host route receiving host-route
Disable host route receiving undo host-route
By default, the firewall receives the host route.
3.2.9 Configuring Route Aggregation
The so-called route aggregation means that different subnet routes in the same natural
network can be aggregated into one natural mask route for transmission when they are
sent to the outside (i.e. other network). Route aggregation can be performed to reduce
the routing traffic on the network as well as to reduce the size of the routing table.
RIP-1 only sends the route with natural mask, that is, it always sends routes in the route
aggregation form. RIP-2 supports classless inter-domain routing (CIDR). To advertise
all the subnet routes, the route aggregation function of RIP-2 can be disabled.
3-8
Table 3-10 Configure route aggregation
Operation Command
Enable the route aggregation function of RIP-2 summary
Disable the route aggregation function of RIP-2 undo summary
By default, RIP-2 route aggregation is enabled.
3.2.10 Configuring Route Exchange of Indirectly Connected RIP Neighbors
By default, RIP sends RIP packets to directly connected segments only. When sending
a unicast packet, RIP checks if the destination is directly connected; when receiving a
RIP packet, RIP checks the source address and tries to find the ingress interface.
According to this kind of mechanism, when two firewalls are indirectly connected RIP
neighbors, no RIP information exchanging can take place.
loopback0: e1/0/0: e1/0/0: e1/0/1: e1/0/1: loopback0:

100.0.0.1/8 1.0.0.1/8 1.0.0.2/8 2.0.0.2/8 2.0.0.1/8 200.0.0.1/24
Figure 3-1 Route exchange of indirectly connected RIP neighbors
As shown in the above figure, if Firewall SecPath A and firewall SecPath C are
indirectly connected neighbors (only the 1.0.0.0/8 segment of SecPath A and the
2.0.0.0/8 segment of SecPath C are RIP-enabled, whereas SecPath B is not
RIP-enabled), to have SecPath A and SecPath C to exchange RIP routing information,
configure as follows:
z Configure SecPath A and SecPath C to be RIP peers.
z Disable the checking of the source address of a received RIP packet.
z Configure static routing to make the route between indirect neighbors reachable
and to ensure packets be sent to the indirect neighbors correctly.
After the above configuration, when sending a unicast packet, the firewall will not check
if the destination is a directly connected address, and SecPath B will no forward the flag
information of the packet; when receiving a RIP packet, the firewall will not check the
source address of the packet, it uses the source address and destination address of the
packet to locate the ingress interface.
I. Configuring unicast of RIP packets
Generally, RIP forwards packets using broadcast or multicast addresses. To run RIP on
a link not supporting broadcast packets, you must employ unicast transmission;
otherwise, the RIP neighborhood cannot be established properly. You must also
3-9
configure unicast of RIP packets when the firewalls running RIP are not directly
connected neighbors.
Table 3-11 Configure unicast of RIP packets
Operation Command
Configure unicast of RIP packets peer ip-address
Disable unicast of RIP packets undo peer ip-address
By default, RIP does not send any packet to any unicast address.
Noted that peer is restricted by the operation status of the interface, which, in turn, is
configured by the rip work, rip output, rip input, or network commands.
II. Configuring to check the source address of a RIP packet
Table 3-12 Configure to check the source address of a RIP packet
Operation Command
Configure to check the source address
validate-source-address
of a RIP packet
Disable the checking of the source
undo validate-source-address
address of a RIP packet
This command applies to the RIP protocol both running in public networks and private
networks in a MPLS VPN.
By default, the source address of a RIP packet is checked.
3.2.11 Configuring Traffic Sharing Across RIP Interfaces
You may enable traffic sharing across multiple RIP interfaces to have them share traffic
equally through equal-cost routes.
Table 3-13 Configure traffic sharing across RIP interfaces
Operation Command
Configure traffic sharing across RIP
traffic-share-across-interface
interfaces
Disable traffic sharing across RIP
undo traffic-share-across-interface
interfaces
3-10
This command applies to the RIP protocol both running in public networks and private
networks in a MPLS VPN.
By default, traffic sharing across RIP interfaces is disabled.
3.2.12 Configuring the RIP Preference
Each kind of routing protocol has its own preference, by which the routing policy will
select the optimal one from the routes of different protocols. The greater the preference
value is, the lower the preference becomes. The preference of RIP can be set
manually.
Table 3-14 Set the RIP preference
Operation Command
Set the RIP preference preference value
Restore the default value of RIP preference undo preference
By default, the preference of RIP is 100.
3.2.13 Configuring RIP Timers
It has been introduced at the beginning of this chapter that RIP has three timers, Period
update, Timeout and Garbage-collection. The modification on the values of these
timers will affect the convergence speed of RIP.
Table 3-15 Configure RIP timers
Operation Command
timers { update update-timer-length |
Set values for RIP timers
timeout timeout-timer-length } *
Restore the default values undo timers { update | timeout } *
The RIP timer values will take effect immediately after the modification.
The default value of timer Period update is 30 seconds, that of timer Timeout is 180
seconds and that of timer Garbage-collection is fixedly as 4 times as that of timer
Period update, i.e., 120 seconds.
In practice, you may find that the timing length of timer Garbage-collection is not fixed.
For instance, given the timer Period update is set to 30 seconds, the timing length of the
timer Garbage-collection may be 90 to 120 seconds. This is because a router needs to
wait for 4 update packets from the same neighbor before completely removing an
3-11
unreachable route from the routing table. However, when a route changes into the
unreachable state is not just the beginning of a new update period. So the actual timing
length of the timer Garbage-collection is about 3 to 4 times as that of the timer Period
update.
Note:
During the RIP timer configuration, you should take the network performance into
consideration when modifying the timer value and keep consistent of configurations on
all firewalls that run RIP to avoid adding unnecessary network traffic or causing network
route oscillation.
3.2.14 Configuring Zero Field Check of an Interface Packet
As RFC1058 provides, some fields in a RIP-1 packet must be 0, and they are called
zero fields. Therefore, when an interface version is set as RIP-1, the zero field check
should be performed on the packet. But if the value in the zero filed is not zero,
processing will be refused. As there are no zero fields in an RIP-2 packet, this
configuration is invalid for RIP-2.
Table 3-16 Configure zero field check of an interface packet
Operation Command
Configure zero field check on the RIP-1 packet checkzero
Disable zero field check on the RIP-1 packet undo checkzero
By default, zero field check is enabled on RIP-1 packets.
3.2.15 Specifying the RIP Version of an Interface
RIP has two versions, RIP-1 and RIP-2. You can specify the version of the RIP packet
processed by an interface.
RIP-1 broadcasts the packets. RIP-2 can transmit packets by both broadcast and
multicast. By default, multicast is adopted for packets transmission. In RIP-2, the
multicast address is 224.0.0.9. The advantage of multicast packet transmission is that it
prevents RIP-disabled hosts from processing RIP broadcast packets. In addition, it also
helps RIP-1-enabled hosts to avoid mistakenly receiving and processing routes with
subnet masks of RIP-2. When RIP-2 is enabled on an interface, RIP-1 packets can also
be received.
3-12
Table 3-17 Specify the RIP version of an interface
Operation Command
Specify the interface version as RIP-1 rip version 1
Specify the interface version as RIP-2 rip version 2 [ broadcast | multicast ]
Restore the default operating RIP
undo rip version { 1 | 2 }
version on an interface
By default, the interface receives and sends RIP-1 packets. When the interface RIP
version is set to RIP-2, the interface will transmit packets in multicast mode.
3.2.16 Configuring RIP Packet Authentication
RIP-1 does not support packet authentication. But when the interface operates RIP-2,
the packet authentication can be configured.
RIP-2 supports two authentication modes, plain text authentication and MD5
authentication. MD5 authentication uses two packet formats: One follows RFC1723
(RIP Version 2 Carrying Additional Information) and the other follows the RFC2082
(RIP-2 MD5 Authentication).
The plain text authentication does not ensure security. The authentication key not
encrypted is sent together with the packet, so the plain text authentication cannot be
applied to the case with higher security requirements.
Table 3-18 Set RIP packet authentication
Operation Command
Configure RIP-2 plain text authentication rip authentication-mode simple
key password
Configure RIP-2 use usual MD5 rip authentication-mode md5 rfc2453
authentication packet format key-string
Configure RIP-2 use nonstandard MD5 rip authentication-mode md5 rfc2082
authentication packet format key-string key-id
Cancel authentication of RIP-2 packet undo rip authentication-mode
If you configure MD5 authentication, you must configure MD5 type. The rfc2453 type
supports the RFC2453-compliant packet format, and the rfc2082 type supports the
RFC2082-compliant packet format.
3-13
3.2.17 Specifying the Operating State of the Interface
In interface view, you can specify the operating state of RIP on the interface. For
example, whether RIP is enabled on the interface, namely, whether RIP update packets
are sent and received on the interface. You can also singly specify an interface to send
(or receive) RIP update packet.
Table 3-19 Specify the Operating State of the Interface
Operation Command
Enable RIP on an interface rip work
Disable RIP on an interface undo rip work
Enable an interface to receive RIP update packet rip input
Disable an interface to receive RIP update packet undo rip input
Enable an interface to send RIP update packet rip output
Disable an interface to send RIP update packet undo rip output
The undo rip work command and the undo network command have similar but not all
the same functions. Both of the two commands disable the corresponding interface to
receive or send RIP route. Their difference is, for the undo rip work command, other
interfaces still forward the route of the interface using this command; while for the undo
network command, other interface will no longer forward the route of the interface
using this command, and it seems that this interface has been removed.
The rip work is functionally equivalent to both rip input and rip output commands.
By default, an interface both receives and transmits RIP update packets.
3.2.18 Resetting RIP Parameters
When you are going to reset the system configuration parameters for the RIP protocol,
you can use this command to return to the default RIP configuration.
Table 3-20 Resetting system configuration parameters of RIP protocol
Operation Command
Reset system configuration parameters of RIP protocol reset
3.2.19 Configuring Multi-Instance of RIP
The firewall supports the RIP multiple instances function and can support MPLS VPN.
3-14
Table 3-21 Configure multi-instance
Operation Command
ipv4-family [ unicast ] vpn-instance
Enter address family view of RIP
vpn-instance-name
Remove the configuration of address undo ipv4-family [ unicast ]
family of RIP vpn-instance vpn-instance-name
All configurations in address family view will be removed after the undo ipv4-family
command is executed.
Address family view applies to BGP/MPLS VPN. For related description, refer to the
VPN part of this manual.
3.3 Displaying and Debugging RIP

running of the RIP configuration, and to verify the effect of the configuration. Execute
debugging command in user view to debug the RIP module.
Table 3-22 Display and debug RIP
Operation Command
Display the current RIP running state and
display rip
configuration information
display rip interface
Display information about RIP interfaces. [ vpn-instance
vpn-instance-name ]
Display the configuration of RIP address display rip vpn-instance
family vpn-instance-name
display rip routing [ vpn-instance
Display the RIP routing table
vpn-instance-name ]
debugging rip packet [ interface
Enable packet debugging of RIP.
type number ]
Disable the packet debugging of RIP undo debugging rip packet
Enable the packet receiving debugging of debugging rip receive [ interface
RIP type number ]
Disable the packet receiving debugging of
undo debugging rip receive
RIP
debugging rip send [ interface
Enable packet sending debugging of RIP
type number ]
Disable packet sending debugging of RIP undo debugging rip send
3-15
3.4 RIP Configuration Example

3.4.1 Configuring the Operating State of the Specified Interface
An intranet accesses the Internet through SecPath A. All hosts in the intranet directly
connect to SecPath B or SecPath C.
RIP is enabled on all the three gateways. SecPath A receives routing information from
external networks, but does not send interior routing information out. SecPath A, B and
C can interchange RIP information in order to allow internal hosts to access the
Internet.
II. Network diagram
Ethernet1/0/0
192.1.2.1/24
SecPathA
Ethernet2/0/0
192.1.1.1/24
Ethernet
192.1.1.3/24 192.1.1.2/24
SecPathC SecPathB
192.1.4.1/24
192.1.3.1/24
Figure 3-2 Specifying the operating state of the interface
1) Configure SecPath A:
# Configure interfaces Ethernet 2/0/0 and Ethernet 6/0/0.
# Enable RIP and run RIP on them.

[H3C] rip
3-16
# Configure the interface Ethernet /0/0 of SecPath A to receive RIP packets only.
[H3C-Ethernet1/0/0] undo rip output
[H3C-Ethernet1/0/0] rip input
# Configure the interface Ethernet 2/0/0.
# Enable RIP and run RIP on Ethernet 2/0/0.

[H3C] rip
[H3C-rip] import direct
3) Configure SecPath C:
# Enable RIP and run RIP on Ethernet 2/0/0.

[H3C] rip
[H3C-rip] import direct
3.4.2 Adjusting the Convergence Time of RIP Network
RIP runs on SecPath A, SecPath B and SecPath C. The convergence time of the
network is within 30 seconds.
3-17
II. Network diagram
SecPathC
Ethernet 1/0/0
Loopback0 12.0.0.2/8
11.0.0.1/8 Ethernet 1/0/0
12.0.0.1/8
SecPathA SecPathB
10.0.0.1/8 10.0.0.2/8
Ethernet
Figure 3-3 Network diagram of RIP timer configuration
Note:
For the IP address configuration of the interface, refer to Figure 3-3.
# Enable RIP and apply it to Ethernet2/0/0 of SecPath A as well as on loopback0.
[H3C] rip
[H3C-rip] timers update 10 timeout 30
# Enable RIP and apply it to Ethernet2/0/0 and Ethernet1/0/0 of SecPath B.
[H3C] rip
# Enable RIP and apply it to Ethernet1/0/0 of SecPath C.
[H3C] rip
3-18
After the above configuration, executing the display ip routing-table command on

SecPath B and SecPath C, you can view the information of route 11.0.0.0/8. Shut down
the interface Ethernet2/0/0 of SecPath A and you can view that the route state of
11.0.0.0/8 to SecPath B and SecPath C changes into unreachable state within 30
seconds.
Before the timer is adjusted, it takes 180 seconds for SecPath B and SecPath C to
know that the route is unreachable after the interface Ethernet2/0/0 of SecPath A is
shut down. Therefore, the convergence time of RIP network is cut down due to the
adjustment on the timer.
3.4.3 Configuring Route Exchange of Indirectly Connected RIP Neighbors
As shown in the following figure, firewall SecPath B does not support the RIP protocol.
The e1/0/0 interface of firewall SecPath A is RIP-enabled, directly connected routes are
redistributed and configured to point to the static route of 2.0.0.0/8. The e1/0/0 interface
of SecPath C is RIP-enabled, directly connected routes are redistributed and
configured to point to the static route of 1.0.0.0/8. SecPath A and SecPath C are
configured to be RIP peers. The checking of the source address of the received RIP
packet is disabled. The aim is to obtain the RIP route of 200.0.0.1/24 to SecPath C on
SecPath A, and the RIP route of 100.0.0.1/8 to SecPath A on SecPath C.
II. Network diagram
loopback0: e1/0/0: e1/0/0: e1/0/1: e1/0/0: loopback0:

100.0.0.1/8 1.0.0.1/8 1.0.0.2/8 2.0.0.2/8 2.0.0.1/8 200.0.0.1/24
SecPath A SecPath B SecPath C
Figure 3-4 Configure route exchange of indirectly connected RIP neighbors
# Configure the IP address of the interface.
[H3C-Ethernet1/0/0] rip version 2
[H3C-Ethernet1/0/0] interface LoopBack0
[H3C-LoopBack0] ip address 100.0.0.1 255.0.0.0
# Enable the RIP protocol.

[H3C] rip
3-19
[H3C-rip] undo summary

# Configure the RIP peer and configure not to check the source address of the RIP
packet.
[H3C-rip] peer 2.0.0.1
[H3C-rip] undo validate-source-address
# Configure RIP to redistribute directly connected routes.

[H3C-rip] import-route direct
# Configure the static route to the 2.0.0.0 segment.

[H3C] ip route-static 2.0.0.0 255.0.0.0 1.0.0.2 preference 60
[H3C-Ethernet1/0/0] rip version 2
[H3C-Ethernet1/0/0] interface LoopBack0
# Enable the RIP protocol.

[H3C] rip
[H3C-rip] undo summary
# Configure the RIP peer and configure not to check the received RIP packets.
[H3C-rip] peer 1.0.0.1
[H3C-rip] undo validate-source-address
# Configure the ingress directly connected route.

[H3C-rip] import-route direct
# Configure the static route to the 1.0.0.0 segment.

3-20
SecPath A and C must be configured with static routes to the peer and the static route
must be reachable; otherwise, RIP packets are unable to be sent to the peer.
In addition, if SecPath C is the PE, you must configure RIP multi-instance, and you
must configure not to check the received RIP packets in RIP address family view:
# Configure vpn-instance.
[H3C] ip vpn-instance in
[H3C-vpn-in] route-distinguisher 100:1
[H3C-vpn-in] vpn-target 100:1 export-extcommunity
[H3C-vpn-in] vpn-target 100:1 import-extcommunity
# Configure RIP multi-instance.

[H3C] rip
[H3C-rip] ipv4-family vpn-instance in
[H3C-rip-af-vpn-instance] undo validate-source-address
3.5 Troubleshooting RIP

Symptom 1: The update packet cannot be received when the physical connection is
normal.
Troubleshooting:
It may be caused by the following reasons:
RIP is not enabled on the corresponding interface (for example, the undo rip work
command is executed) or this interface is not enabled through the network command.
The opposite firewall and router is configured as the multicast mode (for example, the
rip version 2 multicast command is executed) but the local firewall is not configured
as the multicast mode.
Fault 2: Route oscillation occurs to the network running RIP.
Troubleshooting: Use display rip command on each firewall and router that runs RIP to
view the configuration of RIP timers. If the values of Period update timer and Timeout
timer on different devices are different, you should reset them conformably and make
sure that the timing length of Timeout timer is longer than that of Period update timer.
3-21
H3C SecPath Series Security Products Chapter 4 OSPF Configuration
Chapter 4 OSPF Configuration
4.1 OSPF Overview

4.1.1 Introduction to OSPF
OSPF (Open Shortest Path First) is a link state-based internal gateway protocol
developed by IETF organization. At present, OSPF version 2 (RFC2328) is used, which
allows of the following features:
z Applicable scope: It can support networks in various sizes and can support several
hundred routers at maximum.
z Fast convergence: It can transmit the update packets instantly after the network
topology changes so that the change is synchronized in the AS.
z Loop-free: Since the OSPF calculates routes with the shortest path tree algorithm
according to the collected link states, it is guaranteed that no loop routes will be
generated from the algorithm itself.
z Area partition: It allows the network of AS to be divided into different areas for the
convenience of management, hence to reduce the network bandwidth
consumption.
z Equal-cost multi-route: Support multiple equal-cost routes to a destination.
z Routing hierarchy: OSPF has a four-level routing hierarchy. It prioritizes the routes
to be intra-area, inter-area, external type-1, and external type-2 routes.
z Authentication: It supports the interface-based packet authentication so as to
guarantee the security of the route calculation.
z Multicast transmission: Support multicast address to receive and send packets.
4.1.2 Process of OSPF Route Calculation
The routing calculation process of the OSPF protocol is as follows:

z Each OSPF-capable router maintains a Link State Database (LSDB), which
describes the topology of the whole AS. According to the network topology around
itself, each router generates a Link State Advertisement (LSA). The routers on the
network transmit the LSAs among them by transmitting the protocol packets to
each other. Thus, each router receives the LSAs of other routers and all these
LSAs compose its LSDB.
z LSA describes the network topology around a router, so the LSDB describes the
network topology of the whole network. Routers can easily transform the LSDB to
a weighted directed map, which actually reflects the topology architecture of the
whole network. Obviously, all the routers get a map exactly the same.
4-1
z A router uses the SPF algorithm to calculate the shortest path tree with itself as the
root. The tree shows the routes to the nodes in the autonomous system. The
external routing information is leaf node. A router, which advertises the routes,
also tags them and records the additional information of the autonomous system.
Obviously, the routing tables obtained by different routers are different.
Furthermore, to enable the individual routers to broadcast the information (such as
available interface information and reachable neighbor information) of their local
statuses to the whole AS, any two routers in the environment should establish
adjacency between them. In this case, the route changes on any router will result in
multiple transmissions, which are unnecessary and waste the precious bandwidth
resources. To solve this problem, designated Router" (DR) is defined in the OSPF.
Thus, all the routers only send information to the DR for broadcasting the network link
states in the network. Thereby, the number of adjacent router relations on the
multi-access network is reduced.
OSPF supports interface-based packet authentication to guarantee the security of
route calculation. Also, it transmits and receives packets by IP multicast.
4.1.3 Basic Concepts Related to OSPF
I. Router ID
To run OSPF protocol, a router must have a router ID. If not, the system will
automatically select the IP address with the biggest address number from the IP
addresses of the loopback interfaces as the router ID; if no loopback interfaces, the
system will select the biggest IP address number from the IP addresses of all physical
interfaces as the router ID. It is recommended that you choose the IP address of the
loopback interface as the router ID, because the interface is always up unless you shut
it down manually.
II. DR and BDR
z DR (Designated Router)
In the broadcast network or NBMA network, in order for each router to broadcast its
local state information to the whole AS (Autonomous System), multiple neighboring
relationships should be created between routers. This, however, makes it possible for
route variation of any router to result in repeated transmission, which wastes the
valuable bandwidth resource. To solve the problem, OSPF defines the "Designated
Router" (DR). All the routers only need to transmit information to the DR for
broadcasting the network link states. Neighboring relationship is not established
between two routers other than DRs (called as DR Others), nor do the DR Others
exchange any routing information.
It is not manually specified which router will be the DR of the local network segment, but
commonly selected by all the routers in the network segment.
4-2
z BDR (Backup Designated Router)

If a DR becomes invalid due to some fault, it must be reelected and synchronized. It
takes time and meanwhile the route calculation is incorrect. In order to speed up this
process, OSPF puts forward the concept of BDR. In fact, BDR is a backup for DR. DR
and BDR are elected in the mean time. The adjacencies are also established between
the BDR and all the routers on the segment, and routing information is also exchanged
between them. Once a DR becomes invalid, the BDR will immediately turn into a DR,
and a new BDR will be reelected.
III. Area
With the unceasing expansion of network scale, if all routers in a massive network run
OSPF, the increase in routers may lead to a large LSDB, which occupies a great
amount of memory, complicates the operating of SPF algorithm and aggravates the
burden of CPU. In addition, network expansion also brings about increase in the
probability for topology structure to change, whereby many OSPF packets are
forwarded in the network, and bandwidth utility of the network is accordingly reduced.
To solve this problem, OSPF splits an AS into multiple areas, which are identified by
area IDs. In logical sense, the areas put routers into different groups. The area 0, also
known as backbone area, is of the most significance.
The backbone area achieves routing information exchange between the non-backbone
areas. The backbone area and other non-backbone areas must be physically
consecutive. Otherwise, you have to configure virtual links to make them consecutive.
The router connecting the backbone area and another area is called area border router
(ABR).
There also exists the autonomous system boundary router (ASBR) in OSPF, which
connects OSPF routing domain and the router running other routing protocols can be
taken as the router redistributing OSPF external routing information.
IV. Route aggregation
AS is divided into different areas, which are interconnected via OSPF ABRs. The
routing information between areas can be reduced through route aggregation. Thus,
the size of routing table can be reduced and the calculation speed of the router can be
improved.
After calculating an intra-area route of an area, the ABR will look up the routing table
and encapsulate each OSPF route into an LSA and send it outside the area.
For example, in Figure 4-1, there are three intra-area routes in Area 19, 19.1.1.0/24,
19.1.2.0/24 and 19.1.3.0/24. If route aggregation is configured and the three routes are
aggregated into one route 19.1.0.0/16, only one LSA, which describes the route after
aggregation, is generated on RTA.
4-3
19.1.1.0/24
Area 12
Area 19
Virtual Link
Area 0
19.1.3.0/24
RTA
19.1.2.0/24
Area 8
Figure 4-1 Area and route aggregation
4.1.4 OSPF Packets
OSPF uses five types of packets:

z Hello Packet:
A kind of most commonly used packet, which is periodically sent to the peer of a local
router. Hello packet contains the values of some timers, DR, BDR and the known peer.
z DD packet (Database Description Packet):
When two routers synchronize their databases, they use the DD packets to describe
their own LSDBs, including the summary of each LSA. The summary refers to the
HEAD of an LSA, which can be used to uniquely identify the LSA. This reduces the
traffic size transmitted between the routers, since the HEAD of an LSA only occupies a
small portion of the overall LSA traffic. With the HEAD, the peer router can judge
whether it already has had the LSA.
z Link State Request (LSR) Packet:
After exchanging the DD packets, the two routers know which LSAs of the peer routers
are lacked in the local LSDBs. In this case, they will send LSR packets requesting for
the needed LSAs to the peers. The packets contain the summary of the needed LSAs.
z Link State Update (LSU) Packet:
The packet is used to transmit the needed LSAs to the peer router. It contains a
collection of multiple LSAs (complete contents).
z Link State Acknowledgment (LSAck) Packet
The packet is used to acknowledge the received LSU packets. It contains the HEAD(s)
of LSA(s) to be acknowledged (a packet can acknowledge multiple LSAs).
4-4
4.1.5 LSA Types Available in OSPF
I. Five types of basic LSAs
As we learned from last sections, the LSA (Link State Advertisement) is the main
source of OSPF protocol routing information algorithm and maintenance. Five types of
LSAs are defined in RFC2328:
z Router-LSAs: Type-1 LSAs, generated by individual routers to describe their link
state and cost and only advertised in the area for the routers themselves
z Network-LSAs: Type-2 LSAs, generated by the DRs of broadcast network or
NBMA network to describe the links state for the network segment and only
advertised in the area for the DRs themselves.
z Summary-LSAs: Type-3 and Type-4 LSAs, generated by ABRs and advertised in
the areas associated. Each Summary-LSA describes a route to the AS in question
or a destination in other areas (called inter-area route). Type-3 Summary-LSAs
are for routes to network, the destinations of which are segment, while Type-4
Summary-LSAs are for the routes to ASBRs.
z AS-external-LSAs: Type-5 LSAs, generated by ASBR to describe the routes to
other Ass and advertised to the whole AS (excluding STUB areas). The default AS
route can also be described by AS-external-LSAs.
II. LSA type-7
In RFC1587 (OSPF NSSA Option), NSSA (Not-So-Stubby Area) LSAs, also known as
LSAs Type-7 are added.
The major differences between Type-7 LSAs and Type-5 LSAs are illustrated in these
two points according to RFC1587:
z Type-7 LSAs are generated and advertised in NSSA, where Type-5 LSAs are not
generated and advertised.
z Type-7 LSAs are only advertised in one NSSA. They are converted to Type-5
LSAs when they reach the ABRs, for being advertised to other areas or backbone
area.
III. Opaque LSAs
In RFC2370 (The OSPF Opaque LSA), Opaque LSAs, which extends OSPF, are
defined to support more services.
Opaque LSAs also include three types, each with particular spread range:
z Type-9: The spread range is link-local, i.e. only the segment for a certain interface,
not beyond the local segment or local subnet.
z Type-10: The spread range is area-local, i.e. only the local area.
z Type-11: The spread range is identical with that for Type-5 LSAs, i.e. the whole AS
excluding STUB areas and NSSAs.
4-5
An opaque LSA includes a standard 20-byte LSA header and application

information-specific domain. See the following figure:
0
LS age Options LS ty pe (9, 10 or 11)

16-bit 8-bit 8-bit
Opaque ty pe Opaque ID
8-bit 24-bit
Adv ertising Router

32-bit
LS Sequence Number
32-bit
LS checksum Length
16-bit 16-bit
Opaque Information
Figure 4-2 Opaque LSA architecture
The Opaque Type field indicates LSA application type, while the Opaque ID field
differentiates the LSAs of the same application type.
The Opaque Information field stores the LSA-borne information, whose format may be
defined accordingly.
4.1.6 OSPF Features Available in Comware
Currently, the Comware supports these OSPF features:

z OSPF STUB area
z OSPF NSSA area
z OSPF multi-process, that is, a router runs multiple OSPF processes
z OSPF multi-VPN-instance, which runs between a CE and a PE as intra-VPN
routing protocol
Refer to the VPN part for OSPF application in MPLS VPN.
4.2 OSPF Configuration

Among all the configuration tasks, only after OSPF is enabled, interface number and
area number are specified, can other functions be configured. But the configuration of
the functions related to the interface is not restricted by whether the OSPF is enabled or
not. It should be noted that after OSPF is disabled, the OSPF-related interface
parameters also become invalid.
1) Basic OSPF configuration
Basic OSPF configuration includes:
z Configure Router ID
4-6
z Enable OSPF process

z Enter OSPF area view
z Specify the network segment
If the OSPF backbone area is not consecutive, then it is required to
z Configure OSPF virtual link
If the network types for OSPF are different, then it is required to
z Configure network type
z Configure the adjacent point
2) OSPF route management
z Configure OSPF to redistribute routes
z Configure OSPF route filtering
z Configure route aggregation by OSPF
3) OSPF parameters configuration
z Set OSPF route preference
z Configure OSPF timers
z Set the interface priority for DE election
z Configure the cost for sending packets
z Set a PSF calculation interval for OSPF
z Configure an interval required for sending LSU packets
z Configure whether the MTU field will be filled in
z Configure maximum number of OSPF equal-cost routes
4) Security issues
You can perform the following configuration to enhance the OSPF security when
switching routing information and to control the broadcasting range of OSPF packets.
z Configure OSPF authentication
z Disable the interface to send OSPF packets
5) OSPF advanced features configuration
z Configure STUB area of OSPF
z Configure NSSA parameters of OSPF
z Enable Opaque capacity of OSPF
z Configure OSPF to work with NMS
z Reset an OSPF process
Note:
For OSPF multi-instance application and OSPF configuration in MPLS VPN, refer to
the VPN part of this manual.
4-7
4.2.1 Configuring Router ID
Router ID is a 32-bit unsigned integer, in IP address format, that uniquely identifies a

router within an AS. Router ID can be configured manually. If router ID is not configured,
the system will automatically select the biggest IP address number from IP addresses
of the loopback interfaces as the router ID; if no loopback interfaces, the system will
select the biggest IP address number from IP addresses of all physical interfaces as the
router ID. When you do that manually, you must guarantee that the IDs of any two
routers in the AS are unique. A common practice is to set the router ID to be the IP
address of an interface on the router.
Table 4-1 Configure a router ID
Operation Command
Configure a router ID for the firewall router id router-id
Remove a router ID for the firewall undo router id
To ensure stability of OSPF, the user should determine the division of router IDs of
firewalls and manually configure them when implementing network planning.
Note:
The router IDs modified after OSPF is enabled will not take effect until the OSPF is
reset.
4.2.2 Enabling OSPF Process
Firewall supports OSPF multiple-process. When multiple processes are enabled on a

firewall, it is necessary to specify different numbers for them. OSPF process number is
a local concept, with no effect on its packet exchange with other routers. Therefore,
even though the process numbers of different routers are different, packet exchange is
available.
4-8
Table 4-2 Enable/disable OSPF
Operation Command
ospf [ process-id [ [ router-id router-id ]
Enable OSPF and enter OSPF view
vpn-instance vpn-instance-name ] ]
Disable OSPF routing protocol process undo ospf [ process-id ]
By default, OSPF is not enabled.

Notice theses items in enabling OSPF:
z The default process ID 1 will be selected if no one is specified when configuring
the ospf command; process ID 1 is disabled by default if no one is specified when
configuring the undo ospf command.
z The process ID must be consistent in the same area; otherwise, insulation
between processes will be resulted.
z If multiple OSPF processes run on a firewall, you are recommended to specify
different router IDs for different processes with the router-id command.
z Binding an OSPF with a VPN with the vpn-instance command is available in
MPLS VPN application. See the VPN part of this manual.
4.2.3 Entering the OSPF Area View
OSPF divides an AS into smaller areas and assigns routers to different groups logically.
Perform the following configuration in OSPF view.
Table 4-3 Enter the OSPF area view
Operation Command
Enter the OSPF area view area area-id
Delete a designated OSPF area undo area area-id
Area ID can be input in decimal integers or in IP address format, but only output as IP
address.
Take the area as whole in configuring parameters for the OSPF routers in the same
area, otherwise information exchange may fail between adjacent routers, or routing
information may be blocked or routing loops may be generated.
4.2.4 Specifying a Network Segment to Run OSPF
After enabling OSPF with the ospf command in system view, you must specify
particularly which network segment will apply OSPF. Perform the following
configuration in OSPF area view.
4-9
Table 4-4 Specify a network segment to run OSPF
Operation Command
Specify a network segment to run OSPF network ip-address wildcard-mask
undo network ip-address
Disable OSPF on the network segment.
wildcard-mask
A router may belong to different areas at the same time (This kind of router is called an
ABR), but a segment belongs to only one area.
4.2.5 Configuring a OSPF Virtual Link
OSPF stipulates that all the non-backbone areas should maintain the connectivity with
the backbone area. That is, at least one interface on the ABR should fall into the area
0.0.0.0. If an area does not have a direct physical link with the backbone area 0.0.0.0, a
virtual link must be created.
If the physical connectivity cannot be ensured due to the network topology restriction, a
virtual link can satisfy this requirement. The virtual link refers to a logic channel set up
through a non-backbone area between two ABRs. Both ends of the logic channel
should be ABRs and the connection can take effect only when both ends are configured.
The virtual link is identified by the ID of the remote router. Transit area provides the
ends of the virtual link with a non-backbone area internal route. The ID of the transit
area should be specified when making configuration.
The virtual link is activated after the route passing through the transit area is calculated,
which is equivalent to a p2p connection between two ends. Therefore, similar to the
physical interfaces, you can also configure various interface parameters on this link,
such as hello timer.
The "logic channel" means that the multiple routers running OSPF between two ABRs
only take the role of packet forwarding (the destination addresses of the protocol
packets are not these routers, so these packets are transparent for them and the
routers forward them as common IP packets). The routing information is directly
transmitted between the two ABRs. The routing information herein refers to the type-3
LSAs generated by the ABRs, for which the synchronization mode of the routers in the
area will not be changed.
Perform the following configuration in OSPF area view.
4-10
Table 4-5 Configure a OSPF virtual link
Operation Command
vlink-peer router-id [ hello seconds |
retransmit seconds | trans-delay
Create and configure a virtual link
seconds | dead seconds | simple
password | md5 keyid key ] *
Remove the created virtual link undo vlink-peer router-id
Both area-id and router-id have no default value. By default, hello timer is 10 seconds,
retransmit 5 seconds, trans-delay 1 second, and the dead 40 seconds.
4.2.6 Configuring the Network Type of an OSPF Interface
The route calculation of OSPF is based upon the topology of the adjacent network of
the local router. Each router describes the topology of its adjacent network and
transmits it to all the other routers.
OSPF divides networks into four types by link layer protocol:
z Broadcast: If Ethernet or FDDI is adopted, OSPF defaults the network type to
broadcast.
z Non-Broadcast Multi-access (NBMA): If Frame Relay, ATM, or X.25 is adopted as
a link layer protocol, OSPF defaults the network type to NBMA.
z Point-to-Multipoint (p2mp): No link layer protocol is regarded to be p2mp by
default. A p2mp network is compulsorily changed from other network types. The
common practice is to change a non fully-matched NBMA into a p2mp network.
z Point-to-Point (p2p): When the link layer protocol is PPP or LAPB, the default
network type of OSPF is p2p.
NBMA network refers to a non-broadcast and multi-accessible network. Frame Relay
and ATM are typical examples for it. The period for sending a polling hello packet
before a router forms neighboring relationship with its peer router can be specified by
configuring the polling interval.
On a broadcast network, which has no multi-access capability, an interface can be
configured into NBMA.
Configure the interface type to p2mp if not all the routers are directly accessible on an
NBMA network.
Change the interface type to p2p if the router has only one peer on the NBMA network.
Differences between NBMA and p2mp:
z In OSPF, NBMA refers to a network that is fully matched, non-broadcast and
multi-accessible. While a p2mp network is unnecessarily fully matched.
z On a NBMA network, it is necessary to elect DR and BDR; while a p2mp network
has no DR and BDR.
4-11
z NBMA is the default network type. For example, if ATM is adopted as the link layer
protocol, OSPF defaults the network type on the interface to NBMA, regardless of
whether the network is fully connected. In contrast, p2mp is not a default network
type. No link layer protocol is regarded to be p2mp by default. A p2mp network is
compulsorily changed from other networks types. The common practice is to
change a non fully-matched NBMA into a p2mp network.
z NBMA forwards packets by unicast and neighbors shall be configured manually.
While p2mp forwards packets by multicast.
Table 4-6 Configure the network type of an OSPF interface
Operation Command
Configure the network type of an OSPF ospf network-type { broadcast | nbma
interface | p2mp | p2p }
Restore the default network type of an
undo ospf network-type
OSPF interface
After the interface has been configured with a new network type, the original network
type of the interface is removed automatically.
4.2.7 Configuring the Adjacent Point
For an NBMA network, OSPF router cannot discover the adjacent router through
broadcasting the Hello packets, you must manually assign an IP address to the
adjacent router and specify whether the adjacent router is eligible for election.
Table 4-7 Configure the adjacent point
Operation Command
peer ip-address [ dr-priority
Configure a peer for the NBMA interface
dr-priority-number ]
Remove the configured peer for the
undo peer ip-address
NBMA interface
By default, the preference for the neighbor of NBMA interface is 1.

The preference levels set with the ospf dr-priority command and the peer command
are used in different purpose:
z The preference levels set with the ospf dr-priority command are for real DR
election.
z The preference levels set with the peer command indicate if the neighbors are
authorized to elect. The preference level 0 means the neighbor is not authorized
4-12
and no hello messages are sent to the neighbor. This is an effective way to reduce
hello packet number in electing DR and BDR. But if the local router is DR or BDR,
it will still send hello messages to its neighbor with preference level 0, to set up
adjacency relation.
4.2.8 Configuring OSPF to Redistribute Routes
I. Redistributing routes of other protocols
The dynamic routing protocols on the firewall can share the routing information. As far
as OSPF is concerned, the routes discovered by other routing protocols are always
processed as the external routes of AS. You can specify the type of route cost, cost and
tag to overwrite the default route receiving parameters.
The OSPF uses the following four types of routes (sequencing in priority):
z Intra-area route
z Inter-area route
z External route type 1
z External route type 2
Intra-area and inter-area routes describe the internal AS topology whereas the external
routes describe how to select the route to the destinations beyond the AS.
The external routes type-1 refers to the redistributed IGP routes (such as static route
and RIP). Since these routes are more reliable, the calculated cost of the external
routes is the same as the cost of routes within the AS. Also, such route cost and the
route cost of the OSPF itself are comparable. That is, cost to reach the external route
type 1 = cost to reach the corresponding ASBR from the local router + cost to reach the
destination address of the route from the ASBR.
The external routes type-2 refers to the redistributed EGP routes. Since these routes
have lower credibility, OSPF assumes that the cost spent from the ASBR to reach the
destinations beyond the AS is greatly higher than that spent from within the AS to the
ASBR. So in route cost calculation, the former is mainly considered, that is, the cost
spent to reach the external route type 2 = cost spent to the destination address of the
route from the ASBR. If the two values are equal, then the cost of the router to the
corresponding ASBR will be considered.
4-13
Table 4-8 Configure OSPF to redistribute routes of other protocols
Operation Command
import-route protocol [ allow-ibgp]
Configure OSPF to redistribute routes of
[ cost value ] [ type { 1 | 2 } ] [ tag value ]
other protocols
[ route-policy route-policy-name ]
Cancel redistributing routing information
of other protocols
By default, OSPF will not redistribute the routing information of other protocols.
When the protocol argument is set to BGP, the keyword allow-ibgp is optional.
Whereas the import-route bgp command redistributes only EBGP routes, the
import-route bgp allow-ibgp command redistributes IBGP routes in addition and as
such, must be used with cautions.
The protocol specifies a source routing protocol that can be redistributed. By far, it can
be Direct, Static, RIP or BGP.
II. Configuring parameters for OSPF to redistribute external routes
In the case that OSPF redistributes routing information found by other routing protocols
to the local AS, it is also necessary to configure some extra parameters, such as default
cost and default tag for route redistribution. A route label can be used to identify
relevant protocol information, such as the number used to distinguish different ASs
when OSPF receives BGP.
Table 4-9 Configure parameters for OSPF to redistribute external routes
Operation Command
Configure the minimum interval for OSPF to
default interval seconds
redistribute the external routes
Restore the default value of the minimum interval
undo default interval
for OSPF to redistribute the external routes
Configure upper limit for OSPF to redistribute
default limit routes
routes each time
Restore the default upper limit for OSPF to
undo default limit
redistribute routes each time
Configure the default cost for OSPF to receive
default cost value
external routes
Restore the default cost for OSPF to receive
undo default cost
external routes
Configure the default tag when OSPF receives
default tag tag
external routes
4-14
Operation Command
Restore the default tag when OSPF receives
undo default tag
external routes
Configure the default type of external routes that
default type { 1 | 2 }
OSPF will redistribute
Restore the default type of the external routes
undo default type
redistributed by OSPF
By default, no default cost and tag are available when redistributing external routes and
the type of redistributed route is type-2. The interval of redistributing the external route
is 1 second. The upper limit to the external routes redistributed is 1000 per second.
4.2.9 Configuring OSPF to Create the Default Route
By default, no default route is configured for general OSPF areas (backbone area and
non-backbone areas), and you cannot redistribute default route into OSPF routing
domain by using the import-route command.
You can use the default-route-advertise command to generate and advertise a
default route in OSPF area. You need to care for these points in this process:
z Using the default-route-advertise command at ASBR in general OSPF area, you
can generate a default route which is advertised by the Type-5 LSA into OSPF
area.
z Using the default-route-advertise command at ASBR or ABR in NSSA, you can
generate a default route which is advertised by the Type-7 LSA into NSSA.
z This is command is absolutely ineffective to Stub area and totally stub area.
z For an ASBR, only when the routing table contains a default route can OSPF
generate the corresponding Type-5 LSA or Type-7 LSA.
z The Type-5 LSA or Type-7 LSA which advertises the default route has the same
spread range as the general Type-5 LSA or Type-7 LSA.
Table 4-10 Create a default route in an OSPF routing domain
Operation Command
default-route-advertise [ always | cost value |
Create a default route
type value | route-policy route-policy-name ]
undo default-route-advertise [ always | cost |
Remove the default route
type | route-policy ] *
By default, no default route is configured in OSPF area.
4-15
If the always keyword is selected in using the command, the Type-5 LSA or Type-7
LSA will be generated no matter whether there is a default route in the routing table.
Note that this keyword is only available for ASBR and care should be taken in using it.
OSPF will not calculate the LSA generated by itself in SPF algorithm, so no default
route exists among the OSPF routes. You have to redistribute the default route on
those routers connecting with external networks.
Note:
An OSPF router after the default-route-advertise command is executed will become
an ASBR, as is similar to executing the import-route command on an OSPF router.
For the ABR or ASBR in NSSA, the default-route-advertise command is equivalent to
the nssa default-route-advertise command in terms of effect.
4.2.10 Configuring OSPF Route Filtering
I. Configuring OSPF to filter the received routes
After receiving LSAs, OSPF determines whether to add calculated routing information
to the route table according to the filtering condition.
Table 4-11 Configure OSPF to filter the redistributed routes
Operation Command
Configure to filter the redistributed
ip-prefix-name | gateway prefix-list-
routing information
name } import
undo filter-policy { acl-number |
Cancel to filter the redistributed routing
ip-prefix ip-prefix-name | gateway
information
ip-prefix-name } import
Caution:
This command can only prevent routing information from being added to the route table,
but related LSAs can still be notified to other neighbors.
4-16
II. Configuring OSPF to filter the redistributed routes
Use the filter-policy export command to configure the ASBR to filter external routes
redistributed to OSPF, that is, filter the LSAs of redistributed routes distributed to
outside. Thos command is only valid for the ASBR.
Table 4-12 Configure OSPF to filter the distributed routes
Operation Command
Enable OSPF to filter the distributed
ip-prefix-name } export
routes
[ routing-process ]
Disable OSPF to filter the distributed
ip-prefix ip-prefix-name } export
routes
[ routing-process ]
By default, OSPF will not filter the redistributed and distributed routing information.
Note:
You can use the filter-policy import command to filter only this process OSPF routes.
The routes failing to be filtered will not be added into the routing table.
The filter-policy export command is only valid for routes redistributed by local device
using the import-route command. OSPF distributes routing information by LSAs
instead of routing tables. If you only configure the filter-policy export command (do
not configure the import-route command) to redistribute other routes (including OSPF
routes of different processes), the filter-policy export command takes no effect.
If the filter-policy export command does not specify the route type to be filtered, this
command is valid for all types of routes redistributed by this device using the
import-route command.
4.2.11 Configuring Route Aggregation by OSPF
I. Configuring the Route Aggregation of OSPF Area
Route aggregation means that ABR can aggregate information of the routes of the
same prefix and advertise only one route to other areas. An area can be configured
with multiple aggregate segments, thereby OSPF can summarize them. When the ABR
transmits routing information to other areas, it will generate type-3 LSA per network. If
some continuous segments exist in this area, you can use the abr-summary command
to summarize these segments into one segment. In this way, ABR only sends an LSA
after aggregation. No LSA that falls into the specified aggregation network segment of
4-17
this command will be separately transmitted. The LSDB scale in other areas is
accordingly reduced.
If the keyword not-advertise is used to qualify the network segment, the summary
route information to the network segment will not be broadcast. This network segment
is identified by IP address/mask.
Note: Only when configured on ABR can route aggregation take effect.
Table 4-13 Configure the route aggregation in OSPF area
Operation Command
Configure the route aggregation in abr-summary ip-address mask
OSPF area [ advertise | not-advertise ]
Cancel route aggregation in OSPF area undo abr-summary ip-address mask
By default, the inter-area routes will not be aggregated.
II. Configuring aggregation of redistributed routes by OSPF
OSPF supports route aggregation of redistributed routes.

Table 4-14 Configure aggregation of redistributed routes by OSPF
Operation Command
Configure aggregation of redistributed asbr-summary ip-address mask
routes by OSPF [ not-advertise | tag value ]
Remove aggregation of redistributed
undo asbr-summary ip-address mask
routes by OSPF
By default, aggregation of redistributed routes is disabled.

After the aggregation of redistributed routes is configured, if the local router is an
autonomous system border router (ASBR), this command aggregates the redistributed
Type-5 LSAs in the aggregation address range. When NSSA is configured, this
command will also aggregate the redistributed Type-7 LSA in the aggregation address
range.
If the local router works as an area border router (ABR) and a transit router in the NSSA,
this command aggregates Type-5 LSAs transformed from Type-7 LSAs. If the router is
not the router in the NSSA, the aggregation is disabled.
4-18
4.2.12 Setting OSPF Route Preference
Since maybe multiple dynamic routing protocols are run on one firewall concurrently,
the problem of route sharing and selection between various routing protocols occurs.
The system sets a priority for each routing protocol, which will be used in tie-breaking in
the case that different protocols discover the same route.
Table 4-15 Set OSPF route preference
Operation Command
Configure a preference for OSPF to
preference [ ase ] preference
compare with the other routing protocols
Restore the default protocol preference undo preference [ ase ]
By default, the OSPF preference is 10, and the redistributed external routing protocol is
150.
4.2.13 Configuring OSPF Timers
I. Setting the interval of Hello packet transmission
Hello packets are a kind of most frequently used packets, which are periodically sent to
the adjacent router for discovering and maintaining the adjacency, and for electing DR
and BDR. The user can set the value of the interval for sending a hello packet.
According to provisions in RFC2328, it is necessary to keep consistency of the Hello
timer between network neighbors. Note that the value of hello timer is inversely
proportional to route convergence speed and network load.
Table 4-16 Set the interval of hello packet transmission
Operation Command
Set the hello interval of the interface ospf timer hello seconds
Restore the default hello of the interface undo ospf timer hello
Set the poll interval on the NBMA
ospf timer poll seconds
interface
Restore the default poll interval undo ospf timer poll
By default, p2p and broadcast interfaces send Hello packets every 10 seconds; while
p2mp and NBMA interfaces send the packets every 30 seconds.
4-19
II. Setting dead time for the neighboring routers
If a router receives no hello packet from its neighbor in a certain time, the neighbor
router is regarded invalid. This time interval is called dead time between neighboring
routers.
Table 4-17 Set dead time for the neighboring routers
Operation Command
Configure a dead timer for the neighboring routers ospf timer dead seconds
Restore the default dead interval of the neighboring
undo ospf timer dead
routers
By default, the dead interval for the neighboring routers of p2p or broadcast interfaces
is 40 seconds and that for the neighboring routers of p2mp or NBMA interface is 120
seconds.
Note that both hello interval and dead timer will restore to the default values after the
user modify the network type.
III. Setting an interval for LSA retransmission between neighboring routers
After a router sends an LSA to its neighbor, it waits for the acknowledgement packet
from its neighbor. If it receives no acknowledgement packet from its neighbor, it will
retransmit the LSA. The user can set the value of retransmit.
Table 4-18 Set the interval for LSA retransmission between neighboring routers
Operation Command
Configure the interval of LSA retransmission for
ospf timer retransmit interval
the neighboring routers
Restore the default LSA retransmission interval
undo ospf timer retransmit
for the neighboring routers
By default, the interval for neighboring routers to retransmit LSAs is 5 seconds.

The value of interval must be greater than the time for a packet to be transmitted a
round between two routers.
Note that you should not set the LSA retransmission interval too small. Otherwise,
unnecessary retransmission will be caused.
4-20
4.2.14 Setting the Interface Priority for DR Election
Designated router (DR) and backup designated router (BDR) should be elected in
broadcast network or NBMA network.
The priority of the router interface determines the qualification of the interface in DR
election, and the router of higher priority will be considered first if there is a collision in
the election.
DR is elected by all the routers on the segment. Routers with the priorities greater than
0 in the network are eligible "candidates". Among all the routers self-proclaimed to be
the DR, the one with the highest priority will be elected. If two routers have the same
priority, the one with the highest router ID will be elected as the DR. Votes are the hello
packets. Each router writes the elected DR in the packet and sends it to all the other
routers on the segment. If two routers attached to the same segment concurrently
declare themselves to be the DR, choose the one with higher priority. If their priorities
are equal, the one with greater router ID will be preferred. A router, whose priority is 0,
cannot be elected as a DR or BDR.
If a DR becomes invalid due to some fault, it must be reelected from routers on the
network and synchronized with other routers. It takes time and meanwhile the route
calculation is incorrect. In order to speed up this process, the concept of BDR is instilled
in OSPF. In fact, BDR is a backup for DR. DR and BDR are elected in the mean time.
The adjacencies are also established between the BDR and all the routers on the
segment, and routing information is also exchanged between them. When the DR fails,
the BDR will become the DR instantly. Since no re-election is needed and the
adjacencies have already been established, the process is very short. But in this case,
a new BDR should be elected. Although it will also take a quite long period of time, it will
not exert any influence upon the route calculation.
But please note:
z When the precedence of an interface is 0, the interface cannot be a DR/BDR
anyway, which may result in a network without DR or BDR.
z The DR on the network is not necessarily the router with the highest priority.
Likewise, the BDR is not necessarily the router with the second highest priority. If a
new router is added after DR and BDR election, it is impossible for the router to
become the DR even if it has the highest priority.
z A DR is on a certain network segment, in the sense of router interface. Maybe a
router is a DR on one interface, but can be a BDR or DR Other on the other
interface.
z Only when an interface is of broadcast or NBMA type, is it necessary to elect DR. A
p2mp or a p2p interface needs not to elect DR. On a broadcast network or NBMA
network, if no one declares that it is DR in the hello packets received, the election
process starts; if multiple routes declare that they are the DR/BDR, the election
process also starts; if a router declares that it is the DR/BDR, new-added routers
4-21
will accept the existing DR/BDR without considering about its precedence; when
the DR fails, the BDR will become the DR, a new BDR will be elected.
Table 4-19 Set the interface priority for DR election
Operation Command
Configure the interface with a priority for DR
ospf dr-priority priority_num
election
Restore the default interface priority undo ospf dr-priority
By default, the priority of the Interface is 1 in the DR election. The value can be taken
from 0 to 255.
4.2.15 Configuring the Cost for Sending Packets on an Interface
The user can control the network traffic by configuring different packet sending costs for
different interfaces.
Table 4-20 Configure the cost for sending packets on an interface
Operation Command
Configure the cost for sending packets on an interface ospf cost value
Restore the default cost for packet transmission on the interface undo ospf cost
By default, OSPF calculates the cost for sending packets according to the interface
rate.
4.2.16 Setting a Shortest Path First (SPF) Calculation Interval for OSPF
Whenever the LSDB of OSPF changes, the shortest path should be recalculated.
Calculating the shortest path upon change will consume enormous resources as well
as affect the operation efficiency of the router. Adjusting the SPF calculation interval,
however, can restrain the resource consumption due to frequent network changes.
Table 4-21 Set the SPF calculation interval
Operation Command
Set the SPF calculation interval spf-schedule-interval seconds
Restore the SPF calculation interval undo spf-schedule-interval seconds
4-22
By default, the interval of SPF recalculation is 5 seconds.
4.2.17 Configuring an Interval Required for Sending LSU Packets
Transmitting-delay should be added to the aging time of the LSA in an LSU packet.
Setting the parameter like this mainly considers the time duration that the interface
requires for transmitting the packet.
The user can configure the interval of sending LSU packets. Obviously, more attention
should be paid on this item over low speed network.
Table 4-22 Configure the interval for sending LSU packets
Operation Command
Configure the transmitting-delay for sending LSU
ospf trans-delay seconds
packets
Restore the default value of transmitting-delay for
undo ospf trans-delay
sending LSU packets
By default, the transmitting-delay is 1 second.
4.2.18 Configuring if Filling in the MTU Field When Transmitting DD Packets
OSPF-running routers use the DD (Database Description) packets to describe their

own LSDBs when synchronizing the databases.
You can manually specify an interface to fill in the MTU field in a DD packet when it
transmits the packet. The MTU should be set to the real MTU on the interface.
Table 4-23 Configure if filling in the MTU field when transmitting DD packets
Operation Command
Enable an interface to fill in the MTU field when
ospf mtu-enable
transmitting DD packets
Disable the interface to fill in MTU when transmitting
undo ospf mtu-enable
DD packets
By default, the interface does not fill in the MTU field when transmitting DD packets. In
other words, the MTU field in the DD packets is 0.
4.2.19 Configuring Maximum Number of Equal-Cost Routes
4-23
Table 4-24 Configure maximum number of OSPF equal-cost routes
Operation Command
Configure maximum number of OSPF
multi-path-number number
equal-cost routes

undo multi-path-number
OSPF equal-cost routes
The default maximum number of OSPF equal-cost routes is 3.
4.2.20 Configuring OSPF Authentication
I. Configuring the OSPF area to support packet authentication
The authentication type (not support authentication, support plain text authentication or
support MD5 encryption authentication) of all routers in one area must be consistent.
The password on each link can be different. You can use the authentication-mode
simple command to configure plain text authentication password in the area and use
the authentication-mode md5 command to configure MD5 encrypted authentication
password in the area.
Table 4-25 Configure the OSPF area to support packet authentication
Operation Command
Configure the area to support MD5
authentication-mode { simple | md5 }
authentication
Disable the area to support MD5
undo authentication-mode
authentication attributes
By default, the area does not support packet authentication.
II. Configuring OSPF packet authentication
OSPF supports plain text authentication or MD5 authentication between neighboring

routers.
Table 4-26 Configure OSPF Packet Authentication
Operation Command
Specify a password for OSPF simple ospf authentication-mode simple
text authentication password
Cancel plain text authentication on the undo ospf authentication-mode
interface simple
4-24
Operation Command
Specify the key-id and key for OSPF ospf authentication-mode md5 key_id
MD5 authentication key
Cancel MD5 authentication on the
undo ospf authentication-mode md5
interface
By default, the interface is not configured with either plain text authentication or MD5
authentication.
4.2.21 Configuring the Operating State of the Interface
To prevent OSPF routing information from being acquired by the routers on a certain
network, use the silent-interface command to disable the interface to transmit OSPF
packets.
Different processes can disable the same interface to forward OSPF packet; while the
silent-interface command is only valid for the OSPF interface where the specified
process has been enabled, with no effect to the interface with other processes.
Table 4-27 Disable/Enable the interface to send OSPF packets
Operation Command
Disable the interface from sending silent-interface interface-type
OSPF packets interface-number
Enable the interface to send OSPF undo silent-interface interface-type
packets interface-number
By default, all the interfaces are allowed to transmit and receive OSPF packets.
After an OSPF interface is set to be in silent status, the interface can still advertise its
direct route. However, the OSPF packets of the interface will be blocked, and no
neighboring relationship can be established on the interface. Thereby, the capability for
OSPF to adapt to the networking can be enhanced, which will hence reduce the
consumption of system resources.
4.2.22 Configuring OSPF STUB Area
The Stub area, a type of OSPF area, does not receive or advertise Type-5 LSAs. The
Stub area is often at the AS border and can effectively minimize the LSDB size of the
routers in the Stub area and lower resource occupation for SPF calculation.
4-25
To ensure correct forwarding of the packets from the Stub area to the external network,
the ABR in the Stub area advertises a default route through the Type-3 LSAs and only
within this area.
Note:
The ABR advertises inter-area default routes through Type-3 LSA.
Please pay attention to the following items when configuring a STUB area:
z The backbone area cannot be configured to be the STUB area.
z The virtual link cannot pass through the STUB area.
z If you want to configure an area to be the STUB area, then all the routers in this
area should be configured with this attribute.
z ASBR cannot exist in a STUB area. In other words, routers outside an AS cannot
be transmitted in the local area.
Table 4-28 Configure OSPF STUB area
Operation Command
Configure an area to be the STUB area stub [ no-summary ]
Remove the configured STUB area undo stub

Configure the cost of the default route transmitted by
default-cost value
OSPF to the STUB area
Restore the cost of the default route to the STUB area undo default-cost
By default, the STUB area does not exist, and the cost of the default route to the STUB
area is 1.
Note that the no-summary parameter is only available for the ABR. When it is used for
the ABR in the Stub area, the ABR only advertises in the area a Summary-LSA of the
default route, not others. Since this kind of Stub area has no AS-external-LSAs or
Summary-LSAs, it is also called totally Stub area.
The default-cost command is for the ABR in the Stub area and defines the cost value
for the default route advertised by the ABR to the Stub area.
4.2.23 Configuring NSSA Parameters of OSPF
As we learned from last section, there is no information about AS external routing in a

Stub area. The default route ensures its external reachability. RFC1587 (OSPF NSSA
Option) defines the Not-So-Stubby-Area (NSSA), which keeps the strong points of Stub
4-26
area while providing flexible networking. This area can redistribute AS external routes
in a limited way.
NSSA is, in fact, the expansion of the Stub area, so it resembles the Stub area in many
ways. These points should be cared for in configuring an NSSA:
z The backbone area cannot be configured as NSSA.
z NSSA cannot serve as transit area, that is, a viral link cannot be set up across an
NSSA.
z All routers in an NSSA must be configured with the corresponding attribute.
Unlikely the Stub area, an NSSA area may contain ASBRs.
Type-7 LSAs, which are similar to Type-5 LSAs, are used for the AS external route
information in the NSSA. For more details about these two types, see 4.1.5 “LSA Types
Available in OSPF”.
The advertisement of AS external route information in NSSA is illustrated in Figure 4-3,
where three areas are included in the OSPF process 100: area 0 is backbone area;
area 1 is non-backbone area; area 2 is NSSA.
RIP OSPF 100 OSPF 200
SecPathB ABR ASBR

Area 2
SecPathA Area 1 Area 0 SecPathD
NSSA
SecPathC
Ty pe-5 LSA Ty pe-5 LSA Ty pe-7 LSA Ex ternal Route

Information
Ex ternal Route Ty pe-5 LSA Ty pe-5 LSA

Information
Figure 4-3 NSSA
The ASBR in the area 2 redistributes AS external route information (the route
information of OSPF process 200) to generate Type-7 LSAs and advertises them in the
area 2. When the Type-7 LSAs reach the NSSA ABR, they are converted into Type-5
LSAs which are advertised among the entire AS. The ASBR in the area 1 redistributes
AS external route information (the RIP route information) to generate Type-5 LSAs,
which are advertised among the OSPF AS. The RIP route information cannot arrive at
the area 2, the NSSA.
4-27
Table 4-29 Configure NSSA area parameters of OSPF
Operation Command
nssa [ default-route-advertise |
Configure an area to be an NSSA area
no-import-route | no-summary ] *
Remove a configured NSSA area undo nssa
Configure the cost for transmitting the
default-cost cost
default route to NSSA area
Restore the default cost for transmitting
undo default-cost
the default route to NSSA area
By default, the NSSA is not configured, and the cost of the default route to the NSSA is
1.
If the ASBR is also the ABR in NSSA, you are often not recommended to redistribute
AS external route information twice respectively as Type-5 LSAs and Type-7 LSAs.
Then you can select the no-import-route parameter to forbid AS external route
information being advertised to the NSSA as Type-7 LSAs.
Since the NSSA gets limited AS external route information, so the ABR in it need to
advertise a default route via the Type-7 LSAs to ensure correct forwarding of packets to
the networks outside the AS. The default route information from the NSSA ABR will not
be converted into Type-5 LSAs, while that from the NSSA ASBR will be converted.
The default-route-advertise parameter, which is only available for NSSA ASBR or
ABR, is used to generate Type-7 LSAs for the default route.
z When using the parameter at NSSA ABR, you can generate Type-7 LSAs for the
default route no matter whether there exists the default route 0.0.0.0 in the routing
table.
z When using the parameter at NSSA ASBR, you can generate Type-7 LSAs for the
default route only if there exists the default route 0.0.0.0 in the routing table.
z The no-summary parameter is only available for the ABR in NSSA, as is the
same as in Stub area. When the parameter is selected, the NSSA ABR advertises
a default route via the Summary-LSAs (Type-3) in the area, but no other
Summary-LSAs to other areas.
Note:
The default-route-advertise parameter generates AS external default route which is
advertised in the NSSA via the Type-7 LSAs.
The no-summary parameter generates inter-area default route which is advertised via
the Type-3 LSAs.
4-28
The default-cost command, which is only available for the NSSA ABR, defines the
cost value for the default route advertised by the ABR to the NSSA.
4.2.24 Configuring OSPF in Concert with Network Management System
I. Configuring OSPF MIB binding
When multiple OSPF processes are enabled, you can configure OSPF MIB to opt for
the process under processing. In other words, you can configure which process OSPF
MIB is to be bound with.
Table 4-30 Configure OSPF MIB binding
Operation Command
Configure OSPF MIB binding ospf mib-binding process-id
Remove the default OSPF MIB binding undo ospf mib-binding
By default, MIB is bound with the first enabled OSPF process.
II. Configuring OSPF TRAP
OSPF can be configured to forward diversified SNMP TRAP packets and a certain
OSPF process can be specified via process number to send SNMP Trap packets.
Table 4-31 Configure OSPF TRAP
Operation Command
snmp-agent trap enable ospf [ process-id ]
[ ifstatechange | virifstatechange | nbrstatechange |
virnbrstatechange | ifcfgerror | virifcfgerror | ifauthfail |
Enable OSPF Trap
virifauthfail | ifrxbadpkt | virifrxbadpkt | txretransmit |
viriftxretransmit | originatelsa | maxagelsa |
lsdboverflow | lsdbapproachoverflow ]
undo snmp-agent trap enable ospf [ process-id ]
[ ifstatechange | virifstatechange | nbrstatechange |
virnbrstatechange | ifcfgerror | virifcfgerror | ifauthfail |
Disable OSPF Trap
virifauthfail | ifrxbadpkt | virifrxbadpkt | txretransmit |
viriftxretransmit | originatelsa | maxagelsa |
lsdboverflow | lsdbapproachoverflow ]
By default, OSPF Trap is disabled, that is, OSPF process does not forward Trap
packets. If the process number is not specified during configuration, OSPF TRAP
configuration will be valid for all OSPF processes.
4-29
For detailed configuration about SNMP Trap, refer to the module about “Basic
Configuration” of this manual.
4.2.25 Resetting an OSPF Process
If the undo ospf command is executed on a firewall and then the ospf command is
used to reset an OSPF process, the previous OSPF configuration will be lost. With the
reset ospf all command, you can reset the OSPF process without losing the previous
OSPF configuration.
Table 4-32 Reset an OSPF process
Operation Command
Reset an OSPF process reset ospf [ statistics ] { all | process-id }
Resetting the OSPF process can immediately clear the invalid LSAs, make the
modified Router ID immediately effective or re-elect the DR and BDR.
If the process number is not specified, all OSPF processes will be reset.
4.3 Displaying and Debugging OSPF

running of the OSPF configuration, and to verify the effect of the configuration. Execute
debugging command in user view to debug the OSPF module.
Table 4-33 Display and debug OSPF
Operation Command
Display the brief information of the
display ospf [ process-id ] brief
OSPF routing process
Display OSPF statistics display ospf [ process-id ] cumulative
display ospf [ process-id ] lsdb [ brief |
asbr | ase | network | nssa | router |
Display LSDB information of OSPF summary ] [ ip-address ]
[ originate-router ip-address |
self-originate ]
display ospf [ process-id ] peer [ brief |
Display OSPF neighbor information
statistics ]
Display OSPF next hop information display ospf [ process-id ] nexthop
Display OSPF routing table display ospf [ process-id ] routing
Display OSPF virtual links display ospf [ process-id ] vlink
4-30
Operation Command
display ospf [ process-id ]
Display OSPF request list
request-queue
display ospf [ process-id ]
Display OSPF retransmission list
retrans-queue
Display the OSPF routing information to
display ospf [ process-id ] abr-asbr
ABR and ASBR
display ospf [ process-id ] interface
Display OSPF interface information
[ interface-type interface-number ]
Display OSPF errors display ospf [ process-id ] error
Display the debugging of OSPF process display debugging ospf
debugging ospf [ process-id ] packet
[ ack | dd | hello | request I update ]
Enable the debugging of OSPF packet
interface-number ]
Enable to output BGP adjacent status
log-peer-change
change (in BGP view)
Disable to output BGP adjacent status
undo log-peer-change
undo debugging ospf [ process-id ]
packet [ ack | dd | hello | request I
Disable the debugging of OSPF packet
update ] [ interface interface-type
interface-number ]
Enable the debugging of OSPF event debugging ospf [ process-id ] event
undo debugging ospf [ process-id ]
Disable the debugging of OSPF event
event
Enable the debugging of OSPF LSA debugging ospf [ process-id ]
packet lsa-originate
Disable the debugging of OSPF LSA undo debugging ospf [ process-id ]
packet lsa-originate
Enable OSPF SPF debugging debugging ospf [ process-id ] spf
Disable OSPF SPF debugging undo debugging ospf [ process-id ] spf
4-31
4.4 OSPF Configuration Example
Caution:
In configuration examples, only the commands related to the OSPF configuration are
listed.
4.4.1 OSPF Configuration Example
SecPath A and SecPath B are connected by serial interfaces, and SecPath B and
SecPath C are connected by Ethernet interfaces. SecPath A belongs to area0,
SecPath C belongs to area1, and SecPath B belongs to both area0 and area1.
II. Network diagram
PC
e0/0/0 e1/0/0 : e0/0/0: e1/0/0
: e1/0/0
20.0.0.1/8 10.0.0.1/8 10.0.0.2/8 40.0.0.1/8 40.0.0.2/8
e0/0/1: ID:3.3.3.3
30.0.0.1/8 ID:1.1.1.1 ID:2.2.2.2
SecPathA SecPathB Area 1 SecPathC
Area 0
PC
Figure 4-4 Configure OSPF
[H3C] router id 1.1.1.1
[H3C-ethernet1/0/0] ip address 10.0.0.1 255.0.0.0
[H3C-ethernet1/0/0] interface ethernet0/0/0
[H3C-ethernet0/0/1] quit
[H3C] ospf
[H3C-ospf-1] area 0
4-32
[H3C-ospf-1-area-0.0.0.0] network 10.0.0.1 0.255.255.255

[H3C-ospf-1 -area-0.0.0.0] network 20.0.0.1 0.255.255.255
[H3C-ospf-1 -area-0.0.0.0] network 30.0.0.1 0.255.255.255
[H3C] internet ethernet0/0/0
[H3C-ethernet0/0/0] interface ethernet 1/0/0
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1-area-0.0.0.0] area 1
# Configure SecPath C:
[H3C] ospf
[H3C-ospf-1] area 1
Performing the display ip routing-table command on SecPath A and C, you can see
that the two obtains the route to each other by OSPF, that is, both of them have routes
to 20.0.0.0/8, 30.0.0.0/8, and 40.0.0.0/8.
4.4.2 Configuring OSPF Multi-process
Enable the OSPF process 100 on the interface Ethernet1/0/0 of SecPath A in Area 0.
Enable the OSPF process 100 on the interface Ethernet1/0/0 of SecPath B in Area 0
and enable the OSPF process 200 on the interface Ethernet2/0/0 of SecPath B in Area
0.
Enable the OSPF process 200 on the interface Ethernet2/0/0 of SecPath C in Area 0.
You can create neighbourship between SecPath A and SecPath B or between SecPath
B and SecPath C.
4-33
II. Network diagram
SecPathA SecPathB
Loopback0 Ethernet1/0/0 Ethernet1/0/0 Loopback0
10.10.1.2/24 172.10.1.2/16 172.10.1.1/16 10.10.4.2/24
Process 100
Ethernet2/0/0 Area 0 Ethernet2/0/0
202.38.169.2/24 131.108.1.3/16
Process 200
Area 0
Ethernet2/0/0
131.108.1.1/16
Ethernet1/0/0
202.38.168.2/24
Loopback0
SecPathC 10.10.3.2/24
Figure 4-5 OSPF multi-process
[H3C] ospf 100
[H3C-ospf-100] area 0
[H3C] ospf 100 router-id 10.10.2.2
[H3C-ospf-100] quit
[H3C] ospf 200 router-id 10.10.4.2
4-34

[H3C] ospf 200
Execute the display ospf peer command on SecPath B to view the neighbor creation.
You will find that SecPath B and SecPath A form neighboring relationship in the OSPF
process 100; while SecPath A and SecPath C cannot learn the routes from the peer via
OSPF.
4.4.3 Configuring DR Election Based on OSPF Priority
In the following figure, the priority of SecPath A is 100, which is the highest in the
network, so it is elected as the DR; SecPath C has the second highest priority, so it is
elected as the BDR; The priority of SecPath B is 0, which means that it cannot be
elected as the DR, and SecPath D does not have a priority, so the priority is 1 by
default.
II. Network diagram
DR 1.1.1.1 4.4.4.4
SecPathA SecPathD
ethernet1/0/0 ethernet1/0/0
192.1.1.1/24 192.1.1.4/24
Ethernet 192.1.1.0
192.1.1.2/24 192.1.1.3/24
SecPathB SecPathC
2.2.2.2 3.3.3.3 BDR

Figure 4-6 Configuring DR election based on OSPF priority
[H3C-Ethernet1/0/0] ospf dr-priority 100
4-35

[H3C] ospf
[H3C-ospf-1] area 0
[H3C] ospf
[H3C-ospf-1] area 0
[H3C] ospf
[H3C-ospf-1] area 0
# Configure SecPath D:
[H3C] ospf
[H3C-ospf-1] area 0
Execute the display ospf peer command on SecPath A to view the OSPF neighbors
and you will find that there are three neighbors on SecPath A.
All neighbors are in full state. This indicates that SecPath A forms neighboring
relationships with all its neighbors (SecPath A and SecPath C must form neighboring
relationships with all firewalls on the network so as to act on the DR and BDR on the
network. SecPath A is the DR on the network, while SecPath C is the BDR. All other
neighbors are DR other (this indicates that they are neither DR not BDR.)
Change the priority of SecPath B into 200:
4-36
In SecPath A, run display ospf peer to view its OSPF peers. Please note the priority of
SecPath B has been modified as 200, but it is still not the DR.
Only when the current DR is offline, will the DR be changed. Switch off SecPath A and
execute the display ospf peer command on SecPath D to view the OSPF peers and
you will find that the original BDR, SecPath C, has turned into a DR and SecPath B is a
BDR at the moment.
Switch off all the gateways and restart them. Such operations will bring about a new
DR/BDR selection. SecPath B will be selected as a DR (with a priority of 200) and
SecPath A will become a BDR (with a priority of 100).
4.4.4 Configuring Virtual Link of the OSPF
As Figure 4-7 shows, area 2 is not directly connected to area 0. They are actually
connected by the transit area, area 1. A virtual link is created between SecPath B and
SecPath C.
II. Network diagram
SecPathA
1.1.1.1
ethernet2/0/0
Area 0 192.1.1.1/24
ethernet2/0/0
192.1.1.2/24
SecPathB
2.2.2.2 ethernet1/0/0
193.1.1.2/24
Area 1 ethernet1/0/0
Virtual Link 193.1.1.1/24
SecPathC
3.3.3.3
ethernet2/0/0
152.1.1.1/24 Area 2
Figure 4-7 Network diagram of an OSPF virtual link
4-37
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-Ethernet2/0/0] interface ethernet 1/0/0
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1-area-0.0.0.0] quit
[H3C-ospf-1] area 1
[H3C-ospf-1-area-0.0.0.1] vlink-peer 3.3.3.3
[H3C] ospf
[H3C-ospf-1] area 1
[H3C-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[H3C-ospf-1] area 2
[H3C–ospf-1-area-0.0.0.2] network 152.1.1.0 0.0.0.255
4.4.5 Configuring OSPF Peer Authentication
In Figure 1-7, SecPath A and SecPath B exchange routing updates through simple text
authentication, while SecPath A and SecPath C exchange routing updates through
MD5 authentication.
4-38
The Ethernet interfaces of SecPath A and SecPath B reside in OSPF Area 0. The
Ethernet interfaces of SecPath A and SecPath C reside in OSPF Area 1. They are all
configured with MD5 authentication in Area 1.
II. Network diagram
SecPathB
2.2.2.2
Area 0 Simple authentication
ethernet2/0/0
192.1.1.2/24
ethernet2/0/0
192.1.1.1/24
SecPathA
1.1.1.1
Ethernet 1/0/0
193.1.1.1/24
Ethernet 1/0/0
Area 1
MD5 authentication 193.1.1.2/24
SecPathC
3.3.3.3
Figure 4-8 Network diagram for configuring OSPF neighboring authentication
Configure the Area 1, where the network segment 193.1.1.0 of the interface
Ethernet1/0/0 resides, to support MD5 encryption authentication, with the
authentication ID being 1 and the authentication password being password.
Configure the Area 0, where the network segment 192.1.1.0 of the interface
ethernet2/0/0 resides, to support simple text authentication, with the authentication
password being password.
[H3C-Ethernet2/0/0] ospf authentication-mode simple password
[H3C-Ethernet1/0/0] ospf authentication-mode md5 1 password
[H3C] ospf
[H3C-ospf-1] area 0
4-39

[H3C-ospf-1-area-0.0.0.0] authentication-mode simple
[H3C-ospf-1] area 1
[H3C-ospf-1-area-0.0.0.1] authentication-mode md5
[H3C-Ethernet2/0/0] ospf authentication-mode simple password
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1-area-0.0.0.0] authentication-mode simple
[H3C-Ethernet1/0/0] ospf authentication-mode md5 1 password
[H3C] ospf
[H3C-ospf-1] area 1
[H3C-ospf-1-area-0.0.0.1] authentication-mode md5
4.4.6 Configuring OSPF STUB Areas
SecPath A and SecPath B are connected by serial interfaces, and SecPath B and
SecPath C are connected by Ethernet interfaces. SecPath A belongs to area0,
SecPath C belongs to area1, and SecPath B belongs to both area0 and area1.
Configure area1 as a STUB area.
4-40
II. Network diagram
PC e0/0/0: e1/0/0: e0/0/0: e1/0/0

: e1/0/0
20.0.0.1/8 10.0.0.1/8 10.0.0.2/8 40.0.0.1/8 40.0.0.2/8
e0/0/1 : ID:3.3.3.3
30.0.0.1/8 SecPathA ID:1.1.1.1 ID:2.2.2.2 SecPathB SecPathC
Area 1
Area 0
PC
Figure 4-9 Configure OSPF STUB areas
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ethernet0/0/0] interface ethernet 1/0/0
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1-area-0.0.0.0] area 1
[H3C-ospf-1-area-0.0.0.1] stub
4-41
[H3C] ospf
[H3C-ospf-1] area 1
[H3C-ospf-1-area-0.0.0.1] stub
Now, on SecPath C, in addition to inter-area routes discovered by OSPF, there should

be a default route of 0.0.0.0/0.
If you configure the stub nosummary command instead of the stub command on ABR
SecPath B, area1 will become completely a STUB area, and SecPath C no longer has
any inter-area routes but a default route.
4.5 Troubleshooting OSPF

Symptom 1: The OSPF is configured according to the above procedures, but the router
OSPF cannot operate normally.
Troubleshooting:
Please check according to the following procedures.
1) Local fault removal: Firstly, check whether the protocol between two directly
connected routers is in normal operation. The normal sign is the peer status
machine between the two routers reaches the FULL state. (Note that in the
Broadcast and NBMA network, the peer state machine between two DR Other
routers cannot reach the FULL state but the 2-way state. But Full State can be
reached between the DR, BDR and all the other routers)
z Run the display ospf peer command to view the information about OSPF peer.
z Run display ospf interface command to view the OSPF information in the
interface.
z Check whether the physical connections and the lower level protocols operate
normally. You can run ping command to test. If the local router cannot reach the
remote router, it indicates that the physical connections and the lower level
protocols cannot operate normally.
z If the physical connections and the lower level protocols are normal, then please
check the OSPF parameters configured in the interface, but you must guarantee
the consistency of the parameters of its adjacent router. The area IDs should be
the same, and the network segments and the masks should also be consistent
(the p2p and virtually linked network segments and masks can be different).
z Check and ensure that the value of the dead-interval in the same interface should
at least be four times the value of the hello-interval.
4-42
z If the network type is NBMA, you must manually specify Peer. The peer
ip-address command is used.
z If the network type is Broadcast or NBMA, the priority of at least one interface
should be larger than 0.
z If an Area is set as the STUB area, then the area must be set stub in all the routers
connected to this area.
z The interface types of two adjacent routers should be consistent.
z If more than two areas are configured, then at least one area should be configured
as the backbone area (i.e. the area ID is 0).
z Ensure the backbone area is connected with all the other areas.
z The virtual links cannot pass through the STUB area.
2) Global fault removal: If the above procedures are correct, but the OSPF still
cannot find the remote routes, please check the following configurations:
z If a router is configured with more than two areas, then at least one area should be
configured as the backbone area.
As is shown in the following figure, only an area is configured in SecPath A and
SecPath D, but two areas are configured in SecPath B (area0, area1) and SecPath C
(area1, area2) respectively. In which, SecPath B has an area with the ID of 0, so it
meets the requirement; while both areas of SecPath C are not 0, and accordingly it is
necessary to create a virtual connection between SecPath C and SecPath B. Ensure
that Area 2 and Area 0 (the backbone area) be interconnected.
Area 0 Area 1 Area 2
SecPathA SecPathB SecPathC SecPathD
Figure 4-10 OSPF area
z A virtual connection cannot go across a STUB area. The backbone area (Area 0)
cannot be configured into a STUB area either. In other words, if a virtual
connection is configured between SecPath B and SecPath C, neither Area 1 nor
Area 0 can be configured into a STUB area. In the above figure, only Area 2 can
be configured into a STUB area.
z The router in the STUB area cannot receive external routes.
z The backbone area should guarantee the connection between various nodes.
4-43
H3C SecPath Series Security Products Chapter 5 BGP Configuration
Chapter 5 BGP Configuration
Note:
For VPN instances and VPNv4 configuration examples and parameter explanation in
BGP, refer to the VPN part of this manual.
5.1 BGP Overview

Border Gateway Protocol (BGP) is a dynamic inter-AS route discovery protocol.
Three early versions of BGP are BGP-1 (RFC1105), BGP-2 (RFC1163) and BGP-3
(RFC1267). The current version in use is BGP-4 (RFC1771). BGP-4 applies to
distributed structure and supports CIDR (Classless Inter-Domain Routing). BGP also
helps to implement user-configured policies. BGP-4 is becoming the Internet exterior
routing protocol standard and is commonly used between ISPs.
The characteristics of BGP are as follows:
z BGP is an external gateway routing protocol. Different from internal gateway
routing protocols such as OSPF and RIP, it focuses on the control of route
propagation and the selection of optimal routes rather than the discovery and
calculation of routes.
z Eliminating routing loops completely by adding AS path information to BGP routes.
z Using TCP as its transport layer protocol so as to enhance its reliability.
z BGP-4 supports CIDR, which is a major improvement over BGP-3. With a
brand-new perspective of IP address, networks are no longer distinguished as
Class-A networks, Class-B networks, or Class-C networks in CIDR. For example,
by means of CIDR notation, an illegal Class-C network address 192.213.0.0
(255.255.0.0) turns into 192.213.0.0/16, a legal super network address, wherein
the “/16” indicates that the subnet mask is composed of 16 bits starting from the
left most bit of the address. The introduction of CIDR simplifies route aggregation.
Actually, route aggregation is the process of aggregating several different routes,
which turns advertisement processes of several routes into the advertisement of
single route so as to reduce the size of the routing tables.
z When routes are updated, BGP only advertises updated routes, which greatly
reduces bandwidth occupation. It applies to advertising a great amount of routing
information on the Internet.
5-1
z In consideration of management and security, users desire to perform control over

outgoing and incoming routing information of each AS. BGP-4 provides abundant
routing policies, allowing implementing flexible filtering and route selection and
being extended easily to support new developments of the networks.
BGP runs on a special router as an upper-layer protocol. On the initial startup of the
BGP system, the BGP router exchanges routing information with its peers by
advertising the full BGP routing table, and after that only update messages are
exchanged. While in operation, the system sends and receives keep-alive messages to
check the correctness of the connections between peers.
A router advertising BGP messages is called a BGP speaker. It receives and generates
new routing information continuously and advertises the information to the other BGP
speakers. When a BGP speaker receives a new route advertisement from another AS,
it will advertise the route, if the route is better than the current route that has been
learned or is a new route, to all the other BGP speakers in the AS. A BGP speaker calls
other BGP speakers peers that exchange information with it, and multiple related peers
form a peer group.
BGP runs on a router in one of the following two modes:
z IBGP (Internal BGP)
z EBGP (External BGP)
The BGP is called IBGP when it runs within an AS and is called EBGP when it runs
between ASs.
The operation of BGP is driven by messages of the following four types:
z Open message
z Update message
z Notification message
z Keep-alive message
The Open message is the first message sent after a connection is created; it is used to
create the connection relationship between BGP peers. The Notification message is
used to notify errors. The Keep-alive message is used to check the validity of a
connection. The Update message is the most important information in a BGP system,
which is used to exchange routing information between peers. It is composed of up to
three parts: unreachable route, path attributes and network layer reach/reachable
information (NLRI).
5.2 BGP Configuration

The BGP configuration includes:
z Enable BGP
z Configure the network routes for BGP to advertise
z Configure a BGP peer/peer group
z Configure BGP timer
5-2
z Configure the local preference

z Configure MED for AS
z Compare MED Routing Costs from the Peers in Different ASs
z Configure BGP community
z Configure BGP route aggregation
z Configure the BGP preference
z Configure BGP route reflector
z Configure BGP AS confederation attribute
z Configure BGP route dampening
z Configure the interaction between BGP and IGP
z Configure BGP route filtering
z Define ACL, AS path list and route-policy
z Configure BGP load balancing
z Reset BGP connection
5.2.1 Enabling BGP
To enable BGP, you must specify the local AS number. After BGP is enabled, the
firewall listens to BGP connection requests from adjacent routers. To make the firewall
send BGP connection requests to adjacent routers, refer to the peer command. When
BGP is disabled, all established BGP connections are disconnected.
Table 5-1 Enable/disable BGP
Operation Command
Enable BGP and enter the BGP view bgp as-number
Disable BGP undo bgp [ as-number ]
By default, BGP is disabled.
5.2.2 Configuring the Network Routes for BGP to Advertise
Perform the following configuration in BGP view.
Table 5-2 Configure the network routes for BGP to advertise
Operation Command
Configure the network routes for BGP to network ip-address address-mask
advertise [ route-policy route-policy-name ]
undo network ip-address

Cancel the network routes for BGP to
address-mask [ route-policy
advertise
route-policy-name ]
5-3
By default, no network is advertised by the local BGP system.

When using the network command to advertise the network, there must be the
accurately matched route to this network in the routing table. For example, to advertise
the network 172.16.1.0/24 to BGP peer, you must execute the network 172.16.1.0
255.255.255.0 command. In addition, there must be a matched route to 172.16.1.0/24
in the routing table.
5.2.3 Configuring a BGP Peer/Peer Group
The BGP speakers who exchange BGP packets form peer relationship. A BGP peer
cannot exist independently from its peer group. In other words, a peer must belong to a
specific peer group. To configure a BGP peer, you must first configure a peer group and
then add the peer into the peer group.
In case of any change in the configuration of the group, the configuration of each group
member changes accordingly. However, you may configure certain attributes for a
certain member by designating its IP address, making the member not affected by the
group configuration in terms of these attributes.
I. Configuring a peer group
Before configuring a BGP peer, you must first configure the peer group that the peer
belongs to.
Table 5-3 Configure a peer group
Operation Command
Create a peer group group group-name [internal] | external
Delete the specified peer group Undo group group-name
When configuring a peer group, you need to specify the type of the peer group. All
members of an internal peer group are IBGP peers; while members of an external peer
group are EBGP peers or confederation EBGP peers.
By default, a peer group is internal.
II. Specifying the AS number of a peer group
You can specify an AS number for an external peer group. An internal peer group do
not need to be configured with an AS number. After a peer group is configured with an
AS number, all peers added into the peer group inherit the AS number of the peer
group.
5-4
Table 5-4 Specify an AS number for a peer group
Operation Command
peer group-name as-number
Specify an AS number for a peer group
as-number
Delete the specified AS number of the undo peer group-name as-number
peer group as-number
You cannot specify an AS number for a peer group with members. When the AS
number of a peer group is deleted, all peers in the peer group also are deleted.
III. Adding a peer into a peer group
A BGP peer cannot exist independently from its peer group. Therefore, to configure a
peer, you must specify the peer group it belongs to. You can also specify its AS number
at the same time.
Table 5-5 Add a peer into a peer group
Operation Command
peer peer-address group group-name
Create a peer in a peer group
[as-number as-number]
Delete a peer from a peer group undo peer peer-address
In the case of an internal peer group, you cannot specify the AS number, and the added
peer is an IBGP peer.
In the case of an external peer group, if it is not specified with an AS number, you must
specify an AS number for the peer to be added into it; if it has been configured with an
AS number, the peer will inherit its AS number and no AS number is necessary to be
specified for the peer.
IV. Configuring a description for a peer/peer group
In order to help understand the characteristics of a peer/peer group, you can configure
a description for the peer/peer group.
Table 5-6 Configure a description for a peer/peer group
Operation Command
Configure a description for a peer/peer peer { peer-address | group-name }
group description description-line
Delete the description of a peer/peer undo peer { peer-address |
group group-name } description
5-5
By default, no BGP peer/peer group description is set.
V. Connecting with EBGP peer groups on indirectly connected networks
Generally, EBGP peers must be connected physically, or the command below can be
used to perform the configuration.
Table 5-7 Connect with EBGP peer groups on indirectly connected networks
Operation Command
Configure to permit connections with
EBGP peer groups on indirectly peer group-name ebgp-max-hop [ ttl ]
connected networks
Configure to permit connections with
EBGP peer groups on directly undo peer group-name ebgp-max-hop
connected networks only
By default, it is only permitted to establish connections with peer groups on directly

connected networks. ttl represents the maximum hop count, ranging from 1 to 255. By
default, it is 64.
VI. Configuring the timer of a specified peer/peer group
The peer timer command is used to configure the timer of a specified BGP peer/peer
group, including the keep-alive message interval and the hold timer. The preference of
this command is higher than the timer command that is used to configure timers for all
the BGP peers.
Table 5-8 Configure the timer of a peer/peer group
Operation Command
peer { group-name | peer-address }
Configure the keep-alive interval and
timer keep-alive keepalive-interval
hold timer of a specified peer/peer group
hold holdtime-interval
Restore the default keep-alive interval
undo peer { group-name |
and hold timer of a specified peer/peer
peer-address } timer
group
By default, the keep-alive message is sent every 60 seconds and the value of the hold
timer is 180 seconds.
5-6
VII. Configuring the interval at which route updates are sent by a peer group
Table 5-9 Configure the interval at which route updates are sent to a peer group
Operation Command
Configure the interval at which route peer group-name
updates are sent to a peer group route-update-interval seconds
Restore the default route update undo peer group-name
sending interval to a peer group route-update-interval
By default, the intervals at which route updates are sent to an IBGP and EBGP peer
group are 5 seconds and 30 seconds respectively.
VIII. Configuring to send community attributes to a peer group
Table 5-10 Configure to send community attributes to a peer group
Operation Command
Configure to send community attributes peer group-name
to a peer group advertise-community
Not to send community attributes to a undo peer group-name
peer group advertise-community
IX. Configuring a peer group to be a route reflector client
Table 5-11 Configure a peer group to be a route reflector client
Operation Command
Configure a peer group to be a route
peer group-name reflect-client
reflector client
Disable a peer group from being a route
undo peer group-name reflect-client
reflector client
Only internal peer groups can be configured to be a reflector client.

By default, all IBGP peers in the AS are fully-connected and do not mutually notify IBGP
routes learned so as to avoid creating routing loops.
For detailed information on route reflector, refer to "Configure Route Reflector" section
of this manual.
5-7
X. Configuring to send the default route to a peer group
Table 5-12 Configure to send the default route to a peer group
Operation Command
Configure to send the default route to a peer group-name
peer group default-route-advertise
Disable sending of the default route to a undo peer group-name
peer group default-route-advertise
By default, the firewall does not send the default route to any peer. This command does
not require that the default route exist in the BGP routing table. Rather, it
unconditionally sends a default route with the next-hop being itself to the peer.
XI. Configuring to take the local address as the next-hop in advertising route
A BGP router can specify itself as the next hop while advertising a route to a peer
group.
Table 5-13 Configure to take the local address as the next-hop in advertising a route
Operation Command
Configure itself as the next hop in
peer group-name next-hop-local
advertising a route
Disable itself from being the next hop in
undo peer group-name next-hop-local
advertising a route
By default, the firewall does not take its address as the next-hop, when it advertises
route learnt from EBGP peer group to an IBGP peer group.
XII. Configuring not to carry private AS numbers in forwarding BGP updates
Generally speaking, BGP carries AS numbers (either public or private) when it forwards
updates. In order for some egress routers to ignore private AS numbers while sending
updates, you can configure to make them carry no private AS numbers when
forwarding BGP updates.
Table 5-14 Configure not to carry private AS numbers in forwarding BGP updates
Operation Command
Configure not to carry private AS
peer group-name public-as-only
numbers in forwarding BGP updates
Configure to carry private AS number in
undo peer group-name public-as-only
forwarding BGP updates
By default, AS numbers are carried when BGP updates are forwarded.
5-8
XIII. Specifying the source interface for route updates
For updates to be forwarded in case the interface for them experiences a failure, you
can configure to enable the internal BGP session to use any interface on which a TCP
connection can be established with the peer. The Loopback interface is usually used for
the purpose.
Table 5-15 Configure the source interface for route updates
Operation Command
peer { peer-address | group-name }
Configure the source interface for route
connect-interface interface-type
updates
interface-number
Disable the source interface for route undo peer { peer-address |
updates group-name } connect-interface
By default, BGP employs the optimal source interface for route updates.
XIV. Enabling/disabling a peer/peer group
A BGP speaker does not exchange routing information with a disabled peer or peer
group.
Table 5-16 Enable/disable a peer/peer group
Operation Command
Enable a peer/peer group peer { group-name | peer-address } enable
Disable a peer/peer group undo peer { group-name | peer-address } enable
By default, a peer or peer group is enabled.
XV. Enabling MD5 authentication for BGP
TCP connections are necessary for BGP peers/peer groups. To improve BGP security,
you can configure BGP to perform MD5 authentication before setting up a TCP
connection. A TCP connection will not be set up unless the authentication succeeds.
The MD5 authentication does not authenticate BGP packets; it only sets an MD5
authentication password for the TCP connection. The authentication is carried out by
TCP.
5-9
Table 5-17 Enable MD5 authentication for BGP
Operation Command
Enable MD5 authentication for a BGP peer { group-name | peer-address }
peer (group) password { cipher | simple } password
Disable MD5 authentication
peer-address } password
By default, MD5 authentication is disabled.

The MD5 authentication command can be configured in either BGP view or MBGP
VPN-instance address family view. When configured in the BGP view, this command is
also in effect for MBGP multicast expansion and MBGP VPN expansion because all of
them share the same TCP connection.
XVI. Disabling a BGP peer/peer group to initiate or receive BGP connection
Table 5-18 Disable a BGP peer/peer group to initiate or receive BGP connection
Operation Command
Disable the specified BGP peer/peer group to peer { group-name |
initiate or receive BGP connection peer-address } shutdown
undo peer {group-name |
Restore the default
peer-address } shutdown
By default, the BGP peer/peer group is allowed to initiate and receive BGP connection.
5.2.4 Configuring Routing Policy for BGP Peer/Peer Group
I. Configuring a routing policy for a peer/peer group
The peers in a peer group must use the same outbound route update policy as the peer
group, but they can have different inbound policies. In other words, when advertising
routes, a peer group follows the same policy; when receiving routes, each peer in the
group can choose its own policy.
Table 5-19 Configure a routing policy for a peer/peer group
Operation Command
Configure to apply a routing policy to peer { group-name | peer-address }
routes received from a peer/peer group route-policy policy-name import
Cancel the routing policy applied to
peer-address } route-policy
routes received from a peer/peer group
policy-name import
5-10
Operation Command
Configure to apply a routing policy to peer group-name route-policy
routes advertised to a peer group policy-name export
Cancel the routing policy applied to undo peer group-name route-policy
routes advertised to a peer/peer group policy-name export
By default, no routing policy is applied to routes advertised or received.
II. Configuring a route filtering policy based on IP ACL
Table 5-20 Configure a route filtering policy based on IP ACL
Operation Command
Configure to apply an IP ACL-based
route filtering policy to routes received
filter-policy acl-number import
from a peer/peer group
Cancel the IP ACL-based route filtering undo peer { group-name |
policy applied to routes received from a peer-address } filter-policy acl-number
peer/peer group import
Configure to apply an IP ACL-based
peer group-name filter-policy
route filtering policy to routes advertised
acl-number export
to a peer group
Cancel the IP ACL-based route filtering
undo peer group-name filter-policy
policy applied to routes advertised to a
acl-number export
peer/peer group
By default, no route filtering policy based on IP ACL is applied to routes advertised or

received.
III. Configuring a route filtering policy based on AS path ACL
Table 5-21 Configure a route filtering policy based on AS path ACL
Operation Command
Configure to apply an AS path
ACL-based route filtering policy to
as-path-acl number import
Cancel the AS path ACL-based route undo peer { group-name |
filtering policy applied to routes received peer-address } as-path-acl number
from a peer/peer group import
Configure to apply an AS path
peer group-name as-path-acl number
ACL-based route filtering policy to
export
routes advertised to a peer group
5-11
Operation Command
Cancel the AS path ACL-based route
undo peer group-name as-path-acl
filtering policy applied to routes
number export
advertised to a peer/peer group
By default, no route filtering policy based on AS path ACL is applied to routes

advertised or received.
IV. Configuring a route filtering policy based on address prefixes
Table 5-22 Configure a route filtering policy based on address prefixes
Operation Command
Configure to apply an address
prefixes-based route filtering policy to
ip-prefix prefixname import
Cancel the address prefixes-based undo peer { group-name |
route filtering policy applied to routes peer-address } ip-prefix prefixname
received from a peer/peer group import
Configure to apply an address
peer group-name ip-prefix prefixname
prefixes-based route filtering policy to
export
routes advertised to a peer group
Cancel the address prefixes-based
undo peer group-name ip-prefix
route filtering policy applied to routes
prefixname export
advertised to a peer/peer group
By default, no route filtering policy based on address prefixes is applied to routes

advertised or received.
5.2.5 Removing the Route Synchronization between IGP and IBGP
Table 5-23 Removing the route synchronization between IGP and IBGP
Operation Command
Removing the route synchronization
undo synchronization
between IGP and IBGP
5.2.6 Configuring BGP Timers
After a BGP connection is established between peers, each peer periodically sends
Keepalive message to the other so as to avoid the routers from assuming that the BGP
connection is down. If a router does not receive any Keepalive message or any kind of
5-12
packet from the peer within the specified Holdtime, it assumes that the BGP connection
is down and processes the routes received from the BGP connection accordingly.
Therefore, the interval for sending a Keepalive message and the BGP connection
Holdtime are two important parameters in BGP mechanism.
When a BGP router tries to establish a BGP connection with its peer, a negotiation
needs to be carried out on the Holdtime. The resulting Holdtime is the smaller one
those for the peers. If the resulting Holdtime is 0, no keepalive message will be
transmitted and no detection on whether the Holdtime is timed out will be performed.
Table 5-24 Configure BGP timers
Operation Command
timer keepalive keepalive-interval hold
Configure BGP timers
holdtime-interval
Restore the default values of the timers undo timer
The reasonable minimum Hold-time for sending keepalive messages is third times of
the interval. If the Holdtime is not configured as 0, it is 3 seconds at least.
By default, the interval for sending keepalive messages is 60 seconds and the Holdtime
is 180 seconds.
5.2.7 Configuring the Local Preference Attribute
Different local preferences can be configured to affect the BGP routing. When a router
running BGP gets routes with the same destination address but different next hops
through different IBGP peers, it selects the route with the highest local preference.
Table 5-25 Configure the local preference attribute
Operation Command
Configure the local preference attribute default local-preference value
Restore the default local preference value undo default local-preference
The local preference attribute is transmitted only when IBGP peers exchange update
packets and is not transmitted beyond the local AS.
By default, the local preference is 100.
5-13
Note:
Only after the configuration of the default local preference can you trigger BGP to select
the optimal route again when receiving and sending routes. You can execute refresh
bgp all import or reset bgp all command to select the optimal route again or
immediately.
5.2.8 Configuring the MED Attribute for an AS
The multi-exit discriminator (MED) attribute is the external routing cost of the routes.
They are exchanged among ASs. However, a MED entering an AS will no longer be
sent out of the AS.
Local preference is used to select the route for going out of an AS; while the MED
attribute is used to judge the optimal route for entering an AS. When a BGP router
receives multiple routes with the same destination address but different next-hops from
different EBGP, it will opt for the one with the smallest MED value as its optimal route
under the premise that the other conditions are the same.
Table 5-26 Configure an MED for the system
Operation Command
Configure a MED for the system default med med-value
Restore the default MED of the system undo default med
The above configuration compares only the MED values of routes from different EBGP
peers in the same AS. If you hope to compare the MED values of routes from different
EBGP peers in different ASs, configure the compare-different-as-med command.
By default, the value of the MED attribute is 0.
5.2.9 Comparing the MED Values of Routes from Peers in Different ASs
It is used to select the optimal route. When the other conditions are the same, the route
with the smallest MED value will be selected as the outgoing route of the AS.
Table 5-27 Compare the MED values of routes from peers in different ASs
Operation Command
Compare the MED values of routes from
compare-different-as-med
peers in different ASs
5-14
Operation Command
Disable the comparison of the MED values
Undo compare-different-as-med
of routes from peers in different ASs
By default, it is not allowed to compare the MED values of routes from peers in different
ASs.
You are not recommended to use this configuration unless you are sure that the ASs
are using the same IGP protocol and the same routing method.
5.2.10 Configuring the BGP Community Attributes
The community attributes are optional and transitional. Some of them are accepted all
around the world, called as standard community attributes; others are used for special
purposes. You can also define extended community attributes.
Community lists, including standard-community-lists and extended-community-lists,
are lists identifying information of communities.
In addition, a route can have more than one community attributes. The speakers of
multiple community attributes of a route can operate according to one, several or all the
attributes. A firewall can choose to change the community attributes or leave them
unchanged before advertising the route to its peers.
Table 5-28 Configure the community attributes
Operation Command
ip community-list standard-community-list-number
Configure a { permit | deny } [ aa:nn ] [ internet ]
standard-community-list [ no-export-subconfed ] [ no-advertise ]
[ no-export ]
Configure an ip community-list extended-community-list-number
extended-community-list { permit | deny } as-regular-expression
undo ip community-list
Remove the configured
{ standard-community-list-number |
community list
extended-community-list-number }
By default, no BGP community attribute is configured.

The standard-community-list-number argument takes a value in the range 1 to 99; the
extended-community-list-number argument takes a value in the range 100 to 199.
5-15
5.2.11 Configuring BGP Route Aggregation
BGP supports Classless Inter-Domain Routing (CIDR) and route aggregation. There
are two modes of BGP route aggregation: summary and aggregate. The former is to
aggregate the IGP subnet routes redistributed by BGP. After summary is configured,
BGP cannot receive subnet routes redistributed from IGP. The aggregate mode is to
aggregate the local BGP routes. A series of parameters can be configured in the
aggregate mode. In general, the preference of the aggregate mode is higher than that
of the summary mode.
Table 5-29 Configure BGP route aggregation
Operation Command
Configure the subnet routes
summary
automatic summary function
Cancel the subnet routes
undo summary
automatic summary function
aggregate address mask [ as-set ]

[ detail-suppressed ] [ suppress-policy
Configure the local route
route-policy-name ] [ origin-policy
aggregation function
route-policy-name ] [ attribute-policy
route-policy-name ]
undo aggregate address mask [ as-set ]
Cancel the local route [ detail-suppressed ] [ suppress-policy
aggregation function route-policy-name ] [ origin-policy
route-policy-name ] [ attribute-policy policy-name ]
By default, BGP does not aggregate subnet routes and local routes.
5.2.12 Configuring the BGP Preference
Each routing protocol has its own preference, by which the routing policy will select the
optimal one from the routes of different protocols. The greater the preference value is,
the lower the preference becomes. BGP has three kinds of routes: routes learned from
external peers, routes learned from internal peers, and the local routes. You can
manually set BGP preferences for these three kinds of routes respectively.
Different sub-address families can be set with different BGP preferences. Both unicast
address family and multicast address family are supported currently.
5-16
Table 5-30 Configure the BGP preference
Operation Command
Configure the BGP preference preference value1 value2 value3
Restore the default preference values undo preference
Where value1 is for routes learned from EBGP peers, value2 is for routes learned from
IBGP peers, and value3 is for local routes. They can be in the range 1 to 256.
By default, value1, value2, value3 are 256, 256, and 130 respectively.
5.2.13 Configuring the BGP Route Reflector
To ensure the connectivity between IBGP peers, it is necessary to establish a fully

connected network. In some networks, there are large numbers of IBGP peers, and the
internal BGP networks become very large, consequently, the cost to establish a fully
meshed network is very high. Thus, it is required to utilize new peer technology. The
basic idea behind the route reflector conception is to specify a centralized router as the
focus of the internal sessions. Multiple BGP routers can peer one central point, and
then multiple route reflectors will peer again.
The route reflector is the centralized point of other routers, and other routers are called
the clients. A client and the route reflector are peers. They exchange routing
information with each other. The route reflector transfers (reflect) information among
clients in turn.
In the following figure, SecPath A receives an update message from an external peer
and transmits it to SecPath C. SecPath C is configured as the route reflector, with two
clients, SecPath A and SecPath B.
SecPath C reflects the update message from the client SecPath A to the client SecPath
B. Under this configuration, no peer session between SecPath A and SecPath B is
virtually needed because the router reflector will transmit the BGP information to
SecPath B.
5-17
SecPath C
Route reflector
Reflected route
Update route
SecPath A SecPath B
EBGP
EBGP
Figure 5-1 Route reflector
A reflector is a router that performs the route reflection function. Its peers fall into two
categories: clients and non-clients. A route reflector and its clients constitute a cluster,
while all other peers in the AS, not belonging to the cluster, are non-clients. Use the
peer reflect-client command to specify the route reflector and add its clients.
The non-client peers and the route reflector must forms a fully connected network
because they have to follow the basic IBGP peer connectivity principle. A client can not
form peer relationship with any IBGP router outside its cluster. The route reflection
function is implemented by the route reflector, and all its client peers and non-client
peers are regular BGP peers that have no relation to the reflection function. The client
peers are clients just because the route reflector regards them as clients.
I. Configuring route reflection between clients
Table 5-31 Configure route reflection between clients
Operation Command
Enable route reflection between clients reflect between-clients
Disable route reflection between clients undo reflect between-clients
By default, route reflection between clients is enabled.
II. Configuring the route reflector
Generally speaking, there is a route reflector in a cluster, whose ID identifies the

cluster.
5-18
Table 5-32 Configure the cluster ID of the route reflector
Operation Command
reflector cluster-id { cluster-id |
Configure the cluster ID of the route reflector
address }
Cancel the cluster ID of the route reflector undo reflector cluster-id
III. Two measures to avoid loops inside an AS
With the introduction of the route reflector, routing loops might occur in the AS. An
update message originated from the cluster may attempt to return to the cluster. The
conventional AS path method cannot detect an internal loop in the AS because the
update message has not left the AS. With a route reflector configured, you can use the
following measures to avoid internal loops in the AS:
1) Configuring the Originator_ID of the route reflector
If the Originator_ID is wrongly configured, the update message will be returned to the
originator, and the originator will discard it.
This parameter needs no manual configuration, and it is enabled automatically with
BGP.
2) Configuring the Cluster_ID of the route reflector
5.2.14 Configuring BGP AS Confederation Attribute
Confederation provides another solution to handle the booming IBGP network

connections inside an AS. It divides an AS into multiple sub-ASs, with the IBGP peers
inside each sub-AS fully connected and connecting to other sub-ASs in the
confederation.
The shortcomings of confederation lie in: it is required that the router be reconfigured
upon switching from non-confederation to confederation solution, and that the logic
topology be basically changed. Furthermore, the path selected via confederation may
be sub-optimal path if there is no manually-set BGP policy.
I. Configuring confederation ID
In the sight of the BGP speakers that are not included in the confederation, multiple
sub-ASs that belong to the same confederation are a whole. The external network does
not need to know the status of internal sub-ASs, and the confederation ID is the AS
number identifying the confederation as a whole.
5-19
Table 5-33 Configure confederation ID
Operation Command
Configure confederation ID confederation id as-number
Cancel confederation ID undo confederation id
By default, the confederation ID is not configured.

The configured confederation ID cannot be the same as the existing AS number of a
peer or a peer group.
II. Configuring the sub-ASs belonging to a confederation
Configure confederation ID first, and then configure the sub-AS belonging to the
confederation. One confederation includes up to 32 sub-ASs. The as-number used
upon configuring sub-AS belonging to the confederation is valid within the
confederation.
Table 5-34 Configure the sub-ASs belonging to a confederation
Operation Command
Configure the sub-ASs belonging to a confederation peer-as as-number-1
confederation [ ... as-number-n ]
Cancel the specified sub-AS in the undo confederation peer-as
confederation [ as-number-1 ] [ ...as-number-n ]
By default, no sub-AS is configured as a member of the confederation.

The configured confederation sub-AS number cannot be the same as the AS number of
a certain peer who is not configured with peer group AS number.
III. Configuring AS confederation attribute compatible with nonstandard router
If it is necessary to interwork with routers whose implementation mechanisms are

different from RFC1965, you should configure all these routers in the confederation.
Table 5-35 Configure AS confederation attribute compatible with nonstandard router
Operation Command
Configure AS confederation attribute
confederation nonstandard
compatible with nonstandard router
Cancel AS confederation attribute
undo confederation nonstandard
compatible with nonstandard router
5-20
By default, the configured confederation complies with RFC1965.
5.2.15 Configuring BGP Route Dampening
The main possible reason for unstable route is the intermittent disappearance and
reemergence of the route that formerly existed in the routing table. This situation is
called the flapping. When flapping occurs, update packet will be propagated on the
network repeatedly, which will occupy much bandwidth and much processing time of
the router. We have to find measures to avoid it. The technology controlling unstable
route is called route dampening.
The dampening divides the route into the stable route and unstable route, the latter of
which shall be suppressed (not to be advertised). The history performance of the route
is the basis to evaluate the future stability. When the route flapping occurs, penalty will
be given, and when the penalty reaches a specific threshold, the route will be
suppressed. With time going, the penalty value will decrease according to power
function, and when it decreases to certain specific threshold, the route suppression will
be eliminated and the route will be re-advertised.
Table 5-36 Configure BGP route dampening
Operation Command
dampening [ half-life-reachable
half-life-unreachable reuse suppress
Configure BGP route dampening
ceiling ] [ route-policy
route-policy-name ]
Clear route dampening information and
reset bgp dampening
eliminating the suppression of the route
[ network-address [ mask ] ]
(user view)
Cancel BGP route dampening undo dampening
By default, BGP route dampening is not configured.

It must be noted that the parameters in the command are interdependent. If one
parameter is configured, other parameters must be specified.
The dampening command dampens only the routes that are learned from EBGP peers
but not the IBGP routes.
5.2.16 Configuring the Interaction between BGP and IGP
BGP can transmit the internal network information of local AS to other AS. To achieve
the purpose, the network information about the internal system discovered by the
firewall via IGP routing protocol can be transmitted.
5-21
Table 5-37 Redistribute IGP routing information
Operation Command
import-route protocol [ process-id ]
Configure BGP to redistribute IGP
[ med med ] [ route-policy
routing information
route-policy-name ]
Disable BGP from redistributing IGP undo import-route protocol
routing information [ process-id ]
Redistribute the local default routes. default-route imported
Disable BGP from redistributing the local
undo default-route imported
default routes.
By default, BGP does not redistribute the route information of other protocol.
The specified and redistributed source route protocols can be direct, static, rip, ospf,
ospf-ase, and ospf-nssa.
For detailed description of routing information, refer to 6.2.1 “Configuring Route
Filtering”.
5.2.17 Configuring the Repeating Times of Local AS Number
This command can be used to configure the repeating times of local AS number.
Table 5-38 Configure the repeating times of AS-path
Operation Command
Configure the repeating times of local peer { group-name | peer-address }
AS number allow-as-loop [ number ]
Remove the repeating times of local AS undo peer { group-name |
number peer-address } allow-as-loop
By default, the value of the number argument is 3.
5.2.18 Defining ACL, AS Path List, and route-policy
ACL, AS path list, and route-policy can all be the conditions for BGP filtering.
I. Defining the ACL
Refer to "Firewall Configuration" in module "Security" of this manual.
II. Defining the AS path list
The routing information of the BGP includes an autonomous system path domain,
called AS path attributes The as-path-acl can be used to match with the autonomous
5-22
system path domain of the BGP routing information so as to filter the routing
information, which does not conform to the requirements. For the same list number, the
user can define multiple pieces of as-path-acl. In other words, a list number stands for
a group of AS path ACLs. Each AS path list is identified with digits.
Table 5-39 Configure AS path list
Operation Command
ip as-path-acl aspath-acl-number
Configure AS path list
{ permit | deny } as-regular-expression
Remove the defined AS path list undo ip as-path-acl aspath-acl-number
By default, no AS path list is defined.

During the matching, the relationship of F "Or" is available between the members
(acl-number) of the ACLs, i.e., when the routing information passes through one piece
of this group of lists, it means that the routing information has been filtered by this group
of as-path lists identified with this list number.
III. Defining a route-policy
Step 1: For route-policy definition, refer to 6.2.2 “Implementing Routing Policy by

route-policy”.
Step 2: For match-rule definition, refer to 6.2.2 “Implementing Routing Policy by
route-policy”.
Step 3: For definition of evaluation rules, refer to 6.2.2 “Implementing Routing Policy by
route-policy”.
5.2.19 Configuring BGP Route Filtering
I. Configuring BGP to filter the received routes

The routes received by the BGP can be filtered, and only those routes that meet the
certain conditions will be received by the BGP.
Table 5-40 Configure to filter the received routes
Operation Command
Configure to filter the received routes ip-prefix-name [ gateway
5-23
Operation Command
Cancel the filtering of the received
ip-prefix ip-prefix-name [ gateway
routes
For more details, refer to 6.2.1 “Configuring Route Filtering”.
II. Configuring BGP to filter the routes to be advertised
The routes advertised by BGP can be filtered, and only those routes that meet certain
conditions will be advertised by BGP.
Table 5-41 Configure to filter the routes to be advertised by BGP
Operation Command
Configure to filter the routes to be filter-policy { acl-number | ip-prefix
advertised by BGP ip-prefix-name } export [protocol ]
undo filter-policy acl-number |
Cancel the filtering of the routes to be
ip-prefix ip-prefix-name } export
advertised by BGP
[protocol ]
By default, BGP does not filter the received and advertised routing information.
You can choose the protocol parameter to filter routes redistributed from specified
routing protocols, which can be direct, static, RIP, OSPF, OSPF-ASE or OSPF-NSSA.
For more information, refer to 6.2.1 “Configuring Route Filtering”.
5.2.20 Resetting BGP Connection
After changing BGP policies or protocols, the user must reset the current BGP
connection so as to validate the new configuration.
Table 5-42 Reset BGP connection
Operation Command
Reset BGP connection between reset bgp peer-address [ vpn-instance
specified peers vpn-instance-name ]
reset bgp all [ vpn-instance
Reset all BGP connections
vpn-instance-name ]
Reset the BGP connections between all reset bgp group group-name
peers in a specified peer group [ vpn-instance vpn-instance-name ]
5-24
5.2.21 Configuring BGP Route Refreshing
After changing the configuration of BGP policy or protocol, users can use the refresh
function of BGP routing to enable the new configuration without reconfiguring the BGP
connection.
Table 5-43 Configure BGP route refreshing
Operation Command
refresh bgp { all | peer-address | group
Configure BGP route refreshing
group-name } { import | export }
5.3 Displaying and Debugging BGP

running of the BGP configuration, and to verify the effect of the configuration. Execute
debugging command in user view to debug BGP.
Table 5-44 Display and debug BGP
Operation Command
display bgp [ multicast | vpnv4 { all |
Display the routing information in the route-distinguisher route-distinguisher
BGP routing table | vpn-instance vpn-instance-name } ]
routing [ ip-address mask ]
Display the statistics of the routing route-distinguisher route-distinguisher
information in the BGP routing table | vpn-instance vpn-instance-name } ]
routing statistic
display ip as-path-acl
Display the BGP AS path information
[ aspath-acl-number ]
display ip community-list
Display community list information [ stand-comm-list-number |
ext-comm-list-number ]
route-distinguisher route-distinguisher
Display CIDR routes
| vpn-instance vpn-instance-name } ]
routing cidr
Display the routing information of the
routing community [ aa:nn ]
specified BGP community
[ no-export-subconfed ]
[ no-advertise ] [ no-export ]
[ whole-match ]
5-25
Operation Command
Display the routing information allowed
by the specified BGP community list
routing community-list
community-list-number [ whole-match ]
Display BGP dampened route display bgp routing dampened
Display the routing information the route-distinguisher route-distinguisher
specified BGP peer advertised or | vpn-instance vpn-instance-name }
received routing peer peer-address { advertised
| received }
display bgp [ multicast ] routing peer
Display information about the dampened
peer-address dampened [ statistic |
routes received from the specified peer
ip-address ]
Display the route information received route-distinguisher route-distinguisher
from the specified peer and matching | vpn-instance vpn-instance-name }
the specified regular expression. routing peer peer-address
regular-expression text
Display the routes matching with the route-distinguisher route-distinguisher
specified as-path-acl | vpn-instance vpn-instance-name } ]
routing as-path-acl aspath-acl-number
display bgp routing flap-info
[ regular-expression
Display route flapping statistics
as-regular-expression | as-path-acl
information
aspath-acl-number | address [ mask
[ longer-prefix-list ] ] ]
Display routes with different source ASs
| vpn-instance vpn-instance-name }
routing different-origin-as
Display peer information
peer [ [ peer-address ] verbose ]
Display the routing information that has route-distinguisher route-distinguisher
been configured | vpn-instance vpn-instance-name }
network
display bgp paths
Display AS path information
as-regular-expression
Display information about a peer group
group [ group-name ]
5-26
Operation Command
Display the AS path matching AS
regular expression
routing regular-expression
as-regular-expression
Display configured route-policy display route-policy
information [ route-policy-name ]
Enable to output BGP adjacent status
log-peer-change
Disable to output BGP adjacent status
undo log-peer-change
Enable/disable debugging of all BGP
[ undo ] debugging bgp all
information
Enable/disable debugging of BGP
[ undo ] debugging bgp event
events
Enable/disable debugging of normal
[ undo ] debugging bgp normal
BGP operation information
Enable/disable debugging of BGP [ undo ] debugging bgp keepalive
Keepalive packets [ receive | send ] [ verbose ]
Enable/disable debugging of MBGP [ undo ] debugging bgp mp-update
update packets [ receive | send ] [ verbose ]
Enable/disable debugging of BGP Open [ undo ] debugging bgp open [ receive
packets | send ] [ verbose ]
Enable/disable debugging of BGP [ undo ] debugging bgp packet
packets [ receive | send ] [ verbose ]
Enable/disable debugging of BGP route [ undo ] debugging bgp route-refresh
update packets [ receive | send ] [ verbose ]
Enable/disable debugging of BGP [ undo ] debugging bgp update
Update packets [ receive | send ] [ verbose ]
display bgp routing flap-info

Display the flapping information of all the [ regular-expression
routes as-regular-expression | as-path-acl
aspath-acl-number | address [ mask ] ]
Clear the route flapping information of
reset bgp peer-address flap-info
the destination address
5-27
5.4 BGP Configuration Example

5.4.1 Configuring the BGP AS Confederation Attribute
Caution:
The configuration examples here only give some commands related to the BGP
configuration.
In the following figure, the AS 100 is divided into 3 sub-ASs, namely 1001, 1002 and
1003. Configure EBGP, confederation EBGP and IBGP.
II. Network diagram
SecPathA SecPathB
AS100
AS1001
AS1002
172.68.10.1 172.68.10.2
Ethernet
172.68.10.3 SecPathD
172.68.1.1
156.10.1.1
172.68.1.2
SecPathC AS1003
156.10.1.2
SecPathE
AS200
Figure 5-2 Network diagram of configuring AS confederation
[H3C] bgp 1001
[H3C-bgp] confederation id 100
[H3C-bgp] confederation peer-as 1002 1003
5-28
[H3C-bgp] group confed1002 external

[H3C-bgp] peer confed1002 as-number 1002
[H3C-bgp] peer 172.68.10.2 group confed1002
[H3C] bgp 1002
[H3C] bgp 1003
[H3C-bgp] group ebgp200 external
[H3C-bgp] peer 156.10.1.2 group ebgp200 as-number 200
[H3C-bgp] group ibgp1003 internal
[H3C-bgp] peer 172.68.1.2 group ibgp1003
5.4.2 Configuring BGP Route Reflector
SecPath B receives an update packet passing by EBGP and forwards it to SecPath C.

SecPath C is configured as a route reflector with two clients: SecPath B and SecPath D.
SecPath B and SecPath D need no IBGP connection. When SecPath C receives route
update from SecPath B, it reflects that information to SecPath D, and vice versa.
5-29
II. Network diagram
3.3.3.3 SecPath C
Route reflector
Connected AS200
to1.0.0.0 AS100 193.1.1.1/24 194.1.1.1/24
Ethernet1/0/0
193.1.1.2/24 Ethernet1/0/0
IBGP IBGP
EBGP 194.1.1.2/24
Ethernet1/0/0 Ethernet2/0/0 Ethernet2/0/0
1.1.1.1 192.1.1.1/24 192.1.1.2/24 2.2.2.2 4.4.4.4
SecPath A SecPath B SecPathD
Client of the Client of the
route ref lector route reflector
Figure 5-3 Network diagram of configuring BGP route reflector
[H3C] bgp 100
[H3C-bgp] group ex external
[H3C–bgp] peer 192.1.1.2 group ex as-number 200
[H3C –bgp] network 1.0.0.0 255.0.0.0
[H3C] bgp 200
[H3C-bgp] peer 192.1.1.1 group ex as-number 100
[H3C-bgp] group in internal
[H3C-bgp] peer 193.1.1.1 group in
5-30

[H3C] bgp 200
[H3C-bgp] group rr internal
[H3C-bgp] reflect between-clients
[H3C-bgp] peer rr reflect-client
[H3C-bgp] peer 193.1.1.2 group rr
[H3C-bgp] peer 194.1.1.2 group rr
[H3C] bgp 200
Using the display bgp routing command on SecPath B, you can view that SecPath B
has learned that there is a network 1.0.0.0.
Using the display bgp routing command on SecPath D, you can view that SecPath D
has also learned that there is a network 1.0.0.0.
5.4.3 Configuring BGP Routing
This example illustrates how the administrator manages the routing via BGP attributes.
All gateways are configured with BGP, and IGP in AS200 adopts OSPF.
SecPath A resides in AS100, while SecPath B, SecPath C and SecPath D reside in
AS200. EBGP runs between SecPath A, SecPath B and SecPath C, while IBGP runs
between SecPath B, SecPath C and SecPath D.
5-31
II. Network diagram
network
2.0.0.0
SecPathB AS200
192.1.1.2/24 194.1.1.2/24 Ethernet1/0/0
Ethernet2/0/0 194.1.1.1/24
network 192.1.1.1/24 EBGP 2.2.2.2 IBGP
1.0.0.0 Ethernet2/0/0
195.1.1.1/24
SecPathA EBGP IBGP SecPathD
1.1.1.1 Ethernet1/0/0 4.4.4.4
193.1.1.1/24 Ethernet1/0/0 network
AS100 193.1.1.2/24 Ethernet2/0/0 4.0.0.0
195.1.1.2/24
SecPathC
3.3.3.3
network
3.0.0.0
Figure 5-4 Network diagram of configuring BGP routing
[H3C] bgp 100
[H3C-bgp] network 1.0.0.0
[H3C-bgp] group ex192 external
[H3C-bgp] peer 192.1.1.2 group ex192 as-number 200
[H3C-bgp] quit
# Configure the MED attribute for SecPath A.

# Add the ACL to SecPath A and enable the network 1.0.0.0.
[H3C-acl-basic-2001] rule permit source 1.0.0.0 0.255.255.255
# Define two route policies, one called apply_med_50 and the other called
apply_med_100. The MED attribute set by apply_med_50 for network 1.0.0.0 is 50,
while the MED attribute set by apply_med_100 is 100.
[H3C] route-policy apply_med_50 permit node 10
[H3C-route-policy] apply cost 50
5-32
# Apply “apply_med_50” to the egress route update of SecPath C (193.1.1.2), and

apply “apply_med_100” on the egress route update of SecPath B (192.1.1.2).
[H3C] bgp 100
[H3C-bgp] peer ex193 route-policy apply_med_50 export
[H3C] ospf
[H3C-ospf-1] area 0
[H3C] bgp 200
[H3C-bgp] undo synchronization
[H3C] ospf
[H3C-ospf-1] area 0
[H3C] bgp 200
5-33
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-osp-1f-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[H3C] bgp 200
[H3C-bgp] peer ex as-number 200
[H3C-bgp] peer 195.1.1.2 group ex
[H3C-bgp] peer 194.1.1.2 group ex
To enable the configuration, all BGP peers shall be reset using the reset bgp all
command.
After the above configuration, as the MED attribute of route 1.0.0.0 learned by SecPath
C is less than what learned by SecPath B, SecPath D prefers route 1.0.0.0 coming from
SecPath C.
If SecPath A is configured without MED, configure the local preference on SecPath C
as follows:
Add ACL 2001 to SecPath C and enable network 1.0.0.0
Define a route policy named “localpref”. Set the local preference matching ACL 2001 as
200, and that not matching the ACL as 100.
[H3C] route-policy localpref permit node 10
[H3C-route-policy] apply local-preference 200
[H3C] quit
Apply such route policy to the BGP peer 193.1.1.1 (SecPath A)

[H3C] bgp 200
[H3C-bgp] peer 193.1.1.1 route-policy localpref import
In this case, as the local preference of route 1.0.0.0 learned by SecPath C is 200,
bigger than what learned by SecPath B (SecPath B is not configured with any local
5-34
preference attribute and defaults to 100), SecPath D prefers route 1.0.0.0 coming from
SecPath C all the same.
5.5 Troubleshooting BGP

Symptom 1: The neighboring relationship cannot be established (The Established state
cannot be entered).
Troubleshooting:
The establishment of BGP neighborhood needs the router able to establish TCP
session through port 179 and exchange Open packets correctly. Perform the check
according to the following steps:
z Check whether the configuration of the neighbor's AS number is correct.
z Check whether the neighbor's IP address is correct.
z If using the loopback interface, check whether the connect-source loopback has
been configured. By default, the firewall uses the optimal local interface to
establish the TCP connection, rather than uses the loopback interface.
z If it is the EBGP neighbor not directly connected physically, check whether the
peer ebgp-max-hop has been configured.
z Use the ping command to check whether the TCP connection is normal. Since one
firewall may have several interfaces able to reach the peer, the extended ping -a
ip-address command should be used to specify the source IP address sending
ping packet.
z If the Ping operation fails, use display ip routing-table command to check if there
is available route in the routing table to the neighbor.
z If the Ping operation succeeds, check if there is an ACL denying TCP port 179. If
the ACL is configured, cancel the denying of port 179.
5.6 MBGP Overview

5.6.1 Introduction to MBGP
As described at the beginning of this chapter, BGP, as the practical exterior gateway
protocol, is widely used in interconnection between autonomous systems. The
traditional BGP-4 can only manage the routing information of IPv4 and has limitation in
inter-AS routing when used in the application of other network layer protocols (such as
IPv6 etc).
In order to support multiple network layer protocols, IETF extended BGP-4 and formed
MBGP (Multiprotocol Extensions for BGP-4, multiple protocols extension of BGP-4).
The present MBGP standard is RFC2858.
MBGP is compatible, that is, a router supporting BGP extension can be interconnected
with a router that does not support it.
5-35
5.6.2 MBGP Extension Attributes
In the packets BGP-4 uses, three pieces of information related to IPv4 are carried in the
update packet. They are NLRI (Network Layer Reachability Information), Next_Hop
(The next hop address) in path attribute and Aggregator in path attribute (This attribute
includes the BGP speaker address which forms the summary route).
The BGP speaker running on the Internet usually has an IPv4 address. Therefore, it is
only necessary for BGP-4 to reflect the information of the specified network layer
protocol to NLRI and the Next_Hop in the route attribute to implement supporting to
multiple network layer protocols.
Two new path attributes are introduced into MBGP:
z MP_REACH_NLRI: Multiprotocol Reachable NLRI. It is used to advertise
reachable routes and next-hop information.
z MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI. It is used to remove
unreachable routes.
These two attributes are optional non-transitive. Therefore, the BGP speaker that does
not provide multiple protocols ability will ignore the information of them nor transfer
them to other peers.
5.6.3 MBGP Applied on the Firewall
The firewall adopts address family to differentiate different network layer protocols. For
values of address family, refer to RFC1700.
The firewall provides various MBGP extended applications including extension of
multicast and BGP/MPLS VPN etc. Different extended applications should be
performed in their own address family views.
For MBGP applied in BGP/MPLS VPN, refer to "MPLS VPN" chapter in the MPLS part
of this manual.
5.7 MBGP Configuration

MBGP is the extension of BGP. Many concepts and configuration fundamentals of BGP
are also applicable in MBGP.
When configuring MBGP, it is necessary to run BGP before entering corresponding
address family view and configuring relevant parameters for different extended
applications.
When configuring the MBGP peer/peer group, configure the AS number of the
peer/peer group in BGP view first and then enter the corresponding address family view
to enable the peer/peer group relation of the application.
5-36
Part commands in BGP view also exist in MBGP address family view. However, when
configured in MBGP address family view, these commands are only effective to
corresponding applications.
Commands in MBGP address family view that are related to specific applications are
not described in this chapter. For corresponding contents, refer to the VPN part of this
manual.
MBGP versatile configuration includes:
z Configure the address family
z Enable the peer group
5.7.1 Configuring the Address Family
After MBGP is introduced, IPv4 unicast address family view sometimes is used to
indicate the normal BGP view.
Table 5-45 Configure the Address Family
Operation Command
Enter the MBGP multicast address
ipv4-family multicast
family view
Remove the MBGP multicast address
undo ipv4-family multicast
family configuration
Enter MBGP vpn-instance address ipv4-family vpn-instance
family view vpn-instance-name
Remove MBGP vpn instance address undo ipv4-family vpn-instance
family configuration vpn-instance-name
Enter MBGP VPNv4 address family view ipv4-family vpnv4 [ unicast ]
Remove MBGP VPNv4 address family
undo ipv4-family vpnv4 [ unicast ]
configuration
Execute the undo command to return to BGP view and delete corresponding MBGP
extended application configuration.
5.7.2 Enabling Peer/Peer Group
To enable BGP speakers to exchange routing information, it is necessary to activate a

certain peer group under unicast address family, and then add the peers existing under
the unicast address family into the activated peer group.
Perform the following configuration in address family view.
5-37
Table 5-46 Enable peer/peer group
Operation Command
Enable a specified peer group peer group-name enable
Disable a specified peer group undo peer group-name enable
Add peers into the enabled peer group peer peer-address group group-name
Delete peers from the enabled peer
undo peer peer-address
group
By default, only the peer group in the BGP IPv4 unicast address family is enabled; while
other kinds of peers or peer groups are disabled and cannot exchange routing
information.
5.8 MBGP Configuration Examples

MBGP is mainly applied to extension of some new services. Its configuration is similar
to BGP. The following examples in networking and configuration are the same with
those in the "BGP Typical Configuration Examples". The major difference lies in its
configurations of entering MBGP address family view and enabling MBGP peer.
For MBGP configuration in specific services, refer to the Multicast and MPLS part of
this manual.
5.8.1 Configuring MBGP Route Reflector
SecPath A, SecPath B, SecPath C and SecPath D have been configured with MBGP
multicast extended applications. SecPath A and SecPath B are EBGP peers. SecPath
C and SecPath B are IBGP peers, and SecPath C and SecPath D are IBGP peers
respectively.
SecPath B receives an EBGP update packet from SecPath A and transmits it to
SecPath C. SecPath C is configured as a route reflector, with two clients, SecPath B
and SecPath D. When SecPath C receives the EBGP update packet from SecPath B, it
reflects the information to SecPath D. IBGP connection needs not to be created
between SecPath B and SecPath D, for SecPath C will reflect information to SecPath
D.
5-38
II. Network diagram
3.3.3.3 SecPath C
Route reflector
Connected AS200
to1.0.0.0 AS100 193.1.1.1/24 194.1.1.1/24
Ethernet1/0/0
193.1.1.2/24 Ethernet1/0/0
IBGP IBGP
EBGP 194.1.1.2/24
Ethernet1/0/0 Ethernet2/0/0 Ethernet2/0/0
1.1.1.1 192.1.1.1/24 192.1.1.2/24 2.2.2.2 4.4.4.4
SecPath B SecPath D
SecPath A
Client of the Client of the
route reflector route reflector
Figure 5-5 Configure MBGP route reflector
# Configure the interface.
# Configure MBGP of SecPath A.

[H3C] bgp 100
[H3C-bgp] ipv4-family multicast
[H3C-bgp-af-mul] peer ex enable
[H3C-bgp-af-mu] peer 192.1.1.2 group ex
[H3C-bgp-af-mu] network 1.0.0.0 255.0.0.0
# Configure OSPF.
[H3C] ospf
[H3C-ospf-1] area 0
5-39

[H3C-ospf-1] quit
# Configure MBGP of SecPath B.

[H3C] bgp 200
[H3C-bgp] peer in next-hop-local
[H3C-bgp] import-route ospf
[H3C-bgp] import-route direct
[H3C-bgp-af-mul] peer in next-hop-local
[H3C-bgp-af-mul] peer ex enable
[H3C-bgp-af-mul] peer in enable
[H3C-bgp-af-mul] peer 192.1.1.1 group ex
[H3C-bgp-af-mul] peer 193.1.1.1 group in
# Configure OSPF.
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1] quit
# Configure MBGP of SecPath C.

[H3C] bgp 200
[H3C-bgp] peer in reflect-client
5-40

[H3C-bgp-af-mul] peer in reflect-client
# Configure OSPF.
[H3C] ospf
[H3C-ospf-1] area 0
[H3C-ospf-1] quit
# Configure MBGP of SecPath D.

[H3C] bgp 200
Use the display bgp multicast routing command on SecPath B to display the BGP
routing table. It should be noted that SecPath B has known the existence of the network
1.0.0.0.
Use the display bgp multicast routing command on SecPath D to view the BGP
routing table. It should be noted that SecPath D has known the existence of the network
1.0.0.0.
5-41
H3C SecPath Series Security Products Chapter 6 IP Routing Policy Configuration
Chapter 6 IP Routing Policy Configuration
6.1 IP Routing Policy Overview

When a firewall distributes or receives routing information, it possibly needs to
implement some policies to filter the routing information, so as to receive or distribute
the routing information which can meet the specified condition only. A routing protocol,
e.g. RIP, maybe need to redistribute the routing information discovered by other
protocols to enrich its routing knowledge. While redistributing the routing information, it
possibly only needs to redistribute the information meeting the conditions and set some
special attributes to make them meet its requirement.
To implement the routing policy, you need define a set of matching rules by specifying
the characteristics of the routing information in the routing policy under implementation.
You can set the rules based on such attributes as destination address and source
address of the information. The matching rules can be set in advance and then used in
the routing policy to advertise, receive and redistribute routes.
Five kinds of filters, namely route-policy, ACL, AS-path, community-list and IP-prefix,
are provided on a firewall for routing protocols to redistribute. The following will
introduce each kind of filter respectively.
I. route-policy
Routing policy is used for matching some attributes in given routing information and the
attributes of the information will be set if the conditions are satisfied.
A routing policy can comprise multiple nodes. Each node is a unit for matching test, and
the nodes will be matched on the basis of their node numbers. Each node comprises a
set of if-match and apply clauses. The if-match clauses define the matching rules.
The matching objects are some attributes of routing information. The different if-match
clauses on the same node is in logic AND relationship. Only when the matching
requirements specified by all the if-match clauses on a node are satisfied, can the
matching test on the node be passed. The apply clause specifies the actions
performed after the node matching test, concerning the attribute settings of the routing
information.
The different nodes of a route-policy is in logic OR relationship. The system will check
each node of route-policy one by one. Once the test on a route-policy node is passed, it
indicates the matching test of the route-policy is passed (the test on the next-node will
not proceed).
6-1
II. ACL
There are four kinds of ACLs: advanced ACL, basic ACL, interface-based ACL and
MAC address filtering table.
Normally, basic ACL and advanced ACL are adopted to filter routing information. If you
use the basic ACL, you must specify a range of IP addresses or subnets when defining
ACL so as to match the source address of routing information. If you use the advanced
ACL, you can specify protocol type, source/destination address or port number which
will be used for matching.
For ACL configuration, refer to the contents about Firewall Configuration in the security
part of this manual.
III. IP-prefix
The IP-prefix plays a role similar to ACL. But it is more flexible than ACL and easier to
understand. When IP-prefix is applied for filtering of routing information, its matching
object is the destination address information field of routing information. Moreover, for
IP-prefix, the user can specify the gateway option so as to indicate that only routing
information advertised by certain firewalls will be received.
An IP-prefix is identified by the ip-prefix name. Each IP-prefix can include multiple items,
and each item, which is identified by an index-number, can independently specify the
matching range of the network prefix forms. The index-number specifies the matching
sequence in the IP-prefix list.
During the matching, the firewall checks list items identified by the index-number in the
ascending order. If only one list item meets the condition, it means that it has passed
the IP-prefix filtering (will not enter the testing of the next list item).
IV. AS-path-acl
AS-path-acl only applies to BGP. In the BGP routing information packet, there is an
AS-path domain (During BGP routing information exchange, the AS path where routing
information passes will be recorded in the domain). As-path specifies matching
conditions according to the AS-path field.
The definition of the AS-path has already been implemented in the BGP configuration.
For the related configurations, please refer to the ip as-path-acl command in the
chapter BGP Configuration.
V. Community-list
The community-list only applies to BGP. The routing information packet of the BGP
includes a community attribute domain to identify a community. Targeting at the
community attribute, the community-list specifies the match condition.
For the relevant configurations of community-list, please refer to the ip community-list
command in the BGP Configuration.
6-2
6.2 Configuring IP Routing Policy

You can use two methods to implement the routing policy: use filtering lists such as
ACL, ip-prefix, as-path-acl, and community-list to directly filter routes or route attributes,
or configure route-policy to set route attributes meeting the matching conditions.
The following configurations are covered in this chapter:
I. Configuring route filtering
z Define IP prefix list or ACL

z Configure route filtering of received routes
z Redistribute routes from other routing protocols (for OSPF route filtering only)
z Configuring to filter distributed routes (redistributed routes for OSPF)
II. Configuring route-policy to implement routing policy
z Define a route-policy
z Define if-match clauses for a route-policy
z Define apply clauses for a route-policy
z Filter redistributed routes by a route-policy
For information about BGP route filtering by as-path-acl and community-list, refer to
Chapter 5 “BGP Configuration”.
6.2.1 Configuring Route Filtering
I. Defining filtering conditions
1) Defining IP Prefix List

An ip-prefix list is identified by the ip-prefix name. Each ip-prefix can include multiple
items, and each item can independently specify the matching range of the network
prefix forms. The index-number specifies the matching sequence in the ip-prefix list.
Table 6-1 Define IP prefix list
Operation Command
ip ip-prefix ip-prefix-name [ index index-number ]
Define IP prefix list { permit | deny } network len [ greater-equal
greater-equal | less-equal less-equal ]
undo ip ip-prefix ip-prefix-name [ index
Remove IP prefix list
index-number | permit | deny ]
During the matching, the firewall checks list items identified by the index-number in the
ascending order. If only one list item meets the condition, it means that it has passed
the ip-prefix filtering (will not enter the testing of the next list item).
6-3
Pay attention to the following:

z If more than one ip-prefix item are defined, then the match mode of at least one list
item should be the permit mode.
z The list items of the deny mode can be firstly defined to rapidly filter the routing
information not satisfying the requirement, but if all the items are in the deny mode,
any routes will not pass the ip-prefix filtering.
z You can define an item of permit 0.0.0.0/0 greater-equal 0 less-equal 32 after
the multiple list items in the deny mode so as to let all the other routes pass.
For instance, the following configuration will filter out routes from segments 10.1.0.0,
10.2.0.0, and 10.3.0.0, while allowing routing information from other segments to pass
through.
[H3C] ip ip-prefix 1 deny 10.1.0.0 16
[H3C] ip ip-prefix 1 permit 0.0.0.0 0 greater-equal 0 less-equal 32
2) Defining ACL
Refer to the part related to Security module of this manual.
II. Configuring to filter the received routes
Perform the following configuration in routing protocol view.

Define a policy rule to filter unqualified routing information during route reception by
redistributing an ACL or IP-prefix. The keyword parameter gateway indicates only
update packets from specific peer routers will be received.
Table 6-2 Configure to filter the redistributed routes
Operation Command
Configure to filter the received routing
filter-policy gateway ip-prefix-name
information redistributed by the specified
import
address
undo filter-policy gateway
routing information redistributed by the
ip-prefix-name import
specified address
Configure to filter the received global filter-policy { acl-number | ip-prefix
routing information ip-prefix-name [ gateway ] } import
ip-prefix ip-prefix-name [ gateway ] }
routing information
import
The filter-policy import command filters routes received from the routing protocol
(dependent on the protocol view where it resides), and prevents routing information
from being added to the route table. You cannot use this command on the router
6-4
redistributing routes to prevent the route redistributed from other routing protocols,
because this route entry has appeared in the route table.
For a link-state protocol, this command can only prevent route entries from being added
to the route table and cannot filter LSAs. Therefore related LSAs can be notified to the
neighbor.
For RIP and BGP, filtering occurs on routes from neighbors.
III. Redistributing Routing Information Discovered by Other Routing Protocols
A routing protocol can redistribute the routes discovered by other routing protocols to
enrich its route information. When other protocol routing information is to be
redistributed, the route-policy can be used for route information filtering to implement
the purposeful redistribution. If the destination routing protocol redistributing the routes
cannot directly reference the route costs of the source routing protocol, you should
satisfy the requirement of the protocol by specifying a route cost for the redistributed
route.
Table 6-3 Redistribute routes from other protocols
Operation Command
Set to redistribute routes from other import-route protocol [ med med | cost
protocols cost ] [ tag value ] [ type 1 | 2 ]
Cancel the setting for redistributing
routes of other protocols
By default, the routes discovered by other protocols will not be distributed.
Note:
In different routing protocol views, the parameter options are different. For details,
respectively refer to the import-route command in different protocols.
IV. Configuring to filter the distributed routes
Define a policy concerning route distribution to filter the routing information not
satisfying the conditions while redistributing routes by redistributing an ACL or address
ip-prefix list. Filter routing information only about the distributed routing-process by
specifying routing-process.
6-5
Table 6-4 Configure to filter the distributed routes
Operation Command
Configure to filter the routes filter-policy { acl-number | ip-prefix
distributed ip-prefix-name } export [ routing-process ]
Cancel the filtering of the routes undo filter-policy { acl-number | ip-prefix
distributed ip-prefix-name } export [ routing-process ]
For OSPF, the filter-policy export command filters the redistributed routes, and must
be used with the import-route command; otherwise, it takes no effect. By choosing the
routing-process parameter, you can specify to filter redistributed routes of a particular
type. If you do not specify the argument, the command will filter all redistributed routes.
For RIP and BGP, the filter-policy export command can filter the routing table without
the import-route command, It filters advertised routes in this situation.
By far, the routing policy supports redistributing the routes discovered by the following
protocols into the routing table:
z direct: The hop (or host) to which the local interface is directly connected.
z static: Static route.
z rip: Route discovered by RIP.
z ospf: Route discovered by OSPF.
z ospf-ase: External route discovered by OSPF.
z ospf-nssa: NSSA route discovered by OSPF.
z isis: Route discovered by IS-IS.
z bgp: Route acquired by BGP.
By default, the filtering of the redistributed and distributed routes will not be performed.
6.2.2 Implementing Routing Policy by route-policy
I. Defining a route-policy
A route-policy can comprise multiple nodes. Each node is a unit for matching operation.
The nodes are tested according to sequence-number.
Table 6-5 Define a route-policy
Operation Command
route-policy route-policy-name
Enter routing policy view
{ permit | deny } node node-number
undo route-policy route-policy-name

Remove the specified route-policy
[ permit | deny | node node-number ]
6-6
The argument permit specifies the matching mode for a defined node in the
route-policy to be in permit mode. If a route satisfies all the if-match clauses of the
node, it will pass the filtering of the node, and the apply clauses for the node will be
executed without taking the test of the next node. If not, however, the route should take
the test of the next node.
The deny argument specifies the matching mode for a defined node in the route-policy
to be in deny mode. In this mode, the apply clauses will not be executed. If a route
satisfies all the if-match clauses of the node, it will be denied by the node and will not
take the test of the next node. If not, however, the route will take the test of the next
node.
The nodes have the "OR" relationship. In other words, the firewall will test the route
against the nodes in the route-policy in sequence, once a node is matched, the
route-policy filtering will be passed.
By default, the route-policy is not defined.
Note: if multiple nodes are defined in a route-policy, at least one of them should be in
permit mode. Apply the route-policy to filter routing information. If the routing
information does not match any node, the routing information will be denied by the
route-policy. If all the nodes in the route-policy are in deny mode, all routing information
will be denied by the route-policy.
II. Defining if-match clauses for a route-policy
The if-match clauses define the matching rules. That is, the filtering conditions that the
routing information should satisfy for passing the route-policy. The matching objects are
some attributes of routing information.
Table 6-6 Define if-match conditions
Operation Command
Match the AS path domain of the BGP
if-match as-path aspath-acl-number
routing information
Cancel the matched AS path domain of
undo if-match as-path
the BGP routing information
if-match community
Match the community attribute of the { standard-community-number
BGP routing information [ whole-match ] |
extended-community-number }
Cancel the matched community attribute
undo if-match community
of the BGP routing information
Match the destination address of the if-match { acl acl-number | ip-prefix
routing information ip-prefix-name }
6-7
Operation Command
Cancel the matched destination address
undo if-match { acl | ip-prefix }
of the routing information
Match the next-hop interface of the if-match interface interface-type
routing information number
Cancel the matched next-hop interface
undo if-match interface
of the routing information
Match the next-hop of the routing if-match ip next-hop { acl acl-number |
information ip-prefix ip-prefix-name }
Cancel the matched next-hop of the
undo if-match ip next-hop [ ip-prefix ]
routing information
Match the routing cost of the routing
if-match cost value
information
Cancel the matched routing cost of the
undo if-match cost
routing information
Match the tag field of the OSPF routing
if-match tag value
information
Remove the tag field matching OSPF
undo if-match tag
routing information
By default, no matching will be performed.

Pay attention to the following:
z The if-match clauses for a node in the route-policy have the relationship of "AND"
for matching. That is, the route must satisfy all the clauses to match the node
before the actions specified by the apply clauses can be executed.
z If no if-match clauses are specified, all the routes will pass the filtering on the
node.
III. Defining apply clauses for a route-policy
The apply clauses specify actions, which are the configuration commands executed
after a route satisfies the filtering conditions specified by the if-match clauses. Thereby,
some attributes of the route can be modified.
Table 6-7 Define apply clauses
Operation Command
Add the specified AS number before the
apply as-path as-number-1
as-path series of the BGP routing
[ as-number-2 [ as-number-3 ... ] ]
information
6-8
Operation Command
Cancel the specified AS number added
before the as-path series of the BGP undo apply as-path
routing information
apply community { { aa:nn |

Set the community attribute in the BGP no-export-subconfed | no-advertise |
routing information no-export }… [ additive] | additive |
none }
Cancel the set community attribute in
undo apply community
the BGP routing information
Set the local preference of the BGP
apply local-preference localpref
routing information
Cancel the local preference of the BGP
undo apply local-preference
routing information
Set the routing cost of the routing
apply cost value
information
Cancel the routing cost of the routing
undo apply cost
information
Set the cost type of the routing
apply cost-type [ internal | external ]
information
Remove the setting of the cost type undo apply cost-type
Set the route origin of the BGP routing apply origin { igp | egp as-number |
information incomplete }
Cancel the route origin of the BGP
undo apply origin
routing information
Set the tag field of the OSPF routing
apply tag value
information
Cancel the tag field of the OSPF routing
undo apply tag
information
By default, no configuration is performed.

Please note that if the routing information meets the match conditions specified in the
route-policy and also notifies the MED value configured with apply cost-type internal
when notifying the IGP route to the EBGP peers, then this value will be regarded as the
MED value of the IGP route. The preference configured with the apply cost-type
internal is lower than that configured with the apply cost command, but higher than
that configured with the default med command.
IV. Applying route-policy
6-9
Table 6-8 Redistribute routes from other protocols
Operation Command
import-route protocol [ med med | cost
Configure to redistribute routes from
cost ] [ tag value ] [ type 1 | 2 ]
other protocols
route-policy route-policy-name
Disable redistributing routes from other
protocols
By default, routing information from other protocols is not redistributed.
Note:
Different routing protocol views include different optional parameters. For specific
information, refer to the description of the import-route command corresponding to the
routing protocol in the manual.
For BGP, you can also configure route-policy of the peer group to control routes
received from the peer/peer group or advertised to the peer group. Members of the
peer group cannot be configured with a outbound route update policy different from that
of the group, but can be configured with different inbound policies.
Table 6-9 Configure route-policy for a peer
Operation Command
peer { group-name |
Configure route-policy for a peer peer-address }route-policy
route-policy-name import
undo peer { group-name | peer-address }
Disable the route-policy of a peer
route-policy policy-name import
6.3 Displaying and Debugging the Routing Policy

running of the routing policy configuration, and to verify the effect of the configuration.
6-10
Table 6-10 Display and debug the routing policy
Operation Command
display route-policy
Display the routing-policy
[ route-policy-name ]
Display the path information of the AS display ip as-path-acl
filter in BGP [aspath-acl-number ]
Display the address prefix list
display ip ip-prefix [ ip-prefix-name ]
information
6.4 Routing Policy Configuration Example

6.4.1 Configuring to Import Routing Information of Other Protocols
This example shows how OSPF protocol imports RIP routing information selectively.
A firewall connects a campus network to an area network. The campus network uses
RIP as its internal routing protocol, and the area network uses OSPF routing protocol.
The firewall advertises some routing information of the campus network to the area
network. To achieve this function, the OSPF protocol on the firewall filters RIP routing
information by importing a route-policy. The route-policy comprises two nodes, making
OSPF protocol advertise the routing information of 192.1.0.0/24 and 128.2.0.0/16 at
different routing costs.
II. Network diagram
128.1.0.1
192.1.0.0/24
128.1.0.0/16
128.2.0.0/16 e0/0/0
SecPath
Campus netw ork Area netw ork
Figure 6-1 Network diagram of OSPF importing RIP routing information
# Define ip-prefix lists.

[H3C] ip ip-prefix p1 permit 192.1.0.0 24
# Configure a route-policy.
[H3C] route-policy r1 permit node 10
[H3C-route-policy] if-match ip-prefix p1
6-11
[H3C-route-policy] route-policy r1 permit node 20

[H3C-route-policy] if-match ip-prefix p2
# Configure the OSPF protocol. (To have OSPF to redistribute an RIP route
successfully, you need to make corresponding configurations on a security gateway to
configure RIP. The RIP configuration procedure is omitted here.)
[H3C] ospf
[H3C-ospf-1] area 0
[H3C -ospf-1-area-0.0.0.0] network 128.1.0.0 0.0.0.255
[H3C -ospf-1-area-0.0.0.0] quit
[H3C-ospf-1] import-route rip route-policy r1
[H3C-ospf-1] interface ethernet 0/0/0
6.4.2 Configuring to Filter the Advertised Routing Information
This example shows how RIP advertises routing information selectively.

A firewall connects campus network A to campus network B, both of which use RIP as
their internal routing protocol. The firewall advertises the routes on the two segments
(192.1.1.0/24 and 192.1.2.0/24) of campus network A to campus network B. To achieve
this function, you can use the filter-policy command to enable RIP on the firewall to
filter the advertised routing information. By importing an IP-prefix list, the firewall filters
the advertised routing information.
II. Network diagram
192.1.0.0 202.1.1.0
Campus netw ork A SecPath Campus netw ork A
Figure 6-2 Network diagram of filtering advertised routing information
# Configure an IP-prefix list.

# Configure the RIP protocol.

[H3C] rip
6-12

[H3C-rip] filter-policy ip-prefix p1 export
6.4.3 Configuring to Filter the Received Routing Information
z SecPath A communicates with SecPath B. OSPF protocol is enabled on both

gateways.
z Configure the OSPF route process on SecPath A and import three static routes.
z Configure the route filtering rule in SecPath B to make the received three static
routes partially visible and partially shielded---the routes of network segments
20.0.0.0 and 40.0.0.0 are visible, and the route of network segment 30.0.0.0 is
shielded.
II. Network diagram
Static: 20.0.0.1
30.0.0.1
40.0.0.1
Ethernet1/0/1 10.0.0.2/8
10.0.0.1/8
SecPathA SecPathB
1.1.1.1 Area 0 2.2.2.2
Figure 6-3 Network diagram of filtering imported routing information
# Configure the IP address of Ethernet1/0/0.
# Configure three static routes:

[H3C] ip route-static 20.0.0.1 32 ethernet 1/0/1
# Enable the OSPF protocol and specify the area ID of the interface.
6-13

[H3C] ospf
[H3C-ospf-1] area 0
# Import the static routes

[H3C-ospf-1] import-route static
# Configure the IP address of Ethernet1/0/0.
# Configure an ACL
[H3C-acl-basic-2001] rule deny source 30.0.0.0 0.255.255.255
[H3C-acl-basic-2001] rule permit source any
# Enable the OSPF protocol and specify the area ID of the interface.
[H3C] ospf
[H3C-ospf-1] area 0
# Configure the OSPF to filter the received external routes.

[H3C-ospf-1] filter-policy 2001 import
6.4.4 Configuring the BGP cost Attribute to Select Path
This example illustrates how the administrator manages the routing via BGP attributes.
All routers are configured with BGP, and IGP in AS200 adopts OSPF.
SecPath A is in AS100, SecPath B, SecPath C and SecPath D are in AS200. EBGP is
enabled on SecPath A, SecPath B and SecPath C. IBGP is enabled on SecPath B,
SecPath C and SecPath D.
6-14
II. Network diagram
network
2.0.0.0
SecPathB AS200
192.1.1.2/24 194.1.1.2/24 Ethernet1/0/0
Ethernet2/0/0 194.1.1.1/24
network 192.1.1.1/24 EBGP 2.2.2.2 IBGP
1.0.0.0 Ethernet2/0/0
195.1.1.1/24
SecPathA EBGP IBGP SecPathD
1.1.1.1 Ethernet1/0/0 4.4.4.4
193.1.1.1/24 Ethernet1/0/0 network
AS100 193.1.1.2/24 Ethernet2/0/0 4.0.0.0
195.1.1.2/24
SecPathC
3.3.3.3
network
3.0.0.0
Figure 6-4 Configure BGP routing
[H3C] bgp 100
[H3C-bgp p] peer 192.1.1.2 group ex192 as-number 200
[H3C-bgp] quit
# Configure the MED attribute of SecPath A.

# Add ACL to SecPath A and permit the network 1.0.0.0.
# Define two routing policies, one called apply_med_50 and the other apply_med_100.
The MED attribute set by the former for network 1.0.0.0 is 50, while the MED attribute
set by the latter is 100.
6-15

# Apply apply_med_50 to egress route update of SecPath C (193.1.1.2), and apply

apply_med_100 to the egress route update of SecPath B (192.1.1.2).
[H3C] bgp 100
[H3C] ospf
[H3C-ospf-1] import-route bgp
[H3C-ospf] area 0
[H3C-ospf-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[H3C-ospf-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[H3C] bgp 200
[H3C] ospf
[H3C-ospf-1] area 0
[H3C] bgp 200
6-16

[H3C] ospf
[H3C-ospf-1] area 0
[H3C-osp-1f-area-0.0.0.0] network 195.1.1.0 0.0.0.255
[H3C] bgp 200
[H3C-bgp] peer 195.1.1.2 group in as-number 200
[H3C-bgp] peer 194.1.1.2 group in as-number 200
To enable the configuration, all BGP peers will be reset via the reset bgp all command.
After above configuration, due to the fact that the MED attribute of route 1.0.0.0
discovered by SecPath C is less than that of SecPath B, SecPath D will first select the
route 1.0.0.0 from SecPath C.
If the MED attribute of SecPath A is not configured, the local priority on SecPath C is
configured as follows:
# Configure the local priority attribute of SecPath C.
z Add ACL 2001 on SecPath C and permit network 1.0.0.0.
z Define a routing policy named localpref. Set the local preference of routes
matching ACL 2001 as 200, and that of those not matching as 100.
[H3C-route-policy] route-policy localpref permit node 20
[H3C] quit
z Apply such routing policy to routing information from BGP neighbor 193.1.1.1
(SecPath A).
6-17
[H3C] bgp 200

[H3C-bgp] peer 193.1.1.1 route-policy localpref import
By then, due to the fact that the local preference attribute value (200) of the route
1.0.0.0 learned by SecPath C is greater than that of SecPath B (SecPath B is not
configured with local preference attribute, 100 by default), SecPath D will also first
select the route 1.0.0.0 from SecPath C.
6.4.5 Configuring Routing Policy Based on next-hop/as-path/origin/

local-preference
SecPath A and SecPath B are in AS300, SecPath D is in AS100, and SecPath C is in

AS200. Configure SecPath A and D, SecPath B and C, SecPath C and D to be EBGP
peers; configure SecPath A and B to be IBGP peers; configure SecPath A and B to use
the RIP protocol between them.
II. Network diagram
e1/0/0:192.168.1.1/24 AS200
e0/0/1: e0/0/1:
120.56.0.1/24 120.56.0.2/24
AS100
e0/0/0: e0/0/0:
SecPathD 172.16.1.2/24 10.0.0.2/24 SecPathC
e0/0/0: e0/0/0:
172.16.1.1/24
AS300 10.0.0.1/24
e1/0/0:
129.102.1.6/16
e1/0/0:
129.102.1.1/16
SecPathA SecPathB
Figure 6-5 Configure routing policy based on next-hop/as-path/origin/ local-preference
# Configure the IP addresses of the interfaces.
6-18
# Configure the RIP protocol.

[H3C] rip
[H3C-rip] quit
# Configure BGP internal and external neighbors.

[H3C] bgp 300
[H3C-bgp] import-route rip
[H3C-bgp] group in300 internal
[H3C-bgp] peer 129.102.1.1 group in300
[H3C] rip
[H3C-rip] quit
[H3C] bgp 300
[H3C-bgp] import-route rip
[H3C-bgp] group in300 internal
[H3C-bgp] peer 129.102.1.6 group in300
[H3C] bgp 200
6-19

[H3C] bgp 100
[H3C-bgp] network 192.168.1.0 255.255.255.0
[H3C-bgp] quit
[H3C] quit
After completing the above configurations, perform the display bgp routing command
on SecPath A and B, respectively. You will see that the next hop of 192.168.1.0 is
172.16.1.2, and the origin attribute is igp.
z If you add as-path on SecPath D:
[H3C] bgp 100
[H3C-bgp] peer ex300 route-policy AS300 export
[H3C-bgp] quit
[H3C] route-policy AS300 permit node10
[H3C-route-policy] apply as-path 300
[H3C] acl number 2001 match-order auto
[H3C-acl-basic-2001] rule permit source any
[H3C] quit
You will see that the next hop of 192.168.1.0 is changed to 10.0.0.2, with as-path being
200, 100; while the original AS300 routes are filtered out.
z If you specify the IP address of the next hop on SecPath A:
[H3C] bgp 300
[H3C-bgp] peer ex100 route-policy AS100 import
[H3C-bgp] quit
[H3C] route-policy AS100 permit node 10
6-20

[H3C] quit
You will see that the next hop of 192.168.1.0 is changed to 10.0.0.2.
If you configure the origin attribute on SecPath D:
[H3C] bgp 100
[H3C] quit
[H3C-route-policy] apply origin Incomplete
[H3C-acl-2001] rule permit source 192.168.1.0
[H3C-acl-2001] quit
[H3C] quit
You will see that the origin attribute is changed to Incomplete.

If you configure the local-preference attribute on SecPath B:
[H3C] bgp 200
[H3C-bgp] quit
[H3C-acl-2001] rule permit ip destination 192.168.1.0
[H3C-acl-2001] quit
[H3C] quit
You will see that the next hop of 192.168.1.0 is changed to 10.0.0.2.
6.5 Troubleshooting Routing Policy

Symptom 1: Routing information filtering cannot be implemented in normal operation of
the routing protocol
Troubleshooting:
Check the following requirements:
z The if-match mode of at least one node of the route-policy should be the permit
mode. When a route-policy is used for the routing information filtering, if a piece of
routing information does not pass the filtering of any node, then it means that the
6-21
route information does not pass the filtering of the route-policy. When all the nodes
of the route-policy are in the deny mode, then all the routing information cannot
pass the filtering of the route-policy.
z The if-match mode of at least one list item of the ip-prefix should be the permit
mode. The list items of the deny mode can be firstly defined to rapidly filter the
routing information not satisfying the requirement, but if all the items are in the
deny mode, any routes will not pass the ip-prefix filtering. You can define an item
of “permit 0.0.0.0/0 less-equal 32” after the multiple list items in the deny mode so
as to let all the other routes pass the filtering (If less-equal 32 is not specified, only
the default route will be matched).
6-22
H3C SecPath Series Security Products Chapter 7 Route Capacity Configuration
Chapter 7 Route Capacity Configuration
7.1 Route Capacity Configuration Overview

7.1.1 Introduction to Route Capacity Configuration
In practical network applications, there are always a large number of routes in the
routing table especially OSPF routes and BGP routes. The routing information is
usually stored in the memory of the router. When the size of the routing table increases,
the memory used also increases, but the total memory of the router will not change
(unless the hardware is upgraded but upgrade cannot be guaranteed to solve all
problems). When the memory is exhausted, the device will not work.
In order to solve such problem, the VPN provides a mechanism to control the size of
the routing table: Monitor the free memory in the system to determine whether to add
new routes to the routing table and whether to keep connection with a routing protocol.
Note:
It should be noted that the default value meets the requirements normally. The user is
not recommended to modify the configuration to avoid improper configuration to avoid
reducing of stability and availability of the system.
7.1.2 Route Capacity Limitation
Usually, the huge size of the routing table is caused by BGP routes and OSPF routes.
Therefore, the route capacity limitation is only effective to these two types of routes and
has no impact on static routes and other dynamic routing protocols.
When the free memory of a firewall reduces to the lower limit value, the system will
disconnect BGP and OSPF and remove corresponding routes from the routing table so
that the memory occupied is released. The system checks the free memory periodically.
When the free memory is detected to restore to the safety value, BGP and OSPF
connection will be restored.
7.2 Route Capacity Configuration

Route capacity configuration includes:
z Configure/restore the lower limit and the safety value of the firewall memory
z Configure the safety value of the firewall memory
7-1
z Configure the lower limit and the safety value simultaneously

z Restore the lower limit and the safety value of the firewall memory to the default
value
z Disable automatic recovery of the disconnected routing protocol
z Enable automatic recovery of the disconnected routing protocol
7.2.1 Configuring the Lower Limit and the Safety Value of the Memory
When the firewall memory is equal to or lower than the lower limit, BGP and OSPF will
be disconnected.
When the free memory value reduces to the safety value but does not reach the lower
limit value yet, the display memory limit command can be used to see that the firewall
is in an exigent state.
If memory automatic restoration is enabled, when the free memory of the firewall
exceeds the safety value, the disconnected BGP and OSPF will be restored.
Table 7-1 Configure the lower limit and the safety value of the firewall memory
Operation Command
Configure the lower limit and the safety value of memory { safety safety-value |
the firewall memory limit limit-value }*
Restore the lower limit and the safety value of
undo memory { safety | limit }
the firewall memory to their default values
The default of safety-value and limit-value depend on the capacity of the memory.
Note:
safety-value must be configured to be greater than limit-value.
7.2.2 Disabling Automatic Recovery Function of the Firewall
If the automatic recovery function of a firewall is disabled, disconnected BGP and

OSPF connections will not be restored even if the free memory is larger than the safety
value. Perform this configuration cautiously.
7-2
Table 7-2 Disable the automatic recovery function
Operation Command
Disable the automatic recovery function memory auto-establish disable
By default, the automatic recovery function is enabled.
7.2.3 Enabling Automatic Recovery Function of the Firewall
Table 7-3 Enable the automatic recovery function
Operation Command
Enable the automatic recovery function memory auto-establish enable
By default, the automatic recovery function is enabled.
7.3 Displaying and Debugging Route Capacity

running of the route capacity configuration and to verify the effect of the configuration.
Table 7-4 Display and debug route capacity
Operation Command
Display memory setting and state
display memory [ limit ]
information related to route capacity
7-3
MPLS
Operation Manual – MPLS
Table of Contents
Chapter 1 MPLS Architecture....................................................................................................... 1-1

1.1 MPLS Overview ................................................................................................................. 1-1
1.2 MPLS Basic Concepts ....................................................................................................... 1-1
1.2.1 FEC ......................................................................................................................... 1-1
1.2.2 Label........................................................................................................................ 1-1
1.2.3 LDP ......................................................................................................................... 1-3
1.3 MPLS Architecture ............................................................................................................. 1-4
1.3.1 MPLS Network Structure......................................................................................... 1-4
1.3.2 LSP Establishment .................................................................................................. 1-4
1.3.3 LSP Tunnel and Hierarchy ...................................................................................... 1-5
1.3.4 Forwarding Labeled Packets................................................................................... 1-5
1.4 LDP Overview .................................................................................................................... 1-6
1.4.1 LDP Basic Concepts ............................................................................................... 1-6
1.4.2 LDP Working Process ............................................................................................. 1-7
1.4.3 LDP Basic Operation............................................................................................... 1-9
1.4.4 LDP Loop Detection .............................................................................................. 1-10
1.4.5 Constrain-based Routing LDP .............................................................................. 1-11
1.5 MPLS and Other Protocols .............................................................................................. 1-11
1.5.1 MPLS and Routing Protocols ................................................................................ 1-11
1.5.2 MPLS Extension by RSVP .................................................................................... 1-11
1.6 MPLS Application............................................................................................................. 1-12
1.6.1 MPLS-Based VPN................................................................................................. 1-12
1.6.2 MPLS-Based Traffic Engineering.......................................................................... 1-13
1.6.3 MPLS-Based QoS ................................................................................................. 1-13
Chapter 2 MPLS Configuration .................................................................................................... 2-1

2.1 Introduction to MPLS Configuration................................................................................... 2-1
2.2 MPLS Basic Capability Configuration ................................................................................ 2-1
2.2.1 Defining MPLS LSR ID............................................................................................ 2-2
2.2.2 Entering MPLS View ............................................................................................... 2-2
2.2.3 Configuring the Topology-Driven LSP Setup Policy ............................................... 2-2
2.2.4 Configuring Static LSP ............................................................................................ 2-3
2.2.5 Configuring IP TTL Duplication of MPLS ................................................................ 2-3
2.2.6 Configuring MPLS to Return ICMP Responses by IP routing................................. 2-5
2.3 LDP Configuration.............................................................................................................. 2-5
2.3.1 Enabling/Disabling LDP .......................................................................................... 2-5
2.3.2 Enabling/Disabling LDP on Interface ...................................................................... 2-6
2.3.3 Configure LDP extended discovery mode .............................................................. 2-6
i
2.3.4 Configuring Session Parameters ............................................................................ 2-7

2.3.5 Configuring Remote LDP Peer Session Parameters .............................................. 2-8
2.3.6 LDP Loop Detection Control ................................................................................... 2-9
2.3.7 Configuring LDP Authentication Mode.................................................................. 2-10
2.4 Displaying and Debugging MPLS .................................................................................... 2-11
2.4.1 Displaying and Debugging MPLS ......................................................................... 2-11
2.4.2 Displaying and Debugging LDP ............................................................................ 2-13
2.5 MPLS Configuration Example.......................................................................................... 2-14
2.6 Troubleshooting MPLS Configuration.............................................................................. 2-17
ii
H3C SecPath Series Security Products Chapter 1 MPLS Architecture
Chapter 1 MPLS Architecture
1.1 MPLS Overview

MPLS (Multiprotocol Label Switching) encapsulates packets with labels of short and
fixed length. MPLS obtains service from various link layers (such as PPP, ATM, Frame
Relay, and Ethernet) and provides connection-oriented service for network layer. MPLS
can obtain support from IP routing protocol and control protocol and, at the same time,
it supports policy-based restraint route. It possesses powerful and flexible routing
functions and is capable of satisfying the requirements for the network from various
new applications. This technology was initially originated from IPv4. However, its core
technology can be extended to multiple network protocols (IPv6, IPX, etc).
MPLS is a protocol initially developed for increasing forwarding speed of routers.
However, it has gained wider applications in traffic engineering, VPN, and QoS and is
becoming an important standard for large-scale IP networks.
1.2 MPLS Basic Concepts

1.2.1 FEC
Forwarding Equivalent Class (FEC), in fact, is a kind of classify-and-forward technology.

It categorizes packets with the same forwarding strategy (same destination addresses,
same forwarding routes and same QoS levels) into one group, which is called a FEC.
The FEC classification is based on the network layer address. Packets in the same
FEC will be processed in absolutely the same way.
1.2.2 Label
I. Label definition
Label is a locally significant and short identifier with fixed length, which is used to
identify a particular FEC. When reaching at MPLS network ingress, packets are divided
into different FECs, on which different labels are encapsulated. Later forwarding is
based on these labels.
II. Label structure
The structure of the label is shown in Figure 1-1.
Label Exp S TTL
Figure 1-1 Label structure
1-1
Label is located between the link layer header and the network layer packet, with the
length of 4 bytes. A label contains four fields:
Label: label value, 20bits, used as the pointer for forwarding.
Exp: 3bits, reserved for test.
S: 1bit, MPLS supports hierarchical label structure, i.e., multi-layer label. Value 1 refers
to the label of bottom layer.
TTL: 8 bits, similar to TTL in IP packets.
III. Label operations
1) Label mapping
There are two types of label mapping: one is label mapping at ingress routers and the
other is label mapping in MPLS domain.
The first type is also called ingress LSR, in which input packets are grouped on a
certain principle into multiple FECs. The corresponding labels are mapped to these
FECs and the mapping results are recorded into label information base (LIB). In simple
words, it is to assign a label to a FEC.
The second type is also called incoming label mapping (ILM), that is, to map each input
label to a series of next hop label forwarding entries (NHLFE). The packets are
forwarded along the paths based on the mapping results.
2) Label encapsulation
Label encapsulation in different media is illustrated in Figure 1-2.
Ethernet/SONET/ Ethernet header

Label L3 data
SDH packets /PPPheader
Frame-mode
ATM header Label L3 data
ATM packets
Cell-mode ATM VPI/VCI L3 data

packets
Figure 1-2 Label position in packet
3) Label assignment and distribution

Label distribution refers to the process for a FEC to create corresponding label
switching path (LSP).
In the MPLS architecture, the decision to bind a particular label to a particular FEC is
made by downstream LSR, and the downstream LSR notifies the upstream LSR. That
is to say, the label is specified by the downstream LSR, and the label is distributed from
downstream to upstream.
1-2
Two label distribution modes are available in MPLS: Downstream unsolicited (DU)
mode and downstream on demand (DoD) mode.
For a specific FEC, if LSR originates label assignment and distribution even without
receiving label request messages from upstream, it is in DU mode.
For a specific FEC, if LSR begins label assignment and distribution only after receiving
label request messages from upstream, it is in DoD mode.
The upstream and downstream, which have adjacency relation in label distribution,
should reach agreement on label distribution mode.
For the peers, LSR can use LDP messages to distribute labels or bear labels over other
routing protocol messages.
Note:
Upstream and downstream are just on a relative basis: For a packet forwarding
process, the transmit router serves as upstream LSR and receive router serves as
downstream LSR.
4) Label control mode

There are two types of label control modes: independent mode and ordered mode.
In independent control mode, each LSR can notify label mapping messages anytime.
In ordered control mode, a LSR can send label mapping messages to upstream only
when it receives a specific label mapping messages of the next hop of a FEC or the
LSR serves as LSP (Label distribution protocol) egress node.
5) Label retention mode
There are two label-retention modes: liberal label retention mode and conservative
label retention mode.
For a specific FEC, if LSR Ru has received the label binding from LSR Rd, in case Rd is
not the next hop of Ru and Ru saves this binding, then it is called liberal label retention
mode. If Ru discards this binding, then it is called conservative label retention mode.
In case it is required that LSR is capable of adapting route variation rapidly, liberal label
retention mode can be adopted. In case it is required that a few labels are saved in LSR,
then conservative label retention mode can be used.
1.2.3 LDP
Label distribution protocol (LDP) is the signaling control protocol in MPLS, which
controls binding of exchange labels and FECs between LSRs and coordinates a series
of procedures between LSRs.
1-3
1.3 MPLS Architecture

1.3.1 MPLS Network Structure
The basic composing unit of MPLS network is LSR (Label Switching Router). It runs
MPLS control protocol and L3 routing protocol, exchanges routing messages with other
LSRs and create the routing table, maps FECs with IP packet headers, binds FECs
with labels, distributes label binding messages, establishes and maintains label
forwarding table.
The network consisting of LSRs is called MPLS domain. The LSR that is located at the
edge of the domain edge LSR (LER, Labeled Edge Router). It connects an MPLS
domain with a non-MPLS domain or with another MPLS domain, classifies packets,
distributes labels (as egress LER) and distracts labels. The ingress LER is termed as
ingress and egress LER as egress.
The LSR located inside the domain is called core LSR. The core LSR can be either the
router that supports MPLS or the ATM-LSR upgraded from ATM switch. It achieves
label swapping and label distribution. The labeled packets are transmitted along the
LSP (Label Switched Path) composed of a series of LSRs.
Label Switched Path (LSP)

Ingress
Egress
MPLS Core LSR
MPLS Edge LSR (LER)
Figure 1-3 MPLS basic principle
1.3.2 LSP Establishment
Actually, LSP establishment refers to the process of binding FEC with the label, and
then advertising this binding to the adjacent LSR on LSP. This process is implemented
via Label Distribution Protocol (LDP). LDP regulates the message in interactive
processing and message structure between LSRs as well as routing mode. Refer to the
following section for the detail description of LDP
1-4
1.3.3 LSP Tunnel and Hierarchy
I. LSP tunnel
MPLS supports LSP tunnel technology. On an LSP path, LSR Ru and LSR Rd are
upstream and downstream for each other. However, the path between LSR Ru and
LSR Rd may not be part of the path provided by routing protocol. MPLS allows
establishing a new LSP path <Ru R1...Rn Rd> between LSR Ru and LSR Rd, and LSR
Ru and LSR Rd are respectively the starting point and ending point of this LSP. The
LSP between LSR Ru and LSR Rd is referred to as the LSP tunnel, which avoids the
traditional encapsulated tunnel on the network layer. If the route along which the tunnel
passes and the route obtained hop by hop from routing protocol is in consistent, this
tunnel is called hop-by-hop routing tunnel. And if the two routes are not in consistent,
then the tunnel of this type is called explicit routing tunnel.
R1 R2 R3 R4 Layer 1
R21 R22 Layer 2
Figure 1-4 LSP tunnel
As shown in Figure 1-4, LSP <R2 R21 R22 R3> is a tunnel between R2 and R3.
II. Multi-layer label stack
When the packet is sent in LSP tunnel, there will be multiple layers for the label of the
packet. Then, on the ingress and egress of each tunnel, it is necessary to implement
incoming and outgoing operation for the label stack. For each incoming operation, the
label will be added with one layer. And there is no depth limitation for the label stack
from MPLS.
The labels are organized according to the principle “last in first out” in the label stack,
and MPLS processes the labels beginning from the top of the stack.
Suppose that a packet has the label stack depth of m, then the label at the bottom of the
stack is the label of first level, and the label at the top of the stack is the label of level m.
The packet with no label can be regarded as the packet of blank label stack (namely,
the label stack depth is zero).
1.3.4 Forwarding Labeled Packets
In Ingress, the packets entering the network are classified into Forwarding Equivalence
Class (FEC) according to their characteristics. Usually, FEC is classified according to
the IP address prefix or host address. The packets with the same FEC will pass through
the same path (i.e., LSP) in MPLS area. LSR assigns a short label of fixed length for the
incoming FEC packet, and then forwards it through the corresponding interface.
1-5
On the LSR along the LSP, the mapping table of the import/export labels has been
established (the element of this table is referred to as Next Hop Label Forwarding Entry
(NHLFE)). When the labeled packet arrives, LSR only needs to find the corresponding
NHLFE from the table according to the label and replace the original label with the new
special label, and then forwards the labeled packet. This process is called Incoming
Label Map (ILM).
On the Ingress, MPLS specifies FEC of specific packet, and the following routers only
need to forward it by label switching therefore this method is much simpler than the
routine network layer forwarding.
Note:
TTL Processing:
For labeled packet, it is necessary to copy the TTL value in the original IP packet into
the TTL field in the label. While forwarding the label type packet, LSR will perform
minus one operation for the TTL field of the label on the top of the stack. When the label
is out of the stack, the TTL value on the top of the stack is copied back to IP packet or
the label of lower layer.
However, while LSP goes through the non-TTL LSP segment composing of ATM-LSR
or FR-LSR, the LSR inside the non-TTL LSP segment is not capable of processing TTL
field. In this case, it is necessary to carry out unified processing for TTL while entering
non-TTL LSP segment, namely, to reduce for one time the value that reflects the length
of this non-TTL LSP.
1.4 LDP Overview

The LDP is responsible for message regulation and relevant processing in the label
distribution.
An LSR can directly map the routing information on the network layer to a switch path
on the data link over LDP, and then establish an LSP on the network layer. The LSP can
be set up between two adjacent LSRs or terminated at an Egress LSR. All the LSRs in
between adopt the label switching.
1.4.1 LDP Basic Concepts
I. LDP Peers
LDP peers refer to two LSRs undergo an LDP session by exchanging label/FEC
mapping information over LDP.
The LDP peers can obtain the other’s label information through an LDP session,
namely, the LDP is bidirectional.
1-6
II. LDP Session
An LDP session is to exchange label and release messages between LSRs. There are
two types of LDP session:
z Local LDP Session: an LDP session between two directly connecting LSRs.
z Remote LDP Session: an LDP session between two indirectly connecting LSRs.
III. LDP Message
There are four types of message involved in the LDP.

z Discovery message: used to notify or maintain the existing LSRs in the network;
z Session message: used to establish, maintain or terminate a session between
LDP peers;
z Advertisement message: used to establish, modify or delete a flag, that is, an FEC
binding;
z Notification message: used to provide suggestive messages or error notifications.
IV. Label Space and LDP Identifier
A label space refers to the range of labels that can be allocated to LDP peers. You can
specify a label space for each interface of an LSR or for the entire LSR.
An LDP identifier is to identify a special LSR label space. It is a six-byte value in the
following format:
<IP address>: <Label space number>
Here the IP address of four bytes is the LSR IP address and the remaining two bytes is
the label space number.
1.4.2 LDP Working Process
Figure 1-5 illustrates the LDP label distribution.
1-7
LSP1
Egress
Ingress A B C
D
LSP2
Label Request
E
Label Mapping F G
MPLS LSR
MPLS LER
H
LDP Session
Figure 1-5 Label distribution process
On an LSP, along the data transmission direction, neighboring LSRs are respectively
called as upstream LSR and downstream LSR. On LSP1 shown in Figure 1-5, LSR B is
the upstream LSR of LSR C.
Labels can be distributed in two modes: downstream on demand (DoD) and
downstream unsolicited (DU), depending on whether label mapping distribution is done
at the downstream with solicitation or without.
1) DoD mode
In DoD mode, the label is distributed in this way: the upstream LSR sends label request
message (containing FEC descriptive information) to the downstream LSR, and the
downstream LSR distributes label for this FEC, and then sends the bound label back to
the upstream LSR through label mapping message.
When the downstream LSR feeds back the label mapping message depends on
whether this LSR uses independent label control mode or sequential label control
mode. When the sequential label control mode is used by the downstream LSR, the
label mapping message is sent back to its upstream LSR if only it has received the label
mapping message from its downstream LSR. And when the independent label control
mode is used by the downstream LSR, it will send label mapping message to its
upstream LSR immediately, no matter if it has received the returned label mapping
message from its downstream LSR.
Usually, the upstream LSR selects the downstream LSR according to the information in
its routing table. In Figure 1-5, the sequential label control mode has been used by the
LSRs on the way along LSP1, and the independent label control mode has been used
by the LSRs on LSP2.
2) DU mode
1-8
In DU mode, the label is distributed in the following way: when LDP session is
established successfully, the downstream LSR will actively distribute label mapping
message to its upstream LSR. The upstream LSR saves the label mapping information
and processes the received label mapping information according to the routing table.
1.4.3 LDP Basic Operation
The basic LDP operation includes:

z Discovery phase
z Session establishment and maintenance
z LSP setup and maintenance
z Session termination
I. Discovery Phase
The originating LSR periodically sends a Hello message to its adjacent LSRs, notifying
them its peer information, so that the LSR can automatically find its LDP peer.
There are two types of LDP discovery mechanisms.
z Basic discovery mechanism
The basic discovery mechanism is to discover the local LDP peer, that is, to establish a
local LDP session between directly connecting LSRs.
In this case, the LSR periodically sends a Hello message of the LDP link to a specific
port, carrying the LDP identifier of the label space where the specific port belongs as
well as other relevant information. If the LSR receives the Hello message over the
specific port, it knows that there is a potential reachable peer on the link layer and
learns the label space of the port.
z Extended discovery mechanism
The extended discovery mechanism is to discover a remote LDP peer, that is, to
establish a remote LDP session between non-directly connecting LSRs.
In this case, the LSR periodically sends an LDP Targeted Hello message to a specific
IP address.
The LDP Targeted Hello message is sent in a UDP packet to the Well-known LDP
discovery port of the specific address. The message contains the desired label space of
the LSR as well as all relevant information.
II. Session Establishment and Maintenance
After the peer is set up, the LSR begins to establish a session by the following two
steps:
z Establishing a connection on the transport layer, that is, establishing TCP
connection between the LSR peers;
1-9
z Initializing the session and negotiating the parameters involved in the session,
such as the LDP version, label distribution mode, timer timeout and label space.
III. LSP Setup and Maintenance
Actually, LSP establishment refers to the process of binding FEC with the label, and
then advertising this binding to the adjacent LSR on LSP. This process is implemented
through LDP in the following steps:
1) When the routing of the network changes and an LER finds a new destination
address in its routing table not belonging to any existing FEC, the LER needs to
create an FEC for the address and determine routes for the FEC, and then sends
a label request message to the downstream LSR, indicating the FEC to be
allocated;
2) After the downstream LSR receives the label request message and records it, it
relays the message to the next hop LSR according to its routing table;
3) When the label request message reaches the destination LSR or the Egress LSR
in the MPLS network and either can allocate the requested label, it will allocate the
label to the FEC after the label request message passes its authentication. Then it
sends a label mapping message to the upstream LSR with the allocated label
information included;
4) The upstream LSR compares the received label mapping message with its label
database, allocates the matched label to the FEC, adds the map to its label
forwarding table, and then sends the label mapping message to its upstream LSR;
5) When the Ingress ISR receives the label mapping message, it adds the map to its
label forwarding table. In this way, an LSP is set up and the corresponding FEC
data packet can be forwarded based on its label.
IV. Session Termination
The LDP checks the session integrity depending on the LDP PDU transmitted in the
session connection.
The LSR sets up a living timer for each session and refreshes the timer after receiving
an LDP PDU. If the timer expires before the reception of an LDP PDU, the LSR
considers the session interrupted and tears down the corresponding connection on the
transport layer to terminate the session.
1.4.4 LDP Loop Detection
It is necessary to prevent path loop from happening while establishing LSP in the MPLS
domain. The LSP loop detection mechanism can detect such path loop and avoid
message loop occurring such as the label request message.
To avoid the LSP path loop, two methods can be used:
1-10
I. Maximum Hop Count
The maximum hop count method is to contain the hop-count information in the
message bound with the forwarding label. This value is added by one for each hop.
When the value exceeds the specified maximum value, it is considered that a loop
happens, and the process for establishing LSP is terminated.
II. Path Vector
The path vector method is to record the path information in the message bound with the
forwarding label. For every hop, the corresponding router checks if its ID is contained in
this record. If not, the router adds its ID into the record; and if so, it indicates that a loop
happens and the process for establishing LSP is terminated.
1.4.5 Constrain-based Routing LDP
MPLS also supports Constrain-based Routing LDP mechanism (CR-LDP). The

so-called CR-LDP refers to that, while originating the establishment of LSP, the ingress
node adds some constrain information for LSP routing in label request message. Two
routing approaches are available: strict explicit routing, where the constraint
information is the exact designation of all the LSRs along the path; and loose explicit
routing where only some of the LSRs along the path are specified.
1.5 MPLS and Other Protocols

1.5.1 MPLS and Routing Protocols
When LDP establishes LSP in hop-by-hop mode, the next hop will be determined by
using the information that is usually collected via such routing protocols as IGP, BGP in
each LSR route forwarding table on the way. However, LDP just uses the routing
information indirectly, rather than being associated with various routing protocols
directly.
On the other hand, although LDP is the special protocol for implementing label
distribution, but it is not the sole protocol for label distribution. The existing protocols
such as BGP, RSVP, after being extended, can also support MPLS label distribution.
For some MPLS applications, it is also necessary to extend some routing protocols. For
example, MPLS-based VPN application needs the extension of BGP so that the BGP is
capable of supporting the sending of VPN routing information. In addition, MPLS-based
Traffic Engineering (TE) needs the extension of OSPF or IS-IS protocol to carry link
status information.
1.5.2 MPLS Extension by RSVP
Resource Reservation Protocol (RSVP), after being extended, can support MPLS label
distribution. At the same time, while transmitting label-binding message, it is also
1-11
capable of carrying resource reservation information. The LSP established in this way
is of resource reservation function, namely, the LSRs on the way can distribute some
resources for this LSP to ensure the service transmitted on it.
The extension of RSVP mainly refers to adding new objects in its Path message and
Resv message. Besides carrying label binding information, these new objects are also
capable of carrying the constrain information for searching path for the LSRs on the
way, thus supporting LSP constraining function on routing. The extended RSVP also
supports fast rerouting, namely, when it is necessary to change LSP under some
condition, the original service flow can be rerouted to the newly established LSP
without interrupting the customer service.
1.6 MPLS Application

1.6.1 MPLS-Based VPN
For traditional VPN, the transmission of the data flow between private networks on the
public network is usually realized via such tunneling protocols as GRE, L2TP and PPTP,
and LSP itself is the tunnel on the public network. The implementation of VPN using
MPLS is of natural advantages. MPLS-based VPN connects the geographically
different branches of private network by using LSP, forming a united network.
MPLS-based VPN also supports the interconnection between different VPNs.
CE3
Branch 3 of
private network
PE3
CE2
CE1 PE1
Branch 1 of Backbone
network Branch 2 of
private network
private network
PE2
Figure 1-6 MPLS-based VPN
The basic structure of MPLS-based VPN is shown in Figure 1-6. CE is the customer
edge device, and it may be a router, a switch, or perhaps a host. PE is a service
provider edge router, which is located on the backbone network. PE is responsible for
the management of VPN customers, establishing LSP connection between various
PEs, route allocation among different branches of the same VPN customer.
Usually the route allocation between PEs is realized by using extended BGP.
MPLS-based VPN supports the IP address multiplexing between different branches
and the interconnection between different VPNs. Compared with traditional route, it is
necessary to add branch and VPN distinguisher information in VPN route. Therefore, it
is necessary to extend BGP to carry VPN routing information.
1-12
1.6.2 MPLS-Based Traffic Engineering
I. Application of Traffic Engineering
Network congestion is the main problem affecting the backbone network performance.
Usually the network is congested due to insufficient network resources or partially due
to unbalanced network resources. Traffic Engineering is used to solve the congestion
due to unbalanced load. Through monitoring network traffic and the load on network
element dynamically, then adjusting traffic management parameters and routing
parameters as well as resource constraining parameters in real time, the network
prevents the congestion due to unbalanced load and the network resources is
optimized.
II. Advantages of mpls-based traffic engineering
The existing IGPs are all driven by topology, and only the static connection of the
network is taken into account. However, such dynamic status as bandwidth and traffic
characteristics cannot be reflected. This is just the main reason resulting in unbalanced
network load. MPLS, which is different from those of IGP, just satisfies the requirement
of traffic engineering: MPLS supports the explicit LSP routing that is different from
routing protocol path. Compared with traditional single IP packet forwarding, LSP is
more convenient for management and maintenance. Constrain-routing-based LDP is
capable of realizing various policies of traffic engineering. In addition, the system
overhead of MPLS-based traffic engineering is even lower than that of other
implementation modes.
III. MPLS-based traffic engineering implementation
While realizing traffic engineering by using MPLS, first it is necessary to generate

MPLS derived graph according to the topology of physical network, i.e., the derived
topology chart composed of such three elements as LSR, the LSP connecting LSR,
and LSP attribute. Meanwhile, the data passing through MPLS domain are divided into
several traffic trunks. Usually the traffic trunks are defined as all one-way traffic passing
through Ingress and Egress in MPLS domain. Traffic trunks are of multiple attributes,
including traffic parameters, path selection and maintenance mode, precedence,
capability of preemption, resource affinity and so on. Some other attributes are also
defined for the resources, such as resource level, maximum distribution multiplexing
degree and so on. Then, the traffic trunk attributes, resource attributes and network
status information are used as the policies for generating constrain route to find out
traffic trunk path. In addition, the traffic trunk path can be adjusted dynamically
according to network status variation.
1.6.3 MPLS-Based QoS
QoS is indispensable to the implementation of voice, video, and some other real-time
services over an IP network in the sense that it can differentiate the data streams so
1-13
that those crucial, sensitive, and delay-sensitive data streams over the network can be
processed first. As H3C devices support MPLS-based Diff-serv features, they can
provide differentiated services for the data streams assigned with different precedence
levels while maintaining high network efficiency. Thus, they can provide the services
featuring guaranteed bandwidth, low delay, and low loss rate for voice and video traffic.
As it is difficult to deploy TE over the entire network, the Diff-ser model is always
preferred for implementing QoS in actual networking solutions.
The basic mechanism of Diff-serv goes like this: A service is mapped to a service
category, which can be uniquely identified by the DS bits in the ToS field of the IP
packets, according to the required service quality at the network edge. Then, the nodes
on the backbone network adopt the proper service policy to process the packets
according to the service category defined by the DS bits (derived from the ToS field),
ensuring the proper service quality. The service quality classification and the label
mechanism in Diff-serv are very similar to the label distribution in MPLS. In fact,
MPLS-based Diff-serv is fulfilled by integrating DS assignment into the label distribution
process of MPLS.
Diff-serv defines the same processing method, which includes queue selection,
queuing, and the drop operation, for each service category. The combination of these
processing operations is called Per Hop Behavior (PHB). In addition, the packets that
belong to the same PHB may be assigned with different drop preference. The
information of PHB and drop preference is indicated by the DS code assigned to the
packets. The DS codes are also known as Diff-serv Code Point (DSCP). For more
information about Diff-serv, refer to the Section QoS module in this manual.
The following methods are available for supporting end-to-end QoS based on the
Diff-serv model:
z IP Precedence for Traffic Classification
IP precedence classification is implemented at the network edge. It makes use of the
3-bit Type-of-Service field in the IPv4 header to sort precedence of the IP packets
according to their addresses. At the core, different queuing technologies are used to
make different processing on the streams of different precedence, thus to discriminate
the services at different levels. To implement Diff-serv for the voice, image, and data
streams, when PE labels the packets, that is, makes label switching for different traffic,
it will map the ToS value carried in the IP packets to the CoS field of the label. Thus, the
type information previously carried by IP will be carried by the label. Depending on the
CoS field of the label, PE routers will implement differentiated scheduling on the
packets using PQ, CQ, WFQ or CBQ.
z TP for implementing committed and constraint bandwidth
This function can be implemented by configuring Traffic Policing (TP) on the link that
connects PE to CE. In addition, TP also provides the functions of committed bandwidth
and constraint bandwidth.
1-14
z WRED for congestion avoidance

WRED can be used to monitor and alleviate network congestion at the bottleneck of the
network. Usually, congestion is more likely caused at the access layer. At the onset of
congestion, WRED, which is monitoring the network load, begins to select packets and
discard them for decreasing the traffic size. The packet drop policy of WRED is to
discard the packets of low preference to ensure the smooth transmission of high
preference packets. Running WRED on a port prone to congestion is a good choice for
congestion avoidance.
In actual deployment, the tasks should be distributed in order to achieve the optimal
efficiency. As QoS is such an application that will consume enormous resources of the
processor, the tasks of QoS are shared by the edge and core routers so as to alleviate
the load imposed on a single router.
To sum up, four steps should be followed in order to implement CoS-based Diff-serv:
z Impose the incoming bandwidth constraint on the MPLS edge router to classify the
incoming traffic.
z Adopt CAR on the edge devices so that they can share the work of bandwidth
management.
z The MPLS core router accomplishes CoS management to implement Diff-serv
QoS.
z The egress device, like the ingress device, implements bandwidth restriction. The
bandwidth restriction implemented by the ingress and egress devices protects the
network from congestion and hence significantly improves the network scalability.
For more details, see QoS module.
1-15
H3C SecPath Series Security Products Chapter 2 MPLS Configuration
Chapter 2 MPLS Configuration
2.1 Introduction to MPLS Configuration

The following MPLS basic capabilities are available:
z Basic MPLS forwarding
Comware supports the basic MPLS forwarding function, including label packet
forwarding and TTL processing.
z LDP session establishment and LSP maintenance
Each interface supports LDP session and supports the loop detection in both maximum
hop count mode and path vector mode. It can create and delete LSPs.
It also supports loose routing and strict explicit routing: You can also specify LSPs.
Besides MPLS basic functions, Comware also provide performance monitoring and
fault diagnostic tools.
To enable basic MPLS functions at a firewall, you should complete the following
configuration tasks:
1) Configure LSR ID
2) Enable MPLS
3) Enable LDP protocol
4) Enter interface view and enable interface LDP function
Then the firewall can provides MPLS forwarding and LDP signaling functions.
If you want to modify the default parameters or enable some special functions, for
example, creating LSP, creating explicit route, you just configure according to the
method in configuration list. For some complicated functions, configuration
combination may be required.
2.2 MPLS Basic Capability Configuration

MPLS basic capability configuration (compulsory) includes:
z Define MPLS LSR ID
z Disable/enable LDP and enter LDP view
MPLS basic capability configuration (optional) includes:
z Enable LDP on interface
z Control LDP loop detection
z Set LDP session keepalive parameters on interface
2-1
2.2.1 Defining MPLS LSR ID
Before configuring any other MPLS command, it is necessary to configure LSR ID firstly.
The ID is usually in IP address format and must be unique in the domain.
Table 2-1 Define MPLS LSR ID
Operation Command
Define LSR ID mpls lsr-id ip-address
Delete LSR ID undo mpls lsr-id
By default, LSR ID is not specified.
2.2.2 Entering MPLS View
Execute the mpls command in system view to enter the MPLS view. Then, you can
perform the MPLS configurations.
Table 2-2 Enter MPLS view
Operation Command
Enter MPLS view mpls
Disable MPLS globally. undo mpls
Executing the mpls command in interface view will enable the MPLS capability on the
corresponding interface.
For those link layer protocols that do not support broadcast, such as X.25, Frame Relay,
ATM, you must use the protocol ip { ip-address [ ip-mask ] | default | inarp [ minutes ] }
[ broadcast ] command to configure the broadcast attribute to support the
transmission of broadcast and multicast packets.
2.2.3 Configuring the Topology-Driven LSP Setup Policy
It refers to specifying filtering policy as all or ip-prefix.

Perform the following configuration in MPLS view.
Table 2-3 Configure a topology-driven LSP setup policy
Operation Command
Configure a topology-driven LSP setup
lsp-trigger { all | ip-prefix ip-prefix }
policy
2-2
Operation Command
Disable the filtering condition specified
undo lsp-trigger { all | ip-prefix
by the arguments and no routes of any
[ ip-prefix ] }
type can trigger the LSP setup
2.2.4 Configuring Static LSP
You can manually set an LSR to be a node along an LSP, and place a limit on the traffic
over the LSP. Depending on the position in an MPLS domain, LSR can be ingress,
transit node, or an egress. Note that the correct operation of this LSP can be ensured
only after the LSRs along the specified LSP have been properly configured.
The undo static-lsp command is used to delete a specified LSP established manually.
Table 2-4 Set this LSR to be a node on a specified LSP
Operation Command
static-lsp ingress lsp-name destination dest-addr
Set the current LSR to { addr-mask | mask-length } } { nexthop next-hop-addr |
be the ingress of a outgoing-interface interface-type interface-num }
specified LSP out-label out-label-value
undo static-lsp ingress lsp-name
static-lsp transit lsp-name incoming-interface
Set the current LSR to interface-type interface-num } in-label in-label-value
be a transit node along { nexthop next-hop-addr | outgoing-interface
the specified LSP interface-type interface-num } out-label out-label-value
undo static-lsp transit lsp-name
Set the current LSR to static-lsp egress lsp-name incoming-interface

be the egress of the interface-type interface-num in-label in-label-value
specified LSP undo static-lsp egress lsp-name
2.2.5 Configuring IP TTL Duplication of MPLS
The MPLS label contains an eight-bit TTL field same as the one used in an IP header. It
can be used for supporting the tracert command in addition to suppressing routing
loops.
As described in RFC3031, when an LSR labels a packet, it needs to copy the TTL value
in the IP packet or the upper layer label into the TTL field in the added label. When it
forwards a labeled packet, it decrements the TTL value in the top label by one. When
the LSR pops the stack, it copies the TTL value in the top label back to the IP packet or
the lower label.
2-3
If an LSP has a non-TTL LSP segment which comprises a sequence of ATM-LSRs or

FR-LSRs unable to handle the TTL field, the TTL value must be decremented by the
value that reflects the length of the non-TTL LSP segment before a packet is forwarded
into this segment.
In MPLS VPN networking, you may hide the MPLS backbone topology for security sake.
You cannot however, apply on the ingress TTL duplication to VPN packets.
Table 2-5 Configure IP TTL duplication of MPLS
Operation Command
Enable IP TTL duplication of MPLS. ttl propagate { public | vpn }
Disable IP TTL duplication of MPLS. undo ttl propagate { public | vpn }
By default, IP TTL duplication is enabled for public-network packets and disabled for
VPN packets.
If IP TTL duplication is enabled at the ingress, the TTL value of packets is decremented
at each LSR hop that it passes. This allows the tracert to reflect the path that a packet
travels.
If IP TTL duplication is disabled at the ingress, the TTL value is not decremented at the
LSR hops that packets travel and as such, those hops in the MPLS backbone are
excluded from the path shown after you run a tracert, just as if the ingress and the
egress are directly connected.
Note that:
z Inside an MPLS domain, if an MPLS packet has a label stack, the TTL value in a
label is always copied from other labels in the stack.
z The TTL value of the transmitted local packets is copied regardless whether IP
TTL duplication is enabled or not. This ensures that the local administrator can
execute the tracert command to test the network.
z At the egress, if IP TTL duplication is enabled, the TTL value in the MPLS label is
copied to the TTL field in the IP header and decremented by one.
z Configure IP duplication for VPN packets in the same way at the ingress and the
egress: if the ttl propagate vpn command is enabled at the ingress, enable it at
the egress; if the command is disabled at the ingress, disable it also at the egress.
This ensures that the results of traceroutes can reflect the real network conditions.
You are recommended to enable this function on the involved PEs to ensure
consistency of the results gotten by tracerting on different PEs.
z You need not to configure the ttl propagate command on any P routers.
2-4
2.2.6 Configuring MPLS to Return ICMP Responses by IP routing
In an MPLS VPN network, a P router cannot route the IP packets encapsulated in

MPLS. When the TTL value of an MPLS packet expires, the ICMP response continues
to travel the LSP until reaching the egress, where it is forwarded by IP routing. This
approach increases network traffic while decreasing reliability of packet forwarding.
For a one-tier MPLS packet with TTL expired, you can configure to have its ICMP
response forwarded by local IP routing, that is, the default.
Table 2-6 Configure MPLS to return ICMP responses by IP routing
Operation Command
Return ICMP responses by IP routing. ttl expiration pop
Return ICMP responses along the LSP. undo ttl expiration pop
On an ASBR or SPE (it can be an SPE in a nesting application) on an HoVPN network,

the MPLS packets that carry VPN packets may have only one-tier labels. In this
circumstance, to tracert to a VPN to view the forwarding path of the routers on the
public network, you need to perform the following tasks:
1) Configure the ttl propagate vpn command on all the involved PEs.
2) Configure the undo ttl expiration pop command on the ASBR and SPE to
guarantee ICMP responses to be forwarded along the original LSP.
2.3 LDP Configuration

Perform the following compulsory tasks in configuring LDP:
z Enable LDP
z Enable LDP on Interface
Perform the following optional tasks in configuring LDP:
z Configure LDP extended discovery mode
z Configure the label of the penultimate hop at the egress
z Configure session parameters
z Configure LDP loop detection control
z Configuring LDP authentication mode
2.3.1 Enabling/Disabling LDP
To configure LDP, first enable LDP.

2-5
Table 2-7 Enable/disable LDP view
Operation Command
Enable LDP mpls ldp
Disable LDP undo mpls ldp
By default, LDP is disabled.
2.3.2 Enabling/Disabling LDP on Interface
To make the interface be of MPLS function, it is necessary to enable the LDP of

interface in the interface view. Then the interface is capable of establishing LDP
session and forwarding labeled packet.
Disabling LDP function will delete LDP peer, delete LSP tunnel, close TCP connection,
interrupt peer LDP session, stop sending HELLO packets, and stop labeled packet
forwarding.
Table 2-8 Enable/disable LDP on interface
Operation Command
Enable LDP function on interface mpls ldp enable
Disable LDP function on interface mpls ldp disable
By default, the interface MPLS function is disabled.
2.3.3 Configure LDP extended discovery mode
It is to create extended discovery mode, to set up sessions with peers not directly
connected to the link.
I. Entering remote-peer mode
Table 2-9 Enter the extended discovery mode
Operation Command
Enter the extended discovery mode mpls ldp remote-peer index
Delete the corresponding remote-peer undo mpls ldp remote-peer index
There is no default remote-peer.
2-6
II. Configuring a remote-peer address
You can specify the address of any LDP-enabled interface on the remote-peer or the
address of the loopback interface on the LSR that has advertised the route as the
address of the remote-peer.
Perform the following configuration in remote-peer view.
Table 2-10 Configure a remote-peer address
Operation Command
Configure the remote-peer address remote-ip ip-address
There is no default remote-peer.
2.3.4 Configuring Session Parameters
I. Configuring session hold-time
The LDP entity on the interface sends Hello packets periodically to find out LDP peer,
and the established sessions must also maintain their existence by periodic message
(if there is no LDP message, then Keepalive message must be sent).
Caution:
Modifying the holdtime argument does not bring changes for the value of the original
session. However, the modification will take effect on sessions that are going to be
established. Here the session refers to link session, but not remote session.
Table 2-11 Set interface LDP session parameters
Operation Command
Set interface LDP session keepalive mpls ldp timer { session-hold
parameters session-holdtime | hello hello-holdtime }
Restore the default interface LDP undo mpls ldp timer { session-hold |
session parameters hello }
The session-holdtime argument defaults to 60 seconds and the hello-holdtime

argument defaults to 15 seconds.
2-7
II. Configuring hello transport-address
The transport-address discussed here refers to the address carried in the transport
address field TLV in hello messages. Generally, transport-address is the MPLS LSR ID
of the current LSR, but other configurations may be required in some applications.
Table 2-12 Configure hello transport-address
Operation Command
mpls ldp transport-ip { interface |
Configure a hello transport-address
ip-address }
Restore the default hello
undo mpls ldp transport-ip
transport-address
Transport-address defaults to the MPLS LSR ID of the current LSR.

When MPLS LDP is enabled on multiple directly connected links, these links must be
configured with the same transport address. It is recommended that you take the
default LSR-ID as the transport address; otherwise, the LDP session may not be well
established.
2.3.5 Configuring Remote LDP Peer Session Parameters
I. Configuring hello timers
Table 2-13 Configure hello timers
Operation Command
Configure the interval and hold-time mpls ldp timer targeted-hello
value for hello packets { interval time | holdtime time }
Restore the interval and hold-time value undo mpls ldp timer targeted-hello
for hello packets to the default { interval | holdtime }
By default, the hello interval is 13 seconds; the hold-time is 45 seconds.
II. Configuring session keepalive timers
Table 2-14 Configure session keepalive timers
Operation Command
Configure the interval and hold-time mpls ldp timer targeted-session-hold
value for session keepalive packets { interval time | holdtime time }
2-8
Operation Command
Restore the interval and hold-time value undo mpls ldp timer
for session keepalive packets to the targeted-session-hold { interval |
default holdtime }
By default, the keepalive interval is 24 seconds; the hold-time is 60 seconds.
2.3.6 LDP Loop Detection Control
I. Enabling loop detection
It is used to enable or disable the loop detection function during LDP signaling process.
The loop detection includes maximum hop count mode and path vector mode.
In maximum hop count mode, hop count information is included in label binding
information and is added by 1 when the packet passes through another hop. When the
value exceeds the maximum, it is reckoned that loop appears, so LSP setup process
terminates.
In path vector mode, path information is included in the label binding information. Each
time the packet passes through a hop, the corresponding router will check whether its
ID is recorded in the path information. If not, the router just adds its ID. If yes, it means
loop appears, so LSP setup process terminates.
Table 2-15 Enable loop detection
Operation Command
Enable loop detection mpls ldp loop-detect
Disable loop detection undo mpls ldp loop-detect
By default, the loop detection is disabled.
II. Setting the maximum hop count for loop detection
When maximum hop count mode is adopted for loop detection, the maximum
hop-count value can be defined. And if the maximum value is reached, it is considered
that a loop happens and the LSP establishment fails.
2-9
Table 2-16 Set the maximum hop count for loop detection
Operation Command
Set maximum hop count for loop
mpls ldp hops-count hop-number
detection
Restore default maximum hop count undo mpls ldp hops-count
The maximum hop count defaults to 32.
III. Setting the maximum value of the path vector
When path vector mode is adopted for loop detection, it is also necessary to specify the
maximum value of LSP path. In this way, when one of the following conditions is met, it
is considered that a loop happens and the LSP establishment fails.
1) The record of this LSR already exists in the path vector recording table.
2) The path hop count reaches the maximum value set here.
Table 2-17 Set the maximum value of the path vector
Operation Command
Set maximum value of the path vector mpls ldp path-vectors pv-number
Remove maximum value setting for path
undo mpls ldp path-vectors
vector
The maximum hop count defaults to 32.
2.3.7 Configuring LDP Authentication Mode
Perform the following configuration in interface view or remote-peer view.
Table 2-18 Configure LDP authentication mode
Operation Command
mpls ldp password { cipher | simple }
Configure LDP authentication mode
password
Remove LDP authentication undo mpls ldp password
2-10
2.4 Displaying and Debugging MPLS

2.4.1 Displaying and Debugging MPLS
MPLS provides abundant display and debugging commands for monitoring LDP
session state, tunnel, all the LSPs and their states, and so on. These commands are
the powerful debugging and diagnosing tools.
I. Displaying static LSPs
After accomplishing the configuration tasks mentioned earlier, you can execute the
display command in any view to view the running state of a single or all the static LSPs
and thus to evaluate the effect of the configurations.
Table 2-19 Display the static LSP information
Operation Command
display mpls static-lsp [ verbose ]
Display the static LSP information
[ include text ]
II. Displaying MPLS statistics
Execute the display command in any view or the reset command in user view to view
or clear statistics about the specified or all static LSPs.
Table 2-20 Display/clear the MPLS statistics
Operation Command
display mpls statistics { interface { all |
Display the MPLS statistics interface-type interface-number } } | { lsp [ lsp-Index
| all | name lsp-name ] } }
reset mpls statistics { { interface { all |
Clear the MPLS statistics
interface-type interface-num } } | { lsp lsp-name } }
III. Displaying MPLS fast-forwarding information
Execute the display command in any view and reset command in user view to view or
clear MPLS fast-forwarding information.
Table 2-21 Display/clear MPLS fast-forwarding information
Operation Command
Display MPLS fast-forwarding
display mpls fast-forwarding cache
information
Clear MPLS fast-forwarding information reset mpls fast-forwarding cache
2-11
IV. Displaying MPLS-enabled interfaces
After accomplishing the configuration tasks mentioned earlier, you can execute the
display command in any view to view the information related to the MPLS-enabled
interfaces and thus to evaluate the effect of the configurations.
Table 2-22 Display information of the MPLS-enabled interfaces
Operation Command
Display information of the
display mpls interface
MPLS-enabled interfaces
V. Displaying LSP
Please execute the following commands in any view to display the information related
to MPLS LSP.
Table 2-23 Display MPLS LSP
Operation Command
Display the information related to MPLS display mpls lsp [ verbose] [ include
LS text ]
VI. Debugging MPLS
You may execute the debugging command in user view to debug the information
concerning all interfaces with MPLS function enabled.
As enabling debugging may affect the performance of the firewall, you are
recommended to use this command unless necessary. Execute the undo form of this
command to disable the corresponding debugging.
Table 2-24 Debug MPLS
Operation Command
debugging mpls lspm { all | packet |
Enable debugging on various MPLS
event | process | agent | interface |
LSP information.
policy | vpn }
undo debugging mpls lspm { all |
Disable MPLS LSP debugging. packet | event | process | agent |
interface | policy | vpn }
VII. Trapping MPLS
This command is used to enable the trap function of MPLS during an LSP/LDP setup
process.
2-12
Table 2-25 Enable the trap function of MPLS
Operation Command
Enable the ldp trap function of MPLS snmp-agent trap enable ldp
Disable the ldp trap function of MPLS undo snmp-agent trap enable ldp
Enable the lsp trap function of MPLS snmp-agent trap enable lsp
Disable the lsp trap function of MPLS undo snmp-agent trap enable lsp
2.4.2 Displaying and Debugging LDP
I. LDP display commands
Comware provides abundant MPLS monitoring commands for monitoring states of

LSRs, LDP sessions, interfaces and peers. These commands are the powerful
debugging and diagnosing tools.
After accomplishing the configuration tasks described earlier, you can execute the
display command in any view to view the running state of LDP and thus to evaluate the
effect of the configurations.
Table 2-26 LDP monitoring commands
Operation Command
Display LDP information display mpls ldp
Display buffer information for LDP display mpls ldp buffer-info
Display LDP interface information display mpls ldp interface
Display LDP label information display mpls ldp lsp
Display LDP session peer information display mpls ldp peer
Display information of the remote-peers
display mpls ldp remote
in the LDP sessions
Display states and parameters of LDP
display mpls ldp session
sessions
II. Debugging commands
Execute debugging command in user view for the debugging of various messages
related to LDP.
2-13
Table 2-27 Debug MPLS
Operation Command
debugging mpls ldp { { all | main | advertisement |
Enable MPLS debugging session | pdu | notification } [ interface
interface-type interface-number ] | remote }
undo debugging mpls ldp { { all | main |
advertisement | session | pdu | notification |
Disable MPLS debugging.
remote } [ interface interface-type interface-number ]
| remote }
all: Displays all LDP-related debugging information

main: Displays debugging information about LDP main tasks
advertisement: Displays debugging information in processing LDP advertisements
session: Displays debugging information in processing LDP session
pdu: Displays debugging information in processing PDU packets
notification: Displays debugging information in processing notifications
remote: Displays debugging information about all remote peers
2.5 MPLS Configuration Example

As shown in Figure 2-1, there is a network consisting of four firewalls, among which
SecPath B and SecPath C are connected via SDH, and SecPath B, SecPath A and
SecPath D are interconnected via Ethernet.
The four firewalls all support MPLS, and LSP can be established between any two
firewalls with the routing protocol OSPF.
II. Network diagram
SecPath B
SecPath A 168.1.1.2 172.17.1.1 SecPath D
ethernet2/0/0
ethernet0/0/0 100.10.1.2 ethernet2/0/1
168.1.1.1 172.17.1.2
ethernet 1/0/0
100.10.1.1
SecPath C
Figure 2-1 Network diagram
2-14
1) Configuration on SecPath A
# Configure LSR ID and enable MPLS and LDP.
[H3C] mpls lsr-id 168.1.1.1
[H3C] mpls
[H3C] mpls ldp
# Configure IP address and enable LDP for Ethernet interface.

[H3C-Ethernet0/0/0] mpls
[H3C-Ethernet0/0/0] mpls ldp enable
# Enable OSPF on the interfaces connecting SecPath A and SecPath B

[H3C] ospf
[H3C-ospf-1] area 0
2) Configuration on SecPath B
[H3C] mpls lsr-id 172.17.1.1
[H3C] mpls
[H3C] mpls ldp
# Configure IP address and enable LDP for Ethernet interface 1/0/0.

# Configure Ethernet interface 1/0/1 and enable LDP on it.

# Configure Ethernet interface 2/0/2 and enable LDP on it.

2-15
# Enable OSPF on the interfaces connecting SecPath B respectively with SecPath A,

SecPath D and SecPath C.
[H3C] router id 172.17.1.1
[H3C] ospf
[H3C-ospf-1] area 0
3) Configuration on SecPath C:
# Configure a loopback interface.
[H3C] interface LoopBack0
[H3C-LoopBack0] quit
# Configure OSPF.
[H3C] ospf
[H3C-ospf-1] area 0

[H3C] mpls lsr-id 172.16.1.2
[H3C] mpls
[H3C] mpls ldp
# Configure IP address and enable LDP on Ethernet interface 1/0/0.

# Configure OSPF on the interfaces connecting SecPath C and SecPath B.

[H3C] router id 172.16.1.2
[H3C] ospf
[H3C-ospf-1] area 0
4) Configuration on SecPath D:
[H3C] mpls lsr-id 172.17.1.2
[H3C] mpls
[H3C] mpls ldp
# Configure IP address and enable LDP on Ethernet interface 2/0/1.
2-16

# Configure OSPF on the interfaces connecting SecPath D and SecPath B.

[H3C] router id 172.17.1.2
[H3C] ospf
[H3C-ospf-1] area 0
2.6 Troubleshooting MPLS Configuration

Symptom: Session links cannot be setup with the peer after LDP is enabled on the
interface.
Troubleshooting:
Cause 1: Loop detection configuration is different at both ends.
Measure: Check loop detection configuration at both end to see if one end is configured
while the other end is not.
Cause 2: Local machine cannot get the route to peer LSR ID, so TCP connection
cannot be set up.
Measure: The default address for session transfer is MPLS LSR ID. The local machine
should issue the LSR ID route (often the loopback address) and learn the peer LSR ID
route.
2-17
VPN
Operation Manual – VPN
Table of Contents
Chapter 1 VPN Overview .............................................................................................................. 1-1

1.1 VPN Overview.................................................................................................................... 1-1
1.1.1 Features of VPN...................................................................................................... 1-1
1.1.2 Benefits of VPN ....................................................................................................... 1-1
1.1.3 Structure of VPN network........................................................................................ 1-2
1.2 Fundamental Technology of VPN...................................................................................... 1-2
1.2.1 Basic Network Application of VPN .......................................................................... 1-2
1.2.2 Mechanism of VPN ................................................................................................. 1-3
1.3 Classification of VPN ......................................................................................................... 1-5
Chapter 2 L2TP Configuration ..................................................................................................... 2-1

2.1 Introduction to L2TP .......................................................................................................... 2-1
2.1.1 VPDN Overview ...................................................................................................... 2-1
2.1.2 Introduction to L2TP Protocol.................................................................................. 2-2
2.2 LAC Configuration.............................................................................................................. 2-6
2.2.1 Enabling L2TP......................................................................................................... 2-7
2.2.2 Creating L2TP Group .............................................................................................. 2-7
2.2.3 Setting Condition Triggering L2TP Tunnel Setup Request and LNS Address ....... 2-8
2.2.4 Setting Tunnel Name .............................................................................................. 2-9
2.2.5 Setting Tunnel Authentication and Password ....................................................... 2-10
2.2.6 Configuring AVP Hiding ........................................................................................ 2-10
2.2.7 Setting Hello Interval in Tunnel ............................................................................. 2-11
2.2.8 Setting Username, Password and Local User Authentication .............................. 2-11
2.2.9 Disconnecting an L2TP Connection...................................................................... 2-12
2.2.10 Setting Flow Control Function of Tunnel............................................................. 2-13
2.2.11 Setting the L2TP Session Idle-Timeout Timer .................................................... 2-13
2.2.12 Configuring the Tunnel-Hold Function of L2TP................................................... 2-13
2.2.13 Setting LAC to Function as Client ....................................................................... 2-14
2.3 LNS Configuration............................................................................................................ 2-16
2.3.1 Enabling L2TP....................................................................................................... 2-16
2.3.2 Enabling L2TP Multi-Domain Function ................................................................. 2-17
2.3.3 Creating L2TP Group ............................................................................................ 2-17
2.3.4 Creating Virtual Template ..................................................................................... 2-18
2.3.5 Setting Parameters for Call Receiving .................................................................. 2-18
2.3.6 Setting Local Name............................................................................................... 2-19
2.3.7 Setting Tunnel Authentication and Password ....................................................... 2-20
2.3.8 Setting Transfer Mode of AVP Data...................................................................... 2-20
2.3.9 Setting Hello Interval in Tunnel ............................................................................. 2-21
i
2.3.10 Enabling Mandatory Local CHAP Authentication................................................ 2-21

2.3.11 Forcing LCP to Re-negotiate............................................................................... 2-22
2.3.12 Setting Local Address and Assigning Address Pool ........................................... 2-23
2.3.13 Setting Username, Password and User Authentication...................................... 2-24
2.3.14 Disconnecting an L2TP Connection.................................................................... 2-24
2.3.15 Enabling/Disabling Flow Control Function of Tunnel .......................................... 2-24
2.3.16 Setting the L2TP Session Idle-Timeout Timer .................................................... 2-25
2.3.17 Configuring EAD Support for L2TP ..................................................................... 2-25
2.4 Displaying and Debugging L2TP ..................................................................................... 2-26
2.5 L2TP Configuration Example........................................................................................... 2-27
2.5.1 NAS-initialized VPN Networking ........................................................................... 2-27
2.5.2 Client-initialized VPN Networking.......................................................................... 2-28
2.5.3 L2TP Multi-Domain Networking ............................................................................ 2-30
2.5.4 Using LAC as L2TP Client .................................................................................... 2-33
2.5.5 Complex Network Design...................................................................................... 2-35
2.6 L2TP Troubleshooting ..................................................................................................... 2-36
Chapter 3 GRE Configuration ...................................................................................................... 3-1

3.1 Brief Introduction to GRE................................................................................................... 3-1
3.2 GRE Configuration............................................................................................................. 3-4
3.2.1 Creating Virtual Tunnel Interface ............................................................................ 3-4
3.2.2 Setting Encapsulation Mode ................................................................................... 3-5
3.2.3 Specifying Tunnel Source ....................................................................................... 3-5
3.2.4 Specifying Tunnel Destination................................................................................. 3-6
3.2.5 Assigning Network Address to Tunnel Interface ..................................................... 3-6
3.2.6 Configuring End-to-End Verification on Both Ends of Tunnel................................. 3-7
3.2.7 Setting Identification Key of Tunnel Interface ......................................................... 3-7
3.2.8 Configuring Routing via Tunnel............................................................................... 3-8
3.2.9 Configuring the Keepalive Function ........................................................................ 3-8
3.3 Displaying and Debugging GRE ........................................................................................ 3-9
3.4 Typical Configuration Examples of GRE ........................................................................... 3-9
3.5 GRE Troubleshooting ...................................................................................................... 3-11
Chapter 4 IPsec Configuration..................................................................................................... 4-1

4.1 IPsec Overview .................................................................................................................. 4-1
4.1.1 IPsec ....................................................................................................................... 4-1
4.1.2 Overview of Encryption Card .................................................................................. 4-2
4.1.3 IPsec Basic Concepts ............................................................................................. 4-2
4.1.4 Introduction to IPsec Multi-Instance ........................................................................ 4-6
4.1.5 IPsec on Comware.................................................................................................. 4-7
4.2 IPsec Configuration ........................................................................................................... 4-8
4.2.1 Defining ACL ........................................................................................................... 4-9
4.2.2 Defining an IPsec Proposal................................................................................... 4-10
4.2.3 Creating an IPsec Policy ....................................................................................... 4-13
ii
4.2.4 Configuring IPsec Policy Template ....................................................................... 4-21

4.2.5 Applying IPsec Policy Group to Interface.............................................................. 4-23
4.2.6 Disabling Next-Payload Field Checking................................................................ 4-23
4.2.7 Configuring IPsec Fragments Buffering ................................................................ 4-24
4.2.8 Configuring the Encryption Card (Optional) .......................................................... 4-25
4.3 Displaying and Debugging IPsec..................................................................................... 4-27
4.3.1 Displaying and Debugging over IPsec Module on Comware Platform ................. 4-27
4.3.2 Displaying and Debugging Encryption Card Information ...................................... 4-29
4.4 Typical IPsec Configuration Example .............................................................................. 4-32
4.4.1 Establishing SAs Manually.................................................................................... 4-32
4.4.2 Establishing ISAKMP SAs..................................................................................... 4-35
4.4.3 Implementing Encryption/Decryption and Authentication on Encryption Card ..... 4-38
4.4.4 Configuration Example of SA Setup Between a Firewall and the Virtual Address of a
VRRP Standby Group .................................................................................................... 4-41
4.4.5 IPsec/IKE Multi-Instance Configuration Example ................................................. 4-46
4.5 IPsec Troubleshooting ..................................................................................................... 4-50
Chapter 5 IKE Configuration ........................................................................................................ 5-1

5.1 IKE Overview ..................................................................................................................... 5-1
5.1.1 Brief Introduction to IKE .......................................................................................... 5-1
5.1.2 Preparation for IKE Configuration ........................................................................... 5-3
5.2 IKE Configuration............................................................................................................... 5-4
5.2.1 Introduction to IKE Configuration ............................................................................ 5-4
5.2.2 Setting a Name for the Local Security GW ............................................................. 5-4
5.2.3 Defining IKE Proposal ............................................................................................. 5-4
5.2.4 Configuring IKE Peer .............................................................................................. 5-8
5.2.5 Configuring Keepalive Timer................................................................................. 5-11
5.2.6 Disabling IKE DH Hardware Acceleration............................................................. 5-13
5.3 Displaying and Debugging IKE ........................................................................................ 5-13
5.4 Typical Configuration of IKE ............................................................................................ 5-14
5.4.1 Typical IKE Configuration Example....................................................................... 5-14
5.4.2 Typical IKE Aggressive Mode and NAT Traversal Configuration Example .......... 5-15
5.5 IKE Fault Diagnosis and Troubleshooting ....................................................................... 5-18
Chapter 6 DVPN Configuration .................................................................................................... 6-1

6.1 Introduction to DVPN ......................................................................................................... 6-1
6.1.1 Overview ................................................................................................................. 6-1
6.1.2 Basic DVPN Elements ............................................................................................ 6-1
6.1.3 Implementation........................................................................................................ 6-3
6.1.4 Basic Network Structure.......................................................................................... 6-4
6.1.5 Traditional VPN versus DVPN ................................................................................ 6-5
6.2 DVPN Configuration .......................................................................................................... 6-7
6.2.1 Basic DVPN Configuration ...................................................................................... 6-9
6.2.2 Configuring the Tunnel Interface........................................................................... 6-12
iii
6.2.3 Configuring a DVPN class..................................................................................... 6-15

6.2.4 Configuring a DVPN policy.................................................................................... 6-18
6.2.5 Displaying and Debugging DVPN ......................................................................... 6-21
6.3 DVPN Implementation ..................................................................................................... 6-22
6.3.1 NAT traversal ........................................................................................................ 6-22
6.3.2 GRE Cooperation .................................................................................................. 6-26
Chapter 7 BGP/MPLS VPN Configuration ................................................................................... 7-1

7.1 BGP/MPLS VPN Overview ................................................................................................ 7-1
7.1.1 BGP/MPLS VPN Model........................................................................................... 7-2
7.1.2 BGP/MPLS VPN Implementation............................................................................ 7-4
7.1.3 Introduction to Multi-Role Host Features ................................................................ 7-6
7.1.4 OSPF VPN Extension ............................................................................................. 7-6
7.1.5 Multi-AS BGP/MPLS VPN..................................................................................... 7-10
7.2 BGP/MPLS VPN Configuration........................................................................................ 7-14
7.2.1 Configuring CE ...................................................................................................... 7-14
7.2.2 Configuring PE ...................................................................................................... 7-15
7.2.3 Configuring P......................................................................................................... 7-29
7.3 Displaying and Debugging BGP/MPLS VPN................................................................... 7-29
7.4 BGP/MPLS VPN Configuration Example ........................................................................ 7-31
7.4.1 Integrated BGP/MPLS VPN Networking ............................................................... 7-31
7.4.2 Configuring BGP/MPLS VPN using GRE Tunnel ................................................. 7-37
7.4.3 Extranet Networking.............................................................................................. 7-39
7.4.4 Hub&Spoke Networking ........................................................................................ 7-44
7.4.5 CE Dual-Homed Networking ................................................................................. 7-49
7.4.6 Multi-Role Host Networking................................................................................... 7-55
7.4.7 OSPF Multi-Instance Sham Link Networking........................................................ 7-57
7.4.8 OSPF Multi-Instance CE Networking.................................................................... 7-62
7.4.9 Configuring Inter-Provider Backbones Option A ................................................... 7-63
7.4.10 Configuring Inter-Provider Backbones Option B ................................................. 7-76
7.4.11 Configuring Inter-Provider Backbones Option C................................................. 7-83
iv
H3C SecPath Series Security Products Chapter 1 VPN Overview
Chapter 1 VPN Overview
1.1 VPN Overview

Along with the increasingly wide application of the Internet, the virtual private network
(VPN) emerged to construct private networks on public networks. “virtual” here mainly
indicates that VPN is a kind of logical networks.
Employees travel around on business more and more frequently; foreign services and
customers are scattered more widely; cooperation is conducted with a growing number
of partners-all these are sound quite familiar to all the growing companies. More and
more companies therefore turn to the Internet for market promotion, sales, aftersales
services, and also for conducting training, cooperation and other counseling activities.
This provides a broad market for the application of VPN.
1.1.1 Features of VPN
z Different from a traditional network, VPN does not exist physically. It is a kind of
logical network, a virtual network formed through resources collocation employing
the current public network.
z Each VPN is only for a particular enterprise or group of users. For VPN users, VPN
is just like any traditional private network. As a kind of private network, VPN keeps
resources independent of the underlying network, meaning resources of each
VPN are normally inaccessible for other VPNs over the underlying network and
users outside this VPN. It also delivers adequate security, safeguarding the
internal information of VPN against external invasion.
z VPN is a kind of upper layer service but not simple. It establishes network
interconnection between private network users, including network topology inside
VPN, route calculation, joining and leaving of members, etc. Thus, VPN
technology is much more complicated, compared to common point-to-point
applications alike.
1.1.2 Benefits of VPN
VPN allows you to:

z Establish reliable and safe connection between remote users, oversea agencies,
partners, suppliers and company headquarters, ensuring security of data
transmission. This advantage is of special significance to the amalgamation of
E-business or financial network with communication network.
z Provide information communication over public networks, thus allowing
enterprises to connect with remote offices, staff traveling on business and
1-1
business partners at a low cost, while improving utility of network resources. This
will help Internet Service Providers (ISPs) increase profits.
z Add or delete users through software configuration rather than changing hardware
facilities, thus delivering great flexibility.
z Support mobile access of VPN users at any time in any place, thus meeting
growing mobile service demands.
z Create VPN with QoS (for example, MPLS VPN), providing differentiated services
for VPN users and obtaining more profits by pricing these services differently.
1.1.3 Structure of VPN network
VPN comprises a group of sites. A site might join one or more VPNs, but any two sites
are IP reachable only if they belong to the same VPN. According to its standard
definition, VPN with all its Sites coming from a single enterprise is called Intranet, and
cross-enterprise VPN is by contrast called Extranet.
Site 5
Site 2
Site 1
Site 4
VPN 1
VPN 3
Site 3
VPN 2
Figure 1-1 The composition of VPN
The above chart demonstrates the relationship between five sites and three VPNs.
z VPN1---Site2, Site4
z VPN2---Site1, Site3, Site4
z VPN3---Site1, Site5
1.2 Fundamental Technology of VPN

1.2.1 Basic Network Application of VPN
Take an enterprise as an example. Its intranet through VPN is shown in following figure.
1-2
Remote
Subscriber
PSTN/ISDN
POP Internet
PC POP
ISP IP
Frame Relay
ATM Corporate
POP
Headquarter
Cooperator
Internal Server
Figure 1-2 Diagram of VPN application
It can be seen that enterprise internal resource sharers can access local ISP at its POP
(Point of Presence) server via PSTN/ISDN network or local network and access the
internal resources of the company. With traditional WAN networking technology,
however, they need to be connected using dedicated lines to achieve the same
purpose. VPN allows remote end users and clients in other cities to access enterprise
internal resources without being authorized by their local ISPs, which is of great
significance for staffs on business trip and geographically scattered clients.
An enterprise can deploy VPN services simply by setting up a VPN-supported server
for resource sharing (for example, a Windows NT server or a router supporting VPN).
The resource sharers connect to local POP server via PSTN/ISDN or LAN before they
directly call the remote server (VPN server) of the enterprise. The call process is
completed by ISP network access server (NAS) and VPN server together.
1.2.2 Mechanism of VPN
PSTN/ISDN
VPN
Subscriber NAS VPN Server
Figure 1-3 Diagram of accessing VPN
As shown in the above figure, through PSTN/ISDN network, a subscriber accesses ISP
NAS. After NAS server recognizes that this is a VPN user by checking user name or
access number, it establishes a connection, which is called tunnel, to the user’s
destination VPN server. Then NAS encapsulates the user data into IP packets and
transmits it to the VPN server through this tunnel. Upon the receipt of this IP packet,
VPN server removes the encapsulation to get the original data. In the opposite direction,
the packet is handled likewise. On both sides of the tunnel, packets can be encrypted to
make other users on the Internet unable to access them, so they are safe and authentic.
For users, tunnels are only the logical extension of their PSTN/ISDN links and thus can
be operated like the physical links.
1-3
Tunnels are implemented using tunneling protocols. Tunneling protocols are divided
into layer 2 tunneling protocols and layer 3 tunneling protocols depending on at which
layer of OSI model tunnel is implemented.
I. Layer 2 tunneling protocols
Layer 2 tunneling protocols encapsulate PPP frames entirely into internal tunnels. The
existing layer 2 tunneling protocols include:
z PPTP (Point to Point Tunneling Protocol): Supported by companies like Microsoft,
Ascend, and 3Com and in OS of Windows NT 4.0 and its later versions. This
protocol supports tunneling encapsulation of PPP in IP networks. As a call control
and management protocol, PPTP uses an enhanced Generic Routing
Encapsulation (GRE) technology to provide the encapsulation service with flow
control and congestion control for transmitted PPP packets.
z L2F (Layer 2 Forwarding): Supported by Nortel and some other companies. It
supports the tunnel encapsulation for the higher-level link layer and physically
separates dial-up server and dial-up connection.
z L2TP (Layer 2 Tunneling Protocol): Drafted by IETF, Microsoft and other
companies. Absorbing the advantages of above two protocols, it is accepted by
most companies and has become a standard RFC. L2TP provides both dial-up
VPN service and leased line VPN service.
II. Layer 3 tunneling protocols
Both start point and end point of layer 3 tunneling protocol are in ISP. PPP session
terminates at NAS. Only layer 3 packets are carried in tunnels. The existing layer 3
tunneling protocols include:
z GRE (Generic Routing Encapsulation), which is used to encapsulate a network
layer protocol into another one.
z IPsec (IP security), which provides a complete architecture of data security on IP
networks by using several protocols rather than a single one, such as AH
(Authentication Header), ESP (Encapsulating Security Payload), and IKE (Internet
Key Exchange).
GRE and IPsec mainly apply in private line VPN.
III. Contrast between layer 2 tunneling protocols and layer 3 tunneling

protocols
Compared with layer 2 tunneling protocols, the advantages of layer 3 tunneling

protocols are their security, scalability and reliability. In terms of security, layer 2 tunnel
imposes great challenges to security of user networks and firewall technologies while
layer 3 tunnel does not, because layer 2 tunnel generally terminates at customer
premise equipment and layer 3 tunnel at ISP gateway.
1-4
Concerning scalability, layer 2 tunnel is not as efficient as layer 3 tunnel in transmission

due to the encapsulation of entire PPP frames. Besides, its PPP session runs through
the entire tunnel and terminates at customer premise equipment, and thus requires the
user-side gateway to store a large amount of PPP session status and information,
which may not only overload the system but also decrease the scalability. The
introduction of tunneling latency may incur such problems as PPP session timeout in
time sensitive LCP and NCP negotiations of PPP. On the contrary, layer 3 tunnel
terminates within ISP gateway, and PPP session terminates at NAS; thus user gateway
needs not to manage and maintain status of each PPP session, and thereby reduces
system load.
Normally, layer 2 tunneling protocols and layer 3 tunneling protocols are used
separately. The reasonable combination of two types of protocols, however, may
deliver better security and functions (for example, using L2TP and IPsec together).
1.3 Classification of VPN

IP VPN means emulating private line service of WAN (such as remote dial-up and DDN)
over IP networks (including the Internet or dedicated IP backbone). IP VPN is classified
as follows:
I. Classified by operation mode
1) CPE-based VPN (Customer Premises Equipment based VPN)

Users not only have to install expensive devices and special authentication tools, but
also maintain complex VPN (such as channel maintenance and bandwidth
management). Networking in this way features both high complexity and low service
scalability.
2) NBIP-VPN (Network-based VPN)
The maintenance of VPN (permitting users to conduct service management and control
to some extent) is conducted by ISP, and all functions are implemented at network
device side, so as to reduce users’ investment, reinforce the flexibility and scalability of
services, and bring new incomes to ISP.
II. Classified by service application
1) Intranet VPN
Intranet VPN interconnects points distributed inside an enterprise by making use of
public network. It is an extended or substitute form of traditional private network or
other enterprise network.
2) Access VPN
Access VPN allows remote users like staff traveling on business and remote small
offices to establish private network connections with the intranet and extranet of their
1-5
enterprise over a public network. Access VPN provides two types of connections:
client-initiated VPN connection and NAS-initiated VPN connection.
3) Extranet VPN
Extranet VPN extends an enterprise network to suppliers, cooperators and clients by
using VPN, allowing different enterprises to construct VPN over public networks.
III. Classified by networking model
1) VLL
Virtual Leased Line (VLL) is emulation to traditional leased line services. By emulating
leased line over IP networks, it provides asymmetric and low cost “DDN” service. From
the view of end users of VLL, it is similar to traditional leased lines.
2) VPDN
Virtual Private Dial Network (VPDN) means implementing virtual private network by
employing the dial-up function of public networks (such as ISDN and PSTN) and
access networks, to provide access service for enterprises, small ISPs, and mobile
businesspersons.
3) VPLS service
Virtual Private LAN Segment (VPLS) interconnects LANs via virtual private network
segments in virtue of IP public networks. It is an extension of LANs on IP public
networks.
4) VPRN
Virtual Private Routing Network (VPRN) interconnects headquarters, branches and
remote offices via network management virtual router in virtue of IP public networks.
There are two kinds of VPRN services: VPRN implemented using traditional VPN
protocol (IPsec, GRE, etc.) and VPRN by means of MPLS.
IV. Classified by working layer
1) L3VPN: including BGP/MPLS VPN, IPsec VPN, GRE VPN, etc.

2) L2VPN: including MPLS L2VPN in Martini mode, MPLS L2VPN in Kompella mode,
MPLS L2VPN in SVC mode, VPLS and static CCC configuration.
3) VPDN: including L2TP, PPTP, etc.
1-6
H3C SecPath Series Security Products Chapter 2 L2TP Configuration
Chapter 2 L2TP Configuration
2.1 Introduction to L2TP

2.1.1 VPDN Overview
Virtual Private Dial Network (VPDN) means implementing virtual private network by
employing the dial-up function of public networks (such as ISDN and PSDN) and
access networks, thus providing access service for enterprises, small ISPs and mobile
businessmen.
VPDN sets up safe virtual private networks in public networks for enterprises by making
use of special network encryption protocols. In this way, overseas agencies and
traveling staff of an enterprise can access the headquarters' network by making use of
encrypted virtual tunnels over public networks, while other users in public networks
have no access to internal resources of the enterprise network through virtual tunnels.
There are two VPDN implementation approaches:
1) NAS sets up tunnel with VPDN gateway by making use of a tunneling protocol. In
this way, users’ PPP connections are directly connected to enterprise’s gateway.
Protocols available now are L2F and L2TP. This approach has a great deal of
advantages: transparent tunnel setup process from the perspective of users,
network access with one login, user authentication and address assignment by
enterprise network without occupying public addresses, and support to a wide
range of platforms for network access. It requires however: a) NAS supporting the
VPDN protocol, and b) authentication system supporting VPDN attributes, and c)
router or special VPN server working as gateway.
2) Client sets up tunnel with VPDN gateway. In this way, client first creates
connection with the Internet, and then sets up a tunnel with gateway by using the
special client software (for example, L2TP client supported by Win2000). This
approach allows users to access network by whatever available means and
wherever they are without the intervention of ISP. The bad news is the limitation in
platform, meaning users need to install special software (usually Win2000
platform).
There are three types of VPDN tunneling protocols: PPTP, L2F, and L2TP, with L2TP
being most popular.
2-1
2.1.2 Introduction to L2TP Protocol
I. Protocol background
PPP defined a kind of encapsulation technology that allows the transmission of various
kinds of data packets on layer 2 point-to-point links. Meanwhile, PPP is performed
between users and NAS, with endpoint of layer 2 link and PPP session sticking on the
same hardware.
L2TP provides tunnel transmission for PPP link layer packets. It extents PPP model in
that it permits link endpoint of layer 2 and PPP session point staying at different devices
and allows information interaction by using packet switching network technologies. It
combines the advantages of PPTP and L2F. Therefore, it becomes the industrial
standard of IETF in layer 2 tunneling.
II. Typical L2TP network application
Figure 2-1 shows a typical network where VPDN is constructed using L2TP:
Remote user
PC LAC LNS
Internet
backbone netw ork
PSTN/ISDN
L2TPchannel
NAS
Remote user
internet server
Figure 2-1 Network diagram of typical VPDN application created by L2TP
In this figure, LAC stands for L2TP Access Concentrator, a switching network device
with the capability to process PPP and L2TP requests. Usually, LAC functions as
network access server (NAS) to provide access service to users by making use of
PSTN/ISDN. LNS stands for L2TP network server, a device functioning in the PPP
system as L2TP server.
LAC lies between LNS and remote system (remote users and remote branches) to
transmit packets between them, encapsulate packets from remote system in L2TP
protocol and send the encapsulated packets to LNS, and decapsulate packets from
LNS and send the remaining part to remote system. Local connection or PPP link can
be adopted between LAC and remote system, but PPP link is always involved in VPDN
applications. As one end of the L2TP tunnel, LNS is the peer device of LAC, and also is
the logic terminating point of PPP session transmitted in tunnel by LAC.
2-2
III. Technology details of L2TP protocol
1) Architecture of L2TP protocol
PPP Frame
L2TP Data message L2TP Control message
L2TP Data message L2TP Control tunnel

(unreliable) (reliable)
Packet transmission packet (UDP,……)
Figure 2-2 Architecture of L2TP protocol
The architecture of L2TP protocol shown above describes the relationship between
PPP frame, control tunnel and data tunnel. PPP frame is transmitted in unreliable L2TP
data channel. Control message is transmitted in reliable L2TP control channel.
Usually L2TP data is carried in UDP packets for transmission. L2TP registers the UDP
port 1701, but this port is only used for the tunnel setup at the early stage. L2TP tunnel
initiator selects an arbitrary port from available ones (unnecessarily being 1701) and
forwards packets to 1701 port of the receiver. After the receiver receives the packets, it
also selects a free port randomly (unnecessarily being 1701) and forwards packets
again to the specified port of the initiator. Thus, ports of the two sides are determined.
They will remain unchanged until the tunnel connection is disconnected.
2) Definitions of tunnel and session
There are two kinds of connections between LNS-LAC pairs: Tunnel connection and
Session connection. Tunnel connections define pairs of LNS and LAC while Session
connections are multiplexed in a Tunnel connection to present PPP sessions in it.
Several L2TP tunnels can be created between a LNS-LAC pair, which consist of a
control connection, and one or several Sessions. Session connections can be set up
only after tunnels are created successfully (including such information exchange as ID
protection, L2TP version, frame type, hardware transmission type, etc.). Each session
connection corresponds to a PPP data stream between LAC and LNS. Both control
messages and PPP data packets are transmitted in the tunnels.
L2TP uses Hello packets to check the connectivity of a tunnel. LAC and LNS forward
Hello packets to peer ends at regular intervals. If no response to Hello packet is
received in a certain period of time, the tunnel is disconnected.
3) Definitions of control message and data message
There are two kinds of messages in L2TP: control messages and data messages.
Control messages are used for the setup, maintenance and transmission control of
tunnel and session connections, while data messages are for PPP frame encapsulation
and transmission in tunnels. The transmission of control messages is reliable,
delivering flow and congestion control. On the contrary, the transmission of data
2-3
messages is unreliable, meaning it lacks mechanisms of retransmission, flow control,

and congestion control.
Control messages and data messages share the same type of packet headers. Tunnel
ID and Session ID are included in L2TP packet header, to identify different tunnels and
sessions. The packets with the same Tunnel ID but different Session IDs will be
multiplexed in the same tunnel. Tunnel ID and Session ID in the packet header are
assigned by peer ends.
IV. Two typical L2TP tunnel modes
The following figure shows the tunnel modes available between remote system or LAC
clients (hosts running L2TP) and LNS:
LAC client
LAC
Internet
LNS internet server

PSTN/ISDN
Frame Relay
Remote system LAC
or ATM
LNS internet server
Figure 2-3 Two typical L2TP tunnel modes
1) Initiated by remote dial-up user. Remote system dials in LAC via PSTN/ISDN. LAC
sends tunnel setup request to LNS through the Internet. Dial-up users’ addresses
are assigned by LNS. The authentication and accounting of remote dial-up users
can be accomplished either by LAC side as an agent or by LNS side directly.
2) Initiated directly by LAC users (local users who support L2TP). LAC users can
send tunnel setup request directly to LNS, without requiring an additional LAC
device after the public network address is assigned to LAC users. LAC users’
private network addresses are assigned by LNS.
V. Call setup flow of L2TP tunnel
Typical L2TP application network is as follows:
2-4
RADIUS Serv er RADIUS Serv er
IP netw ork IP netw ork
PSTN/ISDN WAN PC
PC SecPathA SecPathB
LAC LNS
PC
Figure 2-4 Typical L2TP application network
Call setup flow of L2TP tunnel is shown in the following figure:
LAC LNS
LAC RADIUS Serv er LNS RADIUS Serv er
PC
(1) Call Setup

(2) PPP LCP Setup
(3) PAP or CHAP authentication
(4) access request
(5) access accept
(6) Tunnel establishment
(7) PAP or CHAP authentication
(challenge/response)
(8) authentication passes
(9) user CHAP response, ppp
negotiation parameter (10) access request
(11) access accept
(12) CHAP authentication tw ice(challenge/response)

(13) access request
(14) access accept
(15) authentication passes
Figure 2-5 Call setup flow of L2TP channel
The following is the call setup process using L2TP tunnel:

1) The PC at user side initiates setup request;
2) The PC and LAC equipment negotiate PPP LCP parameters;
3) LAC performs PAP or CHAP authentication based on the information provided by
the PC;
2-5
4) LAC sends access request including VPN user's name and password to RADIUS
server for authentication;
5) RADIUS server authenticates this user and sends back access accept, such as
LNS address, after authentication is passed successfully; LAC is ready for
initiating a new tunnel request;
6) LAC initiates a tunnel request to the LNS address sent back by RADIUS server;
7) LAC informs LNS of “CHAP challenge” information, LNS sends back CHAP
response and its own CHAP challenge, and LAC sends back CHAP response;
8) Authentication passes successfully;
9) LAC transmits the information of CHAP response, response identifier and PPP
negotiation parameters to LNS;
10) LNS sends the access request to RADIUS server for authentication;
11) RADIUS server authenticates this access request and sends back a response if
authentication is successful;
12) If local mandatory CHAP authentication is configured at LNS, LNS will
authenticate the VPN user by sending CHAP challenge and the VPN user at PC
sends back responses;
13) LNS resends this access request to RADIUS for authentication;
14) RADIUS server re-authenticates this access request and sends back a response if
authentication is successful;
15) The authentication passes and the VPN user can use the internal resources of the
enterprise.
2.2 LAC Configuration

Concerning L2TP configuration, configuration of LAC side differs from that of LNS side.
This section mainly covers the configuration of LAC side. In configuration task list,
L2TP must be enabled and L2TP group must be created before any other functions can
be configured. For detailed introduction to related PPP configuration commands, refer
to the chapters and sections for them.
Configuration tasks at LAC side include:
z Enable L2TP (required)
z Create L2TP group (required)
z Set the condition triggering L2TP tunnel setup request and LNS addresses
(required)
z Set local name (optional)
z Set tunnel authentication and password (optional)
z Configure AVP hiding (optional)
z Set Hello interval in the tunnel.(optional)
z Set user name and password and configure user authentication (required)
z Disconnect Tunnel by force (optional)
z Enable/disable the flow control function of the tunnel (optional)
2-6
z Set L2TP session idle-timeout timer (optional)

z Configure the tunnel-hold function of L2TP (optional)
z Set the LAC to function as client (optional)
2.2.1 Enabling L2TP
Only after L2TP is enabled can L2TP functions on the firewall work normally. If L2TP is
disabled, the firewall cannot provide related functions even if parameters of L2TP have
been configured.
These configurations are compulsory on LAC side.
Table 2-1 Enable/disable L2TP
Operation Command
Enable L2TP l2tp enable
Disable L2TP undo l2tp enable
By default, L2TP is disabled.
Note:
When the tunnel is established or cannot be established due to authentication failure,
disable the L2TP function at the LAC side and then reenable it, if the tunnel cannot be
established:
z When the LAC serves as client end, you need to execute the undo l2tp-auto-client
enable command in virtual template interface view at the LAC side, and then
execute the l2tp-auto-client enable command to establish the tunnel.
z When the LAC does not serve as client end, that is, when a remote user dials to the
LAC, new connection should be set up at the remote end to establish the tunnel.
2.2.2 Creating L2TP Group
L2TP group needs to be created in order to fulfill related parameter configurations of

L2TP. It allows you not only to configure L2TP functions as needed but also to
implement one-to-one and one-to-many network applications between LAC and LNS.
L2TP groups are numbered separately on LAC and LNS, so LAC and LNS only need to
keep consistent in the configurations of the involved L2TP groups (such as remote
name of tunnel and start L2TP and LNS address).
2-7
Table 2-2 Create/delete L2TP group
Operation Command
Create L2TP group l2tp-group group-number
Delete L2TP group undo l2tp-group group-number
After a L2TP group is created, other configurations related to the L2TP group can be
performed in L2TP group view, for example, name of peer end, condition triggering
L2TP tunnel setup request and LNS address.
By default, no L2TP group is created.
2.2.3 Setting Condition Triggering L2TP Tunnel Setup Request and LNS
Address
A firewall will not send L2TP Tunnel setup request to some other devices (such as
firewall, router or LNS server) unless certain conditions are met. By configuring
decision making rule based on user information and specifying IP address of LNS, you
may allow the firewall to determine whether a user is a VPN user and initiate
connection with the LNS. Up to five LNS addresses can be configured, meaning LNS
backup is allowed. In normal operations, local firewall (LAC) sends Tunnel setup
request to the peer end (LNS) in the order in which LNS addresses are configured until
some LNS accepts the request. This LNS becomes the peer end of L2TP tunnel. An
L2TP Tunnel setup request can be triggered by full user name and domain name.
Perform the following configuration in L2TP group view.
Table 2-3 Set condition triggering L2TP Tunnel setup request and LNS address
Operation Command
start l2tp { ip ip-addr [ ip ip-addr] [ ip
Configure to check if the user is VPN
ip-addr] ... } { domain domain-name |
user and set IP address of LNS
fullusername user-name }
Cancel the Tunnel setup request
undo start
configuration
The parameters above have no default values and they can be configured as needed.
But at least one triggering condition must be configured for initiating L2TP Tunnel setup
request.
2-8
When the L2TP LAC starts a L2TP tunnel connection, the system checks whether the
L2TP group specified according to the complete user name exists. If the system does
not find the required L2TP group, the system continues to search for the required L2TP
group according to the domain name.
Note:
z If multiple LNSs are configured, because the PPP timeout time of different clients is
different, connections may not be set up between the LAC and the backup LNSs. So,
you are recommended to configure two LNSs at most.
z A firewall can serve both as LAC and LNS simultaneously. When a firewall serves
both as a LAC and an LNS, different usernames should be used; otherwise, L2TP
may function abnormally.
2.2.4 Setting Tunnel Name
A user can configure local tunnel name on LAC side. The tunnel name of LAC side
must keep in line with the remote name of tunnel configured on LNS side.
These configurations are optional on LAC side.
Table 2-4 Set local Tunnel name
Operation Command
Set local Tunnel name. tunnel name name
Restore the default local Tunnel name. undo tunnel name
By default, local tunnel name is the hostname of the firewall.
Note:
To establish a tunnel, an LNS should select a local L2TP group according to the tunnel
name of the LAC. If all L2TP groups share the same tunnel name, the LNS selects a
group that first meets the requirements to establish a tunnel. To establish multiple
tunnels, you need to set different tunnel names for the L2TP groups.
2-9
2.2.5 Setting Tunnel Authentication and Password
As needed, a user can decide whether to start tunnel authentication before creating
tunnel connection. Tunnel authentication request can be sent by either LAC side or
LNS side. If one end of a tunnel starts tunnel authentication, the other end must also
start tunnel authentication in order to set up the tunnel connection. In addition, both
ends must use the same password, which cannot be void. Otherwise, the local end will
disconnect the tunnel automatically. If tunnel authentication is disabled on both ends,
the consistency of password will be insignificant.
Table 2-5 Set Tunnel authentication and authentication password
Operation Command
Start Tunnel authentication. tunnel authentication
Disable Tunnel authentication. undo tunnel authentication
Set the password of Tunnel tunnel password { simple | cipher }
authentication. password
Restore the password of Tunnel
undo tunnel password
authentication to the default.
By default, tunnel authentication is enabled, with password of tunnel authentication

being null. For the sake of tunnel security, it is not suggested to disable tunnel
authentication.
2.2.6 Configuring AVP Hiding
L2TP uses attribute value pair (AVP) to transfer and negotiate some parameter
attributes. By default, AVP is transferred in simple text. For security, users can hide AVP
data in transmission by using the following configuration. AVP hiding only works when
both of the two ends use tunnel authentication.
Table 2-6 Configure AVP hiding
Operation Command
Enable AVP hiding tunnel avp-hidden
Restore the default AVP transfer mode undo tunnel avp-hidden
By default, AVP is transferred in simple text.
2-10
2.2.7 Setting Hello Interval in Tunnel
In order to check the connectivity of the tunnel between LAC and LNS, LAC and LNS
send Hello packets to each other periodically and the receiver will respond upon the
receipt of the packets. If LAC or LNS does not receive response from the peer end in a
specified interval, it will resend Hello packet and will regard the L2TP tunnel connection
has been disconnected if receiving no response after making three transmission
attempts. In this case, LAC and LNS need to set up a new tunnel connection.
This configuration is optional on LAC side.
Table 2-7 Set Hello interval in a tunnel
Operation Command
Set Hello interval in a tunnel. tunnel timer hello hello-interval
Restore the default Hello interval. undo tunnel timer hello
By default, Hello interval is 60 seconds. If this configuration is not performed on LAC

side, LAC will send Hello packet to the peer end at intervals of the default value.
2.2.8 Setting Username, Password and Local User Authentication
If you have configured local authentication when configuring AAA authentication on

LAC side, you also need to configure local username and password on this side.
LAC performs user authentication to determine whether a user is a valid VPN user by
comparing remote dial-in username and password with usernames and passwords
registered at the local end. It originates Tunnel setup request only upon successful
authentication. Otherwise, the user will be diverted to other kinds of services.
I. Configuring user name and password
Table 2-8 Configure a username and password
Operation Command
Configure a user name and password (in
local-user username
system view).
Delete the current setting (in system
undo local-user username
view).
Configure local user password (in local
password { simple | cipher } password
user view).
By default, no local username and password are configured at the LAC side.
2-11
II. Configuring PPP user authentication mode
Perform the following configuration in virtual template interface view.
Table 2-9 Configure/Cancel PPP user authentication mode
Operation Command
Configure a PPP user authentication ppp authentication-mode { chap |
mode. pap } [ call-in ] [ domain isp-name ]
Disable PPP user authentication. undo ppp authentication-mode
By default, the user authentication is not configured. The interface where you configure
local authentication must be the one connected to users.
III. Configuring a PPP domain user and an authentication scheme
Table 2-10 Configure a PPP domain user and an authentication scheme
Operation Command
Create an ISP domain and enter its view domain { isp-name | default { disable |
(in system view). enable isp-name } }
Delete the specified ISP domain (in
undo domain isp-name
system view.
Configure the local authentication
scheme for the PPP domain user (in ISP scheme local
domain view).
2.2.9 Disconnecting an L2TP Connection
A connection can be disconnected for one of these reasons: no user is present, fault
occurs on the network, or the administrator requests to do so.
Both LAC side and LNS side can start tunnel disconnection. After a tunnel is
disconnected, the control connection and sessions on it are cleared. This tunnel can be
set up when a new user dials in.
2-12
Table 2-11 Disconnect a connection
Operation Command
Disconnect a tunnel reset l2tp tunnel { name remote-name | id tunnel-id }
Disconnect a session reset l2tp session session-id
Disconnect a user reset l2tp user user-name user-name
2.2.10 Setting Flow Control Function of Tunnel
This configuration can enable/disable the flow control function on a tunnel.

Table 2-12 Set flow control function of a tunnel
Operation Command
Enable flow control function of a tunnel. tunnel flow-control
Disable flow control function of a tunnel. undo tunnel flow-control
By default, the flow control function of tunnels is disabled.
2.2.11 Setting the L2TP Session Idle-Timeout Timer
An L2TP session is disconnected automatically if the session is idle or no data is

transmitted or received on it for a specified period of time. You may set a session
idle-timeout timer to specify this idle period. This period can be 0 seconds, that is, never
expired.
Table 2-13 Set the L2TP session idle-timeout timer
Operation Command
Set the L2TP session idle-timeout timer session idle-time seconds
Disable the L2TP session idle-timeout timer undo session idle-time
By default, L2TP session idle-timeout timer never expires.
2.2.12 Configuring the Tunnel-Hold Function of L2TP
Normally, the LAC sets up a tunnel with the LNS only when receiving an L2TP session
request from a PPP user. This tunnel is automatically torn down after all PPP sessions
are disconnected.
2-13
For some applications that require fast connection setup, however, a tunnel must be
available beforehand so that the system can set up a session immediately after
receiving a PPP session request. To this end, the LAC and the LNS must always
maintain a tunnel connection even when no session is present on it.
Table 2-14 Configure the tunnel-hold function of L2TP
Operation Command
Enable the tunnel-hold function of L2TP tunnel keepstanding
Disable the tunnel-hold function of L2TP undo tunnel keepstanding
By default, the tunnel-hold function of L2TP is disabled.
Note:
To have the tunnel-hold function take effect, you must configure it on both LAC and
LNS.
After you configure the tunnel-tunnel function of L2TP, you can execute the start l2tp
tunnel command to start a tunnel connection.
Table 2-15 Start an L2TP tunnel connection
Operation Command
Start an L2TP tunnel connection start l2tp tunnel
2.2.13 Setting LAC to Function as Client
Normally, the L2TP client is the host that dials to the LAC, where the connection
between the user and the LAC is always PPP connection.
If the LAC is functioning as the client, the connection between the host and the LAC can
be an IP connection allowing the LAC to forward the IP packets from the host to the
LNS. This is equivalent to creating a virtual PPP user associated with multiple actual
users on the LAC and maintaining a permanent connection for it. The IP packets of all
these actual users are forwarded to the LNS through this virtual user.
To use the LAC as the client, you must add the following configurations in addition to
other LAC configurations:
2-14
z Create a virtual template interface

z Configure the parameters of the virtual template interface, including IP address,
PPP authentication mode, and username and password for PPP authentication
z Enable the LAC client to set up L2TP tunnel
Note:
When the LAC is functioning as the L2TP client, you must set the L2TP session
idle-timeout timer to 0 or disable it, preventing the session of the virtual user is
disconnected when no data is transmitted or received.
I. Creating a virtual template interface
Table 2-16 Create/delete a virtual template interface
Operation Command
interface virtual-template
Create a virtual template interface
virtual-template-number
Delete a virtual template interface
II. Configuring the parameters of the virtual template interface
Table 2-17 Configure the parameters of the virtual template interface
Operation Command
ip address { address mask |
Assign an IP address to the virtual ppp-negotiate | unnumbered
template interface interface interface-type
interface-number }
ppp authentication-mode { pap |
Configure a PPP authentication mode
chap }
Configure the username for CHAP
ppp chap user user-name
authentication
Configure the password for CHAP ppp chap password { simple | cipher }
authentication password
Configure the username and password ppp pap local-user user-name
for PAP authentication password { simple | cipher } password
2-15
III. Enabling/disabling the LAC client to set up L2TP tunnel
Table 2-18 Enable/disable the LAC client to set up L2TP tunnel
Operation Command
Enable the LAC client to set up L2TP tunnel l2tp-auto-client enable
Disable the LAC client to set up L2TP tunnel undo l2tp-auto-client enable
By default, the LAC client is disabled to set up L2TP tunnel.
2.3 LNS Configuration

In LNS configuration task list, L2TP must be enabled and L2TP group must be created
before any other functions can be configured. For detailed introduction to related
commands of PPP and Virtual-Template, refer to corresponding chapters and sections.
The major configuration tasks on LNS side include:
z Enable L2TP (required)
z Enable L2TP multi-domain function (optional)
z Create L2TP group (required)
z Create virtual template (required)
z Set the parameters for call receiving (required)
z Set local name (optional)
z Set tunnel authentication and password (optional)
z Set the transmission mode of AVP data (optional)
z Set Hello interval in the tunnel (optional)
z Configure mandatory local CHAP authentication (optional)
z Configure mandatory LCP renegotiation (optional)
z Set local address (required) and assigned address pool (optional)
z Set user name and password and configure user authentication (optional)
z Disconnect tunnel by force(optional)
z Set the flow control function of tunnel (optional)
z Configure the timeout time of L2TP session (optional)
2.3.1 Enabling L2TP
Only after L2TP is enabled can L2TP functions on the firewall work normally. If L2TP is
disabled, the firewall cannot provide related functions even if parameters of L2TP have
been configured.
These configurations are compulsory on LNS side.
2-16
Table 2-19 Enable/disable L2TP
Operation Command
Enable L2TP. l2tp enable
Disable L2TP. undo l2tp enable
By default, L2TP is disabled.
2.3.2 Enabling L2TP Multi-Domain Function
Only when L2TP multi-domain function is enabled can the firewall perform LNS for
several enterprises. L2TP multi-domain function enriches VPN networking. In section
2.5.3 “L2TP Multi-Domain Networking”, a brief configuration procedure is described.
In L2TP multi-domain applications, these configurations are compulsory at LNS side.
Table 2-20 Enable/disable L2TP multi-domain function
Operation Command
Enable L2TP multi-domain function. l2tpmoreexam enable
Disable L2TP multi-domain function. undo l2tpmoreexam enable
By default, L2TP multi-instance function is disabled.
2.3.3 Creating L2TP Group
L2TP group needs to be created in order to fulfill related parameter configurations of

L2TP. It allows you not only to configure L2TP functions on the firewall as needed but
also to implement one-to-one and one-to-many network applications between LAC and
LNS easily. L2TP groups are numbered separately on LAC and LNS, so LAC and LNS
only need to keep consistent in the configurations of the involved L2TP groups such as
remote name of tunnel, start L2TP and LNS address.
2-17
Table 2-21 Create/delete L2TP group
Operation Command
Create L2TP group. l2tp-group group-number
Delete L2TP group. undo l2tp-group group-number
After L2TP group is created, other configurations related to the L2TP group can be
performed in L2TP group view, for example, local name and remote name of tunnel.
By default, no L2TP group is created.
2.3.4 Creating Virtual Template
Virtual template is mainly used to configure parameters of virtual interface created

dynamically by the firewall in operation.
Table 2-22 Create/delete virtual template
Operation Command
Create a virtual template. interface virtual-template virtual-template-number
Delete the virtual template.
By default, no virtual template is created.
Note:
If the IP address unnumbered attribute is configured on a virtual template interface, and
the interface is engaged in a certain service, the L2TP function on this interface may
function abnormally.
2.3.5 Setting Parameters for Call Receiving
LNS can adopt different virtual template interfaces for receiving tunnel setup request
from different LACs. When receiving a tunnel setup request from an LAC, LNS needs to
check that the name of LAC is a valid remote name of tunnel before allowing it to create
the tunnel.
2-18
Table 2-23 Set parameters for call receiving
Operation Command
allow l2tp virtual-template
Set remote name of tunnel (L2TP group
virtual-template-number remote
not being 1).
remote-name [ domain domain-name ]
allow l2tp virtual-template

Set remote name of tunnel (L2TP group
virtual-template-number [ remote
being 1).
remote-name ] [ domain domain-name ]
Remove remote name of tunnel undo allow
When the group number of L2TP is 1 (the default L2TP group number), you do not need
to specify remote-name. If remote-name is specified in L2TP group view 1, L2TP group
1 will not be regarded as the default L2TP group.
Note:
z Only L2TP group 1 can be set as default group.
z Any device can initiates a tunnel setup request when L2TP group 1 (the default
group) is set.
z The start command and the allow command are mutually exclusive. After one is
configured, another one goes invalid automatically.
z When PPPoE client is used to trigger the tunnel between the LAC and LNS, you are
recommended to set the MTU value for the virtual template interface at the LNS side
to 1480 bytes.
z A firewall can serve both as LAC and LNS simultaneously. When a firewall serves
both as a LAC and an LNS, different usernames should be used; otherwise, L2TP
may function abnormally.
2.3.6 Setting Local Name
A user can configure local tunnel name on LNS side.

These configurations are optional on LNS side.
2-19
Table 2-24 Set local name
Operation Command
Set local name. tunnel name name
Restore the default value of local name. undo tunnel name
By default, local name is the hostname of the firewall.
2.3.7 Setting Tunnel Authentication and Password
As needed, a user can decide whether to start tunnel authentication before creating
tunnel connection. Tunnel authentication request can be sent by either LAC side or
LNS side. If one end of a tunnel starts tunnel authentication, the other end must also
start tunnel authentication in order to set up the tunnel connection. In addition, both
ends must use the same password, which cannot be void. Otherwise, the local end will
disconnect the tunnel automatically. If tunnel authentication is disabled on both ends,
the consistency of password will be insignificant.
Table 2-25 Set tunnel authentication and authentication password
Operation Command
Start tunnel authentication. tunnel authentication
Disable tunnel authentication. undo tunnel authentication
Set a password for tunnel tunnel password { simple | cipher }
authentication. password
Remove the password for tunnel
undo tunnel password
authentication.
By default, tunnel authentication is enabled, with the password being null. For the sake
of tunnel security, you are not recommended to disable tunnel authentication.
2.3.8 Setting Transfer Mode of AVP Data
AVP is adopted in L2TP protocol to move and negotiated some attribute parameters of
L2TP. By default, AVP is transferred in simple text. For security, users can hide these
AVP in transmission by using the following configuration. The function of hidden VAP
only works when both of the two ends use tunnel authentication.
2-20
Table 2-26 Set the transfer mode of AVP data
Operation Command
Configure hidden AVP data for transfer. tunnel avp-hidden
Restore default transfer mode of AVP. undo tunnel avp-hidden
By default, AVP is transferred in simple text.
2.3.9 Setting Hello Interval in Tunnel
In order to check the connectivity of the tunnel between LAC and LNS, LAC and LNS
send Hello packets to each other periodically and the receiver will respond upon the
receipt of the packets. If LAC or LNS does not receive response from the peer end in a
specified interval, it will resend Hello packet and will regard the L2TP tunnel connection
has been disconnected if receiving no response after making three transmission
attempts. In this case, LAC and LNS need to set up a new tunnel connection.
This configuration is optional on LNS side.
Table 2-27 Set Hello interval
Operation Command
Set Hello interval. tunnel timer hello hello-interval
Restore the default value of Hello interval. undo tunnel timer hello
By default, Hello interval is 60 seconds. If this configuration is not performed on LNS

side, LNS will adopt this default value to send Hello packet to the peer end periodically.
2.3.10 Enabling Mandatory Local CHAP Authentication
After LAC performs agent authentication on a user, LNS can authenticate the user
again. The user therefore undergoes authentication twice: once on LAC side and once
on LNS side. Only after both the two authentications succeed, can L2TP tunnel be
created.
In an L2TP network, LNS side authenticates users in three ways: agent authentication,
mandatory CHAP authentication, and LCP re-negotiation.
Among these three authentication approaches, LCP re-negotiation is of the first priority.
If both LCP re-negotiation and mandatory CHAP authentication are configured on LNS
side, L2TP will choose the former, adopting the authentication mode configured in the
associated virtual template.
2-21
If only CHAP authentication is configured, LNS will perform CHAP authentication on

users.
To perform mandatory CHAP authentication on LNS side, you must configure
username, password and user authentication and enable AAA on this side. Mandatory
local CHAP authentication is optional on LNS side.
Table 2-28 Enable mandatory local CHAP authentication
Operation Command
Enable mandatory local CHAP authentication. mandatory-chap
Disable local CHAP authentication. undo mandatory-chap
If neither LCP re-negotiation nor mandatory CHAP authentication is configured, LNS

will perform agent authentication on the user. In this case, LAC sends LNS all
authentication information received from the user as well as authentication mode
configured on LAC side. If you do not configured authentication mode for the virtual
template, the LNS side will accept the authentication result on LAC side.
When LNS adopts agent authentication, session is allowed to be created if
authentication mode configured in virtual template is PAP and the authentication
succeeds. If authentication mode configured in virtual template is CHAP and that
configured on LAC side is PAP, authentication fails and session cannot be correctly
created as the CHAP authentication level demanded by LNS is higher than PAP
authentication supplied by LAC.
Local end does not perform mandatory CHAP authentication by default.
2.3.11 Forcing LCP to Re-negotiate
For NAS-Initialized VPN, the user first performs PPP negotiation with NAS when PPP
session starts. If the negotiation passes, NAS initializes L2TP tunnel connection, and
transmits user information to LNS so that LNS can judge whether the user is legal or not
according to the received agent authentication information,
But in some cases (for example, authentication and accounting need performing on
LNS side simultaneously), required re-negotiation needs to be created between LNS
and the user, and agent authentication information on NAS side will be ignored.
The configuration of mandatory LCP re-negotiation is optional on LNS side.
2-22
Table 2-29 Enable/disable mandatory LCP re-negotiation
Operation Command
Enable mandatory LCP re-negotiation. mandatory-lcp
Disable mandatory LCP re-negotiation. undo mandatory-lcp
By default, LCP re-negotiation is not performed.

Despite LCP re-negotiation is enabled, LNS will not perform authentication on the user
if authentication is not configured in the associated virtual template. In this case, the
user is only authenticated once on LAC side, and the address from the global address
pool is assigned to the client directly.
2.3.12 Setting Local Address and Assigning Address Pool
After the L2TP tunnel connection between LAC and LNS is created, LNS should assign
IP addresses for VPN users from address pool. Before address pool is specified, you
must use the ip pool command in system view or domain view to define an address
pool. For detailed description about the ip pool command, refer to the “Security” part of
this manual. If LNS adopts agent authentication or mandatory CHAP authentication,
the system uses the address pool configured in domain view for address assignment; if
LNS adopts mandatory LCP re-negotiation, the system uses the domain address pool
for address assignment; if LNS adopts LCP re-negotiation and does not authenticate
users, and the system uses global address pool for address assignment.
On LNS side, local address configuration is required and address pool assignment is
optional.
Perform the following configuration in virtual template view.
Table 2-30 Set local address and assigned address pool
Operation Command
Set local IP address. ip address X.X.X.X netmask
Remove the local IP address. undo ip address X.X.X.X netmask
Specify an address pool for remote remote address { pool pool-number |
address assignment. X.X.X.X }
Delete the address pool for remote
undo remote address
address assignment.
If you do not assign a value to the pool-number parameter behind the keyword pool
when specifying an address pool, the system will use the default address pool for
assignment.
2-23
By default, addresses will be assigned to the peer end from address pool 0 (default
address pool).
2.3.13 Setting Username, Password and User Authentication
On LNS side, if mandatory CHAP authentication has been configured, it needs to

configure local registered username and password on LNS side.
LAC performs user authentication to determine whether a user is a valid VPN user by
comparing remote dial-in username and password with usernames and passwords
registered at the local end. If the authentication passes, the VPN user is allowed to
communicate with LNS; if it fails, L2TP will be notified to clear the L2TP connection.
These configurations are optional on LNS side. For more information on how to
configure them, refer to the section 2.2.8 “Setting Username, Password and Local
User Authentication.”
2.3.14 Disconnecting an L2TP Connection
A connection can be disconnected for one of these reasons: no user is present, fault
occurs on the network, or the administrator requests to do so.
Both LAC side and LNS side can start disconnection. After a tunnel is disconnected, the
control connection and sessions on it are cleared. This tunnel can be set up when a
new user dials in.
Table 2-31 Disconnect a connection by force
Operation Command
Disconnect a tunnel reset l2tp tunnel { name remote-name | id tunnel-id }
Disconnect a session reset l2tp session session-id
Disconnect a user reset l2tp user-name user-name
2.3.15 Enabling/Disabling Flow Control Function of Tunnel
This configuration can enable/disable the simple flow control function on a tunnel.
2-24
Table 2-32 Enable/disable flow control function of a tunnel
Operation Command
Enable flow control function of a tunnel tunnel flow-control
Disable flow control function of a tunnel undo tunnel flow-control
By default, the flow control function of tunnels is disabled.
2.3.16 Setting the L2TP Session Idle-Timeout Timer
An L2TP session is disconnected automatically if the session is idle or no data is

transmitted or received on it for a specified period of time. You may set a session
idle-timeout timer to specify this idle period. This period can be 0 seconds, that is, never
expired.
Table 2-33 Set the L2TP session idle-timeout timer
Operation Command
Set the L2TP session idle-timeout timer session idle-time seconds
Disable the L2TP session idle-timeout timer undo session idle-time
By default, L2TP session idle-timeout timer never expires.
2.3.17 Configuring EAD Support for L2TP
With this feature enabled, the endpoint admission defense (EAD) server will implement
security authentication on PPP users that have passed the access authentication. The
PPP users can access network resources normally after passing the security
authentication; otherwise, they can only access resources in the isolation zone.
Table 2-34 Configure PPP access control
Operation Command Description

interface
Enter VT interface view —
virtual-template number
Enable PPP access ppp access-control Required

control enable Disabled by default
Configure the packet-filter Optional

ppp access-control
fragment matching mode The fragment matching
match-fragments
for PPP users on the VT mode defaults to
{ normally | exactly }
interface normally.
2-25

Display access control display ppp
statistics of PPP users on access-control —
the VT interface { interface type number }
2.4 Displaying and Debugging L2TP

After performing the above configuration tasks, execute display commands in any view
to view the running status of L2TP configurations, and to verify the configuration effect.
The debugging commands can be used in user view.
Table 2-35 Display and debug L2TP
Operation Command
Display information about the current
display l2tp user
L2TP users
display l2tp tunnel
L2TP tunnels
display l2tp session
L2TP sessions
Enable all L2TP information debugging debugging l2tp all
Disable all L2TP information debugging undo debugging l2tp all
Enable L2TP control packet debugging debugging l2tp control
Disable L2TP control packet debugging undo debugging l2tp control
Enable PPP packet debugging debugging l2tp dump
Disable PPP packet debugging undo debugging l2tp dump
Enable L2TP error debugging debugging l2tp error
Disable L2TP error debugging undo debugging l2tp error
Enable L2TP event debugging debugging l2tp event
Disable L2TP event debugging undo debugging l2tp event
Enable hidden AVP debugging debugging l2tp hidden
Disable hidden AVP debugging undo debugging l2tp hidden
Enable L2TP payload debugging debugging l2tp payload
Disable L2TP payload debugging undo debugging l2tp payload
Enable L2TP time stamp debugging debugging l2tp time-stamp
Disable L2TP time stamp debugging undo debugging l2tp timestamp
2-26
2.5 L2TP Configuration Example

Both NAS and user end can initiate L2TP calls. They are illustrated separately as
follows.
2.5.1 NAS-initialized VPN Networking
A VPN user access company headquarters following the procedure below:

z User accesses the network in dialup mode.
z NAS performs authentication on this user, and then originates a tunnel setup
request to LNS if it is a VPN user.
z After establishing the tunnel with LNS, NAS sends packets to LNS, providing the
negotiated information between NAS and VPN users.
z LNS decides whether to accept the connection according to the pre-negotiated
information.
z User communicates with the company headquarters by using the tunnel between
NAS and LNS.
II. Network diagram
Internet
Async2
PSTN/ISDN tunnel Headquarters

NAS
VPN user LAC LNS
Figure 2-6 Network diagram for NAS-Initialized VPN
1) Configuration at user side

At the user end, type user name vpdnuser, password Hello and dialup number 170 in
dialup network window. Then type user name username, password userpass for
RADIUS authentication in dialup terminal window.
2) Configuration at NAS side
# On NAS, set the dial-in number to 170.
# On RADIUS access server, configure a VPN user with user name username and
password userpass, and set IP address for the corresponding LNS device (In this
example, IP address of the serial port connected with the tunnel at LNS side is
202.38.160.2.).
# Set local device name to LAC, adopt tunnel authentication, set tunnel authentication
password to tunnelpwd.
3) LNS configuration
2-27
# Set username and password (consistent with the configuration at user side).
[H3C] local-user vpdnuser
[H3C-luser-vpdnuser] password simple Hello
[H3C-luser-vpdnuser] service-type ppp
# Perform local authentication on VPN users.

[H3C] domain system
# Enable L2TP and set an L2TP group.

[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure a virtual template.

[H3C-virtual-template1] ip address 192.168.0.1 255.255.255.0
[H3C-virtual-template1] ppp authentication-mode chap domain system
[H3C-virtual-template1] remote address pool 1
# Configure local name and remote name of the tunnel at LNS side.
[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the password for it.

[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple tunnelpwd
2.5.2 Client-initialized VPN Networking
A VPN user accesses the headquarters following the procedure below:

It first accesses the Internet, and then originates a tunnel setup request to LNS.
After LNS accepts this connection setup request, VPN establishes a virtual tunnel with
LNS.
The traffic between the user and headquarters travels along the tunnel between the
VPN user and LNS.
2-28
II. Network diagram
SecPath
PSTN Internet Headquarters
VPN user NAS LNS
Tunnel
Figure 2-7 Network diagram for Client-Initialized VPN

Make sure that the user-side host is installed with L2TP client software, WinVPN Client
for example, and the user is connected to the Internet through a dial-up link before
proceeding to perform the following configuration tasks. (The configuration procedure
depends on the installed client software).
# Set VPN user name to vpdnuser and password Hello at user side.
# Set IP address of LNS to the Internet interface address of the firewall (In this example
IP address of the serial port connected with tunnel at LNS side is 202.38.160.2).
# Modify connection attributes. Set the protocol to L2TP, encryption attribute to user
defined. Choose CHAP authentication for tunnel authentication, with tunnel password
tunnelpwd.
2) LNS configuration
# Set username and password (consistent with the configuration at user side).
# Perform local authentication on VPN users.

[H3C] domain system

[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure a virtual template.

[H3C-virtual-template1] ppp authentication-mode chap domain system
2-29
# Configure remote name of the tunnel at LNS side.

[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1

2.5.3 L2TP Multi-Domain Networking
PC1 belongs to 263.net domain, and PC2 belongs to 163.net domain. Generally, users
cannot directly access the intranet of the enterprises via the Internet. However, by
creating multi-domain-supported VPN, different domain users can obtain IP addresses
with different ranges from LNS, thus can access the resources on the intranet.
II. Network diagram
SecPath1 SecPath2
PC1
Ethernet0/0/0
Internet
Tunnel
Ethernet1/0/0
LAC LNS
WAN
PC2
Figure 2-8 Network diagram for multi-domain L2TP

Set up a dial network, and accept addresses assigned by the LNS server to users.
On PC1, the user should type the user name vpdn1@263.net and the password 11111
in the dialup terminal window, supposing that the user name and password have been
registered with the LNS.
On PC2, the user should type the user name vpdn2@163.net and the password 22222
in the pop-up Dial Terminal Window, supposing that the user name and password have
been registered with the LNS.
2) SecPath1 (LAC) configuration
2-30
The Ethernet0/0/0 and Ethernet1/0/0 interfaces at LAC end in this example are for user
access. The IP address of the Ethernet0/0/1 interface is 202.38.160.1; that connecting
the tunnel at LNS end is 202.38.160.2.
# Set username and password.
<H3C> system-view
[H3C] local-user vpdn1
[H3C-luser-vpdn1] password simple 11111
[H3C-luser-vpdn1] service-type ppp
[H3C-luser-vpdn1] quit
# Adopt local authentication.

[H3C] domain 263.net
[H3C-isp-263.net] scheme local
[H3C-isp-263.net] quit
# Configure PPPoE server on the Ethernet0/0/0 and Ethernet1/0/0 interfaces.

[H3C-Ethernet0/0/0] pppoe-server bind Virtual-Template 100
[H3C-Ethernet1/0/0] pppoe-server bind Virtual-Template 101
# Configure IP address on Ethernet0/0/1

# Enable CHAP authentication on the virtual template.

[H3C-Ethernet0/0/1] interface Virtual-Template 100
[H3C-Virtual-Template100] ppp authentication-mode chap domain 263.net
[H3C-Virtual-Template100] interface Virtual-Template 101
[H3C-Virtual-Template101] quit
# Set two L2TP groups and configure the relevant attributes.

[H3C] l2tp enable
[H3C] l2tp-group 1
[H3C-l2tp1] tunnel name LAC
[H3C-l2tp1] start l2tp ip 202.38.160.2 domain 263.net
2-31
[H3C-l2tp1] l2tp-group 2
[H3C-l2tp2] start l2tp ip 202.38.160.2 domain 163.net

[H3C-l2tp2] tunnel password simple 12345
[H3C-l2tp2] quit
[H3C] l2tp-group 1
3) SecPath2 (LNS) configuration.
<H3C> system-view
[H3C] l2tp enable
[H3C] l2tpmoreexam enable
# Create two pairs of usernames and passwords.

# Create two address pools.

[H3C-isp-163.net] ip pool 1 202.38.161.10 202.38.161.100
[H3C-isp-263.net] ip pool 1 202.38.162.10 202.38.162.100
# Create two virtual templates.

[H3C]interface virtual-template 1
[H3C-Virtual-Template1] interface virtual-template 2
2-32

# Create two L2TP-groups correspondingly.

[H3C] l2tp-group 3
[H3C-l2tp3] allow l2tp virtual-template 1 remote LAC domain 163.net
[H3C-l2tp3] quit
[H3C] l2tp-group 4
[H3C-l2tp4] allow l2tp virtual-template 2 remote LAC domain 263.net
If the LSN side requires RADIUS authentication, you simply need to change the AAA
configuration in the configurations described above.
2.5.4 Using LAC as L2TP Client
The LAC-side firewall functions as L2TP client, setting up permanent connection with
LNS. All data from the connected private network is forwarded using the connection to
the LNS.
II. Network diagram
LAC LNS
VT1:192.168.0.1
Priv ate Priv ate
netw ork Internet netw ork
10.2.0.0 3.3.3.2 10.1.0.0
SecPathA SecPathB
Figure 2-9 Network diagram for using LAC as the L2TP client
Note:
This scenario describes only the configurations about VPN, assuming that the involved
public addresses and routes are correctly configured.
1) Configure LAC firewall.

# Set username and password.
2-33

[H3C-luser-vpdnuser] quit
# Enable L2TP and create an L2TP group.

[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure the local tunnel name and the IP address of LNS.

[H3C-l2tp1] start l2tp ip 3.3.3.2 fullusername vpdnuser
# Enable tunnel authentication and set the password.

[H3C-l2tp1] quit
# Configure virtual-template 1.
[H3C-virtual-template1] ip address ppp-negotiate
[H3C-virtual-template1] ppp authentication-mode pap
[H3C-virtual-template1] ppp pap local-user vpdnuser password simple Hello
[H3C-virtual-template1] quit
# Configure static routing to private network 10.1.0.0.

[H3C] ip route-static 10.1.0.0 16 virtual-template 1
2) Configure LNS firewall.
# Configure username and password.
# Configure the Ethernet0/0/1 interface.

# Configure the domain and address pool.

[H3C] domain system
[H3C-isp-system] quit

[H3C] l2tp enable
2-34
[H3C] l2tp-group 1
# Configure virtual template 1.

[H3C-virtual-template1] ppp authentication-mode pap
[H3C-virtual-template1] quit
# Configure the remote name of the receive tunnel.

[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the password.

[H3C-l2tp1] quit
# Configure static routing to private network 10.2.0.0.

[H3C] ip route-static 10.2.0.0 16 virtual-template1
3) Start L2TP connection
# Start L2TP connection in virtual template interface view on SecPath A.
[H3C-virtual-template1] l2tp-auto-client enable
Note:
LAC-side host and LNS-side host must be the gateways for their connected private
networks respectively.
2.5.5 Complex Network Design
SecPath Series Firewalls can serve as LAC and LNS at the same time, supporting
multiple simultaneous incoming calls. L2TP can receive and originate multiple calls as
long as memory and line resources are available. These complex network
requirements and their configurations can be implemented by referring to above cases.
Pay special attention to the configuration of static route, because many applications are
based on routing to originate calls.
2-35
2.6 L2TP Troubleshooting

The VPN tunnel setup process is quite complicated; only several common cases are
analyzed here. Before debugging VPN, please confirm that both LAC and LNS are
connected to a public network, and are connected correctly.
Symptom 1: User’s login fails.
Troubleshooting:
Failure causes are as follows:
z Fail to establish a tunnel because:
1) On LAC side, LNS addresses are improperly set.
2) On LNS side (usually is a firewall, or a router), L2TP group that can receive the
remote end of the tunnel is not configured. For details, refer to the description of
the allow command.
3) Tunnel authentication fails. If authentication is configured, make sure that the
same tunnel authentication password is configured at both sides.
4) If the local end compulsorily disconnects the connection but the opposite end fails
to receive the “Disconnect” packet due to some network transmission problem,
originating tunnel setup request without delay will fail in this case. The reason is
that both sides cannot detect the disconnected link within certain time, and the
tunnel connections originated by two opposite ends with the same IP address are
not allowed.
z PPP negotiation fails because :
1) Error occurs to username or password set on LAC side, or the corresponding
users are not set on LNS side.
2) LNS cannot assign addresses because the address pool is too small or no
address pool is set at all.
3) The types of tunnel password authentication are inconsistent. The default
authentication type of VPN connection created by Windows 2000 is MSCHAP. If
the peer end does not support MSCHAP, CHAP is recommended for substitution.
Symptom 2: Data transmission fails. After the connection is established, no data can be
transmitted, for example, the peer end cannot be pinged.
Troubleshooting: Possible causes are as follows:
z The address set by the user is wrong: Generally, it is up to LNS to assign
addresses, but a user can also designate his own address. If the designated
address and the address assigned by LNS are not in the same network segment,
this problem occurs. It is recommended that LNS assign addresses completely.
z Network congestion: Congestion occurs to the Internet backbone and packet loss
is serious. L2TP uses User Datagram Protocol (UDP) for transmission. Because
UDP lacks in error control mechanism, applying L2TP on an unstable line will
result in ping failures.
2-36
H3C SecPath Series Security Products Chapter 3 GRE Configuration
Chapter 3 GRE Configuration
3.1 Brief Introduction to GRE

I. GRE overview
Generic Routing Encapsulation protocol (GRE) can encapsulate datagrams of some

network layer protocols (such as IP and IPX) and allow these encapsulated datagrams
to be transferred in another network layer protocol (such as IP). GRE is a layer 3 tunnel
protocol of VPN, adopting a technique called Tunnel between protocol layers. Each
tunnel is a virtual point-to-point connection and can be regarded as a virtual interface
only supporting point-to-point connection in actual situation. The interface provides a
tunnel where encapsulated datagrams can be transmitted. And it can also encapsulate
and de-encapsulate datagrams at both ends of the tunnel.
To move in a tunnel, a packet must undergo the processes of encapsulation and
decapsulation, which are illustrated in Figure 3-1:
Nov ell IPX Nov ell IPX

Protocol Internet Protocol
Group1 Group2
Tunnel
SecPath A SecPathB
Figure 3-1 IPX network interconnection through GRE tunnel
1) The process of encapsulation

After receiving an IPX packet, the interface connected to Novell group1 first sends it to
IPX for processing. IPX decides how to route it by examining the destination address
field in its IPX header. If IPX finds that the packet should pass the network 1f (virtual
network number of the tunnel) in order to reach the destination, it delivers the packet to
the tunnel interface with the network number of 1f. After receiving the packet, the tunnel
interface performs GRE encapsulation before forwarding it to the IP module for
processing. After the IP header is encapsulated, the packet will be forwarded to the
appropriate network interface according to its destination address and the routing table.
2) The process of decapsulation
The process of decapsulation is contrary to that of encapsulation. The system
examines the destination address of each IP packet received from the tunnel interface;
if it is this firewall, the system removes the IP header of the packet and sends it to the
GRE module for processing (verifying key, checksum, and serial number of the packet,
etc.). After completing all the works, the GRE module removes the GRE header of the
packet and sends it to the IPX module where it is handled just as a common one.
3-1
When receiving a datagram that requires encapsulating and routing, called payload,
the system first adds a GRE header to the datagram to form a GRE packet. This GRE
packet is then encapsulated into an IP packet, thus allowing the IP layer to take full
charge of the forwarding of the packet. The IP protocol in this particular case is called
Delivery Protocol or Transport Protocol.
The format of an encapsulated tunnel packet is shown as follows:
Delivery Header
（Transport Protocol）
GRE Header
（Encapsulation Protocol）
Payload Packet
（Passenger Protocol）
Figure 3-2 Format of encapsulated tunnel packets
For instance, an IPX Delivery packet encapsulated in IP tunnel is as follows:
IP GRE IPX
Passenger Protocol
Encapsulation Protocol
（Carrier Protocol）
Transport Protocol
Figure 3-3 Format of Delivery packets in Tunnel
II. Application scope
GRE mainly provides services below:

1) Allowing a multi-protocol local network to make transmission through a
single-protocol backbone
Novell IPX Novell IPX

protocol protocol
Group1 Group2
Internet
IP protocol Tunnel IP protocol

Term 1 Term 2
SecPathA SecPathB
Figure 3-4 Multi-protocol local network that makes transmission through a

single-protocol backbone
3-2
In the above figure, Group1 and Group2 are the local networks employing the Novell
IPX protocol; Term1 and Term2 are the local networks running IP. By setting up a GRE
tunnel between SecPath A and SecPath B, you can allow Group1 to communicate with
Group2 and Term1 with Term2 without interfering with each other.
2) Expanding the operating area of networks running hop-limited protocols (such as
IPX)
SecPathA SecPathB
Tunnel
IP network IP network
Router Router
PC IP network PC
r r
Figure 3-5 Expanding network operating area
If the hop count between two terminals in the above figure is more than 15, the two
terminals cannot communicate with each other. By setting up a tunnel across the
network, some hops can be hidden, thus expanding the operating area of the network.
3) Connecting some discontinuous sub-networks to establish VPN
SecPathA SecPathB
IP netw ork nov ell

nov ell l
group 1 VLAN group2
Tunnel
Figure 3-6 Tunnel connecting discontinuous sub-networks
Sub-networks group1 and group2 running Novell IPX are in different cities but they can
form a VPN over WAN by using a tunnel.
4) The use in conjunction with IPsec
GRE Tunnel
IPSec Tunnel
Remote
Corporate
Internet office
intranet
netw ork
SecPathA SecPathB
Figure 3-7 GRE-IPsec tunnel application
3-3
As illustrated in the above figure, GRE can encapsulate multicast data and transmit the
data through the GRE tunnel. As provisioned, IPsec can only protect unicast data at
present. When transmitting such multicast data as routing protocol, voice and image in
an IPsec tunnel, you can set up a GRE tunnel, encapsulate the multicast data with GRE,
and then encrypt the encapsulated data using IPsec. Thus, data secrecy in
transmission can be achieved.
In addition, GRE also supports users to select and record identification key of tunnel
interface, and supports the end-to-end check of encapsulated message.
Due to the influence of such factors as encapsulation and decapsulation between GRE
sender and receiver and data increase caused by encapsulation, the use of GRE may
somewhat decrease the data forwarding efficiency of firewalls.
3.2 GRE Configuration

Among all the configuration tasks, virtual tunnel interface must be created first before
other function features can be configured on it. Deleting a virtual tunnel interface
deletes all configurations on it.
GRE configuration tasks include:
z Create virtual tunnel interface (required)
z Set encapsulation mode (optional)
z Specify source end of tunnel (required)
z Specify destination end of tunnel (required)
z Set network address of tunnel interface (required)
z Configure end-to-end verification on both ends of tunnel (optional)
z Set identification key of tunnel interface (optional)
z Configure routing via tunnel (optional)
3.2.1 Creating Virtual Tunnel Interface
Virtual tunnel interface should be created so that other parameters of GRE can be
configured on it. These configurations are required to be performed on both ends of the
tunnel.
Table 3-1 Create virtual tunnel interface
Operation Command
Create a virtual tunnel interface. interface tunnel number
Delete a virtual tunnel interface. undo interface tunnel number
By default, no virtual tunnel interface is created.
3-4
The device adopts distributed structure, on which interfaces are represented in a

three-dimension way, that is, slot/card/port. The parameter slot represents slot number
of the specified universal interface module; card represents the number of the installed
card, which can take on the value of 0 or 1; port represents the number of the specified
interface, ranging from 0 to 1023, but the actual number of created tunnels depends on
the total number of interfaces and available memory.
On creating Tunnel interface, it is recommended that the parameter slot should keep in
line with the slot of source end interface configured by the source command. In other
words, slot number specified by slot is the same as that of the actual physical interface
forwarding GRE packets, thus improving the forwarding efficiency.
3.2.2 Setting Encapsulation Mode
Encapsulation protocol and delivery protocol are to be configured on tunnel interface.

You may choose not to configure them on both ends of the tunnel, but if you do
configure them, make sure to use the same encapsulation mode on both ends (by far,
only GRE is available).
Perform the following configuration in tunnel interface view.
Table 3-2 Set encapsulation mode
Operation Command
Set encapsulation mode on the tunnel interface. tunnel-protocol gre
By default, encapsulation protocol is GRE, and delivery protocol is IP.
3.2.3 Specifying Tunnel Source
After the creation of a tunnel interface, the source address of the tunnel, that is, the
actual interface address where GRE packets are forwarded also needs to be specified.
A tunnel is uniquely identified by one source address and one destination address.
These configurations are required on both ends of the tunnel, with the source address
at one end being the destination address at the other end and vice versa.
Table 3-3 Specify source address of the tunnel
Operation Command
source { ip-addr | interface-type
Specify source address of the tunnel.
interface-num }
Delete the source address of the tunnel. undo source
3-5
Note:
z The same source address and destination address cannot be configured on two or
more tunnel interfaces encapsulated with the same protocol.
z The source command configures actual physical interface address or actual
physical interface. The network address of tunnel interface also needs configuring
by using the ip address command in tunnel interface view.
3.2.4 Specifying Tunnel Destination
After the creation of a tunnel interface, the destination address of the tunnel, that is, IP
address of the actual physical interface receiving GRE packets, also needs to be
specified. A tunnel is uniquely identified by one source address and one destination
address. These configurations are required on both ends of the tunnel, with the source
address at one end being the destination address at the other end and vice versa.
Table 3-4 Specify destination address of the tunnel
Operation Command
Set destination address of the tunnel. destination ip-addr
Delete the destination address of the tunnel. undo destination
Note:
The destination command sets IP address of actual physical interface. In order to
support dynamic routing protocols, network address of tunnel interface also needs
configuring.
3.2.5 Assigning Network Address to Tunnel Interface
You must assign addresses to the interfaces at the ends of a tunnel. The assigned
addresses can be private ones but they must belong to the same network segment.
Perform the following configuration in Tunnel interface view.
Table 3-5 Assign network address to a tunnel interface
Operation Command
ip address { ip-addr mask |
Assign an IP address to the tunnel
unnumbered interface interface-type
interface.
interface-number }
3-6
Operation Command
Delete the IP address of the tunnel
undo ip address
interface.
By default, network address of tunnel interface is not configured.
3.2.6 Configuring End-to-End Verification on Both Ends of Tunnel
As RFC1701 provisioned, if the Checksum Present bit in GRE header is set to 1, then
the checksum field is present and contains valid information. The sender calculates the
checksum according to GRE header and payload information and sends the packet
containing the checksum information to the peer end. The receiver calculates the
checksum of the received packet and compares it with the one in the packet. If they are
consistent, the packet that may be discarded otherwise will be further processed.
Checksum can be enabled or disabled on the two ends of a tunnel as needed. If
checksum is enabled only at the local end, the local end will calculate the checksum of
each transmitted packet but will ignore the checksum of received packets; on the
contrary, if checksum is enabled only at the remote end, the local end will verify the
checksum of each received packet but will ignore the checksum of transmitted packets.
Table 3-6 Enable/disable end-to-end verification on both ends of a tunnel
Operation Command
Enable end-to-end verification on both ends of the tunnel. gre checksum
undo gre
Disable end-to-end verification on both ends of the tunnel.
checksum
By default, end-to-end verification is disabled on both ends of tunnel.
3.2.7 Setting Identification Key of Tunnel Interface
RFC1701 provisions that if the Key Present bit in the GRE header of a packet is set to 1,
the tunnel identification key carried by the packet will be verified between the sender
and the receiver. The verification will fail if different identification keys are used, and the
packet will be discarded.
3-7
Table 3-7 Set identification key of the tunnel interface
Operation Command
Set identification key of the tunnel interface. gre key key-number
Cancel the identification key of tunnel interface. undo gre key
The key-number parameter is an integer in the range 0 to 4294967295.

By default, tunnel does not use KEY.
3.2.8 Configuring Routing via Tunnel
Tunnel route, either static or dynamic, must exist on both the source and destination
ends, so that GRE packets can be forwarded properly.
I. Configuring static routing
You may manually configure a route to the destination address, which is the destination
address of the packet without GRE encapsulation rather than the destination address
of the tunnel, with the next hop being the address of the remote tunnel interface
address. This configuration is required at both ends of the tunnel. For details about this
configuration, refer to the Routing Protocol module of this manual. For detailed
descriptions on the configuration commands, refer to the Command Manual
accompanying this manual.
II. Configuring dynamic routing
If dynamic routing protocol is running on the firewall, you may simply enable this
protocol on both the tunnel interface and the interface of the firewall directly connected
to the private network. This configuration is required on both ends of the tunnel. For
details about this configuration, refer to the Routing Protocol module of this manual. For
detailed descriptions on the configuration commands, refer to the Command Manual
accompanying this manual.
3.2.9 Configuring the Keepalive Function
Table 3-8 Configure the keepalive function
Operation Command
Enable the keepalive function of GRE. keepalive [ seconds [times] ]
Disable the keepalive function of GRE. undo keepalive
3-8
By default, the keepalive function of GRE is disabled; seconds is set to 10 and times to
3.
After you configure the keepalive command, the firewall sends GRE Keepalive packets
regularly through tunnel interface. If no response is received upon the expiration of a
specified period, the firewall resends the packet. If no response is received yet after the
number of resending attempts exceeds the specified limit, the protocol of the local
tunnel interface goes down.
3.3 Displaying and Debugging GRE

Upon the completion of the above configurations, execute the display command in any
view to view their running state and to verify the effect of the configurations. The
debugging command can be used in user view.
Table 3-9 Display and debug GRE
Operation Command
Display operating state of tunnel interfaces. display interface tunnel number
Enable tunnel information debugging. debugging tunnel
3.4 Typical Configuration Examples of GRE

Two subnets Group 1 and Group 2 run IP protocol and are connected through the
firewalls SecPath 1 and SecPath 2, which runs GRE protocol.
II. Network diagram
10.1.1.1/24 10.1.3.1/24
IP Internet IP
Group1 Group2
SecPath1 Tunnel1 Tunnel2 SecPath 2
192.13.2.1/24 131.108.5.2/24
Figure 3-8 Network diagram of GRE application
1) Configure firewall SecPath1.

# Configure interface Ethernet 0/0/0.
3-9

# Configure interface Serial 0/0/0 (physical interface of tunnel).

# Create interface Tunnel 1.

[H3C] interface tunnel 1
# Configure IP address of interface Tunnel 1.

[H3C-Tunnel1] ip address 10.1.2.1 255.255.255.0
# Configure encapsulation mode for the tunnel.

[H3C-Tunnel1] tunnel-protocol gre
# Configure source address of interface Tunnel1 (IP address of Ethernet1/0/0).

[H3C-Tunnel1] source 192.13.2.1
# Configure destination address of interface Tunnel1 (IP address of Ethernet2/0/1 on

SecPath2).
[H3C-Tunnel1] destination 131.108.5.2
[H3C-Tunnel1] quit
# Configure static route from SecPath1 to Group2 on interface Tunnel1.

[H3C] ip route-static 10.1.3.0 255.255.255.0 tunnel 1
2) Configure firewall SecPath2.
# Configure interface Ethernet 0/0/0.
# Configure interface Ethernet 2/0/1 (physical interface of Tunnel).

# Create interface Tunnel 2.

[H3C] interface tunnel 2
# Configure IP address for interface Tunnel2

[H3C-Tunnel2] ip address 10.1.2.2 255.255.255.0
# Configure encapsulation mode of the tunnel.

[H3C-Tunnel2] tunnel-protocol gre
# Configure source address of interface Tunnel 2 (IP address of Ethernet 2/0/1).
3-10
[H3C-Tunnel2] source 131.108.5.2
# Configure destination address of interface Tunnel 2 (IP address of Ethernet 1/0/0 on

SecPath1).
[H3C-Tunnel2] destination 192.13.2.1
[H3C-Tunnel2] quit
# Configure static route from SecPath2 to Group 1 via interface Tunnel2.

[H3C] ip route-static 10.1.1.0 255.255.255.0 tunnel 2
3.5 GRE Troubleshooting

GRE configuration is relatively simple, except that you should pay more attention to the
consistency. Most errors can be located by executing the debugging tunnel command.
Here, only one type of error is analyzed, as shown in the following figure:
SecPath1 SecPath 3 SecPath 2
PC A PC B
Ethernet1/0/0 Ethernet2/0/ 1 10.2.1.1/16
10.1.1.1/ 16 Tunnel
Tunnel0 Tunnel0
Figure 3-9 Troubleshooting example of GRE
Symptom 1: The interfaces at both ends of the tunnel are correctly configured and both
ends of the tunnel can “ping” each other successfully, but PC A and PC B fail to do so.
Troubleshooting: Perform the following steps:
z In user view, perform the display ip route command on SecPath1 and SecPath2
respectively, making sure there is the route from interface Tunnel1/0/0 to
10.2.0.0/16 on SecPath1, and the route from interface Tunnel 2/0/0 to 10.1.0.0/16
on SecPath2.
z If the needed static route do not exist in the output information of the above step,
perform the ip route command in system view to add it. Taking SecPath1 for
example, make the following configuration:
[H3C] ip route-static 10.2.0.0 255.255.0.0 tunnel 1/0/0
3-11
H3C SecPath Series Security Products Chapter 4 IPsec Configuration
Chapter 4 IPsec Configuration
4.1 IPsec Overview

4.1.1 IPsec
IP security (IPsec) protocol family is a series of protocols defined based on IETF. It

provides high quality, interoperable and cryptology-based security for IP data packets.
The two sides of communication perform encryption and data source authentication on
IP layer to assure confidentiality, data integrity, data origin authentication and
anti-replay for packets when they are being transmitted on networks.
Note:
Confidentiality is to encrypt a client data and then transmit it in cipher text.
Data integrity is to authenticate the received data so as to determine whether the
packet has been modified.
Data origin authentication is to authenticate the data source to make sure that the data
is sent from a real sender.
Anti-replay is to prevent some malicious client from repeatedly sending a data packet.
In other words, the receiver will deny old or repeated data packets.
IPsec implements the above aims via Authentication Header (AH) security protocol and
Encapsulating Security Payload (ESP) security protocol. Moreover, Internet Key
Exchange (IKE) provides auto-negotiation key exchange and Security Association (SA)
setup and maintenance services for IPsec so as to simplify the use and management of
IPsec.
z AH mainly provides data source authentication, data integrity authentication and
anti-replay. However, it cannot encrypt the packet.
z ESP provides encryption function besides the above functions that AH provides.
However, its data integrity authentication does not include IP header.
Note:
AH and ESP can be used either independently or corporately. There are two types of
working modes for AH and ESP: transport mode and tunnel mode, which will be
introduced later.
4-1
z IKE is to negotiate the cryptographic algorithm applied in AH and ESP and to

automatically establish SAs and perform key exchange.
Note:
IPsec policy and algorithm can also be negotiated manually. So IKE negotiation is not
necessary. The comparison of these two negotiation modes will be introduced later.
4.1.2 Overview of Encryption Card
IPsec may use ESP or AH protocol to process packets. For high security purpose,
complicated encryption/decryption and authentication algorithms are often used. The
IPsec on a firewall uses many CPU resources for encryption/decryption algorithm, so
the overall performance may be degraded. To solve this problem, you can insert an
encryption card for a modularized firewall, on which IPsec operations are processed by
hardware. This can improve IPsec processing efficiency, as well as overall
performance of a firewall.
1) Encryption/decryption process on the encryption card: The firewall sends data to
be encrypted or decrypted to the encryption card. The card runs
encryption/decryption operations and add/delete encryption headers to/from data,
and then sends the processed data back to the firewall for forwarding.
2) For the IPsec SA implemented by the encryption card, if the card is faulty, backup
function is enabled on the card and the selected encryption/authentication
algorithms for the SA are supported by the IPsec module on Comware platform,
IPsec shall be implemented by the IPsec module on Comware platform. But you
cannot use one encryption card as the backup to another card.
Note:
The encryption card processes data in the same mechanism as the IPsec module on
the Comware platform. The only difference is that the card uses hardware, while the
IPsec module uses software.
4.1.3 IPsec Basic Concepts
I. Security association
IPsec provides security communication between two ends, which are called as IPsec
peers.
4-2
IPsec allows systems, network subscribers or administrators to control granularity of

security services between peers. For instance, IPsec policies of some group prescribe
that data flow from some subnet should be protected over AH and ESP and be
encrypted over Triple Data Encryption Standard (3DES) simultaneously. Moreover, the
policies prescribe that data flow from another site should be protected over ESP only
and be encrypted via DES only. IPsec can provide security protection in various levels
for different data flows based on SA.
SA is essential to IPsec. It is the standard for some elements of communication peers.
For example, it determines which protocol should be applied (AH, ESP or both) as well
as the working mode (transport mode or tunnel mode), encryption algorithm (DES and
3DES), shared protecting key in some stream and SA duration.
As SAs are unidirectional, at least two SAs are needed to protect data flow from two
directions in a bi-directional communication. Moreover, if both AH and ESP are applied
to protect data flow between peers, still two SAs are needed for AH and ESP
respectively.
SA is identified by a triplet uniquely, including Security Parameter Index (SPI),
destination IP address and security protocol ID (AH or ESP). SPI is a 32-bit number
generated for uniquely identifying SA. It is transmitted in AH/ESP header.
SA has duration. It is calculated as follows:
z Time-based duration is to update SA at a specific interval;
z Traffic-based duration is to update SA after certain data (bytes) transmission.
II. Working mode of IPsec protocol
IPsec protocol falls into two working modes: transport mode and tunnel mode. They are
specified in SA.
In the transport mode, AH/ESP is inserted after the IP header but before all
transmission layer protocols or all other IPsec protocols. In the tunnel mode, AH/ESP is
inserted before the original IP header but after the new header. The data encapsulation
format for various protocols (taking the transmission protocol TCP as an example) in
the transmission/tunnel mode is shown in the following figure:
Mode
transport tunnel
Protocol
AH IP TCP data new IP raw IP TCP data

Header AH Header Header AH Header Header
ESP IP TCP data ESP ESP new IP raw IP TCP ESP

data ESP
Header ESP Header Tail Auth data Header ESP Header Header Tail Auth data
AH-ESP IP TCP data ESP ESP new IP raw P

I TCP ESP
AH ESP data ESP
Header Header Tail Auth data Header AH ESP Header Header Tail Auth data
Figure 4-1 Data encapsulation format for security protocols
4-3
The tunnel mode is safer than the transport mode. It can authenticate and encrypt
original IP data packets completely. Moreover, it can hide the client IP address via the
IPsec peer IP address. On the other hand, the tunnel mode occupies more bandwidth
than the transport mode because it has an extra IP header. Therefore, you can select a
proper mode according to the practical need on security or performance.
III. Authentication algorithm and encryption algorithm
1) Authentication algorithm
Both AH and ESP can authenticate integrity for an IP packet so as to determine
whether the packet is modified. The authentication algorithm is implemented via hybrid
function. The hybrid function is a kind of algorithm that does not limit the length of
inputting messages and outputs messages in a certain length. The output message is
called as message summary. IPsec peers calculate the packet via the hybrid function
respectively. If they get identical summaries, the packet is integrated and not modified.
Generally speaking, there are two types of IPsec authentication algorithms.
z MD5: Input a message in any length and generate a 128-bit message summary.
z SHA-1: Input a message less than 264-bit and generate a 160-bit message
summary.
Because the SHA-1 summary is longer than that of MD5, SHA-1 is safer than MD5.
2) Encryption algorithm
ESP can encrypt IP packets so that the contents of the packets will not let out during the
transmission. Encryption algorithm is implemented by encrypting or decrypting data
with identical key via symmetric key system. Comware implements three types of
encryption algorithm.
z DES(Data Encryption Standard): Encrypt a 64-bit simple text via a 56-bit key.
z 3DES (Triple DES): Encrypt a simple text via three 56-bit keys (168 bits key).
z AES (Advanced Encryption Standard): 128-bit 192-bit and 256-bit AES algorithm,
conforming to IETF standards, can be implemented on Comware.
IV. Negotiation mode
There are two negotiation modes to establish SA: manual mode (manual) and IKE
auto-negotiation mode (isakmp). The former is a bit complex because all information
about SA has to be configured manually. Moreover, it does not support some advanced
features of IPsec, such as key update timer. However, its advantage is that it can
implement IPsec independent of IKE. The latter one is much easier because SA can be
established and maintained by IKE auto-negotiation as long as security policies of IKE
negotiation are configured.
Manual mode is feasible in the case of few peer devices or in a small-sized static
environment. For middle/big-sized dynamic environment, IKE auto-negotiation mode is
recommended.
4-4
V. IPsec DPD
IPsec dead peer detection (IPsec DPD) is a function that allows on-demand IKE peer
liveliness detection on IPsec/IKE tunnels.
The idea of DPD is that when an IKE peer receives no packets from its peer for a
specified period, a DPD query is triggered. The IKE peer sends a query to its peer
detecting the liveliness asking for proof of liveliness.
Compared with other keepalive mechanisms available with IPsec, DPD generates less
traffic, but allows more prompt detection and quicker tunnel recovery.
In the scheme using internet security association and key management protocol
security association (ISAKMP SA) established between a router address and a virtual
address of a virtual router redundancy protocol (VRRP) backup group, DPD can
recover rapidly and automatically security tunnels when the master and slave
switchover in a virtual router redundancy protocol (VRRP) backup group. DPD avoids
security tunnels from interrupting when the master and slave switchover, expands the
IPsec application scope, and makes the IPsec protocol more robust.
DPD is implemented in compliance with RFC3706 and RFC2408.
1) Timers
IPsec DPD uses the following two timers to control sending and receipt of DPD
packets:
z Interval-time: specifies the idle interval for triggering a DPD query. If an IKE peer
receives no IPsec packet from its peer when this timer times out, DPD query is
triggered.
z Time-out: specifies the time waiting for a DPD acknowledgement.
2) Operating mechanism
The following describes how DPD operates after being enabled:
z At the sender side
An IKE peer does not receive IPsec packets from its peer when interval-time timer
expires and now, it wants to send IPsec packets to its peer. Before that, the IKE peer
sends a DPD query to its peer for proof of liveliness. At the same time, a time-out timer
is started. If no acknowledgement is received upon expiration of this timer, DPD records
one failure event. When the number of failure events reaches three, the involved
ISAKMP SAs and IPsec SAs are deleted.
The same applies to the IPsec SAs set up between a router and the virtual address of a
VRRP standby group: when the failure count reaches three, the security tunnel
between them is deleted. The setup of this security tunnel is triggered only when a
packet matching the IPsec policy is present.
The failover duration depends on the setting of time-out timer. A shorter timer setting
means a shorter communication interruption period but increased overheads.
You are recommended to use the default setting in normal cases.
4-5
z At the responder end

The peer of the sender sends an acknowledgement after receiving the query.
Caution:
If the IKE SA corresponding to IPsec SA has been updated, when a DPD query is
triggered, the DPD query will not take effect, and the IPsec SA will be deleted. DPD
functions again only after a new IKE negotiation is triggered and a new IPsec SA
corresponding to the updated IKE SA is established.
4.1.4 Introduction to IPsec Multi-Instance
IPsec multi-instance function means the MPLS PE and CE can be bound. That is,
IPsec tunnels are set up between the PE and CE. The different interfaces of the PE are
connected to different CEs. Therefore the CEs belonging to different VPNs can set up
IPsec tunnels with the PE respectively, consequently making networking more flexible.
IPSec Tunnel1
VPN ID=1
VPN1-CE1 PE
VPN ID=2
IPSec Tunnel2
VPN2-CE2
Figure 4-2 Network diagram for IPsec multi-instance application
Packets are processed as follows:

z When forwarding an IP packet to the CE, the PE determines the VPN the packet
belongs to, searches the corresponding VPN routing table, and forwards the
packet to the corresponding outgoing interface according to the VPN ID in the
packet. If you configure IPsec policy on the outgoing interface, the PE encrypts the
packet matching the ACL and sends the packet to the CE.
When receiving the IPsec packet, the PE decrypts the packet first (the PE does not
decrypt non-IPsec packets), then determines the VPN which the packet belongs to
according to the VPN ID of the packet, and searches the corresponding VPN routing
table to determine whether the IP address of the PE is the destination IP address of the
packet. If the destination is the PE, the packet is delivered to the IP layer for processing
4-6
(or is forwarded to another CE belonging to the same VPN). If the destination is not the
PE, the packet is encapsulated in a tag according to the VPN routing table
specification.
4.1.5 IPsec on Comware
Comware implements the said aspects of IPsec.

Via IPsec, peers (here refer to the firewall where Comware locates as well as its peer)
can perform various security protections (authentication, encryption or both) on
different data flows, which are differentiated based on ACL. Security protection
elements, such as security protocol, authentication algorithm, encryption algorithm and
operation mode, are defined in IPsec proposal. The association between data flows
and IPsec proposal (namely, apply a certain protection on a certain data flow) together
with SA negotiation mode, peer IP address configuration (i.e., the start/end of
protection path), the required key as well as the duration of SA are defined in IPsec
policies. Finally, IPsec policies are applied on interfaces of the firewall. This is the
process of IPsec configuration.
Following is the detailed description:
1) Defining data flows to be protected
A data flow is an aggregation of a series of traffics, regulated by source address/mask,
destination address/mask, number of protocol over IP, source port number and
destination port number. An ACL rule defines a data flow, that is, traffic that matches an
ACL rule is a data flow logically. A data flow can be a single TCP connection between
two hosts or all traffics between two subnets. IPsec can apply different security
protections on different data flows. So the first step of IPsec configuration is to define
data flows.
2) Defining IPsec proposal
IPsec proposal prescribes security protocol, authentication algorithm and encryption
algorithm as well as operation mode (namely, the packet encapsulation mode) for data
flows to be protected.
AH and ESP supported by Comware can be used either independently or corporately.
AH supports MD5 and SHA-1 authentication algorithms. ESP supports MD5 and
SHA-1 authentication algorithms as well as DES, 3DES and AES encryption algorithms.
Working mode supported by Comware includes transport mode and tunnel mode.
As for a data flow, peers should be configured with identical protocol, algorithm and
working mode. Moreover, if IPsec is applied on two firewalls (such as between
Comware firewalls), the tunnel mode is recommended so as to hide the real source and
destination addresses.
Therefore, you should define an IPsec proposal based on requirements so that you can
associate it with data flows.
4-7
3) Defining IPsec policy or IPsec policy group

IPsec policy specifies a certain IPsec proposal for a certain data flow. An IPsec policy is
defined by “name” and “sequence number” uniquely. It falls into two types, manual
IPsec policy and IKE negotiation IPsec policy. The former one is to configure
parameters such as key, SPI as well as IP addresses of two ends in the tunnel mode
manually. As for the latter one, these parameters are automatically generated by IKE
negotiation.
An IPsec policy group is an aggregation of IPsec policies with identical name but
different sequence numbers. In an IPsec policy group, the smaller the sequence
number is, the higher the priority is.
4) Applying IPsec policies on an interface
Apply all IPsec policies in a group on an interface so as to perform different security
protections on different data flows passing the interface.
4.2 IPsec Configuration

I. Configuring IPsec
1) Configure ACL
2) Configure a security proposal
z Create a security proposal (IPsec proposal or card SA proposal)
z Specify the encryption card used in the card SA proposal (only applies to
encryption cards)
z Select security protocol
z Select security algorithm
z Select packet encapsulation mode
3) Create security policy (manually or by using IKE)
For manual mode:
z Create security policy
z Import ACL into security policy
z Configure starting and end points for tunnel
z Configure SPI for SA
z Configure SA keys
For IKE mode:
z Create security policy using IKE
z Import card SA proposal into security policy
z Import ACL into security policy
z Import IKE peer into security policy
z Configure SA duration (optional)
z Configure PFS feature for negotiation (optional)
A security policy can reference an IPsec proposal or card SA proposal as needed.
4-8
4) Configure security policy template (optional)

5) Apply security policy on the interface
6) Disable next-payload field checking (optional)
II. Configuring the encryption card (optional)
1) Enable the encryption card

2) Enable Comware main software backup
3) Configure the fast forwarding function of the encryption card
4) Configure the simple network management operations for the encryption card
4.2.1 Defining ACL
IPsec uses the advanced ACL to determine which packets need to be protected. The
role of the advanced ACL in IPsec is different from what introduced in firewalls.
Normally, advanced ACL is used for determining which data can be permitted and
which must be denied on which interface. Advanced ACL in IPsec, however, is used by
IPsec to determine which packet needs security protection and which does not. For this
reason, advanced ACL applied in IPsec is in fact encryption ACL. Packets permitted by
Encryption ACL will be in protection, while packets denied by the ACL will not be
protected. An encryption ACL can apply on both input interfaces and output interfaces.
For more information about ACL configuration, see the Security part of this manual.
The negotiation succeeds only after you configure the mirror of the sender’s ACL to be
the subset of the receiver’s ACL, or ACLs of both ends to be the mirror of each other.
You are recommended to adopt the second configuration. Refer to the following
example.
Local end:
acl number 3101
rule 1 permit ip source 173.1.1.0 0.0.0.255 destination 173.2.2.0 0.0.0.255
Peer end:
acl number 3101
rule 1 permit ip source 173.2.2.0 0.0.0.255 destination 173.1.1.0 0.0.0.255
Note:
IPsec protects the data flow permitted in the ACL, therefore, the users are
recommended to configure the ACL accurately, that is, to configure permit only to the
data flow that needs IPsec protection so as to avoid the excessive use of the keyword
any.
4-9
Executing the display acl all command will display all the ACLs, including all the
advanced IP ACLs regardless whether they are for communications filtering or for
encryption. Simply speaking, the system does not discriminate the advanced ACLs for
these two purposes in the output information of this command.
4.2.2 Defining an IPsec Proposal
An IPsec proposal saves the particular security protocol and the

encryption/authentication algorithms applied in IPsec, intending for providing security
parameters for IPsec to make SA negotiation. To ensure the success of a negotiation,
the two ends involved in the negotiation must use the same IPsec proposal.
Perform the following tasks to configure a security proposal.
z Create an IPsec or card SA proposal
z Specify the encryption card in the card SA proposal (only applied when an
encryption card is involved)
z Select packet encapsulation mode
z Select a security protocol
z Select a security algorithms
I. Creating an IPsec or card SA proposal
An IPsec proposal is a set of security protocol, algorithms and packet encapsulation

format used to implement IPsec protection. An IPsec policy can determine the adopted
security protocol, algorithms, and encapsulation mode by referencing one or more
IPsec proposals. Before an IPsec proposal is referenced by IPsec policy, this IPsec
proposal must be established.
You are allowed to modify an IPsec proposal, but such modifications cannot take effect
at all if the modified proposal is applied to an SA that has been setup between the two
sides after negotiation – unless you execute the reset ipsec sa (or reset encrypt-card
sa) command to reset the SA. New security proposals can only apply to new SAs.
Table 4-1 Configure an IPsec proposal
Operation Command
Create an IPsec proposal and access
the IPsec proposal view (for IPsec ipsec proposal proposal-name
module)
Delete the IPsec proposal (for IPsec
undo ipsec proposal proposal-name
module)
Create a card SA proposal and access
ipsec card-proposal proposal-name
its view (for encryption cards only )
4-10
Operation Command
Delete the card SA proposal (for undo ipsec card-proposal
encryption card) proposal-name
By default, no security proposal is configured.
II. Specifying the encryption card to be used by a security proposal (only

applied when an encryption card is involved)
When an encryption card is used, you must specify its slot number in card SA proposal
view; each card can be assigned to multiple encryption card security proposals. In
system view, use the ipsec card-proposal proposal-name command to enter
encryption card SA proposal view, and then specify the encryption card to be used by a
security proposal in this view.
Table 4-2 Assign an encryption card to the card SA proposal
Operation Command
Enter the encryption card SA proposal view ipsec card-proposal proposal-name
Assign an encryption card to the card SA
use encrypt-card slot-id
proposal
Remove the configuration undo use encrypt-card
By default, no encryption card is used in the card SA proposal.
III. Selecting packet encapsulation mode
You MUST specify encapsulation mode in a security proposal. In addition, the same
encapsulation mode MUST be adopted at the two ends of a security tunnel.
Perform the following configuration in IPsec proposal or card SA proposal view.
Table 4-3 Select a packet encapsulation mode
Operation Command
Set the IP datagram encapsulation encapsulation-mode { transport |
mode adopted by the security protocol. tunnel }
Restore the default encapsulation mode. undo encapsulation-mode
Normally, tunnel mode is always adopted between two security GWs (routers).
Transport mode is always preferred, however, with respect to the communication
between two hosts or between a host and a security GW.
By default, tunnel mode is adopted.
4-11
IV. Selecting security protocol
The security protocol needs specifying in the IPsec proposal and by far AH and ESP
are the only two options. You are allowed to use AH, ESP, or both, but the choice must
be the same as that at the remote end of the security tunnel.
Table 4-4 Select security protocol
Operation Command
Configure security protocol used by
transform { ah | ah-esp | esp }
IPsec proposal
Restore default security protocol undo transform
By default, esp (defined by RFC 2406) applies.
V. Selecting security algorithm
Different security protocols may use different authentication and encryption algorithms.
Currently AH supports the MD5 and SHA-1 authentication algorithms, while ESP
supports the MD5 and SHA-1 authentication algorithms and the DES, 3DES and AES
encryption algorithms.
Table 4-5 Select security algorithm
Operation Command
Configure encryption algorithm used by esp encryption-algorithm { 3des | des
ESP | aes }
Configure undo packet encrypting for
undo esp encryption-algorithm
ESP
Configure authentication method used esp authentication-algorithm { md5 |
by ESP sha1 }
Configure undo packet authentication
undo esp authentication-algorithm
for ESP
Configure authentication method used ah authentication-algorithm { md5 |
by AH protocol sha1 }
Restore AH protocol default
undo ah authentication-algorithm
authentication method
ESP will allow encryption and authentication process for packet at the same time, or
encryption only or process authentication only. Attention, undo esp
authentication-algorithm command will not restore authentication method to the
default, but configure authentication method as null, i.e., undo authentication-method.
4-12
When encryption algorithm is null, undo esp authentication-algorithm command is

invalid. AH protocol has no encrypting function and can only perform authentication for
packets. undo ah authentication-algorithm command is used to restore AH protocol
default authentication method as md5. On both ends of security tunnel, the IPsec
proposals referenced by IPsec policy must be configured with the same authentication
method and encryption algorithm.
ESP protocol supports three types of encryption algorithms: des, 3des and aes, and
two authentication algorithms: hmac-md5 and hmac-sha1.
AH protocol supports two types of authentication algorithms: hmac-md5 and
hmac-sha1.
By default, encryption algorithm used by ESP is des and authentication method used is
md5. Authentication method used by AH protocol is md5.
Note:
Only when the desired security protocol is selected with the transform command, can
security algorithm be configured. For example, if you can select ESP, you can only
configure those security algorithms particular to ESP, excluding those for AH.
4.2.3 Creating an IPsec Policy
IPsec policy specifies a certain IPsec proposal for a certain data flow. An IPsec policy is
defined by “name” and “sequence number” uniquely. It falls into two types, manual
IPsec policy and IKE negotiation IPsec policy. The former one is to configure
parameters such as key, SPI and SA duration as well as IP addresses of two ends in
the tunnel mode manually. As for the latter one, these parameters are automatically
generated by IKE negotiation.
Note:
This section introduces configurations about IPsec policy in detail, including manual
configuration and IKE negotiation configuration. Configuration for one mode will be
followed by a special description. Otherwise, the configuration should be performed in
both manual mode and IKE negotiation mode.
I. Manually creating an IPsec policy
1) Manually creating an IPsec policy
4-13
You are not allowed to modify the negotiation mode of an IPsec policy that has been
created. For example: If manual IPsec policy is established, it cannot be revised into
isakmp mode, and you have to delete this IPsec policy before establishing a new one.
Table 4-6 Establish IPsec policy
Operation Command
Manually create an IPsec policy for an ipsec policy policy-name seq-number
SA. manual
ipsec policy policy-name seq-number
Modify the IPsec policy of the SA.
manual
undo ipsec policy policy-name
Delete the IPsec policy
[ seq-number ]
IPsec policies with the same name and different sequence numbers can compose an
IPsec policy group. In one IPsec policy group, up to 500 IPsec policies can be
configured. However, the maximum number of all IPsec policies in all IPsec policy
groups is 500. In an IPsec policy group, the smaller the sequence number is, the higher
the priority will be.
By default, there is no IPsec policy.
2) Referencing IPsec proposal in IPsec policy
IPsec policy will specify security protocol algorithm and packet encapsulation format by
referencing IPsec proposal. Before an IPsec proposal is referenced, this IPsec
proposal must be configured.
Table 4-7 Use IPsec proposal in IPsec policy
Operation Command
Configure IPsec proposal referenced by proposal proposal-name1
IPsec policy [ proposal-name2... proposal-name6 ]
Remove IPsec proposal referenced by
undo proposal [ proposal-name ]
IPsec policy
The Security Association can be established through manual mode. One IPsec policy
can reference only one IPsec proposal. If IPsec proposal has been configured, the
former IPsec proposal must be removed so as to configure new IPsec proposal. On
both ends of security tunnel, IPsec proposals referenced by the IPsec policy must be
configured by using the same security protocol, algorithm and packet encapsulation
mode.
3) Configuring ACL referenced in IPsec policy
4-14
IPsec policy will reference access control list. IPsec will specify which packet needs
security protection and which does not according to the rules in this access control list.
Packets permitted by ACL will be in protection, while packets denied by ACL will not be
protected.
Perform the following configuration in IPsec policy view.
Table 4-8 Configure access control list referenced by IPsec policy
Operation Command
Configure access control list referenced by IPsec policy security acl acl-number
Remove access control list referenced by IPsec policy undo security acl
One IPsec policy can reference only one ACL. If the IPsec policy has referenced more
than one ACL, only the last configured one is valid.
As for a manually established IPsec policy, only one ACL rule can be protected in
standard mode. That is, only the packet that first matches this ACL can be protected,
while the packets that match other rules of this ACL will not be protected.
4) Configuring tunnel start/end point
Generally, tunnels applying IPsec policies are called “security tunnels”. A security
tunnel is set up between the local and the peer GWs. To ensure the success in security
tunnel setup, you must configure correct local and peer addresses.
Table 4-9 Configure tunnel start/end point
Operation Command
Configure local address in the IPsec policy tunnel local ip-address
Delete the local address configured in the
undo tunnel local
IPsec policy
Configure peer address in the IPsec policy. tunnel remote ip-address
Delete the peer address configured in the
undo tunnel remote [ ip-address ]
IPsec policy.
With respect to an IPsec policy set up manually, only if both local and peer addresses
are correctly configured, can a security tunnel be set up. (As ISAKMP SA can
automatically obtain local and peer addresses, it does not require the configuration of
local or peer address.
5) Configuring SA SPI
This configuration task only applies to a manually created IPsec policy. Use the
following command to configure SA SPI for manually creating an SA. An isakmp-mode
4-15
IPsec policy does not need manual configuration and IKE will automatically negotiate
SPI and create SA.
Table 4-10 Configure an SA SPI
Operation Command
Configure an SA SPI. sa spi { inbound | outbound } { ah | esp } spi-number
Delete the SA SPI. undo sa spi { inbound | outbound } { ah | esp }
When configuring an SA for the system, you must set the parameters in the inbound
and outbound directions separately.
The SA parameters set at both ends of the security tunnel must be fully matched. The
SPI and key in the inbound SA at the local must be the same as those in the outbound
SA at the remote. Likewise, the SA SPI and key in the outbound SA at the local must be
the same as those in the inbound SA at the remote.
6) Configuring key for SA
This configuration is used only for manual mode IPsec policy. Security association key
can be input manually by using the following commands. (For isakmp negotiation
IPsec policy, manual configuration for key is not required. IKE will automatically
negotiate security association key.)
Table 4-11 Configure key used by security association
Operation Command
Configure AH protocol authentication
key sa authentication-hex { inbound |
outbound } { ah | esp } hex-key
(input in hex form)
Configure protocol key sa string-key { inbound | outbound }
(input in character string) { ah | esp } string-key
Configure ESP encryption key sa encryption-hex { inbound |

(input in hex form) outbound } esp hex-key
undo sa string-key { inbound |

outbound } { ah | esp }
Delete configured security association undo sa authentication-hex { inbound
parameter | outbound } { ah | esp }
undo encryption-hex { inbound |
outbound } esp
4-16
On both ends of security tunnel, configured Security Association parameters must be

consistent. Security association SPI and shared secret input on local end must be the
same as peer output Security Association SPI and shared secret. Security association
SPI and shared secret output on local end must the same as those input on peer end.
For the character string key and hex string key, the last configured one will be adopted.
On both ends of security tunnel, shared secret should be input in the same form. If
shared secret is input in character string on one end and in hex on the other end, the
security tunnel cannot be correctly established.
II. Creating an IPsec policy by using IKE
Following are the configuration tasks for creating an IPsec policy by using IKE.
z Create an IPsec policy by using IKE
z Reference an IPsec proposal in the IPsec policy
z Configure ACL referenced by the IPsec policy
z Referencing an IKE peer in the IPsec policy
z Configure the lifetime of an SA (optional)
z Configure the PFS feature in negotiation (optional)
z Configure IPsec DPD (optional)
1) Creating an IPsec policy by using IKE
Table 4-12 Create an IPsec policy
Operation Command
Create an IPsec policy by using IKE and ipsec policy policy-name seq-number
access the IPsec policy view. isakmp
Dynamically create an IPsec policy by ipsec policy policy-name seq-number
using IKE and an IPsec policy template. isakmp [ template template-name ]
Modify an IPsec policy that has been ipsec policy policy-name seq-number
established by using IKE negotiation isakmp
undo ipsec policy policy-name
Delete the specified IPsec policy.
[ seq-number ]
If you want to create a dynamic IPsec policy by making use of an IPsec policy template,
you must first define the policy template. For more information about defining a policy
template, see section 4.2.4 “Configuring IPsec Policy Template.”
2) Referencing an IPsec proposal in the IPsec policy
An IPsec proposal is referenced in an IPsec policy to specify IPsec protocol, algorithms,
and packet encapsulation mode. Before an IPsec proposal can be referenced, it must
have been created.
4-17
Table 4-13 Reference an IPsec proposal in the IPsec policy
Operation Command
Reference an IPsec proposal in the proposal proposal-name1
IPsec policy. [ proposal-name2... proposal-name6 ]
Remove the IPsec proposal referenced
undo proposal [ proposal-name ]
by the IPsec policy.
In the event of setting up an SA by making use of IKE (isakmp) negotiation, each IPsec
policy can reference up to six IPsec proposals. When making an IKE negotiation, the
systems at the two ends of the security tunnel will look up the configured IPsec
proposals for a match. If no match is found, the setup attempt of SA will fail and the
packets requiring protection will be dropped.
3) Referencing ACL in the IPsec policy
IPsec policy will reference an ACL to specify which packet needs security protection
and which does not according to the rules in this access control list. Packets permitted
by ACL will be in protection, while packets denied by ACL will not be protected.
Table 4-14 Reference ACL in the IPsec policy
Operation Command
Reference an ACL in the IPsec policy security acl acl-number
Remove the ACL referenced by the IPsec policy undo security acl
One IPsec policy can reference only one ACL. If the IPsec policy has referenced more
than one ACL, only the last configured one is valid.
4) Referencing an IKE peer in the IPsec policy
In IKE negotiation mode, these parameters such as peer, SPI and key can be obtained
through negotiation, so you only need to associate IPsec policy with IKE peer. The IKE
peer must be established before being referenced.
Table 4-15 Reference an ACL in the IPsec policy
Operation Command
Reference an IKE peer in the IPsec policy. ike peer peer-name
Remove the referenced IKE peer from the IPsec undo ike peer
policy. [ peer-name ]
4-18
Note:
This section only discusses importing IKE peer for IPsec, but in practice other
parameters also need to be configured in IKE Peer view, including IKE negotiation
mode, ID type, NAT traversal, shared key, peer IP address, peer name etc. Refer to the
next chapter for such details.
5) Configuring SA duration (lifetime) (optional)

a. Configuring global SA lifetime
All the SAs that have not been configured separately with a lifetime in IPsec policy view
adopt the global lifetime. In the SA negotiation via IKE, the lifetime configured at the
local or at the peer will be adopted, whichever is smaller.
There are two types of lifetime: “time-based" lifetime and “traffic-based” lifetime. The
expiration of either type of lifetime will render an SA useless. Before it goes invalid, IKE
will negotiate to set up a new SA for IPsec. Thus, when the old SA becomes fully invalid,
a new one is available.
Table 4-16 Configure a global SA lifetime
Operation Command
ipsec sa global-duration { traffic-based
Configure a global SA lifetime.
kilobytes | time-based seconds }
undo ipsec sa global-duration
Restore the default global SA lifetime.
{ traffic-based | time-based }
Changing the configured global lifetime does not affect the IPsec policies that have
separate lifetimes or the SAs that have been set up. The changed global lifetime will
apply to the IKE negotiation initiated later.
Lifetime is not significant to manually established SAs but isakmp mode SAs. In other
words, a manually established SA will maintain permanently.
b. Configuring SA lifetime in IPsec policy view
You can configure a separate SA lifetime for an IPsec policy. If such a lifetime is not
available, the global SA lifetime will apply.
In the SA negotiation via IKE, the lifetime configured at the local or at the peer will be
adopted, whichever is smaller.
4-19
Table 4-17 Configure an SA lifetime
Operation Command
Configure an SA lifetime for the IPsec sa duration { traffic-based kilobytes |
policy. time-based seconds }
undo sa duration { traffic-based |
Adopt the configured global SA lifetime.
time-based }
Changing the configured global lifetime does not affect the SAs that have been set up.
The changed global lifetime will apply to the IKE negotiation initiated later.
6) Configuring the PFS feature in negotiation (optional)
Perfect Forward Secrecy (PFS) is a security feature. With it, keys are not derivative, so
the compromise of a key will not threaten the security of other keys. This feature is
implemented by adding the process of key exchange in the stage-2 negotiation of IKE.
This command is only significant to isakmp mode SAs.
Table 4-18 Set the PFS feature used in negotiation
Operation Command
Configure the PFS feature used in pfs { dh-group1 | dh-group2 |
negotiation. dh-group5 | dh-group14 }
Disable PFS in negotiation. undo pfs
When IKE initiates a negotiation by using an IPsec policy configured with the PFS
feature, it will make a key exchange operation. In the event that the local adopts PFS,
the peer must also adopt PFS. The local and the peer must specify the same
Diffie-Hellman (DH) group; otherwise, the negotiation between them will fail.
The group2 provides a security level higher than group1 (the group5 provides a
security level higher than group2, and the rest may be deduced by analogy),, but it
needs longer time for calculation.
By default, PFS feature is not configured.
7) Configuring IPsec DPD (optional)
z Creating a DPD structure
4-20
Table 4-19 Create a DPD structure and enter its view
Operation Command
Create a DPD structure and enter its view ike dpd dpd-name
Delete the specified DPD structure undo ike dpd dpd-name
A DPD data structure, or a DPD structure, contains DPD query parameters, such as
interval-time timer and time-out timer. A DPD structure can be referenced by multiple
IKE peers. Thus, you need not to configure one DPD structure for each interface. If a
DPD structure has been referenced by an IKE peer, it cannot be deleted.
z Configuring timers
Perform the following configuration in DPD structure view.
Table 4-20 Configure timers
Operation Command
Configure the interval for triggering a DPD query interval-time seconds
Restore the default interval for triggering a DPD query undo interval-time
Configure the time waiting for a DPD acknowledgment time-out seconds
Restore the default time waiting for a DPD
undo time-out
acknowledgment
By default, the interval for triggering a DPD query is 10 seconds, and the time waiting
for a DPD acknowledgment is five seconds.
z Specifying a DPD structure for an IKE peer
Perform the following configuration in IKE peer view.
Table 4-21 Specify a DPD structure for an IKE peer
Operation Command
Specify a DPD structure for the IKE peer dpd dpd-name
Remove the referenced DPD structure undo dpd
4.2.4 Configuring IPsec Policy Template
When creating the IPsec policy using IKE, you can configure the IPsec policy in IPsec
policy view directly. Besides, you can create the IPsec policy by using IPsec policy
template. In this case, you need to configure all IPsec policies in IPsec policy template
first.
4-21
The configuration of IPsec policy template is similar to common IPsec policy: first, you
need create a policy template, then, template parameters can be specified.
Table 4-22 Configure IPsec policy template
Operation Command
ipsec policy-template template-name
Create/Modify IPsec policy template
seq-number
undo ipsec policy-template
Delete an IPsec policy template
template-name [ seq-number ]
Using IPsec policy-template command, you will enter the IPsec policy template view, in
which you can specify the policy template related parameters.
Note:
The parameters configurable in an IPsec policy template are the same as those of
IPsec policy, but most are optional. Only IPsec proposal and IKE peer (you do not need
to configure the remote IP address in IKE peer) are mandatory. However, it should be
noted that the proposal parameters are mandatory while other parameters are optional.
In IKE negotiation, if IPsec policy template is used for policy matching, the configured
parameters must be matched and the parameters not configured use those of the
initiation side.
After the configuration of policy template, the following command must be executed to
apply the policy template just defined.
Table 4-23 Reference IPsec policy template
Operation Command
ipsec policy policy-name seq-number
Reference an IPsec policy template
isakmp template template-name
When using the IPsec policy template to create the IPsec policy, you cannot configure
or modify the IPsec policy in IPsec policy view, while you can do so in IPsec policy
template view.
4-22
Caution:
The policy of IPsec policy template cannot initiate the negotiation of security
association, but is can response a negotiation.
4.2.5 Applying IPsec Policy Group to Interface
In order to validate a defined SA, you must apply an IPsec policy group at the interface
(logical or physical) where the outgoing data or incoming data needs encryption or
decryption. Data encryption on the interface will be made based on the IPsec policy
group and in conjunction with the peer firewall. Deleting the IPsec policy group from the
interface will disable the protection function of IPsec on the interface.
Table 4-24 Use IPsec policy group
Operation Command
Use the IPsec policy group ipsec policy policy-name
Remove the IPsec policy group in use undo ipsec policy [ policy-name ]
An interface can only use one IPsec policy group. Only ISAKMP IPsec policy group can
be used on more than one interface. A manually configured IPsec policy group can only
be used on one interface.
When packet transmitted from an interface, each IPsec policy in the IPsec policy group
will be searched according to sequence numbers in ascending order. If an access
control list referenced by the IPsec policy permits a packet, the packet will be
processed by this IPsec policy. If the packet is not permitted, keep on searching the
next IPsec policy. If the packet is not permitted by any access control list referenced by
the IPsec policy, it will be directly transmitted (IPsec does not protect the packet).
The IPsec policy implementation of firewall can not only apply on practical physical
ports such as serial ports and Ethernet ports, but also on virtual interfaces such as
Tunnel and Virtual Template. In this way, IPsec can be applied on tunnels like GRE and
L2TP according to the practical network requirements.
To delete all IKE SAs, you need to delete the IPsec policies on all the interfaces, or
manually delete the SAs or wait until the IKE SAs time out.
4.2.6 Disabling Next-Payload Field Checking
An IKE negotiation packet comprises multiple payloads; the next-payload field is in the
generic header of the last payload. According to the protocol, this field should be set to
4-23
0. It however may vary by vendor. For compatibility sake, you can use the following
command to ignore this field during IPsec negotiation.
Table 4-25 Disable to check the next-payload field
Operation Command
Disable to check the next-payload field
in the last payload of the IKE negotiation ike next-payload check disabled
packet during IPsec negotiation
undo ike next-payload check

Remove the default
disabled
By default, the system checks the next-payload field in the last payload of the IKE
negotiation packet during IPsec negotiation.
4.2.7 Configuring IPsec Fragments Buffering
When an interface is configured with IPsec security policy, any packet received on or
sent from the interface is matched against the ACLs before other IPsec handling.
If the packet happens to be a fragment, the subsequent fragments will be unable to
match the security policy for not containing port number and other information.
z If the fragments arrive in order (that is, the first fragment arrives earlier than the
non-first fragments), the first fragment will create a fragment table entry, and fill the
content after matching the security policy. The subsequent fragments are then
matched against this entry before other IPsec handling.
z If the non-first fragments arrive earlier than the first fragments, they have to wait for
the first fragment to establish the fragment entry. The IPsec fragments buffering
provides the mechanism to temporarily store these fragments while they are
waiting.
I. Configuring IPsec fragments buffering mechanism
Table 4-26 Configure IPsec fragments buffering mechanism
Operation Command
Enable fragments buffering in the
ipsec fragment-chain inbound enable
inbound direction
Disable fragments buffering in the ipsec fragment-chain inbound
inbound direction disable
4-24
Operation Command
Enable fragments buffering in the ipsec fragment-chain outbound
outbound direction enable
Disable fragments buffering in the ipsec fragment-chain outbound
outbound direction disable
By default, fragments buffering is disabled. That is, if non-first fragments arrive earlier
than the first fragment, they will be discarded.
II. Configuring timeout time of buffered fragments
Table 4-27 Configure timeout time of buffered fragments
Operation Command
Configure the timeout out of buffered ipsec fragment-chain timeout
fragments seconds
By default, the timeout time is 3 seconds.
4.2.8 Configuring the Encryption Card (Optional)
The basic configurations of an encryption card are the same as those of IPsec; refer to
the previous sections.
The following are the optional configurations for the encryption card.
I. Entering encryption card interface view and enabling the card
When a firewall is fitted with multiple encryption cards, you may use the undo
shutdown and shutdown commands to enable or disable them. The undo shutdown
command can reset and initialize an encryption card that is disabled.
Before you can shut down/enable the encryption card in a specified slot, you must use
the interface encrypt command to enter the view of the encryption card.
Table 4-28 Enter encryption card interface view
Operation Command
Enter encryption card interface view interface encrypt slot-id
Perform the following configuration in encryption card interface view.
4-25
Table 4-29 Enable or shut down the encryption card
Operation Command
Turn up the encryption card undo shutdown
Shut down the encryption card shutdown
By default, all the fitted encryption cards are up.
II. Enabling IPsec module backup function
For the IPsec SA implemented by the encryption card, if the card is normal, IPsec is
processed by the card. If the card fails, backup function is enabled on the card and the
selected encryption/authentication algorithms for the SA are supported by the IPsec
module on Comware platform, IPsec shall be implemented by the IPsec module on
Comware platform. In the event that the selected algorithms are not supported by the
IPsec module, the system drops packets.
Table 4-30 Configure IPsec module backup function
Operation Command
Enable IPsec module backup function encrypt-card backuped
Disable IPsec module backup function undo encrypt-card backuped
By default, IPsec module backup function is disabled.
III. Configuring the fast forwarding function of the encryption card
For the packets that have the same [SourIP, SourPort, DestIP, DestPort, Prot] quintuple,
the firewall creates a fast forwarding entry when it receives the first packet. Then, the
subsequent packets, rather than processed packet by packet, are sent directly to the
encryption card, where they are sent to the destination after being encrypted or
decrypted. This is how the fast forwarding function of the encryption card expedites
packet processing.
Table 4-31 Configure the fast forwarding function of the encryption card
Operation Command
Enable the fast forwarding function of
encrypt-card fast-switch
the encryption card
Disable the fast forwarding function of
undo encrypt-card fast-switch
the encryption card
4-26
By default, the fast forwarding function of the encryption card is disabled.
Caution:
After the fast forwarding function of encryption card is enabled, the statistic information
of the packets processed by the encryption card will not be shown in ACL.
IV. Setting simple network management configuration on encryption cards
You can manage the encryption cards on the firewall remotely by using SNMP. With the
NM function on the firewall, you can query the card status and monitor trap information,
which includes information about card rebooting, status transition and packet loss
processing.
Table 4-32 Configure trap function on Encryption card
Operation Command
Enable trap function on Encryption card snmp-agent trap enable encrypt-card
undo snmp-agent trap enable
Disable trap function on Encryption card
encrypt-card
By default, the trap function is enabled on the encryption card.
4.3 Displaying and Debugging IPsec

4.3.1 Displaying and Debugging over IPsec Module on Comware Platform
I. Displaying and debugging IPsec configuration
running of the IPsec configuration, and to verify the effect of the configuration.
Execute debugging command in user view for the debugging of IPsec configuration.
Table 4-33 Display and debug IPsec
Operation Command
display ipsec sa [ brief | remote
Display Security Association related
ip-address | policy policy-name
information
[ seq-number ] | duration ]
Display IPsec tunnel information display ipsec tunnel
4-27
Operation Command
Display statistical information on IPsec
display ipsec statistics
processed packet
display ipsec proposal
Display IPsec proposal
[ proposal-name ]
display ipsec policy [ brief | name
Display IPsec policy
policy-name [ seq-number ] ]
display ipsec policy-template [ brief |
Display IPsec policy template
name policy-name [ seq-number ] ]
Display IPsec fragments buffering
display ipsec fragment buffer-chain
information
Display statistics of IPsec buffered
display ipsec fragment statistics
fragments
Display DPD configuration information display ike dpd [ dpd-name ]
debugging ipsec { all | sa | packet
[ policy policy-name [ seq-number ] |
Enable IPsec debugging function
parameters ip-address protocol
spi-number ] | fragment | misc }
undo debugging ipsec { all | sa |
packet [ policy policy-name
Disable IPsec debugging function [ seq-number ] | parameters ip-address
protocol spi-number ] | fragment |
misc }
Enable DPD debugging function debugging ike dpd
Disable DPD debugging function undo debugging ike dpd
II. Clearing IPsec packet statistics
This command clears IPsec packet statistics. All statistical information is set to 0.
Table 4-34 Clear IPsec packet statistics
Operation Command
Clear IPsec packet statistics reset ipsec statistics
III. Clearing the statistics of IPsec buffered fragments
All the statistics are set to zero after this configuration.

4-28
Table 4-35 Clear the statistics of IPsec buffered fragments
Operation Command
Clear the statistics of IPsec buffered
reset ipsec fragment statistics
fragments
IV. Clearing the queues of IPsec buffered fragments
All the fragments in the queues are discarded after this configuration.
Table 4-36 Clear the queues of IPsec buffered fragments
Operation Command
Clear the queues of IPsec buffered
reset ipsec fragment buffer-chain
fragments
V. Deleting SA
The configuration is used to delete the established SA (either manually or through IKE
negotiation). If no parameter is specified, all the SAs will be deleted.
Table 4-37 Delete SA
Operation Command
reset ipsec sa [ remote ip-address | policy policy-name
Delete SA
[ seq-number ] | parameters ip-address protocol spi-number ]
If a packet re-triggers IKE negotiation after an SA set up through IKE negotiation is

deleted, IKE will reestablish an SA through negotiation.
If an SA set up manually is deleted, the system will automatically set up a new SA
according to the parameter manually set up.
The keyword parameters will take effect only after the spi of the outbound SA is
defined. Because SAs appear in pairs, the inbound SA will also be deleted after the
outbound SA is deleted.
4.3.2 Displaying and Debugging Encryption Card Information
I. Displaying and debugging IPsec information on encryption cards
You can view the IPsec configurations, including SA information, statistics, log,
interface information and IPsec module backup function, on the encryption card using
display commands.
4-29
Execute the debugging command in user view for the debugging of IPsec
configuration.
Table 4-38 Display and debug encryption card configuration
Operation Command
Display interface information on the
display interface encrypt slot-id
encryption card
Display information about the fast
forwarding cache for the encryption display encrypt-card fast-switch
cards
Enable Comware test software debugging encrypt-card host { all |
debugging on the encryption card packet | sa | command | error | misc }
undo debugging encrypt-card host

Disable Comware test software
{ all | packet | sa | command | error |
debugging on the encryption card
misc }
II. Clearing statistics on encryption card
Use this command to clear statistics of the encryption cards.

Table 4-39 Clear statistics on encryption card(s)
Operation Command
Clear statistics on encryption card reset counters interface encrypt slot-id
III. Deleting SA on encryption card
Use this command to clear the established SAs (either manually or through IKE
negotiation) of the encryption cards on the firewall.
Table 4-40 Delete SA
Operation Command
Delete SAs on the encryption cared reset encrypt-card sa slot-id
Note:
Currently this command is not supported on the encryption card.
4-30
IV. Clearing packet statistics on encryption card
You can reset all counters on the encryption card, including those for data packets, byte
counting, lost packets, failed authentication, faulty SAs, invalid SA proposals, invalid
protocols, and so on.
Table 4-41 Clear packet statistics on encryption card
Operation Command
Clear packet statistics on encryption card reset encrypt-card statistics slot-id
Note:
V. Clearing system log on encryption card
You can clear the system log, which records all key operations to it, on the encryption
card.
Table 4-42 Clear system log on encryption card
Operation Command
Clear system log on encryption card reset encrypt-card syslog slot-id
Note:
VI. Clearing the fast forwarding information on encryption card
Table 4-43 Clear the fast forwarding information on encryption card
Operation Command
Clear the fast forwarding information on
reset encrypt-card fast-switch
the encryption card
4-31
4.4 Typical IPsec Configuration Example

4.4.1 Establishing SAs Manually
Between SecPath A and SecPath B set up a security tunnel to protect the data flows
between the subnets 10.1.1.x and 10.1.2.x where PC A and PC B reside. Set the
security protocol to ESP, and adopt the encryption algorithm DES and the
authentication algorithm SHA1-HMAC-96.
II. Network diagram
SecPathA SecPathB
Ethernet2/0/1 Internet Ethernet2/0/1

202.38.163.1 202.38.162.1
10.1.1.1 10.1.2.1
PC A PC B
10.1.1.2 10.1.2.2
Figure 4-3 IPsec configuration example
# Configure an ACL, defining the data flow from the subnet 10.1.1.x to the subnet
10.1.2.x.
[H3C-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
# Configure a static route to PC B

# Create the IPsec proposal named tran1.

[H3C] ipsec proposal tran1
# Set the packet encapsulation mode to tunnel.

[H3C-ipsec-proposal-tran1] encapsulation-mode tunnel
# Set the security protocol to ESP.

[H3C-ipsec-proposal-tran1] transform esp
# Select the encryption and authentication algorithms.
4-32
[H3C-ipsec-proposal-tran1] esp encryption-algorithm des

[H3C-ipsec-proposal-tran1] esp authentication-algorithm sha1
# Return to system view.

[H3C-ipsec-proposal-tran1] quit
# Create an IPsec policy and set the negotiation mode to manual.

[H3C] ipsec policy map1 10 manual
# Reference the ACL 3101.

[H3C-ipsec-policy-manual-map1-10] security acl 3101
# Reference the IPsec proposal.

[H3C-ipsec-policy-manual-map1-10] proposal tran1
# Configure the remote address.

[H3C-ipsec-policy-manual-map1-10] tunnel remote 202.38.162.1
# Configure the local address.

[H3C-ipsec-policy-manual-map1-10] tunnel local 202.38.163.1
# Configure SPI.
[H3C-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[H3C-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
# Configure a key.
[H3C-ipsec-policy-manual-map1-10] sa string-key outbound esp abcdefg
[H3C-ipsec-policy-manual-map1-10] sa string-key inbound esp gfedcba
[H3C-isec-policy-manual-map1-10] quit
# Configure Ethernet2/0/1.
# Apply the IPsec policy group.

[H3C-Ethernet2/0/1] ipsec policy map1
10.1.1.x.
10.1.1.0 0.0.0.255
# Configure a static route to PC A.

4-33





# Create an IPsec policy, setting the negotiation mode to manual.

[H3C] ipsec policy use1 10 manual
# Reference the ACL.

[H3C-ipsec-policy-manual-use1-10] security acl 3101

[H3C-ipsec-policy-manual-use1-10] proposal tran1
# Configure the remote address.

[H3C-ipsec-policy-manual-use1-10] tunnel remote 202.38.163.1
# Configure the local address.

[H3C-ipsec-policy-manual-use1-10] tunnel local 202.38.162.1
# Configure SPI.
[H3C-ipsec-policy-manual-use1-10] sa spi outbound esp 54321
[H3C-ipsec-policy-manual-use1-10] sa spi inbound esp 12345
# Configure a key.
[H3C-ipsec-policy-manual-use1-10] sa string-key outbound esp gfedcba
[H3C-ipsec-policy-manual-use1-10] sa string-key inbound esp abcdefg
[H3C-ipsec-policy-manual-use1-10] quit
# Configure Ethernet2/0/1.
# Assign an IP address to the Ethernet interface.


[H3C-Ethernet2/0/1] ipsec policy use1
4-34
After you complete the configuration, you can set up a security tunnel between the
firewalls SecPath A and SecPath B to allow the data flow to be transmitted encrypted
between the subnets 10.1.1.x and 10.1.2.x.
4.4.2 Establishing ISAKMP SAs
As shown in Figure 4-3, between SecPath A and SecPath B set up a security tunnel to
protect the data flow between the subnets 10.1.1.x and 10.1.2.x where PC A and PC B
reside. Set the security protocol to ESP, and adopt the encryption algorithm DES and
the authentication algorithm SHA1-HMAC-96.
II. Network diagram
See Figure 4-3.
10.1.2.x.
10.1.2.0 0.0.0.255
# Configure a static route to PC B.






# Configure an IKE peer.

[H3C] ike peer peer
4-35
[H3C-ike-peer-peer] pre-shared-key abcde

[H3C-ike-peer-peer] remote-address 202.38.162.1
# Create an IPsec policy, setting the negotiation mode to ISAKMP.

[H3C] ipsec policy map1 10 isakmp

[H3C-ipsec-policy-isakmp-map1-10] proposal tran1

[H3C-ipsec-policy-isakmp-map1-10] security acl 3101
# Reference the IKE peer.

[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer

[H3C-ipsec-policy-isakmp-map1-10] quit
# Enter the interface view.




10.1.1.x.
10.1.1.0 0.0.0.255
# Configure the static route to PC A.




4-36



[H3C] ike peer peer
# Create an IPsec policy, setting the negotiation mode to ISAKMP.

[H3C] ipsec policy use1 10 isakmp

[H3C-ipsec-policy-isakmp-use1-10] security acl 3101

[H3C-ipsec-policy-isakmp-use1-10] proposal tran1
# Reference the IKE peer.


[H3C-ipsec-policy-isakmp-use1-10] quit
# Enter the interface view.



[H3C-Ethernet2/0/1] ipsec policy use1

After the configuration is finished, the receipt of a packet from the subnet 10.1.1.x or
10.1.2.x can trigger IKE to negotiate SAs between SecPath A and SecPath B. If the
negotiation is successful, the data flow between the two subnets is transmitted
encrypted.
4-37
4.4.3 Implementing Encryption/Decryption and Authentication on

Encryption Card
A security tunnel will be configured between SecPath A and SecPath B. Data flow
security protection will be setup between sub-network (10.1.1.0/24) represented by PC
A and sub-network (10.1.2.0/24) represented by PC B. Manually create SAs, choose
ESP protocol, DES encryption algorithm and SHA1-HMAC-96 authentication algorithm.
II. Network diagram
e0/0/0:10.1.1.1 e0/0/0:10.1.2.1
Internet
e3/0/0:202.38.163.1 e3/0/0:202.38.162.1
SecPathA SecPathB PC B
PC A
10.1.1.2 10.1.2.2
Figure 4-4 Network diagram for creating SAs over encryption card
# Configure an access control list, defining data flow from sub-network 10.1.1.0/24 to
sub-network 10.1.2.0/24.
10.1.2.0 0.0.0.255
# Create SA proposal “tran1”.

[H3C] ipsec card-proposal tran1
# Specify that SA proposal tran1 uses the encryption card on the slot 1/0/0.
[H3C-ipsec-card-proposal-tran1] use encrypt-card 1/0/0
# Packet encapsulation format is tunnel mode.

[H3C-ipsec-card-proposal-tran1] encapsulation-mode tunnel
# Security protocol is ESP.

[H3C-ipsec-card-proposal-tran1] transform esp
# Select algorithm.
[H3C-ipsec-card-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-card-proposal-tran1] esp authentication-algorithm sha1-hmac-96
4-38

[H3C-ipsec-card-proposal-tran1] quit
# Establish a security policy and negotiation mode is manual.

[H3C] ipsec policy policy1 10 manual
# Quote access control list.

[H3C-ipsec-policy-policy1-10] security acl 3001
# Configure the peer address.

[H3C-ipsec-policy-policy1-10] tunnel remote 202.38.162.1
# Configure local end address.

[H3C-ipsec-policy-policy1-10] tunnel local 202.38.163.1
# Quote SA proposal.
[H3C-ipsec-policy-policy1-10] proposal tran1
# Configure SPI.
[H3C-ipsec-policy-policy1-10] sa spi outbound esp 12345
[H3C-ipsec-policy-policy1-10] sa spi inbound esp 54321
# Configure key.
[H3C-ipsec-policy-policy1-10] sa string-key outbound esp abcdefg
[H3C-ipsec-policy-policy1-10] sa string-key inbound esp gfedcba

[H3C-ipsec-policy-policy1-10] quit
# Enter Ethernet interface view, configure IP address.


# Return to system view, configure a static route to the segment 10.1.2.0/24.

# Apply security policy set on the Ethernet interface.

[H3C-Ethernet3/0/0] ipsec policy policy1
# Configure an access control list, specifying data flow from sub-network 10.1.2.0/24 to
sub-network 10.1.1.0/24.
4-39

10.1.1.0 0.0.0.255
# Create SA proposal “trans1”.

[H3C] ipsec card-proposal tran1
# Specify that SA proposal trans1 uses the encryption card on the slot 1/0/0.
[H3C] use encrypt-card 1/0/0
# Packet encapsulation format is tunnel mode.

[H3C-ipsec-card-proposal-tran1] encapsulation-mode tunnel
# Security protocol is ESP.

[H3C-ipsec-card-proposal-tran1] transform esp
# Select algorithm.
[H3C-ipsec-card-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-card-proposal-tran1] esp authentication-algorithm sha1-hmac-96

[H3C-ipsec-card-proposal-tran1] quit
# Establish a security policy and negotiation mode is manual.

[H3C] ipsec policy map1 10 manual
# Quote access control list.

[H3C-ipsec-policy-map1-10] security acl 3000
# Configure the peer address.

[H3C-ipsec-policy-map1-10] tunnel remote 202.38.163.1
# Configure local end address.

[H3C-ipsec-policy-map1-10] tunnel local 202.38.162.1
# Quote SA proposal.
[H3C-ipsec-policy-map1-10] proposal tran1
# Configure SPI.
[H3C-ipsec-policy-map1-10] sa spi outbound esp 54321
[H3C-ipsec-policy-map1-10] sa spi inbound esp 12345
# Configure key.
[H3C-ipsec-policy-map1-10] sa string-key outbound esp gfedcba
[H3C-ipsec-policy-map1-10] sa string-key inbound esp abcdefg

[H3C-ipsec-policy-map1-10] quit
4-40


# Return to system view, configure a static route to the segment 10.1.1.x.

# Apply security policy set on the Ethernet interface.

4.4.4 Configuration Example of SA Setup Between a Firewall and the Virtual

Address of a VRRP Standby Group
As shown in the following diagram, the headquarters uses the VRRP standby group
formed by SecPath A and SecPath B as its default gateway. SecPath C sets up IPsec
SAs with the virtual address of this VRRP standby group to protect data transmitted
between the headquarters and the branch.
Router A and Router B are access routers of operators. They are not discussed here.
4-41
II. Network diagram
12.0.0.1
Host B
Eth1/0/0:12.0.0.2
Branch office SecPathC
Eth0/0/0:13.0.0.1
Eth0/0/0:13.0.0.4
RouterA
Internet
RouterB
eth1/0/0:10.0.0.4
Eth0/0/0:10.0.0.1 VRRP ID1:10.0.0.5 Eth0/0/0:10.0.0.3
SecPathA SecPathB
Eth1/0/0:11.0.0.1 Eth1/0/0:11.0.0.3
VRRP ID2:11.0.0.5
Headquarters 11.0.0.7
Host A
Figure 4-5 Set up SAs between a firewall and a virtual address of a VRRP backup
group
# Configure SecPath A as the master in a VRRP group.
<H3C> system
[H3C] vrrp ping-enable
[H3C-Ethernet0/0/0] vrrp vrid 1 preempt-mode timer delay 5
[H3C-Ethernet0/0/0] interface ethernet1/0/0
4-42
[H3C-Ethernet1/0/0] vrrp vrid 2 preempt-mode timer delay 5

# Configure the data flow protected by IPsec.

[H3C-acl-adv-3101] rule 0 permit ip source 11.0.0.0 0.0.0.255 destination
12.0.0.0 0.0.0.255
# Configure a static route to host B.

# Configure IPsec DPD.

[H3C] ike dpd dpd1
[H3C-ike-dpd-dpd1] interval-time 10
[H3C-ike-dpd-dpd1] time-out 5
[H3C-ike-dpd-dpd1] quit
# Create a security proposal named tran1 (the contents are omitted).

#Configure an IKE peer.

[H3C] ike peer peer
[H3C-ike-peer-peer] local-address 10.0.0.5
[H3C-ike-peer-peer] dpd dpd1
[H3C-ike-peer-peer] quit
# Create a security policy, setting negotiation mode to isakmp.

# Apply an IPsec policy group to the interface.

[H3C-ethernet0/0/0] ipsec policy map1
# Configure SecPath B as a slave in the VRRP standby group. It uses the default
priority 100, lower than that of Router A.
<H3C> system
4-43
[H3C] vrrp ping-enable


12.0.0.0 0.0.0.255
# Configure a static route to host B.


[H3C] ike dpd dpd1
# Create a security proposal named tran1 (the contents are omitted).


[H3C] ike peer peer
# Create an IPsec policy, setting negotiation mode to isakmp.

# Apply a security policy group to the interface.

4-44
3) Configure SecPath C
11.0.0.0 0.0.0.255
# Configure a static route to host A.


[H3C] ike dpd dpd1
# Create a security proposal named tran1 (the content is omitted).


[H3C] ike peer peer
# Create a security policy, setting negotiation mode to isakmp.

# Apply an IPsec policy group to the interface.

# Configure an Ethernet interface.

4-45
Execute the ping -c 500 11.0.0.7 command on host B to ping PC A, and then execute
the display ike sa and display ipsec sa commands on SecPath A and SecPath C
respectively to display established SAs.
Execute the shutdown command on interface Ethernet 0/0/0 on SecPath A. Then
execute the debugging ike dpd command on SecPath C. You may find out that a DPD
query is sent three times, but no acknowledgement is received. Then, all SAs on the
involved peer are deleted, while failover is happening in the VRRP standby group.
About 10 seconds later, the security tunnel is recovered. The following debugging
information is displayed:
<H3C> debugging ike dpd
(SAs are deleted after three DPD query attempts are failed.)
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-12903966)
H3C IKE/8/DEBUG:REQUEST: wait for response timeout
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-1917909230
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-1183268982)
H3C IKE/8/DEBUG:REQUEST: there are three fail and all SAs associated were
deleted
(A response is received from the peer after the failover completes in its corresponding
VRRP standby group)
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:1382148220)
H3C IKE/8/DEBUG:REQUEST(recv dpd response): received a message
(seqno:1382148220)
H3C IKE/8/DEBUG:RESPONSE(recv dpd request): received a message
(seqno:1382148220)
H3C IKE/8/DEBUG:RESPONSE(send dpd response): send a message
(seqno:1382148220)
4.4.5 IPsec/IKE Multi-Instance Configuration Example
CE1 and CE3 belong to VPN1. CE1 and PE1 are connected by an IPsec/IKE tunnel.
CE2 and CE4 belong to VPN2. CE2 and PE1 are connected by an IPsec/IKE tunnel.
4-46
II. Network diagram
Eth0/0/1: Eth0/0/0: 33.33.33.3/24

32.32.32.2/24 21.21.21.2/24
51.51.51.1/24
Eth0/0/0:
21.21.21.1/24
AS 100 51.51.51.2/24 VPN1-CE3
Eth0/0/2:
VPN1-CE1 41.41.41.1/24 41.41.41.3/24
Loopback0: Loopback0:
Eth0/0/1: 100.100.100.1/32 100.100.100.2/32 61.61.61.2/24
31.31.31.1/24 PE 2
PE 1 61.61.61.1/24
Eth0/0/1: Eth0/0/0:
34.34.34.2/24 31.31.31.2/24 62.62.62.1/24
VPN2-CE2 VPN2-CE4
Figure 4-6 Network diagram for IPsec/IKE multi-instance configuration
III. Configuration example
1) Configure CE1
<CE1> system-view

[CE1] ike peer test
[CE1-ike-peer-test] pre-shared-key H3C
[CE1-ike-peer-test] remote-address 21.21.21.1
[CE1-ike-peer-test] quit
# Configure a security proposal (omitted).

[CE1] ipsec proposal prop
# Configure a security policy.

[CE1] ipsec policy map 1 isakmp
[CE1-ipsec-policy-isakmp-map-1] security acl 3000
[CE1-ipsec-policy-isakmp-map-1] ike-peer test
[CE1-ipsec-policy-isakmp-map-1] proposal prop
[CE1-ipsec-policy-isakmp-map-1] quit
# Configure the Ethernet interface and apply the security policy on the interface.
[CE1] interface Ethernet0/0/0
[CE1-Ethernet0/0/0] ip address 21.21.21.2 255.255.255.0
[CE1-Ethernet0/0/0] ipsec policy map
[CE1-Ethernet0/0/0] quit
[CE1-Ethernet0/0/1] quit

[CE1] acl number 3000
4-47
[CE1-acl-adv-3000] rule 0 permit ip source 21.21.21.0 0.0.0.255 destination

51.51.51.0 0.0.0.255
[CE1-acl-adv-3000] quit
# Configure a static route.

[CE1] ip route-static 0.0.0.0 0.0.0.0 21.21.21.1 preference 60
[CE1] ip route-static 33.33.33.0 255.255.255.0 21.21.21.1 preference 60
2) Configure PE1
<PE1> system-view
# Configure MPLS basic capability.

[PE1] mpls lsr-id 100.100.100.1
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
# Configure vpn-instance vrf1.

[PE1] ip vpn-instance vrf1
[PE1-vpn-vrf1] route-distinguisher 100:1
[PE1-vpn-vrf1] vpn-target 100:1 export-extcommunity
[PE1-vpn-vrf1] vpn-target 100:1 import-extcommunity
[PE1-vpn-vrf1] quit
# Configure vpn-instance vrf2.

[PE1] ip vpn-instance vrf2
[PE1-vpn-vrf2] route-distinguisher 100:2
[PE1-vpn-vrf2] vpn-target 100:2 export-extcommunity
[PE1-vpn-vrf2] vpn-target 100:2 import-extcommunity
[PE1-vpn-vrf2] quit
# Configure IKE peer test1.

[PE1] ike peer test1
[PE1-ike-peer-test1] pre-shared-key H3C
[PE1-ike-peer-test1] remote-address 21.21.21.2
[PE1-ike-peer-test1] quit
# Configure IKE peer test2.

[PE1] ike peer test2
[PE1-ike-peer-test2] pre-shared-key H3C
[PE1-ike-peer-test2] remote-address 31.31.31.2
[PE1-ike-peer-test2] quit
# Configure a security proposal (the content is omitted).

[PE1] ipsec proposal prop1
[PE1] ipsec proposal prop2
# Configure a security policy.
4-48
[PE1] ipsec policy map1 1 isakmp

[PE1-ipsec-policy-isakmp-map1-1] security acl 3000
[PE1-ipsec-policy-isakmp-map1-1] ike-peer test1
[PE1-ipsec-policy-isakmp-map1-1] proposal prop
[PE1-ipsec-policy-isakmp-map1-1] quit
[PE1] ipsec policy map2 1 isakmp
[PE1-ipsec-policy-isakmp-map2-1] security acl 3001
[PE1-ipsec-policy-isakmp-map2-1] ike-peer test2
[PE1-ipsec-policy-isakmp-map2-1] proposal prop2
# Bind the vpn-instance on the interface and apply the security policy on the interface.
[PE1] interface Ethernet0/0/0
[PE1-Ethernet0/0/0] ip binding vpn-instance vrf1
[PE1-Ethernet0/0/0] ip address 21.21.21.1 255.255.255.0
[PE1-Ethernet0/0/0] ipsec policy map1
[PE1-Ethernet0/0/0] quit
[PE1-Ethernet0/0/1] ip binding vpn-instance vrf2
[PE1-Ethernet0/0/1] ipsec policy map2
# Enable MPLS on Ethernet0/0/2 interface.

[PE1- Ethernet0/0/2] ip address 41.41.41.1 255.255.255.0
[PE1- Ethernet0/0/2] mpls
[PE1- Ethernet0/0/2] mpls ldp enable
[PE1- Ethernet0/0/2] quit
# Configure LoopBack0 interface.

[PE1] interface LoopBack0
[PE1-LoopBack0] ip address 100.100.100.1 255.255.255.255

[PE1] acl number 3000
[PE1-acl-adv-3000] rule 0 permit ip source 51.51.51.0 0.0.0.255 destination
21.21.21.0 0.0.0.255
[PE1-acl-adv-3000] quit
[PE1-acl-adv-3001] rule 0 permit ip source 61.61.61.0 0.0.0.255 destination
31.31.31.0 0.0.0.255
# Establish the MP-IBGP neighbor between PE1 and PE2. Activate the MP-IBGP peer
in VPNv4 address cluster view.
4-49
[PE1] bgp 100

[PE1-bgp] undo synchronization
[PE1-bgp] group g1 internal
[PE1-bgp] peer 100.100.100.2 group g1
[PE1-bgp] peer 100.100.100.2 connect-interface LoopBack0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer g1 enable
[PE1-bgp-af-vpn] peer 100.100.100.2 group g1
[PE1-bgp-af-vpn] quit
# Configure the private network route importing CE1 and CE2.

[PE1-bgp] ipv4-family vpn-instance vrf1
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] undo synchronization
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] ipv4-family vpn-instance vrf2
# Enable OSPF on the interface connecting PE1 to PE2 and the loop interface to
implement interworking inside the AS.
[PE1] ospf 1
[PE1-ospf-1] area 0.0.0.0
[PE1-ospf-1] network 41.41.41.0 0.0.0.255
[PE1-ospf-1] network 100.100.0.0 0.0.255.255
[PE1-ospf-1] quit
# Configure the static route for the private network.

[PE1] ip route-static vpn-instance vrf1 32.32.32.0 255.255.255.0 21.21.21.2
preference 60
CE2, CE3 and CE4 configuration are similar to CE1 configuration. PE2 configuration is
similar to PE1 configuration.
4.5 IPsec Troubleshooting

Symptom: When apply the IPsec policy on an interface for the first time, the
receive/send end can encrypt and decrypt the data flow; after disabling the IPsec
function, the receive/send end can communicate normally; when apply the IPsec policy
for the second time, packets cannot perform the IPsec process, and the peer end
cannot be pinged successfully.
Troubleshooting: This problem usually appears when the originator configures the
security policy directly in the security policy view, and connected end creates security
policy by importing security policy template. When apply the IPsec policy for the first
4-50
time, the communication is normally. However, when you disable the function, a fast
switching entry is established at the connected end. So when you enable the IPsec
policy for the second time, the presence of the fast switching entry causes the fail of
IPsec process to the packets. If you use the reset ip fast-forwarding cache command
to clear the fast switching buffer before enable the IPsec policy for the second time, the
problem will be solved.
4-51
H3C SecPath Series Security Products Chapter 5 IKE Configuration
Chapter 5 IKE Configuration
5.1 IKE Overview

5.1.1 Brief Introduction to IKE
IKE (Internet Key Exchange) is Internet shared secret exchange protocol. It is a mixed
protocol, configured in a framework specified by Internet Security Association and Key
Management Protocol (ISAKMP). IKE will provide automatic negotiation and exchange
of shared key for IPsec and configure Security Association, thus to simplify IPsec
application and management.
Network security has 2 meanings: one is internal LAN security, the other is external
data exchange security. The former is implemented by means of Firewall, network
address translation (NAT) etc. Emerging IPsec (IP security) implements the latter.
IPsec Security Association can be established by manual configuration, but when
nodes increase in the network, manual configuration will be very difficult, and hard to
ensure security. In this case, the IKE automatic negotiation can be used to establish
Security Association and exchange shared secret.
IKE has a series of self-protection mechanisms to safely distribute shared key,
authenticate identity, and establish IPsec Security Association etc. in unsecured
network.
IKE security mechanism includes:
z Diffie-Hellman (DH) exchange and shared key distribution
Diffie-Hellman algorithm is a shared key algorithm. The both parties in communication
can exchange some data without transmitting shared key and find the shared key by
calculation. The pre-condition for encryption is that the both parties must have shared
key. The merit of IKE is that it never transmits shared key directly in the unsecured
network, but calculates the shared key by exchanging a series data. Even if the third
party (such as Hackers) captured all exchange data used to calculate shared key for
both parties, he cannot figure out the real shared key.
z Perfect Forward Secrecy (PFS)
PFS feature is a security feature. When a shared key is decrypted, there will be no
impact on the security of other shared keys, because these secrets have no derivative
relations among them. IPsec is implemented by adding one key exchange during IKE
negotiation phase II.
z Identity authentication
Identity authentication will authenticate identity for both parties in communication.
Authentication key can input to generate shared secret. It is impossible for different
5-1
authentication keys to generate the same shared secret between the two parties.
Authentication key is the key in identity authentication for both parties.
z Identity protection
After shared secret is generated, identity data will be encrypted and transmitted, thus
implementing identity data protection.
IKE using 2 stages to implement shared secret negotiation for IPsec and creating
Security Association. In the first stage, parties involved in the communication will
establish a channel for identity authentication and security protection. An ISAKMP
Security Association (ISAKMP SA) is established by the exchange in this stage. In the
second stage, security channel established in phase 1 will be used to negotiate specific
Security Association for IPsec and establish IPsec SA. IPsec SA will be used for final IP
data security transmission.
The relation between IKE and IPsec is shown in the following figure.
SA negotiation
IKE IKE
SecPathA SecPathB
TCP/UDP SA SA TCP/UDP
IPSec IPSec
IP
Encry pted IP packet
Figure 5-1 Relation between IKE and IPsec
I. IKE aggressive mode
ADSL and dial-up mode are two solutions widely adopted at present in VPN
construction. In these two solutions, there is an exceptional case where IP addresses of
the devices at central office end are static and the IP addresses of the devices at
subscriber end are dynamic. In order to support the application in this special case,
aggressive mode is introduced in IKE negotiation. This mode allows IKE to search for
the pre-shared key of the negotiation initiator by the IP address or ID of the negotiation
initiator to accomplish the negotiation. Compared to the main mode, IKE aggressive
mode allows of more flexibility and supports IKE negotiation even when the IP address
of the initiator is dynamic.
5-2
II. NAT traversal
If there is a NAT GW on the VPN tunnel set up via IPsec/IKE and if this GW performs
NAT on the VPN service data, you must configure the NAT traversal function for
IPsec/IKE. With this function, the IKE negotiation will not authenticate the UDP port
number. At the same time, traversal allows NAT GW discovery on the VPN tunnel. If a
NAT GW is discovered, UDP encapsulation will be used in the subsequent IPsec data
transmission, i.e., encapsulating IPsec packets in the UDP connection tunnel for IKE
negotiation), to prevent the NAT GW from modifying the IPsec packets. That is, the NAT
GW will change the outermost IP and UDP headers but leave the IPsec packets
encapsulated in the UDP packets intact, thus ensuring the integrity of the IPsec packets.
The authentication process of an IPsec data encryption/decryption requires the IPsec
packet to arrive at the destination intact. Currently NAT traversal is available in
aggressive mode, but not in main mode.
Usually the two features described above are used together in the ADSL + IPsec
networking to solve the problems resulted from dynamic IP addresses on
broadband-access enterprise networks and NAT traversal on the public network. The
combination of these two features provides a security solution for substituting the ADSL
broadband access for the original leased line access.
III. IKE multi-instance
You can use IKE multi-instance to implement IKE packet negotiation between different
CEs and a PE. The IKE multi-instance and IPsec can implement IPsec/IKE
multi-instance function bound to the interface connecting the PE and CE.
When the CE initiates IKE negotiation, the information about the VPN instance in the IP
packet is sent to the PE. After receiving the information, the PE saves the VPN ID
during negotiation. When sending a negotiation IP packet to the CE, the PE fills the
VPN ID in the IP packet, and then forwards the packet to the IP layer for processing.
The IP layer forwards the packet to the corresponding CE according to the VPN routing
table.
5.1.2 Preparation for IKE Configuration
Prior to IKE configuration, user needs to specify following subjects, so as to smooth the
configuration process:
z Make clear of algorithm strength for IKE exchange process, i.e., security
protection strength (including identity authentication method, encryption algorithm,
and authentication-algorithm algorithm, DH algorithm). There are different
algorithm strengths. The higher strength the algorithm has, the harder it is to
decrypt the protected data, but more calculation resource will be consumed.
Generally, the longer the shared secret is, the higher the algorithm strength is.
z Make sure of the identity authentication key of both sides in communication.
5-3
5.2 IKE Configuration

5.2.1 Introduction to IKE Configuration
IKE configuration includes:

1) Set a name for the local security GW
2) Define IKE proposal
z Establish IKE Proposal
z Select encryption algorithm
z Select authentication method
z Select authentication algorithm
z Select Diffie-Hellman Group ID
z Set lifetime of ISAKMP SA (optional)
3) Configure IKE peer
z Create an IKE peer
z Configure IKE negotiation mode
z Configure identity authentication key (pre-shared key)
z Configure ID type in IKE negotiation
z Configure IP address in IKE negotiation
z Configure NAT traversal
z Configure subnet type of the IKE peer
4) Configure the parameters of Keepalive timer
z Configure interval for Keepalive transmission
z Configure timeout time for Keepalive
5.2.2 Setting a Name for the Local Security GW
If the initiator uses the GW name in IKE negotiation (that is, id-type name is used), you
must configure the ike local-name command on the local device.
Table 5-1 Configure name of the local security GW
Operation Command
Configure name of the local security GW. ike local-name name
Restore the default name of the local security GW. undo ike local local-name
5.2.3 Defining IKE Proposal
I. Establishing IKE Proposal
IKE proposal defines a set of attributes describing how IKE negotiation conducts
security communications. Configuring an IKE proposal includes the tasks of IKE
5-4
proposal creation, selection in encryption algorithm, authentication mode,

authentication algorithm, and Diffie-Hellman group ID, and SA lifetime duration setting.
As for main mode, the user may create multiple IKE proposals on the basis of
preference, but the negotiation parties should have at least one matched IKE proposal
in order to reach an agreement. As for aggressive mode, the sponsor negotiates with
the counter party only by selecting the security proposal with the highest preference.
The agreement of negotiation will be reached If the counter party has the matched
security proposal, or the negotiation will fail. That is to say, the sponsor will not hold the
negotiation using security proposal with low preference any more.
This configuration is used to define an IKE proposal. The IKE proposal configured is
used to establish the security channel.
Table 5-2 Establish IKE proposal
Operation Command
Create IKE proposal ike proposal proposal-number
Delete IKE proposal undo ike proposal proposal-number
Execute the ike proposal command to enter the IKE proposal view, where you can
configure the encryption algorithm, authentication algorithm, Diffie-Hellman group ID,
sa duration, and authentication method.
The parameter proposal-number is the IKE proposal number, ranging from 1 to 100.
This parameter also stands for the priority. A smaller number stands for a higher priority.
You can create multiple IKE proposals for each side of the negotiation. Both side in the
negotiation matches the proposal from the one with the highest priority. There must be
at least one matched policy for successful negotiation, that is, both side must have the
same encryption and authentication algorithm, some authentication method and
Diffie-Hellman group ID.
The system provides a default IKE proposal, which has the lowest priority and has the
default encryption algorithm, authentication algorithm, Diffie-Hellman group ID, SA
duration, and authentication method. The parameters needed by an IKE proposal are
as follows.
II. Selecting Encryption Algorithm
This configuration is used to specify an encryption algorithm used by an IKE proposal.

Perform the following configuration in IKE proposal view.
5-5
Table 5-3 Select encryption algorithm
Operation Command
encryption-algorithm { des-cbc |
Select encryption algorithm
3des-cbc | aes-cbc }
Set the encryption algorithm to the
undo encryption-algorithm
default value
By default, the 56-bit DES algorithm in CBC mode is adopted.
III. Selecting authentication method
This configuration is used to specify an authentication method used by an IKE

proposal.
IKE authentication has two algorithms: pre-share-key and PKI (rsa-signature).
The authentication key must be configured when using the authentication method of
pre-shared key. (Refer to the part of “Configuring pre-shared key”)
Table 5-4 Specify authentication method
Operation Command
authentication-method { pre-share |
Specify authentication method
rsa-signature }
Restore the authentication method to
undo authentication-method
the default value
By default, pre-share key algorithm is adopted.
Note:
z Refer to the “PKI Configuration” part of this manual for detailed PKI configurations.
z In an IKE negotiation, if the initiator uses the rsa-signature authentication method,
the id-type and remote-name command configured in the IKE peer will not take
effect. The responder selects an IKE peer according to the remote-address
configured in IKE peer. So, if rsa-signature authentication method is adopted, both
the initiator and responder should specify the remote-address, otherwise, all
addresses are matched by default.
5-6
IV. Selecting Authentication Algorithm
This configuration is used to specify the authentication algorithm used by an IKE

proposal.
Table 5-5 Select authentication algorithm
Operation Command
Select authentication algorithm authentication-algorithm { md5 | sha }
Set authentication algorithm to the
undo authentication-algorithm
default value
By default SHA-1 authentication algorithm is adopted.
V. Selecting Diffie-Hellman Group ID
This configuration is used to specify the Diffie-Hellman group ID used by an IKE

proposal.
Table 5-6 Select Diffie-Hellman group ID
Operation Command
Select Diffie-Hellman group ID dh { group1 | group2 | group5 | group14 }
Restore the default value of
undo dh
Diffie-Hellman group ID
By default, 768-bit Diffie-Hellman group (group 1) is selected.
VI. Configuring lifetime of ISAKMP SA (optional)
This configuration is used to specify the lifetime of ISAKMP SA used by an IKE

proposal.
Table 5-7 Set sa duration of IKE SA
Operation Command
Configure lifetime of IKE SA. sa duration seconds
Restore the default lifetime. undo sa duration
If sa duration expires, the ISAKMP SA will automatically update. The SA lifetime can
be set as one number between 60 and 604800 seconds. Because the IKE negotiation
5-7
needs to perform DH algorithm, which will take a longer period of time. For the purpose
that the update of ISAKMP SA does not affect the security communication, it is
recommended to set the sa duration greater than 10 minutes.
The SA will negotiate another one to replace the old SA before the set SA duration is
exceeded. It is called soft timeout. The starting time of the soft timeout is 90% of the SA
duration timeout. The old SA will be cleared automatically when the SA duration is
exceeded, which can be called hard timeout.
By default, the ISAKMP SA duration is 86400 seconds (a day).
5.2.4 Configuring IKE Peer
I. Creating an IKE peer
Table 5-8 Configure IKE peer
Operation Command
Configure an IKE peer and access the
ike peer peer-name
IKE peer view.
Delete the IKE peer. undo ike peer peer-name
II. Configuring IKE negotiation mode
Perform the following configuration in IKE-peer view.
Table 5-9 Configure negotiation mode
Operation Command
Configure IKE negotiation mode exchange-mode { aggressive | main }
Restore the default IKE negotiation
undo exchange-mode
mode
By default, the main mode is adopted.
Note:
z If the IP address of one end of a security tunnel is dynamic, you must adopt the
aggressive mode for IKE negotiation.
z If the peer accepts the request using policy template, it selects the negotiation mode
according to the negotiation mode of the initiator.
5-8
III. Configuring pre-shared key
Table 5-10 Configure pre-shared key
Operation Command
Configure a pre-shared key for IKE negotiation. pre-shared-key key
Remove the pre-shared key used in IKE negotiation. undo pre-shared-key
IV. Configuring ID type in IKE negotiation
Table 5-11 Configure ID type in IKE negotiation
Operation Command
Select ID type in the IKE negotiation. id-type { ip | name }
Restore the default ID type in the IKE negotiation. undo id-type
By default, IP address is taken as the ID in IKE negotiation.

In main mode, only IP address can be taken as the ID in IKE negotiation. In aggressive
mode, however, you may use either IP address or name as the ID in IKE negotiation.
V. Specifying name of the remote device
If the initiator uses its GW name in IKE negotiation (that is, id-type name is used), it
sends the name to the peer as its identity, whereas the peer uses the username
configured using the remote-name name command to authenticate the initiator. To
pass authentication, this remote name must be the same one configured using the ike
local-name command on the gateway at the initiator end.
Table 5-12 Specify name of the remote device
Operation Command
Specify the name of a remote device. remote-name name
Remove the name of the remote device. undo remote-name
VI. Configuring IP addresses of the local security GW and remote device
If the initiator uses its IP address in IKE negotiation (that is, id-type ip is used), it sends
its IP address to the peer as its identity, whereas the responder uses the address
5-9
configured using the remote-address low-ip-address [ high-ip-address ] command to

authenticate the initiator. If only the low-ip-address argument is configured on the
responder, it should be the same as the one configured using the local-address
command on the initiator; if low-ip-address and high-ip-address are all configured on
the responder (that is, an address range is specified), this address range should
include the IP address configured using the local-address command on the initiator.
The initiator of an IKE negotiation cannot specify an address range using the
remote-address command.
Table 5-13 Configure IP address of the local security GW and remote device
Operation Command
Configure IP address of the local security GW. local-address ip-address
Delete IP address of the local security GW undo local-address
remote-address low-ip-address
Configure IP address of the remote device.
[ high-ip-address ]
Delete the IP address of the remote device. undo remote-address
Generally speaking, you do not need to configure the local-address command unless
you want to specify a special address for the local GW (such as the address of
loopback interface).
VII. Configuring NAT traversal
The NAT traversal function must be configured so long as there is a NAT IPsec device
on the VPN tunnel constructed using IPsec/IKE.
Table 5-14 Configure the NAT traversal function of IPsec/IKE
Operation Command
Enable the NAT traversal function of IPsec/IKE. nat-traversal
Disable the NAT traversal function of IPsec/IKE. undo nat-traversal
To save IP address space, ISPs often deploy NAT gateways on public networks so that
private IP addresses can be allocated to users. The likelihood thus exists that at one
end of an IPsec/IKE tunnel is a public address and at the other end is a private one. To
set up the tunnel in this case, you must configure NAT traversal at both ends of the
tunnel.
5-10
VIII. Configuring subnet type of the IKE peer
You can use these two commands only when your firewall is interoperable with a
Netscreen device.
Perform the following configuration in IKE-peer view:
Table 5-15 Configure subnet type of the IKE peer
Operation Command
Configure subnet type of the local GW local { multi-subnet | single-subnet }
Restore the default subnet type of the
undo local
local GW
Configure subnet type of the peer GW peer { multi-subnet | single-subnet }
Restore the default subnet type of the
undo peer
peer GW
The default subnet type of the local GW and peer GW is single-subnet.
5.2.5 Configuring Keepalive Timer
I. Configuring keepalive interval
Configure time interval for ISAKMP SA to transmit hold packet to the peer.
Table 5-16 Configure time interval for Keepalive packet transmission
Operation Command
Configure time interval for ISAKMP SA ike sa keepalive-timer interval
to transmit Keepalive packet to the peer seconds
Disable the above function undo ike sa keepalive-timer interval
IKE will maintain the ISAKMP SA link state through this packet. Generally, if the peer
has used the ike sa keepalive-timer timeout command to configure timeout time, this
Keepalive interval must be configured on local end. When the ISAKMP SA on the peer
does not have a timeout flag if the configured timeout time expires, it will be added with
a timeout flag. When the peer receives the Keepalive packets sent from local end again
after the timeout time expires, the timeout flag will be cleared; if the ISAKMP SA on the
peer has a timeout flag, it indicates that no Keepalive packet is received within the
configured timeout time, and this ISAKMP SA and its corresponding IPsec SA will be
deleted. Therefore, the configured timeout time should be longer than Keepalive packet
transmission time.
By default, this function is invalid.
5-11
II. Configuring keepalive timeout time
Configure timeout time for ISAKMP SA waiting for Keepalive packet.

Table 5-17 Configure timeout waiting time for Keepalive packet
Operation Command
Configure ISAKMP SA timeout time for ike sa keepalive-timer timeout
waiting Keepalive packet seconds
Disable this function undo ike sa keepalive-timer timeout
IKE maintains this ISAKMP SA link status through this packet. When the ISAKMP SA
on the peer does not have a timeout flag if the configured timeout time expires, it will be
added with a timeout flag. When the peer receives the Keepalive packets sent from
local end again after the timeout time expires, the timeout flag will be cleared; if the
ISAKMP SA on the peer has a timeout flag, it indicates that no Keepalive packet is
received within the configured timeout time, and this ISAKMP SA and its corresponding
IPsec SA will be deleted. Therefore, configured timeout time should be longer than
Keepalive packet transmission time.
On the network, packet loss will rarely exceed 3 times, so timeout time can be
configured to be 3 times as long as Keepalive packet transmission time interval of the
peer.
By default, this function is invalid.
III. Configuring Keepalive sending interval
Table 5-18 Configure Keepalive sending interval
Operation Command
Define the time interval for the IKE peer to ike sa nat-keepalive-timer
send NAT Keepalive packets. interval seconds
Restore the default time interval for the IKE undo ike sa nat-keepalive-timer
peer to send NAT Keepalive packets. interval
By default, the time interval for the IKE peer to send NAT Keepalive packets is 20
seconds.
The NAT gateway sends NAT Keepalive packets to maintain dynamic mapping
between IKE peers, but not to detect the status of the peers. When defining the timer
interval, ensure that the time interval is less than the timeout time for NAT translation.
5-12
5.2.6 Disabling IKE DH Hardware Acceleration
The firewall supports IKE DH hardware acceleration. You can switch to software
processing when the encryption card becomes faulty.
Table 5-19 Disable/enable IKE DH hardware acceleration
Operation Command
ike encrypt-card dh-computation
Disable IKE DH hardware acceleration.
disabled
undo ike encrypt-card
Enable IKE DH hardware acceleration.
dh-computation disabled
By default, IKE DH hardware acceleration is enabled.
Note:
DH switching uses software processing when IKE DH hardware acceleration is
disabled, so system performance may be degraded.
5.3 Displaying and Debugging IKE

running of the IKE configuration, and to verify the effect of the configuration.
Execute debugging and reset commands in user view.
Table 5-20 Display and debug IKE
Operation Command
Display the current established display ike sa [ verbose [ connection-id
security channel id | remote-address ip-address ] ]
Display the parameters of each IKE
display ike proposal
proposal configuration.
Display the configuration of IKE peers display ike peer [ peer-name ]
Delete a security channel reset ike sa [ connection-id ]
Enable the information debugging of debugging ike { all | error | exchange |
IKE message | misc| transport }
Disable the information debugging of undo debugging ike { all | error |
IKE exchange | message | misc| transport }
5-13
You can delete a specified security channel by specifying SA connection-id which can
be displayed by executing the display ike sa command. So far as the same security
channel (that is, the same remote end) is concerned, the connection-id information
includes the information at stage 1 and the information at stage 2.
If the ISAKMP SA at stage 1 still exists when you deleting the local SA, the system will
send the DELETE message in the protection mode of the ISAKMP SA to notify the peer
to clear the SA database.
If no connection-id is specified, all the SAs at stage 1 will be removed.
Security channel and SA are totally different concepts. Security channel is a channel
via which its two endpoints can make bidirectional communications but IPsec SA is just
a unidirectional connection. In other words, security channel comprises a pair or
several pairs of SAs.
5.4 Typical Configuration of IKE

5.4.1 Typical IKE Configuration Example
z Hosts 1 and 2 communicate securely, and a security channel is established with

IKE automatic negotiation between security SecPath A and B.
z Configure an IKE proposal assigned with the priority level 10 on the security
SecPath A and apply the default IKE proposal on the security SecPath B.
z Configure authentication key for the proposal using the pre-shared key
authentication method.
II. Network diagram
Ethernet 2/0/1 Ethernet 2/0/1

202.38.160.1 171.69.224.33
SecPathA Internet SecPathB
Ethernet Ethernet
202.39.1.0 172.70.2.0
Host 1 Host 2
Figure 5-2 Network diagram of IKE configuration example
1) Make the following configurations on the SecPath A:

5-14
[H3C] ike peer peer

# Configure an IKE proposal 10.

[H3C] ike proposal 10
# Set the authentication algorithm used by the IKE proposal to MD5.

[H3C-ike-proposal-10] authentication-algorithm md5
# Apply the pre-shared key authentication mode.

[H3C-ike-proposal-10] authentication-method pre-share
# Set the lifetime duration of ISAKMP SA to 5000 seconds.

[H3C-ike-proposal-10] sa duration 5000
2) Make the following configurations on the SecPath B:
[H3C] ike peer peer
[H3C-ike-peer-peer] remote address 202.38.160.1
The configurations made above can ensure the proper IKE negotiation between
SecPath A and B. As SecPath A is configured with proposal 10 and
authentication-algorithm md5 but SecPath B is configured with only a default IKE
proposal and authentication-algorithm sha, SecPath B will not have a proposal
matching the IKE proposal 10 configured on SecPath A. For this reason, the system will
find only a match, that is, the default IKE proposal for the both parties when it makes the
match operation in proposals starting from the one with the highest priority. In addition,
no match operation will be done on duration in the proposal matching process, as the
lifetime is decided by the initiator of IKE negotiation.
For more information about IPsec configurations, see “Typical IPsec Configuration
Examples” in Chapter 5.
5.4.2 Typical IKE Aggressive Mode and NAT Traversal Configuration

Example
z The Ethernet0/0/0 interface of SecPath A has a fixed IP address in public network

and SecPath B obtains IP address dynamically.
z Since SecPath B can only access public network through NAT devices of service
provider, so a company branch has to obtain IKE aggressive mode and NAT
traversal function to set up IPsec connection.
z To ensure information security, IPsec/IKE is adopted to create a security tunnel.
5-15
II. Network diagram
Branch Internet Headquarters

E0/0/0
E0/0/0
SecPathB SecPathA
Figure 5-3 Network application of IKE aggressive mode and NAT traversal
# Set a name for the local security GW.
[H3C] ike local-name SecPathA
# Configure ACL.
[H3C-acl-adv-3101] rule permit ip source any destination any

[H3C] ike peer peer
[H3C-ike-peer-peer] exchange-mode aggressive
[H3C-ike-peer-peer] pre-shared-key abc
[H3C-ike-peer-peer] id-type name
[H3C-ike-peer-peer] remote-name SecPathB
[H3C-ike-peer-peer] nat traversal
# Create an IPsec proposal “prop”.

[H3C] ipsec proposal prop
[H3C-ipsec-proposal-prop] encapsulation-mode tunnel
[H3C-ipsec-proposal-prop] transform esp
[H3C-ipsec-proposal-prop] esp encryption-algorithm des
[H3C-ipsec-proposal-prop] esp authentication-algorithm sha1
# Create an IPsec policy and establish an SA through IKE negotiation.

[H3C] ipsec policy policy 10 isakmp
# Configure the IPsec policy and quote the IKE peer in the policy.
[H3C-ipsec-policy-isakmp-policy-10] ike-peer peer
# Quote the ACL 3101 in the IPsec policy.

[H3C-ipsec-policy-isakmp-policy-10] security acl 3101
# Quote the IPsec proposal “prop” in the IPsec policy.

[H3C-ipsec-policy-isakmp-policy-10] proposal prop
# Access the interface E0/0/0 and configure its IP address.
5-16

# Apply the IPsec policy group “policy” on the interface E0/0/0.

[H3C-Ethernet0/0/0] ipsec policy policy
# Set a name for the local security GW.
[H3C] ike local-name SecPathB
# Configure ACL.
[H3C-acl-adv-3101] rule permit ip source any destination any

[H3C] ike peer peer
[H3C-ike-peer-peer] exchange-mode aggressive
[H3C-ike-peer-peer] pre-shared-key abc
[H3C-ike-peer-peer] id-type name
[H3C-ike-peer-peer] remote-name SecPathA
[H3C-ike-peer-peer] nat traversal
# Create an IPsec proposal “prop”.

[H3C] ipsec proposal prop
[H3C-ipsec-proposal-prop] encapsulation-mode tunnel
[H3C-ipsec-proposal-prop] transform esp
[H3C-ipsec-proposal-prop] esp encryption-algorithm des
[H3C-ipsec-proposal-prop] esp authentication-algorithm sha1
# Create an IPsec policy and specify to set up SA by means of IKE negotiation.

[H3C] ipsec policy policy 10 isakmp
# Quote the IKE peer in the IPsec policy.

[H3C-ipsec-policy-isakmp-policy-10] ike-peer peer
# Quote the ACL 3101 in the IPsec policy.

[H3C-ipsec-policy-isakmp-policy-10] security acl 3101
# Quote the IPsec proposal “prop” in the IPsec policy.

[H3C-ipsec-policy-isakmp-policy-10] proposal prop
# Access the interface E0/0/0 and assign a dynamic IP address to the interface.
# Configure dial-up interface.

5-17
[H3C-Dialer1] link-protocol ppp

[H3C-Dialer1] ppp pap local-user aaa password simple aaa
[H3C-Dialer1] mtu 1450
[H3C-Dialer1] dialer user 12
# Apply the IPsec policy group “policy” on the interface Dialer 1.

[H3C-Dialer1] ipsec policy policy
5.5 IKE Fault Diagnosis and Troubleshooting

When configuring parameters to establish IPsec security channel, you can enable the
Error debugging of IKE to help us find configuration problems. The command is as
follows:
<H3C> debugging ike error
Symptom 1: Invalid user ID information

Troubleshooting: User ID is the data that the user initiating the IPsec communication
uses to identify itself. In actual applications, you can make use of user ID to set up
different security channels for various types of data traffic for the sake of protection. In
the implementation of H3C Technology, a user is so far identified by its IP address.
Following is the debugging information you may view on the screen:
got NOTIFY of type INVALID_ID_INFORMATION
Or
drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION
Check whether the ACLs of the IPsec policies configured on the interfaces at both ends
of the negotiation are compatible. The user is recommended to configure the ACLs to
mirror each other. For more information about ACL mirror, refer to Section Configure
ACL in IPsec Configuration.
Symptom 2: Proposal mismatch
Troubleshooting:
Following is the debugging information you may view on the screen:
got NOTIFY of type NO_PROPOSAL_CHOSEN
Or
drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN
The two parties of the negotiation have no matched proposal. For the negotiation at
stage 1, you can look up the IKE proposals for a match. For the negotiation at stage 2,
you can check whether the parameters of the IPsec polices applied on the interfaces
5-18
are matched, and whether the referenced IPsec proposals have a match in protocol,
encryption and authentication algorithms.
Symptom 3: Unable to establish security channel
Troubleshooting: Check whether the network is stable and the security channel is
established correctly. Sometimes there is a security channel but there is no way to
communicate, and ACL of both parties are found correctly configured, and there is also
matched policy.
In this case, the problem is usually cased by the restart of one firewall after the security
channel is established. Solution:
z Use the command display ike sa to check whether both parties have established
SA of Phase 1.
z Use the command display ipsec sa to check whether the ipsec policy on interface
has established IPsec SA.
z If the above two results display that one party has SA but the other does not, then
use the command reset ike sa to clear SA with error and re-originate negotiation.
5-19
H3C SecPath Series Security Products Chapter 6 DVPN Configuration
Chapter 6 DVPN Configuration
6.1 Introduction to DVPN

6.1.1 Overview
Dynamic virtual private network (DVPN) technology is a kind of technology that

establishes virtual private networks (VPN) by dynamically acquiring the information
about the peers. DVPN adopts a NBMA-type tunnel mechanism, which enables
devices to encapsulate and transmit packets with tunnel interfaces as the end points of
DPVN tunnels and enables devices to learn routes of private networks through tunnel
interfaces dynamically. (NBMA: non-broadcast multiple access)
DVPN technology also adopts a client-server model to overcome the drawbacks that
the traditional VPN technology suffers from. By registering with a server, clients store
their information on the server. So a registered client can then acquire information
about other registered clients through the redirecting function the server provides to
establish separate sessions with corresponding clients. By registering with the same
server, multiple DVPN-enabled access devices can form a DVPN domain to have
VPNs connected to these access devices interconnected.
6.1.2 Basic DVPN Elements
I. DVPN domain
A set of private networks and their firewalls and routers that are interconnected using
DVPN.
II. DVPN access device
Routers or firewalls in a network that are used to form DVPN domains. Any router or
firewall that supports DVPN technology can be a DVPN access device.
III. DVPN server
DVPN access device that operates as the server in a DVPN domain. DVPN access
devices must register with the DVPN server before they can access a DVPN domain.
Functions of DVPN severs are as follows.
z Storing and maintaining registering information about DVPN clients
z Authenticating clients that apply for accessing the DVPN domain
z Forwarding packets between clients with no sessions established in between, and
sending redirecting packets to source clients
z Encrypting packets using IPsec
6-1
IV. DVPN client
DVPN access device that operates as client in a DVPN domain. A device must
successfully register with the DVPN server to access a DVPN domain. Functions of
DVPN client are as follows.
z Registering with the DVPN server to join a DVPN domain
z Establishing sessions with DVPN servers for data transmission
z Establishing sessions with other DVPN clients in the DVPN domain
z Encrypting packets using IPsec
V. DVPN ID
Identifier of a DVPN domain. For a DVPN access device, different DVPN domains have
different DVPN IDs.
VI. Map
Channel established between a DVPN client and a DVPN server when the DVPN client
attempts to register with the DVPN server. A map remains after the client successfully
registers with the DVPN server until the DVPN client exit the DVPN domain or the
network. The information a map holds, such as the ID of the DVPN domain, the private
IP address of the peer, the public IP address of the peer, the UDP port number used,
the state of the map, and the control ID, is stored in both the client side and the DVPN
server side.
VII. Session
DVPN tunnel for data transmission. In a DVPN domain, sessions are established
between pairs of DVPN access devices and are used to connect private networks.
Packets in a DVPN domain are transmitted through sessions. The information a
session contains is similar to that of a map, such as the ID of the DVPN domain, the
private and public IP address of the peer, UDP port number used, the state of the
session, and the type of the session.
VIII. Redirect
Redirecting mechanism. For two clients with no session in between, communications

between them are carried out by the DVPN server. When forwarding packets between
these two clients, the DVPN server sends redirecting packets to the source client if the
DVPN server determines a separate session can be established between the two
clients. Redirecting packets contain information about the destination clients and
enable sessions to be established between clients.
IX. Active side and passive side
The two sides of a session must be either an active side or a passive side. A session
can have only one active side and one passive side. For a session established between
a client and a server, the client operates as the active side and the server operates as
6-2
the passive side. If a session is established between two clients, the one that initiates
the session is the active side and the other is the passive side.
6.1.3 Implementation
To implement DVPN, DVPN access devices must have DVPN proprietary protocol
employed, through which the DVPN server holds information about all successfully
registered clients, and the clients hold information about all sessions they establish,
such as the private IP addresses of destination devices (the IP addresses of tunnel
interfaces), the public IP addresses of destination devices (the IP addresses of WAN
interfaces), the UDP port numbers of the destination devices (when employing UDP),
the identifiers of session state. Following is the descriptions of phases undergone when
implementing DVPN to transmit data.
I. Register
After a client is configured with proper interface properties and the server address and
its interfaces are up, the client negotiates with the DVPN server for algorithm, key,
authentication (optional), information registering, policy issuing, and so on.
Registers are carried out through maps established between the clients and the servers.
A map remains after the client registers and accesses the DVPN domain. It is removed
only when the client exits the DVPN domain. If you remove a map through which a
client registers, the client releases all resources it occupies (including all sessions it
establishes) and resumes the initial state.
Figure 6-1 demonstrates the registering workflow. Any error during the workflow results
in the registering being aborted and cause the client resume the initial state.
Client (1 ) Server
(2)
(3 )
( 4)
( 5)
(6)
( 7)
(8)
Figure 6-1 DVPN registering workflow
1) The client sends algorithm negotiation request messages to the server.

2) The server sends algorithm negotiation response messages to the client.
6-3
3) The client sends key negotiation request messages and server authentication
request messages to the server.
4) The server sends key negotiation response messages, client authentication
messages, and server authentication response messages to the client.
5) The client sends authentication messages to the server.
6) The server sends authentication result to the client.
7) The client sends register request messages to the server, where all information
about the client is included.
8) The server sends register response messages to the client, where information
such as data encrypting policies, key, and the ID of the DVPN domain is included.
II. Establishing session
Immediately after a successful registration, the client establishes a session with the
DVPN server to transmit packets using DVPN. If the packets the server receives are
destined for other networks instead of the local private network, the server forwards the
packets and sends next hop redirecting messages to the source client to inform it of the
information about the destination. The client then sends session Setup requests to the
peer client to negotiate with it for establishing a separate session and the IPsec SA
(security association). After the session is established, the two clients can
communicate with each other without the server.
When removing a session, the server checks to see if it is coupled with a registered
map. If the map does not exist, the session is removed directly. Otherwise, you need to
remove the coupled map first.
III. Transmitting data
You can transmit data between entities (clients and servers) after the sessions between
them are established. The data being transmitted is encrypted using IPsec, with DES
as the encryption algorithm and MD5 as the authentication algorithm.
The encryption method mentioned above is employed by default and need not manual
configuration.
6.1.4 Basic Network Structure
DVPN adopts a client/server model. Among all the access devices in a DVPN domain,
only one can be the server and uses a fixed public IP address, whereas others operate
as clients. You need to configure information about the server manually on each client
to enable the clients to register with the server. A session is automatically established
between a client and the server after the client successfully registers with the server. By
sending redirecting packets, the server can provide information about other clients to a
client to enable sessions being established between clients, through which the DVPN
domain can be fully connected.
6-4
When transmitted in a DVPN domain, DVPN packets are encapsulated using UDP, that
is, DVPN control packets and other DVPN packets to be forwarded are encapsulated
using UDP. As UDP packets are capable of traversing NAT gateways, sessions can be
established between DVPN clients even though they use private IP addresses.
Server
Session Session
Internet
Client Session Client
Figure 6-2 A simple DVPN network diagram
6.1.5 Traditional VPN versus DVPN
I. Drawbacks of traditional VPN
Current network solutions commonly use GRE (generic routing encapsulation) or

MPLS/BGP (multiprotocol label switching/border gateway protocol) to form Layer 3
VPNs. Both of these two kinds of VPNs suffer from the following drawbacks:
z Complicated in networking and configuration. Layer 3 VPNs communicate through
point-to-point tunnels. So, to form a fully connected VPN with number of access
points of N, the number of point-to-point VPN tunnels to be manually configured is
N * (N-1) / 2.
z Inconvenient in maintenance and expansion. For an established VPN, you must
reconfigure all other nodes if you add a node to the VPN or reconfigure an existing
node in the VPN, which results in high maintaining cost.
z Unable to traverse NAT gateways. For VPN tunnels that are established using
GRE and with NAPT (network address port translation) gateways deployed at the
egresses, you must map each private IP address to a unique public IP address to
transmit packets along the VPN tunnel. So large amount of public IP addresses
are needed for this kind of VPNs. So GRE is not applicable in NAT gateways.
(VPNs that are established using early versions of IPsec cannot traverse NAT
gateways either. This problem is resolved by encapsulating IPsec packets as UDP
packets.)
z Not applicable for dynamic IP addresses. VPN tunnels that are established using
GRE are based on fixed IP addresses. So you cannot establish VPNs for dial-up
subscribers using GRE.
6-5
z Not secure. L2TP (Layer 2 tunnel protocol) and GRE do not encrypt packets.
Whereas IPsec provides satisfactory security for packets forwarded across IPsec
VPNs.
z IPsec does not support dynamical routes. VPN tunnels that are established using
GRE and L2TP are interface-based, whereas those that are established using
IPsec are data stream-oriented, so route learning is not applicable between these
two kinds of private networks interconnected with IPsec VPN tunnels, which is
contradictory to network dynamically planning.
II. Advantages of DVPN
DVPN has all advantages that traditional VPN benefits from. It also overcomes lot of
problems that traditional VPN faces. It provides an easy way to configure and plan
networks and is more powerful. It is more suitable for modern and future networks. It
features the following:
z Ease of configuration. Instead of configuring logic interfaces as the tunnel ends for
each tunnel, only one logic tunnel interface is needed for a DVPN access device to
establish sessions with multiple other DVPN access devices, which simplifies
DVPN configuration remarkably and improves maintainability and extensibility. To
add a private network to an existing DVPN domain, you need only to configure
information about the DVPN server of the DVPN domain on the DVPN access
device of the private network.
z Capable of NAT traversal. UDP-encapsulated DVPN packets are capable of
traversing NAT gateways. This enables VPN connections to be established
between internal network DVPN access devices and public network DVPN access
devices and enables VPNs that contain both internal private networks and
external private networks to be established.
z Capable of establishing dynamic IP address-based VPN. You need only to provide
the IP address of the DVPN server to establish a tunnel in a DVPN domain. So
DVPN is applicable to subscribers that use dynamic IP addresses, such as dial-up
and xDSL.
z Capable of establishing tunnels automatically. A DVPN server maintains
information about all DVPN access devices in the DVPN domain. The redirecting
function enables the DVPN clients acquire information about any other DVPN
clients in the DVPN domain from the DVPN server to establish sessions. A DVPN
client is only needed to be configured with information about itself and the DVPN
server, so the work load of network administration can be remarkably eased.
z Encrypted registration. When registering with a DVPN server, a client first
negotiates with the server for the algorithm suite and keys, and then encrypts the
key registering information (such as user name and password) using the
negotiated algorithm. They can also validate the registering packets to secure the
key registering information.
6-6
z Authentication. When registering with a DVPN server, a client can authenticate the
server using a pre-shared-key to make sure the DVPN server is valid. The DVPN
server, in turn, can identify the clients that want to access the DVPN domain using
AAA to ensure DVPN clients are authenticated.
z Centralized policy management. Policies applied to sessions in a DVPN domain
are the same. A DVPN server issues the policy of the DVPN domain to each
registered client, including the algorithm suite used in session negotiations, the
keepalive time of sessions, the idle timeout time of sessions, the IPsec encryption
algorithm, the renegotiation time of IPsec SA, and so on.
z Encryption during session negotiation. In the course of session negotiation, all the
control packets are IPsec-encrypted using the algorithm suite the DVPN server
issues. The client negotiates with the DVPN server for the IPsec SA of the session
using the encryption and authentication algorithm issued by the DVPN server. DH
(Diffie-Hellman) is used for negotiating the key of the IPsec SA. Data that are to be
encrypted and transmitted through this session are encrypted using the IPsec SA
negotiated in the course of the session establishment and then are transmitted
through the DVPN domain. The IPsec SA of a session can be renegotiated. You
can specify an IPsec SA renegotiation interval to improve security.
z Support for multiple DVPN domains. A single DVPN device can accommodate
multiple DVPN domains. That is, a firewall can belong to both DVPN domain A and
DVPN domain B simultaneously, and a DVPN device can be a client in DVPN
domain A and the DVPN server in DVPN domain B at same time. A DVPN device
can accommodate up to 200 DVPN domains and can be the DVPN server of up to
200 DVPN domains. This improves network flexibility remarkably and protects
user investment efficiently, and enables you to make full use of network device
resource. When multiple DVPN domains are configured on one DVPN device, you
can isolate these DVPN domains using private network routes.
z Support for dynamic routes. In a DVPN domain, route packets that need to be
transmitted through tunnel interfaces can be broadcast over all sessions to enable
route learning in DVPN domains. When accompanied with dynamic routing
protocols, DVPN can simplify planning of private networks that are to access a
DVPN domain and the configuration of the entire network, improve network
maintainability and automation.
6.2 DVPN Configuration

DVPN configuration comprises client configuration and server configuration.
I. Client configuration
As for DVPN clients, you need to perform basic configuration, tunnel interface
configuration, and DVPN class configuration.
1) Basic configuration
6-7
Basic configuration includes the following:

z Enable/Disable DVPN
z Configure the client registration interval
z Configure the registering retries
z Configure the dumb time
2) Tunnel interface configuration
Tunnel interface configuration includes the following:
z Encapsulate the tunnel interface using UDP DVPN
z Configure the tunnel interface to client type
z Configure the source address or source interface of the tunnel interface
z Configure the DVPN class to be applied to the tunnel interface
z Configure the DVPN domain the tunnel interface belongs to
z Configure register type (optional)
z Configure IPsec-encrypted data stream
3) DVPN class configuration
DVPN class configuration refers to configuring parameters that are necessary for a
client to register with a DVPN server and providing information used in negotiation in a
DVPN class view, it mainly includes the following:
z Create a DVPN class and enter its view
z Assign a public IP address to the DVPN server
z Assign a private IP address to the DVPN server (optional)
z Configure the register algorithm suite (optional. The default registering algorithm
suite is DES-MD5-DH1.)
z Specify how the client authenticates the DVPN server (optional)
z Configure the pre-shared-key used when the client authenticates the DVPN server
(optional)
z Configure user information used when the client registers with the DVPN server
(optional)
II. DVPN server configuration
As for a DVPN server, you need to perform basic configuration, tunnel interface
configuration, and DVPN policy suite configuration (DVPN policies are configured in
DVPN policy views), which are described as follows.
1) Basic configuration
Basic configuration includes the following:
z Enable/Disable DVPN
z Configure the map aging time
z Configure how to authenticate the clients
z Configure the pre-shared-key
2) Tunnel interface configuration
6-8
Tunnel interface configuration includes the following:

z Encapsulate the tunnel interface with UDP DVPN
z Configure the tunnel interface to server
z Configure the DVPN domain the tunnel interface belongs to
z Configure the source address or source interface of the tunnel interface
z Configure the DVPN policy the tunnel interface uses (optional)
z Configure IPsec-encrypted data stream
3) DVPN policy suite configuration
DVPN policy suite configuration includes the following:
z Create and enter a DVPN policy view
z Configure how the DVPN server authenticates the clients (optional and is NONE
by default)
z Configure the algorithm suite for a specified session (optional and is des-md5-dh1
by default)
z Configure the timeout time for a specified session (optional and is 300 seconds by
default)
z Configure the interval for sending keepalive packets (optional and is 10 seconds
by default)
z Configure the interval for sending requests to establish a session (optional and is
10 seconds by default)
z Configure the IPsec algorithm suite (optional and is des-md5-dh1 by default)
z Configure the time out time to renegotiate a specified IPsec SA (optional and is
3600 seconds by default)
To correspond to the configurations mentioned above, following sections describe how
to configure DVPN in terms of basic configuration, tunnel interface configuration, DVPN
class configuration, and DVPN policy configuration.
6.2.1 Basic DVPN Configuration
I. Enabling/Disabling DVPN
Perform these operations to enable/disable DVPN. If you disable DVPN on a DVPN

server, the existing DVPN sessions are removed after they time out.
Perform the following configuration in system view on a client or a DVPN server.
Table 6-1 Enable/Disable DVPN
Operation Command
Enable DVPN dvpn service enable
Disable DVPN undo dvpn service enable
DVPN is disabled by default.
6-9
II. Configuring the pre-shared-key
Perform these operations to configure/remove authentication information

(pre-shared-key) on a DVPN server. If a client authenticates using a pre-shared-key, it
specifies the pre-shared-key the DVPN server to be accessed uses. The specified
pre-shared-key must be identical to the one the DVPN server owns.
Perform the following configuration in system view on a DVPN server.
Table 6-2 Configure the pre-shared-key for a DVPN server
Operation Command
Configure a pre-shared-key dvpn server pre-shared-key key
Remove a pre-shared-key undo dvpn server pre-shared-key
Pre-shared-keys are not configured by default.
III. Configuring how to authenticate a client
At present, PAP (password authentication protocol) and CHAP (challenge

authentication protocol) are available for a DVPN server to authenticate a clients that
attempt to access the DVPN domain. After you perform this operation to specify how a
DVPN server authenticates a client, a DVPN server authenticates clients in the
specified way if it has no DVPN policy applied.
Perform the following configuration in system view on a DVPN server.
Table 6-3 Configure how to authenticate a client
Operation Command
dvpn server authentication-client
Configure how to authenticate a client method { none | { chap | pap }
[ domain isp-name ] }
A DVPN server does not authenticate clients by default.
IV. Configuring the map age time
You can limit the number of maps by configuring the map age time. For clients that
cannot successfully register with the DVPN server, the related maps are removed when
the map age time expires.
Table 6-4 Configure the map age time
Operation Command
Configure the map age time dvpn server map age-time time
6-10
Operation Command
Revert the map age time to the default undo dvpn server map age-time
The default map age time is 30 seconds.
V. Configuring the registering interval for a client
If a client fails to register with a DVPN server, it registers with the DVPN server again
after a specified interval. You can configure the register interval on a client.
Perform the following configuration in system view on a client.
Table 6-5 Configure the registering interval for a client
Operation Command
Configure the register interval for the dvpn client register-interval
client time-interval
Revert to the default register interval for
undo dvpn client register-interval
the client
The default register interval is 10 seconds.
VI. Configuring the register retries for a client
A client turns to dumb state if it fails to register with a DVPN server for specified times.
You can configure the maximum retries during a register round by performing this
operation.
Table 6-6 Configure the registering retries for a client
Operation Command
Configure the register retries for the client dvpn client register-retry times
Revert to the default register retries for the
undo dvpn client register-retry
client
The default register retries for the client is 3.
Caution:
A client in dumb state does not register with a DVPN server.
6-11
VII. Configuring the dumb time for a client
When registering with the DVPN server, a client can try for a specified number of times.
If all attempts fail, the client turns into the dumb state. A client in the dumb state cannot
register with the DVPN server. After a specified interval called dump interval elapses,
the client becomes active and can register with the DVPN server again.
Table 6-7 Configure the dumb time for a client
Operation Command
Configure the dumb time for the client dvpn client register-dumb time
Revert to the default dumb time for the client undo dvpn client register-dumb
The default dumb time for the client is 300 seconds.
6.2.2 Configuring the Tunnel Interface
I. Configuring the encapsulation format
Before configuring other DVPN parameters, be sure to encapsulate the tunnel interface
with UDP DVPN.
Perform the following configuration in tunnel interface view on a client or a DVPN
server.
Table 6-8 Configure the encapsulation format
Operation Command
Encapsulate the tunnel interface with
tunnel-protocol udp dvpn
UDP DVPN
A tunnel interface is encapsulated using GRE by default.
II. Configuring the type of the tunnel interface
Configure the tunnel interface as server or client type according to its location (server
side or client side).
server.
6-12
Table 6-9 Configure the type of the tunnel interface
Operation Command
Configure the type of the tunnel interface dvpn interface-type { client | server }
Restore the default type of the tunnel
undo dvpn interface-type
interface
A tunnel interface is of client type by default.
III. Configuring register type for a DVPN client
You can only use the dvpn register-type command on the client. When registering
with the server, the client can ask the server to the data packet from this client and
notify the server not to send the registering information about this client to other clients.
Perform the following configuration in tunnel interface view on the client.
Table 6-10 Configure register type for a DVPN client
Operation Command
Configure register type for the DVPN dvpn register-type { forward |
client undistributed } *
undo dvpn register-type { forward |
Remove the configuration
undistributed } *
By default, the register type for the DVPN client is not configured.
IV. Configuring the DVPN domain the tunnel interface belongs to
You can configure the ID of the DVPN domain the tunnel interface belongs to by
performing this operation. (Tunnel interfaces that belong to the same DVPN domain
have the same DVPN ID.)
server.
Table 6-11 Configure the DVPN domain the tunnel interface belongs to
Operation Command
Configure the DVPN domain the tunnel
dvpn dvpn-id dvpn-id
interface belongs to
Revert the tunnel interface to the default undo dvpn dvpn-id
A tunnel interface is not configured with a DVPN ID.
6-13
V. Configuring the source end address of the tunnel interface
The source address or source interface refers to address of the interface DVPN
packets sourced from. The source end address along with the destination address,
which must be configured on both the server end and the client end respectively,
uniquely identify a tunnel. The two addresses are source and destination addresses
mutually.
server.
Table 6-12 Configure the source end address of the tunnel interface
Operation Command
Configure the source end address or source { X.X.X.X | interface-type
source interface of the tunnel interface interface-num }
Remove the source end address or the
undo source
source interface of the tunnel interface
VI. Configuring the DVPN class to be applied to the tunnel interface (client
side only)
After configuring the DVPN server in a DVPN class view on the client side, perform the
following operations to apply the DVPN class.
Perform the following configuration in tunnel interface view on the client side.
Table 6-13 Configure/Remove the DVPN class to be applied to the tunnel interface
Operation Command
Configure the DVPN class to be applied
dvpn server dvpn-class-name
to the tunnel interface
Remove the DVPN class applied to the
undo dvpn server dvpn-class-name
tunnel interface
A tunnel interface does not have a DVPN class applied by default.
VII. Configuring the DVPN policy to be applied to the tunnel interface (server
side only)
After configuring the policy in a DVPN policy view on the server side, perform the
following operations to apply it to the DVPN domain.
Perform the following configuration in tunnel interface view on the server side.
6-14
Table 6-14 Configure/Remove the DVPN policy to be applied to the tunnel interface
Operation Command
Configure the DVPN policy to be applied
dvpn policy dvpn-policy-name
to the tunnel interface
Remove the DVPN policy applied to the
undo dvpn policy dvpn-policy-name
tunnel interface
A tunnel interface does not have a DVPN policy applied by default.
VIII. Configuring IPsec-encrypted data stream
Use the dvpn security acl command in conjunction with the acl and rule commands.
When the ACL referenced in the dvpn security acl command contains a set of deny
rules, matched packets are not to be encrypted. Note that configuring permit rules is
meaningless for the dvpn security acl command.
Table 6-15 Configure IPsec-encrypted data stream
Operation Command
Configure an ACL to specify packets that
dvpn security acl acl-number
are not IPsec-encrypted
Remove all configured ACLs undo dvpn security acl
All packets that pass through the tunnel interface are IPsec-encrypted by default.
6.2.3 Configuring a DVPN class
After configuring parameters of a specified DVPN server used for clients to register with
the DVPN server in a DVPN class view (such as private IP address, public IP address,
and user name), you need to perform corresponding configuration on the client side, as
described in the following sections.
I. Creating a DVPN class and enter its view
You can create a DVPN class and enter its view, or remove an existing DVPN class by
performing the following operations. A DVPN class that is in use cannot be removed.
6-15
Table 6-16 Create/Remove a DVPN class
Operation Command
Create and enter a DVPN class dvpn class dvpn-class-name
Remove a DVPN class view undo dvpn class dvpn-class-name
No DVPN class is configured by default.
II. Assigning a public IP address to a DVPN server
The IP address here refers to the fixed public IP address assigned to the DVPN server.
Perform the following configuration in DVPN class view.
Table 6-17 Assign a public IP address to the DVPN server
Operation Command
Assign a public IP address to the DVPN server public-ip ip-address
Remove a public IP address undo public-ip
A DVPN server is not assigned a public IP address by default.
III. Assigning a private IP address to a DVPN server
The IP address here refers to the IP address of the tunnel interface through which the
DVPN server accesses a DVPN domain and is optional. When a client configured with
the private IP address of the DVPN server registers, the response information contains
the private IP address of the DVPN server. And the client tears down the connection if
the two private IP address are not the same.
Table 6-18 Assign a private IP address to a DVPN server
Operation Command
Assign a private IP address to a DVPN server private-ip ip-address
Remove the private IP address undo private-ip
A DVPN server is not assigned a private IP address by default.
IV. Configuring the register algorithm suite
DVPN register control packets must be encrypted for security. The encryption algorithm,
authentication algorithm, and key negotiation algorithm are determined by the register
algorithm suite.
6-16
Table 6-19 Configure the register algorithm suite
Operation Command
Configure the register algorithm suite algorithm-suite suite-number
Revert to the default register algorithm suite undo algorithm-suite
The suite-number parameter is 1 by default, which stands for DES-MD5-GROUP1.

Refer to Command Manual for the meanings of other values.
V. Specifying how the client authenticates the DVPN server
A client can authenticate the DVPN server to be accessed using a pre-shared-key. The
configured pre-shared-key must be identical to the one the DVPN server holds for the
client to successfully register with the DVPN server.
Table 6-20 Specify how the client authenticates the DVPN server
Operation Command
Specify to authenticate the DVPN server authentication-server method
using the pre-shared-key pre-share
Specify not to authenticate the DVPN
authentication-server method none
server
A client does not authenticate a DVPN server by default.
Table 6-21 Configure a pre-shared-key for a DVPN server
Operation Command
Configure a pre-shared-key for a DVPN server pre-shared-key key
Remove the configured pre-shared-key undo pre-shared-key
A DVPN server is not configured with a pre-shared-key by default.
VI. Configuring the user name and password for a client
User names and passwords are used when clients register with DVPN servers. You
must configure the user name and password in a DVPN class view for a client if it is to
register with a DVPN server that authenticates registering clients.
6-17
Table 6-22 Configure the user name and password for a client
Operation Command
Configure the user name and password for a local-user username password
client { simple | cipher } password
Remove the user name and password of a client undo local-user
A client is not configured with a user name and password by default.
6.2.4 Configuring a DVPN policy
Parameters about DVPN policy, such as session algorithm, IPsec algorithm for data,
time parameters, are configured in DVPN policy views. A DVPN server issues DVPN
policies applied in the DVPN domain to clients that successfully register with it.
Caution:
After modifying and applying a policy on a tunnel interface, you must reboot the
interface or use the shutdown and undo shutdown commands on the interface to
validate the new policy.
I. Creating a DVPN policy view
You can create and enter a DVPN policy view, or remove an existing DVPN policy by
performing the following operations. To remove a DVPN policy that is applied in a
DVPN domain, you must disable it first.
Table 6-23 Create a DVPN policy view
Operation Command
Create a DVPN policy view and enter its
dvpn policy dvpn-policy-name
view
Remove a DVPN policy undo dvpn policy dvpn-policy-name
No DVPN policy is configured by default.
II. Configuring how a DVPN server authenticates clients
You can configure a DVPN server to authenticate clients that are to access the DVPN
domain. At present, you can specify to authenticate using PAP and CHAP.
6-18
Perform the following configuration in DVPN policy view.
Table 6-24 Configure how a DVPN server authenticates clients
Operation Command
Configure how a DVPN server authentication-client method { none |
authenticates clients { chap | pap } [ domain isp-name ] }
A DVPN server does not authenticate clients by default.
III. Configuring the encryption algorithm suite for a session
You can apply DES, 3DES, and AES encryption algorithms, MD5 and SHA1
authentication algorithms, and DH-group1 and DH-group2 key negotiation algorithms
to control packets transmitted during DVPN session negotiation by performing the
following operations.
Table 6-25 Configure the encryption algorithm suite for a session
Operation Command
Configure the encryption algorithm suite
session algorithm-suite suite-number
for a session
Revert to the default encryption
undo session algorithm-suite
algorithm suite
The suite-number parameter is 1 by default, which stands for DES (for encryption),
MD5 (for authentication) and DH-group1 (for key negotiation).
IV. Configuring the idle time out time for a session
A session is torn down if no packet passes through it during a specified interval known
as the idle time out time.
Table 6-26 Configure the idle time out time for a session
Operation Command
Configure the idle time out time for a session session idle-time time-interval
Revert to the default idle time out time undo session idle-time
The default idle time out time is 300 seconds.
6-19
V. Configuring the interval for sending keepalive packets
After a session is established, the active side sends keepalive packets regularly to
check the connection state of the session if no packet passes through the session. The
keepalive packet is not sent when there is any packet passes through the session.
Table 6-27 Configure the interval for sending keepalive packets
Operation Command
Configure the interval for sending session keepalive-interval
keepalive packets time-interval
Revert to the default interval for sending
undo session keepalive-interval
keepalive packets
The default interval for sending keepalive packets is 10 seconds.
VI. Configuring the interval for sending requests to establish a session
If a session is not successfully established, the initiator sends a request again to try to
establish the session after a specific interval. The initiator fails to establish a session if
the session is not established after the initiator sends three successive requests.
Table 6-28 Configure the interval for sending requests to establish a session
Operation Command
Configure the interval for sending
session setup-interval time-interval
requests to establish a session
Revert to the default interval for sending
undo session setup-interval
requests to establish a session
The default interval for sending requests to establish a session is 10 seconds.
VII. Configuring the IPsec algorithm suite
Packets transmitted in a DVPN domain are IPsec-encrypted for security. At present,

DES, 3DES, and AES encryption algorithms and MD5, SHA1 authentication algorithms
are available. You can specify the algorithm suite used when an IPsec SA forwards
packets by performing the following operations.
6-20
Table 6-29 Configure the IPsec algorithm suite
Operation Command
Configure the IPsec algorithm suite data algorithm-suite suite-number
Revert to the default IPsec algorithm suite undo data algorithm-suite
The suite-number parameter is 1 by default, which stands for DES (for encryption) and
MD5 (for authentication).
VIII. Configuring the Lifetime of IPsec SA
Table 6-30 Configure the lifetime of IPsec SA
Operation Command
data ipsec-sa duration time-based
Configure the lifetime of IPsec SA
time-interval
undo data ipsec-sa duration
Revert to the default lifetime of IPsec SA
time-based
The default lifetime of IPsec SA is 3600 seconds.
6.2.5 Displaying and Debugging DVPN
Execute the display command in any view to display how DVPN operates.
Execute the reset command in user view to clear sessions, maps, statistics information,
or initiate a DVPN domain.
Execute the debugging command in user view to debug DVPN.
Table 6-31 Display and debug DVPN
Operation Command
[undo] debugging dvpn { all | error |
event { all | register | session | misc } |
Enable/Disable debugging for DVPN
hexadecimal | packet { all | control |
data | ipsec } }
Display global information about DVPN
display dvpn info { dvpn-id dvpn-id |
in a system or information about a DVPN
global }
domain
Display information about maps in a display dvpn map {all | dvpn-id
DVPN domain dvpn-id | public-ip public-ip }
Display information about sessions in a display dvpn session { all | dvpn-id
DVPN domain dvpn-id [ private-ip private-ip ] }
6-21
Operation Command
Display information about IPsec SAs in a display dvpn ipsec-sa { all | dvpn-id
DVPN domain dvpn-id [ private-ip private-ip ] }
Display information about online DVPN
display dvpn online-user
users
Initiate a DVPN domain reset dvpn all dvpn-id
reset dvpn map public-ip port
Clear a specified map
[ client-id ]
Clear a specified session reset dvpn session dvpn-id private-ip
Clear DVPN statistics information reset dvpn statistics
Note:
If you want to use a new policy after changing the dvpn policy, you must reboot the
firewall or shutdown/undo shutdown the tunnel interface. The new policy cannot be
used by using the reset command.
6.3 DVPN Implementation

6.3.1 NAT traversal
As Figure 6-3 shows, Branch A and Branch B establish DVPN connections with the
headquarters respectively. The private network of Branch A is connected to the private
network of the headquarters through NAT (network address translation), so DVPN NAT
traversal is needed for this implementation. Detailed requirements are as follows:
z Use the default algorithm suite (algorithm suite 1) for register and sessions, that is,
use DES for encryption, MD5 for authentication, and DH-group1 for key
negotiation.
z Data is IPsec-encrypted for security using algorithm suite 1. That is, use DES for
encryption, MD5 for authentication, and DH-group1 for key negotiation.
6-22
II. Network diagram
Server
Ethernet0/0/1:10. 0. 1.1/24
Headquarters
Tunnel0 : 10.0. 0.1/24
Ethernet0/0 /0: 201. 1. 1. 1
Internet
Ethernet0/0/0: 201.1.1.2/24
Ethernet0/0/0: 201.1.1.3
Tunnel0: 10.0.0.3/24
NAT Client2
Ethernet0/0/1:192.168.1.1/24 Ethernet0/0/1:10.0.3.1/24
T unnel0:10.0.0.2/24
Ethernet0/0/0:192.168.1.2/24
Client1
Ethernet0/0/1:10.0.2.1/24
Branch B
Branch A
Figure 6-3 Network diagram for NAT traversal
1) Configure Server as follows:

# Configure Ethernet0/0/0 interface.
[Server] interface Ethernet0/0/0
[Server-Ethernet0/0/0] ip address 201.1.1.1 255.255.255.0
[Server-Ethernet0/0/0] quit

# Configure DVPN policy, with all the settings using the default value.
[Server] dvpn policy testpolicy
[Server-Policy-testpolicy] quit
# Configure Tunnel0 interface.

[Server] interface tunnel 0
[Server-Tunnel0] tunnel-protocol udp dvpn
6-23
[Server-Tunnel0] dvpn interface-type server

[Server-Tunnel0] ip address 10.0.0.1 255.255.255.0
[Server-Tunnel0] source Ethernet0/0/0
[Server-Tunnel0] dvpn dvpn-id 1
[Server-Tunnel0] dvpn policy testpolicy
[Server-Tunnel0] quit
# Configure static routes.

[Server] ip route-static 10.0.2.0 255.255.255.0 10.0.0.2
2) Configure the NAT device as follows:
[Nat] interface Ethernet0/0/0
[Nat-Ethernet0/0/0] ip address 201.1.1.2 255.255.255.0
[Nat-Ethernet0/0/0] nat outbound 3000
[Nat-Ethernet0/0/0] quit

[Nat] interface Ethernet0/0/1
[Nat-Ethernet0/0/1] ip address 192.168.1.1 255.255.255.0
[Nat-Ethernet0/0/1] quit
# Configure an ACL.
[Nat] acl number 3000
[Nat-Acl-Adv-3000] rule permit ip
# Configure a static route.

[Nat] ip route-static 10.0.2.0 255.255.255.0 192.168.1.2
3) Configure Client 1 as follows:
[Client1] interface Ethernet0/0/0
[Client1-Ethernet0/0/0] ip address 192.168.1.2 255.255.255.0
[Client1-Ethernet0/0/0] quit

# Configure the DVPN class.

[Client1] dvpn class testserver
[Client1-dvpn-class-testserver] public-ip 201.1.1.1
[Client1-dvpn-class-testserver] quit
# Configure Tunnel 0 interface.
6-24
[Client1] interface tunnel 0

[Client1-Tunnel0] ip address 10.0.0.2 255.255.255.0
[Client1-Tunnel0] tunnel-protocol udp dvpn
[Client1-Tunnel0] source Ethernet0/0/0
[Client1-Tunnel0] dvpn interface-type client
[Client1-Tunnel0] dvpn server testserver
[Client1-Tunnel0] dvpn dvpn-id 1
[Client1-Tunnel0] quit

[Client1] ip route-static 10.0.1.0 255.255.255.0 10.0.0.1


# Configure Tunnel 0 interface.


6-25
6.3.2 GRE Cooperation
As Figure 6-4 shows, the headquarters, Branch A and Branch B form a VPN. This VPN
comprises a DVPN established between the headquarters and Branch A and a VPN
established between the headquarters and Branch B using GRE.
Configure to have Server and Client 1 authenticate to each other when Client 1
attempts to access the DVPN.
II. Network diagram
Server
Headquarters Ethernet0/0/1:10. 0. 1.1/24
Tunnel1:10. 1. 0.1/24
Tunnel0 : 10.0. 0.1/24
Ethernet0/0 /0: 201. 1. 1. 1
DVPN GRE
Internet
Ethernet0/0/0: 201.1.1.2/24
Ethernet0/0/0: 201.1.1.3
Tunnel0:10.0.0.2/24 Tunnel1:1 0.1.0.2/24
Client1 Client2
Ethernet0/0/1:10.0.2.1/24 Ethernet0/0/1:10.1.2.1/24
Branch A Branch B
Figure 6-4 Network diagram for GRE cooperation
1) Configure Server as follows:


# Configure a pre-shared-key.
6-26
[Server] dvpn server pre-shared-key 123456
# Configure to authenticate locally.

[Server] domain dvpn
[Server-isp-dvpn] scheme local
[Server-isp-dvpn] quit
# Configure a DVPN policy.

[Server] dvpn policy testpolicy
[Server-dvpn-Policy-testpolicy] authentication-client method chap domain
dvpn
[Server-dvpn-Policy-testpolicy] data algorithm-suite 7
[Server-dvpn-Policy-testpolicy] session algorithm-suite 12
[Server-dvpn-Policy-testpolicy] quit
# Configure a local DVPN user.

[Server] local-user dvpnuser
[Server-luser-dvpnuser] password simple dvpnuser
[Server-luser-dvpnuser] service-type dvpn
[Server-luser-dvpnuser] quit
# Configure Tunnel 0 interface used by DVPN.

[Server-Tunnel0] tunnel-protocol udp dvpn
[Server-Tunnel0] dvpn interface-type server
[Server-Tunnel0] dvpn dvpn-id 1
[Server-Tunnel0] dvpn policy testpolicy
# Configure Tunnel 1 interface used by GRE.

[Server-Tunnel1] destination 201.1.1.3

[Server] ip route-static 10.1.2.0 255.255.255.0 tunnel1
6-27
# Configure Ethernet 0/0/1 interface.


[Client1-dvpn-class-testserver] authentication-server method pre-share
[Client1-dvpn-class-testserver] pre-shared-key 123456
[Client1-dvpn-class-testserver] local-user dvpnuser@dvpn password simple
dvpnuser


3) Configure Client 2.


[Client2-Tunnel0] destination 201.1.1.1
6-28

6-29
H3C SecPath Series Security Products Chapter 7 BGP/MPLS VPN Configuration
Chapter 7 BGP/MPLS VPN Configuration
7.1 BGP/MPLS VPN Overview

Traditional VPN, for which layer 2 tunneling protocol (L2TP, L2F and PPTP, etc.) or
layer 3 tunnel technology (IPsec, GRE and etc.) is adopted, is a great success in such
aspects as solving network security and flexibility and is widely used. However, as the
connecting domain extends, the deficiency of traditional VPN on such aspects as
expansibility and manageability becomes more and more obvious. In addition, QoS
(Quality of Service) and security are also the difficult problem for traditional VPN.
MPLS (Multiprotocol Label Switching) technology is fit for VPN networking. With MPLS
network, the IP-based VPN service can be realized easily, thus the requirements for the
expansibility and manageability of VPN are satisfied. In addition, security precautions
can be adopted on MPLS VPN to ensure that no IP connection can be established
between different VPNs and thus VPN security is guaranteed. The VPN constructed by
using MPLS also provides the possibility for the implementation of value-added service.
Multiple VPNs can be formed from a single access point, and each VPN represents a
different service, making the network able to transmit services of different types in a
flexible way.
Comware provides comparatively complete BGP/MPLS VPN networking capabilities:
z Address separation. Allow the address overlapping of the different VPN or
between VPN and public network.
z Supporting MP-BGP advertising VPN routing message, establishing BGP/MPLS
VPN.
z Forwarding VPN data stream over MPLS LSP.
z Providing MPLS VPN performance monitoring and fault detecting tools.
7-1
7.1.1 BGP/MPLS VPN Model
I. BGP/MPLS VPN model
VPN1 site 1
site 1 Backbone network of
PE the service provider CE
CE P P
PE VPN 2
CE
site 2
VPN2
P
site 3 P VPN1
PE
site 2
CE
CE
Figure 7-1 MPLS VPN model
As shown in Figure 7-1, MPLS VPN model contains three parts: CE, PE and P.
z CE (Customer Edge) device: It is a composing part of the customer network, which
is usually connected with the service provider directly via an interface. It is
commonly a router. CE cannot “sense” the existence of VPN.
z PE (Provider Edge) router: It is the Provider Edge router, namely the edge device
of the provider network, which is connected with the customer’s CE directly. In
MPLS network, PE router disposes all the processing for VPN.
z P (Provider) router: It is the backbone router in the provider network, which is not
connected with CE directly. P router needs to possess MPLS basic forwarding
capability.
The classification of CE and PE mainly depends on the range for the management of
the provider and the customer, and CE and PE are the edges of the management
domains. Firewalls can be used as the CE or PE devices.
II. Basic concepts in BGP/MPLS VPN
1) vpn-instance
vpn-instance is an important concept in VPN routing in MPLS. In actual network, each
site on PE corresponds to a single vpn-instance (their association is implemented via
interface binding). If subscribers on one site belong to multiple VPNs, then the
corresponding vpn-instance should include information about all these VPNs.
Specifically, such information should be included in vpn-instance: label forwarding table,
IP routing table, the interfaces bound with vpn-instance, and the management
7-2
information (RD, route filtering policy, member interface list, etc). It includes the VPN
membership and routing rules of this site.
PE is responsible for updating and maintaining the correlation between vpn-instance
and VPN. To avoid data leakage from the VPN and illegal data entering into the VPN,
each vpn-instance on the PE has an independent set of routing table and label
forwarding table, in which the forwarding information of the message is saved
2) MP-BGP
MP-BGP (multiprotocol extensions for BGP-4, see RFC2283) propagates VPN
membership information and routes between PE routers. It features backward
compatibility: It not only supports conventional IPv4 address family, but also supports
other address families, for example, VPN-IPv4 address family. MP-BGP ensures that
VPN private routes are only advertised within VPNs, as well as implementing
communication between MPLS VPN members.
3) VPN-IPv4 address family
VPN is just a private network, so it can use the same IP address to indicate different
sites. But the IP address is supposed as unique when MP-BGP advertises CE routes
between PE routers, so routing errors may occur for the different meaning in two
systems. The solution is to switch IPv4 addresses to VPN-IPv4 address family to
generate a globally unique address before advertising them, so PE routers is required
to support MP-BGP.
A VPN-IPv4 address consists of 12 bytes, and the first eight bytes represent the RD
(Route Distinguisher), which are followed by a 4-byte IPv4 address. The service
providers can distribute RD independently. However, their special AS (Autonomous
System) number must be taken as a part of the RD to ensure that each RD is globally
unique. The VPN-IPv4 address with the RD of zero is synonymous with the IPv4
address that is globally unique. After being processed in this way, even if the 4-byte
IPv4 address contained in VPN-IPv4 address has been overlapped, the VPN-IPv4
address can still maintain globally unique. RD is only used within the carrier network to
differentiate routes. When the RD is 0, a VPN-IPv4 address is just a IPv4 address in
general sense.
The route received by PE from CE is the IPv4 route that needs to be redistributed into
vpn-instance routing table, and in this case a RD needs to be added. It is recommended
that the same RD be configured for the same VPN.
III. VPN Target attribute
VPN Target attribute is one of the MP-BGP extension community attributes and is used
to limit VPN routing information advertisement and receiving. It identifies the set of sites
that can use some route, namely by which Sites this route can be received, and the PE
router can receive the route transmitted by which Sites. The PE routers connected with
the Site specified in VPN Target can all receive the routes with this attribute. After PE
7-3
router has received the route with this attribute, it will add the route into the
corresponding routing table.
For PE routers, there are two sets of VPN Target attributes: one of them, referred to as
Export Targets, is added to the route received from a directly connected Site in
advertising local routes to remote PE routers. And the other one, known as Import
Targets, is used to decide which routes can be redistributed into the routing table of this
Site in receiving routings from remote PE routers.
In matching the VPN Target attribute carried by the route, if there are identical items in
the export VPN target set of the route and import VPN target set of the PE, the route is
redistributed into the VPN routing table and then advertised to the CE connected.
Otherwise, the route is rejected.
ERT: Export Route Targets
RD IPv4 address ... ERT1 ERT2 ... ERTn
MPLS VPN Route

Import Route Targets:
( IRT1, IRT2, ... ,IRTm )
Figure 7-2 Route filtering via matching VPN Target attribute
Note:
The routes for other VPNs will not appear in the routing table of the VPN in question
using VPN Target attribute to filter routing information received at PE router, so the
CE-transmitted data will only be forwarded within the VPN.
7.1.2 BGP/MPLS VPN Implementation
BGP/MPLS VPN works on this principle: It uses BGP to propagate VPN private routing
information on carrier backbone network and MPLS to forward VPN service traffic.
I. Advertising VPN routing information via BGP
1) Routing information exchange between CE and PE

A PE router can learn routing information about the CE connected to it through static
route, RIP (supporting multi-instance), OSPF (supporting multi-instance) or EBGP, and
redistributes it into a vpn-instance.
7-4
2) Routing information exchange between ingress PE and egress PE

The ingress PE router uses MP-BGP to advertise routing information learned from CE
to the egress PE router (with MPLS label) and learn the CE routing information learned
at the egress PE router.
The internal connectivity among all the PEs is ensured via IGP (for example, RIP and
OSPF), so IGP should run at all interconnection interfaces and loopback interfaces.
3) LSP setup between PEs
LSPs should be set up between PEs for VPN data traffic forwarding with MPLS LSP.
The PE router that receives packets from CE and create label protocol stack is called
ingress LSR, while the BGP next hop (egress PE router) is egress LSR.
4) Routing information exchange between PE and CE
A CE can learn remote VPN routes from the PE connected through static routes, RIP,
OSPF or EBGP.
With above-mentioned steps, reachable routes can be established between CEs, for
transmission of VPN private routing information over public network.
II. Forwarding VPN packets
VPN packets are forwarded by adopting two-layer label mode:

Interior-layer label, also called MPLS label, is at the bottom in label stack and
distributed when the egress PE advertises routing information (in VPN forwarding table)
to ingress GE. When VPN packets from public network reach the CE, they can be
forwarded from the designated interface to the designated CE or site by searching for
the target MPLS forwarding table according to the labels contained.
Exterior-layer label, known as LSP initialization label, is at the top in label stack and
indicates an LSP from the ingress PE to egress PE. By switching exterior-layer label,
VPN packets can be forwarded along the LSP to the peer PE.
Figure 7-3 illustrates the details:
Layer1
1.1.1.2 Layer2 Layer2 1.1.1.2

1.1.1.2 1.1.1.2
CE1 CE2
PE1 PE2
P P
site1 site2
1.1.1.1/24 1.1.1.2/24
Figure 7-3 VPN packet forwarding
7-5
1) Site 1 sends an IPv4 packet with destination address 1.1.1.2 to CE1. CE1 looks
routing information up in the IP routing table and sends the packet to PE1.
2) PE1 looks up in the VPN-instance table according to the destination interface and
destination address to get MPLS label (or interior-layer label), LSP initialization
label (or exterior-layer label), BGP next hop (PE2), egress interface etc. When the
label stack is established, PE1 forwards via the egress interface the MPLS packet
to the first P on the LSP.
3) Every P router on the LSP forwards the MPLS packet according to the
exterior-layer label until the packet reaches the penultimate router, i.e. the P router
right before the PE2, which extracts the exterior-layer label and forwards the
packet to PE2.
4) PE2 looks up in the MPLS forwarding table according to the interior-layer label and
destination address to determine the egress interface for labeling operation and
the packet. It then extracts the interior-layer label and forwards through the egress
interface the IPv4 packet to CE2.
5) CE2 looks up in the routing table and sends the packet in normal IPv4 packet
forwarding mode to the site2.
7.1.3 Introduction to Multi-Role Host Features
As the VPN attribute of a packet that enters PE from CE is determined by the VPN
bound with the incoming interface, it in essence determines that all the CEs that obtain
the forwarding service of PE via the same incoming interface must belong to the same
VPN. In the actual networking environments, however, there is the need for a CE to
access multiple VPNs via the same physical interface. Such a requirement can be
satisfied by setting different logical interfaces, but such a stopgap solution will increase
the extra configuration works and have great limit in application. In the process of
solving this problem, the concept of multi-role host was introduced. It distinguishes the
VPNs that the packets will access by configuring policy routing based on IP address. As
for the PE-CE downstream traffic, this function is implemented via static routing. The
static routing in a multi-role host application is different from the regular static routes in
the sense that it enables a logical interface to access multiple VPNs by making use of
the static route on a VPN to specify an interface in some other VPN as the outgoing
interface.
7.1.4 OSPF VPN Extension
I. OSPF multi-instance
As one of the most popular IGP routing protocols, OSPF is used as internal routing
protocol in many VPNs. If OSPF is also used on PE-CE links, then CE routers only
need to support OSPF protocol. If you want to transform conventional OSPF backbone
into BGP/MPLS VPN, the OSPF can simplify this process.
7-6
When OSPF is used as PE-CE routing protocol in BGP/MPLS VPN application,, PE

must support OSPF multi-instance, one OSPF instance corresponds to one VPN
instance. It owns its own interface, routing table and sends VPN routing information
over MPLS network using BGP/OSPF interaction.
The following involves details about the OSPF configuration between PE and CE.
1) OSPF domain configuration between PE and CE
The OSPF domain between PE and CE can be a non-backbone area or a backbone
area.
In the application of OSPF VPN extension, the MPLS VPN backbone network is
considered as the backbone area (area 0). All the areas should be connected with the
backbone area in OSPF, so area 0 of all the VPN nodes must be connected with the
MPLS VPN backbone network.
That is, if a VPN node involves OSPF domain 0, the PE connected to CE must connect
with the backbone area of the VPN node through area 0 (The virtual link can be used
for logical connection).
2) BGP/OSPF interaction
After OSPF runs between PE and CE, PE advertises VPN routes to other PEs through
BGP and to CEs through OSPF.
As shown in Figure 7-4, PE1 connects to PE2 through the MPLS backbone network.
CE11, CE21, and CE22 belong to VPN1. Suppose all the routers in the figure belong to
the same AS, that is, CE11, CE21, and CE22 belong to the same OSPF area.
The advertisement procedure of VPN1 routes is as follows:
z BGP redistributes OSPF routes of CE11 on PE1.
z BGP advertises the VPN routes to PE2.
z OSPF redistributes BGP VPN routes on PE2, and advertises them to CE21 and
CE22.
7-7
VPN1 VPN1
Site1 Site2
OSPF Area0 OSPF Area1
CE11 CE21
Area 0 Area 1
OSPF 100 VPN1 OSPF 100 VPN1
MPLS VPN
PE1 Backbone PE2
Area 1 Area 1
CE12
CE22 VPN1
VPN2
Site1 Site3
Figure 7-4 Application of OSPF in VPN
The standard BGP/OSPF interaction enables PE2 to advertise the BGP VPN routes to
CE21 and CE22 through Type5 LSAs (ASE LSAs). However, CE11, CE21, and CE22
belong to the same OSPF area, and the route advertisement between them depends
on Type3 LSAs (inter-domain routes).
To avoid the above cases, the PE applies a modified BGP/OSPF interaction process
(shorted as BGP/OSPF interoperability). It can advertise the routes from a Site to
another, and differentiate the routes from real AS-External routes. The process requires
the extension community attribute of BGP and the information identifying OSPF
attributes.
The Comware requires that each OSPF domain have a Domain ID. It is recommended
to configure a same Domain ID for all OSPF instances in the network related to each
VPN instance, or adopt the default ID 0. In this case, all the VPN routes with the same
Domain ID come from the same VPN instance.
3) Routing loop detection
Suppose PE connects to CE through the OSPF backbone area, and a VPN Site
connects to multiple PEs. When a PE advertises BGP VPN routes learnt from
MPLS/BGP to a VPN Site through LSAs, the LSAs may possibly be received by
another PE, thus resulting in the routing loop.
To avoid the routing loop, the PE sets the flag bit DN for BGP VPN routes learnt from
MPLS/BGP when originating Type3 LSAs, regardless of whether PE connects to CE
through the OSPF backbone area. The PE ignores the Type3 LSAs for DN settings
during the route calculation of OSPF process.
To advertise a route from another OSPF domain to CE, the PE should claim an ASBR
and advertise the route as Type5 LSA. The VPN Route Tag configured for an OSPF
instance is contained in Type5 or Type7 LSAs. The PE ignores the Type5 or Type7 LSA
7-8
if the contained tag value is the same as that configured on PE during the route
calculation of OSPF process.
II. Multi-VPN-Instance CE
If supporting OSPF multi-instance, one router can run multiple OSPF procedures,
which can be bound to different VPN instances. In practice, you can create one OSPF
instance for each service type. OSPF multi-instance can fully isolate different services
in transmission, which can solve security problems with low cost. OSPF multi-instance
runs on PE router, which is called multi-VPN-instance CE. Currently, different services
in a LAN are often isolated with the VLAN function of a switch, but OSPF multi-instance
provides a solution for service isolation on routers.
Engineering
ospf 100
vpn-engineering
ospf 100
vpn-engineering
MPLS Network opsf 200 opsf 200
vpn-rd vpn-rd R&D
ospf 300
PE vpn-finances
Router Multi-VPN-Instance CE
ospf 300
vpn-finances Finances
Figure 7-5 Multi-VPN-instance CE application in conventional LAN
III. Sham Link
As shown in Figure 7-6, two Sites in a same OSPF domain connect to PE1 and PE2.
There is an OSPF link inside the area (called backdoor link) between the two Sites. The
two Sides belong to a same VPN. In this case, the route connecting the two Sites
through PEs is called the Inter-Area Route. It is not selected as the optimal route by
OSPF because its preference is lower than that of the Intra-Area Route across the
backdoor link.
Sham link
PE1 MPLS VPN Backbone PE2
Area 1 Area 1
CE12
VPN1 CE12 CE22 VPN1
Site1 Site3
Backdoor
Figure 7-6 Sham link application
7-9
In some cases, the routes across the MPLS VPN backbone network need to be firstly
selected. You can establish a sham link between PEs to make the routes become the
Intra-Area Routes.
The sham link acts as an unnumbered point-to-point link inside the area and is
advertised using Type1 LSA. You can select a route between the sham link and
backdoor link by adjusting the metric.
The sham link is considered the link between two VPN instances with one endpoint
address in each VPN instance. The address is a Loopback interface address with a
32-bit mask in the VPN address space on the PE. The same OSPF process can share
endpoint addresses between sham links, while different OSPF processes cannot.
The BGP advertises the endpoint addresses of sham links as VPN-IPv4 addresses. A
route across the sham link cannot be redistributed into BGP as a VPN-IPv4 route.
The sham link can be configured in any area. You need to configure it manually in
Comware. In addition, the local VPN instance must contain a route to the destination of
sham link.
7.1.5 Multi-AS BGP/MPLS VPN
In some networking scenarios, a user’s multiple sites belong to the same VPN may
connect to multiple ISPs that use different ASs or connect to multiple ASs of an ISP.
Such application is called Multi-AS BGP/MPLS VPN.
RFC 2547bis presents three multi-AS VPN solutions, which are:
z VPN-INSTANCE-to-VPN-INSTANCE: ASBRs manage VPN routes in between by
using subinterfaces, which is also called Inter-Provider Backbones Option A.
z EBGP Redistribution of labeled VPN-IPv4 routes: ASBRs advertise labeled
VPN-IPv4 routes to each other through MP-EBGP, which is also called
Inter-Provider Backbones Option B.
z Multihop EBGP redistribution of labeled VPN-IPv4 routes: PEs advertise labeled
VPN-IPv4 routes to each other through Multihop MP-EBGP, which is also called
Inter-Provider Backbones Option C.
The Comware supports the above three solutions.
I. Managing VPN routes between ASBRs by using subinterfaces
PEs, acting as ASBRs in two ASs, are directly connected.

ASBR PEs connect to each other through multiple subinterfaces. Considering each
other as their CE, the ASBR PEs advertise IPv4 routes to the peer using traditional
EBGP. Each subinterface is associated with a VPN. You need to bind the subinterfaces
on the ASBR to their corresponding VPN-instances but do not need to enable MPLS on
them. Within an AS, packets are forwarded as VPN packets using two-tier labels;
between ASBRs, they are forwarded using IP routing.
7-10
Ideally, each multi-AS VPN has a pair of subinterfaces for exchanging VPN routing
information.
CE-1 CE-3
VPN-1 VPN-1
PE-1 BGP/MPLS backbone BGP/MPLS backbone PE-3

AS 100 AS 200
MP-EBGP
ASBR-1 ASBR-2
(PE) (PE)
MP-IBGP Sub-interface MP-IBGP
PE-2 MP-IBGP Sub-interface MP-IBGP PE-4
VPN LSP1 VPN LSP2

IP forwarding
LSP1 LSP2
CE-2 CE-4
VPN-2 VPN-2
Figure 7-7 Network diagram for managing VPN routes between ASBRs by using
subinterfaces
This method is easily to implement. No special configuration is required on the ASBRs.

However, it has weak extensibility. Because ASBR PEs need to manage all VPN routes
and create VPN instances on a per-VPN basis. This will lead to excessive VPN-IPv4
routes on PEs, and poses high performance requirements for the PEs.
II. Advertising labeled VPN-IPv4 routes through MP-EBGP between ASBRs
Two ASBRs, through MP-EBGP, exchange labeled VPN-IPv4 routes that they obtain
from respective AS PEs.
The routes are advertised following the procedures below:
1) PEs in AS1 advertise labeled VPN-IPv4 routes to ASBR PE of AS1 or the Route
Reflector (RR) of ASBR PE through MP-IBGP.
2) ASBR PE advertises labeled VPN-IPv4 routes to ASBR PE of AS2 through
MP-EBGP.
3) ASBR PE of AS2 advertises labeled VPN-IPv4 routes to PEs in AS2 or the RR of
ASBR PE through MP-IBGP.
In this way, special processing is needed for labeled VPN-IPv4 routes on ASBRs. So it
is also called ASBR extension method.
7-11
CE-1 CE-3
VPN-1 VPN-1

AS 100 AS 200
ASBR-1 ASBR-2
(PE) (PE)
MP-IBGP MP-IBGP
MP-EBGP
PE-2 MP-IBGP MP-IBGP PE-4
VPN LSP1 VPN LSP2 VPN LSP3
LSP1 LSP2
CE-2 CE-4
VPN-2 VPN-2
Figure 7-8 Network diagram for advertising labeled VPN-IPv4 routes through
MP-EBGP between ASBRs
In terms of extensibility, advertising labeled VPN-IPv4 routes through MP-EBGP is prior

to managing VPN between ASBRs through subinterfaces.
When adopting MP-EBGP method, note that:
z ASBRs perform no VPN-Target filtering on VPN-IPv4 routes that they receive from
each other. So the ISPs in different ASs that exchange VPN-IPv4 routes need to
reach a trust agreement on the route exchange.
z VPN-IPv4 routes are exchanged only between VPN peers. A VPN user cannot
exchange VPN-IPv4 routes with the public network or with MP-EBGP peers with
whom it has not signed a trust agreement.
III. Advertising labeled VPN-IPv4 routes through multihop MP-EBGP between

PEs
The two methods above require ASBRs to participate in maintaining and distributing
VPN-IPv4 routes. When all ASs need to exchange a great amount of VPN routes,
ASBRs may become the bottleneck that prevents the extension of network.
One solution is to make PEs exchange VPN-IPv4 routes directly with each other,
without the participation of ASBRs.
Two ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through
MP-IBGP.
ASBRs neither keep VPN-IPv4 routes nor advertise VPN-IPv4 routes in between.
ASBRs keep the labeled IPv4 routes of PEs in the AS and advertise them to the peers
in other ASs. The ASBR in the transit AS also advertises labeled IPv4 routes. Therefore,
an LSP is established between ingress PE and egress PE.
7-12
PEs in different ASs establish Multihop EBGP connections with each other and
exchange VPN-IPv4 routes.
CE-1 CE-3
VPN-1 VPN-1
BGP/MPLS backbone BGP/MPLS backbone
AS 100 AS 200
PE-1 PE-3
Multi-hop MP-EBGP
ASBR-1 ASBR-2
(PE) (PE)
MP-IBGP MP-IBGP
MP-EBGP
PE-2 MP-IBGP MP-IBGP PE-4
Multi-hop MP-EBGP
VPN LSP
CE-2 LSP CE-4

VPN-2 VPN-2
Figure 7-9 Network diagram for advertising labeled VPN-IPv4 routes through Multihop
MP-EBGP between PEs
To improve the extensibility, you can specify an RR in each AS to keep all VPN-IPv4
routes and exchange VPN-IPv4 routes with PEs in the AS. The RRs in two ASs
establish multi-AS VPNv4 connection with each other and advertise VPN-IPv4 routes,
as shown in the following figure.
CE-1 CE-3
VPN-1 VPN-1

AS 100 AS 200
ASBR-1 ASBR-2
RR-1 (PE) (PE) RR-2
MP-IBGP MP-IBGP
MP-EBGP
PE-2 MP-IBGP MP-IBGP
PE-4
Multi-hop MP-EBGP
VPN LSP
CE-2 LSP CE-4

VPN-2 VPN-2
Figure 7-10 Network diagram for multi-AS VPN Option C adopting RR
7-13
7.2 BGP/MPLS VPN Configuration

To configure MPLS VPN, you are required to complete the following procedures in
general:
z Configure basic information on PE, CE and P.
z Establish the logical or physical link with IP capabilities from PE to PE.
z Advertise and update VPN network information.
I. CE
Only static route, RIP, OSPF or EBGP is configured for VPN routing information
exchange with the PE connected, without MPLS.
II. PE
It implements MPLS/BGP VPN core functions, so its configuration is a bit complicated,

including:
z Configure MPLS basic capacity, joint maintenance of LSP with P or other PE
z Configure BGP/MPLS VPN site, that is, VPN instance
z Configure static route, RIP, OSPF or MP-EBGP, for VPN routing information
exchange with CE.
z Configure IGP, for intra-PE interconnection.
z Configure MP-IBGP, for VPN routing information exchange between PEs.
III. P
MPLS basic capacity is configured, to support LDP and MPLS forwarding.

The following are detailed configurations.
7.2.1 Configuring CE
Only basic configuration is required on CE, for routing information exchange with PE.
Currently route switching modes available include static route, RIP, OSPF, EBGP,
VLAN subinterface etc.
I. Configuring static route
If you select static route mode for CE-PE route switching, you should then configure a
private static route pointing to PE on CE.
Table 7-1 Configure/delete static routes in the VPN-instance routing table
Operation Command
ip route-static ip-address { mask | mask-length }
Create a specific
{ interface-type interface-number | gateway-address }
vpn-instance static route
[ preference preference-value ] [ reject | blackhole ]
7-14
Operation Command
undo ip route-static ip-address { mask |
Delete a specific
mask-length } [interface-type interface-number |
vpn-instance static route
gateway-address ] [ preference preference-value ]
You can also specify preference for a static route. By default, the preference value for a
static route is 60.
II. Configuring RIP
If you select RIP mode for CE-PE route switching, you should then configure RIP on CE.
For details about RIP configuration, see RIP Configuration section in Routing Protocol
module of this manual.
III. Configuring OSPF
If you select OSPF mode for CE-PE route switching, you should then configure OSPF
on CE. For details about OSPF configuration, see Routing Protocol module of this
manual.
IV. Configuring EBGP
If you select BGP mode for CE-PE route switching, you should then configure EBGP
peer, redistribute directly connected route, static route and other IGP routes, for BGP to
advertise VPN routes to PE.
7.2.2 Configuring PE
I. Configuring MPLS basic capacity
It includes configuring MPLS LSR ID, enabling global MPLS and enabling MPLS in
interface view.
See section MPLS Basic Capacity Configuration for details.
II. Defining VPN-instance
1) Establish and enter vpn-instance view

The VPN instance is associated with the site. The VPN membership and routing rules
of a site is configured in the corresponding VPN instance.
This command is used to establish a new vpn-instance or enter the existing
vpn-instance view. If this vpn-instance already exists, then directly enter the view of this
vpn-instance to perform the corresponding configurations.
7-15
Table 7-2 Create and enter vpn-instance view
Operation Command
Establish and enter vpn-instance view ip vpn-instance vpn-instance_name
undo ip vpn-instance
Delete vpn-instance
vpn-instance_name
By default, no vpn-instance is defined.

2) Configure RD for VPN instance
After PE is configured with RD, MP-BGP attaches the RD behind IPv4 when BGP is
redistributed at a VPN route learned at the CE. Then the general IPv4 address is turned
into a globally unique VPN IPv4 address.
Perform the following configuration in vpn-instance view.
Table 7-3 Configure RD for VPN instance
Operation Command
Configure RD for VPN instance route-distinguisher route-distinguisher
Here, no default value is set for the parameter.

Other parameters for VPN instance (except description information) cannot be
configured before configuring RD for it.
3) Configure vpn-instance description
Table 7-4 Configure vpn-instance description
Operation Command
Configure vpn-instance description description vpn-instance-description
Delete vpn-instance description undo description
4) Configure vpn-target attribute for vpn-instance

VPN-target attribute, a BGP extension community attribute, controls advertisement of
VPN routing information.
It works on such principle:
z When BGP redistributes a VPN route learned at CE, it associates a VPN-target
extension community attribute list with the route. Usually the list is the
VPN-instance output routing attribute list associated with CE.
7-16
z VPN instance defines input routing attribute list according the

import-extcommunity in VPN-target, defining the range of routes that are
acceptable and can be redistributed.
z VPN instance modifies VPN-target attributes for the routes to be advertised,
according to the export-extcommunity in VPN-target.
Like RD, an extension community includes an ASN plus an arbitrary number or an IP
address plus an arbitrary number. There are two types of formats:
16-bit ASN: 32-bit user-defined number, for example, 100:1.
32-bit IP address: 16-bit user-defined number, for example, 172.1.1.1:1.
Table 7-5 Configure vpn-target attribute for vpn-instance
Operation Command
vpn-target vpn-target-extcommunity
Establish vpn-target extension
[ import-extcommunity |
community for vpn-instance
export-extcommunity | both ]
Delete the specified route-target undo vpn-target vpn-target-extcommunity
attribute from the vpn-target [ import-extcommunity |
attribute list export-extcommunity | both ]
By default, the value is both. In general, all sites in a VPN can be interconnected, and
the import-extcommunity and export-extcommunity attributes are the same.
Up to 16 vpn-targets can be configured with a command, and up to 256 vpn-targets can
be configured for a VPN-INSTANCE.
5) Limit the maximum route number in a vpn-instance
This command is used to limit the maximum route number for a vpn-instance to avoid
too many routes at the import of PE.
Table 7-6 Limit the maximum route number for a vpn-instance
Operation Command
Limit the maximum route number for a routing-table limit threshold-value
vpn-instance { warn-threshold | syslog-alert }
Remove maximum route number
undo routing-table limit
limitation
7-17
Note:
Changing maximum route count for VPN-instance will not affect the existing routing
table. To make the new configuration take effect immediately, you should rebuild the
corresponding routing protocol or perform shutdown/undo shutdown operation on
the corresponding interface.
6) Associate interface with vpn-instance

VPN instance is associated with the directly connected site through interface binding.
When the packets from the site reach the PE though the interface bound, then the PE
can look routing information (including next hop, label, egress interface etc.) up in the
corresponding VPN instance.
This command can associate a vpn-instance with an interface.
Table 7-7 Associate the interface with vpn-instance
Operation Command
Associate the interface with ip binding vpn-instance
vpn-instance vpn-instance-name
Remove the association of the interface undo ip binding vpn-instance
with vpn-instance vpn-instance-name
Caution:
As executing the ip binding vpn-instance command on an interface will delete the IP

address of the interface, you must configure the IP address of the interface after
executing that command when you bind the interface with a vpn-instance.
III. Configuring PE-CE routing switch
These routing switch modes are available between PE and CE: static route, RIP, OSPF,
EBGP and VLAN subinterface.
1) Configure static route on PE
You can configure a static route pointing to CE on PE for it to learn VPN routing
information from CE.
7-18
Table 7-8 Create/delete the static route in vpn-instance routing table
Operation Command
ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 …destination--address { mask |
Create a specific
mask-length } { interface-type interface-number
vpn-instance static
[ nexthop-address ] | vpn-instance vpn-nexthop-name
route
vpn-nexthop- address | nexthop-address [ public ] }
[ preference preference-value ] [ reject | blackhole ]
undo ip route-static vpn-instance vpn-instance-name1

Delete a specific vpn-instance-name2 … ip-address { mask | mask-length }
vpn-instance static { interface-type interface-number [ vpn-instance
route vpn-nexthop-name vpn-nexthop-address | nexthop-address
[ public ] } [ preference preference-value ]
You can also specify preference for a static route. By default, the preference value for a
static route is 60.
2) Configure RIP multi-instance
If you select RIP mode for CE-PE route switching, you should then specify running
environment for RIP instance on PE. With this command, you can enter RIP view and
redistribute and advertise RIP instance in the view.
Table 7-9 Configure PE-CE RIP instance
Operation Command
ipv4-family [ unicast ] vpn-instance
Create PE-CE RIP instance
vpn-instance-name
undo ipv4-family [ unicast ]
Delete PE-CE RIP instance
vpn-instance vpn-instance-name
Then configure the RIP multi-instance to induct IBGP routing.

For details about RIP configuration, see the Routing Protocol part of this manual.
3) Configure EBGP on PE
If EBGP runs between PE and CE, you should then configure neighbor for each VPN
and redistribute IGP route into CE in the VPN-instance view of MP-BGP.
Step 1: Configure peer group
Perform the following configuration in VPN-instance view of MP-BGP.
7-19
Table 7-10 Configure peer group
Operation Command
Configure a peer group group group-name [ internal | external ]
Delete the specified peer group undo group group-name
By default, the peer group is configured as internal. When BGP mode is used for
PE-CE route switching, they often belong to different ASs, so you should configure
EBGP peer as external.
Step 2: Configure AS number for a specific neighbor
When EBGP mode is used for PE-CE route switching, you should configure AS number
for a specific neighbor for every CE VPN-instance.
Perform the following configuration in VPN-instance view of MP-BGP.
Table 7-11 Configure AS number for a specific neighbor
Operation Command
peer group-name as-number as-number

Configure AS number for a
specific neighbor peer peer-address group group-name
[ as-number as-number ]
Delete the AS number of a undo peer { group-name as-number |
specific neighbor peer-address }
Step3: Redistribute IGP route

To advertise correctly VPN routing information over public network to other PEs with
which BGP adjacency has been created, a PE must redistribute the VPN routing
information of the directly connected CE into its MBGP routing table.
For example, if a static route is used between PE and CE, PE must redistribute a static
route in VPN-instance view of MBGP (import-route static). If RIP is run between PE and
CE, PE must redistribute an RIP route in VPN-instance view of MBGP (import-route rip).
If BGP is run between PE and CE, MBGP redistributes a directly connected route.
Perform the following configuration in VPN-instance view of MBGP.
Table 7-12 Redistribute IGP routes
Operation Command
Redistribute IGP routes import-route protocol [ process-id ] [ med med ]
Remove IGP route distribution undo import-route protocol
Step 4: Configure BGP in asynchronous mode
7-20
Perform the following configuration in VPN-instance view of MBGP.
Table 7-13 Configure BGP asynchronous with IGP
Operation Command
Configure BGP asynchronous with IGP undo synchronization
By default, asynchronous mode is selected.

Step 5: Permit route loop configuration in Hub&Spoke networking (optional)
Normally, PE-CE configuration can be performed by specifying the AS number of the
peer; other configurations can be performed by keeping the system default value.
In the case of standard BGP, BGP tests routing loop via AS number to avoid generating
routing loop. In the case of Hub&Spoke networking, however, PE carries the AS
number of the local autonomous system when advertising the routing information to CE,
if EBGP is run between PE and CE. Accordingly, the updated routing information will
carry the AS number of the local autonomous system when route update is received
from CE. In this case, PE cannot receive the route update information.
This phenomenon can be avoided by configuring the peer allowas-loop command,
which permits the routing loop to pass through and makes PE still receive the route
update information containing the local AS number from CE.
Perform the following configuration in IPv4 address-family sub-view.
Table 7-14 Allow/disable routing loop
Operation Command
peer { group-name | peer-address } allow-as-loop
Allow routing loop.
[number]
Disable routing loop undo peer { group-name | peer-address } allow-as-loop
By default, the received route update information is not allowed to generate loop
information.
Step 6: Configure BGP attribute.
IV. Configuring PE-PE route switching
To exchange VPN-IPv4 routing information between PEs, you should configure

MP-IBGP on PEs.
Perform the following configuration in BGP view or VPN instance view.
1) Configure IBGP
These steps are often required.
Step 1: Configure BGP as asynchronous.
7-21
Step 2: Configure BGP neighbor.

Note that BGP adjacency is established through loopback interface and the sub-net
mask must be 32 bits.
Step 3: Permit BGP session over any operable TCP interface.
In general, BGP uses the best local address in TCP connection. To keep TCP
connection available even when the interface involved fails, you can permit BGP
session over any interface through which TCP connection can be set up.
Table 7-15 Permit BGP session over any operable TCP interface
Operation Command
peer { peer-address | group-name }
Permit BGP session over any operable
connect-interface interface-type
TCP interface
interface-number
Use the best local address for TCP undo peer { peer-address |
connection group-name } connect-interface
BGP often uses the specified loopback interface to set up BGP adjacency with the peer.
This can reduce the impact of network flap, because loopback interfaces are always up.
2) Configure MP-IBGP
Step 1: Enter MP-IBGP address family view.
Table 7-16 Configure VPNv4 address family view
Operation Command
Enter MBGP VPNv4 view ipv4-family vpnv4 [ unicast ]
Exit MBGP VPNv4 view undo ipv4-family vpnv4 [ unicast ]
Step 2: Configure MBGP neighbor

Configure MBGP internal neighbor in MBGP VPNv4 view.
Step 3: Activate peer (group)
By default, BGP neighbor is active while MBGP neighbor is inactive. You should
activate MBGP neighbor in VPNv4 view.
Step 4: Configure local address as next hop in route advertisement (optional)
It is not configured by default. When configuring in multi-AS VPN Option B mode, you
must configure the IBGP peers in each involved domain with this command.
Perform the following configuration in MPGP VPNv4 view.
7-22
Table 7-17 Configure local address as next hop in route advertisement
Operation Command
Configure its address as next hop in
peer group-name next-hop-local
route advertisement
Remove the configuration undo peer group-name next-hop-local
Step 5: Transfer BGP update packet without AS number (optional)

Perform the following configuration in MPGP VPNv4 view.
Table 7-18 Transfer BGP update packet without AS number
Operation Command
Transfer BGP update packet without AS
peer group-name public-as-only
number
Transfer BGP update packet with AS
undo peer group-name public-as-only
number
V. Configuring OSPF VPN extension
Configuration of OSPF VPN extension includes:

z Running OSPF between PE and CE
z Configuring Multi-VPN-Instance CE
z Configuring sham link
1) Configure OSPF multi-instance on PE
If you select OSPF mode for CE-PE route switching, you should then configure OSPF
multi-instance on PE. It should be noted that when OSPF routes and directly connected
routes are redistributed into VPN instance, BGP routes should also be redistributed into
OSPF. Here only OSPF multi-instance configuration is detailed.
Step 1: Configure OSPF procedure.
Table 7-19 Configure OSPF procedure
Operation Command
ospf process-id [ router-id router-id-number ]
Configure an OSPF procedure
[ vpn-instance vpn-instance-name ]
Delete an OSPF procedure undo ospf process-id
By default, the procedure index is 1.
7-23
Caution:
An OSPF procedure can only belong to one VPN instance, while one VPN instance
may contain multiple OSPF procedures. By default, an OSPF procedure belongs to
public network.
Step 2: Configure domain ID

Domain ID identifies an OSPF autonomous system (AS). Each procedure is configured
with one domain ID, but different procedures may have the same domain ID.
Table 7-20 Configure domain ID
Operation Command
Configure domain ID domain-id { id-number | id-addr }
Restore the default value undo domain-id
By default, id-number is 0 and id-addr is 0.0.0.0.

It is recommended that all OSPF instances in VPN be configured with the same domain
ID or the default value 0.
Caution:
The configured value will not take effect unit the command reset ospf is executed.
Step 3: Configure tag for redistributed VPN route (optional)

If a VPN site is linked to multiple PEs, routing ring may be caused when the routes
learned by MPLS/BGP are received by another PE in being advertised by category-5/-7
LSA of a PE to the VPN site. To solve this problem, you should configure route-tag. It is
recommended to configure identical route-tag for the PEs in the same VPN.
Caution:
The configured value will not take effect unit the command reset ospf is executed.
7-24
Table 7-21 Configure tag for redistributed VPN route
Operation Command
Configure tag for an redistributed VPN route route-tag tag-number
Restore the default value undo route-tag
By default, the first two characters of tag-number are fixed to 0xD000 and the last two
ones are the AS number of the local BGP. For example, if the local BGP AS number is
100, the tag value in decimal is 3489661028. Tag-number is an integer in range of
0~4294967295.
2) Configuring Multi-VPN-Instance CE
You may configure OSPF multi-instance to isolate the services of different VPNs.
After binding an OSPF process with a VPN instance on a CE firewall, you must
configure the following command in OSPF view.
Table 7-22 Configure a firewall as multi-VPN-instance CE
Operation Command
Configure a firewall as
vpn-instance-capability simple
multi-VPN-instance CE
Remove the configuration undo vpn-instance-capability
3) Configuring a Sham-Link
Sham links are required between two CEs when backdoor links are set up between the
two PEs and service data is expected to be transmitted over MPLS backbone. A sham
link between two PEs is considered as a link in OSPF domain. Its source and
destination addresses are both the loopback interface address with 32-bit mask, but
this loopback interface should be bound to a VPN instance and directly connected
routes must be redistributed to BGP.
Perform the following configuration in OSPF domain view.
Table 7-23 Configure a sham-link
Operation Command
sham-link source-addr destination-addr [ cost
cost-value ] [ simple password | md5 keyid key ]
Configure a sham-link
[ dead seconds ] [ hello seconds ] [ retransmit
seconds ] [ trans-delay seconds ]
Remove the sham-link undo sham-link source-addr destination-addr
7-25
By default, the value of cost is 1, and the values of dead, hello, retransmit and
trans-delay are respectively 40, 10, 5 and 1 second.
VI. Configuring multi-role host attribute
After the configuration of the routing switch between PEs, configure these items on PE
to achieve multi-role application with the site connected.
Step 1: Configure VPN-instance.
In multi-role application, a site is connected to a PE through physical port, but it can
access multiple VPNs. So you need to configure multiple VPN-instances on the PE and
bind the site port with the desired VPNs. For details about VPN-instance configuration,
see II. Defining VPN-instance.
Step 2: Configure policy routing
If policy routing has been enabled and the route-policy conditions have been met, the
command in the following table can be used to specify the system to forward the
packets along the route found by looking up the configured vpn-name1, vpn-name2,
vpn-name3, vpn-name4, vpn-name5, and vpn-name6.
Table 7-24 Look up private forwarding route and make the forwarding
Operation Command
Look up private forwarding route and apply access-vpn vpn-instance
make the forwarding [ vpn-name1 vpn-name2 … ]
Remove the lookup in the specified VPN undo apply access-vpn vpn-instance
instances [ vpn-name1 vpn-name2 … ]
Step 3: Configure a private static route

Configure a static route to specify an interface in another VPN as egress interface, so
that the packets from PE to CE can be returned directly to the site.
Table 7-25 Configure static route
Operation Command
ip route-static vpn-instance vpn-instance-name1

vpn-instance-name2 … ip-address { mask | mask-length }
Configure a private
{ interface-type interface-number | [ vpn-instance
static route
vpn-nexthop-name vpn-nexthop-address ] } [ preference
preference-value ] [ reject | blackhole ]
7-26
Operation Command
undo ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 … ip-address { mask | mask-length }
Remove the static
{ interface-type interface-number [ vpn-instance
route
vpn-nexthop-name vpn-nexthop- address ] } [ preference
preference-value ] [ reject | blackhole ]
VII. Configuring multi-AS BGP/MPLS VPN
Do following configuration to achieve the Multi-AS BGP/MPLS VPN after the

configuration of the routing switch between PEs.
1) Configuring VPN-Target filtering
By default, PE performs VPN-Target filtering for the received VPNv4 routes. The routes
passing the filtering are added into the routing table, while the rest are discarded.
If PE acts as an ASBR, it needs to collect all the VPNv4 routing information and
advertise it to other ASBRs. In this case, PE accepts all the VPNv4 routing information
from its peers without filtering based on VPN-target.
Perform the following configuration in BGP-VPNv4 sub-address family view.
Table 7-26 Configure VPN-Target filtering
Operation Command
Enable VPN-Target filtering for the
policy vpn-target
VPNv4 routing information
Disable VPN-Target filtering for the
undo policy vpn-target
VPNv4 routing information
The undo policy vpn-target command is only applied to ABSR PEs in multi-AS VPN
Option B.
2) Configuring label processing on public network routes
In the Multihop MP-EBGP multi-AS VPN solution, you need to establish a multi-AS
VPN LSP. PEs and ASBRs exchange public network routes through carried MPLS label
information.
Through the route-policy, MPLS labels are assigned to those public network routes that
match certain conditions. Other routes are still common IPv4 routes.
7-27
Table 7-27 Configure label processing on public network routes
Operation Command
Assign MPLS labels to the public network routes that
apply mpls-label
match route-policy conditions
Remove the assigned MPLS labels undo apply mpls-label
Configure to only receive/transmit the public network
if-match mpls-label
routes with MPLS labels
Remove the configuration of only receiving/sending undo if-match
public network routes with MPLS labels mpls-label
By default, public network routes do not carry MPLS labels and no route-policy is
defined.
The public network routes with MPLS labels are advertised by MP-BGP. According to
RFC 3107 (Carrying Label Information in BGP-4), the label mapping information of a
route can be piggybacked by advertising BGP Update messages of the route. This
capability is implemented through BGP extension attributes and requires BGP peers
processing labeled IPv4 routes.
Table 7-28 Configure the capability for processing labeled IPv4 routes
Operation Command
Enable the capability for processing peer group-name
labeled IPv4 routes label-route-capability
Disable the capability for processing undo peer group-name
labeled IPv4 routes label-route-capability
By default, BGP peers cannot process labeled IPv4 routes.

3) Configuring invariable next hop when advertising routes
Generally, BGP Speaker changes the next hop to itself when advertising routes to
EBGP peers. In the networking application that adopts Multihop MP-EBGP multi-AS
VPN mode and uses RR to advertise VPNv4 routes, BGP Speaker cannot vary the next
hop when advertising VPNv4 routes between RRs.
Perform the following configuration in BGP view, BGP-VPNv4 sub-address family view,
BGP VPN instance view, or BGP-IPv4 multicast sub-address family view.
7-28
Table 7-29 Configure invariable next hop when advertising routes
Operation Command
Configure invariable next hop when
peer group-name next-hop-invariable
advertising routes to EBGP peers
undo peer group-name

Restore the default configuration
next-hop-invariable
By default, the next hop changes to BGP Speaker when sending routes to EBGP peers.
7.2.3 Configuring P
P does not maintain VPN routes, but do keep connection with public network and
coordinate with PE in creating LSPs. These configurations are required on P router:
Step 1: Configure MPLS basic capacity and enable LDP on the interfaces connecting P
router to PE router, for forwarding MPLS packets. For details, see Chapter 2 MPLS
Basic Capability Configuration in the MPLS module of this manual.
Step 2: Enable OSPF on the interfaces that connect P router to PE router and
redistribute directly connected routes. For details, see OSPF section in the Routing
Protocol part of this manual.
7.3 Displaying and Debugging BGP/MPLS VPN

I. Displaying VPN address information from BGP table
running of the VPNv4 information in BGP database configuration, and to verify the
effect of the configuration.
Table 7-30 Display VPN address information from BGP table
Operation Command
display bgp vpnv4 { all | route-distinguisher rd-value |
vpn-instance vpn-instance-name } { group [ group-name ] |
network | peer [ ip-address1 | verbose ] | routing
Display VPN
[ ip-address2 | statistic ] [ label ] [ as-path-acl as-path-acl |
address
cidr | community [ community-number | no-advertise |
information from
no-export | no-export-subconfed | whole-match ] |
BGP table
community-list community-list [ whole-match ] |
different-origin-as | peer ip-address1 [ advertised |
received ] | regular-expression text ] }
7-29
II. Displaying IP routing table associated with vpn-instance
After the above configuration, you can execute display command in any view to
display the corresponding information in the IP routing tables related to vpn-instance,
and to verify the effect of the configuration.
Table 7-31 Display the IP routing table associated with vpn-instance
Operation Command
display ip routing-table vpn-instance
Display the IP routing table associated
vpn-instance-name [ statistics |
with vpn-instance
[ ip-address ] [ verbose ] ]
III. Displaying vpn-instance related information
After finishing the above configuration, executing the display command in any view
can display the vpn-instance related information, including its RD, description, the
interfaces associated with it, and so on. You can view the information to verify the
configuration effect.
Table 7-32 Display the vpn-instance related information
Operation Command
Display the vpn-instance related information, display ip vpn-instance
including its RD, description, the interfaces [ vpn-instance-name |
associated with it, and so on. verbose ]
IV. Debugging information concerning processing BGP
Execute debugging command in user view for the debugging of the related
vpn-instance information.
Table 7-33 Debugging information concerning processing BGP
Operation Command
Debug information debugging bgp { { keepalive | mp-update | open |
concerning processing packet | update | route-refresh } [ receive | send |
BGP verbose ] } { all | event | normal }
undo debugging bgp { { keepalive | mp-update |
Disable the debug
open | packet | update | route-refresh } [ receive |
information
send | verbose ] } { all | event | normal }
7-30
V. Displaying MPLS l3vpn-lsp information
Table 7-34 Display MPLS l3vpn-lsp information
Operation Command
Display information on MPLS L3VPN display mpls l3vpn-lsp [ verbose]
LSPs. [ include text ]
display mpls l3vpn-lsp [ vpn-instance
Display information on the
vpn-instance-name ] [ transit | egress |
VPN-instances of MPLS L3VPN LSPs.
ingress ] [include text | verbose ]
VI. Displaying sham link
Table 7-35 Display sham link
Operation Command
Display sham link display ospf [ process-id ] sham-link
7.4 BGP/MPLS VPN Configuration Example

7.4.1 Integrated BGP/MPLS VPN Networking
z VPN-A includes CE1 and CE3; VPN-B includes CE2 and CE4
z Subscribers in different VPNs cannot access each other. The VPN-target attribute
for VPN-A is 111:1 and that for VPN-B is 222:2.
z PE and P use the firewalls, while CE is usually a mid-range or low-end device.
Note:
The configuration in this case is focused on:
z Configure EBGP to exchange VPN routing information between CE and PE.
z Configure OSPF for intra-PE communication between PEs.
z Configure MP-IBGP to exchange VPN routing information between PEs.
7-31
II. Network diagram
Figure 7-11 Network diagram for integrated BGP/MPLS VPN
The following respectively describes the configurations on PE, CE and P.

1) Configure CE1.
# Configure CE1 and PE1 as neighbors, import direct-connect routes and static routes
to import intra-CE1 VPN routes into BGP and advertise to PE1. CE1 connects PE1
through Ethernet0.
[CE1] interface ethernet 0
[CE1-Ethernet0] ip address 168.1.1.1 255.255.0.0
[CE1-Ethernet0] quit
[CE1] bgp 65410
[CE1-bgp] group 168 external
[CE1-bgp] peer 168.1.1.2 group 168 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] import-route static
Note:
The configurations on other three CEs (CE2 to CE4) are similar to that on CE1.
7-32
2) Configure PE1
# Configure vpn-instance for VPN-A on PE1, as well as other associated attributes to
control advertisement of VPN routing information.
[PE1] ip vpn-instance vpna
[PE1-vpn-vpna] route-distinguisher 100:1
[PE1-vpn-vpna] vpn-target 111:1 both
[PE1-vpn-vpna] quit
# Configure PE1 and CE1 as EBGP neighbors, import CE1 VPN routes learned into
MBGP VPN-instance address family.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 168 external
[PE1-bgp-af-vpn-instance] peer 168.1.1.1 group 168 as-number 65410
[PE1-bgp] quit
# Bind the interface Ethernet1/0/0 connecting PE1 and CE1 to the VPN-A. Note that
you should first configure association between the interface and VPN-instance, and
then the IP address.
[PE1] interface ethernet 1/0/0
[PE1-Ethernet1/0/0] ip binding vpn-instance vpna
# Configure loopback interface. (For PE, the IP address for loopback interface must be
a host address with 32-bit mask, to prevent the route is aggregated and then LSP
cannot process correctly interior-layer labels.)
[PE1] interface loopback0
[PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[PE1-LoopBack 0] quit
# Configure MPLS basic capacity, enable LDP on the interface connecting PE1 and
PE2 and the interface connecting PE1 and PE3. Establish LSP and forward MPLS
packets.
[PE1] mpls lsr-id 202.100.1.1
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls] quit
[PE1-Ethernet2/0/0] mpls
[PE1-Ethernet2/0/0] mpls ldp enable
7-33
# Enable OSPF on the interface connecting PE3 and P and the loopback interface,
import direct-connect routes.
[PE1] ospf
[PE1-ospf] area 0
[PE1-ospf-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[PE1-ospf-area-0.0.0.0] quit
[PE1-ospf] import-route direct
[PE1-ospf] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing

information. Activate the MP-IBGP peer in VPN v4 address family view.
[PE1] bgp 100
[PE1-bgp] group 202 internal
[PE1-bgp] peer 202.100.1.3 group 202
[PE1-bgp] peer 202.100.1.3 connect-interface loopback0
[PE1-bgp-af-vpn] peer 202 enable
[PE1-bgp-af-vpn] peer 202.100.1.3 group 202
[PE1-bgp] quit
3) Configure P
# Configure MPLS basic capacity, enable LDP on the interfaces connecting P and PE
for MPLS packet forwarding.
[P] mpls lsr-id 172.1.1.2
[P] mpls
[P-mpls] mpls ldp
[P-mpls] quit
[P] interface Ethernet1/0/0
[P-Ethernet1/0/0] ip address 172.1.1.2 255.255.0.0
[P-Ethernet1/0/0] mpls
[P-Ethernet1/0/0] mpls ldp enable
[P-Ethernet1/0/0] interface Ethernet2/0/0
7-34

[P-Ethernet4/0/0] quit
# Enable OSPF protocol on the interfaces connecting P and PE, import direct-connect
route to achieve intra-PE communication.
[P] ospf
[P-ospf] area 0
[P-ospf-area-0.0.0.0] network 172.1.1.0 0.0.255.255
[P-ospf-area-0.0.0.0] quit
[P-ospf] import-route direct
4) Configure PE3.
Note:
The configuration on PE3 is similar to that on PE1, you should pay more attention to
VPN routing attribute setting on PE3 to get information about how to control
advertisement of a same VPN routing information (with same VPN-target) over MPLS
network.
# Create VPN-instance for VPN-A on PE3, configure correlative attributes to control

advertisement of VPN routing information.
[PE3-vpn-vpna] quit
# Set up EBGP adjacency between PE3 and CE3, import intra-CE3 VPN routes
learned into MBGP VPN-instance address family.
[PE3] bgp 100
[PE3-bgp] quit
# Bind the interface Ethernet1/0/0 connecting PE3 and CE3 to VPN-A.
7-35

# Configure loopback interface.

[PE3-LoopBack 0] ip address 202.100.1.3 255.255.255.255
[PE3-LoopBack 0] quit
PE2 and the interface connecting PE1 and PE3. Establish LSP and forward MPLS
packets.
[PE3] mpls lsr-id 202.100.1.3
[PE3] mpls
[PE3-mpls] mpls ldp
[PE3-mpls] quit
[PE3] interface Ethernet 2/0/0
import direct-connect routes.
[PE3] ospf
[PE3-ospf-area-0.0.0.0] import-route direct

information.
[PE3] bgp 100
[PE3-bgp] group 202 internal
[PE3-bgp] peer 202.100.1.1 group 202
5) Configure PE2 and PE4
The configurations of PE2 and PE4 are similar to those of PE1 and PE3.
7-36
7.4.2 Configuring BGP/MPLS VPN using GRE Tunnel
z VPN-A includes CE-1 and CE3; VPN-B includes CE-2 and CE-4.
z PEs use the firewalls with MPLS capacity. P uses the firewall without MPLS
capacity required and CE is often a mid-range or low-end device.
II. Network diagram
P
192.168.1.0/24 192.168.2.0/24 CE-3
CE-1 ether1/0/1
ethenet1/0/0 ethernet2/0/2 ethernet1/0/0
PE 1 L0:4.4.4.9/32 PE 2
L0:1.1.1.9/32
AS 100 L0:2.2.2.9/32
CE-2
CE-4
Figure 7-12 Network diagram for BGP/MPLS VPN configuration using GRE tunnel
1) Configure CE1
# Configure CE1 and PE1 as neighbors, import direct-connect routes and static routes
to import intra-CE1 VPN routes into BGP and advertise to PE1. CE1 connects PE1
through Ethernet0.
[CE1] bgp 65410
[CE1-bgp] import-route direct
[CE1-bgp] import-route static
Note:
The configurations on other three CEs (CE2 to CE4) are similar to that on CE1.
2) Configure PE1
7-37

[PE1-vpn-vpna] quit
# Bind the interface Ethernet1/0/0 connecting PE1 and CE1 to the VPN-A.
[PE1-LoopBack0] quit
[PE1-LoopBack1/0/0] quit
[PE1] interface ethernet1/0/1
# Configure PE1 and CE1 as EBGP neighbors, import VPN-instance interface routes.
[PE1] bgp 100
[PE1-bgp-af-vpn-instance] peer 20 next-hop-local
[PE1-bgp] quit
# Set up MP-IBGP adjacency between PEs, for intra-PE VPN routing information
exchange, activate MP-IBGP peer in VPNv4 address family view.
[PE1] bgp 100
[PE1-bgp] group 2
[PE1-bgp] peer 2.2.2.9 group 2
import direct-connect routes to achieve intra-AS communication.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] import-route direct
7-38
# Configure MPLS.
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] mpls ldp
# Configure GRE tunnel

[PE1] interface tunnel 1
[PE1-Tunnel1] tunnel-protocol gre
[PE1-Tunnel1] source loopback 0
[PE1-Tunnel1] destination 2.2.2.9
[PE1-Tunnel1] mpls
[PE1-Tunnel1] mpls ldp enable
[PE1-Tunnel1] mpls ldp transport-ip interface
Note:
z The configuration of PE2 is similar to that on PE1.
z The configuration of VPN_B is similar to that on VPN_A. However, you need to set a
unique route distinguisher for VPN_B, and set VPN target attribute correctly, thus to
ensure routes can only be imported to corresponding VPN instances.
3) Configure P
# Configure interface.
[P] interface ethernet1/0/0
[P-ethernet1/0/0] ip address 192.168.1.2 255.255.255.0
[P] interface ethernet2/0/1
[P-ethernet2/0/1] ip address 192.168.2.2 255.255.255.0
# Enable OSPF protocol.

[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] import-route direct
7.4.3 Extranet Networking
Both Company A and Company B are based in City C. They are interconnected with
VPN and respectively own VPN1 and VPN2.
7-39
MPLS provides VPN function. There are some shared resources at the City C for two
VPNs. All VPN subscribers can access the shared resources, but VPN subscribers in
City A and City B cannot access each other.
The two companies cannot use identical IP addresses, for they share the same
VPN-instance at PE-C.
Note:
In this example the configuration is focused on controlling access authority of VPN
subscribers at different cities by configuring different VPN-target attributes at different
PEs.
II. Network diagram
Service provider
network
AS100
PE-A
PE-C PE-B
10.1.1.1
20.1.1.1 30.1.1.1
172.15.0.1/16 172.16.0.1/16 Ethernet1/0/0
Ethernet2/0/0 Ethernet2/0/0 172.17.0.1/16 Ethernet2/0/0
172.15.1.1/16 172.16.1.1/16 172.17.1.1/16
City A
CE-A City C CE-C City B CE-B
AS65011 AS65012 AS65013
10.11.1.0/24 10.12.1.0/24
PC PC PC PC PC PC PC
VPN 1
VPN 2
Figure 7-13 Extranet network diagram
7-40
Note:
The example omits the configuration of basic MPLS capacity between the PEs and
between the PE and P. For these details refer to the former example.
1) Configure PE-A
# Configure VPN-instance for VPN1 on PE-A, so that it can receive VPN routing
information of VPN-target 111:1.
[PE-A] ip vpn-instance vpn1
[PE-A-vpn-vpn1] route-distinguisher 100:1
[PE-A-vpn-vpn1] vpn-target 111:1 both
[PE-A-vpn-vpn1] quit
# Set up EBGP adjacency between PE-A and CE-A, import intra-CE-A VPN routes
[PE-A] bgp 100
[PE-A-bgp] ipv4-family vpn-instance vpn1
[PE-A-bgp-af-vpn-instance] group 172 external
[PE-A-bgp-af-vpn-instance] peer 172.15.1.1 group 172 as-number 65011
[PE-A-bgp-af-vpn-instance] import-route direct
[PE-A-bgp-af-vpn-instance] import-route static
[PE-A-bgp-af-vpn-instance] quit
[PE-A-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-A with VPN-instance.

[PE-A] interface ethernet 1/0/0
[PE-A-Ethernet1/0/0] ip binding vpn-instance vpn1
[PE-A-Ethernet1/0/0] ip address 172.15.0.1 255.255.0.0
[PE-A-Ethernet1/0/0] quit

[PE-A] interface loopback 0
[PE-A-LoopBack0] ip address 10.1.1.1 255.255.255.255
[PE-A-LoopBack0] quit
# Configure MPLS basic capacity.

[PE-A] mpls lsr-id 10.1.1.1
[PE-A] mpls
[PE-A-mpls] quit
[PE-A] mpls ldp
7-41

information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE-A] bgp 100
[PE-A-bgp] group 20
[PE-A-bgp] peer 20.1.1.1 group 20
[PE-A-bgp] peer 20.1.1.1 connect-interface loopback 0
[PE-A-bgp] group 30
[PE-A-bgp] peer 30.1.1.1 group 30
[PE-A-bgp] peer 30.1.1.1 connect-interface loopback 0
[PE-A-bgp] ipv4-family vpnv4
[PE-A-bgp-af-vpn] peer 20 enable
[PE-A-bgp-af-vpn] peer 20.1.1.1 group 20
[PE-A-bgp-af-vpn] peer 30 enable
[PE-A-bgp-af-vpn] peer 30.1.1.1 group 30
[PE-A-bgp-af-vpn] quit
2) Configure PE-C
# Create a VPN-instance on PE-C, so that it can transceive VPN routing information of
VPN-target 111:1 and 222:2.
[PE-C] ip vpn-instance vpn2
[PE-C-vpn-vpn2] route-distinguisher 100:2
[PE-C-vpn-vpn2] vpn-target 111:1
[PE-C-vpn-vpn2] vpn-target 222:2
[PE-C-vpn-vpn2] quit
# Set up EBGP adjacency between PE-C and CE-C, import intra-CE-C VPN routes
[PE-C] bgp 100
[PE-C-bgp] ipv4-family vpn-instance vpn2
[PE-C-bgp-af-vpn-instance] group 172 external
[PE-C-bgp-af-vpn-instance] peer 172.16.1.1 group 172 as-number 65012
[PE-C-bgp-af-vpn-instance] import-route direct
[PE-C-bgp-af-vpn-instance] import-route static
[PE-C-bgp-af-vpn] quit
[PE-C-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-C with VPN-instance.

[PE-C] interface ethernet 1/0/0
[PE-C-Ethernet1/0/0] ip binding vpn-instance vpn2
[PE-C-Ethernet1/0/0] ip address 172.16.0.1 255.255.0.0

[PE-C] interface loopback 0
[PE-C-LoopBack0] ip address 20.1.1.1 255.255.255.255
7-42
[PE-C-LoopBack0] quit

[PE-C] mpls lsr-id 20.1.1.1
[PE-C] mpls
[PE-C-mpls] quit
[PE-C] mpls ldp

[PE-C] bgp 100
[PE-C-bgp] group 10
[PE-C-bgp] peer 10.1.1.1 group 10
[PE-C-bgp] peer 10.1.1.1 connect-interface loopback 0
[PE-C-bgp] group 30
[PE-C-bgp] peer 30.1.1.1 group 30
[PE-C-bgp] peer 30.1.1.1 connect-interface loopback 0
[PE-C-bgp] ipv4-family vpnv4
[PE-C-bgp-af-vpn] peer 10 enable
[PE-C-bgp-af-vpn] peer 10.1.1.1 group 10
[PE-C-bgp-af-vpn] peer 30 enable
[PE-C-bgp-af-vpn] peer 30.1.1.1 group 30
[PE-C-bgp-af-vpn] quit
3) Configure PE-B
# Create VPN-instance for VPN2 on PE-B, so that it can transceive VPN routing
information of VPN-target 222:2.
[PE-B] ip vpn-instance vpn3
[PE-B-vpn-vpn3] route-distinguisher 100:3
[PE-B-vpn-vpn3] vpn-target 222:2
[PE-B-vpn-vpn3] quit
# Set up EBGP adjacency between PE-B and CE-B, import intra-CE-B VPN routes
[PE-B] bgp 100
[PE-B-bgp] ipv4-family vpn-instance vpn3
[PE-B-bgp-af-vpn-instance] group 172 external
[PE-B-bgp-af-vpn-instance] peer 172.17.1.1 group 172 as-number 65013
[PE-B-bgp-af-vpn-instance] import-route direct
[PE-B-bgp-af-vpn-instance] import-route static
[PE-B-bgp-af-vpn-instance] quit
[PE-B-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-B with VPN-instance.

[PE-B] interface ethernet 1/0/0
7-43
[PE-B-Ethernet1/0/0] ip binding vpn-instance vpn3

[PE-B-Ethernet1/0/0] ip address 172.17.0.1 255.255.0.0
[PE-B-Ethernet1/0/0] quit

[PE-B] interface loopback 0
[PE-B-LoopBack0] ip address 30.1.1.1 255.255.255.255
[PE-B-LoopBack0] quit

[PE-B] mpls lsr-id 30.1.1.1
[PE-B] mpls
[PE-B-mpls] quit
[PE-B] mpls ldp

[PE-B] bgp 100
[PE-B-bgp] group 10
[PE-B-bgp] peer 10.1.1.1 group 10
[PE-B-bgp] peer 10.1.1.1 connect-interface loopback 0
[PE-B-bgp] group 20
[PE-B-bgp] peer 20.1.1.1 group 20
[PE-B-bgp] peer 20.1.1.1 connect-interface loopback 0
[PE-B-bgp] ipv4-family vpnv4
[PE-B-bgp-af-vpn] peer 10 enable
[PE-B-bgp-af-vpn] peer 10.1.1.1 group 10
[PE-B-bgp-af-vpn] peer 20 enable
[PE-B-bgp-af-vpn] peer 20.1.1.1 group 20
[PE-B-bgp-af-vpn] quit
7.4.4 Hub&Spoke Networking
Hub&Spoke networking is also called central server networking. The site in the center
is called hub-site, while the one not in the center is called spoke-site. The hub-site
knows the routes to all other sites in the same VPN, and the spoke-site must send its
traffic first to hub-site and then to the destination. Hub-site is the central node for
spoke-sites.
A bank has its headquarters network and subsidiary networks, and it requires that
subsidiaries cannot exchange data with each other, but through the headquarters
network. Hub&Spoke networking topology is used here: CE2 and CE3 are as
spoke-sites, while CE1 is as the hub-site of the bank data center. CE1 controls
communication between CE2 and CE3.
7-44
z Set up IBGP adjacency between PE1 and PE2, between PE1 and PE3, but not
between PE2 and PE3, that is, VPN routing information cannot be exchanged
between PE2 and PE3.
z Create two VPN-instances on PE1, import VPN routes of VPN-target 100:1, set
VPN-target for VPN routes advertised as 100:2.
z Create one VPN-instance on PE2, import VPN routes of VPN-target 100:2, set
z Create one VPN-instance on PE3, import VPN routes of VPN-target 100:2, set
Then PE2 and PE3 can only learn their neighbor’s routes through PE1.
Note:
In the case the configuration is focused on two points:
z Route advertisement can be controlled by VPN-target settings on different PEs.
z One routing loop is permitted, so that PE can receive route update messages with
AS number included from CE.
II. Network diagram
CE1
Hub Site
Ethernet1/0/0.2 Ethernet1/0/0.1
172.17.0.1/16 172.16.0.1/16
PE1
Loopback0
11.1.1.1/32
MPLS
Spoke Site Spoke Site
PE3
CE2 PE2 20.1.1.2 CE3
Loopback0 Loopback0
172.15.0.1/16 172.18.0.1/16
22.1.1.1/32 33.1.1.1/32
Figure 7-14 Hub&Spoke network diagram
7-45
Note:
The example omits the configuration of basic MPLS capacity between the PEs and CE
configuration. See 7.4.1 “Integrated BGP/MPLS VPN Networking” for details.
1) Configure PE1
# Configure two VPN-instances on PE1, set specified VPN-target for the routes
received from PE2 and PE3.
[PE1] ip vpn-instance vpn-instance2
[PE1-vpn-vpn-instance2] route-distinguisher 100:2
[PE1-vpn-vpn-instance2] vpn-target 100:1 import-extcommunity
[PE1-vpn-vpn-instance2] quit
[PE1-vpn-vpn-instance3] route-target 100:2 export-extcommunity
learned into MBGP VPN-instance address family, with one routing loop permitted.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn-instance2
[PE1-bgp-af-vpn-instance] peer 172.16.1.1 allow-as-loop 1
[PE1-bgp-af-vpn-instance] import-route static
[PE1-bgp-af-vpn-instance] peer 172.17.1.1 allow-as-loop 1
[PE1-bgp] quit
# Bind the interface connecting PE1 and CE1 to different VPN-instances. # Bind the
interface Ethernet1/0/0.1 with VPN-instance 2 and interface Ethernet1/0/0.2 with
VPN-instance 3.
7-46
[PE1] interface ethernet 1/0/0.1

[PE1-Ethernet1/0/0.1] ip binding vpn-instance vpn-instance2
[PE1-Ethernet1/0/0.1] ip address 172.16.0.1 255.255.0.0
[PE1-Ethernet1/0/0.1] quit
[PE1] interface ethernet 1/0/0.2
[PE1-Ethernet1/0/0.2] ip binding vpn-instance vpn-instance3
[PE1-Ethernet1/0/0.2] ip address 172.17.0.1 255.255.0.0
[PE1-Ethernet1/0/0.2] quit

[PE1] interface loopback 0

[PE1] bgp 100
[PE1-bgp] group 22
[PE1-bgp] peer 22.1.1.1 connect-interface loopback 0
[PE1-bgp] group 33
2) Configure PE2
# Create a VPN-instance on PE2, import VPN routing information of VPN-target 100:2
and advertise VPN routing information of VPN-target 100:1.
[PE2-vpn-vpn-instance1] route-target 100:2 import-extcommunity
[PE2] bgp 100
7-47

[PE2-bgp] quit
# Bind the interface connecting PE2 and CE2 with VPN-instance.

[PE2-Ethernet1/0/0] ip binding vpn-instance vpn-instance1


[PE2] bgp 100
[PE2] group 11
[PE2-bgp] quit
3) Configure PE3
# Create a VPN-instance on PE3, import VPN routing information of VPN-target 100:2
and advertise VPN routing information of VPN-target 100:1.
[PE3-vpn-vpn-instance2] route-target 100:2 import-extcommunity
# Set up EBGP adjacency between PE3 and CE3 import intra-CE3 VPN routes learned
into MBGP VPN-instance address family.
[PE3] bgp 100
[PE3-bgp-af] group 172 external
7-48

[PE3-bgp] quit
# Bind the interface connecting PE3 and CE3 with VPN-instance.

[PE3-Ethernet1/0/0] ip binding vpn-instance vpn-instance2


[PE3] bgp 100
[PE3-bgp] group 11
[PE3-bgp] quit
7.4.5 CE Dual-Homed Networking
For the applications which require high robustness of network, you may use CE
dual-homed networking mode.
CE1 and CE2 are respectively connected to PE1 and PE2 to achieve dual-homed
configuration. Three PEs are also connected to each other as back links. CE3 and CE4
are not in dual-homed mode, and only connected to one PE.
CE1 and CE3 are in one VPN, and CE2 and CE4 are in another VPN. Two VPNs
cannot access each other.
7-49
II. Network diagram
AS:65003 AS:65004
CE3 CE4
192.168.13.2/24 192.168.23.2/24
Loopback0
3.3.3.3/32
192.168.13.1/24 192.168.23.1/24
30.1.1.1/24 20.1.1.2/24
PE3
30.1.1.2/24 AS:100 20.1.1.1/24
Loopback0 Loopback0
1.1.1.1/32 Ethernet3/0/0 Ethernet3/0/0
10.1.1.1/24 10.1.1.2/24 2.2.2.2/32
Ethernet1/0/0 PE1 Ethernet2/0/0 Ethernet2/0/0 PE2 Ethernet1/0/0

172.11.11.1/24 172.21.21.1/24 172.12.12.1/24 172.22.22.1/24
172.11.11.2/24 172.22.22.2/24
172.12.12.2/24 172.21.21.2/24
CE1 CE2
AS:65001 AS:65002
Figure 7-15 CE dual-homed networking diagram
Note:
The configuration of CE is omitted in this case and you can refer to 7.4.1 “Integrated
BGP/MPLS VPN Networking”.
1) Configure PE1
# Configure two VPN-instances 1.1 and 1.2 respectively for CE1 and CE2 on PE1, set
different VPN-targets for them.
[PE1] ip vpn-instance vpn-instance1.1
[PE1-vpn-vpn-instance1.1] route-distinguisher 1.1.1.1:1
[PE1-vpn-vpn-instance1.1] route-target 1.1.1.1:1
[PE1-vpn-vpn-instance1.1] vpn-target 2.2.2.2:1 import-extcommunity
[PE1-vpn-vpn-instance1.1] quit
7-50
[PE1-vpn-vpn-instance1.2] route-target 1.1.1.1:2

learned into VPN-instance 1.1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn-instance1.1
[PE1-bgp] quit
learned into VPN-instance 1.2.
[PE1-bgp] quit
# Bind the interface connecting PE1 and CE1 with VPN-instance 1.1 and interface
connecting PE1 and CE2 with VPN-instance 1.2.
[PE1-Ethernet1/0/0] ip binding vpn-instance vpn-instance1.1

PE2 and the interface connecting PE1 and PE3.
7-51
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls] quit
[PE1] interface Ethernet 3/0/0
[PE1-Ethernet3/0/0] interface Ethernet 4/0/0
# Enable OSPF on the interface connecting PE1 and PE2 and the interface connecting
PE1 and PE3 and the loopback interface, to achieve intra-PE communication.
[PE1] router id 1.1.1.1
[PE1] ospf
[PE1-ospf] area 0
[PE1-ospf-area-0.0.0.0] quit
[PE1-ospf] quit

[PE1] bgp 100
[PE1-bgp] group 2
[PE1-bgp] group 3
2) Configure PE2
7-52
Note:
The configuration of PE2 is similar to that of PE1, so only VPN-instance configuration is
detailed here.
# Create two VPN-instances 2.1 and 2.2 respectively for CE1 and CE2 on PE2,
configure different VPN-targets for them.
[PE2-vpn-vpn-instance2.1] vpn-target 2.2.2.2:1
learned into VPN-instance2.1.
[PE2] bgp 100
[PE2-bgp] quit
# Bind the interface connecting PE2 and CE1 with VPN-instance 2.1 and the interface
7-53

3) Configure PE3.
Note:
Only VPN-instance configuration is detailed here for PE3, and others are similar to
those of PE1 and PE2.
# Create two VPN-instances 3.1 and 3.2 respectively for CE3 and CE4 on PE3,
configure different VPN-targets for them.
[PE3] bgp 100
[PE3-bgp] quit
7-54

[PE3-bgp] quit
# Bind the interface connecting PE3 and CE3 with VPsN-instance3.1 and the interface
7.4.6 Multi-Role Host Networking
A company provides VPN service with BGP/MPLS VPN.

The interface Serial1/0/0 connecting PE1 and CE1 is bound with VPN1 and the
interface Serial0/0/0 connecting PE2 and CE2 is bound with VPN2.
PC1, with IP address 100.1.1.2, is accessed into the VPN1 and VPN 2 through CE1.
Note:
In the case, the configuration is focused on this point:
With proper configuration of static route and routing policy, PC1 can access packets in
different VPNs and search routes in different VPN-instances.
7-55
II. Network diagram
PE1 Ethernet1/0/0: PE2

2.1.1.1/24
Ethernet0/0/0: Ethernet1/0/0:
1.1.1.2/24 Ethernet0/0/0:
Ethernet0/0/0: 2.1.1.2/24 Ethernet0/0/0: 3.1.1.2/24
CE1 1.1.1.1/24 3.1.1.1/24
CE2
Ethernet2/0/0:
100.1.1.1/24 Ethernet2/0/0:
110.1.1.1/24
PC1
100.1.1.2/24 PC2
Figure 7-16 Multi-role host networking diagram
1) Configure CE1.
# Configure a default route to PE1 on CE1.
[CE1] ip route-static 0.0.0.0 0 1.1.1.1
2) Configure PE1
# Configure two VPN-instances respectively for VPN1 and VPN2 on PE1, set different
VPN-targets for them.
[PE1] ip vpn-instance vpn1
[PE1-vpn-vpn1] route-distinguisher 100:1
[PE1-vpn-vpn1] vpn-target 100:1 both
[PE1-vpn-vpn1] quit
[PE1] ip vpn-instance vpn2
[PE1-vpn-vpn2] route-distinguisher 100:2
[PE1-vpn-vpn2] vpn-target 100:2 both
[PE1-vpn-vpn2] quit
# Bind the interface connecting PE1 and CE1 with VPN 1.

[PE1-Ethernet0/0/0] ip binding vpn-instance vpn1
# Configure a static route, so that the packets returned from VPN2 can find the correct
route in the VPN-instance vpn1 on PE1 and travel along this route back to PC1.
(Correspondingly, configure MBGP to import the static route on PE2, so that MBGP can
advertise the route among VPN2.)
7-56
[PE1] ip route-static vpn-instance vpn2 100.1.0.0 16 vpn-instance vpn1 2.1.1.2
# Configure a policy-based route, so that the packets from PC1 can find a private route
in VPN-instance vpn1 and vpn2 simultaneously and get forwarded.
[PE1-acl-adv-101] rule 0 permit ip vpn-instance vpn1 100.1.1.2 0
[PE1] route-policy aaa permit node 10
[PE1-route-policy] if-match acl 101
[PE1-route-policy] apply access-vpn vpn-instance vpn1 vpn2
[PE1-route-policy] quit
# Enable routing policy at the interface Ethernet0/0/0.

[PE1-Ethernet0/0/0] ip policy route-policy aaa
For other settings, refer to the previous example.
7.4.7 OSPF Multi-Instance Sham Link Networking
A company is connected to WAN using the OSPF multi-instance function of the firewall,
with OSPF bound to VPN1. Between the PEs is MPLS VPN backbone network. OSPF
runs between the PE and CE. Configure a sham link between PE1 and PE2, so that the
traffic between CE1 and CE2 can bypass the backdoor link directly connected between
them.
II. Network diagram
LoopBack0: LoopBack0:
1.1.1.1 3.3.3.3
CE1 PE1 PE3
10.10.10.10 1.1.1.1 E2/0/0 3.3.3.3
E1/0/0 E1/0/0 LoopBack1
LoopBack1: E2/0/0
10.1.1.0/24 50.1.1.1 50.1.1.3
E0/0/0 E0/0/0 E0/0/0

MPLS VPN
Backbone
12.1.1.0/24 (backdoor) sham link (168.1.1.0/24)
E0/0/0
E0/0/0 E2/0/0
20.2.1.0/24
LoopBack1:50.1.1.2
E1/0/0 E1/0/0
PE2
CE2 2.2.2.2
20.20.20.20
LoopBack0:
2.2.2.2
Figure 7-17 Network diagram for OSPF multi-instance configuration
7-57
1) Configure PE1
# Enable MPLS and LDP.
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1] ip vpn-instance VPN1
[PE1-vpn-VPN1] route-distinguisher 2:1
[PE1-vpn-VPN1] vpn-target 100:1 export-extcommunity
[PE1-vpn-VPN1] vpn-target 100:1 import-extcommunity
[PE1-Ethernet0/0/0] ospf cost 1
[PE1-Ethernet0/0/0] mpls ldp transport-ip interface
[PE1-Ethernet1/0/0] ip binding vpn-instance VPN1
[PE1-Ethernet2/0/0]ospf cost 1
[PE1-LoopBack0] ip binding vpn-instance VPN1
# Configure BGP peer.

[PE1] bgp 100
[PE1-bgp] undo synchronization
[PE1-bgp] group fc internal
[PE1-bgp] peer 2.2.2.2 group fc
[PE1-bgp] peer 3.3.3.3 group fc
7-58
# Configure BGP to import OSPF route and direct-connect route.

[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-af-vpn-instance] import-route ospf 100
[PE1-bgp-af-vpn-instance] import-route ospf-ase 100
[PE1-bgp-af-vpn-instance] import-route ospf-nssa 100
# Create peer in MBGP and activate it.

[PE1-bgp-af-vpn] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer fc enable
[PE1-bgp-af-vpn] peer fc advertise-community
[PE1-bgp-af-vpn] peer 2.2.2.2 group fc
# Bind OSPF process to vpn-instance.

[PE1] ospf 100 router-id 1.1.1.1 vpn-instance VPN1
[PE1-ospf-100] import-route bgp
[PE1-ospf-100] area 0.0.0.1
Configure a sham link

[PE1-ospf-100-area-0.0.0.1] sham-link 1.1.1.1 2.2.2.2
# Configure static routes to PE2 and PE3.

[PE1] ip route-static 50.1.1.2 255.255.255.255 168.1.12.2
2) Configure PE2
# Enable MPLS and LDP.
[PE2] mpls
[PE2- mpls] mpls ldp
# Configure vpn-instance VPN1.

[PE2] ip vpn-instance VPN1
[PE2-vpn-VPN1] route-distinguisher 2:1
[PE2-vpn-VPN1] vpn-target 100:1 export-extcommunity
[PE2-vpn-VPN1] vpn-target 100:1 import-extcommunity
7-59
[PE2-Ethernet1/0/0] ip binding vpn-instance VPN1
[PE2- LoopBack0] ip binding vpn-instance VPN1
[PE2- LoopBack0] ip address 2.2.2.2 255.255.255.255
[PE2- LoopBack1] ip address 50.1.1.2 255.255.255.255
# Configure BGP.
[PE2] bgp 100
[PE2-bgp-100] undo synchronization
[PE2-bgp-100] group fc internal
[PE2-bgp-100] peer 50.1.1.1 group fc
[PE2-bgp-100] peer 50.1.1.1 connect-interface LoopBack10
[PE2-bgp-100] peer 50.1.1.3 group fc
[PE2-bgp-100] peer 50.1.1.3 connect-interface LoopBack10
# Configure vpn-instance VPN 1 to import OSPF route and direct-connect route.

[PE2-bgp] ipv4-family vpn-instance VPN1
[PE2-bgp-af-vpn-instance] import-route ospf-nssa 100
[PE2-bgp-af-vpn-instance] import-route ospf-ase 100
[PE2-bgp-af-vpn-instance] import-route ospf 100
# Configure MBGP to enable peer.

[PE2-bgp-af-vpn] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer fc enable
[PE2-bgp-af-vpn] peer fc advertise-community
# Configure OSPF to import BGP route and direct-connect route.
7-60
[PE2] ospf 100 router-id 2.2.2.2 vpn-instance VPN1

[PE2-ospf-100] import-route bgp
[PE2-ospf-100] import-route static
[PE2-ospf-100] area 0.0.0.1
[PE2-ospf-100-0.0.0.1] network 20.1.1.0 0.0.0.255
# Configure a sham link

[PE2-ospf-100-0.0.0.1] sham-link 2.2.2.2 1.1.1.1
# Configure static routes to PE1 and PE3.

3) Configure CE1.
[CE1-Ethernet0/0/0] ospf cost 1
# Configure OSPF.
[CE1] ospf 100 router-id 10.10.10.129
[CE1-ospf-100] import-route direct
[CE1-ospf-100] area 0.0.0.1
[CE1-ospf-100] network 10.1.1.0 0.0.0.255
[CE1-ospf-100] network 12.1.1.0 0.0.0.255
4) Configure E2
# Configure OSPF.
[CE2] ospf 100 router-id 20.20.20.20
[CE2-ospf-100] area 0.0.0.1
[CE2-ospf-100] network 12.1.1.0 0.0.0.255
[CE2-ospf-100] network 20.1.1.0 0.0.0.255
7-61
7.4.8 OSPF Multi-Instance CE Networking
Configure multiple vpn-instances to isolate the services between multiple CEs in a

VPN.
II. Network diagram
vpn1
ospf 100
E0/0/0 E1/0/0
vpn2
MPLS
Network
ospf 300 E2/0/0 E3/0/0
PE vpn2 Multi-VPN- vpn2
Instance CE
Figure 7-18 Network diagram of OSPF multi-instance CE configuration
# Configure CE
# Configure instance CE-VPN1
[CE] ip vpn-instance CE-VPN1
[CE-vpn-CE-VPN1] route-distinguisher 100:1
[CE-vpn-CE-VPN1] vpn-target 100:1 export-extcommunity
[CE-vpn-CE-VPN1] vpn-target 100:1 import-extcommunity
# Configure instance CE-VPN2

[CE] ip vpn-instance CE-VPN2
[CE-vpn-CE-VPN2] route-distinguisher 200:1
[CE-vpn-CE-VPN2] vpn-target 200:1 export-extcommunity
[CE-vpn-CE-VPN2] vpn-target 200:1 import-extcommunity
# Configure ethernet0/0/0
[CE] interface Ethernet0/0/0
[CE-Ethernet 0/0/0] ip binding vpn-instance CE-VPN1
[CE-Ethernet 0/0/0] ip address 10.1.1.2 255.255.255.0
[CE-Ethernet1/0/0] ip binding vpn-instance CE-VPN1
[CE-Ethernet1/0/0] ip address 10.2.1.2 255.255.255.0
[CE-Ethernet1/0/0] ospf cost 100
7-62

# Configure ospf 100

[CE] ospf 100 vpn-instance CE-VPN1
[CE-ospf-100] vpn-instance-capability simple
[CE-ospf-100] area 0.0.0.0
[CE-ospf-100-area-0.0.0.0] network 10.1.1.0 0.0.0.255
# Configure ospf 200

[CE] ospf 200 vpn-instance CE-VPN2
[CE-ospf-200] vpn-instance-capability simple
[CE-ospf-200] area 0.0.0.1
7.4.9 Configuring Inter-Provider Backbones Option A
CE1 and CE2 belong to the same VPN. CE1 accesses the network through PE1 in AS
100 and CE2 accesses the network through PE2 in AS 200.
Multi-AS BGP/MPLS VPN is implemented using Option A method. (That is,
VPN-INSTANCE-to-VPN-INSTANCE method is used to manage VPN routes).
The MPLS backbone network in the same AS adopts OSPF as the IGP.
7-63
II. Network diagram
BGP/MPLS Backbone BGP/MPLS Backbone

AS 100 AS 200
Loopback0: Loopback0:
202.100.1.1/32 202.200.1.1/32
E2/0/0: E2/0/0: E1/0/0:
E1/0/0: 192.1.1.1/24192.1.1.2/24
Loopback0: 172.1.1.1/16 162.1.1.1/16 Loopback0:
202.100.1.2/32 200.200.1.2/32
ASBR -PE1 ASBR-PE2
LSR ID:172.1.1.1 LSR ID:162.1.1.1
E1/0/0: E1/0/0:
172.1.1.2/16 162.1.1.2/16
PE1 PE2
LSR ID: Ethernet2/0/0: LSR ID:
Ethernet2/0/0:
172.1.1.2 168.2.2.1/16 162.1.1.2
168.1.1.1/16
Ethernet1: Ethernet1:
168.1.1.2/16 168.2.2.2/16
CE1 CE2
AS 65001 AS 65002
Figure 7-19 Network diagram for Inter-Provider Backbones
The configuration procedures include:

z Configuring OSPF on the MPLS backbone network
z Configuring basic MPLS capability on the MPLS backbone network
z Configuring VPN instances on PEs
z Configuring MP-BGP
They are introduced below in order.
1) Configuring OSPF on the MPLS backbone network to make PEs learn routes from
each other
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure ASBR-PE1.
7-64
[ASBR-PE1] interface loopback0

[ASBR-PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[ASBR-PE1-LoopBack 0] quit
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] ip address 172.1.1.1 255.255.0.0
[ASBR-PE1-Ethernet1/0/0] quit
[ASBR-PE1] ospf
[ASBR-PE1-ospf-1] area 0
[ASBR-PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[ASBR-PE1-ospf-1-area-0.0.0.0] quit
[ASBR-PE1-ospf-1] quit
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
[ASBR-PE2-LoopBack0] ip address 202.200.1.1 255.255.255.255
[ASBR-PE2-LoopBack0] quit
[ASBR-PE2] ospf
After the configuration, the OSPF neighbor relationship should be established between
ASBR PE and the PEs of the same AS. Executing the display ospf peer command,
7-65
you can find that the OSPF neighbor relationship is in Full state. PEs can learn
Loopback addresses from each other.
The ping operation succeeds between ASBR-PE and other PEs in the same AS.
Take PE1 and ASBR-PE1 as an example:
[PE1] display ospf peer
OSPF Process 1 with Router ID 202.100.1.2
Neighbors
Area 0 interface 172.1.1.2(Ethernet1/0/0)'s neighbor(s)
RouterID: 202.100.1.1 Address: 172.1.1.1
State: Full Mode: Nbr is Slave Priority: 1
DR: None BDR: None
Dead timer expires in 40s
Neighbor comes up for 00:01:32
[PE1] display ip routing-table

172.1.0.0/16 DIRECT 0 0 172.1.1.2 Ethernet1/0/0
172.1.1.1/32 DIRECT 0 0 172.1.1.1 Ethernet1/0/0
202.100.1.1/32 OSPF 10 1563 172.1.1.1 Ethernet1/0/0
[PE1] ping 202.100.1.1

PING 202.100.1.1: 56 data bytes, press CTRL_C to break
Reply from 202.100.1.1: bytes=56 Sequence=1 ttl=255 time=10 ms
--- 202.100.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
[ASBR-PE1] display ospf peer

OSPF Process 1 with Router ID 202.100.1.1
Neighbors
Area 0 interface 172.1.1.1(Ethernet1/0/0)'s neighbor(s)
7-66
RouterID: 202.100.1.2 Address: 172.1.1.2

State: Full Mode: Nbr is Master Priority: 1
DR: None BDR: None
Dead timer expires in 30s
Neighbor comes up for 00:01:49
[ASBR-PE1] display ip routing-table

172.1.0.0/16 DIRECT 0 0 172.1.1.1 Ethernet1/0/0
172.1.1.2/32 DIRECT 0 0 172.1.1.2 Ethernet1/0/0
202.100.1.2/32 OSPF 10 1563 172.1.1.2 Ethernet1/0/0
[ASBR-PE1] ping 202.100.1.2

0.00% packet loss
2) Configuring basic MPLS capability on the MPLS backbone network to make the
network forward VPN traffic
# Configure basic MPLS capability on PE1 and enable LDP on the interface connecting
ASBR-PE1.
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
7-67
# Configure basic MPLS capability on ASBR-PE1 and enable LDP on the interface
connecting PE1.
[ASBR-PE1] mpls lsr-id 172.1.1.1
[ASBR-PE1] mpls
[ASBR-PE1-mpls] lsp-trigger all
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1-Ethernet1/0/0] mpls
[ASBR-PE1-Ethernet1/0/0] mpls ldp enable
connecting PE2.
[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
ASBR-PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
After you complete the configurations, the PEs and the ASBR-PEs in the same AS
should be able to set up LDP neighborhood. Executing the display mpls ldp session
command on the firewalls, you can find the Session State is “Operational” in the output.
You do not need to enable MPLS on the interface connecting ASBR-PE1 and
ASBR-PE2.
Take the display results on PE1 and ASBR-PE1 for example:
[PE1] display mpls ldp session
7-68
Displaying information about all sessions:

Local LDP ID: 172.1.1.2:0; Peer LDP ID: 172.1.1.1:0
TCP Connection: 172.1.1.2 -> 172.1.1.1
Session State: Operational
Session Role: Active
Session existed time: 3 minutes 32 seconds
KeepAlive Packets Sent/Received: 11/11
Negotiated Keepalive hold time: 60 Peer PV Limit: 0
LDP Basic Discovery Source((A) means active):
Ethernet1/0/0(A)
[ASBR-PE1] display mpls ldp session

Displaying information about all sessions:
Local LDP ID: 172.1.1.1:0; Peer LDP ID: 172.1.1.2:0
TCP Connection: 172.1.1.1 <- 172.1.1.2
Session State: Operational
Session Role: Passive
Session existed time: 4 minutes 37 seconds
KeepAlive Packets Sent/Received: 14/14
Negotiated Keepalive hold time: 60 Peer PV Limit: 0
LDP Basic Discovery Source((A) means active):
Ethernet1/0/0(A)
3) Configuring VPN instances on PEs and binding to the interfaces connecting to
CEs
Note:
The VPN-Target attributes of VPN instances of ASBR-PE and PE in the same AS
should match each other. In different ASs, the matching of VPN-Target attributes of
PEs is unnecessary.
# Configure CE1.
# Configure a VPN instance on PE1 and bind it to the interface connecting to CE1.
[PE1-vpn-vpn-vpna] route-distinguisher 100:2
[PE1-vpn-vpn-vpna] vpn-target 100:1 both
[PE1-vpn-vpn-vpna] quit
7-69

# Configure a VPN instance on ASBR-PE1 and bind it to the interface connecting to

ASBR-PE2 (ASBR-PE1 regards ASBR-PE2 as its CE).
[ASBR-PE1] ip vpn-instance vpna
[ASBR-PE1-vpn-vpn-vpna] route-distinguisher 100:1
[ASBR-PE1-vpn-vpn-vpna] vpn-target 100:1 both
[ASBR-PE1-vpn-vpn-vpna] quit
[ASBR-PE1] interface Ethernet 2/0/0
[ASBR-PE1-Ethernet2/0/0] ip binding vpn-instance vpna
# Configure CE2.
[PE2-vpn-instance] route-distinguisher 200:2
[PE2-vpn-instance] vpn-target 100:1 both
[PE2-vpn-instance] quit
# Configure a VPN instance on ASBR-PE2 and bind it to the interface connecting to

ASBR-PE1 (ASBR-PE2 regards ASBR-PE1 as its CE).
[ASBR-PE2] ip vpn-instance vpna
[ASBR-PE2-vpn-vpn-vpna] route-distinguisher 200:1
[ASBR-PE2-vpn-vpn-vpna] vpn-target 100:1 both
[ASBR-PE2-vpn-vpn-vpna] quit
[ASBR-PE2-Ethernet2/0/0] ip binding vpn-instance vpna
After the configuration, you can see the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs.
Take the display results on PE1 and ASBR-PE1 as an example:
7-70
[PE1] display ip vpn-instance verbose

VPN-Instance : vpna
No description
Route-Distinguisher :
100:2
Interfaces :
Ethernet2/0/0
Export-ext-communities :
100:1
Import-ext-communities :
100:1
[ASBR-PE1] display ip vpn-instance verbose

VPN-Instance : vpna
No description
Route-Distinguisher :
100:1
Interfaces :
Ethernet2/0/0
Export-ext-communities :
100:1
Import-ext-communities :
100:1
The ping operations are successful to CEs on PEs, and successful between
ASBR-PEs.
When pinging CE on PE, you need to specify the VPN to which the destination address
belongs.
For example, ping ASBR-PE2 on ASBR-PE1:
[ASBR-PE1] ping -vpn-instance vpna 192.1.1.2
0.00% packet loss
Ping PE1 on CE1:
7-71
[CE1] ping 168.1.1.1

0.00% packet loss
Ping CE1 on PE1:

[PE1] ping -vpn-instance vpna 168.1.1.2
0.00% packet loss
4) Configuring MP-BGP, establishing IBGP peer relationship between PEs, and
establishing EBGP peer relationship between PE and CE
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] quit
# Configure PE1 to establish EBGP peer relationship with CE1 and IBGP peer
relationship with ASBR-PE1.
[PE1] bgp 100
[PE1-bgp] group 20
7-72

[PE1-bgp] quit
# Configure ASBR-PE1 to establish EBGP peer relationship with ASBR-PE2 and IBGP
peer relationship with PE1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] ipv4-family vpn-instance vpna
[ASBR-PE1-bgp-af-vpn-instance] group 10 external
[ASBR-PE1-bgp-af-vpn-instance] peer 192.1.1.2 group 10 as-number 200
[ASBR-PE1-bgp-af-vpn-instance] quit
[ASBR-PE1-bgp] group 20
[ASBR-PE1-bgp] peer 202.100.1.2 group 20
[ASBR-PE1-bgp] peer 202.100.1.2 connect-interface loopback0
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpn] peer 20 enable
[ASBR-PE1-bgp-af-vpn] peer 202.100.1.2 group 20
[ASBR-PE1-bgp-af-vpn] quit
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] quit
[PE2] bgp 200
[PE2-bgp] group 20
7-73
[PE2-bgp] quit
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] ipv4-family vpn-instance vpna
[ASBR-PE2-bgp-af-vpn-instance] group 10 external
[ASBR-PE2-bgp-af-vpn-instance] peer 192.1.1.1 group 10 as-number 100
[ASBR-PE2-bgp-af-vpn-instance] quit
[ASBR-PE2-bgp] quit
After the configuration, you can find that the BGP peer relationship has been
established in Established state between PEs and between PE and CE.
Take the display results on PE1 and ASBR-PE1 as an example:
[PE1] display bgp vpnv4 all peer
Peer AS-num Ver Queued-Tx Msg-Rx Msg-Tx Up/Down State
--------------------------------------------------------------------
168.1.1.2 65001 4 0 4 7 00:03:23 Established
202.100.1.1 100 4 0 1 1 00:03:14 Established
[ASBR-PE1] display bgp vpnv4 all peer

Peer AS-num Ver Queued-Tx Msg-Rx Msg-Tx Up/Down State
--------------------------------------------------------------------
192.1.1.2 200 4 0 5 6 00:03:38 Established
202.100.1.2 100 4 0 1 1 00:04:17 Established
CEs can learn interface routes from each other. CE1 and CE2 can be pinged
successfully on each other.
[CE1] display ip routing-table
168.1.0.0/16 DIRECT 0 0 168.1.1.2 Ethernet1
7-74
168.2.0.0/16 BGP 256 0 168.1.1.1 Ethernet2/0/0
[PE1] display ip routing-table vpn-instance vpna

vpna Route Information
Routing Table: vpna Route-Distinguisher: 100:2
168.1.0.0/16 DIRECT 0 0 168.1.1.1 Ethernet2/0/0
VPN Routing Table: Route-Distinguisher: 100:1
168.2.0.0/16 BGP 256 0 202.100.1.1 InLoopBack0
[ASBR-PE1] display ip routing-table vpn-instance vpna

vpna Route Information
Routing Table: vpna Route-Distinguisher: 100:1
168.2.0.0/16 BGP 256 0 192.1.1.2 Ethernet2/0/0
192.1.1.0/24 DIRECT 0 0 192.1.1.1 Ethernet2/0/0
192.1.1.2/32 DIRECT 0 0 192.1.1.2 Ethernet2/0/0
VPN Routing Table: Route-Distinguisher: 100:2
168.1.0.0/16 BGP 256 0 202.100.1.2 InLoopBack0
[CE1] ping 168.2.2.2

0.00% packet loss
[CE2] ping 168.1.1.2

7-75
0.00% packet loss
7.4.10 Configuring Inter-Provider Backbones Option B
Multi-AS BGP/MPLS VPN is implemented through Option B method. That is, VPN-IPv4
routes are advertised between ASBRs.
The MPLS backbone network in the same AS adopts OSPF as the IGP.
II. Network diagram
See Figure 7-19.
The configuration procedures include:

Compared with Option A, Option B differs in the last two procedures.
each other
Note:
In this part:
z The configurations on PE1 and PE2 are the same as those in section 7.4.9
“Configuring Inter-Provider Backbones Option A”.
z Configuration of interface IP address between ASBR-PE1 and ASBR-PE2 is added.
# Configure PE1.
7-76
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
[ASBR-PE1] ospf
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
7-77

[ASBR-PE2] ospf
ASBR PE and PEs in the same AS. Executing the display ospf peer command, you
can find that the neighbor relationship is in Full state. PEs can learn Loopback
addresses from each other.
ASBR-PE and other PEs in the same AS can be pinged successfully on each other.
ASBR-PEs can be pinged successfully on each other.
Note:
In this part:
The configurations on PE1, PE2, ASBR-PE1, and ASBR-PE2 are the same as those in
section 7.4.9 “Configuring Inter-Provider Backbones Option A”.
ASBR-PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
connecting PE1.
7-78
[ASBR-PE1] mpls
[ASBR-PE1] mpls ldp
connecting PE2.
[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
ASBR-PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
After the configuration, the LDP neighbor relationship should be established between
PE and ASBR-PE in the same AS. Executing the display mpls ldp session command
on the firewalls, you can find the Session State item is “Operational” in the display
result.
CEs
7-79
Note:
Different from Option A, Option B method requires that the VPN-Target attribute of VPN
instances of ASBR-PE and PE in the same AS should match each other. In addition, in
different ASs, the matching of VPN-Target attributes of PEs is necessary.
In this part:
z The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.9 “Configuring Inter-Provider Backbones Option A”.
z It is unnecessary to configure VPN instances and interface binding on ASBR-PEs.
# Configure CE1.
# Configure CE2.
After the configuration, you can view the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs. CEs can be pinged successfully
on PEs.
7-80
belongs.
For example, ping CE1 on PE1:
Note:
In this part:
z The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.9 “Configuring Inter-Provider Backbones Option A”.
z Special configurations are necessary on ASBR-PE1 and ASBR-PE2: configuring
the undo policy vpn-target command in VPNv4 address family view and
configuring the next-hop-local command on IBGP peers in the AS.
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] quit
[PE1] bgp 100
[PE1-bgp] group 20
[PE1-bgp] quit
7-81
[ASBR-PE1] bgp 100

[ASBR-PE1-bgp] group 10 external
[ASBR-PE1-bgp] peer 192.1.1.2 group 10 as-number 200
[ASBR-PE1-bgp-af-vpn] peer 20 next-hop-local
[ASBR-PE1-bgp-af-vpn] undo policy vpn-target
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] quit
[PE2] bgp 200
[PE2-bgp] group 20
[PE2-bgp] quit
[ASBR-PE2] bgp 200
7-82
[ASBR-PE2-bgp-af-vpn] peer 20 next-hop-local
[ASBR-PE2-bgp-af-vpn] undo policy vpn-target
[ASBR-PE2-bgp] quit
After completing the configuration, you can find that the BGP peer relationship has
been established in Established state between PEs and between PE and CE by
executing the display bgp vpnv4 all peer command on the firewalls.
When a PE works as an ASBR at the same time, it needs to retain all VPNv4 routing
information and advertise it to other ASBRs. To this end, you must configure the undo
policy vpn-target command on it to have it receive all VPNv4 routing information
without filtering it based on VPN-target.
7.4.11 Configuring Inter-Provider Backbones Option C
Multi-AS BGP/MPLS VPN is implemented through Option C method. That is, labeled
VPN-IPv4 routes are advertised between PEs through Multihop MP-EBGP to manage
VPN routes.
II. Network diagram
See Figure 7-19.
According to the functions, the configuration procedures fall into four parts:
Compared with Option A, Option C differs in the last two procedures.
7-83
each other
Note:
In this part:
The configurations on PE1 and PE2 are the same as those in section 7.4.10
“Configuring Inter-Provider Backbones Option B”.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
[ASBR-PE1] ospf
# Configure PE2.
7-84

[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
[ASBR-PE2] ospf
ASBR-PE and other PEs in the same AS. Executing the display ospf peer command,
you can find that the neighbor relationship is in Full state. PEs can learn Loopback
addresses from each other.
ASBR-PE and other PEs in the same AS can be pinged successfully on each other.
ASBR-PEs can be pinged successfully on each other.
7-85
Note:
In this part:
The configurations on PE1 and PE2 are the same as those in section 7.4.10
It is necessary to configure MPLS capability for interfaces between ASBR-PEs.
ASBR-PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
# Configure basic MPLS capability on ASBR-PE1, enable LDP on the interface

connecting PE1, and enable MPLS on the interface connecting ASBR-PE2.
[ASBR-PE1] mpls
[ASBR-PE1] mpls ldp
# Configure basic MPLS capability on ASBR-PE2, enable LDP on the interface

connecting PE2, and enable MPLS on the interface connecting ASBR-PE1.
[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
7-86
ASBR-PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
After the configuration, the LDP neighbor relationship should be established between
PE and ASBR-PE in the same AS. Executing the display mpls ldp session command
on the firewalls, you can find the Session State is “Operational" in the display result.
CEs
Note:
In this part:
The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.10 “Configuring Inter-Provider Backbones Option B”.
# Configure CE1.
7-87

# Configure CE2.
After the configuration, you can see the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs. CEs can be pinged successfully
on PEs.
belongs.
For example, ping CE1 on PE1:
Note:
In this part:
z The configurations on CE1 and CE2 are the same as those in section 7.4.10
z The exchange of labeled IPv4 routes is configured between PE1 and ASBR-PE1,
PE2 and ASBR-PE2, ASBR-PE1 and ASBR-PE2.
z ASBR-PE varies the next hop to itself when advertising routes to PEs in the same AS.
z Route-policy is configured on ASBR-PE. For the routes received from PEs in the
same AS, ASBR-PE assigns MPLS labels for them when they are advertised to the
ASBR of the remote AS. For the routes advertised to PEs in the same AS, ASBR-PE
assigns new MPLS labels for them if they are labeled IPv4 routes.
7-88
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] quit
# Configure PE1 to establish EBGP peer relationship with CE1, IBGP peer relationship
with ASBR-PE1, and Multihop MP-EBGP peer relationship with PE2.
[PE1] bgp 100
[PE1-bgp] group 20
[PE1-bgp] peer 20 label-route-capability
[PE1-bgp] group 30 external
[PE1-bgp] peer 30 ebgp-max-hop
[PE1-bgp] peer 200.200.1.2 group 30 as-number 200
[PE1-bgp] quit
# Configure route-policy on ASBR-PE1.

[ASBR-PE1] acl number 2001
[ASBR-PE1-acl-basic-2001] rule permit source 202.100.1.2 0
[ASBR-PE1-acl-basic-2001] rule deny source any
[ASBR-PE1-acl-basic-2001] quit
[ASBR-PE1] route-policy rtp-ebgp permit node 1
[ASBR-PE1-route-policy] if-match acl 2001
[ASBR-PE1-route-policy] apply mpls-label
[ASBR-PE1-route-policy] quit
[ASBR-PE1] route-policy rtp-ibgp permit node 10
[ASBR-PE1-route-policy] if-match mpls-label
7-89
[ASBR-PE1] bgp 100

[ASBR-PE1-bgp] import-route ospf
[ASBR-PE1-bgp] peer 10 label-route-capability
[ASBR-PE1-bgp] peer 10 route-policy rtp-ebgp export
[ASBR-PE1-bgp] peer 20 next-hop-local
[ASBR-PE1-bgp] peer 20 route-policy rtp-ibgp export
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] quit
# Configure PE2 to establish EBGP peer relationship with CE2, IBGP peer relationship
with ASBR-PE2, and Multihop MP-EBGP peer relationship with PE1.
[PE2] bgp 200
[PE2-bgp] group 20
[PE2-bgp] peer 20 label-route-capability
[PE2-bgp] group 30 external
[PE2-bgp] peer 30 ebgp-max-hop
[PE2-bgp] peer 202.100.1.2 group 30 as-number 100
[PE2-bgp] quit
# Configure route-policy on ASBR-PE2.

[ASBR-PE2] acl number 2001
7-90
[ASBR-PE2-acl-basic-2001] rule permit source 200.200.1.2 0

[ASBR-PE2-acl-basic-2001] rule deny source any
[ASBR-PE2-acl-basic-2001] quit
[ASBR-PE2] route-policy rtp-ebgp permit node 1
[ASBR-PE2-route-policy] if-match acl 2001
[ASBR-PE2] route-policy rtp-ibgp permit node 10
[ASBR-PE2-route-policy] if-match mpls-label
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] import-route ospf
[ASBR-PE2-bgp] peer 10 route-policy rtp-ebgp export
[ASBR-PE2-bgp] peer 20 next-hop-local
[ASBR-PE2-bgp] peer 20 route-policy rtp-ibgp export
After the establishment of all BGP peer relationships, you can find the IPv4 route of the
peer, that is, 200.200.1.2 and 202.100.1.2 respectively on PE1 and PE2. Executing the
display bgp routing label command, you can find that the two routes carry labels and
the IPv4 routes learned from each other by PE1 and PE2.
7-91
Security
Operation Manual – Security
Table of Contents
Chapter 1 Network Security Configuration................................................................................. 1-1

1.1 Introduction to Network Security Features Provided by Comware.................................... 1-1
1.2 Hierarchical Command Line Protection ............................................................................. 1-2
1.3 RADIUS-Based AAA.......................................................................................................... 1-2
1.4 Packet Filter and Firewall .................................................................................................. 1-2
1.4.1 Firewall Concept...................................................................................................... 1-2
1.4.2 Firewall Classification.............................................................................................. 1-3
1.4.3 Packet Filter ............................................................................................................ 1-4
1.5 Security Authentication before Route Information Exchange............................................ 1-5
Chapter 2 AAA and RADIUS/HWTACACS Protocol Configuration .......................................... 2-1

2.1 Overview ............................................................................................................................ 2-1
2.1.1 Introduction to AAA ................................................................................................. 2-1
2.1.2 Introduction to the RADIUS Protocol ...................................................................... 2-2
2.1.3 Introduction to the HWTACACS Protocol ............................................................... 2-7
2.2 Configuring AAA .............................................................................................................. 2-10
2.2.1 Creating an ISP Domain and Setting the Related Attributes ................................ 2-10
2.2.2 Creating a Local User and Setting the Related Attributes .................................... 2-16
2.3 Configuring the RADIUS Protocol.................................................................................... 2-18
2.3.1 Creating a RADIUS Scheme................................................................................. 2-19
2.3.2 Configuring RADIUS Authentication/Authorization Servers.................................. 2-19
2.3.3 Configuring RADIUS Accounting Servers and the Related Attributes .................. 2-20
2.3.4 Setting the Shared Key for RADIUS Packet Encryption ....................................... 2-23
2.3.5 Setting the Maximum Number of RADIUS Request Attempts .............................. 2-24
2.3.6 Setting the Supported RADIUS Server Type ........................................................ 2-24
2.3.7 Setting RADIUS Server State ............................................................................... 2-25
2.3.8 Setting Username Format Acceptable to RADIUS Server.................................... 2-25
2.3.9 Setting the Unit of Data Flows Destined for RADIUS Server................................ 2-26
2.3.10 Configuring Source Address for RADIUS Packets Sent by NAS........................ 2-26
2.3.11 Setting Timers Regarding RADIUS Server ......................................................... 2-27
2.3.12 Configure the RADIUS server to send a trap packet .......................................... 2-29
2.3.13 Configuring Local RADIUS Authentication Server .............................................. 2-29
2.4 HWTACACS Protocol Configuration................................................................................ 2-30
2.4.1 Creating a HWTACACS scheme .......................................................................... 2-31
2.4.2 Configuring TACACS Authentication Servers....................................................... 2-31
2.4.3 Configuring TACACS Authorization Servers......................................................... 2-32
2.4.4 Configuring TACACS Accounting Servers and the Related Attributes ................. 2-32
2.4.5 Configuring Source Address for HWTACACS Packets Sent by NAS................... 2-34
i
2.4.6 Setting a Key for Securing the Communication with TACACS Server ................. 2-34
2.4.7 Setting the Username Format Acceptable to the TACACS Server....................... 2-35
2.4.8 Setting the Unit of Data Flows Destined for the TACACS Server......................... 2-35
2.4.9 Setting Timers Regarding TACACS Server .......................................................... 2-35
2.5 TACACS Supporting Super Authentication ..................................................................... 2-37
2.5.1 Super Authentication Level Switching Process..................................................... 2-37
2.5.2 Configuring Super Authentication Mode ............................................................... 2-38
2.5.3 Configuring Super Authentication Scheme ........................................................... 2-39
2.6 Displaying and Debugging AAA and RADIUS/HWTACACS Protocols ........................... 2-39
2.7 AAA Protocol Configuration Example .............................................................................. 2-41
2.7.1 Telnet/SSH User Authentication/Accounting Using RADIUS Server.................... 2-41
2.7.2 Configuring FTP/Telnet User Local Authentication............................................... 2-43
2.7.3 PPP User Authentication/Accounting/Authorization with TACACS ...................... 2-43
2.7.4 Configuring HWTACACS Server Authentication/Accounting................................ 2-45
2.8 Troubleshooting AAA....................................................................................................... 2-47
2.8.1 Troubleshooting the RADIUS Protocol ................................................................. 2-47
2.8.2 Troubleshooting the HWTACACS Protocol .......................................................... 2-48
Chapter 3 ACL Configuration....................................................................................................... 3-1

3.1 Introduction to ACL ............................................................................................................ 3-1
3.1.1 ACL Overview ......................................................................................................... 3-1
3.1.2 Classification of ACL ............................................................................................... 3-1
3.1.3 Match order of ACL ................................................................................................. 3-1
3.1.4 ACL Creation........................................................................................................... 3-2
3.1.5 Basic ACL................................................................................................................ 3-3
3.1.6 Advanced ACL ........................................................................................................ 3-4
3.1.7 Interface-based ACL ............................................................................................. 3-11
3.1.8 MAC-Based ACL ................................................................................................... 3-12
3.1.9 ACL Supporting Fragment .................................................................................... 3-13
3.2 Configuring an ACL ......................................................................................................... 3-14
3.2.1 Configuring a Basic ACL ....................................................................................... 3-14
3.2.2 Configuring an Advanced ACL.............................................................................. 3-14
3.2.3 Configuring an Interface-based ACL..................................................................... 3-15
3.2.4 Configuring a MAC-Based ACL ............................................................................ 3-15
3.2.5 Adding Description to an ACL ............................................................................... 3-16
3.2.6 Adding Comment to an ACL Rule ......................................................................... 3-16
3.2.7 Deleting an ACL .................................................................................................... 3-16
3.2.8 Enabling/Disabling the ACL Counters................................................................... 3-17
3.3 Configuring Time Range.................................................................................................. 3-17
3.3.1 Creating/Deleting a Time Range........................................................................... 3-17
3.4 Displaying and Debugging ACL....................................................................................... 3-18
3.5 Typical Configuration Examples of ACL .......................................................................... 3-18
ii
Chapter 4 NAT Configuration....................................................................................................... 4-1

4.1 NAT Overview.................................................................................................................... 4-1
4.2 Functions Provided by NAT ............................................................................................... 4-2
4.2.1 Many-to-Many Address Translation and Address Translation Control ................... 4-2
4.2.2 NAPT....................................................................................................................... 4-3
4.2.3 Static Network Segment Address Translation ........................................................ 4-4
4.2.4 Bidirectional Network Address Translation ............................................................. 4-5
4.2.5 Internal Server......................................................................................................... 4-6
4.2.6 Easy IP .................................................................................................................... 4-6
4.2.7 NAT Application Level Gateway.............................................................................. 4-6
4.2.8 NAT Maximum TCP Connections Limit Function.................................................... 4-7
4.2.9 Multi-Instance of NAT Supported ............................................................................ 4-7
4.3 NAT Configuration ............................................................................................................. 4-8
4.3.1 Configuring Address Pool ....................................................................................... 4-8
4.3.2 Configuring NAT...................................................................................................... 4-9
4.3.3 Configuring Internal Server ................................................................................... 4-12
4.3.4 Enabling NAT ALG................................................................................................ 4-14
4.3.5 Configuring Domain Name Mapping ..................................................................... 4-14
4.3.6 Configuring Address Translation Lifetimes ........................................................... 4-14
4.3.7 Configuring NAT Maximum TCP Connections Limit Function .............................. 4-15
4.3.8 Setting the Packet Matching Mode ....................................................................... 4-17
4.3.9 Setting NAT Entry Refresh Speed ........................................................................ 4-18
4.4 Displaying and Debugging NAT....................................................................................... 4-18
4.5 NAT Configuration Examples .......................................................................................... 4-19
4.5.1 Typical NAT Configuration .................................................................................... 4-19
4.5.2 Using Loopback Interface for NAT Configuration ................................................. 4-21
4.5.3 Static NAT Configuration....................................................................................... 4-22
4.5.4 Bidirectional NAT Configuration ............................................................................ 4-24
4.5.5 Domain Name Mapping Configuration .................................................................. 4-25
4.5.6 Limiting Connections from a Source Address....................................................... 4-26
4.6 Troubleshooting NAT Configuration ................................................................................ 4-27
Chapter 5 Firewall Configuration................................................................................................. 5-1

5.1 Introduction to Firewall....................................................................................................... 5-1
5.1.1 ACL/Packet Filter .................................................................................................... 5-1
5.1.2 Application Specific Packet Filter ............................................................................ 5-2
5.2 Configuring Packet Filter Firewall ...................................................................................... 5-6
5.2.1 Enabling or Disabling Packet Filter ......................................................................... 5-6
5.2.2 Setting the Default Filtering Mode of Firewall ......................................................... 5-6
5.2.3 Enabling/Disabling Fragment Inspection of Packet Filter ....................................... 5-7
5.2.4 Configuring Upper/Lower Threshold of Fragment Inspection ................................. 5-7
5.2.5 Applying ACL on the Interface ................................................................................ 5-7
5.2.6 Displaying and Debugging Packet Filter ................................................................. 5-8
iii
5.2.7 Typical Configuration Examples of Packet Filter .................................................... 5-9

5.2.8 Fragment Packet Configuration Examples of Packet Filter .................................. 5-11
5.3 Configuring ASPF ............................................................................................................ 5-13
5.3.1 Enabling Firewall ................................................................................................... 5-13
5.3.2 Configuring ACL .................................................................................................... 5-13
5.3.3 Defining an ASPF Policy ....................................................................................... 5-13
5.3.4 Applying ASPF Policy on Specified Interface ....................................................... 5-16
5.3.5 Setting the Session Timeout Values ..................................................................... 5-16
5.3.6 Configuring ASPF Session Logging Function....................................................... 5-17
5.3.7 Configuring a Port Mapping Entry ......................................................................... 5-17
5.3.8 Displaying and Debugging ASPF.......................................................................... 5-18
5.3.9 Cautions for Implementing ASPF.......................................................................... 5-19
5.3.10 ASPF Configuration Example ............................................................................. 5-19
5.4 Black List.......................................................................................................................... 5-20
5.4.1 Introduction to Black List ....................................................................................... 5-20
5.4.2 Black List Configuration ........................................................................................ 5-21
5.4.3 Displaying and Debugging Black List.................................................................... 5-22
5.4.4 Typical Example of Black List Configuration......................................................... 5-22
5.5 MAC and IP Address Binding .......................................................................................... 5-23
5.5.1 Introduction to MAC and IP Address Binding........................................................ 5-23
5.5.2 MAC and IP Address Binding Configuration ......................................................... 5-24
5.5.3 Displaying and Debugging MAC and IP Address Binding .................................... 5-25
5.5.4 Typical Example of MAC and IP Address Binding Configuration ......................... 5-26
5.6 Security Zone Configuration ............................................................................................ 5-27
5.6.1 Security Zone Overview ........................................................................................ 5-27
5.6.2 Security Zone Configuration.................................................................................. 5-27
5.6.3 Security Zone Display ........................................................................................... 5-29
Chapter 6 Object-Oriented Management..................................................................................... 6-1

6.1 Object-Oriented Management Overview ........................................................................... 6-1
6.2 Creating Objects ................................................................................................................ 6-1
6.2.1 Creating an Address Object .................................................................................... 6-1
6.2.2 Refreshing DNS Objects ......................................................................................... 6-2
6.2.3 Creating an Address Group Object ......................................................................... 6-2
6.2.4 Creating a Service Object ....................................................................................... 6-3
6.2.5 Creating a Service Group Object ............................................................................ 6-3
6.2.6 Creating a Flow Object............................................................................................ 6-4
6.2.7 Creating a Time Range Object................................................................................ 6-5
6.3 Referencing Flow Objects.................................................................................................. 6-5
6.3.1 Referencing a Flow Object for Packet Filtering....................................................... 6-5
6.3.2 Referencing a Flow Object in NAT.......................................................................... 6-6
6.4 Displaying and Debugging Object-Oriented Management ................................................ 6-6
iv
Chapter 7 Transparent Firewall.................................................................................................... 7-1

7.1 Transparent Firewall Overview .......................................................................................... 7-1
7.1.1 Obtaining MAC Address Table................................................................................ 7-1
7.1.2 Forwarding and Filtering ......................................................................................... 7-3
7.2 Transparent Firewall Configuration.................................................................................... 7-5
7.2.1 Configuring Firewall Mode ...................................................................................... 7-5
7.2.2 Configuring System IP Address .............................................................................. 7-6
7.2.3 Enabling/Disabling Dynamic ARP Learning............................................................ 7-7
7.2.4 Configuring Handling Approach for the Packets with Unknown MAC Address ...... 7-7
7.2.5 Configuring MAC Address-based ACLs.................................................................. 7-8
7.2.6 Applying MAC Address-based ACL to the Interface ............................................... 7-8
7.2.7 Configuring Aging Time of the MAC Forwarding Table .......................................... 7-9
7.2.8 Defining Allowed Packet Types............................................................................... 7-9
7.2.9 Configuring VLAN ID Transparent Transmission Function................................... 7-10
7.3 Displaying and Debugging Transparent Firewall............................................................. 7-11
7.4 Typical Configuration Example ........................................................................................ 7-12
7.4.1 VLAN ID Transparent Transmission Configuration Example................................ 7-12
Chapter 8 Hybrid Mode Configuration ........................................................................................ 8-1

8.1 Introduction to Bridge......................................................................................................... 8-1
8.1.1 Obtaining MAC Address Table................................................................................ 8-1
8.1.2 Forwarding and Filtering ......................................................................................... 8-3
8.2 Configuring the Bridging Functions.................................................................................... 8-5
8.2.1 Basic Bridge Configuration...................................................................................... 8-6
8.2.2 Configuring the Bridging Address Table ................................................................. 8-7
8.2.3 Configuring Ethernet Frame Filtering ...................................................................... 8-8
8.2.4 Configuring the Routing Function of the Bridge .................................................... 8-10
8.2.5 Configuring a Bridge-Set to Bridge for the Network Layer Protocol ..................... 8-10
8.2.6 Defining Allowed Packet Types............................................................................. 8-11
8.2.7 Configuring Handling Approach for the Packets with Unknown MAC Address ............ 8-11
8.2.8 Configuring VLAN ID Transparent Transmission Function................................... 8-12
8.3 Displaying and Debugging Bridging Information ............................................................. 8-12
8.4 Bridging Configuration Examples .................................................................................... 8-13
8.4.1 Implementing Integrated Routing and Bridging..................................................... 8-13
8.4.2 Implementing Bridging on Ethernet Subinterfaces................................................ 8-14
8.4.3 VLAN ID Transparent Transmission ..................................................................... 8-16
Chapter 9 PKI Configuration ........................................................................................................ 9-1

9.1 PKI Overview ..................................................................................................................... 9-1
9.1.1 Introduction.............................................................................................................. 9-1
9.1.2 Terminology............................................................................................................. 9-2
9.1.3 Applications ............................................................................................................. 9-2
9.1.4 Configuration Task List ........................................................................................... 9-3
9.2 Certificate Request Configuration...................................................................................... 9-3
v
9.2.1 Certificate Request Overview.................................................................................. 9-3

9.2.2 Entering PKI Domain View...................................................................................... 9-3
9.2.3 Specifying a Trustworthy CA................................................................................... 9-4
9.2.4 Configuring Servers for Certificate Request ........................................................... 9-5
9.2.5 Configuring Entity Name Space .............................................................................. 9-7
9.2.6 Creating a Local Public – Private Key Pair ........................................................... 9-11
9.2.7 Configuring Polling Interval and Count ................................................................. 9-12
9.2.8 Configuring Certificate Request Mode .................................................................. 9-12
9.2.9 Delivering a Certificate Request Manually ............................................................ 9-13
9.2.10 Retrieving a Certificate Manually ........................................................................ 9-14
9.2.11 Importing Certificates .......................................................................................... 9-14
9.2.12 Deleting Certificates ............................................................................................ 9-14
9.3 Certificate Validation Configuration ................................................................................. 9-15
9.3.1 Configuration Task List ......................................................................................... 9-15
9.3.2 Specifying CRL Distribution Point location............................................................ 9-15
9.3.3 Configuring CRL Update Period............................................................................ 9-15
9.3.4 Enabling/Disabling CRL Check ............................................................................. 9-16
9.3.5 Retrieving a CRL ................................................................................................... 9-16
9.3.6 Verifying Certificate Validity .................................................................................. 9-17
9.4 Displaying and Debugging............................................................................................... 9-17
9.5 Typical Configuration Examples ...................................................................................... 9-18
9.5.1 IKE Authentication with PKI Certificate ................................................................. 9-18
9.6 Troubleshooting ............................................................................................................... 9-21
9.6.1 Fault 1: Failing to Retrieve a CA Certificate.......................................................... 9-21
9.6.2 Fault 2: Failing to Request a Local Certificate ...................................................... 9-21
9.6.3 Fault 3: Failing to Retrieve a CRL ......................................................................... 9-22
Chapter 10 SSL Configuration ................................................................................................... 10-1

10.1 SSL Overview ................................................................................................................ 10-1
10.2 Configuring SSL............................................................................................................. 10-3
10.2.1 Configuring Server SSL Policies ......................................................................... 10-4
10.2.2 Configuring SSL Encryption Card ....................................................................... 10-8
10.2.3 Configuring Access Control Policies Based on Certificate Attributes ................. 10-9
10.2.4 Configuring SSL Proxy Server Policies............................................................. 10-12
10.2.5 Configuration Example: Setting up SSL Proxy Server...................................... 10-16
Chapter 11 Web and E-mail Filtering......................................................................................... 11-1

11.1 Introduction to Web and E-mail Filtering ....................................................................... 11-1
11.2 Configuring Web Filtering .............................................................................................. 11-1
11.2.1 Configuring Web Address Filtering ..................................................................... 11-1
11.2.2 Configuring Web Content Filtering ...................................................................... 11-5
11.2.3 Configuring SQL Attack Prevention .................................................................... 11-7
11.3 Configuring E-mail Filtering ........................................................................................... 11-9
11.3.1 Configuring E-mail Address Filtering................................................................... 11-9
vi
11.3.2 Configuring E-mail Subject Filtering.................................................................. 11-11

11.3.3 Configuring E-mail Content Filtering ................................................................. 11-13
11.3.4 Configuring E-mail Attachment Filtering ........................................................... 11-14
11.3.5 Displaying and Debugging E-mail filtering ........................................................ 11-16
Chapter 12 Attack Prevention and Packet Statistics ............................................................... 12-1

12.1 Introduction to Attack Prevention and Packet Statistics ................................................ 12-1
12.1.1 Introduction to Attack Prevention ........................................................................ 12-1
12.1.2 Classes of Network Attacks ................................................................................ 12-1
12.1.3 Typical Examples of Network Attacks ................................................................. 12-2
12.1.4 Introduction to Statistics Analysis........................................................................ 12-3
12.2 Attack Prevention Configuration .................................................................................... 12-4
12.2.1 Enabling/Disabling ARP Flood Attack Prevention............................................... 12-5
12.2.2 Configuring ARP Spoofing Attack Prevention..................................................... 12-5
12.2.3 Enabling/Disabling the IP Spoofing Attack Prevention Function ........................ 12-5
12.2.4 Enabling/Disabling the Land Attack Prevention Function ................................... 12-6
12.2.5 Enabling/Disabling the Smurf Attack Prevention Function ................................. 12-6
12.2.6 Enabling/Disabling the WinNuke Attack Prevention Function ............................ 12-6
12.2.7 Enabling/Disabling the Fraggle Attack Prevention Function............................... 12-7
12.2.8 Enabling/Disabling Frag Flood Attack Prevention............................................... 12-7
12.2.9 Enabling/Disabling the SYN Flood Attack Prevention Function.......................... 12-7
12.2.10 Enabling/Disabling the ICMP Flood Attack Prevention Function .................... 12-10
12.2.11 Enabling/Disabling the UDP Flood Attack Prevention Function ..................... 12-11
12.2.12 Enabling/Disabling the ICMP Redirect Packet Control Function .................... 12-13
12.2.13 Enabling/Disabling the ICMP Unreachable Packet Control Function ............. 12-13
12.2.14 Enabling/Disabling the IP Sweep Attack Prevention Function........................ 12-14
12.2.15 Enabling/Disabling the Port Scan Attack Prevention Function ....................... 12-15
12.2.16 Enabling/Disabling the Control Function of the IP Packet Carrying Source
Route ........................................................................................................................... 12-15
12.2.17 Enabling/Disabling Attack Prevention for Route Record Options ................... 12-16
12.2.18 Enabling/Disabling the Tracert Packet Control Function ................................ 12-16
12.2.19 Enabling/Disabling the Ping of Death Attack Prevention Function ................. 12-16
12.2.20 Enabling/Disabling the Teardrop Attack Prevention Function ........................ 12-17
12.2.21 Enabling/Disabling the TCP Flag Validity Detection Function ........................ 12-17
12.2.22 Enabling/Disabling the IP Fragment Packet Detection Function .................... 12-18
12.2.23 Enabling/Disabling the Large ICMP Packet Control Function ........................ 12-18
12.3 Warning Level Configuration ....................................................................................... 12-18
12.4 System-Based Statistics Configuration ....................................................................... 12-19
12.4.1 Enabling/Disabling the System-Based Statistics Function ............................... 12-19
12.4.2 Configuring Monitor the Number of System-Based Connections ..................... 12-20
12.4.3 Configuring Alarm Detection for Abnormal System Packet Rate...................... 12-20
12.5 Zone-Based Statistics Configuration ........................................................................... 12-21
12.5.1 Enabling/Disabling the Zone-Based Statistics Function ................................... 12-21
vii
12.5.2 Configuring Monitor of the Connection Number in a Security Zone ................. 12-22
12.5.3 Configuring Monitor the Rate of Connections in a Zone................................... 12-22
12.6 IP-Based Statistics Configuration ................................................................................ 12-23
12.6.1 Enabling/Disabling the IP-Based Statistics Function ........................................ 12-23
12.6.2 Configuring Monitor of the IP-Based Connection Number................................ 12-24
12.6.3 Configuring Monitor of the IP-based Connection Rate ..................................... 12-25
12.7 Displaying and Debugging Attack Prevention and Packet Statistics........................... 12-26
12.7.1 Displaying and Debugging Attack Prevention................................................... 12-26
12.7.2 Displaying Packet Statistics .............................................................................. 12-28
12.8 Configuring SMTP Client ............................................................................................. 12-28
12.8.1 Configuring Mail Triggering Time ...................................................................... 12-29
12.8.2 Configuring Mail Addresses .............................................................................. 12-29
12.8.3 Displaying and Debugging SMTP Client........................................................... 12-29
12.9 Configuring DNS Client................................................................................................ 12-30
12.9.1 Configuring DNS Server.................................................................................... 12-30
12.9.2 Configuring DNS Cache.................................................................................... 12-30
12.9.3 Displaying and Debugging DNS Client ............................................................. 12-31
12.10 Typical Examples of Attack Prevention and Packet Statistics Configuration ............ 12-31
12.10.1 Enabling the Land Attack Prevention Function ............................................... 12-31
12.10.2 Enabling the SYN Flood Attack Prevention Function ..................................... 12-32
12.10.3 Enabling the Address Scanning Attack Prevention Function.......................... 12-33
12.10.4 Monitoring the Zone Connection Number ....................................................... 12-34
12.10.5 Displaying the Specified IP Statistics Information........................................... 12-36
12.11 Attack Prevention Troubleshooting............................................................................ 12-37
Chapter 13 IDS Cooperation....................................................................................................... 13-1

13.1 Introduction to IDS Cooperation .................................................................................... 13-1
13.2 Configuring IDS Cooperation......................................................................................... 13-2
13.2.1 Issuing IDS-Reconfigured ACL Rules to Interfaces ............................................ 13-2
13.2.2 Displaying and Debugging IDS Cooperation ...................................................... 13-2
13.2.3 IDS Configuration Example................................................................................. 13-3
Chapter 14 Log Maintenance ..................................................................................................... 14-1

14.1 Introduction to Log ......................................................................................................... 14-1
14.2 Syslog Log Configuration............................................................................................... 14-2
14.2.1 Configuring the Sweep Time for the Syslog Log Buffer ...................................... 14-2
14.2.2 Configuring the Log Redirection for the Information Center ............................... 14-3
14.3 Configuring Inter-Zone Flow Log ................................................................................... 14-4
14.3.1 Configuring Inter-Zone Flow Log......................................................................... 14-4
14.3.2 Configuring Flow Log Thresholds ....................................................................... 14-5
14.4 Configuring NAT Flow Log............................................................................................. 14-5
14.5 Clearing Log................................................................................................................... 14-6
14.6 Typical Examples of Log Configuration ......................................................................... 14-6
14.6.1 Outputting Attack Prevention Log to Host........................................................... 14-6
viii
14.6.2 Inter-Zone Flow Log Configuration Example ...................................................... 14-7

14.6.3 NAT Flow Log Configuration Example................................................................ 14-9
ix
H3C SecPath Series Security Products Chapter 1 Network Security Configuration
Chapter 1 Network Security Configuration
1.1 Introduction to Network Security Features Provided by

Comware
A firewall must be able to withstand various malicious attacks from the public network.
As sometimes, the accidental but destructive access of the user may also result in
significant performance decrease and even the operation failure.
Comware provides the following network security characteristics:
z AAA services based on Remote Authentication Dial-In User Service (RADIUS)
and HUAWEI Terminal Access Controller Access Control System (HWTACACS)
provide the security services of Authentication, Authorization, and Accounting on
accessing subscribers for preventing illegal accessing.
z Authentication protocol supports CHAP and PAP authentication on PPP line.
z Packet filter implemented through Access Control List (ACL) specifies the type of
packets that the firewall will permit or deny.
z Application Specific Packet Filter (ASPF), or status firewall, is an advanced
communication filtering approach that checks the application layer information and
monitors connection-oriented application layer protocol state, maintain the state
information of each connection, and dynamically makes decision in permitting or
deny a packet.
z IPsec (IP security): it guarantees the privacy, integrity and validity of the data
packets while transmitted on the Internet through encryption and data source
authentication on the IP layer.
z IKE (Internet Key Exchange) provides the services of auto-negotiated key
exchange and Security Association (SA) establishment to simplify the use and
management of IPsec.
z Event log is used to record system security events and trace illegal access in real
time.
z Address translation provided by NAT Gateway (GW), which separates the public
network from the intranet, makes the IP addresses of the internal devices
unknown to the public network and hence prevents the attacks initiated from it.
z Dynamic routing protocol authentication: ensuring reliable route information to be
exchanged.
z Hierarchical view protection divides users into four levels, each assigned with a
configuration right, and a user cannot access the view of a higher level.
In the following chapters tells you how to configure AAA and RADIUS, user password,
firewall and packet filter. Refer to the VPN module of this manual for IPsec/IKE
configuration; refer to the User Access module of this manual for PPP authentication
1-1
protocol configuration; refer to the Fundamental Configuration module for log

configuration; refer to Chapter 4 NAT Configuration for address translation
configuration; refer to Routing Protocol module of this manual for dynamic routing
protocol authentication configuration.
1.2 Hierarchical Command Line Protection

The system command lines are protected in a hierarchical way. In this approach, the
command lines are divided into viewing level, monitoring level, configuring level, and
management level. You will be unable to use the commensurate level of commands
unless you have provided the correct login password.
1.3 RADIUS-Based AAA

AAA is used for user access management. It can be implemented via multiple protocols
but the AAA discussed here is RADIUS-based.
AAA provides the functions of:
z Hierarchical user management. The users are allowed to perform the operations
like managing and maintaining the system configuration data, and monitoring and
maintaining the equipment that are crucial to the normal operation of the system.
Therefore, it is necessary to strictly manage the users by classifying them into
different levels and granting each with a specific right. In this case, a low-level user
is allowed to perform but only some viewing operations and only a high-level user
can modify data, maintain the equipment, and perform some other sensitive
operations.
z PPP authentication. With it, user name and password authentication will be
performed before the setup of a PPP connection is allowed.
z PPP address management and allocation. When setting up a PPP connection, the
system may assign the IP address that has been specified to the PPP user.
The next chapter will cover the details of RADIUS protocol and its configurations, user
password configuration, and PPP user address configuration. For PPP authentication
protocols, refer to the User Access module of this manual.
1.4 Packet Filter and Firewall

1.4.1 Firewall Concept
Firewall can prevent unauthorized or unauthenticated users on the Internet from

accessing a protected network while allowing the users on the internal network to
access web sites on the Internet and transmit/receive E-mails. It can also work as an
Internet access right control GW by permitting only some particular users inside the
organization to access the Internet.
1-2
Internet
Firewall
Ethernet
PC PC Server PC
Figure 1-1 A firewall separating the intranet from the Internet
The firewall is not only applied to the Internet connection, but also used to protect the
mainframe and crucial resources like data on the intranet of the organization. Access to
the protected data should be permitted by the firewall, even if the access is initiated
from the organization.
An external network user must pass through the firewall before it can access the
protected network resources. Likewise, an intranet user must pass through the firewall
before it can access the external network resources. Thus, the firewall plays the role of
“guard” and discards the denied packets.
1.4.2 Firewall Classification
Normally, firewalls are classified into two categories: network layer firewalls and
application layer firewalls. Network layer firewalls mainly obtain the header information
of packet, such as protocol, source address, destination address, and destination port.
Alternatively, they can directly obtain a segment of header data. The application layer
firewalls, however, analyze the whole information traffic.
Firewalls that you often meet are divided into the following categories:
z Application gateway: It verifies all the application layer data in packets that will
traverse it. Take a File Transfer Protocol (FTP) application GW as an example.
From the perspective of the client of a connection, the FTP application GW is an
FTP server. However, from the perspective of the server, it is an FTP client. All the
FTP packets transmitted on the connection must pass this FTP application GW.
z Circuit-Level Gateway: The "circuit” in this particular context refers to Virtual
Circuit (VC). Before TCP or UDP is allowed to open a connection or VC, the
session reliability must be verified. The packet transmission is allowed only if the
handshake has been proved valid and accomplished. After a session is set up, its
information will be written into the valid connection table maintained by the firewall.
A packet can be permitted only if the session information carried by it matches an
1-3
entry in the valid connection table. After the session is terminated, the session
entry will be deleted from the table. Circuit-level GW authenticates a connection
only at the session layer. If the authentication is passed, any application can be
run on the connection. Take FTP as an example. A circuit-level GW only
authenticates an FTP session at the TCP layer at the beginning of the session. If
the authentication is passed, all the data can be transmitted on this connection
until the session is terminated.
z Packet filter: Such a firewall filters each packet depending on the items that
defined by the user. For example, it compares the packets with the defined rules in
source and destination addresses for a match. A packet filter neither considers the
status of sessions, nor analyzes the data. If the user specifies that the packets
carrying port number 21 or a port number no less than 1024 are permitted, all the
packets matching the condition will be able to pass through the firewall. If the
configured rules are properly set for the actual applications, many packets that
bring potential threat to the security can be filtered at this layer.
z Network Address Translation (NAT): Also called address proxy, NAT makes it
possible for a private network to access an external network. The NAT mechanism
is to substitute an external network address and port of firewall for the IP address
and port of a host on a private network and vice versa. In other words, it fulfills the
conversion between <Private address + Port number> and <Public address + Port
number>. The private address discussed here refers to an internal network or host
address, and public address refers to a globally unique IP address on the Internet.
Internet Assigned Number Authority (IANA) provisioned that that the following IP
address ranges are reserved for private addresses: 10.0.0.0 to 10.255.255.255;
172.16.0.0 to 172.31.255.255; and 192.168.0.0 to 192.168.255.255.
The addresses in these three ranges will be used inside an organization or companies
rather than assigned on the Internet. A company can select a proper internal network
address ranges, taking into consideration the number of the internal hosts and
networks in the near future. The internal network addresses of different companies can
be the same. However, it will be very likely to cause chaos if a company selects a
segment beyond the three ranges given above as the internal network address. NAT
allows internal hosts to access the Internet resources while keeping their “privacy”.
1.4.3 Packet Filter
I. Function
Normally, a packet filter filters the IP packets. For the packets that the firewall will
forward, the filter will first obtain the header information of each packet, including upper
protocol carried by the IP layer, source and destination addresses of the packet, and
source and destination ports. Then, it compares them with the preset rules to determine
whether the packet should be forwarded or discarded.
1-4
Figure 1-2 illustrates the elements selected by a packet filter for decision making (on IP
packets), given the upper layer carried by IP is TCP/UDP.
Figure 1-2 Packet filtering elements
Most packet filter systems do not make any operations on data itself or make
contents-based filtering.
II. ACL
Before the system can filter the packets, you should configure some rules in ACLs to
specify the types of packets allowed or denied.
A user should configure an ACL according to the security policy and apply it to a
particular interface or the whole equipment. After that, the firewall will examine all the
packets on the interface or all the interfaces based on the ACL and make
forwarding/discard decision on the packets matching the rules. In this way, it plays the
role of a firewall.
1.5 Security Authentication before Route Information

Exchange
The maintenance of route forwarding table depends on the dynamic route information
exchanging between neighboring firewalls.
I. Necessity of implementing security authentication before route information

exchange
As the neighboring routers on a network need to exchange enormous route information,

there is the likelihood for a firewall to receive the network equipment attacking
information sent from unreliable routers. If available with the route authentication
function, a firewall will be able to authenticate the switching route update packets
received from the neighboring routers and hence make sure to receive only the reliable
route information.
II. Authentication Implementation
The routers exchanging route information share the same password key that is sent
along with the route information packets. The routers receiving the route information
1-5
will authenticate the packets, and verify the password key carried by the packets. If the
key carried by the packets is the same as the shared password key, the packets will be
accepted. If not, they will be discarded.
Authentication implementations fall into simple text authentication and MD5
authentication. The former sends password keys in plain text providing lower security,
whereas the latter sends encrypted password keys providing higher security.
1-6
Operation Manual – Security Chapter 2 AAA and RADIUS/HWTACACS
H3C SecPath Series Security Products Protocol Configuration
Chapter 2 AAA and RADIUS/HWTACACS Protocol

Configuration
2.1 Overview
2.1.1 Introduction to AAA
Authentication, Authorization and Accounting (AAA) provide a uniform framework used

for configuring these three security functions to implement the network security
management.
The network security mentioned here refers to access control and it includes:
z Which user can access the network server?
z Which service can the authorized user enjoy?
z How to keep accounts for the user who is using network resource?
Accordingly, AAA provides the following services:
I. Authentication
AAA supports the following authentication methods:

z None authentication: All users are trusted and are not authenticated. Generally,
this method is not recommended.
z Local authentication: User information (including username, password, and
attributes) is configured on the broadband access server (BAS). Local
authentication features high speed but low cost; the information can be stored in
this approach is however limited depending on the hardware capacity.
z Remote authentication: Supports both RADIUS and HWTACACS protocols. In this
approach, the BAS acts as the client to communicate with the RADIUS or
TACACS server. With respect to RADIUS, you can use the standard RADIUS
protocol or extended RADIUS protocol to complete authentication in collaboration
with devices like iTELLIN/CAMS.
II. Authorization
AAA supports the following authorization methods:

z Direct authorization: All users are trusted and directly authorized to pass.
z Local authorization: Users are authorized according to the attributes related to
their accounts on the BAS.
z HWTACACS authorization: Users are authorized using a TACACS server.
z If-authenticated authorization: Users are authorized to pass if they are
authenticated and using any allowed method other than none authentication.
2-1
z RADIUS authorization following successful authentication: With RADIUS, users

are authorized only after they pass authentication. In other words, you cannot
perform RADIUS authorization without authentication.
III. Accounting
AAA supports the following accounting methods:

z None accounting: no accounting required.
z Remote accounting: conducted through a RADIUS server or TACACS server.
Note:
Currently, the firewall only supports accounting for PPP users and Telnet users but
does not support real-time accounting for Telnet users.
AAA usually utilizes a client/server model, where the client controls user access and
the server stores user information. The framework of AAA thus allows for good
scalability and centralized user information management. Being a management
framework, AAA can be implemented using multiple protocols. In Comware, AAA is
implemented based on RADIUS or HWTACACS.
2.1.2 Introduction to the RADIUS Protocol
I. What is RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information

switching protocol in client/server model. RADIUS can prevent the network from
interruption of unauthorized access and it is often used in the network environments
where both high security and remote user access are required. For example, it is often
used for managing a large number of scattering dial-in users that use serial ports and
modems. The RADIUS system is an important auxiliary part of a network access server
(NAS).
The RADIUS service involves three components:
z Protocol: Based on the UDP/IP layer, RFC 2865 and 2866 define the RADIUS
frame format and the message transfer mechanism, and use 1812 as the
authentication port and 1813 as the accounting port.
z Server: RADIUS server runs on the computer or workstation at the center, and
contains information on user authentication and network service access.
z Client: Located at the network access server (NAS) side. It can be placed
anywhere in the network.
As the RADIUS client, the NAS (a firewall or a router) is responsible for passing user
information to a designated RADIUS server and acts on the response returned from the
2-2
server (such as connecting/disconnecting users). The RADIUS server receives user

connection requests, authenticates users, and returns the required information to the
NAS.
In general, the RADIUS server maintains three databases, namely, Users, Clients and
Dictionary, as shown in the following figure. “Users” stores user information such as
username, password, applied protocols, and IP address; “Clients” stores information
about RADIUS clients such as shared key; and “Dictionary” stores the information for
interpreting RADIUS protocol attributes and their values.
RADIUS Server
Users Clients Dictionary
Figure 2-1 Components of RADIUS server
In addition, RADIUS servers can act as the client of some other AAA server to provide
the proxy authentication or accounting service. They support multiple user
authentication methods, such as PPP-based PAP, CHAP and UNIX-based login.
II. Basic message exchange procedures in RADIUS
In most cases, user authentication using a RADIUS server always involves a device
that can provide the proxy function, such as the NAS. Transactions between the
RADIUS client and RADIUS server are authenticated through a shared key, and user
passwords are sent encrypted over the network for the security sake. The RADIUS
protocol combines the authentication and authorization processes by sending
authorization information in the authentication response message. See the following
figure.
2-3
SecPath RADIUS Serv er

RADIUS client
PSTN/
ISDN
PC
The user enters the username and passw ord
Authentication request (Access -request)
Authentication accept (Access -accept)
Accounting-request (Start)
Accounting-response
The user accesses the resources
Accounting-request (Stop)
Accounting-response
Notify the termination of the access
Figure 2-2 The basic message interaction procedures of RADIUS
Following is how RADIUS operates:

1) The user enters the username and password.
2) Having received the username and password, the RADIUS client sends the
authentication request (Access-Request) to the RADIUS server.
3) The RADIUS server compares the received user information against that in the
Users database. If the authentication succeeds, it sends back an authentication
response (Access-Accept) containing the information of user’s right. If the
authentication fails, it returns an Access-Reject message.
4) The RADIUS client acts on the returned authentication result to accept or deny the
user. If it is allowed to accept the user, the RADIUS client sends an accounting
start request (Accounting-Request) to the RADIUS server, with the value of
Status-Type being “start”.
5) The RADIUS server returns a start-accounting response (Accounting-Response).
6) The RADIUS client sends a stop-accounting request (Accounting-Request) to the
RADIUS server, with the value of Status-Type being “stop”.
7) The RADIUS server returns a stop-accounting response (Accounting-Response).
III. RADIUS packet structure
RADIUS uses UDP to transmit messages; with timer management, retransmission, and
slave server mechanisms, it ensures the smooth message exchange between the
RADIUS server and the client. The following figure shows the RADIUS packet
structure.
2-4
Code Identifier Length
Authenticator
Attribute
Figure 2-3 RADIUS packet structure
The Identifier field is used for matching request packets and response packets. It varies
with the Attribute field and the received valid response packets, but keeps unchanged
during retransmission. The 16-byte Authenticator field is used to authenticate the
request transmitted by the RADIUS server, and it also applies to the password hidden
algorithm. There are two kinds of authenticators: Request and Response.
z Request Authenticator is the random code of 16 bytes in length.
z Response Authenticator is the result of applying the MD5 algorithm to Code,
Identifier, Request Authenticator, Length, Attribute and shared-key.
1) The Code field decides the type of a RADIUS packet, as shown in the following
table.
Table 2-1 Code values
Code Packet type Description

The packet carries user information and is
transmitted by the client to the server to help the
Access-Reque client determine whether the user can access the
1
st network. The packet carries the required attribute of
User-Name and some other options, such as
NAS-IP-Address, User-Password, and NAS-Port.
The packet is transmitted by the server to the client. If
all the attribute values carried in the Access-Request
2 Access-Accept are acceptable, the server allows the user to pass
authentication and sends back an Access-Accept
response.
The packet is transmitted by the server to the client. If
any attribute value carried in the Access-Request is
3 Access-Reject
unacceptable, the server rejects the user and sends
back an Access-Reject response.
The packet carries user information and is
transmitted by the client to the server to request the
server to start accounting. The server can determine
Accounting-Re
4 whether to start accounting according to the field of
quest
the Acct-Status-Type attribute. The attributes carried
in this type of packet are basically the same as those
carried by an Access-Request packet.
2-5
Code Packet type Description

The packet is transmitted by the server to the client,
notifying that the server has received the
Accounting-Re Accounting-Request and has correctly record the
5
sponse accounting information. The packet carries such
information as input/output bytes and packets, and
session duration.
2) The Attribute field contains special authentication, authorization, and accounting

information that provides the configuration details of a request or response. This
field is represented by the triplet of Type and Length and Value. The following
table lists the major standard attribute values defined by RFC:
Table 2-2 Attribute values
Type Attribute type Type Attribute type

1 User-Name 23 Framed-IPX-Network
2 User-Password 24 State
3 CHAP-Password 25 Class
4 NAS-IP-Address 26 Vendor-Specific
5 NAS-Port 27 Session-Timeout
6 Service-Type 28 Idle-Timeout
7 Framed-Protocol 29 Termination-Action
8 Framed-IP-Address 30 Called-Station-Id
9 Framed-IP-Netmask 31 Calling-Station-Id
10 Framed-Routing 32 NAS-Identifier
11 Filter-ID 33 Proxy-State
12 Framed-MTU 34 Login-LAT-Service
13 Framed-Compression 35 Login-LAT-Node
14 Login-IP-Host 36 Login-LAT-Group
15 Login-Service 37 Framed-AppleTalk-Link
16 Login-TCP-Port 38 Framed-AppleTalk-Network
17 (unassigned) 39 Framed-AppleTalk-Zone
18 Reply_Message 40-59 (reserved for accounting)
19 Callback-Number 60 CHAP-Challenge
20 Callback-ID 61 NAS-Port-Type
21 (unassigned) 62 Port-Limit
2-6
Type Attribute type Type Attribute type

22 Framed-Route 63 Login-LAT-Port
The RADIUS protocol is extensible. The Attribute 26 (Vender-Specific) defined in it

allows a user to define an extended attribute. The following figure illustrates the
structure of a RADIUS packet:
Type Length Vendor-ID
type length
Vendor-ID
(specified) (specified)
specified attribute value……
Figure 2-4 A RADIUS packet segment containing the extended attribute
IV. Features of RADIUS
RADIUS uses UDP as transfer protocol and has good capability for real-time
applications. It also supports retransmission mechanism and backup server
mechanism so that it boasts better reliability. RADIUS is easy to implement, and
applicable to the multithreading structure of the server in the time of mass users. For all
the advantages above, RADIUS protocol is used widely.
2.1.3 Introduction to the HWTACACS Protocol
I. What is HWTACACS
HWTACACS is an enhanced security protocol based on TACACS (RFC 1492). Similar

to the RADIUS protocol, it implements AAA for different types of users (such as
PPP/VPDN/login users) through communications with TACACS servers in the
server/client model.
Compared with RADIUS, HWTACACS provides more reliable transmission and
encryption, and therefore is more suitable for security control. The following table lists
the primary differences between HWTACACS and RADIUS protocols.
Table 2-3 Comparison between HWTACACS and RADIUS
HWTACACS RADIUS
Adopts TCP, providing more reliable
Adopts UDP.
network transmission.
Encrypts the entire packet except for the Encrypts only the password field in
standard HWTACACS header. authentication packets.
2-7
HWTACACS RADIUS
Separates authentication from
authorization. For example, you can Brings together authentication and
provide authentication and authorization authorization.
on different TACACS servers.
Suitable for security control. Suitable for accounting.
Supports to authorize the use of
Not supports.
configuration commands.
In a typical HWTACACS application, a dial-up or terminal user needs to log onto the
firewall for operations. Working as the client of HWTACACS in this case, the firewall
sends the username and password to the TACACS server for authentication. After
passing authentication and being authorized, the user can log onto the firewall to
perform operations, as shown in the following figure.
Terminal user
TACACS server
129.7.66.66
ISDN \PSTN
Remote user
SecPath TACACS server
HWTACACS client 129.7.66.67
Figure 2-5 Network diagram for a typical HWTACACS application
II. Basic message exchange procedures in HWTACACS
For example, use HWTACACS to implement authentication, authorization, and

accounting for a telnet user. The basic message exchange procedures are as follows:
1) A user requests access to the firewall; the TACACS client sends a
start-authentication packet to TACACS server upon receipt of the request.
2) The TACACS server sends back an authentication response requesting for the
username; the TACACS client asks the user for the username upon receipt of the
response.
3) The TACACS client sends an authentication continuance packet carrying the
username after receiving the username from the user.
4) The TACACS server sends back an authentication response, requesting for the
login password. Upon receipt of the response, the TACACS client requests the
user for the login password.
5) After receiving the login password, the TACACS client sends an authentication
continuance packet carrying the login password to the TACACS server.
2-8
6) The TACACS server sends back an authentication response indicating that the
user has passed the authentication.
7) The TACACS client sends the user authorization packet to the TACACS server.
8) The TACACS server sends back the authorization response, indicating that the
user has passed the authorization.
9) Upon receipt of the response indicating an authorization success, the TACACS
client pushes the configuration interface of the firewall to the user.
10) The TACACS client sends a start-accounting request to the TACACS server.
11) The TACACS server sends back an accounting response, indicating that it has
received the start-accounting request.
12) The user logs off; the TACACS client sends a stop-accounting request to the
TACACS server.
13) The TACACS server sends back a stop-accounting packet, indicating that the
stop-accounting request has been received.
The following figure illustrates the basic message exchange procedures:
HWTACACS HWTACACS
User
Client Server
User logs in Authentication Start Request packet

Authentication response packet,
requesting for the user name
Request User for the user name
User enters the user name Authentication continuance packet
carrying the user name
Authentication response packet,
requesting for the password
Request User for the password
User enters the password Authentication continuance packet
carrying the password
Authentication success packet
Authorization request packet
Authorization success packet

User is permitted
Accounting start request packet
Accounting start response packet
User quits
Accounting stop packet
Accounting stop response packet
Figure 2-6 The AAA implementation procedures for a telnet user
2-9
2.2 Configuring AAA

AAA configuration tasks include:
1) Create an ISP domain and set the related attributes
z Create an ISP domain
z Configure an AAA scheme
z Configure the ISP domain state
z Set an access limit
z Enable accounting optional
z Define a local IP pool and allocate IP addresses to PPP users
2) Create a local user and set the related attributes (for local authentication only)
2.2.1 Creating an ISP Domain and Setting the Related Attributes
I. Creating an ISP domain
An Internet service provider (ISP) domain is a group of users that belong to the same
ISP. For a username in the userid@isp-name format, myuser@mydomain.net for
example, the isp-name (mydomain.net) following the @ sign is the ISP domain name.
When receiving a connection request from a user named userid@isp-name, the firewall
system considers the userid part as the username for authentication and the isp-name
part as the domain name.
The purpose of introducing ISP domain settings is to support the multi-ISP application
environment, where one access device might access users of different ISPs. Because
the attributes of ISP users, such as username and password formats, can be different,
you must differentiate them through setting ISP domains. In ISP domain view, you can
configure a complete set of exclusive ISP domain attributes on a per-ISP domain basis,
including an AAA scheme.
For SecPath Series Firewalls, each supplicant belongs to an ISP domain. Up to 16
domains can be configured in the system. If a user has not reported its ISP domain
name, the system puts it into the default domain.
Table 2-4 Create/delete an ISP domain
Operation Command
of a specified domain. enable isp-name } }
Remove a specified ISP domain. undo domain isp-name
By default, the default ISP domain in the system is system.
2-10
II. Configuring an AAA scheme
Users can configure authentication, authorization and charging schemes in the

following two modes.
1) AAA binding mode
In this mode, you can use the scheme command to specify a scheme. If you choose
the RADIUS or HWTACACS scheme, the corresponding RADIUS or HWTACACS
server will perform the authentication, authorization and accounting tasks. That is, you
cannot specify different schemes for authentication, authorization and accounting
respectively. If you use the local scheme, only authentication and authorization but not
accounting is implemented.
When the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name local command is configured, the local scheme applies as a
backup scheme in case the RADIUS or TACACS server is not available. If the RADIUS
or TACACS server is available, local authentication is not used.
If the local scheme applies as the first scheme, only local authentication is performed
and the RADIUS, HWTACACS or none scheme cannot be adopted. If the none
scheme applies as the first scheme, no RADIUS or HWTACACS scheme can be
adopted.
Perform the following configuration in ISP domain view.
Table 2-5 Configure the related attributes of the ISP domain
Operation Command
scheme { radius-scheme radius-scheme-name
Configure an AAA scheme for
[ local ] | hwtacacs-scheme
the domain.
hwtacacs-scheme-name [ local ] | local | none }
Restore the default AAA undo scheme [ radius-scheme |
scheme. hwtacacs-scheme | none ]
The default AAA scheme is local.
Caution:
z When authenticating FTP users, none authentication cannot be performed because

FTP server implemented in Comware does not support anonymous login.
z If the scheme none command is configured, user’s access level is 0 after login to
the system.
2) AAA separate mode
2-11
In this mode, you can use the authentication, authorization or accounting command
to select schemes for the three tasks respectively. For example, you can specify the
RADIUS scheme for authentication and authorization, and the HWTACACS scheme for
optional accounting, so as to provide users with flexibility in scheme combination.
Implementations of AAA services in this mode are listed below.
z For terminal users
Use RADIUS, HWTACACS, local, RADIUS-local, HWTACACS-local or none for
authentication;
Use HWTACACS or none for authorization;
Use RADIUS, HWTACACS or none for accounting.
You can custom an AAA scheme combination according to the above implementations.
z For FTP users
Only authentication can be applied on FTP users.
Use RADIUS, HWTACACS, local, RADIUS-local or HWTACACS-local for
authentication.
z For PPP and L2TP users
Use RADIUS, HWTACACS, local, RADIUS-local, HWTACACS-local or none for
authentication.
Use HWTACACS or none for authorization.
Use RADIUS, HWTACACS or none for accounting.
You can custom an AAA scheme combination according to the above implementations.
z For DVPN services
At present, only RADIUS, local and RADIUS-local support authentication and
authorization, and only RADIUS supports accounting.
Table 2-6 Configure the related ISP domain attributes
Operation Command
authentication { radius-scheme
radius-scheme-name [ local ] |
Configure an authentication scheme for
hwtacacs-scheme
the domain.
hwtacacs-scheme-name [ local ] | local
| none }
Restore the default authentication
undo authentication
scheme for the domain.
Configure an authorization scheme for authorization { hwtacacs-scheme
the domain. hwtacacs-scheme-name | none }
Restore the default authorization
undo authorization
scheme for the domain.
2-12
Operation Command
accounting { radius-scheme
Configure an accounting scheme for the radius-scheme-name |
domain. hwtacacs-scheme
hwtacacs-scheme-name | none }
Restore the default accounting scheme
undo accounting
for the domain.
Note:
1) If separate AAA schemes are configured as well as the binding AAA scheme, the
former ones are used.
2) The RADIUS and local schemes do not support separated authentication and
authorization. Therefore, the following should be noted:
z When the scheme radius-scheme or scheme local command is configured, and
the authentication command is not configured:
If authorization none is configured, the authorization data returned by the
RADIUS or local scheme is still valid;
If authorization hwtacacs is configured, the HWTACACS scheme is used for
authorization.
z If the scheme radius-scheme or scheme local command is configured as well
as the authentication hwtacacs-scheme command, the HWTACACS scheme is
used for authentication and no authorization is performed.
III. Configuring the ISP domain state
Every ISP has active/block states. If an ISP domain is in active state, the users in it can
request for network service, while in block state, its users cannot request for any
network service, which will not affect the users already online. An ISP is in the active
state when it is first created. Users in the domain are allowed to request network
service.
Table 2-7 Configure the ISP domain state
Operation Command
Configure the ISP domain state. state { active | block }
By default, an ISP domain is active when it is created.
IV. Setting an access limit
You can specify the maximum number of users that an ISP domain can accommodate
by setting an access limit.
2-13
Table 2-8 Configure an access limit
Operation Command
Set an access limit to limit the number of
access-limit { disable | enable
users that the domain can
max-user-number }
accommodate.
Restore the default value. undo access-limit
By default, an ISP domain has no limit on the user number upon its creation.
V. Enabling accounting optional
If a user is configured with accounting optional, the device does not disconnect the
user during the accounting even when it finds no available accounting server or fails to
communicate with the accounting server.
Unlike the scheme none command, with the accounting optional command, the
system sends accounting information to the accounting server but does not terminate
the connection regardless of whether the accounting server responds or performs the
accounting service. However, with the scheme none command, the system neither
sends accounting information to the accounting server nor terminates the connection. If
you specify RADIUS or HWTACACS in the scheme command without configuring
accounting optional, the system sends accounting information to the accounting
server and if the server does not respond or perform accounting service terminates the
connection.
Table 2-9 Enable/disable accounting optional
Operation Command
Enable accounting optional. accounting optional
Disable accounting optional. undo accounting optional
By default, when an ISP domain is created, accounting optional is disabled.
VI. Defining an address pool and allocating IP addresses to PPP users
PPP users can obtain IP addresses from the device through PPP address negotiation.
Three approaches are available for address allocation on an interface:
z Directly allocate IP addresses on the interface without configuring an address
pool.
2-14
z Define an address pool in system view and assign it (only one is allowed) to the
interface in the view of this interface for assigning addresses to the connected
ends.
z Define address pools in domain view and directly allocate the addresses from the
pools to the login domain PPP users.
Table 2-10 Define an IP address pool for PPP domain users
Operation Command
Define an IP address pool for allocating ip pool pool-number low-ip-address
addresses to PPP users. [ high-ip-address ]
Delete the specified address pool. undo ip pool pool-number
By default, no address pool is configured.

The following are the principles of IP address allocation to PPP users in AAA:
1) For a domain user with a name either in the form of userid or userid@default, the
address is allocated as follows:
z If RADIUS or TACACS authentication/authorization applies, the address that the
server has issued to the user is allocated, if there is any.
z If the server issues an address pool instead of an address, the device searches
the address pool in domain view for an address.
z In case no address can be allocated with the above two methods or local
authentication is used, the device allocates address according to the configuration
on the interface.
z If the interface is configured with remote address ip-address command, the
address that has not been used will be allocated to the user.
z If the interface is configured with remote address pool command, the device
searches the address pool in domain view for an address.
z If the interface is not configured with remote address command, the device
searches all the address pools in domain view for an address.
2) For a user that is not to be authenticated, the device allocates address using the
specified address pool (defined in system view) on the interface.
Note:
You still can modify the PPP address allocation mode after the PPP connection is
established, provided that the remote address ip-address command is not used.
2-15
2.2.2 Creating a Local User and Setting the Related Attributes
Create a local user and configure the related attributes on the firewall if you select the
local authentication scheme in AAA.
Note:
If you use a radius-scheme or hwtacacs-scheme to authenticate users, you must
appropriately configure the RADIUS or TACACS server; the local configuration in this
case has no effect.
I. Creating a local user
A local user is a group of users set on NAS (a firewall). The username is the unique
identifier of a user. A user requesting network service can pass local authentication as
long as its information has been added to the local user database of NAS.
Perform the following configuration in system view
Table 2-11 Create/delete a local user and the relevant properties
Operation Command
Add a local user. local-user user-name
Delete a local user or the service type of undo local-user user-name
the local user. [ service-type | level ]
Delete all local users or all local users of undo local-user all [ service-type { ftp
a specific service type. | ppp | ssh | telnet | terminal } ]
By default, there is no local user in the system.
II. Setting attributes of a local user
The attributes of a local user include user password display mode, user password, user
state, and the type of service that is authorized to the user.
Table 2-12 Set the password display mode for local users
Operation Command
Set the password display mode for all local-user password-display-mode
local users. { cipher-force | auto }
Cancel the password display mode for undo local-user
local users. password-display-mode
2-16
Where, auto means that the password display mode will be the one specified by the
user at the time of configuring password (see the password command in the following
table for reference), and cipher-force means that the password display mode of all the
accessing users must be in cipher text.
Perform the following configuration in local user view.
Table 2-13 Set/remove the attributes concerned with a specified user
Operation Command
password { simple | cipher }
Set a user password.
password
Remove the user password. undo password
Set the user state. state { active | block }
Remove the user state setting. undo state { active | block }
service-type { telnet | ssh | terminal |
Set a service type available for the user.
pad }
Cancel the service type available for the undo service-type { telnet | ssh |
user. terminal | pad }
Set a priority level for the user. level level
Restore the default priority level. undo level
Authorized DVPN service to the user service-type dvpn
Remove the DVPN service authorization undo service-type dvpn
Set the directory that can be accessed if service-type ftp [ ftp-directory
the user is an FTP user. directory]
Restore the default directory that can be
undo service-type ftp [ ftp-directory ]
accessed if the user is an FTP user.
Authenticate that the user can use PPP
service-type ppp
service.
Cancel the PPP service. undo service-type ppp
By default, no service is authorized to users. The default user priority level is 0.
2-17
Note:
If the configured authentication method requires username and password (including
local, RADIUS, and HWTACACS authentication), your user priority determines which
level of commands you can access after logging onto the system. If you adopt RSA
authentication, your interface priority determines which level of commands you can
access. If the authentication method is none or only requires password, your interface
priority determines which level of commands you can access.
2.3 Configuring the RADIUS Protocol

The RADIUS protocol is configured scheme by scheme. In a real networking
environment, a RADIUS scheme can comprise an independent RADIUS server or a
pair of primary and secondary RADIUS servers with the same configuration but
different IP addresses. Accordingly, attributes of every RADIUS scheme include IP
addresses of primary and secondary servers, shared key, and RADIUS server type.
Actually, the RADIUS protocol configurations only define the parameters necessary for
the information interaction between a NAS and a RADIUS server. To validate these
parameter settings, you also need to reference the RADIUS scheme containing those
parameter settings in ISP domain view. For more information about the configuration
commands, refer to section 2.2 “Configuring AAA.”
RADIUS protocol configuration includes:
z Create a RADIUS scheme
z Configure RADIUS authentication/authorization servers
z Configure RADIUS accounting servers and the related attributes
z Configure the shared key for RADIUS packet encryption
z Set the maximum number of RADIUS request attempts
z Set the supported RADIUS server type
z Set RADIUS server state
z Set the username format acceptable to the RADIUS server
z Set the unit of data flows destined for the RADIUS server
z Configure the source address in the RADIUS packets sent by NAS
z Set timers regarding RADIUS server
z Configure the RADIUS server to send a trap packet
Among these tasks, creating a RADIUS scheme and configuring RADIUS
authentication/authorization servers are required, while other tasks are optional at your
discretion.
2-18
2.3.1 Creating a RADIUS Scheme
As mentioned earlier, the RADIUS protocol is configured scheme by scheme.

Therefore, before performing other RADIUS protocol configurations, you must create a
RADIUS scheme and enter its view.
You can use the following commands to create/delete a RADIUS scheme.
Table 2-14 Create/delete a RADIUS scheme
Operation Command
Create a RADIUS scheme and enter its
radius scheme radius-scheme-name
view.
undo radius scheme

Delete a RADIUS scheme.
radius-scheme-name
A RADIUS scheme can be referenced by several ISP domains at the same time. The
system supports up to 16 RADIUS schemes.
By default, the system has a RADIUS scheme named system whose attributes are all
default values.
Caution:
FTP, terminal, and SSH are not standard attribute values of the RADIUS protocol, so
you need to define them in the attribute login-service (the standard attribute 15):
login-service(50) = SSH
login-service(51) = FTP
login-service(52) = Terminal
After that, reboot the RADIUS server to validate them.
2.3.2 Configuring RADIUS Authentication/Authorization Servers
You can use the following commands to configure IP address and port number of
RADIUS authentication/authorization servers.
Perform the following configuration in RADIUS view.
2-19
Table 2-15 Configure IP address and port number of RADIUS

authentication/authorization servers
Operation Command
Configure IP address and port number of the
primary authentication
primary RADIUS authentication/authorization
ip-address [ port-number ]
server.
Restore IP address and port number of the primary
undo primary
RADIUS authentication/authorization server to the
authentication
default values.
Configure IP address and port number of the
secondary authentication
secondary RADIUS authentication/authorization
ip-address [ port-number ]
server.
Restore IP address and port number of the
undo secondary
secondary RADIUS authentication/authorization
authentication
server to the default values.
As the authorization information from the RADIUS server is sent to RADIUS clients in
authentication response packets, so you do not need to specify a separate
authorization server.
In real networking environments, you may specify two RADIUS servers as primary and
secondary authentication/authorization servers respectively, or specify one server to
function as both.
2.3.3 Configuring RADIUS Accounting Servers and the Related Attributes
I. Configuring RADIUS accounting servers
You can use the following commands to configure IP address and port number of
RADIUS accounting servers.
Table 2-16 Configure IP address and port number of RADIUS accounting servers
Operation Command
Configure IP address and port number
primary accounting ip-address
of the primary RADIUS accounting
[ port-number ]
server.
Restore the default IP address and port
number of the primary RADIUS undo primary accounting
accounting server.
Configure IP address and port number
secondary accounting ip-address
of the secondary RADIUS accounting
[ port-number ]
server.
2-20
Operation Command
Restore the default IP address and port
number of the secondary RADIUS undo secondary accounting
accounting server.
In practice, you can specify two RADIUS servers as the primary and the secondary
accounting servers respectively; or specify one server to function as both.
For normal interaction between the NAS and a RADIUS server, you must ensure the
connectivity of the routes between the RADIUS server and the NAS before configuring
the IP address and UDP port of the RADIUS server. In addition, since RADIUS uses
different UDP ports for authentication/authorization and accounting, you must assign
different numbers to the authentication/authorization port and the accounting port,
which are 1812 and 1813 respectively as recommended by RFC 2138/2139. You can
assign port numbers different from the two recommended in the RFC, however. (For
example, in the early stage of RADIUS server implementation, 1645 and 1646 were
often assigned to the authentication/authorization port and accounting port). When
doing this, make sure that the port settings on the firewall and the RADIUS server are
consistent.
You can use the display radius scheme command to view the IP addresses and port
number of the primary and secondary accounting servers in the RADIUS scheme.
Note:
After an accounting operation succeeds, the accounting update and stop-accounting
packets will be forwarded to the server where the successful accounting was
performed. The master/backup status switching will not happen even if the server is not
available for use. The master/backup status switches in the authentication,
authorization and accounting process performed at the beginning and will not switch if
the operation succeeds.
II. Configuring optional accounting
If a user is configured with the accounting optional command, the device does not
disconnect the user during the accounting even when it finds no available accounting
server or fails to communicate with the accounting server.
Perform the following configuration in RADIUS domain view.
2-21
Table 2-17 Enable/disable optional accounting
Operation Command
Enable optional accounting. accounting optional
Disable optional accounting. undo accounting optional
By default, when an RADIUS scheme is created, optional accounting is disabled.
III. Enabling the stop-accounting packet buffer and retransmission
Since the stop-accounting packet affects the bill and eventually the charge to a user, it
has importance for both users and the ISP. Therefore, the NAS should make its best
effort to send every stop-accounting packet to the RADIUS accounting server. If the
NAS receives no response from the RADIUS accounting server to a stop-accounting
packet that it has sent for a specified period, it buffers and resends the packet until the
RADIUS accounting server responds, or discards the packet if the number of
transmission attempts reaches the configured limit. You can use the following
commands to enable the NAS to buffer stop-accounting packets and set the maximum
number of transmission attempts.
Table 2-18 Enable the stop-accounting packet buffer and set the maximum number of
transmission attempts
Operation Command
Enable the stop-accounting packet
stop-accounting-buffer enable
buffer.
Disable the stop-accounting packet
undo stop-accounting-buffer enable
buffer.
Enable stop-accounting packet
retransmission and specify the
retry stop-accounting retry-times
maximum number of transmission
attempts.
undo retry stop-accounting
transmission attempts.
By default, the stop-accounting packet buffer is disabled and the maximum number of
packet transmission attempts is 500.
IV. Configuring the maximum number of real-time accounting request

attempts
A RADIUS server usually determines the online state of a user using the connection
timeout timer. If the RADIUS sever receives no real-time accounting packets from the
2-22
NAS for a long time, it considers that the line or device fails and stops user accounting.
To work with this feature of the RADIUS server, the NAS is required to terminate user
connections simultaneously with the RADIUS server when unpredictable faults occur.
SecPath Series Firewalls allow you to set the maximum number of continuous real-time
accounting request attempts. The NAS terminates a user connection if it receives no
response after the number of transmitted real-time accounting requests exceeds the
configured limit.
You can use the following command to set the maximum number of real-time
accounting request attempts.
Table 2-19 Set the maximum number of real-time accounting request attempts
Operation Command
Set the maximum number of real-time
retry realtime-accounting retry-times
accounting request attempts.
undo retry realtime-accounting
real-time accounting request attempts.
By default, the maximum number of real-time accounting request attempts is 5.
2.3.4 Setting the Shared Key for RADIUS Packet Encryption
The RADIUS client (the firewall) and RADIUS server use the MD5 algorithm to encrypt
the exchanged packets between them. The two ends verify the packets using a shared
key. Only when the same key is used can they properly receive the packets and make
responses.
Table 2-20 Set the shared key for RADIUS packet encryption
Operation Command
Set the shared key for RADIUS
key authentication string
authentication/authorization packet encryption.
Restore the default shared key for RADIUS
undo key authentication
authentication/authorization packet encryption.
Set the shared key for RADIUS accounting
key accounting string
packet encryption.
Restore the default shared key for RADIUS
undo key accounting
accounting packet encryption.
By default, no shared key is used for RADIUS authentication/authorization and

accounting packet encryption.
2-23
2.3.5 Setting the Maximum Number of RADIUS Request Attempts
Since RADIUS uses UDP packets to carry data, the communication process is not
reliable. If the RADIUS server does not respond to the NAS before the response timer
times out, the NAS should retransmit the RADIUS request. After the number of
transmission attempts exceeds the specified retry-times, the NAS considers the
communication with the current RADIUS server has been disconnected and turns to
another RADIUS server.
You can use the following command to set the maximum number of allowed RADIUS
request attempts.
Table 2-21 Set the maximum number of RADIUS request attempts
Operation Command
Set the maximum number of RADIUS request attempts. retry retry-times
Restore the default maximum number of RADIUS request
undo retry
attempts.
By default, a RADIUS request can be sent up to three times.
2.3.6 Setting the Supported RADIUS Server Type
You can use the following command to set the supported RADIUS server type.
Table 2-22 Set the supported RADIUS server type
Operation Command
Set the supported RADIUS server type server-type { extended | standard }
Restore the RADIUS server type to
undo server-type
standard
By default, in system scheme, the RADIUS server type is extended; in the newly
added RADIUS scheme, the RADIUS server type is standard.
2-24
Note:
When using the CAMS server, you need to configure the service-type to extend to
make the parameters (such as service type, EXEC priority and FTP directory) take
effect.
2.3.7 Setting RADIUS Server State
For primary and secondary servers (no matter they are authentication/authorization
servers or accounting servers) in a RADIUS scheme, if the primary server is
disconnected from the NAS due to some fault, the NAS automatically turns to the
secondary server. However, after the primary one recovers, the NAS does not resume
the communication with it at once; instead, the NAS continues communicating with the
secondary one and turns to the primary one again only after the secondary one fails. To
have the NAS communicate with the primary server right after its recovery, you can
manually set the primary server state to active.
When both primary and secondary servers are active or blocked, the NAS sends
packets to the primary one only.
Table 2-23 Set RADIUS server state
Operation Command
Set the state of the primary RADIUS state primary authentication { block |
authentication/authorization server. active }
Set the state of the primary RADIUS state primary accounting { block |
accounting server. active }
Set the state of the secondary RADIUS state secondary authentication
authentication/authorization server. { block | active }
Set the state of the secondary RADIUS state secondary accounting { block |
accounting server. active }
You can use the display radius scheme command to view the server state in the
RADIUS scheme.
2.3.8 Setting Username Format Acceptable to RADIUS Server
As mentioned above, the supplicants are generally named in userid@isp-name format.

The part following “@” is the ISP domain name. SecPath Series Firewalls will put the
users into different ISP domains according to the domain names. However, some
earlier RADIUS servers reject the username including ISP domain name. In this case,
you have to remove the domain name before sending the username to the RADIUS
2-25
server. The firewall provides the following command to specify whether the username
to be sent to the RADIUS server carries ISP domain name or not.
Table 2-24 Set username format acceptable to RADIUS server
Operation Command
Set the username format transmitted to user-name-format { with-domain |
the RADIUS server. without-domain }
Note:
If a RADIUS scheme is configured not to allow usernames to include ISP domain
names, the RADIUS scheme shall not be simultaneously used in more than one ISP
domain. Otherwise, the RADIUS server will regard two users in different ISP domains
as the same user by mistake, if they have the same username (excluding their
respective domain names.)
By default, in system scheme, the NAS server sends user names without the ISP
domain name to the RADIUS server; in the newly added RADIUS scheme, the NAS
server sends user names with the ISP domain name to the RADIUS server.
2.3.9 Setting the Unit of Data Flows Destined for RADIUS Server
SecPath Series Firewalls provide you with the following command to define the unit of
the data flow sent to RADIUS servers.
Table 2-25 Set the unit of data flows destined for RADIUS server
Operation Command
Set the unit of data flows data-flow-format data { byte | giga-byte |
transmitted to RADIUS kilo-byte | mega-byte } packet { giga-packet |
server. kilo-packet | mega- packet | one-packet }
Restore the default unit. undo data-flow-format
In a RADIUS scheme, the default data unit is byte and the default data packet unit is
one packet.
2.3.10 Configuring Source Address for RADIUS Packets Sent by NAS
Perform the following configuration in specified view.
2-26
Table 2-26 Configure source address for the RADIUS packets sent by the NAS
Operation Command
Configure the source address to be carried in the
nas-ip ip-address
RADIUS packets sent by the NAS (RADIUS view).
Cancel the configured source address to be carried in
undo nas-ip
the RADIUS packets sent by the NAS (RADIUS view).
Configure the source address to be carried in the
radius nas-ip ip-address
RADIUS packets sent by the NAS (System view).
Cancel the configured source address to be carried in
undo radius nas-ip
the RADIUS packets sent by the NAS (System view).
You can use either command to bind a source address with the NAS.
By default, no source address is specified and the source address of a packet is the
address of the interface where it is sent.
2.3.11 Setting Timers Regarding RADIUS Server
I. Setting the response timeout timer
If the NAS receives no response from the RADIUS server after sending a RADIUS
request (authentication/authorization or accounting request) for a period, the NAS has
to resend the request, thus ensuring the user can obtain the RADIUS service.
You can use the following commands to set the response timeout timer.
Table 2-27 Set the response timeout timer
Operation Command
timer seconds
Set the response timeout timer.
timer response-timeout seconds
Restore the default response timeout undo timer

timer. undo timer response-timeout
By default, the response timeout timer for the RADIUS server is set to three seconds.
Command timer and timer response-timeout share the same function.
II. Setting the quiet timer for the primary RADIUS server
2-27
Table 2-28 Configure the quiet timer for the primary RADIUS server
Operation Command
Configure the quiet timer for the primary
timer quiet minutes
RADIUS server.
Restore the default setting. undo timer quiet
By default, the primary RADIUS server must wait five minutes before it can resume the
active state.
III. Setting a realtime accounting interval
The setting of real-time accounting interval is indispensable to real-time accounting.

After an interval value is set, the NAS transmits the accounting information of online
users to the RADIUS accounting server at intervals of this value.
Table 2-29 Set a real-time accounting interval
Operation Command
Set a real-time accounting interval. timer realtime-accounting minutes
Restore the default real-time accounting
undo timer realtime-accounting
interval.
In the command, the minutes argument represents the interval for realtime accounting
and it must be a multiple of three.
The setting of real-time accounting interval somewhat depends on the performance of
the NAS and the RADIUS server: a shorter interval requires higher device performance.
You are therefore recommended to adopt a longer interval when there are a large
number of users (more than 1000, inclusive). The following table recommends the ratio
of minutes to the number of users.
Table 2-30 Recommended ratio of interval to user number
Interval for realtime accounting

User number
(minute)
1 – 99 3
100 – 499 6
500 – 999 12
ú1000 ú15
The realtime accounting interval defaults to 12 minutes.
2-28
2.3.12 Configure the RADIUS server to send a trap packet
Table 2-31 Configure the RADIUS server to send a trap packet
Operation Command
radius trap
Configure the RADIUS server to send a
{ authentication-server-down |
trap packet when it goes down.
accounting-server-down }
undo radius trap

Configure the RADIUS server not to
{ authentication-server-down |
send a trap packet when it goes down.
accounting-server-down }
By default, the RADIUS server does not send a trap packet when it goes down.
2.3.13 Configuring Local RADIUS Authentication Server
The firewall provides the simple local RADIUS server function, including authentication
and authorization, called RADIUS authentication server function.
Table 2-32 Configure local RADIUS authentication server
Operation Command
Configure local RADIUS authentication local-server nas-ip ip-address key
server. password
Cancel the local RADIUS authentication
undo local-server nas-ip ip-address
server configuration.
By default, a local RADIUS authentication server with the NAS-IP as 127.0.0.1 and key
as NULL is created.
2-29
Note:
When the local RADIUS authentication server function is enabled, the UDP port
number for the authentication/authorization services must be 1645 and that for the
accounting service must be 1646.
The packet key password configured here must be the same with the
authentication/authorization packet key password configured in the key
authentication command in RADIUS view.
The device supports 16 local RADIUS authentication servers at most, including default
ones created by the system.
2.4 HWTACACS Protocol Configuration

The configuration tasks of HWTACACS include:
z Create a HWTACACS scheme
z Configure TACACS authentication servers
z Configure TACACS authorization servers
z Configure TACACS accounting servers
z Configure Source Address for HWTACACS Packets Sent by NAS
z Configure a key for securing the communication with a TACACS server
z Set the username format acceptable to a TACACS server
z Set the unit of data flows destined for a TACACS server
z Set timers regarding TACACS server
Note:
In contrast to the settings in RADIUS server, note the following points when configuring
a TACACS server:
z The system does not check whether users are using the current HWTACACS
scheme when you change most of its attributes, except when you delete the
scheme.
z By default, the TACACS server has no key.
Among these configuration tasks, creating a HWTACACS scheme and configuring

TACACS authentication/authorization server are mandatory, while others are arbitrary
at your discretion.
2-30
2.4.1 Creating a HWTACACS scheme
As aforementioned, HWTACACS protocol is configured scheme by scheme. Therefore,

you must create a HWTACACS scheme and enter HWTACACS view before you
perform other configuration tasks.
Table 2-33 Create a HWTACACS scheme
Operation Command
Create a HWTACACS scheme and hwtacacs scheme
enter HWTACACS view. hwtacacs-scheme-name
undo hwtacacs scheme
Delete a HWTACACS scheme.
hwtacacs-scheme-name
If the HWTACACS scheme you specify does not exist, the system creates it and enters
HWTACACS view.
In HWTACACS view, you can configure the HWTACACS scheme.
The system supports up to 16 HWTACACS schemes. You can only delete the schemes
that are not being used.
By default, no HWTACACS scheme exists.
2.4.2 Configuring TACACS Authentication Servers
Perform the following configuration in HWTACACS view.
Table 2-34 Configure TACACS authentication servers
Operation Command
Configure the TACACS primary primary authentication ip-address
authentication server. [ port ]
Delete the TACACS primary
undo primary authentication
authentication server.
Configure the TACACS secondary secondary authentication ip-address
authentication server. [ port ]
Delete the TACACS secondary
undo secondary authentication
The primary and secondary authentication servers cannot use the same IP address.
Otherwise, the system will prompt unsuccessful configuration. The default port number
is 49.
If you execute this command repeatedly, the new settings will replace the old settings.
2-31
You can remove a server that cannot be removed otherwise, only when it is not used by
any active TCP connection for sending authentication packets. This delete does not
affect the packets sent before the operation.
2.4.3 Configuring TACACS Authorization Servers
Table 2-35 Configure TACACS authorization servers
Operation Command
Configure the primary TACACS primary authorization ip-address
authorization server. [ port ]
Delete the primary TACACS
undo primary authorization
Configure the secondary TACACS secondary authorization ip-address
authorization server. [ port ]
Delete the secondary TACACS
undo secondary authorization
Note:
If TACACS authentication is configured for a user without TACACS authorization
server, the user cannot log in regardless of its user type.
The primary and secondary authorization servers cannot use the same IP address.
is 49.
any active TCP connection for sending authorization packets.
2.4.4 Configuring TACACS Accounting Servers and the Related Attributes
I. Configuring TACACS accounting servers
Table 2-36 Configure TACACS accounting servers
Operation Command
Configure the primary TACACS
primary accounting ip-address [ port ]
accounting server.
2-32
Operation Command
Delete the primary TACACS accounting
undo primary accounting
server.
Configure the secondary TACACS secondary accounting ip-address
accounting server. [ port ]
Delete the secondary TACACS
undo secondary accounting
accounting server.
The primary and secondary accounting servers cannot use the same IP address.
is 49.
The default IP address of TACACS accounting server is 0.0.0.0.
any active TCP connection for sending accounting packets.
Note:
After an accounting operation succeeds, the accounting update and stop-accounting
packets will be forwarded to the server where the successful accounting was
performed. The master/backup status switching will not happen even if the server is not
available for use. The master/backup status switches in the authentication,
authorization and accounting process performed at the beginning and will not switch if
the operation succeeds.
II. Enabling stop-accounting packet buffer and packet retransmission
Table 2-37 Enable stop-accounting packet buffer and packet retransmission
Operation Command
Enable stop-accounting packet buffer. stop-accounting-buffer enable
Disable stop-accounting packet buffer. undo stop-accounting-buffer enable
Enable stop-accounting packet
retransmission and set the allowed
retry stop-accounting retry-times
maximum number of transmission
attempts.
2-33
Operation Command
Disable stop-accounting packet
undo retry stop-accounting
retransmission.
By default, stop-accounting packet retransmission is enabled, and the allowed

maximum number of transmission attempts is 100.
2.4.5 Configuring Source Address for HWTACACS Packets Sent by NAS
Perform the following configuration in HWTACACS view and system view.
Table 2-38 Configure the source address to be carried in HWTACACS packets sent by
the NAS
Operation Command
Configure the source address to be carried in HWTACACS
nas-ip ip-address
packets sent by the NAS (HWTACACS view).
Delete the configured source address to be carried in the
undo nas-ip
HWTACACS packets sent by the NAS (HWTACACS view).
Configure the source address to be carried in the hwtacacs hwtacacs nas-ip
packets sent by the NAS (System view). ip-address
Cancel the configured source address to be carried in the undo hwtacacs
hwtacacs packets sent by the NAS (System view). nas-ip
By default, no source address is specified and the source address to be carried in a

packet is the address of the interface where the packet is sent.
2.4.6 Setting a Key for Securing the Communication with TACACS Server
When using a TACACS server as an AAA server, you can set a key to improve the
communication security between the firewall and the TACACS server.
Table 2-39 Set a key for securing the communication with the TACACS server
Operation Command
Configure a key for securing the
communication with the TACACS key { accounting | authorization |
accounting, authorization or authentication } string
undo key { accounting | authorization
Delete the configuration.
| authentication }
2-34
No key is configured by default.
2.4.7 Setting the Username Format Acceptable to the TACACS Server
Username is usually in the “userid@isp-name” format, with the domain name following
“@”.
If a TACACS server does not accept the username with domain name, you can remove
the domain name and resend it to the TACACS server.
Table 2-40 Set the username format acceptable to the TACACS server
Operation Command
Send username with domain name. user-name-format with-domain
Send username without domain name. user-name-format without-domain
By default, each username sent to a TACACS server contains a domain name.
2.4.8 Setting the Unit of Data Flows Destined for the TACACS Server
Table 2-41 Set the unit of data flows destined for the TACACS server
Operation Command
data-flow-format data { byte | giga-byte
| kilo-byte | mega-byte }
Set the unit of data flows destined for
the TACACS server. data-flow-format packet { giga-packet |
kilo-packet | mega-packet |
one-packet }
Restore the default unit of data flows
undo data-flow-format { data | packet }
destined for the TACACS server.
The default data unit is byte, packet unit is one packet.
2.4.9 Setting Timers Regarding TACACS Server
I. Setting the response timeout timer
Since HWTACACS is implemented based on TCP, server response timeout or TCP

timeout may terminate the connection to the TACACS server.
2-35
Table 2-42 Set the response timeout timer
Operation Command
Set the response timeout time. timer response-timeout seconds
Restore the default setting. undo timer response-timeout
The default response timeout timer is set to five seconds.
II. Setting the quiet timer for the primary TACACS server
Table 2-43 Set the quiet timer for the primary TACACS server
Operation Command
Set the quiet timer for the primary
timer quiet minutes
TACACS server.
Restore the default setting. undo timer quiet
By default, the primary TACACS server must wait five minutes before it can resume the
active state.
III. Setting a realtime accounting interval
The setting of real-time accounting interval is indispensable to real-time accounting.

After an interval value is set, the NAS transmits the accounting information of online
users to the RADIUS accounting server at intervals of this value.
Table 2-44 Set a real-time accounting interval
Operation Command
Set a real-time accounting interval. timer realtime-accounting minutes
Restore the default real-time accounting
undo timer realtime-accounting
interval.
The interval is in minutes and must be a multiple of 3.

The setting of real-time accounting interval somewhat depends on the performance of
the NAS and the TACACS server: a shorter interval requires higher device performance.
You are therefore recommended to adopt a longer interval when there are a large
number of users (more than 1000, inclusive). The following table recommends the ratio
of minutes to the number of users.
2-36
Table 2-45 Recommended ratio of the interval to the number of users
Real-time accounting interval (in

User number
minutes)
1 – 99 3
100 – 499 6
500 – 999 12
ú1000 ú15
The real-time accounting interval defaults to 12 minutes.
2.5 TACACS Supporting Super Authentication

You can use the super level command to acquire higher access level when logging into
the firewall.
Super-password mode can be used for authentication when switching access levels;
however, for a specified level, all users use the same password, which is not flexible
and secure. TACACS authentication is developed based on TACACS supporting super
authentication, that is, user name and super password are configured on TACACS
server, thus to enhance management flexibility and security.
2.5.1 Super Authentication Level Switching Process
The system allows configuring super authentication mode in any user interface view.
Following are the four authentication modes supported:
z super-password
z scheme
z super-password + scheme
z scheme + super-password
After login, you can use the super level command to modify your access level.
The system deals with this command in the following cases:
I. The applied access level is not greater than the current level
You do not need to pass the authentication, for you can acquire the applied access
level directly.
II. The applied access level is greater than the current level
The system processing depends on the super authentication mode configured on the
user interface.
1) super-password authentication mode
A super-password authentication mode can be configured for each level.
2-37
z If the password is specified for the applied access level, the system prompts to
enter the password, and then you can obtain the applied access level; otherwise
the system prompts that the authentication fails.
z If the password is not specified, you can not obtain the access level.
Caution:
The system uses different processing method if super-password is not set. You can
obtain the access level directly through the console port and other users cannot before,
while now, none of the users can obtain the access level.
2) scheme authentication mode

z If you use AAA authentication mode (that is, you need to input the user name and
password when login ), the system prompts you to input the password after
executing the super level command, and then sends the user name and the super
password to TACACS server for authentication. If the authentication succeeds,
you can obtain corresponding access level; otherwise, the system prompts that
the authentication fails.
z If the authentication mode is password or no authentication mode is used (that is,
you do not need to input the user name when login), the system prompts you to
input the user name and super password after executing the super level
command, and then sends the user name and password to TACACS server for
authentication. If the authentication succeeds, you can obtain corresponding
access level; otherwise, the authentication fails.
3) scheme + super-password authentication mode
In this mode, the system adopts scheme authentication mode first. If TACACS server
configured in the scheme is not routable or no authentication scheme is configured in
domain, the system adopts super-password authentication mode.
4) super-password + scheme authentication mode
In this mode, the system prefers to adopt super-password authentication mode. If the
corresponding super-password is not specified, the system adopts scheme
authentication mode.
2.5.2 Configuring Super Authentication Mode
2-38
Table 2-46 Configure super authentication mode
Operation Command
super authentication-mode
Configure super authentication mode
{ super-password | scheme }*
Restore super authentication mode to
undo super authentication-mode
the default
By default, super authentication mode is super-password.
2.5.3 Configuring Super Authentication Scheme
The system supports configuring a super authentication scheme for each domain. This
scheme can only be set to HWTACACS scheme, not RADIUS or local scheme. If one
HWTACACS scheme is referenced by a super authentication scheme of a domain, this
scheme cannot be deleted. If no scheme is specified or the specified scheme does not
exist, TACACS authentication fails.
Table 2-47 Configure super authentication scheme
Operation Command
Configure super authentication authentication super hwtacacs-scheme
scheme hwtacacs-scheme-name
Cancel the configuration of super
undo authentication super
authentication scheme
By default, super authentication scheme is not configured.
2.6 Displaying and Debugging AAA and RADIUS/HWTACACS

Protocols
After the above configuration, execute the display commands in any view to view the
running of the AAA and RADIUS/HWTACACS configurations and to check the
configuration effect. Execute the reset commands in user view to reset the
configurations. Execute the debugging commands in user view for debugging.
Table 2-48 Display and debug the AAA protocol
Operation Command
Display the configuration information of
display domain [ isp-name ]
the specified or all the ISP domains.
2-39
Operation Command
display connection [ domain isp-name
| ip ip-address | mac mac-address |
Display related information of user’s
radius-scheme radius-scheme-name |
connection.
ucibindex ucib-index | user-name
user-name ]
display local-user [ domain isp-name |
Display related information of the local service-type { dvpn | telnet | ssh |
user terminal | ftp | ppp } | state { active |
block } | user-name user-name ]
Table 2-49 Display and debug the RADIUS protocol
Operation Command
Display the specified or all the RADIUS display radius scheme
schemes [ radius-scheme-name ]
Display the statistics on RADIUS
display radius statistics
packets.
display stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range
stop-accounting packets in the buffer.
start-time stop-time | user-name
user-name }
Display the statistics on the local
display local-server statistics
RADIUS authentication server.
Enable RADIUS packet debugging. debugging radius packet
Disable RADIUS packet debugging. undo debugging radius packet
Enable local RADIUS authentication debugging local-server { all | error |
server debugging. event | packet }
Disable local RADIUS authentication undo debugging local-server { all |
server debugging. error | event | packet }
reset stop-accounting-buffer
{ radius-scheme radius-scheme-name |
Clear stop-accounting packets from the
session-id session-id | time-range
buffer.
start-time stop-time | user-name
user-name }
Reset the statistics of RADIUS server. reset radius statistics
Table 2-50 Display and debug the HWTACACS protocol
Operation Command
Display the specified or all the display hwtacacs scheme
HWTACACS schemes. [ hwtacacs-scheme-name [ statistics ] ]
2-40
Operation Command
display stop-accounting-buffer
hwtacacs-scheme
stop-accounting packets in the buffer.
debugging hwtacacs { all | error |
Enable HWTACACS debugging. event | message | receive-packet |
send-packet }
undo debugging hwtacacs { all | error
Disable HWTACACS debugging. | event | message | receive-packet |
send-packet }
reset stop-accounting-buffer
Clear stop-accounting packets from the
hwtacacs-scheme
buffer.
reset hwtacacs statistics
Reset the statistics about TACACS
{ accounting | authentication |
servers.
authorization | all }
2.7 AAA Protocol Configuration Example

2.7.1 Telnet/SSH User Authentication/Accounting Using RADIUS Server
Note:
Configuring authentication on the RADIUS server for SSH users is similar to Telnet
users. The following example is based on Telnet users.
Configure the firewall to enable the RADIUS server to provide authentication and
accounting services for Telnet users accessing the firewall (see the following figure).
Connect the firewall to the RADIUS server device (functions as both authentication and
accounting servers) whose IP address is 10.110.91.146. On the firewall, set both the
shared keys for encrypting authentication and accounting packets to "expert”.
You can use a CAMS server as the RADIUS server. Set server-type in the RADIUS
scheme to standard or extended if a third-party RADIUS server is used and to extended
if a CAMS server is used. On the RADIUS server, set both the shared keys for
encrypting authentication and accounting packets to "expert”; set the authentication
and accounting port numbers; add the usernames and login passwords of the Telnet
users. If the firewall is configured in the RADIUS scheme to send the full username
2-41
(both userid and isp-name) to the RADIUS server, the usernames added onto the
RADIUS server are in the userid@isp-name format.
II. Network diagram
Authentication/Accounting Servers
( IP address:10.110.91.146 )
Intern
e
Internet
t
telnet user
SecPath
Figure 2-7 Configure remote RADIUS authentication for Telnet users
# Apply AAA authentication to Telnet users, that is, the scheme mode.
# Configure domain.
[H3C] domain cams
[H3C-isp-cams] access-limit enable 10
[H3C-isp-cams] idle-cut enable 20 50
[H3C-isp-cams] accounting optional
[H3C-isp-cams] quit
# Configure a RADIUS scheme, adopting remote authentication.

[H3C] radius scheme cams
[H3C-radius-cams] primary authentication 10.110.91.146 1812
[H3C-radius-cams] key authentication expert
[H3C-radius-cams] server-type extended
[H3C-radius-cams] user-name-format with-domain
[H3C-radius-cams] quit
# Associate the domain to the RADIUS scheme.

[H3C] domain cams
[H3C-isp-cams] scheme radius-scheme cams
Telnet users use usernames in the userid@cams format to log onto the network and
are to be authenticated as CAMS domain users.
2-42
2.7.2 Configuring FTP/Telnet User Local Authentication
Note:
Configuring local authentication for FTP users is similar to that for Telnet users. The
following example is based on Telnet users.
Configure the firewall to authenticate the login Telnet users at the local (see the
following figure).
II. Network diagram
Internet
Internet
telnet user SecPath
Figure 2-8 Local authentication for Telnet users
# Apply AAA authentication to Telnet users.

# Create a local user telnet.

[H3C] local-user telnet
[H3C-luser-telnet] service-type telnet
[H3C-luser-telnet] password simple pwd
[H3C] domain system
Telnet users use usernames in the “userid@system” format to log onto the network and
are to be authenticated as users of the system domain.
2.7.3 PPP User Authentication/Accounting/Authorization with TACACS
Configure the firewall to use a TACACS server to assign IP addresses and provide
authentication, accounting, and authorization services to login PPP users (see the
following figure).
2-43
Connect the firewall to one TACACS server (providing the services of authentication,
authorization, and accounting) with the IP address 10.110.91.146. On the firewall, set
the shared key for authentication, authorization, and accounting packet encryption to
“expert”. Configure the firewall to send usernames to the TACACS server with
isp-name removed.
On the TACACS server, set the shared key for encrypting the packets exchanged with
the firewall to “expert”; add the usernames and passwords of PPP users.
II. Network diagram
Authentication/Authorization/
Accounting Serv ers
( IP address:10.110.91.146)
e1/0/0:
10.110.91.160
PSTN Intranet
Virtual-Template 1:
SecPath
PPP user 188.188.188.2
Figure 2-9 Configure remote PPP user authentication with HWTACACS
# Configure a HWTACACS scheme.

[H3C] hwtacacs scheme hwtac
[H3C-hwtacacs-hwtac] primary authentication 10.110.91.146 49
[H3C-hwtacacs-hwtac] primary authorization 10.110.91.146 49
[H3C-hwtacacs-hwtac] primary accounting 10.110.91.146 49
[H3C-hwtacacs-hwtac] key authentication expert
[H3C-hwtacacs-hwtac] key authorization expert
[H3C-hwtacacs-hwtac] key accounting expert
[H3C-hwtacacs-hwtac] user-name-format with-domain
[H3C-hwtacacs -hwtac] quit
# Associate the domain with the hwtacacs.

[H3C] domain hwtacacs
[H3C-isp-hwtacacs] scheme hwtacacs-scheme hwtac
[H3C-isp-hwtacacs] ip pool 1 200.1.1.1 200.1.1.99
[H3C-isp-hwtacacs] quit
# Configure the virtual template parameters on the firewall.
2-44

[H3C-Virtual-Template1] ppp authentication-mode pap domain hwtacacs
# Configure the Ethernet interface.

2.7.4 Configuring HWTACACS Server Authentication/Accounting
In the network environment as shown in Figure 2-10, make proper configuration to

enable the HWTACACS server to employ one-time password authentication
/accounting on Telnet users.
One HWTACACS server host, serving as both authentication server, authorization
server and accounting server, is connected to a firewall. The IP address of the server
host is 10.110.91.146. Set the shared keys both for packet exchange with the TACACS
server as “expert”. The HWTACACS server provides one-time password authentication,
and the firewall does not remove the domain name from the user name but sends them
together to the HWTACACS server, so the user name you add on the HWTACACS
server should be “test@tacacs”.
II. Network diagram
Authentication/Accounting Serv ers

( IP address:10.110.91.146 )
Internet
Internet
telnet user
SecPath
Figure 2-10 Configure remote HWTACACS authentication for the Telnet user
1) Configure the firewall.

# Configure Telnet users to use AAA authentication.
2-45
[H3C] user-interface vty0 4

# Configure the domain name.

[H3C] domain tacacs
[H3C-isp-tacacs] access-limit enable 10
[H3C-isp-tacacs] accounting optional
[H3C-isp-tacacs] quit
# Configure the TACACS scheme.

[H3C] hwtacacs scheme system
[H3C-hwtacacs-system] primary authentication 10.110.91.146
[H3C-hwtacacs-system] primary authorization 10.110.91.146
[H3C-hwtacacs-system] primary accounting 10.110.91.146
[H3C-hwtacacs-system] key authentication expert
[H3C-hwtacacs-system] key authorization expert
[H3C-hwtacacs-system] key accounting expert
[H3C-hwtacacs-system] user-name-format with-domain
[H3C-hwtacacs-system] quit
# Associate the domain with the HWTACACS scheme.

[H3C] domain tacacs
[H3C-isp-tacacs] scheme hwtacacs-scheme system
2) Configure the HWTACACS server.
z Configure IP address
z Configure shared keys
z Add Telnet username test@tacacs
z Enable one-time password authentication
3) Login process
Configuring one-time password authentication for Telnet users are in these steps:
Figure 2-11 Telnet user login interface
2-46
Step 1: Type username test@tacacs.

Step 2: Choose to use the winkey.exe calculator to get the login password at the prompt
“s/key 89 gf55236”.
Figure 2-12 Calculate login password
In the above figure:

Type the prompt “89 gf55236” in the Challenge field.
Type private password (test for example) in the Password field.
The Response field outputs the calculation result, that is, the password you need to
type in the login interface.
Step 3: Type the calculated password in the login interface and you are authorized to
access.
2.8 Troubleshooting AAA

2.8.1 Troubleshooting the RADIUS Protocol
The RADIUS protocol of the TCP/IP protocol suite is located at the application layer. It
mainly provisions how to exchange user information between a NAS and a RADIUS
server of an ISP. So it is very likely to get invalid.
z Symptom 1: User authentication/authorization always fails
Troubleshooting:
Check that:
1) The username is in the userid@isp-name format or a default ISP domain is
specified on the NAS.
2) The user exists in the database on the RADIUS server.
3) The password input by the user is correct.
4) The same shared key is configured on both the RADIUS server and the NAS.
5) The NAS can communicate with the RADIUS server (by pinging the RADIUS
server).
z Symptom 2: RADIUS packets cannot reach the RADIUS server.
Troubleshooting:
Check that:
2-47
1) The communication links (at both physical and link layers) between the NAS and
the RADIUS server work well.
2) The IP address of the RADIUS server is correctly configured on the NAS.
3) Authentication/Authorization and accounting UDP ports are set in consistency with
the port numbers set on the RADIUS server.
z Symptom 3: A user passes the authentication and gets an authorization already,
but its charging bill cannot be sent to the RADIUS server.
Troubleshooting:
Check that:
1) The accounting port number is correctly set.
2) The authentication/authorization and accounting servers are correctly configured
on the NAS. For example, the fault can occur in the situation where one server is
configured on the NAS to provide all the services of authentication/authorization
and accounting, despite the fact that different server devices are used to provide
the services.
2.8.2 Troubleshooting the HWTACACS Protocol
See the previous section if you encounter a HWTACACS fault.
2-48
H3C SecPath Series Security Products Chapter 3 ACL Configuration
Chapter 3 ACL Configuration
3.1 Introduction to ACL

3.1.1 ACL Overview
In order to filter data packets, a series of rules need to be configured on the firewall to
decide which data packets can pass. These rules are defined by ACL (Access Control
List), which are a series of sequential rules consisting of permit and deny statements.
The rules are described by source address, destination address and port number of
data packets. ACL classifies data packets through these firewall interface applied rules,
by which the firewall decides which packets can be received and which should be
rejected.
3.1.2 Classification of ACL
According to application purpose, ACL falls into four groups:

z Basic ACL
z Advanced ACL
z Interface-based ACL
z MAC-based ACL
The application purpose of ACL is specified by the range of the number.
Interface-based ACL ranges from 1000 to 1999; basic ACL ranges from 2000 to 2999;
advanced ACL ranges from 3000 to 3999; and MAC-based ACL ranges from 4000 to
4999.
3.1.3 Match order of ACL
An access control rule may consist of several permit and deny statements, each
statement specifying different packet ranges. In this case, match order problem exists
on matching a packet and access control rule.
There are two kinds of match orders:
z Configuration sequence: match ACL rules according to their configuration order.
z Automatic sequencing: follow the principle of “depth priority”.
“Depth priority” rule puts the statement that specifies the smallest packet range into first
place. This can be realized by comparing address wildcard. The smaller the wildcard is,
the smaller the specified host range. For example, 129.102.1.1 0.0.0.0 specifies a host:
129.102.1.1, while 129.102.1.1 0.0.255.255 specifies a network segment: from
129.102.1.1 to 129.102.255.255. Obviously, the former is put first in access control rule.
The detailed standard is: for statements of basic access control rule, directly compare
3-1
their source address wildcards. If the same wildcard is shared, arrange them according
to configuration sequence. For interface-based access control rules, put the rule
configured with “any” behind, and arrange others according to configuration sequence.
For advance access control rules, compare their source address wildcards first. If they
are the same, compare their destination address wildcards. If they are also the same,
compare their ranges of port number. Put those with smaller ranges before others. If the
ranges of port number are still the same, arrange then according to configuration
sequence.
The display acl command can be used to verify which rule takes effect first. Upon the
display, the rule that is listed first takes effect first.
3.1.4 ACL Creation
An ACL is virtually a series of rule lists that consist of permit and deny statements.
Several rule lists constitute an ACL. Before configuring the rule of ACL, you need to
create an ACL first.
The following command can be used to create an ACL:
acl number acl-number [ match-order { config | auto } ]
The following command can be used to delete an ACL:
undo acl { number acl-number | all }
Parameter description:
z number acl-number: Specify an ACL.
z acl-number: Number of ACL. An interface-based ACL takes a value in the range
1000 to 1999, a basic ACL in the range 2000 to 2999, an advanced ACL in the
range 3000 to 3999, and a MAC-based ACL in the range 4000 to 4999.
z match-order config: Specify to match rules according to configuration sequence
of the user.
z match-order auto: Specify to match rules by system automatic sequencing,
namely in “depth priority” sequence.
z all: Delete all configured ACL.
By default, the match order is configuration sequence of the user, namely “config” is in
use. Once the user specifies the match order of a certain ACL, he can never change it,
unless he deletes all the contents in the ACL and specifies its match order again.
ACL view can be entered after an ACL is created. ACL view is classified according to
the application purpose of ACL. For example, advanced ACL view can be entered by
creating an ACL numbered 3000. The following is the firewall prompt:
[H3C-acl-adv-3000]
After entering the ACL view, you can configure ACL rules. The rules of different ACLs
are different. The detailed configuration method of each ACL rule will be introduced
respectively in the following sections.
3-2
3.1.5 Basic ACL
Basic ACL can only adopt source address information to serve as element for defining
ACL rule. A basic ACL can be created and basic ACL view be entered by the
above-mentioned ACL command. In basic ACL view, the rule of basic ACL can be
created.
The following command can be used to define a basic ACL rule:
rule [ rule-id ] { permit | deny } [ source { source-addr source-wildcard | any } ]
[ time-range time-name ] [ logging ] [ fragment ] [ vpn-instance vpn-instance-name ]
z rule-id: Optional parameter, number of ACL rule, ranging from 0 to 65534. After
the number is specified, if the ACL rule related to the number has existed, a newly
defined rule may be used to overwrite the old definition, just as editing an existing
ACL rule. So, it is recommended that when editing an existing ACL rule, the
existed rule should be deleted before defining a new rule; otherwise, the result
may be different from the expected result. If the ACL rule related to the number
does not exist, use the specified number to create a new rule. When the number is
not specified, it indicates to add a new rule. In this case, the system will assign a
number automatically for the ACL rule and add the new rule.
z permit: Permit qualified data packet.
z deny: Discard qualified data packet.
z source: Optional parameter, used to specify source address information of ACL
rule. If it is not specified, it indicates any source address of the packet matches.
z source-addr: Source address of data packet, in dotted decimal.
z source-wildcard: Wildcard of source address, in dotted decimal.
z any: Used to represent all source address. It is same with setting the source
address as 0.0.0.0 and wildcard as 255.255.255.255.
z time-range: Optional parameter, used to specify effective time range of ACL.
z time-name: Name of ACL effective time range.
z logging: Optional parameter, indicating whether to log qualified data packet. The
log content includes sequence number of access control rule, data packet passed
or discarded and the number of data packets. Currently, only packet filter firewalls
support this option (referenced by the firewall packet-filter command on the
interface).
z fragment: Optional parameter, used to specify whether the rule is only valid for
non-first-fragment. When this parameter is included, it indicates the rule is only
valid for non-first-fragment.
z vpn-instance vpn-instance-name: Optional parameter, specifying the
vpn-instance to which the packets belong. If it is not specified, the ACL rule will be
valid for packets in all the vpn-instances. If it is specified, the ACL rule will be valid
only for packets in the specified vpn-instance.
3-3
For existing ACL rule, if edit is performed with specified ACL rule number, the rest part
will not be affected. For example:
First configure an ACL rule:
rule 1 deny source 1.1.1.1 0
Then edit the ACL rule:
rule 1 deny logging
Then, the ACL rule becomes:
rule 1 deny source 1.1.1.1 0 logging
The following command can be used to delete a basic ACL rule:
undo rule rule-id [ source ] [ time-range ] [ logging ] [ fragment ] [ vpn-instance ]
z rule-id: Number of ACL rule, which should be an existing ACL rule number. If there
is no parameter followed, the entire ACL rule will be deleted. Otherwise, only part
of information related to the ACL rule will be deleted.
z source: Optional parameter. Only the source address information setting of ACL
rule with corresponding number will be deleted.
z time-range: Optional parameter. Only the specific effective time range setting of
ACL rule with corresponding number will be deleted.
z logging: Optional parameter. Only the logging qualified packet setting of ACL rule
with corresponding number will be deleted.
z fragment: Optional parameter. Only the validation setting solely for
non-first-fragment of ACL rule with corresponding number will be deleted.
z vpn-instance: Optional parameter. Only the VPN instance setting of ACL rule with
corresponding number will be deleted.
3.1.6 Advanced ACL
Advanced ACL can define rules by using such contents of data packet as source
address information, destination address information, IP carried protocol type and
protocol oriented feature (for example, source port and destination port of TCP, type
and code of ICMP). Advance ACL can be used to define more accurate, diversified and
flexible rules than basic ACL.
An advanced ACL can be created and advanced ACL view be entered by the previously
mentioned ACL command. In advance ACL view, the rules of advanced ACL can be
created.
The following command can be used to define an advanced ACL rule:
rule [ rule-id ] { permit | deny } protocol [ source { source-addr source-wildcard | any } ]
[ destination { dest-addr dest-wildcard | any } ] [ source-port operator port1 [ port2 ] ]
[ destination-port operator port1 [ port2 ] ] [ icmp-type { icmp-message | icmp-type
3-4
icmp-code } ] [ dscp dscp ] [ established ] [ precedence precedence ] [ tos tos ]

[ time-range time-name ] [ logging ] [ fragment ] [ vpn-instance vpn-instance-name ]
z rule-id: Optional parameter, number of ACL rule, ranging from 0 to 65534. After
the number is specified, if the ACL rule related to the number has existed, a newly
defined rule may be used to partly overwrite the old definition, just as editing an
existing ACL rule. So, it is recommended that when editing an existing ACL rule,
the existed rule should be deleted before defining a new rule; otherwise, the result
may be different from the expected result. If the ACL rule related to the number
does not exist, use the specified number to create a new rule. When the number is
not specified, it indicates to add a new rule. In this case, the system will assign a
z protocol: IP carried protocol type represented by name or number. The number
range is from 1 to 255. The name can be gre, icmp, igmp, ip, ipinip, ospf, tcp, and
udp.
z source: Optional parameter, used to specify source address information of ACL
rule. If it is not configured, it indicates any source address of the packet matches.
z source-addr: Source address of data packet, in dotted decimal.
z destination: Optional parameter, used to specify destination address information
of ACL rule. If it is not configured, it indicates any destination address of the packet
matches.
z dest-addr: Destination address of data packet, in dotted decimal.
z dest-wildcard: Destination address wildcard, in dotted decimal.
z any: Used to represent all source or destination addresses. It is same with setting
the source or destination address as 0.0.0.0 and wildcard as 255.255.255.255.
z icmp-type: Optional parameter, used to specify type of ICMP packet and
message code information, only valid when the packet protocol is ICMP. If it is not
configured, it indicates any type of ICMP packet matches.
z icmp-type: ICMP packet can be filtered according to the message type of ICMP. It
is a number ranging from 0 to 255.
z icmp-code: ICMP packet filtered according to ICMP message type can also be
filtered according to message code. It is a number ranging from 0 to 255.
z icmp-message: ICMP packet can be filtered according to name of ICMP type or
name of ICMP code.
z source-port: Optional parameter, used to specify source port information of UDP
or TCP message, only valid when the specified protocol number is TCP or UDP. If
it is not specified, it indicates any source port information of TCP/UDP packet
matches.
z destination-port: Optional parameter, used to specify destination port information
of UDP or TCP packet, only valid when the protocol number specified by the rule is
3-5
TCP or UDP. If it is not specified, it indicates any destination port information of

TCP/UDP packet matches.
z operator: Optional parameter. The port number operator, name and meaning of
source/destination address are compared as follows: lt (lower than), gt (greater
than), eq (equal to), neq (not equal to) and range (between). Only “range” needs
two port numbers as operator, others only need one port number as operator
z port1, port2: Optional parameter, port number of TCP or UDP, represented by
name or number, with the number ranging from 0 to 65535.
z dscp dscp: Specifies a DSCP field (the DS byte in IP packets). This parameter is
mutually exclusive with precedence, tos.
z established: Compares all TCP packets with ACK or RST flags set, including
SYN+ACK, ACK, FIN+ACK, RST and RST+ACK packets. You are recommended
to disable the fast-forwarding function when specifying this argument. Refer to the
Network Layer Protocol part of this manual for details about fast-forwarding.
z precedence: Optional parameter, according to which data packet can be filtered.
It could be a number ranging from 0 to 7 or a name. This parameter is mutually
exclusive with dscp
z tos tos: Optional parameter. Data packet can be filtered according to service type
field. It could be a number ranging from 0 to 15 or a name. This parameter is
mutually exclusive with dscp.
The value of ToS is the four bits (from left to right, the fourth to the seventh bit) in the
ToS field, ranging from 0 to 15 (as shown in the following figure), which actually range
from 0 to 30.
Figure 3-1 ToS parameter in ACL
So, when the ToS value is configured (1 for example) in ACL, the value configured by
ping command using -tos needs to be doubled (which means the value must be 2).
Thus the ToS result configured in ACL can be tested by ping command. The system
logs events only when ACL is used as packet filter.
z logging: Optional parameter, indicating whether to log qualified data packet. The
log contents include sequence number of ACL, data packet permitted/discarded,
upper layer protocol type over IP, source/destination address, source/destination
port number, and the number of data packets. Currently, only packet filter firewalls
interface).
z time-range time-name: The ACL rule is valid in the time range.
3-6
z fragment: Used to specify whether the rule is only valid for non-first-fragment.
When this parameter is included, it indicates the rule is only valid for
non-first-fragment.
z vpn-instance vpn-instance-name: Optional parameter, specifying the
vpn-instance to which the packets belong. If it is not specified, the ACL rule will be
valid for packets in all the vpn-instances. If it is specified, the ACL rule will be valid
only for packets in the specified vpn-instance.
For existing ACL rule, if edit is performed with specified ACL rule number, the rest part
will not be affected. For example:
First configure an ACL rule:
rule 1 deny ip source 1.1.1.1 0
Then edit the ACL rule:

rule 1 deny ip destination 2.2.2.1 0
Then, the ACL rule becomes:

rule 1 deny ip source 1.1.1.1 0 destination 2.2.2.1 0
The following command can be used to delete an advanced ACL rule:

undo rule rule-id [ source ] [ destination ] [ source-port ] [ destination-port ]
[ icmp-type ] [ dscp ] [ precedence ] [ tos ] [ time-range ] [ logging ] [ fragment ]
[ vpn-instance ]
z rule-id: Number of ACL rule, which should be an existing ACL rule number. If there
is no parameter followed, the entire ACL rule will be deleted. Otherwise, only part
of information related to the ACL rule will be deleted.
z source: Optional parameter. Only the source address information setting of ACL
rule with corresponding number will be deleted.
z destination: Optional parameter. Only the destination address information setting
of ACL rule with corresponding number will be deleted.
z source-port: Optional parameter. Only source port information setting of ACL rule
with corresponding number will be deleted. It is only valid when the protocol
number of the rule is TCP or UDP.
z destination-port: Optional parameter. Only the destination port information
setting of ACL rule with corresponding number will be deleted. It is only valid when
the protocol number of the rule is TCP or UDP.
z icmp-type: Optional parameter. Only ICMP type and message code information
setting of ACL rule with corresponding number will be deleted. It is only valid when
the protocol number of the rule is ICMP.
z dscp: Optional parameter. Only the DSCP field setting of ACL rule with
z precedence: Optional parameter. Only the precedence setting of ACL rule with
3-7
z tos: Optional parameter. Only the tos setting of ACL rule with corresponding
number will be deleted.
z time-range: Optional parameter. Only the specific effective time range setting of
ACL rule with corresponding number will be deleted.
z logging: Optional parameter. Only the logging qualified packet setting of ACL rule
with corresponding number will be deleted.
z fragment: Optional parameter. Only the validation setting solely for
non-first-fragment of ACL rule with corresponding number will be deleted.
z vpn-instance: Optional parameter. Only the VPN instance setting of ACL rule with
Only TCP and UDP protocols need to specify port range. The supported operators and
grammar are listed below.
Table 3-1 Operator meaning of advanced ACL
Operator and grammar Meaning

eq portnumber Equal to port number
gt portnumber Greater than port number
lt portnumber Less than port number

neq portnumber Not equal to port number
range portnumber1 portnumber2 Between portnumber1 and portnumber2
When specifying portnumber, part of common port numbers can use mnemonics to
substitute actual numbers. The supported mnemonics are shown in the table below.
3-8
Table 3-2 Port number mnemonics
Protocol Mnemonics Meaning and actual value

Border Gateway Protocol (179)
Bgp
Character generator (19)
Chargen
Remote commands (rcmd, 514)
Cmd
Daytime (13)
Daytime
Discard (9)
Discard
Domain Name Service (53)
Domain
Echo (7)
Echo
Exec (rsh, 512)
Exec
Finger (79)
Finger
File Transfer Protocol (21)
Ftp
FTP data connections (20)
Ftp-data
Gopher (70)
Gopher
NIC hostname server (101)
Hostname
Internet Relay Chat (194)
Irc
Kerberos login (543)
Klogin
Kerberos shell (544)
TCP Kshell
Login (rlogin, 513)
Login
Printer service (515)
Lpd
Network News Transport Protocol
Nntp
(119)
Pop2
Post Office Protocol v2 (109)
Pop3
Post Office Protocol v3 (110)
Smtp
Simple Mail Transport Protocol (25)
Sunrpc
Sun Remote Procedure Call (111)
Syslog
Syslog (514)
Tacacs
TAC Access Control System (49)
Talk
Talk (517)
Telnet
Telnet (23)
Time
Time (37)
Uucp
Unix-to-Unix Copy Program (540)
Whois
Nicname (43)
Www
World Wide Web (HTTP, 80)
3-9
Protocol Mnemonics Meaning and actual value

Mail notify (512)
biff Bootstrap Protocol Client (68)
bootpc Bootstrap Protocol Server (67)
bootps Discard (9)
discard Domain Name Service (53)
dns DNSIX Security Attribute Token Map
dnsix (90)
echo Echo (7)
mobilip-ag MobileIP-Agent (434)
mobilip-mn MobilIP-MN (435)
nameserver Host Name Server (42)
netbios-dgm NETBIOS Datagram Service (138)
netbios-ns NETBIOS Name Service (137)
UDP netbios-ssn NETBIOS Session Service (139)
ntp Network Time Protocol (123)
rip Routing Information Protocol (520)
snmp SNMP (161)
snmptrap SNMPTRAP (162)
sunrpc SUN Remote Procedure Call (111)
syslog Syslog (514)
tacacs-ds TACACS-Database Service (65)
talk Talk (517)
tftp Trivial File Transfer (69)
time Time (37)
who Who(513)
Xdmcp X Display Manager Control Protocol
(177)
For ICMP, ICMP packet type can be specified. The default is all ICMP packets. When
specifying ICMP packet type, it can be a number (ranging from 0 to 255) or a
mnemonic.
3-10
Table 3-3 Mnemonics of ICMP packet type
Mnemonic Meaning
echo Type=8, Code=0
echo-reply Type=0, Code=0
fragmentneed-DFset Type=3, Code=4
host-redirect Type=5, Code=1
host-tos-redirect Type=5, Code=3
host-unreachable Type=3, Code=1
information-reply Type=16,Code=0
information-request Type=15,Code=0
net-redirect Type=5, Code=0
net-tos-redirect Type=5, Code=2
net-unreachable Type=3, Code=0
parameter-problem Type=12,Code=0
port-unreachable Type=3, Code=3
protocol-unreachable Type=3, Code=2
reassembly-timeout Type=11,Code=1
source-quench Type=4, Code=0
source-route-failed Type=3, Code=5
timestamp-reply Type=14,Code=0
timestamp-request Type=13,Code=0
ttl-exceeded Type=11,Code=0
The user can add appropriate access rules by configuring firewall. IP packets passing
the firewall will be checked through packet filtering and the packets that the user does
not want them to pass the firewall will be ruled out. Thus, network security is protected.
3.1.7 Interface-based ACL
Interface-based ACL is a kind of special ACL, which specifies rules according to

packet-receiving interface.
An interface-based ACL can be created and interface-based ACL view be entered by
the previously mentioned ACL command. In interface-based ACL view, the rules of
interface-based ACL can be created.
The following command can be used to define an interface-based ACL rule:
rule [ rule-id ] { permit | deny } interface { interface-type interface-number | any }
[ time-range time-name ] [ logging ]
z rule-id: Optional. ACL rule number, ranging from 0 to 65534. After the number is
specified, if the ACL rule related to the number has existed, a newly defined rule
3-11
may be used to partly overwrite the old definition, just as editing an existing ACL
rule. So, it is recommended that when editing an existing ACL rule, the existed rule
should be deleted before defining a new rule; otherwise, the result may be
different from the expected result. If the ACL rule related to the number does not
exist, use the specified number to create a new rule. When the number is not
specified, it indicates to add a new rule. In this case, the system will assign a
z interface interface-type interface-number: Specifies an interface by specifying the
interface type and number for filtering packets received by the interface. any
represents all interfaces.
z logging: Optional parameter, indicating whether to log qualified packet. Log
contents include sequence number of ACL rule, packet permitted or discarded and
the number of data packets. The system logs events only when ACL is used as
packet filter.
z time-range time-name: Optional, specifies the time range in which the rule is
valid.
The following command can be used to delete an interface-based ACL rule:
undo rule rule-id [ logging ] [ time-range ]
z rule-id: Number of ACL rule, which must be an existing ACL rule number.
z logging: Optional, indicating whether to log matched packets. The log contents
include sequence number of ACL rule, packets passed or discarded, upper layer
protocol type over IP, source/destination address, source/destination port number,
and number of packets. Currently, only packet filter firewalls support this option
(referenced by the firewall packet-filter command on the interface).
z time-range: Optional, specifies the time range in which the rule is valid.
3.1.8 MAC-Based ACL
MAC-based ACLs are numbered in the range 4000 to 4999.

You can use the following command to configure a MAC-based ACL rule:
rule [ rule-id ] { deny | permit } [ type type-code type-mask | lsap lsap-code lsap-mask ]
[ source-mac sour-addr sour-mask ] [ dest-mac dest-addr dest-mask ] [ time-range
time-name ] [ logging ]
The parameters are described as follows:
rule-id represents a rule number.
type-code is a hexadecimal number in the format of xxxx, used for matching the
protocol type of the transmitted packets.
3-12
type-mask represents the protocol type wildcard. For type-code values, refer to the
chapter that discusses bridge configuration in the link layer protocol part of this manual.
lsap-code is a hexadecimal number in the format of xxxx, used for matching the
encapsulation format of bridged packet on an interface. lsap-wildcard represents the
wildcard of protocol type.
sour-addr represents the source MAC address of a data frame in the format of
xxxx-xxxx-xxxx. sour-mask represents the wildcard of the source MAC address.
dest-addr represents the destination MAC address in the format of xxxx-xxxx-xxxx.
dest-mask represents the wildcard of the destination MAC address.
time-range time-name is used to configure a time range within which an ACL rule takes
effect.
logging indicates whether to log qualified packet, an optional parameter. The system
logs events only when ACL is used as packet filter. Currently, only packet filter firewalls
interface).
The following command can be used to delete a MAC-based ACL rule:
undo rule rule-id [ time-range time-name ] [ logging ]
The parameters are described as follows:
rule-id: ACL rule number, which must exist already.
3.1.9 ACL Supporting Fragment
Traditional packet filter does not process all IP packet fragments. Rather, it only
performs matching processing on the first fragment and releases all the follow-up
fragments. Thus, security dormant trouble exists, which makes attackers able to
construct follow-up segments to realize traffic attack.
Packet filter of SecPath firewall provides fragment filtering function, including:
performing Layer 3 (IP Layer) matching filtering on all fragments; at the same time,
providing two kinds of matching, normal matching and exact matching, for ACL rule
entries containing advanced information (such as TCP/UDP port number and ICMP
type). Normal matching is the matching of Layer 3 information and it omits non-Layer 3
information. Exact matching matches all ACL entries, which requires firewall should
record the state of first fragment so as to obtain complete matching information of
follow-up fragments. The default function mode is normal matching.
The keyword fragment is used in the configuration entry of ACL rule to identify that the
ACL rule is only valid for non-first fragments. For non-fragments and first fragment, this
rule is omitted. In contrast, the configuration rule entry not containing this keyword is
valid for all packets.
For example:
[H3C-acl-basic-2000] rule deny source 202.101.1.0 0.0.0.255 fragment
3-13

[H3C-acl-adv-3001] rule permit ip destination 171.16.23.1 0 fragment
[H3C-acl-adv-3001] rule deny ip destination 171.16.23.2 0
In above rule entries, all entries are valid for non-first fragments. The first and the third
entries are omitted for non-fragments and first fragment, only valid for non-first
fragments.
3.2 Configuring an ACL

ACL configuration includes:
z Configure a basic ACL
z Configure an advanced ACL
z Configure an interface-based ACL
z Configure a MAC-based ACL
z Add description to an ACL
z Add comment to an ACL rule
z Delete an ACL
z Enable/disable the ACL counters
3.2.1 Configuring a Basic ACL
Perform the following configuration.
Table 3-4 Configure a basic ACL
Operation Command
Create a basic ACL in acl number acl-number [ match-order { config |
system view. auto } ]
rule [ rule-id ] { permit | deny } [ source source-addr
source-wildcard | any ] [ time-range time-name ]
Configure/delete an ACL [ logging ] [ fragment ] [ vpn-instance
rule in basic ACL view. vpn-instance-name ]
undo rule rule-id [ source ] [ time-range ] [ logging ]
[ fragment ] [ vpn-instance ]
For detailed introduction to parameters, refer to basic ACL.
3.2.2 Configuring an Advanced ACL
3-14
Table 3-5 Configure an advanced ACL
Operation Command
Create an
advanced ACL in acl number acl-number [ match-order { config | auto } ]
system view.
rule [ rule-id ] { permit | deny } protocol [ { source
source-addr source-wildcard | any } ] [ destination
{ dest-addr dest-wildcard | any } ] [ sourer-port operator
port1 [ port2 ] ] [ destination-port operator port1 [ port2 ] ]
Configure/delete [ icmp-type {icmp-type icmp-code| icmp-message}] [ dscp
an ACL rule in dscp ] [ established ] [ precedence precedence ] [ tos tos ]
advanced ACL [ time-range time-name ] [ logging ] [ fragment ]
view. [ vpn-instance vpn-instance-name ]
undo rule rule-id [ source ] [ destination ] [ source-port ]
[ destination-port ] [ icmp-type ] [ dscp ] [ precedence ]
[ tos ] [ time-range ] [ logging ] [ fragment ] [ vpn-instance ]
3.2.3 Configuring an Interface-based ACL
Table 3-6 Configure an interface-based ACL
Operation Command
Create an interface-based ACL acl number acl-number [ match-order { config
in system view. | auto } ]
rule { permit | deny } interface { interface-type

Configure/delete an ACL rule in interface-number | any } [ time-range
interface-based ACL view. time-name ] [ logging ]
undo rule rule-id [ time-range | logging ]*
You can specify an interface by specifying its type and number for filtering packets
received by this interface. The keyword any represents all interfaces.
3.2.4 Configuring a MAC-Based ACL
Table 3-7 Configure a MAC-based ACL
Operation Command
Create a MAC-based
acl number acl-number
ACL in system view.
3-15
Operation Command
rule [ rule-id ] { deny | permit } [ type type-code
Configure/delete an type-mask | lsap lsap-code lsap-mask ] [ source-mac
ACL rule in sour-addr sour-wildcard ] [ dest-mac dest-addr
MAC-based ACL view. dest-mask ] [ time-range time-name ] [ logging ]
undo rule rule-id [ time-range ] [ logging ]
3.2.5 Adding Description to an ACL
You can add description to an ACL for reminding purpose.

Perform the following configuration in ACL view.
Table 3-8 Add description to an ACL
Operation Command
Add description to an ACL. description text
Remove the description. undo description
An ACL description contains up to 127 characters.
3.2.6 Adding Comment to an ACL Rule
You can add comment to an ACL rule for reminding purpose.

Perform the following configuration in ACL view.
Table 3-9 Add comment to an ACL rule
Operation Command
Add comment to an ACL rule. rule rule-id comment text
Remove the comment of an ACL rule. undo rule rule-id comment
The Comment of an ACL rule contains up to 127 characters.
3.2.7 Deleting an ACL
3-16
Table 3-10 Delete an ACL
Operation Command
Delete ACL undo acl { number acl-number | all }
3.2.8 Enabling/Disabling the ACL Counters
Table 3-11 Enable/disable the ACL counters
Operation Command
Enable the ACL counters acl counter enable
Disable the ACL counters acl counter disable
By default, the ACL counters are enabled.
3.3 Configuring Time Range

Time range configuration includes:
z Create a time range
3.3.1 Creating/Deleting a Time Range
The configuration task is used to create a time range or many time ranges with the
same name.
Table 3-12 Configure time range
Operation Command
time-range time-name { start-time to end-time
days-of-the-week [ from start-time start-date ] [ to
Create a time range
end-time end-date ] | from start-time start-date [ to
end-time end-date ] | to end-time end-date }
undo time-range time-name [ start-time to end-time
Delete a time range.
end-time end-date ] | to end-time end-date ]
3-17
3.4 Displaying and Debugging ACL

running of the ACL configuration, and to verify the effect of the configuration. Execute
the reset command in user view to reset ACL counters.
Table 3-13 Display and debug ACL
Operation Command
Display the configured ACL rules. display acl { all | acl-number }
Display information on time ranges. display time-range { all | time-name }
Reset ACL counters. reset acl counter { all | acl-number }
3.5 Typical Configuration Examples of ACL

Refer to the typical configuration examples in the part about packet filter.
3-18
H3C SecPath Series Security Products Chapter 4 NAT Configuration
Chapter 4 NAT Configuration
4.1 NAT Overview

As described in RFC 1631, Network Address Translation (NAT) is to translate the IP
address in IP data packet header into another IP address, which is mainly used to
implement private network accessing external network in practice. NAT can reduce the
depletion speed of IP address space via using several public IP addresses to represent
multiple private IP addresses.
Note:
Private address denotes the address of network or host on intranet, whereas public
address denotes the universal unique IP address on Internet.
IP addresses that RFC 1918 reserves for private and private use are.
Class A: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8)
Class B: 172.16.0.0 to 172.31.255.255 (172.16.0.0/12)
Class C: 192.168.0.0 to 192.168.255.255 (192.168.0.0/16)
IP addresses in the above three ranges will not be assigned in the Internet, so they can
be used in the intranet by a company or enterprise with no need for requesting ISP or
register center.
A basic NAT application is shown in the following figure.
202.120.10.2
Data packet 1: Data packet 1:
192.168.1.3
Source: 192.168.1.3 Source: 202.169.10.1 Server
PC Destination: 202.120.10.2 Destination:2 02.120.10.2
192.168.1.1 202.169.10.1
Internet
202.120.10.3
Server Data packet 2: Data packet 2: PC

Source: 202.120.10.2 Source: 202.120.10.2
192.168.1.2 Destination:192.168.1.3 Destination: 202.169.10.1
Figure 4-1 Network diagram for basic processes of address translation
4-1
NAT server such as the firewall is located at the joint between private network and
public network. When the internal PC at 192.168.1.3 sends the data packet1 to the
external server at 202.120.10.2, the data packet will traverse the NAT server. The NAT
server checks the contents in the packet header. If the destination address in the
header is an extranet address, the server will translate the source address 192.168.1.3
into a valid public address on the Internet 202.169.10.1, then forward the packet to the
external server and record the mapping in the network address translation list. The
external server sends the response packet2 (The destination is 202.169.10.1) to the
NAT server. After inquiring the network address translation list, the NAT server replaces
the destination address in packet2 header with the original private address 192.168.1.3
of the internal PC.
The above mentioned NAT process is transparent for terminals such as the PC and
server in the above figure. NAT “hides” the private network of an enterprise because the
external server regards 202.169.10.1 as the IP address of the internal PC without the
awareness of the existence of 192.168.1.3.
The main benefit NAT offers is the easy access to the outside resources for the intranet
hosts while maintaining the privacy of the inner hosts.
z Since it is necessary to translate the IP address translation of data packets, the
header of the data packet related to IP address cannot be encrypted. For example,
encrypted FTP connection is forbidden to be used. Otherwise, FTP port cannot be
correctly translated.
z Network debugging becomes more difficult. For instance, while a certain internal
network host attempts to attack other networks, it is hard to point out which
computer is malicious, for the host IP address is shielded.
z NAT has little impact on the performance of the network for the 10Mbit/s
bandwidth links, for the bottleneck is the data transfer circuit. When the baud rate
is over 10Mbits/s, NAT will cause some certain effects upon the performance of
the firewall.
4.2 Functions Provided by NAT

4.2.1 Many-to-Many Address Translation and Address Translation Control
Based on the Figure 4-1, the source address of the intranet will be translated into an
appropriate extranet address (the public address of the outbound interface on the NAT
server in the above figure) via NAT. In this way, all the hosts in the intranet share one
extranet address when they access the external network. In other words, only one host
can access the external network at a time when there are many access requirements,
which is called “one-to-one address translation”.
An extended NAT implements the concurrent access, that is, multiple public IP
addresses are assigned to a NAT server. The NAT server assigns a public address IP1
to a requesting host, keeps a record in the address translation list and forwards the data
4-2
packet, then assigns another public address IP2 to another request host and so on.
This is called “many-to-many address translation”.
Note:
The number of public IP addresses on the NAT server is far less than the number of
hosts in the intranet because not all hosts will access the extranet at one time. The
public IP address number is determined based on the maximum number of intranet
hosts at the rush hour of the network.
In practice, it may be required that only some intranet hosts can access the Internet
(external network). In other words, the NAT server will not translate source IP
addresses of those unauthorized hosts, which is called address translation control.
The firewall implements many-to-many address translation and address translation
control via address pool and ACL respectively.
z Address pool: A set of public IP addresses for address translation. A client should
configure an appropriate address pool according to its valid IP address number,
internal host number as well as the actual condition. An address will be selected
from the pool as the source address during the translation process.
z ACL-based address translation: Only the data packet matching the ACL rule can
be translated, which effectively limits the address translation range and allows
some specific hosts to access Internet.
4.2.2 NAPT
There is another way to implement the concurrent access, that is, Network Address
Port Translation (NAPT), which allows the map from multiple internal addresses to an
identical public address. Therefore, it can be called as “many-to-one address
translation” or address multiplex informally.
NAPT maps IP addresses and port numbers of data packets form various internal
addresses to an identical public address with different port numbers. In this way,
different internal addresses can share an identical public address.
The fundamentals of NAPT are shown in the following figure.
4-3

Source IP:192.168.1.3 Source IP: 202.169.10.1
Source port: 1537 Source port: 3001 202.120.10.2
192.168.1.3 Data packet 2: Data packet 2:
Source IP:192.168.1.3 Source IP:202.169.10.1 Serv er
PC Source port: 2468 Source port: 3002
192.168.1.1 202.169.10.1
Internet
202.120.10.3

Serv er
Source IP:192.168.1.2 Source IP:202.169.10.1 PC
Source port: 1111 Source port: 3003
192.168.1.2
Source IP:192.168.1.1 Source IP: 202.169.10.1
Source port: 1111 Source port: 3004
Figure 4-2 NAPT allowing multiple internal hosts to share a public address
As shown in the above figure, four data packets from internal addresses arrive at the
NAT server. Among them, packet1 and packet2 come from the same internal address
with different source port number, pakcet3 and packet4 come from different internal
addresses with an identical source port number. After the NAT mapping, all the 4
packets are translated into an identical public address with different source port
numbers, so they are still different from each other. As for the response packets, the
NAT server can also differentiate these packets based on their destination addresses
and port numbers and forward the response packets to the corresponding internal
hosts.
4.2.3 Static Network Segment Address Translation
This static network segment address translation function converts the internal host
addresses in a specified range to the specified public network addresses (only the
network part is converted and the host part is unchanged). When internal hosts access
the outside network, their internal addresses are converted to public network
addresses if their internal addresses are in the specified range. Accordingly, outside
hosts can use the public network address to access directly internal hosts if the internal
host addresses which are converted from the public network addresses are in the
specified range.
Static network segment address translation function creates direct mapping between
internal host addresses and public network addresses, and implement the function
similar to NAT server.
However, static network segment address translation function requires a large IP
address space because it holds the one-to-one mapping between internal host
addresses and public network addresses. In this scenario, you can combine this
4-4
function with the traditional static or dynamic NAT function, as long as the addresses
are not in conflict.
4.2.4 Bidirectional Network Address Translation
Traditional NAT function converts only the packet source or destination address, but
directional NAT function converts both. This function is used in the case where internal
host addresses and public network addresses overlap. As shown in Figure 4-3, the
addresses of the internal host PC1 and the host PC3 on the public network overlap.
Then if the internal host PC1 or PC2 sends a packet to PC3, the packet will not be
forwarded to PC3, but by mistake to PC1. Bidirectional NAT function can guarantee
correct packet forwarding by configuring the mapping from overlap address pool to
temporary address pool on SecPath A (traditional NAT function is also implemented) to
convert the overlap address to a unique temporary address.
PC1
10.0.0.1/24
PC3
SecPathA Intranet
www.web.com
PC2 10.0.0.1/24
10.1.1.1/24
DNS Server
Figure 4-3 Bidirectional NAT implementation
For example, to configure bidirectional NAT function on SecPath A, you can:

Step 1: Configure traditional NAT (many-to-many address conversion).
Configure the NAT address pool containing 200.0.0.1 to 200.0.0.100, and assign it to
the WAN interface.
Step 2: Configure the mapping between a group of overlap and temporary addresses.
10.0.0.0 ←→ 3.0.0.0, with 24-bit subnet mask.
One overlap address pool corresponds to one temporary address pool. The conversion
rule is as follows:
Temporary address = Start address of the temporary address pool + (overlap address −
start address of the overlap address pool)
Overlap address = Start address of the overlap address pool + (temporary address −
start address of the temporary address pool)
When PC2 accesses PC3 with the domain name, packets are processed as follows:
1) PC2 sends a DNS request for resolving www.web.com; the DNS server on the
public network resolves the address; SecPath A receives the response packet
4-5
from the DNS server. SecPath A checks the address 10.0.0.1 resolved from the
response packet, and finds it is an overlap address, so it converts the overlap
address to the 3.0.0.1 temporary address. SecPath A converts the destination
address of the DNS response packet (traditional DNS processing) and sends the
DNS response packet to PC2.
2) PC2 originates an access request with the temporary address 3.0.0.1, which
corresponds to www.web.com. Upon receiving the packet, SecPath A first
converts the source address of the packet (traditional DNS processing), and then
converts the destination address (or temporary address) to the 10.0.0.1 overlap
address.
3) SecPath A sends the packet to its outgoing WAN interface, and the packet is
forwarded over the WAN hop by hop to PC3.
4) When receiving the packet returned from PC3 to PC2, SecPath A checks the
10.0.0.1 source address, and finds it is an overlap address (listed in the overlap
address pool), so it converts the overlap address to the 3.0.0.1 temporary address.
SecPath A converts the destination address of the returned packet (traditional
DNS processing) and sends the packet to PC2.
4.2.5 Internal Server
NAT can “shield” internal hosts via hiding the architecture of the intranet. However,
there always the times that you want to permit some hosts on external networks to
access some hosts on the intranet, such as a WWW server or a FTP server. You can
flexibly add servers on the intranet via NAT, for example, you can use 202.169.10.10 as
the external address of the WWW server and 202.110.10.11 as the external address of
the FTP server. Even 202.110.10.12:8080 can be used as the external address of the
WWW server. Moreover, NAT can provide multiple identical servers such as WWW
servers for external clients.
The NAT function on the firewall provides some servers on the intranet for some hosts
on external networks. When a client on an external network accesses a server on the
intranet, the NAT device translates the destination address in the request packet into a
private address on the internal server and translates the source address (a private
address) in the response packet into a public address.
4.2.6 Easy IP
Easy IP is to use the public IP address of an interface as the source address after the
address translation. It also controls the address translation based on ACL.
4.2.7 NAT Application Level Gateway
NAT may cause anomaly to many NAT-sensitive protocols, so you must make special
processing to them. Some packets for NAT-sensitive protocols carry IP addresses or
4-6
port numbers in their payload, and lack of special processing will affect the subsequent
protocol exchange.
NAT application level gateway (ALG), a common solution to special protocol traversal,
replaces the IP addresses and port numbers in payload based on NAT rules, and
achieves transparent protocol relay. Currently, NAT ALG supports PPTP, DNS, FTP,
ILS, NBT, H.323 and other protocols.
4.2.8 NAT Maximum TCP Connections Limit Function
However, NAT also has problems. For example, in a LAN, a PC containing virus
initiates large numbers of TCP connections, which causes rapid resource consumption
and device performance deterioration, and thus affects other users. This case can be
avoided by limiting the number of TCP connections.
By setting the upper limit for specified TCP connections, you can limit the maximum
number of TCP connections by using NAT.
You can configure to limit different kinds of connections. The configuration policy is
consisted of the following two aspects:
I. What kind of feature is to be matched for the packets to be limited
You can specify the feature of packets flexibly by ACL according to your requirements,
such as source address-based packets, destination address-based packets, and
service-based packets.
II. How to limit the connections that match the specified feature
You can specify the upper and lower threshold values to control the setup of the
connection. When the number of connections that match a specified feature reaches
the upper limit, these connections will be refused to set up; when the number of
connections reaches or is below the lower limit, these connections will be permitted to
set up.
4.2.9 Multi-Instance of NAT Supported
NAT multi-instance function offers a solution that allows not only the MPLS VPN users
to access the Internet through a single gateway, but also the users from different VPNs
to use the same private address. When an MPLS VPN user wants to access the
Internet, NAT translates the IP address and the port of the internal host into external IP
address and port of the firewall and records the MPLS VPN information (such as
protocol type and route identifier RD) about the user. When the packet is sent back,
NAT restores the external IP address and port to the IP address and port of the internal
host, and recognizes the MPLS VPN user. No matter what kind of NAT it is, PAT or
NO-PAT, multi-instance will be supported.
4-7
Comware NAT supports the multi-instance of internal server, and provides the outside
network with the access to the hosts within MPLS VPN. For example, the WWW server
in VPN1 uses the address of 10.110.1.1 as the inner address, on the other hand, uses
the address of 202.110.10.20 as the outer address. Using the outer address
(202.110.10.20), the Internet users can access the WWW service provided by MPLS
VPN1.
4.3 NAT Configuration

NAT configuration includes:
z Configure address pool.
z Configure Easy IP
z Configure static NAT
z Configure many-to-many NAT
z Configure NAPT
z Configure internal server support
z Configure NAT application layer gateway
z Configure domain name mapping
z Configure NAT effective time
z Configure NAT maximum TCP connection limit
z Set the packet matching mode
z Set the NAT entry refresh speed
4.3.1 Configuring Address Pool
The address pool is a collection of some consecutive IP addresses, while internal data
packet needs to access external network via NAT, a certain address in the address pool
will be chosen as the source address. Perform the following configuration in system
view.
Table 4-1 Configure address pool
Operation Command
Define an address pool nat address-group group-number start-addr end-addr
Delete an address pool undo nat address-group group-number
4-8
Note:
z To avoid address conflict, an address pool should not contain the IP addresses
used by the hosts in public networks.
z If Easy IP is the one and only function supported by the firewall, the address of the
interface will be used plainly as the translated IP address.
z No NAT pool is needed. An address pool is irremovable while this address pool has
set up the association with a certain access control list for NAT.
z A NAT address pool contains up to 255 IP addresses.
4.3.2 Configuring NAT
The NAT is accomplished by associating address pool with ACL. The association
creates a relationship between such IP packets, characterized in the ACL, and that
addresses, defined in the address pool. When a packet is transferred from inner
network to outer network, first, the packet is filtered by the ACL to let it out, then the
association between the ACL and address pool is used to find an address, which will
later serve actually as the translated address.
The configuration of ACL is discussed in Chapter 3 “ACL Configuration”.
The configuration varies by different NAT types, such as one-to-one, many-to-one, and
many-to-many.
I. Easy IP
The NAT command without the address-group parameter functions as the nat
outbound acl-number command, implementing the "easy-ip" feature. When
performing address translation, the IP address of the interface is used as the translated
address and the ACL can be used to control which addresses can be translated.
Table 4-2 Configure Easy IP
Operation Command
Add association for access control list
nat outbound acl-number
and address pool
Delete association for access control list
undo nat outbound acl-number
and address pool
II. Associating ACL with Loopback interface address
4-9
Table 4-3 Associate ACL with loopback interface address
Operation Command
Associate the ACL with the specified nat outbound acl-number interface
loopback interface address interface-type interface-number
undo nat outbound acl-number
Remove the association between the
ACL and loopback interface address
interface-number
The source address of the data packets that match the ACL will be replaced with the IP
specified address of the loopback interface.
III. Configuring static NAT table
1) Configuring static one-to-one NAT table

Table 4-4 Configure a one-to-one private-to-public address binding
Operation Command
Configure a one-to-one private-to-public
nat static ip-addr1 ip-addr2
address binding.
Delete an existing one-to-one
undo nat static ip-addr1 ip-addr2
private-to-public address binding.
2) Configuring static net-to-net NAT table

Static NAT function only converts the network addresses and remains the host
addresses unchanged.
Table 4-5 Configure static net-to-net NAT table
Operation Command
nat static inside ip inside-address global ip
Configure a static global-address
net-to-net NAT table nat static inside ip inside-start-address
inside-end-address global ip global-address mask
undo nat static inside ip inside-address
Remove the existing undo nat static inside ip inside-address global ip
static net-to-net NAT global-address
table undo nat static inside ip inside-start-address
inside-end-address [ global ip global-address mask ]
4-10
The nat static inside and nat static commands create two different types of static NAT
entries. Note that the two types cannot be in conflict.
Caution:
When configuring static NAT, please make sure that the address obtained after
translation cannot be used by other devices in the network topology.
3) Enabling the static NAT table on the interface

Table 4-6 Enable the static NAT table on the interface
Operation Command
Enabling the configured NAT table on the
nat outbound static
interface.
Disabling the configured NAT table on the
undo nat outbound static
interface.
IV. Configuring many-to-many NAT
The many-to-many NAT is accomplished by associating the ACL with the NAT pool.
Table 4-7 Configure many-to-many NAT
Operation Command
Add association for access nat outbound acl-number [ address-group
control list and address pool group-number [ no-pat ]
Delete association for access undo nat outbound acl-number
control list and address pool [ address-group group-number [ no-pat ]
V. Configuring NAPT
While associating the ACL and NAT pool, the selected no-pat parameter denotes that
only the IP address but the port information is translated, i.e. not using NAPT function;
whereas the omit of the no-pat parameter denotes using the NAPT function.
By default, the NAPT function is active.
4-11
Table 4-8 Configure NAPT
Operation Command
Add association for access control list nat outbound acl-number
and address pool [ address-group group-number ]
Delete association for access control list undo nat outbound acl-number
and address pool [ address-group group-number ]
VI. Configure Bidirectional NAT Table
Table 4-9 Configure bidirectional NAT table
Operation Command
nat overlapaddress number
Configure the mapping from the overlap
overlappool-startaddress
address pool to the temporary address
temppool-startaddress { pool-length
pool
pool-length | address-mask mask }
Remove the mapping from the overlap
address pool to the temporary address undo nat overlapaddress number
pool
VII. Configuring NAT Multi-instance
Easy IP, many-to-many NAT and NAPT whatsoever all support the configuration of NAT
multi-instance. And all the works to be done to support MPLS VPN is to add
vpn–instance vpn-instance-name option into the rule command in ACL view to show
clearly which MPLS VPN user needs translation.
4.3.3 Configuring Internal Server
By configuring internal server, the related external address and port can be mapped
into the internal server, thus enabling the function of external network accessing the
internal server.
The mapping table for internal server and external network is configured by the nat
server command.
The information user needs to provide includes external address, external port, internal
server address, internal server port and the protocol type of the service.
The firewall supports using interface address as the public address of NAT server.
When the public interface of firewall obtains public address by dialing-up or using
DHCP, the public address of NAT server can be updated dynamically for user’s
convenience to perform configurations.
4-12
If the internal server belongs to an MPLS VPN, it is necessary to specify the

vpn-instance-name. Otherwise the internal server will be regarded to be in an ordinary
VPN rather than a MPLS VPN.
Table 4-10 Configure internal server
Operation Command
nat server [ vpn-instance vpn-instance-name ] protocol
pro-type global { global-addr | current-interface | interface
type number } [ global-port ] inside host-addr [ host-port ]
Add an internal
server nat server [ vpn-instance vpn-instance-name ] protocol
pro-type global { global-addr | current-interface | interface
type number } global-port1 global-port2 inside host-addr1
host-addr2 host-port
undo nat server [ vpn-instance vpn-instance-name ]
protocol pro-type global { global-addr | current-interface |
interface type number } [ global-port ] inside host-addr
Delete an internal [ host-port ]
server undo nat server [ vpn-instance vpn-instance-name ]
protocol pro-type global { global-addr | current-interface |
interface type number } global-port1 global-port2 inside
host-addr1 host-addr2 host-port
Note:
z While either one of the global-port and inside-port being defined as “any”, the other
one must either be defined as “any” or not be defined, that is, one of the ports
defined as “any” implies that both of them are “any”.
z If the value of both global-port and inside-port is set to zero, “any” or not neither is
configured, an internal server can access the public network, provided that the
protocol that initiates the access should be the same as the one already configured.
z When using port range to configure NAT server function on the security gateway for
accessing the FTP server, you cannot configure the internal port number to 20 and
21; if you do not use port range to perform the configuration, the internal port
number cannot be configured to 20.
z TFTP protocol is special, so when you configure NAT server function for accessing
the TFTP server, you also need to configure the nat outbound command for the
internal TFTP server.
4-13
4.3.4 Enabling NAT ALG
Table 4-11 Enable NAT ALG
Operation Command
Enable NAT ALG (application level nat alg { dns | ftp | h323 | ils | msn | nbt
gateway) | pptp | tns }
undo nat alg { dns | ftp | h323 | ils |
Disable NAT ALG
msn | nbt | pptp | tns }
By default, NAT ALG is enabled.
4.3.5 Configuring Domain Name Mapping
Given an internal network where no DNS server is present, you may configure NAT
entries for domain names to allow internal hosts to identify and access internal servers
(such as FTP and WWW) by domain name.
Table 4-12 Configure domain name mapping
Operation Command
Configure a mapping entry from a
nat dns-map domain-name global-addr
domain name to the external IP address,
global-port [ tcp | udp ]
port number and protocol type
Remove the domain name mapping
undo nat dns-map domain-name
entry
Up to 64 domain name mapping entries can be defined.
4.3.6 Configuring Address Translation Lifetimes
Since the Hash table used by NAT will not exist forever, the user can configure the
lifetime of the Hash table for protocols such as TCP, UDP and ICMP respectively. If the
Hash table is not used in the set time, the connection as well as the table it uses will be
outdated.
For example, the user with the IP address 10.110.10.10 sets up an external TCP
connection using port 2000, and NAT assigned corresponding address and port for it,
but in a defined time, this TCP connection is not in use, the system will delete this
connection.
4-14
Table 4-13 Configure address translation lifetime values
Operation Command
nat aging-time { default | { dns |
Configure address translation lifetime
ftp-ctrl | ftp-data | icmp | pptp | tcp |
values.
tcp-fin | tcp-syn | udp } seconds }
If the nat aging-time default command is configured, the default address translation
lifetime values of the system apply.
Following are the default address translation lifetime values for different protocols:
z DNS: 60 seconds
z FTP control link: 7200 seconds
z FTP data link: 300 seconds
z PPTP: 86400 seconds
z TCP: 86400 seconds
z TCP FIN, RST or SYN connection: 60 seconds
z UDP: 300 seconds
z ICMP: 60 seconds
The default ALG aging time depends on the specific applications. To effectively prevent
attacks, you can set the aging time of first packet to five seconds.
4.3.7 Configuring NAT Maximum TCP Connections Limit Function
I. Enabling connection limit function
Table 4-14 Enable connection limit function
Operation Command
Enable connection limit function connection-limit enable
Disable connection limit function undo connection-limit enable
By default, the connection limit function is disabled.
II. Setting default connection limit action
When no connection limit policy is found, you can set the default action, whether or not
to limit connections.
4-15
Table 4-15 Set the default connection limit action
Operation Command
connection-limit default { permit |
Set the default connection limit action
deny }
By default, if no connection limit policy is found, the system does not limit connections.
III. Setting default threshold for the number of connections
Table 4-16 Set the default threshold for the number of connections
Operation Command
connection-limit default amount
Set the default threshold for the number
{ upper-limit upper-limit | lower-limit
of connections
lower-limit }*
undo connection-limit default
Cancel the set threshold
amount { upper-limit | lower-limit }*
By default, the upper limit is 50 and the lower limit is 20.
IV. Creating connection limit policy
Table 4-17 Create connection limit policy
Operation Command
Create connection limit policy and enter
connection-limit policy policy-number
policy view
undo connection-limit policy

Delete the connection limit policy
{ policy-number | all }
V. Defining connection limit policy rule
Perform the following configuration in connection limit policy view.
Table 4-18 Define connection limit policy rule
Operation Command
limit limit-id acl acl-number [ { per-source |
Define connection limit policy
per-destination | per-service }* amount
rule
upper-limit lower-limit ]
4-16
Operation Command
Delete the connection limit
undo limit limit-id
policy rule
By default, no connection limit policy rule is defined.
Note:
z By defining ACL, you can limit not only TCP connections, but also non-TCP
connections (such as UDP, ICMP connections). You need to specify in the ACL if
you want to limit TCP connections only.
z Set the upper and lower limit of TCP connections according to practical
requirements; otherwise normal service may be affected.
VI. Binding connection limit policy
After configuring the connection limit policy, you need to bind it to NAT in order to make
it take effect.
Table 4-19 Bind connection limit policy
Operation Command
Bind connection limit policy nat connection-limit-policy policy-number
Cancel the binding of undo nat connection-limit-policy
connection limit policy policy-number
By default, no connection limit policy is bound.
4.3.8 Setting the Packet Matching Mode
You can use the following commands to change the packet matching mode.
Table 4-20 Set the packet matching mode
Operation Command
Set the packet matching mode to quintuple matching nat match factor-all
undo nat match
Set the packet matching mode to triple matching
factor-all
4-17
By default, the packet matching mode of quintuple matching is used.

In triple matching mode, an established NAT entry for UDP includes neither the
destination address nor the destination port number.
4.3.9 Setting NAT Entry Refresh Speed
You can use the following commands to change the NAT entry refresh speed.
Table 4-21 Set the NAT entry refresh speed
Operation Command
nat session refresh-speed level
Set the NAT entry refresh speed
level-value
Restore the default NAT entry refresh
undo nat session refresh-speed
speed
The level-value argument refers to the NAT entry refresh speed level, in the range 1 to
5. The greater the level value, the higher the refresh speed.
By default, the refresh speed level is 2 for the SecPath F1000, 3 for the SecBlade, and
1 for other SecPath security gateway devices.
4.4 Displaying and Debugging NAT

running of the NAT configuration, and to verify the effect of the configuration.
Use the reset command in user views to clear the running.
Use the debugging command in user view for the debugging of NAT.
Table 4-22 Display and debug NAT
Operation Command
display nat { address-group | aging-time | all |
outbound | server | statistics | static | session
Check NAT status
[ vpn-instance vpn-instance-name ] [ source { global
global-addr | inside inside-addr } ] }
display connection-limit statistics [ source
source-addr { source-mask | source-mask-len } ]
Display connection limit [ destination destination-addr { destination-mask |
statistics destination-mask-len } ] [ destination-port { { eq | neq
| gt | lt } destination-port | range destination-port1
destination-port2 } ] [ vpn-instance vpn-name ]
Display connection limit display connection-limit policy { policy-number |
policy all }
4-18
Operation Command
display nat connection-limit [ source source-addr
{ source-mask | source-mask-len } ] [ destination
Display connection limit
destination-addr { destination-mask |
information related with
destination-mask-len } ] [ destination-port { { eq | neq
NAT
| gt | lt } destination-port | range destination-port1
destination-port2 } ] [ vpn-instance vpn-name ]
Enable the debugging of debugging nat { alg | event | packet [ interface
NAT { interface-type interface-number ] }
Disable the debugging of undo debugging nat { alg | event | packet
NAT [ interface interface-type interface-number ] }
Enable the debugging of
debugging connection-limit
connection limit
Disable the debugging of
undo debugging connection-limit
connection limit
Clear NAT mapping table reset nat{ log-entry | session slot slot-number }
4.5 NAT Configuration Examples

4.5.1 Typical NAT Configuration
An enterprise is connected to WAN by the address translation function of the firewall. It

is required that the enterprise can access the Internet via serial 3/0/0 of the firewall, and
provide WWW, FTP and SMTP services to the outside, as well as two WWW servers.
The internal network address of the enterprise is 10.110.0.0/16.
The internal FTP server address is 10.110.10.1. The internal WWW server1 address is
10.110.10.2. The internal WWW server 2 address is 10.110.10.3. The internal SMTP
server address is 10.110.10.4. It is expected to provide uniform server IP address to the
outside. Internal network segment 10.110.10.0/24 may access Internet, but PC on
other segments cannot access Internet. External PC may access internal server. The
enterprise has six legal IP addresses from 202.38.160.100 to 202.38.160.105.
Choose 202.38.160.100 to be the external IP address of the enterprise, and WWW
server2 uses 8080 port to the outside.
4-19
II. Network diagram
10.110.10.1 10.110.10.2 10.110.10.3 10.110.10.4
FTP server WWWserver1 WWW server2 SMTP server
Internal Ethernet
10.110.10.100 of enterprise 10.110.12.100
Internal PC Internal PC
SecPath
Internet
External PC
Figure 4-4 Network diagram for NAT configuration
# Configure address pool and access control list and allow address translation of
segment at 10.110.10.0/24.
[H3C] nat address-group 1 202.38.160.101 202.38.160.105
[H3C-Ethernet3/0/0] nat outbound 2001 address-group 1
# Set internal FTP server

[H3C-Ethernet3/0/0] nat server protocol tcp global 202.38.160.100 inside
10.110.10.1 ftp
# Set internal WWW server 1

10.110.10.2 www
# Set internal WWW server 2

[H3C-Ethernet3/0/0] nat server protocol tcp global 202.38.160.100 8080 inside
10.110.10.3 www
4-20
# Set internal SMTP server

10.110.10.4 smtp
4.5.2 Using Loopback Interface for NAT Configuration
As shown in Figure 4-5, the intranet accesses the Internet through the serial interface
3/0/0 on the SecPath; the internal network segment 10.110.10.0/24 can access the
Internet, but other network segments cannot; the internal network segment uses the
loopback interface address 202.38.160.106 as the converted address. The intranet
provides WWW, FTP and SMTP services to the outside, and the three servers use the
same public address 202.38.160.100.
II. Network diagram
10.110.10.1 10.110.10.2 10.110.10.3 10.110.10.4
WWW WWW
FTP server server 1 SMTP server
server 2
Intranet
10.110.10.100 10.110.12.100
Internal PC Internal PC
Ethernet3/0/0
SecPath
Internet
Outside PC
Figure 4-5 Configuration network diagram
# Configure the ACL.

# Configure the loopback interface.

[H3C] interface loopback0
4-21
[H3C-LoopBack0] ip address 202.38.160.106 32

# Configure the internal FTP server.

10.110.10.1 ftp
# Configure the internal WWW server 1.

10.110.10.2 www
# Configure the internal WWW server 2.

[H3C-Ethernet3/0/0] nat server protocol tcp global 202.38.160.100 8080 inside
10.110.10.3 www
# Configure the internal SMTP server.

10.110.10.4 smtp
# Associate the ACL with the loopback interface address.

[H3C-Ethernet3/0/0] nat outbound 2001 interface loopback 0
4.5.3 Static NAT Configuration
Private networks A and B both are at the 10.1.1.0/24 network segment; the IP
addresses of both PC1 and PC2 are 10.1.1.2; the WAN interface IP addresses of both
SecPath A and SecPath B are 201.1.1.1/24. Configure static NAT entries on SecPath A
and SecPath B to convert the 10.1.1.0/24 of private network A to 211.2.1.0/24 and the
10.1.1.0/24 of private network B to 211.2.2.0/24. Configure dynamic routes on SecPath
A and SecPath B to ensure that SecPath A is reachable to 211.2.2.0/24 and that
SecPath B is reachable to 211.2.1.0/24.
It is required that the private networks can access the Internet: PC1 on private network
A can access PC2 through the public network address 211.2.2.2 stored in SecPath B;
PC2 on private network B can access PC1 through the public network address
211.2.1.2 stored in SecPath A.
4-22
II. Network diagram
priv ate netw ork A priv ate netw ork B

Eth0/0/0 Eth0/0/0
201.2.2.2/24
SecPathA
201.1.1.1/24 Internet SecPathB
Eth1/0/0:10.1.1.1/24
Eth1/0/0:10.1.1.1/24
PC2
PC1
10.1.1.2/24 10.1.1.2/24
Figure 4-6 Network diagram for static NAT configuration
1) Configure SecPath A.
# Configure the static NAT list.
[H3C] nat static inside ip 10.1.1.1 10.1.1.254 global ip 211.2.1.0
255.255.255.0
# Assign the static NAT list on the Ethernet 0/0/0 interface.

[H3C-Ethernet0/0/0] nat outbound static
# Configure the Ethernet 1/0/0 interface.

# Configure the dynamic route to ensure the 211.2.2.0 network segment is reachable
(omitted here).
2) Configure SecPath B.
# Configure the static NAT list.
[H3C] nat static inside ip 10.1.1.1 10.1.1.255 global ip 211.2.2.0
# Assign the static NAT list on the Ethernet 0/0/0 interface.

[H3C-Ethernet0/0/0] nat outbound static

[H3C-Ethernet1/0/0] ip address 10.1.1.1 255.255.255.0 255.255.255.0
4-23
# Configure the dynamic route to ensure the 211.2.1.0 network segment is reachable
(omitted here).
4.5.4 Bidirectional NAT Configuration
The intranet uses the 10.0.0.0/24 and 10.1.1.0/24 network segments. The internal host
PC1 and the outside host PC3 have the same IP address (10.0.0.1). PC1 and PC2
(another internal host) can access PC3 through the www.web.com domain name and
3.0.0.1/24 IP address. The IP address of the DNS server is 192.168.0.0/24.
II. Network diagram
Eth1/0/0: Eth0/0/0
PC1
10.0.0.3/24 192.168.0.1/24
10.0.0.1/24
Intranet PC3
SecPathA
Eth3/0/0: www.web.com
10.1.1.3/24 10.0.0.1/24
PC2
10.1.1.1/24
DNS Server
192.168.0.150/24
Figure 4-7 Network diagram for bidirectional NAT configuration
# Configure the NAT address pool.

# Configure bidirectional NAT mapping.

[H3C] nat overlapaddress 3 10.0.0.0 3.0.0.0 address-mask 24
# Configure the ACL.

# Bind NAT outbound to the WAN interface.

[H3C] interface serial0/0/0
[H3C-Ethernet0/0/0] nat outbound 2000 address-group 1
# Set the IP address of the LAN interface.
4-24

4.5.5 Domain Name Mapping Configuration
The internal network at the 10.0.0.0/8 network segment provides the internal FTP and
WWW servers, with the domain names respectively as www.zc.com and ftp.zc.com.
The domain name can be correctly resolved by the outside DNS server. The IP address
of the Ethernet 0/0/0 interface, which connects the outside network, is 1.1.1.1/8.
II. Network diagram
10.0.0.2 10.0.0.3
WWW server FTP server Internal PC
Internal Ethernet
Eth1/0/0:
10.0.0.1
Eth0/0/0:
1.1.1.1 SecPath
Internet
DNS server
Figure 4-8 Network diagram for domain name mapping configuration
# Configure internal FTP and WWW servers on the Ethernet 0/0/0 interface.
[H3C-Ethernet0/0/0] nat outbound 2000
[H3C-Ethernet0/0/0] nat server protocol tcp global 1.1.1.1 www inside 10.0.0.2
www
[H3C-Ethernet0/0/0] nat server protocol tcp global 1.1.1.1 ftp inside 10.0.0.3
ftp
4-25
# Configure the ACL to allow the 10.0.0.0/8 network segment to access the Internet.
[H3C-acl-basic-2000] rule 1 deny

The outside hosts can access the corresponding internal servers with the www.zc.com
and ftp.zc.com domain names. After you make the following settings, internal hosts
also can access the corresponding internal servers with the www.zc.com and
ftp.zc.com domain names.
# Configure the mapping from the domain names to the external IP addresses, port
numbers and protocol types.
[H3C] nat dns-map www.zc.com 1.1.1.1 80 tcp
[H3C] nat dns-map ftp.zc.com 1.1.1.1 21 tcp
4.5.6 Limiting Connections from a Source Address
As shown in Figure 4-9, Ethernet1/0 is connected with a LAN 192.168.1.0/24, and

Ethernet1/1 is connected to the Internet; NAT is configured on the firewall. Thus, all
PCs in the LAN can access the Internet.
Configure the NAT maximum TCP connection limit function on the firewall to limit the
number of connections initiated from PCs in the LAN, so as not to affect the normal
access of other PCs to the Internet. You can limit the connections initiated from this
source address by setting the upper limit to 10, and lower limit to 1.
4-26
II. Network diagram
192.168.1.2/24
PC1
PC2 Server
E1/0 E1/1
Internet
192.168.1.0/24 202.106.10.1/24
PC3
SecPath
200.100.1.1/24
PC4
PC5
Figure 4-9 Network diagram for NAT maximum TCP connections limit function
# Configure the firewall to implement the access of LAN PCs to the Internet through
NAT.
The configuration procedure is omitted, refer to section 4.5.1 “Network Security
Configuration” for details.
# Create an ACL and configure the rule to match the data sourced from 192.168.1.2/24.
<H3C> system-view
[H3C-acl-adv-3000] rule 0 permit tcp source 192.168.1.2 0
# Create a connection limit policy and the sub-rule to limit the connections initiated from
a source address.
[H3C] connection-limit enable
[H3C] connection-limit policy 0
[H3C-connection-limit-policy-0] limit 0 acl 3000 amount 10 1
[H3C-connection-limit-policy-0] quit
# Configure the connection limit policy to 0.

[H3C] nat connection-limit-policy 0
4.6 Troubleshooting NAT Configuration

Fault 1: address translation abnormal
4-27
Troubleshooting: enable the debug for NAT, and refer to debugging nat in the
debugging command for specific operation. According to the Debugging information
displayed on the firewall, initially locate the failure, and then use other commands for
further check. Observe the source address after translation carefully, and make sure
that it is the expected address. Otherwise, it is possible the configuration of address
pool is wrong. Meanwhile, make sure that there is route in the accessed network to
return to the address segment defined in the address pool. Take into consideration the
influence onto the NAT by the ACL of firewall and address conversion itself, and also
route configuration.
Fault 2: internal server abnormal
Troubleshooting: if an external host can not access the internal server normally, check
the configuration on the internal server host, or the internal server configuration on the
firewall. It is possible that the internal server IP address is wrong, or that the firewall has
inhibited the external host to access the internal network. Use the command display
acl for further check. Refer to Chapter 10 SSL Configuration.
4-28
H3C SecPath Series Security Products Chapter 5 Firewall Configuration
Chapter 5 Firewall Configuration
5.1 Introduction to Firewall

In building construction, firewall is designed to prevent fire spreading from one part of
the building to another part. Network firewall serves to the similar purpose: to prevent
the Internet danger from spreading to your internal network.
On the one hand, firewall prohibits unauthorized or unauthenticated access from the
Internet to the protected network. On the other hand, firewall permits internal network
subscribers to Web access the Internet or send/receive E-mails. Firewall can also
serve as an authority control gateway for accessing the Internet, for example, to permit
specific user of the internal network to access the Internet. Many firewalls now still bear
some other attributes, such as subscriber identification, information security
(encryption) processing and so on.
In addition to protecting Internet connection, a firewall can protect mainframes and
important resources (such as data) on your network as well. All accesses to the
protected data should pass the firewall, even for internal access from inside the
organization.
When subscribers of external networks access internal network resources, they pass
the firewall, so do internal network subscribers who access external network resources.
In this case, firewall plays a role like a “guard” who discards data packets that should be
prohibited.
In Comware, firewall mainly refers to ACL-based packet filter (referred to as
ACL/packet filter throughout this manual), application specific packet filter (ASPF, also
known as stateful firewall), and NAT. For more information about NAT, refer to Chapter
4 “NAT Configuration.” The following sections in this chapter mainly introduce
ACL/packet filter and ASPF.
5.1.1 ACL/Packet Filter
I. ACL/Packet filter overview
The application of ACL/Packet filter on the firewall provides the firewall an capability of
filtering packets. When the ACL/packet filter firewall needs to forward a packet, it first
gets information about the packet header, including the upper layer protocol number
carried by the IP Layer, source address, destination address, source port and
destination port. Then it matches the packet against the configured ACL rule. Finally, it
forwards or drops the packet based on the comparison result.
5-1
II. Packet filter supporting fragment filtering
ACL/Packet filter on Comware platform supports testing and filtering of fragments. The
ACL/Packet filter firewall checks packet type (non-fragment packet, first fragment or
non-first fragment), obtains such information as Layer 3 (IP Layer) information about
the packet (basic ACL rule and advanced ACL rule not containing information except
Layer 3) and non-Layer 3 information (advanced ACL rule containing non-Layer 3
information) for matching, and obtains configured ACL rule.
For advanced ACL rule that has configured exact matching filtering, packet filter need
to record the non-Layer 3 information of each first fragment. When the follow-up
fragments arrive, the saved information will be used to perform full matching on each
matching condition of ACL rule.
After exact matching is used for filtering, the implementation efficiency of packet filter
will be slightly reduced. More configured matching entries means less efficiency.
Threshold can be configured to limit the maximum processing number of firewall.
For definitions of normal matching and exact matching, refer to Chapter 3 “ACL
Configuration.”
5.1.2 Application Specific Packet Filter
ACL/Packet filter is a static firewall with the following problems:

z Some security policies are unable to foresee multi-channel application protocols
such as FTP and H.323.
z It is unable for detecting some attacks such as TCP SYN, Java applet, and
ActiveX, from the application layer.
Therefore, the concept of status firewall -- ASPF was brought forth. Application specific
packet filter (ASPF) is packet filtering oriented to the application and transport layers,
namely status based packet filtering. The application layer protocol detections include
FTP, HTTP, SMTP, RTSP, H.323 (Q.931, H.245, and RTP/RTCP), SNMP, and SQLNET
ones. The transport layer protocol detection contains general TCP/UDP detection.
ASPF is able to perform the primary functions as follows:
z Check application layer protocol information, such as the protocol type of a packet
and port number. In addition, it monitors the connection-based application layer
protocol status. ASPF maintains the information of each connection and
dynamically decides whether to permit a data packet into the internal network for
malicious-intrusion prevention.
z Detect the transport layer protocol information, that is, general TCP and UDP
protocol detection. It can also decide whether to permit a TCP/UDP packet into the
internal network.
ASPF implements the following additional functions:
z It can detect and defense the Denial of Service (DoS) attack.
5-2
z It can both filer packets based on connection status and detect packet contents at
the application layer. It can provide Java blocking and Active X Blocking to
distrusted sites.
z It enhances the session logging function and can log all the connection information
including time, source address, destination address, the port in use, and the
number of transmitted bytes.
z It supports Port to Application Map (PAM) and allows user-defined application
protocol to use non-general port.
On the network edge, ASPF cooperates with common static firewall to provide
comprehensive and practical security policy for intranets.
I. Basic Concepts
z Java blocking and activeX blocking

Java blocking blocks the java applet transferred by HTTP protocol. When Java blocking
is configured, ASPF will block and filter out the request commands sent by users who
attempt to obtain the Java applet-included programs from web pages. If activeX
blocking is configured, ASPF will block Active controls transferred through HTTP
protocols to protect the user from installing unsafe or malicious controls.
z Port to application mapping
Application layer protocols use some (well-known) port numbers pre-defined by the
system for communication. PAM (Port to Application Mapping) permits subscribers to
define a set of new port numbers other than port numbers pre-defined by the system for
different applications. PAM provides some mechanism to maintain and use port
configuration information defined by subscribers.
PAM supports two kinds of mapping mechanisms: general port mapping and
ACL-based host port mapping. General port mapping is to establish mapping
relationship between user-defined port numbers and application layer protocols. For
example, map 8080 port as HTTP protocol so that all TCP packets with destination port
of 8080 could be regarded as HTTP packets. Basic ACL-based host mapping is to
establish mapping relationship between user-defined port numbers and application
protocols for packets to/from some specific hosts. For example, map the TCP packets
using the port 8080 and destined to the network segment 10.110.0.0 to HTTP packets.
The range of hosts is specified by basic ACL.
z Single-channel protocol/multi-channel protocol
Single-channel protocol: Only one channel is available for data interaction from the
establishment of a session to the end. Such protocols include SMTP and HTTP.
Multi-channel protocol: The interaction of the control information and the transfer of
data are achieved in different channels. They can be FTP and RTSP.
z Internal interface and external interface
5-3
If a firewall connects an internal network and the Internet and deploys ASPF to protect
the server of the internal network, the interface on the firewall connecting with the
internal network is an internal interface while the one connecting with Internet is an
external interface.
When ASPF is applied to the outbound direction of an external interface on the firewall,
a temporary channel can be opened on the firewall for the returned packets of internal
network users who access the Internet.
II. Fundamentals of application protocol layer detection
Packets of other sessions blocked
Client A initializes a session

WAN
Client A Returned packets of client A are Server

permitted to pass
SecPath
Protected network
Figure 5-1 Fundamentals of application protocol layer detection
As shown in the above figure, generally a static ACL is needed on the firewall to allow a
host of the internal network to access the external network and to prohibit a host of the
external network to access internal network. However, a static ACL will filter out the
returned packets after the user initiates a connection, so the connection cannot be
established. When a firewall is configured with application layer protocol detection,
ASPF is able to detect every session on application layer and create a status table and
a temporary access control list (TACL). The status table is created once the first packet
is detected and is used in maintaining the status of a session at a certain time detecting
the session status transition is correct. The entry of a TACL is created together with a
status entry and will be deleted after a session terminates. It seems like the permit entry
in an advanced ACL to match all the returned packets in a session, which functions like
that a temporary channel is created at the external interface of the firewall for some
returned packets.
Take FTP detection for example to illustrate the process of a multi-channel application
layer protocol detection.
5-4
port: 1333 port: 21

FTP command and response
Control channel connection
FTP FTP
Client Port command Server
Data control connection

port: 1600 port: 20
Figure 5-2 FTP detection process
Following is how an FTP connection is set up:

Suppose that an FTP client initiates an FTP control channel connection from its port
1333 to the port 21 of FTP server. After negotiation, Server initiates a data channel
connection from its port 20 to the port 1600 of Client. The timeout or end of a data
transfer makes a connection deleted.
Following is how FTP detection operates since an FTP connection is set up till it is
disconnected:
1) Check the IP packet sent from the egress interface to the outside and
acknowledges it is an FTP packet based on TCP.
2) Check the port number, acknowledges it as a control connection to create a TACL
and status table for returned packets.
3) Check the FTP control connection packets, makes FTP instruction resolution, and
updates the status table according to the instructions. If there are data channel
establish instructions, then it the TACL for other data links. It does not detect the
status of data links.
4) A match detection is performed on returned packets according to protocol type
and then ASPF decides if to pass the packets after referring to the status table and
TACL of the protocol.
5) The status table and TACL are cleared along with the deletion of an FTP
connection.
The detection of single-channel application layer protocols, such as SMTP and HTTP,
is rather simple. A TACL is created and cleared together with the connection.
III. Fundamentals of transport protocol layer detection
Here the transport layer protocol detection refers to TCP/UDP detection. Different from
the application layer protocol detection, the transport layer protocol detects the packet
information of transport layer, such as source address, destination address and port
number. The TCP/UDP detection requires that the packets returned back to the
external interface of ASPF match exactly the packets sent out it, that is, the source
address, destination address and port number are right. Otherwise, the returned
packets will be blocked. Therefore, you cannot establish a connection for the
multi-channel application layer protocols such as FTP and .H.323, if you just configure
TCP detection, but not application layer detection.
5-5
5.2 Configuring Packet Filter Firewall

Packet filter configuration includes:
z Enable or Disable Packet Filter
z Set the Default Filtering Mode of Firewall
z Enable/Disable Fragment Inspection of Packet Filter
z Configure High/Low Threshold of Fragment Inspection
z Apply ACL on the Interface
5.2.1 Enabling or Disabling Packet Filter
Table 5-1 Enable or disable packet filter
Operation Command
Enable packet filter firewall packet-filter enable
Disable packet filter undo firewall packet-filter enable
By default, packet filter is enabled on SecPath series firewalls, but disabled on SecPath
series security gateways.
5.2.2 Setting the Default Filtering Mode of Firewall
To set the default filtering mode of firewall means when there is no appropriate rule to
judge whether the user packet can pass, the policy adopted by the firewall is to permit
the packet to pass or not.
Table 5-2 Set the default filtering mode of firewall
Operation Command
Set the default filtering mode as
firewall packet-filter default permit
permitting the packet to pass
Set the default filtering mode as denying
firewall packet-filter default deny
the packet to pass
When firewall is enabled, the default is to block any packet to pass.

If deny is the default filtering mode of a firewall working in transparent mode, apart from
binding a Layer 2 ACL (with number 4000 to 4999), you also need to bind an interface
ACL (with number 1000 to 1999) to the firewall to make the firewall forward packets
normally.
5-6
5.2.3 Enabling/Disabling Fragment Inspection of Packet Filter
Table 5-3 Enable/disable fragment inspection of packet filter
Operation Command
Enable fragment inspection of packet firewall packet-filter
filter fragments-inspect
Disable fragment inspection of packet undo firewall packet-filter
filter fragments-inspect
Note:
Only after fragment inspection of packet filter is enabled, can exact matching mode be
valid in the real sense.
5.2.4 Configuring Upper/Lower Threshold of Fragment Inspection
Table 5-4 Configure upper/lower threshold of fragment inspection
Operation Command
firewall packet-filter
Specify number of upper/lower threshold
fragments-inspect { high | low }
fragment state records
{ default | number }
Restore the default number of
undo firewall packet-filter
upper/lower threshold fragment state
fragments-inspect { high | low }
records
The default number of upper threshold fragment state records is 2000. The default
number of lower threshold fragment state records is 1500.
5.2.5 Applying ACL on the Interface
When applying access rule on the interface, the time range filtering principle is followed
at the same time. Moreover, access rule can be specified respectively for transmitting
and receiving packets on the interface.
5-7
Table 5-5 Apply ACL on the interface
Operation Command
firewall packet-filter acl-number
Specify the rule of filtering transmitting { inbound | outbound }
and receiving packets in the interface [ match-fragments { normally |
exactly } ]
Remove the rule of filtering transmitting undo firewall packet-filter acl-number
and receiving packets in the interface { inbound | outbound }
You can only use the parameter outbound for interface-based ACL (ACL 1000 to 1999).
An interface-based ACL matches the packets received through a specified interface,
and then permit or deny the matched packets to leave from a specified interface
(including the one that receives the packets).
An advanced ACL can perform standard matching and exact matching. The standard
matching matches no information except those of the third layer; whereas the exact
matching matches information by all rules of advanced ACLs. Therefore, a firewall
must be able to get and keep the state information of the first fragment packet to get
complete matching information of the fragments that followed.
The standard matching is used by default.
The match-fragments keyword can be applied to advanced ACLs only.
Only after the packet filter function is enabled can an ACL applied on an interface take
effect.
5.2.6 Displaying and Debugging Packet Filter
running of the packet filter configuration, and to verify the effect of the configuration.
Execute debugging command in user view to debug the packet filter.
Table 5-6 Display and debug firewall
Operation Command
display firewall packet-filter statistics
Display statistics about firewall { all | interface type number |
fragments-inspect }
Display the fragments on the firewall display firewall fragment
debugging firewall packet-filter { all |
denied | permitted | icmp | packet
Enable packet filter debugging (in user
{ permitted | denied } | tcp | udp |
view)
fragments-inspect | others }
5-8
Operation Command
undo debugging firewall packet-filter
{ all | denied | permitted | icmp |
Disable packet filter debugging (in user
packet { permitted | denied } | tcp | udp
view)
| fragments-inspect | others }
Enable event debugging of the debugging firewall packet-filter
fragments fragments-inspect events
Disable event debugging of the undo debugging firewall packet-filter
fragments fragments-inspect events
reset firewall packet-filter statistics
Clear packet filter statistics
{ all | interface type number }
5.2.7 Typical Configuration Examples of Packet Filter
The following example of configuring firewall in a company explains firewall

configuration.
The company accesses the internet through the interface Ethernet 1/0/0 on a SecPath
firewall. It provides WWW, FTP and Telnet services externally. The internal subnet of
the company is 129.38.1.0, the internal FTP server address is 129.38.1.1, internal
Telnet server address is 129.38.1.2, internal WWW server address is 129.38.1.3 and
company external address is 202.38.160.1. Address translation is configured on the
firewall so that internal PCs could access the Internet and external PCs could access
internal server. The following requirements are aimed to be satisfied through
configuration firewall:
z Only specific subscribers on external network can access the internal server.
z Only specific hosts on the internal network can access external network.
Suppose the IP address of the specific external subscriber is 202.39.2.3.
5-9
II. Network diagram
129.38.1.1 129.38.1.2 129.38.1.3
FT P Server Telnet Server WWW Server
Company internal Ethernet

Ethernet0/0/0
SecPath 129.38.1.5
Specific PC inside the company Ethernet1/0/0 202.39.2.3

129.38.1.4 202.38.160.1
WAN
Specific PC outside the company
Figure 5-3 Network diagram of packet filter configuration example
# Enable packet filter.

[H3C] firewall packet-filter enable
# Set the default firewall filtering mode as permitting packet to pass.

[H3C] firewall default permit
# Create ACL 3001.

# Configuration rule permits specific host to access external network and permits
internal server to access external network.
[H3C-acl-adv-3001] rule permit ip source 129.38.1.4 0
[H3C-acl-adv-3001] rule deny ip
# Create ACL 3002.

# Configuration rule permits specific user to access internal server from external
network.
5-10
[H3C-acl-adv-3002] rule permit tcp source 202.39.2.3 0 destination 129.38.1.0

0.0.0.3
# Configuration rule permits specific user to obtain data from external network (only
packets with ports bigger than 1024 are permitted.)
[H3C-acl-adv-3002] rule permit tcp destination 129.38.1.4 0 destination-port
gt 1024
[H3C-acl-adv-3002] rule deny ip
# Act the rule 3001 on inbound packet from the interface Ethernet 0/0/0.
[H3C-Ethernet0/0/0] firewall packet-filter 3001 inbound
# Act the rule 3002 on inbound packet from the interface Ethernet 1/0/0.
5.2.8 Fragment Packet Configuration Examples of Packet Filter
The company accesses the internet through the interface Ethernet 1/0/0 on a SecPath
firewall. The firewall is connected with the company internal network through the
interface Ethenet0/0/0. This company provides WWW and Telnet services externally.
The internal subnet of the company is 200.1.1.0/24, internal WWW server address is
200.1.1.1, internal Telnet server address is 200.1.1.2 and the external interface
(Ethernet 1/0/0) address of the firewall is 202.38.160.1.
Apply ACL on the inbound direction of the external interface on the firewall to prevent
the external fragment packet attack on the internal WWW and Telnet server, thus to
block the fragment packets forwarded to the internal servers.
5-11
II. Network diagram
200.1.1.2 200.1.1.1
Telnet server WWW server
Company internal netw ork

Ethernet0/0/0
SecPath 200.1.1.254
Ethernet1/0/0
202.38.160.1
WAN
External public netw ork
Figure 5-4 Network diagram of fragment packet configuration example of packet filter
# Configure ACL to block the fragment packets from external network.

[H3C-acl-adv-3001] rule 1 deny ip source any destination 200.1.1.1 0 fragment
[H3C-acl-adv-3001] rule 2 deny ip source any destination 200.1.1.2 0 fragment
[H3C-acl-adv-3001] rule 3 permit tcp source any destination 200.1.1.1 0
destination-port eq 80
[H3C-acl-adv-3001] rule 4 permit tcp source any destination 200.1.1.2 0
[H3C-acl-adv-3001] rule 5 deny ip
# Configure packet filter, apply the ACL on the inbound direction of the external
interface.
The inbound ACL is used to block the fragment packets moving toward the specific
internal server and it permits the external host to access the internal server. If the
returning flow corresponding to the initial session of internal host moves through the
firewall, you need to add some other ACL rules or you can use ASPF status firewall.
5-12
5.3 Configuring ASPF

ASPF configuration includes:
z Enable firewall
z Configure ACL
z Define an ASPF policy
z Apply the ASPF policy on specified interfaces
5.3.1 Enabling Firewall
This configuration task is the same as the packet filter configuration describe in
preceding sections.
5.3.2 Configuring ACL
To protect internal network, access control list should be configured on the firewall and
applied to external interface, permitting the internal hosts access external network and
prohibiting external hosts from accessing internal network.
Table 5-7 Configure ACL
Operation Command
Configure ACL (in ACL view) rule deny
Apply ACL to external interface (in
firewall packet-filter acl-num inbound
interface view)
5.3.3 Defining an ASPF Policy
Define an ASPF policy according to the following steps:

z Create an ASPF policy
z Configure aging-time value
z Configure application layer protocol detection
z Configure general TCP or UDP detection
I. Creating an ASPF policy
Table 5-8 Create an ASPF policy
Operation Command
Create an ASPF policy aspf-policy aspf-policy-number
Delete the created ASPF policy undo aspf-policy aspf-policy-number
5-13
In the table, aspf-policy-number is ASPF policy number, ranging from 1 to 99. When the
command is used to create an ASPF policy, the ASPF policy view is entered at the
same time.
II. Configuring aging-time value
Perform the following configuration in ASPF policy view.
Table 5-9 Configure aging-time value
Operation Command
aging-time { syn | fin | tcp | udp }
Configure aging-time value
seconds
Restore the default aging-time value undo aging-time { syn | fin | tcp | udp }
This task is used to configure waiting timeout value in SYN state and FIN state of TCP,
default free timeout value of TCP and UDP session entries. The default timeout time of
syn, fin, tcp and udp are 30s, 5s, 3600s and 30s respectively.
III. Configuring application layer protocol detection
Table 5-10 Configure application layer protocol detection
Operation Command
Configure ASPF detection for detect protocol [ acl number ]
application layer protocol [ aging-time seconds ]
Delete the configured application
undo detect protocol [ acl number ]
protocol detection
The application protocol can be ftp, http, h323, smtp, snmp, rtsp, sqlnet, and the
transport layer protocol can be tcp or udp.
The default timeout time of application layer protocols is 3600 seconds.
The default TCP timeout time is 3600 seconds and the default UDP timeout time is 30
seconds.
The acl number combination is supported only when the protocol argument is ftp, smtp,
or snmp.
When the protocol argument is set to http, Java blocking can be configured as follows.
5-14
Table 5-11 Configure Java blocking detection
Operation Command
detect http [ java-blocking
Configure Java blocking detection [ acl-number1 ] | activex-blocking
[ acl-number2 ] ]* [ aging-time seconds ]
Delete the configured ASPF detection undo detect http [ java-blocking |
rule activex-blocking ]*
Note:
Currently, only those Java requests suffixed with “class” in HTTP requests can be
filtered by using Java blocking function.
IV. Configuring generic TCP and UDP protocol detection
Table 5-12 Configure general TCP and UDP protocol detection
Operation Command
Configure general TCP detection detect tcp [ aging-time seconds ]
Configure general UDP detection detect udp [ aging-time seconds ]
Delete general TCP detection undo detect tcp

Delete general UDP detection undo detect udp
The TCP-based default timeout time is 3600 seconds and the UDP-based timeout time
is 30 seconds.
You are recommended to use the application layer detection together with TCP/UDP
detection, for a configuration of TCP/UDP detection without application layer protocol
might cause packet return failures.
Note:
For Telnet applications, just configure generic TCP detection to implement ASPF
function.
5-15
5.3.4 Applying ASPF Policy on Specified Interface
The interface stream detection will take effect only after applying the pre-defined ASPF
policy on the external interface.
Table 5-13 Apply ASPF policy on specified interface
Operation Command
Configure ASPF detection policy in firewall aspf aspf-policy-number
specified interface { inbound | outbound }
Delete the ASPF detection policy undo firewall aspf aspf-policy-number
applied in the interface { inbound | outbound }
As ASPF saves and maintains application layer protocol status based on interface, you
must ensure that the originating and response packets for a connection are sent out
and received on the same interface.
5.3.5 Setting the Session Timeout Values
Use the following command to configure timeout values for protocols in the session
table.
Table 5-14 Set the session timeout values
Operation Command
Set the session timeout values of all
firewall session aging-time default
protocols to their defaults.
firewall session aging-time { fin-rst |

Set session timeout values for individual fragment | ftp | h323 | http | icmp |
protocols. netbios | ras | rtsp | smtp | syn | tcp |
telnet | udp } { default | seconds }
Refer to the Command Manual for default session timeout values of protocols.
Note:
Do not configure the same timeout for syn as that for fin-rst or tcp. Otherwise, timeout
updating will fail.
5-16
5.3.6 Configuring ASPF Session Logging Function
ASPF provides enhanced session logging function. All the connections and information
about connection including the time, source address, destination address, ports used
and number of bytes can be logged.
Table 5-15 Configure ASPF session logging function
Operation Command
Enable ASPF session logging function log enable
Disable ASPF session logging function undo log enable
By default, the session logging function is disabled.
5.3.7 Configuring a Port Mapping Entry
Table 5-16 Configure PAM
Operation Command
port-mapping application-name port
Configure the generic PAM function.
port-number
Delete the user-configured generic undo port-mapping application-name
PAM. port port-number
port-mapping application-name port
Configure PAM for a host.
port-number acl acl-number
Delete the user-configured PAM of a undo port-mapping application-name
host port port-number acl acl-number
The range of hosts in the host-specific PAM is specified using a basic ACL.
When configuring to monitor the application protocol examination function on a
non-standrd port (for example, the HTTP protocol listens port 8080 rather than the
non-standard port 80), you need enable the corresponding port mapping with this
command, guaranteeing that the ASPF state is checked properly.
5-17
5.3.8 Displaying and Debugging ASPF
running status of ASPF, and to verify the effect of the configuration. Execute
debugging command in user view for the debugging information of ASPF.
Table 5-17 Display and debug ASPF
Operation Command
Display all ASPF configurations display aspf all
Display information about the interfaces
where ASPF policies and ACLs are display aspf interface
applied
Display the configuration of a specific
display aspf policy aspf-policy-number
ASPF policy
Display sessions currently traced and
display aspf session [ verbose ]
inspected by ASPF
Display ASPF statistics information display aspf statistics
display firewall session table
Display the session table on the firewall [ verbose ] [ source ip-address ]
[ destination ip-address ]
Display the session timeout values of
display firewall session aging-time
various protocols
display port-mapping
Display port mapping information.
[ application-name | port port-number ]
debugging aspf { all | verbose | events
Enable ASPF debugging | ftp | h323 | http | rtsp | session | smtp
| sqlnet | tcp | timers | udp }
undo debugging aspf { all | verbose |
Disable ASPF debugging events | ftp | h323 | http | rtsp | session
| smtp | sqlnet | tcp | timers | udp }
debugging aspf http { java-blocking |
Enable HTTP debugging activex-blocking } { all | error | event |
filter | packet }
undo debugging aspf http
Disable HTTP debugging { java-blocking | activex-blocking }
{ all | error | event | filter | packet }
Clear ASPF session information reset aspf session
reset aspf statistic http
Clear ASPF HTTP statistics information
[ java-blocking | activex-blocking ]
Clear session table on the firewall reset firewall session table
5-18
5.3.9 Cautions for Implementing ASPF
The modification on the interface ASPF policy by executing the detect, aging-time and
port-mapping commands, or the modification on the interface policy by executing the
firewall aspf aspf-policy-number { inbound | outbound } command, only takes effect
on newly established sessions. You can manually clear the sessions in the case that
they may be inconsistent with the ASPF policy; however, this action should be taken
with caution because it will cut off the existing sessions.
5.3.10 ASPF Configuration Example
Configure an ASPF policy on the firewall to inspect FTP and HTTP traffic passing the
firewall. Requirement: If the packet is a returned packet of FTP and HTTP connections
initiated by internal network subscribers, permit it to pass the firewall and enter the
internal network. For other packets, deny them. In addition, this detection policy can
filter out Java Applets in HTTP packets from the server 2.2.2.11. This example can be
applied in the case when local user needs to access remote network service.
II. Network diagram
ASPF
SecPath Router
Internet netw ork Ethernet0/0/0 Ex ternal netw ork
Ethernet0/0/0
202.101.1.1
Ethernet Ethernet
202.101.1.2 Server Host 2.2.2.11
Figure 5-5 Network diagram for ASPF configuration
# Enable packet filter.

[H3C] firewall packet-filter enable
# Configure ACL 3111 to refuse all TCP and UDP traffic to enter internal network. ASPF
will create a temporary ACL for traffic that is permitted to pass.
[H3C-acl-adv-3111] rule deny tcp
[H3C-acl-adv-3111] rule deny udp
[H3C-acl-adv-3111] rule permit ip
5-19
# Configure ACL 2001 to filter Java Applets from the site 2.2.2.11.
[H3C-acl-basic-2001] rule permit source 2.2.2.11 0
[H3C-acl-basic-2001] rule deny
# Create ASPF policy, with a policy number of 1. The policy detects two protocols on
application layer, FTP and FTTP, and defines the timeout time of the two protocols in
case of no actions as 3000 seconds.
[H3C] aspf-policy 1
[H3C-aspf-policy-1] detect ftp aging-time 3000
[H3C-aspf-policy-1] detect http aging-time 3000
[H3C-aspf-policy-1] detect http java-blocking 2001
[H3C-aspf-policy-1] quit
# Apply the ASPF policy on the interface.

[H3C-Ethernet0/0/0] firewall aspf 1 outbound
# Apply ACL 3111 on the interface.

5.4 Black List

5.4.1 Introduction to Black List
Black list is used to filter packets based on source IP address of packets. Compared
with ACL, the zones for black list to match are much simpler, so it can filter packets in a
high speed, which effectively shields the packets sent from the specific IP address. The
most important feature of black list is that it can be added and deleted dynamically by
the firewall module. When firewall discovers the attack attempt of a specific IP address
based on packet behavior, it can automatically modify its black list to filter all the
packets sent from the specific address. For this reason, black list is important for
firewall.
I. Creating black list
Two approaches are available to create a black list: manual creation through command
lines and dynamic creation and insertion by some modules of the firewall.
1) Creation through command lines
The following command is used to create a black list entry.
firewall blacklist sour-addr [ timeout minutes ]
5-20
Black list entries created with the timeout minutes argument can age out when their
timers expire and be removed automatically. Accordingly, the filtering function for the
packets with the source IP addresses defined in these entries is removed. On the
contrary, entries without an aging timeout setting never age out.
2) Dynamic creation by some modules of the firewall
Some modules of the firewall can dynamically insert an entry into the black list. For
instance, when the attack prevention module discovers attack from a specific IP
address, it will automatically insert the specific IP address into the black list. Therefore,
any packet from the IP address will be denied in a specific period after that.
If identical IP addresses are inserted in the black list, the entry with a long aging period
is reserved.
So far, the attack prevention firewall module can insert entries into the black list.
For the related configuration, refer to Chapter 12 “Attack Prevention and Packet
Statistics.”
II. Removing black list entry
Using the following command, you can remove the black list entries.
undo firewall blacklist [ sour-addr ]
With parameter sour-addr, the specific IP address entry will be removed. Without the
parameter, all entries in the current black list will be removed.
The creation and deletion of black list entries is independent of the black list’s running
status, that is, black list entries can be created and removed no matter whether the
black list is enabled or not.
III. Enabling black list
Only when the black list is enabled, can the firewall filter the IP packet based on the
black list. Otherwise, the IP packet will not be discarded though it is in the black list.
Use the firewall blacklist enable command to enable the black list.
Use the undo firewall blacklist enable command to disable the black list.
By default, the black list is disabled.
5.4.2 Black List Configuration
Black list configuration includes:

z Configure/remove black list entry
z Enable or disable black list
I. Configuring/removing black list entry
5-21
Table 5-18 Configuring black list entry
Operation Command
Configure black list entry firewall blacklist sour-addr [ timeout minutes ]
Remove black list entry undo firewall blacklist [ sour-addr ]
The value of minutes ranges from 1 to 1000, in minutes. Without parameter timeout
minutes, the configured entry is a permanent entry. Without parameter sour-addr
means removing all entries in the current black list.
II. Enabling or disabling black list
Table 5-19 Enabling or disabling black list
Operation Command
Enable black list firewall blacklist enable
Disable black list undo firewall blacklist enable
By default, black list is disabled.
5.4.3 Displaying and Debugging Black List
Execute the display command in any view to display the running of black list entry or
black list configuration.
Execute the debugging command in user view to enable the debugging of the back
list.
Table 5-20 Displaying and debugging black list
Operation Command
Display the current black list entry display firewall blacklist { enable |
information or running status item [ sour-addr ]
debugging firewall blacklist { all |
Enable the debugging for the black list
item | packet }
5.4.4 Typical Example of Black List Configuration
The server and the client PC are located in firewall Trust zone and Untrust zone
respectively. It is required to filter all packets sent from the client PC within 100 minutes.
5-22
II. Network Diagram
202.169.168.1 SecPath 192.168.10.1
PC Server
Figure 5-6 Network diagram of blacklist filter
III. Configuration Procedures
# Insert the IP address of the client PC into the black list.

[H3C] firewall blacklist 202.169.168.10 timeout 100
# Enable the black list.

[H3C] firewall blacklist enable
Based on the above configuration, all the packets sent from the client PC will be denied
within the aging period 100 minutes. After that period, the packet sent from the client
PC can pass the firewall.
5.5 MAC and IP Address Binding

5.5.1 Introduction to MAC and IP Address Binding
MAC and IP address binding means the firewall associates the specific IP address and
MAC address based on the client configuration. In this way, firewall will discard the
so-called packet whose MAC address does not correspond to the associated IP
address and forcibly forwards the packet whose destination address is the specific IP
address to the associated MAC address. This effectively avoids the imitated IP address
attack to protect the network.
I. Creating MAC and IP address binding
Using the following commands, you can create an address binding map.
firewall mac-binding sour-addr mac-addr
Address binding map is created based on IP address. If identical IP address is
configured in the address binding map, the new configured entry will replace the old
one. One MAC address can be bound with various IP addresses.
II. Removing MAC and IP address binding
Using the following commands, you can remove one or all address binding map(s).
undo firewall mac-binding [ ip-addr ]
5-23
With parameter ip-addr, the specific IP address binding will be removed. Without this
parameter, all entries in the current address binding list will be removed.
The creation and deletion of address binding map is independent of address binding
function, that is, address binding map can be created and removed no matter whether
the address binding is enabled or not.
III. Enabling MAC and IP address binding
Only when address binding is enabled, can firewall compare the IP address and MAC
address of the packet based on the address binding map and deny the packet not
meeting the binding map. Otherwise, it will not discard any packet even the packet
whose IP address and MAC address do not meet the binding map.
Using the following commands, you can enable address binding.
firewall mac-binding enable
Using the following commands, you can disable address binding.
undo firewall mac-binding enable
By default, address binding is disabled.
5.5.2 MAC and IP Address Binding Configuration
MAC and IP address binding configuration includes:

z Configuring MAC and IP address binding map
z Enabling or disabling MAC and IP address binding
I. Configuring MAC and IP address binding Map
Table 5-21 Configuring MAC and IP address binding condition
Operation Command
Configure MAC and IP address binding firewall mac-binding sour-addr
map mac-addr
Remove MAC and IP address binding undo firewall mac-binding
map [ sour-addr ]
Without the parameter sour-addr, all the current address binding entries are removed.
5-24
Caution:
z Address binding is regarded as another kind of expression of static ARP. In the case
of address binding being enabled, the configuration of address binding, whose IP
address has been configured in the static ARP list, will cause deletion of the
corresponding static ARP entry. If identical IP address has been configured in the
address binding, static ARP configuration will fail and receive prompt information.
However, identical IP address can be configured in both address binding and static
ARP if address binding function is disabled.
z MAC and IP address binding is ineffective to PPPoE addresses, because the
system cannot identify and handle the PPP packets over Ethernet frames.
z Broadcasting addresses of classes A, B and C cannot be bound.
z If the IP address to be bound is not in the same network segment with the interface
IP address of the firewall, a message appears, prompting “The IP address is not in
the same subnet of the interfaces' IP address”. However, the binding entry will be
created.
z With MAC address and IP address binding function enabled, a MAC address and IP
address binding entry takes effect once it is created. A firewall checks the packets it
receives and discards those that do not match the binding rules. As the destination
MAC address of a packet changes when it is forwarded across networks, the
destination MAC address of the packet may differ when it is forwarded along
different routes if the IP address is bound to an indirectly connected network, which
causes the packet being dropped and communication problems.
II. Enabling/disabling MAC and IP address binding
Table 5-22 Enable/disable MAC and IP address binding
Operation Command
Enable MAC and IP address binding firewall mac-binding enable
Disable MAC and IP address binding undo firewall mac-binding enable
By default, MAC and IP address binding is disabled.
5.5.3 Displaying and Debugging MAC and IP Address Binding
Execute the display command in any view to display the running of address binding
configuration.
Execute the debugging command in user view to debugging the address binding.
5-25
Execute the reset command in user view to clear the statistics on the binding between
MAC and IP addresses.
Table 5-23 Display and debug MAC and IP address binding
Operation Command
Display the current MAC and IP address display firewall mac-binding item
binding map information [ ip-addr | ] [ statistic ]
Display the current running information
display firewall mac-binding enable
of MAC and IP address binding function
Enable the debugging of MAC and IP debugging firewall mac-binding [ { all
address binding | item | packet ]}
Clear the statistics on the binding reset firewall mac-binding item
between MAC and IP addresses [ ip-addr ] statistic
5.5.4 Typical Example of MAC and IP Address Binding Configuration
The server and the client PC are located in the firewall trust zone and untrust zone
respectively. The client PC is at 202.169.168.1 and the corresponding MAC address is
00e0-fc00-0100. Configure address binding map on the firewall that only the packet
meeting the above map can pass the firewall and the packet sent to 202.169.168.1 is
forwarded to the network card at 00e0-fc00-0100.
II. Network diagram
202.169.168.1 SecPath 192.168.10.1
PC Server
Figure 5-7 Network diagram of address binding configuration
III. Configuration procedures
# Insert IP address and MAC address of the client PC into the address binding map.
[H3C] firewall mac-binding 202.169.168.1 00e0-fc00-0100
# Enable the address binding function.

[H3C] firewall mac-binding enable
5-26
5.6 Security Zone Configuration

5.6.1 Security Zone Overview
Security zones refer to the networks connected to the firewall. Four security zones are
predefined in the system: Local, Trust, Untrust and DMZ, with descending security
levels.
z Local zone stands for the local system on the firewall. All packets sent to the
firewall are regarded as being sent to the Local zone on the firewall.
z Trust zone stands for the private network over user network.
z Untrust zone stands for public or insecure network, such as Internet.
z DMZ (demilitarized zone) is an independent zone between the intranet and
outside networks. It belongs neither to the intranet nor to outside networks. For
example, in a network providing E-commerce services, some hosts, such as Web
server, FTP server and mail server, are required to provide these services. To
provide better services and effectively protect the intranet, you can add these
servers into the DMZ zone to isolate them from the intranet. Then you can apply
different firewall policies to intranet devices and these servers.
5.6.2 Security Zone Configuration
I. Entering security zone view
Table 5-24 Enter security zone view
Operation Command
Enter the security zone view firewall zone zonename
II. Enter interzone view
Table 5-25 Enter interzone view
Operation Command
Enter the interzone view firewall interzone zone1 zone2
III. Creating security zone
5-27
Table 5-26 Create security zone
Operation Command
Create a security zone firewall zone name zonename
Delete the security zone undo firewall zone name zonename
Four security zones are predefined in the system: Local, Trust, Untrust and DMZ. You
cannot remove these security zones.
IV. Adding interface into security zone
Perform the following configuration in zone view.
Table 5-27 Add interface into security zone
Operation Command
add interface interface-type
Add an interface into the security zone
interface-number
Remove the interface from the security undo add interface interface-type
zone interface-number
By default, no interface belongs to the Trust zone.

An interface can belong to only one security zone. You must remove the interface from
the original security zone before adding it to another security zone if an interface
already belongs to a security zone.
Caution:
For interworking between the firewall and other devices, corresponding interfaces
should be added to a security zone.
V. Setting priority value for the security zone
You can set priority value for the security zone. A large priority value means high
security.
5-28
Table 5-28 Set priority value for security zone
Operation Command
Set priority value for the security zone set priority number
By default, the priority value for the Local zone is 100; that for the Trust zone is 85; that
for Untrust zone is 5; that for DMZ zone is 50. You cannot change these priority values.
Note:
There is no limit to access across security zones. Since security zones do not support
configuring policies, you need to specify an interface in the security zone to implement
access control.
5.6.3 Security Zone Display
You can view the configuration in security zone by executing display command in any
view.
Table 5-29 Display security zone
Operation Command
Display interfaces in the security zone display zone [ zone-name ] interface
Display priority of security zone display zone [ zone-name ] priority
Display interfaces and priority of security

display zone [ zone-name ]
zone
Display inter-security zone configuration
display interzone [ zone1 zone2 ]
information
5-29
H3C SecPath Series Security Products Chapter 6 Object-Oriented Management
Chapter 6 Object-Oriented Management
6.1 Object-Oriented Management Overview

Object-oriented management employs the concept of object to help simplifying
configuration and management tasks. It uses an address object or address group
object to represent one or more IP addresses or domain names, uses a service object
or service group object to represent one or more combinations of source ports,
destination ports and protocol numbers, and uses a flow object to represent a
quintuplet. A flow object can reference address objects (or address group objects) and
service objects (or service group objects). This significantly simplifies the configuration
tasks, enhances the ease of use, and improves the usability and user-friendliness.
6.2 Creating Objects

Currently, the system supports configuration and management of the following types of
objects:
z Address object
z Address group object
z Service object
z Service group object
z Flow object
z Time range object
6.2.1 Creating an Address Object
Address object is a basic unit in object-oriented management. An address object can

be added into multiple address group objects and referenced by one or more flow
objects, and must be created so as to be used. You can create an address object that
represents either an IP address or domain name.
Before creating an address group object or flow object, you must create an address
object.
Perform the following configurations in system view.
Table 6-1 Create/delete an address object
Operation Command
object address object-name { address
Create an address object
mask | domain-name }
Delete an address object undo object address object-name
6-1
By default, no address object is created.
6.2.2 Refreshing DNS Objects
When the address corresponding to a domain name changes, use this command to
refresh the domain name information in DNS objects.
Table 6-2 Refresh DNS objects
Operation Command
Refresh DNS objects object refresh dns
6.2.3 Creating an Address Group Object
You can group multiple address objects into an address group object to simplify your
configuration and save time.
I. Creating/deleting an address group object
Table 6-3 Create/delete an address group object
Operation Command
object address-group
Create an address group object
object-group-name
undo object address-group
Delete an address group object
object-group-name
By default, no address group object is created.
II. Adding/deleting an address group member
After creating an address group object, you can add one or more existing address
objects to the address group object. An address object can be added to multiple
address group objects.
Perform the following configurations in address group object view.
Table 6-4 Add/delete an address group member
Operation Command
Add an address group member add object-name
Delete an address group member undo add object-name
6-2
By default, no address object is added to an address group object.
6.2.4 Creating a Service Object
Service object is another basic unit in object-oriented management. A service object

can be added into multiple service group objects and referenced in one or more flow
objects. Before creating a service group object or flow object, you must create a service
object.
The system supports service objects based on ICMP, TCP, UDP and other types of
protocols. You can group a combination of protocol number, source port, destination
port, or ICMP message type into a service object.
Table 6-5 Create/delete a service object
Operation Command
object service object-name protocol
{ tcp | udp } [ src-port src-port1 to
Create a TCP or UDP service object
src-port2 ] [ dst-port dst-port1 to
dst-port2 ]
object service object-name protocol

Create an ICMP service object
icmp type icmp-type code icmp-code
Create a service object of a protocol object service object-name protocol
other than TCP, UDP, and ICMP protocol-number
Delete a service object undo object service object-name
There are some predefined service objects in the system, which can be referenced
directly in service group objects or flow objects. You can view the predefined service
objects with the display object predefined service command.
6.2.5 Creating a Service Group Object
I. Creating/deleting a service group object
You can group multiple service objects into a service group object to simplify your
configuration tasks and save time.
Table 6-6 Create/delete a service group object
Operation Command
object service-group
Create a service group object
object-group-name
6-3
Operation Command
undo object service-group
Delete a service group object
object-group-name
By default, no service group object is created.
II. Adding/deleting a service group member
After creating a service group object, you can add one or more existing service objects
to the service group object. A service object can be added to multiple service group
objects.
Perform the following configurations in service group object view.
Table 6-7 Add/delete a service group member
Operation Command
Add a service group member add object-name
Delete a service group member undo add object-name
By default, no service object is added to a service group object.
6.2.6 Creating a Flow Object
I. Creating/deleting a flow object
A flow object represents the quintuplet, namely the protocol, source address,
destination address, source port, and destination port. Besides, a flow object can have
a time-range associated with it. This helps in remembering the quintuplet information
and simplifies the configuration and management.
Table 6-8 Create/delete a flow object
Operation Command
Create a flow object acl name acl-name
Delete a flow object undo acl name acl-name
By default, no flow object is created.
II. Adding/deleting a flow rule
A flow object can accommodate multiple rules, which work together to filter data flows.
Perform the following configurations in flow object view.
6-4
Table 6-9 Add/delete a flow rule
Operation Command
rule [ rule-id ] { permit | deny } [ source { src-name |
Add a rule to the flow src-group-name } ] [ destination { dst-name |
object dst-group-name } ] [ service { srv-name |
srv-group-name } ] [ time-range time-name ] [ logging ]
undo rule rule-id [ source ] [ destination ] [ service ]
Delete a rule
[ time-range ] [ logging ]
By default, no rule is added to a flow object.
6.2.7 Creating a Time Range Object
If you want some filtering policies to take effect in a certain period or some periods, you
can configure a time range or multiple time ranges and then reference the configured
time range(s) for a filtering policy to perform time range based filtering.
A time range object can include multiple time ranges of different types.
Table 6-10 Configure time range
Operation Command
time-range time-name { start-time to end-time
Create a time range object
end-time end-date ] | to end-time end-date }
undo time-range time-name [ start-time to end-time
Delete a time range object
end-time end-date ] | to end-time end-date ]
6.3 Referencing Flow Objects

6.3.1 Referencing a Flow Object for Packet Filtering
A packet filtering firewall can reference one or more flow object to filter its traffic.
Perform the following configurations in interface view.
Table 6-11 Apply a flow object to a packet filtering firewall
Operation Command
Apply a flow object to a packet filtering firewall packet-filter acl-name
firewall { inbound | outbound }
6-5
Operation Command
Remove the application of a flow object undo firewall packet-filter acl-name
in packet filtering { inbound | outbound }
By default, no flow object is applied to packet filtering.

For details about packet filtering firewall, refer to the chapter about Firewall
Configuration.
6.3.2 Referencing a Flow Object in NAT
NAT can reference one or more flow objects to determine the data flows to be serviced.
Perform the following configurations in interface view.
Table 6-12 Apply a flow object to NAT
Operation Command
nat outbound acl-name [ address-group
Apply a flow object to NAT
group-number [ no-pat ] ]
Remove the application of a undo nat outbound acl-name [ address-group
flow object in NAT group-number [ no-pat ] ]
By default, no flow object is applied to NAT.

For details about NAT, refer to the chapter about NAT Configuration.
6.4 Displaying and Debugging Object-Oriented Management

After the above configurations, you can execute the display commands in any view to
display the running status and verify your configurations. You can also execute the
reset command in user view to reset the statistics for object-oriented management or
execute the debugging command in user view to enable debugging for object-oriented
management.
Table 6-13 Display and debug object-oriented management
Operation Command
Display address object information display object address [ object-name ]
Display address group object display object address-group
information [ object-group-name ]
Display service object information display object service [ object-name ]
display object service-group

Display service group object information
[ object-group-name ]
6-6
Operation Command
Display predefined service object
display object predefined service
information
Display flow object information display acl { all | name acl-name }
Display time range object information display time-range { all | time-name }
Enable DNS debugging for address
debugging object dns
objects
Disable DNS debugging for address
undo debugging object dns
objects
reset acl counter { all | name
Clear the rule matching statistics
acl-name }
6-7
H3C SecPath Series Security Products Chapter 7 Transparent Firewall
Chapter 7 Transparent Firewall
Note:
Only H3C SecPath F100-C and F100-S firewalls support transparent firewall.
7.1 Transparent Firewall Overview

By default, the firewall operates in route mode. When it is transparent mode (bridge
mode), you cannot configured IP address for its interfaces, and the interfaces belong to
Layer 2 security zones, and all outside users connected to the interfaces which belong
to Layer 2 security zones are in the same subnet.
When packets are forwarded between the interfaces of Layer 2 security zones, the
system determines the outgoing interfaces based the MAC addresses borne in packets.
The firewall actually operates as a transparent bridge. Different from the bridge,
however, the firewall matches packets against the session table and ACL rules and
then determines if to forward the packets received to the upper layer for filtering other
further processing. Other attack prevention checks are also implemented on the firewall.
The transparent firewall supports ACL rule check, ASPF filtering, attack prevention
check, flow control, and other functions.
The transparent firewall is connected to the LAN on the data link layer, and no special
configuration is required for network client users, but treating them as common
Ethernet switches when connecting them into the network.
7.1.1 Obtaining MAC Address Table
The transparent firewall forwards packets based on the MAC address table, which
comprises two parts: MAC addresses and interfaces. Therefore, it must obtain the
mapping between them.
I. Broadcast packets
When connected with the physical network segment, the transparent firewall monitors
all Ethernet frames on the segment. After detecting an Ethernet frame on an interface,
the transparent firewall extracts its source MAC address and adds the mapping
between the MAC address and the interface receiving the frame into the MAC address
table. See Figure 7-1.
7-1
00e0.fcaa.aaaa 00e0.fcbb.bbbb
Workstation A Workstation B
Source Destination
00e0.fcbb.bbbb 00e0.fcaa.aaaa
Interface 1 Ethernet segment 1
00e0.fccc.cccc 00e0.fcdd.dddd
SecPath
Workstation C Workstation D
Interface 2
Ethernet segment 2
Figure 7-1 Broadcast packets
Stations A, B, C and D belong to two LANs. Ethernet segment 1 is connected to the

interface 1 on the transparent firewall; Ethernet segment 2 is connected to the interface
2 on the firewall. When station A sends an Ethernet frame to station B, both the
transparent firewall and station B can receive the frame.
II. Learning mapping between station A MAC address and the interface
After receiving the Ethernet frame, the transparent firewall knows station A is
connected to it through interface 1 (since it receives the frame from interface 1).
Therefore the transparent firewall adds the mapping between station A MAC address
and interface 1. See Table 7-2.
Workstation A Workstation C
Destination Source
Address table Ethernet segment 1

MAC Port Interface 1
00e0.fcaa.aaaa 1
SecPath 00e0.fcdd.ddd
00e0.fccc.cccc
d
Workstation D
Workstation B Interface 2
Ethernet segment 2
Figure 7-2 Learn mapping between station A MAC address and the interface
7-2
III. Learning mapping between station B MAC address and the interface
When station B returns the response to the Ethernet frame, the transparent firewall also
can detect the response and know that station B is connected to it through interface 1
(since it receives the frame from interface 1). Therefore the transparent firewall adds
the mapping between station B MAC address and interface 1. See Table 7-3.
Destination Source
00e0.f caa.aaaa 00e0.f cbb.bbbb

00e0.f caa.aaaa 1
00e0.fccc.cccc 00e0.f cbb.bbbb 1 SecPath 00e0.fcdd.dddd
Interface 2
Workstation D
Workstation C
Ethernet segment 2
Figure 7-3 Learn mapping between station B MAC address and the interface
The reverse MAC address learning continues till the transparent firewall obtains the
mapping entries between all MAC addresses (those of stations A, B, C and D in this
example) and the interfaces (here we assume that all stations are in operation).
7.1.2 Forwarding and Filtering
On the data link layer, the transparent firewall determines forwarding (or filtering)
actions based on the following three cases:
I. Forwarding after successful lookup on address table
When station A sends an Ethernet frame to station C, the transparent firewall looks up
on the address table and knows that station C corresponds to interface 2. It therefore
forwards the frame from interface 2. See Figure 7-4.
7-3
00e0.fcaa.aaaa
00e0.fcbb.bbbb
Workstation A
WorkStation B
Source Destination
00e0.f caa.aaaa 00e0.f ccc.cccc

00e0.fccc.cccc 00e0.f caa.aaaa 1 00e0.fcdd.dddd
00e0.f cbb.bbbb 1
SecPath
00e0.f ccc.cccc 2
00e0.f cdd.dddd 2 Workstation D
Interface 2
Workstation C Forward
Ethernet segment 2
Destination Source
00e0.f ccc.cccc 00e0.f caa.aaaa
Figure 7-4 Forwarding after successful lookup on address table
Note that the transparent firewall forwards to other interfaces or discard the broadcast
and multicast frames received on an interface.
II. No forwarding (filtering) after successful lookup on address table
When station A sends an Ethernet frame to station B, the transparent firewall filters out
and does not forward the frame since stations A and B are in the same network
segment.
00e0.fcaa.aaaa
00e0.fcbb.bbbb
Workstation A
WorkStation B
Source Destination

00e0.f cbb.bbbb 1
SecPath
00e0.f ccc.cccc 2
Do not Interface 2
Workstation C
Forward
Ethernet segment 2
Figure 7-5 No forwarding after successful lookup on address table
7-4
III. Forwarding after failed lookup on address table
If no mapping entry for station C MAC address is found in the MAC address table after
station A sends an Ethernet frame to station C, the transparent firewall forwards the
frame to all other interfaces except the source interfaces. In this case, the firewall works
as a HUB to guarantee that all packets are forwarded. See Figure 7-6.
Source Destination

00e0.f caa.aaaa 1
00e0.fccc.cccc 00e0.f cbb.bbbb 1 SecPath 00e0.fcdd.dd
dd
Interface 2
Ethernet segment 2
Figure 7-6 Forwarding after failed lookup on address table
7.2 Transparent Firewall Configuration

The following sections describe transparent firewall configuration tasks:
z Configuring Firewall Mode
z Configuring System IP Address
z Enabling/Disabling Dynamic ARP Learning
z Configuring Handling Approach for the Packets with Unknown MAC Address
z Configuring MAC Address-based ACLs
z Applying MAC Address-based ACL to the Interface
z Configuring Aging Time of the MAC Forwarding Table
z Defining Allowed Packet Types
z Configuring VLAN ID Transparent Transmission Function
7.2.1 Configuring Firewall Mode
7-5
Table 7-1 Configure firewall mode
Operation Command
Set the firewall in transparent mode firewall mode transparent
Set the firewall in route mode firewall mode route
Restore the default firewall mode undo firewall mode
By default, the firewall operates in route mode.
Note:
z When operating in transparent mode, the firewall automatically enables bridging
function. Configuring operating mode is available only on SecPath F Series
Firewalls.
z When operating in transparent mode, some attack prevention features and
commands become unavailable.
7.2.2 Configuring System IP Address
On the firewall in route mode, all interfaces work at Layer 3 and you can configure
Layer 3 attributes for them. When the firewall is in transparent mode, all interfaces
operate at Layer 2 and you cannot configure such Layer 3 attributes as IP address for
them. The firewall must own an IP address for management over it and offerings of
network services (Telnet or SNMP). To solve this problem, you can configure a system
IP address, instead of interface IP address, for the transparent firewall.
Table 7-2 Configure system IP address
Operation Command
Configure a system IP address for the firewall system-ip system-ip-address
firewall [ address-mask ]
Restore the default system IP address undo firewall system-ip
When a firewall works in transparent mode, the system creates a loopback0 interface
with IP address 169.0.0.1/8 in the case no loopback0 interface exists in the system, and
the IP address of loopback0 is adopted as the default system IP address; if loopback0
exists in the system, the IP address of the loopback0 is adopted as the system IP
address. The system IP address will be modified or deleted corresponding to the
modification or deletion operation on interface loopback0. You can modify the system
7-6
IP with the firewall system-ip command. When in route mode, you cannot configure
system IP address for the firewall.
7.2.3 Enabling/Disabling Dynamic ARP Learning
Communications between the intranet and outside networks must go through the
transparent firewall. ARP requests and responses are generated therefore when a
device accesses itself or originates a connection to an outside device. The transparent
can automatically learn ARP entries for later address translation.
Only limited ARP table entries are maintained on the firewall. When ARP Flood attacks
occur, the firewall may have too many ARP table entries and normal ARP resolution
processes will be affected. To avoid this problem, you can disable dynamic ARP
learning and manually configure static ARP entries.
Table 7-3 Enable/disable ARP learning
Operation Command
Enable dynamic ARP learning firewall arp-learning enable
Disable dynamic ARP learning undo firewall arp-learning enable
By default, ARP learning is enabled on the transparent firewall.
7.2.4 Configuring Handling Approach for the Packets with Unknown MAC
Address
Upon receiving the packets with unknown destination MAC address, the transparent
firewall cannot determine the outgoing interfaces for them. Therefore it handles these
packets in three ways:
z Drops the IP packets with unknown destination MAC address.
z Broadcasts the ARP request packet to the interfaces in a specific security zone
other than the interface receiving the packet, and drops the IP packets with
unknown MAC address. The transparent firewall saves the mapping between the
MAC address and the interface after receiving the ARP response packet.
z Floods the ARP request packet to the interfaces in a specific security zone other
than the interface receiving the packet. The transparent firewall saves the
mapping between the MAC address and the interface after receiving the ARP
response packet.
7-7
Table 7-4 Configure handling approach for the packets with unknown MAC address
Operation Command
Configure handling approach for unicast
IP packets, multicast and broadcast firewall unknown-mac { drop | flood }
packets with unknown MAC address
Configure handling approach for the
firewall unknown-mac [ unicast ]
unicast IP packets with unknown MAC
{ drop | arp | flood }
address
Configure handling approach for IP firewall unknown-mac { broadcast |
broadcast and multicast packets multicast } { drop | flood }
Restore the default handling approach
undo firewall unknown-mac [ unicast
for the packets with unknown MAC
| broadcast | multicast ]
address
By default, the firewall handles IP unicast packets, IP broadcast and multicast packets
with unknown IP addresses in flood mode.
7.2.5 Configuring MAC Address-based ACLs
You may create MAC-based ACLs and numbered them in the range 4000 to 4999.
Perform the following configuration in specified view.
Table 7-5 Configure MAC address-based ACLs
Operation Command
Configure a MAC address-based ACL
and enter the corresponding view acl number acl-number
(system view)
Delete the existing ACL undo acl { number acl-number | all }
rule [ rule-id ] { permit | deny } [ type

type-code type-wildcard | lsap
Create a MAC-based ACL rule (ACL lsap-code lsap-wildcard ] ] [ source-mac
view) sour-addr source-wildcard ] [ dest-mac
dest-addr dest-wildcard ] [ time-range
undo rule rule-id [ time-range ]
Delete an existing MAC-based ACL rule
[ logging ]
By default, no MAC-based ACL is created.
7.2.6 Applying MAC Address-based ACL to the Interface
7-8
Table 7-6 Apply MAC address-based ACL to the interface
Operation Command
Apply the MAC address-based ACL to firewall ethernet-frame-filter
the interface acl-number { inbound | outbound }
Remove the MAC address-based ACL undo firewall ethernet-frame-filter
on the interface { inbound | outbound }
By default, no MAC address-based ACL is applied to the interface.
Note:
z To apply MAC address-based ACLs to interfaces, you must set the firewall in
transparent mode. Otherwise, the system prompts error information.
z A firewall working in transparent mode performs Layer 2 filtering as well as Layer 3
filtering of packets.
7.2.7 Configuring Aging Time of the MAC Forwarding Table
Aging time of the MAC forwarding table refers to the lifetime of a MAC forwarding table
entry and is determined by the aging timer. When the timer expires, the corresponding
entry will be removed from the MAC forwarding table.
Table 7-7 Configure aging time of the MAC forwarding table
Operation Command
Configure the aging time of the MAC firewall transparent-mode aging-time
forwarding table seconds
Restore the default aging time of the undo firewall transparent-mode
MAC forwarding table aging-time
By default, the aging time of the MAC forwarding table is 300 seconds.
7.2.8 Defining Allowed Packet Types
You can configure the transparent firewall to allow BPDU (bridge protocol data unit),
DLSw (data link switching) or IPX (internetwork packet exchange) packets to pass.
7-9
Table 7-8 Define allowed packet types
Operation Command
Define the type of packets that are firewall transparent-mode transmit
allowed to pass the transparent firewall { bpdu | dlsw | ipx }
Define the type of packets that are not undo firewall transparent-mode
allowed to pass transmit { bpdu | dlsw | ipx }
By default, the firewall filters out all packets.
7.2.9 Configuring VLAN ID Transparent Transmission Function
VLAN ID transparent transmission indicates the interface forwards packets directly, and
does not process the VLAN ID of the packet. The packet VLAN ID will not be change
even the outbound interface has VLAN ID.
Table 7-9 Configure VLAN ID transparent transmission
Operation Command
Enable VLAN ID transparent bridge vlanid-transparent-transmit
transmission on the interface enable
Disable VLAN ID transparent undo bridge
transmission on the interface vlanid-transparent-transmit enable
By default, VLAN ID transparent transmission function is disabled on the interface.

If an Ethernet subinterface is configured with VLAN ID, the subinterface only receives
data from this VLAN. This determines for which VLAN the bridge-set transmits data.
After enabling VLAN ID transparent transmission function, the VLAN ID will not be
processed by the system, so the two switches on both sides can be regarded as
directly connected. You need to configure the same VLAN ID for the trunk port on each
switch to maintain normal communication.
Caution:
After enabling VLAN transparent transmission function on an interface, you need also
to configure interface-based ACL on the corresponding physical interface and
subinterface to filter packets received by this interface, avoiding packets from being
returned.
7-10
7.3 Displaying and Debugging Transparent Firewall

Use the commands listed in Table 7-10 to view the configuration information about
transparent firewall and enable debugging for transparent firewall configuration.
Execute the display command in any view to display the running status of transparent
firewall and thus verify the configuration.
Execute the reset command in user view to clear information.
Execute the debugging command in user view.
Table 7-10 Display and debug transparent firewall
Operation Command
Display the current firewall mode display firewall mode
display firewall ethernet-frame-filter
Display statistics on Ethernet frame
{ all | interface interface-type
filtering
interface-number }
Display transparent firewall display firewall transparent-mode
configuration config
display firewall transparent-mode
Display the MAC address table on the
address-table [ interface interface-type
transparent firewall
interface-number | mac mac-address ]
display firewall transparent-mode

Display traffic on the transparent firewall traffic [ interface interface-type
interface-number ]
Enable debugging for Ethernet frame debugging firewall eff [ interface
filtering interface-type interface-number ]
debugging firewall transparent-mode
Enable debugging for Ethernet frame
eth-forwarding [ interface
forwarding
Enable debugging for IP packet debugging firewall transparent-mode
forwarding ip-forwarding
reset firewall ethernet-frame-filter { all
Clear Ethernet frame filtering
| interface interface-type
information
interface-number }
reset firewall transparent-mode

Clear MAC address table address-table [ interface interface-type
interface-number ]
reset firewall transparent-mode
Clear traffic statistics on the transparent
traffic [ interface interface-type
firewall
interface-number ]
7-11
7.4 Typical Configuration Example

7.4.1 VLAN ID Transparent Transmission Configuration Example
As shown in Figure 7-7, PC1 and PC2 are connected to SW1 and SW2 respectively,
and they are bridged together by two firewalls. Ping PC2 on PC1. If the Ethernet
subinterfaces and E 0/1 of the two firewalls are enabled with VLAN ID transparent
transmission function, PC2 can receive the ping packets from PC1, and PC1 can
receive response packets from PC2.
II. Network diagram
PC1 PC2
SW1 SW2
E0/1 E0/1 E0/0.1

E0/0.1
vlan 2 vlan 2
SecPath1 SecPath2
Figure 7-7 Network diagram for enabling VLAN ID transparent transmission function
on Ethernet interface
# Enable transparent firewall on SecPath1.
<H3C> system-view
[H3C] firewall mode transparent
# Enable the VLAN ID transparent transmission function.

[H3C] interface Ethernet 0/0.1
[H3C-Ethernet0/0.1] vlan-type dot1q vid 2
[H3C-Ethernet0/0.1] bridge vlanid-transparent-transmit enable
[H3C-Ethernet0/0.1] quit
[H3C] interface Ethernet 0/1
[H3C-Ethernet0/1] bridge vlanid-transparent-transmit enable
7-12
# Apply an ACL to Ethernet0/0 to filter packets received through Ethernet0/0.1 and

prevent those packets from being forwarded back.
[H3C-acl-if-1000] rule deny interface Ethernet0/0.1
[H3C-acl-if-1000] rule permit interface any
[H3C-acl-if-1000] quit
[H3C-Ethernet0/0] firewall packet-filter 1000 outbound
# Enable transparent firewall on SecPath2.
<H3C> system-view
[H3C] firewall mode transparent

[H3C] interface Ethernet 0/0.1
[H3C-Ethernet0/0.1] vlan-type dot1q vid 2
[H3C-Ethernet0/0.1] bridge vlanid-transparent-transmit enable
[H3C-Ethernet0/0.1] quit
[H3C-Ethernet0/1] bridge vlanid-transparent-transmit enable
# Apply an ACL to Ethernet 0/0 to filter packets received through Ethernet 0/0/.1 and
prevent those packets from being forwarded back.
[H3C-acl-if-1000] rule deny interface Ethernet0/0.1
[H3C-acl-if-1000] rule permit interface any
[H3C-acl-if-1000] quit
[H3C-Ethernet0/0] firewall packet-filter 1000 outbound
7-13
H3C SecPath Series Security Products Chapter 8 Hybrid Mode Configuration
Chapter 8 Hybrid Mode Configuration
Note:
Only H3C SecPath F1000-A, F1000-S, F100-A, F100-M, and F100-E firewalls support
hybrid mode.
8.1 Introduction to Bridge

By default, the firewall operates in route mode. When it is in bridge mode, you cannot
configure IP address for its interfaces, and the interfaces belong to Layer 2 security
zones, and all outside users connected to the interfaces which belong to Layer 2
security zones are in the same subnet.
When packets are forwarded between the interfaces of Layer 2 security zones, the
system determines the outgoing interfaces based the MAC addresses borne in packets.
The firewall actually operates as a transparent bridge. Different from the bridge,
however, the firewall matches packets against the session table and ACL rules and
then determines if to forward the packets received to the upper layer for filtering other
further processing. Other attack prevention checks are also implemented on the firewall.
The bridge firewall supports ACL rule check, ASPF filtering, attack prevention check,
flow control, and other functions.
The bridge firewall is connected to the LAN on the data link layer, and no special
configuration is required for network client users, but treating them as common
Ethernet switches when connecting them into the network.
8.1.1 Obtaining MAC Address Table
The bridge firewall forwards packets based on the MAC address table, which
comprises two parts: MAC addresses and interfaces. Therefore, it must obtain the
mapping between them.
I. Broadcast packets
When connected with the physical network segment, the bridge firewall monitors all
Ethernet frames on the segment. After detecting an Ethernet frame on an interface, the
transparent firewall extracts its source MAC address and adds the mapping between
the MAC address and the interface receiving the frame into the MAC address table.
See Figure 8-1.
8-1
Source Destination
Interface 1 Ethernet segment 1
00e0.fccc.cccc 00e0.fcdd.dddd
SecPath
Interface 2
Ethernet segment 2
Figure 8-1 Broadcast packets
Stations A, B, C and D belong to two LANs. Ethernet segment 1 is connected to the

interface 1 on the bridge firewall; Ethernet segment 2 is connected to the interface 2 on
the firewall. When station A sends an Ethernet frame to station B, both the bridge
firewall and station B can receive the frame.
II. Learning mapping between station A MAC address and the interface
After receiving the Ethernet frame, the bridge firewall knows station A is connected to it
through interface 1 (since it receives the frame from interface 1). Therefore the bridge
firewall adds the mapping between station A MAC address and interface 1. See Figure
8-2.
Workstation A Workstation C
Destination Source

00e0.fcaa.aaaa 1
SecPath 00e0.fcdd.ddd
00e0.fccc.cccc
d
Workstation D
Workstation B
Interface 2
Ethernet segment 2
Figure 8-2 Learn mapping between station A MAC address and the interface
8-2
III. Learning mapping between station B MAC address and the interface
When station B returns the response to the Ethernet frame, the bridge firewall also can
detect the response and know that station B is connected to it through interface 1 (since
it receives the frame from interface 1). Therefore the bridge firewall adds the mapping
between station B MAC address and interface 1. See Figure 8-3.
Destination Source
00e0.f caa.aaaa 00e0.f cbb.bbbb

00e0.f caa.aaaa 1
00e0.fccc.cccc 00e0.f cbb.bbbb 1 SecPath 00e0.fcdd.dddd
Interface 2
Workstation D
Workstation C
Ethernet segment 2
Figure 8-3 Learn mapping between station B MAC address and the interface
The reverse MAC address learning continues till the firewall in bridge obtains the
mapping entries between all MAC addresses (those of stations A, B, C and D in this
example) and the interfaces (here we assume that all stations are in operation).
8.1.2 Forwarding and Filtering
On the data link layer, the bridge firewall determines forwarding (or filtering) actions
based on the following three cases:
I. Forwarding after successful lookup on address table
When station A sends an Ethernet frame to station C, the bridge firewall looks up on the
address table and knows that station C corresponds to interface 2. It therefore forwards
the frame from interface 2. See Figure 8-4.
8-3
00e0.fcaa.aaaa
00e0.fcbb.bbbb
Workstation A
WorkStation B
Source Destination

00e0.f cbb.bbbb 1
SecPath
00e0.f ccc.cccc 2
Interface 2
Workstation C Forward
Ethernet segment 2
Destination Source
00e0.f ccc.cccc 00e0.f caa.aaaa
Figure 8-4 Forwarding after successful lookup on address table
Note that the bridge firewall forwards to other interfaces or discard the broadcast and
multicast frames received on an interface.
II. No forwarding (filtering) after successful lookup on address table
When station A sends an Ethernet frame to station B, the bridge firewall filters but does
not forward the frame since stations A and B are in the same network segment.
00e0.fcaa.aaaa
00e0.fcbb.bbbb
Workstation A
WorkStation B
Source Destination

00e0.f cbb.bbbb 1
SecPath
00e0.f ccc.cccc 2
Do not Interface 2
Workstation C
Forward
Ethernet segment 2
Figure 8-5 No forwarding after successful lookup on address table
8-4
III. Forwarding after failed lookup on address table
If no mapping entry for station C MAC address is found in the MAC address table after
station A sends an Ethernet frame to station C, the bridge firewall forwards the frame to
all other interfaces except the source interfaces. In this case, the firewall works as a
HUB to guarantee that all packets are forwarded. See Figure 8-6.
Source Destination

00e0.f caa.aaaa 1
1 SecPath 00e0.fcdd.dd
00e0.fccc.cccc 00e0.f cbb.bbbb
dd
Interface 2
Ethernet segment 2
Figure 8-6 Forwarding after failed lookup on address table
8.2 Configuring the Bridging Functions

The bridge configuration tasks are described in the following sections:
1) Basic Bridge Configuration
z Enabling/disabling bridging
z Enabling/disabling a bridge-set
z Adding interfaces to a bridge-set
2) Configuring the Bridging Address Table
z Configuring static address entries
z Enabling/disabling dynamic address learning
z Configuring the aging timer of the dynamic address table
3) Configuring Ethernet Frame Filtering
z Creating a MAC Address-based ACL
z Applying a MAC-based ACL in the inbound/outbound direction of the interface
4) Configuring the Routing Function of the Bridge
z Configuring a bridge-template interface
z Configuring the MAC address of a bridge-template interface manually
5) Configuring a Bridge-Set to Bridge for the Network Layer
6) Defining Allowed Packet Types
7) Configuring Handling Approach for the Packets with Unknown MAC Address
8) Configuring VLAN ID Transparent Transmission Function
8-5
8.2.1 Basic Bridge Configuration
I. Enabling/disabling bridging
Table 8-1 Enable/disable bridging
Operation Command
Enable bridging bridge enable
Disable bridging undo bridge enable
By default, bridging is disabled.
II. Enabling/disabling a bridge-set
As bridge-sets are independent, packets cannot be transmitted between ports that

belong to different bridge-sets. A packet that is received on a bridging port can only be
sent out through another port in the same bridge-set. The interfaces on the firewall can
join only one bridge-set.
Table 8-2 Enable/disable a bridge-set
Operation Command
Enable a specified bridge-set. bridge bridge-set enable
Disable a specified bridge-set. undo bridge bridge-set enable
By default, a bridge-set is disabled.
III. Adding interfaces to a bridge-set
Ethernet interfaces, Ethernet subinterfaces and Tunnel interfaces can be assigned into
bridge-sets. However, an interface cannot be assigned to two or more bridge-sets.
Table 8-3 Add the port to a bridge-set
Operation Command
Add the port to a bridge-set bridge-set bridge-set
Remove the port from the bridge-set undo bridge-set bridge-set
By default, the port is not added to any bridge-set.
8-6
Layer 3 attributes of a port in a bridge-set do not take effect.
Note:
z The interfaces in the same bridge-set must be assigned to the security zone for
communication to each other.
z Only the bridge-template interface is assigned to the security zone can the
interfaces in different bridge-sets communicate with each other.
8.2.2 Configuring the Bridging Address Table
The bridging address table records the association between destination MAC
addresses and the ports for the bridge to make forwarding decision.
I. Configuring static address entries
Normally, a bridging table is dynamically generated according to the correlation

between the MAC addresses and the ports obtained by the bridge. However, there are
still some static entries in the bridging address table, which are manually configured
and maintained by the administrators and will not age out forever.
Table 8-4 Configure a static address entry
Operation Command
Configure a static bridge bridge-set mac-address mac-address { permit
address entry interface interface-type interface-number | deny }
Delete a static address undo bridge bridge-set mac-address mac-address
entry [ interface interface-type interface-number ]
By default, frames are forwarded according to the dynamic address table.
II. Enabling/disabling dynamic address learning
8-7
Table 8-5 Enable/disable dynamic address learning
Operation Command
Enable dynamic address learning bridge bridge-set learning
Disable dynamic address learning undo bridge bridge-set learning
By default, dynamic address learning is enabled.
III. Configuring the aging timer of the dynamic address table
The aging timer of the dynamic address table controls the aging time of an entry before
it is deleted from the table. The entry is deleted when the timer times out.
Table 8-6 Configure the aging timer of the dynamic address table
Operation Command
Configure the aging timer of the dynamic
bridge aging-time seconds
address table.
Restore the default aging timer value. undo bridge aging-time
The aging timer of the dynamic address table is in the range 10 to 1000000 seconds
and defaults to 300 seconds.
Note:
When it has learned an MAC address unavailable in the address table, a bridge-set will
creates a new entry and initialize the aging timer:
z If it has not received any packets from this MAC address before the aging timer
expires, the bridge-set will delete the entry after the aging timer times out.
z If it has received packets from this MAC address before the aging timer expires, the
bridge-set will initialize the aging timer after the aging timer times out.
8.2.3 Configuring Ethernet Frame Filtering
I. Creating a MAC Address-based ACL
Perform the following configuration in system view (for the command acl) and ACL view
(for the command rule).
8-8
Table 8-7 Create a MAC address-based ACL
Operation Command
Configure a MAC address-based ACL
and enter the corresponding view acl number acl-number
(system view)
Delete the existing ACL undo acl { number acl-number | all }
rule [ rule-id ] { permit | deny } [ type
type-code type-wildcard | lsap
Create a MAC-based ACL rule (ACL lsap-code lsap-wildcard ] [ source-mac
view) sour-addr source-wildcard ] [ dest-mac
dest-addr dest-wildcard ] [ time-range
undo rule rule-id [ time-range ]
Delete an existing MAC-based ACL rule
[ logging ]
By default, no MAC-based ACL is created.
II. Applying a MAC-based ACL in the inbound/outbound direction of the

interface
Table 8-8 Apply MAC address-based ACLs to the interface
Operation Command
Apply a MAC-based ACL on the inbound firewall ethernet-frame-filter
direction of the interface acl-number { inbound | outbound }
Remove the MAC-based ACL applied in undo firewall ethernet-frame-filter
the inbound direction of the interface { inbound | outbound }
By default, no MAC address-based ACL is applied to the interface.
Note:
z To apply MAC address-based ACLs to interfaces, the interfaces must be assigned
to bridge-sets. Otherwise, the system prompts error information.
z Both Layer 2 filtering and Layer 3 filtering will be performed for packets on an
interfaces that is in a bridge-set.
8-9
8.2.4 Configuring the Routing Function of the Bridge
Bridge routing provides forwarding that integrates routing and bridging. For some
particular protocol data units (PDUs), if the communication is conducted between
bridging ports, they are bridged; if the communication is conducted with a network
outside the bridge-set, they are routed.
I. Configuring a bridge-template interface
A bridge-template interface exists on the firewall. It does not support bridging; but on
the firewall it represents the bridge-set associated to a routing interface and carries the
number of the bridge-set. Bridge-template interfaces are virtual routing interfaces on
which you can configure network layer attributes. For each bridge-set, you can assign
only one bridge-template interface.
Table 8-9 Configure a bridge-template interface
Operation Command
Create a bridge-template interface and
connect the specified bridge-set to the interface bridge-template bridge-set
network of the route
undo interface bridge-template
Delete a bridge-template interface
bridge-set
II. Configuring the MAC address of a bridge-template interface manually
When the devices on each side of a link are both SecPath series firewalls, they will
conflict with each other because the system automatically creates the same MAC
address on the bridge-template interfaces. You are recommended, therefore, to
manually specify a MAC address to the bridge-template interface.
Perform the following configuration in bridge-template view.
Table 8-10 Configure the MAC address of a bridge-template interface manually
Operation Command
Configure the MAC address of a
mac-address H-H-H
bridge-template interface
Delete the manually configured MAC address undo mac-address
By default, the bridge-template interface uses the automatically created MAC address.
8.2.5 Configuring a Bridge-Set to Bridge for the Network Layer Protocol
8-10
Table 8-11 Configure a bridge-set to bridge for the network layer protocol
Operation Command
Enable the bridging function of a
bridge bridge-set bridging { ip | ipx }
bridge-set for the network layer protocol
Disable the bridging function of a undo bridge bridge-set bridging { ip |
bridge-set for the network layer protocol ipx }
By default, bridging is enabled and routing is disabled.
8.2.6 Defining Allowed Packet Types
You can configure the bridge to allow BPDU (bridge protocol data unit), DLSw (data link
switching) or IPX (internetwork packet exchange) packets to pass.
Table 8-12 Define allowed packet types
Operation Command
Define the type of packets that are
bridge permit { bpdu | dlsw | ipx }
allowed to pass the bridge
Define the type of packets that are not undo bridge permit { bpdu | dlsw |
allowed to pass ipx }
By default, the bridge allows BPDU, DLSw, and IPX packets to pass.
8.2.7 Configuring Handling Approach for the Packets with Unknown MAC
Address
Upon receiving the packets with unknown destination MAC address, the bridge cannot
determine the outgoing interfaces for them. Therefore it handles these packets in three
ways:
z Drops the IP packets with unknown destination MAC address.
z Broadcasts the ARP request packet to the interfaces in a specific security zone
other than the interface receiving the packet, and drops the IP packets with
unknown MAC address. The bridge saves the mapping between the MAC address
and the interface after receiving the ARP response packet.
z Floods the ARP request packet to the interfaces in a specific security zone other
than the interface receiving the packet. The bridge saves the mapping between
the MAC address and the interface after receiving the ARP response packet.
8-11
Table 8-13 Configure handling approach for the IP packets with unknown MAC
address
Operation Command
Configure handling approach for IP
unicast packets, multicast and bridge bridge-set firewall
broadcast packets with unknown MAC unknown-mac { drop | flood }
address
Configure handling approach for the IP bridge bridge-set firewall
unicast packets with unknown MAC unknown-mac unicast { drop | arp |
address flood }
bridge bridge-set firewall

Configure handling approach for IP
unknown-mac { broadcast |
broadcast and multicast packets
multicast } { drop | flood }
Restore the default handling approach undo bridge bridge-set firewall
for the packets with unknown MAC unknown-mac [ unicast | broadcast |
address multicast ]
By default, the bridge-set handles IP unicast packets, IP broadcast and multicast

packets with unknown IP addresses in flood mode.
8.2.8 Configuring VLAN ID Transparent Transmission Function
VLAN ID transparent transmission indicates the interface forwards packets directly, and
does not process the VLAN ID of the packet.
With VLAN ID transparent transmission enabled, the non-Ethernet outbound interface
in a bridge-set can forward packets with VLAN ID. The packet VLAN ID will not be
changed even the outbound interface has VLAN ID for VLAN separation.
Table 8-14 Configure VLAN ID transparent transmission
Operation Command
Enable VLAN ID transparent bridge vlanid-transparent-transmit
transmission on the interface enable
Disable VLAN ID transparent undo bridge
transmission on the interface vlanid-transparent-transmit enable
By default, VLAN ID transparent transmission function is disabled on the interface.
8.3 Displaying and Debugging Bridging Information

After you complete the aforesaid configurations, execute display command in any view
to view the operating state of the bridge and verify effect of the configurations.
8-12
Execute the debugging command in user view for the debugging of bridge and the
reset command in user view to clear the related information.
Table 8-15 Display and debug bridges
Operation Command
debugging bridge eth-forwarding
Enable the Ethernet frame forwarding
debugging of the bridge
interface-number ]
undo debugging bridge

Disable the Ethernet frame forwarding
eth-forwarding [ interface
Enable the IP packet forwarding
debugging bridge ip-forwarding
Disable the IP packet forwarding
undo debugging bridge ip-forwarding
Display information on one or all the display bridge information
bridge-sets in the bridge module [ bridge-set bridge-set ]
display bridge address-table

Display information on the bridging [ bridge-set bridge-set | interface
address table interface-type interface-number | mac
mac-address ] [ static | dynamic ]
display bridge traffic [ bridge-set
Display traffic statistics on one or all
bridge-set | interface interface-type
interfaces in a bridge-set
interface-number ]
Display statistics of filtering Ethernet display firewall ethernet-frame-filter
frames on one or all interfaces in a { all | interface interface-type
bridge-set interface–number }
reset bridge address-table
Clear the MAC address forwarding table [ bridge-set bridge-set | interface
reset bridge traffic [ bridge-set

Clear traffic statistics on one or all
bridge-set | interface interface-type
interfaces in a bridge-set
interface-number ]
reset firewall ethernet-frame-filter { all
Clear statistics about ACL-based
| interface interface-type
filtering
interface–number }
8.4 Bridging Configuration Examples

8.4.1 Implementing Integrated Routing and Bridging
Ethernet 1/0/0 and Ethernet 2/0/0 of the firewall are assigned to the bridge-set. A
8-13
bridge-template interface is used to route packets between the bridge-set and Ethernet
0/0/0.
II. Network diagram
Bridge-template 1
(1.1.1.1)
Bridge-set1
E1/0/0
E0/0/0
2.1.1.1
E2/0/0
Figure 8-7 Network diagram for implementing integrated routing and bridging
# Enable the bridge.

[H3C] bridge enable
# Add interfaces to the bridge-set1.

[H3C-Ethernet1/0/0] bridge-set 1
# Create and configure a bridge-template interface.

[H3C] interface Bridge-template 1
[H3C-Bridge-Template1] ip address 1.1.1.1 255.255.255.0
[H3C-Bridge-Template1] quit
# Configure Ethernet 0/0/0.

8.4.2 Implementing Bridging on Ethernet Subinterfaces
SecPathA and SecPathB are connected through only one physical link. Enable bridging
8-14
on the sub-interfaces so that the two bridge-sets established on the SecPathA and
SecPathB can be interconnected.
II. Network diagram
e1/0/0 e1/0/0
e0/0/0.1 e0/0/0.1
SecPathA SecPathB
e0/0/0.2 e0/0/0.2
e2/0/0 e2/0/0
Figure 8-8 Network diagram for bridging on subinterfaces
1) Configure SecPathA
# Enable the bridging function on the firewall.
[H3C] bridge enable
# Enable bridge-set 1 and bridge-set 2.

[H3C] bridge 1 enable
# Add Ethernet interfaces and sub-interfaces to the corresponding bridge-sets.

[H3C] interface Ethernet 0/0/0.1
[H3C-Ethernet0/0/0.1] bridge-set 1
[H3C-Ethernet0/0/0.1] quit
2) Configure SecPathB
# Enable the bridging function on the firewall.
8-15
[H3C] bridge enable
# Enable bridge-set 1 and bridge-set 2.

# Add Ethernet interfaces and sub-interfaces to the corresponding bridge-sets.

8.4.3 VLAN ID Transparent Transmission
PC1 and PC2 are connected to SW1 and SW2 respectively, and they are bridged
together by two firewalls. Ping PC2 on PC1. If the Ethernet subinterfaces and E0/0/1 of
the two firewalls are enabled with VLAN ID transparent transmission function, PC2 can
receive the ping packets from PC1, and PC1 can receive response packets from PC2.
8-16
II. Network diagram
PC1 PC2
SW1 SW2
E0/0/1 E0/0/1 E0/0/0.1

E0/0/0.1
vlan 2 vlan 2
SecPath1 SecPath2
Figure 8-9 Network diagram for enabling VLAN ID transparent transmission function
on Ethernet interface
# Enable the bridging function on SecPath1.
<H3C> system-view
[H3C] bridge enable
# Enable bridge-set2.

[H3C-Ethernet0/0/0.1] bridge vlanid-transparent-transmit enable
[H3C-Ethernet0/0/1] bridge vlanid-transparent-transmit enable
# Enable the bridging function on SecPath2.
<H3C> system-view
[H3C] bridge enable
# Enable bridge-set2.
8-17

[H3C-Ethernet0/0/0.1] bridge vlanid-transparent-transmit enable
[H3C-Ethernet0/0/1] bridge vlanid-transparent-transmit enable
8-18
H3C SecPath Series Security Products Chapter 9 PKI Configuration
Chapter 9 PKI Configuration
9.1 PKI Overview

9.1.1 Introduction
Public key infrastructure (PKI) is a system that uses public key technology and digital
certificate to protect system security and authenticates digital certificate users. It
provides a whole set of security mechanism by combining software/hardware systems
and security policies together. PKI uses certificates to manage public keys: It binds
user public keys with other identifying information through a trustworthy association, so
that online authentication is possible. PKI provides safe network environment and
enables an easy use of encryption and digital signature technologies under many
application environments, to assure confidentiality, integrity and validity of online data.
A PKI system consists of public key algorithm, certificate authority, registration authority,
digital certificate, and PKI repository, as shown in Figure 9-1.
PKI application
Digital certificate
CA RA PKI repository
Figure 9-1 PKI components block diagram
Certificate authority issues and manages certificates. Registration authority

authenticates user identity and manages certificate revocation list. PKI repository
stores and manages such information as certificates and logs, and provides query
function. Digital certificate, also called Public Key Certificate (PKC), underlies the
security of PKI system and the trust in application. Adopting an authentication
technology based on public key technology, it is a file duly signed by certificate authority
that contains public key and owner information. It can be used as an identity proof for
online information exchange and commercial activities. A certificate has its lifetime,
which is specified in issuing. Of course, certificate authority can revoke a certificate
before its expiration date.
9-1
9.1.2 Terminology
z Public key algorithm: Key algorithm that involves different encryption key and
decryption key. A pair of keys is generated for each user: One is publicized as
public key; the other is reserved as private key. The information encrypted by one
key has to be decrypted by the other; the key pair therefore is generally used in
signature and authentication. In communication, if the sender signs with its private
key, the receiver needs to authenticate this signature with the sender’s public key.
If the sender encrypt the information with the receiver’s public key, then only the
receiver’s private is capable of decryption.
z Certificate authority (CA): Trustworthy entity issuing certificates to persons, PCs or
any other entities. CA deals with certificate requests, and checks applicant
information according to certificate management policy. Then it signs the
certificate with its private key and issues the certificate.
z Registration authority (RA): Extension of CA. It forwards the entities' certificate
requests to CA, and digital certificates and certificate revocation list to directory
server, for directory browsing and query.
z Light-weight directory access protocol (LDAP) server: LDAP provides a means to
access PKI repository, with the purpose of accessing and managing PKI
information. LDAP server supports directory browsing and enlists the user
information and digital certificates from a RA server. Then the user can get his or
others’ certificates when accessing the LDAP server.
z Certificate revocation list (CRL): A certificate has its lifetime, but CA can revoke a
certificate before its expiration date if the private key leaks or if the service ends.
Once a certificate is revoked, a CRL is released to announce its invalidity, where
lists a set of serial numbers of invalid certificates. CRL, stored in LDAP server,
provides an effective way to check the validity of certificates, and offers centralized
management of user notification and other applications.
9.1.3 Applications
PKI includes a set of security services provided using the technologies of public key
and X.509 certification in distributed computing systems. It can issue certificates for
various purposes, such as Web user identity authentication, Web server identity
authentication, secure Email using S/MIME (secure/multipurpose internet mail
extensions), virtual private network (VPN), IP security, Internet key exchange (IKE),
secure sockets layer/transport layer security (SSL/TLS) and digital signature. One CA
can issue certificates to another CA, to establish certification hierarchies.
9-2
9.1.4 Configuration Task List
PKI configuration includes applying to CA for a local certificate for a designated device
and authenticating validity of the certificate. The configuration involves:
z PKI certificate request
z PKI certificate validation
z Display and debug
9.2 Certificate Request Configuration

9.2.1 Certificate Request Overview
Certificate request is a process when an entity introduces itself to CA. The identity
information the entity provides will be contained in the certificate issued later. CA uses a
set of criteria to check applicant creditability, request purpose and identity reliability, to
ensure that certificates are bound to correct identity. Offline and non-auto out-of-band
(phone, storage disk and Email, for example) identity checkup may be required in this
process. If this process goes smooth, CA issues a certificate to the user and displays it
along with some public information on the LDAP server for directory browsing. The user
can then download its own public-key digital certificate from the notified position, and
obtain those of others through the LDAP server.
The following are configuration tasks for implementing local certificate request:
z Entering PKI domain view
z Specifying a trustworthy CA
z Configuring servers for certificate request
z Configuring entity name space
z Creating a local public — private key pair
z Setting request polling interval and count
z Configuring certificate request mode
z Delivering a certificate request manually
z Retrieving a certificate
9.2.2 Entering PKI Domain View
A PKI domain manages in a unified way a group of PKI users who trust a same third
trustworthy organization. That means, it suffices with the trust each member lays on CA;
no trust between the group members is required. It serves a lot in relieving system load
and extending the capability of PKI certificate system.
For the configuration of domain parameters, you should enter the PKI domain view.
9-3
Table 9-1 Enter PKI domain view
Operation Command
Enter a designated PKI domain view pki domain name
Delete a designated PKI domain and its
undo pki domain name
relative information
By default, no PKI domain is specified.
Note:
Currently, one device supports only two PKI domains, so you need to delete one of the
existing two domains first by using undo command then create a new domain.
9.2.3 Specifying a Trustworthy CA
Trustworthy CAs function to provide registration service and issue certificates for
entities. They are essential to PKI. Only when a CA trusted by everyone is available,
can users enjoy the security services with public key technology.
Perform the following configuration in PKI domain view.
Table 9-2 Specify trustworthy CA
Operation Command
Specify a trustworthy CA ca identifier name
Delete the trustworthy CA undo ca identifier
By default, no trustworthy CA is specified.
Note:
The standard set CA uses in request processing, certificate issuing and revoking, and
CRL releasing is called CA policy. In general, CA uses files, called certification practice
statements (CPS), to advertise its policy. CA policy can be obtained in out-of-band or
other mode. You are recommended to understand CA policies before choosing a CA,
for different CAs may use different methods to authenticate the public key -- subject
binding.
9-4
9.2.4 Configuring Servers for Certificate Request
I. Configuring the entity used to apply for a certificate
When you send a certificate application request to the CA, an entity name must be
specified to indicate you identity.
Table 9-3 Configure the entity used to apply for a certificate
Operation Command
Configure the entity used to apply for a
certificate request entity entity-name
certificate.
Cancel the configured entity used to
undo certificate request entity
apply for a certificate.
By default, no entity is specified to apply for a certificate.
Note:
For more information about entities (entity-name), see section 9.2.5 “Configuring Entity
Name Space.”
II. Specifying a registration organization
Registration management is often implemented by an independent registration

authority (RA), which handles certificate requests, examines entity qualification and
decides whether a CA should issue a digital certificate. As you can se, an RA examines
entity qualification but does not issue certificates, as is performed by a CA. Sometimes
no independent RA is set. It does not mean that registration function of PKI is disabled,
since CA takes over the registration management.
Table 9-4 Specify a registration organization
Operation Command
Choose between CA and RA as the certificate request from { ca | ra } entity
registration organization entity-name
Delete the registration organization undo certificate request from { ca | ra }
By default, no registration organization is specified.

PKI security policy recommends the involvement of RA.
9-5
III. Configuring registration server location
Before entities can request certificates, the URL of a registration server must be
specified for them so that they can present to this server certificate requests using
simple certification enrollment protocol (SCEP, a protocol to communicate with
certification authorities).
Table 9-5 Specify registration server location
Operation Command
Specify the location of a registration server certificate request url string
Delete the location setting undo certificate request url
By default, no registration server location is specified.
IV. Configuring LDAP server IP
Storage of entity certificates and CRL information is essential to a PKI system. Usually,
this is done using a LDAP directory server.
Table 9-6 Specify LDAP server IP
Operation Command
ldap-server ip ip-address [ port
Specify the IP address for LDAP server
port-num ] [ version version-number ]
Delete the IP address setting undo ldap-server ip
By default, no LDAP server is specified.
V. Configuring fingerprint for root certificate authentication
When the firewall gets an identity certificate from the CA, it will need the CA root
certificate to make sure that the identity certificate is true and legal. In addition, when
the firewall obtains CA root certificate, it needs to validate its fingerprint, that is, the
hash value of the root certificate contents, which is unique for each certificate. If the
fingerprint is different with that configured with the command below, the firewall denies
the root certificate. The fingerprint can be MD5 or SHA1 format.
9-6
Table 9-7 Configure the fingerprint for root certificate authentication
Operation Command
Configure the fingerprint for root root-certificate fingerprint { md5 |
certificate authentication. sha1 } string
Cancel the configured fingerprint for root
undo root-certificate fingerprint
certificate authentication.
By default, no fingerprint is configured for root certificate authentication.

For an MD5 fingerprint, the value for the string argument must consist of 32 characters
and be entered in hexadecimal format.
For an SHA1 fingerprint, the value of the string argument must consist of 40 characters
and be entered in hexadecimal format.
9.2.5 Configuring Entity Name Space
I. Name space overview
Entity name space should be taken into account when setting up PKI. In a certificate,
the public key and owner name must be consistent. Each CA details about an entity
with the information it considers important. A unique identifier (also called
DN-distinguished name) can be used to identify an entity. It consists of several parts,
such as user common name, organization, country and owner name. It must be unique
among the network.
The entity DN configuration in PKI entity view comprises the configuration of:
z PKI entity name
z Entity FQDN
z Country code
z State name
z Geographic locality
z Organization name
z Organization unit name
z Common name of the entity
z IP address of the entity
9-7
Note:
Entity configuration information must comply with the CA certificate issue policy. This
determines which entity DN configuration tasks must be performed and which are
optional in configuring entity parameters. Otherwise, certificate request may be
rejected.
II. Specifying a PKI entity name
In PKI entity view, you can configure the attributes of entity DN.
Table 9-8 Specify an entity name
Operation Command
Specify an entity name and enter the entity view pki entity name-str
Delete the entity name and relative parameters undo pki entity name-str
By default, no entity name is given.
Note:
z The entity name must comply with the entity name in the certificate request from
{ ca | ra } entity entity-name command used by the RA. Otherwise, the certificate
request is rejected. name-str is just for the convenience in using, but does not
appear as a field of the certificate.
z Windows 2000 CA server has a requirement on the length of the certificate data.
When the entity length exceeds the requirement, the certificate request is rejected.
III. Configuring the entity FQDN
Fully qualified domain name (FQDN) is the unique identifier of the entity among the
network, for example, Email address. It is often in the format of user.domain and can be
resolved to IP address. FQDN is equivalent to IP address in function. This configuration
is optional.
Perform the following configuration in PKI entity view.
9-8
Table 9-9 Configure the entity FQDN
Operation Command
Configure the entity FQDN fqdn name-str
Delete the entity FQDN undo fqdn
By default, no FQDN is configured for the entity.
IV. Configuring the country code for the entity
Table 9-10 Configure the country code for the entity
Operation Command
Configure the country code country country-code-str
Delete the country setting undo country
By default, no country code is specified for the entity.
Note:
Country code uses two standard characters, for example, CN for China and US for the
United States.
V. Configuring the state name for the entity
Table 9-11 Configure the state name for the entity
Operation Command
Configure the state name state state-str
Delete the state setting undo state
By default, no state name is specified for the entity.
VI. Configuring the geographic locality for the entity
9-9
Table 9-12 Configure the geographic locality for the entity
Operation Command
Configure the geographic locality locality locality-str
Delete the locality setting undo locality
By default, no geographic locality is specified for the entity.
VII. Configuring the organization name for the entity
Table 9-13 Configure the organization name for the entity
Operation Command
Configure the organization name organization org-str
Delete the organization setting undo organization
By default, no organization name is specified for the entity.
VIII. Configuring the organization unit name for the entity
This optional field specifies to which of the many units of an organization this entity
belongs.
Table 9-14 Configure the organization unit name for the entity
Operation Command
Configure the organization unit name organization-unit org-unit-str
Delete this name specification undo organization-unit
By default, no organization unit name is specified for the entity.
IX. Configuring the common name for the entity
9-10
Table 9-15 Configure the common name for the entity
Operation Command
Configure the common name common-name name-str
Delete the common name undo common-name
By default, no common name is specified for the entity.
X. Configuring the IP address for the entity
It is an optional operation, with the same function as specifying the entity FQDN.
Table 9-16 Configure the IP address for the entity
Operation Command
Configure the IP address ip ip-address
Delete the IP address undo ip
By default, no IP address is specified for the entity.
9.2.6 Creating a Local Public – Private Key Pair
A pair of keys is generated during certificate request: one public and the other private.
The private key is held by the user, while the public key and other information are
transferred to CA center for signature and then the generation of the certificate. Each
CA certificate has a lifetime that is determined by the issuing CA. When the private key
leaks or the current certificate is about to expire, you have to delete the old key pair.
Then another key pair can be generated for a new certificate.
If an RSA key pair already exists when you create a local key pair, the system prompts
whether to replace it. Each key pair is named using this convention: Firewall name +
host. The minimum length of a host key is 512 bits and the maximum length is 2048
bits.
Table 9-17 Create and destroying an RSA key pair
Operation Command
Create an RSA key pair rsa local-key-pair create
Destroy an RSA key pair rsa local-key-pair destroy
9-11
By default, there is no existent local RSA key pair.
Caution:
z If a local certificate already exists, you are not recommended to create another key
pair. To ensure consistency between key pair and existing certificate, you should
first delete the existing certificate and then create a new key pair.
z If a local RSA key pair exists, the newly-generated key pair will overwrite the
existing one.
z The key pairs are originally for the use in SSH. Local server regularly updates local
server key pair. However, the host key pair we use in certificate request remains
unchanged.
9.2.7 Configuring Polling Interval and Count
If CA examines certificate request in manual mode, then a long time may be required
before the certificate is issued. In this period, you need to query the request status
periodically, so that you may get the certificate right after it is issued.
Table 9-18 Configure polling interval and count
Operation Command
certificate request polling { interval
Configure polling interval and count
minutes | count count }
undo certificate request polling

Restore the default values
{ interval | count }
By default, the request polling message is sent for 5 times at an interval of 20 minutes.
9.2.8 Configuring Certificate Request Mode
Request mode can be manual or auto. Auto mode enables the automatic request for a
certificate through SCEP when there is none and for a new one when the old one is
about to expire. For manual mode, all the related configuration and operation need to
be carried out manually.
9-12
Table 9-19 Configure certificate request mode
Operation Command
Configure certificate request mode certificate request mode { manual | auto }
Restore the default request mode undo certificate request mode
By default, manual mode is selected.
9.2.9 Delivering a Certificate Request Manually
A certificate request completes with user public key and other registered information.
All configured, you can deliver the certificate request to a PKI RA.
Table 9-20 Deliver a certificate request
Operation Command
pki request certificate domain-name
Deliver a certificate request.
[ password ] [ pem ]
Caution:
z If a local certificate already exists, certificate request operation is disallowed to

eliminate inconsistency between certificate and registration information resulted
from configuration change. To request a new certificate, you should first delete the
existing local certificate and all the CA certificates locally stored using the pki delete
certificate command.
z If you cannot send certificate request to CA using SCEP, you can select the
parameter pkcs10 to print out the request information, copy it and send one to CA in
out-of-band mode.
z Before you deliver the certificate request, make sure the clocks of entity and CA are
synchronous. Otherwise, fault occurs to the certificate validation period.
z If the certificate is obtained from Windows CA server, when configure the Windows
CA server, you cannot specify the RA identifier to be the same as CA identifier;
otherwise, the CA certificate and local certificate cannot be obtained.
z This operation will not be saved.
9-13
9.2.10 Retrieving a Certificate Manually
Certificate retrieval serves two purposes: store locally the certificate related to local
security domain to improve query efficiency; prepare for certificate verification.
When downloading a digital certificate, select the local keyword for a local certificate
and ca keyword for a CA certificate.
Table 9-21 Retrieve a certificate
Operation Command
Retrieve a certificate and download it pki retrieval certificate { local | ca }
locally domain domain-name
Caution:
z If a CA certificate already exists locally, CA certificate request operation is

disallowed to eliminate inconsistency between certificate and registration
information resulted from configuration change. To request a new certificate, you
should first delete the existing CA and local certificates using the pki delete
certificate command.
z This operation will not be saved.
9.2.11 Importing Certificates
You can import obtained local certificate or CA certificate with the command below.
Table 9-22 Import a certificate
Operation Command
pki import-certificate { local | ca } domain
Import a certificate.
domain-name { der | p12 | pem } [ filename filename ]
9.2.12 Deleting Certificates
You can delete existing local certificate or CA certificate with the command below.
9-14
Table 9-23 Delete a certificate
Operation Command
Delete a certificate. pki delete-certificate { local | ca } domain domain-name
9.3 Certificate Validation Configuration

9.3.1 Configuration Task List
At every stage of data communication, both parties should verify the validity of
corresponding certificates, including issue time, issuer and certificate validity. The core
is to verify the signature of CA and to make sure the certificate is still valid. It is believed
that CA never issues fake certificates, so every certificate with an authentic CA
signature will pass the verification. For example, if you receive an Email, which contains
a certificate with public key and is encrypted with private key, then you should verify the
validity of this certificate, to determine whether it is valid and trustworthy.
For certificate validation, you need to:
z Specify CRL distribution point location
z Configure CRL update period
z Enable/Disable CRL check
z Retrieve CRL
z Verify certificate validity
9.3.2 Specifying CRL Distribution Point location
Table 9-24 Configure CRL distribution point location
Operation Command
Specify CRL distribution point location crl url { url-string | scep }
Delete the location setting undo crl url
By default, no CRL distribution point location is specified.
9.3.3 Configuring CRL Update Period
CRL update period refers to the interval to download CRLs from CRL access server to
a local machine.
9-15
Table 9-25 Configure CRL update period
Operation Command
Specify CRL update period crl update period {default | days}
Restore the default period undo crl update period
By default, CRLs are updated according to their validity period.
Note:
CRL update period configured manually takes priority over that specified in CRLs.
9.3.4 Enabling/Disabling CRL Check
CRL check is optional for certificate validation. If it is enabled, you must check CRL to
decide on the certificate validity. The validation can be carried out directly in CA center
or locally with CRL downloaded. If it is disabled, the system ignores CRL when verifying
certificate validity.
Perform the following configuration in PKI domain view
Table 9-26 Enable/disable CRL check
Operation Command
Enable CRL check crl check enable
Disable CRL check crl check disable
By default, CRL check is enabled.
9.3.5 Retrieving a CRL
Having finished the above configuration tasks, you can retrieve CRL in any view. The
purpose of downloading CRL is to verify the validity of the certificates on a local device.
Table 9-27 Retrieve a CRL
Operation Command
Retrieve a CRL and download it locally pki retrieval crl domain domain-name
9-16
Note:
This operation will not be saved in configuration.
9.3.6 Verifying Certificate Validity
You can verify the validity of a local certificate using the parameter “local”; or a CA
certificate using the parameter “ca”.
Table 9-28 Verify certificate validity
Operation Command
pki validation certificate { local | ca }
Verify the validity of a local certificate
domain domain-name
Note:
This operation will not be saved in configuration.

I. Displaying certificates
If the certificate retrieval succeeds, you can display the fields of the certificates locally
downloaded. Certificate format and fields comply with X.509 standard. All kinds of
identifying information about user and CA are included, such as user E-mail address;
public key of the certificate holder; issuer, serial number, and validity (period) of the
certificate, etc.
Table 9-29 Display certificates
Operation Command
display pki certificate [ local | ca | request-status ]
Displaying certificates
[ domain domain-name ]
II. Displaying CRL
The fields of a CRL that is retrieved and locally downloaded can be displayed by the
following operation. CRL complies with X.509 standard, covering version, signature
9-17
(algorithm), issuer name, this update, next update, user public key, signature value,
serial number, and revocation date, etc.
Table 9-30 Display CRLs
Operation Command
Displaying CRLs display pki crl [ domain domain-name ]
III. Displaying and debugging configuration
Using the display current command, you can view current PKI configuration. You can
enable PKI debugging to monitor and diagnose relevant certificate implementation.
Table 9-31 Display and debug PKI information
Operation Command
Enable PKI debugging debugging pki { verify | request | retrieval | error }
undo debugging pki { verify | request | retrieval |
Disable PKI debugging
error }
By default, all PKI debugging is disabled.
9.5 Typical Configuration Examples

9.5.1 IKE Authentication with PKI Certificate
I. Network requirement
An IPsec security channel is created between SecPath A and SecPath B to ensure the
security of the data stream between the subnet represented by PC A (10.1.1.x) and the
subnet represented by PC B (10.1.2.x). IKE automatic negotiation creates secure
communication between SecPath A and SecPath B. IKE authentication policy adopts
PKI certificate system to authenticate identity.
Figure 1-2 supposes that SecPath A and SecPath B have different CAs (they can be
the same depending on the real situation).
9-18
II. Network diagram
Figure 9-2 IKE authentication with PKI certificate
# Use the defaulted IKE policy on SecPath A and enable PKI (rsa-signature) to
authenticate identity.
[H3C-ike-proposal-1] authentication-method rsa-signature
[H3C-ike-proposal-1] quit
# Configure entity DN.

[H3C] pki entity en
[H3C-pki-entity-en] ip 202.38.163.1
[H3C-pki-entity-en] common-name SecPathA
[H3C-pki-entity-en] quit
# Configure parameters on PKI domain.

[H3C] pki domain 1
[H3C-pki-domain-1] ca identifier CA1
[H3C-pki-domain-1] certificate request url
http://1.1.1.100/certsrv/mscep/mscep.dll
[H3C-pki-domain-1] certificate request from ra entity en
[H3C-pki-domain-1] ldap server ip 1.1.1.102
9-19
# Configure CRL distribution point location (if CRL check is disabled, this configuration
is not necessary).
[H3C-pki-domain-1] crl url ldap://1.1.1.102
# Create local key pair using RSA algorithm.

# Request certificate
[H3C-pki-entity-en] pki retrieval certificate ca domain 1
[H3C-pki-entity-en] pki request certificate 1
# Use the defaulted IKE policy on SecPath B and enable PKI (rsa-signature) to
authenticate identity.
[H3C-ike-proposal-1] authentication-method rsa-signature
[H3C-ike-proposal-1] quit
# Configure entity DN.

[H3C] pki entity en
[H3C-pki-entity-en] ip 202.38.162.1
[H3C-pki-entity-en] common-name SecPathB
[H3C-pki-entity-en] quit
# Configure parameters on PKI domain.

[H3C] pki domain 1
[H3C-pki-domain-1] ca identifier CA2
[H3C-pki-domain-1] certificate request url
http://2.1.1.100/certsrv/mscep/mscep.dll
[H3C-pki-domain-1] certificate request from ra entity en
[H3C-pki-domain-1] ldap server ip 2.1.1.102
# Configure CRL distribution point location (if CRL check is disabled, this configuration
is not necessary).
[H3C-pki-domain-1] crl url ldap://2.1.1.102
# Create local key pair using RSA algorithm.

# Request certificate
[H3C-pki-entity-en] pki retrieval certificate ca domain 1
[H3C-pki-entity-en] pki request certificate 1
9-20
Note:
The configuration of IKE negotiation using PKI identity authentication is described
above. If you want to create an IPsec security channel to ensure communication
security, you also need to configure IPsec. Refer to the configuration tasks described in
the chapters “IPsec Configuration” and “IKE Configuration”.
9.6 Troubleshooting
9.6.1 Fault 1: Failing to Retrieve a CA Certificate
Troubleshooting: If you fail to request a CA certificate, the reasons might include:

1) Software problems
z No trustworthy CA is specified.
z Server URL for the certificate request through SCEP is not correct or not
configured. You can check if the server is well connected by using the ping
command.
z No RA is specified.
z The system clock does not synchronize with the CA server.
2) Hardware problems
z Network connection faults, such as broken network cable and loose interface.
9.6.2 Fault 2: Failing to Request a Local Certificate
Troubleshooting: If you fail to request a local certificate when the firewall has finished
the configuration of PKI domain parameters and entity DN, and has created a new RSA
key pair, the reasons might include:
z No CA/RA certificate has been retrieved.
z No key pair is created, or the current key pair has had a certificate.
z No trustworthy CA is specified.
z Server URL for the certificate request through SCEP is not correct or not
configured. You can check if the server is well connected by using the ping
command.
z No certificate authority is configured.
z The necessary attributes of entity DN are not configured. You can configure the
relevant attributes by checking CA/RA authentication policy.
Network connection faults, such as broken network cable and loose interface.
9-21
9.6.3 Fault 3: Failing to Retrieve a CRL
Troubleshooting: If you fail to retrieve a CRL, the reasons might include:

z No local certificate exists when you try to retrieve a CRL.
z IP address of LDAP server is not configured.
z CRL distribution point location is not configured.
z LDAP server version is wrong.
z Network connection faults, such as broken network cable and loose interface.
9-22
H3C SecPath Series Security Products Chapter 10 SSL Configuration
Chapter 10 SSL Configuration
10.1 SSL Overview

Developed by Netscape, SSL protocols provide security channels between two devices
by transmission data protection and communicating devices. SSL protocols are
designed for two purposes, namely, for secure transmission between the client and the
server and authentication at both the server and client sides. SSL protocols are divided
into two layers. The lower layer is SSL record protocol, and the upper one consists of
SSL handshake protocol, SSL password change protocol and SSL warning protocol.
SSL handshake protocol is the most complicated one among the four protocols.
SSL record protocol fragments and compresses upper layer data, and attach MAC
addresses to the data packet tails to ensure data integrity. Then it encrypts data and
MAC addresses into records, and transmits them to the receiver.
SSL handshake protocol is used to set up a session between the client and server. It
contains a set of arguments, including the peer certificate, encryption suite,
compression algorithm and mastersecret. In addition, it marks the session to indicate
whether it is restorable. The session can be shared by multiple connections to avoid
high cost.
SSL password change protocol uses a message named ChangeCipherSpec, which
can be sent at both the client and server end. It is to inform the receiver that new
encryption suite and arguments are used for all the successive records.
SSL warning protocol is used to report exceptions to the receiver, by a simple message
including the severity (Warning Level, Fatal Level) and detailed description.
SSL protocols provide a comprehensive security policy by the following means. First
they encrypt the suite through negotiation, then they exchange session keys using
asymmetric encryption algorithm in the suite, and ensure user validity through
certificate authentication. Keys are used for data encryption during the transmission to
ensure the transmission security. If any error occurs, such as data tampering or user
authentication failure, the two sides are disconnected to avoid malicious attacks.
HTTPS server and client implemented based on SSL protocols ensure that valid
remote users can log into the device securely. Data is encrypted for transmission during
the device management, thus the device is secured. In addition, access control based
on certificate attributes is adopted, which controls access rights of login users through
access policies. This can protect device resources from being accessed or modified by
invalid users, and thus further secure the device.
Besides all of the above, SSL Proxy can be used to decrypt requests from the client,
send decrypted text data to the HTTP server, then get responses from the server,
10-1
encrypt the response data and send it to the client. With this data encryption and
decryption process, SSL Proxy reduces server load and improves server performance.
Digital certificates are often used for authentication of the two communication parties to
ensure communication security. The server first authenticates the client through the
client’s certificate, and then performs access control with attributes and attribute values
in the certificate, if the client is found valid. Only when all attribute values satisfy
predefined conditions of the server, the client can get access to server resources.
Comparing with the original PKI module, the SSL module adds access control based on
certificate attributes. This provides better secure access control for HTTP Server and
SSL Proxy.
SSL is mainly applied to HTTPS and SSL Proxy.
z HTTPS applications
HTTPS applications include server-side applications and client-side applications.
When HTTPS services are set up on the device, the client can log in remotely through
SSL protocols for device management. Data transmitted between the client and remote
device is encrypted for security and integrity. Thus, device security management is
implemented. In addition, access control based on certificate attributes is implemented
on HTTPS service on the device. It defines access control schemes and policies based
on certificate attributes and policies for access control based on certificate attributes,
which enables control over access right of the client. This further protects the device
from being attacked by invalid clients, and thus improves device security.
The device can access server resources through the HTTPS client. Resource requests
can be sent to the server side securely and reliably, and resources can be obtained
securely, reliably and keeping intact.
HTTPS Server
Internet
HTTPS Client
Figure 10-1 HTTPS application
z SSL Proxy
The client connects with the server based on SSL protocols, and performs argument
and key negotiation on the handshake phase, which occupies a lot of CPU resources of
the server. Data encryption and decryption during application data transmission also
occupies a lot of CPU resources. However, if SSL protocol processing is taken over by
the SSL Proxy instead of the HTTPS server, CPU cost of the HTTP server can be
reduced, and HTTP server performance can be improved as a result.
Acting as the bridge for communication between the HTTPS client and HTTP server,
the SSL Proxy is located between the two parties. After the client sends an HTTPS
10-2
request, SSL Proxy sets up an SSL connection with the client and thus an SSL channel
is created. Then the SSL Proxy sets up a TCP connection with the target HTTP server,
and forwards the resource request from the client to the HTTP server in plain text. Later
when it gets response from the HTTP server, SSL Proxy encrypts it, packetizes it to an
SSL record and then forwards to the HTTPS client, so as to complete the
communication between the client and server. In this process, SSL Proxy performs
data encryption and decryption instead of the HTTP server, thus improves HTTP server
performance.
SSL Proxy
Internet
HTTPS Client
HTTP Server
Figure 10-2 SSL Proxy application
10.2 Configuring SSL
Caution:
The amount of memory should be no less than 512MB in order to ensure the firewall to
perform SSL Proxy function normally.
SSL configuration includes the following tasks:

z Creating server SSL policies
z Configuring SSL Encryption Card
z Configuring Access Control Policies Based on Certificate Attributes
z Configuring SSL Proxy Server Policies
10-3
10.2.1 Configuring Server SSL Policies
I. Creating server SSL policies
Client policies are SSL connection parameters for configuring HTTPS server startup or
SSL Proxy startup. You need to first create a server SSL policy with the ssl
server-policy command, and then enter server SSL policy view.
Perform the following configuration in system view. This is mandatory.
Table 10-1 Create a server SSL policy
Operation Command
Create a server SSL policy. ssl server-policy policy-name
Delete one or all server SSL policies. undo ssl server-policy { policy-name | all }
Note:
An HTTPS server or SSL Proxy may use different SSL policies to meet different needs.
Each policy should be configured with unique information in SSL policy view.
II. Specifying PKI domain for a server SSL policy
When an HTTPS server or SSL Proxy is started at the server side, it gets certificate,
certificate chain and CA, which is used to validate client certificate, from the configured
PKI domain.
Perform the following configuration in server SSL policy view. This is mandatory.
Table 10-2 Configure PKI domain
Operation Command
Configure PKI domain. pki-domain pki-name
Delete PKI domain used by the server policy. undo pki-domain
By default, the server policy is not configured with a PKI domain.
10-4
Caution:
A PKI domain should first be configured in system view before being used by a server
policy. In addition, it must first apply for the certificate and obtain the CA certificate. For
more information about PKI, see Chapter 8 Hybrid Mode Configuration.
III. Configuring server-supported encryption suite list
This is to configure the list of encryption suites that the server supports.
Perform the following configuration in server policy view. This is optional.
Table 10-3 Configure server-supported encryption suite list
Operation Command
ciphersuite { rsa_ rc4_128_md5 | rsa_rc4_128_sha |
Add server-supported
rsa _des_cbc_sha | rsa_3des_ede_cbc_sha |
encryption suites.
rsa_aes_128_cbc_sha | rsa_aes_256_cbc_sha ] } *
undo ciphersuite [ rsa_rc4_128_md5 |

Delete server-supported rsa_rc4_128_sha | rsa_des_cbc_sha |
encryption suites rsa_3des_ede_cbc_sha | rsa_aes_128_cbc_sha |
rsa_aes_256_cbc_sha ] *
By default, all the six encryption suites are supported.

If no argument is set when configuring the undo ciphersuite command, all supported
encryption suite configurations are cancelled. That is, all the above six encryption
suites are supported.
IV. Configuring SSL handshake timeout
Table 10-4 Configure SSL handshake timeout on the server side
Operation Command
Configure SSL handshake connection lasting
handshake timeout time
time on the server side.
Restore the default SSL handshake connection
undo handshake timeout
lasting time on the server side.
The argument time refers to the hold time of handshake connection. It ranges from 180
to 7200 seconds and defaults to 3600 seconds.
10-5
V. Configuring SSL connection close mode
Two server close modes are available. In the wait mode, the server sends a
“close-notify” warning message to the client and then waits for a close-notify message
from the client. However, in the non-wait mode, the server sends a “close-notify”
warning message to the client, and then close the session without waiting for a
close-notify message from the client.
Table 10-5 Configure SSL connection close mode
Operation Command
Configure SSL connection close mode as wait close-mode wait
Restore the default SSL connection close mode undo close-mode wait
By default, the server does not wait for the close-notify messages from the client before
it terminates the session after sending the close-notify messages to the client.
Note:
Only when performing encryption using hardware, the SSL close-mode is wait after the
close-mode wait command is configured; while this command does not take effect
when encrypting using software.
VI. Configuring authentication on the client
This is to decide, during the handshake process, whether to perform certificate-based

SSL authentication on the client.
Table 10-6 Configure whether to perform authentication on the client
Operation Command
Configuring authentication on the client. client-verify enable
Configure no authentication on the client. undo client-verify enable
By default, no client authentication is performed.
VII. Configuring session cache storage time and size
You can configure the time that session units are stored in the session cache. The
value of time is to specify the time that session units are stored in the cache, after which
10-6
the session unit is timed out and cleared from the cache. If no enough space is left in
the cache, new connection can still be established but the new session will not be
saved into the cache. With the command, you can also specify the cache size.
Table 10-7 Configure session cache storage time and size
Operation Command
Configure session cache storage time session { timeout time | cachesize
and size size }*
Restore the default session cache
undo session { timeout | cachesize}*
storage time and size
The argument time refers to the storage time of the session cache. The unit is second,
and the value range is [1800-72000]. The default value is 3600.
The argument size refers to the numbers of session units can be hold in the cache. The
value range is [1000-10000], and the default value is 2000.
VIII. Displaying server SSL policy
Table 10-8 Display server SSL policy
Operation Command
display ssl server-policy
Display one or all server SSL policies.
{ policy-name | all }
IX. Enabling/disabling SSL server debugging
Table 10-9 Enable/disable SSL server debugging
Operation Command
debugging ssl server { all | event |
Enable SSL server debugging.
packet | error | process | misc }
undo debugging ssl server { all |
Disable SSL server debugging. event | packet | error | process |
misc }
By default, SSL server debugging is disabled.
10-7
10.2.2 Configuring SSL Encryption Card
I. Configuring SSL encryption card for the server
Software encryption/decryption of the SSL server occupies a lot of CPU resources, and
thus reduces the overall processing efficiency. However, you can use the SSL
encryption card to perform hardware encryption/decryption, which avoids performance
reduction, as well as improves SSL processing efficiency.
Perform the following configuration in server policy view.
Table 10-10 Configure SSL encryption card for the server
Operation Command
Configure SSL encryption card for the server. use ssl-card slot-id
Cancel the configured SSL encryption card. undo use ssl-card
By default, no encryption card is configured.
II. Enabling/disabling SSL encryption card
Perform the following configuration in encryption card interface view.
Table 10-11 Enable/disable SSL encryption card
Operation Command
Disable SSL encryption card. shutdown
Enable SSL encryption card. undo shutdown
III. Displaying SSL encryption card statistics
Table 10-12 Display and debug SSL
Operation Command
Display SSL encryption card statistics. display interface ssl-card slot-id
IV. Enabling/disabling SSL encryption card debugging
10-8
Table 10-13 Enable/disable SSL encryption card debugging
Operation Command
debugging ssl card { all | event |
Enable SSL encryption card debugging.
undo debugging ssl card { all | event |
Disable SSL encryption card debugging.
By default, SSL encryption card debugging is closed.
10.2.3 Configuring Access Control Policies Based on Certificate Attributes
I. Configuring certificate attribute group
HTTPS server and SSL Proxy can perform access control based on client certificates.
To configure access control policies based on certificate attributes, you need to first
configure corresponding attribute groups.
Perform the following configuration in system view to configure certificate attribute
group, and then enter attribute group view.
Table 10-14 Configure certificate attribute group
Operation Command
pki certificate attribute-group
Configure a certificate attribute group.
group-name
Delete one or all certificate attribute undo pki certificate attribute-group
groups. { group-name | all }
Note:
z The undo command will delete all attribute filter conditions of the corresponding
group.
z You can configure multiple certificate attribute groups, but each of them must have a
unique name.
II. Configuring certificate attribute filter conditions
After you configure an attribute group, configure attribute filter conditions for it.
Perform the following configuration in certificate attribute filter group view
10-9
Table 10-15 Configure certificate attribute filter conditions
Operation Command
Configure filter conditions for the dn attribute id { subject-name |
value of attribute “subject-name” or issuer-name } dn { ctn | nctn }
“issuer-name”. attribute-value
Configure filter conditions for the fgdn attribute id { subject-name |
value of attributes “subject-name”, issuer-name | alt-subject-name } fqdn
“issuer-name” and “alt-subject-name”. { equ | nequ | ctn | nctn } attribute-value
Configure filter conditions for the ip attribute id { subject-name |
value of attributes “subject-name”, issuer-name | alt-subject-name } ip
“issuer-name” and “alt-subject-name”. { equ | nequ } attribute-value
Delete an attribute filter condition. undo attribute { id | all }
Note:
z The value of attribute “alt-subject-name” cannot be in the form of “dn”, therefore no
“dn” is set in its filter condition.
z You can configure multiple attribute filter conditions in one group, but the “id” value
for each of them must be unique.
z The relationship between the attribute filter conditions in the group is and, that is, all
the attribute filter conditions in this group must be matched.
III. Configuring access control policies based on certificate attributes
After you configure certificate attribute groups, you can configure access control
policies based on certificate attributes.
Perform the following configuration in system view, and enter control policy view.
Table 10-16 Configure an access control policy based on certificate attributes
Operation Command
Configure an access control policy pki certificate access-control-policy
based on certificate attributes. policy-name
undo pki certificate
Delete one or all access control policies
access-control-policy { policy-name |
based on certificate attributes.
all }
10-10
Note:
z You can configure multiple access control policies based on certificate attributes,
but each of them must have an unique name.
z When you delete an access control policies based on certificate attributes, all
access control rules in this policy are deleted.
IV. Configuring access control rules based on certificate attributes
After you configure access control policies based on certificate attributes, you can
configure access control rules based on certificate attributes.
Perform the following configuration in certificate attribute access control rule view.
Table 10-17 Configure an access control rule based on certificate attributes
Operation Command
Configure an access control rule based
rule [ id ] { permit | deny } group-name
on certificate attributes.
Delete one or all access control rules
undo rule { id | all }
based on certificate attributes.
Note:
z You can configure multiple access control rules based on certificate attributes, but
the value of “id” for each of them must be unique.
z Before a rule is configured, “group-name” must be first configured with the pki
certificate attribute-group command.
V. Displaying certificate attribute filter statistics
After configuring a certificate attribute group, you can view group statistics through
command.
Table 10-18 Display certificate attribute group statistics
Operation Command
Display certificate attribute group display pki certificate attribute-group
statistics. { group-name | all }
10-11
VI. Displaying certificate attribute access control policy statistics
After configuring an access control policy based on certificate attribute, you can view
policy statistics through command.
Table 10-19 Display statistics of an access control policy based on certificate attribute
Operation Command
Display statistics about one or all access display pki certificate
control policies based on certificate access-control-policy { policy-name |
attribute. all }
VII. Enabling/disabling certificate attribute access control debugging
During certificate attribute access control, you can enable or disable certificate attribute
access control debugging with commands.
Table 10-20 Enable/disable certificate attribute access control debugging
Operation Command
Enable certificate attribute access
debugging pki acp
control debugging.
Disable certificate attribute access
undo debugging pki acp
control debugging.
By default, certificate attribute access control debugging is disabled.
10.2.4 Configuring SSL Proxy Server Policies
I. Creating SSL Proxy server policies
SSL Proxy policies on the server side specify the configuration parameters used for
HTTPS server running. You need first create an SSL Proxy policy for the server with the
ssl proxy command, and then enter SSL Proxy policy view.
Perform the following configuration in system view. This is mandatory.
Table 10-21 Create an SSL Proxy server policy
Operation Command
Create an SSL Proxy server policy. ssl proxy ssl-proxy-name
Delete one or all SSL Proxy server
undo ssl proxy { ssl-proxy- name | all }
policies.
10-12
Note:
An SSL Proxy server may use different SSL Proxy server policies to meet different
needs. Each policy should be configured with unique information in SSL Proxy policy
view.
II. Specifying server SSL Proxy policy port
This is to specify the port to be used by SSL Proxy server policies.

Perform the following configuration in SSL proxy server policy view. This is optional.
Table 10-22 Specify SSL Proxy server policy port
Operation Command
Specify SSL Proxy server policy port. port port-number
Restore SSL Proxy server policy port. undo port
By default, the SSL Proxy server policy port is 443.
III. Specifying SSL server policy for SSL Proxy server
The SSL server policy used by the SSL Proxy server must be specified in the SSL
Proxy server policy configuration.
Perform the following configuration in SSL proxy server policy view. This is mandatory.
Table 10-23 Specify SSL server policy for SSL Proxy server policy
Operation Command
Specify SSL server policy for SSL Proxy
ssl-server-policy policy_name
server policy.
Cancel the specified SSL server policy undo ssl-server-policy
By default, no SSL server policy is specified.
IV. Specifying certificate access control policies used by server HTTPS

policies
Perform the following configuration in SSL proxy server policy view. This is optional.
10-13
Table 10-24 Configure the certificate access control policy used by an SSL Proxy
server policy
Operation Command
Configure the certificate access control certificate access-control-policy
policy used by an SSL Proxy server policy policy-name
Delete the certificate access control policy undo certificate
used by an SSL Proxy server policy. access-control-policy
By default, no certificate access control policy is specified.
V. Configuring IP address and port number of the destination server
Perform the following configuration in SSL proxy server policy view.
Table 10-25 Configure IP address and port number of the destination server
Operation Command
Configure the IP address and port
server ip ip-address port port-number
number of the destination server
Delete the configured IP address of the
undo server ip ip-address
destination server
By default, no IP address and port number of the destination server is configured.
VI. Displaying server SSL Proxy policies
Table 10-26 Display server HTTPS policies
Operation Command
Display one or all server SSL Proxy display ssl proxy { ssl-proxy-name |
policies. all }
VII. Displaying SSL Proxy session statistics
Table 10-27 Display SSL Proxy session statistics
Operation Command
Display SSL Proxy session statistics. display ssl-proxy session [ statistics ]
10-14
VIII. Resetting SSL Proxy connection statistics
This is to clear SSL Proxy connection statistics.

Table 10-28 Reset SSL Proxy connection statistics
Operation Command
Reset SSL Proxy connection statistics. reset ssl proxy statistic
IX. Resetting SSL Proxy connections
Table 10-29 Reset SSL Proxy connections
Operation Command
Reset SSL Proxy connections. reset ssl-proxy session
X. Enabling/disabling SSL Proxy debugging
Table 10-30 Enable/disable SSL Proxy debugging
Operation Command
debugging ssl proxy { all | event |
Enable SSL Proxy debugging.
undo debugging ssl proxy { all | event
Disable SSL Proxy debugging.
| packet | error | process | misc }
By default, SSL Proxy debugging is disabled.
XI. Starting the SSL Proxy server
After SSL Proxy server policy configuration, you can start SSL Proxy server through a
command.
Table 10-31 Start the SSL Proxy server
Operation Command
ssl proxy server ssl-proxy-name
Start the SSL Proxy server.
enable
10-15
Note:
SSL Proxy server policies must be defined before you running this command.
XII. Shutting down SSL Proxy server
This is to shut down a running SSL Proxy server.

Table 10-32 Shut down the SSL Proxy server
Operation Command
Shut down the SSL Proxy server. undo ssl proxy server ssl-proxy-name enable
Note:
The name of SSL Proxy server policy in this command must be the same with that of
the running policy.
10.2.5 Configuration Example: Setting up SSL Proxy Server
The HTTPS client connects to the SSL Proxy service on the firewall through the
Internet, and then the firewall sends requests to the HTTP server.
II. Network diagram
Ethernet0/0/0 SSL Proxy

10.165.87.165
Internet
Internet
HTTPS client
10.165.87.154 Ethernet1/0/0
10.165.88.1
HTTP server
10.165.88.15
Figure 10-3 Network diagram for SSL Proxy server
10-16
# Configure the interface IP address.

Configure an SSL server policy.

# Custom the SSL server policy to be used on the SSL Proxy server.
[H3C] ssl server-policy myssl
# Configure the PKI domain. Refer to Chapter 9 “PKI Configuration” for detailed
description on PKI configuration.
[H3C-ssl-server-policy-myssl] pki-domain 1
Configure the certificate attribute group.

# Configure two certificate attribute groups, named mygroup1 and mygroup2
respectively, and configure filter conditions for each of them.
[H3C] pki certificate attribute-group mygroup1
[H3C-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn cn=H3C
[H3C-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ
10.165.87.154
[H3C-cert-attribute-group-mygroup1] quit
[H3C] pki certificate attribute-group mygroup2
[H3C-cert-attribute-group-mygroup] attribute 1 alt-subject-name fqdn nctn
Cisco
[H3C-cert-attribute-group-mygroup] attribute 2 issuer-name dn ctn H3C
Configure certificate ACP policy:

# Configure an access control policy based on certificate attributes, with the name
myacp, and configure control rules for it.
[H3C] pki certificate access-control-policy myacp
[H3C-cert-acp-myacp] rule 1 deny mygroup1
[H3C-cert-acp-myacp] rule 2 permit mygroup2
Configure an SSL Proxy server policy:

# Custom an SSL Proxy server policy.
[H3C] ssl proxy myproxy
# Configure “myssl” as the SSL server policy.

[H3C-sslproxy-myproxy] ssl-server-policy myssl
10-17
# Configure “myacp” as the certificate ACP.

[H3C-sslproxy-myproxy] certificate access-control-policy myacp
# Configure target HTTP server.

[H3C-sslproxy-myproxy] server ip 10.165.88.15 port 80
Run the SSL Proxy server.

# Set the SSL Proxy server policy as “myproxy” and then start the SSL Proxy server.
[H3C] ssl proxy server myproxy enable
Configure routing policy on the firewall, and then the CPU of the firewall will process the
HTTPS request packets; otherwise, the firewall forwards the packets normally and
cannot function as an SSL Proxy server.
# Configure ACL which is used to match the data stream.
[H3C-acl-adv-3000] rule permit tcp source any destination 10.165.88.15 0
# Configure routing policy. The firewall sends the packets that match the ACL to the
loopback interface, and then the CPU processes the packets.
[H3C] interface LoopBack 1
[H3C] route-policy https permit node 1
# Apply the routing policy on the interface.

[H3C-Ethernet0/0/0] ip policy route-policy https
10-18
H3C SecPath Series Security Products Chapter 11 Web and E-mail Filtering
Chapter 11 Web and E-mail Filtering
11.1 Introduction to Web and E-mail Filtering

As network technology increasingly gains popularity in various fields, attacks sourced
from within a LAN escalate. Faced with this situation, traditional network security
solutions, which only focus on attacks initiated from external networks, become
inadequate. Network devices are thus required to provide more measures to secure
internal networks.
The Web and e-mail filtering function provided by firewalls can deny accesses to
illegitimate Web sites or Web pages and prevent internal users from sending mails
such as personal mails. The mail alarming function can inform administrators of
external attacks through alarming mails for them to take proper measures on time.
The SecPath firewall can also effectively fence databases against SQL (structure query
language) attacks by checking the HTTP commands in received HTTP packets.
11.2 Configuring Web Filtering

11.2.1 Configuring Web Address Filtering
I. Enable/Disable Web address filtering
You must enable the Web address filtering function before its configuration can take
effect.
Table 11-1 Enable Web address filtering
Operation Command
Enable Web address filtering firewall url-filter host enable
Disable Web address filtering undo firewall url-filter host enable
Web address filtering is disabled by default.
11-1
Caution:
You must configure ASPF policies and execute the detect http and detect tcp
commands first to enable Web address filtering. Refer to section 5.3 “Configuring
ASPF” for information about ASPF.
For the HTTP protocol listening to a non-standard port, you must execute the
port-mapping command to configure port mapping to enable the Web address filtering
function.
II. Configure the default filtering operation
You can configure the default filtering operation for a firewall to make the firewall to
permit/deny packets that do not match the Web addresses set by the administrator.
Table 11-2 Configure the default filtering operation
Operation Command
firewall url-filter host default { permit |
Configure the default filtering operation
deny }
Packets that do not match are permitted by default.
III. Configure a Web address to be filtered
Web addresses are filtered according to the address items previously configured in a
Web address filtering file. When managing the file, the administrator can add, delete,
and clear up Web addresses.
Table 11-3 Configure a Web address to be filtered
Operation Command
firewall url-filter host add { permit |
Add a Web address to be filtered
deny } url-address
firewall url-filter host delete

Delete a Web address
url-address
Clear all Web addresses firewall url-filter clear
11-2
Note:
If you want to save the filtering address added by executing firewall url-filter host add
command, you have to save the filtering address to filtering files by executing firewall
url-filter host save-file command. If not so, the newly added address will be lost next
time when you enable the firewall.
IV. Save/Load a Web address filtering file
After configuring the Web addresses to be filtered, you can save them to a Web
address filtering file for later use. You must load a Web address filtering file first to
configure or modify items in it.
Table 11-4 Save/Load a Web address filtering file
Operation Command
firewall url-filter host { save-file |
Save/Load a Web address filtering file
load-file } file-name
Unload the current Web address filtering
undo firewall url-filter host load-file
file
You must load the Web addresses filtering file for items in it to take effect, that is, for
Web addresses that match these items to be filtered.
V. Configuring IP address filtering
If users access the Web through IP addresses, you can configure the firewall to control
whether to allow such access requests.
Table 11-5 Configure IP address filtering
Operation Command
firewall url-filter host ip-address
Configure IP address filtering.
{ permit | deny }
By default, the firewall denies Web access requests with IP addresses as destination
URLs.
VI. Filtering IP addresses through ACL
This is to filter Web access requests with IP addresses as destination URLs through
ACL.
11-3
Table 11-6 Filter IP addresses through ACL
Operation Command
firewall url-filter host acl-number
Filter IP addresses through ACL.
number
undo firewall url-filter host
Cancel the configured ACL rule.
acl-number
By default, no ACL rule is configured.

When the firewall receives a Web request with the IP address as the destination URL, it
will first match the ACL in the firewall url-filter host acl-number command. If the
result is “permit”, the request is permitted to pass through; if the result is “deny”, the
request is denied. If no matched entry is found in ACL or the firewall url-filter host
acl-number is not configured, the firewall will decide whether to permit or deny the
request according to the configuration result of command firewall url-filter host
ip-address { permit | deny }.
This command can only refer to one ACL rule. Any new configured rule will covers the
original one.
VII. Display and debug Web address filtering
Use the commands listed in Table 11-7 to view information about Web address filtering
and enable debugging Web address filtering.
Execute the display command in any view, and execute the debugging and reset
commands in user view.
Table 11-7 Display and debug Web address filtering
Operation Command
Display information about Web address display firewall url-filter host { enable
filtering | all | item { url-address | all } }
debugging firewall url-filter host { all |
Enable debugging Web address filtering
error | event | filter | packet }
undo debugging firewall url-filter

Disable debugging Web address filtering host { all | error | event | filter |
packet }
Clear statistics on Web address filtering reset firewall url-filter host counter
11-4
11.2.2 Configuring Web Content Filtering
I. Enable/Disable Web content filtering
Before configuring Web content filtering for a firewall, you must enable this function first
for related configurations to take effect.
Table 11-8 Enable Web content filtering
Operation Command
Enable Web content filtering firewall webdata-filter enable
Disable Web content filtering undo firewall webdata-filter enable
Web content filtering is disabled by default.
Caution:
z You must configure ASPF policies and execute the detect http and detect tcp
commands first to enable Web content filtering. Refer to section 5.3 “Configuring
ASPF” for detailed information about ASPF.
z For the HTTP protocol listening to a non-standard port, you must execute the
port-mapping command to configure port mapping to enable the Web content
filtering function.
z You may see a flashing IE browser after certain Web contents are filtered out.
II. Configure a filtering keyword for Web content filtering
Web pages can be filtered according to the filtering keyword items previously
configured in a Web content filtering file. The administrator can manipulate this kind of
files to add or delete Web content filtering keywords in them, or even clear all the Web
content filtering keywords.
Table 11-9 Configure a filtering keyword for Web content filtering
Operation Command
Add a Web content filtering keyword firewall webdata-filter add keywords
firewall webdata-filter delete
Delete a Web content filtering keyword
keywords
11-5
Operation Command
Clear all Web content filtering keywords firewall webdata-filter clear
Note:
z The new Web content filtering keyword cannot be an HTML tag such as <head>,
<html>, <title> and <script>. Otherwise, valid web pages may be filtered.
z If you want to save the keyword added by executing firewall webdata-filter add
command, you have to save the keyword to filtering files by executing firewall
webdata-filter save-file command. If not so, the newly added keyword will be lost
next time when you enable the firewall.
III. Save/Load a Web content filtering file
After configuring the Web content filtering keywords, you can save them to a Web
content filtering file for later use. You must load a Web content filtering file first to
Table 11-10 Save /Load a Web content filtering file
Operation Command
firewall webdata-filter { save-file |
Save /Load a Web content filtering file
Unload the current Web content filtering
undo firewall webdata-filter load-file
file
You must load the Web content filtering file for items in it to take effect, that is, for Web
contents that match these items to be filtered.
IV. Display and debug Web content filtering
Use the commands listed in Table 11-11 to view information about Web content filtering
and enable debugging Web content filtering.
Table 11-11 Display and debug Web content filtering
Operation Command
Display information about Web content display firewall webdata-filter
filtering { enable | all | item keywords | all } }
11-6
Operation Command
debugging firewall webdata-filter { all
Enable debugging Web content filtering
| error | event | filter | packet }
undo debugging firewall
Disable debugging Web content filtering webdata-filter { all | error | event |
filter | packet }
Clear statistics on Web content filtering reset firewall webdata-filter counter
11.2.3 Configuring SQL Attack Prevention
I. Enabling SQL attack prevention
To validate later configuration on the firewall, you must enable SQL attack prevention
first before make any configuration on SQL attack prevention.
Table 11-12 Enable SQL attack prevention
Operation Command
Enable SQL attack prevention firewall url-filter parameter enable
Disable SQL attack prevention undo firewall url-filter parameter enable
By default, SQL attack prevention is not enabled.
Caution:
To enable SQL attack prevention successfully, you must first configure ASPF policies,
and the detect http and detect tcp commands. Refer to section 5.3 “Configuring
ASPF” for more information about ASPF.
port-mapping command to configure port mapping to enable the SQL attack
prevention function.
II. Configuring filter keywords for SQL attack prevention
SQL attack prevention functions filters HTTP commands based on the predefined filter
keywords. If the keyword is borne in a HTTP request, the firewall will block the request.
You can define table names, fields, saving process names (default or custom) as
keywords depending on specific needs.
11-7
Table 11-13 Configure filter keywords for SQL attack prevention
Operation Command
Add a filter keyword for SQL attack firewall url-filter parameter add
prevention keywords
firewall url-filter parameter
Add the system-default filter keywords
add-default
firewall url-filter parameter delete
Delete a filter keyword
keywords
Clear all filter keywords firewall url-filter parameter clear
The system predefines these filter keywords for SQL attack prevention: ^select^,
însert^, ûpdate^, ^delete^, ^drop^, –, ', êxec^ and %27. If you delete some keywords
unconsciously or use the firewall url-filter parameter clear command by mistake, you
can restore the default configuration with this command.
Note:
If you want to save the keyword added by executing firewall url-filter parameter add
command and firewall url-filter parameter add-default, you have to save the
keyword to filtering files by executing firewall url-filter parameter save-file command.
If not so, the newly added keyword will be lost next time when you enable the firewall.
III. Saving/loading SQL attack prevention filter file
After configuring filter keywords, you can save them in the filter file. You can load the
filter file later if you want to modify the existing configuration or make other settings.
Table 11-14 Save/load SQL attack prevention filter file
Operation Command
Save/load SQL attack prevention filter firewall url-filter parameter { save-file
file | load-file } file-name
Unload the SQL attack prevention filter undo firewall url-filter parameter
file load-file
To validate the entries in SQL attack prevention filter file enable them to filter HTTP
commands, you must load them.
11-8
IV. Displaying and debugging SQL attack prevention configuration
Use the commands listed in Table 11-15 to display information about SQL attack
prevention filtering and enable/disable debugging SQL attack prevention filtering.
Table 11-15 Display and debug SQL attack prevention configuration
Operation Command
Display SQL attack prevention filter display firewall url-filter parameter
configuration { enable | all | item { keywords | all } }
Display the number for matching each display firewall url-filter parameter
filter keyword counter detail
debugging firewall url-filter
Enable debugging for SQL attack
parameter { all | error | event | filter |
prevention
packet }
undo debugging firewall url-filter

Disable debugging for SQL attack
parameter { all | error | event | filter |
prevention
packet }
Clear statistics on SQL attack reset firewall url-filter parameter
prevention counter
11.3 Configuring E-mail Filtering

11.3.1 Configuring E-mail Address Filtering
E-mail filtering is needed to prevent internal users from sending out unnecessary
information to illegal targets outside intranets. The firewall enables you to filter E-mails
by their addresses.
I. Enable/Disable E-mail address filtering
Before configuring E-mail address filtering for a firewall, you must enable this function
first for related configurations to take effect.
Table 11-16 Enable E-mail address filtering
Operation Command
Enable E-mail address filtering firewall smtp-filter rcptto enable
undo firewall smtp-filter rcptto
Disable E-mail address filtering
enable
11-9
E-mail address filtering is disabled by default.
Caution:
You must configure ASPF policies and execute the detect smtp and detect tcp
commands first to enable E-mail address filtering. Refer to section 5.3 “Configuring
port-mapping command to configure port mapping to enable the E-mail address
filtering function.
II. Configure the default filtering operation
You can configure the default filtering operation for a firewall to make the firewall
permit/deny packets that do not match the E-mail addresses set by the administrator.
Table 11-17 Configure the default filtering operation
Operation Command
firewall smtp-filter rcptto default
Configure the default filtering operation
{ permit | deny }
Revert to the default filtering operation undo firewall smtp-filter rcptto default
Packets that do not match are permitted by default.
III. Configure an E-mail address to be filtered
E-mails are filtered according to the address items previously configured in an E-mail
address filtering file. The administrator can manipulate this kind of files to add or delete
E-mail addresses in them, or even clear all the E-mail addresses.
Table 11-18 Configure an E-mail address to be filtered
Operation Command
Add an E-mail address to be firewall smtp-filter rcptto add { permit |
filtered deny } mail-address
Delete an E-mail address firewall smtp-filter rcptto delete mail-address
Clear all E-mail addresses firewall smtp-filter rcptto clear
11-10
Note:
If you want to save the filtering address added by executing firewall smtp-filter rcptto
add command, you have to save the filtering address to filtering files by executing
firewall smtp-filter rcptto save-file command. If not so, the newly added filtering
address will be lost next time when you enable the firewall.
IV. Save/Load an E-mail address filtering file
After configuring the E-mail addresses to be filtered, you can save them to an E-mail
address filtering file for later use. You must load an E-mail address filtering file first to
Table 11-19 Save/Load an E-mail address filtering file
Operation Command
Save/Load an E-mail address filtering firewall smtp-filter rcptto { save-file |
file load-file } file-name
Unload the current E-mail address undo firewall smtp-filter rcptto
filtering file load-file
You must load the E-mail addresses filtering file for items in it to take effect, that is, for
E-mail addresses that match these items to be filtered.
11.3.2 Configuring E-mail Subject Filtering
You can also filter outgoing E-mails by their subjects.
I. Enable/Disable E-mail subject filtering
Before configuring E-mail subject filtering for a firewall, you must enable this function
Table 11-20 Enable E-mail subject filtering
Operation Command
Enable E-mail subject filtering firewall smtp-filter subject enable
Disable E-mail subject filtering undo firewall smtp-filter subject enable
E-mail subject filtering is disabled by default.
11-11
Caution:
commands first to enable E-mail subject filtering. Refer to section 5.3 “Configuring
port-mapping command to configure port mapping to enable the E-mail subject
filtering function.
II. Configure a filtering keyword for E-mail subject filtering
E-mails can be filtered according to the filtering keyword items previously configured in
an E-mail subject filtering file. The administrator can manipulate this kind of files to add
or delete E-mail subject filtering keywords in them, or even clear all the E-mail subject
filtering keywords.
Table 11-21 Configure an filtering keyword for E-mail subject filtering
Operation Command
firewall smtp-filter subject add
Add an E-mail subject filtering keyword
mail-subject
Delete an E-mail subject filtering firewall smtp-filter subject delete
keyword mail-subject
Clear all E-mail subject filtering
firewall smtp-filter subject clear
keywords
Note:
If you want to save the keyword added by executing firewall smtp-filter subject add
smtp-filter subject save-file command. If not so, the newly added keyword will be lost
III. Save/Load an E-mail subject filtering file
After configuring the E-mail subject filtering keywords, you can save them to an E-mail
subject filtering file for later use. You must load an E-mail subject filtering file first to
11-12
Table 11-22 Save/Load an E-mail subject filtering file
Operation Command
firewall smtp-filter subject { save-file |
Save/Load an E-mail subject filtering file
Unload the current E-mail subject undo firewall smtp-filter subject
You must load the E-mail subject filtering file for items in it to take effect, that is, for
E-mails that match these items to be filtered.
11.3.3 Configuring E-mail Content Filtering
E-mails can also be filtered according to their content.
I. Enable/Disable E-mail content filtering
Before configuring E-mail content filtering for a firewall, you must enable this function
Table 11-23 Enable E-mail content filtering
Operation Command
Enable E-mail content filtering firewall smtp-filter content enable
Disable E-mail content filtering undo firewall smtp-filter content enable
Caution:
commands first to enable E-mail content filtering. Refer to section 5.3 “Configuring
port-mapping command to configure port mapping to enable the E-mail content
filtering function.
E-mail content filtering is disabled by default.
II. Configure a filtering keyword for E-mail content filtering
E-mails can be filtered according to the filtering keyword items previously configured in
an E-mail content filtering file. The administrator can manipulate this kind of files to add
11-13
or delete E-mail content filtering keywords in them, or even clear all the E-mail content
filtering keywords.
Table 11-24 Configure a filtering keyword for E-mail content filtering
Operation Command
firewall smtp-filter content add
Add an E-mail content filtering keyword
content-keywords
Delete an E-mail content filtering firewall smtp-filter content delete
keyword content-keywords
Clear all E-mail content filtering
firewall smtp-filter content clear
keywords
Note:
If you want to save the keyword added by executing firewall smtp-filter content add
smtp-filter content save-file command. If not so, the newly added keyword will be lost
III. Save/Load an E-mail content filtering file
After configuring the E-mail content filtering keywords, you can save them to an E-mail
content filtering file for later use. You must load an E-mail content filtering file first to
Table 11-25 Save /Load an E-mail content filtering file
Operation Command
Save /Load an E-mail content filtering firewall smtp-filter content { save-file
file | load-file } file-name
Unload the current E-mail content undo firewall smtp-filter content
You must load the E-mail content filtering file for items in it to take effect, that is, for
11.3.4 Configuring E-mail Attachment Filtering
You can also filter outgoing E-mails by their attachments.
11-14
I. Enable/Disable E-mail attachment filtering
Before configuring E-mail attachment filtering for a firewall, you must enable this
function first for related configurations to take effect.
Table 11-26 Enable E-mail attachment filtering
Operation Command
Enable E-mail attachment filtering firewall smtp-filter attach enable
undo firewall smtp-filter attach
Disable E-mail attachment filtering
enable
Caution:
commands first to enable E-mail attachment filtering. Refer to section 5.3 “Configuring
port-mapping command to configure port mapping to enable the E-mail attachment
filtering function.
E-mail attachment filtering is disabled by default.
II. Configure an attachment name for E-mail attachment filtering
E-mails can be filtered according to the attachment name items previously configured
in an E-mail attachment filtering file. The administrator can manipulate this kind of files
to add or delete E-mail attachment names in it, or even clear all the E-mail attachment
names.
Table 11-27 Configure an attachment name for E-mail attachment filtering
Operation Command
firewall smtp-filter attach add
Add an E-mail attachment name
file-name
firewall smtp -filter attach delete
Delete an E-mail attachment name
file-name
Clear all E-mail attachment names firewall smtp -filter attach clear
11-15
Note:
If you want to save the filtering attachment name added by executing firewall
smtp-filter attach add command, you have to save the filtering attachment name to
filtering files by executing firewall smtp-filter attach save-file command. If not so, the
newly added filtering attachment name will be lost next time when you enable the
firewall.
III. Save/Load an E-mail attachment filtering file
After configuring the E-mail attachment names, you can save them to an E-mail
attachment filtering file for later use. You must load an E-mail attachment filtering file
first to configure or modify items in it.
Table 11-28 Save/Load an E-mail attachment filtering file
Operation Command
Save/Load an E-mail attachment firewall smtp-filter attach { save-file |
filtering file load-file } file-name
Unload the current E-mail attachment undo firewall smtp-filter attach
You must load the E-mail attachment filtering file for items in it to take effect, that is, for
11.3.5 Displaying and Debugging E-mail filtering
Use the commands listed in Table 11-29 to display information about E-mail filtering
and enable/disable debugging E-mail filtering.
Table 11-29 Display and Debug E-mail filtering
Operation Command
display firewall smtp-filter { all |
Display information about E-mail filtering rcptto | subject | content | attach }
item { string | all } }
Enable debugging E-mail filtering debugging firewall smtp-filter
Disable debugging E-mail filtering undo debugging firewall smtp-filter
11-16
Operation Command
reset firewall smtp-filter counter
Clear statistics on E-mail filtering
[ rcptto | subject | content | attach ]
11-17
H3C SecPath Series Security Products Chapter 12 Attack Prevention and Packet Statistics
Chapter 12 Attack Prevention and Packet

Statistics
12.1 Introduction to Attack Prevention and Packet Statistics

12.1.1 Introduction to Attack Prevention
Generally, network attacks intrude or destroy network servers (hosts) for stealing the
sensitive data on servers or interrupting server services. There are also the network
attacks that directly destroy network devices, which can make networks service
abnormal or even out of service. The attack prevention function of the firewall can
detect various types of network attacks and take the corresponding measures to
protect internal networks against malicious attacks so as to assure the normal
operations of internal networks and systems.
12.1.2 Classes of Network Attacks
Network attacks can be divided into three classes, denial of service attack, scanning
and snooping attack and defective packet attack.
I. Denial of service attack
Denial of service (DoS) attack is to attack a system by sending a large number of data
packets so that the system cannot receive requests from clients normally or the host is
suspended and cannot work normally. The main DoS attacks include SYN Flood and
Fraggle. Different from other types of attacks, the special feature of the DoS attack is
that attackers prevent valid clients from accessing network resources instead of
searching for ingresses of internal networks.
II. Scanning and snooping attack
Scanning and snooping attack is to point out a potential target by identifying an existing
system in the network by ping scanning (including ICMP and TCP). Scanning through
TCP and UDP ports, the attacker can detect the running system and the monitoring
service and then get a general idea of the service type and the potential security defect
of the system so as to prepare for the further intrusion.
III. Defective packet attack
Defective packet attack is to send a defective IP packet to the destination system so

that the system will crash when it processes the IP packet. The main defective packets
include Ping of Death and Teardrop.
12-1
12.1.3 Typical Examples of Network Attacks
I. IP spoofing attack
To get an access authority, an intruder generates a packet carrying a bogus source

address, which can make an unauthorized client access the system applying the
IP-based authentication even in the root authority.
II. Land attack
Land attack is to configure both the source address and the destination address of the
TCP SYN packet to the IP address of the attack target. Thus, the target sends the
SYN-ACK message and sends back the ACK message to it, and then creates a null
connection. Each of the null connection will be saved till the timeout. Different attack
targets have different responses to the Land attack. For instance, many UNIX hosts will
crash and Windows NT hosts will be slowdown.
III. Smurf attack
The simple Smurf attack is to attack a network by sending an ICMP request to the
broadcast address of the target network. All the hosts in the network will respond to the
request. Network congestion thus occurs.
The advanced Smurf attack is mainly used to attack the target host by configuring the
source address of the ICMP packet to the address of the target host, so as to make the
host crash due to having received large numbers of ICMP reply messages finally. It
takes certain traffic and duration to send the attack packet to perform attack.
Theoretically, the larger the number of the hosts is, the more obvious the effect will be.
Another new form of the Smurf attack is the Fraggle attack.
IV. WinNuke attack
WinNuke attack is to cause a NetBIOS fragment overlap by sending Out-Of-Band

(OOB) data packets to the NetBIOS port (139) of the specified target installed with the
Windows system so as to make the target host crash. There are also IGMP fragment
packets. Because IGMP packets cannot be fragmented generally, few systems can
solve the attack caused by IGMP fragment packets thoroughly.
V. SYN flood attack
Because of the limited resources, TCP/IP stacks only permit a restricted number of
TCP connections. Based on the above defect, the SYN Flood attack forges an SYN
packet whose source address is a bogus or non-existent address and initiates a
connection to the server. Accordingly, the server will not receive the ACK packet for its
SYN-ACK packet, which forms a semi-connection. A large number of semi-connections
will exhaust the network resources so that normal clients cannot access the network
until the semi-connections are timeout. The SYN Flood attack also takes effect in the
12-2
applications whose connection number is not limited to consume the system resources
such as memories.
VI. ICMP and UDP flood attack
ICMP and UDP Flood attack is to send a large number of ICMP messages (such as
ping) and UDP packets to the specific target in a short time so as to make the target
system not be able to transmit valid packets normally.
VII. Address/port scanning attack
Address/port scanning attack is to detect the target address and port with scanning
tools to make sure the active system connected with the target network if it receives
responses from the system and the port through which the host provides services for
future attack.
VIII. Ping of death attack
The ping of death attack is to attack the system by some extra large ICMP packets.
Because the field length of an IP packet is 16 bits, the maximum length of an IP packet
is 65535. Therefore, if the data length of an ICMP request packet is larger than 65507,
the entire length of the ICMP packet (ICMP data + IP header 20 + ICMP header 8) will
be larger than 65535, which may make some routers or systems crash, die or reboot.
This is the Ping of Death attack.
12.1.4 Introduction to Statistics Analysis
A firewall needs to perform a large amount of statistics calculation and analysis to

monitor data traffic as well as to detect connections between intranet and extranet. On
one hand, the firewall can perform after-the-fact analysis on the log information with the
specific analysis software. On the other hand, the firewall can implement some analysis
functions in real-time. For example, the firewall can determine whether to limit the new
connections from external networks or the new connections to some internal IP
address by analyzing whether the total number of TCP/UDP connections is greater
than the configured value.
The following figure shows a typical application of the firewall. If the IP-based statistics
analysis function from the external network to the DMZ is enabled, the firewall will limit
new connections from the external network when the number of the TCP connections
to the server is greater than the configured value until the number drops to the normal
range.
12-3
Enable statistics function

SecPath
Internet
PC
Ethernet TCP connection
Internal netw ork
DMZ
Server
Figure 12-1 Firewall denies the redundant external connections for the server
12.2 Attack Prevention Configuration

The attack prevention configuration includes:
z Enabling ARP Flood attack prevention function
z Enabling ARP spoofing attack prevention function
z Enabling the IP Spoofing attack prevention function
z Enabling the Land attack prevention function
z Enabling the Smurf attack prevention function
z Enabling the WinNuke attack prevention function
z Enabling the Fraggle attack prevention function
z Enabling Frag Flood attack prevention function
z Enabling the SYN Flood attack prevention function
z Enabling the ICMP Flood attack prevention function
z Enabling the UDP Flood attack prevention function
z Enabling the ICMP redirect packet control function
z Enabling the ICMP unreachable packet attack prevention function
z Enabling the IP Sweep attack prevention function
z Enabling the port scan attack prevention function
z Enabling the control function for the IP packet carrying route record
z Enabling the attack prevention for route record options
z Enabling the Tracert packet control function
z Enabling the Ping of Death attack prevention function
z Enabling the Teardrop attack prevention function
z Enabling the TCP flag validity detection function
z Enabling the IP fragment packet detection function
z Enabling the large ICMP packet control function
12-4
12.2.1 Enabling/Disabling ARP Flood Attack Prevention
Table 12-1 Enable/disable ARP Flood attack prevention
Operation Command
firewall defend arp-flood [ max-rate
Enable ARP Flood attack prevention
rate-number ]
undo firewall defend arp-flood
Disable ARP Flood attack prevention
[ max-rate ]
By default, ARP Flood attack prevention is not enabled. The maximum connection rate
for receiving ARP packets ranges from 1 to 1,000,000 (pps) and defaults to 100 pps.
12.2.2 Configuring ARP Spoofing Attack Prevention
Table 12-2 Configure ARP spoofing attack prevention
Operation Command
Enable ARP spoofing attack prevention,
firewall defend arp-spoofing
and specify to use non-loose detection
Disable ARP spoofing attack prevention undo firewall defend arp-spoofing
Enable ARP spoofing attack prevention,
firewall defend arp-spoofing loose
and specify to use loose detection
Disable loose detection and enable undo firewall defend arp-spoofing
non-loose detection loose
By default, ARP spoofing attack prevention is disabled.
12.2.3 Enabling/Disabling the IP Spoofing Attack Prevention Function
Table 12-3 Enable/disable the IP Spoofing attack prevention function
Operation Command
Enable the IP Spoofing attack
firewall defend ip-spoofing
prevention function
Disable the IP Spoofing attack
undo firewall defend ip-spoofing
prevention function
12-5
By default, the IP Spoofing attack prevention function is disabled.
Note:
The IP Spoofing attack prevention function cannot be used in transparent mode.
12.2.4 Enabling/Disabling the Land Attack Prevention Function
Table 12-4 Enable/disable the Land attack prevention function
Operation Command
Enable the Land attack prevention function firewall defend land
Disable the Land attack prevention function undo firewall defend land
By default, the Land attack prevention function is disabled.
12.2.5 Enabling/Disabling the Smurf Attack Prevention Function
Table 12-5 Enable/disable the Smurf attack prevention function
Operation Command
Enable the Smurf attack prevention function firewall defend smurf
Disable the Smurf attack prevention function undo firewall defend smurf
By default, the Smurf attack prevention function is disabled.
12.2.6 Enabling/Disabling the WinNuke Attack Prevention Function
Table 12-6 Enable/disable the WinNuke attack prevention function
Operation Command
Enable the WinNuke attack prevention function firewall defend winnuke
Disable the WinNuke attack prevention function undo firewall defend winnuke
By default, the WinNuke attack prevention function is disabled.
12-6
12.2.7 Enabling/Disabling the Fraggle Attack Prevention Function
Table 12-7 Enable/disable the Fraggle attack prevention function
Operation Command
Enable the Fraggle attack prevention function firewall defend fraggle
Disable the Fraggle attack prevention function undo firewall defend fraggle
By default, the Fraggle attack prevention function is disabled.
12.2.8 Enabling/Disabling Frag Flood Attack Prevention
Table 12-8 Enable/disable Frag flood attack prevention
Operation Command
Enable Frag Flood attack firewall defend frag-flood [ max-identical-rate
prevention max-identical-rate ] [ max-total-rate max-total-rate ]
Disable Frag Flood attack undo firewall defend frag-flood
prevention [ max-identical-rate ] [ max-total-rate ]
By default, Frag Flood attack prevention is not enabled. The max-identical-rate

argument ranges from 1 to 10,000 and defaults to 50. The max-total-rate argument
ranges from 1 to 10,000 and defaults to 100.
Note:
If the destination of the Frag flood attack packet is the firewall, the firewall warns but
does not drop the packets; otherwise, the attack is warned and the packets are
dropped.
12.2.9 Enabling/Disabling the SYN Flood Attack Prevention Function
The SYN Flood attack prevention function can be configured to the specific security
zone or the specific IP address. Only when the SYN Flood attack prevention function is
enabled and the inbound IP statistics function of the protected zone (or the zone to
which the protected IP belongs) is enabled can the SYN Flood attack prevention
function be enabled.
12-7
I. Enabling/disabling the SYN flood attack prevention function
Table 12-9 Enable/disable the SYN Flood attack prevention function
Operation Command
Enable the SYN Flood attack prevention
firewall defend syn-flood enable
function
Disable the SYN Flood attack prevention undo firewall defend syn-flood
function enable
By default, the SYN Flood attack prevention function is disabled.
II. Configuring the specified SYN Flood attack prevention function
Table 12-10 Configure the SYN Flood attack prevention function
Operation Command
firewall defend syn-flood ip
ip-address [ max-rate rate-number ]
function for IPs
[ tcp-proxy ]
firewall defend syn-flood zone

zone-name [ max-rate rate-number ]
function for all IPs of the zone
[ tcp-proxy ]
Disable the SYN Flood attack prevention undo firewall defend syn-flood ip
function for some IPs ip-address [ max-rate ] [ tcp-proxy ]
Disable the SYN Flood attack prevention
undo firewall defend syn-flood ip
function for all IPs
Disable the SYN Flood attack prevention undo firewall defend syn-flood zone
function for all IPs of some zones zone-name [ max-rate ] [ tcp-proxy ]
Disable the SYN Flood attack prevention
undo firewall defend syn-flood zone
function for IPs of all zones
Disable all the SYN Flood attack
undo firewall defend syn-flood
prevention functions
By default, the SYN Flood attack prevention function is disabled. max-rate indicates
the maximum connection rate of SYN packets, in the range of 1 to 1,000,000, and the
default value is 1000. tcp-proxy indicates the TCP proxy. The TCP proxy can start
automatically when the protected host is attacked by SYN Flood and close
automatically when the host is safe.
12-8
Note:
z When configuring SYN Flood attack prevention, the IP-based priority is higher than
the zone-based priority. If the function of SYN Flood attack prevention is enabled
both specific to a particular IP address and to all IP addresses in the zone to which
the IP address belongs, the IP-based detection parameters are preferred. If the
IP-based configuration is disabled, the zone-based parameters will be applied.
z The SYN Flood attack prevention function (SYN Flood, ICMP Flood and UDP Flood
function) of SecPath firewall can protect up to 1000 IPs at the same time.
z If to enable the SYN Flood attack prevention function, you must configure TCP
proxy.
Caution:
Following three points are necessary to enable the SYN Flood attack prevention
function.
z Enable the inbound IP statistics function in the protected zone (or the zone where
the protected IP locates)
z Enable the SYN Flood attack prevention function
z Configure the specific SYN Flood attack prevention function
z Configure the Local zone to prevent attacks to the firewall
III. Enabling/disabling TCP proxy
TCP proxy is used to protect the target host or all hosts in the target security zone from
SYN Flood attacks. Before establishing a TCP connection to the protected host, an
outside host must first run the three-way handshake with the firewall. If the three-way
handshake fails, then the outside host cannot establish the TCP connection. This can
effectively block malicious attacks to the internal hosts.
Table 12-11 Enable/disable TCP proxy
Operation Command
Enable TCP proxy on a specified host or firewall tcp-proxy { ip ip-address | zone
security zone zone-name }
Disable TCP proxy on a specified host or undo firewall tcp-proxy { ip ip-address
security zone | zone zone-name }
By default, TCP proxy is not enabled on any host or security zone.
12-9
Note:
Although you can also enable TCP proxy when configuring SYN flood attack prevention,
the configuration with this command takes preference over that. That is, TCP proxy will
be enabled for protecting the target host or security zone no matter if SYN flood attacks
occur.
12.2.10 Enabling/Disabling the ICMP Flood Attack Prevention Function
The ICMP Flood attack prevention function can be configured to the specific security
zone or the specific IP address. Only when the ICMP Flood attack prevention function
is enabled and the inbound IP statistics function of the protected zone (or the zone to
which the protected IP belongs) is enabled, can the ICMP Flood attack prevention
I. Enabling/disabling ICMP flood attack prevention function
Table 12-12 Enable/disable the ICMP Flood attack prevention function
Operation Command
Enable the ICMP Flood attack
firewall defend icmp-flood enable
prevention function
Disable the ICMP Flood attack undo firewall defend icmp-flood
prevention function enable
By default, the ICMP Flood attack prevention function is disabled.
II. Configuring the specified ICMP flood attack prevention function
Table 12-13 Configure the ICMP Flood attack prevention function
Operation Command
Enable the ICMP Flood attack firewall defend icmp-flood ip
prevention function for IPs ip-address [ max-rate rate-number ]
Enable the ICMP Flood attack firewall defend icmp-flood zone
prevention function for all IPs of the zone zone-name [ max-rate rate-number ]
Disable the ICMP Flood attack undo firewall defend icmp-flood ip
prevention function for some IPs ip-address [ max-rate ]
Disable the ICMP Flood attack
undo firewall defend icmp-flood ip
prevention function for all IPs
12-10
Operation Command
undo firewall defend icmp-flood zone
prevention function for all IPs of some
zone-name [ max-rate ]
zones
undo firewall defend icmp-flood zone
prevention function for IPs of all zones
Disable all the ICMP Flood attack
undo firewall defend icmp-flood
By default, the ICMP Flood attack prevention function is disabled. max-rate indicates
the maximum connection rate of ICMP packets, in the range of 1 to 1,000,000. The
default value is 1000.
Note:
z When configuring ICMP Flood attack prevention, the IP-based priority is higher than
the zone-based priority. If the function of ICMP Flood attack prevention is enabled
both specific to a particular IP address and to all IP addresses of the zone to which
z The SYN Flood attack prevention function (SYN Flood, ICMP Flood and ICMP
Flood function) of SecPath firewall can protect up to 1000 IPs at the same time.
Caution:
Following three points are necessary to enable the ICMP Flood attack prevention
function.
z Enable the ICMP Flood attack prevention function
z Configure the specific ICMP Flood attack prevention function
12.2.11 Enabling/Disabling the UDP Flood Attack Prevention Function
The UDP Flood attack prevention function can be configured to the specific security
zone or the specific IP address. Only when the UDP Flood attack prevention function is
enabled and the inbound IP statistics function of the protected zone (or the zone to
12-11
which the protected IP belongs) is enabled, can the UDP Flood attack prevention
I. Enabling/disabling UDP Flood attack prevention function
Table 12-14 Enable/disable the UDP Flood attack prevention function
Operation Command
Enable the UDP Flood attack prevention
firewall defend udp-flood enable
function
Disable the UDP Flood attack undo firewall defend udp-flood
prevention function enable
By default, the UDP Flood attack prevention function is disabled.
II. Configuring the specified UDP Flood attack prevention function
Table 12-15 Configure the UDP Flood attack prevention function
Operation Command
Enable the UDP Flood attack prevention firewall defend udp-flood ip
function for IPs ip-address [ max-rate rate-number ]
Enable the UDP Flood attack prevention firewall defend udp-flood zone
function for all IPs of the zone zone-name [ max-rate rate-number ]
Disable the UDP Flood attack undo firewall defend udp-flood ip
prevention function for some IPs ip-address [ max-rate ]
Disable the UDP Flood attack
undo firewall defend udp-flood ip
prevention function for all IPs
undo firewall defend udp-flood zone
prevention function for all IPs of some
zone-name [ max-rate ]
zones
undo firewall defend udp-flood zone
prevention function for IPs of all zones
Disable all the UDP Flood attack
undo firewall defend udp-flood
By default, the UDP Flood attack prevention function is disabled. max-rate indicates
the maximum connection rate of UDP packets, in the range of 1 to 1,000,000. The
default value is 1000.
12-12
Note:
z When configuring UDP Flood attack prevention, the IP-based priority is higher than
the zone-based priority. If the function of UDP Flood attack prevention is enabled
both specific to a particular IP address and to all IP addresses of the zone to which
z The SYN Flood attack prevention function (SYN Flood, ICMP Flood and UDP Flood
function) of SecPath firewall can protect up to 1000 IPs at the same time.
Caution:
Following three points are necessary to enable the UDP Flood attack prevention
function.
z Enable the UDP Flood attack prevention function
z Configure the specific UDP Flood attack prevention function
12.2.12 Enabling/Disabling the ICMP Redirect Packet Control Function
Table 12-16 Enable/disable the ICMP redirect packet control function
Operation Command
Enable the ICMP redirect packet control
firewall defend icmp-redirect
function
Disable the ICMP redirect packet control
undo firewall defend icmp-redirect
function
By default, the ICMP redirect packet control function is disabled.
12.2.13 Enabling/Disabling the ICMP Unreachable Packet Control Function
12-13
Table 12-17 Enable/disable the ICMP unreachable packet control function
Operation Command
Enable the ICMP unreachable packet
firewall defend icmp-unreachable
control function
Disable the ICMP unreachable packet undo firewall defend
control function icmp-unreachable
By default, the ICMP unreachable packet control function is disabled.
12.2.14 Enabling/Disabling the IP Sweep Attack Prevention Function
Table 12-18 Enable/disable the IP Sweep attack prevention function
Operation Command
Enable the IP Sweep attack firewall defend ip-sweep [ max-rate
prevention function rate-number ] [ blacklist-timeout minutes ]
Disable the IP Sweep attack
undo firewall defend ip-sweep
prevention function
By default, the IP Sweep attack prevention function is disabled. max-rate indicates the
maximum sweeping rate, in the range of 1 to 10,000. The default value is 4000.
blacklist-timeout indicates the time when the address is in the blacklist, in the range of
1 to 1,000 minutes. The default value is 0 indicating the address is not added in the
blacklist.
Caution:
z Following two points are necessary to enable the IP Sweep attack prevention
function: 1) Enable the outbound IP statistics function in the zone where the
connection is initiated; 2) Configure the IP Sweep attack prevention function.
z The aging time of blacklist entries must be larger than that of firewall session (using
the firewall session aging-time command). Otherwise, attack packets may pass
the firewall. So, it is recommended to set the aging time of blacklist entries to be
greater than 2 minutes.
z The blacklist function set by using this command takes effect only when the blacklist
function is enabled on the firewall. Refer to 5.4 “Black List” for detailed description
on blacklist.
12-14
12.2.15 Enabling/Disabling the Port Scan Attack Prevention Function
Table 12-19 Enable/disable the port scan attack prevention function
Operation Command
firewall defend port-scan [ max-rate
Enable the port scan attack prevention
rate-number ] [ blacklist-timeout
function
minutes ]
Disable the port scan attack prevention
undo firewall defend port-scan
function
By default, the port scan attack prevention function is disabled. max-rate indicates the
maximum scanning rate, in the range of 1 to 10,000. The default value is 4000.
blacklist-timeout indicates the time when the address is in the blacklist, in the range of
1 to 1,000 minutes. The default value is 0 indicating the address is not added in the
blacklist.
Caution:
z Following two points are necessary to enable the IP Sweep attack prevention
function: 1) Enable the outbound IP statistics function in the zone where the
connection is initiated; 2) Configure the IP Sweep attack prevention function; 3)
Configure the Local zone to prevent attacks to the firewall.
z The aging time of blacklist entries must be larger than that of firewall session (using
the firewall session aging-time command). Otherwise, attack packets may pass
the firewall. So, it is recommended to set the aging time of blacklist entries to be
greater than 2 minutes.
z The blacklist function set by using this command takes effect only when the blacklist
function is enabled on the firewall. Refer to 5.4 “Black List” for detailed description
on blacklist.
12.2.16 Enabling/Disabling the Control Function of the IP Packet

Carrying Source Route
12-15
Table 12-20 Enable/disable the control function for the IP packet carrying source route
Operation Command
Enable the control function for the IP
firewall defend source-route
packet carrying source route
Disable the control function for the IP
undo firewall defend source-route
packet carrying source route
By default, the attack prevention function for the IP packet carrying source route is
disabled.
12.2.17 Enabling/Disabling Attack Prevention for Route Record Options
Table 12-21 Enable/disable attack prevention for route record options
Operation Command
Enable attack prevention for route
firewall defend route-record
record options
Disable attack prevention for route
undo firewall defend route-record
record options
By default, attack prevention for route record options is not enabled.
12.2.18 Enabling/Disabling the Tracert Packet Control Function
Table 12-22 Enable/disable the Tracert packet control function
Operation Command
Enable the Tracert packet control function firewall defend tracert
Disable the Tracert packet control function undo firewall defend tracert
By default, the Tracert packet control function is disabled.
12.2.19 Enabling/Disabling the Ping of Death Attack Prevention Function
12-16
Table 12-23 Enable/disable the Ping of Death attack prevention function
operation command
Enable the Ping of Death attack
firewall defend ping-of-death
prevention function
Disable the Ping of Death attack
undo firewall defend ping-of-death
prevention function
12.2.20 Enabling/Disabling the Teardrop Attack Prevention Function
Table 12-24 Enable/disable the Teardrop attack prevention function
Operation Command
Enable the Teardrop attack prevention function
firewall defend teardrop
and specify to use non-loose detection
Disable the Teardrop attack prevention function undo firewall defend teardrop
Enable the Teardrop attack prevention function firewall defend teardrop
and specify to use loose detection teardrop-loose
Disable loose detection and enable non-loose undo firewall defend teardrop
detection teardrop-loose
By default, the Teardrop attack prevention function is disabled.

Teardrop attack prevention can work in two modes:
z Non-loose detection: In this mode, the firewall performs Teardrop attack
prevention detection for all packets received on all interfaces.
z Loose detection: In this mode, the firewall performs Teardrop attack prevention
detection for packets received on all interfaces except for bridge-template
interfaces.
12.2.21 Enabling/Disabling the TCP Flag Validity Detection Function
Table 12-25 Enable/disable the TCP flag validity detection function
Operation Command
Enable the TCP flag validity detection function firewall defend tcp-flag
Disable the TCP flag validity detection function undo firewall defend tcp-flag
By default, the TCP flag validity detection function is disabled.
12-17
12.2.22 Enabling/Disabling the IP Fragment Packet Detection Function
Table 12-26 Enable/disable the IP fragment packet detection function
Operation Command
Enable the IP fragment packet detection
firewall defend ip-fragment
function
Disable the IP fragment packet detection
undo firewall defend ip-fragment
function
By default, the IP fragment packet detection function is disabled.
12.2.23 Enabling/Disabling the Large ICMP Packet Control Function
Table 12-27 Enable/disable the large packet attack prevention function
Operation Command
Enable the large ICMP packet control
firewall defend large-icmp [ length ]
function
Disable the large ICMP packet control
undo firewall defend large-icmp
function
By default, the large ICMP packet control function is disabled. The maximum length of
the packet is 28 to 65535 bytes. The default value is 8000.
12.3 Warning Level Configuration

The system-based statistics function of the SecPath firewall provides connection
number and connection rate monitoring. The firewall outputs a warning when the
connection number and connection rate exceed the limit configured. The warning level
can be classified into two kinds, namely, alarm log and discard. “alarm log” means that
the system only outputs the alarm log when the connection number and connection rate
are greater than the threshold value; “discard” means when the connection number and
connection rate are greater than the threshold value, the system not only outputs the
alarm log, but also discards the subsequent packets. Only when the connection
number and connection rate falls below the threshold can the system stop discarding
the packets.
12-18
Table 12-28 Set the warning level
Operation Command
Set the warning level to outputting the
firewall statistic warning-level drop
alarm log and discarding packets
Set the warning level to outputting the undo firewall statistic warning-level
alarm log only drop
By default, the warning level is outputting the alarm log only.
Note:
The commands in the above table are effective to only security zone-based statistics
and IP-based statistics, but not to system statistics.
12.4 System-Based Statistics Configuration

Before configuring the traffic restriction function, you should enable the corresponding
statistics function. Once the statistics function is disabled, the associated restriction
alarm function will be invalid accordingly.
The system-based statistics function configuration includes:
z Enabling the system-based statistics function
z Enabling monitor the number of system-based connections
z Enabling alarm detection for abnormal system packet rate
12.4.1 Enabling/Disabling the System-Based Statistics Function
Enable the system-based statistics function to perform statistics on all the packets
passing the firewall.
Table 12-29 Enable/disable the system-based statistics function
Operation Command
Enable the system-based statistics function firewall statistics system enable
undo firewall statistics system
Disable the system-based statistics function
enable
By default, the system-based statistics function is enabled.
12-19
Caution:
Please use the undo firewall statistics system enable command with caution. If the
system-based statistics function is disabled, the associated detection function will be
invalid accordingly. If there is traffic, disabling the statistics function may cause
inaccurate statistics. Thus, functions related to statistics are affected.
12.4.2 Configuring Monitor the Number of System-Based Connections
Using this command, you can configure the threshold value for the number of
connections in the system. The firewall will output an alarm log if the number of
TCP/UDP connections is greater than the threshold value.
Table 12-30 Configure the system-based connection number monitoring function
Operation Command
firewall statistic system
Configure the system-based connection
connect-number { tcp | udp } { high
number monitoring function
high-value low low-value
Restore the system-based connection undo statistics system
number to the default connect-number { tcp | udp }
By default, the upper threshold value of TCP or UDP connections allowed in the system
is 500000, while the lower threshold value is 450000.
12.4.3 Configuring Alarm Detection for Abnormal System Packet Rate
Using this command, you can configure the normal percentage for different types of
packets and the permitted alternation percentage. The system detects in regular time
the percentage of each type of packets, and compares the information with the
configured values. If the percentage for one type (TCP, UDP, ICMP or others) of
packets exceeds the configured upper threshold value (with the alternation added) or
falls below the lower threshold value (with the alternation subtracted), the system
exports log alarm.
12-20
Table 12-31 Configure alarm detection for abnormal system packet rate
Operation Command
firewall statistics system flow-percent tcp
Configure alarm detection for tcp-percent udp udp-percent icmp
abnormal system packet rate icmp-percent alteration alteration-percent
[ time time-value]
Restore the alarm detection for
undo firewall statistics system
abnormal system packet rate to the
flow-percent
default
By default, the percentages for TCP, UDP, and ICMP packets are 75, 15, and 5; the
permitted alternation percentage of all packets is 25; detection period is 60 minutes.
You must configure the percentages for the three types (TCP, UDP, and ICMP) of
packets simultaneously, and the sum of the three percentage numbers cannot exceed
100%, otherwise, the command will not take effect; you do not need to configure packet
percentages for other packets.
The alarm is based on the current system statistics. As long as the current system
statistics are not cleared, the alarm is issued at the specified interval.
12.5 Zone-Based Statistics Configuration

The zone-based statistics function configuration includes:
z Enabling/Disabling the Zone-Based Statistics Function
z Configuring Monitor of the Connection Number in a Security Zone
z Configuring Monitor the Rate of Connections in a Zone
12.5.1 Enabling/Disabling the Zone-Based Statistics Function
Table 12-32 Enable/disable the zone-based statistics function
Operation Command
Enable the zone-based statistics statistics enable zone { inzone |
function outzone }
Disable the zone-based statistics undo statistics enable zone { inzone |
function outzone }
Be default, the zone-based statistics function is disabled.
12-21
Caution:
If the zone-based statistics function is disabled, the associated traffic monitoring

function will be invalid accordingly.
12.5.2 Configuring Monitor of the Connection Number in a Security Zone
Using this command, you can configure the threshold value for the number of
TCP/UDP connections based on one direction in a security zone. According to the
above configuration, you can restrict the number of connections to or from the current
zone. The system will function according to the firewall statistic warning-level
command when the connection number is greater than or below the set threshold value.
Once the zone-based statistics function is enabled, the default value of the connection
number monitoring function takes effect automatically.
Table 12-33 Configure the zone-based connection number monitoring function
Operation Command
statistics connect-number { zone | ip }
Configure the zone-based connection
{ inzone | outzone } { tcp | udp } high
number monitoring function
high-limit low low-limit }
Restore the zone-based connection
undo statistics connect-number zone
number monitoring function to the
{ inzone | outzone } { tcp | udp }
default
By default, the upper threshold value of the zone-based TCP/UDP connections is

500000, and the lower threshold value is 450000.
Caution:
The connection number restriction function of a zone will not take effect unless the
corresponding statistics function is enabled.
12.5.3 Configuring Monitor the Rate of Connections in a Zone
Using this command, you can configure the threshold value for the rate (per second) of
TCP/UDP connections based on one direction in a zone. According to the above
12-22
configuration, you can restrict the rate of connections to or from the current zone. The
system will function according to the firewall statistic warning-level command when
the connection rate is greater than or below the set threshold value. Once the
zone-based statistics function is enabled, the default value of the connection rate
monitoring function takes effect automatically.
Table 12-34 Configure monitor the rate of connections in a zone
Operation Command
statistics connect-speed { zone | ip }
Configure monitor the rate of
{ inzone | outzone } { tcp | udp } { high
connections in a zone
high-limit low low-limit }
Restore monitor of monitor the rate of undo statistics connect-speed { zone
connections in a zone to the default | ip } { inzone | outzone } { tcp | udp }
By default, the threshold value of the zone-based TCP/UDP connections is 10,000, and
the lower threshold value is 9,000.
Caution:
The connection rate restriction function of a zone will not take effect unless the
corresponding statistics function is enabled.
12.6 IP-Based Statistics Configuration

The IP-based statistics function configuration includes:
z Enabling the IP-based statistics function
z Enabling monitor of the IP-based connection number
z Enabling monitor of the IP-based connection rate
12.6.1 Enabling/Disabling the IP-Based Statistics Function
Once the IP-based statistics function is enabled, the firewall will perform statistics on
the outbound/inbound data packets in the current zone based on IP addresses (source
addresses in outbound direction and destination addresses in inbound direction).
The inbound direction indicates the packet whose destination address is the local zone
and source address is other zone. The outbound direction is on the contrary.
Perform the following configuration in security zone view.
12-23
Table 12-35 Enable/disable the IP-based statistics function
Operation Command
Enable the IP-based statistics function statistics enable ip { in | out }
Disable the IP-based statistics function undo statistics enable ip { in | out }
By default, the IP-based statistics function is disabled.
Caution:
Once the IP-based statistics function is disabled, the IP-based traffic monitoring
function will be invalid accordingly.
12.6.2 Configuring Monitor of the IP-Based Connection Number
Using this command, you can configure the maximum number of TCP and UDP
connections in the outbound/inbound direction of a local IP address. With the above
configuration, you can restrict not only the number of connections initiated from the
current zone but also that of connections initiated from external networks to the current
zone. The system will function according to the firewall statistic warning-level
command when the connection number is greater than or below the set threshold value.
Once the zone-based statistics function is enabled, the default value of the connection
rate monitoring function takes effect automatically.
Table 12-36 Configure the IP-based connection number monitoring function
Operation Command
statistic connect-number ip outzone
Configure the upper and lower { tcp | udp } high high-limit low low-limit
thresholds for the IP-based TCP and
UDP connections in the outbound statistic connect-number id id ip
direction outzone { tcp | udp } high high-limit low
low-limit acl-number acl-number
Restore the default upper and lower
thresholds for the IP-based TCP and undo statistic connect-number [ id id ]
UDP connections in the outbound ip outzone { tcp | udp }
direction
Configure the upper and lower
thresholds for the IP-based TCP and statistic connect-number ip inzone
UDP connections in the inbound { tcp | udp } high high-limit low low-limit
direction
12-24
Operation Command
thresholds for the IP-based TCP and undo statistic connect-number ip
UDP connections in the inbound inzone { tcp | udp }
direction
By default, the upper threshold for the IP-based TCP and UDP connections is 500000
and the lower threshold is 450000.
Caution:
z The IP-based connection number detection function will not take effect unless the
corresponding IP-based statistics function is enabled.
z The ACL rule can only be used in one direction if you want to account the number of
the IP-based connection that matches an ACL rule at the same time.
12.6.3 Configuring Monitor of the IP-based Connection Rate
Using this command, you can configure the maximum rate of TCP and UDP
connections in the outbound/inbound direction of a local IP address. With the above
configuration, you can restrict not only the rate of connections initiated from the current
zone but also that of connections initiated from external networks to the current zone.
The system will function according to the firewall statistic warning-level command
when the connection number is greater than or below the set threshold value. Once the
zone-based statistics function is enabled, the default value of the connection rate
monitoring function takes effect automatically.
Table 12-37 Configure monitor of the IP-based connection rate
Operation Command
statistic connect-speed ip outzone
Configure the upper and lower { tcp | udp } high high-limit low low-limit
thresholds for the IP-based TCP and
UDP connection speed in the outbound statistic connect-speed id id ip
direction. outzone { tcp | udp } high high-limit
low low-limit acl-number acl-number
thresholds for the IP-based TCP and undo statistic connect-speed [ id id ]
UDP connection speed in the outbound ip outzone { tcp | udp }
direction
12-25
Operation Command
Configure the upper and lower
thresholds for the IP-based TCP and statistic connect-speed ip inzone
UDP connection speed in the inbound { tcp | udp } high high-limit low low-limit
direction
thresholds for the IP-based TCP and undo statistic connect-speed ip
UDP connection speed in the inbound inzone { tcp | udp }
direction
By default, the upper threshold of the IP-based TCP and UDP connection rate is 10,000,
and the lower threshold is 9000.
12.7 Displaying and Debugging Attack Prevention and

Packet Statistics
12.7.1 Displaying and Debugging Attack Prevention
running of the attack prevention to verify the effect of the configuration. Execute the
debugging command to debug the attack prevention.
Table 12-38 Displaying and debugging attack prevention
Operation Command
Display the type of the attack prevention
display firewall defend flag
applied on the firewall
Display the session information of TCP display firewall tcp-proxy session
proxy [ zone zone-name | ip ip-address ]
Enable all attack prevention debugging debugging firewall defend all
Enable debugging for ARP Flood attack
debugging firewall defend arp-flood
prevention
Enable debugging for ARP spoofing debugging firewall defend
attack prevention arp-spoofing
Enable the debugging of IP spoofing debugging firewall defend
attack prevention ip-spoofing
Enable the Land attack prevention
debugging firewall defend land
debugging
Enable the debugging of Smurf attack
debugging firewall defend smurf
prevention
Enable the debugging of Fraggle attack
debugging firewall defend fraggle
prevention
12-26
Operation Command
Enable debugging for Frag Flood attack
debugging firewall defend frag-flood
prevention
Enable the WinNuke attack prevention
debugging firewall defend winnuke
debugging
Enable the debugging of SYN Flood
debugging firewall defend syn-flood
attack prevention
Enable the debugging of UDP Flood
debugging firewall defend icmp-flood
attack prevention
Enable the debugging of UDP Flood
debugging firewall defend udp-flood
attack prevention
Enable the debugging of ICMP debugging firewall defend
redirection packet attack prevention icmp-redirect
Enable the debugging of ICMP debugging firewall defend
unreachable packet attack prevention icmp-unreachable
Enable the debugging of address sweep
debugging firewall defend ip-sweep
attack prevention
Enable the debugging of port sweep
debugging firewall defend port-scan
attack prevention
Enable debugging for attack prevention debugging firewall defend
for route record options route-record
Enable the debugging of source route debugging firewall defend
option packet attack prevention source-route
Enable the debugging of Tracert attack
debugging firewall defend tracert
prevention
Enable the debugging of Ping of Death debugging firewall defend
attack prevention ping-of-death
Enable the debugging of TearDrop
debugging firewall defend teardrop
attack prevention
Enable the debugging of TCP flag
debugging firewall defend tcp-flag
validity detection attack prevention
Enable the debugging of IP
debugging firewall defend
fragmentation packet detection attack
ip-fragment
prevention
Enable the debugging of large ICMP
debugging firewall defend large-icmp
packet attack prevention
12-27
Note:
When the firewall functions in transparent mode, it may happen that the attacking
packets appear are n-1 times of the actual packets. (n is the number of the interfaces
which are up currently.) This is because the firewall working in transparent mode
broadcasts the packets from unknown MAC address through all the interfaces (except
the receiving interface) which are up.
12.7.2 Displaying Packet Statistics
You can execute the display command in view and the reset command in user view.
Table 12-39 Displaying packet statistics
Operation Command
display firewall statistic { system |
zone zone-name { inzone | outzone } |
Display statistics of the firewall
ip { ip-address { source-ip |
destination-ip | both } | which } }
display firewall statistic system
Display the statistics of the firewall
[ defend | flow-percent ]
reset firewall statistic system
Clear the statistics of the firewall
[ defend | current ]
reset firewall statistic zone
Clear the zone statistics of the firewall
zone-name { inzone | outzone }
reset firewall statistic ip ip-address
Clear the IP statistics of the firewall
{ source-ip | destination-ip | both }
12.8 Configuring SMTP Client

SecPath firewall supports SMTP client functions, which can send realtime mails to the
specified address at a predefined time. Mails can provide the administrator with firewall
information on system statistics, attacks and defense, traffic alarms, web page filtering
and mail filtering. This enables the administrator informed of firewall statistics, and
improves firewall flexibility and maintainability significantly.
Note:
The normal running of SMTP client is dependent on the domain name resolution of
DNS client (DNSC). Refer to 12.9 Configuring DNS Client.
12-28
12.8.1 Configuring Mail Triggering Time
This is to specify the time that the firewall triggers mails.

Table 12-40 Configure mail triggering time
Operation Command
Configure mail triggering time. smtpc trigger time hh:mm
Cancel the configured mail triggering
undo smtpc trigger { all | time hh:mm }
time.
By default, no mail triggering time is configured.

The value for hh:mm falls between 00:00 to 23:59. You can execute this command for
several times to add up to five triggering time point.
12.8.2 Configuring Mail Addresses
This is to configure the receiving addresses of mails.

Table 12-41 Configure a timed mail address
Operation Command
smtpc administrator mail
Configure a mail address.
mail-address
undo smtpc administrator { all | mail
Cancel the configured mail addresses.
mail-address }
By default, no address is configured for timed mails.

The specified addresses must be a standard SMTP mail address. You can execute this
command for several times to add up to five addresses.
12.8.3 Displaying and Debugging SMTP Client
After the above configurations, you can execute the display command to display
configuration statistics of the SMTP client, so as to validate your configurations. You
can also run the debugging command to debug the SMTP client.
Table 12-42 Display and debug SMTP client
Operation Command
Display SMTP client configuration display smtpc [ administrator |
statistics trigger ]
12-29
Operation Command
Enable SMTP client debugging. debugging smtpc
Disable SMTP client debugging. undo debugging smtpc
12.9 Configuring DNS Client

DNS client (DNSC) is an important component for the normal running of SMTP client.
DNSC resolves the domain name in IP address format, and then the SMTP client can
send mails to the correct destination address.
12.9.1 Configuring DNS Server
You need to know the address of the domain name server before resolving DNS
domain name; then the request packet can be sent to the correct server. You can use
the following command to configure the IP address of DNS server.
Table 12-43 Configure DNS server
Operation Command
Configure the IP address of DNS server dnsc server ip ip-address
Cancel the configuration of DNS server undo dnsc server { all | ip ip-address }
By default, DNS server is not configured.
12.9.2 Configuring DNS Cache
When resolving the DNS client name, the result that comes back from DNS server can
be stored in cache. Thus, next time when the same name needs to be resolved, the
name can be found in the DNS cache and the network traffic is relieved.
Table 12-44 Configure DNS cache
Operation Command
dnsc cache add domain domain-name
Add an entry in DNS cache
type { a | mx } ip ip-address ttl ttl
dnsc cache delete domain

domain-name type { a | mx}
Delete the entry from DNS cache
undo dnsc cache { all | domain
domain-name type { a | mx } }
12-30
By default, no entry is added in the DNS cache.
12.9.3 Displaying and Debugging DNS Client
Upon finishing the above configuration, execute display command in any view to
display and verify the configuration of DNS client. You can debug the DNS client by
executing debugging command in user view.
Operation Command
Display the configuration of DNS client display dnsc { server | cache }
Enable the debugging of DNS client debugging dnsc
Disable the debugging of DNS client undo debugging dnsc
12.10 Typical Examples of Attack Prevention and Packet

Statistics Configuration
12.10.1 Enabling the Land Attack Prevention Function
Adopt the firewall in the network and configure the Ethernet 0/0/0 in the trust zone, the
Ethernet 2/0/0 in the untrust zone and the Ethernet 1/0/0 in the DMZ zone.
II. Network diagram
192.168.1.0/24
PC PC
SecPath
202.1.0.0/16
Ethernet2/0/0
Ethernet1/0/0
Ethernet0/0/0
PC
10.110.0.0/8
Internet
Server
10.110.1.1
Figure 12-2 Network diagram of the firewall attack prevention configuration

# Configure the Ethernet 0/0/0 on the firewall.
12-31



# Add the Ethernet0/0/0 to the trust zone.

[H3C] firewall zone trust
[H3C-zone-trust] add interface Ethernet 0/0/0
# Add the Ethernet 2/0/0 to the untrust zone.

[H3C] firewall zone untrust
[H3C-zone-untrust] add interface Ethernet 2/0/0
# Add the Ethernet 1/0/0 to the DMZ zone.

[H3C] firewall zone DMZ
[H3C-zone-DMZ] add interface Ethernet 1/0/0
# Enable the Land attack prevention function.

[H3C-zone-DMZ] quit
[H3C] firewall defend land
12.10.2 Enabling the SYN Flood Attack Prevention Function
Ethernet 2/0/0 in the untrust zone and the Ethernet 1/0/0 in the DMZ zone. You are
required to enable the SYN Flood attack prevention function on the server in the DMZ
zone.
II. Network diagram
Refer to Figure 12-2.

12-32


# Add the Ethernet 0/0/0 to the trust zone.

# Add the Ethernet 2/0/0 to the untrust zone.


# Enable the inbound IP statistics function in the DMZ zone.

[H3C-zone-DMZ] statistics enable ip inzone
# Enable the SYN Flood attack prevention function in the global scope.
[H3C-zone-trust] quit
[H3C] firewall defend syn-flood enable
# Enable the SYN Flood attack prevention function on the server at 10.110.1.1, set the
maximum connection rate of SYN packets to 500 packets per second, and enable the
TCP proxy manually.
[H3C] firewall defend syn-flood ip 10.110.1.1 max-rate 500 tcp-proxy
12.10.3 Enabling the Address Scanning Attack Prevention Function
Ethernet 2/0/0 in the untrust zone and the Ethernet 1/0/0 in the DMZ zone. You are
required to enable the address scanning attack prevention function on the server in the
untrust zone.
II. Network diagram

12-33



# Add the Ethernet 0/0/0 to the trust zone.

# Add the Ethernet2/00 to the untrust zone.


# Enable the outbound IP statistics function in the untrust zone.

[H3C-zone-untrust] statistics enable ip outzone
[H3C-zone-untrust] quit
# Enable the address scanning attack prevention and set the maximum scanning rate
to 1000 packets per second. Set the valid time of the blacklist to 5 minutes and enable
the blacklist function.
[H3C] firewall defend ip-sweep max-rate 1000 blacklist-timeout 5
12.10.4 Monitoring the Zone Connection Number
Adopt the firewall and bind Ethernet 0/0/0 to the trust zone, Ethernet 2/0/0 to the untrust
zone and Ethernet 1/0/0 to the DMZ zone. You are required to configure restriction on
the number of connections to or from the trust zone respectively.
12-34
II. Network diagram
192.168.1.0/24
PC PC
SecPath 202.1.0.0/16
Router
Internet
Ethernet
Ethernet0/0/0 2/0/0
Ethernet
1/0/0
PC 10.110.0.0/8
Server
Figure 12-3 Network diagram of the firewall statistics function configuration
# Configure the interface Ethernet 0/0/0 on the firewall.



# Bind the interface Ethernet 0/0/0 to the trust zone.

[H3C-zone-trust] add interface ethernet 0/0/0
# Bind the interface Ethernet 2/0/0 to the untrust zone.

[H3C-zone-untrust] add interface ethernet 2/0/0
# Bind the interface Ethernet 1/0/0 to the DMZ zone.

[H3C] firewall zone dmz
[H3C-zone-dmz] add interface ethernet 1/0/0
# Enable the outbound packet statistics function in the trust zone.

[H3C-zone-trust] statistics enable zone outzone
# Enable the inbound packet statistics function in the trust zone.
12-35
[H3C-zone-trust] statistics enable zone inzone
# Configure the threshold value of the inbound TCP connections in the trust zone to
120000.
[H3C-zone-trust] statistics connect-number zone inzone tcp high 120000 low
10000
# Configure the threshold value of the outbound TCP connections in the trust zone to
200000.
[H3C-zone-trust] statistics connect-number zone outzone tcp high 200000 low
10000
12.10.5 Displaying the Specified IP Statistics Information
Adopt the firewall and bind Ethernet 0/0/0 to the trust zone, Ethernet 2/0/0 to the untrust
zone and Ethernet 1/0/0 to the DMZ zone.
II. Network diagram



# Bind the interface Ethernet 0/0/0 to the trust zone.

# Bind the interface Ethernet 2/0/0 to the untrust zone.

[H3C-zone-untrust] add interface ethernet 2/0/0
# Add Ethernet 1/0/0 to DMZ zone.

[H3C-zone-dmz] add interface ethernet 1/0/0
12-36
# Access zone view.

# Enable the outbound packet statistics function in the zone to perform statistics on
source addresses.
[H3C-zone-trust] statistic enable ip outzone
# Enable the inbound packet statistics function in the zone to perform statistics on
destination addresses.
[H3C-zone-trust] statistic enable ip inzone
# Display the statistics on the connections initiated from 192.168.1.3 in the trust zone.
<H3C> display firewall statistics ip 192.168.1.3 source-ip
# Display the statistics on the connections initiated to 192.168.1.3 in the trust zone.
<H3C> display firewall statistics ip 192.168.1.3 destination-ip
12.11 Attack Prevention Troubleshooting

Fault1: The SYN Flood attack prevention function is invalid.
Troubleshooting: Take the following procedures.
1) Check whether the SYN Flood attack prevention function is enabled for the
destination zone or for the destination IP.
2) Check whether the SYN Flood attack prevention function is enabled in the global
scope.
3) Check whether the inbound IP statistics function is enabled in the destination zone
or in the zone to which the destination IP belongs.
Fault2: The address scanning attack prevention function is invalid.
Troubleshooting: Take the following procedures.
1) Check whether the address scanning attack prevention function is enabled.
2) Check whether the outbound IP statistics function is enabled in the zone to which
the scanning source belongs.
12-37
H3C SecPath Series Security Products Chapter 13 IDS Cooperation
Chapter 13 IDS Cooperation
13.1 Introduction to IDS Cooperation

With the development of broadband network technology, demands for network security
increase. To answer this situation, IDS (intrusion detect system) device emerges, which
detects packets in depth. An IDS device can assist preventing network attacks and
viruses by analyzing the content characteristic of the packets that pass through a
network. It can also analyze packets for protocol anomaly and traffic anomaly. Since
IDS devices are bypassed by other access devices, they only detect network traffic
instead of actually preventing any intrusion. When cooperating with firewalls, an IDS
device informs the firewalls of intruding packets to help them preventing these packets.
SecPath
10.153.110.96
10.153.110.98
Switch IDS device
Figure 13-1 Typical IDS network diagram
Upon detecting dubious packets, an IDS device sends cooperation messages to

firewall devices through SNMP (simple network management protocol) to block these
packets. The message contains information such as MAC address, IP address,
protocol number, the source and destination port number, it also contains information
about operations against dubious packets, acting time and valid/invalid conditions.
After receiving and analyzing the cooperation messages, the firewalls attempt to block
these packets by generating and issuing corresponding ACL (access control list) rules,
which are applied when the firewalls forward packets.
13-1
13.2 Configuring IDS Cooperation

13.2.1 Issuing IDS-Reconfigured ACL Rules to Interfaces
Upon receiving cooperation messages sent by an IDS device, a firewall analyzes these
messages and generates corresponding ACL rules. To block the packet, the firewall
must issue these ACL rules to its interfaces for the ACL rules to take effect.
Table 13-1 Issue IDS-reconfigured ACL rules to interfaces
Operation Command
Enable issuing IDS-reconfigured ACL rules to interfaces ids-acl enable
Disable issuing IDS-reconfigured ACL rules to interfaces undo ids-acl enable
IDS-reconfigured ACL rules are not issued to any interface by default.
Caution:
When the firewall works in transparent mode, the IDS-reconfigured ACL rules to its
interface should be issued in the inbound direction. To filter the packets effectively, the
IDS-reconfigured ACL rules are issued to both the outbound and inbound interfaces.
13.2.2 Displaying and Debugging IDS Cooperation
Use the commands listed in Table 13-2 to display information about IDS cooperation
and IDS-reconfigured ACL rules, and enable/disable debugging IDS cooperation.
Execute the display command in any view, and execute the debugging command in
user view.
Table 13-2 Display and debug IDS cooperation
Operation Command
display ids { all | controlled-interface |
Display information about IDS
name name | source ip-addr |
cooperation
destination ip-addr }
Display IDS-reconfigured ACL rules display ids-acl { all | name name }
Enable debugging IDS cooperation debugging ids
Disable debugging IDS cooperation undo debugging ids
13-2
13.2.3 IDS Configuration Example
As Figure 13-2 shows, the firewall, which forwards all incoming and outgoing packets,
operates as a boundary device between the internal and external network. The IDS
device detects and handles packets in the internal network according to a set of
detecting rules. The firewall listens to the IDS device for cooperation messages and
issues ACL rules to its interfaces to block dubious packets.
II. Network diagram
Attacker
10.153.111.101
10.153.111.96
SecPath
10.153.110.96
10.153.110.98
Switch IDS device
Server
Figure 13-2 Network diagram that employs IDS cooperation
# Assign IP addresses for the interfaces of the firewall.

[H3C] interface GigabitEthernet 0/0
[H3C-GigabitEthernet0/0] ip address 10.153.110.96 24
# Configure SNMP
[H3C] snmp-agent
13-3
[H3C] snmp-agent sys-info version all
Note:
To make IDS devices operate properly, you must ensure that SNMP datagrams can be
transmitted between firewalls and IDS devices, and the SNMP configurations of the
firewalls are in accordance with those of IDS devices. Refer to sections about SNMP
configuring in basic configurations part of this manual for details on SNMP configuring.
# Enable issuing IDS-reconfigured ACL rules to the interfaces of the firewall.

[H3C-GigabitEthernet0/0] ids-acl enable
Caution:
The switch shown in Figure 13-2 must support port mirroring function, by which traffic
on the port to be detected can be mirrored to the one that connects the detecting port of
the IDS device.
Note:
At present, the IDS device could be SecEngine D200 only. Its configuration is beyond
the scope of this manual.
13-4
H3C SecPath Series Security Products Chapter 14 Log Maintenance
Chapter 14 Log Maintenance
14.1 Introduction to Log

I. Types
Log functions to save system messages or packet filtering actions to the buffer, or direct
them to log host. By analyzing and managing log information, network administrators
can detect security leaks and attack types. Furthermore, real-time log records help to
detect ongoing intrusions.
SecPath firewall uniformly takes various attacks and events into account, and
standardizes kinds of log formats and statistics, so as to ensure a uniform log style and
serious log functions.
SecPath firewall includes the following log information:
z NAT/ASPF log
z Attack prevention log
z Traffic monitoring log
z Black list log
z Address binding log
II. Output Principle
The above mentioned logs are broken into two categories based on output method:
binary flow log and Syslog log. Figure 14-1 shows the corresponding relationships
between log types and output methods.
Binary flow log
NAT /ASPF Lo Log information

g
inf l og Log Server
or g
Defense Log
ma slo
inf ti Sy
orm on
atio
Statistics Log info n
rmation
Terminal
Information
Log information
Blacklist center Consle
tio n
fo rma Redirect Buffer
in
Address L og
binding ……
Figure 14-1 Log output principles on the SecPath
In the SecPath firewall, the log information about attack prevention, traffic monitoring,
blacklist and address binding are generated in little capacities. Therefore, such logs are
14-1
outputted in Syslog format. The information must be sent to the Comware-based

information center for log management and redirection. For example, you can choose
to either display the log information on the terminal screen or output the Syslog log to
the log server for storage and analysis.
On contrary, the log information about NAT/ASPF is generated in large capacity.
Therefore, such logs are outputted in Binary mode. The information must be directly
sent to the log host for storage and analysis without the intervention of the information
center on the SecPath firewall. Binary logs take precedence over Syslog logs in terms
of transformation efficiency.
14.2 Syslog Log Configuration

Syslog configuration includes:
z Configuring the sweep time for the Syslog log buffer
z Configuring the log redirection of the information center
14.2.1 Configuring the Sweep Time for the Syslog Log Buffer
Table 14-1 Configure the sweep time for the Syslog log buffer
Operation Command
Configure the sweep frequency for the log buffer
firewall defend log-time time
of the attack prevention
Configure the sweep frequency for the log buffer firewall statistics log-time
of the traffic monitoring time
firewall http log-time time
of HTTP filtering
firewall ftp log-time time
of FTP filtering
firewall snmp log-time time
of SNMP filtering
firewall smtp log-time time
of SMTP filtering
Restore the sweep frequency for the log buffer of
undo firewall defend log-time
the attack prevention to the default value
Restore the sweep frequency for the log buffer of undo firewall statistics
the traffic monitoring to the default value log-time
undo firewall http log-time
the HTTP filtering to the default value
undo firewall ftp log-time
the FTP filtering to the default value
14-2
Operation Command
undo firewall snmp log-time
the SNMP filtering to the default value
undo firewall smtp log-time
the SMTP filtering to the default value
By default, the sweep time for the log buffering 30 seconds.
14.2.2 Configuring the Log Redirection for the Information Center
Generally, the log information exported to the information center is redirected in the
following ways:
z Export information to the local console through the Console port.
z Export information to the remote Telnet terminal, which can be used for remote
maintenances.
z Allocate log buffer with proper size inside the SecPath firewall, which can be used
to record information.
z Configure log server to which the information center sends information directly,
and the information will be saved in the format of file for you to view it anytime.
z Allocate trap buffer with proper size inside the SecPath firewall, which can be used
to record information.
z Export information to SNMP agent.
Table 14-2 Configure the log redirection for the information center
Operation Command
info-center console channel
Export information to the console
Export information to the Telnet terminal info-center monitor channel
or dumb terminal { channel-number | channel-name }
info-center snmp channel

Export information to SNMP
info-center logbuffer [ channel
Set the log buffer size and the
{ channel-number | channel-name } |
information channel to the log buffer
size buffersize ] *
14-3
Operation Command
info-center loghost X.X.X.X [ channel
Set the information channel to the log { channel-number | channel-name } |
host and other parameters facility local-number | language
{ chinese | english } ] *
info-center trapbuffer [ channel
Set the trap buffer size and the
{ channel-number | channel-name } |
information channel to the trap buffer
size buffersize ] *
See the Fundamental Configuration part of this manual for details.
14.3 Configuring Inter-Zone Flow Log

The flow log function is specific to the session table of inter-zone streams on the firewall.
The system supports binary flow log format (private log format). When a firewall
session entry gets aged out, the system sends the information of the stream
corresponding to the aged session in the specified format to a firewall flow data
analyzer (FDA). The FDA can be either a log host comes with the firewall, or an XLog
log host that supports flow log in binary format.
14.3.1 Configuring Inter-Zone Flow Log
Table 14-3 Configure inter-zone flow log
firewall interzone zone1

Enter inter-zone view Required
zone2
Required
session log enable
Enable inter-zone flow log By default, the inter-zone
[ acl-number
function flow log function is
acl-number ]
disabled.
Return to system view quit —
firewall session Required

Specify a flow log format log-type { syslog | Only binary format is
binary } supported currently.
Required
Configure a binary flow firewall binary-log host
log host ip-address [ port-number ] The port number defaults
to 9002.
14-4
14.3.2 Configuring Flow Log Thresholds
Table 14-4 Configure flow log thresholds

Optional
Configure the length of firewall session
time to trigger flow log log-threshold time value The default is 600
minutes.
firewall session Optional

Configure the number of
log-threshold The default is 4095 mega
packets to trigger flow log
mega-packet value packets.
Configure the number of firewall session Optional

megabytes to trigger flow log-threshold The default is 4095
log mega-byte value megabytes.
Note:
z The system starts logging a data stream when it hits any of the above-mentioned
thresholds.
z The start time of a long-term data stream logging can be calculated by the stop time
of a normal data stream plus the aging duration of a firewall session table.
14.4 Configuring NAT Flow Log

Table 14-5 Configure NAT flow log
Required
firewall nat log-type
Specify a flow log format By default, syslog format
{ syslog | binary }
is adopted.
Required
If binary format is
adopted, the system
Configure IP address for a
firewall binary-log host sends the NAT flow log to
log host that supports
ip-address [ port-number ] the IP address configured
binary flow log
using this command.
The port number defaults
to 9002.
14-5
14.5 Clearing Log

Execute the reset command in user view to clear the log buffer.
Table 14-6 Displaying and debugging log
Operation Command
reset firewall log-buf { defend | session |
Clear the log buffer on the firewall
statistic | http | ftp | snmp | smtp }
14.6 Typical Examples of Log Configuration

14.6.1 Outputting Attack Prevention Log to Host
Configure Ethernet port Ethernet 0/0/0 on the firewall as trust zone, Ethernet port
Ethernet 1/0/0 as untrust zone, and Ethernet port Ethernet 2/0/0 as DMZ zone.
II. Network diagram
Figure 14-2 Configuring firewall log


14-6

# Add the interface Ethernet 0/0/0 to the zone named trust.

# Add the interface Ethernet 1/0/0 to the zone named untrust.

# Add the interface Ethernet 2/0/0 to the zone named untrust.

[H3C-zone-dmz] add interface Ethernet 2/0/0
# Enable the information center and configure the system to output logs to the log host
at 192.168.1.10.
[H3C] info-center loghost 192.168.1.10 language english
# Enable the port-scan attack switch to add source address of the attacker to blacklist,
set aging time to 10 minutes and enable the blacklist function.
[H3C] firewall defend port-scan max-rate 100 blacklist-timeout 10
# Enable IP outbound packet statistics in Untrust zone.

[H3C-zone-untrust] statistics enable ip outzone
You can use a tool (such as nmap) on the PC in untrust zone to perform port scanning
over the server in trust zone. Then, the firewall adds the address of the PC to blacklist
(aging time is set to 10 minutes) and immediately outputs blacklist log information. After
the scanning time for attack prevention reaches, the system outputs log information
about UDP port-scan attack.
14.6.2 Inter-Zone Flow Log Configuration Example
A server locates in the Untrust zone and a PC locates in the Trust zone. Enable
inter-zone flow log function on the firewall so that the log information about streams
between the Trust and the Untrust zone will be sent to XLog host in the DMZ zone.
14-7
II. Network diagram
XLog
192.168.2.199/24
GigabitEthernet1/1
192.168.2.1/24
GigabitEthernet0/1
192.168.1.1/24
GigabitEthernet0/0
172.16.1.1/24
SecPath PC
Server 172.16.1.2/24
192.168.1.2/24
Figure 14-3 Network diagram for inter-zone flow log configuration
# Configure IP addresses for the interfaces on the firewall.

<H3C> system-view
[H3C-GigabitEthernet0/0] quit
# Add the interfaces to different zones.

[H3C-zone-trust] add interface GigabitEthernet 0/0
[H3C-zone-untrust] add interface GigabitEthernet 0/1
[H3C-zone-dmz] add interface GigabitEthernet 1/1
[H3C-zone-dmz] quit
# Enter inter-zone view and enable the inter-zone flow log function.
[H3C] firewall interzone trust untrust
[H3C-interzone-trust-untrust] session log enable
14-8
[H3C-interzone-trust-untrust] quit
# Specify binary log format.

[H3C] firewall session log-type binary
# Specify the IP address of the log host that will receive the binary flow log information.
[H3C] firewall binary-log host 192.168.2.199 9002
14.6.3 NAT Flow Log Configuration Example
A server locates in the Untrust zone and a PC locates in the Trust zone. Enable NAT on
the firewall and enable the NAT flow log function so that the NAT log information will be
sent to XLog in the DMZ zone.
II. Network diagram
XLog
192.168.2.199/24
GigabitEthernet1/1
GigabitEthernet0/1 192.168.2.1/24
192.168.1.1/24
GigabitEthernet0/0
172.16.1.1/24
SecPath PC
Server 172.16.1.2/24
192.168.1.2/24
Figure 14-4 Network diagram for NAT flow log configuration
# Add the interfaces on the firewall to different zones.

<H3C> system-view
[H3C-zone-trust] add interface GigabitEthernet 0/0
[H3C-zone-untrust] add interface GigabitEthernet 0/1
[H3C-zone-dmz] add interface GigabitEthernet 1/1
[H3C-zone-dmz] quit
14-9
# Enable logging in an ACL rule.

<H3C> system-view
192.168.1.0 0.0.0.255 logging
# Configure an NAT address pool.

# Configure IP addresses for the interfaces and enable NAT on GigabitEthernet0/1.

[H3C-GigabitEthernet0/1] nat outbound 3001 address-group 0
# Specify binary NAT flow log format.

[H3C] firewall nat log-type binary
# Specify the IP address of the log host that will receive the binary flow log information.
[H3C] firewall binary-log host 192.168.2.199 9002
14-10
Reliability
Operation Manual – Reliability
Table of Contents
Chapter 1 VRRP Configuration .................................................................................................... 1-1

1.1 Introduction to VRRP ......................................................................................................... 1-1
1.2 VRRP Configurations......................................................................................................... 1-2
1.2.1 Adding or Deleting a Virtual IP Address.................................................................. 1-3
1.2.2 Configuring Priority in a Standby Group ................................................................. 1-3
1.2.3 Configuring Preemption Mode and Preemption Delay............................................ 1-4
1.2.4 Configuring Authentication Mode and Authentication Key...................................... 1-5
1.2.5 Configuring the Adver_Timer of VRRP ................................................................... 1-6
1.2.6 Configuring Interface Tracking ................................................................................ 1-6
1.2.7 Enabling/Disabling Virtual IP Address Pinging ....................................................... 1-7
1.2.8 Configuring TTL Check for VRRP Packets ............................................................. 1-7
1.3 Displaying and Debugging VRRP...................................................................................... 1-8
1.4 Typical Examples of VRRP Configuration ......................................................................... 1-8
1.4.1 VRRP Single Standby Group Example................................................................... 1-8
1.4.2 VRRP Monitoring Interface Example ...................................................................... 1-9
1.4.3 Multi-standby Group Example............................................................................... 1-10
1.5 VRRP Troubleshooting .................................................................................................... 1-11
Chapter 2 Dual-System Hot Backup Configuration ................................................................... 2-1

2.1 Introduction to Dual-System Hot Backup........................................................................... 2-1
2.2 Basic Theory of the Dual-System Hot Backup Function.................................................... 2-1
2.2.1 RDMP...................................................................................................................... 2-1
2.2.2 RDO ........................................................................................................................ 2-2
2.2.3 Status Negotiation Interface.................................................................................... 2-3
2.2.4 RCP......................................................................................................................... 2-3
2.2.5 SCP ......................................................................................................................... 2-4
2.3 Dual-System Hot Backup Features ................................................................................... 2-4
2.3.1 Backing up Configuration Commands and Dynamic Table Entry........................... 2-4
2.3.2 Supporting Multiple Deployment Modes ................................................................. 2-5
2.4 Dual-System Hot Backup Configuration Task List............................................................. 2-5
2.5 Creating the RDO .............................................................................................................. 2-6
2.5.1 Prerequisites ........................................................................................................... 2-6
2.5.2 Configuring an RDO................................................................................................ 2-6
2.6 Configuring the Local HA Interface.................................................................................... 2-6
2.6.1 Prerequisites ........................................................................................................... 2-6
2.6.2 Configuring the Local HA Interface ......................................................................... 2-7
2.7 Configuring the Virtual Interface ........................................................................................ 2-7
2.7.1 Prerequisites ........................................................................................................... 2-8
i
2.7.2 Configuring the VIF ................................................................................................. 2-8

2.8 Adjusting and Optimizing the Dual-System Hot Backup Configuration ............................. 2-9
2.8.1 Prerequisites ........................................................................................................... 2-9
2.8.2 Configuring the RDO Static Preference .................................................................. 2-9
2.8.3 Configuring the Advertisement Interval................................................................. 2-10
2.9 Displaying and Maintaining the Dual-System Hot Backup Configuration........................ 2-11
2.10 Configuration Example .................................................................................................. 2-12
2.10.1 Network Application in Bridge Mode ................................................................... 2-12
2.10.2 Network Application in Routed Mode .................................................................. 2-14
ii
H3C SecPath Series Security Products Chapter 1 VRRP Configuration
Chapter 1 VRRP Configuration
1.1 Introduction to VRRP

During communication, any software or hardware error, network device or line fault for
example, may disrupt the connection, causing transmission failure. To avoid these
situations, Comware provides virtual router redundancy protocol (VRRP) technology to
ensure availability of a backup scheme when faults occur. This guarantees smooth
communication, and makes the network more robust and reliable.
VRRP improves reliability of connections to the outside networks and as such, is well
suited to multicast or broadcast LANs such as Ethernet. Multiple routers can form a
standby group or a virtual router, acting as the only egress gateway for the local
network. These routers, however, are transparent to the local network. In the standby
group, a router is engaged in packet forwarding, a backup router is ready for replacing
the active router, and the other routers are listening. In case the active router fails, the
backup router would take over and the other routers would elect from them a new
backup router. This improves reliability, allowing the local hosts to continue their
operation without any modification.
Normally, you can configure a default route for the hosts on a network, for example,
10.100.10.1 in the following figure. All packets destined to the external network are sent
over this default route to Router to gain access to the external networks. When the
Router fails, all the hosts using this Router as the default next-hop are isolated from the
external network.
Network
Router
10.100.10.1
10.100.10.1
Ethernet
LAN
Host 1 Host 2 Host 3
Figure 1-1 Network diagram for a LAN
1-1
VRRP was designed to address this problem on multicast and broadcast LANs such as
Ethernet.
The following figure illustrates how VRRP is implemented.
VRRP combines a group of routers on a LAN (including a master and multiple backups)
into a virtual router called standby group.
Network
RouterA Virtual IP Address RouterB

10.100.10.1
Master Backup
10.100.10.2 10.100.10.3
Ethernet
10.100.10.1 10.100.10.1 10.100.10.1 LAN 1
Host 1 Host 2 Host 3
Figure 1-2 VRRP network diagram
This virtual router has its own IP address: 10.100.10.1 (it can be the interface address
on a router in the standby group). The routers in the standby group also have their own
IP addresses: 10.100.10.2 for the master and 10.100.10.3 for a backup router for
example.
The hosts on the LAN, however only know the IP address of this virtual router or
10.100.10.1 and as such, use this IP address as the address of the default next-hop
router when communicating with the external network.
When the master in the standby group fails, the backup routers in the standby group
elects a new master to take over, allowing the hosts on the network to communicate
with the external network without interruption.
For more information about VRRP, refer to RFC 2338.
1.2 VRRP Configurations

The basic VRRP configuration tasks are described in the following sections:
z Adding or Deleting a Virtual IP Address
z Configuring Priority in a Standby Group
z Configuring Preemption Mode and Preemption Delay
1-2
The advanced VRRP configuration tasks are described in the following sections:
z Configuring Authentication Mode and Authentication Key
z Configuring the Adver_Timer of VRRP
z Configuring Interface Tracking
z Enabling/Disabling Virtual IP Address Pinging
z Configuring TTL Check for VRRP Packets
1.2.1 Adding or Deleting a Virtual IP Address
You may assign an IP address on this network segment to a virtual router or standby
group or delete the specified or all virtual IP address from the virtual address list.
Table 1-1 Add/delete a virtual IP address
Operation Command
vrrp vrid virtual-router-ID virtual-ip
Add a virtual IP address.
virtual-address
Delete the specified or all virtual IP undo vrrp vrid virtual-router-ID
addresses. virtual-ip virtual-address
The standby group number virtual-router-ID is in the range 1 to 255. The virtual IP
address can be an unassigned address on the network segment to which the standby
group belongs, or the IP address of an interface in the standby group. In the latter case,
the firewall owns the IP address is called IP address owner.
The system creates a standby group the first time that you assign an IP address to it.
When you assign virtual IP addresses to the group after that, the system only adds the
addresses to the virtual IP address list of this standby group. You can assign an
interface to 14 standby groups, while one standby group can accommodate up to 16
virtual IP addresses.
Note that before you can configure a standby group, you must create it by assigning an
IP address to it. Deleting the last virtual IP address from the standby group also deletes
the standby group. After that, all its configurations become invalid.
1.2.2 Configuring Priority in a Standby Group
In VRRP, the role that a firewall plays in a standby group depends on its priority. The
firewall with the highest priority becomes the master.
The priority is in the range 0 to 255, with a larger number indicating a higher priority.
However, the configurable range is 1 to 254. The priority 0 is reserved for special use
and 255 for the IP address owner.
1-3
Table 1-2 Configure the priority of the interface in the standby group
Operation Command
Configure the priority of the interface in vrrp vrid virtual-router-ID priority
the standby group. priority-value
Restore the default value. undo vrrp vrid virtual-router-ID priority
The priority defaults to 100.
Note:
All VRRP group members have two priorities: configurable and operating. The
configurable priority is the one assigned using the vrrp vrid command. The operating
priority of the non-IP owner is the same as the configurable priority, and the operating
priority of IP owners is always 255 and not configurable.
1.2.3 Configuring Preemption Mode and Preemption Delay
In non-preemption mode, once a firewall in the standby group becomes the master and
operates well, other firewalls, even assigned higher priority later, cannot preempt it. A
firewall working in preemption mode however, can preempt a lower priority master.
Accordingly, the existing master becomes a backup.
When enabling preemption in a standby group, you can configure a delay to have the
backup firewalls wait for a while before preempting the existing master. This is to
prevent frequent state transition on an unstable network where the backup group
firewalls cannot receive packets from the master regularly due to network congestion
instead of master failure.
The delay is in the range 0 to 255 seconds.
Table 1-3 Configure the preemption mode and preemption delay for a standby group
Operation Command
vrrp vrid virtual-router-ID
Enable preemption and configure
preempt-mode [ timer delay
preemption delay for a standby group.
delay-value ]
Disable preemption in the standby undo vrrp vrid virtual-router-ID
group. preempt-mode
1-4
The default mode is preemption without delay.
Note:
After you disable preemption, the preemption delay automatically becomes to 0
seconds.
1.2.4 Configuring Authentication Mode and Authentication Key
VRRP provides two authentication modes: simple (simple text authentication) and
MD5.
On a secure network, you can use the default where no authentication key is required.
It allows the firewall to ignore authentication considerations when handling the VRRP
packets to be sent.
On a network where potential threats are present, you can set the authentication mode
to simple, where the authentication key must not be greater than eight characters.
When the firewall sends a VRRP packet, it fills the authentication key into the VRRP
packet. When the firewall receives a VRRP packet, it compares the authentication key
in the packet with the one that it retains. If they are the same, the packet is considered
genuine and legitimate. If otherwise, the packet is considered illegitimate and is
discarded.
On an unsafe network, you can set the authentication mode to MD5, where the
authentication key must not be greater than eight bytes. This allows the firewall to
authenticate VRRP packets using the authentication method provided by
authentication header (AH) and the MD5 algorithm. The length of the authentication
key can be either less than eight characters or 24 characters. If you input in plain text,
the length ranges from one to eight characters, such as 1234567; if you input in
encrypted text, the length must be 24 characters, such as (TT8F]Y\5SQ=^Q`MAF4<1!!.
The firewall discards the packets that fail authentication and sends traps to the NMS.
Table 1-4 Configure the authentication mode and authentication key
Operation Command
Configure the authentication mode and vrrp authentication-mode { md5 key |
authentication key. simple key }
Restore the default. undo vrrp authentication-mode
1-5
By default, the firewall does not authenticate VRRP packets.
Note:
For the standby groups on the same interface, you must set the same authentication
mode and authentication key.
1.2.5 Configuring the Adver_Timer of VRRP
In a VRRP standby group, the master tells other firewalls that it is alive by sending
VRRP packets regularly. If no VRRP packets are received after a specified period, the
backup assumes the master has failed and changes its state to master. The VRRP
packet sending interval and the state transition of the backup are controlled by two
timers: Adver_Timer and Master_Down_Timer.
The Master_Down_Timer is about three times that of the Adver_Timer. Either
enormous traffic or difference of the timer settings on the firewalls can result in
abnormal timeout of the Master_Down_Timer, causing state transition. One solution to
this problem is to set Adver_Timer (in seconds) to a greater value and/or configure
preemption delay.
Table 1-5 Configure the Adver_Timer of VRRP
Operation Command
vrrp vrid virtual-router-ID timer advertise
Configure the Adver_Timer of VRRP.
adver-interval
undo vrrp vrid virtual-router-ID timer
Restore the default.
advertise
The adver_interval argument is in the range 1 to 255 seconds and defaults to 1 second.
1.2.6 Configuring Interface Tracking
The interface tracking function expands the backup functionality of VRRP. It provides
backup not only when the interface to which a standby group is assigned fails but also
when other interfaces on the firewall become unavailable. This is achieved by tracking
interfaces. When a monitored interface goes down, the operating priority of the firewall
owning this interface automatically decreased by the value specified by value-reduced,
allowing a higher priority router in the standby group to take over as the master.
1-6
Table 1-6 Configure interface tracking
Operation Command
vrrp vrid virtual-router-ID track
Configure the interface to be tracked. interface-type interface-number
[ reduced priority-reduced ]
undo vrrp vrid virtual-router-ID track

Disable to track the specified interface.
The priority-reduced argument defaults to 10.
Note:
You cannot configure interface tracking on the firewall that is IP address owner.
1.2.7 Enabling/Disabling Virtual IP Address Pinging
According to VRRP, users cannot ping the virtual IP addresses of standby groups and
as such, cannot determine whether an IP address is assigned to a standby group. If a
host on the network uses the same IP address of a standby group coincidently, all
packets in this network will be forwarded to the host improperly.
You can however use this command to enable or disable users to ping virtual IP
addresses of standby groups.
Table 1-7 Enable/disable virtual IP address pinging
Operation Command
Enable virtual IP address pinging. vrrp ping-enable
Disable virtual IP address pinging. undo vrrp ping-enable
By default, virtual IP address pinging is disabled.

Note that you must configure this command before creating standby groups. Once a
standby group is created, you cannot use this command and its undo form.
1.2.8 Configuring TTL Check for VRRP Packets
You can enable or disable the backup firewall to check TTL value for VRRP packets.
According to VRRP, the TTL value of VRRP packets must be 255. If detecting that the
TTL value of a packet is not 255, the backup firewall drops the packet.
1-7
Perform the following configuration in VLAN interface view.
Table 1-8 Disable TTL check for VRRP packets
Operation Command
Disable TTL check for VRRP packets vrrp un-check ttl
Enable TTL check for VRRP packets undo vrrp un-check ttl
By default, the system checks the TTL value for VRRP packets.
1.3 Displaying and Debugging VRRP

After completing the above configurations, you may execute the display command in
any view to view the operating state about VRRP, and to verify the effect of the
configurations.
Execute the debugging vrrp command in user view.
Table 1-9 Display and debug VRRP
Operation Command
display vrrp [ interface type number
Display state information about VRRP.
[ virtual-router-ID ] ]
Enable VRRP packet debugging. debugging vrrp packet
Disable VRRP packet debugging. undo debugging vrrp packet
Enable VRRP state debugging. debugging vrrp state
Disable VRRP state debugging. undo debugging vrrp state
By default, the debugging function is disabled.
1.4 Typical Examples of VRRP Configuration

1.4.1 VRRP Single Standby Group Example
Host A takes the VRRP standby gateway, which is made up of SecPath A and SecPath
B, as its default gateway to access the Host B on the Internet.
About the VRRP standby group: Standby group number is 1 and virtual IP address is
202.38.160.111. SecPath A functions as the Master, while SecPath B as the Backup.
Preemption is enabled.
1-8
II. Network diagram
203.2.3.1 Host B
Internet
E2/0/0 E2/0/0
SecPathA SecPathB
E1/0/0 : 202.38.160.1 Virtual IP address E1/0/0 : 202.38.160.2

202.38.160.111
202.38.160.3
Host A
Figure 1-3 VRRP application illustration
Configure SecPath B:
The standby group can be used immediately after configuration. Host A can take the
default gateway as 202.38.160.111.
In normal cases, SecPath A is responsible for gateway work, unless it is switched off or
malfunctioning, when SecPath B shall take the charge. The preemption mode is
configured for SecPath A to resume its gateway function as the Master when it
recovers.
1.4.2 VRRP Monitoring Interface Example
When its interface connecting to the Internet is unavailable, even if SecPath A can still
function, SecPath B is possibly preferred to takeover the task. This can be implemented
by configuring the monitoring interface.
For simplicity of explanation, the standby group number is set as 1 with configuration of
authorization key and timer added (which are unnecessary in this application).
1-9
II. Network diagram
See Figure 1-3.
# Create a standby group.
# Set the priority of the standby group.

# Set the authentication key of the standby group.

[H3C-Ethernet1/0/0] vrrp authentication-mode md5 vrrppwd
# Configure Master to send VRRP packets at intervals of 5 seconds.

[H3C-Ethernet1/0/0] vrrp vrid 1 timer advertise 5
# Set the interface to be monitored.

[H3C-Ethernet1/0/0] vrrp vrid 1 track Ethernet2/0/0 reduced 30
# Create a standby group.
# Set the authentication key of the standby group.

[H3C-Ethernet1/0/0] vrrp authentication-mode md5 vrrppwd
# Configure Master to send VRRP packets at intervals of 5 seconds.

[H3C-Ethernet1/0/0] vrrp vrid 1 timer advertise 5
In normal cases, SecPath A is responsible for gateway work. When its interface
Ethernet 2/0/0 goes unavailable, its priority will decrease by 30 and therefore become
lower than that of SecPath B; hence, SecPath B will preempt the role of Master.
Whenever its Ethernet 2/0/0 recovers, SecPath A can restore its role as Master.
1.4.3 Multi-standby Group Example
One firewall in the Comware is allowed to function as the standby for many standby
groups.
Such a multi-standby configuration can implement load sharing. SecPath A serves as
the Master of standby group 1 and simultaneously a backup of standby group 2, while
SecPath B is quite the contrary, serving as the Master of standby group 2 but a backup
of standby group 1. Some hosts shall take standby group 1 as their gateways, others
1-10
take standby group 2. In this way, both purposes of data stream balancing and mutual
standby are achieved.
II. Network diagram
See Figure 1-3.
# Create standby group 1.




1.5 VRRP Troubleshooting

The configuration of VRRP is simple. You can locate most of the problems by checking
the output of the display command and the debugging command. The following
presents some troubleshooting cases.
Symptom 1:
The console screen displays error prompts frequently.
Solution:
Check that the received VRRP packets are correct.
The router may receive an incorrect VRRP packet for two reasons: its configuration is
inconsistent with that on another firewall in the standby group; a device is attempting to
send illegitimate VRRP packets. In the first case, modify the configuration. In the
second case, you must resort to non-technical measures.
Symptom 2:
Multiple masters are present in the same standby group.
1-11
Solution:
If presence of multiple masters lasts a short period, this is normal and requires no
manual intervention. If it lasts long, you must check that these masters can receive
VRRP packets and the received packets are legitimate.
Do the following:
Have these masters ping each other.
If they can be pinged, check that their configurations are consistent, making sure that
the same number of virtual IP addresses, the configured virtual IP addresses, timer
setting and authentication mode are configured for the same VRRP standby group.
If they cannot be pinged, check for other reasons.
Symptom 3:
Frequent VRRP state transition is present.
Solution:
Set the Adver_Timer of the standby group to a larger value or configure a preemption
delay.
1-12
H3C SecPath Series Security Products Chapter 2 Dual-System Hot Backup Configuration
Chapter 2 Dual-System Hot Backup Configuration
2.1 Introduction to Dual-System Hot Backup

Dual-system hot backup, which is the status backup of two firewalls, indicates that two
firewalls are deployed to negotiate the master/backup status through redundancy
device management protocol (RDMP). After the negotiation, the master firewall
performs forwarding operation, and the backup firewall is in monitoring status;
meanwhile, the master firewall sends status information and information to be backed
up to the backup firewall periodically. When the master firewall fails, the backup firewall
takes over the operation of the master firewall immediately.
The status of the two firewalls (master/backup) determines which firewall to perform the
forwarding operation. If the master firewall fails, the master/backup status will switch
automatically between the two firewalls, and then, the other firewall takes over the
operation from the failed firewall, thus the continuous traffic passing is ensured.
SecPath1000F
PC Master
PC Session entries
PC
Trust zone
Untrust zone
Server Physical link
Backup
SecPath1000F
Traffic
DMZ zone
Figure 2-1 Networking scheme for dual-system hot backup
The main advantage of the status backup is to protect the current service, such as the
IP phone, from being interrupted. If the firewall is not configured with the status backup
function, the current service will be intermitted after status switching, and you need to
reestablish the connection. Therefore, the dual-system hot backup networking scheme
can better solve the problems occur in traditional networking schemes (such as VRRP).
2.2 Basic Theory of the Dual-System Hot Backup Function

2.2.1 RDMP
Redundancy device management protocol (RDMP) is used to enable the dual-system

hot backup function on two firewalls. By running RDMP, the backup device takes over
the operation from the master device that fails. RDMP also supports the
2-1
synchronization of the connection status, address translation information and

configuration information between the master and backup devices. Status information
backup can prevent the early established services from being intermitted after traffic is
switched to the backup device.
The RDMP consists of two protocols:
z Redundancy link control protocol (RCP), used to negotiate the master/backup
status between two physical devices and manage basic link status.
z Synchronization control protocol (SCP), used to back up and restore the status
information between two devices.
2.2.2 RDO
RDMP introduces the concept of redundancy device object (RDO) and virtual interface
(VIF).
An RDO is an abstract virtual device, distinguished from actual physical devices. Two
RDOs with the same ID represent themselves as an entity with complete functions.
Only the firewall with the RDO status as Master passes traffic and performs filtering,
address translation and forwarding function.
VIF is an entity (with real IP address) among virtual devices that processes service data.
The interface bound with the VIF affects the RDO status of the device directly. Each
RDO has multiple VIFs similar to actual devices to process services, and you need to
specify the actual interface for each virtual interface.
The logical relationship between the physical device and redundancy device is shown
in Figure 2-2.
VIF 1
RDO 1
Ethernet 0/ 0 SecPath
SecPathAA Ethernet 0/ 1
Ethernet 0/ 0 SecPath
SecPathBB Ethernet 0/ 1
VIF 2
Figure 2-2 Logical relationship between a physical device and a redundancy device
In Figure 2-2, SecPath A and SecPath B run the RDMP respectively, and through RDO
1, they bind the VIF 1 with Ethernet 0/0, VIF 2 with Ethernet 0/1 on the two devices
respectively; thus forms a two-interface virtual device (RDO 1).
2-2
2.2.3 Status Negotiation Interface
The RDMP uses the standard Ethernet interface as the interface for status negotiation
(HA interface), which is used to transmit negotiation packets and data between two
master/backup firewalls.
2.2.4 RCP
In the RDMP, RCP is mainly for the master/backup status negotiation and link status
management of two physical devices.
The two devices negotiate the master/backup status of RDO by comparing their RDO
realtime preferences; the one with higher preference serves as the master device. If the
two devices share the same preference, they compare the MAC addresses of their HA
interfaces. The one with higher MAC address serves as the master device.
The realtime preference is determined by the RDO static preference, each VIF value of
the RDO and the status of the interface corresponding to each VIF of the RDO. The
following is the formula to calculate RDO realtime preference:
RDO realtime preference = RDO static preference – value of all shut down VIFs
On firewall A, if the static preference configured on RDO 1 is 100, you can view the VIF
status in Table 2-1.
Table 2-1 Firewall A status table
VIF Interface Value Interface status

VIF 1 Ethernet 0/0/0 20 UP
VIF 3 Ethernet 1/0/0 10 DOWN
By calculating with the above formula, the realtime preference value of RDO 1 on
Firewall A is 90.
On Firewall B, if the static preference configured on RDO 1 is 100, you can view the VIF
status in Table 2-2.
Table 2-2 Firewall B status table
VIF Interface Preference value Interface status

2-3
By calculating with the above formula, the realtime preference value of RDO 1 on
Firewall B is 100.
The two devices negotiate the master/backup status by sending negotiation packets to
each other periodically. After receiving the negotiation packet containing realtime
preference information, the peer device determines its status by comparing the
preference value of the two devices. In the above example, the RDO 1 status on
Firewall B is Master, while the RDO 1 status on Firewall A is Backup.
2.2.5 SCP
In the RDMP, SCP is used to back up and restore the status information for the two
devices, and handles data transmission error during synchronization process.
Data synchronization consists of the following two processes:
z Batch synchronization, usually happens when you place a backup device into the
network, the master device synchronizes the saved status information and related
configuration to the backup device.
z Realtime synchronization usually happens after batch synchronization when the
SCP is in stable synchronization state. In this stage, the SCP backs up the newly
created, updated and deleted status information on the master device to the
backup device.
2.3 Dual-System Hot Backup Features

2.3.1 Backing up Configuration Commands and Dynamic Table Entry
SecPath series firewalls are status firewalls. After a packet is detected, the firewall will
create a dynamic session entry. Then, only the packets (including the packet that
returns) that match this entry can pass the firewall. So, the inbound and outbound paths
of the session should be consistent with each other. The consistency of the firewall
status ensures continuous traffic passing after status switching between the two
firewalls.
Following are the dual-system hot backup modes:
z Automatic realtime backup mode: The master device backs up dynamic backup
information to the backup device automatically.
z Automatic batch backup mode: The master device backs up all the commands
and dynamic backup information to the backup device which is just connected to
the network or rebooted. The backup device will perform all the configuration
commands needed to be backed up to synchronize with the master device.
z Manual batch synchronization: Enter the command for synchronization on the
master device to send all configuration commands and dynamic backup
information to the backup device.
2-4
Note:
z The dual-system hot backup function does not support the NAT Easy IP feature, nor
support to set the IP address of the firewall interface as the NAT global IP address.
z During batch backup, do not perform any operation when the backup does not reach
the stable state.
z When you use the manual batch synchronization mode, consecutively executing of
the command for synchronization on the master device will result in abnormal
entries on the backup device.
z The master-backup switchover interval is the interrupted time of the original
connection during the switchover. This interval is only related to ad-interval and poll
interval (5 seconds).
z For master-backup switchover, the time for the switchover to reach the stable state
is equal to the advertisement timeout time plus the synchronization time of the
configuration information and status information after switchover. The stable time is
related to the size of the configuration file to be restored, number of entries, and the
current usage of the CPU; the more the resources to be restored, the longer the time
needed.
z The dual-system hot backup function does not support TCP-Proxy and Traffic Log.
TCP-Proxy and Traffic Log do not take effect if the dual-system hot backup function
is enabled.
z For the backlist entries manually configured through command lines, you cannot
synchronize them to the backup device through automatic realtime backup, but
through automatic batch backup or manual batch backup.
z To ensure normal services on the master and backup devices, the status
information must be consistent on the master and backup devices. Therefore, if
there is service traffic, do not execute the reset nat session command on the
backup device.
z When there are data services, the status information of the backup device will be
cleared if you execute the scp batch-sync config command. In this case, if
synchronization is needed, execute the scp batch-sync all command.
2.3.2 Supporting Multiple Deployment Modes
SecPath series firewall supports two networking modes: routed mode and bridge mode.
The RDMP supports the firewall backup function in these two modes, and is capable to
ensure the reliability of the system and maintain the flexibility of the firewall networking.
2.4 Dual-System Hot Backup Configuration Task List

Complete these tasks to configure the dual-system hot backup function:
2-5
Table 2-3 Dual-System Hot Backup Configuration Task List
Task Remarks
Creating the RDO Required
Configuring the Local HA Interface Required
Configuring the Virtual Interface Required
Adjusting and Optimizing Configuring the RDO Static Preference Optional
the Dual-System Hot
Backup Configuration Configuring the Advertisement Interval Optional
2.5 Creating the RDO

Before configuring the dual-system hot backup function, you need to create the RDO
on each device, and then you can configure and enable other functions.
2.5.1 Prerequisites
No prerequisites are required for this configuration task.
2.5.2 Configuring an RDO
Table 2-4 Create an RDO

Create an RDO and enter
rdo rdo-id Required
the RDO view
Caution:
The master and backup devices must share the same RDO ID.
2.6 Configuring the Local HA Interface

2.6.1 Prerequisites
Create the RDO on the local device before configuring the local HA interface.
2-6
2.6.2 Configuring the Local HA Interface
Both the local and peer firewalls use the HA interface to negotiate their master/backup
status, and synchronize their configuration commands and status information.
Table 2-5 Configure the local HA interface

Enter RDO view rdo rdo-id Required
Required
ha-interface
interface The peer-mac argument can be used
Configure the local to specify the MAC address for the
interface-name
HA interface peer HA interface. If the MAC address
[ peer-mac
mac-address ] is not specified, the broadcast MAC
address FFFF-FFFF-FFFF is used.
Caution:
z In the dual-system hot backup function, negotiation packets and synchronization

packets are transmitted through HA interfaces. Since these packets are different
from common packets, the firewall module of the firewall (such as the blacklist and
packet filter function) does not take effect on them.
z The HA interface must be a physical interface.
z If the physical state of the HA interface is DOWN, the RDO state stops in the Init
state after the device reboots. Therefore, keep the physical state of the HA interface
to be UP in the dual-system hot backup environment.
z If the physical state of the HA interface is DOWN, the status of both the master and
backup devices is Master. In this case, the two devices both respond to the ARP
packets and forward data, resulting in abnormal services. Therefore, in the
dual-system hot backup environment, always keep the physical state of the HA
interface to be UP.
z The HA interface cannot be multiplexed with the service interfaces.
z The HA interfaces of the master and backup devices need to be connected directly
through a cable.
2.7 Configuring the Virtual Interface

This section mainly introduces the configuration of the virtual interface (VIF) and the
interface bound to the VIF. The two master and backup firewalls can provide services
and operate normally after the VIF is configured.
2-7
2.7.1 Prerequisites
Perform the following tasks before configuration:

z In routed mode, you need to configure an IP address for the bound interface on
both master and backup firewalls to make sure the two devices connected with the
two firewalls are reachable to each other.
z The RDO is already created on the local and peer devices.
2.7.2 Configuring the VIF
The configuration on the VIF includes configuring the virtual IP address, interface value
and the virtual MAC address.
When the firewall operates in routed mode, you need to configure the same VIF ID,
virtual IP address and virtual MAC address for the backing up interfaces on the master
and backup firewalls. The virtual IP address should be on the same network segment
with the actual IP address, but cannot be the same; the virtual MAC address cannot be
the same with the actual MAC address.
When the firewall operates in bridge mode, neither of the virtual IP address and virtual
MAC address can be configured.
The interface value is used to update the preference dynamically. When the interface is
down or up, the system adjusts the realtime preference of the RDO according to the
interface value.
Table 2-6 Configure the VIF

vif vif-id interface type Required

Configure the VIF in number virtual-ip ip-address The value of the
routed mode [ virtual-mac H-H-H ] value-reduced defaults to
[ reduce value-reduced ] 10.
Required
vif vif-id interface type
Configure the VIF in The value of the
number [ reduce
bridge mode value-reduced defaults to
value-reduced ]
10.
2-8
Caution:
z The VIF IP address cannot be configured repeatedly; use the undo command to
cancel the IP address before you configure a new IP address for the VIF.
z The VIF IP address cannot be the same as the IP address of the bound interface.
z After an interface is bound to the VIF, if you modify the IP address of the bound
interface, the device does not check the validity of the VIF IP address.
z Do not use the undo command to cancel the VIF IP address in the batch backup
process.
z To ensure that the realtime preference of the RDO is a positive number, the value of
the interface (value-reduced) bound to the RDO cannot be greater than or equal to
the corresponding static preference value.
z Do no configure VRRP after enabling the dual-system hot backup function;
otherwise, the dual-system hot backup configuration may function abnormally.
2.8 Adjusting and Optimizing the Dual-System Hot Backup

Configuration
This section mainly introduces how to adjust and optimize the dual-system hot backup
configuration to meet different network requirements. The configuration tasks include
configuring RDO static preference, and advertisement interval.
2.8.1 Prerequisites
Perform the following tasks before configuration:

z For routed mode, you need to configure an IP address for the bound interface on
both the master and backup firewall to make sure the two devices connected with
the two firewalls are reachable to each other.
z The RDO is already created on the local and peer devices.
2.8.2 Configuring the RDO Static Preference
The RDO static preference indicates the RDO preference when all the interfaces of a
device are up. According to the static preference, actual state and value of all the
interfaces, the RDO realtime preference can be calculated. Then, by comparing the
RDO realtime preference between two devices, the one with higher preference value
serves as the master device.
2-9
Table 2-7 Configure the RDO static preference

Required
Configure the RDO static
priority value The RDO static preference value
preference
defaults to 100.
Note:
If the local and peer end share the same preference, they compare the MAC addresses
of their HA interfaces. The one with higher MAC address serves as the master device.
2.8.3 Configuring the Advertisement Interval
The master device in an RDO sends suppress packets to the backup device
periodically, informing its normal running status and preference. The backup device
defines the timeout time for receiving the suppress packets according to the
advertisement interval. If no suppress packet is received after three times, the backup
device considers that the master devices fails, and performs status switching.
Table 2-8 Configure the advertisement interval

Required
Configure the
ad-interval time-value The advertisement interval
advertisement interval
defaults to three seconds.
2-10
Caution:
z Taking various hardware features of different types of devices and the service
volume into consideration, the backup device may not process the advertisement
packet received from the master device in time in the process of batch backup and
restoration. Thus, the master and backup devices cannot perform synchronization
stably, resulting in frequent master/backup status switching. To prevent such
problems, you can set a longer advertisement interval, where no less than three
seconds is recommended.
z You are recommended to set a longer advertisement interval when there is large
traffic, many sessions, or a large configuration file.
z Configure the same advertisement interval for the local and peer devices.
2.9 Displaying and Maintaining the Dual-System Hot Backup

Configuration
running status of the dual-system hot backup and verify the configuration results.
Table 2-9 Display and maintain the dual-system hot backup
Operation Command
Display the global information of all RDOs display rdo
Display detailed information about a specified RDO. display rdo rdo-id
Display the information about synchronous modules display rdo
of the dual-system hot backup function sync-modules
Note:
In the firewall status switching process, if the log function of the information center is
enabled, the user terminal may be flooded with blacklist or other configuration
information when restored by the master and backup devices. This will interrupt user’s
operation. To avoid such problems, use the undo info-center enable command to
disable the log information in the information center.
2-11
2.10 Configuration Example

2.10.1 Network Application in Bridge Mode
z SecPath A and SecPath B both work in bridge mode.

z The dual-system hot backup function is enabled on SecPath A and SecPath B to
ensure continuous data transmission.
z Interface Ethernet 0/0/1 of the two firewalls is configured as their respective HA
interfaces.
z SecPath A forwards packets while SecPath B monitors the status of SecPath A.
z Suppose the MAC address of Ethernet 0/0/1 is 0001-0001-0001 on SecPath A,
and the MAC address of Ethernet 0/0/1 is 0002-0002-0002 on SecPath B.
II. Network diagram
1 92.168 .0. 3 1 92.1 68. 0.4
SecPathA E1/0/0 SecPathB E1/0 /0
E0/0/1 E0/0/1
E0/0/0 E0/0/0
19 2.16 8.0.5
Figure 2-3 Network diagram for dual-system hot backup function in bridge mode
2-12
# Configure bridging function on the firewall and enable bridge-set 1.
<SecPathA> system-view
[SecPathA] bridge enable
[SecPathA] bridge 1 enable
# Add interfaces into the bridge-set.

[SecPathA] interface Ethernet 0/0/0
[SecPathA-Ethernet0/0/0] bridge-set 1
[SecPathA-Ethernet0/0/0] quit
[SecPathA-Ethernet1/0/0] bridge-set 1
# Create RDO 1.
[SecPathA] rdo 1
[SecPathA-rdo1] priority 105
[SecPathA-rdo1] ha-interface interface Ethernet 0/0/1 peer-mac 0002-0002-0002
[SecPathA-rdo1] vif 1 interface Ethernet0/0/0
[SecPathA-rdo1] vif 2 interface Ethernet1/0/0
# Configure bridging function on the firewall and enable bridge-set 1.
<SecPathB> system-view
[SecPathB] bridge enable
[SecPathB] bridge 1 enable
# Add interfaces into the bridge-set.

[SecPathB] interface Ethernet 0/0/0
[SecPathB-Ethernet0/0/0] bridge-set 1
[SecPathB-Ethernet0/0/0] quit
[SecPathB-Ethernet1/0/0] bridge-set 1
# Create RDO 1
[SecPathB]rdo 1
[SecPathB-rdo1] ha-interface interface Ethernet 0/0/1 peer-mac 0001-0001-0001
[SecPathB-rdo1] vif 1 interface Ethernet0/0/0
[SecPathB-rdo1] vif 2 interface Ethernet1/0/0
2-13
2.10.2 Network Application in Routed Mode
z SecPath A and SecPath B both work in routed mode.

z There is a route between PC 1 and PC 2.
z The dual-system hot backup function is enabled on SecPath A and SecPath B,
and a RDO is configured on each firewall respectively.
z The interface Ethernet 1/0/0 on each firewall serves as their HA interfaces.
z Normally, SecPath A forwards traffic accessed by PC 1 and PC 2, while SecPath B
monitors the status of SecPath A.
z When SecPath A or the link fails, such as SecPath A goes offline, or the connected
uplink or downlink fails, the traffic switches automatically to SecPath B, which
takes over the forwarding function.
z Suppose the MAC address of Ethernet 1/0/0 is 0001-0001-0001 on SecPath A,
and the MAC address of Ethernet 1/0/0 is 0002-0002-0002 on SecPath B.
2-14
II. Network diagram
PC2:172.16.1.2
E0/0/1 E0/0/1 SecPathB

SecPathA 172.16.1.254 172.16.1.253
E1/0/0 E1/0/0
E0/0/0 E0/0/0
192.168.0.254 192.168.0.253
PC1:192.168.0.2
Figure 2-4 Network diagram for dual-system hot backup function in routed mode
# Configure the IP address for the interface on SecPath A.
[SecPathA-Ethernet0/0/0] ip address 192.168.0.254 24
[SecPathA-Ethernet0/0/1] ip address 172.16.1.254 24
[SecPathA]
# Create RDO 1
2-15
[SecPathA] rdo 1
[SecPathA-rdo1] priority 105
[SecPathA-rdo1] ha-interface interface Ethernet 1/0/0 peer-mac 0002-0002-0002
[SecPathA-rdo1] vif 1 interface Ethernet 0/0/0 virtual-ip 192.168.0.1
[SecPathA-rdo1] vif 2 interface Ethernet 0/0/1 virtual-ip 172.16.1.1
# Configure the IP address for the interface on SecPath B.
[SecPathB-Ethernet0/0/0] ip address 192.168.0.253 24
[SecPathB-Ethernet0/0/1] ip address 172.16.1.253 24
[SecPathB]
# Create RDO 1
[SecPathB] rdo 1
[SecPathB-rdo1] ha-interface interface Ethernet 1/0/0 peer-mac 0001-0001-0001
[SecPathB-rdo1] vif 1 interface Ethernet 0/0/0 virtual-ip 192.168.0.1
[SecPathB-rdo1] vif 2 interface Ethernet 0/0/1 virtual-ip 172.16.1.1
3) Configure PC 1
IP address: 192.168.0.2
Gateway address: 192.168.0.1
4) Configure PC 2
IP address: 172.16.1.2
Gateway address: 172.16.1.1
2-16
QoS
Operation Manual – QoS
Table of Contents
Chapter 1 Brief Introduction to QoS............................................................................................ 1-1

1.1 Overview ............................................................................................................................ 1-1
1.2 Traditional Packets Transmission Application ................................................................... 1-1
1.3 New Requirements Caused by New Applications ............................................................. 1-1
1.4 Congestion: Causes, Impact, and Countermeasures........................................................ 1-2
1.4.1 Causes .................................................................................................................... 1-2
1.4.2 Impact...................................................................................................................... 1-3
1.4.3 Countermeasure...................................................................................................... 1-3
1.5 Traffic Control Technologies.............................................................................................. 1-3
Chapter 2 Traffic Classification, Policing, and Shaping............................................................ 2-1

2.1 Traffic Classification........................................................................................................... 2-1
2.2 Traffic Policing and Traffic Shaping ................................................................................... 2-1
2.2.1 Traffic Evaluation and Token Bucket ...................................................................... 2-2
2.2.2 Traffic Policing......................................................................................................... 2-3
2.2.3 Traffic Shaping ........................................................................................................ 2-3
2.2.4 Line Rate on Physical Port...................................................................................... 2-4
2.3 Traffic Policing and Traffic Shaping Configuration ............................................................ 2-5
2.3.1 Configuring Traffic Policing ..................................................................................... 2-5
2.3.2 Configuring Traffic Shaping..................................................................................... 2-7
2.3.3 Configuring LR on Port............................................................................................ 2-7
2.4 Traffic Policing and Shaping Display and Debug .............................................................. 2-8
2.4.1 Displaying TP Rule.................................................................................................. 2-8
2.4.2 Displaying TP Configuration and Statistics on Each Interface................................ 2-8
2.4.3 Displaying TS Configuration and Statistics on Interface ......................................... 2-8
2.4.4 Displaying LR Configuration and Statistics on Interface ......................................... 2-8
2.5 Typical Example of Traffic Policing and Shaping .............................................................. 2-9
Chapter 3 Congestion Management ............................................................................................ 3-1

3.1 Brief Introduction to Congestion Management .................................................................. 3-1
3.1.1 Congestion Management Policies........................................................................... 3-1
3.1.2 Comparisons among Congestion Management Technologies ............................... 3-6
3.2 Configuring FIFO Queue ................................................................................................... 3-9
3.2.1 Configuring FIFO Queue Length............................................................................. 3-9
3.3 Priority Queuing Configuration......................................................................................... 3-10
3.3.1 Configuring Priority-list .......................................................................................... 3-10
3.3.2 Applying Priority-list Queue on the Interface......................................................... 3-12
3.3.3 Displaying and Debugging Priority Queue ............................................................ 3-12
3.4 Custom Queuing Configuration ....................................................................................... 3-12
i
3.4.1 Configuring a CQL ................................................................................................ 3-13

3.4.2 Applying a CQL on the Interface ........................................................................... 3-15
3.4.3 Displaying and Debugging CQL............................................................................ 3-15
3.5 WFQ Configuration .......................................................................................................... 3-15
3.5.1 Using WFQ or Modifying WFQ Parameters.......................................................... 3-16
3.5.2 Displaying and Debugging WFQ........................................................................... 3-17
3.6 Class-based Queuing Configuration................................................................................ 3-17
3.6.1 Configuring the Maximum Available Bandwidth on the Interface ......................... 3-18
3.6.2 Configuring Matching Rules of a Class ................................................................. 3-18
3.6.3 Configuring Features of a Traffic Behavior ........................................................... 3-22
3.6.4 Configuring Policy ................................................................................................. 3-27
3.6.5 Applying Policy ...................................................................................................... 3-28
3.6.6 Displaying and Debugging CBQ ........................................................................... 3-29
3.7 RTP Priority Queuing Configuration ................................................................................ 3-29
3.7.1 Applying RTP priority queuing on the interface..................................................... 3-29
3.7.2 Configuring Maximum Reserved Bandwidth......................................................... 3-30
3.7.3 Displaying and Debugging RTP Priority Queuing Configuration .......................... 3-30
3.8 Typical Configuration Example ........................................................................................ 3-31
3.8.1 PQ Configuration Example.................................................................................... 3-31
3.8.2 CBQ Configuration Example ................................................................................. 3-32
3.8.3 CQ Configuration Example ................................................................................... 3-34
Chapter 4 DAR Configuration ...................................................................................................... 4-1

4.1 DAR Overview ................................................................................................................... 4-1
4.2 Configuring DAR ................................................................................................................ 4-1
4.2.1 Configuring Matching Rules of Protocol.................................................................. 4-1
4.2.2 Configuring HTTP Matching Rules.......................................................................... 4-1
4.2.3 Configuring RTP Matching Rules............................................................................ 4-2
4.2.4 Configuring Port Number of DAR Application Protocol........................................... 4-2
4.2.5 Renaming User-defined Protocols .......................................................................... 4-3
4.2.6 Enabling/Disabling DAR Packet Statistics .............................................................. 4-3
4.2.7 Configuring Maximum Number of Connections Recognizable by DAR.................. 4-3
4.3 Displaying and Debugging DAR ........................................................................................ 4-4
4.4 DAR Configuration Examples ............................................................................................ 4-5
4.4.1 DAR Configuration Examples ................................................................................. 4-5
Chapter 5 Congestion Avoidance................................................................................................ 5-1

5.1 Introduction to Congestion Avoidance ............................................................................... 5-1
5.2 WRED Configuration ......................................................................................................... 5-3
5.2.1 Enabling WRED ...................................................................................................... 5-3
5.2.2 Setting WRED to Calculate the Coefficient of Average Queue Length .................. 5-3
5.2.3 Setting WRED Priorities .......................................................................................... 5-4
5.2.4 Setting DSCP Parameters for WRED ..................................................................... 5-4
5.3 Displaying WRED .............................................................................................................. 5-5
ii
Chapter 6 MPLS QoS..................................................................................................................... 6-1

6.1 MPLS QoS Overview......................................................................................................... 6-1
6.2 MPLS QoS Configuration .................................................................................................. 6-1
6.2.1 Configuring MPLS PQ............................................................................................. 6-2
6.2.2 Configuring MPLS CQ............................................................................................. 6-2
6.2.3 Configuring MPLS CBQ .......................................................................................... 6-3
6.2.4 Configuring MPLS CAR .......................................................................................... 6-5
6.3 MPLS QoS Configuration Example ................................................................................... 6-6
6.3.1 QoS Configuration for Streams in the Same VPN .................................................. 6-6
iii
H3C SecPath Series Security Products Chapter 1 Brief Introduction to QoS
Chapter 1 Brief Introduction to QoS
1.1 Overview
Quality of Service (QoS) measures the service performance of service providers in
terms of client satisfaction. Instead of giving accurate marks, QoS emphasizes
analyzing what good or imperfect services are, and they come in what kind of
circumstances, so as to provide a cutting edge improvement.
In the Internet, QoS evaluates service performance for network packet transmission.
Due to various services offered by the network, the evaluation for QoS will be based on
different aspects accordingly. Generally QoS evaluates the service performance for
those network core requirements during packet transmission process, such as: delay,
jitter and packet loss ratio.
1.2 Traditional Packets Transmission Application

On traditional IP networks, the firewalls treat all packets identically and handle them
with the first in, first out (FIFO) policy, assigning forwarding resources by arrival
sequence of packets.
All the packets share the resources of the network and the firewalls. How many
resources the packets can obtain will completely depend on the time they arrive. This
service policy is called Best-effort, which delivers the packets to their destination as it
can, without any assurance and guarantee for delivery delay, jitter, packet loss ratio,
reliability and so on.
The traditional Best-Effort service policy is only suitable for applications insensitive to
bandwidth and delay performance, such as WWW, file transfer and e-mail.
1.3 New Requirements Caused by New Applications

With the fast development of the network, more and more networks access the Internet.
The Internet has been expanded in terms of its scale, coverage and users quantities.
More and more users use Internet as their data transmission platform to implement
various applications. And service providers expect to increase their income with new
applications.
Apart from traditional applications of WWW, e-mail and FTP, network users try to
expand some new applications, such as tele-education, telemedicine, video telephone,
videoconference and Video-on-Demand (VoD), on the Internet. And the enterprise
users expect to connect their regional branches together to develop some operational
applications through VPN technology, for instance, to access the database of the
company or monitor their remote equipment via Telnet.
1-1
Those new applications have one thing in common, i.e. high requirements for
bandwidth, delay, and jitter. For instance, videoconference and VOD need the
assurance of wide bandwidth, low delay and jitter. As for mission-critical applications,
such as transaction and Telnet, they may not require wide bandwidth but do require
lower delay and be handled by priority during congestion.
The new emerging applications demand higher requirements for service performance
of IP network. Better network services during packets transmission are required other
than simply delivering the packets to their destination, such as providing user-specific
bandwidth, reducing packet loss ratio, avoiding congestion, regulating network traffic,
setting priority of the packets. To meet those requirements, the network should be
provided with better service capability.
1.4 Congestion: Causes, Impact, and Countermeasures

Network congestion is a key factor to degrade the service quality of the traditional
network. Congestion refers to such a fact that the service rates are decreased due to
relative deficiency of the resources supply (leading to extra delay).
1.4.1 Causes
Congestion will easily occur in complex packet switching circumstances in the Internet,
with two cases illustrated in the following Figures:
100 M
100 M 10 M 100 M 100 M
Traffic congestion at interfaces

w ith different speed
100 M
Traffic c ongestion at interfaces
w ith the same speed
Figure 1-1 Diagram for traffic congestion
1) The packet streams enter a firewall from a high speed link and are forwarded via a
low speed link;
2) Packet streams enter to a firewall from several interfaces with a same speed and
are forwarded through an interface with the same speed as well;
When traffic arrives at wire speed, congestion may occur for network resource
bottleneck.
Besides the bottleneck of link bandwidth, congestion will also be caused by resources
deficiency in normal packet forwarding, such as the deficiency of assignable processor
time, buffer and memory. In addition, congestion may occur if the arrival traffic is not
managed efficiently and the assignable network resources are inadequate.
1-2
1.4.2 Impact
Congestion may cause the following negative effects:

z Increase the delay and jitter of packet transmission
z Packet re-transmission caused by high delay
z Decrease the efficient throughput of network and waste the network resources
z Intensified congestion can occupy too many network resources (especially in
memory), and the irrational assignment of resources even can lead to resource
block and breakdown for the system.
It is obvious that congestion will make the traffics unable to obtain the resources in time
and degrade the service performance accordingly. No one wants congestion, but it
occurs frequently in complex environments where packet switching and multi-users
applications coexist. So it needs to be treated cautiously.
Note:
The congestion degrades the processing performance of a device. When the network
throughput rate falls into the degree that QoS can manage, the device begins to restore
its normal processing performance gradually.
1.4.3 Countermeasure
A direct way to solve resources deficient problem is to increase the bandwidth of

network; however, it cannot resolve all the problems concerning congestion.
A more effective method to solve the problem of QoS is to enhance the functions of
traffic control and resource allocation at network layer, and to provide differentiated
services for applications with different service requirement in order to allocate and use
resources rightly. During the process of resources allocation and traffic control, the
direct or indirect factors that might cause network congestion should be controlled with
best effort to reduce the probability of congestion. As congestion occurs, resource
allocation should be balanced according to features and demands of applications, to
minimize the effects on QoS by congestion.
1.5 Traffic Control Technologies

Traffic classification, traffic policing, traffic shaping, congestion management,
congestion avoidance, and physical-interface rate limiting are the foundations for a
network to provide differentiated services. Mainly they implement the following
functions:
1-3
z Traffic classification: It is a prerequisite for differentiated service, to identify the

interested objects based on a certain matching rule.
z Traffic policing: polices the specification of particular traffics entering the firewall.
When the traffics exceed the specification then some restriction or punishment
measures can be taken to protect the commercial benefits of carriers and to
prevent network resources from being damaged. Traffic policing is implemented at
the IP layer.
z Congestion management: handles resource competition during network
congestion. Generally, it stores the packets in the queue first, and then takes a
dispatching algorithm to assign the forwarding sequence of packets.
z Congestion avoidance: Exceeding congestion can waste the network resources.
Congestion avoidance can monitor the usage status of network resources, and as
congestion becomes worse actively take the policy of dropping packets through
adjusting traffic, to resolve the overloading of the network.
z Traffic shaping: A traffic control measure of actively adjusting the output speed of
traffics, generally it can enable the traffic to adapt to the network resources
supplied by the downstream router, to prevent the unwanted packet dropping and
congestion. Same as traffic policing, traffic shaping is implemented at the IP layer.
z Physical-interface rate limiting: Unlike traffic policing, which can handle only
packets that are processed at the IP layer, rate limiting restricts all packets on
physical interfaces and thus is well suited to the situation where rate limiting on all
packets is desired.
Among those traffic management technologies, traffic classification is the basis. It is a
prerequisite for differentiated service, which identifies the interested packet with certain
matching rule. As for traffic policing, traffic shaping, congestion management and
congestion avoidance, they implement management to network traffic and allocated
resources from different aspects respectively to realize the differentiated service.
Normally, QoS provides the following functions:
z Traffic classification
z Traffic policing and shaping
z Congestion management
z Congestion avoidance
1-4
Operation Manual – QoS Chapter 2 Traffic Classification, Policing,
H3C SecPath Series Security Products and Shaping
Chapter 2 Traffic Classification, Policing, and

Shaping
2.1 Traffic Classification

Traffic classification is the prerequisite and foundation for differentiated service, which
uses certain rules to identify the packets with certain features.
Normally, traffic is classified by one field or combination of fields in the packet header. It
is rare to use packet contents as classification criteria. You may create traffic
classification rules using the priority bits of ToS (type of service) field in the IP packet
header to identify the traffics having different preference features. Alternatively, the
network administrator may define a traffic classification policy, for instance, integrating
information such as source IP address, destination IP address, MAC address, IP, or
port number of the applications to classify traffic. In general, it can be a narrow range
defined by a quintuple (source IP address, source port number, destination IP address,
destination port number and the Transport Protocol), or can be all packets to a network
segment.
In general, while packets being classified on the network border, the precedence bits in
the ToS byte of IP header are set so that IP precedence can be used as a direct packet
classification standard within the network. The queuing technologies, such as WFQ,
can use IP precedence to handle the packets. Downstream network can receive the
packets classification results from upstream network selectively, or re-classify the
packets with its own standard.
Traffic classification is used to provide differentiated service, so it must be associated
with certain kinds of traffic policing or resource-assignment mechanisms. To adopt what
kind of traffic policing action will depend on the current stage and load status of the
network. For example, to police the packets according to the committed rate when they
enter the network, to make traffic shaping before they flow out the nodes, to do queuing
management in the event of congestion and to employ congestion avoidance when
congestion becomes worse.
2.2 Traffic Policing and Traffic Shaping

If no restrictions are imposed on the traffics from the users, bursting data sent by mass
users continuously will make the network become more congested. Thus for more
efficient network function and better network service for more users, the traffics from
the users must be restricted, for example, to restrict a traffic can only acquire the
specific assigned resources in certain time interval so as to prevent the network
congestion caused by excess burst.
2-1
Traffic policing and traffic shaping is a traffic monitoring policy to restrict the traffic and
resources through comparing with the traffic specification. To know whether the traffic
exceeds he specification or not is a prerequisite for traffic policing or shaping. Then
based upon the evaluation result you can implement a regulation policy. Usually Token
Bucket is used to value the traffic specification.
2.2.1 Traffic Evaluation and Token Bucket
I. Token bucket features
Token Bucket can be regarded as a container to reserve Token, which has certain
capacity. The system will put Tokens into the Bucket at a defined rate. In case the
Bucket is full, the extra Tokens will overflow and no more Tokens will be added.
Figure 2-1 Measuring the traffic with Token bucket
II. Measuring the traffic with Token Bucket
Whether or not the token quantity of the Token Bucket can satisfy the packets
forwarding is the basis for Token Bucket to measure the traffic specification. If enough
tokens are available for forwarding packets, traffic is regarded conforming the
specification (Generally one token is associated to the forwarding ability of one bit)
otherwise, non-conform or excess.
When measuring the traffic with Token Bucket, these parameters are included:
z Mean rate: The rate of putting Token into Bucket, i.e. average rate of the permitting
traffic. Generally set as CIR (Committed Information Rate).
z Burst size: Token Bucket’s capability, i.e. the maximum traffic size of every burst.
Generally, it is set as CBS (Committed Burst Size), and the bursting size must be
greater than the maximum packets size.
A new evaluation will be made when a new packet arrives. If there are enough tokens in
bucket for each evaluation, it shows that traffics are within the bound, and at this time
2-2
the amount of tokens appropriate for the packets forwarding rights, need to be taken
out. Otherwise, it shows that too much tokens have been used, and traffic
specifications are exceeded.
III. Complicated evaluation
Two Token Buckets can be configured to evaluate conditions that are more complex
and to implement more flexible regulation policy. For example, Traffic Policing (TP) has
three parameters, as follows:
z CIR (Committed Information Rate)
z CBS (Committed Burst Size)
z EBS (Excess Burst Size)
It uses two Token Buckets with the token-putting rate of every bucket set as CIR equally,
but with different capabilities: CBS and EBS (CBS < EBS, called C Bucket and E
Bucket), which represents different bursting class permitted. In each evaluation, you
may use different traffic control policies for different situations, such as "C bucket has
enough tokens”; "Tokens of C bucket are deficient, but those of E bucket are enough”;
"Tokens of C bucket and E bucket are all deficient”.
2.2.2 Traffic Policing
Typically, traffic policing is used to monitor the specification of certain traffic entering the
network and keep it within a reasonable bound, or it will make “penalty” on the
exceeding traffic so as to protect network resources and profits of carriers. For example,
it can restrict HTTP packets to occupy network bandwidth of no more than 50%. Once
finding the traffic of a connection exceeds, it may drop the packets or reset the
precedence of packets.
Traffic policing is widely used by ISP to police the network traffic. TP also includes the
traffic classification service for the policed traffics, and depending upon the different
evaluation results, it will implement the pre-configured policing actions, which are
described as the following:
z Forward: For example, continue to forward the packets evaluated as “conform”.
z Drop: For example, dropping the packets evaluated as “not conform”.
z Reset precedence and forward: For example, for packets evaluated “partly
conform”, to sign another priority then forwards them.
z Enter the policing of the next level: Traffic policing can stack gradually with each
class caring and policing objects that are more specific.
2.2.3 Traffic Shaping
Traffic shaping is a proactive way to adjust the traffic output rate. A typical application is
to control the output traffic with TP index based upon downstream network nodes.
2-3
The main difference between traffic shaping and traffic policing is: The packets to be
dropped in traffic policing will be stored during traffic shaping — generally they will be
put into buffer or queues (Also called Traffic Shaping – TS, See Figure 2-2). Once there
are enough tokens in Token Bucket, those stored packets will be evenly sent out.
Another difference is that traffic shaping may intensify delay, yet traffic policing seldom
does so.
Tokens enter bucket
at the given speed
Incoming packets
Outgoing packets
Classify
Token Bucket
Queue
Cache
Figure 2-2 TS diagram
As shown in the figure below, SecPath A sends packets to SecPath B. And SecPath B
implements TP on those packets, and directly drops exceeding traffic.
SecPath A SecPath B
A sends packets to B
Traffic
Physical line policing
Figure 2-3 Traffic shaping application
To reduce packets dropping, TS can be used for the packets on the egress interface of
SecPath A. The packets beyond the traffic features of TS will be stored in SecPath A.
While sending the next set of packets, TS will take out those packets from buffer or
queues and send them. So that all the packets sent to SecPath B accord with the traffic
regulation of SecPath B.
2.2.4 Line Rate on Physical Port
Line Rate (LR) on physical port can be used to limit the total rate of sending packets
(Incl. urgent packets) on a physical port.
LR also uses Token Bucket for traffic control. If LR is configured on an interface of a
firewall, all packets to be sent via the interface will be firstly handled by Token Bucket of
2-4
LR. If there are enough tokens in Token Bucket, then those packets can be forwarded;
otherwise, those packets will be put into QoS queues for congestion management, so
that the packet traffics through the physical port can be managed.
Tokens enter bucket

at the given speed
Incoming packets
Outgoing packets
Queue Token Bucket

Classify
Buffer
Figure 2-4 LR processing diagram
If Token Bucket is used to control the traffics, when there are tokens in Token Bucket,
the packets can be sent in burst; if no tokens are available, packets will not be sent until
new tokens generate in the Token Bucket. Thus, the traffic of packets is restricted under
the generating rate of new token to achieve the goal of restricting the traffics while
allowing bursting traffic overpass.
Compared with TP, LR can restrict all packets via physical port. TP is realized at IP
layer implementing no function for packets not through IP layer. If users demand to limit
the rate of all packets, LR is easier to be implemented.
2.3 Traffic Policing and Traffic Shaping Configuration

Traffic policing configuration includes:
z Configure CAR list
z Apply CAR policy
Traffic shaping configuration includes:
z Set shaping parameters for a certain kind of traffic
z Set shaping parameters for all traffics
LR on physical port configuration includes:
z Set LR on physical port
2.3.1 Configuring Traffic Policing
The traffic-policing configuration is divided into two tasks: one is to define the
characters of the packets that need traffic policing; the other is to define the policing
policy.
2-5
I. Configuring CAR list
You can configure the TP list for packet classification before applying the TP policy. For
different carl-index, the repeat execution of the command will create several TP lists;
for the same carl-index, the repeat execution of the command will modify the
parameters of CAR list, i.e. the CAR list just configured will replace the one, which
already exists using the same carl-index.
Table 2-1 Configure CAR list
Operation Command
qos carl carl-index { precedence precedence-value |
Create/modify CAR List
dscp dscp-value | mac mac-address }
Delete CAR List undo qos carl carl-index
You may specify precedence-value with multiple precedence-values or dscp-values if

you want to match several preference levels or DSCP values in one CAR list.
II. Applying CAR Policy
You may repeatedly perform this command to configure several CAR policies on the
interface. Except IP packets, this command will not handle other data packets.
Please set the following configuration in interface view.
Table 2-2 Apply CAR policy
Operation Command
qos car { inbound | outbound } { any | acl acl-number| carl
carl-index } cir committed-information-rate cbs
Apply CAR policy
committed-burst-size ebs excess-burst-size green action red
action
undo qos car { inbound | outbound } { any | acl acl-number |
Delete CAR policy carl carl-index } cir committed-information-rate cbs
committed-burst-size ebs excess-burst-size
The CIR cannot be greater than CBS × 20.

The action taken on a packet can be:
z continue: to have it dealt with by the next CAR strategy.
z discard: to discard the data packet.
z pass: to send the data packet.
z remark-prec-continue new-precedence: to specify a new IP priority
new-precedence and execute the next CAR strategy. The value range is 0~7.
2-6
z remark-prec-pass new-precedence: to specify a new IP priority new-precedence

and send the packet. The value range is 0~7.
CAR policy can be used on an ingress or egress interface.
2.3.2 Configuring Traffic Shaping
The command in the following table is used to set the shaping parameters for a
category of traffic or all the traffic and start the shaping as well.
You can configure the qos gts acl command to set the shaping parameters for the
traffic matching some ACL and use different ACLs to set the shaping parameters for
different categories of traffic.
You can use the qos gts any command to set the traffic parameters for all the traffic. If
you use the command repeatedly, the latest configuration will replace the previous one.
The commands qos gts acl and qos gts any cannot be used together.
Please set the following configurations in interface view.
Table 2-3 Set shaping parameters for a certain kind of traffic
Operation Command
qos gts { any | acl acl-number } cir
Set shaping parameters for a committed-information-rate [ cbs
certain kind of traffic committed-burst-size [ ebs excess-burst-size
[ queue-length queue-length ] ] ]
Remove shaping for a certain
undo qos gts { any | acl acl-number }
kind of traffic
2.3.3 Configuring LR on Port
Configuring LR on port is to restrict the speed of outward data via port.

Table 2-4 Configure LR on port
Operation Command
Set rate-restriction of physical qos lr cir committed-information-rate [ cbs
port committed-burst-size [ ebs excess-burst-size ] ]
Remove LR on physical port undo qos lr
2-7
2.4 Traffic Policing and Shaping Display and Debug

2.4.1 Displaying TP Rule
running of a certain rule or all the access rules of TP configuration, and to verify the
effect of the configuration.
Table 2-5 Display TP rule
Operation Command
Display TP rule display qos carl [ carl-index ]
2.4.2 Displaying TP Configuration and Statistics on Each Interface
running of the TP configuration information and running statistic information on each
interface, and to verify the effect of the configuration.
Table 2-6 Display the TP configuration and statistics on each interface
Operation Command
Display the TP configuration and display qos car interface
statistics on each interface [ interface-type interface-number ]
2.4.3 Displaying TS Configuration and Statistics on Interface
running of TS configuration and statistics in certain interface or all interfaces, and to
verify the effect of the configuration.
Table 2-7 Display TS configuration and statistics on the interface
Operation Command
Display TS configuration and statistics in display qos gts interface
the interface [ interface-type interface-number ]
2.4.4 Displaying LR Configuration and Statistics on Interface
running of LR configuration and statistics in certain interface or all interfaces, and to
verify the effect of the configuration.
2-8
Table 2-8 Display LR configuration and statistics in the interface
Operation Command
Display LR configuration and statistics in display qos lr interface [ interface-type
the interface interface-number ]
2.5 Typical Example of Traffic Policing and Shaping

As shown in Figure 2-5, the interface Ethernet0/0/0 of the firewall SecPath1 is

connected with the interface Ethernet1/0/0 of the firewall SecPath2. Server, PC1 and
PC2 can access the Internet via SecPath1 and SecPath2. Server, PC1 and the
interface Ethernet1/0/0 of SecPath1 are in the same network segment while PC2 and
the interface Ethernet2/0/0 of SecPath1 are in the same network segment. The traffics
from Server and PC1 received by the interface Ethernet1/0/0 require to be controlled
on SecPath2.
The traffic restriction from Server is 54000bps. The traffic less than this restriction can
be transmitted normally. When the traffic exceeds this restriction, the preference of the
ultra-long packet will be set to 0 before transmission.
The traffic restriction from PC is 8000bps. The traffic less than this restriction can be
transmitted normally. When the traffic exceeds this restriction, the ultra-long packet will
be dropped.
In the meantime, there are the following requirements for the interfaces Ethernet1/0/0
and Ethernet0/0/0 on the firewall SecPath2:
z The restriction of the total traffic received by the interface Ethernet1/0/0 on
SecPath2 is 0.5Mbps and when the traffic exceeds this restriction, the ultra-long
packet will be dropped.
z The restriction of the traffic entering the Internet via the interface Ethernet0/0/0 on
SecPath2 is 1Mbps and when the traffic exceeds this restriction, the ultra-long
packet will be dropped.
2-9
II. Network diagram
Server PC1 Internet

SecPath2
ethernert1/0/
0 ethernet0/0/0
1.1.1.1/8 1.1.1.2/8
ethernert1/0/0
PC2
SecPath1 ethernet0/0/0
ethernert2/0/0
Figure 2-5 Network diagram of traffic policing and shaping
1) Configure SecPath 1:
# Configure TS on the interface Ethernet0/0/0 of SecPath1 to shape the traffic (over
0.5Mbps) transmitted from the interface so as to reduce the packet drop rate on the
interface Ethernet1/0/0 of SecPath2.
[H3C-Ethernet0/0/0] qos gts any cir 500000
2) Configure SecPath 2:
# Configure the ACL to match the packets from Server and PC1.
# Configure TP on the interface Ethernet1/0/0 to perform the corresponding traffic

control on the different traffics received by the interface Ethernet1/0/0.
[H3C-Ethernet1/0/0] qos car inbound acl 2001 cir 54000 cbs 54000 ebs 0 green
pass red remark-prec-pass 0
[H3C-Ethernet1/0/0] qos car inbound acl 2002 cir 80000 cbs 80000 ebs 0 green
pass red discard
[H3C-Ethernet1/0/0] qos car inbound any cir 500000 cbs 500000 ebs 0 green pass
red discard
# Configure TP on the interface Ethernet0/0/0 to perform traffic control on the traffic

transmitted on the interface Ethernet0/0/0. The traffic should not exceed 1Mbps and the
ultra-long packets will be dropped.
2-10
[H3C-Ethernet0/0/0] qos car outbound any cir 1000000 cbs 1000000 ebs 0 green
pass red discard
2-11
H3C SecPath Series Security Products Chapter 3 Congestion Management
Chapter 3 Congestion Management
3.1 Brief Introduction to Congestion Management

As to a network device, congestion will occur on the interface where the arrival rate of
packets is faster than the sending rate. If there is no enough memory capacity to store
those packets and then a part of them will be lost, which may cause the packet
retransmission from the hosts or router because of timeout, and lead to a vicious circle.
The key to congestion management is how to define a dispatching policy for resources
to decide the forwarding order of packets when congestion occurs.
3.1.1 Congestion Management Policies
In general, congestion management adopts queuing technology. The system classifies

traffics using a kind of queuing algorithm, and then it will send out them with a certain
preference algorithm. Each queuing algorithm is used to handle a particular network
traffic problem and has great impacts on bandwidth resource assignment, delay, and
jitter.
We will introduce several common queue-scheduling mechanisms here.
I. FIFO queuing
Incoming packets Outgoing packets
Queue Interface
Transmit
queue
Figure 3-1 FIFO queuing
As shown in above figure, FIFO (First In First Out) designs the forwarding order of
packets depending upon their arrival time. On a firewall, the resources assigned for
data traffic of users are based on the arrival time of packets and the current load status
of the network. Best-Effort services use FIFO queuing policy.
If there is only one FIFO-based output/input queue on firewall’s interface, malicious
applications may occupy all network resources and seriously affect mission-critical
data.
3-1
Within each queue, the sending (sequence) of packets is defaulted as FIFO.
II. PQ (Priority Queuing)
Top queue
Middle queue
Interface
Normal queue
Transmit
Classify Scheduler
Bottom queue queue
Figure 3-2 Priority queuing
Priority queuing is designed for mission-critical applications. Those applications have

an important feature, i.e. when congestion occurs they require preferential service to
reduce the response delay. PQ can flexibly design priority sequence according to
different network protocols (e.g. IP and IPX), interface receiving packets, packet length,
source/destination IP address etc. Priority queuing classifies the packets into four
different types: top, middle, normal and bottom, in descending order. By default, the
data flow enters the normal queue.
During queues dispatching, PQ strictly comply with the priority sequence from high to
low, and it will send packets in the high-priority queue first. When that queue is empty,
PQ will begin to send packets in lower priority queue. The system then put packets of
mission-critical application in higher priority queue, and packets of normal application in
lower priority queue. It guarantees that the packets of mission-critical application are
sent with priority, and the packets of normal application are sent at the free interval of
operating mission-critical application.
The disadvantage of PQ is that packets in the lower queues will be neglected if there
are packets in the higher queues for a long time.
3-2
III. CQ (Custom Queuing)
Queue1 10%
Queue2 30%
Interface
……
Classify Queue15 10% Transmit
Scheduler
queue
Queue16
5%
Figure 3-3 Custom queuing
CQ classifies packets into 17 classes in accordance with certain rules (corresponding

to 17 queues). Based on their own classes, packets will enter the corresponding
custom queues with FIFO policy.
Of these 17 queues, queue 0 is a system queue (not shown) which is not configurable
and queues 1 through 16 are user queues, as shown in the above figure. User can set
the rules of traffic classification and assign the proportions on occupying interface
bandwidth for those 16 user queues. During dispatching, packets in system queue are
sent preferentially till the queue is empty. Then with polling method a certain number of
packets, taken from No.1-16 user queues under the bandwidth-occupying proportion
set in advance, are sent out. In this way, packets of different application can be
assigned with different bandwidth. Therefore, it will not only ensure mission-critical
application to get more bandwidth but also prevent normal application from obtaining
no bandwidth at all. By default, the data flow enters the No.1 queue.
Another advantage of custom queuing is that bandwidth can be assigned according to
the busyness of applications, which is suitable for those applications having special
requirement for bandwidth. Though the dispatching for 16 user queues is polling, the
service time for each queue is not fixed. So when there are no packets of certain
classes, the CQ dispatching mechanism can automatically increase bandwidth
occupied by the packets of current existing class.
3-3
IV. WFQ (Weighted Fair Queuing)
Queue1 weight1
Queue2 weight2
Interface
……
Classify QueueN-1 weightN-1 Transmit
Scheduler queue
QueueN weightN
Figure 3-4 WFQ diagram
Before further to Weighted Fair Queuing, FQ (Fair Queue) is to be introduced first. FQ

is designed for fairly sharing network resources, which will try to reduce the delay and
jitter of all traffics to their optimum levels. It has taken all the aspects into consideration,
which has the following features:
z Different queues have fair opportunity of dispatching to equilibrate the delay of
each stream on the whole.
z Short packets and long packets are treated fairly while dequeuing: if there are long
packets in a queue and short packets in another queue waiting simultaneously to
be send out, the short packets should also be cared, and statistically the short
packets should be treated preferentially, and the jitter between packets of every
traffic will be reduced on the whole.
Compared with FQ, WFQ concerns about priority in addition when calculating the
dispatching sequence of packets. Statistically, with WFQ, high priority traffic takes
priority over low priority packets in dispatching. WFQ can automatically classify traffic
according to the “session” information of traffic (protocol type, source/destination TCP
or UDP port number, source/destination IP address, preference bits of ToS field, etc),
and try to provide more queues so that each traffic will be equably put into different
queues and equilibrate the delay of every traffic on a whole. While dequeuing, WFQ
can assign the bandwidth of egress interfaces occupied by each flow according to the
precedence. The bigger the numerical value of the precedence, the more bandwidth
can be obtained.
For example: Now if there are five streams on the interface, and their precedence
values are 0, 1, 2, 3, 4, respectively, then the total bandwidth quota will be: the sum of
total (precedence of traffic +1), i.e.
1+2+3+4+5=15
3-4
The bandwidth-occupying proportion for each traffic is: (priority + 1)/total quota of
bandwidth, i.e. Bandwidth available for each traffic: 1/15, 2/15, 3/15, 4/15, 5/15.
Because WFQ can balance the delay and jitter of every flow when congestion occurs, it
is effectively applied in particular fields. For instance, in the assured services using the
RSVP (resource reservation protocol), generally, WFQ will be used as the dispatching
policy. And also in TS, WFQ is used to dispatch buffered packets.
V. CBQ (Class-Based Queuing)
CBQ is the extension of WFQ, which supports user-defined classes. CBQ allocates an
independent FIFO reserved queue for each user-defined class to buffer data of the
same class. In case of network congestion, CBQ matches output packets according to
user-defined class rules and enables them to enter corresponding queues. It is
necessary to check the congestion avoidance mechanism, namely, whether tail drop or
weighted random early detection (WRED) is used, and bandwidth restriction before the
packets enter queues. WFQ is performed to the packets in the queue corresponding to
each class when they go out of the queue.
CBQ provides an emergency queue for emergency packets. CBQ uses FIFO dispatch
and has no bandwidth restriction. If CBQ performs WFQ on queues of all classes, such
data traffic as voice packets that are delay sensitive may not be transmitted in time. In
this case, PQ is added to CBQ, which is known as LLQ (Low Latency Queuing) to
provide strict priority (SP) mechanism for such delay-sensitive data streams as voice
packets.
LLQ combines SP mechanism with CBQ. The user can set a class subject to SP
mechanism when defining the class. Such a class is known as priority class. All packets
of the priority class will enter the same priority queue. It is necessary to check
bandwidth restriction of packets before they enter queues. When the packets go out of
queues, the packets in priority queue get transmitted first and then the packets in other
queues corresponding to other classes follows. These packets are dispatched in
weighted fair mode when being transmitted.
In order that packets in other queues will not be delayed too long, maximum available
bandwidth can be specified to each priority class when using LLQ. The bandwidth value
is used to monitor traffic in case of congestion. If no congestion happens, the priority
class is allowed to use the bandwidth exceeding the allocated value. If congestion
happens, the packets of the priority class exceeding the allocated bandwidth will be
discarded. LLQ can also specify burst-size.
The system will always match the priority class first and then the other classes when
matching rules for packets. Multiple priority classes are matched in the configuration
sequence. It is the same with other classes. Multiple rules in a class are matched in the
configuration sequence.
3-5
VI. RTP (Real-time Transport Protocol) priority queuing
RTP priority queuing technology is used to solve the QoS problems of real-time service
(including audio and video services). Its principle is to put RTP packets carrying audio
or video into high-priority queue and send it first, thus minimizing delay and jitter and
ensuring the quality of audio or video service which is sensitive to delay.
Packets sent from RTP queue Outgoing first

this interface Sent packets
Classification Other queueing Sent queue

mechanism: FQ, Scheduling
CQ, WFQ
Figure 3-5 RTP queuing diagram
As shown in the above figure, an RTP packet is sent into a high priority queue. RTP
packet is the UDP packet whose port number is even. The range of the port number is
custom. RTP priority queue can be used along with any queue (e.g., FIFO, PQ, CQ,
WFQ and CBQ), while it has the highest priority. Since LLQ of CBQ can also be used to
solve real-time service, it is recommended not to use RTP together with CBQ.
3.1.2 Comparisons among Congestion Management Technologies
SecPath firewalls will provide several congestion management technologies. Breaking

through the single congestion management policy of FIFO for traditional IP equipment,
they provide strong QoS ability, which meets the demands of different service quality
required by different applications. For efficient use of congestion management
technologies, the following table compares the available queuing technologies.
3-6
Table 3-1 Congestion management technologies
Type Queue No. Advantages Disadvantages

z All packets are put in a
first in, first out queue,
whether they are voice
or data packets and
despite of their urgency.
The available
bandwidth, delay and
drop probability are
decided by the arrival
z No need for order of the packets.
configuration, easy to
use z No restriction on the
FIFO 1
unmatched data sources
z Easy operation, low (that is, flows without
delay flow control mechanism,
UDP for example),
resulting bandwidth loss
of matched data sources
such as TCP.
z No guarantee to the
delay of time-sensitive
real-time application,
such as VoIP
z Provide absolute
preference to data of z Need to be configured
different applications, with high system
and capable of overhead
ensuring the low delay z If there are no restriction
for real-time on bandwidth-occupying
PQ 4 applications (VoIP) of packets with high
z Provide absolute preference, the packets
preference to the with low preference
packets of preferential won’t obtain the required
business on their bandwidth
bandwidth-occupying
z Capable of assigning
the
bandwidth-occupying
proportion according
to packets with
different applications Need to be configured with
CQ 17
high system overhead
z If packets of certain
classes do not exist, it
can increase the
bandwidth for existing
packets
3-7

z Easily configured
z Capable of ensuring
the
bandwidth-occupying
for data sources (e.g.
TCP packets sending)
used for interactive
purpose
z Capable of reducing
jitter
z Capable of reducing System overhead is higher
WFQ Configurable the delay for than FIFO but lower than
interactive application PQ and CQ
with small data
z Capable of assigning
different bandwidth for
traffics with different
priorities
z When the amount of
the traffics decreased,
it can automatically
increase the
bandwidth for existing
traffics.
3-8

z Capable of classifying
data according to
flexible, various rules,
providing different
queue dispatching
mechanism for the
expedited forwarding
(EF), assured
forwarding (AF) and
best-effort (BE)
services.
z Capable of providing
highly precise
bandwidth assurance
for the AF service and
ensuring that the
queue dispatching is
performed according
Configurable to a certain weight
proportion among The system overhead is
CBQ
(0 to 64) various AF services. high.
absolutely preferential
queue dispatching for
the EF service so as to
ensure the real-time
data delay. In the
mean time, it can
overcome the
disadvantage that the
PQ of low preference
will "extinct due to too
little data flow" since it
restricts the data flow
of high preference.
WFQ dispatching for
the default data of
best-effort forwarding.
3.2 Configuring FIFO Queue

FIFO queue configuration includes:
z Configure the length of FIFO queue
3.2.1 Configuring FIFO Queue Length
FIFO is the queue scheduling mechanism for interface by default, and the length of the
queue can be changed by configuration command.
Please set the following configuration in interface view.
3-9
Table 3-2 Configure FIFO queue length
Operation Command
Configure the length of FIFO queue qos fifo queue-length queue-length
Restore the default length of FIFO queue undo fifo queue-length
The default length for FIFO queue is 75.
3.3 Priority Queuing Configuration

PQ configuration includes:
z Configure priority-list
z Apply priority-group on the interface
3.3.1 Configuring Priority-list
I. Configuring Priority-list under network layer protocol
The packets will be classified into different queues based on different protocol types.
For a same pql-index, repeatedly using this command can set several rules for it.
The system will match the packets according to the sequence of configured rules. Once
finding the packets match a certain rule, the system will stop searching.
Please set the following configurations in system view.
Table 3-3 Priority-list configuration based on network layer protocol
Operation Command
qos pql pql-index protocol ip
Configure priority-list according to
[ queue-key key-value ] queue { top |
network layer protocol
middle | normal | bottom }
Delete the relative classifying rules in undo qos pql pql-index protocol ip
group-number [ queue-key key-value ]
II. Configuring Priority-list based on interfaces on which packets are received
Classify the packets based on the ingress interfaces of firewalls, and send them into
different queues.
3-10
Table 3-4 Configure Priority-list based on interfaces on which packets are received
Operation Command
Configure Priority-list based on qos pql pql-index inbound-interface
interfaces on which packets are interface-type interface-number queue
received { top | middle | normal | bottom }
undo qos pql pql-index

Delete the relative classifying rules in
inbound-interface interface-type
group-number
interface-number
III. Configuring default queue
A default queue is designated for the packets that do not match any rules.
Table 3-5 Configure default queue
Operation Command
qos pql pql-index default-queue { top |
Configure default queue
Restore the default value of default
undo qos pql pql-index default-queue
queue
You may define multiple rules for a priority-list group and apply these rules to an
interface. When a packet that need to be forwarded out the interface arrives at the
interface, the system compares it against the rule chain, If a match is found, the packet
is put into the corresponding queue and the match operation is complete; if no match is
found, the packet is put into the default queue.
The default value for default queue is normal.
IV. Configuring the Length of Queue
Configure the length of each queue (i.e. the capability of queue).

Table 3-6 Configure length of the queue
Operation Command
qos pql pql-index queue { top | middle
Configure Length of the queue | normal | bottom } queue-length
queue-length
undo qos pql pql-index queue { top |
Recover the default length value of each
queue
queue-length
3-11
The following table lists the default length of each queue.
Table 3-7 Default length of each queue
Queue Length
top 20
middle 40
normal 60
bottom 80
3.3.2 Applying Priority-list Queue on the Interface
Apply a group of Priority-list on the interface; to use this command repeatedly will set a
new priority-list for the same interface.
Table 3-8 Apply priority-list group on the interface
Operation Command
Apply priority-list group on the interface qos pq pql pql-index
Cancel using PQ on the interface undo qos pq
Not PQ but FIFO is employed on the interface by default.
3.3.3 Displaying and Debugging Priority Queue
After the above configuration, execute display commands in any view to display the
running of the priority queue configuration, and to verify the effect of the configuration.
Table 3-9 Display priority queue status and application on the interfaces
Operation Command
Display the status of priority queue display qos pql [ pql-index ]
Display priority queue configuration display qos pq interface

status on the interface [ interface-type interface-number ]
3.4 Custom Queuing Configuration

Customize queuing configuration includes:
z Configure custom queuing list (CQL)
z Apply custom-group onto the interface
3-12
3.4.1 Configuring a CQL
There are 16 groups (called custom-groups) of CQLs (1 through 16), each specifying
packet queuing rule, length of each queue, and bytes to be sent continuously for each
queue during a poll. You may apply only one custom-group on an interface.
I. Configuring a CQL under network layer protocol
Packets can be classified under different protocols, and enter different queues. But
Comware can only classify IP packets by far.
Table 3-10 Configure a CQL under network layer protocol
Operation Command
qos cql cql-index protocol ip
Configure a CQL under network layer
[ queue-key key-value ] queue
protocol
queue-number
Remove a CQL from the custom-group undo qos cql cql-index protocol ip
identified by the cql-index argument [ queue-key key-value ]
II. Configuring a CQL according to the ingress interfaces of packets
Set an interface-based classifying rule. Repeatedly using this command can add rules
to a cql-index.
Table 3-11 Configure a CQL based on interface
Operation Command
qos cql cql-index inbound-interface
Configure a CQL based on the incoming
interface-type interface-number queue
interface of packets
queue-number
undo qos cql cql-index
Remove a CQL from the custom-group
inbound-interface interface-type
identified by the cql-index argument
interface-number
III. Configuring default queue
Designate a default queue for those packets matching no rules.

3-13
Table 3-12 Configure default queue
Operation Command
qos cql cql-index default-queue
Configure default queue
queue-number
Restore the default value of default
undo qos cql cql-index default-queue
queue
We can define several rules for a custom-group and apply the rules to an interface.
When a packet is treated by the interface (the packet needs to be sent out via this
interface), the system will match this packet along rule chain; if it matched with a certain
rule, then it will enter the corresponding queue and the matching is finished, otherwise,
the packet will enter default queue.
The default value of default queue is 1.
IV. Configuring length of the queue
Designate length for a custom queue (i.e. Capacity of the queue).

Table 3-13 Configure the length of the queue
Operation Command
Configure the length of the qos cql cql-index queue queue-number
queue queue-length queue-length
Restore the default length of undo qos cql cql-index queue queue-number
each queue queue-length queue-length
The queue-length argument specifies the maximum queue length; it defaults to 20.
V. Configuring the queue continuously sending bytes
Configure the bytes of packets sent by polling of each queue.

Table 3-14 Configure the queue continuously sending bytes
Operation Command
Configure the queue continuously qos cql cql-index queue queue-number
sending bytes serving byte-count
Recover the default value of sending undo qos cql cql-index queue
bytes queue-number serving
In which:
3-14
byte-count: When the firewall dispatches user queue of CQ, it will continuously pick out
the packets to send from this queue till the sending bytes are no less than value of
byte-count configured for this queue or the queue is empty, then it will dispatch another
user queue of CQ. So the value of byte-count will affect the proportion of interface
bandwidth occupied by every user queue of CQ, and also determine the time interval of
dispatching another queue of CQ by the firewalls. The default byte number of
byte-count is 1500.
If the value of byte-count is too small, since the firewall won't treat the packets in the
next queue unless at least one packet in the former one is sent out, the actual acquired
bandwidth of a queue would be far from that expected. If byte-count is too large, it may
cause great switch delay between different queues.
3.4.2 Applying a CQL on the Interface
Table 3-15 Apply a CQL on the interface
Operation Command
Apply a CQL on the interface qos cq cql cql-index
Disable CQ on the interface undo qos cq
By default, FIFO instead of CQ is adopted on the interface.
3.4.3 Displaying and Debugging CQL
running of the CQL configuration, and to verify the effect of the configuration.
Table 3-16 Display CQL status and application on the interfaces
Operation Command
Display CQL status display qos cql [ cql-index ]
Display CQL application status on the display qos cq interface
interfaces [ interface-type interface-number ]
3.5 WFQ Configuration

Configuring WFQ (Weighted Fair Queuing) includes:
z Use WFQ or modify WFQ parameters
3-15
3.5.1 Using WFQ or Modifying WFQ Parameters
WFQ classifies packets by traffic streams. On the IP network, the packets with the
same quintuple (source and destination IP addresses, source and destination ports and
protocol number) and IP preference (DSCP value) belong to a traffic stream. On the
access network, traffic classification is based on IP preference and the quintuple; on
the convergence network, traffic classification is based DSCP value and the quintuple.
By default, traffic classification is based on IP preference and the quintuple, but you can
choose the traffic classification criteria use the command.
In case where no WFQ is employed on the interface, this command can be used to
employ WFQ and designate the parameter for WFQ, otherwise, this command can be
used to modify the parameters of WFQ.
Table 3-17 Use WFQ or modify WFQ parameters
Operation Command
qos wfq [ precedence | dscp ]
Use WFQ or modify WFQ parameters [ queue-length max-queue-length
[ queue-number total-queue-number ] ]
Remove WFQ setting undo qos wfq
FIFO instead of WFQ is employed on the interface by default.

The total-queue-number argument can be 16, 32, 64, 128, 256, 512, 1024, 2048, or
4096. It defaults to 256.
Caution:
z You can apply WFQ on the dialer interface. To do it successfully, however, the
corresponding physical interface must be configured with the default queuing
mechanism.
z After you apply a new queuing mechanism on the dialer interface. the Dialer
interface queuing mechanism cannot be applied on the physical interface bound to
the dialer interface if the physical interface has set up a link with the connected
device.
3-16
3.5.2 Displaying and Debugging WFQ
running of the configuration and statistics information of WFQ on one or interfaces, and
to verify the effect of the configuration.
Table 3-18 Display the configuration and statistics of WFQ on one or all interfaces
Operation Command
Display the configuration and statistics display qos wfq interface
information of WFQ on interfaces [ interface-type interface-number ]
3.6 Class-based Queuing Configuration

The class-based queuing CBQ configuration includes:
z Configure the maximum available bandwidth on the interface
z Define the class and define a group of traffic classification rules in the class view.
z Define traffic behavior, and define a group of QoS features in the traffic behavior
view.
z Define the policy, and define the corresponding traffic behavior for the class in use
in the policy view.
z Apply QoS policy in the interface view.
The system pre-defines some classes, traffic behaviors and policies. The detailed
description is given below.
I. Pre-defined classes
The system pre-defines some classes and defines general rules for them. The user can
use the pre-defined classes when defining the policy. The classes include:
1) Default class: default-class, matching the default data flow.
2) DSCP-based pre-defined class: ef, af1, af2, af3, af4, matching IP DSCP values of
ef, af1, af2, af3, af4 respectively.
3) IP priority-based pre-defined class: ip-prec0, ip-prec1, ip-prec7: matching IP
priorities of 0, 1, 7 respectively.
4) MPLS EXP-based pre-defined class: mpls-exp0, mpls-exp1, …mpls-exp7:
matching MPLS EXP values of 0, 1, …7.
II. Pre-defined traffic behaviors
The system pre-defines some traffic behaviors and defines QoS features for them.
1) ef: Defines a feature of input ef queue, occupying 20% of the available bandwidth
of the interface.
2) af: Defines a feature of input af queue, occupying 20% of the available bandwidth
of the interface.
3-17
3) be: Defines no features.
III. Pre-defined policies
The system pre-defines a policy, and specifies the pre-defined class for the policy and
specifies the pre-defined behavior for the class. The policy is named default, with the
default CBQ behavior.
The detailed rules of the default policy are as follows.
1) Pre-defined class ef, adopting pre-defined traffic behavior of ef.
2) Pre-defined classes af1 to af4, adopting pre-defined traffic behavior of af.
3) default-class, adopting pre-defined traffic behavior of be.
3.6.1 Configuring the Maximum Available Bandwidth on the Interface
The bandwidth discussed here refers to the maximum interface bandwidth used when
CBQ enqueues packets, rather than the actual bandwidth of the physical interface.
Table 3-19 Configure bandwidth of the interface
Operation Command
Configure the bandwidth of the interface qos max-bandwidth bandwidth
Restore the default bandwidth undo qos max-bandwidth
The bandwidth argument indicates the available bandwidth of the interface. It is in kbps
(1 to 1000000). By default, this value is the actual interface baud rate or speed for a
physical interface, or 64 kbps for a logical interface like virtual template or VE.
The maximum available bandwidth of an interface is preferred to be smaller than the
real available bandwidth of the physical interfaces or the logical links.
Caution:
If LR and CBQ (in percentage) are both configured on the interface, make sure that the
bandwidth configured using this command should be consistent with LR.
3.6.2 Configuring Matching Rules of a Class
Before you can define a class, you must first create its class name. Then you can
configure matching rules in this class view.
3-18
I. Defining a class and enter the class view
Table 3-20 Define a class and enter the class view
Operation Command
traffic classifier tcl-name [ operator
Define a class and enter the class view
{ and | or } ]
Delete a class undo traffic classifier tcl-name
The user-defined class name tcl-name should not be that of the classes pre-defined by
the system.
By default, the class is defaulted to and. That is, the relation between respective
matching rules in the class view is logic AND.
II. Defining/Deleting the rule matching all packets
Perform the following configuration in class view.
Table 3-21 Define/delete the rule matching all packets
Operation Command
Define the rule matching all packets if-match [ not ] any
Delete the rule matching all packets undo if-match [ not ] any
III. Defining/Deleting classifier match rule
Table 3-22 Define/delete classifier match rule
Operation Command
Define classifier match rule if-match [ not ] classifier tcl-name
Delete classifier match rule undo if-match [ not ] classifier tcl-name
This command cannot be used circularly. For example, traffic classifier A defines the
rules to match traffic classifier B but traffic classifier B cannot define a rule match traffic
classifier A directly or indirectly.
IV. Defining/Deleting ACL match rule
3-19
Table 3-23 Define/delete ACL match rule
Operation Command
Define ACL match rule if-match [ not ] acl access-list-number
Delete ACL match rule undo if-match [ not ] acl access-list-number
V. Defining/Deleting match rule of MAC address
Table 3-24 Define/delete MAC address match rule
Operation Command
if-match [ not ] { destination-mac |
Define MAC address match rule
source-mac } mac-address
undo if-match [ not ] { destination-mac |
Delete MAC address match rule
source-mac } mac-address
The match rules of the destination MAC address are only meaningful for policies in the
output direction and the interface of Ethernet type.
The match rules of the source MAC address are only meaningful for policies in the input
direction and the interface of Ethernet type.
VI. Defining/Deleting input-interface match rule of a class
Table 3-25 Define/delete input-interface match rule of a class
Operation Command
Define input-interface match rule of a if-match [ not ] inbound-interface type
class number
Delete input-interface match rule of a undo if-match [ not ]
class inbound-interface type number
The rule will be deleted automatically when the matched interface is deleted.
VII. Defining/Deleting DSCP match rule
DSCP (Differentiated Services Code Point) is a refined field from the 6 high bits of ToS
bytes in IP header by IETF DiffServ workgroup. In the solution submitted by DiffServ,
services are classified and traffic is controlled according to service requirements at
network ingress. Simultaneously, DSCP is set. Communication (including resource
3-20
allocation, packet discard policy, etc.) is classified and served on the basis of the
grouped DSCP values
The user can set classified matching rules according to DSCP values.
Table 3-26 Define/delete DSCP match rule
Operation Command
Define DSCP match rule if-match [ not ] dscp { dscp-value }
Delete DSCP match rule undo if-match [ not ] dscp { dscp-value }
VIII. Defining/Deleting ip precedence match rule
Table 3-27 Define/delete ip precedence match rule
Operation Command
if-match [ not ] ip-precedence
Define ip precedence match rule
{ ip-precedence-value }
Delete ip precedence match rule undo if-match [ not ] ip-precedence
Use the corresponding command to configure the value of ip precedence during the
configuration, otherwise, the configuration of the if-match ip precedence command
will overwrite the previous configurations.
IX. Defining/Deleting RTP port match rule
Table 3-28 Define/delete RTP port match rule
Operation Command
if-match [ not ] rtp start-port
Define RTP port match rule
starting-port-number end-port end-port-number
undo if-match [ not ] rtp start-port
Delete RTP port match rule
starting-port-number end-port end-port-number
Because the RTP priority queue has the higher priority than that of the CBQ, the RTP
will take effect only if both the RTP priority queue and the queue based on the class
matching RTP are configured at the same time.
3-21
X. Defining/Deleting protocol match rule
Table 3-29 Define/delete protocol match rule
Operation Command
Define protocol match rule if-match [ not ] protocol protocol-name
Delete protocol match rule undo if-match [ not ] protocol protocol-name
protocol-name: Only the IP protocol is used.
3.6.3 Configuring Features of a Traffic Behavior
To define a traffic behavior, you should first create a traffic behavior name and then
configure attributes for it in the new traffic behavior view.
I. Defining a traffic behavior and Entering traffic behavior view
Table 3-30 Define a traffic behavior and enter traffic behavior view.
Operation Command
Define a traffic behavior and enter traffic
traffic behavior behavior–name
behavior view.
Delete a traffic behavior undo traffic behavior behavior–name
behavior-name: Name of the traffic behavior. It is not the name of the traffic behavior
pre-defined by the system.
II. Configuring AF and minimum available bandwidth
Perform the following configuration in traffic behavior view.
Table 3-31 Configure AF and minimum available bandwidth
Operation Command
Configure AF and minimum available queue af bandwidth { bandwidth | pct
bandwidth percentage }
Delete the configuration undo queue af
This behavior can apply only in output direction of an interface.

In the same policy, you need to use the same standard to configure queue ef and
queue af, either bandwidth or percentage.
3-22
III. Configuring EF and CBS
Table 3-32 Configure EF and CBS
Operation Command
queue ef bandwidth { bandwidth [ cbs
Configure EF and CBS committed-burst-size ] | pct percentage [ cbs_ratio
ratio] }
Delete the configuration undo queue ef
In traffic behavior view, this command cannot be used along with queue af,
queue-length and wred.
This command cannot be used for default-class.
The same traffic behavior must use the same standard to configure queue ef and
queue af, either bandwidth or percentage.
IV. Configuring fair queuing
Table 3-33 Configure fair queuing
Operation Command
Configure fair queuing queue wfq [ queue-number total-queue-number ]
Delete the configured undo queue wfq
Configure that the traffic behavior of the feature can only be associated with the default
class.
V. Configuring maximum queue length
Configure maximum queue length and the drop type is tail drop.
Table 3-34 Configure maximum queue length
Operation Command
Configure maximum queue length queue-length queue-length
Delete the configuration undo queue-length
This command can be used only after the queue af command and queue wfq
command have been configured.
3-23
Execute the undo queue af command and undo queue wfq command, then
queue-length will be deleted as well.
For the default-class, this command can be used only after the queue af or queue wfq
command has been configured.
VI. Configuring the drop type as random
Table 3-35 Configure the discarding mode as random
Operation Command
Configure the discarding mode as random wred [ dscp | ip-precedence ]
Restore the default setting undo wred
dscp indicates that the dscp value is used to calculate drop proportion of a packet.
Ip-precedence indicates that the IP precedence value is used to calculate discard
proportion of a packet, which is the default setting.
This command can be used only after the queue af command and queue wfq
command have been configured. The wred and queue-length are mutually exclusive.
Other configurations under the random drop will be deleted when this command is
deleted. When a QoS policy included WRED is applied on an interface, the original
WRED configuration on interface will be ineffective.
The default-class can only be associated with the traffic behavior configured the
random drop based on the IP precedence.
VII. Configuring exponential of average queue length calculated by WRED
Table 3-36 Configure exponential of average queue length calculated by WRED
Operation Command
Configure exponential of average queue
wred weighting-constant exponent
length calculated by WRED
Delete the configuration undo wred weighting-constant
This command can be used only after the queue af or queue wfq command has been
configured and the wred command has been used to enable WRED
VIII. Configuring DSCP lower-limit, upper-limit and discard probability of

WRED
3-24
Table 3-37 Configure DSCP lower-limit, upper-limit and discard probability of WRED
Operation Command
wred dscp dscp-value low-limit
Configure DSCP lower-limit, upper-limit
low-limit high-limit high-limit
and discard probability of WRED
[ discard-probability discard-prob ]
Delete the configuration undo wred dscp dscp-value
The dscp-value is in the range of 0 to 63, which can be any of the following keys: ef,
af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3,
cs4, cs5, cs6, cs7 or default.
Precedence based WRED drop type has been enabled via the wred dscp command.
When the configuration of wred is deleted, the wred dscp dscp-value will be deleted at
the same time.
When the configuration of queue af or queue wfq is deleted, the configuration of
discarding parameters will also be deleted.
IX. Configuring lower-limit, upper-limit and discard probability of WRED

precedence
Table 3-38 Configure lower-limit, upper-limit and discard probability of WRED

precedence
Operation Command
Configure lower-limit, upper-limit and wred ip-precedence precedence
discard probability of WRED low-limit low-limit high-limit high-limit
precedence [ discard-probability discard-prob ]
Delete the configuration undo wred ip-precedence precedence
Before configuring this command, make sure that precedence-based WRED has been
enabled with the wred ip-precedence command.
By default, IP preference-based WRED drop mode is enabled.
When the configuration of wred is deleted, the wred ip-precedence will also be
deleted.
When the configuration of queue af or queue wfq is deleted, the configuration of
discarding parameters will also be deleted.
X. Using/Removing traffic policing
3-25
Table 3-39 Use/remove traffic policing
Operation Command
car cir committed-information-rate [ cbs
Use traffic policing committed-burst-size ebs excess-burst-size ] [ green
action [ red action] ]
Remove traffic policing undo car
In the command, the CIR cannot be greater than CBS × 20; action is a behavior
conducted to the packets, which includes the following types:
z discard: Drops the packet
z pass: Transmits the packet.
z remark-dscp-pass new-dscp: Sets new-dscp and transmit the packet, in the
range 0 to 63.
z remark-prec-pass new-precedence: Sets new-precedence of IP and transmit the
packet, in the range 0 to 7.
The policy in which TP is used in traffic behavior on an interface can be used in the
input or output of the interface.
The policy in which TP is used in traffic behavior on an interface will cause the previous
qos car command ineffective on the interface.
If this command is frequently configured on the class of the same behavior, the last
configuration will replace the previous one.
The class configured with shaping and policing but without bandwidth can be sent if it
passes the detection of policing or shaping. However, in case of congestion, the class
will enter the default queue.
XI. Configuring/Deleting TS
Table 3-40 Configure/delete TS
Operation Command
gts cir committed-information-rate [ cbs
Configure traffic shaping committed-burst-size [ ebs excess-burst-size
[ queue-length queue-length ] ] ]
Delete traffic shaping undo gts
When behavior including TS is used in the policy, it can only be used in the egress
interface.
When the policy with behavior including TS is applied on the interface, the qos gts
command configured on the interface will become invalid.
3-26
If this command is frequently configured on the same behavior, the last configuration
will replace the previous one.
For a class configured with TS but without AF or EF, packets can be sent if they pass
the detection of TS. However, in case of congestion, these packets will enter the default
queue.
XII. Setting/removing DSCP value
Table 3-41 Set/remove DSCP value to identify matched packets
Operation Command
Set DSCP value to identify matched packets remark dscp dscp-value
Remove DSCP value setting undo remark dscp
XIII. Setting/Removing precedence value
Table 3-42 Set/remove precedence value to identify matched packets
Operation Command
Set precedence value to identify remark ip-precedence
matched packets ip-precedence-value
Remove precedence value setting undo remark ip-precedence
3.6.4 Configuring Policy
I. Defining the Policy and entering the Policy View
Policy mapping defines the traffic behavior of each class in the policy. Each traffic
behavior is composed of a group of features, such as queue dispatching, including EF,
AF, WFQ, TP, TS, WRED and label.
Table 3-43 Define the policy and enter the policy view
Operation Command
Define the policy and enter the policy view qos policy policy-name
Delete the specified policy undo qos policy policy-name
The policy name should not be that of the policies pre-defined by the system.
3-27
When creating the policy, the default has the default-class as the default class, which
associates with be behavior.
If this policy is applied on an interface, it cannot be deleted. The user must remove the
application of this policy on the interface and then delete the policy with the undo qos
policy command.
II. Specifying the Traffic Behavior for the Class in the Policy
Perform the following configuration in the policy view.
Table 3-44 Specify the traffic behavior for the class in the policy
Operation Command
Specify the traffic behavior for the class classifier tcl-name behavior
in the policy behavior-name
Remove the application of the specified
undo classifier tcl-name
class in the policy
tcl-name: Class name. It must be that of the defined class, the system-defined or
user-defined class.
behavior-name: It must be that of the defined behavior, the system-defined or
user-defined class.
3.6.5 Applying Policy
The qos apply policy command maps a policy to an interface. One policy can be
applied on multiple interfaces.
Table 3-45 Apply a policy to the interface or ATM PVC
Operation Command
qos apply policy policy-name
Apply a policy to the interface
{ inbound | outbound }
undo qos apply policy { inbound |
Delete the policy from the interface
outbound }
The application rule of the QoS policy in interface view is as follows.

z VT introduced by common physical port and MP can apply the policy configured
with various features, including remark, car, gts, queue af, queue ef, queue wfq,
wred, etc.
z The policy configured with TS (e.g. gts) and queue (e.g. queue ef, queue af, queue
wfq) features cannot be applied on the inbound interface as the input direction
policy.
3-28
z The sub-interface does not support queue (e.g. queue ef, queue af, queue wfq)
feature but support TS (e.g. gts) and TP (e.g. car). The policy configured with TS
and TP can be applied on the sub-interface.
3.6.6 Displaying and Debugging CBQ
running of the CBQ configuration, and to verify the effect of the configuration.
Table 3-46 Display and debug CBQ
Operation Command
display traffic classifier
Display class information configured on
{ system-defined | user-defined }
the firewall
[ tcl-name ]
display traffic behavior

Display configuration information of
{ system-defined | user-defined }
specified traffic behavior
[ behavior-name ]
Display configuration information of display qos policy { system-defined |
specified class of specified policy and user-defined } [ policy-name [ classifier
behavior associated with these classes. tcl-name ] ]
Display policy configuration information display qos policy interface
and operating condition of specified or [ interface-type interface-number
all interfaces. [ inbound | outbound ] ]
Display CBQ configuration information
display qos cbq interface
and operating condition of specified
interface or all interfaces.
Display debugging information of queue debugging qos cbq { ef | af | be }
3.7 RTP Priority Queuing Configuration

RTP priority queue configuration includes:
z Apply RTP priority queuing on the interface
z Configure bandwidth limitation
z Display and debug RTP priority queuing configuration
3.7.1 Applying RTP priority queuing on the interface
The following command is used to apply RTP priority queue on the interface. It has no
default configuration.
3-29
Table 3-47 Apply RTP priority queuing on the interface
Operation Command
qos rtpq start-port start-port-number
Apply RTP priority queuing on the
end-port end-port-number bandwidth
interface
bandwidth [ cbs committed-burst-size ]
Disable PQ setting from the interface undo qos rtpq
Caution:
Although you are allowed to apply RTP priority queuing on the dialer interface, but the
physical interface must be configured with default queuing and have sufficient
bandwidth to guarantee successful action.
3.7.2 Configuring Maximum Reserved Bandwidth
This command can set the max reserved bandwidth percentage of the available
bandwidth.
Table 3-48 Configure bandwidth limitation
Operation Command
Configure bandwidth limitation qos reserved-bandwidth pct percentage
Restore the default value undo qos reserved-bandwidth
The percentage argument is the percentage of the reserved bandwidth. It is in the

range of 1 to 100 and the default value is 80.
3.7.3 Displaying and Debugging RTP Priority Queuing Configuration
The following command can display the queue information of the current IP RTP Priority,
including the current RTP queue depth and number of RTP packet dropping. It can
display the RTP priority queue configuration and statistics on an interface or on all
interfaces.
3-30
Table 3-49 Display RTP priority queue configuration and statistics on an interface
Operation Command
Display configuration and statistics of display qos rtpq interface
RTP priority queue on an interface [ interface-type interface-number ]
3.8 Typical Configuration Example

3.8.1 PQ Configuration Example
As shown in the following diagram, when Server1 and PC1 send data to PC2 via the
firewall SecPath1 (Server1 sends the data of key services and PC1 sends that of
common services), congestion may occur on the interface Ethernet2/0/0 and this may
lead to packet loss because the rate of the inbound interface Ethernet0/0/0 is larger
than that of the outbound interface Ethernet2/0/0 on SecPath1. The data of
mission-critical services shall be processed first when the network congestion occurs.
II. Network diagram
SecPath2
Ethernet1/0/0
Ethernet0/0/0 PC2
SecPath1 10 M Internet
Ethernet
Ethernet2/0/0
Ethernet0/0/0 100 M
ethernet
PC1 (1.1.1.1/8)
(1.1.1.2/8)
Server1
Figure 3-6 Network diagram for PQ configuration
Configure the firewall SecPath1:

# Configure ACL to match the packets from Server1 and PC1 respectively.
3-31
# Configure the priority-group so that the packets from Server1 can enter the top queue
for cache and those from PC1 can enter the bottom queue for cache when the network
congestion happens. The maximum queue length of the top queue should be set to 50
while that of the bottom queue set to 100.
[H3C] qos pql 1 protocol ip acl 2001 queue top
[H3C] qos pql 1 protocol ip acl 2002 queue bottom
[H3C] qos pql 1 queue top queue-length 50
[H3C] qos pql 1 queue bottom queue-length 100
# Apply the priority-group 1 to the interface Ethernet2/0/0

[H3C-Ethernet2/0/0] qos pq pql 1
3.8.2 CBQ Configuration Example
In the following network diagram, the data stream sent from SecPath C reaches
SecPath D through SecPath A and SecPath B. SecPath C sends three types of data
streams according to the DSCP field in an IP packet. It is necessary to configure QoS
policy and perform AF on the stream whose DSCP field is AF11 and AF21, with a
minimum bandwidth of 5%. Perform EF on the stream whose DSCP field is EF, with a
maximum bandwidth of 30%.
EF streams are assured of certain bandwidth, delay and jitter, by use of LLQ technology.
Comparatively, AF streams are only assured of bandwidth, and no bandwidth or delay
guarantee is available for default streams (not matching any defined category).
Check the following items before initiating configuration:
z Data stream sent from SecPath C can reach SecPath D through SecPath A and
SecPath B.
z DSCP field has been configured for the packets before they enter SecPath A.
II. Network diagram
SecPathC SecPathD
Ethernet Ethernet
AF11
Ethernet 1/0/0 AF21 Ethernet1/0/0
1.1.1.1/24 1.1.1.2/24
EF
SecPathA SecPathB
Figure 3-7 Network for CBQ configuration
3-32
Perform the following configuration on SecPath A.

# Define three classes and match them respectively with the IP packets with DSCP
fields AF11, AF21 and EF.
[H3C] traffic classifier af11_class
[H3C-classifier-af11_class] if-match dscp af11
[H3C-classifier-af11_class] traffic classifier af21_class
[H3C-classifier-af21_class] if-match dscp af21
[H3C-classifier-af21_class] traffic classifier ef_class
[H3C-classifier-ef_class] if-match dscp ef
[H3C-classifier-ef_class] quit
# Define a traffic behavior and configure AF and the minimum available bandwidth.
[H3C] traffic behavior af11_behav
[H3C-behavior-af11_behav] queue af bandwidth pct 5
[H3C-behavior-af11_behav] traffic behavior af21_behav
[H3C-behavior-af21_behav] queue af bandwidth pct 5
[H3C-behavior-af21_behav] quit
# Define a traffic behavior, configure EF and allocate the minimum bandwidth (For EF
streams, bandwidth and delay guarantee are also available).
[H3C] traffic behavior ef_behav
[H3C-behavior-ef_behav] queue ef bandwidth pct 30
[H3C-behavior-ef_behav] quit
# Specify the QoS policy and allocate traffic behaviors to different classes.
[H3C] qos policy dscp
[H3C-qospolicy-dscp] classifier af11_class behavior af11_behav
[H3C-qospolicy-dscp] classifier af21_class behavior af21_behav
[H3C-qospolicy-dscp] classifier ef_class behavior ef_behav
[H3C-qospolicy-dscp] quit
# Apply the defined QoS policy to the Ethernet1/0/0 output direction of the SecPath A.
[H3C-Ethernet1/0/0] qos apply policy dscp outbound
After the configurations, once network congestion occurs, EF streams are forwarded
with high priority.
3-33
3.8.3 CQ Configuration Example
In the following diagram, firewalls SecPath A and SecPath B are connected. Use the
PC attached to SecPath A as FTP and HTTP servers and the PC attached to SecPath B
as FTP and HTTP clients. Configure routes to have traffic forwarded from SecPath A to
SecPath B.
Before the configuration, make sure to:
z Set up a connection between SecPath A and SecPath B, and an FTP connection
between the two PCs.
z On the client PC, FTP and HTTP large files from the FTP and HTTP servers at the
same time.
Customize FTP and HTTP traffic to share link bandwidth in the ratio of 1 to 2.
II. Network diagram
SecPathB
Eth0/0/0 SecPathA Eth0/0/0
Internet
FTP Server & Eth1/0/0 10.1.1.1/24 Eth1/0/0 10.1.1.2/24 PC

WWW Server
Figure 3-8 Network diagram for CQ configuration
Configure SecPath A as follows:

# Configure ACL rules for filtering FTP and HTTP packets
[H3C-acl-adv-3001] rule 0 permit tcp source-port eq ftp
[H3C-acl-adv-3001] rule 1 permit tcp source-port eq ftp-data
[H3C] quit
[H3C-acl-adv-3001] rule 0 permit tcp source-port eq www
# Configure CQ rules, customizing the FTP and HTTP traffic to share link bandwidth in
the ratio of 1 to 2.
[H3C] qos cql 1 queue 11 serving 1000
[H3C] qos cql 1 queue 12 serving 2000
[H3C] qos cql 1 protocol ip acl 3001 queue 11
[H3C] qos cql 1 protocol ip acl 3002 queue 12
3-34
# Apply the CQ rule in outbound direction of interface Serial 2/0/0.

[H3C]] interface Ethernet1/0/0
[H3C1-Ethernet1/0/0] ip address 10.1.1.1 255.255.255.0
[H3C1-Ethernet1/0/0] qos cq cql 1
[H3C1-Ethernet1/0/0] quit
3-35
H3C SecPath Series Security Products Chapter 4 DAR Configuration
Chapter 4 DAR Configuration
4.1 DAR Overview

Nowadays, Internet has become a major media for enterprises to implement various
businesses, which has stimulated service-based applications. The simple mechanism
that only checks IP headers in packets cannot meet the requirements of today’s
complicated network any longer. Therefore, the concept of service-based DAR (Deeper
Application Recognition) has been put forward.
DAR is an intelligent recognition and classification tool that is capable of checking and
recognizing the contents and dynamic protocols from layer 4 to layer 7 (e.g. BT, HTTP,
FTP, RTP) in the packets, in order to distinguish application-based protocols. This
complements the disadvantage of simple classification of packets.
The deeper recognition and classification of packets help enhance user’s control on
data streams. The combination of DAR and QoS provides a more effective method to
implement high-priority policies for critical service data, thus protecting user’s
investment.
4.2 Configuring DAR

4.2.1 Configuring Matching Rules of Protocol
To apply various policies on data streams (e.g. setting packet priority, allocating
bandwidth for data streams), first you need to classify the data streams with the DAR
function.
Table 4-1 Define or remove a protocol matching rule
Operation Command
Define a protocol matching rule if-match [ not ] protocol protocol-name
undo if-match [ not ] protocol
Remove a protocol matching rule
protocol-name
By default, no protocol matching rule is configured.
4.2.2 Configuring HTTP Matching Rules
You can use DAR to classify HTTP packets by checking their contents (for example,
URL address, hostname and MIME type).
4-1
Table 4-2 Define or remove an HTTP matching rule
Operation Command
if-match [ not ] protocol http [ url url-string |
Define an HTTP matching rule
host hostname-string | mime mime-type ]
undo if-match [ not ] protocol http [ url
Remove an HTTP matching rule url-string | host hostname-string | mime
mime-type ]
By default, no HTTP matching rule is configured.
4.2.3 Configuring RTP Matching Rules
You can use DAR to classify Real-Time Transfer Protocol (RTP) packets by checking
their payloads.
Table 4-3 Define or remove an RTP matching rule
Operation Command
if-match [ not ] protocol rtp [ payload-type
Define an RTP matching rule
{ audio | video | payload-string }* ]
undo if-match [ not ] protocol rtp
Remove an RTP matching rule [ payload-type { audio | video |
payload-string }* ]
By default, no RTP matching rule is configured.
4.2.4 Configuring Port Number of DAR Application Protocol
The system pre-defines a large number of protocols and their port numbers. The
protocols include some well-known protocols and 10 user-defined protocols, namely
user-defined01, user-defined02, …, user-defined10. You can use the following
command to define port numbers for these protocols to enhance their scalability.
Table 4-4 Configure port number of DAR application protocol
Operation Command…
dar protocol protocol-name { tcp |
Configure port number of DAR
udp } port { portvalue | range port-min
application protocol
port-max }*
4-2
Restore the port number of DAR undo dar protocol protocol-name { tcp
application protocol to the default | udp } port
By default, no port number is configured for ten user-defined protocols. Other protocols
have their default port numbers.
4.2.5 Renaming User-defined Protocols
By default, the system has created ten user-defined protocols, namely user-defined01,
user-defined02, …, user-defined10. You can rename the following command to
rename the user-defined protocols, following the steps shown in Table 4-5.
Table 4-5 Rename user-defined protocols
dar protocol-rename old-name
Rename a user-defined protocol
user-defined-name
Restore the default name of a undo dar protocol-rename
user-defined protocols user-defined-name
4.2.6 Enabling/Disabling DAR Packet Statistics
With the DAR packet statistics function, you can timely monitor the numbers of packets,
data traffic, and mean/maximum historical data rates of application protocols on
individual interfaces, thus to implement corresponding policies for data streams.
Table 4-6 Enable/disable DAR packet statistics function
Enable DAR packet statistics dar protocol-statistic [ flow-interval time ]
Disable DAR packet statistics undo dar protocol-statistic
By default, the DAR packet statistics function is disabled.
4.2.7 Configuring Maximum Number of Connections Recognizable by DAR
When large amount of data stream passes the device, a large amount of system
resources will be consumed if DAR recognizes them one by one, which affects the
normal operation of other modules.
4-3
To avoid this, you can limit the maximum number of connections that can be recognized
by DAR in order to save system resources. When the number of connections exceeds
the upper threshold, DAR stops recognizing packets of connections exceeding the
upper limit and directly marks them as unrecognizable packets.
Table 4-7 Configure the maximum number of connections recognizable by DAR
dar max-session-count count
connections recognizable by DAR
Restore to the default value undo dar max-session-count
The maximum number of connections recognizable by DAR varies with devices. Refer
to your specific device.
4.3 Displaying and Debugging DAR

After the about-mentioned configuration, you can use the display command in any
view to view DAR running status, use the debugging command in user view to debug
DAR, and use the reset command in user view to clear DAR statistics and session
information.
Table 4-8 Display and debug DAR
Display DAR module information display dar information
display dar protocol { all |
Display DAR protocol information
protocol-name }
Display user-defined protocol renaming
display dar protocol-rename
information
display dar protocol-statistic
[ protocol protocol-name | top
Display DAR packet statistics
top-number | all ] [ interface
information
[ direction { in | out } ]
debugging dar { packet | event | error |
Enable DAR debugging
all }
undo debugging dar { packet | event |
Disable DAR debugging
error | all }
reset dar protocol-statistic
Clear DAR protocol statistics information { { protocol protocol-name | interface
type number }* | all }
4-4
Clear cache information of all session
reset dar session
connections
4.4 DAR Configuration Examples

4.4.1 DAR Configuration Examples
As shown in Figure 4-1, users on the LAN segment 192.168.1.0/24 access the Internet
through firewall. To ensure normal transport of critical service data, 1 Mbps of
bandwidth needs to be provided for the data stream. The data stream is transported
based on TCP, using port 10000.
II. Network diagram
PC1
192.168.1.0/24
PC2
Internet
PC3 192.168.1.1/24 202.106.10.1/24
SecPath
PC4
PC5
Figure 4-1 Network diagram of DAR configuration
# Configure protocol user-defined01 to use TCP port 10000.

<H3C> system-view
[H3C] dar protocol user-defined01 tcp port 10000
# Create a class and set matching rules.

[H3C] traffic classifier test
[H3C-classifier-test] if-match protocol user-defined01
[H3C-classifier-test] quit
# Configure traffic behaviors.
4-5
[H3C] traffic behavior 1

[H3C-behavior-2] queue af bandwidth 1000
[H3C-behavior-2] quit
# Configure QoS policy.

[H3C] qos policy 1
[H3C-qospolicy-1] classifier test behavior 1
[H3C-qospolicy-1] quit
# Apply the policy.

[H3C] interface serial 1/0/1
[H3C-Serial1/0/1] qos apply policy 1 outbound
4-6
H3C SecPath Series Security Products Chapter 5 Congestion Avoidance
Chapter 5 Congestion Avoidance
5.1 Introduction to Congestion Avoidance

Excessive congestion can endanger network resources greatly, so some avoidance
measures must be taken. The Congestion Avoidance refers to a traffic control
mechanism that can monitor the occupancy status of network resources (such as the
queues or buffer). As congestion becomes worse, the system actively drops packets
and tries to avoid the network overload through adjusting the network traffics.
Comparing with the end-to-end traffic control, this traffic control has broader
significance, which affects more loads of application streams through firewall. Of
course, while dropping packets, the firewall may cooperate with traffic control action on
the source end, such as TCP traffic control to adjust the network's traffic to a
reasonable load level. A good combination of packet-dropping policy with traffic control
mechanism at the source end will always try to maximize the throughput and utilization
of network and minimize the packet dropping and delay.
I. Traditional packet-dropping policy
Traditional policy of dropping packets adopts the Tail-Drop method. When the amount
of packets in a queue reaches a certain maximum value, all new arrived packets will be
dropped.
This kind of dropping policy will lead to phenomenon of TCP synchronization - when
queues drop packets of several TCP connections at the same time, it will lead these
TCP connections to enter congestion avoidance and slow start status to adjust traffics
simultaneously, then reach a high peak of traffics simultaneously. This results in
saw-teeth pattern of network traffic and low network bandwidth utilization, which often
fluctuates between creak and trough.
II. RED and WRED
To avoid the phenomenon of TCP synchronization, RED (Random Early Detection) or

WRED (Weighted Random Early Detection) can be used.
In RED algorithm, it sets minimum and maximum thresholds for each queue.
z When the length of queue is less than the minimum limitation, no packet will be
dropped.
z When the length of queue exceeds the maximum limitation, all the incoming
packets will be dropped.
z When the length of queue between low and high limitations, the packet will be
dropped randomly. The method is to give a random number to every new packet,
and then compare it with packet dropping probability of the current queue. If the
5-1
random number is larger than the latter, the packet will be dropped. The longer the
length of queue, the higher the dropping probability is, but a maximum dropping
probability will remain.
Unlike RED, the random number of WRED generated is based on priority. It uses IP
precedence to determine the dropping policy thus the dropping probability of packets
with high priority will relatively decrease.
RED and WRED employ the random packet dropping policy to avoid TCP
synchronization - when packet of one TCP connection is dropped with a decreased
sending rate, other TCP connections will still keep higher sending rate. So there are
always some TCP connections, which have a higher sending rate to realize more
efficient network bandwidth utilization.
To drop packets through comparing the length of the queue with the high/low limitations
(set the absolute length of queue threshold) will treat the bursting data stream unfairly
and influence the transmission of data stream. So here we can use the average queue
length (Set the relative comparison value with queue threshold and average length).
The equation used by WRED to calculate the average queue length is as follows:
Average queue length = (Average queue length in the past x (1 – 1/2n)) + (Current
queue length x (1/2n)), where n is the weight factor, a configurable parameter.
The average length of queue reflects the changing of queue and is insensitive to
bursting change of queue length, preventing the unfair treatment for the bursting data
stream.
When WFQ is adopted, you can set weight factor, minimum threshold, maximum
threshold and drop probability for packets depending on their precedence levels. Drop
characteristics of packets thus vary with packet precedence.
The relation between WRED and Queue mechanism is shown in the following figure.
WRED drop Queue1 weight1

Queue2 weight2
Interface
…… ……
Classify QueueN-1 weightN-1 Transmit
Scheduler queue
QueueN weightN
Discarded
packets
Figure 5-1 Relation between WRED and Queue mechanism
5-2
Associating WRED with WFQ, the flow-based WRED can be realized. Because
different flow has its own queue during packet classification, the flow with small traffic
always has a short queue length, so the packet dropping probability will be small. The
flow with high traffic will have the longer queue length and will drop more packets, so
we can protect the benefits of the flow with small traffic.
5.2 WRED Configuration

WRED configuration includes:
z Enable WRED
z Set WRED exponent for mean queue depth calculation
z Set WRED parameters for each precedence
5.2.1 Enabling WRED
Table 5-1 Enable WRED
Operation Command
Enable WRED qos wred [ ip-precedence | dscp ]
Restore default undo qos wred
WRED cannot be used independently or with the queuing methods but WFQ.
By default, WRED is not used and the dropping method is tail drop.
Note:
Make sure WFQ has already been applied on the interface before enabling WRED.
5.2.2 Setting WRED to Calculate the Coefficient of Average Queue Length
Set WRED to calculate the filter coefficient of the average queue length.
5-3
Table 5-2 Set WRED exponent for mean queue depth calculation
Operation Command
Set WRED exponent for mean queue qos wred weighting-constant
depth calculation exponent
Recover the default value of exponent undo qos wred weighting-constant
The exponent is the filter coefficient to calculate the average queue length, ranging
from 1 to 16, with the default set as 9.
You must use qos wred command first on the interface before applying WRED, and
then set the parameter of WRED.
5.2.3 Setting WRED Priorities
When WFQ (Weighted Fair Queuing) is configured on an interface, you can set
minimum/maximum threshold and drop probability denominator of the each
precedence of WRED.
Table 5-3 Set WRED parameters for each precedence
Operation Command
qos wred ip-precedence ip-precedence
Set WRED parameters for each
low-limit low-limit high-limit high-limit
precedence
discard-probability discard-prob
To restore the default value of
undo qos wred ip-precedence ip-precedence
precedence
You must use qos wred command first on the interface before applying WRED, and
then set the WRED parameter.
5.2.4 Setting DSCP Parameters for WRED
When WRED is enabled on the interface, you can set DSCP precedence lower-limit,
upper-limit and drop probability denominator.
5-4
Table 5-4 Set DSCP parameters for WRED
Operation Command
qos wred dscp dscp-value low-limit
Set DSCP parameters for WRED low-limit high-limit high-limit
discard-probability discard-prob
Restore the default DSCP parameters
undo qos wred dscp dscp-value
for WRED
This command can be used only after the qos wred command has been used to
enable WRED on the interface.
5.3 Displaying WRED

running of the WRED configuration, and to verify the effect of the configuration.
Table 5-5 Display WRED configuration and statistics information on the interface
Operation Command
Display WRED configuration and display qos wred interface
statistics information on the interface [ interface-type interface-number ]
This command can show WRED configuration and statistics information on one or all
interfaces
z interface-type is interface type
z interface-number is interface number
5-5
H3C SecPath Series Security Products Chapter 6 MPLS QoS
Chapter 6 MPLS QoS
6.1 MPLS QoS Overview

The QoS solution for MPLS mainly completes the following functions:
Classify the service traffic on CE or PE according to specific needs, for example, into
three types: voice, video and data.
When PE adds a Label to the packet, it will map the IP precedence flag carried by the IP
packet to the CoS domain of the flag, and thus the class information carried by IP is
carried by the flag now.
Among the PE routers, the differentiated dispatching (such as PQ, WFQ, and CBQ) is
performed, that is, transmit the service traffic with flag on a LSP in the mode of
differentiated QoS.
Note:
To understand the contents in this chapter, you should have some background
knowledge related to MPLS. Refer to the MPLS Configuration part in this manual for the
description of MPLS basic concepts and related configurations. This chapter only
involves MPLS QoS configuration.
6.2 MPLS QoS Configuration

To configure MPLS QoS, you should first perform the related configuration of MPLS
and specify to display the route forwarding mode. For detailed configurations of MPLS,
refer to MPLS module in this manual. This chapter only describes MPLS QoS
configuration.
MPLS QoS configuration includes:
z MPLS PQ
z MPLS CQ
z MPLS CBQ
z MPLS CAR
The following describes the method of configuration for each of the above in detail.
6-1
6.2.1 Configuring MPLS PQ
Complete these two steps to configure MPLS PQ: First, configure priority list according
to MPLS EXP. Second, apply the priority list on the interface. For more information,
refer to 3.3 “Priority Queuing Configuration” in Chapter 3 “Congestion Management”.
I. Configuring Priority List according to MPLS EXP
Classify the packets according to MPLS EXP value and enable them to enter different
queues.
Table 6-1 Configure priority list according to network protocol
Operation Command
qos pql pql-index protocol mpls exp
Configure priority list according to
{ mpls-experimental-value } queue { top
network protocol
| middle | normal | bottom }
Delete corresponding classification rule undo qos pql pql-index protocol mpls
of a specified group exp mpls-experimental-value
For PQ configurations, refer to 3.1.1 “Congestion Management Policies”.
II. Applying PLQ on the interface
Apply a group of priority-lists on the interface; to use this command repeatedly will set a
new priority-list for the same interface.
Table 6-2 Apply priority-list group on the interface
Operation Command
Apply priority-list group on the interface qos pq pql pql-index
Cancel PQ setting on the interface undo qos pq
Not PQ but FIFO is employed on the interface by default.
6.2.2 Configuring MPLS CQ
Complete these two steps to configure MPLS CQ: First, configure priority list according
to MPLS EXP. Second, apply the priority list on the interface. For more information,
refer to 3.4 “Custom Queuing Configuration” in Chapter 3 “Congestion Management”.
6-2
I. Configuring custom-list according to MPLS EXP
Configure custom-list according to MPLS EXP and enable packets to enter different
queues.
Table 6-3 Configure custom-list according to network protocol
Operation Command
qos cql cql-index protocol mpls exp
Configure custom-list according to
experimental-number queue
MPLS EXP
queue-number
Delete the corresponding classification undo qos cql cql-index protocol mpls
rule exp experimental-number
For PQ configurations, refer to 3.1.1 “Congestion Management Policies”.
II. Applying custom-list on the interface
Table 6-4 Apply custom-list on the interface
Operation Command
Apply Custom-list on the interface qos cq cql cql-index
Cancel CQ setting on the interface undo qos cq
Not CQ but FIFO is employed on the interface by default.
6.2.3 Configuring MPLS CBQ
Complete these four steps to configure MPLS CBQ: First, define CBQ classes and
configure matching rule according to the MPLS EXP. Second, define traffic behaviors
and configure processing scheme of MPLS EXP domain. Third, define a QoS policy
and specify specific traffic behavior for CBQ classes. Forth, apply QoS policy on the
interface. For more information, refer to 3.6 “Class-based Queuing Configuration” in
Chapter 3 “Congestion Management”.
I. Defining/deleting exp domain rule of packets matching MPLS
MPLS QoS allows users to set MPLS EXP domain on PE to classify MPLS packets and
make them enter different queues to implement QoS. In this case, IP packets can travel
through MPLS network transparently without change.
Firstly you should define a CBQ class with a certain class name, and then enter this
class view to configure the classification regulation by EXP value in MPLS label field.
6-3
Table 6-5 Define a class and enter the class view
Operation Command
traffic classifier tcl-name [ operator
Define a class and enter the class view
{ and | or } ]
undo traffic classifier tcl-name
Delete a class
[ operator { and | or } ]
Table 6-6 Define/delete EXP domain rule of packets matching MPLS
Operation Command
if-match [ not ] mpls-exp
Define exp domain rule matching MPLS
{ mpls-experimental-value }
Delete exp domain rule matching MPLS undo if-match [ not ] mpls-exp
II. Setting the value of MPLS EXP domain
Configure the value of MPLS EXP domain and associate the class with the behavior in
policy view. Then, the packets matching the class can be MPLS EXP domain-labeled.
Table 6-7 Define a traffic behavior and enter traffic behavior view.
Operation Command
Define a traffic behavior and enter traffic
traffic behavior behavior-name
behavior view.
Delete a traffic behavior undo traffic behavior behavior-name
Table 6-8 Set the value of the MPLS EXP domain to identify a matched packet
Operation Command
Set the value of the MPLS EXP domain remark mpls-exp
to identify a matched packet mpls-experimental-value
Delete the setting of the value of the
undo remark mpls-exp
MPLS EXP domain
6-4
III. Configuring policy
Firstly you should define a policy with a certain policy name and then enter the policy
view to specify the behavior for the class defined.
Table 6-9 Define the policy and enter the policy view
Operation Command
Define the policy and enter the policy
qos policy policy-name
view
Delete the specified policy undo qos policy policy-name
Perform the following configuration in policy view.
Table 6-10 Specify the traffic behavior for the class in the policy
Operation Command
Specify the traffic behavior for the class classifier tcl-name behavior
in the policy behavior-name
Remove the application of the specified
undo classifier tcl-name
class in the policy
tcl-name: Class name. The class must have been defined by system or by user.
behavior-name: Traffic behavior name. The traffic behavior must have been defined by
system or by user.
IV. Applying policy
Table 6-11 Apply a policy to the interface
Operation Command
qos apply policy policy-name
Apply a policy to the interface
{ inbound | outbound }
Remove the application of the policy on undo qos apply policy { inbound |
the interface outbound }
6.2.4 Configuring MPLS CAR
Complete these two steps to configure MPLS CAR: First, determine supervision targets
(what kinds of packets). Second, define supervision policy. You can choose access
6-5
control list (ACL) or TP list (carl-index) in the first step or just select the any keyword to
supervise all packets. For more details, refer to Traffic Supervision Configuration.
I. Applying TP policy on the interface and labeling MPLS packets
Apply TP policy (CAR) on the interface and label MPLS packets.

Table 6-12 Apply TP policy on the interface and label MPLS packets
Operation Command
qos car inbound { any | acl acl-number
| carl carl-index } cir
Apply TP policy on the interface and committed--information-rate cbs
label MPLS packets committed-burst-size ebs
excess-burst-size green action red
action
undo qos car inbound { any | acl
Remove the application of TP policy on acl-number | carl carl-index } cir
the interface and disable labeling of committed-information-rate cbs
MPLS packets committed-burst-size ebs
excess-burst-size
action can be:

z remark-mpls-exp-continue new-mpls-exp: Configures the new MPLS EXP value,
new-mpls-exp, and continue to be processed by the next CAR policy, ranging from
0 to 7.
z remark-mpls-exp-pass new-mpls-exp: Configures the new MPLS EXP value,
new-mpls-exp, and send the packet to the destination, ranging from 0 to 7.
EXP domain of the MPLS packet can only be set on the inbound interface of the PE. If
in the input direction is IP packet, but is encapsulated as MPLS packet in the output
direction, the configured TP policy has taken effect.
When setting the EXP domain of the MPLS packet, two layers of labels shall be set and
ToS domain in the IP header shall not be modified.
6.3 MPLS QoS Configuration Example

6.3.1 QoS Configuration for Streams in the Same VPN
In the network diagram, CE1 and CE2 belong to VPN1; the bandwidth of the PE1-P link
and P-PE2 link is 10M. Define different QoS guarantee levels for the streams with
different priority levels in the VPN1.
The configuration in this example includes these two parts:
6-6
First, configure MPLS VPN on the CE1, PE1, P, PE2 and CE2.
z Run OSPF between PE1, P and PE2
z Create MP-EBGP neighbors between PE and CE
z Create MP-IBGP neighbors between PEs
Second, configure MPLS QoS on the PE1 and P.
z Configure QoS policy on the ingress interface Ethernet1/0/1 on the PE1 and set
EXP domain value according to the DSCP attribute of MPLS packets.
z On the firewall P, identify streams according to their EXP domain value and
configure stream-specific CBQs: EXP1 streams with 10% bandwidth, EXP2
streams with 20% bandwidth, EXP3 streams with 30% bandwidth and EXP4
streams with 40% bandwidth; delay guarantee is available for EXP4 streams.
Note:
Only MPLS QoS configuration is mentioned here. For MPLS VPN configuration, see
the MPLS Configuration part of this manual.
II. Network diagram
P
172.1.1.2/24 172.2.1.2/24
PE1 PE2
10.1.1.1 10M 10M
LoopBack0 30.1.1.1 LoopBack0
202.100.1.1/32 202.100.1.2/32
172.1.1.1/24
AS100 172.2.1.1/24
100M 100M
168.1.1.1/24 168.2.1.1/24
Ethernet1/0/0
Ethernet2/0/0
168.1.1.2/24
168.2.1.2/24
CE1 CE2
VPN 1
VPN 1
10.1.0.0/16 11.1.0.0/16
AS65410 AS65420
Figure 6-1 Network diagram for MPLS QoS configuration
1) Configure PE1
# Define four classes, match them respectively with the MPLS packets with DSCP
being AF11, AF21, AF31 and EF in the same VPN.
6-7
[PE1] traffic classifier af11

[PE1-classifier-af11] if-match dscp af11
[PE1-classifier-af11] traffic classifier af21
[PE1-classifier-af21] traffic classifier af31
[PE1-classifier-af31] traffic classifier efclass
[PE1-classifier-efclass] if-match dscp ef
[PE1-classifier-efclass] quit
# Define four traffic behaviors and configure EXP domain value for their MPLS packets.
[PE1] traffic behavior exp1
[PE1-behavior-exp1] remark mpls-exp 1
[PE1-behavior-exp1] traffic behavior exp2
[PE1-behavior-exp4] quit
# Define QoS policy to specify traffic behaviors to different packet types, that is to label
different EXP values for different packet types.
[PE1] qos policy REMARK
[PE1-qospolicy-REMARK] classifier af11 behavior exp1
[PE1-qospolicy-REMARK] classifier efclass behavior exp4
[PE1-qospolicy-REMARK] quit
# Apply the QoS policy to the ingress interface of PE1.

[PE1-Ethernet1/0/1] qos apply policy REMARK inbound
2) Configure P
# Define four classes, match them respectively with the MPLS packets with EXP values
being 1, 2, 3 and 4.
[P] traffic classifier EXP1
[P-classifier-EXP1] if-match mpls-exp 1
[P-classifier-EXP1] traffic classifier EXP2
6-8

[P-classifier-EXP4] quit
# Define traffic behaviors and configure different bandwidth and delay
guarantee levels for them.
[P] traffic behavior AF11
[P-behavior-AF11] queue af bandwidth pct 10
[P-behavior-AF11] traffic behavior AF21
[P-behavior-AF21] traffic behavior AF31
[P-behavior-AF31] traffic behavior EF
[P-behavior-EF] queue ef bandwidth pct 40
[P-behavior-EF] quit
# Define a QoS policy which satisfies this requirement: EXP1 streams with 10%
bandwidth, EXP2 streams with 20% bandwidth, EXP3 streams with 30% bandwidth
and EXP4 streams with 40% bandwidth; delay guarantee is available for EXP4
streams.
[P] qos policy QUEUE
[P-qospolicy-QUEUE] classifier EXP1 behavior AF11
[P-qospolicy-QUEUE] classifier EXP4 behavior EF
[P-qospolicy-QUEUE] quit
# Apply the QoS policy to the outbound direction of the Ethernet2/0/0 on P.

[P] interface ethernet 2/0/0
[P-Ethernet2/0/0] qos apply policy QUEUE outbound
After the configurations, upon traffic congestion in VPN1, the traffic receiving ratio
between DSCP fields af11, af21, af31 and ef is 1:2:3:4, among which, ef has a shorter
delay than the other three.
6-9
Appendix
Operation Manual – Appendix
Table of Contents
Appendix A Abbreviations and Acronyms .................................................................................A-1
i
H3C SecPath Series Security Products Appendix A Abbreviations and Acronyms
Appendix A Abbreviations and Acronyms
ABCDEFGHIJKLMNOPQRSTUV
ACK Acknowledgement, Acknowledgment
ADSL Asymmetric Digital Subscriber Line
AFI Address-Family Identifier
AS Access Server;
ASCII American Standard Code for Information Interchange
ASE Application Service Element
ASIC Application Specific Integrated Circuit
ASN Autonomous System Number
BSP Board Support Package
CoS Class of Service
CPU Center Processing Unit
C-RP Candidate RP
CSMA Carrier Sense Multiple Access
DF Don't fragment
DNIS Dialed Number Identification Service
DoD Direct Outward Dialing
DOS Denial of Service
DS Differentiated Services
DSLAM Digital Subscriber Line Access Multiplexer
DU DUration
DVMRP Distance Vector Multicast Routing Protocol
DVPN Dynamic VPN
EBGP External BGP
FIB Forward Information Base
FQ Fair Queue
FR-LSR Frame Relay LSR
HoVPN Hierarchy of VPN
IBGP Internal BGP
A-1
H3C SecPath Series Security Products Appendix A Abbreviations and Acronyms
ILS Internet Locator Service

L2VPN Layer Two VPN
L3VPN Layer Three VPN
LD Label Distribution
LFI Link Fragmentation and Interleaving
LIB Indicator Light Immobility Board
LLQ Low Latency Queueing
LR Location Registration
MED Multi-Exit Discriminators
NAPT Network Address and Port Translation
NLRI Network Layer Reachable Information
PAM Port to Application Mapping
PDU Packet Data Unit
PE Provider Edge
PFS Perfect Forward Secrecy
PHY Physical Sublayer & Physical Layer
RED Random Early Detection
RM Remote Manager
RPT Rendezvous Point Tree
RPU Path Process Unit
RSVP-TE RSVP-Traffic Engineering
RTPQ Real-time Transport Protocol Queue
RTSP Real Time Streaming Protocol
SBM Successful Backward setup information Message
SNPA Subnetwork Points of Attachment
SP Service Provider
SPE Synchronous Payload Envelope
ST Segment Type
TP Traffic Policing
UTC Universal Temps Coordine, Universal Coordinated Time
VOS Virtual Operating System
A-2

Firewall All PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Firewall All PDF

Uploaded by

Copyright:

Available Formats

H3C SecPath Series Security Products

Hangzhou H3C Technologies Co., Ltd.

Manual Version: T2-08162P-20070625-C-1.03

All Rights Reserved

H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot,

To obtain the latest information, please access:

H3C SecPath Series Security Products Operation Manual is organized as follows:

The manual uses the following conventions:

II. GUI conventions

Means reader be careful. Improper operation may cause

Note Means a complementary description.

Chapter 1 Security Products Overview ....................................................................................... 1-1

Chapter 2 User Configuration Interface ...................................................................................... 2-1

Chapter 3 Comware Basic Configurations ................................................................................. 3-1

Chapter 4 System Maintenance and Management..................................................................... 4-1

4.1.1 Testing Network Connection ................................................................................... 4-1

Chapter 5 Auto Detect Configuration .......................................................................................... 5-1

Chapter 6 HWPing Configurations .............................................................................................. 6-1

Chapter 7 File Management.......................................................................................................... 7-1

Chapter 8 User Interface Configuration ...................................................................................... 8-1

Chapter 9 User Management........................................................................................................ 9-1

Chapter 10 NTP Configuration ................................................................................................... 10-1

Chapter 11 SNMP Configuration................................................................................................ 11-1

11.2.5 Setting the SNMP User ....................................................................................... 11-4

Chapter 12 BIMS Configuration ................................................................................................. 12-1

Chapter 13 RMON Configuration ............................................................................................... 13-1

13.2.5 Adding/Removing a Statistics Entry .................................................................... 13-4

Chapter 14 Terminal Services .................................................................................................... 14-1

Chapter 15 Modem Configuration.............................................................................................. 15-1

15.4 Typical Modem Configuration Example......................................................................... 15-6

Chapter 16 Interface Configuration ........................................................................................... 16-1

Chapter 1 Security Products Overview

1.1 Introduction to the Security Gateway

1.2 Introduction to the Firewall

Firewall provides the following authentication functions.

Firewall currently provides several NAT modes, such as one-to-one, many-to-one,

1.3.2 Supporting Abundant VPN Services

II. GRE VPN

III. IPsec VPN

IPsec protocol suite is established by Internet Engineering Task Force (IETF). It

AH IP TCP new IP raw IP TCP

Figure 1-1 Data encapsulation formats of security protocols

Compared with MD5, SHA-1 produces longer message summary; so it is safer.

IV. Dynamic VPN

Dynamic VPN (DVPN) introduces NBMA (NonBroadcast MultiAccess) tunneling

1.4 Functionality of H3C SecPath Security Products

Chapter 2 User Configuration Interface

2.1 Setting up Configuration Environments

2.1.1 Setup through the Console Port

RS-232 serial port PC

Step 2: Run the terminal emulation program (Windows9X/Windows XP/Windows 2000

Figure 2-2 New connection

Figure 2-3 Set the connection port

Figure 2-4 Set the port communication parameters

2.1.2 Setup through Telnet

Figure 2-5 Set up a local configuration environment through the LAN

Laptop WAN line

Remote LAN Ethernet

Figure 2-6 Set up a configuration environment through the WAN

2.1.3 Setup through the AUX Port

To set up a configuration environment by connecting the AUX port on the firewall

Telephone line Modem

Figure 2-8 Set up a remote configuration environment