Huawei Usg6000v v500r001c10spc100 Administrator Guide

HUAWEI USG6000V Series
V500R001C10SPC100
Administrator Guide
Issue 01
Date 2015-12-8
HUAWEI TECHNOLOGIES CO., LTD.

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

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://e.huawei.com
Issue 01 (2015-12-8) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Administrator Guide About This Document
About This Document
Product Version
The following table lists the product versions of this document.
Product Name Product Version
USG6000V V500R001C10SPC100
Intended Audience
This document describes the features, configuration guide, and troubleshooting guide of the
FW in detail. This document focuses on how to manage the device on the Web UI, but
provides information on how to manage the device on the CLI to meet different user
preferences.
This document is intended for administrators who configure and manage FW. The
administrators must have good Ethernet knowledge and network management experience.
Encryption Algorithm Declaration

Currently, the device uses the following encryption algorithms: DES, 3DES, AES, RSA,
SHA1, SHA2, and MD5. The encryption algorithm depends on the applicable scenario. Use
the recommended encryption algorithm; otherwise, security defense requirements may be not
met.
l The encryption algorithms DES/3DES/RSA (RSA-1024 or lower)/MD5 (in digital

signature scenarios and password encryption)/SHA1 (in digital signature scenarios) have
a low security, which may bring security risks. If protocols allowed, using more secure
encryption algorithms, such as AES/RSA (RSA-2048 or higher)/SHA2/HMAC-SHA2, is
recommended.
l For the symmetrical encryption algorithm, use AES with the key of 128 bits or more.
l For the asymmetrical encryption algorithm, use RSA with the key of 2048 bits or more.
l For the hash algorithm, use SHA2 with the key of 256 bits or more.
Issue 01 (2015-12-8) Huawei Proprietary and Confidential ii

l For the HMAC algorithm, use HMAC-SHA2.

l SHA2 is irreversible encryption algorithm. The irreversible encryption algorithm must
be used for the administrator password.
Personal Data Declaration

Some personal data may be obtained or used during operation or fault location of your
purchased products, services, features. Huawei Technologies Co., Ltd. alone is unable to
collect or save the content of users' communications. It is suggested that you activate the user
data-related functions based on the applicable laws and regulations in terms of purpose and
scope of usage. You are obligated to take considerable measures to ensure that the content of
users' communications is fully protected when the content is being used and saved.
Feature Usage Declaration

To protect your legitimate interest, please carefully read the OPEN SOURCE SOFTWARE
NOTICE at the bottom of the web login page.
The IPSec VPN functions are not provided in versions shipped to Russia in accordance with
Russian laws.
The following features may involve collecting users' communication contents. Huawei
Technologies Co., Ltd. alone is unable to collect or save the content of users' communications.
It is suggested that you activate the user data-related functions based on the applicable laws
and regulations in terms of purpose and scope of usage. You are obligated to take considerable
measures to ensure that the content of users' communications is fully protected when the
content is being used and saved.
l Antivirus and IPS support attack evidence collection to analyze data packets for viruses
or intrusions. However, the attack evidence collection process may involve the collection
of user's communication content. The device provides dedicated audit administrators to
obtain collected attack evidence. Other administrators do not have such permissions.
Please keep the audit administrator account safe and clear the attack evidence collection
history in time.
l Port mirroring are vital to fault diagnosis and traffic statistics and analysis, but may
involve the collection of user's communication content. The product provides permission
control over such functions. You are advised to clear traffic records after fault diagnosis
and traffic analysis.
l Data feedback function(user experience plan ) may involve transferring or processing
users' communication contents or personal data. Huawei Technologies Co., Ltd. alone is
unable to transfer or process the content of users' communications and personal data. It is
suggested that you activate the user data-related functions based on the applicable laws
and regulations in terms of purpose and scope of usage.
l The device can transfer files through FTP, TFTP, SFTPv1, SFTPv2, and FTPS. Using
FTP, TFTP or SFTPv1 has potential security risks. SFTPv2 or FTPS is recommended.
l Telnet and STelnetv1&v2 can be used to log in to the device. Using Telnet or STelnetv1
has potential security risks. STelnetv2 is recommended.
l SNMPv1&v2c&v3 can be used to manage network elements. Using SNMPv1&v2c has
potential security risks. SNMPv3 is recommended.
Issue 01 (2015-12-8) Huawei Proprietary and Confidential iii

Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
NOTE Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to
personal injury, equipment damage, and environment
deterioration.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... } * Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
Issue 01 (2015-12-8) Huawei Proprietary and Confidential iv

[ x | y | ... ] * Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n

times.
# A line starting with the # sign is comments.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Update History
Updates between document issues are cumulative. Therefore, the latest document issue
contains all updates made in previous issues.
Updates in Issue 01 (2015-12-08) of Product Version V500R001C10SPC100

Initial commercial release.
Issue 01 (2015-12-8) Huawei Proprietary and Confidential v

Administrator Guide Contents
Contents
About This Document.....................................................................................................................ii

1 System..............................................................................................................................................1
1.1 Logging In to the Device for the First Time...................................................................................................................3
1.1.1 Logging In to the CLI Through the Console Port....................................................................................................... 3
1.1.2 Logging In to the Web UI Using HTTPS.................................................................................................................... 6
1.2 Startup Wizard................................................................................................................................................................ 8
1.3 Administrators.............................................................................................................................................................. 14
1.3.1 Overview................................................................................................................................................................... 14
1.3.1.1 Administrator Overview......................................................................................................................................... 14
1.3.1.2 Administrator Interfaces Overview........................................................................................................................ 19
1.3.2 Restrictions and Precautions......................................................................................................................................21
1.3.3 Configuring an Administrator Using the Web UI......................................................................................................21
1.3.3.1 (Optional) Creating an Administrator Role............................................................................................................ 21
1.3.3.2 Creating an Administrator Account........................................................................................................................23
1.3.3.3 Configuring Device Services..................................................................................................................................26
1.3.4 Configuring an Administrator Using the CLI............................................................................................................28
1.3.4.1 (Optional) Creating an Administrator Role............................................................................................................ 29
1.3.4.2 Creating an Administrator Account (Local Authentication).................................................................................. 29
1.3.4.3 Creating an Administrator Account (Server Authentication).................................................................................33
1.3.4.4 (Optional) Configuring the Web UI........................................................................................................................37
1.3.4.5 (Optional) Managing a CLI Administrator Interface..............................................................................................39
1.3.4.6 Maintaining CLI Administrator Interfaces and Administrator Accounts...............................................................42
1.3.5 Configuration Examples............................................................................................................................................ 43
1.3.5.1 Example for Logging in to the Web UI Using HTTPS (Default Certificate)......................................................... 43
1.3.5.2 Example for Logging In to the Web UI Using HTTPS (Specified Certificate)......................................................46
1.3.5.3 Example for Logging in to the CLI Using the Telnet (Local Authentication)....................................................... 49
1.3.5.4 Example for Logging in to the CLI Using the Telnet (RADIUS Server Authentication)...................................... 52
1.3.5.5 Example for Logging in to the CLI Using the Telnet (HWTACACS Server Authentication)...............................57
1.3.5.6 Example for Logging in to the CLI Using STelnet (Password Authentication).....................................................61
1.3.5.7 Example for Logging In to the CLI Using STelnet (RSA Authentication)............................................................ 66
1.3.5.8 Example for Configuring the FW as a Client to Log In to Other Devices............................................................. 76
1.3.6 Feature Reference...................................................................................................................................................... 78
1.3.6.1 Specifications..........................................................................................................................................................78
Issue 01 (2015-12-8) Huawei Proprietary and Confidential vi

1.3.6.2 Feature History....................................................................................................................................................... 79

1.3.7 Administrator FAQs...................................................................................................................................................79
1.4 System Clock................................................................................................................................................................ 81
1.4.1 Overview................................................................................................................................................................... 81
1.4.2 Setting the System Time Using the Web UI.............................................................................................................. 82
1.4.3 Feature History.......................................................................................................................................................... 83
1.5 License Management.................................................................................................................................................... 84
1.5.1 Overview................................................................................................................................................................... 84
1.5.1.1 Overview................................................................................................................................................................ 84
1.5.1.2 Single-Device Licenses.......................................................................................................................................... 85
1.5.1.3 Network Licenses................................................................................................................................................... 89
1.5.2 Managing Licenses Using the Web UI...................................................................................................................... 95
1.5.2.1 Single-Device Licenses.......................................................................................................................................... 95
1.5.2.2 Network Licenses................................................................................................................................................... 97
1.5.3 Managing Licenses Using the CLI.......................................................................................................................... 100
1.5.3.1 Single-Device Licenses........................................................................................................................................ 100
1.5.3.2 Network Licenses................................................................................................................................................. 102
1.5.3.3 Maintaining a License.......................................................................................................................................... 105
1.5.4 Feature History........................................................................................................................................................ 106
1.5.5 License FAQs...........................................................................................................................................................106
1.6 Update Center............................................................................................................................................................. 106
1.6.1 Overview................................................................................................................................................................. 106
1.6.2 Update Scenarios..................................................................................................................................................... 107
1.6.3 Restrictions and Precautions....................................................................................................................................110
1.6.4 Managing Signature Databases Using the Web UI..................................................................................................110
1.6.4.1 Preparation............................................................................................................................................................ 110
1.6.4.2 Scheduled Update................................................................................................................................................. 112
1.6.4.3 Immediate Update.................................................................................................................................................113
1.6.4.4 Local Update.........................................................................................................................................................115
1.6.4.5 Version Rollback...................................................................................................................................................115
1.6.5 Managing Signature Databases Using the CLI........................................................................................................116
1.6.5.1 Preparation............................................................................................................................................................ 116
1.6.5.2 Determining Signature Database Update Options................................................................................................ 118
1.6.5.3 Scheduled Update................................................................................................................................................. 119
1.6.5.4 Immediate Update.................................................................................................................................................120
1.6.5.5 Local Update.........................................................................................................................................................121
1.6.5.6 Version Rollback...................................................................................................................................................122
1.6.5.7 Version Restoration...............................................................................................................................................122
1.6.5.8 Maintaining the Update........................................................................................................................................ 123
1.6.6 Feature History........................................................................................................................................................ 124
1.7 SNMP......................................................................................................................................................................... 124
1.7.1 Overview................................................................................................................................................................. 125
Issue 01 (2015-12-8) Huawei Proprietary and Confidential vii

1.7.2 Mechanism...............................................................................................................................................................125
1.7.4 Configuring SNMP Using the Web UI.................................................................................................................... 129
1.7.5 Maintaining SNMP..................................................................................................................................................133
1.7.6 Feature History........................................................................................................................................................ 134
1.8 Across-Layer-3 MAC Identification...........................................................................................................................134
1.8.1 Overview................................................................................................................................................................. 134
1.8.2 Configuring Across-Layer-3 MAC Identification Using the Web UI..................................................................... 136
1.8.3 Configuring Across-Layer-3 MAC Identification Using the CLI........................................................................... 137
1.8.4 Feature History........................................................................................................................................................ 139
1.9 Logs............................................................................................................................................................................ 139
1.9.1 Overview................................................................................................................................................................. 139
1.9.2 Mechanism...............................................................................................................................................................142
1.9.2.1 Session Logs......................................................................................................................................................... 142
1.9.2.2 Packet Discard Logs............................................................................................................................................. 143
1.9.2.3 Service Logs......................................................................................................................................................... 144
1.9.2.4 System Logs......................................................................................................................................................... 144
1.9.4 Configuring Logs Using the Web UI.......................................................................................................................148
1.9.5 Configuring Logs Using the CLI.............................................................................................................................151
1.9.5.1 Configuring the FW to Send Session Logs to a Log Host....................................................................................151
1.9.5.2 Configuring the FW to Send Service Logs to a Log Host....................................................................................155
1.9.5.3 Enabling the FW to Send Packet Discard Logs to a Log Host.............................................................................156
1.9.5.4 Configuring the FW to Output Service Logs and System Logs to a Log Host Through the Information Center158
1.9.5.4.1 Enabling the Information Center....................................................................................................................... 158
1.9.5.4.2 Configuring the FW to Output Logs to a Log Buffer........................................................................................160
1.9.5.4.3 Outputting Logs to Log Files.............................................................................................................................161
1.9.5.4.4 Outputting Logs to the Console.........................................................................................................................161
1.9.5.4.5 Outputting Logs to a Terminal...........................................................................................................................162
1.9.5.4.6 Outputting Logs to a Log Host.......................................................................................................................... 163
1.9.5.5 Maintaining Logs..................................................................................................................................................164
1.9.6 Configuration Example............................................................................................................................................165
1.9.6.1 CLI: Example for Configuring the FW to Output Session Logs to Log Hosts.................................................... 165
1.9.6.2 CLI: Example for Configuring the FW to Output Service Logs to Log Hosts.................................................... 170
1.9.6.3 CLI: Example for Configuring the FW to Output Packet Loss Logs to Log Hosts............................................. 175
1.9.6.4 CLI: Example for Configuring the FW to Output Service Logs and System Logs to a Log Host Through the
Information Center........................................................................................................................................................... 180
1.9.7 Feature Reference.................................................................................................................................................... 183
1.9.7.1 Specifications........................................................................................................................................................183
1.9.7.2 Feature History..................................................................................................................................................... 184
1.10 Alarms...................................................................................................................................................................... 184
1.10.1 Overview............................................................................................................................................................... 184
1.10.2 Mechanism.............................................................................................................................................................184
Issue 01 (2015-12-8) Huawei Proprietary and Confidential viii

1.10.3 Configuring the FW to Output Alarms..................................................................................................................187

1.10.3.1 Enabling the Information Center........................................................................................................................ 187
1.10.3.2 Outputting Alarms to the Trap Buffer................................................................................................................ 188
1.10.3.3 Outputting Alarms to Log Files..........................................................................................................................189
1.10.3.4 Outputting Alarms to the Console...................................................................................................................... 189
1.10.3.5 Outputting Alarms to a Terminal........................................................................................................................190
1.10.3.6 Outputting Alarms to a Log Host....................................................................................................................... 191
1.10.3.7 Outputting Alarms to the SNMP Agent............................................................................................................. 191
1.10.4 Maintaining Alarms............................................................................................................................................... 192
1.10.5 Configuration Example..........................................................................................................................................193
1.10.5.1 Configuring the FW to Output Alarms to the NMS........................................................................................... 193
1.10.6 Feature Reference.................................................................................................................................................. 195
1.10.6.1 Specifications......................................................................................................................................................195
1.10.6.2 Feature History................................................................................................................................................... 196
1.11 Debugs...................................................................................................................................................................... 196
1.11.1 Overview................................................................................................................................................................196
1.11.2 Mechanism.............................................................................................................................................................197
1.11.3 Configuring the FW to Output Debugging Information........................................................................................199
1.11.3.1 Enabling the Information Center........................................................................................................................ 199
1.11.3.2 Outputting Debugging Information to Log Files................................................................................................200
1.11.3.3 Outputting Debugging Information to the Console............................................................................................ 201
1.11.3.4 Outputting Debugging Information to a Terminal.............................................................................................. 202
1.11.3.5 Outputting Debugging Information to a Log Host............................................................................................. 203
1.11.4 Maintaining Debugging Information..................................................................................................................... 204
1.11.5 Configuration Example..........................................................................................................................................204
1.11.5.1 Configuring the FW to Output Debugging Information to the Console.............................................................204
1.11.6.1 Specifications......................................................................................................................................................205
1.11.6.2 Feature History................................................................................................................................................... 206
1.12 Setting the Mail Service........................................................................................................................................... 206
1.13 Status Check and Packet Processing........................................................................................................................ 207
1.13.1 Configuring Status Check......................................................................................................................................207
1.13.1.1 Overview............................................................................................................................................................ 208
1.13.1.2 Configuring Status Check Using the Web UI.....................................................................................................209
1.13.1.3 Configuring Status Check-CLI........................................................................................................................... 210
1.13.2 Configuring the Aging Time of the Session Table................................................................................................ 211
1.13.3 Configuring a Persistent Connection..................................................................................................................... 212
1.13.4 Configuring the Hash-based Board Selection Mode............................................................................................. 213
1.13.5 Feature History...................................................................................................................................................... 214
1.14 File System............................................................................................................................................................... 214
1.14.1 Overview............................................................................................................................................................... 214
1.14.1.1 File System......................................................................................................................................................... 214
Issue 01 (2015-12-8) Huawei Proprietary and Confidential ix

1.14.1.2 File Transfer Mode............................................................................................................................................. 216

1.14.2 Managing the File System..................................................................................................................................... 217
1.14.3 Transferring Files...................................................................................................................................................221
1.14.3.1 Configuring the FW as an FTP Server............................................................................................................... 221
1.14.3.2 Configuring the FW as an FTP Client................................................................................................................ 223
1.14.3.3 Configuring the FW as an SFTP Server............................................................................................................. 224
1.14.3.4 Configuring the FW as an SFTP Client..............................................................................................................228
1.14.3.5 Configuring the FW as a TFTP Client................................................................................................................231
1.14.4 Maintaining the File System..................................................................................................................................232
1.14.4.1 Displaying Information About the FTP Server and FTP Administrator............................................................ 232
1.14.4.2 Displaying Information About the SFTP Server and SFTP Administrator........................................................232
1.14.5 Configuration Examples........................................................................................................................................ 233
1.14.5.1 Example for Back Up Files................................................................................................................................ 233
1.14.5.2 Example for Configuring the FW as an FTP Server.......................................................................................... 234
1.14.5.3 Example for Configuring the FW as an FTP Client........................................................................................... 236
1.14.5.4 Example for Configuring the FW as an SFTP Server (Password Authentication).............................................238
1.14.5.5 Example for Configuring the FW as an SFTP Server (RSA Authentication).................................................... 242
1.14.5.6 Example for Downloading Files from the TFTP Server.................................................................................... 253
1.14.6 Feature History...................................................................................................................................................... 255
1.15 Configuration File.....................................................................................................................................................255
1.15.1 Overview............................................................................................................................................................... 255
1.15.2 Managing Configuration Files Using the Web UI................................................................................................. 256
1.15.3 Feature History...................................................................................................................................................... 258
1.16 System Upgrade........................................................................................................................................................259
1.16.1 Overview............................................................................................................................................................... 259
1.16.1.1 System Software................................................................................................................................................. 259
1.16.1.2 Patch Management............................................................................................................................................. 259
1.16.2 Upgrading the System Using the Web UI .............................................................................................................261
1.16.3 Upgrading the System Using the CLI....................................................................................................................263
1.16.3.1 Upgrading System Software............................................................................................................................... 263
1.16.3.2 Patch Management............................................................................................................................................. 264
1.16.4 Feature History...................................................................................................................................................... 266
1.17 System Restart.......................................................................................................................................................... 266
1.17.1 Overview............................................................................................................................................................... 266
1.17.2 Upgrading the System Using the Web UI..............................................................................................................266
1.17.3 Feature History...................................................................................................................................................... 267
1.18 User Experience Plan................................................................................................................................................267
1.19 NQA..........................................................................................................................................................................269
1.19.1 Overview............................................................................................................................................................... 269
1.19.1.1 NQA....................................................................................................................................................................269
1.19.1.2 NQA Server and NQA Client............................................................................................................................. 270
1.19.2 Mechanism.............................................................................................................................................................271
Issue 01 (2015-12-8) Huawei Proprietary and Confidential x

1.19.3 Setting ICMP Test Parameters...............................................................................................................................275

1.19.4 Setting DHCP Test Parameters..............................................................................................................................277
1.19.5 Setting the FTP Download Test Parameters.......................................................................................................... 278
1.19.6 Setting the FTP Upload Test Parameters............................................................................................................... 280
1.19.7 Setting HTTP Test Parameters...............................................................................................................................282
1.19.8 Setting the DNS Test Parameters...........................................................................................................................284
1.19.9 Setting Traceroute Test Parameters....................................................................................................................... 285
1.19.10 Configuring the UDP Test................................................................................................................................... 287
1.19.10.1 Configuring the UDP Server............................................................................................................................ 287
1.19.10.2 Configuring the UDP Client............................................................................................................................. 287
1.19.11 Configuring the Jitter Test................................................................................................................................... 289
1.19.11.1 Configuring the NQA Server for the Jitter Test................................................................................................289
1.19.11.2 Configuring the NQA Client for the Jitter Test................................................................................................ 290
1.19.12 Setting General NQA Test Parameters................................................................................................................ 292
1.19.13 Setting Round-Trip Delay Thresholds.................................................................................................................293
1.19.14 Configuring the Trap Function............................................................................................................................ 294
1.19.14.1 Sending Trap Messages When Tests Failed..................................................................................................... 294
1.19.14.2 Sending Trap Messages When Probes Failed...................................................................................................294
1.19.14.3 Sending Trap Messages When Probes Are Complete...................................................................................... 295
1.19.15 Maintaining NQA................................................................................................................................................ 295
1.19.15.1 Restarting an NQA Test Instance..................................................................................................................... 295
1.19.15.2 Clearing NQA Statistics................................................................................................................................... 296
1.19.15.3 Debugging NQA...............................................................................................................................................296
1.19.16 Configuration Examples...................................................................................................................................... 297
1.19.16.1 Example for Performing an ICMP Test............................................................................................................ 297
1.19.16.2 Example for Performing a DHCP Test............................................................................................................. 298
1.19.16.3 Example for Performing an FTP Download Test............................................................................................. 299
1.19.16.4 Example for Performing an FTP Upload Test.................................................................................................. 301
1.19.16.5 Example for Performing an HTTP Test............................................................................................................303
1.19.16.6 Example for Performing a DNS Test................................................................................................................304
1.19.16.7 Example for Performing a Traceroute Test.......................................................................................................306
1.19.16.8 Example for Performing a UDP Test................................................................................................................307
1.19.17 Feature Reference................................................................................................................................................ 309
1.19.17.1 Feature History................................................................................................................................................. 309
1.19.17.2 Specifications....................................................................................................................................................309
1.19.17.3 Standards and Protocols....................................................................................................................................310
2 High Availability.......................................................................................................................312
2.1 Hot Standby................................................................................................................................................................ 313
2.1.1 Overview................................................................................................................................................................. 313
2.1.2 Application Scenarios..............................................................................................................................................315
2.1.2.1 In-line Deployment of Hot Standby..................................................................................................................... 315
2.1.2.2 Transparent Deployment of Hot Standby............................................................................................................. 318
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xi

2.1.2.3 Off-line Deployment of Hot Standby................................................................................................................... 319

2.1.3 Mechanism...............................................................................................................................................................321
2.1.3.1 VRRP....................................................................................................................................................................321
2.1.3.2 VGMP...................................................................................................................................................................324
2.1.3.3 HRP...................................................................................................................................................................... 332
2.1.4 Analysis of Typical Hot Standby Networks............................................................................................................ 338
2.1.4.1 In-line Deployment with Upstream and Downstream Switches...........................................................................338
2.1.4.2 In-line Deployment with Upstream and Downstream Routers.............................................................................342
2.1.4.3 Transparent Deployment with Upstream and Downstream Switches.................................................................. 344
2.1.4.4 Transparent Deployment with Routers................................................................................................................. 346
2.1.4.5 Off-line Deployment.............................................................................................................................................347
2.1.6 Configuring Hot Standby Using the Web UI...........................................................................................................354
2.1.7 Configuring Hot Standby Using the CLI.................................................................................................................357
2.1.7.1 Configuration Flow...............................................................................................................................................358
2.1.7.2 Configuring VGMP Groups................................................................................................................................. 358
2.1.7.2.1 Configuring VRRP Groups............................................................................................................................... 359
2.1.7.2.2 Configuring Interface Monitoring..................................................................................................................... 362
2.1.7.2.3 Configuring VLAN Monitoring........................................................................................................................ 364
2.1.7.2.4 Configuring IP-Link Monitoring....................................................................................................................... 367
2.1.7.2.5 Configuring BFD Monitoring............................................................................................................................367
2.1.7.3 Configuring Heartbeat Interfaces......................................................................................................................... 368
2.1.7.4 Enabling Hot Standby...........................................................................................................................................371
2.1.7.5 Configuring the Backup Mode............................................................................................................................. 373
2.1.7.6 Configuring Mirroring Mode................................................................................................................................377
2.1.7.7 Binding NAT to VRRP......................................................................................................................................... 378
2.1.7.7.1 Binding NAT Address Pools to VRRP Groups................................................................................................. 378
2.1.7.7.2 Binding NAT Server to VRRP...........................................................................................................................382
2.1.7.8 Maintaining Hot Standby......................................................................................................................................385
2.1.8 Configuration Examples.......................................................................................................................................... 388
2.1.8.1 Web: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-2 Upstream and
Downstream Devices........................................................................................................................................................ 389
2.1.8.2 Web: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-2 Upstream and
2.1.8.3 Web: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and
2.1.8.4 Web: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and
2.1.8.5 Web: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and Layer-2
2.1.8.6 Web: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and Layer-2
2.1.8.7 Web: Load Balancing Networking in Which the FWs Are Connected Transparently to Layer-3 Upstream and
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xii

2.1.8.8 Web: Active/Standby Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Static Routing
Mode)................................................................................................................................................................................430
2.1.8.9 Web: Load Balancing Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Static
Routing Mode)..................................................................................................................................................................437
2.1.8.10 Web: Active/Standby Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Dynamic
Routing Mode)..................................................................................................................................................................446
2.1.8.11 Web: Load Balancing Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Dynamic
Routing Mode)..................................................................................................................................................................457
2.1.8.12 CLI: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-2 Upstream and
2.1.8.13 CLI: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-2 Upstream and
2.1.8.14 CLI: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and
2.1.8.15 CLI: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and
2.1.8.16 CLI: Active/Standby Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and Layer-2
2.1.8.17 CLI: Load Balancing Networking in Which the FWs Are Connected In-line to Layer-3 Upstream and Layer-2
2.1.8.18 CLI: Load Balancing Networking in Which the FWs Are Connected Transparently to Layer-3 Upstream and
2.1.8.19 CLI: Active/Standby Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Static
Routing Mode)..................................................................................................................................................................505
2.1.8.20 CLI: Load Balancing Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Static
Routing Mode)..................................................................................................................................................................513
2.1.8.21 CLI: Active/Standby Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Dynamic
Routing Mode)..................................................................................................................................................................523
2.1.8.22 CLI: Load Balancing Networking in Which the FWs Are Connected Off-line to Layer-3 Devices (Dynamic
Routing Mode)..................................................................................................................................................................533
2.1.9.1 Specifications........................................................................................................................................................543
2.1.9.2 Feature History..................................................................................................................................................... 546
2.1.9.3 Standards and Protocols........................................................................................................................................546
2.1.10 Hot Standby FAQ.................................................................................................................................................. 546
2.1.10.1 FAQs on Failures................................................................................................................................................ 547
2.1.10.2 FAQs on Configurations..................................................................................................................................... 549
2.1.10.3 FAQs on Mechanism.......................................................................................................................................... 550
2.1.10.4 FAQs on Specifications...................................................................................................................................... 552
2.1.10.5 FAQs on Miscellaneous Issues........................................................................................................................... 553
2.2 IP-Link........................................................................................................................................................................553
2.2.1 Overview................................................................................................................................................................. 553
2.2.2.1 IP-Link in the Hot Standby Environment.............................................................................................................554
2.2.2.2 IP-Link in the Static Routing Environment.......................................................................................................... 554
2.2.2.3 IP-Link in the Policy-based Routing Environment.............................................................................................. 555
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xiii

2.2.2.4 IP-Link in the DHCP Environment...................................................................................................................... 555

2.2.3 Configuring IP-Link Using the Web UI.................................................................................................................. 556
2.2.4 Configuring IP-Link Using the CLI........................................................................................................................ 556
2.2.5.1 CLI: Example for Configuring the Interworking Between IP-Link and Hot Standby......................................... 558
2.2.5.2 CLI: Example for Configuring the Interworking Between Static Routes and IP-Link........................................ 563
2.2.5.3 CLI: Example for Configuring the Interworking Between PBR and IP-Link......................................................566
2.2.5.4 CLI: Example for Configuring the Interworking Between DHCP and IP-Link...................................................572
2.2.6.1 Specifications........................................................................................................................................................575
2.2.6.2 Feature History..................................................................................................................................................... 576
2.3 Link-Group................................................................................................................................................................. 576
2.3.1 Overview................................................................................................................................................................. 576
2.3.2 Configuring Link-Group Using the Web UI............................................................................................................576
2.3.3 Configuring Link-Group Using the CLI..................................................................................................................577
2.3.4.1 Specifications........................................................................................................................................................578
2.3.4.2 Feature History..................................................................................................................................................... 578
2.4 BFD............................................................................................................................................................................ 579
2.4.1 Overview................................................................................................................................................................. 579
2.4.2.1 Interworking Between BFD and Hot Standby......................................................................................................579
2.4.2.2 Interworking Between BFD and Static Routes.....................................................................................................580
2.4.2.3 Interworking Between BFD and OSPF................................................................................................................ 582
2.4.2.4 Interworking Between BFD and BGP.................................................................................................................. 584
2.4.2.5 Interworking Between BFD and IS-IS................................................................................................................. 584
2.4.2.6 Interworking Between BFD and PBR.................................................................................................................. 585
2.4.2.7 Interworking Between BFD and DHCP............................................................................................................... 586
2.4.3 Mechanism...............................................................................................................................................................587
2.4.3.1 BFD Packet...........................................................................................................................................................587
2.4.3.2 BFD Mechanism...................................................................................................................................................591
2.4.3.3 BFD Session Management................................................................................................................................... 594
2.4.4 Configuring BFD Using the Web UI....................................................................................................................... 596
2.4.5 Configuring BFD Using the CLI............................................................................................................................. 598
2.4.5.1 Configuring Global BFD Functions..................................................................................................................... 598
2.4.5.2 Configuring Static BFD........................................................................................................................................599
2.4.5.2.1 Creating a Static BFD Session...........................................................................................................................600
2.4.5.2.2 (Optional) Adjusting Session Detection Parameters......................................................................................... 602
2.4.5.2.3 (Optional) Configuring Auto-negotiation of Static Discriminators.................................................................. 604
2.4.5.2.4 (Optional) Configuring Session Descriptions....................................................................................................605
2.4.5.2.5 (Optional) Configuring the Priority for Sending BFD Packets......................................................................... 605
2.4.5.2.6 (Optional) Configuring the BFD WTR Time.................................................................................................... 606
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xiv

2.4.5.3 Configuring Interworking Between BFD and Other Functions........................................................................... 606

2.4.5.3.1 Configuring Interworking Between BFD and Hot Standby.............................................................................. 607
2.4.5.3.2 Configuring Interworking Between BFD and Static Routes............................................................................. 607
2.4.5.3.3 Configuring BFD-PBR Interworking................................................................................................................ 608
2.4.5.3.4 Configuring BFD-DHCP Interworking............................................................................................................. 608
2.4.5.3.5 Configuring BFD-RIP Interworking................................................................................................................. 609
2.4.5.3.6 Configuring BFD-OSPF Interworking.............................................................................................................. 611
2.4.5.3.7 Configuring BFD-BGP Interworking................................................................................................................ 613
2.4.5.3.8 Configuring BFD-BGP4+ Interworking............................................................................................................615
2.4.5.3.9 Configuring BFD-IS-IS Interworking............................................................................................................... 617
2.4.5.4 Maintaining BFD.................................................................................................................................................. 619
2.4.6.1 CLI: Example for Configuring Interworking Between BFD and Hot Standby....................................................622
2.4.6.2 CLI: Example for Configuring Interworking Between BFD and Static Routes...................................................626
2.4.6.3 CLI: Example for Configuring BFD-OSPF Interworking....................................................................................630
2.4.6.4 CLI: Example for Configuring BFD-PBR Interworking......................................................................................637
2.4.6.5 CLI: Example for Configuring BFD-DHCP Interworking...................................................................................644
2.4.7.1 Specifications........................................................................................................................................................648
2.4.7.2 Feature History..................................................................................................................................................... 649
2.4.7.3 Standards and Protocols........................................................................................................................................649
3 Virtual System............................................................................................................................650
3.1 Overview.................................................................................................................................................................... 651
3.2 Application Scenario.................................................................................................................................................. 651
3.3 Mechanism..................................................................................................................................................................653
3.3.1 Virtual System and Administrator........................................................................................................................... 653
3.3.2 Virtual System Resource Allocation........................................................................................................................655
3.3.3 Virtual System Traffic Sorting.................................................................................................................................657
3.3.4 Communication Between Virtual Systems.............................................................................................................. 659
3.4 Restrictions and Precautions.......................................................................................................................................664
3.5 Deploying a Virtual System Using the Web UI..........................................................................................................666
3.5.1 Enabling the Virtual System Function.....................................................................................................................666
3.5.2 Configuring a Resource Class ................................................................................................................................ 666
3.5.3 Creating a Virtual System and Allocating Resources .............................................................................................668
3.5.4 Enabling Communication Between Virtual Systems ..............................................................................................669
3.5.4.1 Enabling Communication Between a Virtual System and the Public System .....................................................669
3.5.4.2 Enabling Communication Between Virtual Systems ...........................................................................................672
3.5.5 Creating a Virtual System Administrator................................................................................................................ 675
3.6 Deploying a Virtual System Using the CLI................................................................................................................677
3.6.1 Enabling the Virtual System Function.....................................................................................................................678
3.6.2 Configuring a Resource Class................................................................................................................................. 678
3.6.3 Creating a Virtual System and Allocating Resources..............................................................................................679
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xv

3.6.4 Enabling Communication Between Virtual Systems ..............................................................................................681

3.6.4.1 Enabling Communication Between a Virtual System and the Public System......................................................681
3.6.4.2 Enabling Communication Between Virtual Systems............................................................................................683
3.6.5 Creating a Virtual System Administrator................................................................................................................ 686
3.6.6 Managing Virtual System Logs............................................................................................................................... 689
3.6.7 Maintaining a Virtual System.................................................................................................................................. 689
3.7 Configuring Virtual System Services......................................................................................................................... 690
3.8 Configuration Examples............................................................................................................................................. 693
3.8.1 CLI Example for Configuring Virtual Systems to Isolate Enterprise Departments (Layer-3 Access, Virtual Systems
Having Independent WAN Interfaces)..............................................................................................................................693
3.8.2 CLI Example for Configuring Virtual Systems to Isolate Enterprise Departments (Layer-3 Access, Virtual Systems
Sharing the WAN Interface of the Public System)........................................................................................................... 699
3.8.3 CLI Example for Configuring Virtual Systems to Isolate Enterprise Departments (Layer-2 Access)....................709
3.8.4 CLI Example for Configuring Virtual Systems on a Cloud Computing Gateway.................................................. 716
3.8.5 CLI Example for Configuring the Communication Between Virtual Systems....................................................... 724
3.9 Feature Reference....................................................................................................................................................... 731
3.9.1 Function Availability for Virtual Systems............................................................................................................... 731
3.9.2 Specifications...........................................................................................................................................................734
3.9.3 Feature History........................................................................................................................................................ 736
3.10 Virtual System FAQ..................................................................................................................................................736
4 Networks..................................................................................................................................... 739
4.1 Interfaces.................................................................................................................................................................... 741
4.1.1 Overview................................................................................................................................................................. 741
4.1.1.1 Supported Interface Types.................................................................................................................................... 741
4.1.1.2 IP Addresses......................................................................................................................................................... 745
4.1.2 Interface Configuration Using the Web UI..............................................................................................................753
4.1.2.1 Configuring a Layer 3 Ethernet Interface.............................................................................................................753
4.1.2.3 Configuring a Layer 3 Ethernet Subinterface.......................................................................................................763
4.1.2.5 Configuring a VLAN Interface.............................................................................................................................772
4.1.2.6 Configuring an Eth-Trunk Interface..................................................................................................................... 780
4.1.2.7 Configuring a Loopback Interface........................................................................................................................789
4.1.2.8 Configuring the Tunnel Interface......................................................................................................................... 790
4.1.3 Interface Configuration Using the CLI....................................................................................................................794
4.1.3.5 Configuring a VLAN Interface.............................................................................................................................803
4.1.3.6 Configuring an Eth-Trunk Interface..................................................................................................................... 806
4.1.3.6.1 Configuration Procedure....................................................................................................................................806
4.1.3.6.2 Configuring a Layer 3 Eth-Trunk Interface.......................................................................................................807
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xvi

4.1.3.6.3 Configuring a Layer 2 Eth-Trunk Interface.......................................................................................................810

4.1.3.6.4 Configuring a Eth-Trunk Sub-interface.............................................................................................................812
4.1.3.6.5 Adding Physical Interfaces to an Eth-Trunk Interface...................................................................................... 814
4.1.3.6.6 Configuring the Lower Limit of Up Member Interface for an Eth-Trunk Interface......................................... 815
4.1.3.6.7 Configuring a Load Balancing Mode for an Eth-Trunk Interface..................................................................... 816
4.1.3.7 Configuring a Loopback Interface........................................................................................................................817
4.1.3.8 Configuring a Null Interface.................................................................................................................................818
4.1.3.9 Configuring a Tunnel Interface.............................................................................................................................819
4.1.3.10 Configuring a Virtual Template Interface...........................................................................................................820
4.1.3.11 Maintaining Interfaces........................................................................................................................................ 822
4.1.3.11.1 Displaying Interface Information.....................................................................................................................822
4.1.3.11.2 Clearing Interface Statistics............................................................................................................................. 822
4.1.3.11.3 Debugging an Interface....................................................................................................................................823
4.1.3.11.4 Configuring the Loopback Function on Interfaces.......................................................................................... 824
4.1.4.1 CLI: Example for Accessing the Internet Using a Static IPv4 Address............................................................... 824
4.1.4.2 CLI: Example for Accessing the Internet Using DHCP.......................................................................................828
4.1.4.3 CLI: Example for Accessing the Internet Using IPv4 PPPoE..............................................................................831
4.1.4.4 CLI: Example for Configuring Static IPv6 Addresses for Devices to Communicate.......................................... 835
4.1.4.5 CLI: Example for Configuring VLAN Interfaces to Allow VLANs to Communicate........................................ 838
4.1.4.6 CLI: Example for Configuring VLANs on Ethernet Subinterfaces to Allow the VLANs to Communicate....... 841
4.1.4.7 CLI Example for Configuring VLAN Trunk Interfaces to Enable VLANs on Different Network Segments to
Communicate....................................................................................................................................................................844
4.1.4.8 CLI Example for Configuring Link Aggregation in Manual Mode..................................................................... 846
4.1.5 Troubleshooting for Interface Faults....................................................................................................................... 849
4.1.5.1 Physical Status of an Electronic Ethernet Interface Cannot Be Up......................................................................849
4.1.5.2 Physical Status of an Optical Interface Cannot Be Up......................................................................................... 853
4.1.6.1 Feature History..................................................................................................................................................... 859
4.2 Interface Pairs............................................................................................................................................................. 859
4.2.1 Overview................................................................................................................................................................. 859
4.2.2 Configuring an Interface Pair Using the Web UI.................................................................................................... 859
4.2.3 Configuring Interface Pairs Using CLI................................................................................................................... 860
4.2.4 Feature References.................................................................................................................................................. 861
4.2.4.1 Specifications........................................................................................................................................................861
4.2.4.2 Feature History..................................................................................................................................................... 862
4.3 Security Zones............................................................................................................................................................ 862
4.3.1 Overview................................................................................................................................................................. 862
4.3.2 Mechanism...............................................................................................................................................................862
4.3.3 Zone Configuration Using the Web UI....................................................................................................................865
4.3.4 Zone Configuration Using the CLI..........................................................................................................................866
4.3.5 Feature References.................................................................................................................................................. 868
4.3.5.1 Specifications........................................................................................................................................................868
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xvii

4.3.5.2 Feature History..................................................................................................................................................... 868

4.4 PPP..............................................................................................................................................................................869
4.4.1 Overview................................................................................................................................................................. 869
4.4.2 Applications.............................................................................................................................................................869
4.4.3 Mechanism...............................................................................................................................................................870
4.4.4 Configuring PPP...................................................................................................................................................... 875
4.4.4.1 Encapsulating the Interface with PPP...................................................................................................................875
4.4.4.2 Configuring PAP Authentication.......................................................................................................................... 876
4.4.4.3 Configuring CHAP Authentication...................................................................................................................... 877
4.4.4.4 Configuring Optional Functions of PPP............................................................................................................... 878
4.4.4.4.1 Configuring the Negotiation DNS Server Address........................................................................................... 878
4.4.4.4.2 Configuring the Negotiation WINS Server Address......................................................................................... 879
4.4.4.4.3 Configuring the Negotiation Timeout Period.................................................................................................... 879
4.4.4.4.4 Configuring the Negotiation Polling Interval.................................................................................................... 880
4.4.5 Maintaining PPP...................................................................................................................................................... 880
4.4.6.1 Example for Configuring PAP Authentication..................................................................................................... 882
4.4.6.2 Example for Configuring Bidirectional PAP Authentication............................................................................... 885
4.4.6.3 Example for Configuring Unidirectional CHAP Authentication......................................................................... 889
4.4.6.4 Example for Configuring Bidirectional CHAP Authentication........................................................................... 893
4.4.7.1 Specifications........................................................................................................................................................897
4.4.7.2 Feature History..................................................................................................................................................... 898
4.4.7.3 Reference Standards and Protocols...................................................................................................................... 898
4.5 PPPoE......................................................................................................................................................................... 898
4.5.1 Overview................................................................................................................................................................. 898
4.5.2 Mechanism...............................................................................................................................................................899
4.5.3 Configuring PPPoE..................................................................................................................................................900
4.5.3.1 Configuring the IPv4 PPPoE Server.....................................................................................................................900
4.5.3.2 Configuring an IPv4 PPPoE Client...................................................................................................................... 902
4.5.3.3 Configuring an IPv6 PPPoE Client...................................................................................................................... 904
4.5.4 Maintaining PPPoE..................................................................................................................................................905
4.5.4.1 Displaying the PPPoE Configuration................................................................................................................... 905
4.5.4.2 Clearing Statistics About PPPoE Sessions........................................................................................................... 905
4.5.4.3 Resetting a PPPoE Session................................................................................................................................... 906
4.5.5.1 Example for Configuring IPv4 PPPoE................................................................................................................. 906
4.5.5.2 Example for Configuring an IPv6 PPPoE Client (Stateless Address Autoconfiguration)................................... 911
4.5.6.1 Specifications........................................................................................................................................................913
4.5.6.2 Featurea History................................................................................................................................................... 914
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xviii

4.6 DNS............................................................................................................................................................................ 914

4.6.1 Overview................................................................................................................................................................. 914
4.6.2 Application Scenario............................................................................................................................................... 915
4.6.2.1 Typical Application of the Device as a DNS Client............................................................................................. 915
4.6.2.2 Typical Application of the Device as a DNS Proxy............................................................................................. 915
4.6.2.3 The Device Serving as a DDNS Client to Realize Updates by the DDNS Server............................................... 916
4.6.2.4 DNS Transparent Proxy........................................................................................................................................917
4.6.3 Mechanism...............................................................................................................................................................918
4.6.3.1 DNS Client-Server Exchange............................................................................................................................... 918
4.6.3.2 Working Principle of DNS Proxy/Relay...............................................................................................................921
4.6.3.3 DDNS Client-Server Exchange............................................................................................................................ 923
4.6.3.4 DNS Transparent Proxy........................................................................................................................................924
4.6.4 DNS Configuration Using the Web UI.................................................................................................................... 927
4.6.4.1 DNS...................................................................................................................................................................... 927
4.6.4.2 Configuring DNS Transparent Proxy................................................................................................................... 928
4.6.4.3 Configuring DDNS...............................................................................................................................................930
4.6.5 Configuring DNS Using the CLI.............................................................................................................................931
4.6.5.1 Configuring the Device as a DNS Client..............................................................................................................932
4.6.5.1.1 Configuring IPv4 Static Domain Name Resolution.......................................................................................... 932
4.6.5.1.2 Configuring IPv4 Dynamic Domain Name Resolution.....................................................................................932
4.6.5.2 Configuring the Device as a DNS Proxy/Relay................................................................................................... 934
4.6.5.2.1 Configuring the Device as an IPv4 DNS Proxy/Relay......................................................................................934
4.6.5.3 Configuring the Device as a DDNS Client...........................................................................................................936
4.6.5.3.1 Configuring a DDNS Policy..............................................................................................................................936
4.6.5.3.2 Applying a DDNS Policy.................................................................................................................................. 939
4.6.5.3.3 Manually Updating DDNS................................................................................................................................ 940
4.6.5.4 Configuring DNS Transparent Proxy................................................................................................................... 940
4.6.5.5 Maintaining DNS..................................................................................................................................................942
4.6.6 Configuration Examples ........................................................................................................................................ 944
4.6.6.1 CLI: Example for Configuring the Device as a DNS Client................................................................................ 944
4.6.6.2 CLI: Example for Configuring the Device as a DNS Proxy................................................................................ 947
4.6.6.3 CLI: Example for Configuring the Device as a DDNS Client (Using the Update Mode Defined by the RFC2136)
.......................................................................................................................................................................................... 948
4.6.6.4 CLI Example for Configuring the Device as a DDNS Client (Using the Update Mode Implemented Through the
DDNS Server)...................................................................................................................................................................951
4.6.6.5 CLI: Example for Configuring DNS Transparent Proxy......................................................................................954
4.6.7 Troubleshooting for DNS........................................................................................................................................ 959
4.6.7.1 Dynamic Domain Name Resolution Cannot Be Implemented on a DNS Client................................................. 959
4.6.8.1 Specifications........................................................................................................................................................959
4.6.8.2 Feature History..................................................................................................................................................... 960
4.7 DHCP..........................................................................................................................................................................961
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xix

4.7.1 Introduction............................................................................................................................................................. 961

4.7.2 Application Scenario............................................................................................................................................... 961
4.7.2.1 The Device Serving as a DHCP Server................................................................................................................ 962
4.7.2.2 The Device Serving as a DHCP Relay................................................................................................................. 963
4.7.2.3 The Device Serving as a DHCP Client or BOOTP Client................................................................................... 964
4.7.3 Mechanism...............................................................................................................................................................965
4.7.3.1 Introduction to DHCP Packets............................................................................................................................. 965
4.7.3.2 Typical Networking of DHCP.............................................................................................................................. 971
4.7.3.3 How a DHCP Server Allocates Network Parameters to New DHCP Clients...................................................... 972
4.7.3.4 How a DHCP Client Reuses an IP Address......................................................................................................... 977
4.7.3.5 How a DHCP Client Renews the IP Address Lease.............................................................................................978
4.7.3.6 Principles of IP Address Assignment................................................................................................................... 981
4.7.4 Configuring DHCP Using the Web UI.................................................................................................................... 982
4.7.4.1 Configuring the Device as a DHCP Server.......................................................................................................... 982
4.7.4.2 Configuring the Device as a DHCP Relay........................................................................................................... 985
4.7.4.3 Monitoring DHCP................................................................................................................................................ 987
4.7.5 DHCP Configuration Using the CLI....................................................................................................................... 988
4.7.5.1 Configuring the Device as a DHCP Server.......................................................................................................... 988
4.7.5.1.1 Planning Data.................................................................................................................................................... 988
4.7.5.1.2 Enabling DHCP................................................................................................................................................. 989
4.7.5.1.3 Configuring an Address Pool............................................................................................................................ 990
4.7.5.1.4 Configuring the Range of IP Addresses That Cannot Be Automatically Allocated to Clients from an Address
Pool................................................................................................................................................................................... 994
4.7.5.1.5 Configuring a DHCP Server to Allocate Fixed IP Addresses to Specified Clients.......................................... 995
4.7.5.1.6 Configuring the Address Lease Time................................................................................................................ 996
4.7.5.1.7 Configuring IP Address Conflict Detection Before a DHCP Server Allocates IP Addresses...........................998
4.7.5.1.8 Configuring Automatic Saving of IP Address Allocation Information.............................................................999
4.7.5.1.9 Configuring the Gateway Address for Clients.................................................................................................. 999
4.7.5.1.10 Configuring DNS and the NetBIOS Service on the DHCP Clients.............................................................. 1001
4.7.5.1.11 Configuring the Configuration File for a DHCP Client................................................................................ 1004
4.7.5.1.12 Configuring User-defined Options for Clients.............................................................................................. 1005
4.7.5.2 Configuring the Device as a DHCP Relay..........................................................................................................1011
4.7.5.3 Configuring the Device as a DHCP Client......................................................................................................... 1013
4.7.5.3.1 Configuring an Expected Lease for a DHCP Client........................................................................................1013
4.7.5.3.2 Enabling the DHCP Client Function............................................................................................................... 1014
4.7.5.4 Configuring a BOOTP Client............................................................................................................................. 1014
4.7.5.5 Maintaining DHCP............................................................................................................................................. 1015
4.7.5.5.1 Viewing DHCP Configuration Informatin and Statistics About DHCP Messages......................................... 1015
4.7.5.5.2 Clearing Statistics About DHCP Messages.....................................................................................................1016
4.7.5.5.3 Resetting a DHCP Address Pool..................................................................................................................... 1016
4.7.5.5.4 Locking a DHCP Address Pool....................................................................................................................... 1018
4.7.6.1 CLI Example for Configuring a Device as the DHCP Server (Based on the Interface Address Pool).............. 1018
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xx

4.7.6.2 CLI Example for Configuring the Device as a DHCP Server (Using the Global Address Pool-based Layer-3
Ethernet Interface).......................................................................................................................................................... 1022
4.7.6.3 CLI Example for Configuring a Global Address Pool-based DHCP Server (Using Sub-interfaces)................ 1028
4.7.6.4 CLI Example for Configuring the Device as a DHCP Relay............................................................................. 1034
4.7.6.5 CLI Example for Configuring the Device as an DHCP Client...........................................................................1038
4.7.7.1 Specifications......................................................................................................................................................1040
4.7.7.2 Feature History................................................................................................................................................... 1042
4.7.7.3 Reference Standards and Protocols.................................................................................................................... 1042
4.8 DHCP Snooping....................................................................................................................................................... 1043
4.8.1 Overview............................................................................................................................................................... 1043
4.8.2 Mechanism.............................................................................................................................................................1045
4.8.3 Configuring Defense Against Attacks Initiated by a Bogus DHCP Server.......................................................... 1053
4.8.3.1 Configuring a Layer 2 Interface to Defend Against Attacks Initiated by a Bogus DHCP Server..................... 1053
4.8.3.2 Configuring a Layer 3 Interface to Defend Against Attacks Initiated by a Bogus DHCP Server..................... 1054
4.8.4 Configuring Defense Against Man-in-the-Middle and IP/MAC Spoofing Attacks..............................................1056
4.8.4.1 Configuring a Layer 2 Interface to Defend Against Man-in-the-Middle and IP/MAC Spoofing Attacks.........1056
4.8.4.2 Configuring a Layer 3 Interface to Defend Against Man-in-the-Middle and IP/MAC Spoofing Attacks.........1058
4.8.5 Configuring Defense Against Attacks Launched by Changing the CHADDR Value...........................................1061
4.8.5.1 Configuring Defense on the Layer 2 Interfaces Against Attacks by Changing CHADDRs.............................. 1061
4.8.5.2 Configuring Defense on the Layer 3 Interfaces Against Attacks by Changing CHADDRs.............................. 1062
4.8.6 Configuring Defense Against Attacks by Sending Bogus Packets for Extending IP Leases................................1063
4.8.6.1 Configuring Defense on the Layer 2 Interfaces Against Attacks by Sending Bogus Packets for Extending IP
Leases............................................................................................................................................................................. 1063
4.8.6.2 Configuring Defense on the Layer 3 Interfaces Against Attacks by Sending Bogus Packets for Extending IP
Leases............................................................................................................................................................................. 1065
4.8.7 Configuring Alarms Used to Discard Packets....................................................................................................... 1067
4.8.8 Maintaining DHCP Snooping................................................................................................................................1068
4.8.8.1 Maintaining a DHCP Snooping Binding Table.................................................................................................. 1068
4.8.8.2 Debugging the DHCP Snooping Function......................................................................................................... 1069
4.8.9 Example for Configuring DHCP Snooping...........................................................................................................1070
4.8.10.1 Specifications....................................................................................................................................................1075
4.8.10.2 Feature History................................................................................................................................................. 1077
4.8.10.3 Reference Standards and Protocols.................................................................................................................. 1077
4.9 MAC Address Table................................................................................................................................................. 1077
4.9.1 Overview............................................................................................................................................................... 1078
4.9.2 Configuring a MAC Address Table.......................................................................................................................1080
4.9.2.1 Configuring the MAC Address Table Based on the VLAN and Layer 2 Interface............................................1080
4.9.2.2 Configuring the Aging Time of a MAC Address Table..................................................................................... 1081
4.9.2.3 Configuring a Limit Rule for Learning MAC Addresses...................................................................................1081
4.9.3 Maintaining the MAC Address Table....................................................................................................................1082
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxi

4.9.4.1 Example for Configuring the MAC Address Table Based on the Interface and VLAN.................................... 1083
4.9.5.1 Specifications......................................................................................................................................................1086
4.9.5.2 Feature History................................................................................................................................................... 1086
4.10 ARP........................................................................................................................................................................ 1087
4.10.1 Overview............................................................................................................................................................. 1087
4.10.2 Mechanism...........................................................................................................................................................1088
4.10.3 Configuring ARP................................................................................................................................................. 1092
4.10.3.1 Configuring Static ARP....................................................................................................................................1092
4.10.3.2 Enabling a Device to Learn Multicast MAC Addresses and Generate ARP Entries....................................... 1094
4.10.3.3 Optimizing Dynamic ARP................................................................................................................................1096
4.10.3.4 Configuring a Device to Delete Dynamic ARP Entries after a Delay..............................................................1097
4.10.3.5 Configuring ARP Automatic Scanning and Fixed ARP.................................................................................. 1098
4.10.3.6 Configuring the ARP Proxy..............................................................................................................................1100
4.10.3.6.1 Configuring Routed Proxy ARP.................................................................................................................... 1100
4.10.3.6.2 Configuring Proxy ARP Within a VLAN......................................................................................................1101
4.10.3.7 Configuring Gratuitous ARP............................................................................................................................ 1102
4.10.3.7.1 Configuring the Learning of Gratuitous ARP Packets.................................................................................. 1102
4.10.3.7.2 Configuring the Sending of Gratuitous ARP Packets....................................................................................1102
4.10.3.8 Preventing Attacks on ARP Entries..................................................................................................................1103
4.10.3.8.1 Configuring Global Strict ARP Entry Learning............................................................................................ 1103
4.10.3.8.2 Configuring Strict ARP Entry Learning on Interfaces.................................................................................. 1104
4.10.3.8.3 Configuring Interface-based ARP Entry Restriction..................................................................................... 1105
4.10.3.8.4 Enabling Alarm Functions for Potential Attack Behaviors........................................................................... 1105
4.10.4 Maintaining ARP................................................................................................................................................. 1106
4.10.4.1 Displaying ARP Configuration.........................................................................................................................1106
4.10.4.2 Clearing ARP Entries........................................................................................................................................1106
4.10.5.1 Example for Configuring Static ARP............................................................................................................... 1107
4.10.5.2 Example for Configuring ARP Automatic Scanning and Fixed ARP..............................................................1109
4.10.5.3 Example for Configuring Proxy ARP...............................................................................................................1112
4.10.6 Troubleshooting ARP Faults................................................................................................................................1115
4.10.7.1 Specifications....................................................................................................................................................1119
4.10.7.2 Feature History................................................................................................................................................. 1120
4.10.7.3 Reference Standards and Protocols...................................................................................................................1120
4.11 VLAN..................................................................................................................................................................... 1121
4.11.1 Overview..............................................................................................................................................................1121
4.11.2 Mechanism...........................................................................................................................................................1122
4.11.3 Configuring a VLAN........................................................................................................................................... 1130
4.11.3.1 Dividing a LAN into VLANs Based on Ports.................................................................................................. 1130
4.11.3.2 Configuring Vlanif Interfaces to Enable VLANs to Communicate..................................................................1132
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxii

4.11.3.3 Configuring Layer 3 Subinterfaces to Enable VLANs to Communicate......................................................... 1133

4.11.3.4 Configuring Inter-VLAN Communication Using Layer 2 Subinterfaces.........................................................1133
4.11.4 Maintaining a VLAN........................................................................................................................................... 1134
4.11.5 Example for Dividing a LAN into VLANs Based on Ports.................................................................................1135
4.11.6.1 Specifications....................................................................................................................................................1137
4.11.6.2 Feature History..................................................................................................................................................1137
4.12 IPv6 Neighbor Discovery....................................................................................................................................... 1138
4.12.1 Overview..............................................................................................................................................................1138
4.12.2 Mechanism...........................................................................................................................................................1139
4.12.2.1 IPv6 ND............................................................................................................................................................ 1139
4.12.2.2 IPv6 SEND....................................................................................................................................................... 1142
4.12.3 Configuring IPv6 ND...........................................................................................................................................1144
4.12.3.1 Configuring a Static Neighbor..........................................................................................................................1144
4.12.3.2 Configuring RA Message Advertisement.........................................................................................................1145
4.12.3.3 Setting the Interval for Advertising RA Messages........................................................................................... 1146
4.12.3.4 Configuring the Address Prefixes to Be Advertised.........................................................................................1147
4.12.3.5 Configuring Other Information to Be Advertised.............................................................................................1147
4.12.3.6 Configuring the Default Router Priority and Route Information..................................................................... 1149
4.12.3.7 Enabling IPv6 ND Strict Learning....................................................................................................................1150
4.12.3.8 Setting an Aging Time for Neighbor Entries in the Stale State........................................................................1151
4.12.4 Configuring IPv6 SEND......................................................................................................................................1151
4.12.4.1 Configuring the CGA........................................................................................................................................1152
4.12.4.2 Configuring Strict IPv6 SEND......................................................................................................................... 1153
4.12.5 Maintaining ND................................................................................................................................................... 1154
4.12.5.1 Displaying IPv6 ND Configuration.................................................................................................................. 1154
4.12.5.2 Clearing IPv6 ND Information......................................................................................................................... 1155
4.12.6.1 Example for Configuring Stateless Address Autoconfiguration...................................................................... 1155
4.12.7.1 Specifications....................................................................................................................................................1159
4.12.7.2 Feature History................................................................................................................................................. 1160
4.13 IP Performance....................................................................................................................................................... 1161
4.13.1 Overview..............................................................................................................................................................1161
4.13.2 Improving IPv4 Performance...............................................................................................................................1162
4.13.2.1 Verifying the Source IPv4 Address...................................................................................................................1162
4.13.2.2 Configuring Direct Forwarding of Fragment Packets...................................................................................... 1162
4.13.2.3 Forwarding Broadcast Packet........................................................................................................................... 1163
4.13.2.4 Configuring the Maximum Transmission Unit of the Interface....................................................................... 1164
4.13.2.5 Configuring TCP Attributes..............................................................................................................................1164
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxiii

4.13.3 Improving IPv6 Performance...............................................................................................................................1166

4.13.3.1 Configuring ICMPv6 Attributes....................................................................................................................... 1166
4.13.3.2 Configuring TCPv6 Attributes..........................................................................................................................1166
4.13.3.3 Configuring a PMTU........................................................................................................................................ 1167
4.13.4 Maintaining IP Performance................................................................................................................................1169
4.13.4.1 Checking IP Performance Configuration..........................................................................................................1169
4.13.4.2 Clearing IP Performance Statistics................................................................................................................... 1170
4.13.5.1 Specifications....................................................................................................................................................1170
4.13.5.2 Feature History................................................................................................................................................. 1171
5 Routing...................................................................................................................................... 1172
5.1 Routing Protocol Overview...................................................................................................................................... 1174
5.1.1 Overview................................................................................................................................................................1174
5.1.2 Static Routes and Dynamic Routes........................................................................................................................1174
5.1.3 Default Routes....................................................................................................................................................... 1175
5.1.4 Routing Table and FIB Table.................................................................................................................................1175
5.1.5 Routing Protocol Preference..................................................................................................................................1179
5.1.6 Route Import.......................................................................................................................................................... 1181
5.1.7 Route Metric.......................................................................................................................................................... 1181
5.1.8 Load Balancing...................................................................................................................................................... 1181
5.1.9 Priority-based Route Convergence........................................................................................................................ 1183
5.2 Routing Basics Configuration...................................................................................................................................1184
5.2.1 Routing Basics Configuration Using the Web UI..................................................................................................1184
5.2.1.1 Configuring Virtual Routers............................................................................................................................... 1184
5.2.1.2 Monitoring OSPF and BGP................................................................................................................................ 1185
5.2.1.3 Checking the Routing Table............................................................................................................................... 1186
5.2.2 Routing Basics Configuration-CLI........................................................................................................................1187
5.2.2.1 Configuring the Global Router ID...................................................................................................................... 1187
5.2.2.2 Configuring the IP-Prefix List............................................................................................................................ 1188
5.2.2.2.1 Configuring the IPv4 IP-Prefix List.................................................................................................................1188
5.2.2.2.2 Configuring the IPv6 IP-Prefix List.................................................................................................................1189
5.2.2.3 Managing IP Routing Tables.............................................................................................................................. 1190
5.2.2.3.1 Managing the Routing Table............................................................................................................................1190
5.2.2.3.2 Managing the Routing Management Module.................................................................................................. 1192
5.3 IP Static Route.......................................................................................................................................................... 1193
5.3.1 Overview................................................................................................................................................................1193
5.3.2 Mechanism.............................................................................................................................................................1193
5.3.2.1 Components of Static Routes..............................................................................................................................1193
5.3.2.2 Applications of Static Routes............................................................................................................................. 1194
5.3.2.3 Default Routes.................................................................................................................................................... 1196
5.3.2.4 BFD for Static Routes.........................................................................................................................................1196
5.3.3 Configuring Static Route Using the Web UI......................................................................................................... 1197
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxiv

5.3.4 Configuring Static Route-CLI............................................................................................................................... 1199

5.3.4.1 Configuring an IPv4 Static Route.......................................................................................................................1199
5.3.4.2 Configuring an IPv6 Static Route.......................................................................................................................1200
5.3.4.3 Configuring BFD for Static Routes.................................................................................................................... 1202
5.3.5 Checking Static Route Configuration....................................................................................................................1203
5.3.6.1 CLI Example for Configuring an IP Static Route.............................................................................................. 1203
5.3.7.1 Specifications......................................................................................................................................................1210
5.3.7.2 Feature History................................................................................................................................................... 1211
5.4 RIP............................................................................................................................................................................ 1211
5.4.1 Overview................................................................................................................................................................1211
5.4.2 Mechanism.............................................................................................................................................................1212
5.4.2.1 RIP-1...................................................................................................................................................................1212
5.4.2.2 RIP-2...................................................................................................................................................................1212
5.4.2.3 Timers................................................................................................................................................................. 1213
5.4.2.4 Triggered Update................................................................................................................................................ 1213
5.4.2.5 Route Aggregation..............................................................................................................................................1214
5.4.2.6 Multi-process and Multi-instance....................................................................................................................... 1215
5.4.3 RIP Configuration Using the Web UI....................................................................................................................1215
5.4.4 RIP Configuration Using the CLI..........................................................................................................................1221
5.4.4.1 Establishing the RIP Neighbor Relationship...................................................................................................... 1221
5.4.4.1.1 Enabling RIP....................................................................................................................................................1221
5.4.4.1.2 Enabling RIP on the Specified Network Segment...........................................................................................1222
5.4.4.1.3 Configuring RIP Version Number................................................................................................................... 1223
5.4.4.2 Controlling the Advertising of RIP Routing Information.................................................................................. 1224
5.4.4.2.1 Configuring RIP to Advertise Default Routes.................................................................................................1224
5.4.4.2.2 Disabling an Interface from Sending RIP Update Packets..............................................................................1224
5.4.4.2.3 Configuring RIP-2 Route Summarization....................................................................................................... 1225
5.4.4.3 Controlling the Receiving of RIP Routing Information..................................................................................... 1227
5.4.4.3.1 Disabling an Interface from Receiving RIP Update Packets...........................................................................1227
5.4.4.3.2 Disabling RIP from Receiving Host Routes....................................................................................................1227
5.4.4.3.3 Configuring RIP to Filter the Received Routes...............................................................................................1228
5.4.4.4 Configuring RIP to Import External Routes.......................................................................................................1229
5.4.4.5 Configuring the RIP Routing..............................................................................................................................1230
5.4.4.5.1 Configuring Additional Metrics of an Interface.............................................................................................. 1230
5.4.4.5.2 Configuring RIP Preference............................................................................................................................ 1231
5.4.4.5.3 Setting the Maximum Number of Equal-Cost Routes.....................................................................................1231
5.4.4.6 Optimizing a RIP Network................................................................................................................................. 1232
5.4.4.6.1 Configuring RIP Timers.................................................................................................................................. 1232
5.4.4.6.2 Setting the Interval for Sending Packets and the Maximum Number of the Sent Packets..............................1233
5.4.4.6.3 Configuring Split Horizon and Poison Reverse.............................................................................................. 1233
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxv

5.4.4.6.4 Configuring RIP to Check the Validity of Update Packets............................................................................. 1234

5.4.4.6.5 Configuring RIP Neighbors.............................................................................................................................1235
5.4.4.7 Improve the RIP Network Security.................................................................................................................... 1236
5.4.4.7.1 Configuring Packet Authentication of RIP-2.................................................................................................. 1236
5.4.4.8 Enhancing the RIP Network Reliability............................................................................................................. 1237
5.4.4.8.1 Configuring RIP GR........................................................................................................................................ 1237
5.4.4.8.2 Configuring BFD for RIP................................................................................................................................ 1238
5.4.4.9 Configuring the Network Management Function in RIP................................................................................... 1241
5.4.5 Maintaining RIP.................................................................................................................................................... 1241
5.4.6.1 CLI: Example for Configuring RIP Version.......................................................................................................1242
5.4.6.2 CLI: Example for Configuring RIP to Import External Routes......................................................................... 1246
5.4.7.1 Specifications......................................................................................................................................................1250
5.4.7.2 Feature History................................................................................................................................................... 1253
5.5 RIPng........................................................................................................................................................................ 1253
5.5.1 Overview............................................................................................................................................................... 1253
5.5.2 Mechanism.............................................................................................................................................................1254
5.5.3 RIPng Configuration..............................................................................................................................................1257
5.5.3.1 Establishing RIPng Neighbor Relationships...................................................................................................... 1257
5.5.3.1.1 Enabling RIPng................................................................................................................................................1257
5.5.3.1.2 Enabling RIPng in the Interface View............................................................................................................. 1257
5.5.3.2 Controlling the Advertising of RIPng Routing Information.............................................................................. 1258
5.5.3.2.1 Configuring RIPng to Advertise the Default Routes.......................................................................................1258
5.5.3.2.2 Disabling Sending of RIPng Packets on an Interface......................................................................................1259
5.5.3.2.3 Configuring RIPng to Filter the Routes to be Sent..........................................................................................1259
5.5.3.2.4 Configuring RIPng Route Summarization...................................................................................................... 1260
5.5.3.3 Controlling the Receiving of RIPng Routing Information................................................................................. 1260
5.5.3.3.1 Disabling Receiving of RIPng Packets on an Interface...................................................................................1261
5.5.3.3.2 Configuring RIPng to Filter the Received Routes...........................................................................................1261
5.5.3.4 Configuring RIPng to Import External Routes...................................................................................................1262
5.5.3.5 Controlling RIPng Routing.................................................................................................................................1263
5.5.3.5.1 Configuring the RIPng Preference.................................................................................................................. 1263
5.5.3.5.2 Configuring Additional Metrics of an Interface.............................................................................................. 1263
5.5.3.5.3 Configuring the Maximum Number of Equal-Cost Routes.............................................................................1264
5.5.3.6 Optimizing the RIPng Network.......................................................................................................................... 1265
5.5.3.6.1 Configuring the RIPng Timer.......................................................................................................................... 1265
5.5.3.6.2 Setting the Interval for Sending Update Packets and the Maximum Number of Packets Sent Each Time.....1265
5.5.3.6.3 Configuring Split Horizon and Poison Reverse.............................................................................................. 1266
5.5.3.6.4 Enabling the Zero Field Check for RIPng Packets..........................................................................................1266
5.5.4 Maintaining RIPng................................................................................................................................................ 1267
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxvi


5.5.5.1 Example for Configuring RIPng to Connect Network Devices......................................................................... 1268
5.5.6 Reference............................................................................................................................................................... 1273
5.5.6.1 Specifications......................................................................................................................................................1273
5.5.6.2 Feature History................................................................................................................................................... 1276
5.6 OSPF.........................................................................................................................................................................1276
5.6.1 Overview............................................................................................................................................................... 1276
5.6.2 Mechanism.............................................................................................................................................................1277
5.6.2.1 OSPF Fundamentals........................................................................................................................................... 1277
5.6.2.2 Basic Principles of OSPF................................................................................................................................... 1287
5.6.2.3 OSPF Packet Format.......................................................................................................................................... 1293
5.6.2.4 OSPF LSA Format..............................................................................................................................................1301
5.6.2.5 OSPF Areas........................................................................................................................................................ 1308
5.6.2.6 OSPF GR............................................................................................................................................................ 1312
5.6.2.7 OSPF Packet Authentication.............................................................................................................................. 1316
5.6.2.8 BFD for OSPF.................................................................................................................................................... 1318
5.6.3 Restrictions and Precautions..................................................................................................................................1319
5.6.4 OSPF Configuration Using the Web UI................................................................................................................ 1320
5.6.5 OSPF Configuration Using the CLI...................................................................................................................... 1334
5.6.5.1 Establishing the OSPF Neighbor Relationship...................................................................................................1334
5.6.5.1.1 Enabling OSPF................................................................................................................................................ 1334
5.6.5.1.2 Configuring the Network Segments Included by Each Area...........................................................................1335
5.6.5.2 Configuring OSPF Areas....................................................................................................................................1336
5.6.5.2.1 Configuring OSPF Stub Areas........................................................................................................................ 1336
5.6.5.2.2 Configuring OSPF NSSA Areas......................................................................................................................1337
5.6.5.2.3 Configuring OSPF Virtual Links..................................................................................................................... 1338
5.6.5.3 Controlling OSPF Routing Information............................................................................................................. 1339
5.6.5.3.1 Configuring ABR Route Aggregation............................................................................................................. 1339
5.6.5.3.2 Configuring ASBR Route Aggregation...........................................................................................................1340
5.6.5.3.3 Configuring OSPF to Filter Routes Received by OSPF..................................................................................1340
5.6.5.3.4 Configuring OSPF to Filter ABR Type3 LSA.................................................................................................1341
5.6.5.3.5 Configuring OSPF to Import Routes of Other Protocols................................................................................ 1342
5.6.5.3.6 Configuring OSPF to Import a Default Route.................................................................................................1343
5.6.5.3.7 Configuring the Related Parameters for OSPF to Import Routes................................................................... 1343
5.6.5.4 Configuring OSPF Route Selection....................................................................................................................1344
5.6.5.4.1 Configuring the Cost of OSPF Interfaces........................................................................................................1344
5.6.5.4.2 Configuring the Maximum Number of Equal-Cost Routes.............................................................................1345
5.6.5.4.3 Configuring the OSPF Priority........................................................................................................................ 1345
5.6.5.4.4 Configuring the Priority for OSPF Equal-Cost Routes................................................................................... 1346
5.6.5.5 Configuring OSPF Network Types.....................................................................................................................1347
5.6.5.5.1 Configuring Network Types of OSPF Interfaces.............................................................................................1347
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxvii

5.6.5.5.2 Configuring Neighbors for NBMA Networks.................................................................................................1347

5.6.5.5.3 Configuring DR Priorities of OSPF Interfaces................................................................................................1348
5.6.5.6 Optimizing OSPF Networks............................................................................................................................... 1349
5.6.5.6.1 Configuring OSPF Packet Timer.....................................................................................................................1349
5.6.5.6.2 Configuring the Delay for Transmitting LSAs on the Interface......................................................................1350
5.6.5.6.3 Configuring the Interval for Updating LSA.................................................................................................... 1351
5.6.5.6.4 Configuring the Interval for Receiving LSA................................................................................................... 1352
5.6.5.6.5 Configuring the Interval for SPF Calculation..................................................................................................1352
5.6.5.6.6 Suppressing the Interface from Receiving and Sending OSPF Packets.......................................................... 1353
5.6.5.6.7 Configuring Stub Router................................................................................................................................. 1354
5.6.5.6.8 Configuring the MTU in DD Packets..............................................................................................................1355
5.6.5.6.9 Configuring the Maximum Number of External LSAs in the LSDB..............................................................1355
5.6.5.6.10 Configuring RFC1583 Compatible External Routing................................................................................... 1356
5.6.5.7 Improving OSPF Network Security................................................................................................................... 1357
5.6.5.7.1 Configuring the Authentication Mode.............................................................................................................1357
5.6.5.8 Enhancing OSPF Network Reliability................................................................................................................1359
5.6.5.8.1 Configuring OSPF GR.....................................................................................................................................1359
5.6.5.8.2 Configuring BFD for OSPF.............................................................................................................................1361
5.6.5.9 Configuring the Network Management Function of OSPF................................................................................1363
5.6.5.9.1 Configuring OSPF MIB Binding.....................................................................................................................1363
5.6.5.9.2 Configuring OSPF Trap...................................................................................................................................1363
5.6.5.9.3 Configuring OSPF Log....................................................................................................................................1364
5.6.6 Maintaining OSPF................................................................................................................................................. 1364
5.6.7.1 CLI Example for Configuring Basic OSPF Functions....................................................................................... 1365
5.6.7.2 CLI Example for Configuring OSPF NSSA Areas............................................................................................ 1372
5.6.7.3 CLI Example for Configuring OSPF Virtual Links............................................................................................1377
5.6.7.4 CLI Example for Configuring DR Election of OSPF.........................................................................................1381
5.6.7.5 CLI Example for Configuring OSPF Load Balancing....................................................................................... 1385
5.6.8.1 Specifications......................................................................................................................................................1388
5.6.8.2 Feature History................................................................................................................................................... 1392
5.7 OSPFv3.....................................................................................................................................................................1392
5.7.1 Overview............................................................................................................................................................... 1392
5.7.2 Mechanism.............................................................................................................................................................1393
5.7.2.1 Principle of OSPFv3........................................................................................................................................... 1393
5.7.2.2 OSPFv3 Authentication...................................................................................................................................... 1400
5.7.2.3 Association between OSPFv3 and BGP............................................................................................................. 1400
5.7.2.4 OSPFv3 GR........................................................................................................................................................ 1402
5.7.2.5 Comparison Between OSPFv3 and OSPFv2......................................................................................................1405
5.7.3 OSPFv3 Configuration Using the Web UI............................................................................................................ 1407
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxviii

5.7.4 OSPFv3 Configuration Using the CLI...................................................................................................................1411

5.7.4.1 Establishing OSPFv3 Neighbor Relationships................................................................................................... 1411
5.7.4.1.1 Enabling OSPFv3............................................................................................................................................ 1412
5.7.4.1.2 Enabling OSPFv3 on an Interface................................................................................................................... 1412
5.7.4.1.3 Entering the OSPFv3 Area View.....................................................................................................................1413
5.7.4.2 Configuring OSPFv3 Areas................................................................................................................................1414
5.7.4.2.1 Configuring OSPFv3 Stub Areas.................................................................................................................... 1414
5.7.4.2.2 Configuring OSPFv3 NSSA Areas..................................................................................................................1415
5.7.4.2.3 Configuring OSPFv3 Virtual Links................................................................................................................. 1416
5.7.4.3 Controlling OSPFv3 Routing Information......................................................................................................... 1417
5.7.4.3.1 Configuring OSPFv3 Route Aggregation........................................................................................................1417
5.7.4.3.2 Configuring OSPFv3 to Filter the Received Routes....................................................................................... 1418
5.7.4.3.3 Configuring OSPFv3 to Import External Routes............................................................................................ 1419
5.7.4.3.4 Configuring OSPFv3 to Filter LSAs in an Area..............................................................................................1420
5.7.4.4 Configuring OSPFv3 Route Selection................................................................................................................1421
5.7.4.4.1 Setting the Cost of the OSPFv3 Interface........................................................................................................1421
5.7.4.4.2 Setting the Maximum Number of Equal-Cost Routes.....................................................................................1422
5.7.4.5 Maintaining OSPFv3 Neighbor Relationship.....................................................................................................1423
5.7.4.5.1 Configuring the Interval for Sending Hello Packets....................................................................................... 1423
5.7.4.5.2 Configuring Dead Time of Neighbor Relationship......................................................................................... 1423
5.7.4.5.3 Configuring the Interval for Retransmitting LSAs to Neighboring Routers................................................... 1424
5.7.4.5.4 Configuring the Delay for Transmitting LSAs on the Interface......................................................................1425
5.7.4.6 Optimizing an OSPFv3 Network........................................................................................................................1425
5.7.4.6.1 Configuring the SPF Timer..............................................................................................................................1425
5.7.4.6.2 Setting the Interval for Receiving LSAs..........................................................................................................1426
5.7.4.6.3 Configuring an Intelligent Timer for Generating LSAs.................................................................................. 1427
5.7.4.6.4 Suppressing an Interface from Sending and Receiving OSPFv3 Packets....................................................... 1427
5.7.4.6.5 Configuring DR Priority of an Interface..........................................................................................................1428
5.7.4.6.6 Configuring Stub Routers................................................................................................................................ 1429
5.7.4.6.7 Ignoring MTU Check on DD Packets............................................................................................................. 1430
5.7.4.7 Improving OSPFv3 Network Security............................................................................................................... 1430
5.7.4.7.1 Configuring an Authentication Mode..............................................................................................................1430
5.7.4.8 Enhancing OSPFv3 Network Reliability............................................................................................................1432
5.7.4.8.1 Configuration OSPFv3 GR..............................................................................................................................1432
5.7.4.9 Configuring the Network Management Function of OSPFv3............................................................................1433
5.7.4.9.1 Configuring OSPFv3 MIB Binding.................................................................................................................1433
5.7.4.9.2 Configuring OSPFv3 Trap...............................................................................................................................1434
5.7.5 Maintaining OSPFv3............................................................................................................................................. 1434
5.7.6.1 Example for Configuring OSPFv3 to Connect Network Devices...................................................................... 1435
5.7.7 Reference............................................................................................................................................................... 1445
5.7.7.1 Specifications......................................................................................................................................................1445
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxix

5.7.7.2 Feature History................................................................................................................................................... 1449

5.8 IS-IS..........................................................................................................................................................................1449
5.8.1 Overview............................................................................................................................................................... 1449
5.8.2 Principles............................................................................................................................................................... 1449
5.8.2.1 Basic Concepts of IS-IS......................................................................................................................................1450
5.8.2.2 Basic Protocols of IS-IS..................................................................................................................................... 1453
5.8.2.3 IS-IS Routing Information Control.....................................................................................................................1460
5.8.2.4 IS-IS Multi-instance and Multi-process............................................................................................................. 1463
5.8.2.5 IS-IS Fast Convergence...................................................................................................................................... 1465
5.8.2.6 Priority-based IS-IS Convergence...................................................................................................................... 1466
5.8.2.7 IS-IS LSP Fragment Extension...........................................................................................................................1466
5.8.2.8 Dynamic Hostname Exchange Mechanism........................................................................................................ 1470
5.8.2.9 IS-IS Wide Metric...............................................................................................................................................1471
5.8.2.10 IS-IS GR........................................................................................................................................................... 1472
5.8.2.11 BFD for IS-IS....................................................................................................................................................1478
5.8.2.12 IS-IS Authentication......................................................................................................................................... 1481
5.8.2.13 IS-IS Control Messages.................................................................................................................................... 1483
5.8.3 IS-IS Configuration............................................................................................................................................... 1489
5.8.3.1 Establishing IS-IS Neighbor Relationships........................................................................................................ 1489
5.8.3.1.1 Starting an IS-IS Process................................................................................................................................. 1489
5.8.3.1.2 Configuring an NET........................................................................................................................................ 1490
5.8.3.1.3 Configuring the Device Level......................................................................................................................... 1490
5.8.3.1.4 Enabling IS-IS for Interfaces of Different Network Types..............................................................................1491
5.8.3.2 Controlling IS-IS Routing Information.............................................................................................................. 1494
5.8.3.2.1 Configuring IS-IS to Generate Default Routes................................................................................................1495
5.8.3.2.2 Configuring IS-IS Route Aggregation.............................................................................................................1496
5.8.3.2.3 Configuring IPv4 IS-IS to Import External Routes......................................................................................... 1497
5.8.3.2.4 Filtering IPv4 IS-IS Routes............................................................................................................................. 1498
5.8.3.3 Configuring IS-IS Route Selection.....................................................................................................................1499
5.8.3.3.1 Setting a Cost for an IS-IS Interface................................................................................................................1499
5.8.3.3.2 Configuring a Preference Value for IS-IS........................................................................................................1502
5.8.3.3.3 Configuring IS-IS Route Leaking....................................................................................................................1503
5.8.3.3.4 Configuring Principles for Using Equal-Cost IS-IS Routes............................................................................ 1504
5.8.3.3.5 Configuring an Overload Bit for an IS-IS Device........................................................................................... 1505
5.8.3.4 Optimizing an IS-IS Network.............................................................................................................................1506
5.8.3.4.1 Configuring the IS-IS Packet Timer................................................................................................................ 1506
5.8.3.4.2 Setting the Parameters of LSP......................................................................................................................... 1509
5.8.3.4.3 Configuring the LSP Fast Flooding.................................................................................................................1512
5.8.3.4.4 Setting the SPF Calculation Interval............................................................................................................... 1513
5.8.3.4.5 Configuring Convergence Priorities for IS-IS Routes.....................................................................................1514
5.8.3.4.6 Configuring the Dynamic Host Name Mapping of IS-IS................................................................................1515
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxx

5.8.3.5 Improving the Security of the IS-IS Network.................................................................................................... 1517

5.8.3.5.1 Configuring IS-IS Authentication................................................................................................................... 1517
5.8.3.5.2 Configuring the Optional Checksum............................................................................................................... 1521
5.8.3.6 Configuring IS-IS Reliability............................................................................................................................. 1522
5.8.3.6.1 Configuring Static BFD for IPv4 IS-IS........................................................................................................... 1522
5.8.3.6.2 Configuring Dynamic BFD for IPv4 IS-IS......................................................................................................1523
5.8.3.6.3 Configuring IS-IS GR......................................................................................................................................1525
5.8.4 Maintaining IS-IS.................................................................................................................................................. 1527
5.8.4.1 Configuring the Output Switch of Adjacent Status............................................................................................ 1527
5.8.4.2 Viewing IS-IS..................................................................................................................................................... 1528
5.8.4.3 Restarting IS-IS.................................................................................................................................................. 1528
5.8.5.1 Example for Configuring Basic IS-IS Functions................................................................................................1529
5.8.5.2 Example for Configuring IS-IS Route Summarization...................................................................................... 1536
5.8.6 Reference............................................................................................................................................................... 1539
5.8.6.1 Specifications......................................................................................................................................................1539
5.8.6.2 Feature History................................................................................................................................................... 1541
5.9 IPv6 IS-IS................................................................................................................................................................. 1542
5.9.1 Overview............................................................................................................................................................... 1542
5.9.2 Principles............................................................................................................................................................... 1542
5.9.3 IPv6 IS-IS Configuration.......................................................................................................................................1543
5.9.3.1 Establishing IPv6 IS-IS Neighbor Relationships................................................................................................1543
5.9.3.1.1 Starting an IPv6 IS-IS Process.........................................................................................................................1543
5.9.3.1.2 Configuring an NET........................................................................................................................................ 1543
5.9.3.1.3 Configuring the Device Level......................................................................................................................... 1544
5.9.3.1.4 Enabling IPv6 IS-IS for Interfaces of Different Network Types..................................................................... 1545
5.9.3.2 Controlling IPv6 IS-IS Routing Information......................................................................................................1548
5.9.3.2.1 Configuring IPv6 IS-IS to Import External Routes......................................................................................... 1548
5.9.3.2.2 Configuring IS-IS to Generate IPv6 Default Routes....................................................................................... 1549
5.9.3.2.3 Configuring IPv6 IS-IS Route Summarization................................................................................................1551
5.9.3.2.4 Filtering IPv6 IS-IS Routes............................................................................................................................. 1552
5.9.3.3 Configuring IPv6 IS-IS Route Selection............................................................................................................ 1552
5.9.3.3.1 Configuring the Cost of an IS-IS Interface on IPv6 network.......................................................................... 1552
5.9.3.3.2 Configuring a Preference Value for IPv6 IS-IS............................................................................................... 1555
5.9.3.3.3 Configuring IPv6 IS-IS Route Leaking........................................................................................................... 1557
5.9.3.3.4 Configuring Principles for Using Equal-Cost IPv6 IS-IS Routes................................................................... 1558
5.9.3.3.5 Configuring an Overload Bit for an IPv6 IS-IS Device.................................................................................. 1559
5.9.3.4 Optimizing an IPv6 IS-IS Network.................................................................................................................... 1559
5.9.3.4.1 Configuring the IPv6 IS-IS Packet Timer........................................................................................................1559
5.9.3.4.2 Setting the Parameters of LSP......................................................................................................................... 1562
5.9.3.4.3 Configuring the LSP Fast Flooding.................................................................................................................1566
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxi

5.9.3.4.4 Setting the SPF Calculation Interval............................................................................................................... 1566

5.9.3.4.5 Configuring Convergence Priorities for IPv6 IS-IS Routes............................................................................ 1567
5.9.3.5 Improving IPv6 IS-IS Network Security............................................................................................................ 1568
5.9.3.5.1 Configuring IPv6 IS-IS Authentication........................................................................................................... 1568
5.9.3.5.2 Configuring the Optional Checksum............................................................................................................... 1572
5.9.3.6 Configuring Dynamic BFD for IPv6 IS-IS.........................................................................................................1573
5.9.4 Maintaining IPv6 IS-IS..........................................................................................................................................1575
5.9.5.1 Example for Configuring Basic IS-IS IPv6 Functions....................................................................................... 1576
5.9.6 Reference............................................................................................................................................................... 1583
5.9.6.1 Specifications......................................................................................................................................................1583
5.9.6.2 Feature History................................................................................................................................................... 1585
5.10 BGP........................................................................................................................................................................ 1586
5.10.1 Overview............................................................................................................................................................. 1586
5.10.2 Principles............................................................................................................................................................. 1588
5.10.2.1 Basic Principle of BGP.....................................................................................................................................1588
5.10.2.2 Route Import.....................................................................................................................................................1595
5.10.2.3 Route Summarization....................................................................................................................................... 1595
5.10.2.4 Route Dampening............................................................................................................................................. 1597
5.10.2.5 Community Attribute........................................................................................................................................1598
5.10.2.6 Route Reflector.................................................................................................................................................1600
5.10.2.7 BGP Confederation...........................................................................................................................................1603
5.10.2.8 MP-BGP and Address Families........................................................................................................................1604
5.10.2.9 BGP GR............................................................................................................................................................ 1611
5.10.2.10 BGP Security.................................................................................................................................................. 1613
5.10.2.11 BFD for BGP.................................................................................................................................................. 1613
5.10.3 BGP Configuration Using the Web UI................................................................................................................ 1614
5.10.4 Configuring BGP-CLI......................................................................................................................................... 1616
5.10.4.1 Establishing BGP Peer Relationships...............................................................................................................1616
5.10.4.1.1 Starting a BGP Process..................................................................................................................................1616
5.10.4.1.2 Configuring BGP Peers................................................................................................................................. 1617
5.10.4.1.3 (Optional)Configuring BGP Peer Groups..................................................................................................... 1619
5.10.4.2 Configuring BGP to Advertise Routes............................................................................................................. 1622
5.10.4.2.1 Configure BGP to Advertise Local Routes................................................................................................... 1622
5.10.4.2.2 Configuring a BGP Device to Send a Default Route to Its Peer................................................................... 1622
5.10.4.2.3 Configuring BGP Route Aggregation........................................................................................................... 1624
5.10.4.3 Configuring BGP to Import Routes from Other Routing Protocols................................................................. 1625
5.10.4.3.1 Configuring BGP to Import Routes...............................................................................................................1626
5.10.4.3.2 Configuring BGP to Import Default Routes..................................................................................................1626
5.10.4.4 Controlling the Receiving and Advertisement of BGP Routes........................................................................ 1627
5.10.4.4.1 Configuring BGP Filters................................................................................................................................1627
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxii

5.10.4.4.2 Configuring the Policy for Advertising BGP Routing Information.............................................................. 1631
5.10.4.4.3 Configuring the Policy for Receiving BGP Routing Information................................................................. 1633
5.10.4.4.4 Configuring BGP Soft Resetting................................................................................................................... 1635
5.10.4.5 Configuring BGP Route Selection and Load Balancing.................................................................................. 1637
5.10.4.5.1 Configuring the BGP Preference................................................................................................................... 1637
5.10.4.5.2 Configuring Preferred Values for BGP Routes..............................................................................................1638
5.10.4.5.3 Configuring a Default Local_Pref Attribute for a Device............................................................................. 1639
5.10.4.5.4 Configuring the MED Attribute.................................................................................................................... 1639
5.10.4.5.5 Configuring Next_Hop Attributes for Routes............................................................................................... 1642
5.10.4.5.6 Configuring the BGP Community Attribute................................................................................................. 1644
5.10.4.5.7 Configuring AS_Path Attributes for Routes..................................................................................................1646
5.10.4.5.8 Configuring BGP Load Balancing................................................................................................................ 1650
5.10.4.6 Simplifying BGP Network Connections.......................................................................................................... 1653
5.10.4.6.1 Configuring BGP Route Reflectors............................................................................................................... 1653
5.10.4.6.2 Configuring a BGP Confederation................................................................................................................ 1654
5.10.4.7 Adjusting the BGP Network Convergence Speed............................................................................................ 1655
5.10.4.7.1 Configuring a BGP ConnectRetry Timer...................................................................................................... 1655
5.10.4.7.2 Configuring BGP Keepalive and Hold Timers..............................................................................................1657
5.10.4.7.3 Configuring a Update Message Timer...........................................................................................................1659
5.10.4.7.4 Disabling Fast Reset of EBGP Connections..................................................................................................1660
5.10.4.7.5 Configuring BGP Route Dampening.............................................................................................................1661
5.10.4.8 Configuring BGP Security................................................................................................................................1662
5.10.4.8.1 Configuring MD5 Authentication................................................................................................................. 1662
5.10.4.8.2 Configuring Keychain Authentication...........................................................................................................1662
5.10.4.9 Configuring BGP Reliability............................................................................................................................ 1663
5.10.4.9.1 Enabling BGP Tracking.................................................................................................................................1663
5.10.4.9.2 Configuring BFD for BGP............................................................................................................................ 1664
5.10.4.9.3 Configuring BGP GR.................................................................................................................................... 1667
5.10.5 Maintaining BGP................................................................................................................................................. 1668
5.10.5.1 Configuring BGP to Record Peer Status Changes and Event Information...................................................... 1668
5.10.5.2 Viewing BGP Routing Information.................................................................................................................. 1669
5.10.5.3 Clearing and Resetting BGP.............................................................................................................................1670
5.10.6.1 Example for Configuring Basic BGP Functions.............................................................................................. 1671
5.10.6.2 Example for Configuring AS_Path Filters....................................................................................................... 1677
5.10.6.3 Example for Configuring MED Attributes to Control BGP Route Selection.................................................. 1682
5.10.6.4 Example for Configuring BGP Load Balancing...............................................................................................1686
5.10.7 Troubleshooting BGP.......................................................................................................................................... 1691
5.10.7.1 Failure in Establishing BGP Peers....................................................................................................................1691
5.10.7.2 Route Loss During the Exchange of Update Messages Between BGP Peers.................................................. 1695
5.10.8 Reference............................................................................................................................................................. 1698
5.10.8.1 Specifications....................................................................................................................................................1698
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxiii

5.10.8.2 Feature History................................................................................................................................................. 1703

5.11 BGP4+.................................................................................................................................................................... 1704
5.11.1 Overview..............................................................................................................................................................1704
5.11.2 Principles............................................................................................................................................................. 1704
5.11.3 BGP4+ Configuration.......................................................................................................................................... 1704
5.11.3.1 Establishing BGP4+ Peer Relationships...........................................................................................................1705
5.11.3.1.1 Starting a BGP4+ Process..............................................................................................................................1705
5.11.3.1.2 Configuring BGP4+ Peers............................................................................................................................. 1705
5.11.3.1.3 (Optional)Configuring a BGP4+ Peer Group................................................................................................ 1708
5.11.3.2 Configuring BGP4+ to Advertise Routes......................................................................................................... 1710
5.11.3.2.1 Configure BGP4+ to Advertise Local Routes............................................................................................... 1710
5.11.3.2.2 Configuring BGP4+ Route Aggregation....................................................................................................... 1711
5.11.3.2.3 Configuring Routers to Advertise a Default Route to a Peer........................................................................ 1712
5.11.3.3 Configuring BGP4+ to Import Routes..............................................................................................................1713
5.11.3.4 Controlling the Advertising and Receiving of BGP4+ Routing Information...................................................1713
5.11.3.4.1 Configuring the Policy for Advertising BGP4+ Routing Information.......................................................... 1713
5.11.3.4.2 Configuring the Policy for Receiving BGP4+ Routing Information.............................................................1715
5.11.3.4.3 Configuring BGP4+ Soft Resetting............................................................................................................... 1716
5.11.3.5 Configuring BGP4+ Route Selection and Load Balancing.............................................................................. 1717
5.11.3.5.1 Configuring the BGP4+ Preference...............................................................................................................1717
5.11.3.5.2 Configuring BGP4+ Preferred Value for Routing Information..................................................................... 1718
5.11.3.5.3 Configuring the Default Local_Pref Attribute of the Local Router...............................................................1719
5.11.3.5.4 Configuring the MED Attribute.....................................................................................................................1719
5.11.3.5.5 Configuring the Next_Hop Attribute.............................................................................................................1720
5.11.3.5.6 Configuring the BGP4+ Community Attribute............................................................................................. 1721
5.11.3.5.7 Configuring the AS_Path Attribute............................................................................................................... 1723
5.11.3.5.8 Configuring BGP4+ Load Balancing............................................................................................................ 1724
5.11.3.6 Simplifying BGP4+ Network Connections...................................................................................................... 1726
5.11.3.6.1 Configuring a BGP4+ Route Reflector..........................................................................................................1726
5.11.3.6.2 Configuring a BGP4+ Confederation............................................................................................................ 1727
5.11.3.7 Adjusting the BGP4+ Network Convergence Speed........................................................................................1728
5.11.3.7.1 Setting the BGP4+ ConnectRetry Interval.................................................................................................... 1728
5.11.3.7.2 Configuring BGP4+ Keepalive and Hold Timers..........................................................................................1729
5.11.3.7.3 Configuring the Interval for Sending Update Packets................................................................................... 1731
5.11.3.7.4 Configuring BGP4+ Route Dampening.........................................................................................................1732
5.11.3.8 Configuring BGP4+ Security........................................................................................................................... 1732
5.11.3.8.1 Configuring MD5 Authentication..................................................................................................................1733
5.11.3.8.2 Configuring Keychain Authentication...........................................................................................................1733
5.11.3.9 Configuring BGP4+ Reliability........................................................................................................................ 1734
5.11.3.9.1 Configuring BGP4+ Tracking........................................................................................................................1734
5.11.3.9.2 Configuring BFD for BGP4+........................................................................................................................ 1735
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxiv

5.11.4 Maintaining BGP4+.............................................................................................................................................1737

5.11.5.1 Example for Configuring Basic BGP4+ Functions.......................................................................................... 1739
5.11.6 Reference............................................................................................................................................................. 1745
5.11.6.1 Specifications....................................................................................................................................................1745
5.11.6.2 Feature History................................................................................................................................................. 1748
5.12 Routing Policy........................................................................................................................................................ 1749
5.12.1 Overview............................................................................................................................................................. 1749
5.12.2 Principles............................................................................................................................................................. 1750
5.12.3 Configuring the Route-Policy..............................................................................................................................1756
5.12.3.1 Configuring Filters........................................................................................................................................... 1756
5.12.3.1.1 Configuring an AS_Path Filter...................................................................................................................... 1756
5.12.3.1.2 Configuring a Community Filter................................................................................................................... 1757
5.12.3.1.3 Configuring an Extended Community Filter................................................................................................. 1758
5.12.3.1.4 Configuring an RD Filter...............................................................................................................................1758
5.12.3.2 Configuring the Route-Policy...........................................................................................................................1759
5.12.3.2.1 Creating a Route-Policy.................................................................................................................................1759
5.12.3.2.2 Configuring the If-Match Clause...................................................................................................................1760
5.12.3.2.3 Configuring the Apply Clause....................................................................................................................... 1761
5.12.3.2.4 Applying a Route-Policy............................................................................................................................... 1764
5.12.3.3 Controlling the Valid Time of the Routing policy............................................................................................ 1775
5.12.4 Maintaining the Routing Policy...........................................................................................................................1776
5.12.5.1 Example for Applying the Routing Policy When Importing Routes................................................................1777
5.12.6 Reference............................................................................................................................................................. 1780
5.12.6.1 Specifications....................................................................................................................................................1781
5.12.6.2 Feature History................................................................................................................................................. 1783
6 Intelligent Uplink Selection..................................................................................................1784

6.1 Global Route Selection Policy..................................................................................................................................1785
6.1.1 Overview............................................................................................................................................................... 1785
6.1.2 Mechanism.............................................................................................................................................................1785
6.1.4 Configuring Global Route Selection Policies Using the Web UI..........................................................................1791
6.1.4.1 Configuring Global Route Selection Policies.....................................................................................................1791
6.1.5 Configuring Global Route Selection Policies Using the CLI................................................................................1796
6.1.5.1 Configuring Global Route Selection Policies.....................................................................................................1796
6.1.6.1 CLI: Example for Configuring Load Balancing by Link Bandwidth.................................................................1800
6.1.6.2 CLI: Example for Configuring Load Balancing by Link Quality...................................................................... 1803
6.1.6.3 CLI: Example for Configuring Load Balancing by Link Weight.......................................................................1807
6.1.6.4 CLI: Example for Configuring Load Balancing by Link Priority...................................................................... 1810
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxv

6.1.6.5 CLI: Example for Configuring Active/Standby Backup by Link Priority......................................................... 1813
6.1.6.6 CLI: Example for Configuring DNS Transparent Proxy....................................................................................1817
6.1.7 Maintaining Global Route Selection Policies........................................................................................................1822
6.1.8.1 Feature History................................................................................................................................................... 1822
6.2 PBR...........................................................................................................................................................................1822
6.2.1 Overview............................................................................................................................................................... 1822
6.2.2 Mechanism.............................................................................................................................................................1823
6.2.4 Configuring PBR Using the Web UI..................................................................................................................... 1825
6.2.5 Configuring PBR Using the CLI........................................................................................................................... 1832
6.2.6.1 CLI: Example for Configuring Protocol-Specific PBR......................................................................................1837
6.2.6.2 CLI: Example for Configuring Source IP Address-Specific PBR..................................................................... 1840
6.2.6.3 CLI: Example for Configuring PBR Intelligent Uplink Selection Among Multiple ISP Outbound Interfaces. 1842
6.2.6.4 CLI: Example for Configuring Policy-based Routes for Internet Access from Multiple ISPs.......................... 1847
6.2.7 Maintaining PBR................................................................................................................................................... 1850
6.2.8.1 Feature History................................................................................................................................................... 1851
6.3 ISP Link Selection by ISP Routes............................................................................................................................ 1851
6.3.1 Overview............................................................................................................................................................... 1851
6.3.2 Application Scenarios............................................................................................................................................1852
6.3.3 Mechanism.............................................................................................................................................................1853
6.3.4 Configuring ISP Link Selection Using the Web UI...............................................................................................1854
6.3.5 Configuring ISP Link Selection Using the CLI.....................................................................................................1856
6.3.6.1 CLI: Example for Accessing the Internet Through Multiple ISP Networks (ISP Link Selection).................... 1858
6.3.6.2 CLI: Example for Configuring Intelligent Uplink Selection Among Outbound Interfaces of Different ISPs...1862
6.3.7 Maintaining ISP Link Selection............................................................................................................................ 1868
6.3.8.1 Feature History................................................................................................................................................... 1868
6.4 Health Check............................................................................................................................................................ 1868
6.4.1 Overview............................................................................................................................................................... 1868
6.4.3 Mechanism.............................................................................................................................................................1872
6.4.4 Configuring Health Check Using the Web UI....................................................................................................... 1874
6.4.5 Configuring Health Check Using the CLI............................................................................................................. 1875
6.4.6 Maintaining Health Check.....................................................................................................................................1877
6.4.7.1 Feature History................................................................................................................................................... 1878
7 SLB..............................................................................................................................................1879
7.1 Overview.................................................................................................................................................................. 1880
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxvi

7.2 Application Scenarios...............................................................................................................................................1881

7.3 Mechanism................................................................................................................................................................1884
7.3.1 Implementation Mechanism.................................................................................................................................. 1884
7.3.2 Load Balancing Algorithms...................................................................................................................................1890
7.3.3 Sticky Session........................................................................................................................................................1894
7.3.4 Service Health Check............................................................................................................................................ 1897
7.4 Restrictions and Precautions.....................................................................................................................................1899
7.5 Configuring SLB Using the Web UI........................................................................................................................ 1900
7.5.1 Configuring SLB................................................................................................................................................... 1900
7.5.2 Monitoring SLB.....................................................................................................................................................1904
7.6 Configuring SLB Using the CLI.............................................................................................................................. 1905
7.6.1 Configuration Flow................................................................................................................................................1905
7.6.2 Enabling SLB........................................................................................................................................................ 1909
7.6.3 Configuring a Real Server Group.......................................................................................................................... 1909
7.6.4 Configuring a Virtual Server................................................................................................................................. 1915
7.7 Configuration Examples........................................................................................................................................... 1919
7.7.1 Web: Example for Configuring FTP Server Load Balancing................................................................................1920
7.7.2 Web: Example for Configuring HTTP Server Load Balancing.............................................................................1924
7.7.3 Web: Example for Configuring HTTPS Server Load Balancing.......................................................................... 1928
7.7.4 CLI: Example for Configuring FTP Server Load Balancing................................................................................ 1933
7.7.5 CLI: Example for Configuring HTTP Server Load Balancing............................................................................. 1936
7.7.6 CLI: Example for Configuring HTTPS Server Load Balancing........................................................................... 1940
7.8 Maintaining SLB...................................................................................................................................................... 1943
7.9 Feature Reference..................................................................................................................................................... 1944
7.9.1 Specifications.........................................................................................................................................................1944
7.9.2 Feature History...................................................................................................................................................... 1945
8 MPLS..........................................................................................................................................1946
8.1 Overview.................................................................................................................................................................. 1947
8.2 Mechanism................................................................................................................................................................1947
8.2.1 MPLS Basics......................................................................................................................................................... 1948
8.2.1.1 Concepts............................................................................................................................................................. 1948
8.2.1.2 Establishing LSPs............................................................................................................................................... 1954
8.2.1.3 MPLS Forwarding.............................................................................................................................................. 1956
8.2.2 MPLS LDP............................................................................................................................................................ 1960
8.2.2.1 Concepts............................................................................................................................................................. 1960
8.2.2.2 LDP Sessions...................................................................................................................................................... 1961
8.2.2.3 Advertising and Managing Labels......................................................................................................................1963
8.2.2.4 LDP LSP Establishment..................................................................................................................................... 1965
8.2.2.5 LDP Extension for Inter-Area LSP.....................................................................................................................1966
8.2.2.6 LDP GR.............................................................................................................................................................. 1967
8.2.2.7 LDP MTU...........................................................................................................................................................1969
8.2.2.8 LDP Authentication............................................................................................................................................ 1970
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxvii

8.2.2.9 LDP-IGP Synchronization..................................................................................................................................1971

8.2.2.10 Synchronization Between LDP and Static Routes........................................................................................... 1975
8.3 Static LSPs Configuration........................................................................................................................................ 1976
8.3.1 Configuring Static LSPs........................................................................................................................................ 1976
8.3.1.1 Configuring the LSR ID..................................................................................................................................... 1977
8.3.1.2 Enabling MPLS.................................................................................................................................................. 1977
8.3.1.3 Configuring the Ingress for a Static LSP............................................................................................................1978
8.3.1.4 Configuring the Transit Node for a Static LSP...................................................................................................1978
8.3.1.5 Configuring the Egress for a Static LSP.............................................................................................................1979
8.3.2 Maintaining Static LSPs........................................................................................................................................ 1979
8.3.2.1 Enabling the LSP Trap Function........................................................................................................................ 1979
8.3.2.2 Monitoring the Operating Status of Static LSPs................................................................................................ 1980
8.4 MPLS LDP Configuration........................................................................................................................................1980
8.4.1 Configuring Basic MPLS LDP Functions............................................................................................................. 1980
8.4.1.1 Configuring the LSR ID..................................................................................................................................... 1980
8.4.1.2 Enabling Global MPLS ..................................................................................................................................... 1981
8.4.1.3 Enabling Global MPLS LDP.............................................................................................................................. 1981
8.4.1.4 Configuring a Local LDP Session...................................................................................................................... 1982
8.4.1.5 (Optional) Configuring an LDP Transport Address........................................................................................... 1982
8.4.1.6 (Optional) Configuring Timers for an LDP Session...........................................................................................1983
8.4.1.7 (Optional) Configuring PHP...............................................................................................................................1986
8.4.1.8 (Optional) Configuring an MPLS MTU on an Interface.................................................................................... 1987
8.4.1.9 (Optional) Configuring the Path for ICMP Reply Messages............................................................................. 1988
8.4.1.10 (Optional) Configuring LDP Label Policies.....................................................................................................1989
8.4.1.11 (Optional) Configuring a Policy for Triggering LDP LSP Establishment....................................................... 1991
8.4.1.12 (Optional) Configuring a Policy for Triggering Transit LSP Establishment....................................................1993
8.4.1.13 (Optional) Configuring Delayed Transmission of Label Withdraw Messages................................................ 1993
8.4.2 Configuring LDP Extension for Inter-Area LSP................................................................................................... 1994
8.4.3 Configuring LDP GR.............................................................................................................................................1994
8.4.3.1 Enabling LDP GR...............................................................................................................................................1995
8.4.3.2 (Optional) Configuring the GR Restarter Timer.................................................................................................1995
8.4.3.3 (Optional) Configuring GR Helper Timers........................................................................................................ 1996
8.4.4 Configuring the Non-Label Public Network Route to Be Iterated to the LSP...................................................... 1997
8.4.5 Configuring LDP Security Features...................................................................................................................... 1997
8.4.5.1 Configuring LDP MD5 Authentication.............................................................................................................. 1997
8.4.5.2 Configuring LDP Keychain Authentication....................................................................................................... 1998
8.4.6 Configuring Synchronization Between LDP and Static Routes............................................................................ 1999
8.4.7 Configuring Synchronization Between LDP and IGP...........................................................................................2001
8.4.7.1 Configuring Synchronization Between LDP and IGP........................................................................................2001
8.4.7.2 (Optional) Blocking Synchronization Between LDP and IS-IS on an Interface................................................ 2003
8.4.7.3 (Optional) Setting the Hold-down Timer Value................................................................................................. 2003
8.4.7.4 (Optional) Setting the Hold-max-cost Timer Value............................................................................................2005
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxviii

8.4.7.5 (Optional) Setting the Delay Timer Value.......................................................................................................... 2006

8.4.7.6 (Optional) Configuring LDP Graceful Deletion.................................................................................................2007
8.5 Maintaining MPLS LDP...........................................................................................................................................2008
8.5.1 Resetting LDP........................................................................................................................................................2008
8.5.2 Clearing LDP Statistics......................................................................................................................................... 2008
8.5.3 Monitoring the LDP Running Status..................................................................................................................... 2009
8.5.4 Enabling the LSP Trap Function........................................................................................................................... 2009
8.6 Configuration Examples........................................................................................................................................... 2009
8.6.1 Example for Configuring Local LDP Sessions..................................................................................................... 2010
8.7 Reference.................................................................................................................................................................. 2014
8.7.1 Specifications.........................................................................................................................................................2014
8.7.2 Feature History...................................................................................................................................................... 2016
8.7.3 Standards and Protocols.........................................................................................................................................2017
9 VPN............................................................................................................................................ 2018
9.1 VPN Overview......................................................................................................................................................... 2019
9.1.1 Introduction........................................................................................................................................................... 2019
9.2 IPSec......................................................................................................................................................................... 2025
9.2.1 IPSec Basics.......................................................................................................................................................... 2025
9.2.1.1 Overview............................................................................................................................................................ 2025
9.2.1.2 Application Scenarios.........................................................................................................................................2025
9.2.1.2.1 Site-to-Site IPSec VPN....................................................................................................................................2026
9.2.1.2.2 Hub-Spoke IPSec VPN....................................................................................................................................2028
9.2.1.2.3 Remote VPN Access for an IKEv2 Client.......................................................................................................2031
9.2.1.2.4 IPSec Redundancy Design...............................................................................................................................2031
9.2.1.2.5 Application of IPSec Multiple Instances......................................................................................................... 2037
9.2.1.3 IPSec Framework............................................................................................................................................... 2038
9.2.1.3.1 Overview of the Protocol Framework............................................................................................................. 2038
9.2.1.3.2 Encapsulation Mode........................................................................................................................................ 2039
9.2.1.3.3 Security Protocol............................................................................................................................................. 2042
9.2.1.3.4 Encryption....................................................................................................................................................... 2044
9.2.1.3.5 Verification...................................................................................................................................................... 2045
9.2.1.3.6 Key Exchange..................................................................................................................................................2048
9.2.1.4 IPSec Security Association.................................................................................................................................2049
9.2.1.4.1 SA Overview................................................................................................................................................... 2049
9.2.1.4.2 IKEv1 SA Negotiation.....................................................................................................................................2051
9.2.1.4.3 IKEv2 SA Negotiation Process....................................................................................................................... 2055
9.2.1.5 Restrictions and Precautions...............................................................................................................................2059
9.2.1.6 IPSec VPN Configuration Overview..................................................................................................................2059
9.2.1.7 Configuring IPSec Using the Web UI................................................................................................................ 2060
9.2.1.7.1 Configuring an IPSec Policy in Site-to-Site VPN........................................................................................... 2060
9.2.1.7.2 Configuring an IPSec Policy in Hub-Spoke VPN........................................................................................... 2067
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxxix

9.2.1.7.3 Monitoring IPSec Tunnels............................................................................................................................... 2074

9.2.1.8 Configuring ACL-based IPSec Using the CLI................................................................................................... 2075
9.2.1.8.1 Configuration Flow..........................................................................................................................................2076
9.2.1.8.2 Defining Data Flows to Be Protected.............................................................................................................. 2077
9.2.1.8.3 Configuring an IKE Proposal.......................................................................................................................... 2080
9.2.1.8.4 Configuring IKE Peers to Be Referenced in an IPSec Policy......................................................................... 2082
9.2.1.8.5 Configuring IKE Peers to Be Referenced in an IPSec Policy Template......................................................... 2087
9.2.1.8.6 Configuring an IPSec Proposal........................................................................................................................2092
9.2.1.8.7 Configuring an ISAKMP IPSec Policy........................................................................................................... 2094
9.2.1.8.8 Configuring a Template IPSec Policy..............................................................................................................2097
9.2.1.8.9 Configuring a Manual IPSec Policy................................................................................................................ 2100
9.2.1.8.10 Applying an IPSec Policy Group...................................................................................................................2104
9.2.1.8.11 (Optional) Configuring the IKE Peer Detection Function.............................................................................2106
9.2.1.8.12 (Optional) Setting the IKE SA Lifetime........................................................................................................2109
9.2.1.8.13 (Optional) Configuring the IKE DSCP..........................................................................................................2110
9.2.1.8.14 (Optional) Configuring NAT Traversal..........................................................................................................2111
9.2.1.8.15 (Optional) Setting the IPSec SA Lifetime..................................................................................................... 2113
9.2.1.8.16 (Optional) Configuring the IPSec Anti-Replay Window...............................................................................2116
9.2.1.8.17 (Optional) Configuring the IPSec Backward Checking Function................................................................. 2117
9.2.1.8.18 Configuring the IPSec Fragmentation Before Encryption.............................................................................2118
9.2.1.8.19 (Optional) Configuring Fast Access from Branches or Users to the Headquarters.......................................2119
9.2.1.8.20 (Optional) Enabling Dependency Between IPSec SA and IKE SA During IKEv1 Negotiation.................. 2120
9.2.1.8.21 (Optional) Enabling SHA2 authentication function to be compatible with earlier software versions.......... 2120
9.2.1.9 Configuring Route-based IPSec Using the CLI................................................................................................. 2120
9.2.1.9.2 Configuring an IKE Proposal.......................................................................................................................... 2121
9.2.1.9.3 Configuring IKE Peers to Be Referenced in an IPSec Profile.........................................................................2123
9.2.1.9.4 Configuring an IPSec Proposal........................................................................................................................2128
9.2.1.9.5 Configuring an IPSec Profile...........................................................................................................................2129
9.2.1.9.6 Applying an IPSec Profile............................................................................................................................... 2130
9.2.1.9.7 (Optional) Configuring the IKE Peer Detection Function...............................................................................2132
9.2.1.9.8 Optional) Set IKE SA Lifetime....................................................................................................................... 2134
9.2.1.9.9 (Optional) Configuring the IKE DSCP........................................................................................................... 2136
9.2.1.9.10 (Optional) Configuring NAT Traversal......................................................................................................... 2137
9.2.1.9.11 (Optional) Set the IPSec SA Lifetime............................................................................................................2138
9.2.1.9.12 (Optional) Configuring IPSec Anti-Replay Window.................................................................................... 2139
9.2.1.9.13 (Optional) Configuring the IPSec Backward Checking Function................................................................. 2141
9.2.1.9.14 Configuring the IPSec Fragmentation before Encryption............................................................................. 2142
9.2.1.9.15 (Optional) Enabling Dependency Between IPSec SA and IKE SA During IKEv1 Negotiation.................. 2143
9.2.1.9.16 (Optional) Enabling SHA2 authentication function to be compatible with earlier software versions ......... 2143
9.2.1.10 Configuring IPSec Hot Standby Using the CLI............................................................................................... 2143
9.2.1.11 Configuring IPSec VPN Multi-Instance........................................................................................................... 2144
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xl

9.2.1.11.1 Configuration Flow........................................................................................................................................2144

9.2.1.11.2 Configuring IPSec Multi-Instance................................................................................................................. 2145
9.2.1.12 Updating an IPSec Certificate.......................................................................................................................... 2147
9.2.1.13 Configuration Examples................................................................................................................................... 2149
9.2.1.13.1 Web: Example for Configuring Site-to-Site IPSec VPN Using Pre-shared Key Authentication..................2149
9.2.1.13.2 Web: Example for Configuring Site-to-Site IPSec VPN Using RSA-Signature Authentication.................. 2159
9.2.1.13.3 Web: Example for Configuring IPSec VPN Between the Headquarters and Branch Offices (IP Address of the
Headquarters Is Fixed)....................................................................................................................................................2170
9.2.1.13.4 CLI: Example for Configuring Site-to-Site IPSec VPN Using Pre-shared Key Authentication...................2186
9.2.1.13.5 CLI: Example for Configuring Site-to-Site IPSec VPN Using RSA-Signature Authentication................... 2195
9.2.1.13.6 CLI: Example for Configuring route-based IPSec VPN Using Pre-shared Key Authentication.................. 2207
9.2.1.13.7 CLI: Example for Configuring a Point-to-Point IPSec Tunnel Manually..................................................... 2214
9.2.1.13.8 CLI: Example for Configuring IPSec VPN Between the Headquarters and Branch Offices (IP Address of the
Headquarters Is Fixed)....................................................................................................................................................2222
9.2.1.13.9 CLI: Example for Branches to Access the Headquarters Using Domain Names Through PPPoE Dial-up..2234
9.2.1.13.10 CLI: Example for Configuring IPSec VPN Tunnel Negotiation in IKE Mode in the Networking Where a
NAT Device Exists Between Two Gateways (do not specify the remote-address on the gateway of the headquarters)
........................................................................................................................................................................................ 2244
NAT Device Exists Between Two Gateways (the Headquarters Authenticate Branches by Name)..............................2253
NAT Device Exists Between Two Gateways (the Headquarters Authenticate Branches by Pre-NAT IP Address)...... 2263
9.2.1.13.13 CLI: Example for Configuring IPSec VPN for Users to Access the Headquarters Using the Windows 7
IKEv2 Client...................................................................................................................................................................2272
9.2.1.13.14 CLI: Example for Configuring IPSec VPN Between Branches and the Headquarters and Enabling the
Headquarters and Branches to Access the Internet with Post-NAT IP Addresses Translated by Their Respective IPSec
Gateways........................................................................................................................................................................ 2291
9.2.1.13.15 CLI Example for Configuring IPSec VPN Between Branches and the Headquarters and Enabling the
Headquarters and Branches to Access the Internet with Post-NAT IP Addresses Translated by the Headquarters IPSec
Gateway.......................................................................................................................................................................... 2301
9.2.1.13.16 CLI Example for Configuring IPSec VPN Across VPN Instances (Using the Tunnel Interface for Inter-VPN
Forwarding).................................................................................................................................................................... 2310
9.2.1.13.17 CLI: Example for Configuring IPSec in the Same VPN Instance...............................................................2315
9.2.1.13.18 CLI: Example for Configuring IPSec in Different VPN Instances............................................................. 2323
9.2.1.13.19 CLI:Example for Configuring Link Backup for an IPSec Tunnel...............................................................2333
9.2.1.13.20 CLI: Example for Configuring Tunnel Interfaces Between Gateways to Implement IPSec VPN Tunnel
Redundancy.................................................................................................................................................................... 2345
9.2.1.13.21 CLI Example for Configuring IPSec Gateway Redundancy.......................................................................2356
9.2.1.13.22 CLI: Example for Configuring IPSec Gateway Load Balancing Without Tunnel Redundancy................. 2365
9.2.1.13.23 CLI: Example for Configuring IPSec Gateway Load Balancing With Routers Connected in the Upstream
and Downstream............................................................................................................................................................. 2375
9.2.1.13.24 CLI: Example for Configuring IPSec Gateway Load Balancing With Switches Connected in the Upstream
and Downstream............................................................................................................................................................. 2392
9.2.1.13.25 CLI: Example for Configuring Redundant IKE Peers Between the HQ and Branch Gateways to Implement
Geographical Redundancy..............................................................................................................................................2406
9.2.2 L2TP over IPSec....................................................................................................................................................2415
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xli

9.2.2.1 Overview............................................................................................................................................................ 2415

9.2.2.2 Mechanism..........................................................................................................................................................2416
9.2.2.3 Configuring L2TP over IPSec Using the CLI.................................................................................................... 2418
9.2.2.4 Configuring L2TP over IPSec Using the Web UI.............................................................................................. 2420
9.2.2.5 Configuration Examples..................................................................................................................................... 2427
9.2.2.5.1 CLI: Example for Configuring L2TP over IPSec VPN for Users that Dial Up to the Headquarters Using the
VPN Client..................................................................................................................................................................... 2427
9.2.2.5.2 CLI: Example for Configuring L2TP over IPSec VPN for Users to Access the Headquarters Using the
Windows L2TP Client.................................................................................................................................................... 2440
9.2.2.5.3 CLI: Example for Configuring Site-to-Site L2TP over IPSec VPN............................................................... 2450
9.2.3 GRE over IPSec.....................................................................................................................................................2461
9.2.3.1 Overview............................................................................................................................................................ 2461
9.2.3.2 Mechanism..........................................................................................................................................................2462
9.2.3.3 Configuring GRE over IPSec Using the CLI..................................................................................................... 2463
9.2.3.4 Configuring GRE over IPSec Using the Web UI............................................................................................... 2465
9.2.3.5 Configuration Examples..................................................................................................................................... 2465
9.2.3.5.1 CLI: Example for Configuring GRE over IPSec VPN Between Two Gateways (Using IPSec Policy)......... 2465
9.2.3.5.2 CLI: Example for Configuring route-based GRE over IPSec VPN Using Pre-shared Key Authentication... 2473
9.2.4 IPSec Troubleshooting...........................................................................................................................................2481
9.2.4.1 IPSec Troubleshooting Roadmap....................................................................................................................... 2481
9.2.4.2 IKE Negotiation Is Not Triggered...................................................................................................................... 2481
9.2.4.3 IKE SA Negotiation Failure............................................................................................................................... 2483
9.2.4.4 IPSec SA Negotiation Failure.............................................................................................................................2486
9.2.4.5 IKE Negotiation Succeeds Unidirectionally.......................................................................................................2488
9.2.4.6 Unidirectional IKE Negotiation Succeeds After the Device Restarts by Anomalies.........................................2489
9.2.4.7 The Tunnel is Established, but VPN Services Are Interrupted.......................................................................... 2491
9.2.4.8 The Tunnel is Established, but the VPN Service Quality Is Degraded.............................................................. 2492
9.2.5.1 Specifications......................................................................................................................................................2494
9.2.5.2 Feature History................................................................................................................................................... 2500
9.2.5.3 Standards and Protocols......................................................................................................................................2500
9.2.6 IPSec FAQs............................................................................................................................................................2501
9.3 L2TP......................................................................................................................................................................... 2503
9.3.1 Overview............................................................................................................................................................... 2503
9.3.2.1 NAS-Initiated VPN.............................................................................................................................................2505
9.3.2.1.1 LAC-Initiated L2TP Connection upon Receiving a Call Connection Request............................................... 2505
9.3.2.1.2 LAC-Initiated L2TP Connection upon Receiving a Call from a PPPoE User................................................ 2506
9.3.2.1.3 LAC-Initiated L2TP Connection When Users from Multiple Domains Are Connected................................ 2507
9.3.2.2 Automatic LAC Dial-up..................................................................................................................................... 2507
9.3.2.3 Client-Initiated VPN...........................................................................................................................................2508
9.3.3 Mechanism.............................................................................................................................................................2509
9.3.3.1 Tunnel and Session Establishment..................................................................................................................... 2509
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlii

9.3.3.2 Packet Encapsulation.......................................................................................................................................... 2515

9.3.3.3 Authentication Modes.........................................................................................................................................2518
9.3.5 Configuring L2TP Using the Web UI....................................................................................................................2520
9.3.5.1 Configuring an LAC........................................................................................................................................... 2520
9.3.5.2 Configuring an LNS........................................................................................................................................... 2523
9.3.5.3 Monitoring L2TP................................................................................................................................................ 2527
9.3.6 Configuring L2TP Using the CLI..........................................................................................................................2528
9.3.6.1 Configuring a LAC............................................................................................................................................. 2528
9.3.6.1.2 Enabling L2TP.................................................................................................................................................2530
9.3.6.1.3 Configuring a VT Interface (NAS-Initiated VPN )......................................................................................... 2530
9.3.6.1.4 Configuring a VT Interface in the Automatic Dial-Up Scenario.................................................................... 2532
9.3.6.1.5 Configuring an L2TP Connection................................................................................................................... 2533
9.3.6.2 Configuring an LNS........................................................................................................................................... 2535
9.3.6.2.2 Enabling L2TP.................................................................................................................................................2536
9.3.6.2.3 Configuring the Virtual Template Interface.....................................................................................................2536
9.3.6.2.4 Configuring an L2TP Connection................................................................................................................... 2539
9.3.6.2.5 (Optional) Configuring a LNS Authentication Scheme.................................................................................. 2541
9.3.6.2.6 (Optional) Enabling Virtual Forwarding......................................................................................................... 2542
9.3.6.3 Verifying Configuration......................................................................................................................................2543
9.3.6.4 Maintaining L2TP...............................................................................................................................................2544
9.3.7.1 Web Example for Configuring an Automatic LAC Dial-up L2TP Tunnel........................................................ 2546
9.3.7.2 Example for Configuring a Client-Initiated L2TP VPN.................................................................................... 2557
9.3.7.3 CLI: Example for Enabling Branches to Access the Headquarters Through NAS-Initialized L2TP VPN
(RADIUS Authentication).............................................................................................................................................. 2566
9.3.7.4 CLI: Example for Configuring an Automatic LAC Dial-up L2TP Tunnel........................................................ 2577
9.3.7.5 CLI: Example for Configuring a Client-Initiated L2TP VPN............................................................................ 2586
9.3.7.6 CLI: Example for Configuring L2TP Multiple Instances.................................................................................. 2594
9.3.8.1 Specifications......................................................................................................................................................2598
9.3.8.2 Feature History................................................................................................................................................... 2599
9.3.9 L2TP FAQs............................................................................................................................................................2600
9.4 GRE.......................................................................................................................................................................... 2603
9.4.1 Overview............................................................................................................................................................... 2603
9.4.2 Mechanism.............................................................................................................................................................2605
9.4.3 Configuring GRE Using the Web UI.....................................................................................................................2609
9.4.4 Configuring GRE Using the CLI...........................................................................................................................2614
9.4.5.1 CLI: Configuring a Static Route-based GRE Tunnel......................................................................................... 2617
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xliii

9.4.5.2 CLI: Configuring an OSPF-based GRE Tunnel................................................................................................. 2621

9.4.6 Reference............................................................................................................................................................... 2626
9.4.6.1 Specifications......................................................................................................................................................2626
9.4.6.2 Feature History................................................................................................................................................... 2626
9.4.7 FAQs...................................................................................................................................................................... 2627
9.5 BGP/MPLS IP VPN................................................................................................................................................. 2627
9.5.1 Overview............................................................................................................................................................... 2627
9.5.2 Mechanism.............................................................................................................................................................2629
9.5.2.1 Basic BGP/MPLS IP VPN................................................................................................................................. 2629
9.5.2.2 Hub and Spoke....................................................................................................................................................2637
9.5.2.3 Inter-AS VPN..................................................................................................................................................... 2639
9.5.2.4 Sham Link...........................................................................................................................................................2644
9.5.2.5 Multi-VPN-Instance CE..................................................................................................................................... 2646
9.5.2.6 Interconnection Between VPNs and the Internet................................................................................................2647
9.5.3 Configuring BGP/MPLS IP VPN..........................................................................................................................2648
9.5.3.1 Configuring Basic BGP/MPLS IP VPN............................................................................................................. 2648
9.5.3.1.1 Configuring a VPN Instance............................................................................................................................2649
9.5.3.1.2 Binding Interfaces to a VPN Instance............................................................................................................. 2651
9.5.3.1.3 Establishing MP-IBGP Peer Relationships Between PEs............................................................................... 2652
9.5.3.1.4 Configuring Route Exchange Between PEs and CEs......................................................................................2652
9.5.3.2 Configuring Tunnel Policies for a BGP/MPLS IP VPN.....................................................................................2661
9.5.3.2.1 Creating a Tunnel Policy................................................................................................................................. 2661
9.5.3.2.2 Applying a Tunnel Policy................................................................................................................................ 2662
9.5.3.3 Configuring Hub and Spoke............................................................................................................................... 2663
9.5.3.3.1 Creating a VPN Instance................................................................................................................................. 2663
9.5.3.3.2 Configuring Route Attributes of a VPN Instance............................................................................................2664
9.5.3.3.3 Binding an Interface with the VPN Instance................................................................................................... 2666
9.5.3.3.4 Configuring MP-IBGP Between Hub-PE and Spoke-PE................................................................................2667
9.5.3.3.5 Configuring Route Exchange Between PEs and CEs......................................................................................2667
9.5.3.4 Configuring Inter-AS VPN Option A.................................................................................................................2668
9.5.3.5 Configuring Inter-AS VPN Option B................................................................................................................. 2669
9.5.3.5.1 Configuring MP-IBGP Between PEs and ASBRs in the Same AS................................................................ 2669
9.5.3.5.2 Configuring MP-EBGP Between ASBRs in Different ASs............................................................................ 2670
9.5.3.5.3 Controlling the Receiving and Sending of VPN Routes Using Routing Policies........................................... 2671
9.5.3.5.4 (Optional) Storing VPN Instance Information on the ASBR.......................................................................... 2672
9.5.3.5.5 (Optional) Enabling Next-Hop-based Label Allocation on the ASBR........................................................... 2675
9.5.3.5.6 Configuring the Routing Protocol Between a CE and a PE............................................................................ 2676
9.5.3.6 Configuring Inter-AS VPN Option C (Solution 1).............................................................................................2676
9.5.3.6.1 Enabling the Labeled IPv4 Route Exchange................................................................................................... 2676
9.5.3.6.2 Configuring a Routing Policy to Control Label Distribution.......................................................................... 2677
9.5.3.6.3 Establishing the MP-EBGP Peer Relationship Between PEs..........................................................................2679
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xliv

9.5.3.6.4 Configuring Route Exchange Between CEs and PEs......................................................................................2681

9.5.3.7 Configuring Inter-AS VPN Option C (Solution 2).............................................................................................2682
9.5.3.7.1 Establishing the EBGP Peer Relationship Between ASBRs........................................................................... 2682
9.5.3.7.2 Advertising the Routes of the PE in the Local AS to the Remote PE............................................................. 2682
9.5.3.7.3 Enabling the Capability of Exchanging Labeled IPv4 Routes........................................................................ 2683
9.5.3.7.4 Establishing an LDP LSP for the Labeled BGP Routes of the Public Network............................................. 2684
9.5.3.7.5 Establishing the MP-EBGP Peer Relationship Between PEs..........................................................................2685
9.5.3.7.6 Configuring Route Exchange Between CEs and PEs......................................................................................2685
9.5.3.8 Configuring a Multi-VPN-Instance CE.............................................................................................................. 2687
9.5.3.8.1 Configuring an OSPF Multi-Instance on the Multi-Instance CE.................................................................... 2687
9.5.3.8.2 Configuring an OSPF Multi-Instance on the PE............................................................................................. 2687
9.5.3.8.3 Canceling Loop Detection on the Multi-Instance CE......................................................................................2688
9.5.3.9 Configuring OSPF Sham Link........................................................................................................................... 2688
9.5.3.9.1 Setting the Loopback Address of the Sham Link............................................................................................ 2689
9.5.3.9.2 Advertising Routes Destined for the End Address of the Sham Link............................................................. 2689
9.5.3.9.3 Creating a Sham Link...................................................................................................................................... 2690
9.5.3.10 Connecting a VPN to the Internet.....................................................................................................................2691
9.5.3.10.1 Configuring the Static Route on the CE........................................................................................................ 2691
9.5.3.10.2 Configuring the Private Network Static Route on the PE............................................................................. 2692
9.5.3.10.3 Configuring the Static Route from a Device on the Public Network to a VPN............................................ 2692
9.5.4 Maintaining BGP/MPLS IP VPN..........................................................................................................................2693
9.5.4.1 Performing MPLS Ping/Traceroute Tests...........................................................................................................2693
9.5.4.2 Displaying BGP/MPLS IP VPN Configuration................................................................................................. 2694
9.5.4.3 Clearing BGP Statistics of a VPN Instance........................................................................................................2698
9.5.4.4 Resetting BGP Connections............................................................................................................................... 2699
9.5.5.1 Example for Configuring BGP/MPLS IP VPN.................................................................................................. 2700
9.5.6 Reference............................................................................................................................................................... 2712
9.5.6.1 Specifications......................................................................................................................................................2712
9.5.6.2 Feature History................................................................................................................................................... 2714
9.6 BGP/MPLS IPv6 VPN............................................................................................................................................. 2715
9.6.1 Overview............................................................................................................................................................... 2715
9.6.2 Configuring a Basic BGP/MPLS IPv6 VPN......................................................................................................... 2716
9.6.2.1 Configuring a VPN Instance...............................................................................................................................2716
9.6.2.2 Binding an Interface to a VPN Instance............................................................................................................. 2719
9.6.2.3 Establishing MP-IBGP Peer Relationships Between PEs.................................................................................. 2720
9.6.2.4 Configuring Route Exchange Between PEs and CEs.........................................................................................2720
9.6.3 Configuring a Tunnel Policy applied to BGP/MPLS IPv6 VPN...........................................................................2728
9.6.3.1 Configuring a Tunnel Policy...............................................................................................................................2728
9.6.3.2 Applying a Tunnel Policy to the IPv6 VPN....................................................................................................... 2729
9.6.4 Configuring Hub and Spoke.................................................................................................................................. 2730
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlv

9.6.4.1 Configuring a VPN Instance Enabled with the IPv6 Address Family............................................................... 2730
9.6.4.2 Configuring Route-Related Attributes of the VPN instance IPv6 Address Family........................................... 2731
9.6.4.3 Binding an Interface to a VPN Instance............................................................................................................. 2733
9.6.4.4 Configuring MP-IBGP Between Hub-PE and Spoke-PE...................................................................................2734
9.6.5 Configuring Inter-AS IPv6 VPN-Option A...........................................................................................................2736
9.6.6 Configuring Inter-AS IPv6 VPN-Option B........................................................................................................... 2737
9.6.6.1 Configuring MP-IBGP Between PEs and ASBRs in the Same AS................................................................... 2737
9.6.6.2 Configuring MP-EBGP Between ASBRs in Different ASs............................................................................... 2737
9.6.6.3 Controlling the Receiving and Sending of VPN Routes.................................................................................... 2738
9.6.6.4 (Optional) Storing Information About the VPN instance on the ASBRs...........................................................2739
9.6.7 Configuring Inter-AS IPv6 VPN-Option C (Solution 1).......................................................................................2742
9.6.7.1 Enabling Exchange of the IPv4 Routes with Labels.......................................................................................... 2742
9.6.7.2 Configuring a Routing Policy to Control Label Distribution............................................................................. 2743
9.6.7.3 Establishing the MP-EBGP Peer Between PEs.................................................................................................. 2745
9.6.7.4 Configuring Route Exchange PEs and CEs........................................................................................................2746
9.6.8 Configuring Inter-AS IPv6 VPN Option C (Solution 2)....................................................................................... 2747
9.6.8.1 Establishing an EBGP Peer Relationship Between ASBRs............................................................................... 2747
9.6.8.2 Advertising the Routes of the PE in the Local AS to the Remote PE................................................................ 2747
9.6.8.3 Enabling Labeled IPv4 Route Exchange............................................................................................................ 2748
9.6.8.4 Establishing an LDP LSP for the Labeled BGP Routes of the Public Network................................................ 2749
9.6.8.5 Establishing an MP-EBGP Peer Relationship Between PEs..............................................................................2750
9.6.8.6 Enabling Route Exchange Between CEs and PEs..............................................................................................2750
9.6.9 Configuring Route Reflection for BGP VPNv6 Routes........................................................................................ 2751
9.6.9.1 Configuring the Client PEs to Establish MP IBGP Connections with the RR...................................................2751
9.6.9.2 Configuring the RR to Establish MP IBGP Connections with All Client PEs...................................................2751
9.6.9.3 Enabling Route Reflection for BGP VPNv6 Routes.......................................................................................... 2752
9.6.10 Maintaining BGP/MPLS IPv6 VPN....................................................................................................................2753
9.6.10.1 Displaying BGP/MPLS IPv6 VPN Information...............................................................................................2753
9.6.10.2 Checking the Network Connectivity and Reachability.................................................................................... 2754
9.6.10.3 Resetting BGP Statistics of a VPN Instance IPv6 Address Family................................................................. 2755
9.6.10.4 Resetting BGP Connections............................................................................................................................. 2755
9.6.11.1 Example for Configuring BGP/MPLS IPv6 VPN............................................................................................ 2756
9.6.12 Reference............................................................................................................................................................. 2770
9.6.12.1 Specifications....................................................................................................................................................2770
9.6.12.2 Feature History................................................................................................................................................. 2772
10 Object....................................................................................................................................... 2774
10.1 Address Object and Address Group....................................................................................................................... 2776
10.1.1 Overview............................................................................................................................................................. 2776
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlvi

10.1.2 Configuring an Address Object and Address Group Using the Web UI............................................................. 2776
10.1.3 Configuring an Address Object and Address Group Using the CLI................................................................... 2777
10.1.4 Maintaining Address Objects and Address Groups.............................................................................................2779
10.1.5 Reference............................................................................................................................................................. 2779
10.1.5.1 Specifications....................................................................................................................................................2779
10.1.5.2 Feature History................................................................................................................................................. 2781
10.2 Domain Group........................................................................................................................................................ 2781
10.2.1 Overview............................................................................................................................................................. 2781
10.2.2 Configuring Domain Groups Using the Web UI................................................................................................. 2782
10.2.3 Configuring Domain Groups Using the CLI....................................................................................................... 2782
10.2.4 Maintaining Domain Groups............................................................................................................................... 2783
10.2.5 Reference............................................................................................................................................................. 2783
10.2.5.1 Specifications....................................................................................................................................................2783
10.2.5.2 Feature History................................................................................................................................................. 2783
10.3 Region and Region Group...................................................................................................................................... 2784
10.3.1 Overview............................................................................................................................................................. 2784
10.3.2 Configuring Regions and Region Groups Using the Web UI..............................................................................2785
10.3.2.1 Modifying a Predefined Region....................................................................................................................... 2785
10.3.2.2 Creating a User-Defined Region...................................................................................................................... 2786
10.3.2.3 Creating a Region Group.................................................................................................................................. 2787
10.3.3 Configuring Regions and Region Groups Using the CLI....................................................................................2788
10.3.3.1 Modifying a Predefined Region....................................................................................................................... 2788
10.3.3.2 Creating a User-Defined Region...................................................................................................................... 2789
10.3.3.3 Creating a Region Group.................................................................................................................................. 2790
10.3.4 Maintaining Regions and Region Groups........................................................................................................... 2790
10.3.5 Reference............................................................................................................................................................. 2791
10.3.5.1 Specifications....................................................................................................................................................2791
10.3.5.2 Feature History................................................................................................................................................. 2791
10.4 Service and Service Group..................................................................................................................................... 2792
10.4.1 Overview............................................................................................................................................................. 2792
10.4.2 Configure a Service Object and Service Group Using the Web UI.....................................................................2794
10.4.3 Configuring a Service Object and Service Group Using the CLI....................................................................... 2796
10.4.4 Maintaining Service Object and Service Groups.................................................................................................2797
10.4.5 Reference............................................................................................................................................................. 2798
10.4.5.1 Specifications....................................................................................................................................................2798
10.4.5.2 Feature History................................................................................................................................................. 2798
10.5 Application and Application Group....................................................................................................................... 2798
10.5.1 Overview............................................................................................................................................................. 2799
10.5.2 Restrictions and Precautions................................................................................................................................2799
10.5.3 Predefined Application........................................................................................................................................ 2800
10.5.4 Configuring a User-Defined Application............................................................................................................ 2801
10.5.5 Configuring an Application Group......................................................................................................................2804
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlvii

10.5.6 Reference............................................................................................................................................................. 2805

10.5.6.1 Mechanism........................................................................................................................................................2805
10.5.6.2 Specifications....................................................................................................................................................2809
10.5.6.3 Feature History................................................................................................................................................. 2812
10.5.7 FAQs.................................................................................................................................................................... 2813
10.6 IP Address Pool...................................................................................................................................................... 2813
10.6.1 Configuring an IP Address Pool Using the Web UI............................................................................................ 2813
10.6.2 Configuring an IP Address Pool Using the CLI.................................................................................................. 2814
10.7 Certificate............................................................................................................................................................... 2817
10.7.1 Overview............................................................................................................................................................. 2817
10.7.2 Application Scenarios..........................................................................................................................................2818
10.7.2.1 Certificate Application in HTTPS Web Login................................................................................................. 2818
10.7.2.2 Certificate Application in IPSec VPN.............................................................................................................. 2819
10.7.2.3 Certificate Application in IPv6 Send................................................................................................................2820
10.7.3 Mechanism...........................................................................................................................................................2821
10.7.3.1 Encryption and Digital Signature Technologies............................................................................................... 2821
10.7.3.2 PKI System Architecture.................................................................................................................................. 2825
10.7.3.3 PKI Implementation......................................................................................................................................... 2827
10.7.3.4 Digital Certificate Structure..............................................................................................................................2829
10.7.4 Restrictions and Precautions................................................................................................................................2830
10.7.5 Configuring Certificates Using the Web UI........................................................................................................ 2831
10.7.5.1 Local Certificate............................................................................................................................................... 2831
10.7.5.2 CA Certificate...................................................................................................................................................2837
10.7.5.3 CRL Certificates............................................................................................................................................... 2838
10.7.5.4 Certificate Filtrate.............................................................................................................................................2840
10.7.6 Configuring Certificates Using the CLI.............................................................................................................. 2841
10.7.6.1 Configuration Flow...........................................................................................................................................2841
10.7.6.2 Configuring Key Pairs...................................................................................................................................... 2843
10.7.6.3 Configuring Entity Information........................................................................................................................2846
10.7.6.4 Applying for and Updating Certificates........................................................................................................... 2847
10.7.6.4.1 Applying for and Updating Certificates Online Through SCEP................................................................... 2847
10.7.6.4.2 Applying for and Updating Certificates Online Through CMPv2................................................................ 2850
10.7.6.4.3 Applying for Certificates Offline...................................................................................................................2854
10.7.6.5 Downloading Certificates................................................................................................................................. 2856
10.7.6.5.1 (Optional) Downloading a Certificate Applied Online................................................................................. 2856
10.7.6.5.2 Downloading a Certificate Applied Offline.................................................................................................. 2856
10.7.6.6 Installing Certificates........................................................................................................................................2857
10.7.6.7 Configuring Certificate Authentication............................................................................................................ 2858
10.7.6.7.1 Configuring the Certificate Check Mode...................................................................................................... 2858
10.7.6.7.2 Configuring a CRL to Check Certificate Status............................................................................................ 2860
10.7.6.7.3 Configuring OCSP to Check Certificate Status.............................................................................................2863
10.7.6.7.4 Verifying Certificate Validity.........................................................................................................................2864
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlviii

10.7.6.8 Configuring Certificate Attribute-Based Access Control.................................................................................2865

10.7.6.9 Configuring A Self-Signed Certificate or Local Certificate.............................................................................2866
10.7.6.10 Configuring the Certificate Expiration Pre-Warning Time............................................................................ 2867
10.7.6.11 Maintaining Certificates................................................................................................................................. 2868
10.7.7.1 CLI: Example for Using SCEP to Apply For a Certificate Online.................................................................. 2869
10.7.7.2 CLI: Example for Configuring Online Certificate Application Through CMPv2........................................... 2878
10.7.7.3 CLI: Example for Configuring the Access Control Policy of Certificate Attributes....................................... 2883
10.7.8 Reference............................................................................................................................................................. 2884
10.7.8.1 Specifications....................................................................................................................................................2884
10.7.8.2 Feature History................................................................................................................................................. 2888
10.7.8.3 Standards and Protocols....................................................................................................................................2888
10.8 Schedule..................................................................................................................................................................2889
10.8.1 Overview............................................................................................................................................................. 2889
10.8.2 Configuring a Schedule Using the Web UI......................................................................................................... 2890
10.8.3 Configuring a Schedule Using the CLI............................................................................................................... 2891
10.8.4 Maintaining Schedules........................................................................................................................................ 2892
10.8.5 Reference............................................................................................................................................................. 2892
10.8.5.1 Specifications....................................................................................................................................................2892
10.8.5.2 Feature History................................................................................................................................................. 2893
10.9 ACL........................................................................................................................................................................ 2893
10.9.1 Overview............................................................................................................................................................. 2893
10.9.2 Mechanism...........................................................................................................................................................2893
10.9.3 Configuring ACLs............................................................................................................................................... 2895
10.9.3.1 Creating a Basic ACL.......................................................................................................................................2895
10.9.3.2 Creating an Advanced ACL............................................................................................................................. 2897
10.9.4 Maintaining ACLs............................................................................................................................................... 2900
10.9.5 Reference............................................................................................................................................................. 2900
10.9.5.1 Specifications....................................................................................................................................................2900
10.9.5.2 Feature History................................................................................................................................................. 2902
10.10 IPv6 ACL..............................................................................................................................................................2902
10.10.1 Overview........................................................................................................................................................... 2902
10.10.2 Mechanism.........................................................................................................................................................2903
10.10.3 Configuring IPv6 ACLs.....................................................................................................................................2903
10.10.3.1 Creating a Basic IPv6 ACL............................................................................................................................ 2904
10.10.3.2 Creating an Advanced IPv6 ACL................................................................................................................... 2905
10.10.4 Maintaining IPv6 ACLs.....................................................................................................................................2907
10.10.5 Reference........................................................................................................................................................... 2908
10.10.5.1 Specifications..................................................................................................................................................2908
10.10.5.2 Feature History............................................................................................................................................... 2909
10.11 Keychain............................................................................................................................................................... 2909
10.11.1 Overview............................................................................................................................................................2909
Issue 01 (2015-12-8) Huawei Proprietary and Confidential xlix

10.11.2 Mechanism.........................................................................................................................................................2909
10.11.2.1 Basic Concepts................................................................................................................................................2909
10.11.2.2 Mechanism of Applying Keychain to a Non-TCP Application......................................................................2911
10.11.2.3 Mechanism of Applying Keychain to TCP Applications............................................................................... 2913
10.11.3 Configuring a Keychain.....................................................................................................................................2915
10.11.3.1 Creating a Keychain........................................................................................................................................2915
10.11.3.2 Configuring a Key.......................................................................................................................................... 2916
10.11.3.3 Applying the Keychain................................................................................................................................... 2918
10.11.4 Maintenance.......................................................................................................................................................2919
10.11.5 Configuration Examples.................................................................................................................................... 2919
10.11.5.1 CLI: Example for Configuring Keychain Authentication for Non-TCP Application.................................... 2919
10.11.5.2 Example for Configuring Keychain Authentication for TCP Application..................................................... 2921
10.11.6 Reference........................................................................................................................................................... 2924
10.11.6.1 Feature History............................................................................................................................................... 2924
10.11.6.2 Standards and Protocols..................................................................................................................................2924
10.12 Authentication Server........................................................................................................................................... 2924
10.12.1 Overview........................................................................................................................................................... 2924
10.12.2 Configuring Authentication Servers Using the Web UI.................................................................................... 2927
10.12.2.1 Configuring a RADIUS Server.......................................................................................................................2928
10.12.2.2 Configuring an HWTACACS Server............................................................................................................. 2930
10.12.2.3 Configuring an AD Server..............................................................................................................................2932
10.12.2.4 Configuring an LDAP Server......................................................................................................................... 2935
10.12.3 Configuring Authentication Servers Using the CLI.......................................................................................... 2937
10.12.3.1 Configuring a RADIUS Server.......................................................................................................................2937
10.12.3.2 Configuring an HWTACACS Server............................................................................................................. 2940
10.12.3.3 Configuring an AD Server..............................................................................................................................2941
10.12.3.4 Configuring an LDAP Server......................................................................................................................... 2943
10.12.3.5 Maintaining the Authentication Servers......................................................................................................... 2944
10.12.4 Reference........................................................................................................................................................... 2946
10.12.4.1 Specifications..................................................................................................................................................2947
10.12.4.2 RADIUS Attributes........................................................................................................................................ 2949
10.12.4.3 Feature History............................................................................................................................................... 2961
10.12.4.4 Standards and Protocols..................................................................................................................................2962
11 User and User Authentication.............................................................................................2963

11.1 Overview.................................................................................................................................................................2965
11.2 Application Scenarios............................................................................................................................................. 2965
11.2.1 Remote Access Users Access Intranet Resources Using L2TP VPN..................................................................2965
11.2.2 Remote Access Users Access Intranet Resources Using IPSec VPN................................................................. 2967
11.3 Mechanism..............................................................................................................................................................2968
11.3.1 User Organizational Structure............................................................................................................................. 2968
11.3.2 User Authentication............................................................................................................................................. 2972
11.3.2.1 Overall Authentication Flow............................................................................................................................ 2972
Issue 01 (2015-12-8) Huawei Proprietary and Confidential l

11.3.2.2 Authentication Triggering.................................................................................................................................2973

11.3.2.3 Authentication Domain.....................................................................................................................................2973
11.4 Restrictions and Precautions...................................................................................................................................2975
11.5 Configuring User Management and Authentication Using the Web UI................................................................. 2975
11.5.1 Configuration Flow..............................................................................................................................................2975
11.5.2 Creating an Authentication Domain.................................................................................................................... 2977
11.5.3 Configuring an Authentication Domain.............................................................................................................. 2978
11.5.3.1 Configuring L2TP/L2TP over IPSec User Authentication...............................................................................2978
11.5.3.2 Configuring IPSec User Authentication (EAP Authentication)....................................................................... 2982
11.5.3.3 Configuring Administrator Authentication.......................................................................................................2983
11.5.4 Configuring Users, User Groups, or Security Groups......................................................................................... 2984
11.5.4.1 Creating Users and User Groups...................................................................................................................... 2984
11.5.4.2 Creating Security Groups..................................................................................................................................2988
11.5.4.3 Importing Users and User Groups from a CSV File.........................................................................................2989
11.5.4.4 Importing Security Groups from a CSV File....................................................................................................2990
11.6 Configuring User Management and Authentication Using the CLI....................................................................... 2992
11.6.1 Configuration Flow..............................................................................................................................................2992
11.6.2 Creating an Authentication Domain.................................................................................................................... 2993
11.6.3 Configuring an Authentication Domain.............................................................................................................. 2994
11.6.4 Configuring Users, User Groups or Security Groups.......................................................................................... 2996
11.6.4.1 Creating Users and User Groups...................................................................................................................... 2996
11.6.4.2 Creating Security Groups..................................................................................................................................2999
11.6.4.3 Importing Users and User Groups from a CSV File.........................................................................................3000
11.6.4.4 Importing Security Groups from a CSV File....................................................................................................3002
11.6.5 Monitoring User Management and Authentication............................................................................................. 3003
11.7 User Access Scenarios............................................................................................................................................ 3004
11.8 Configuration Examples......................................................................................................................................... 3004
11.8.1 Example for Configuring Local Authentication on Remote Access Users Using L2TP VPN in NAS-Initiated
Mode............................................................................................................................................................................... 3005
11.8.2 Example for Configuring Local Authentication on Remote Access Users Using IPSec VPN........................... 3009
11.9 Reference................................................................................................................................................................ 3012
11.9.1 Specifications.......................................................................................................................................................3012
11.9.2 Feature History.................................................................................................................................................... 3013
11.9.3 Standards and Protocols.......................................................................................................................................3013
11.10 FAQs..................................................................................................................................................................... 3013
12 Security Policy and Content Security................................................................................ 3014

12.1 Security Policy........................................................................................................................................................3015
12.1.1 Overview............................................................................................................................................................. 3015
12.1.2 Application Scenarios..........................................................................................................................................3015
12.1.3 Security Policy Mechanism................................................................................................................................. 3018
12.1.4 Configuration Guide............................................................................................................................................ 3020
12.1.5 Configuring a Security Policy Using the Web UI............................................................................................... 3022
Issue 01 (2015-12-8) Huawei Proprietary and Confidential li

12.1.6 Configuring a Security Policy Using the CLI..................................................................................................... 3026

12.1.7.1 Web: Example for Configuring Security Policies Based on IP Addresses and Ports.......................................3029
12.1.7.2 Web: Example for Configuring Security Policies for Bypass Detection..........................................................3039
12.1.7.3 CLI: Example for Configuring Security Policies Based on IP Addresses and Ports....................................... 3042
12.1.7.4 CLI: Example for Configuring Security Policies for Bypass Detection...........................................................3046
12.1.8 Troubleshooting Security Policy......................................................................................................................... 3048
12.1.8.1 Intranet Users Can Access the Internet but Cannot Watch Online Videos.......................................................3048
12.1.8.2 The FW Fails to Detect a Virus Detected on a PC........................................................................................... 3049
12.1.9 Feature History.................................................................................................................................................... 3050
12.1.10 Security Policy FAQs........................................................................................................................................ 3050
12.2 Content Security..................................................................................................................................................... 3051
12.2.1 Antivirus.............................................................................................................................................................. 3051
12.2.1.1 Overview.......................................................................................................................................................... 3051
12.2.1.2 Application Scenarios.......................................................................................................................................3051
12.2.1.3 Mechanism........................................................................................................................................................3052
12.2.1.4 Restrictions and Precautions.............................................................................................................................3055
12.2.1.5 Configuring Antivirus.......................................................................................................................................3056
12.2.1.6.1 Example for Configuring Antivirus...............................................................................................................3059
12.2.1.6.2 Example for Configuring Antivirus...............................................................................................................3064
12.2.1.7 Troubleshooting Antivirus................................................................................................................................3067
12.2.1.7.1 Antivirus Does Not Take Effect.....................................................................................................................3067
12.2.1.8 Feature Reference............................................................................................................................................. 3069
12.2.1.8.1 Specifications.................................................................................................................................................3069
12.2.1.8.2 Feature History.............................................................................................................................................. 3070
12.2.1.8.3 Standards and Protocols.................................................................................................................................3070
12.2.1.9 Antivirus FAQs.................................................................................................................................................3070
12.2.2 Intrusion Prevention............................................................................................................................................ 3071
12.2.2.1 Overview.......................................................................................................................................................... 3071
12.2.2.2 Application Scenarios.......................................................................................................................................3072
12.2.2.3 Mechanism........................................................................................................................................................3074
12.2.2.4 Restrictions and Precautions.............................................................................................................................3079
12.2.2.5 Configuring Intrusion Prevention..................................................................................................................... 3079
12.2.2.5.1 Configuring Signatures..................................................................................................................................3079
12.2.2.5.2 Configuring Intrusion Prevention.................................................................................................................. 3089
12.2.2.6.1 Example for Configuring Intrusion Prevention............................................................................................. 3097
12.2.2.6.2 Example for Configuring Intrusion Prevention............................................................................................. 3104
12.2.2.7 Managing Intrusion Prevention........................................................................................................................ 3109
12.2.2.8 Troubleshooting Intrusion Prevention.............................................................................................................. 3110
12.2.2.8.1 Intrusion Prevention Is Configured but Fails to Block Attacks.....................................................................3110
Issue 01 (2015-12-8) Huawei Proprietary and Confidential lii

12.2.2.9 Feature Reference............................................................................................................................................. 3113

12.2.2.9.1 Specifications.................................................................................................................................................3113
12.2.2.9.2 Feature History.............................................................................................................................................. 3114
12.2.2.9.3 Standards and Protocols.................................................................................................................................3114
12.2.2.10 Intrusion Prevention FAQs............................................................................................................................. 3114
Issue 01 (2015-12-8) Huawei Proprietary and Confidential liii

Administrator Guide 1 System
1 System
About This Chapter
This chapter describes the configurations of the basic functions, upgrade, and maintenance of
the device.
1.1 Logging In to the Device for the First Time

This section describes how an administrator can use the console port and web to log in to the
FW administrator interface for the first time.
1.2 Startup Wizard
The quick wizard assists you in completing basic device configurations and connecting the
device to the Internet. This section describes parameters for each step and the operations of
the wizard.
1.3 Administrators
This section describes how to configure administrators, including configuring administrator
accounts, administrator interfaces, and services.
1.4 System Clock
A precise system time ensures the accuracy and consistency of collaboration between devices
and helps the administrator gain visibility into the specific time of system events.
1.5 License Management
Licenses determine what features can be used on the device. To meet service requirements,
you can purchase licenses to activate these features.
1.6 Update Center
This section describes how to update the signature database to the specified versions to
enhance the dynamic defense capabilities of a network security device.
1.7 SNMP
The Simple Network Management Protocol (SNMP) provides a set of standard protocols for
the communication between the network management station (NMS) and devices, allowing
the NMS to normally manage devices and receive alarms reported by the devices.
1.8 Across-Layer-3 MAC Identification
When the FW is connected to the intranet through layer-3 devices, configuring across-Layer-3
MAC address identification enables the FW to obtain MAC addresses of intranet PCs.
Issue 01 (2015-12-8) Huawei Proprietary and Confidential 1

1.9 Logs
You can display logs to gain visibility into device operating, which facilitates fault location.
1.10 Alarms
By viewing alarms, you can rapidly be informed of faults occurring when the device is
running, helping quickly rectify the faults and ensure normal device operation.
1.11 Debugs
To learn about device running information or commission the device, you can output the
debugging information of a specified module through the information center to different
directions.
1.12 Setting the Mail Service
After the SMTP mail server is configured, the device can send information to a specified
email box.
1.13 Status Check and Packet Processing
You can modify the link status check function and packet processing mode to meet the
network environment requirements.
1.14 File System
This chapter describes how to manage the directories and files in the file system of the FW
and how to transfer files between the FW and other devices.
1.15 Configuration File
This section describes how to save, back up, and remove a configuration file as well as
conduct a comparison between configuration files.
1.16 System Upgrade
You can upgrade the system or install patches.
1.17 System Restart
You need to restart the system if the device works improperly or needs to be upgraded or to
replace the startup file.
1.18 User Experience Plan
This section describes the content of the user experience plan.
1.19 NQA
This chapter describes the Network Quality Analysis (NQA) mechanism, testing scenarios,
and general parameters and provides examples for configuring NQA.

1.1 Logging In to the Device for the First Time

This section describes how an administrator can use the console port and web to log in to the
FW administrator interface for the first time.
1.1.1 Logging In to the CLI Through the Console Port

By default, the FW allows an administrator to log in to the CLI administrator interface using
the console port.
Context
Figure 1-1 shows the networking diagram for the login to the FW through the console port.
Figure 1-1 Cabling between the PC and the Console port of the FW
COM Console
RS-232
PC NGFW
Procedure
Step 1 Connect the console cable.
1. Shut down the FW and power off the configuration terminal.
2. Connect the RS-232 serial port of the configuration terminal to the configuration
interface of the FW with a cable.
3. After checking the installation, power on the configuration terminal.
Step 2 Configure the terminal. The following examples describe terminal configurations in the
Windows XP and Windows 7 operating systems.
Windows XP
1. Run the terminal emulation program (such as the HyperTerminal on Windows XP) on
the PC. Choose Start > All programs > Accessories > Communications > Hyper
Terminal. The Connection Description dialog box is displayed.
2. In Name, enter the name (for example, COMM1) of the connection between the PC and
the FW. Then, select an icon in Icon, as shown in Figure 1-2.

Figure 1-2 Setting the name of the connection
3. Click OK. The Connect to dialog box is displayed.

4. Select the serial port, such as COM1, used for the connection between the PC and the
FW from the Connect using drop-down list, as shown in Figure 1-3.
Figure 1-3 Selecting the COM port of the PC
5. Click OK. The COM1 Properties dialog box is displayed.

6. Set communications parameters of the serial port or click Restore Defaults to set the
default value for the parameters, as shown in Figure 1-4.

Figure 1-4 Setting port properties
7. Click OK.
Windows 7
1. Download the PuTTY software to the local device and double-click it to run the
software.
2. Choose Session, set the Connection type to Serial.
3. Set the parameters for connecting the serial port to the device.
Figure 1-5 shows detailed parameter settings.

Figure 1-5 Setting the PuTTY parameters for connecting the serial port to the FW
4. Click Open.
Step 3 Click Enter and enter account admin and password Admin@123.
NOTE
After three consecutive login failures through the console port, the system automatically locks out the
console port (prohibiting administrators login) for 10 minutes.
Step 4 Change the default administrator password and access the CLI interface.
NOTE
To enhance security, a password must meet the minimum strength requirements, that is, the password
needs to contain at least three types of the following characters: uppercase letters (A to Z), lowercase
letters (a to z), digits (0 to 9), and special characters, such as exclamation points (!), at signs (@),
number signs (#), dollar signs ($), and percent (%).
Please keep the new password you entered safe for your next login.
----End
Follow-up Procedure
Log in to the device through the console port for management and configuration. You can also
create more administrators or establish the Telnet, STelnet, and web login environment. For
details, refer to 1.3 Administrators.
1.1.2 Logging In to the Web UI Using HTTPS

By default, the device allows an administrator to log in to the FW web UI using HTTPS.

Prerequisites
The browser on the administrator PC must meet any of the following requirements:
l Internet Explorer: version 6.0 to 9.0
l Firefox (recommended): version 10.0 or later
l Chrome: version 17.0 or later
NOTE
When using Internet Explorer, you are advised to version 7.0 or later.
Procedure
Step 1 Connect the network interface of the administrator PC to management interface
GigabitEthernet 0/0/0 using network cables or layer-2 switches.
Step 2 Set the IP address of the administrator PC, within a range from 192.168.0.2 to 192.168.0.254.
Step 3 Open the browser on the administrator PC. In the address box, enter the default IP address of
the management interface (https://192.168.0.1:8443).

NOTE
If the address is http://192.168.0.1, the device automatically uses the more secure HTTPS to access the
web UI.
If the browser displays a notification for an insecure certificate, you can continue the browsing. For
security, you are advised to configure the specified certificate after logging in to the device. For details,
refer to 1.3.5.2 Example for Logging In to the Web UI Using HTTPS (Specified Certificate).
Click Open Source Software Notice in the web login page, you can check the related information about
the open source software notice.
Step 4 On the login page, enter the default user name admin and password Admin@123 of the
system administrator. Click Login.
NOTE
You can also use default audit administrator account audit-admin (password Admin@123) to log in to
the device.
After three consecutive login failures, the web UI is automatically locked out for 10 minutes to forbid
any user login.
Step 5 Changing the password of the default administrator account. Click OK to access the web UI.
NOTE
To enhance security, a password must meet the minimum strength requirements, that is, the password
needs to contain at least three types of the following characters: uppercase letters (A to Z), lowercase
letters (a to z), digits (0 to 9), and special characters, such as exclamation points (!), at signs (@),
number signs (#), dollar signs ($), and percent (%).
Please keep the new password you entered safe for your next login.
----End
Follow-up Procedure
Use HTTPS to log in to the web UI for management and configuration. You can also create
more administrators. For details, refer to 1.3 Administrators.
1.2 Startup Wizard

The quick wizard assists you in completing basic device configurations and connecting the
device to the Internet. This section describes parameters for each step and the operations of
the wizard.
Welcome to Startup Wizard

After you access the quick wizard, the Welcome to Startup Wizard is displayed first.
Step 1 Choose System > Startup Wizard.
Step 2 Click Next.

NOTE
By default, the Welcome to Startup Wizard page is displayed after the successful login. If you do not want
to enter the Startup Wizard page after login, select Do not display this page upon the next login on the
lower left of the page. Upon the next login, the Dashboard page is directly displayed.
----End

Basic Configuration
Step 1 In Basic Configuration, enter or select parameters listed in Table 1-1.
Step 2 Click Next.
Table 1-1 Parameter description of basic configuration
Parameter Description
Host Name Indicates the name of the device. The host name appears in the
command prompt, and can be modified as required.
Change Administrator Configures whether to change the administrator password for

Password logging in to the Web page.
You are required to change the password upon your first login.
Old Password Enters the old password. After you select Change
Administrator Password, Old Password becomes available.
New Password Enters the new password. After you select Change
Administrator Password, New Password becomes available.
Confirm Enters the new password again. Ensure that the new passwords
you entered twice are consistent. After you select Change
Administrator Password, Confirm becomes available.
----End
Time Settings
Step 1 In Time Settings, enter or select parameters listed in Table 1-2.
Step 2 Click Next.
Table 1-2 Parameter description of time settings
Configuration Mode You can use one of the following methods to set the system
time:
l Manually Set the Time.
l Synchronize the Time with the Local System Time. If you
select this method, the time zone, date, and system time
cannot be manually set.
l Synchronize the Time with the NTP Server. If you select
this method, you also need to set the IP address of the NTP
server.
Time Zone Selects the time zone in which the device is located from the
drop-down list.

Date Perform either of the following methods to configure the

system date:
l Enter the system date in the text box in the
YYYY/MM/DD format.
l Click , and select a date from the calendar that is
displayed.
Time Perform either of the following methods to configure the

system time:
l Enter the system time in the text box in the hh:mm:ss
format.
l Select the area for the hour, minute, or second and then
click or .
Automatically adjust After this item is selected, the system automatically adjusts the
clock for daylight saving clock for the DST.
time (DST)
Start Time Indicates the start time of the DST. This item is displayed after
Automatically adjust clock for daylight saving time (DST)
is selected.
End Time Indicates the end time of the DST. This item is displayed after
Automatically adjust clock for daylight saving time (DST)
is selected.
Offset Time Indicates the offset time of the system in the DST mechanism.
This item is displayed after Automatically adjust clock for
daylight saving time (DST) is selected.
For example, set the Start Time to 08:00:00 on the first
Monday in August, End Time to 10:00:00 on the first Monday
in October, and Offset Time to 01:00:00. At 08:00:00 on the
first Monday in August, the system time is automatically
changed to 09:00:00. At 10:00:01 on the first Monday in
October, the system time is automatically changed to 09:00:01.
----End
WAN Mode
Select the Internet access mode based on the information supplied by the network service
provider. Internet access parameters vary with different access modes.
Step 1 In WAN Mode, select the Internet access mode, as shown in Table 1-3.
Step 2 Click Next.

Table 1-3 Parameter description of selecting an Internet access mode

Static IP Applies if you obtain a fixed IP address or an IP address

segment from the network service provider.
DHCP Applies if you obtain an IP address automatically from the

network service provider.
PPPoE Applies if you obtain a user name and password from the
network service provider.
----End
WAN Settings
Step 1 Enter or select parameters according to the Internet access mode.
l Table 1-4 shows parameters for access to the Internet through a static IP address.
Table 1-4 Parameter description of accessing the Internet in static IP mode

Interface Selects an interface for accessing the Internet.
IP Address Indicates the IP address of the interface for accessing the

Internet.
The value is supplied by the network service provider and
is in dotted decimal notation (for example, 1.1.1.1).
Subnet Mask Indicates the subnet mask of the interface for accessing the
Internet.
is in 255.x.x.x format.
Default Gateway Indicates the IP address of the default gateway on the

interface for accessing the Internet. The packets of intranet
users' access to the Internet are sent to the default gateway
through the interface for accessing the Internet. Then the
default gateway forwards such packets.
is in dotted decimal notation (for example, 1.1.1.254).
Primary DNS Server Indicates the IP address of the primary DNS server.
Generally, LAN hosts require to access the Web site by
using domain names. Therefore, you need to specify the IP
address of the DNS server.
The value is supplied by the network service provider.

Secondary DNS Server Indicates the IP address of the secondary DNS server.
When the primary DNS server is faulty, the device accesses
the secondary DNS server for domain name resolution.
l Table 1-5 shows parameters for access to the Internet through DHCP.
Table 1-5 Parameter description of accessing the Internet in DHCP mode
Interface The interface for accessing the Internet serves as the DHCP
client and attempts to obtain an IP address from the
network service provider (DHCP server).
l Table 1-6 shows parameters for access to the Internet through PPPoE.
Table 1-6 Parameter description of accessing the Internet in PPPoE mode
Interface Selects an interface for accessing the Internet.
User Name Indicates the user name used by identity authentication for
access in PPPoE mode.
Password Indicates the password used by identity authentication for

access in PPPoE mode.
Online Mode – Always Online: applies if you are a monthly-payment

subscriber or pay by traffic.
– Inactivity Disconnection (seconds): applies if you pay
by online duration. If no traffic is transmitted with
Inactivity Disconnection(seconds), connection to the
Internet is interrupted.
Obtain an IP Address Indicates that the interface for accessing the Internet
Automatically automatically obtains an IP address from the network
service provider.
Use the Following IP Manually sets the IP address of the interface for accessing
Address the Internet.
IP Address After you select Use the Following IP Address:, IP

Address becomes available.

Step 2 Click Next.
----End
LAN Settings
Step 1 In LAN Settings, enter or select parameters listed in Table 1-7.
Step 2 Click Next.
Table 1-7 Parameter description of configuring a LAN interface
Interface Selects the interface connecting to the LAN on the device.
IP Address Indicates the IP address of the interface connecting to the

LAN. A private address such as 10.0.0.1 or 192.168.0.1 is
recommended.
Subnet Mask Indicates the subnet mask of the interface connecting to the
LAN.
----End
LAN DHCP Settings

Step 1 In LAN DHCP Settings, enter or select parameters listed in Table 1-8.
Step 2 Click Next.
Table 1-8 Parameter description of configuring the DHCP service on the LAN
Enable DHCP Server on After the DHCP service on the LAN is enabled, users on the
LAN LAN can automatically obtain IP addresses ranging from the
start IP address to the end IP address.
Start IP Address Indicates the start IP address of the IP addresses assigned to the
DHCP client.
By default, the system takes the IP address mask range for the
interface as the assignable IP address range. For example, the
IP address of an interface is 192.168.1.5 255.255.255.0. When
you create a DHCP server on the interface, the system regards
Start IP Address as 192.168.1.1, and End IP Address to
192.168.1.254 by default. Because 192.168.1.5 is the IP
address of the interface, it will not be assigned. When
assignable IP address range is different from the default value,
you can directly specify the Start IP Address and End IP
Address.

End IP Address Indicates the end IP address of the IP addresses assigned to the
DHCP client.
----End
Check Configuration Information

Check configuration information displays configuration information in the previous steps,
including:
l Outside: displays WAN Settings configurations.

l Inside: displays LAN Settings and LAN DHCP Settings configurations.
Step 1 Check configuration information in Summary. After confirming the information, click
Apply.
Step 2 Wait a period of time. If the configuration information is successfully delivered, the Startup
Wizard Complete page is displayed.
Step 3 Click Finish. The configuration of the quick wizard is complete.
----End
1.3 Administrators
This section describes how to configure administrators, including configuring administrator
accounts, administrator interfaces, and services.
1.3.1 Overview
The FW provides an administrator mechanism consisting of administrators and administrator
interfaces. The administrator interface is a unified management page over configuration UIs
and administrators using a login method.
1.3.1.1 Administrator Overview

This section describes the administrator login methods and permission control mechanism.
Administrator Login Methods

The Table 1-9 shows administrator login methods. By default, the default administrator
(admin/Admin@123) and auditor (audit-admin) can log in to the device using web, and
console port.

Table 1-9 Administrator login methods

Login Application Scenario Interface Description
Method
Web An administrator performs Any Ethernet By default, an

(HTTPS) operations on a device port reachable to administrator uses account
through the web page, the login PC and admin, password
which is more intuitive device works. Admin@123, and
than the CLI. You are advised management interface
to select MGMT to log in. For
management details, refer to 1.1.2
interface Logging In to the Web UI
MGMT for Using HTTPS.
login. The device enables the
HTTPS service by default.
CLI Cons Console is the basis of Console port The default account and
ole other CLI login methods. password are admin and
Only one administrator Admin@123. For details,
can operate at the same refer to 1.1.1 Logging In
time. Console is used in to the CLI Through the
the following scenarios: Console Port.
l An administrator logs
in to the CLI for the
first time.
l If an administrator
cannot log in to the
device remotely, the
administrator can log
in locally through the
console port.
l If a device cannot start
normally, the
administrator can
access the BootROM
menu through the
console port to load
the system software.

Login Application Scenario Interface Description

Method
Teln This method applies to Any Ethernet Direct login is not enabled
et remote management and port reachable to by default. You must
maintenance. Multiple the login PC and configure the Telnet
administrators can operate device works. service. For details, refer
at the same time. You are advised to 1.3.5.3 Example for
to select Logging in to the CLI
management Using the Telnet (Local
interface Authentication) or 1.3.5.4
MGMTfor login. Example for Logging in
to the CLI Using the
Telnet (RADIUS Server
Authentication).
NOTICE
During Telnet login, data and
passwords are transmitted in
plaintext mode, causing
security risks. To secure data
transmission, use STelnet
instead.
STel STelnet supports identity Direct login is not enabled

net authentication and by default. You must
encrypted data configure the SSH service
transmission and is more and users. For details, refer
secure than Telnet. to 1.3.5.6 Example for
Logging in to the CLI
Using STelnet (Password
Authentication) or 1.3.5.7
Example for Logging In
to the CLI Using STelnet
(RSA Authentication).
Administrator Permission Control

The FW controls administrator permissions based on administrator roles, including the
configurable menus on the web UI for web administrators and the executable commands on
the CLI for CLI administrators. By default, the FW provides the administrator roles listed in
Table 1-10. Each role has corresponding permissions, and the permissions determine the
operations that administrators are allowed to perform. When you create an administrator, you
can grant the default role to the administrator or custom-make a role on the FW.
Table 1-10 Default administrator roles
Default Role Description
system-admin Has all permissions .
device-admin Has service configuration and device monitoring

permissions.

Default Role Description
device-admin (monitor) Has the device monitoring permission.
audit-admin
NOTE
The FW classifies roles based on permissions on web configuration items. The FW assigns a role read-
write permission, read-only permission, or none permission on a web configuration item.
l The CLI structure differs from the web UI menu. Therefore, the CLI permission control of a role is
not the same as the previous operations on the web UI.
l On the administrator Web UI, the configuration rights are read-write, read-only, and none; on the
CLI, the rights are read-write and none. The read-only right on the Web UI is treated as the none
right on the CLI. If the configuration right of a user is read-only on the Web UI, the user can view
configurations on the Web UI, but cannot view the configurations on the CLI.
Except the role, each administrator has a level. In common cases, levels are configured only
for CLI administrators. The FW provides the following default level-role mappings for the
administrators that have levels configured but not bound to any role:
l 1: Monitoring level corresponds to Configuration administrator (monitoring).
l 2: Configuration level corresponds to Configuration administrator.
l 3: Management level to the 15th level correspond to System administrator.
That is to say, level-2 administrators have the operation permission of configuration
administrators.
On the FW, the role is the only factor that determines administrator permissions, especially
for CLI administrators. The level alone cannot determine the commands that can be executed
by a CLI administrator. For example, the default level of A feature commands is level-2, and
the level-2 administrator corresponds to the configuration administrator role. If the
configuration administrator does not have permission on feature A, the level-2
administrator cannot execute the commands of feature A.
NOTICE
Note the following when you use roles to control administrator permissions:
l If an administrator account is bound to a specific role, the level of the administrator role
takes precedence over the server authorization.
l The default administrator admin is not subject to control (no matter what method is used
for the login) and has permissions on all commands and web configurations except those
of the function.
l For CLI administrators using passwords for authentication, their permissions are
determined by the configurations on the administrator page.
Administrator Authentication Method

The FW authenticates an administrator account in one of the following modes before allowing
the administrator to log in:

l Local authentication
Both the administrator account and password are stored on the FW.
l Server authentication:
l Server and local authentication
The FW performs server authentication first. The FW performs local authentication only
if it fails to connect to the authentication server.
After the administrator account is created, the virtual system or authentication domain of a
user name must be obtained to log in to the device. For example, user username on virtual
system vsys with domain (domainname) authentication uses user name
username@domainname@@vsys to log in to and manage the FW.
Administrator Accounts
Table 1-11 shows the default administrators of the FW.
Table 1-11 Default administrators

Account Password Role Description
admin Admin@123 System administrator The system administrator logs in

to the device for the first time
using the web UI or console port
and creates administrators. Only
the system administrator can
create other administrators.
audit- Admin@123 Audit administrator

admin
api-admin admin@123 API administrator Invoke a NETCONF API to

access the FW.
To secure FW, you are advised to follow the minimum authorization principle and plan
administrator accounts with different permissions to avoid administrator account sharing. If
default roles cannot meet requirements, you can create new administrator roles.
Administrator Login Control

After configuring the administrator account, permission, and login method, you must
configure the administrator login control function on the FW. Otherwise, the administrator
cannot log in.
l For the :
l For the :
– If the administrator logs in through the management port MGMT, which has been
added to a security zone and has the access control function enabled by default, the
login succeeds, and no security policy is required.
– If the administrator wants to log in through a service interface (not the management
port), you can add the service interface to a security zone and enable the access
control function on the interface, or configure a security policy for the interzone

between the Local zone and the zone where the interface resides, to permit the
login.
For details on the configuration of the access control function on an interface, see 4.1
Interfaces.
1.3.1.2 Administrator Interfaces Overview

An administrator interface is a unified page on which administrators using a certain login
method are managed and not bound to specific administrators.
When an administrator logs in, the device automatically assigns the administrator an idle
administrator interface with the minimum number by login method. The administrator
interface configurations control the login process.
Table 1-12 shows the relationship between administrator interfaces and login methods.
Table 1-12 Administrator interface

Login Administrator Description
Meth Interface
od
Web Web-based Controls the web login behavior, such as setting timeout
administrator period after login and account lockout upon the failed
interface login.
Telnet/ CLI Virtual Controls Telnet or STelnet login behavior. By default, the
STelne admini Type service supports five VTY interfaces. A maximum of 15
t strator Terminal interfaces can be supported. The number of VTY
interfac (VTY) interfaces determines the maximum number of
e interface concurrent Telnet or STelnet administrators.
If an administrator logs in, the device automatically
assigns an idle VTY interface to the administrator in
order.
NOTICE
During Telnet login, data and passwords are transmitted in
plaintext mode, causing security risks. To secure data
transmission, use STelnet instead.
CLI Administrator Interface Numbering Methods

The CLI administrator interfaces are distinguished by number. A user must access the
administrator interface view to configure functions. There are two types of CLI administrator
interface numbers.
l Relative numbers
The same type of administrator interfaces uses relative numbers, which are in the format
of type + number.
Relative numbers apply to administrator interfaces of the same type.
l Absolute numbers
Absolute numbers apply to all types of administrator interfaces on a FW.

Table 1-13 lists relative and absolute numbers of the console, VTY, and WCON interfaces on
a FW.
Table 1-13 Relative and absolute numbers of the console, VTY, and WCON interfaces
CLI Absolute Relative Number
Administrat Number
or Interface
VTY 34 to 38 VTY0 to VTY14

34 is mapped to VTY0.
NOTE
You can run the display user-interface command on a FW to display the numbers of CLI administrator
interfaces.
CLI Administrator Interface Authentication Modes

The web administrator interface does not have an independent authentication mode but uses
the administrator authentication mode. Table 1-14 lists authentication modes for CLI
administrator interfaces.
Table 1-14 Authentication modes

Aut VTY Description
hent
icati
on
Mod
e
AAA Supporte If Authentication, Authorization and Accounting (AAA) authentication

d is enabled on CLI administrator interface, an administrator must enter
an administrator account and a password to log in to the FW. The
administrator can log in to an administrator interface only after being
authenticated by the FW. For description of the administrator
authentication mode, see 1.3.1.1 Administrator Overview. By
default, the local account is admin, and the password is Admin@123.
Pass Supporte A FW authenticates an administrator based only on a password. The

word d and password of an administrator is set on the interface to which the
enabled administrator logs in. The password mode is not widely used because
by the mode does not require an administrator account and is insecure.
default
CLI Administrator Interface Levels

To secure the CLI administrator interface not using AAA domain authentication, you can
specify the level of the CLI administrator interface (from 1 to 15). An administrator interface
of a specific level allows an administrator to execute commands lower than or equal to the

level. For example, a level 2 interface allows an administrator to execute commands of levels
0, 1, and 2 only.
NOTE
If the CLI administrator interface uses AAA domain authentication, the administrator account level is
prior to the administrator interface level. The administrator interface level takes effect only when the
administrator account level is not set.
1.3.2 Restrictions and Precautions

Read this section carefully before you configure Administrators.
l The FW controls administrator permissions based on administrator roles. The role of an
administrator determines the features that the administrator can configure. The level
alone cannot determine the commands that can be executed by a CLI administrator. For
example, the default level of A feature commands is level-2. If a level-2 administrator
needs to configure A feature, the administrator must be assigned the role that has the
permission to configure A feature. Otherwise, the level-2 administrator cannot execute
the commands of feature A.
l If an administrator logs in using an account in user-name@domain-name format, the
service-type administrator-access command must be run in domain-name to allow
administrator access.
1.3.3 Configuring an Administrator Using the Web UI

This section describes how to configure an administrator on the web.
1.3.3.1 (Optional) Creating an Administrator Role

This section describes how to create an administrator role.
Step 1 Choose System > Admin > Administrator Role.
Step 2 Click Add.
Step 3 Set the administrator role parameters to the desired values.

If the operation is successful, a new administrator role is displayed in the Administrator
Role List page.
Repeat the preceding steps to add another administrator role.
The administrator role referenced by an administrator cannot be deleted.
Table 1-15 lists administrator role parameters.

Table 1-15 Administrator role parameters

Name Name of an administrator role.

The value is a string of 1 to 64 characters. The name cannot
contain the following characters: pipe characters (|), dashes (/),
backward dashes (\), equal signs (=), number signs (#),
ampersands (&), colons (:), asterisks (*), question marks (?),
quotation marks ("), greater than symbols (<), less than
symbols (>), or spaces.
The role name must be unique on a FW.
Description Description of an administrator role.

The value is a string of 1 to 64 characters. The name cannot
contain the following characters: pipe characters (|), dashes (/),
backward dashes (\), equal signs (=), number signs (#),
ampersands (&), colons (:), asterisks (*), question marks (?),
quotation marks ("), greater than symbols (<), less than
symbols (>), or spaces.

Permission Control Permission for modules. Select one of the following options:
Modules l Read-write: Indicates the access and control permission on
the selected content.
l Read-only: Indicates only the access permission on the
selected content.
l None: Indicates no access or control permission on the
selected content. This is the default permission.
NOTE
l Only the default role system-admin has the Read-write
permission to SNMP module, even though the Read-write
permission to System > Setup has been configured when a role is
created.
permission to admin module, even though the Read-write
permission to System has been configured when a role is created.
permission to Log configuration module, even though the Read-
write permission to System has been configured when a role is
created.
permission to System upgrade module, even though the Read-
write permission to System has been configured when a role is
created.
permission to Configuration file Management module, even though
the Read-write permission to System has been configured when a
role is created.
permission to the Diagnosis Info module, even though the Read-
write permission to Monitor has been configured when a role is
created.
permission to the Quintuple Packet Capture module, even though
the Read-write permission to Monitor has been configured when
a role is created.
permission to IPv6 configuration module, even though the Read-
write permission to Dashboard has been configured when a role is
created.
Step 4 Click OK.
----End
1.3.3.2 Creating an Administrator Account

This section describes how to configure an administrator account.
Step 1 Choose System > Admin > Administrators.
Step 2 Click Add.

Step 3 Set the administrator parameters.

The new administrator will be listed in the Administrator List.
Repeat the preceding steps to create more administrators.
Table 1-16 lists administrator parameters.
Table 1-16 Administrator parameters

User Name Account of an administrator.

The value is a string of 1 to 64 characters. The name contains
letters, digits, and symbols.
The account must be unique on a FW.
Authentication Type Authentication type for an administrator:

l Local Authentication: A FW uses the locally configured
account and password to attempt to authenticate an
administrator before an administrator can log in to the FW.
l Server Authentication: A FW uses the account and
password configured on an authentication server to attempt
to an administrator before the administrator can log in to
the FW.
l Server Authentication/Local Authentication: A FW
performs server authentication. Only if the FW fails to
connect to an authentication server, the FW performs local
authentication.
Authentication Server Existing or new authentication server.
Password/Confirm Password of an administrator.

Password This parameter must be specified if Authentication Mode is
set to Local Authentication or Server Authentication/Local
Authentication.
Role Name of an administrator role.

A specific role is granted specific permission. Choose System
> Admin > Administrator Role to view administrator roles
and their permissions.
Trusted Host IP address range of the hosts that can log in to the FW. The
value is in the format of IP address/mask. For example,
10.1.1.1/24 or 10.1.1.1/255.255.255.0 can be entered.
To add an address range, click and enter the range. A
maximum of 10 IP addresses ranges can be specified.
Advanced

Service Type Login method, which can be WEB, Telnet, SSH, console, FTP,
and API.
NOTE
l After the FTP is specified, the system automatically generates an
FTP directory for the administrator. By default, the FTP directory
name is hda1:.
l There are security risks if the service type is configured to be
Telnet or FTP. So it is suggested to configure the service type to be
SSH.
l If the administrator service types are changed, the login
administrator will be forced offline.
l The API service is mutually exclusive with other service types. If
you specify the API service type, you cannot specify other service
types.
SSH Authentication SSH authentication method, which can be:

l RSA
l PASSWORD-RSA: allows the FW to use both the Revist-
Shamir-Adleman (RSA) algorithm and a password to
authenticate an administrator.
l PASSWORD
l All: allows the FW to use either RSA or password
authentication to authenticate an administrator.
This item is required when you create an SSH authentication
account. The default authentication method is PASSWORD.
NOTE
When RSA or DSA authentication is used, the priorities of users
depend on the priorities of the VTYs used by the users for access.
RSA Key Value of an RSA key used to authenticate an administrator.

This parameter can be configured only when SSH
Authentication Mode is set to RSA, PASSWORD-RSA, or
All.
To set an RSA key, perform either of the following operations:
l Select an existing RSA key.
l Create an RSA key.
1. Click Manage RSA Key.
2. Click Add.
3. Enter a name in the Public Key Name text box.
4. Enter a key in the Key text box for an RSA peer. The
key is generated by an SSH client, and you can copy and
paste the key in the Key text box.
5. Click Apply.

NOTE
By default, an administrator created using the web UI can log in to the device from a web page.
Interface access control, administrator service type, and enabled service on the device determine the
login method. For example, if an administrator wants to log in using HTTPS through the management
interface, the management interface must enable the HTTPS access control, the administrator account
must support HTTPS, and the device must enable HTTPS. For detailed configuration process, see 1.3.5
Configuration Examples.
Step 4 Click OK.
----End
Follow-up Procedure
Modify administrator parameters. You can click of the administrator whose parameters
need to be modified.
NOTE
To change the password of an administrator, enter the current administrator account password in the
Please input the administrator current password dialog box that is displayed and then click Confirm.
1.3.3.3 Configuring Device Services

This section describes how to enable the HTTP, HTTPS, and SSH services of the FW.
Adjusting HTTPS Server Parameters

By default, the HTTPS service with port number 8443 is enabled on the FW. After logging in
to the FW through HTTPS, an administrator cannot disable the HTTPS service or change the
HTTPS service port on the web UI.
Step 1 Choose System > Admin > Settings.

Step 2 Enter a timeout period in Web Timeout.
If you do not perform any action before the specified web service timeout period elapses, the
FW displays a web service timeout message prompting you to log in again.
The default timeout period is 10 minutes. Using the default value is recommended.
Step 3 In Max. Online Web Users, enter the maximum number of online web administrators.
Step 4 Click Apply.
----End
Enabling the Telnet Service
NOTICE
During Telnet login, data and passwords are transmitted in plaintext mode, causing security
risks. To secure data transmission, use STelnet instead.
Telnet is a FW function as a server. Telnet on the FW provides access services.

1. Choose System > Admin > Settings.

2. Select Enable for Telnet Service.
3. Click Apply.
Enabling the FTP Service
NOTICE
During FTP login, data and passwords are transmitted in plaintext mode, causing security
risks. To secure data transmission, use SFTP instead.
FTP is a FW function as a server. FTP on the FW provides access services.

2. Select Enable for FTP Service.
3. Click Apply.
Enabling Password Management

If an administrator logs in to the FW after password management function is enabled, the FW
will prompt the administrator to perform the following operations based on the administrator
account and password status:
l If the administrator logs in to the FW for the first time after password management
function is enabled, the FW prompts the administrator to change the password.
Otherwise, the administrator fails to log in.
l If the administrator's password has expired, the FW will prompt the administrator to
change the password. Otherwise, the administrator fails to log in.
2. Select Enable in Password Management.
3. Enter the password validity period in Password Valid Days.
4. Click Apply.
Enabling the STelnet or SFTP Service

SSH Telnet (STelnet) is a secure Telnet service. A FW functions as a Telnet server. It
authenticates Telnet clients and encrypts data exchanged between the Telnet server and
clients. STelnet on the FW provides secure access services.
SSH FTP (SFTP) is a secure FTP service. A FW functions as an FTP server. It authenticates
FTP clients and encrypts data exchanged between the FTP server and clients. SFTP on the
FW provides secure file transfer services.
Step 2 Expand SSH Configuration, perform one of the following operations:

l Select Enable for STelnet Service.
l Select Enable for SFTP Service.

Step 3 Set the following parameters.
Table 1-17 System parameters

SSH Port Number of a listening port for STelnet or SFTP.

On a FW SSH server providing STelnet and SFTP services, if a
new port number is set, the FW must disconnect all the
existing STelnet and SFTP connections to clients and then re-
establish connections to clients using the new port number.
Authentication Times Maximum number of SSH authentication attempts allowed. If

the number of failed attempts reaches the maximum number,
the FW locks out an administrator for 10 minutes.
Authentication Timeout Timeout period (seconds) for SSH user authentication. If an

SSH client fails to be authenticated within the specified
authentication timeout period, the SSH client must re-initiate
an SSH connection.
Key Generation Interval Interval (hours) at which a FW SSH server generates a key.
SSH User Level Level of an administrator that uses SSH to log in to a FW.
A larger value indicates a higher level.
Step 4 Click Apply.
----End
Configuring the Northbound Interface

Northbound interfaces are developed to provide application programs with a series of specific
rules and requirements for mutual communication.
The northbound interfaces use SSH to communicate with third-party clients. For details on
environment construction and service configuration using a northbound API, refer to the
Northbound API Secondary Development Guide.

Step 2 In NETCONF Port, enter a port number.
Step 3 SelectEnable for NETCONF.
The default NETCONF port is 830.
Enabling NETCONF port after NETCONF is enabled will disconnect online users.
Step 4 Click Apply.
----End
1.3.4 Configuring an Administrator Using the CLI

This section describes how to configure an administrator using the CLI.

1.3.4.1 (Optional) Creating an Administrator Role

If the default administrator role cannot meet requirements, you can define new administrator
roles.
Procedure
Step 1 Access the system view.
system-view
Step 2 Access the AAA view.
aaa
Step 3 Create an administrator role and access the administrator role view.
role role-name
The administrator role referenced by an administrator cannot be deleted.
Step 4 Optional: Rename an administrator role.
rename new-role-name
Step 5 Optional: Add a description of an administrator role.
description description-information
Step 6 Grant the role the permission for configuration modules.
NOTE
feature-name is the module name. You can set one or more module names during configuration.
Operation Command
Grant permission for the dashboard module. dashboard { none | read-only | read-
write }
Grant permission for the monitor module. monitor { none | read-only | read-write }
[ feature-name ]
Grant permission for the network module. network { none | read-only | read-write }
[ feature-name ]
Grant permission for the object module. object { none | read-only | read-write }
[ feature-name ]
Grant permission for the policy module. policy { none | read-only | read-write }
[ feature-name ]
Grant permission for the system module. system { none | read-only | read-write }
[ feature-name ]
----End
1.3.4.2 Creating an Administrator Account (Local Authentication)

This topic describes how to create an administrator account for local authentication.

Procedure
Step 1 Set the authentication mode to AAA for the administrator UI.
1. Run the system-view command to access the system view.
2. Run the user-interface [ ui-type ] first-ui-number [ last-ui-number ] command to access
the administrator user interface view.
3. Run the authentication-mode aaa command to set the authentication mode to AAA.
4. Run quit to return to the system view.
Step 2 Create an administrator.
1. Run the aaa command to access the AAA view.
2. Run the manager-user user-name command to configure an administrator account and
access the administrator view.
3. Run the service-type { api | ftp | ssh | telnet | terminal | web } * command to set the
service type for the administrator account.
By default, no service type is specified for an administrator created using the CLI.
NOTE
There are security risks if the service type is configured to be Telnet or FTP. So it is suggested to
configure the service type to be SSH.
Interface access control, administrator service type, and enabled service on the device determine
the login method. For example, if an administrator wants to log in using HTTPS through the
management interface, the management interface must enable the HTTPS access control, the
administrator account must support HTTPS, and the device must enable HTTPS. For detailed
configuration process, see 1.3.5 Configuration Examples.
If administrator service types are changed, the service types of online administrators are not
changed, but for the administrators logging in after service types are changed, the new service
types take effect.
If the administrator service types are changed, the login administrator will be forced offline.
The service types of virtual system administrators can be Web, Telnet, and SSH only.
The API service is mutually exclusive with other service types. If you specify the API service
type, you cannot specify other service types.
4. Run the password [ cipher cipher-password ] command to set a password for the
administrator account.
When setting a password, note the following points:
– The value is a string that contains 8 to 64 characters.
– To enhance security, a password must meet the minimum strength requirements,
that is, the password needs to contain at least three types of the following
characters: uppercase letters (A to Z), lowercase letters (a to z), digits (0 to 9), and
special characters, such as exclamation points (!), at signs (@), number signs (#),
dollar signs ($), and percent (%).
– The password cannot contain more than two identical characters in a row.
– The password cannot be the same as the administrator name or reverse of the
administrator name.
– The interactive mode is recommended for creating administrator passwords because
the passwords configured by the cipher password command are not safe.
– A new administrator can use Admin@123 as the password but will be prompted to
change it upon login.

5. Run the quit command to return to the AAA view.
Step 3 Set the administrator authentication mode to local authentication.

NOTE
By default, the authentication scheme is default, and the administrator authentication mode is local
(local authentication).
1. Run the authentication-scheme scheme-name command to create an authentication
scheme and access the authentication scheme view.
2. Run the authentication-mode local command to configure the local authentication.
3. Run the quit command to quit the AAA view.
Step 4 Optional: Create an authentication domain.

1. Run the domain domain-name to create a domain and access the domain view.
2. Run the authentication-scheme scheme-name command to bind the authentication
scheme to the domain.
3. Run the service-type administrator-access command to allow administrators to access
the authentication domain.
Step 5 Configure the permission and other attributes for the administrator account.
1. Control the administrator permission based on the administrator role or level.
In the AAA view, run the bind manager-user manager-name role role-name command
to bind the administrator account to a role.
If the administrator account is not bound to any role, you can run the level level
command in the administrator view to set the administrator level. The FW will determine
the administrator role based on the administrator level according to the following
mappings:
– 1: Monitoring level corresponds to Configuration administrator (monitoring).

– 2: Configuration level corresponds to Configuration administrator.
– 3: Management level to the 15th level correspond to System administrator.
NOTE
– The administrator role is prior to the administrator level. If an administrator is bound to a role,
the administrator level does not take effect.
– If the administrator permission is changed, the login administrator will be forced offline.
2. Optional: In the administrator view, configure attributes for the administrator account.
Operation Command
Configure an FTP directory. ftp-directory directory

NOTE
If administrator FTP directories are changed,
the FTP directories of online administrators
are not changed, but for the administrators
logging in after FTP directories are changed,
the new FTP directories take effect.
Set the maximum number of logged-in access-limit max-number

users with the same administrator
account.

Operation Command
Specify the status of an administrator state { active | block }

account.
You can specify either of the following
parameters:
– active: The administrator account is
available.
– block: The administrator account is
unavailable.
Bind the administrator account to the acl-number acl-number

ACL.
Before binding, run the rule command to
configure the ACL rule.
3. Optional: In the AAA view, enable the function of locking out the administrators that
fail the authentication.
This function is invalid to the console administrators. After an administrator account is

locked, using the account to log in fails even if the IP address is changed or another
mode (except the console port mode) is used. The administrator account is unlocked only
after the lockout duration expires.
a. Run the lock-authentication enable command to enable the administrator account

lockout function.
b. Run the lock-authentication failed-count count command to set the limit of login
authentication attempts.
c. Run the lock-authentication timeout timeout command to set the lockout duration
for administrator accounts.
4. Optional: In the AAA view, enable the administrator password change function.
If an administrator logs in to the FW after password change function is enabled, the FW

will prompt the administrator to perform the following operations based on the
administrator account and password status:
– If the administrator logs in to the FW for the first time after password change
function is enabled, the FW prompts the administrator to change the password.
Otherwise, the administrator fails to log in.
– If the administrator's password is about to expire in 10 days, the FW will prompt the
administrator to change the password.
– If the administrator's password has expired, the FW will prompt the administrator to
change the password. Otherwise, the administrator fails to log in.
You cannot change the password to any of the latest 10 passwords.
a. Run the manager-user password-modify enable command to enable the

administrator password change function.
b. Run the manager-user password valid-days days command to configure the
validity period for administrator passwords.

The default validity period for administrator passwords is 90 days.
----End
1.3.4.3 Creating an Administrator Account (Server Authentication)

This topic describes how to create an administrator account for server authentication.
Procedure
Step 1 Set the authentication mode to AAA for the administrator UI.
1. Run the system-view command to access the system view.
2. Run the user-interface [ ui-type ] first-ui-number [ last-ui-number ] command to access
the administrator user interface view.
3. Run the authentication-mode aaa command to configure the AAA authentication
mode.
4. Run the quit command to return the system view.
Step 2 Set the administrator authentication mode to server authentication.

NOTE
By default, the authentication scheme is default, and the administrator authentication mode is local
(local authentication).
1. Configure an authentication scheme.
a. Run the aaa command to access the AAA view.
b. Run the authentication-scheme scheme-name command to create an authentication
scheme and access the authentication scheme view.
c. Run the authentication-mode { ad | hwtacacs | ldap | radius } * command to
configure the authentication mode.
d. Run the quit command to return to the AAA view.
2. Configure the authorization scheme.
a. Run the authorization-scheme scheme-name command to create authorization
scheme.
b. Configure the authorization mode. The default mode is local, indicating local
authorization.
n Run the authorization-mode hwtacacs command to set the HWTACACS
authorization mode for user name-based authorization.
For the FW, HWTACACS authorization supports not only user-specific
authorization, but also command-specific authorization. After command-
specific authorization is enabled and an administrator of a specific level logs in
to the FW, the commands that the administrator enters can be executed only
after being authorized by the HWTACACS server. Configure command-
specific authorization.
1) Run the authorization-cmd privilege-level hwtacacs [ local ] command
to configure the command-specific authorization for an administrator of a
specific level.
To enable the command-specific authorization, you must configure an
HWTACACS server template on the FW, apply this template in the view

of the domain to which the administrator of the specific level belongs,

and perform the following configurations on the HWTACACS server:
○ Add administrator information on the HWTACACS server.
○ Specify the commands to be authorized on the HWTACACS server
for the user group to which the administrator belongs.
For how to create an administrator and configure the commands to be
authorized by user group, refer to HWTACACS server documents.
By default, the command-specific authorization is disabled. That is, an
administrator of any level can execute only commands of or below its
level after logging in to the FW.
NOTE
HWTACACS command-based authorization is independent from authorization
modes (authorization-mode) and authentication modes (authentication-mode).
That is, even if HWTACACS command-based authorization is implemented on
an administrator, non-HWTACACS authentication and authorization modes can
be implemented on this administrator as well.
2) Run the authorization-cmd no-response-policy { online | offline [ max-
times max-times-value ] } command to configure a no response policy in
case that the HWTACACS server is unavailable or in case of no
administrator is configured on the FW.
By default, administrator can remain online even though the command-
specific authorization fails.
n Run the authorization-mode local command to set the local authorization
mode for user name-based authorization.
If only RADIUS server authentication is configured for the administrator, the
administrator level can be set through the command line. By default, the
administrator level is 0 for Telnet and login modes other than web login. The
administrator level is 1 for web login.
1) Run the user privilege level level command to set the administrator level
for Telnet login. The default value is 0.
2) Run the web-manager user privilege level privilege-level command to
set the administrator level for web login. The default value is 1.
c. Run the quit command to return to the AAA view.
3. Configure the authentication server based on the authentication and authorization
schemes.
When an authentication server is used to authenticate administrator accounts, the FW
acts as the proxy client for the authentication server and sends the user name and
password to the server for authentication. For details, see 10.12 Authentication Server.
Step 3 Bind the authentication scheme for the administrator account or domain based on the server
authentication mode and reference the server template.
l Bind the authentication scheme for the administrator and reference the template based on
the server authentication mode.
If administrator domain authentication is not used, the administrator account must be
created on the FW, and the password is saved on the authentication server. After an
administrator is created, the administrator uses User Name/Password to log in to and
manage the FW.
– In the AAA view, run the manager-user user-name command to configure an
administrator account and access the administrator view.

– Run the service-type { api | ftp | ssh | telnet | terminal | web } * command to set
the service type for the administrator account.
By default, no service type is specified for an administrator created using the CLI.
NOTE
There are security risks if the service type is configured to be Telnet or FTP. So it is
suggested to configure the service type to be SSH.
Interface access control, administrator service type, and enabled service on the device
determine the login method. For example, if an administrator wants to log in using HTTPS
through the management interface, the management interface must enable the HTTPS access
control, the administrator account must support HTTPS, and the device must enable HTTPS.
For detailed configuration process, see 1.3.5 Configuration Examples.
If the administrator service types are changed, the login administrator will be forced offline.
The service types of virtual system administrators can be Web, Telnet, and SSH only.
The API service is mutually exclusive with other service types. If you specify the API
service type, you cannot specify other service types.
– Run the authorization-scheme scheme-name command to bind the authentication
scheme for the administrator account.
– Reference the server template.
n Run the radius-server template-name command to reference the RADIUS
server template.
n Run the hwtacacs-server template-name command to apply the HWTACACS
server template.
n Run the ad-server template-name command to reference the AD server
template.
n Run the ldap-server template-name command to reference the LDAP server
template.
l Create an authentication domain.
If administrator domain authentication is used, the administrator account and password
must be created and saved on the authentication server. The FW does not have user
information configured. After an administrator is created, the administrator uses User
Name@Authentication Domain/Password to log in to and manage the FW.
NOTE
When administrator domain authentication is used, the administrator does not have any role. The
administrator level is set on the server. If not configured, the administrator level is determined by
command line authorization.
The administrator with server domain authentication has all service types without additional
configuration.
– Create an administrator on the server. For details, see the server-related document.
– Run the domain domain-name to create a domain (user group) and access the
domain view.
– Optional: Run the authorization-scheme scheme-name command to configure the
authorization scheme for the domain.
This authentication scheme must be the same as that configured in the AAA view.
– Apply the server template based on the selected authentication server.
Run the radius-server template-name command to apply the RADIUS server
template.
– Run the service-type administrator-access command to allow administrators to
access the authentication domain.

Step 4 Configure the permission and other attributes for the administrator account.
If no authentication domain is planned for the administrator, the administrator account is

created on the local device, and other functions can be configured for the administrator
account as required.
1. Control the administrator permission based on the administrator role or level.
In the AAA view, run the bind manager-user manager-name role role-name command
to bind the administrator account to a role.
If the administrator account is not bound to any role, you can run the level level
command in the administrator view to set the administrator level. The FW will determine
the administrator role based on the administrator level according to the following
mappings:
– 1: Monitoring level corresponds to Configuration administrator (monitoring).

– 2: Configuration level corresponds to Configuration administrator.
– 3: Management level to the 15th level correspond to System administrator.
NOTE
– The administrator role is prior to the administrator level. If an administrator is bound to a role,
the administrator level does not take effect.
– If the administrator permission is changed, the login administrator will be forced offline.
2. Optional: Enable the function of locking out the administrators that fail the
authentication.
This function is invalid to the console administrators. After an administrator account is

locked, using the account to log in fails even if the IP address is changed or another
mode (except the console port mode) is used. The administrator account is unlocked only
after the lockout duration expires.
a. Run the lock-authentication enable command to enable the administrator account

lockout function.
b. Run the lock-authentication failed-count count command to set the limit of login
c. Run the lock-authentication timeout timeout command to set the lockout duration
for administrator accounts.
3. Optional: Configure attributes for the administrator account.
Operation Command
Configure an FTP directory. ftp-directory directory

NOTE
If administrator FTP directories are changed,
the FTP directories of online administrators
are not changed, but for the administrators
logging in after FTP directories are changed,
the new FTP directories take effect.
Set the maximum number of logged-in access-limit max-number

users with the same administrator
account.

Operation Command
Specify the status of an administrator state { active | block }

account.
parameters:
– active: The administrator account is
available.
– block: The administrator account is
unavailable.
Bind the administrator account to the acl-number acl-number

ACL.
Before binding, run the rule command to
configure the ACL rule.
----End
1.3.4.4 (Optional) Configuring the Web UI

This section describes how to configure the administrator web UI.
Context
The FW enables ports 80 and 8443 to provide the HTTPS service by default. When you use
the web browser to access port 80, the FW automatically redirects the access to port 8443 for
you to log in through HTTPS.
You can run the undo web-manager enable command to disable port 80.
By default, if you fail to access the web page for three consecutive times, your account will be
locked for 30 minutes. In addition, the FW provides the web administrator page locking
function. If three administrator accounts that share the same IP address are locked within a
specific period, the web page will be locked for a period. The IP address cannot be used to
access the web page within the period. Therefore, the function prevents the passwords of
administrator accounts from be cracked by brute force attacks.
Procedure
system-view
Step 2 Adjust HTTPS server parameters.

l Configure HTTPS with a default certificate.
When a PC (client) attempts to use HTTPS to log in to a FW, the FW (server) delivers a
default certificate to the PC. The certificate is assigned by an unknown Certificate
Authority (CA). The PC cannot verify the certificate, and is therefore vulnerable to
attacks.

NOTE
If you do not use the default port to log in, run the undo web-manager security enable [ port
port-number ] command in advance to disable the HTTPS service and default port 8443. Then
enable the HTTPS service again.
a. Run the web-manager security enable [ port port-number ] command to enable

the HTTPS service.
b. Specify an SSL protocol and an encryption algorithm.
The FW (server) and a PC (client) must run the same SSL protocol and use the
same encryption algorithm. An inconsistency causes an SSL negotiation failure.
i. Specify an SSL or TLSV protocol.
web-manager security version { { sslv3 | tlsv1 } * | all }
The FW supports TLSv1 by default.
After you specify a new SSL protocol type, new connections will use the new
SSL protocol for negotiation, and the existing connections still use the original
SSL protocol for negotiation.
ii. Specify an encryption algorithm.
web-manager security cipher-suit { high-strength | all }
By default, the FW supports high strong encryption algorithms.
NOTICE
If you specify the all parameter, insecure encryption algorithms are included
which may pose security risks. You are advised to set the high-strength
parameter instead.
l Configure HTTPS with a specified certificate.

When a PC (client) uses HTTPS to log in to a FW, the FW (server) delivers a specified
certificate to the PC. The certificate is assigned by a CA that the PC can recognize.
Therefore the PC can establish a secure connection to the FW based on the valid
certificate.
NOTE
The certificate can be issued by a worldwide known certificate authority or a PC that supports the
certificate service. The PC must import a CA certificate before being able to authenticate a
certificate sent by the FW.
a. The FW generates a certificate request file, sends the file to the CA server to apply
for the certificate, and imports the local certificate to the FW. For the configuration
procedure, see 10.7 Certificate.
b. Optional:
Import the CA certificate obtained from the CA server which the FW applies for a
certificate to the browser. For details, see the instructions to the Firefox or Internet
Explorer.
NOTE
Although the client can still access the FW through HTTPS even if the CA certificate is not
imported to the browser, the client cannot authenticate the access and is vulnerable to
attacks.

c. Configure the FW to send a certificate to the client when the client accesses the FW
through HTTPS.
web-manager security server-certificate file-name
d. Enable HTTPS.
web-manager security enable [ port port-number ]
Enter the address of a FW following the string of "https://" in the address bar on the
web browser of the PC to log in to the FW. Ensure that the address is the same as
that specified in the certificate.
e. Configure an SSL or TLS protocol and an encryption algorithm. For the
configuration procedure, see Specify an SSL protocol and an encryption
algorithm.
Step 3 Optional: Set the timeout period for a web service.
web-manager timeout minutes
The default timeout period is 10 minutes.
----End
1.3.4.5 (Optional) Managing a CLI Administrator Interface

This section describes how to manage a CLI administrator interface, how to set console
attributes, how to configure administrator interfaces to exchange messages, and how to log
out online administrators.
Configuring a CLI Administrator Interface

system-view
Step 2 Optional: Set the maximum number of available VTY interfaces.
user-interface maximum-vty number
Existing VTY interfaces are assigned specified levels and authentication parameters manually.
If the maximum number of allowed VTY to be set is greater than the number of existing
VTYs, specify a level and a password for the password authentication mode for the new VTY.
You can also specify another authentication mode.
NOTE
By default, the maximum number of VTY administrator interfaces is five.
Step 3 Access the CLI administrator interface view.
user-interface [ ui-type ] first-ui-number [ last-ui-number ]
Step 4 Optional: Enable a terminal service.
shell
By default, the terminal service is enabled on all CLI administrator interfaces.
Step 5 Optional: Configure the CLI administrator interface.

Operation Command
Set the timeout period after which a idle-timeout minutes [ seconds ]

connection between a FW and an
administrator PC is disconnected.
Set the maximum number of lines on each screen-length screen-length

screen.
By default each screen displays a maximum
of 24 lines.
Set the size of the historical command history-command max-size size-value

buffer.
By default, the buffer caches a maximum of
10 historical commands.
Specify a command that a FW automatically auto-execute command command

executes after an administrator logs in to the
FW.
The console interface does not support this
command.
Set the CLI administrator interface priority. user privilege level level
Bind a CLI administrator interface to an acl acl-number { inbound | outbound }

access control list (ACL).
parameters:
l inbound: permits a host request with a
specified address or address range to log
in to the FW.
l outbound: permits a request to log in to
another device through the FW.
NOTE
By default, a VTY interface supports SSH and Telnet.
Step 6 Specify an authentication mode.

NOTE
l If password, or AAA authentication is specified and no level is specified for an administrator

account for AAA authentication, the highest level of commands that an administrator can access is
determined by the CLI administrator interface level.
l If AAA authentication is enabled and a level is specified for an administrator account, the highest
level of commands that an administrator can access is determined by the administrator account level.
l After an authentication mode is specified, the default authentication mode does not take effect. Keep
the new account and password (if configured) secure.
Configure an authentication mode.

l Configure AAA authentication.

a. Specify the AAA authentication mode.
authentication-mode aaa
b. Configure an administrator. For the configuration procedure, see 1.3.4.2 Creating
an Administrator Account (Local Authentication) or 1.3.4.3 Creating an
Administrator Account (Server Authentication).
l Configure password authentication.
Specify the password authentication mode.
authentication-mode password
Specify the password.
set authentication password [ cipher password ]
NOTE
The interactive mode is recommended for creating administrator passwords because the passwords
configured by the cipher password command are not safe.
----End
Configuring Attributes of the Console Port

system-view
Step 2 Access the administrator interface view.
user-interface console interface-number
Step 3 Set console port attributes.
Operation Command
Set the transmission rate. speed speed-value

The default rate is 9600 bit/s.
Specify a flow control mode. flow-control { hardware | none |

The default mode is none. software }
Specify a parity mode. parity { even | mark | none | odd | space }

The default mode is none.
Set stop bits. stopbits { 1.5 | 1 | 2 }

The default stop bit is 1.
Set data bits. databits { 5 | 6 | 7 | 8 }

The default data bits are 8.
----End
Sending Messages to Another CLI Administrator Interface

Administrator interfaces can exchange messages.

Step 1 In the user view, enable the current interface to send messages to another administrator
interface.
send { all | ui-type ui-number | ui-number }
Step 2 Enter a message to be sent and press Ctrl+Z or Enter to send the message.
----End
Logging Out Online Administrators of Another CLI Administrator Interface

You can log out an online administrator that has logged in to another administrator interface.
Step 1 View online administrator information, including interfaces to which the administrators log in.
Write down the administrators to be logged out and their administrator interfaces.
display users
Step 2 In the user view, specify an interface to which administrators logged in are to be logged out.
free user-interface { ui-number | ui-type ui-number }
Step 3 Perform either of the following operations:

l Enter y and press Enter to log out the administrator that logs in to a specified
administrator interface.
l Enter n and press Enter to cancel the logout operation.
----End
1.3.4.6 Maintaining CLI Administrator Interfaces and Administrator Accounts

You can view information about CLI administrator interfaces and administrator accounts.
Run the commands listed in Table 1-18 in any view to display information about CLI
administrator interfaces and administrator accounts.
Table 1-18 Displaying information about CLI administrator interfaces and administrator
accounts
Operation Command
Modify the current current-user password-modify

administrator password.
Display the last display manager-user password-validity information

modification time and [ username user-name ]
remaining valid days of
the administrator
password.
Display the display web-manager { configuration | statistics | users }

configuration of and
login information on
the web UI.

Operation Command
Display administrator display manager-user [ username user-name ]

details. display manager-user [ service-type { api | ftp | ssh | telnet |
terminal | web } ]
Display online display manager-user online-user [ username user-name ]

administrator
information.
Tear down the cut manager-user online-user [ user-id user-id | username

connections of online user-name ]
administrators.
Display administrator display users [ all ]

login information.
Display the display user-interface [ { console number | vty number } | ui-

configurations of CLI number ] [ summary ]
administrator
interfaces.
Display the maximum display user-interface maximum-vty

number of allowed
VTY interfaces.
Display the SSH server display ssh server { status | session }

information.
1.3.5 Configuration Examples

This section provides configuration examples for multiple application scenarios.
1.3.5.1 Example for Logging in to the Web UI Using HTTPS (Default Certificate)
This section provides an example of how to configure HTTPS using the web and log in to the
web UI.
Networking Requirements
Figure 1-6 shows how to configure local authentication administrator webadmin that can use
HTTPS to log in to the web UI on the FW.
Figure 1-6 Networking diagram of logging in to the web UI using HTTPS (default certificate)
Administrator
GE1/0/3
10.3.0.1/24
10.3.0.10/24 FW

Data Planning
Item Data Description
User name webadmin -
Password Myadmin@123 -
Authentication mode Local authentication -
Role service-admin service-admin is a user-defined

role and has permissions only on
the network, policy, and object.
Trusted host 10.3.0.0/24 The administrator area is limited

by IP address.
Service Type WEB -
Web service timeout 5 minutes -

period
Configuration Roadmap
1. Enable the HTTPS server on the interface.
2. Create an administrator role.
3. Create an administrator account and set the authentication mode, administrator role, and
trusted host.
4. Set the web service timeout period.
NOTE
This section describes only how to configure an administrator.
Procedure
Step 1 Enable the HTTPS server on interface GigabitEthernet 1/0/3.
NOTE
If you use the default settings of management interface GigabitEthernet 0/0/0 to log in to the device,
skip this step.
Because the default IP address of the management interface has been set to 192.168.0.1, the interface
has been added to the Trust zone, and the administrator is allowed to log in to the device using HTTPS.
1. Choose Network > Interface.
2. Click for interface GE1/0/3 and set the parameters as follows:
Zone trust
Connection Type Static IP
IP Address 10.3.0.1/255.255.255.0

Management Access HTTPS
3. Click OK.
Step 2 Optional: Create an administrator role for administrator B.

1. Choose System > Admin > Administrator Role.
2. Click Add and set parameters as follows:
Name service-admin
Description policy_object_network_readwrite_and_other_modules_non
e
Popedom
Policy, Object, Read-write

Network
Dashboard, Monitor, None

System
3. Click OK.

1. Choose System > Admin > Administrators.
2. Click Add and set parameters as follows:
User Name webadmin
Authentication Type Local authentication
Password Myadmin@123
Role service-admin
Trusted Host 10.3.0.0/24
Advanced
Service Type WEB
3. Click OK.
Step 4 Enable the HTTPS service (default certificate) and set the service port and web service
timeout period.
2. Select Enable next to HTTPS Service.
3. Click Apply.
Step 5 In the upper right of the page, click Save Then click OK in the dialog box that is displayed.
Step 6 Open a browser and enter https://10.3.0.1:8443.

NOTE
If the browser displays a notification for an insecure certificate, you can continue the browsing.
Step 7 On the login UI, enter user name webadmin and password Myadmin@123 and click Login
to access the web UI.
----End
Configuration Scripts
#
interface GigabitEthernet1/0/3
ip address 10.3.0.1 255.255.255.0
service-manage https permit
#
firewall zone trust
set priority 85
add interface GigabitEthernet1/0/3
#
acl number 2000
rule 5 permit source 10.3.0.0 0.0.0.255
#
web-manager security enable
web-manager timeout 5
#
aaa
authentication-scheme default
#
manager-user webadmin
password cipher %@%@*y:3*ZN}.%%qcL1cC|@XBVMDyDwlB.Wq'6JF(iOz2D8>A\SN%@%@
service-type web
level 15
acl-number 2000
authentication-scheme admin_local
#
bind manager-user webadmin role service-admin
role service-admin
description policy_object_network_readwrite_and_other_modules_none
dashboard none
monitor none
system none
network read-write
object read-write
policy read-write
#
return
1.3.5.2 Example for Logging In to the Web UI Using HTTPS (Specified

Certificate)
This section provides an example for configuring HTTPS (specified certificate) using the CLI
and logging in to the web UI.
Figure 1-7 shows how to configure FW authentication administrator webadmin that can use
HTTPS to log in to the web UI.

Figure 1-7 Networking diagram of logging in to the web UI using HTTPS (specified
certificate)
Administrator
GE1/0/3
10.3.0.1/24
10.3.0.10/24 FW
Data Planning
Administrator Account: webadmin -

Password:
Myadmin@123
Level: 3
Service type: web
Maximum number of
online users: 10
Role service-admin service-admin is a user-defined

role and has permissions only on
the network, policy, and object.
Trusted host 10.3.0.0/24 The administrator area is limited

by IP address.
Web service timeout 5 minutes -

period
1. Assign the administrator and device the certificates from one Certificate Authority (CA)
for connection security.
2. Create an administrator account and configure a trusted host for the administrator.
3. Set an IP address for the administrator PC.
Procedure
Step 1 Configure the certificate.
1. The FW generates a certificate request file. An administrator sends the file to the CA
server through web, disks, or emails to apply for a certificate. The CA server generates a
certificate. The administrator can use HTTP, LDAP, or other methods to download the
CA certificate and local certificate from the server that stores the certificate to the FW
memory and install the certificate. For detailed configuration process, see 10.7
Certificate.

NOTE
CA certificate cep_ca.cer and local certificate cep_local.cer are used as examples.
2. Optional: Obtain the CA certificate and import it to the browser of the administrator PC
(client). For details, refer to the help of the browser.
NOTE
Although the client can still access the device through HTTPS even if the CA certificate is not
imported to the browser, the client cannot verify the certificate and is prone to attacks.
3. Configure the device to send a certificate to the client when the client accesses the device
using HTTPS.
<FW> system-view
[FW] web-manager security server-certificate cep_local.cer
Step 2 Adjust web service parameters.

1. Configure the web service timeout period.
[FW] web-manager timeout 5

2. Optional: Configure SSL and the encryption algorithm.
[FW] web-manager security version tlsv1
[FW] web-manager security cipher-suit high-strength
The device and PC must support the same SSL and encryption algorithm. If not, the SSL
negotiation fails.
3. Configure GigabitEthernet 1/0/3 IP address and enable the HTTPS service.
[FW] interface GigabitEthernet 1/0/3
[FW-GigabitEthernet1/0/3] ip address 10.3.0.1 255.255.255.0
[FW-GigabitEthernet1/0/3] service-manage enable
[FW-GigabitEthernet1/0/3] service-manage https permit
[FW-GigabitEthernet1/0/3] quit
4. Add an interface to the security zone.

[FW] firewall zone trust
[FW-zone-trust] add interface GigabitEthernet1/0/3
[FW-zone-trust] quit

1. Configure a trusted host for the administrator.
[FW] acl
2001
[FW-acl-basic-2001] rule permit source 10.3.0.0 0.0.0.255
[FW-acl-basic-2001] quit
2. Create an administrator role.

[FW] aaa
[FW-aaa] role service-admin
[FW-aaa-role-service-admin] description
policy_object_network_readwrite_and_other_modules_none
[FW-aaa-role-service-admin] dashboard none
[FW-aaa-role-service-admin] monitor none
[FW-aaa-role-service-admin] system none
[FW-aaa-role-service-admin] network read-write
[FW-aaa-role-service-admin] object read-write
[FW-aaa-role-service-admin] policy read-write
[FW-aaa-role-service-admin] quit
3. Create an administrator and bind a role to the administrator.

[FW-aaa] manager-user webadmin
[FW-aaa-manager-user-webadmin] password
Enter Password:
Confirm Password:

[FW-aaa-manager-user-webadmin] service-type web

[FW-aaa-manager-user-webadmin] access-limit 10
[FW-aaa-manager-user-webadmin] acl-number 2001
[FW-aaa-manager-user-webadmin] quit
[FW-aaa] bind manager-user webadmin role service-admin
[FW-aaa] quit
4. Set the IP address of the administrator PC to 10.3.0.10/24.
Step 4 Log in to the FW on the administrator PC.

1. Open a browser and enter https://10.3.0.1:8443.
2. On the login UI, enter user name webadmin and password Myadmin@123 and click
Login to access the web UI.
----End
The configuration script of the administrator and web service is as follows:
#
ip address 10.3.0.1 255.255.255.0
service-manage enable
service-manage https permit
#
firewall zone dmz
set priority 85
#
acl number 2001
rule 5 permit source 10.3.0.0 0.0.0.255
#
web-manager security enable
web-manager timeout 5
#
aaa
authentication-scheme default
#
manager-user webadmin
password cipher %@%@fPXYG8r|>17U(MYaBLw0OE<3BRR/*~[B0>uW"^/){U_>wKB=%@
%@
service-type web
access-limit 10
acl-number 2001
authentication-scheme admin_local
#
bind manager-user webadmin role service-admin
role service-admin
description policy_object_network_readwrite_and_other_modules_none
dashboard none
monitor none
system none
network read-write
object read-write
policy read-write
#
return
1.3.5.3 Example for Logging in to the CLI Using the Telnet (Local Authentication)
By default, the Telnet is disabled on the device. You need to establish a Telnet login
environment. This section provides an example for configuring how to log in to the CLI using
the Telnet.

Context
NOTE
Telnet login is not secure. You are advised to log in to the CLI using STelnet.
Figure 1-8 shows that the FW has a local administrator. The local administrator has some
administrator permissions and can use the Telnet to log in to the CLI only from a local PC for
FW management and maintenance. The FW implements local authentication on
administrators.
Figure 1-8 Networking diagram of logging in to the CLI using the Telnet
Administrator( Telnet ) GE1/0/3
10.3.0.1/24
10.3.0.100/24 FW
Data Planning
VTY interface timeout 5 minutes The default period is 10 minutes.

period
Maximum number of 2 The default value is 3.

authentication attempts
allowed
Lockout period 10 minutes The default period is 30 minutes.
Administrator account/ vtyadmin/ Note down the user name and

password Mydevice@abc password in case you forget them.
IP address of the 10.3.0.100/255.255.255.0 -

administrator's PC
1. Configurations on the FW are as follows:
a. Enable the Telnet service on the FW.
b. Configure the administrator login interface.
c. Configure the VTY administrator interface.
d. Configure the administrator.
2. Configure the IP address of the administrator PC and use the Telnet software to log in to
the VTY interface.

Procedure
Step 1 If you log in to the CLI for the first time, reference Logging In to the CLI Through the
Console Port and establish the Telnet login environment.
Step 2 Enable the Telnet service for IPv4 or IPv6. IPv4 is used as an example.
<FW> system-view
[FW] telnet server enable
Step 3 Optional: Configure the login interface.

NOTE
If you use the default settings of management interface MGMT to log in to the device, do not perform
this step.
has been added to the Trust zone, and the administrator is allowed to log in to the device using Telnet.
1. Configure the interface IP address and interface-based access control and enable the
administrator to log in to the device through Telnet.
[FW-GigabitEthernet1/0/3] service-manage telnet permit

Step 4 Configure the VTY administrator interface.
Set the authentication mode of the VTY administrator interface to AAA and idle
disconnection duration to 5 minutes (the default value is 10 minutes).
NOTE
The number of default VTY administrator interfaces is five. To add more interfaces, run the user-
interface maximum-vty number command.
[FW] user-interface vty 0 4
[FW-ui-vty0-4] authentication-mode aaa
[FW-ui-vty0-4] user privilege level 3
[FW-ui-vty0-4] protocal inbound telnet
[FW-ui-vty0-4] idle-timeout 5
[FW-ui-vty0-4] quit
Step 5 Optional: Configure the Telnet administrator.

NOTE
The default administrator (admin/Admin@123) can use Telnet and web port to log in to the device. If
you use the administrator account to log in to the device, skip this step. Change the default password
upon first login as prompted and keep the new password secure.
1. Create an administrator account.
[FW] aaa
[FW-aaa] manager-user vtyadmin
[FW-aaa-manager-user-vtyadmin] password
Enter Password:
Confirm Password:
[FW-aaa-manager-user-vtyadmin] service-type telnet
[FW-aaa-manager-user-vtyadmin] quit
[FW-aaa] bind manager-user vtyadmin role system-admin
2. Optional: Configure the automatic lockout function upon a failed login.

By default, an account is locked for 30 minutes after three failed login attempts. In the
following example, the account is locked for 10 minutes after two failed login attempts.
[FW-aaa] lock-authentication enable
[FW-aaa] lock-authentication failed-count 2
[FW-aaa] lock-authentication timeout 10
Step 6 Configure the local administrator PC as follows:

1. Set the IP address and subnet mask of the administrator PC to 10.3.1.100 and
255.255.255.0.
2. Run the Telnet software on the PC. Windows OS is used as an example. Choose Start >
Run. The Run window is displayed. Enter telnet 10.3.0.1 in Open.
3. Click OK and start to connect to the FW.
4. On the login page, enter vtyadmin for Username: and press Enter.
5. Enter Mydevice@abc for Password: and press Enter to log in to the VTY interface.
----End
#
telnet server enable
#
ip address 10.3.0.1 255.255.255.0
service-manage telnet permit
#
user-interface vty 0 4
user privilege level 3
protocal inbound telnet
idle-timeout 5
#
aaa
authorization-scheme default
manager-user vtyadmin
password cipher %@%@*y:3*ZN}.%%qcL1cCyDwlB.|@XBVMDWq'6JF(iOz2D8>A\SN%@
%@
service-type telnet
level 15
lock-authentication enable
lock-authentication failed-count 2
lock-authentication timeout 10
bind manager-user vtyadmin role system-admin

#
firewall zone trust
set priority 85
#
return
1.3.5.4 Example for Logging in to the CLI Using the Telnet (RADIUS Server
Authentication)
the Telnet.

Context
NOTE
FW management and maintenance. RADIUS server authentication takes precedence over
local authentication. The FW implements local authentication on administrators only when
the RADIUS server does not respond.
RADIUS Server
172.16.0.2/24
GE1/0/2
Administrator( Telnet ) GE1/0/3 172.16.0.1/24
10.3.0.1/24
10.3.0.100/24 FW
Data Planning

period

allowed

Authentication scheme Name: RADIUS -

Authentication methods:
RADIUS and local

RADIUS server template Name: radius_server -

RADIUS server address:
172.16.0.2
IP address of the 10.3.0.100/255.255.255.0 -

administrator's PC
d. Configure the administrator, authentication scheme, and RADIUS server template.
the VTY interface.
Procedure
<FW> system-view

NOTE
If you use the default settings of management interface GigabitEthernet 0/0/0 to log in to the device, do
not perform this step.


NOTE
[FW-ui-vty0-4] quit
Step 5 Set the interface IP address, assign the interface to a security zone, and configure a security
policy.
Set the interface IP address.

Add the interface to a security zone.

[FW] firewall zone dmz
[FW-zone-dmz] add interface GigabitEthernet1/0/2
[FW-zone-dmz] quit
Configure a security policy.

[FW] security-policy
[FW-policy-security] rule name rule1
[FW-policy-security-rule-rule1] source-zone local
[FW-policy-security-rule-rule1] destination-zone dmz
[FW-policy-security-rule-rule1] destination-address 172.16.0.2 32
[FW-policy-security-rule-rule1] action permit
[FW-policy-security-rule-rule1] quit
[FW-policy-security] quit
Step 6 Configure a server template. In this example, a RADIUS server is used.

[FW] radius-server template radius_server
[FW-radius-radius_server] radius-server authentication 172.16.0.2 1812
[FW-radius-radius_server] quit
Step 7 Configure an authentication scheme.

[FW] aaa
[FW-aaa] authentication-scheme radius
[FW-aaa-authen-radius] authentication-mode radius local
[FW-aaa-authen-radius] quit

NOTE
The default administrator (admin/Admin@123) can use Telnet, web, and console port to log in to the
device. If you use the administrator account to log in to the device, skip this step. Change the default
password upon first login as prompted and keep the new password secure.
[FW] aaa
Enter Password:
Confirm Password:
[FW-aaa-manager-user-vtyadmin] authentication-scheme radius
[FW-aaa-manager-user-vtyadmin] radius-server radius_server

[FW] aaa

255.255.255.0.
----End
#
#
ip address 172.16.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
idle-timeout 5
#
aaa
authentication-scheme radius
authentication-mode radius local
%@
service-type telnet
level 15
authentication-scheme radius
radius-server radius_server

#
firewall zone trust
set priority 85
#
firewall zone dmz
set priority 50
#
security-policy

rule name rule1

source-zone local
destination-zone dmz
destination-address 172.16.0.2 32
action permit
#
return
1.3.5.5 Example for Logging in to the CLI Using the Telnet (HWTACACS Server
Authentication)
the Telnet.
Context
NOTE
FW management and maintenance. HWTACACS server authentication takes precedence over
local authentication. The FW implements local authentication on administrators only when
the HWTACACS server does not respond.
HWTACACS Server
172.16.0.2/24
GE1/0/2
Administrator( Telnet ) GE1/0/3 172.16.0.1/24
10.3.0.1/24
10.3.0.100/24 FW
Data Planning

period


allowed

Authentication scheme Name: hwtacacs -

Authentication methods:
hwtacacs and local
HWTACACS server Name: hwtacacs_server -

template HWTACACS server
address: 172.16.0.2
IP address of the 10.3.0.100/255.255.255.0 -

administrator's PC
d. Configure the administrator, authentication scheme, and HWTACACS server
template.
the VTY interface.
Procedure
<FW> system-view

NOTE
If you use the default settings of management interface GigabitEthernet 0/0/0 to log in to the device, do
not perform this step.



NOTE
[FW-ui-vty0-4] quit
Step 5 Set the interface IP address, assign the interface to a security zone, and configure a security
policy.
Set the interface IP address.

Add the interface to a security zone.

[FW-zone-dmz] add interface GigabitEthernet1/0/2
[FW-zone-dmz] quit
Configure a security policy.

[FW-policy-security] rule name rule1
[FW-policy-security-rule-rule1] source-zone local
[FW-policy-security-rule-rule1] destination-zone dmz
[FW-policy-security-rule-rule1] destination-address 172.16.0.2 32
[FW-policy-security-rule-rule1] action permit
[FW-policy-security-rule-rule1] quit
Step 6 Configure a server template. In this example, a HWTACACS server is used.

[FW] hwtacacs-server template hwtacacs_server
[FW-hwtacacs-hwtacacs_server] hwtacacs-server authentication 172.16.0.2 1812
[FW-hwtacacs-hwtacacs_server] quit
Step 7 Configure an authentication scheme.

[FW] aaa
[FW-aaa] authentication-scheme hwtacacs
[FW-aaa-authen-hwtacacs] authentication-mode hwtacacs local
[FW-aaa-authen-hwtacacs] quit

NOTE
The default administrator (admin/Admin@123) can use Telnet, web, and console port to log in to the
device. If you use the administrator account to log in to the device, skip this step. Change the default
password upon first login as prompted and keep the new password secure.
[FW] aaa
Enter Password:
Confirm Password:
[FW-aaa-manager-user-vtyadmin] authentication-scheme hwtacacs
[FW-aaa-manager-user-vtyadmin] hwtacacs-server hwtacacs_server

[FW] aaa

255.255.255.0.
----End
#
#
ip address 172.16.0.1 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
idle-timeout 5
#
aaa
authentication-scheme hwtacacs
authentication-mode hwtacacs local
%@

service-type telnet
level 15
authentication-scheme hwtacacs
hwtacacs-server hwtacacs_server

#
firewall zone trust
set priority 85
#
firewall zone dmz
set priority 50
#
security-policy
rule name rule1
source-zone local
action permit
#
return
1.3.5.6 Example for Logging in to the CLI Using STelnet (Password

Authentication)
This section provides an example for configuring the administrator PC as the STelnet client
and FW as the STelnet server, and how to use STelnet to log in to the VTY administrator
interface of the FW after password authentication.
Figure 1-11 shows that the FW has an administrator. The administrator wants to use STelnet
to log in to the VTY administrator interface of the FW after password authentication and
manage and maintain the FW.
Figure 1-11 Networking diagram of using STelnet to log in to the CLI (password
authentication)
Administrator(Stelnet) GE1/0/3
10.3.0.1/24
10.2.0.100/24 FW
Data Planning
Item Data
FW SSH sshadmin
account

Item Data
Authenticat Password
ion mode
Password Mydevice@123
Service STelnet
type
Administrator PC SSH client software: PuTTY software (Windows XP

operating system). The PuTTY software includes the
PuTTY client for the STelnet service and the SFTP client
PSFTP.
1. Configure FW as the SSH server.
– Enable the SSH service on the interface.
– Configure the VTY administrator interface.
– Create an SSH administrator account and specify the authentication type and
service type.
– Generate a local key pair.
– Enable the STelnet service.
– Configure the SSH service parameters.
2. Configure the administrator PC as the SSH client.
– Set an IP address for the administrator PC.
– Install the PuTTY software.
– Use PuTTY to log in to the FW through SSH.
NOTE
The prerequisite is that IP addresses of the interface and administrator PC, security zone, route, and
security policies have been configured. The following example introduces content related only to the
administrator.
Procedure
Step 1 Configure the FW.
1. Enable the SSH service on interface GigabitEthernet 1/0/3.
<FW> system-view
[FW-GigabitEthernet1/0/3] service-manage ssh permit
2. Configure VTY administrator interfaces that support AAA.

[FW-ui-vty0-4] protocol inbound ssh
[FW-ui-vty0-4] quit

3. Create SSH administrator account sshadmin and set the authentication type and service
type to Password and Stelnet. In this example, local authentication is used. You can also
use server authentication in actual scenarios. For details, see 1.3.5.4 Example for
Logging in to the CLI Using the Telnet (RADIUS Server Authentication) and 1.3.5.5
Example for Logging in to the CLI Using the Telnet (HWTACACS Server
Authentication).
[FW] aaa
[FW-aaa] manager-user sshadmin
[FW-aaa-manager-user-sshadmin] password
Enter Password:
Confirm Password:
[FW-aaa-manager-user-sshadmin] service-type ssh
[FW-aaa-manager-user-sshadmin] quit
[FW-aaa] bind manager-user sshadmin role system-admin
[FW-aaa] quit
NOTE
The level of an SSH administrator is determined by the administrator level and the level of the
authentication mode or VTY interface. To ensure that the administrator can log in to the device
normally, you are advised to set the administrator level and the VTY interface level to not lower
than 3.
4. Generate a local key pair.
[FW] rsa local-key-pair create
The key name will be: FW_Host
The range of public key size is (512 ~ 2048).
NOTES: A key shorter than 1024 bits may cause security risks.
The generation of a key longer than 512 bits may take several minutes.
Input the bits in the modulus[default = 2048]:
Generating keys...
...++++++++
..++++++++
..................................+++++++++
............+++++++++
5. Enable the STelnet service.

[FW] stelnet server enable
6. Configure the administrator as an STelnet administrator.

[FW] ssh user sshadmin
[FW] ssh user sshadmin authentication-type password
[FW] ssh user sshadmin service-type stelnet
7. Optional: Set the SSH server parameters.

# Set the listening port of the SSH server to 1025, authentication timeout period 80
seconds, number of authentication retries to 4, update interval of the key pair to 1 hour,
and enable the backward compatibility function.
[FW] ssh server port 1025
[FW] ssh server timeout 80
[FW] ssh server authentication-retries 4
[FW] ssh server rekey-interval 1
[FW] ssh server compatible-ssh1x enable
Step 2 Configure the administrator PC as the SSH client.

255.255.255.0.
2. Install the PuTTY software. Details are omitted.
3. Use the PuTTY software to log in to the FW through STelnet. (The following example
uses PuTTY0.60.)
a. Double-click PuTTY.exe. The interface shown in Figure 1-12 is displayed. Enter
the IP address of the SSH server in the Host Name (or IP address) text box.

Figure 1-12 Entering the IP address of the SSH server
b. Choose Connection > SSH in the left Category tree. The interface shown in
Figure 1-13 is displayed. In Protocol options, set Preferred SSH protocol version
to 2 and click Open.

Figure 1-13 Setting SSH protocol version
c. Dialog box shown in Figure 1-14 is displayed upon the first login. Click Yes.
Figure 1-14 PuTTY security alert

d. In the login page that is displayed, enter SSH administrator account sshadmin and
press Enter. Enter Mydevice@123 and press Enter again. You can log in to FW.
----End
#
ip address 10.3.0.1 255.255.255.0
service-manage ssh permit
#
protocol inbound ssh
#
manager-user sshadmin
password cipher %@%@fPXYG8r|>17U(MYaBLw0OE<3BRR/*~[B0>uW"^/){U_>wKB=%@%@
service-type ssh
level 15
bind manager-user sshadmin role system-admin

#
stelnet server enable
ssh user sshadmin
ssh user sshadmin authentication-type password
ssh user sshadmin service-type stelnet
ssh server port 1025
ssh server timeout 80
ssh server authentication-retries 4
ssh server rekey-interval 1
ssh server compatible-ssh1x enable
#
return
1.3.5.7 Example for Logging In to the CLI Using STelnet (RSA Authentication)
This section describes how to configure the administrator PC as the STelnet client and FW as
the STelnet server, and how to use STelnet to log in to the VTY administrator interface of the
FW after RSA authentication.
Figure 1-15 shows that the FW has an administrator. The administrator wants to use STelnet
to log in to the VTY administrator interface of the FW after RSA authentication and manage
and maintain the FW.
Figure 1-15 Networking diagram of using STelnet to log in to the CLI (RSA authentication)
Administrator(Stelnet) GE1/0/3
10.3.0.1/24
10.2.0.100/24 FW

Data Planning
Item Data
FW SSH sshadmin
account
Authenticat RSA
ion mode
Service STelnet
type
Administrator PC SSH client software: PuTTY software (Windows 7

operating system). The PuTTY software includes the
PuTTY client for the STelnet service and the SFTP client
PSFTP.
1. Generate a local RSA key pair on the PC and an RSA public key in the format supported
by the FW.
– Install the PuTTY software.
– Use the PuTTYgen tool to generate a local SSH-RSA key pair.
2. Configure FW as the SSH server.
– Enable the SSH service on the interface.
– Configure the VTY administrator interface.
– Save the RSA public key on the SSH client (the PC).
– Create an SSH administrator account.
– Enable the STelnet service.
3. Configure the administrator PC as the SSH client.
– Set an IP address for the administrator PC.
– Use PuTTY to log in to the FW through SSH.
NOTE
The prerequisite is that IP addresses of the interface and administrator PC, security zone, route, and
security policies have been configured. The following example introduces content related only to the
administrator.
Procedure
Step 1 Generate an RSA public key on the PC.
2. Use the PuTTYgen tool to generate a local SSH-RSA key pair. (PuTTYgen 0.60 is used
as an example in the following part.)
a. Double-click PuTTYgen.exe. The interface shown in Figure 1-16 is displayed. In
Parameters, set Type of key to generate to SSH-2 RSA. Click Generate. The PC
starts to generate a local RSA key pair.

Figure 1-16 Selecting the SSH version for generating the local SSH-RSA key pair
b. Figure 1-17 shows the interface for generating a local RSA key pair. You must
move the mouse continuously during the generation of the local RSA key pair.
Move the pointer only in the window other than the process bar in green.
Otherwise, the progress bar suspends, and the generation of the key pair is stopped.

Figure 1-17 Generating a local RSA key pair
c. Figure 1-18 shows the generation of the local RSA key pair. Do as follows to save
the RSA key pair in the specified format:
n OpenSSH: Copy the marked content in the Key text box.
n PEM: Click Save public key, enter public for the name of the public key file,
and click Save. Click Save private key, enter private for the name of the
private key file, and click Save.
NOTE
To enhance security, you must enter a password in the Key passphrase text box and enter
the password again in the Confirm passphrase text box to set a password for using this key
pair.

Figure 1-18 Saving a local RSA key pair

1. Enable the SSH service on interface GigabitEthernet 1/0/3.
NOTE
The SSH service is enabled on management interface GigabitEthernet 0/0/0 by default. If the SSH
service is disabled, enable it as follows.
<FW> system-view
2. Configure the VTY administrator interface.
# Configure VTY administrator interfaces that support AAA.

[FW-ui-vty0-4] quit
3. Save the RSA public key of the intranet PC. In this example, the RSA public key is
saved in the OpenSSH coding format.

[FW] rsa peer-public-key key_pc encoding-type openssh

Enter "RSA public key" view, return system view with "peer-public-key end".
[FW-rsa-public-key] public-key-code begin
Enter "RSA key code" view, return last view with "public-key-code end".
[FW-rsa-key-code] ssh-rsa
AAAAB3NzaC1yc2EAAAABJQAAAIBwsFDGbVAbK35ecJqsioQ3BdTCa1+eU3i13YQBHvBltIdI9bOMKY
EYJbjuY4UYXkdtwA2ar6LWTI8X1hHbtYGqPk2MvjSF0hXn1DBabNUXbLRyzWAhaopcsTbGboU88cQ6
fe/DqE9jUpNLsPdg4EXz1LMyLNe134JCSe3Ufh7o/w== rsa-key-20140515
[FW-rsa-key-code] public-key-code end
[FW-rsa-public-key] peer-public-key end
[FW]
4. Create an SSH administrator account.

[FW] aaa
[FW-aaa] manager-user sshadmin
[FW-aaa-manager-user-sshadmin] service-type ssh
[FW-aaa-manager-user-sshadmin] quit
[FW-aaa] bind manager-user sshadmin role system-admin
[FW-aaa] quit
NOTE
The level of an SSH administrator is determined by the administrator level and the level of the
authentication mode or VTY interface. To ensure that the administrator can log in to the device
normally, you are advised to set the administrator level and the VTY interface level to not lower
than 3.
5. Enable the STelnet service.
[FW] stelnet server enable
6. Configure the administrator as an STelnet administrator.

[FW] ssh user sshadmin
[FW] ssh user sshadmin authentication-type rsa
[FW] ssh user sshadmin service-type stelnet
[FW] ssh user sshadmin assign rsa-key key_pc
7. Optional: Set the SSH server parameters.

# Set the listening port of the SSH server to 1025, authentication timeout period 80
seconds, number of authentication retries to 4, update interval of the key pair to 1 hour,
and enable the backward compatibility function.
[FW] ssh server port 1025
[FW] ssh server timeout 80
[FW] ssh server authentication-retries 4
[FW] ssh server rekey-interval 1
[FW] ssh server compatible-ssh1x enable
Step 3 Configure the administrator PC as the SSH client.

255.255.255.0.
3. Use the PuTTY software to log in to the FW through STelnet. (The following example
uses PuTTY0.60.)

b. Choose Connection > SSH in the left Category tree. The interface shown in Figure
1-20 is displayed. In the Protocol options area, set Preferred SSH protocol
version to 2.

Figure 1-20 Setting SSH protocol version
c. Select Auth in SSH. The dialog box shown in Figure 1-21 is displayed. Click
Browse, import the private key file private.ppk in the saved SSH-RSA key pair.

Figure 1-21 Importing the private key in the SSH-RSA key pair
d. Click Session, enter ssh-rsa in the Saved Sessions text box, and click Save to save
the SSH session, as shown in Figure 1-22.
NOTE
The saved session will be used when the PSFTP tool is used for SFTP login. Besides, no
configuration is required for future STelnet login. You can double-click the SSH session to
open the login page.

Figure 1-22 Importing the private key in the SSH-RSA key pair
e. Enter SSH administrator account sshadmin in the login page that is displayed and
press Enter. You can log in to FW.
NOTE
If a password is specified for using the key pair, you must enter the password for the login.
----End
#
ip address 10.3.0.1 255.255.255.0
#
#
manager-user sshadmin
service-type ssh
level 15

#

stelnet server enable

ssh user sshadmin
ssh user sshadmin authentication-type rsa
ssh user sshadmin service-type stelnet
ssh user sshadmin assign rsa-key key_pc
ssh server port 1025
ssh server timeout 80
ssh server authentication-retries 4
ssh server rekey-interval 1
ssh server compatible-ssh1x enable
#
return
1.3.5.8 Example for Configuring the FW as a Client to Log In to Other Devices

This section provides an example for configuring FW as the STelnet or Telnet client.
Prerequisites
l The FW between the STelnet or Telnet server is routable.
l The STelnet server has been enabled on the server.
l The STelnet or Telnet user information configured on the STelnet or Telnet server has
been obtained.
The FW logs in to the server using STelnet or Telnet, as shown in Figure 1-23.
NOTICE
During Telnet login, data and passwords are transmitted in plaintext mode, causing security
risks. To secure data transmission, use STelnet instead.
Figure 1-23 Networking diagram of configuring FW as a client to log in to other devices

GE1/0/3
10.1.1.1/24 10.2.2.1/24
FW
Stelnet/Telnet Server
Stelnt/Telnet Client
Procedure
l Configure the FW to access the server using Telnet.
a. Enable the Telnet service on the server.
b. Use the FW to log in to the server using Telnet.
<FW> telnet 10.2.2.1
l Configure the FW to access the server using STelnet.

a. Enable first-time authentication.

<FW> system-view
[FW] ssh client first-time enable
b. If the STelnet server uses RSA or PASSWORD-RSA authentication method, you

must bind the FW STelnet account to the RSA key on the server.
i. Generate a local RSA key pair.
The range of public key size is (512 ~ 2048).
NOTES: A key shorter than 1024 bits may cause security
risks.
The generation of a key longer than 512 bits may take several
minutes.
Input the bits in the modulus[default = 2048]:
Generating keys...
...++++++++
..++++++++
..................................+++++++++
............+++++++++
ii. Copy the RSA keys. The information in bold is the RSA keys generated by the
client. Copy the keys and save them.
[FW] display rsa local-key-pair public
=====================================================
Time of Key pair created: 18:34:19 2013/1/17

Key name: FW_Host
Key type: RSA encryption Key
=====================================================
Key code:
308188
028180
CB35ED46 660B55CC 80EAAFD7 78DDFBF7 467A1C13
5D29865C 63509D5D E25E423A DB11A00F 77CDBBB4
D93436EA D50E4261 AC476E56 7AC6344A B0ECE377
EA2E6912 4EC32710 FC4B5D2D 61E358B1 E8EA739F
A0338BE0 ED72A9A0 EDFE49FD 071623A4 96A0A45B
4EAD2641 A8D7A39F 567B02B9 90DE5722 980072B4
B320FDA0 10F18DF9
0203
010001
Host public key for PEM format code:

---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAAAgQDLNe1GZgtVzIDqr9d43fv3RnocE10phlxj
UJ1d4l5COtsRoA93zbu02TQ26tUOQmGsR25WesY0SrDs43fqLmkSTsMnEPxLXS1h
41ix6Opzn6Azi+Dtcqmg7f5J/QcWI6SWoKRbTq0mQajXo59WewK5kN5XIpgAcrSz
IP2gEPGN+Q==
---- END SSH2 PUBLIC KEY ----
Public key code for pasting into OpenSSH authorized_keys file :

ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAAAgQDLNe1GZgtVzIDqr9d43fv3RnocE10phlxjUJ1d4
l5C
OtsRoA93zbu02TQ26tUOQmGsR25WesY0SrDs43fqLmkSTsMnEPxLXS1h41ix6Opzn6Azi
+Dtcqmg7f5J
/QcWI6SWoKRbTq0mQajXo59WewK5kN5XIpgAcrSzIP2gEPGN+Q== rsa-
key
=====================================================
Time of Key pair created: 11:43:19 2013/9/17
Key name: FW_Server
Key type: RSA encryption Key
=====================================================
Key code:
3067
0260
EC20AA8E 967145ED 186D85B4 3B928A81 C312F0E2

EF34E96C 944FDE4F 6215B98A C046FB51 A195AA9E

D926DE1B 59C6B87E 024C12D1 078DE2CE E9F9C5E6
C5C2E32D CDD74D33 78E70E64 C6CF46E3 A91F8C87
5354BDDD A1A2C9BB 21112D5E 0D2CB44B
0203
010001
c. Use the FW to log in to the server in STelnet mode.

<FW> system-view
[FW] stelnet 10.2.2.1
----End
1.3.6 Feature Reference

This section provides administrators references.
1.3.6.1 Specifications
This section provides the specifications of the administrator.
Function Specifications
Func Sub- Description Supported or
tion functi Not
on
Logi Consol Login Supported by all

n e through the models
meth console port
od
HTTP HTTPS login Supported by all
S models
Telnet Telnet login Supported by all

models
STelne STelnet login Supported by all

t models
Telnet - Allows enabling Supported by all models

server the Telnet
service.
STeln - Allows Supported by all

et enabling the models
serve STelnet
r service and
changing the
service port.

Func Sub- Description Supported or

tion functi Not
on
HTT - Allows Supported by all

PS enabling the models
serve HTTPS
r service,
changing the
service port,
and using the
default or
specified
certificate for
SSL
negotiation.
Performance Specifications
Number of administrators 1
using console port login
Number of administrators 5 by default and 15 to be maximum, shared by Telnet

using Telnet/STelnet login and STelnet login methods
Number of administrators 5
using web login
Number of online web 200

administrators
Total number of administrators 128 plus the number of virtual systems supported by the
that can be created in the root device
system and virtual systems
1.3.6.2 Feature History

This section describes the versions and changes in the administrators feature.
Version Change Description
V500R001C10 The first version.
1.3.7 Administrator FAQs

This section describes FAQs related to administrator login.

What Is the Default Administrator Account?

The FW provides two default accounts.
l System administrator account admin and password Admin@123: You can use this
account to log in to the device through console or web UI for first login.
l Audit administrator account audit-admin and password Admin@123.
l API administrator account api-admin and password admin@123.
When the FW Is Connected to the Network at Layer 2 in Transparent Mode, How

Can I Log In to the Device Through Service Interfaces?
Add the layer-2 interface (service interface) to the VLAN and log in to the device through
interface VLANIF. For example, the two service interfaces are GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2. The configurations are as follows:
# Create a VLAN and add the interfaces to the VLAN. By default, the interfaces belong to
VLAN1.
<FW> system-view
[FW] vlan 2
[FW-vlan-2] quit
[FW-GigabitEthernet1/0/1] portswitch
[FW-GigabitEthernet1/0/1] port access vlan 2
[FW-GigabitEthernet1/0/2] port access vlan 2
#Configure the VLANIF interfaces.

[FW] interface vlanif 2
[FW-Vlanif2] ip address 10.1.3.1 24
[FW-Vlanif2] service-manage enable
[FW-Vlanif2] service-manage ssh permit
[FW-Vlanif2] service-manage https permit
[FW-Vlanif2] quit
[FW-zone-trust] add interface vlanif 2
Log in to the device using 10.1.3.1 after the configurations are complete.
What Do I Do If I Forget the Console Port Password?

If the console port password is forgotten, you can log in to the device through Telnet or SSH
by using a level-3 or higher administrator account to change the console port password.
NOTE
Telnet login has security risks. You are advised to log in to the device through SSH.
1. Log in to the device through SSH by using account admin1 and then confirm the
permission assigned to the administrator account.
Run the display users command to view all login accounts. The account with the "+"
mark is the current administrator account, and the number of the account is VTY 0.
<FW> display users
User-Intf Delay Type Network Address AuthenStatus

AuthorcmdFlag
0 CON 0 47:47:45
no
Username :
Unspecified
+ 34 VTY 0 16:32:31 SSH 172.16.30.93 pass

no
Username :
admin1
2. Run the display user-interface command to view the permission of the administrator
account. The command output shows that VTY 0 corresponds to level 15 and has the
permission to change the console port password.
<FW> display user-interface
Idx Type Tx/Rx Modem Privi ActualPrivi Auth
Int
0 CON 0 9600 - 15 15 P
-
+ 34 VTY 0 - 15 15 A -
......
3. Change the console port password based on the authentication mode of the console port.
– The console port uses the password authentication mode.
Change the console port password to Admin@1234.
<FW> system-view
[FW] user-interface console 0
[FW-ui-console0] set authentication password
Please configure the login password
(8-16)
Enter
Password:
Confirm Password:
– The console port uses the AAA authentication mode.

Change the password of account admin to Admin@1234.
<FW> system-view
[FW] aaa
[FW-aaa] manager-user admin
[FW-aaa-manager-user-admin] password
Enter
Password:
Confirm Password:
4. Then you can uses the changed password to log in to the device through the console port.
1.4 System Clock

A precise system time ensures the accuracy and consistency of collaboration between devices
and helps the administrator gain visibility into the specific time of system events.
1.4.1 Overview
This section describes the definition and objective of the system clock.

Definition
The system clock indicates the current time of the device. It is an important parameter for
device running.
Objective
You can view the time of device logs and alarms to know the exact time when a specific event
happens. In addition, if multiple devices interwork on a network, configuring a correct system
time ensures the accuracy and consistency of device collaboration.
1.4.2 Setting the System Time Using the Web UI

This section describes how to configure the system time on the web UI.
Manually Setting the Time

The administrator can manually set the system time of the device.
Step 1 Choose System > Setup > Time.
Step 2 Select Manually Set the Time in Configuration Mode.
Step 3 Set Time Zone.
Step 4 Set Date.
The date is in YYYY/MM/DD (year/month/date) format.
To change a date, select the date item (such as the year) and enter a new value. Alternatively,
click and select a date from the calendar that is displayed.
Step 5 Set System Time.
The system time is in HH:MM:SS (hour:minute:second) format.
To change the system time, select the time item (such as the hour) and enter a new value.
Alternatively, click / on the right.
Step 6 Click Apply.
----End
Synchronizing the Time with the Local System Time

The administrator can synchronize the time of the terminal device (that is, the PC used for
logging in to the device on the web UI) as the device system time.
Step 2 Select Synchronize the Time with the Local System Time in Configuration Mode.
Step 3 Click Apply.
----End

Synchronizing the Time with the NTP Server

The administrator can synchronize the time of the NTP server as the device system time.

Step 2 Select Synchronize the Time with the NTP Server in Configuration Mode.
Step 3 Set Time Zone.
Step 4 Optional: Set Date and System Time.
Configure the date and system time. When the NTP server works abnormally, the device uses
the date and system time that are manually specified.
Step 5 In NTP Server IP, enter the IP address of the NTP server.
Step 6 Click Apply.
----End
Enabling the DST

Before enable DST, configure the system time first.

Step 2 Select Automatically adjust clock for daylight saving time (DST).
Step 3 Set parameters as follows:
Start Time Start time of the DST.
End Time End time of the DST.
Offset Time Offset time during the DST period.

For example, set the Start Time to 08:00 on the first Monday
in April, End Time to 10:00 on the first Monday in November,
and Offset Time to 01:00. After the settings are complete, the
system time is automatically set to 09:00 at 08:00 on the first
Monday in April, and to 09:00 at 10:00 on the first Monday in
November.
Step 4 Click Apply.
----End
1.4.3 Feature History

This section describes the versions and changes in the System Clock Setting.

1.5 License Management

Licenses determine what features can be used on the device. To meet service requirements,
you can purchase licenses to activate these features.
1.5.1 Overview
1.5.1.1 Overview
A license is a type of contract from the vendor who confers certain rights to a customer. These
rights include usage scope of a product and time period of its usage. Licenses can dynamically
control whether some features of a product are available. If new devices are deployed, you
can purchase new licenses as needed to enable license-controlled features and functions on the
devices. This reduces purchase costs. If the capacities of existing devices are expanded, you
can update the licenses used on the devices to enable more license-controlled features and
functions.
Definition
A license is a permission or authorization granted by the supplier to the customer regarding
the function, resource, and upgrade service of a product. The license is physically the
combination of a license file and a license authorization certificate.
After the license is purchased, the carrier provides the license authorization certificate for the
user to activate the license. The license authorization certificate contains the contract number,
license entitlement ID, and the content of the license.
A license file is a .dat file obtained after the license is activated. Customers need to load the
license file to the device or software to use the functions that require a license.
Categories
Licenses are divided into commercial licenses and non-commercial licenses according to their
actual purpose.
l Commercial license
This license is purchased under contract. If the customer needs to use license-controlled
features or the resources beyond the upper quantity limit, the customer must purchase
commercial licenses.
The commercial licenses are permanent or temporary. The permanent commercial
license includes the license certificate and the electronically delivered license file. Unless
otherwise specified, the term commercial license herein refers to permanent commercial
license. The temporary commercial license is for trial use or similar purposes.
l Non-commercial license
The license applies to non-commercial purposes such as internal tests, demonstrations,
and trainings. The non-commercial license requires no contract, and has a limited
validity period, which is no longer than three months.
According to authorization modes, licenses are classified into single-device licenses and
network licenses.

l Single-device licenses
The single-device license refers to that each FW corresponds to a separate license. This
type of license applies to scenario where the VM environment is fixed and licenses are
not updated frequently.
Each FW purchases, applies for, or activates licenses independently. In case of an ESN
change due to capacity expansion, a license certificate change, or FW migration, the
corresponding license needs to be updated.
l Network licenses
The network license refers to that all FWs in a cloud data center share one license. In this
case, a license server needs to deployed to manage the license in a unified manner and
send requests to the license center website (ESDP platform) for activating or updating
the license.
The FW competes with other devices to apply for resource authorization from the license
server. If the number of available resources on the license server is greater than or equal
to the number of requested ones, the authorization application succeeds.
Network licenses apply to rapid FW start or stop in a cloud data center. In this case, the
ESN of the FW changes rapidly, and the requirement of each FW for resources
dynamically changes.
Because the license server is fixed and the total requirements of all FWs for resources
are fixed, the corresponding license does not need to be updated even through the ESN
or resource requirement of each FW changes frequently.
1.5.1.2 Single-Device Licenses

Single-device licenses apply to scenarios where the VM environment is fixed, licenses do not
need to be updated frequently, and each FW purchases, applies for, and activates licenses
independently.
Before FW, you need to purchase the required license certificate and activate the license.
Before related licenses are activated, the maximum forwarding throughput is 50 Mbit/s, a
maximum of 100 sessions and a maximum of 10 virtual systems are supported, intrusion
prevention and antivirus are available but cannot be automatically upgraded, and functions
that are not controlled by licenses are available. After related licenses are activated, the
license-controlled functions and resources (upgrade services) are controlled according to the
licenses. After licenses expire or are revoked, the device enters the grace period of the
licenses. Users are allowed to access the device within the grace period (60 days) as they do
when the licenses are activated. After the grace period expires, the device enters the state
before the licenses are activated.
License Control Items

Currently, the application of licenses involves the control over functions, resources, and
service upgrades.
l For the control over functions, a license determines whether a certain function is
available. Only after a proper license file is loaded, certain functions are available.
l For the control over resources, a license determines the available number of certain
resources. If no license file is loaded, functions are available with only a limited number
of resources.
l For the control over service upgrades, a license determines whether a service can be
upgraded. You can upgrade services only after you load a proper license file.

NOTE
You must purchase the license for the basic software service time. Otherwise, the other license control items
do not take effect during license activation.
The control items excluding those for virtual systems correspond to different licenses based on models.
Table 1-19 lists the license control items of the FW.
Table 1-19 License control items of the FW

Control Item Status When the License Status When the Official
Is Not Activated License Is Activated
Basic software service time The functions that are not The validity periods of the
controlled by licenses are license-controlled functions,
available. resources, and upgrade
The maximum forwarding services are the same as the
throughput is 50 Mbit/s, and basic software service time
the maximum number of and classified into
sessions is 100. permanent and one-year.
After the validity period
expires, no license-
controlled function,
resource, or upgrade service
is available.
The forwarding throughput
and number of sessions are
limited by the device
performance.
Number of virtual systems Ten virtual systems are You can increase the number
supported. of supported virtual systems
by purchasing a license, but
the number of virtual
systems cannot exceed the
upper threshold supported
by the device. The
maximum number of virtual
systems supported by the
license varies according to
device models:
l USG6000V1: 20
l USG6000V2: 50
l USG6000V4: 200
l USG6000V8: 500

Intrusion prevention The function is available but After the license is

cannot be automatically activated, the function can
upgraded. be used and automatically
upgraded.
The validity period of the
upgrade service is the same
as the basic software service
time and classified into
permanent and one-year.
After the license expires, the
intrusion prevention
function and upgrade
service become unavailable.
Antivirus The function is available but After the license is

cannot be automatically activated, the function can
upgraded. be used and automatically
upgraded.
as the basic software service
time and classified into
permanent and one-year.
After the license expires, the
antivirus function and
upgrade service become
unavailable.
Server load balancing This function is unavailable. This function is available.
License Authorization Mode

In case of single-device license, license certificates are purchased independently based on
resource requirements for each FW. Log in to the license self-service platform (ESDP
platform) to request to activate the license file and upload the file to the device.
License Management
Single-device license management includes applying for, loading, and replacing the licensing
files. Table 1-20 describes license management.

Table 1-20 License management

Sc Conte Prerequisites Operation Expected
en nt Result
ari
o
Nu
mb
er
1 Applyi l The ESN is Log in to the license self-service The license

ng for available. platform and enter the ESN and file is
a l A license is the entitlement ID of the license obtained.
license purchased to certificate to apply for a license
file obtain the license file.
certificate.
2 Loadin The license file is Upload the license file to the Licenses are
g the obtained from the device and activate it. activated.
license license self-service
file platform.
3 Replac Capacity expansion 1. Purchase a license. The license

ing the needs to be carried 2. Log in to the license self- center
license out or license- service platform and enter the automatically
file controlled functions ESN and the entitlement ID of combines the
are required. the license certificate to apply licenses for
for a new license file. new features
with the
3. Upload the new license file to existing
the device and activate it. license and
generates a
new license.
The license file is 1. Revoke the current license file Licenses are
damaged because and obtain the invoke code activated.
the content of the 2. Log in to the license self-
existing license file service platform and enter the
is changed due to ESN and license revoke code
misoperation or the to retrieve the invalid license
license file is not file.
compatible with
existing licenses 3. Upload the new license file to
after device upgrade. the device and activate it.


en nt Result
ari
o
Nu
mb
er
The ESN is changed 1. Revoke the current license file Licenses are
during FW and obtain the invoke code activated.
migration and 2. Log in to the license self-
mismatches with the service platform, enter the
current license file, ESN and license revoke code,
you need to revoke and change the ESN to apply
the current license for a new license file.
file, obtain the
revoke code, and 3. Upload the new license file to
apply for a new the device and activate it.
license file.
1.5.1.3 Network Licenses

Network licenses apply to rapid FW start or stop in a cloud data center. In this case, the ESN
of the FW changes rapidly, and the requirement of each FW for resources dynamically
changes.
When a network licenses is used, a license server is required to send requests to the license
center website (ESDP platform) for activating or updating license files and manage license
resources. For details on license server installation and deployment, see the product
documentation of the license server.
As shown in Figure 1-24, the administrator sends requests in a unified manner to the license
self-service platform (ESDP platform) for activating the license file and uploads the license
file to the license server. The license server manages the license resources in a unified manner.
All FWs serve as license clients and communicate with the license server through TCP/IP.

Figure 1-24 Application scenarios of network licenses

Activating a license
Obtain the ESN of the license

server. Log in to
Obtain the license Upload the license file
the ESDP
Obtain the entitlement ID from file. to the license server.
platform.
the license certificate.
License
License resource pool
Server
vFW_A vFW_B vFW_C vFW_D vFW_E
IPS IPS
IPS IPS
AV AV VSYS=100
SLB VSYS=150
VSYS=20 VSYS=50
After obtaining the ESN of the license server and the entitlement ID of the license certificate,
the administrator logs in to the license self-service platform to activate the license file and
uploads the license file to the license server. After the license file expires, the license server
can still deliver authorization within the grace period (60 days) of the license file as it does
when the license file is activated. After the grace period expires, the license server cannot
deliver any authorization.
To perform capacity expansion or replace the license server, apply for a new license file.
Before FW, apply for resource authorization from the license server.
When no resource authorization is requested, the maximum forwarding throughput is 50

Mbit/s, a maximum of 100 sessions and a maximum of 10 virtual systems are supported,
intrusion prevention and antivirus are available but cannot be automatically upgraded, and
functions that are not controlled by the license are available. After resource authorization is
required, license-controlled functions and resources are controlled based on the number of
requested resources.
Each FW applies for resources from the license server. The license server responds to the FW
by determining whether the license is within the validity period and whether the number of
available resources is greater than or equal to the number of requested ones. If the license is
within the validity period and the number of available resources is greater than or equal to the
number of requested ones, the license server assigns the resources to the FW. Otherwise, the
application fails.
If the FW does not use some functions or resources, the FW needs to request the license
server to release the corresponding authorization for timely resource sharing. If the FW
cannot proactively release authorization due to a network fault, the administrator can force the
FW to release the authorization through the license server, implementing flexible license
resource control.

If the FW and license server fails to communicate due to a fault, such as a fault in the FW, a
fault in the license server, and a fault in the device between the FW and license server and the
fault lasts less than 24 hours, the FW can continue to use the requested resources after the
communication with the license server recovers. If the fault lasts 24 hours or more than 24
hours, the requested authorization requested by the FW will be automatically deregistered and
retired to the resource pool, and the FW needs to reapply for required authorization.
License Control Items

Currently, the application of licenses involves the control over functions, resources, and
service upgrades.
l For the control over functions, a license determines whether a specific function is
available. Only after a proper license file is loaded, certain functions are available.
l For the control over resources, a license determines the available number of specific
resources. If no license file is loaded, functions are available with only a limited number
of resources.
l For the control over service upgrades, a license determines whether a service can be
upgraded. You can upgrade services only after you load a proper license file.
NOTE
When applying for the authorization for resources, the device must apply for the authorization for the basic
software. Otherwise, the authorization for resources does not take effect even if it is requested.
The control items excluding those for virtual systems correspond to different licenses based on models.
Table 1-21 lists the license control items of the FW.
Table 1-21 License control items of the FW

Basic software The functions that are not The validity periods of all
controlled by licenses are license-controlled functions
available. excluding the intrusion
The maximum forwarding prevention and antivirus
throughput is 50 Mbit/s, and signature database upgrade
the maximum number of services are the same as that
sessions is 100. of the basic software service
for a specific model defined
in the license.
The forwarding throughput
and number of sessions are
limited by the device
performance.

Number of virtual systems Ten virtual systems are Each FW requests the
supported. number of virtual systems
from the license server, but
the number of requested
virtual systems cannot
exceed the upper threshold
supported by the device.
The maximum number of
virtual systems supported by
the license varies according
to device models:
l USG6000V1: 20
l USG6000V2: 50
l USG6000V4: 200
l USG6000V8: 500
Intrusion prevention The function is available but After the license for
cannot be automatically intrusion prevention is
upgraded. requested from the license
server, intrusion prevention
can be used and
automatically upgraded.
as that of the IPS upgrade
service for a specific model
defined in the license. After
the license is expired, the
upgrade service becomes
unavailable, but the
intrusion prevention
function is still available.
Antivirus The function is available but After the license for

cannot be automatically antivirus is requested from
upgraded. the license server, antivirus
can be used and
automatically upgraded.
as that of the antivirus
upgrade service for a
specific model defined in
the license. After the license
expires, the upgrade service
becomes unavailable, but
the antivirus function is still
available.

Server load balancing This function is unavailable. This function is available.
License Authorization Mode

When a network license is used, the administrator plans all resource requirements and
purchase license certificates. The administrator logs in to the license self-service platform
(ESDP platform) to apply for activating the license file and uploads the license file to the
license server. After the license file is loaded, the license server has a shared resource pool.
Each FW applies for the authorization for resources from the license server as required. If the
number of resources in the resource pool is greater than or equal to the number of requested
ones, the FW can obtain the authorization for the resources. The authorization for the
resources is obtained independently. If the FW applies for 100 virtual systems (10 virtual
systems are provided for free by default, and 90 virtual systems are required) and requests to
enable intrusion prevention upgrade service but the resource pool of the license server has
only the authorization for 80 virtual systems and the authorization for one intrusion
prevention upgrade service applicable to a specific model, the FW fails to apply for the virtual
systems but can enable intrusion prevention upgrade service.
The authorization for the quantity of basic software and the authorization for the validity
period of basic software in the resource pool of the license server limit the number of devices
that can simultaneously run the basic software and the period during which the devices can
run the basic software. If the quantity of the available basic software is 0 or the validity period
of the basic service service expires, the devices cannot obtain the authorization for the basic
software, even if other resources are sufficient.
resource control.
License Management
Network-type license management includes applying for, loading, and replacing the licensing
files. Table 1-22 describes license management.

Table 1-22 License management

en nt Result
ari
o
Nu
mb
er
1 Applyi l The ESN of the Log in to the license self-service The license
ng for license server is platform and enter the ESN and file is
a obtained. the entitlement ID of the license obtained.
license l A license is certificate to apply for a license
file purchased to file.
obtain the license
certificate.
2 Loadin The license file is Upload the license file to the Licenses are
g the obtained from the license server and activate it. activated.
license license self-service
file platform.
3 Replac Capacity expansion 1. Log in to the license self- The license

ing the needs to be service platform and enter the center
license implemented, or ESN and the entitlement ID of automatically
file license-controlled the license certificate to apply combines the
functions are for a new license file. licenses for
required. 2. Upload the new license file to new features
the license server and activate with the
it. existing
license and
generates a
new license.
The license file is 1. Log in to the license self- Licenses are

damaged because service platform and enter the activated.
the content of the ESN and the entitlement ID of
existing license file the license certificate to apply
is changed due to for a license file.
misoperation. 2. Upload the license file to the
license server and activate it.
The ESN is changed 1. Log in to the license self- The license is

during License service platform and enter the activated.
Server migration ESN and the entitlement ID of
and mismatches the license certificate to apply
with the current for a new license file.
license file. 2. Upload the new license file to
the license server and activate
it.


en nt Result
ari
o
Nu
mb
er
4 Applyi l An IP address Apply for the number of Authorization

ng for and port number resources from the license server. is obtained.
authori are configured
zation for the license
server, and the
connection to the
license server is
established.
l The license
server has loaded
the license file.
l The license
server has
enough license
resources.
5 Releas The device is no Request the license server to Authorization

ing longer used. release authorization for timely is released.
authori resource sharing.
zation
1.5.2 Managing Licenses Using the Web UI

This section describes how to manage licenses using the web UI.

This section describes how to apply for and activate single-device licenses.
Overview
independently.

Activating a License File

After you purchase or renew a license, you can obtain a license certificate. You need to apply
for a license file (*.dat) to use license-controlled functions. The license file name extension
must be .dat and cannot be changed.
Step 1 Obtain the entitlement ID.
Find the license certificate in the delivery accessories and obtain the entitlement ID, as shown
in Figure 1-25.
NOTE
The license certificate is delivered together with the product to the customer in A4 papers or CD-ROMs.
If the license certificate is list, log in to the http://app.huawei.com/isdp (ESDP platform) to retrieve it
based on the contract number.
The license certificates may be different due to different purchase channels.
Figure 1-25 License certificate
Step 2 Obtain the device Equipment serial number (ESN).
An ESN uniquely identifies a hardware device or software system. Before loading the license
file, ensure that the ESN of the device or system is the same as that in the license file.
Otherwise, the license file fails to be activated.
Log in to the device and choose Dashboard. In System Information, obtain SN.
Step 3 Obtain the license file from the license self-service platform.
Log in to the http://app.huawei.com/isdp and obtain the license file according to the system
Help or information.

NOTE
When you apply for licenses for multiple devices, ensure that the entitlement ID and ESN of each device
match each other.
If you cannot obtain the license file in time, contact the customer service center.
Step 4 To carry out capacity expansion and add license-controlled functions, use the ESN and new
entitlement ID to obtain a new license file through the license self-service system. In this case,
the previous procedure still is applicable.
The license center automatically combines the licenses for new features with the existing
license and generates a new license.
----End
Loading a License File

Step 1 Log in to the web UI and choose System > License Management.
Step 2 In License type, select Single Device License.
Step 3 In File, click Browse and select the license file to be uploaded.
Step 4 Click Activate to activate the current license file.
----End
Revoking Licenses
Licenses can be revoked only through command lines.
In the following scenarios, you need to revoke the existing licenses of the device and obtain
the revoke code, use the license revoke code and ESN to obtain a new license file through the
license self-service platform, and upload the new license file to the device and activate it.
l The license file is damaged because the content of the existing license file is changed
due to misoperation.
l The license file is not compatible with existing licenses after device upgrade.
l The ESN is changed due to FW migration.
NOTICE
The license file of the device cannot be reactivated after being revoked, regardless of whether
the license file expires or not.

This section describes how to activate a network license.
Overview
changes.



server. Log in to
the ESDP
platform.
License
Server
IPS IPS
IPS IPS
AV AV VSYS=100
SLB VSYS=150
VSYS=20 VSYS=50

application fails.
resource control.
Applying for Authorization

The FW can request resources from the license server as required.
Step 2 In License type, select Network License.
Step 3 Configure an IP address and port for the license server.

NOTE
Enter the correct IP address and port number. If the text box is empty or the IP address is 0.0.0.0, the text box
is in red.
Step 4 Select the types of resources to be activated.

NOTE
When applying for authorization for resources, apply for the authorization for basic software. Otherwise, the
authorization for resources does not take effect even after being requested. That is, Basic Software is
mandatory, and other resources can be selected as required.
By default, a maximum of 10 virtual systems can be created. After the license is activated, 10 plus the
number of virtual systems specified in the license can be created totally.
Step 5 Click Activate to apply for resources from the license server.
In License Status, you can view the license status and authorization of each type of resource.
NOTE
If you apply for license activation several times, your last application result takes effect, and the activated
resources are not accumulated.
----End
Releasing Authorization
server to release the corresponding authorization for timely resource sharing.
Step 2 In License type, select Network License.

Step 3 Click Deactivate at the right site of License Status to release all requested authorization.
In License Status, you can view the license status and authorization of each type of resource.
----End
1.5.3 Managing Licenses Using the CLI

This section describes how to manage licenses using the CLI.

This section describes how to apply for and activate single-device licenses.
Overview
independently.
Activating a License File

After you purchase or renew a license, you can obtain a license certificate. You need to apply
for a license file (*.dat) to use license-controlled functions. The license file name extension
must be .dat.
Step 1 Obtain the entitlement ID.

Find the license certificate in the delivery accessories and obtain the entitlement ID, as shown
in Figure 1-27.
NOTE
The license certificate is delivered together with the product to the customer in A4 papers or CD-ROMs.
If the license certificate is list, log in to the http://app.huawei.com/isdp (ESDP platform) to retrieve it
based on the contract number.
The license certificates may be different due to different purchase channels.

Figure 1-27 License certificate
Step 2 Obtain the ESN.
An ESN uniquely identifies a hardware device or software system. Before loading the license
file, ensure that the ESN of the device or system is the same as that in the license file.
Otherwise, the license file fails to be activated.
After logging in to the device, you can run the display esn command in any view to obtain
the ESN.
Step 3 Obtain the license file from the license self-service platform.
Log in to http://app.huawei.com/isdp to obtain the license file according to the system Help
or information.
NOTE
When you apply for licenses for multiple devices, ensure that the entitlement ID and ESN of each device
match each other.
If you cannot obtain the license file in time, contact the customer service center.
Step 4 To carry out capacity expansion or add license-controlled functions, you must reapply for the
license file according to the preceding procedure.
The license center automatically combines the licenses for new features with the existing
license and generates a new license.
----End
Loading a License File

Step 1 Check whether there is a sufficient space for storing the license file.
dir
Step 2 Upload the license file to the root directory of the storage device.

The license file can be renamed but its license file name extension .dat cannot be changed.
Otherwise, the system cannot properly load the license file. The license file is stored in the
root directory of the storage device.
For details on how to upload the license file to the root directory of the storage device, see
1.14.3 Transferring Files.
Step 3 Activate the specified license file.
license active file-name
After activating the license file, you can run the display license command to view license
information.
----End
Revoking Licenses
In the following scenarios, you need to revoke the existing licenses of the device and obtain
the revoke code, use the license revoke code and ESN to obtain a new license file through the
license self-service platform, and upload the new license file to the device and activate it.
l The license file is damaged because the content of the existing license file is changed
due to misoperation.
l The license file is not compatible with existing licenses after device upgrade.
l The ESN is changed due to FW migration.
NOTICE
The license file of the device cannot be reactivated after being revoked, regardless of whether
the license file expires or not.

system-view
Step 2 Revoke existing licenses and obtain the license revoke code.
license revoke
You can run the display license revoke-ticket command to view the license revoke code of
the current revoked license file.
----End

This section describes how to activate a network license.
Overview
changes.



server. Log in to
the ESDP
platform.
License
Server
IPS IPS
IPS IPS
AV AV VSYS=100
SLB VSYS=150
VSYS=20 VSYS=50

application fails.
resource control.
Applying for Authorization

The FW can request resources from the license server as required.
system-view
Step 2 Configure an IP address and port number for the license server.
net-license server ip ip-address and net-license server port port-number
To use a network license, you need to configure an IP address and port number for the license
server so that devices can communicate with the license server. Ensure that the IP address and
port number of the license server configured on the devices are the same as those on the
license server.
Step 3 Configure authorization for resources required by the device.
net-license { base-function | intrusion-prevention | anti-virus | server-load-balance |

encryption | virtual-system } value
By default, control items over functions and control items over upgrade services are not
enabled, and 10 virtual systems are supported.
When applying for authorization for resources, the device must apply for authorization for
basic software. Otherwise, the authorization for resources does not take effect even if it is
requested.
If you apply for license activation several times, your last application result takes effect, and
the activated resources are not accumulated.
Step 4 Release requested authorization.
net-license active
You can run the display net-license status command to check the network license status,
including the license server status and authorization of each type of resource.
----End

Releasing Authorization
server to release the corresponding authorization for timely resource sharing.
system-view
Step 2 Release requested authorization.
undo net-license active
----End
1.5.3.3 Maintaining a License

After configuring a license, you can run display commands to view the related configuration.
You can also enable the debugging function if necessary.
Checking License Configuration

Table 1-23 shows the operations related to checking license configuration.
Table 1-23 Checking license configuration

Action Command
Check the ESN of the device. display esn
Check the status of single-device licenses. display license
Check the revocation code of the current display license revoke-ticket

license file.
Check the status of the network license. display net-license status
Debugging a License
Before the debugging, you must run the terminal monitor and terminal debugging
commands in the user view to enable the display of logs, messages, debugging messages on
the terminal, so that debugging messages can be displayed on the terminal.
NOTICE
Enabling the debugging function compromises the system performance. Therefore, after
debugging, run the undo debugging all command to disable the debugging function at once.
For the description of the debugging command, see Debugging Reference.
Table 1-24 lists the command for you to debug a license.

Table 1-24 Debugging a license

Action Command
Debug the license for the device. debugging license
Debug the license module. display debugging license-info

This section describes the versions and changes in the License feature.
1.5.5 License FAQs

This section provides FAQs on license management.
When Should I Start to Calculate the Activation Time of License Control Items?
When the ESDP binds authorization IDs and device ESNs and generates a license file, the
system time of the ESDP is the activation time of all license control items. The validity
periods of the license control items start from the activation time.
After the license file is generated, download and load it on the device to prevent resource
wastes.
What Do I Do If the License Certificate Is Lost?

If the license certificate is list, log in to the http://app.huawei.com/isdp (ESDP platform) to
retrieve it based on the contract number.
1.6 Update Center

This section describes how to update the signature database to the specified versions to
enhance the dynamic defense capabilities of a network security device.
1.6.1 Overview
You can connect to the update center to update your signature databases to detect the latest
intrusions, viruses, applications, malicious domain names,and locations of IP addresses.
Signature databases fall into:
l Intrusion prevention signature database

l Antivirus signature database

l Application identification signature database for the device to identify application

protocols
l Malicious domain name database for intrusion prevention
l Region identification signature database for the device to identify locations of IP
addresses
NOTE
Before you update the IPS signature, malicious domain name, or antivirus signature database, ensure
that the license for the specified database update service has been activated. The Intrusion prevention
signature database and malicious domain name database use the same update license.
1.6.2 Update Scenarios

This section describes update scenarios of the FW.
FW signature databases can be updated online, using a proxy server, or locally.

Update Scenario Description
Online update The FW connects to the update center over the Internet to
update the signature databases.
NOTE
Generally, the update center is the security center platform. Enterprises
will create their own update centers if their networks are isolated from
the Internet (such as for military sectors).
1 Sending the update request and verifying the update right

2 Downloading the update package Security
1 Service Center
2
Intranet
FW
The FW uses HTTP to send update requests and uses FTP to

download signature databases. Therefore, you must configure
security policies to permit HTTP and FTP.
Signature databases can be updated immediately or as
scheduled.
l Scheduled update
The FW accesses the update center on a scheduled basis to
search for the latest signature databases. If the new versions
of signature databases are found, the FW downloads the
latest signature databases to update the local signature
databases at scheduled time.
l Immediate update
When new signature database on the network, you can
immediately update signature databases instead of waiting
for the scheduled update.
The download address and process for updating the
signature database immediately is the same as that for the
update through scheduled update. The two update modes
differ in that immediate update can be performed at any
time whereas scheduled update must be implemented at the
specified time.

Update using a proxy When the FW cannot communicate with the update center over
server the Internet, a proxy server can be used to connect to the
update center and download signature databases for the FW.
NOTE
If the proxy server runs the Windows operating system, CCProxy is
recommended. If the proxy server runs the Linux operating system,
Squid is recommended. Ensure that the proxy server enables the HTTP
port and four access methods, namely, PUT, GET, CONNECT, and
POST.
1. Connects to the proxy server and sends it an update request.
2. Confirms the identity.
3. Forwards the update request and verifies the update
Security Service Center
permission.
4. Downloads the latest signature database.
1
Intranet 2
3
4
FW Proxy Server
The FW supports HTTP proxy only. Therefore, the security

policy that allows HTTP must be configured.
Signature databases can be updated immediately or as
scheduled via the proxy server.
l Scheduled update
The proxy server accesses the update center on a scheduled
basis to search for the latest signature databases. If the new
versions of signature databases are found, the proxy server
downloads the latest signature databases to update the local
signature databases at scheduled time.
l Immediate update
When new signature database on the network, you can
immediately update signature databases instead of waiting
for the scheduled update.
The download address and process for updating the
signature database immediately is the same as that for the
update through scheduled update. The two update modes
differ in that immediate update can be performed at any
time whereas scheduled update must be implemented at the
specified time.

Local update When the FW is physically isolated from the Internet and no
proxy server is deployed on the intranet, you can update
signature databases locally.
NOTE
The region identification signature database supports only local update.
Administrator
1 Logging in and registering

2 Obtaining the offline update package 1
3 Uploading the package to the 2
device for updating
3 Security
service center
Untrust
FW

This section describes the restrictions and precautions for you to know when configuring
update center.
Before you update the IPS signature, malicious domain name, or antivirus signature database,
ensure that the license for the specified database update service has been activated. The IPS
signature database and malicious domain name database use the same update license.
1.6.4 Managing Signature Databases Using the Web UI

This section describes how to manage signature databases using the Web UI.
1.6.4.1 Preparation
This section describes preparations for signature database updates.
Checking the License Status

Before updating a signature database, ensure that the license for the update service has been
purchased and activated.
To check the license status, perform the following operation:
Step 1 Choose System > License Management.
Step 2 In License Resource, search for the signature database to be updated. Check whether the
license is activated or expired in State.
l If State is Disable, activate the license. For operations, see 1.5.2 Managing Licenses
Using the Web UI.

l If State indicates that the service has expired, renew the corresponding license.
----End
Checking the Free Space of the Root Directory

Before updating a signature database, check whether the free space of the root directory is
sufficient. For details, see the following table.
Signature Database Required Free Space
Antivirus signature database (AV- 190 MB or higher

SDB) NOTE
The USG6000V1 requires at least 50 MB of free space.
Malicious domain name database 10 MB or higher
Intrusion prevention signature 30 MB or higher

database (IPS-SDB)
Application identification 10 MB or higher

signature database (SA-SDB)
Perform the following operation:
Step 1 Select Dashboard.
Step 2 In System Resource, move the pointer to CF Card Usage to view the CF card usage.
----End
Checking the Current Update Status

Before you update a signature database, check whether the current update status is idle,
because you can update a signature database only after the current update status is idle.
Details are as follows:
Step 1 Choose System > Update Center.
Step 2 In Update Center List, view Status of the signature database to be updated.
If the current update status is not idle, wait until it is idle.
----End
Checking the Signature Database Version

Check the signature database version to determine whether the signature database needs to be
updated.
Details are as follows:

Step 2 In Update Center List, view Status of the signature database to be updated and determine
whether it requires an update.
----End
1.6.4.2 Scheduled Update

You can configure scheduled update if the FW can access the update server directly or
through the proxy server.
Prerequisites
l A license is available for updating the signature database, and the license is activated on
the FW.
l The FW can access the update server directly or through the proxy server.
l If the FW can access the update server directly, a security policy must have been
configured to permit HTTP and FTP traffic. If the FW can access the update server
through the proxy server, a security policy must have been configured to permit HTTP
traffic.
Procedure
Step 2 Click Server IP Address.
Step 3 In the Configure Server dialog box that is displayed, set the IP address of the update server.
Server IP Address Enter the IP address of the server that the FW accesses for the
scheduled update. By default, update through Huawei security
center (domain name: sec.huawei.com) is used.
NOTE
l You must configure the DNS to parse the domain name of the
security center. For details, see 4.6.4 DNS Configuration Using
the Web UI.
l To update through another update server, set the server IP address
to that of the specified update server.
port Enter the port of the server. The default value is 80.
Connect to the upgrade If the FW cannot access the update center directly, select this
center through a proxy item and configure a proxy server for the update.
server
Address If the FW cannot communicate with the update center over the
Internet, configure a proxy server to connect to the update
center and download signature databases for the FW. The
proxy server address can be an IP address or domain name.
NOTE
If a proxy server domain name is used, you must configure DNS to
resolve the domain name. For details, see 4.6.4 DNS Configuration
Using the Web UI.

Port Enter the port of the proxy server.
User Name Enter the user name and password for logging in to the proxy
server.
Password
Step 4 Click OK.
Step 5 Select Scheduled Update for the signature database to be updated.
Step 6 Click Scheduled Update time and set the time for the scheduled update.
Scheduled update of signature databases includes:
l Download Only: The FW regularly downloads the signature database to the specified
path but does not install the downloaded signature database.
l Download And Install: The FW regularly downloads and automatically installs the
signature database. By default, the system downloads and installs the signature database.
Step 7 Click OK.
Step 8 After the update is complete, you can view that Status is The online upgrade succeeded.
and Current Version is the target version.
If Configure Scheduled Update Time is set to Download Only, Status is displayed as The
download succeeded. Click Install immediately to install the signature database. After the
installation succeeds, Status is displayed as The loading succeeded.
NOTE
If the scheduled update consumes too much bandwidth and interrupts normal services of the FW, you
can run the update abort command to abort the update process.
----End
1.6.4.3 Immediate Update

You can always update signature databases anytime you want.
Prerequisites
the FW.
traffic.
Context
For scheduled and immediate updates, signature database download addresses (IP address of
the server configured on the FW or the IP address of the proxy server) and update procedures
are the same.

Procedure
Step 2 Click Server IP Address.
Step 3 In the Configure Server dialog box that is displayed, set the IP address of the update server.
Server IP Address Enter the IP address of the server that the FW accesses for the
scheduled update. By default, update through Huawei security
center (domain name: sec.huawei.com) is used.
NOTE
l You must configure the DNS to parse the domain name of the
security center. For details, see 4.6.4 DNS Configuration Using
the Web UI.
l To update through another update server, set the server IP address
to that of the specified update server.
port Enter the port of the server. The default value is 80.
Connect to the upgrade If the FW cannot access the update center directly, select this
center through a proxy item and configure a proxy server for the update.
server
Address If the FW cannot communicate with the update center over the
Internet, configure a proxy server to connect to the update
center and download signature databases for the FW. The
proxy server address can be an IP address or domain name.
NOTE
If a proxy server domain name is used, you must configure DNS to
resolve the domain name. For details, see 4.6.4 DNS Configuration
Using the Web UI.
Port Enter the port of the proxy server.
User Name Enter the user name and password for logging in to the proxy
server.
Password
Step 4 Click OK.
Step 5 Click Update Immediately for the specified signature database.
Step 6 Click OK.
Step 7 After the update is complete, you can view that Status is The online upgrade succeeded.
and Current Version is the target version.
NOTE
If the immediate update consumes too much bandwidth and interrupts normal services of the FW, you
can abort the update process.
----End

1.6.4.4 Local Update

If the device cannot access the security center, locally update the signature databases. The
region identification signature database supports only local update.
Prerequisites
The update package has been uploaded to the root directory of the FW using the Web
interface.
Procedure
Step 1 Download the update package.
l AV-SDB, SA-SDB,Malicious domain database, and IPS-SDB: Download update
packages from the security center (sec.huawei.com). For details, refer to Help of the
security center.
The abbreviations of each signature database in the security center are as follows:
– Antivirus signature database: AV
– Application identification signature database: SA
– Malicious domain name database: CNC
– Intrusion prevention signature database: IPS
l The region identification signature database supports only local update. The database is
released irregularly. You can obtain an update file using either of the following methods:
– Log in to the technical support website and download the signature database from
the Downloads area.
– Download the update file from sec.huawei.com.
Step 2 Upload the update package to the specified directory of the FW.
NOTE
The signature database files are in ZIP format. You can upload them directly to the FW without
decompressing them.
Step 4 Click Update Locally for the specified signature database.
Step 5 Click Browse... and select the desired update package.
Step 6 Click Update.
Step 7 After the update is complete, Status is The local upgrade succeeded., and Current Version
is the target version.
----End
1.6.4.5 Version Rollback

If an exception occurs after a signature database is updated, you can roll back the signature
database to the source version.

Context
You can roll back to only one version. If you perform version rollbacks repeatedly, the version
rollback is implemented between the current version and the rollback version.
Procedure
Step 2 Click Roll Back for the specified signature database.
Step 3 Click OK.
Step 4 After the rollback is complete, Status is The version rollback succeeded, and Current
Version is the source version.
----End
1.6.5 Managing Signature Databases Using the CLI

This section describes how to manage signature databases using the CLI.
1.6.5.1 Preparation
This section describes preparations for signature database updates.
Checking the License Status

Before updating a signature database, ensure that the license for the update service has been
purchased and activated.
To check the license status, perform the following operation:
Step 1 Run the display license command to check whether the required license has been activated or
has expired.
<sysname> display license
Device ESN is: A9BFDA9904B737xxxxxxxxxxxxxxxx
The file activated is: hda1:/license.dat
The time when activated is: 2015/08/08 14:21:01
The time when expired is: 2016/08/08
Basic License: ENABLED
Virtual System: 20
Encryption Function: ENABLED
IPS Update : ENABLED; service expire time: 2016/08/08
Anti Virus Update : ENABLED; service expire time: 2016/08/08
l If the status of the signature database to be updated is Disabled, activate the license. For
details on how to activate the license, see 1.5.3 Managing Licenses Using the CLI.
l If the status of the signature database to be updated is Enabled, check whether the
license has expired. If yes, purchase the license.
----End

Checking the Free Space of the Root Directory

Before updating a signature database, check whether the free space of the root directory is
sufficient. For details, see the following table.
Signature Database Required Free Space
Antivirus signature database (AV- 190 MB or higher

SDB) NOTE
The USG6000V1 requires at least 50 MB of free space.
Malicious domain name database 10 MB or higher
Intrusion prevention signature 30 MB or higher

database (IPS-SDB)
Application identification 10 MB or higher

signature database (SA-SDB)
To check the free space of the root directory, perform the following operations:
Step 1 In the user view, run the dir command to check the free space of the root directory on the
MPU.
<sysname> dir
Directory of hda1:/
Idx Attr Size(Byte) Date Time FileName

0 -rw- 754 Feb 06 2015 15:35:33 private-data.txt
1 -rw- 5,805 Feb 06 2015 15:35:51 cfgfile.zip
2 drw- - Feb 06 2015 09:07:58 default-sdb
3 drw- - Jul 08 2014 17:02:48 conf
........
48 -rw- 36 Jan 30 2015 10:28:44 $_patchstate_reboot
49 -rw- 1,063 Feb 06 2015 09:13:26 nlog.log
50 -rw- 173,569,921 Feb 04 2015 20:31:10 sup_c30.bin
1,200,576 KB total (379,168 KB free)
Step 2 Optional: In the user view, run the delete command to delete unwanted files from the CF
card if the free space is insufficient.
NOTE
Files are deleted and cannot be restored after the delete command with the /unreserved parameter is
executed.
----End
Checking the Current Update Status

Signature databases cannot be updated simultaneously. You can update a signature database
only after the current update status is idle.
To check the current update status, perform the following operation:
Step 1 Run the display update status command to check the update status of the signature database.
<sysname> display update status
Current Update Status: Idle.

If Current Update Status is Idle, you can update the desired signature database. Otherwise,
repeat the display update status command until Current Update Status changes to Idle,
and then update the desired signature database.
----End
Checking the Signature Database Version

Check the signature database version to determine whether the signature database needs to be
updated.
To check the signature database version, perform the following operation:
Step 1 Run the display version { { av-sdb | cnc | ips-sdb | sa-sdb } * | location-sdb } command to
check the signature database version.
# View the version of a region identification signature database.
<sysname> display version location-sdb
Location SDB Update Information List:
----------------------------------------------------------------
Current Version :
Signature Database Version : 2014010414
Signature Database Size(byte) : 836969
Update Time : 08:13:19 2014/08/26
Issue Time of the Update File : 14:07:35 2014/01/04
Backup Version :
Signature Database Version : 0
Signature Database Size(byte) : 0
Update Time : 00:00:00 0000/00/00
Issue Time of the Update File : 00:00:00 0000/00/00
----------------------------------------------------------------
----End
1.6.5.2 Determining Signature Database Update Options

You can choose "download only" or "download and install" when it comes to signature
database update.
Context
Signature database updates offer two options:
l Download only: After signature databases are downloaded, you must manually install
them.
l Download and install: Signature databases are automatically installed after being
downloaded.
By default, the system downloads and installs the signature database. For details about how to
change the update option, see Procedure. If you choose to use the "download and install"
option, install the signature database after downloading it.
Procedure
system-view
Step 2 Enable the signature database update confirmation function.

update confirm { av-sdb | cnc | ips-sdb | sa-sdb } enable

If a new signature database exists on the FW and needs to be installed, go to Step 3.
Step 3 Install the downloaded signature database.

update apply { av-sdb | cnc | ips-sdb | sa-sdb }
----End
Follow-up Procedure
To restore to the default signature database update option, follow the instructions below:
1. Access the system view.

system-view
2. Disable the signature database update confirmation function.

undo update confirm { av-sdb | cnc | ips-sdb | sa-sdb } enable
1.6.5.3 Scheduled Update

After scheduled update is configured, the FW automatically downloads signature databases as
scheduled.
Prerequisites
the FW.
traffic.
Procedure
Step 1 Configure an update center.
system-view
2. Configure the update center.

update server { domain domain-name | ip ip-address } [ port port-number ]
The update center is the security center platform, and its default domain name is
sec.huawei.com.
Configure the DNS server to resolve the domain name of the update center. For details,
see Step 3.
Step 2 Optional: Configure a proxy server.
Perform this step when the FW needs to access the update center using a proxy server.
1. Enable the signature database proxy update.

update proxy enable
2. Set the domain name (or IP address), user name, and password of the proxy server.
update proxy { domain domain-name | ip ip-address } [ port port-number ]
[ user user-name [ password password ] ]

NOTE
If a domain name is configured for the proxy server, a DNS server must be configured to resolve
the domain name. For details on how to configure the DNS server, see Step 3.
Step 3 Optional: Configure a DNS server.

1. Configure the DNS server to resolve domain names.
dns resolve
2. Specify the IP address of the DNS server.

dns server ip-address
Step 4 Optional: Specify an interface over which update requests will be sent.
update host source interface-type interface-number
If VPN is used to access the Internet and scheduled or immediate update is enabled, you must
run the update host source command to specify the interface which sends the upgrade
request packets. Otherwise, the update fails.
Step 5 Enable the scheduled update function.
update
schedule { av-sdb | cnc | ips-sdb | sa-sdb } enable
Step 6 Set scheduled update time.

update schedule [ { daily | weekly { Mon | Tue | Wed | Thu | Fri | Sat | Sun } }
time ]
update schedule { av-sdb | cnc | ips-sdb | sa-sdb } { daily | weekly { Mon | Tue
| Wed | Thu | Fri | Sat | Sun } } time
NOTE
During a scheduled update, you can run the update abort command to abort the update if the update
consumes too much bandwidth and interrupts normal services. Wait until the bandwidth is sufficient for
the update and normal services and then run the update online { av-sdb | cnc | ips-sdb | sa-sdb }
command to download the latest signature database.
Step 7 Optional: Install the downloaded signature database.

You do not need to run this command if the system has been configured to download and
install the signature database. To change the signature database update option, see 1.6.5.2
Determining Signature Database Update Options.
----End
1.6.5.4 Immediate Update

You can always update signature databases anytime you want.
Prerequisites
the FW.
traffic.

Context
For scheduled and immediate updates, signature database download addresses (IP address of
the server configured on the FW or the IP address of the proxy server) and update procedures
are the same.
Procedure
Step 1 Optional: Configure an update center or a proxy server. For details, see 1.6.5.3 Scheduled
Update.
If the update center or proxy server has been configured as described in 1.6.5.3 Scheduled
Update, skip this step.
Step 2 Optional: Specify an interface over which update requests will be sent.
update host source interface-type interface-number
If VPN is used to access the Internet and scheduled or immediate update is enabled, you must
run the update host source command to specify the interface which sends the upgrade
request packets. Otherwise, the update fails.
Step 3 Download the latest signature database.

update online { av-sdb | cnc | ips-sdb | sa-sdb }
NOTE
If the immediate update consumes too much bandwidth and interrupts normal services of the FW, you
can run the update abort command to abort the signature database update. Wait until the bandwidth is
sufficient for the update and normal services and then perform Step 3 to download the latest signature
database.
Step 4 Optional: Install the downloaded signature database.

----End
1.6.5.5 Local Update

If the device cannot access the security center, locally update the signature databases. The
region identification signature database supports only local update.
Prerequisites
The update package has been uploaded to the specified directory of the FW using SFTP, FTP
or TFTP.
Procedure
Step 1 Download the update package.
l AV-SDB, SA-SDB,Malicious domain database, and IPS-SDB: Download update
packages from the security center (sec.huawei.com). For details, refer to Help of the
security center.
The abbreviations of each signature database in the security center are as follows:
– Antivirus signature database: AV
– Application identification signature database: SA

– Malicious domain name database: CNC

– Intrusion prevention signature database: IPS
l The region identification signature database supports only local update. The database is
released irregularly. You can obtain an update file using either of the following methods:
– Log in to the technical support website and download the signature database from
the Downloads area.
– Download the update file from sec.huawei.com.
Step 2 Upload the update package to the specified directory of the FW.
NOTE
The signature database files are in ZIP format. You can upload them directly to the FW without
decompressing them.

system-view
Step 4 Enable the local update function.

update local { av-sdb | cnc | ips-sdb | location-sdb | sa-sdb } file filename
----End
1.6.5.6 Version Rollback

When the current signature database is faulty (for example, false positive occurs or system
performance is degraded), you can roll back the current signature database to the previous
version through version rollbacks.
Context
You can roll back to only one version. If you perform version rollbacks repeatedly, the version
rollback is implemented between the current version and the rollback version.
Procedure
system-view
Step 2 Roll back the signature database to an earlier version.

update rollback { av-sdb | cnc | ips-sdb | location-sdb | sa-sdb }
----End
1.6.5.7 Version Restoration

If an exception occurs during the update of the signature database, you can restore the
signature database to the factory default version and perform the update again.

Context
NOTICE
If the signature database is restored to the factory default version, all other versions on the FW
are deleted. Perform the operation with caution.
Procedure
system-view
Step 2 Restore the signature database to the factory default version.

update restore sdb-default { av-sdb | ips-sdb | sa-sdb }
----End
1.6.5.8 Maintaining the Update

This section describes the operations for update troubleshooting and routine maintenance.
Checking Update Information

After the update is complete, you can run the display commands in any view to check the
update information, as shown in Table 1-25.
Table 1-25 Checking update information

Action Command
Check the version of the display version

engine or signature
database.
Check the update display update configuration

configuration.
Check the current update display update status

status.
Check the interface display update host source

which sends the upgrade
request packets.
Debugging the Update Function

When faults occur on the update module, you can run the debugging commands in the user
view to view the debugging information and locate and analyze the faults.
Before you enable the debugging function, you must run the terminal monitor and terminal
debugging commands in the user view to enable the information display function and

debugging display function of the terminal, so that debugging information can be displayed
on the terminal.
NOTICE
Enabling the debugging affects system performance. Therefore, after the debugging, you
should run the undo debugging all command to disable the debugging immediately.
For the description of the debugging commands, refer to the Debugging Reference.
Table 1-26 Debugging the update function
Action Command
Enable all the debugging functions of the debugging update all

update module.
Enable the error debugging of the update debugging update data

module.
Enable the event debugging of the update debugging update error

module.
Enable the data debugging of the update debugging update event

module.
Enable the function debugging of the update debugging update func

module.
Enable the timer debugging of the update debugging update timer

module.

This section describes the versions and changes in the Update Center.
1.7 SNMP
The Simple Network Management Protocol (SNMP) provides a set of standard protocols for
the communication between the network management station (NMS) and devices, allowing
the NMS to normally manage devices and receive alarms reported by the devices.

1.7.1 Overview
This section describes the definition and objective of SNMP.
Definition
The Simple Network Management Protocol (SNMP) is a network management protocol
widely used in the TCP/IP network. SNMP is a method of managing network elements
through an NMS which runs network management software.
Objective
As network services develop, more devices are deployed on existing networks. The devices
are not close to the central equipment room where a network administrator works. When
faults occur on the remote devices, the network administrator cannot detect, locate or rectify
faults immediately because the devices do not report the faults. This affects maintenance
efficiency and greatly increases maintenance workload.
To resolve this problem, SNMP came into being. By employing the "network management
over networks" mode, SNMP is used to manage network devices in batches. In addition,
SNMP enables the unified management of network devices of different types and from
different vendors.
1.7.2 Mechanism
This section describes the SNMP principles.
SNMP Components
SNMP device management uses the following three components:
l NMS
The NMS sends various query packets to query managed devices and receives alarms
from these devices.
l Agent
A network-management process on a managed device. An agent has the following
functions:
– Receives and parses query packets sent from the NMS.
– Reads or writes management variables based on the query type, and generates and
sends response packets to the NMS.
– Sends an alarm to the NMS when triggering conditions defined on each protocol
module corresponding to the alarm are met. For example, the system view is
displayed or closed, or the device is restarted.
l Managed device
The managed device is managed by an NMS and generates and reports alarms to the
NMS.
Figure 1-29 shows the relationship between the NMS and agent.

Figure 1-29 SNMP structure

UDP Port161
Request
Response
NMS SNMP Agent
UDP Port162
NMS SNMP Agent
MIB
A Management Information Base (MIB) specifies the variables maintained by network
elements. These variables are the information that can be queried and set by the management
process. A MIB presents a data structure, collecting all possible managed objects over the
network. The SNMP MIB adopts a tree structure like the Domain Name System (DNS) with
its root on the top without a name. Figure 1-30 shows a part of the MIB, called object naming
tree. Each managed object is uniquely identified by its object identifier.

Figure 1-30 MIB tree structure
root
ccitt(0) iso(1) Joint-iso-ccitt(2)
org(3)
dod(6)
internet(1)
directory(1) mgmt(2) experimental(3) private(4)
OID: 1.3.6.1.2
mib(1) Enterprises(1)
system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7)
...... ...... ...... ...... ...... ...... ......
The NMS mainly manages the objects under the 1.3.6.1 MIB node on the FW. This node is
also called the ViewDefault view.
SNMP Operations
SNMP uses Get and Set operations to replace a complex command set. Table 1-27 gives
details on the SNMP operations.
Table 1-27 SNMP operations
Operation Function
GetRequest Retrieves the value of a variable. The NMS sends the

request to a managed device to obtain the value of an
object on the device.
GetNextRequest Retrieves the value of the next variable. The NMS sends
the request to a managed device to obtain the status of
the next object on the device.
GetResponse Responds to GetRequest, GetNextRequest,

GetBulkRequest and SetRequest operations. It is sent
from the managed device to the NMS.
GetBulk Request from the NMS-to-agent, equaling continuous

GetNextRequest operations.

Operation Function
SetRequest Sets the value of a variable. The NMS sends the request
to a managed device to adjust the status of an object on
the device.
Trap Reports an event to the NMS.
Inform Notifies the NMS of a fault or event occurring on a

managed device. After a managed device sends an
inform request, the NMS must send an InformResponse
packet as a response to the managed device.
SNMP Version Comparison

The FW supports SNMPv1, SNMPv2c, and SNMPv3. Table 1-28 lists the features supported
by each version.
Table 1-28 Different SNMP versions' support for the features

Feature SNMPv1 SNMPv2c SNMPv3
Access Community-name- Community-name- User or user-group-

control based access control based access control based access control
supported supported supported
Authenticati Not supported Not supported Supported

on and l Authentication
encryption mode: MD5 and
SHA
l Encryption mode:
DES56
Error code 6 error codes supported 16 error codes 16 error codes

supported supported
Trap Supported Supported Supported
Inform Not supported Supported Supported
GetBulk Not supported Supported Supported
Table 1-29 lists the usage scenarios of each SNMP version.

Table 1-29 Usage scenarios of different SNMP versions
Version Usage Scenario
SNMPv1 Applies to small-scale networks whose networking is simple and

security requirements are low or whose security and stability are
good, such as campus networks and small enterprise networks.
SNMPv2c Applies to medium and large-scale networks whose security

requirements are not strict or whose security is good (for
example, VPNs) but whose services are so busy that traffic
congestion may occur.
SNMPv3 This version is applicable to networks of various scales,

especially the networks that have strict requirements on security
and can be managed only by authorized administrators, such as
the scenario where data between the NMS and managed devices
needs to be transmitted over a public network.

Read this section carefully before you configure SNMP.
l When you add users to the SNMP group, you are advised to add AAA users who use an
RADIUS or HWTACACS server for authentication, not local users.
l If a MIB Browser tool or NMS workstation connects to the FW, to ensure that the MIB
Browser tool or NMS workstation can read the MIB information on the FW, you are
advised to use SNMPv2c or SNMPv3.
l SNMPv3 is much securer than SNMPv1 and SNMPv2c. Therefore, you are advised to
use SNMPv3 rather than SNMPv1 and SNMPv2c.
1.7.4 Configuring SNMP Using the Web UI

This section describes how to use the Web UI to configure SNMP. After you configure SNMP,
the network management station (NMS) can monitor and manage the managed devices.
Step 1 Choose System > Setup > SNMP.
Step 2 Select Enable to the right of SNMP to enable SNMP.
Step 3 Set the parameters listed in Table 1-30 and Table 1-31 for connecting managed devices to the
NMS.
Step 4 Click Apply.
Table 1-30 Parameters for configuring SNMPv1 or SNMPv2c
Parameter Description Value
SNMP Version Version of SNMP. The value is negotiated with the

peer NMS.

SNMP Read- Community name used by an The read-only community name

Only NMS user to authenticate the on the NMS must be the same as
Community managed device. that on the managed devices.
Name If you configure access Otherwise, the NMS fails to access
permissions on all function the managed devices.
modules on the managed devices To enhance security, the read-only
and an NMS user uses the read- community name is suggested to
only community name for contain a minimum of eight
authentication, the user can only characters, including at least three
view the statuses of the function types of characters from the
modules. following four groups: : uppercase
letters (A to Z), lowercase letters
(a to z), digits (0 to 9), and special
characters, such as exclamation
points (!), at signs (@), number
signs (#), dollar signs ($), and
percent (%).
SNMP Read- Community name used by an The read-write community name

Write NMS user to authenticate the on the NMS must be the same as
Community managed device. that on the managed devices.
Name If you configure access Otherwise, the NMS fails to access
permissions on all function the managed devices.
modules on the managed devices To enhance security, the read-write
and an NMS user uses read-write community name is suggested to
community name for contain a minimum of eight
authentication, the user can modify characters, including at least three
the statuses of the function types of characters from the
modules. That is, the user can following four groups: : uppercase
configure the device. letters (A to Z), lowercase letters
percent (%).
Trap Receiving Trap Receiving Host: IP address of By default, the UDP port number
Host: Port: the host that receives trap packets. is 162.
Security Name Port: port on the managed device
for sending trap packets to a
destination host. Specify this
parameter when you need to use a
non-default port, for example, port
162 is in use.
Security Name: the same as the
name of the NMS server.

Source Address IP address of the source interface -

of Trap Packets for sending trap messages. When
multiple routes destined for the
NMS server exist, specifying a
source interface can ensure that
trap messages carry the IP address
of a fixed source interface. This
helps administrators identify trap
senders on the NMS server.
Device Location of the site where -

Location managed devices reside. This
helps administrators locate faulty
devices quickly.
Contact Contact information of a -

Information maintenance engineer for the
managed devices, such as a
telephone number.
Table 1-31 Parameters for configuring SNMPv3

SNMP Version Version of SNMP. The value is negotiated with the

peer NMS.
User Name User name used by an NMS user The user name on the NMS must
to access the managed device. be the same as that on the
managed devices.

Authentication Password used to authenticate The authentication password on

Password administrators. the NMS must be the same as that
The authentication ensures that on the managed devices.
only administrators that have To enhance security, the
access permissions can access the authentication password is
managed devices. The suggested to contain a minimum of
authentication function applies to eight characters, including at least
networks that are secure but have three types of characters from the
multiple administrators who following four groups: : uppercase
perform operations on the device letters (A to Z), lowercase letters
frequently. (a to z), digits (0 to 9), and special
percent (%).
NOTE
If the NMS or the managed devices
are on an insecure network (for
example, the network is vulnerable to
attacks), you are advised to enable
data authentication and encryption,
and configure the different
authentication and encryption
password.
Encryption Password used to encrypt data. The encryption password on the

Password The encryption function encrypts NMS must be the same as that on
data into cipher text to prevent the managed devices.
data interception and key data To enhance security, the
leaks. encryption password is suggested
to contain a minimum of eight
characters, including at least three
types of characters from the
following four groups: : uppercase
letters (A to Z), lowercase letters
percent (%).
Trap Receiving Trap Receiving Host: IP address of By default, the UDP port number
Host: Port: the host that receives trap packets. is 162.
Security Name Port: port on the managed device
for sending trap packets to a
destination host. Specify this
parameter when you need to use a
non-default port, for example, port
162 is in use.
Security Name: the same as the
name of the NMS server.

Source Address IP address of the source interface -

of Trap Packets for sending trap packets. When
multiple routes destined for the
NMS server exist, specifying a
source interface can ensure that
trap messages carry the IP address
of a fixed source interface. This
helps administrators identify trap
senders on the NMS server.
Device Location of the site where -

Location managed devices reside. This
helps administrators locate faulty
devices quickly.
Contact Contact information of a -

Information maintenance engineer for the
managed devices, such as a
telephone number.
----End
1.7.5 Maintaining SNMP

This section describes how to clear and monitor statistics about operations performed by the
NMS.
Clearing Statistics on Operations Performed by the NMS
NOTICE
Operation statistics cannot be restored after they are cleared. Exercise caution when running
the reset snmp-agent statistics mib command.
l Run the reset snmp-agent statistics mib [ address ipv4-address | ipv6 ipv6-address |
vpn-instance vpn-instance-name address ipv4-address ] command in the user view to
clear operation statistics.
----End
Monitoring Statistics on Operations Performed by the NMS

l Run the display snmp-agent statistics mib [ address ipv4-address | ipv6 ipv6-address |
vpn-instance vpn-instance-name address ipv4-address ] command in any view to check
operation statistics.

To disable this function due to some reasons, for example, high CPU usage caused by
collecting statistics about the NMS accessing MIB objects, run the snmp-agent
statistics mib disable command in the system view.
----End

This section describes the versions and changes in SNMP.
1.8 Across-Layer-3 MAC Identification

When the FW is connected to the intranet through layer-3 devices, configuring across-Layer-3
MAC address identification enables the FW to obtain MAC addresses of intranet PCs.
1.8.1 Overview
This section describes the definition and service flow of across-Layer-3 MAC identification.
Definition and Objective

With Across-Layer-3 MAC address identification, when a Layer-3 network device is between
the FW and intranet PCs, the FW can still learn the MAC address of the intranet PCs.
If an intranet PC uses a dynamic IP address to access the Internet, IP address cannot be used
to match the traffic to or from the PC. In this case, you need to use the MAC address as the
matching condition of policies.
However, in the across-layer-3 networking as shown in Figure 1-31 and Figure 1-32, the FW
cannot directly obtain MAC addresses of intranet PCs. You must enable across-Layer-3 MAC
address identification on the FW.
The FW across-Layer-3 MAC address identification supports the following two networking
scenarios:
Figure 1-31 FW connected to the Layer-3 network device as a Layer-3 device
L3SW FW
Intranet
GE1/0/1 GE1/0/2
10.100.10.2/24 202.38.10.2/24

Figure 1-32 FW connected to the Layer-3 network device as a Layer-2 device
L3SW FW
Intranet
GE1/0/1 GE1/0/2
Service Flow
Figure 1-33 shows the service flow of across-Layer-3 MAC address identification on the FW.
Figure 1-33 Service flow of across-Layer-3 MAC address identification

FW Layer-3 Intranet PC
device
Generate or Update ARP Entries
Periodically Sends SNMP Requests
Phase 1
Returns the ARP Entries
Saves the ARP Entries

Synchronized from Layer-3
device to the Memory
Use the Learned MAC

Phase 2 Addresses of Intranet
PCs to make policies
Accesses the Internet through the

Layer-3 device and firewall
Phase 3
Permits or Blocks Intranet
Packets Based on Configured
Policies
1. Phase 1
a. The SNMP agent on the Layer-3 network device is enabled, and the network device
obtains IP-MAC mapping of intranet PCs and generate or update ARP entries.
b. The FW periodically sends SNMP requests to the specified Layer-3 network device
for ARP entries.
c. The Layer-3 network device replies and returns the ARP entries.
d. The FW learns MAC addresses of intranet PCs and saves the ARP entries to the
memory.
2. Phase 2
An administrator can use the learned MAC addresses on the FW as conditions in
policies.

The MAC addresses are obtained from ARP entries in the memory, not from packet
header.
3. Phase 3
a. An intranet PC accesses the Internet through the Layer-3 network device and FW.
b. The FW permits or blocks intranet packets based on configured policies.
After receiving intranet PC packets, the FW compares the IP and MAC address of
the PC with the obtained ARP entries to verify whether the MAC address is the real
MAC address. The FW uses the actual MAC address to match policies and process
intranet packets based on matching results.
1.8.2 Configuring Across-Layer-3 MAC Identification Using the

Web UI
This section describes how to configure across-Layer-3 MAC identification using the Web UI.
Prerequisites
Before configuring the across-Layer-3 MAC identification function, ensure that the Layer-3
network device connected to the FW supports SNMPv2c or SNMP v3, and the SNMP agent
has been enabled and community name has been configured on the network device.
Context
Intranet users use the FW to access the Internet, and the FW uses MAC addresses as matching
conditions to control intranet traffic. If the FW uses a Layer-3 network device to connect to an
intranet PC, the FW cannot obtain the MAC address of the intranet PC directly.
Therefore, across-Layer-3 MAC address identification must be enabled on the FW to
synchronize ARP entries from the Layer-3 network device using SNMP to obtain MAC
addresses of intranet PCs.
NOTE
If multiple Layer-3 network devices are deployed between the FW and an intranet PC, you are advised
to specify a network device closest to the intranet PC as the SNMP server. The FW can serve multiple
Layer-3 devices (SNMP servers) to synchronize ARP entries.
Procedure
Step 1 Choose System > Configuration > Across-Layer-3 MAC Identification.
Step 2 Select Enable on the right of Across-Layer-3 MAC Identification.
Step 3 Optional: Enter the parameters.
Interval for Accessing SNMP Interval between two SNMP requests.

Server
Time of Failures in Accessing Length of time the SNMP server waits for a response to a
SNMP Server request sent to the target network device. You can specify
this parameter based on the update interval of a PC IP
address and the network delay.

Step 4 Click Apply.
Step 5 Add an SNMP server.

1. Click Add.
2. Configure an ID for the SNMP server.
SNMP Version SNMP version of the SNMP server:

– v2c
– v3
SNMP Server IP address of the target Layer-3 network device.

Select an IP address from the existing IP addresses of
Layer-3 network devices.
The device supports 64 Layer-3 network devices as
SNMP servers to synchronize ARP entries.
v2c Community Name Community name of SNMP server. The community

name must have been configured on the specified
Layer-3 network device, and the community name
and IP address must identify the same Layer-3
network device.
v3 Security User Name Uer name must have been configured on a specific
Layer-3 network device, and the user name and IP
address must identify the same Layer-3 network
device.
Authentication Password Authentication password must be the same as that on

the SNMP server.
Authentication Method
Encryption Password
Encryption Method
3. Click OK.
----End
1.8.3 Configuring Across-Layer-3 MAC Identification Using the

CLI
This section describes how to use the command line interface (CLI) to configure Across-
Layer-3 MAC identification.
Prerequisites
Before configuring the FW learning function, ensure that the Layer-3 network device
connected to the FW supports SNMPv2c or SNMPv3, and the SNMP agent has been enabled
and community name or user name has been configured on the network device.

Context
Intranet users use the FW to access the Internet, and the FW uses MAC addresses as matching
conditions to control intranet traffic. If the FW uses a Layer-3 network device to connect to an
intranet PC, the FW cannot directly obtain the MAC address of the intranet PC. Therefore,
across-Layer-3 MAC address learning must be enabled on the FW to synchronize ARP entries
of the intranet PCs from the specified Layer-3 network device.
NOTE
If multiple Layer-3 network devices are deployed between the FW and intranet PCs, you are advised to
specify a network device closest to the intranet PCs as a target network device. The FW can serve
multiple Layer-3 devices (SNMP agents).
This function can be configured using command lines in hot standby deployments.
Procedure
Step 1 Display the system view.
system-view
Step 2 Enable synchronization of Layer-3 network device ARP entries using SNMP in the system
view.
snmp-server arp-syn enable
Step 3 Configure the identification information of the target Layer-3 network device.
l SNMP v2c
snmp-server target-host arp-sync address ip-address [ vpn-instance vpn-instance-
name ] community community-name v2c
address and community must identify the same Layer-3 network device. If the target
network device is configured in the specified VPN instance, vpn-instance, address, and
community must identify the same Layer-3 network device.
l SNMP v3
snmp-server target-host arp-sync address ip-address [ vpn-instance vpn-instance-
name ] usm-user v3 user-name [ authentication-mode { md5 | sha } password
[ privacy-mode { 3des | aes128 | aes192 | aes256 | des56 } password ] ]
address and user-name must identify the same Layer-3 network device. If the target
network device is configured in the specified VPN instance, vpn-instance, address, and
user-name must identify the same Layer-3 network device.
NOTE
With across-Layer-3 MAC identification, the FW can specify multiple Layer-3 network devices as
SNMP servers to obtain ARP entries using SNMP. The device supports 64 Layer-3 network devices as
SNMP servers to synchronize ARP entries.
Step 4 Configure the SNMP request interval or request timeout period.
snmp-server arp-sync { interval interval | timeout time } *
You can specify timeout time based on the update interval of a PC IP address and the network
delay.
----End

Example
# Specify a Layer-3 network device and enable the firewall to learn MAC addresses of
intranet PCs and set the IP address of the network device to 10.10.90.7 and community name
to Public@123.
<sysname> system-view
[sysname] snmp-server arp-syn enable
[sysname] snmp-server target-host arp-sync address 10.10.90.7 community
Public@123 v2c
[sysname] snmp-server arp-sync interval 10 timeout 5
Follow-up Procedure
Run the display snmp-server arp-sync table [ vpn-instance vpn-instance-name ] command
to view ARP entries obtained using SNMP.
<sysname> display snmp-server arp-sync table
Synchronization status of the IP-MAC address mapping table: Done
The start time of synchronizing IP-MAC mapping table: 2013/8/2 09:39:24
The end time of synchronizing IP-MAC mapping table: 2013/8/2
09:39:28
----------------------------------------------------------------------------------
-------------
IP Address MAC Address Expire(M) VPN
Instance
----------------------------------------------------------------------------------
-------------
10.10.90.220 0022-a105-b948
20
10.10.90.33 0000-1111-0000 20
----------------------------------------------------------------------------------
-------------
Total:2
The display information above includes obtained ARP entries. The synchronization status is
Done, indicating that ARP entry synchronization between the device and target network
device is complete.

This section describes the versions and changes in the across-Layer-3 MAC identification
feature.
1.9 Logs
You can display logs to gain visibility into device operating, which facilitates fault location.
1.9.1 Overview
This section describes basic log concepts.
Logs are information output during FW operating. You can display logs to learn about service
running status and functional module operating status on the FW.

Log Type
The FW supports the following types of logs:
l Session logs
After processing a packet, the FW sets up a session for it. The FW supports session logs.
You can enable the FW to output session logs after a session ages, when a session is
created, or regularly.
l Packet discard logs
After discarding a packet, the FW logs the packet information and packet discard cause.
The packet discard cause may be session table mismatching, failure to match any
security policy.
l Service Logs
The FW can output service logs, such as traffic, threat,policy matching logs.
l System logs
The FW can output the operating information about functional modules, including
administrator login/logout logs, attack defense logs, blacklist logs, service awareness
(SA) logs, intrusion prevention logs, and IP-CAR logs. You can refer to the Log
Reference to learn system log information generated by the functional modules on the
FW.
In addition, the FW can output NAT444 port pre-allocation logs. For details on port pre-
allocation, see NAT444.
Log Format
The FW supports the following log formats:
l Binary
Session Logs in binary format occupy few network resources. However, before viewing
binary logs, enable the FW to output them to a log server.
l Syslog
Session logs, packet discard logs and system logs in syslog format are displayed in texts.
l Netflow
The FW can also output session logs in netflow format to a log server for you to analyze
IP packet flows on the network.
l Dataflow
The FW outputs service logs in dataflow format to a log server.
Log Output Mechanism

On the FW, the log output mechanisms vary with log types, as shown in Figure 1-34.

Figure 1-34 Log output mechanism
Session logs
Packet discard Binary/Syslog/Netflow/Dataflow

logs
Log host
Port pre-allocation
logs
Service logs
Hard disk
Log query
Database and report Web UI-Monitor
processing
Log cache Log retrieval WebUI-Dashboard
Log buffer CLI/Web UI
Remote terminal
Information channel
System logs Console

Syslog
Log host
Log file
Information center
l The FW outputs session logs, packet discard logs, and port pre-allocation logs to a log
server through separate channels for you to view and analyze.
l The FW outputs service logs to a log server in separate channels for you to view and
analyze, outputs them to the memory database for the log query module for further
process before logs and reports are displayed on the web UI (for details, see Logs and
Reports), outputs them to to the log buffer and displays them on the Dashboard of web
UI, or outputs them to the information center.
l The FW outputs system logs from the information center. The information center is an
information hub of system software modules on the FW. It can output system logs to
specific log servers, log buffers, console (console user interfaces), log file, or terminals
(VTY user interfaces). You can view system logs on the FW or log server.

Log Server (Log Host)

To ensure that the FW and log server can communicate properly, you need to set the
parameters on the FW for the FW to communicate with the log server.
If the network has multiple log servers, configure all of them on the FW to for the log servers
to back up each other.
1.9.2 Mechanism
This section describes the log mechanism.
1.9.2.1 Session Logs

The FW can output session information in different formats to log hosts.
Outputting Logs After Sessions Are Aged Out

The FW can enable the session log function in the security policy to output logs after sessions
are aged out.
Outputting Logs When Sessions Are Created

For IPv4 traffic, the FW outputs session information in binary, syslog, or netflow format to a
log host when a session is created.
For IPv6 traffic, the FW outputs session information in binary or netflow sessions only)
format to a log host when a session is created.
Outputting Logs Regularly

For IPv4 traffic, the FW outputs session information in binary, syslog, or netflow format to a
log host regularly based on the specified interval.
Outputting NAT No-PAT Logs

For IPv4 traffic, the FW outputs session information in binary format to a log host when NAT
No-PAT is performed.
Session Log Output Mechanism

Table 1-32 lists the session log types and formats supported by the FW as well as the log
output mechanisms.
Table 1-32 Details on session log types, formats, and log output mechanisms
Log Type IPv4/IPv6 Log Format Log Output
Mechanism
Session Outputs logs Supports l Binary Outputs logs to a

logs after sessions IPv4. l Syslog log server.
are aged out.
l Netflow


Mechanism
Supports l Binary
IPv6. l Netflow only)
Outputs logs Supports l Binary Outputs logs to a

when IPv4. l Syslog log server.
sessions are
created. l Netflow
Supports l Binary
IPv6. l Netflow only)
Outputs logs Supports l Binary Outputs logs to a

regularly. IPv4. l Syslog log server.
l Netflow
Does not - -
support IPv6.
Outputs NAT Supports Binary Outputs logs to a

No-PAT logs. IPv4. log server.
Does not - -
support IPv6.
1.9.2.2 Packet Discard Logs

The FW can output packet discard information in syslog format to log hosts.
For IPv4 traffic, if a packet is discarded, the FW can output the packet information and
discard cause in syslog format to a log host. The packet discard cause may be session table
mismatching, failure to match any security policy, or default packet filtering.
Table 1-33 lists the packet discard log formats supported by the FW as well as the log output
mechanisms.
Table 1-33 Details on packet discard log formats, and log output mechanisms
Mechanism
Packet discard logs Supports Syslog Outputs logs to a

IPv4. log server.
Does not - -
support IPv6.

1.9.2.3 Service Logs

The FW can output security service logs. You can view these logs on the web UI or a log
server.
Service logs on the FW includes traffic, threat,policy matching logs.
The FW can output service logs to the web UI, a log host, or the information center for you to
understand the operating of services and networks.
1.9.2.4 System Logs

The FW can output the logs generated on its functional modules in syslog format from the
information center.
The FW outputs system logs from the information center. The information center is an
information hub of system software modules on the FW. The information center classifies the
output information in a fine-grained manner to effectively filter information.
NOTE
Except logs, the information center can also output alarm and debugging information. This section
describes only logs. For details on alarm and debugging information, see 1.10 Alarms and 1.11 Debugs.
Information Categorization
Information has eight levels based on its severity and emergency. More critical information
has a lower level, as shown in Table 1-34.
Table 1-34 Information severity levels
Value Severity Level Description
0 Emergency Critical device fault which causes the system unable to

recover, and device restart is required. For example,
program exception causes device restart or memory
usage error.
1 Alert Major device fault which requires an immediate solution.

For example, the device memory usage reaches the upper
limit.
2 Critical Major device fault which requires a solution or cause

analysis. For example, the memory usage exceeds the
lower limit, BFD detects that a device is unreachable, or
an error message is detected (the message is from the
inside device).
3 Error Incorrect operations or abnormal device processing that

do not affect subsequent services but require attention
and cause analysis, such as incorrect commands,
incorrect passwords, and detection of error packets (the
packets are detected by another device).

Value Severity Level Description
4 Warning Device operating exceptions that may cause service

failures. such as routing process disabled, packet loss
detected by BFD, and detection of error protocol packets.
5 Notice Key device operating information, such as the execution

of the shutdown command and neighbor discovery.
6 Informational General device operating information.
7 Debugging General device operating information that requires no

attention.
The FW outputs only the information of the specified severity level and more critical levels.
That is, the FW outputs information with the specified value and the smaller values.
For example, if the severity level for filtering information is set to 6, the FW outputs
information with severity levels from 0 to 6.
Information Output
The information center defines 10 information channels independent from each other to
facilitate information output control in each direction. You can configure system log output
rules for the FW to output specific information from specific information channels to specific
directions, as shown in Figure 1-35.
Figure 1-35 Schematic diagram of outputting system logs
Logs Infomation channels Output directions

0
Console Console
1 Remote
Monitor
terminal
2
Loghost Loghost
3 Trapbuffer
Logbuffer Log buffer

4
5 SNMP agent
6 channel6
7 channel7
8 channel8
channel9 Logfile
9

Table 1-35 shows the mapping between information channels and output directions.
Table 1-35 Information channels and output directions

Chan Default Output Description
nel ID Channel Direction
Name
0 console console Local console that can receive logs, alarms, and
debugging messages.
1 monitor monitor VTY terminal that can receive logs, alarms, and
debugging messages to facilitate remote
maintenance.
2 loghost loghost Log host that can receive logs, alarms, and
debugging messages. Information is stored as
files on log hosts.
3 trapbuffer trapbuffer Trap buffer that can receive alarm information.

The buffer allocated inside the FW is used to
record information.
4 logbuffer logbuffer Log buffer that can receive log information. The
buffer allocated inside the FW is used to record
information.
5 snmpagent snmpagent SNMP agent that can receive alarm information.
6 channel6 Unspecified Reserved. The customer can specify the output

direction.

direction.

direction.
9 channel9 logfile Log file that can receive logs, alarms, and
debugging messages. The information is saved as
files on the FW CF card.
When multiple log hosts are configured, you can enable the FW to output system logs from
one or more channels to different logs hosts. For example, the FW can output some system
logs from channel 2 (loghost) to one log host and some other logs from channel 6 to another
log host. You can also change the name of channel 6 to facilitate information channel
management.
Log Format
Figure 1-36 lists the formats of system logs.
Figure 1-36 Output formats of system logs

<Int_16>TIMESTAMP HOSTNAME %%ddAAA/B/CCC(l)[N]:YYYY

Table 1-36 describes the details of each field.
Table 1-36 Description of system log formats
Field Meaning Description
<Int_16> Preamble The FW adds a preamble before sending logs to a

log host.
If logs are saved on the FW, the preamble is not
saved.
TIMESTAMP Timestamp, indicating Five timestamp formats are available:

the information l Boot: relative time.
output time.
l Date: system time. System logs use the date
timestamp by default.
l Short-date: same as the date format except
that the short-date timestamp does not include
the year.
l Format-date: another system time format.
l None: The information does not contain any
timestamp.
The timestamp and host name are separated by a
space.
HOSTNAME Host name The default value is FW.
%% Huawei identifier Indicates that a log is output by a Huawei device.
dd Version Identifies the version of the log format.
AAA Module name Indicates the name of the module that outputs
information to the information center.
B Log level Indicates the level of the log information.
CCC Brief description Further describes the type of the information.
(l) Information category 1: Log identifier
[N] Log position Display the position of the current log in the log
queue.
YYYY Description Details on the information that each module

outputs to the information center. Each module
adds a description before sending a log to
describe log details.

Read this section carefully before you configure logs.

l Table 1-37 lists the mappings between log formats and log servers. Select a log server as
required.
Table 1-37 Mappings between log formats and log servers

Log Format Log Server
Binary eLog
Netflow eLog
Syslog l Session logs, packet discard logs, and IM logs are output to an
eLog server if in the default format and to a third-party log server
if in MTN format.
l For system logs, you are advised to use an eLog server or a third-
party log server.
Dataflow eLog
1.9.4 Configuring Logs Using the Web UI

This section describes how to configure logs on the web UI.
Prerequisites
The system time setting is correct during the initial configuration. Changing system time
during device running results in incorrect timestamps in existing logs.
To output policy matching logs and session logs to log hosts, choose Policy > Security Policy
and enable Record Policy Matching Log and Record Session Log.
Configuring Syslog Output

After a syslog host is configured, the FW sends the syslogs it has generated to the syslog host.
The syslog host analyzes and maintains the syslogs.
Step 1 Choose System > Log Configuration.
Step 2 Configure the syslog sending function.

Log Host IP Address IP address of the log host that receives syslogs from the FW
This IP address must be the actual IP address of the log host.
Destination Port Port number of the log host that receives syslogs from the FW
This port number must be the actual port number configured
on the log host. The default port number on the log host is 514.
Language Language in which syslogs are sent to a log host

To ensure that the log collector of the log host correctly
analyzes logs, select the language that the log collector
supports.

Send Interface Source interface that sends information to a syslog host

If you do not specify this parameter, the source interface is the
interface that sends logs.
This interface must exist on the FW and have an IP address.
Step 3 Click and repeat the preceding steps to add more log hosts.
If multiple log hosts are configured, the FW sends the same syslogs to different log hosts for
syslog backup.
Step 4 Click Apply.
If the Operation succeeded dialog box is displayed, the syslog sending function has
been configured.
----End
Configuring Session Log Output

After you configure the session log host, the FW sends the session logs to the session log host
for log analysis and management.
Step 2 Configure the session log.

Log Format Log format:

l Binary
l Syslog
l Netflow
Send Binary Logs to All If Send Logs Concurrently is selected, session logs are sent to
Log Servers all log hosts.
If not, the device sends logs to all log hosts in turn based on the
specified log host IDs.
Log Source IP Address Source IP address for sending session logs
Source Port Source port of session logs. The default port is 1617.
Log Host IP Address IP address of the log host that receives session logs
Port Port of the log host that receives session logs. The default port
number depends on the log format.
The mappings between them are as follows:
l Binary: 9002
l Syslog: 514
l NetflowL: 9996

Encryption Transmit If Enable is selected, logs will be encrypted.
Password Password for the encryption. You must set the same password
on the log server.
Confirm Password Password for the encryption.
Step 3 Click and repeat the preceding steps to add more log hosts.
Step 4 Click Apply.
If the Operation succeeded dialog box is displayed, the session log sending function
has been configured.
----End
Configuring Service Log Output

During service log output configuration, if the log format is set to dataflow, the log host
specified in the session log is used to output service logs; if the log format is set to Syslog, the
log host specified in the syslog is used to output service logs.
NOTICE
When service logs are output in dataflow format, the destination port number of packets is
fixed to 9903 and cannot be changed. The eLog host also uses port 9903 to receive service
logs. When service logs are output in Syslog, the destination port number of packets is the one
configured in Configuring Syslog Output. Because the eLog host always uses interface 514
to receive logs in Syslog format, the port number must be set to 514 in Configuring Syslog
Output.
Step 2 Configure the service log.

Log Format Log format:

l dataflow
l Syslog
Step 3 Click Apply.
If the Operation succeeded dialog box is displayed, the service log sending function
has been configured.
----End

Configuring SA
The FW enables SA by default and displays application information in service logs.
Step 2 Select Enable corresponding to SA.

If a security policy references an application or application group, SA cannot be disabled.
Step 3 Click Apply.
If the Operation succeeded dialog box is displayed, the SA function has been
configured.
----End
1.9.5 Configuring Logs Using the CLI

This section describes how to configure logs on the CLI.
1.9.5.1 Configuring the FW to Send Session Logs to a Log Host

After you enable the FW to send session logs to a log host, you can view and analyze the
session logs generated on the FW on the log host.
Configuring a Log Host

The FW can output session logs to two groups of log hosts. Each group contains a maximum
of 16 log hosts. These two groups can back up each other.
To improve reliability of the links between the FW and log hosts, you can use the IP-Link
function to detect link status. After the IP-Link function is enabled, the FW sends logs to log
hosts only when the IP-Link is Up.

system-view
Step 2 Set the log host receiving session logs.

firewall log host host-id ip-address port [ vpn-instance vpn-instance-name ]
[ secondary ] [ track ip-link link-name ]
If vpn-instance is specified, the session logs generated on the public system are output to the
log host on the virtual system specified by vpn-instance.
If you set the secondary parameter, the log host belongs to the secondary log host group.
NOTICE
For the eLog server, if the log format is binary, port 9002 is used; if the log format is netflow,
port 9996 is used; if the log format is syslog, port 514 is used.
Step 3 Set the source IP address and port for the FW to send session logs.
firewall log source ip-address port

Step 4 Optional: Configure the log concurrent function.

firewall log session multi-host-mode concurrent
If multiple log hosts are configured on the FW, the FW sends logs to the log hosts in turn. To
be specific, one log is sent to only one log host.
After the log concurrent function is enabled, the FW sends each log to every log host.
Step 5 Optional: Enable the log encryption function.
firewall log password password
After you run this command, the FW will use the specified encryption password to encrypt
the logs before sending. After receiving the binary logs, the log host will use the decryption
password to decrypt the logs. This ensures the log transmission security. The encryption
password specified on the FW and the decryption password specified on the log host must be
the same.
----End
Setting the Log Output Format

The FW can output session logs in binary, syslog, and netflow formats to log hosts.

system-view
Step 2 Set the output format of session logs.

firewall log session log-type { netflow | syslog }
The default output format of session logs is binary.
NOTICE
l The FW outputs only IPv4 session logs in syslog format. If you set the output format of
session logs to syslog, then IPv6 session logs are output in binary format.
l The FW can output only IPv4 session logs If you set the output format of session logs to
netflow, then general IPv6 session logs are output in binary format.
l If the session log format is set to netflow, the log host must be an eLog server.
Step 3 Optional: Set the MTN format for the output of session logs in syslog format.
firewalllog syslog content format mtn
You can use this command only when the syslog format is employed to output session logs.
The default log format is default when the syslog format is employed to output session logs.
NOTE
A log in the default format contains a keyword and value, such as:
SourceIP=172.16.36.196,DestinationIP=128.18.75.33,SourcePort=4408,DestinationP
ort=80......
A log in the MTN format contains a complete sentence, such as:
172.16.36.196:4439[128.18.75.33:4439] (trust) to
128.18.75.33:80[172.16.36.196:80] (trust)......

Step 4 Optional: Specify the log header format when the syslog format is employed to output
session logs.
firewall log syslog header { default [ timestamp { utc | local | none } ] | host-
name | none }
If the default log header format (default) is used and no timestamp type is specified, the UTC
time applies by default.
If you specify parameter host-name, the log header contains only the device name. If you
specify parameter none, the output logs do not contain any log header.
Step 5 Optional: Specify the timestamp of log headers for session logs in netflow format.
firewall log netflow header default timestamp { utc | local }
The device uses UTC as the default timestamp.
----End
Enabling the Session Log Function in a Security Policy

The FW can enable the session log function in the security policy to output logs after sessions
are aged out.

system-view
Step 2 Access the security policy view.

security-policy
Step 3 Access the security policy rule view.

rule name rule-name
Step 4 Define the match conditions of the security policy.
The detailed configuration process is omitted.
Step 5 Set the action of the security policy.

action permit
The session log function takes effect only when the policy action is set to permit.
Step 6 Enable the session log function.

session logging
By default, the session log function is disabled.
----End
Enabling the Function of Sending Session Creation Logs

The FW can send new session information to a specific log host only after the function of
sending session creation logs is enabled.

system-view
Step 2 Enable the function of sending session creation logs.

firewalllog session new-session enable

The function of sending session creation logs is disabled by default.
----End
Enabling the Function of Periodically Sending IPv4 Session Logs

The FW can send IPv4 session information to a specific log host periodically only after the
function of periodic IPv4 session log sending is enabled.

system-view
Step 2 Enable the function of periodically sending IPv4 session logs.

firewall log session periodic enable
The function of periodically sending IPv4 session logs is disabled by default.

Step 3 Optional: Set an interval for periodically sending IPv4 session logs.
firewall log session periodic time-interval timevalue
timevalue indicates the interval for the FW to send IPv4 session logs. The default value is 180
minutes.
----End
Enabling the Function of Sending NAT No-PAT Logs

The FW can send NAT No-PAT session information to a specific log host only after the
function of sending NAT No-PAT logs is enabled.
NOTICE
NAT No-PAT logs must be output in binary format to log hosts.

system-view
Step 2 Enable the function of sending NAT No-PAT logs.

firewall log nat-nopat enable
The function of sending NAT No-PAT logs is disabled by default.
----End
Enabling the Function of Sending Half-Connection Session Logs

system-view
Step 2 Enable the function of sending half-connection session logs.

firewall log session half-connection enable
This function is disabled by default.
----End

1.9.5.2 Configuring the FW to Send Service Logs to a Log Host

After you configure the FW to send service logs to a log server, you can display and analyze
the service logs generated on the FW on the log server.
Configuring a Log Host

The FW can output service logs to two groups of log hosts. Each group contains a maximum
of 16 log hosts. These two groups can back up each other.

system-view
Step 2 Set the log host receiving service logs.

If vpn-instance is specified, the service logs generated on the public system are output to the
log host on the virtual system specified by vpn-instance.
NOTICE
The FW can output service logs to a log host in either dataflow or syslog format. If service
logs are output in dataflow format, use the configured log host to output service logs. The port
number must be set to 9903. The eLog host also uses port 9903 to receive service logs.
Step 3 Set the source IP address and port for the FW to send service logs.
Step 4 Optional: Enable the log concurrent function.

If multiple log hosts are configured on the FW, the FW sends logs to the log hosts in turn. To
be specific, one log is sent to only one log host.
After the log concurrent function is enabled, the FW sends each log to every log host.
the same.
----End

Enabling the Service Log Function

system-view
Step 2 Enable the traffic log function.

log type traffic enable
By default, the traffic log function is enabled.
Step 3 Enable the service log function.

engine log
By default, the service log function is enabled.
Step 4 Run the following commands to enable the policy matching log function.
1. Run the log type policy enable command to enable the function of generating policy
matching logs.
By default, this function is enabled.

2. Run the security-policy command to access the security policy view.
3. Run the rule name rule-name command to access the security policy rule view.
4. Run the policy logging command to enable the policy matching log function.
By default, the policy matching log function is disabled.
----End
1.9.5.3 Enabling the FW to Send Packet Discard Logs to a Log Host

After you enable the FW to send packet discard logs to a log host, you can display and
analyze the packet discard information generated on the FW.
Configuring Log Hosts

The FW can output packet discard logs to two groups of log hosts. Each group contains a
maximum of 16 log hosts. These two groups can back up each other.

system-view
Step 2 Set the log host for receiving packet discard logs.
If you set the vpn-instance parameter, the FW outputs the packet discard logs generated in
the public system to the log host of the virtual system specified by the vpn-instance
parameter.

NOTICE
If the log host is an eLog server and the log format is syslog, the port must be set to 514.
Step 3 Run:
The source IP address and port used for the FW to send packet discard logs are specified.
Step 4 Optional: Enable the concurrent log sending function.

If multiple log hosts are configured on the FW, the FW sends session logs to multiple log
hosts in turn by default.
After you enable the concurrent log sending function, the FW sends each log to all log hosts.
the same.
----End
Enabling the Function of Sending Packet Discard Logs

The FW can send packet discard information to a specific log host only after the function of
sending packet discard logs is enabled.

system-view
Step 2 Enable the function of sending packet discard logs.

firewall log packet-discard enable
The function of sending packet discard logs is disabled by default.
Step 3 Set the packet discard log type.

firewall log packet-discard { session-miss | packet-filter | default-packet-
filter }
l If parameter session-miss is used, the FW sends a log when a packet mismatches the
session table.
l If parameter packet-filter is used, the FW sends a log when a packet is discarded
because the packet matches a security policy.
l If parameter default-packet-filter is used, the FW sends a log when a packet is
discarded because of default packet filtering.
----End

Configuring the Header of Packet Discard Logs
NOTICE
The FW sends packet discard logs to log hosts only in syslog format.
You can also set the header of the packet discard logs that the FW sends in syslog format.

system-view
Step 2 Set the MTN format for the output of packet discard logs in syslog format.
firewalllog syslog content format mtn
The default log format is default when the syslog format is employed to output packet discard
logs.
NOTE
A log in the default format contains a keyword and value, such as:
SourceIP=172.16.36.196,DestinationIP=128.18.75.33,SourcePort=4408,DestinationP
ort=80......
A log in the MTN format contains a complete sentence, such as:
172.16.36.196:4439[128.18.75.33:4439] (trust) to
128.18.75.33:80[172.16.36.196:80] (trust)......
Step 3 Specify the log header format when the syslog format is employed to output packet discard
logs.
firewall log syslog header { default [ timestamp { utc | local | none } ] | host-
name | none }
If the default log header format (default) is used and no timestamp type is specified, the UTC
time applies by default.
If you specify parameter host-name, the log header contains only the device name. If you
specify parameter none, the output logs do not contain any log header.
----End
1.9.5.4 Configuring the FW to Output Service Logs and System Logs to a Log
Host Through the Information Center
This section describes how to enable the FW to output service logs and system logs from the
information center so that you can learn the FW operating status after system log analysis.
1.9.5.4.1 Enabling the Information Center

The FW can output logs only after the information center is enabled.
Context
By default, the information center is enabled on the FW. If the information center is disabled,
perform the following operations to enable the information center.

NOTICE
When the information center is enabled and the system is busy sorting and outputting
information, system performance is affected.
Procedure
system-view
Step 2 Enable the information center.

info-center enable
Step 3 Optional: Name an information channel.

info-center channel channel-number name channel-name
Each information channel must have a unique name, and the channel names must represent
the actual channel functions.
Step 4 Optional: Configure a timestamp for logs.
info-center timestamp log { none | boot | { date | short-date | format-date }
[ precision-time { tenth-second | millisecond } ] }
The default log timestamp format is date.

Step 5 Optional: Configure log filtering for specified logs.
info-center filter-id { id | bymodule-alias modname alias } &<1-50> [ bytime
interval | bynumber number ]
Currently, only 50 IDs can be shielded. The aggregation of these shielded IDs is called a log
ID filtering list. The log ID filtering list is arranged by ID values.
Step 6 Optional: Run the following commands to configure the log suppression function.
During the running of a device, if too many logs with the same log ID are generated, the
information center is too busy processing these logs to process logs with other log IDs, which
may even affect the running service. The information center monitors the traffic of logs with
different log IDs. When the traffic of logs with a specific log ID repeatedly exceeds the
threshold during the monitoring period, the information center suppresses the processing rate
of these specified logs by processing only the conforming traffic and discarding the non-
conforming traffic; when the traffic of logs with the specific log ID falls below the threshold
and remains below the threshold for five monitoring periods, the suppression is removed.
1. Run the info-center rate-limit threshold value [ byinfoid infoid | bymodule-alias
modname alias ] command to set the maximum number of logs with the same log ID that
the information center can process each second.
By default, the information center processes a maximum of 50 logs with the same log ID
each second. In certain application scenarios, the information center is required to
process a maximum of more than 30 logs with the same log ID every second. You can
set thresholds for logs with different log IDs.
NOTE
– If the threshold is too low, some logs may be discarded.

– If the threshold is too high, the information center cannot identify the log ID under which too many
logs are generated.

2. Run the info-center rate-limit global-threshold value command to set the total number
of logs that the information center can process each second.
3. Run the info-center rate-limit monitor-period value command to set the period for the
information center to limit the log processing rate.
4. Run the info-center rate-limit except { byinfoid infoid | bymodule-alias modname
alias } command to cancel the log processing rate limit for logs with the specified ID or
module name.
If logs with the specified ID or module name will never be generated in a huge number,
you can run this command to cancel the log processing rate limit for the logs. After this
command is run, the configured log processing rate limit will not be effective for logs
with the specified ID or module name.
Step 7 Optional: Enable the statistical output of consecutive duplicate logs.
info-center statistic-suppress enable
On the FW, service modules generate logs and control the volume of generated logs. The
information center processes the received logs.
Service modules, such as ARP and VRRP produce large numbers of duplicate logs in short
periods in some scenarios. In this case, you can enable the statistical output of consecutive
duplicate logs to prevent the information center from the failure in processing other logs.
NOTE
Consecutive duplicate logs have the same ID and parameters, and they do not have two or more other logs in
between.
----End
1.9.5.4.2 Configuring the FW to Output Logs to a Log Buffer

If you want to view logs generated on the FW in the log buffer, you can configure the FW to
output logs to the log buffer.
Context
By default, the information center enables the function of outputting logs to the log buffer.
Logs are output to the log buffer over information channel 4. You can change the information
channel over which logs are output to the log buffer and adjust the capacity of the log buffer.
Procedure
system-view
Step 2 Add log information to the information channel.

info-center source { module-name | default } channel { channel-number | channel-
name } log { state { off | on } | level severity } *
Step 3 Optional: Specify the information channel through which logs are output to the log buffer.
info-center logbuffer channel { channel-number | channel-name }
By default, channel 4 is used.

Step 4 Optional: Set the log buffer size.
info-center logbuffer size buffersize

By default, the log buffer contains a maximum of 512 logs.
----End
1.9.5.4.3 Outputting Logs to Log Files

If you want to save logs as files on the FW, you can configure the FW to output logs to log
files.
Context
After this configuration, logs are output to log files and saved on the FW. You can view the
logs to know the operating status of the FW.
Procedure
system-view

Step 3 Optional: Specify the information channel through which logs are output to log files.
info-center logfile channel { channel-number | channel-name }
Step 4 Optional: Set the log file size.

info-center logfile size size
By default, the log file size is 8 MB.
Step 5 Optional: Set the maximum number of log files.

info-center max-logfile-number filenumbers
By default, the FW can save a maximum of 200 log files.
If more log files are generated, the system deletes the earliest log files, ensuring that the
number of log files is smaller than or equal to the threshold.
Step 6 Optional: Save configurations to a log file.

save logfile
----End
1.9.5.4.4 Outputting Logs to the Console

If you want to query logs generated on the FW on the console, you can configure the FW to
output logs to the console.
Context
After this configuration, you can log in to the FW in console mode and view logs to know the
operating status of the FW.

Procedure
system-view

Step 3 Optional: Specify the information channel through which logs are output to the console.
info-center console channel { channel-number | channel-name }
Step 4 Return to the system view.

quit
Step 5 Enable the information display function of the terminal.

terminal monitor
Step 6 Enable the log display function of the terminal.

terminal logging
Step 7 Optional: Enable the log information synchronous display function of the terminal.
terminal echo synchronous
----End
1.9.5.4.5 Outputting Logs to a Terminal

If you want to query logs generated on the FW on a terminal, you can configure the FW to
output logs to the terminal.
Context
After this configuration, you can log in to the FW using Telnet or STelnet and view logs to
know the operating status of the FW.
Procedure
system-view

Step 3 Optional: Specify the information channel through which logs are output to the terminal.
info-center monitor channel { channel-number | channel-name }
Step 4 Return to the user view.

quit

terminal monitor

Step 6 Enable the log display function of the terminal.

terminal logging
Step 7 Optional: Enable the log information synchronous display function of the terminal.
----End
1.9.5.4.6 Outputting Logs to a Log Host

If you want to view logs generated on the FW on the log host, you can configure the FW to
output logs to the log host.
Context
The FW can output logs to a maximum of eight log hosts. The log hosts back up each other.
Procedure
system-view

NOTE
The command does not take effect for service logs and cannot control whether to enable service logs or the
levels of service logs. The FW sends logs of each level generated by all service modules to its connected log
server only after the info-center loghost command is run.
Step 3 Configure the channel through which logs are output to the log host.
NOTICE
The FW can output service logs to a log host in either dataflow or syslog format. If service
logs are output in dataflow format, use the configured log host to output service logs. When
the eLog host is used to receive logs, the configured port must be the same as the port used by
the eLog host to receive logs. Currently, the eLog host uses port 514 to receive non-encrypted
service logs and certificate-encrypted service logs, and therefore the port number must be set
to 514.
l On an IPv4 network, specify the channel through which logs are output to the log host.
info-center loghost ip-address [ channel { channel-number | channel-name } |
facility local-number | language language-name | { vpn-instance vpn-instance-
name | public-net } ] *
By default, logs are not output to the log host.

Before information is sent to a log host over a UDP connection by default, run the info-
center loghost ip-address transport tcp ssl-policy policy-name command to change the
log transfer mode to TCP SSL encryption.
l On an IPv6 network, specify the channel through which logs are output to the log host.
info-center loghost ipv6 ipv6-address [ channel { channel-number | channel-
name } | facility local-number | language language-name ] *


center loghost ipv6 ipv6-address transport tcp ssl-policy policy-name command to
change the log transfer mode to TCP SSL encryption.
l For a log host with a domain name specified, specify the channel through which logs are
output to the log host.
info-center loghost domain domain-name [ channel { channel-number | channel-
name } | facility local-number | language language-name | log-counter
{ disable | enable } | local-time ] *

center loghost domain domain-name transport tcp ssl-policy policy-name command to
change the log transfer mode to TCP SSL encryption.
Step 4 Optional: Set the source interface.

info-center loghost source { interface-type interface-number | ip-address }
This interface is recognized by the log host as the log sending interface.
Step 5 Optional: Configure a CA certificate for the log host.

log ca-certificate cert-filename
The FW can output encrypted service logs to the log host in syslog format. Therefore, you
need to configure a CA certificate for the log host on the FW.
----End
1.9.5.5 Maintaining Logs

After the log-related configuration is complete, you can check the configuration result and
view or clear log information.
Checking Configuration Results

Run the commands listed in Table 1-38 in any view to check the log configuration result.
Table 1-38 Checking log configuration results
Operation Command
Check log configuration and statistics. display firewall log { configuration |

statistic } [ vsys vsys-name ]
Check statistics in the information buffer. display buffer [ feature-name [ buffer-

name ] ]
Check the channel configuration. display channel [ channel-number |

channel-name ]
Check information recorded by the display info-center [ statistics [ module-id

information center. id | module-name name ]

Operation Command
Check information in the log buffer. display logbuffer [ common-log | sec-log ]

[ size size-value | module module-name |
security | level { severity | emergencies |
alert | critical | error | warning |
notification | informational | debugging } |
slot slot-number | vsys vsys-name ] *
display logbuffer summary [ level severity
| slot slot-number ] *
Check log file information. display logfile driver path file-name [ offset
| hex ] *
Check information about a specified log ID display info-center filter-id [ bymodule-

in the filtering table. alias modname alias ]
Check rate limit records in the information display info-center rate-limit record
center.
Check rate limit records in the information display info-center rate-limit threshold
center.
Clearing Log-related Information

Run the commands listed in Table 1-39 in user view to clear log-related information.
Log information cannot be restored after it is cleared. Exercise caution before performing the
operation.
Table 1-39 Clearing log-related information
Operation Command
Clear log statistics. reset firewall log statistic [ vsys vsys-

name ]
Clear statistics on every module in the reset info-center statistics

information center.
Clear information in the log buffer. reset logbuffer
1.9.6 Configuration Example

This section provides log configuration examples.
1.9.6.1 CLI: Example for Configuring the FW to Output Session Logs to Log Hosts
This section provides an example for configure the FW to output session logs to log hosts.

As shown in Figure 1-37, the FW is deployed on the network border. The network
environment is as follows:
l The intranet is the Trust zone, while the Internet is the Untrust zone. Users on the
intranet access the Internet using the NAT function provided by the FW.
l The DMZ has two eLog servers.
The FW is required to send session information generated when intranet users access the
Internet to the eLog servers in the syslog format. The administrator can view and analyze
session information on the eLog servers. The log concurrent function is required, so that each
log can be sent to both eLog servers.
Figure 1-37 Networking for outputting session logs to eLog servers
FW
GE2/0/1 GE2/0/3
Trust Untrust
Intranet 192.168.0.1/24 1.1.1.1/24
192.168.0.0/24
GE2/0/2
DMZ
172.16.0.1/24
eLog server1 eLog server2

172.16.0.2 172.16.0.3
NOTE
This example provides only the FW configuration. For the eLog server configuration, see the eLog
server product document.
1. Set the IP addresses for interfaces and add the interfaces to security zones.
2. Configure security policies.
3. Configure a NAT policy.
4. Configure routes.
5. Configure log hosts.
6. Enable the session log function in a security policy.
7. Configure the log output format and the source IP address and source port, and enable
the log concurrent function.

Procedure
Step 1 Set the IP addresses for interfaces and add the interfaces to security zones.
# Configure an IP address for GE 2/0/1.

<FW> system-view
[FW-GigabitEthernet2/0/1] ip address 192.168.0.1 24


# Add GE 2/0/1 to the Trust zone.

[FW-zone-trust] add interface GigabitEthernet 2/0/1
# Add GE 2/0/2 to the DMZ.

[FW-zone-dmz] add interface GigabitEthernet 2/0/2
[FW-zone-dmz] quit
# Add GE 2/0/3 to the Untrust zone.

[FW] firewall zone untrust
[FW-zone-untrust] add interface GigabitEthernet 2/0/3
[FW-zone-untrust] quit
Step 2 Configure security policies.
# Configure a Trust-Untrust interzone security policy and enable the session log function. The
session log function takes effect only when the policy action is set to permit.
[FW-policy-security] rule name trust_untrust
[FW-policy-security-rule-trust_untrust] source-zone trust
[FW-policy-security-rule-trust_untrust] destination-zone untrust
[FW-policy-security-rule-trust_untrust] source-address 192.168.0.0 24
[FW-policy-security-rule-trust_untrust] action permit
[FW-policy-security-rule-trust_untrust] session logging
[FW-policy-security-rule-trust_untrust] quit
# Configure a Local-DMZ interzone security policy.

[FW-policy-security] rule name local_dmz
[FW-policy-security-rule-local_dmz] source-zone local
[FW-policy-security-rule-local_dmz] destination-zone dmz
[FW-policy-security-rule-local_dmz] destination-address 172.16.0.2 32
[FW-policy-security-rule-local_dmz] action permit
[FW-policy-security-rule-local_dmz] quit
Step 3 Configure a NAT policy.

# Configure NAT address pool 1 and set the mode to PAT. In this example, the public address
ranges from 1.1.1.10 to 1.1.1.15.
[FW] nat address-group add1
[FW-address-group-add1] mode pat
[FW-address-group-add1] section 0 1.1.1.10 1.1.1.15
[FW-address-group-add1] route enable
[FW-address-group-add1] quit
# Configure a NAT policy.

[FW] nat-policy
[FW-policy-nat] rule name policy1
[FW-policy-nat-rule-policy1] source-zone trust
[FW-policy-nat-rule-policy1] destination-zone untrust
[FW-policy-nat-rule-policy1] source-address 192.168.0.0 24
[FW-policy-nat-rule-policy1] action nat address-group add1
[FW-policy-nat-rule-policy1] quit
[FW-policy-nat] quit
Step 4 Configure routes.

# Configure a default route. In this example, the next hop of the FW to the Internet is 1.1.1.2.
[FW] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2
Step 5 Configure log hosts. When the log format is syslog, the log host must use port 514.
[FW] firewall log host 1 172.16.0.2 514
Step 6 Configure the log output format and the source IP address and source port, and enable the log
concurrent function.
[FW] firewall log session log-type syslog
[FW] firewall log session multi-host-mode concurrent
[FW] firewall log source 172.16.0.1 6000
----End
Configuration Script
#
sysname FW
#
firewall log session log-type syslog

firewall log session multi-host-mode
concurrent
firewall log host 1 172.16.0.2

514

514
firewall log source 172.16.0.1 6000

#
nat address-group add1

0
mode
pat
route enable
section 0 1.1.1.10
1.1.1.15

interface
GigabitEthernet2/0/1
undo
shutdown
ip address 192.168.0.1
255.255.255.0
interface
undo
shutdown
255.255.255.0
interface
undo
shutdown
ip address 1.1.1.1
255.255.255.0
firewall zone
trust
set priority
85
add interface
firewall zone
untrust
set priority
5
add interface
firewall zone
dmz
set priority
50
add interface
#
security-policy

rule name trust_untrust

session logging
source-zone trust
destination-zone untrust
source-address 192.168.0.0 24
action permit
rule name local_dmz
source-zone local
action permit
#
nat-
policy
rule name policy1

source-zone trust
action nat address-group
add1
ip route-static 0.0.0.0 0.0.0.0

1.1.1.2
return
1.9.6.2 CLI: Example for Configuring the FW to Output Service Logs to Log Hosts
The FW sends traffic logs and threat logs (antivirus and IPS) to eLog servers in binary log
format so that you can view and analysis these logs on the eLog server. The log concurrent
function is required, so that each log can be sent to both eLog servers.

Figure 1-38 Networking for outputting service logs to a log host
FW
GE2/0/1 GE2/0/3
Trust Untrust
Intranet 192.168.0.1/24 1.1.1.1/24
192.168.0.0/24
GE2/0/2
DMZ
172.16.0.1/24

172.16.0.2 172.16.0.3
NOTE
6. Enable the traffic log and threat logs function.
7. Enable the log concurrent function and configure the source IP address and source port.
Procedure
<FW> system-view





[FW-zone-dmz] quit


# Configure a Trust-Untrust interzone security policy. The default antivirus and IPS profiles
named default are used.
[FW-policy-security-rule-trust_untrust] profile av default
[FW-policy-security-rule-trust_untrust] profile ips default


ranges from 1.1.1.10 to 1.1.1.15.

[FW] nat-policy


Step 5 Enable the traffic log function. By default, the traffic log function is used on the FW. If the
function is disabled, run the following command to enable it:
[FW] log type traffic enable
Step 6 Enable the threat log function. By default, the threat log function is used on the FW. If the
function is disabled, run the following command to enable it:
[FW] engine log av enable
[FW] engine log ips enable
Step 7 Configure log hosts.

Step 8 Enable the log concurrent function and configure the source IP address and source port.
----End
#
sysname FW
#

concurrent

9002

9002

#

0
mode
pat
route enable
section 0 1.1.1.10
1.1.1.15
interface
undo
shutdown
255.255.255.0

interface
undo
shutdown
255.255.255.0
interface
undo
shutdown
ip address 1.1.1.1
255.255.255.0
firewall zone
trust
set priority
85
add interface
firewall zone
untrust
set priority
5
add interface
firewall zone
dmz
set priority
50
add interface
#
security-policy
session logging
source-zone trust
profile av default
profile ips default
action permit
rule name local_dmz
source-zone local

action permit
#
nat-
policy
rule name policy1

source-zone trust
add1

1.1.1.2
return
1.9.6.3 CLI: Example for Configuring the FW to Output Packet Loss Logs to Log
Hosts
This section provides a example for configure the FW to output packet loss logs to log hosts.
The FW is required to send packet loss information as syslogs to the eLog servers. The
administrator can view and analyze packet loss information on the eLog servers. The log
concurrent function is required, so that each log can be sent to both eLog servers.

Figure 1-39 Networking for outputting packet loss logs to eLog servers
FW
GE1/0/1 GE1/0/3
Trust Untrust
Intranet 192.168.0.1/24 1.1.1.1/24
192.168.0.0/24
GE1/0/2
DMZ
172.16.0.1/24

172.16.0.2 172.16.0.3
NOTE
6. Enable the function of sending packet loss logs.
7. Enable the log concurrent function and configure the source IP address and source port.
Procedure

<FW> system-view





[FW-zone-dmz] quit

# Configure a Trust-Untrust interzone security policy.


ranges from 1.1.1.10 to 1.1.1.15.

[FW] nat-policy


Step 5 Configure log hosts. Packet loss information can be recorded only in the syslog format. The
log hosts must use port 514.
Step 6 Enable the function of sending packet loss logs.

[FW] firewall log packet-discard enable
[FW] firewall log packet-discard default-packet-filter
[FW] firewall log packet-discard packet-filter
[FW] firewall log packet-discard session-miss
Step 7 Enable the log concurrent function and configure the source IP address and source port.
----End
#
sysname FW
#

concurrent
firewall log packet-discard

enable
firewall log packet-discard session-

miss
firewall log packet-discard packet-

filter
firewall log packet-discard default-packet-filter

514

514

#

0
mode
pat
route enable
section 0 1.1.1.10
1.1.1.15
interface

undo
shutdown
255.255.255.0
interface
undo
shutdown
255.255.255.0
interface
undo
shutdown
ip address 1.1.1.1
255.255.255.0
firewall zone
trust
set priority
85
add interface
firewall zone
untrust
set priority
5
add interface
firewall zone
dmz
set priority
50
add interface
#
security-policy
session logging
source-zone trust
action permit

rule name local_dmz

source-zone local
action permit
#
nat-
policy
rule name policy1

source-zone trust
add1

1.1.1.2
return
1.9.6.4 CLI: Example for Configuring the FW to Output Service Logs and System
Logs to a Log Host Through the Information Center
This section provides an example for configure the FW to output service logs and system logs
to a log host through the information center.
As shown in Figure 1-40, the FW connects to four eLog servers.
The FW is required to send system logs to the eLog servers to meet the following
requirements:
l The FW sends notification logs generated by the FIB and IP modules as well as all
service logs to eLog server 1. eLog server 3 backs up eLog server 1.
l The FW sends all service logs to eLog server 2. eLog server 4 backs up eLog server 2.
Figure 1-40 Networking for outputting system logs to eLog servers

eLog server2
eLog server1
172.16.0.3
172.16.0.2
GE2/0/2
DMZ
172.16.0.1/24
eLog server4
FW 172.16.0.5
eLog server3
172.16.0.4

NOTE
2. Configure a security policy.
3. Enable the information center.
4. Name the information channel.
5. Specify the modules from which logs are output.
Procedure

<FW> system-view

[FW-zone-dmz] quit
Step 2 Configure a security policy.


[FW] info-center enable
Step 4 Name the information channel.

[FW] info-center channel 6 name loghost1
Step 5 Specify the modules from which logs are output.

[FW] info-center source fib channel loghost log level notification
[FW] info-center source ip channel loghost log level notification
Step 6 Configure log hosts.

# Configure eLog server 1 as the master log server and eLog server 3 as the backup log server
to receive logs generated by the FIB and IP modules. Set the log language to English and use
log recording tool Local2.
[FW] info-center loghost 172.16.0.2 channel loghost facility local2 language
english
[FW] info-center loghost 172.16.0.4 channel loghost facility local2 language
english
# Configure eLog server 2 as the master log server and eLog server 4 as the backup log server
to receive logs generated by the AV and IPS modules. Set the log language to English and use
log recording tool Local4.
[FW] info-center loghost 172.16.0.3 channel loghost1 facility local4 language
english
[FW] info-center loghost 172.16.0.5 channel loghost1 facility local4 language
english
----End
#
sysname FW
#
info-center channel 6 name

loghost1
info-center source FIB channel 2 log level

notification
info-center source IP channel 2 log level

notification
info-center loghost 172.16.0.2 facility

local2
info-center loghost 172.16.0.4 facility

local2
info-center loghost 172.16.0.3 channel 6 facility

local4
info-center loghost 172.16.0.5 channel 6 facility
local4
#
interface
undo
shutdown
255.255.255.0
firewall zone
dmz
set priority
50
add interface

#
security-policy
rule name local_dmz
source-zone local
action permit
#
return

This section provides logs references.
This section provides the specifications of the logs.
Function Sub- Description Supported or Not
function
Logs Log type Session logs, packet loss Supported by all models
logs, service logs, and
system logs are
supported.
Log format The binary, syslog, Supported by all models

netflow, dataflow formats
are supported.
Log server Logs can be output to the Supported by all models

eLog server.
Informatio Default log l To the console over Supported by all models

n center output information channel 0
directions l To a remote terminal
over information
channel 1
l To a log host over
information channel 2
l Log output to a log
buffer over
l To a log file over

Function Sub-function Specifications
Logs Number of log servers 16
Information Maximum number of log entries 1024

center in the log buffer
Number of log servers 8

This section describes the versions and changes in the logs feature.
V500R001C10SPC The first version.

100
1.10 Alarms
By viewing alarms, you can rapidly be informed of faults occurring when the device is
running, helping quickly rectify the faults and ensure normal device operation.
1.10.1 Overview
This section describes the definition and objective of alarms.
Definition
Alarms are notifications generated on the FW upon detected faults. The alarms carry
corresponding fault information. Unlike logs, alarms are time-sensitive and must be reported
to the administrator as soon as possible.
Objective
By viewing alarms, the administrator can rapidly locate the modules where faults occurred
and rapidly rectify the faults to ensure normal operation of the FW.
1.10.2 Mechanism
This section describes the mechanism for alarm output.
The FW outputs alarms through the information center. The information center is an
information hub of system software modules on the FW. You can sort output system
information in a refined manner to effectively filter information.

NOTE
In addition to alarms, the information center can output logs and debugging information. This chapter
focuses on alarms, for logs and debugging information, see 1.9 Logs and 1.11 Debugs.
Information Output
10 information channels are defined for the information center to control information output
in different directions. These channels are independent of each other. You can configure alarm
output rules as required to allow information of different levels to be output through different
channels, as shown in Figure 1-41.
Figure 1-41 Alarm output schematic diagram

Information Output
channels directions
0 Console
Console
1
Alarms Monitor Remote terminal
2
Loghost Log host
3
Trapbuffer Trap buffer
4 Logbuffer
5
SNMP agent SNMP agent
6 channel6
7 channel7
8 channel8
channel9 Log file

9
Table 1-40 shows the relationships between information channels and output directions.

Name
0 console console The console can receive logs, alarms, and

debugging information.
1 monitor monitor VTY terminals can receive logs, alarms, and

debugging information, facilitating remote
maintenance.


Name
2 loghost loghost Log hosts can receive logs, alarms, and

debugging information. Information is stored in
files on the log hosts. You can view the files at
any time.
3 trapbuffer trapbuffer The trap buffer can receive alarms.
4 logbuffer logbuffer The log buffer can receive logs.
5 snmpagent snmpagent The SNMP agent can receive alarms.
6 channel6 Not specified This channel is reserved. You can specify the
output direction.
output direction.
output direction.
9 channel9 logfile Log files can receive logs, alarms, and

files on the storage medium of the device, such
as the CF card.
If multiple log hosts are configured, you can configure the device to output alarms through
one or more channels to log hosts. For example, configure the device to output some alarms to
log hosts through channel 2 (loghost) and the rest alarms to log hosts through channel 6. You
can rename channel 6 to facilitate information channel management.
Information Format
Figure 1-42 shows the alarm format.
Figure 1-42 Format of an output alarm
Table 1-41 lists the description of every field in an alarm.

Table 1-41 Alarm format description

Field Meaning Description
TimeStamp Timestamp, indicating There are five timestamp formats:

when the alarm is l Boot: relative time.
output
l Date: system time. This timestamp format is
used for alarms by default.
l Short-date: similar to the date format. The
difference is that the short-date timestamp
does not contain the year.
l Format-date: another system time.
l None: no timestamp in output alarms.
The timestamp and host name are separated by a
space.
HostName Host name It is the system name of a local host.

The host name and module name are separated
by a space.
ModuleName Module name Indicates the module where an alarm is

generated.
Severity Severity Indicates the alarm severity, which can be:

l 1: Critical
l 2: Major
l 3: Minor
l 4: Warning
l 5: Indeterminate
l 6: Cleared
Brief Brief description Indicates the brief description of an alarm.
Description Description Indicates the description of an alarm.
1.10.3 Configuring the FW to Output Alarms

You can configure the FW to output alarms through the information center. By viewing the
alarms, you can rapidly rectify the faults to ensure the normal operation of the FW.
1.10.3.1 Enabling the Information Center

The FW can output alarms only after the information center is enabled.
Context

NOTICE
When the information center is enabled and the system is busy sorting and outputting
Procedure
system-view

info-center enable
Step 3 Optional: Name the information channel.

Step 4 Optional: Configure a timestamp is configured for alarms.
info-center timestamp trap { none | boot | { date | short-date | format-date }
[ precision-time { tenth-second | millisecond } ] }
The default alarm timestamp format is date.
----End
1.10.3.2 Outputting Alarms to the Trap Buffer

If you want to view alarms generated on the FW in the trap buffer, you can configure the FW
to output alarms to the trap buffer.
Context
By default, the information center enables the function of outputting alarms to the trap buffer.
Alarms are output to the trap buffer over information channel 3. You can change the
information channel over which alarms are output to the trap buffer and adjust the capacity of
the trap buffer.
Procedure
system-view
Step 2 Add alarm information to the information channel.

name } trap { state { off | on } | level severity } *
Step 3 Optional: Specify the information channel through which alarms are output to the trap buffer.
info-center trapbuffer channel { channel-number | channel-name }

Step 4 Optional: Set the trap buffer size.
info-center trapbuffer size buffersize

By default, the trap buffer contains a maximum of 256 alarms.
----End
1.10.3.3 Outputting Alarms to Log Files

If you want to save alarms as files on the FW, you can configure the FW to output alarms to
log files.
Context
After this configuration, alarms are output to log files and saved on the FW. You can view the
alarms to know the operating status of the FW.
Procedure
system-view

Step 3 Optional: Specify the information channel through which alarms are output to log files.

Step 4 Optional: Set the log file size.

Step 5 Optional: Set the maximum number of log files.

----End
1.10.3.4 Outputting Alarms to the Console

If you want to query alarms generated on the FW on the console, you can configure the FW to
output alarms to the console.
Context
After this configuration, you can log in to the FW in console mode and view alarms to know
the operating status of the FW.
Procedure
system-view


Step 3 Optional: Specify the information channel through which alarms are output to the console.

quit

terminal monitor
Step 6 Enable the alarm display function of the terminal.

terminal trapping
Step 7 Optional: Enable the alarm information synchronous display function of the terminal.
----End
1.10.3.5 Outputting Alarms to a Terminal

If you want to query alarms generated on the FW on a terminal, you can configure the FW to
output alarms to the terminal.
Context
After this configuration, you can log in to the FW using Telnet or STelnet and view alarms to
know the operating status of the FW.
Procedure
system-view

Step 3 Optional: Specify the information channel through which alarms are output to the terminal.

quit

terminal monitor
Step 6 Enable the alarm display function of the terminal.

terminal trapping
Step 7 Optional: Enable the alarm information synchronous display function of the terminal.

----End
1.10.3.6 Outputting Alarms to a Log Host

If you want to view alarms generated on the FW on the log host, you can configure the FW to
output alarms to the log host.
Context
The FW can output alarms to a maximum of eight log hosts. The log hosts back up each other.
Procedure
system-view

Step 3 Configure the channel through which alarms are output to the log host.
l On an IPv4 network, set the channel through which alarms are output to the log host.
By default, alarms are not output to the log host.

l On an IPv6 network, set the channel through which alarms are output to the log host.

l For a log host with a domain name specified, specify the channel through which alarms
are output to the log host.

Step 4 Optional: Set the source interface.
This interface is recognized by the log host as the alarm sending interface.
----End
1.10.3.7 Outputting Alarms to the SNMP Agent

If you want to query alarms generated on the FW on the NMS, you can configure the FW to
output alarms to the SNMP agent.
Context
To output alarms to the NMS, you need to output alarms to the SNMP agent. The SNMP
agent then sends the alarms to the NMS server.

Procedure
system-view

Step 3 Optional: Specify the information channel through which alarms are output to the SNMP
agent.
info-center snmp channel { channel-number | channel-name }
Step 4 Enable the SNMP agent function.

snmp-agent
By default, this function is disabled.
After the SNMP agent function is enabled, you must configure the SNMP function.
Otherwise, alarms cannot be sent to the NMS. For the SNMP configuration, see 1.7 SNMP.
----End
1.10.4 Maintaining Alarms

After the alarm-related configuration is complete, you can check the configuration result and
view or clear alarm-related information.
Checking Configuration Results

Run the commands listed in Table 1-42 in any view to check the alarm configuration result.
Table 1-42 Checking the alarm configuration
Operation Command

channel-name ]
Check information recorded by the display info-center [ statistics [ module-id

information center. id | module-name name ]
Check information in the trap buffer. display trapbuffer [ size size-value ]
Clearing Alarm-related Information

Run the commands listed in Table 1-43 in user view to clear alarm-related information.
Alarm information cannot be restored after it is cleared. Perform the operation with caution.

Table 1-43 Clearing alarm-related information

Operation Command
Clear statistics on every module in the reset info-center statistics

information center.
Clear information in the trap buffer. reset trapbuffer

This section provides trap configuration examples.
1.10.5.1 Configuring the FW to Output Alarms to the NMS

This section provides a configuration example for outputting alarms to the NMS.
Context
As shown in Figure 1-43, the FW connects to the NMS. The administrator wants to view the
alarms generated on the FW on the NMS to monitor the operation of the FW and locate faults.
Figure 1-43 Networking for outputting alarms to the NMS
DMZ
GE1/0/0
10.1.1.1/24
NMS
FW
10.1.1.2
1. Set IP addresses to interfaces on the FW, assign the interfaces to security zones, and
configure security policies.
2. Enable the information center on the FW.
3. Configure the information channel through which alarms are output and the alarm output
rule.
4. Configure SNMP on the FW.
5. Configure the NMS.
Procedure
Step 1 Set an IP address for GE 1/0/0 on the FW, add the interface to a security zone, and configure a
security policy.

# Set an IP address for GE 1/0/0.

<FW> system-view
[FW] interface gigabitethernet 1/0/0
[FW] ip address 10.1.1.1 24
[FW] quit
# Add GE 1/0/0 to a security zone.

[FW-zone-dmz] quit
# Configure a security policy.

[FW-policy-security-rule-local_dmz] source-address 10.1.1.1 32
[FW-policy-security] rule name dmz_local
[FW-policy-security-rule-dmz_local] source-zone dmz
[FW-policy-security-rule-dmz_local] destination-zone local
[FW-policy-security-rule-dmz_local] destination-address 10.1.1.1 32
[FW-policy-security-rule-dmz_local] action permit
[FW-policy-security-rule-dmz_local] quit
Step 2 Enable the information center on the FW.

Step 3 Configure the information channel through which alarms are output and the alarm output rule.
# Configure the information channel through which alarms are output to the SNMP agent.
[FW] info-center snmp channel channel7
# Configure the rule according to which the FW outputs alarms to the SNMP agent.
[FW] info-center source ip channel channel7 trap level informational state on
NOTE
By default, the FW outputs alarms for all modules through the SNMP agent.
Step 4 Configure SNMP on the FW.
# Configure the SNMP version.

[FW] snmp-agent sys-info version v2c
Warning: SNMPv1/SNMPv2c is not secure, and it is recommended to use SNMPv3.
# Configure the SNMP write community.

[FW] snmp-agent community write cipher private@123
# Configure the SNMP alarm function.

[FW] snmp-agent trap enable
Warning: All switches of SNMP trap/notification will be open. Continue? [Y/N]:y
[FW] snmp-agent target-host trap address udp-domain 10.1.1.2 params securityname
Admin123 v2c
Step 5 Configure the NMS.

You need to refer to the configuration guide of the NMS that is deployed. The NMS
authentication parameters must be consistent with those on the FW. Otherwise, the NMS may
fail to manage the FW.
----End
#
sysname FW
#
info-center source IP channel 7 trap level informational
info-center snmp channel 7
#
ip address 10.1.1.1 255.255.255.0
#
snmp-agent trap type base-trap
#
firewall zone dmz
set priority 50
#
snmp-agent
snmp-agent local-engineid 000007DB7F00000100003598
snmp-agent community write cipher %$%$z=UX9vmQgCHS/E2xC5IPIZQH%$%$
snmp-agent sys-info version v2c v3
snmp-agent target-host trap address udp-domain 10.1.1.2 params securityname %$%$
\d\R0yX`|T+ZwqXUB}o&,kbY%$%$ v2c
snmp-agent trap enable
#
security-policy
rule name local_dmz
source-zone local
action permit
rule name dmz_local
source-zone dmz
destination-zone local
destination-address 10.1.1.1
32
action permit
#
return

This section provides the reference information about the trap feature.
This section describes trap specifications.

Function Description Supported or Not
Default alarm output l To the console over Supported by all models.

directions information channel 0
l To a remote terminal
over information channel
1
l To a trap buffer over
l To the SNMP agent over
Maximum number of alarms in 1024

the trap buffer

This section describes the versions and changes in the trap feature.
1.11 Debugs
To learn about device running information or commission the device, you can output the
debugging information of a specified module through the information center to different
directions.
1.11.1 Overview
This section describes the definition and objective of debugging information.

Definition
Debugging information refers to the tracking information on the operating of internal modules
of the FW.
Objective
The FW can output debugging information of multiple functional modules, helping the
administrator to understand the operating of functions and locate faults.
1.11.2 Mechanism
This section describes the debug mechanism.
The FW outputs debugging information through the information center. The information
center is an information hub of system software modules on the FW. You can sort output
system information in a refined manner to effectively filter information.
NOTE
In addition to debugging information, the information center can output logs and alarms. This chapter
focuses on debugging information, for logs and alarms, see 1.9 Logs and 1.10 Alarms.
Information Output
10 information channels are defined for the information center to control information output
in different directions. These channels are independent of each other. You can configure
debugging information output rules as required to allow information of different levels to be
output through different channels, as shown in Figure 1-44.
Figure 1-44 Debugging information output schematic diagram

Information Output
channel direction
0 Console Console
1 Monitor Remote terminal

2 Loghost Loghost
Debugging
information 3 Trapbuffer
4 Logbuffer
5 SNMP agent
6 channel6
7 channel7
8 channel8
channel9 Logfile
9

Table 1-44 shows the relationships between information channels and output directions.

Name
0 console console The console can receive logs, alarms, and

debugging information.
1 monitor monitor VTY terminals can receive logs, alarms, and

debugging information, facilitating remote
maintenance.
2 loghost loghost Log hosts can receive logs, alarms, and

files on the log hosts. You can view the files at
any time.
3 trapbuffer trapbuffer The trap buffer can receive alarms.
4 logbuffer logbuffer The log buffer can receive logs.
5 snmpagent snmpagent The SNMP agent can receive alarms.
output direction.
output direction.
output direction.
9 channel9 logfile Log files can receive logs, alarms, and

files in the storage media (CF card) of the device
If multiple log hosts are configured, you can configure the device to output debugging
information through one or more channels to log hosts. For example, configure the device to
output some debugging information to log hosts through channel 2 (loghost) and the rest
debugging information to log hosts through channel 6. You can rename channel 6 to facilitate
information channel management.
Debugging Functions
The output of debugging information depends on the following situations:
l Whether debugging information about a protocol is output
l Whether terminal display is enabled, that is, whether to display the debugging
information on the screen
Figure 1-45 shows the relationship between the preceding two situations. After the debugging
of protocol 1 and 3 is enabled, corresponding debugging information is output. As screen

display is also enabled, the debugging information is displayed. No debugging information

about protocol 2 is output because the debugging of protocol 2 is not enabled.
Figure 1-45 Diagram for enabling debugging functions
1.11.3 Configuring the FW to Output Debugging Information

This section describes how to configure the FW to output debugging information to a log file,
console, terminal, or log host.
1.11.3.1 Enabling the Information Center

The FW can output debugging information only after the information center is enabled.
Context
NOTICE
l When the information center is enabled and the system is busy sorting and outputting
l Debugging degrades system performance. Therefore, after debugging, run the undo
debugging all command to disable debugging immediately.

Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Run:
info-center enable
The information center is enabled.

Step 3 Optional: Run:
Channel channel-number is named channel-name.

info-center timestamp debugging { none | boot | { date | short-date | format-
date } [ precision-time { tenth-second | millisecond } ] }
A timestamp is configured for debugging information.

The default debugging information timestamp format is date.
debugging timeout timeout
The period after which a debugging is automatically disabled is set.

To immediately disable a debugging, press the Ctrl+O hotkeys or run the undo debugging all
command.
----End
1.11.3.2 Outputting Debugging Information to Log Files

If you want to save debugging information as files on the FW, you can configure the FW to
output debugging information to log files.
Context
After this configuration, debugging information is output to log files and saved on the FW.
You can view the debugging information to know the operating status of the FW.
Procedure
Step 1 Run:
system-view

Step 2 Run:
name } debug { state { off | on } | level severity } *
Debugging information is added to the information channel.


The information channel through which debugging information is output to log files is
specified.
The log file size is set.

The maximum number of log files is set.

----End
1.11.3.3 Outputting Debugging Information to the Console

If you want to query debugging information generated on the FW on the console, you can
configure the FW to output debugging information to the console.
Context
After this configuration, you can log in to the FW in console mode and view debugging
information to know the operating status of the FW.
Procedure
Step 1 Run:
system-view

Step 2 Run:

The information channel through which debugging information is output to the console is
specified.
Step 4 Run:

quit
Return to the user view.

Step 5 Run:
terminal monitor
The information display function of the terminal is enabled.

Step 6 Run:
terminal debugging
The debugging information display function of the terminal is enabled.

The debugging information synchronously display function of the terminal is enabled.
----End
1.11.3.4 Outputting Debugging Information to a Terminal

If you want to query debugging information generated on the FW on a terminal, you can
configure the FW to output debugging information to the terminal.
Context
After this configuration, you can log in to the FW using Telnet or STelnet and view debugging
information to know the operating status of the FW.
Procedure
Step 1 Run:
system-view

Step 2 Run:

The information channel through which debugging information is output to the terminal is
specified.
Step 4 Run:
quit
Return to the user view.

Step 5 Run:
terminal monitor

The information display function of the terminal is enabled.

Step 6 Run:
terminal debugging
The debugging information is display function of the terminal is enabled.

The debugging information synchronously display function of the terminal is enabled.
----End
1.11.3.5 Outputting Debugging Information to a Log Host

If you want to view debugging information generated on the FW on the log host, you can
configure the FW to output debugging information to the log host.
Context
The FW can output debugging information to a maximum of eight log hosts. The log hosts
back up each other.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Configure the channel through which debugging information is output to the log host.
l (On an IPv4 network) Run:
The channel through which debugging information is output to the log host is
configured.
By default, debugging information is not output to the log host.
l (On an IPv6 network) Run:
configured.
l For a log host with a domain name specified, run:

configured.
A source interface is configured. This interface is recognized by the log host as the debugging
information sending interface.
----End
1.11.4 Maintaining Debugging Information

After the debugging configuration is complete, you can check the configuration result.
Run the commands listed in Table 1-45 in any view to check the debugging configuration
result.
Table 1-45 Checking the debugging configuration result

Operation Command

channel-name ]
Check enabled debugging functions. display debugging [ interface interface-

type interface-number | module-name ]

This section provides debugging configuration examples.
1.11.5.1 Configuring the FW to Output Debugging Information to the Console

This section provides a configuration example for outputting debugging information to the
console.
As shown in Figure 1-46, a PC connects to a server where the FW is installed. Debugging
information of the critical severity generated on the ARP module must be output to the
console.
Figure 1-46 Networking of outputting debugging information to the console

FW
Server
PC

1. Enable the information center.
2. Configure the module that is allowed to output debugging information.
3. Configure the channel through which the debugging information is output.
4. Enable the terminal monitor function and display the debugging information.
Procedure
<FW> system-view
Step 2 Allow the debugging on the ARP module to be output to the Console with the severity of the
information as debugging.
[FW] info-center console channel console
[FW] info-center source arp channel console debug level debugging
[FW] quit
Step 3 Enable the terminal monitor function and display the debugging information.
<FW> terminal monitor
<FW> terminal debugging
Step 4 Enable ARP module debugging.

<FW> debugging arp packet
----End
Configuration Files
#
sysname FW
#
info-center source ARP channel 0
#
return

This section provides the reference information about the debugging feature.
This section describes debugging specifications.

Default debugging l To the console over Supported by all models.

information output information channel 0
directions l To a remote terminal
over information channel
1

This section describes the versions and changes in the debugging feature.
1.12 Setting the Mail Service

After the SMTP mail server is configured, the device can send information to a specified
email box.
Context
After the mail service is enabled, the FW functions as an SMTP client to connect to the SMTP
server.
When the device sends information through mails, the device automatically references the
mail service parameters, such as email address.
Procedure
1. Choose System > Set Mail Service.
2. Configure the mail service.
From Sender address. Each mail address must contain 6

to 64 characters.

To Recipient address. Each mail address must contain 6

to 64 characters.
To send reports to multiple
addresses, separate the addresses
with line feeds.
Copy To CC recipient address. Each mail address must contain 6

to 64 characters.
To copy reports to multiple
addresses, separate the addresses
with line feeds.
SMTP Mail Domain name, IPv4 address, or The default SMTP server port is
Server/Port port of the mail server. 25.
NOTE
The device does not support email
sending through a forcibly SSL-
connected email server, such as
Gmail. Commonly used email
servers, such as Sina, 163, and
Winmail, are recommended.
User Name/ User name and password for When the SMTP server requires
Password logging in to the SMTP mail ID authentication, select Verify
server. Sender's Name and Password,
and enter the user name and
password registered on the mail
server.
NOTE
When the SMTP mail server requires
ID authentication, "sender address"
is the mailbox address obtained
during the user name registration.
3. Click Apply.
4. Click Set Test Email and log in to the recipient's or CC recipient's mailbox to see
whether the test mail is received.
Test emails are sent to test whether email messages can be successfully sent and
received. If not, check whether the parameters are correctly configured. Then, check the
connectivity between the FW and the SMTP server.
1.13 Status Check and Packet Processing

You can modify the link status check function and packet processing mode to meet the
network environment requirements.
1.13.1 Configuring Status Check

The status check function allows the FW to check the validity of the link status in packets.

1.13.1.1 Overview
This section describes basic concepts about status detection.
Using status detection, the FW checks the validity of the link status of packets and discards
the packets with invalid link status. Status detection takes effect on both common packets and
inner packets (decapsulated VPN packets).
When the FW is the only egress of a network, all packets are forwarded through the FW. In
this case, both incoming and outgoing packets pass through the FW. You can enable status
detection on the FW to secure services.
If either incoming or outgoing packets do not pass through the FW, the FW may not receive
the first packet, as shown in Figure 1-47.
Figure 1-47 Network with different forward and return paths
Untrust
Switch
Outgoing traffic
Trust
Incoming traffic
In this case, you must disable stateful inspection to ensure normal services. The FW can also
establish sessions based on subsequent packets.
Table 1-46 shows session establishment on the FW for TCP, UDP, ICMP and SCTP packets.
The prerequisite for session establishment is that the packets pass the checks of security
mechanisms on the firewall, including security policies.
Table 1-46 Session establishment for TCP, UDP, ICMP and SCTP packets
Protocol Stateful Inspection Stateful Inspection
Enabled Disabled
TCP SYN packet The firewall creates The firewall creates sessions
sessions and forwards and forwards packets.
packets.
SYN+ACK The firewall does not create The firewall creates sessions
and ACK sessions and discards and forwards packets.
packets packets.

Protocol Stateful Inspection Stateful Inspection

Enabled Disabled
UDP The firewall creates The firewall creates sessions

packets.
ICMP Echo The firewall creates The firewall creates sessions

Request sessions and forwards and forwards packets.
packet (ping packets.
packet)
Echo Reply The firewall does not create The firewall creates sessions
packet (ping sessions and discards and forwards packets.
packet) packets.
Other ICMP The firewall does not create The firewall does not create
packets sessions but forwards sessions but forwards
packets. packets.
SCTP INIT packet The firewall creates The firewall creates sessions
packets.
INIT— The firewall does not create The firewall creates sessions
ACK,COOK sessions and discards and forwards packets.
IE—ECHO packets.
and
COOKIE-
ACK packets
1.13.1.2 Configuring Status Check Using the Web UI

This section describes how to configure the status check function on the web UI.
Context
You can enable or disable the IPv4 TCP or Internet Control Message Protocol (ICMP) status
check function as required.
Procedure
Step 1 Choose System > Setup > Status Detection.
Step 2 Select TCP Status Detection or ICMP Status Detection to enable this function.
The TCP status check function and ICMP status check function are independent of each other.
Enabling or disabling of one function does not affect the status check on the other type of data
flows.

NOTICE
Disabling the TCP status check function makes defending against SYN flood attacks in TCP
proxy mode unavailable.
Step 3 Click Apply.
----End
1.13.1.3 Configuring Status Check-CLI

This section describes how to configure the status check function using commands.
Context
You can enable or disable the IPv4/IPv6 TCP or ICMP status check function as required.
Procedure
system-view
Step 2 Enable or disable the status check function as required.

l Enable the IPv4 or IPv6 status check function.
firewall session link-state [ icmp | tcp ] check
Or
firewall ipv6 session link-state [ icmpv6 | tcp ] check
l Disable the IPv4 or IPv6 status check function.

undo firewall session link-state [ icmp | tcp ] check
Or
undo firewall ipv6 session link-state [ icmpv6 | tcp ] check
After the status check function is enabled, a session is established only when the first packet
passes through the FW. After the status check function is disabled, sessions can be established
even if no subsequent packets are found.
----End
Follow-up Procedure
Run the display firewall [ ipv6 ] session link-state command to check whether the status
check function is enabled.
Check whether the IPv4 status check function is enabled. The command output shows that the
status check function is enabled for TCP flows but disabled for ICMP flows.
<FW> system-view
[FW] display firewall session link-state
Current firewall session link-
state:
------------------------------------

TCP check:
on
ICMP check:
off
------------------------------------
Check whether the IPv6 status check function is enabled. The command output shows that the
status check function is enabled for TCP and ICMP flows.
<FW> system-view
[FW] display firewall ipv6 session link-state
Current firewall ipv6 session link-state:
-----------------------------------------
TCP check: on
ICMPv6 check: on
-----------------------------------------
1.13.2 Configuring the Aging Time of the Session Table

You can reset the aging time of the session on the FW to meet the requirement of the network.
Context
The created session entry needs to be matched by packets constantly. If no packet matches for
a long time, it indicates that the connection between both communications parties is
interrupted, and the session entry is unnecessary. To save system resources, the system deletes
the entry that is not matched for a continuous period of time; that is, the session entry ages.
When the session entry ages and the packet whose quintuple is the same as that of the entry
passes through, the system determines whether to create a session entry based on the security
policy. If no session entry is created, the packet cannot be forwarded. The length of the aging
time of the session table affects system forwarding as following:
l If the aging time is too long, a large number of interrupted session entries may exist in
the system and consume system resources. In addition, new session entries may not be
created, affecting the forwarding of other services.
l If the aging time of the session entry is too short, certain connections that require a long
time for sending packets are interrupted, affecting service forwarding.
Generally, the default aging time of the session table is adopted. To change the aging time,
you should first estimate and identify the traffic type and connection number of the actual
network. For special services that require long time connections, you are advised to
implement the 1.13.3 Configuring a Persistent Connection function instead of running the
following command to lengthen the aging time of the traffic of a certain protocol.
Procedure
system-view
Step 2 Set the aging time of the session table.

firewall session aging-time { service-set session-type aging-time | default }
Step 3 View the aging time of the session table.

display firewall session aging-time [ type { pre-defined | user-defined } ]

Step 4 View information about the IPv4 or IPv6 session table.

display firewall session table [ verbose ] [ source-cpe ipv6-address [ to end-
ipv6-address ] ] [ source { inside ip-address [ to end-ip-address ] | global ip-
address [ to end-ip-address ] } ] [ destination-cpe ipv6-address [ to end-ipv6-
address ] ] [ destination { inside ip-address [ to end-ip-address ] | global ip-
address [ to end-ip-address ] } ] [ protocol protocol ] [ application
application ] [ source-port { inside source-port | global source-port } ]
[ destination-port destination-port ] [ long-link ]
Or
display firewall ipv6 session table [ verbose ] [ source ipv6-address [ to end-
ipv6-address ] ] [ source-port source-port ] [ destination ipv6-address [ to end-
ipv6-address ] ] [ application application ] [ destination-port destination-
port ] [ long-link ]
----End
1.13.3 Configuring a Persistent Connection

On actual networks, sessions of data flows in certain services require long aging time.
Configuring the persistent connection function guarantees the normal running of such
services.
Context
Generally, the default aging time on the device can meet the forwarding requirements. You
can also fine-tune the aging time as needed. However, for some services, the idle time
between two packets can be very long. For example:
l When a user downloads large files using FTP, the idle time between control packets
along the control channel can be very long.
l A user may query a database server now and then, and the time between query
operations may be greater than the aging time of the TCP session.
To remedy this, you can set the aging time to a larger value. However, the aging time applies
to all protocol sessions, resulting in performance degradation.
Therefore, the aging time setting must be more precise. The persistent connection function
allows you to set the session aging time for specific flows. However, the FW supports
persistent connection only for TCP.
NOTE
l When stateful inspection is disabled, the device also creates session entries for non-first packets. In
this case, you do not need to enable the persistent connection function.
l The aging time specified through the persistent connection function is not affected by the global
aging time of the session table.
Procedure
system-view
Step 2 Access the security policy view.
security-policy

Step 3 Create a security policy rule and access the security policy rule view.
rule name rule-name
Step 4 Enable the persistent connection function.
long-link enable
Step 5 Specify the aging time of each persistent connection.
long-link aging-time interval
----End
1.13.4 Configuring the Hash-based Board Selection Mode

This section describes the basic concept and configuration of the hash-based board selection
mode.
Context
NOTE
Only supports this function.
The is a distributed device. You can insert multiple firewall SPUs in the device. When the
LPU receives the packets that need to be processed by SPUs, the hash algorithm is applied to
send the packets to the corresponding CPU of the SPU by computing the information of the
packets.
Currently, the supports the following hash based board selection modes:
l Hash-based board selection mode that is oriented to the source IP address
The source IP address of a packet determines the CPU of the SPU on the firewall that
processes the packet.
You must set the hash-based board selection mode to the source address mode to use the
following functions:
– Triplet NAT
l Hash-based board selection mode that is oriented to the source and destination IP
addresses
The source and destination IP addresses of a packet determine the CPU of the SPU on
the firewall that processes the packet.
According to the result of hash-based computation, different types of traffic may be sent to the
same CPU of the SPU on the firewall due to certain features of the hash algorithm. As a
result, the CPU cannot process other services. To avoid the preceding issue, the can adjust the
hash gene to evenly send different types of traffic to the SPUs on the firewall.
Procedure
system-view
Step 2 Configure the hash-based board selection mode.
firewall hash-mode { source-and-destination | source-only }

By default, the hash-based board selection mode is oriented to the source and destination IP
addresses.
The configuration takes effect after you restart the device.
Step 3 Specify a hash gene.
firewall hash-gene hash-gene
By default, the hash gene is 0.
The configuration takes effect after you restart the device.
NOTICE
You are recommended to use the default configuration.
----End

This section describes the versions and changes in the status check and packet processing
feature.
Version Description
1.14 File System

This chapter describes how to manage the directories and files in the file system of the FW
and how to transfer files between the FW and other devices.
1.14.1 Overview
This section describes the file system structure and file transfer mode of the FW.
1.14.1.1 File System

A file system consists storage devices and the files stored on the storage devices. You can
manage the storage devices and the files stored on the storage devices.
Table 1-47 lists the storage devices supported by the FW.

Table 1-47 Supported storage devices

Storage Device Root Directory Description
CF card hda1:/ Storage device in standard configuration. It is

used to store system software and configuration
files.
Table 1-48 shows the system directories in the
CF card. To display the directories, run the
dir /all command.
NOTE
Information in system directories is important.
Therefore, do not change or delete these directories.
The FW allows you to repair and format the storage devices, as well as create, delete, and
modify files or directories on the storage devices.
Table 1-48 System directories in the CF card

Directory Function
Name
default-sdb Stores the default signature database file and version information.
update Stores post-upgrade signature database file and version information.
gpmbak Stores the backup state machines of the GPM module.
loc Stores location information.
umdb Stores user information, including users' basic information, customized

logo, and background image.
hidehttpdcertke Stores encrypted device default certificates and key pairs.

y
hidepkirsakey Stores encrypted PKI key pairs.
cfgbak Stores the backup configuration profile.

The system automatically generates this directory only when the backup
parameter is selected during the manual upgrade of the configuration
profile.
download Stores web page and image resources.
$_install_mod Stores the dynamically loaded component packages.
isp Stores ISP address files.
dhcp Stores DHCP address pool data and client DUIDs.
tracefile Stores the exported temporary packet tracing files.
log Stores system and diagnosis logs.

Directory Function
Name
seclog Stores service logs.
pmdata Stores performance management statistics files.
1.14.1.2 File Transfer Mode

The FW supports FTP, SFTP, and TFTP file transfer modes.
During file transfer, the FW can server as a server or client:
l FW as a server: Administrators can access the FW from terminals to manage files on the
FW or transfer files with the FW.
l FW as a client: Administrators can access other devices from the FW to manage files on
these devices or transfer files with these devices.
In the TFTP mode, the FW can serve only as a client. In the FTP and SFTP modes, the FW
can server as a server or client.
Table 1-49 lists the advantages and disadvantages of different file management modes.
Table 1-49 File transfer mode

File Transfer Application Advantages Disadvantages
Mode Scenarios
FTP Applies to file l Features simple l Transfers data in

transfer scenarios configuration plain text and
that requires high and supports file therefore brings
security, such as transfer and file security risks.
version upgrade. directory
operations.
l Supports file
transfer between
two file systems.
l Supports
authentication
and
authorization.

File Transfer Application Advantages Disadvantages

Mode Scenarios
TFTP Applies to scenarios l Uses less l Supports only

where no complex memory space file transfer, but
communication is than FTP. not interactions.
required between the l Features simple l Transfers only
client and the server, configuration. files no larger
for example, the than 32 MB.
online version load
and upgrade in lab l Transfers data in
LANs that have plain text, does
good network not support
condition. authentication or
authorization,
and therefore
brings security
risks.
SFTP Applies to scenarios l Implements strict l Requires

that require high encryption and complex
security, such as log integration configuration.
download and protection on
configuration file data to ensure
backup. high security.
l Supports file
transfer and file
directory
operations.
NOTICE
SFTP is recommended because of high security.
1.14.2 Managing the File System

You can manage the storage devices, directories, and files after logging in to the FW through
the console port, Telnet, or STelnet.
Managing Storage Devices

Table 1-50 lists the commands for managing storage devices.
NOTE
All these commands need to be executed in the user view.

Table 1-50 Commands for managing storage devices

Operation Command Description
Repair a storage device. fixdisk device-name If an exception occurs in the

file system on a storage
device, the FW notifies you
to repair the storage device.
Back up the files before
repairing the storage device
to avoid data loss.
Format a storage device. format device-name If the file system is

abnormal or the data is no
longer required, you can
format the storage device.
NOTICE
The data cannot be restored
after the storage device is
formatted. Therefore, exercise
caution when performing this
operation.
Managing Directories
Table 1-51 lists the commands for managing directories.
NOTE
All these commands need to be executed in the user view.
Table 1-51 Commands for managing directories

Access a specific directory. cd { .. | directory } l directory: specifies the

name of the directory to
be accessed in the
current path.
l path: specifies the name
of the directory to be
accessed in the specified
path.
Display the current pwd -

directory.

Display the files and dir [ /all ] [ filename | /all- l /all: Displays the
subdirectories in the specific filesystems ] [ /order information about all
directory. datetime [ reverse ] ] files, including deleted
files. Deleted files are
square-bracketed, for
example, [ text ].
l filename | directory:
Displays the files and
subdirectories of a
specific directory. If the
value is not specified, the
dir command displays
all files and
subdirectories in the
current directory.
l /all-filesystems: displays
information about files in
all storage medium root
directories.
l /order: displays
sequential file
information.
l datetime: displays file
information in ascending
order of file modification
time.
l reverse: displays file
information in
descending order of file
modification time.
Create a directory. mkdir make-remote- make-remote-directory:

directory specifies a directory name.
Delete a directory. rmdir delete-remote- delete-remote-directory:

directory specifies a directory name.
Managing Files
Table 1-52 lists the commands for managing files.
NOTE
All these commands need to be executed in the user view, except execute filename and file prompt { alert |
quiet } (in the system view).

Table 1-52 Commands for managing files

Display a file. more file-name [ offset ] l file-name: specifies a file

[ all ] name.
l offset: specifies the offset
of file displaying.
l all: indicates that all files
are displayed at a time.
Copy a file. copy source-filename -

destination-filename
Move a file. move source-filename -

Rename a file. rename source-filename -

Compress a file. zip source-filename -

Decompress a file. unzip source-filename -

Delete a file. delete [ /unreserved ] [ / NOTICE

quiet ] { filename | device- If the command carries the /
unreserved parameter, the
name }
deleted file cannot be restored.
Restore a deleted file. undelete filename The delete filename

command deletes a file and
puts it to the recycle bin.
You can run the undelete
filename command to
restore it.
The dir /all command
displays deleted files. The
names of deleted files are
square-bracketed, for
example, [ text ].
If the current directory is not
the root directory, use the
absolute path to operate the
file.
Delete files from the recycle reset recycle-bin -

bin. [ filename ]
Run a batch file. execute filename This command runs only

batch files with file name
extension bat and are stored
on storage devices of the
FW.

Configure a file system file prompt { alert | quiet } The file prompt command
prompt method. enables the system to
display information or alert
especially when your
operations may lead to data
loss or damage. You can run
this command to change the
file system prompt method.
NOTICE
If the prompt mode is set to
quiet, the file system does not
prompt for data loss caused by
misoperations, such as file
deletion.
1.14.3 Transferring Files

You can transfer files between FW and other devices through FTP, SFTP, or TFTP mode, and
manage the files on the FW through FTP or SFTP mode.
NOTICE
1.14.3.1 Configuring the FW as an FTP Server

This section describes how to configure the FW as an FTP server.
Procedure
system-view
Step 2 Enable the FTP server.
ftp server enable
The FTP server is configured on the FW by default. You need to run this command to enable
the FTP service.
Step 3 Create an FTP administrator.

1. Access the AAA view.
aaa
2. Configure an administrator account and access the administrator view.
manager-user user-name

3. Configure a password for the administrator account.
password [ cipher cipher-password ]
NOTE
The interactive mode is recommended for creating administrator passwords because the passwords
configured by the cipher password command are not safe.
4. Set the administrator level.
level level
NOTE
To ensure that the administrator can log in to the FW, set the administrator level to be 3 or higher.
5. Set the service type to FTP for the administrator account.
service-type ftp
6. Set the FTP service directory for the administrator account.
ftp-directory directory
7. Set the maximum number of administrators that can concurrently log in using this
administrator account.
access-limit max-number
8. Return to the AAA view.
quit
9. Return to the system view.
quit
Step 4 Optional: Set the idle duration of FTP connections.
ftp timeout minutes
To prevent unauthorized access, the FW automatically closes the FTP connections if the FW
does not receive any FTP request in a specific period of time. To use the FTP service, FTP
administrators must log in to the FTP server again.
The default connection idle duration is 30 minutes.
Step 5 Optional: Configure ACLs for FTP connections.
ACLs are configured to enhance the security of the FTP server.
1. Access the ACL view.
acl [ number ] acl-number [ vpn-instance vpn-instance ]
NOTE
FTP supports only basic ACLs. Therefore, the acl-number value ranges from 2000 to 2999.
2. Configure an ACL rule.
rule [ rule-id ] { deny | permit } [ logging | source { source-ip-address soucer-wildcard

| any } | time-range time-name ]
quit
4. Configure basic ACLs for FTP connections.

ftp acl acl-number
----End
1.14.3.2 Configuring the FW as an FTP Client

This section describes the common operations on the FW which serves as an FTP client.
Procedure
Step 1 Log in to the FTP server.
Different commands are available for you to log in to the FTP server from different views.
l Set up a connection with the FTP server from the user view.
ftp ip-address or hostname [ port-number ] [ vpn-instance vpn-instance-name ]
l Set up a connection with the FTP server from the FTP client view.
open ip-address or hostname [ port-number ] [ vpn-instance vpn-instance-name ]
Step 2 Optional: Configure the data type and file transfer mode.
Set the data type to ASCII code or binary. ascii or binary

The default data type is ASCII.
Set the file transfer mode to passive or passive or undo passive

active.
The client uses the passive mode to
establish the data tunnel by default.
Step 3 Perform common operations on the FTP client.
Display FTP command online help. remotehelp [ command ]
Upload a local file to the FTP server. put local-filename [ remote-filename ]
Download a file from the FTP server to the get remote-filename [ local-filename ]
local device.
Display the current directory on the FTP pwd

server.
Change the current directory on the FTP cd pathname

server.
Create a directory on the FTP server. mkdir remote-directory

NOTE
l The directory name can contain letters and
digits, but not special characters, such as
angle brackets (< >), question mark (?),
backslash (\), or colon (:).
l If you run the mkdir abc command,
directory abc is created in the root directory.
Delete a directory from the FTP server. rmdir remote-directory

Display or change the current directory on lcd [local-directory ]

the FTP client.
Display the specified directory or file on the ls [ remote-filename ] [ local-filename ]

FTP server.
Display details on a directory or a file on the dir [ remote-filename ] [ local-filename ]

FTP server.
Delete a file from the FTP server. delete remote-filename
Change the login account and log in again. user user-name [ password ]
Close the connection with the FTP server, close

but stay in the FTP view.
Close the connection with the FTP server bye or quit

and return to the user view.
----End
1.14.3.3 Configuring the FW as an SFTP Server

This section describes how to configure the FW as an SFTP server.
Procedure
system-view
Step 2 Enable the SFTP server function.
sftp server enable
Step 3 Configure the VTY UI.
1. Access the VTY UI.
user-interface [ ui-type ] first-ui-number [ last-ui-number ]
2. Set the authentication mode to AAA.
3. Configure SSH.
4. Configure a VTY UI level.
user privilege level level
NOTE
To ensure that administrators can log in to the FW, set the VTY UI level to be 3 or higher.
Step 4 Create an SFTP administrator.

1. Access the AAA view.
aaa
2. Configure an administrator account and access the administrator view.
manager-user user-name

3. Configure a level for the administrator.

level level
NOTE
To ensure that the administrator can log in to the FW, set the administrator level to be 3 or higher.
4. Set the service type to SSH for the administrator.
service-type ssh
quit
Step 5 Create an RSA key pair or a DSA key pair.
l Run the rsa local-key-pair create command to create a local RSA key pair.
NOTE
– You need to run the rsa local-key-pair create command to generate the local RSA key pair
before performing other SSH configurations. The host key pair length and server key pair
length range from 512 to 2048, in bits.
The default value is 2048 bit. As for version upgrade, if the original key pair length is smaller
than 1024 bits, you are advised to run the command after the upgrade.
– After creating a local RSA key pair, you can run the display rsa local-key-pair public
command to view the public key in the local key pair.
– You can run the rsa local-key-pair destroy to clear all local RSA key pairs, the host key pairs
and host key pairs.
After running the rsa local-key-pair destroy command, check whether all local RSA key
pairs are cleared. The command configuration takes effect only once and is not saved into the
configuration file.
l Run the dsa local-key-pair create command to create a local DSA key pair.
NOTE
– You need to run the dsa local-key-pair create command to generate the local DSA key pair
before performing other SSH configurations. The host key pair length and server key pair
length can be 512 bits, 1024 bits, or 2048 bits. The default key pair length is 2048 bits.
– After creating the local DSA key pair, you can run the display dsa local-key-pair public
command to view the public key in the local key pair.
– You can run the dsa local-key-pair destroy to clear all local DSA key pairs, the host key pairs
and host key pairs.
After running the dsa local-key-pair destroy command, check whether all local DSA key
pairs are cleared. The command configuration takes effect only once and is not saved into the
configuration file.
Step 6 Create an SSH user.

ssh user username
Step 7 Select one authentication mode for the SFTP account.

Configure the password 1. Run the ssh user username authentication-type password
authentication mode. command to set the authentication mode to password.
2. Run the aaa command to access the AAA view.
3. Run the manager-user user-name command to enter the
administrator view.
4. Run the password [ ciphercipher-password ] command to
set a password for the SFTP account.
NOTE
The interactive mode is recommended for creating administrator
passwords because the passwords configured using the cipher cipher-
password command are not safe.
Do not use the default password Admin@123. Otherwise, SFTP users
cannot log in to the device.
Configure the RSA 1. Run the ssh user username authentication-type rsa
authentication mode. command to set the authentication mode to RSA.
2. Bind the SFTP account with the RSA public key on the
client.
a. Run the rsa peer-public-key key-name [ encoding-type
{ der | pem | openssh } ] command to access the RSA
public key view.
b. Run the public-key-code begin command to access
public key editing view.
c. Enter the RSA public key of the client through typing or
copy and paste.
d. Run the public-key-code end command to return to the
RSA public key view.
e. Run the peer-public-key end command to return to the
system view.
f. Run the ssh user user-name assign rsa-key key-name
command to bind an RSA public key to the SFTP
account.

Configure the DSA 1. Run the ssh user username authentication-type dsa
authentication mode. command to set the authentication mode to DSA.
2. Bind the SFTP account with the DSA public key on the
client.
a. Run the dsa peer-public-key key-name [ encoding-type
{ der | pem | openssh } ] command to access the DSA
public key view.
b. Run the public-key-code begin command to access
public key editing view.
c. Enter the DSA public key of the client through typing or
copy and paste.
d. Run the public-key-code end command to return to the
DSA public key view.
e. Run the peer-public-key end command to return to the
system view.
f. Run the ssh user user-name assign dsa-key key-name
command to bind a DSA public key to the SFTP
account.
Configure the all The all authentication mode indicates either password or RSA
authentication mode. authentication. If both password authentication and RSA
authentication are configured, RSA authentication is used
preferentially.
Configure the password- Password-RSA authentication indicates that both password

RSA authentication authentication and RSA authentication are implemented.
mode.
Configure the password- Password-DSA authentication indicates that both password

DSA authentication authentication and DSA authentication are implemented.
mode.
Step 8 Optional: Configure command-specific authorization for an SSH user.

Run the ssh user user-name authorization-cmd aaa command to configure command-
specific authorization for a specific SSH user.
After configuring command-specific authorization for the SSH user, you need to configure
AAA authorization. Otherwise, command-specific authorization does not take effect for the
SSH user.
Step 9 Set the service type to SFTP for the SSH account.
ssh user username service-type sftp
Step 10 Configure an SFTP service authorization directory for the SSH user.
ssh user username sftp-directory directoryname
Step 11 Optional: Set other parameters for the SFTP server.

Set a service port number ssh server port port-number

for the SFTP server. NOTE
The port-number value ranges from 1025 to 55535.
By default, the FW serving as the SFTP server uses port 22.
Set the timeout duration ssh server timeout seconds

of SFTP authentication.
Set the number of SFTP ssh server authentication-retries times

Set the interval for ssh server rekey-interval interval

updating SFTP server
key pairs.
Enable the backward ssh server compatible-ssh1x enable

compatibility function.
Specify a source ssh server-source -i loopback interface-number

interface.
Configure an ACL for l ssh server acl acl-number

the SSH server. l ssh ipv6 server acl acl-number
----End
1.14.3.4 Configuring the FW as an SFTP Client

This section describes how to configure the FW as an SFTP client and how to log in to the
SFTP server.
Procedure
system-view
Step 2 Enable first-time authentication or bind the RSA public key to the SFTP server. First-time
authentication is recommended.
NOTE
When communicating with an SFTP server, the FW (SFTP client) needs to compare the RSA public key sent
by the server with the locally stored RSA public key to check whether it is communicating with the correct
server.
If the server RSA public key is not obtained in advance and does not exist on theFW, enable first-time
authentication on the FW to ensure that the FW can log in to the server.
If you have obtained the server RSA public key in advance, you can copy the public key to the FW and bind
the server to this public key. This method also ensures that the FW can log in to the server, but binding the
server to the RSA public key is complex. Therefore, first-time authentication is recommended.
l Enable first-time authentication.
ssh client first-time enable
l Bind the SFTP server to an RSA public key.
a. Access the public key view.

rsa peer-public-key key-name [ encoding-type { der | pem | openssh } ]

b. Access the public key editing view.
public-key-code begin
c. Enter the RSA public key through typing or copy and paste.
d. Return to the public key view.
public-key-code end
e. Return to the system view.
peer-public-key end
f. Bind the SFTP server to the RSA public key.
ssh client servername assign rsa-key keyname
NOTE
If the binding between the SFTP server and the RSA public key becomes invalid, run the
undo ssh client servername assign rsa-key command to cancel the binding and bind the
SFTP server to a new RSA public key.
Step 3 If the SFTP server uses password authentication, perform Step 4 to log in to the SFTP server.
If the SFTP server uses RSA authentication, bind the SFTP account of the FW to the RSA
public key on the server as follows:
1. Generate an RSA key pair on the FW.
rsa local-key-pair create
2. Check the public key in the RSA key pair, copy the public key information of the host
key pair to the server, and bind the SFTP account on the FW to this public key. For
details, refer to the SFTP server operation guide.
display rsa local-key-pair public

NOTE
The public key information to be copied is the Key code, Host public key for PEM format code,
or Public key code for pasting into OpenSSH authorized_keys file (based on the server coding
format) field below the sysname_Host field in the display rsa local-key-pair public command
output.
<sysname> display rsa local-key-pair public
=====================================================
Time of Key pair created: 18:34:19

2013/1/17
Key name:
sysname_Host
Key type: RSA encryption
Key
=====================================================
Key
code:
308188
028180
CB35ED46 660B55CC 80EAAFD7 78DDFBF7

467A1C13
5D29865C 63509D5D E25E423A DB11A00F
77CDBBB4
D93436EA D50E4261 AC476E56 7AC6344A
B0ECE377
EA2E6912 4EC32710 FC4B5D2D 61E358B1
E8EA739F
A0338BE0 ED72A9A0 EDFE49FD 071623A4
96A0A45B
4EAD2641 A8D7A39F 567B02B9 90DE5722
980072B4
B320FDA0
10F18DF9
0203
010001
Host public key for PEM format

code:
---- BEGIN SSH2 PUBLIC KEY
----
AAAAB3NzaC1yc2EAAAADAQABAAAAgQDLNe1GZgtVzIDqr9d43fv3RnocE10phlxj
UJ1d4l5COtsRoA93zbu02TQ26tUOQmGsR25WesY0SrDs43fqLmkSTsMnEPxLXS1h
41ix6Opzn6Azi+Dtcqmg7f5J/
QcWI6SWoKRbTq0mQajXo59WewK5kN5XIpgAcrSz
IP2gEPGN
+Q==
---- END SSH2 PUBLIC KEY
----
Public key code for pasting into OpenSSH authorized_keys

file :
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAAAgQDLNe1GZgtVzIDqr9d43fv3RnocE10phlxjUJ1d4l5C
OtsRoA93zbu02TQ26tUOQmGsR25WesY0SrDs43fqLmkSTsMnEPxLXS1h41ix6Opzn6Azi
+Dtcqmg7f5J

/QcWI6SWoKRbTq0mQajXo59WewK5kN5XIpgAcrSzIP2gEPGN+Q== rsa-
key
Step 4 Log in to the SFTP server.
sftp [ -a source-address | -i ] host-ip [ port ] [ [ -vpn-instance vpn-instance-name ] |

[ prefer_kex { dh_group1 | dh_exchange_group } ] [ prefer_ctos_cipher { des | 3des |
aes128 } ] [ prefer_stoc_cipher { des | 3des | aes128 } ] [ prefer_ctos_hmac { sha1 |
sha1_96 | md5 | md5_96 } ] [ prefer_stoc_hmac { sha1 | sha1_96 | md5 | md5_96 } ] ] *
If first-time authentication is enabled and the FW does not store the server RSA public key,
you need to determine whether to trust the server and whether to save the server RSA public
key upon first login. Select Y when prompted.
[sysname] sftp 10.2.2.1
Please input the username:sysname
Trying 10.2.2.1 ...
Press CTRL+K to abort
Connected to 10.2.2.1 ...
The server is not authenticated. Continue to access it? [Y/N] :Y
Save the server's public key? [Y/N] :Y
The server's public key will be saved with the name 10.2.2.1. Please wait .
..
NOTE
To improve file transfer security, use AES128 preferentially as the encryption algorithm. DES and 3DES
are not recommended. Use SHA1 or SHA1-96 preferentially as the HMAC algorithm. MD5 and
MD5-96 are not recommended.
----End
1.14.3.5 Configuring the FW as a TFTP Client

This section describes the common operations and configurations on the FW which serves as
a TFTP client.
Procedure
Step 1 Optional: Configure ACLs to limit the access from the FW to the TFTP server.
system-view
2. Access the ACL view.
acl [ number ] acl-number [ vpn-instance vpn-instance ]
NOTE
TFTP supports only basic ACLs. Therefore, the acl-number value ranges from 2000 to 2999.
3. Configure ACL rules.
rule [ rule-id ] { deny | permit } [ logging | source { source-ip-address source-wildcard
| any } | time-range time-name ]
quit
5. Use ACLs to limit the access from the FW to the TFTP server.
tftp-server acl acl-number
Step 2 Perform TFTP file download and upload on the FW.

l In the user view, run the following command to download files through TFTP.
tftp tftp-server get source-filename [ destination-filename ]
l In the user view, run the following command to upload files through TFTP.
tftp tftp-server put source-filename [ destination-filename ]
----End
1.14.4 Maintaining the File System

You can run commands to display the FTP server and SFTP server configurations on the FW.
1.14.4.1 Displaying Information About the FTP Server and FTP Administrator
This section describes how to use commands to display FTP configuration information.
Context
In routine maintenance, you can run the commands shown in Table 1-53 in any view to
display FTP configurations and FTP administrators.
Table 1-53 Displaying information about FTP configurations and FTP administrators
Operation Command
Display the configurations and display ftp-server

status of the FTP server.
Display information about the display ftp-users

FTP administrators that have
logged in.
1.14.4.2 Displaying Information About the SFTP Server and SFTP Administrator
This section describes how to display the SFTP server configuration and how to debug the
SFTP function.
Displaying SFTP Administrator and Server Information

Table 1-54 lists the operations to display SFTP administrator and SFTP server information.
Table 1-54 Displaying SFTP administrator and server information
Operation Command
Display SFTP administrator information. display manager-user
Display SFTP server information. display ssh server

Debugging SFTP
Before you enable the debugging function, you must run the terminal monitor command and
the terminal debugging command in the user view to enable the information display and
debugging display functions of the terminal. Then debugging information can be displayed on
the terminal.
NOTICE
Debugging commands compromise system performance. After the debugging is complete, run
the undo debugging all command to disable all debugging functions.
For the description of debugging commands, refer to the Debugging Reference.

Table 1-55 lists the operations to debug SFTP.
Table 1-55 Debugging SFTP

Operation Command
Debug SFTP. debugging ssh server { all | vty vty-

number } { all | event | message | packet }

This section provides examples for enabling administrators to log in to the FW using SSH.
1.14.5.1 Example for Back Up Files

This section describes how to back up files in the storage device after you log in to the FW.
Requirements
You have already copied files to the specified directory.
NOTE
The is a root directory example.
Item Data
Source file name and path hda1:/sample.txt
Destination file name and path hda1:/test/sample1.txt
Procedure
Step 1 Display the information about the files in the directory of the storage device.
<FW> dir hda1:
Directory of hda1:/

0 -rw- 264 Oct 23 2009 10:58:16 private-data.txt

2 -rw- 679 Oct 18 2009 17:51:41 vspcfg.zip
3 -rw- 396 Aug 03 2009 09:58:16 hostkey
4 -rw- 540 Aug 03 2009 09:58:23 serverkey
13 -rw- 1717 Sep 21 2009 18:48:00 or4148.dat
15 -rw- 23 Oct 24 2009 11:14:39 sample.txt
<FW> dir hda1:/test/
Directory of hda1:/test/
0 drw- - Jul 12 2009 17:35:57 database
1 drw- - Jul 12 2009 17:25:57 conf
3 drw- - Jul 12 2009 17:32:57 log
Step 2 Copy files from hda1:/sample.txt to hda1:/test/sample1.txt.

<FW> copy hda1:/sample.txt hda1:/test/sample1.txt
Copy hda1:/sample.txt to hda1:/test/sample1.txt?[Y/N] :y
100% complete
Info:Copied file hda1:/sample.txt to hda1:/test/sample1.txt...Done
----End
Verification
Check whether the copied files exist in the specified directory.
<FW> dir hda1:/test/
Directory of hda1:/test/
0 drw- - Jul 12 2009 17:35:57 database
1 drw- - Jul 12 2009 17:25:57 conf
3 drw- - Jul 12 2009 17:32:57 log
4 -rw- 23 Oct 24 2009 11:16:40 sample1.txt
1.14.5.2 Example for Configuring the FW as an FTP Server

This section describes how to configure the FW as an FTP server and how to use a PC to
download files from the FW through FTP.
As shown in Figure 1-48, a PC is used to log in to the FW and download files from the FW
through FTP.
NOTICE
FTP transmits passwords and data in plaintext mode, causing security risks. To secure data
transmission, use SFTP.
Figure 1-48 Networking diagram for configuring the FW as an FTP server
MGMT (GE0/0/0)
192.168.0.1/24
192.168.0.100/24
FW PC

Data Planning
Item Data
FW Security policy: policy_ftp

FTP administrator account: admin_ftp,
password: Mydevice@ftp
FTP server directory: hda1
File: sys.bin
PC IP address and mask of the administrator's

PC: 192.168.0.100/24
FTP client software: cmd (in the Windows
operating system)
Procedure
1. Configure a security policy for the Local-Trust interzone to permit the FTP service.
<FW> system-view
[FW-policy-security] rule name policy_ftp
[FW-policy-security-rule-policy_ftp] service ftp
[FW-policy-security-rule-policy_ftp] source-zone trust
[FW-policy-security-rule-policy_ftp] destination-zone local
[FW-policy-security-rule-policy_ftp] source-address 192.168.0.100 32
[FW-policy-security-rule-policy_ftp] destination-address 192.168.0.1 32
[FW-policy-security-rule-policy_ftp] action permit
[FW-policy-security-rule-policy_ftp] quit
2. Configure an FTP administrator account.

[FW] aaa
[FW-aaa] manager-user admin_ftp
[FW-aaa-manager-user-admin_ftp] password
Enter Password:
Confirm Password:
[FW-aaa-manager-user-admin_ftp] level 3
[FW-aaa-manager-user-admin_ftp] service-type ftp
[FW-aaa-manager-user-admin_ftp] ftp-directory hda1:
[FW-aaa-manager-user-admin_ftp] quit
[FW-aaa] quit
3. Enable the FTP service.

[FW] ftp server enable
Step 2 Set an IP address and subnet mask for the PC. Details are omitted.
Step 3 Use FTP to log in to the FW from the PC and download files.
1. Choose Start > Run, enter cmd, and press Enter.
2. Enter D: and press Enter to set drive D as the working directory for the administrator's
PC.
3. Enter ftp 192.168.0.1, press Enter, and then use the account and password to log in to
the FW.
4. Download file sys.bin from the FTP directory on the FW to the root directory of drive D.

5. Close the FTP connection and view the downloaded file.

C:\Documents and Settings\user> d:
D:\> ftp 192.168.0.1
Trying 192.168.0.1 ...
Warning: FTP is not a secure protocol, and you are advised to use SFTP.
Connected to 192.168.0.1.
220 FTP service ready.
User(192.168.0.1:(none)):admin_ftp
331 Password required for admin_ftp.
Password:
230 User logged in.
ftp> binary
200 Type set to I.
ftp> get sys.bin
200 PORT command okay.
150 Opening BINARY mode data connection for sys.bin.
226 Transfer complete.
ftp:
20116676 bytes received for 43.60 seconds at 461.40 kbyte/s.
ftp> quit
D:\>dir
......
2010-09-25 15:56 20,116,676 sys.bin
......
----End
#
sysname FW
#
aaa
manager-user admin_ftp
password cipher %@%@*y:3*ZN}.%%qcB.|@XBVML1cCyDwlDWq'6JF(iOz2D8>A\SN%@
%@
service-type ftp
level 3
ftp-directory hda1:
#
security-policy
rule name policy_ftp
source-zone trust
service ftp
source-address 192.168.0.100
32
action permit
1.14.5.3 Example for Configuring the FW as an FTP Client

This section describes how to configure the FW as an FTP client to obtain files from an FTP
server.
As shown in Figure 1-49, configure the FW as an FTP client and download files from the
FTP server to the specified local directory.

NOTICE
FTP transmits passwords and data in plaintext mode, causing security risks. To secure data
transmission, use SFTP.
Figure 1-49 Networking diagram for configuring the FW as an FTP client
GE1/0/1
192.168.0.100/24 192.168.0.1/24
Network
FTP Server FW
Data Planning
Item Data
FTP server (already configured) IP address and subnet mask:

192.168.0.100/24
FTP account/password: ftp_sever/
FTPserver@123
File: sys.ini
FW Security policy: policy_ftp

Directory for saving the file: hda1: (default
directory on the FW)
Procedure
Step 1 Configure a security policy for the Local-Trust interzone to permit the FTP service.
<FW> system-view
[FW-policy-security] rule name policy_ftp
[FW-policy-security-rule-policy_ftp] service ftp
[FW-policy-security-rule-policy_ftp] source-zone local
[FW-policy-security-rule-policy_ftp] destination-zone trust
[FW-policy-security-rule-policy_ftp] source-address 192.168.0.1 24
[FW-policy-security-rule-policy_ftp] destination-address 192.168.0.100 24
[FW-policy-security-rule-policy_ftp] action permit
[FW-policy-security-rule-policy_ftp] quit
Step 2 Log in to the FTP server from the FW and download the file to the specified directory.
# Log in to the FTP server.
<FW> ftp 192.168.0.100
Trying 192.168.0.100
Connected to 192.168.0.100
Warning: FTP is not a secure protocol, and you are advised to use SFTP.

220 FTP service ready.

User(ftp 192.168.0.100:(none)):ftp_sever
331 Password required for ftp_sever
Password:
230 User ftp_sever logged in.
# Set the file transfer mode to binary and display the current directory on the FW for saving
the file.
[ftp] binary
200 Type set to I.
[ftp] lcd
Info: Local directory now hda1:.
# Download the file from the FTP server and display the downloaded file in the specified
directory on the FW.
[ftp] get sys.bin
200 PORT command okay.
150 Opening BINARY mode data connection for sys.bin.
226 Transfer complete.
ftp: 20116676 byte(s) received, in 43.60 seconds at 461.40 kbytes/sec.
[ftp] quit
<FW> dir
Directory of hda1:/
...
3 -rw- 20116676 Aug 07 2009 06:58:17 sys.bin
...
----End
1.14.5.4 Example for Configuring the FW as an SFTP Server (Password

Authentication)
This section describes how to configure the FW as an SFTP server and how to download files
from the FW through SFTP on a PC.
through SFTP.
Figure 1-50 Networking diagram for logging in to the FW through SFTP (password
authentication)
GE1/0/3
10.3.0.1/24
PC FW
10.3.1.100/24 (SFTP Server)

Data Planning
Item Data
FW SFTP administrator account: sftpadmin_a

Authentication type: password
Password: Mydevice@a
Service type: SFTP
Administrator PC SFTP client software: PuTTY software (Windows 7

operating system). The PuTTY software contains the
PuTTY client for the STelnet service and the SFTP
client PSFTP.
Procedure
1. Set an IP address for interface GigabitEthernet 1/0/3 and assign the interface to a security
zone.
<FW> system-view
2. Configure a security policy for the Local-Trust interzone to permit the SSH service.
[FW-policy-security] rule name policy_sftp
[FW-policy-security-rule-policy_sftp] service ssh
[FW-policy-security-rule-policy_sftp] source-zone trust
[FW-policy-security-rule-policy_sftp] destination-zone local
[FW-policy-security-rule-policy_sftp] source-address 10.3.1.0 24
[FW-policy-security-rule-policy_sftp] action permit
[FW-policy-security-rule-policy_sftp] quit
3. Enable the SFTP service.

[FW] sftp server enable

The range of public key size is (512 ~
2048).
risks.
Input the bits in the modulus[default =
2048]:
Generating
keys...
...+++++++
+
..+++++++
+
..................................++++++++

+
............+++++++++
5. Configure the VTY administrator interface.

[FW-ui-vty0-4] quit
6. Create an SFTP administrator account and specify an authentication mode and a service
type.
# Create SFTP administrator account sftpadmin_a and set the authentication mode to
password, service type to SFTP, and service directory to hda1:.
[FW] ssh user sftpadmin_a

[FW] ssh user sftpadmin_a authentication-type password
[FW] aaa
[FW-aaa] manager-user sftpadmin_a
[FW-aaa-manager-user-sftpadmin_a] service-type ssh
[FW-aaa-manager-user-sftpadmin_a] level 3
[FW-aaa-manager-user-sftpadmin_a] password
Enter Password:
Confirm Password:
[FW-aaa-manager-user-sftpadmin_a] quit
[FW-aaa] quit
7. Set the service type to SFTP for the SSH account.
[FW] ssh user sftpadmin_a service-type sftp
8. Configure an SFTP service authorization directory for the SSH user.
[FW] ssh user sftpadmin_a sftp-directory hda1:
Step 2 Configure the administrator PC.

1. Set the IP address and subnet mask of the administrator PC to 10.3.1.100/255.255.255.0.
3. Use the PuTTY to log in to FW_B through SFTP (the following uses PuTTY0.60 as an
example).
a. Run PSFTP.exe and enter open 10.3.0.1 to set up an SFTP connection with the
FW. The system displays a prompt upon the first connection, as shown in Figure
1-51.
Figure 1-51 PSFTP security prompt

b. Enter y and type the user name and password (sftpadmin_a/Mydevice@a) to log in
to the FW, as shown in Figure 1-52.
Figure 1-52 Logging in to the FW
Step 3 Download files from the FW.
Figure 1-53 Downloading files from the FW
----End
#
sysname FW

#
aaa
manager-user sftpadmin_a
password cipher %@%@fPXYG8r|>17U(MYaBLw0OE<3BRR/*~[B0>uW"^/){U_>wKB=%@%@
service-type ssh
level 3
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
sftp server enable
ssh user sftpadmin_a
ssh user sftpadmin_a authentication-type password
ssh user sftpadmin_a service-type sftp
ssh user sftpadmin_a sftp-directory hda1:
#
idle-timeout 120 0
#
security-policy
rule name policy_sftp
source-zone trust
service ssh
action permit
1.14.5.5 Example for Configuring the FW as an SFTP Server (RSA Authentication)

This section describes how to configure the FW as an SFTP server and how to download files
from the FW through SFTP on a PC.
through SFTP.
Figure 1-54 Networking diagram for logging in to the FW through SFTP (RSA
authentication)
GE1/0/3
10.3.0.1/24
PC FW
10.3.1.100/24 (SFTP Server)

Data Planning
Item Data
FW SFTP administrator account: sftpadmin_a

Authentication type: RSA
Bound client public key: key_pc
Service type: SFTP
Administrator PC SSH client software: PuTTY software

(Windows XP operating system). The
PuTTY software contains the PuTTY client
for the STelnet service, the SFTP client
PSFTP, and key generation tool PuTTYgen.
Name of the public key in the local RSA
key pair: public
Name of the private key in the local RSA
key pair: private
SSH connection: ssh-rsa
Procedure
Step 1 Generate an RSA public key on the PC.
2. Use the PuTTYgen tool to generate a local RSA key pair (the following uses
PuTTYgen0.60 as an example).
a. Double-click PuTTYgen.exe. The interface shown in Figure 1-55 is displayed. In
Parameters, set Type of key to generate to SSH-2 RSA. Click Generate. The PC
starts to generate a local RSA key pair.

Figure 1-55 Selecting the SSH version for generating the local RSA key pair
b. Figure 1-56 shows the interface for generating a local RSA key pair. You must
move the mouse continuously during the generation of the local RSA key pair.
Move the pointer only in the window other than the progress bar in green.
Otherwise, the progress bar suspends, and the generation of the key pair stops.

Figure 1-56 Generating a local RSA key pair
c. Figure 1-57 shows the generation of the local RSA key pair. Do as follows to save
the RSA key pair in the specified format:
n OpenSSH: Copy the marked content in the Key text box.
n PEM: Click Save public key, enter public for the name of the public key file,
and click Save. Click Save private key, enter private for the name of the
private key file, and click Save.
NOTE
To enhance security, you must enter a password in the Key passphrase text box and enter
the password again in the Confirm passphrase text box to set a password for using this key
pair.

Figure 1-57 Saving a local RSA key pair

1. Set an IP address for interface GigabitEthernet 1/0/3 and assign the interface to a security
zone.
<FW> system-view
2. Configure a security policy for the Local-Trust interzone to permit the SSH service.
[FW-policy-security] rule name policy_sftp
[FW-policy-security-rule-policy_sftp] service ssh
[FW-policy-security-rule-policy_sftp] source-zone trust
[FW-policy-security-rule-policy_sftp] destination-zone local
[FW-policy-security-rule-policy_sftp] source-address 10.3.1.0 24
[FW-policy-security-rule-policy_sftp] action permit
[FW-policy-security-rule-policy_sftp] quit
3. Enable the SFTP service.

[FW] sftp server enable

The range of public key size is (512 ~
2048).
risks.
Input the bits in the modulus[default =
2048]:
Generating
keys...
...+++++++
+
..+++++++
+
..................................++++++++
+
............+++++++++
5. Save the RSA public key of the intranet PC. In this example, the RSA public key is
saved in the OpenSSH coding format.
[FW] rsa peer-public-key key_pc encoding-type openssh
Enter "RSA public key" view, return system view with "peer-public-key end".
[FW-rsa-public-key] public-key-code begin
Enter "RSA key code" view, return last view with "public-key-code end".
[FW-rsa-key-code] ssh-rsa
AAAAB3NzaC1yc2EAAAABJQAAAIBwsFDGbVAbK35ecJqsioQ3BdTCa1+eU3i13YQBHvBltIdI9bOMKY
EYJbjuY4UYXkdtwA2ar6LWTI8X1hHbtYGqPk2MvjSF0hXn1DBabNUXbLRyzWAhaopcsTbGboU88cQ6
fe/DqE9jUpNLsPdg4EXz1LMyLNe134JCSe3Ufh7o/w== rsa-key-20140515
[FW-rsa-key-code] public-key-code end
[FW-rsa-public-key] peer-public-key end
6. Configure the VTY UI.
[FW-ui-vty8-10] protocol inbound all
[FW-ui-vty8-10] quit
7. Create an SFTP administrator account and specify an authentication mode and a service
type.
# Create SFTP administrator account sftpadmin_a and set the authentication mode to
RSA, service type to SFTP, and service directory to hda1:.
[FW] aaa
[FW-aaa] manager-user sftpadmin_a
[FW-aaa-manager-user-sftpadmin_a] service-type ssh
[FW-aaa-manager-user-sftpadmin_a] level 3
[FW-aaa-manager-user-sftpadmin_a] quit
[FW-aaa] quit
8. Set the authentication mode to RSA.
[FW] ssh user sftpadmin_a authentication-type rsa

9. Bind an RSA public key to the SFTP account.
[FW] ssh user sftpadmin_a assign rsa-key key_pc

10. Configure command-specific authorization for an SSH user.
[FW] ssh user sftpadmin_a authorization-cmd aaa

11. Set the service type to SFTP for the SSH account.
[FW] ssh user sftpadmin_a service-type sftp

12. Configure an SFTP service authorization directory for the SSH user.
[FW] ssh user sftpadmin_a sftp-directory hda1:
Step 3 Configure the administrator PC.

1. Set the IP address and subnet mask of the administrator PC to 10.3.1.100/255.255.255.0.
3. Use the PuTTY to log in to FWthrough SFTP (the following uses PuTTY0.60 as an
example).
b. Choose Connection > SSH in the left Category navigation tree. The interface
shown in Figure 1-59 is displayed. In the Protocol options area, set Preferred
SSH protocol version to 2.

Figure 1-59 Setting the SSH protocol version
c. Select Auth in SSH. The dialog box shown in Figure 1-60 is displayed. Click
Browse, import the private key file private.ppk in the saved RSA key pair.

Figure 1-60 Importing the private key in the RSA key pair
d. Click Session, enter ssh-rsa in the Saved Sessions text box, and click Save to save
the SSH session, as shown in Figure 1-61.
NOTE
The saved session will be used in the SFTP login using the PSFTP tool. Besides, no
configuration is required for future STelnet login. You can double-click the SSH session to
open the login page.

Figure 1-61 Importing the private key in the RSA key pair
e. Double-click PSFPT.exe, enter open ssh-rsa and press Enter (ssh-rsa is the name
of the saved PyTTY session), and then enter SSH administrator account
sshadmin_b and press Enter. You can access the file directory on FW, as shown in
Figure 1-62.
Figure 1-62 SFTP login page
Step 4 Download files from the FW.

Figure 1-63 Downloading files from the FW
----End
#
sysname FW
#
rsa peer-public-key key_pc encoding-type openssh
public-key-code begin
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBwsFDGbVAbK35ecJqsioQ3BdTCa1+eU3i13YQBHvBltI
dI
9bOMKYEYJbjuY4UYXkdtwA2ar6LWTI8X1hHbtYGqPk2MvjSF0hXn1DBabNUXbLRyzWAhaopcsTbGbo
U8
8cQ6fe/DqE9jUpNLsPdg4EXz1LMyLNe134JCSe3Ufh7o/w== rsa-key
public-key-code end
peer-public-key end
#
aaa
manager-user sftpadmin_a
service-type ssh
level 3
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
sftp server enable
ssh user sftpadmin_a
ssh user sftpadmin_a authentication-type rsa
ssh user sftpadmin_a assign rsa-key key_pc
ssh user sftpadmin_a service-type sftp
ssh user sftpadmin_a sftp-directory hda1:
ssh user sftpadmin_a authorization-cmd aaa
#

protocol inbound all

#
security-policy
rule name policy_sftp
source-zone trust
service ssh
action permit
1.14.5.6 Example for Downloading Files from the TFTP Server

This section describes how to download files from the TFTP server using the FW as the TFTP
client.
As shown in Figure 1-64, the IP address of the TFTP server is 10.111.16.160/24. Log in to
the FW through PC and download test.cc from the TFTP server.
NOTICE
Figure 1-64 Networking diagram of downloading files from the TFTP server
TFTP Server FW PC
Item Data
Path of the source file on the TFTP server test.cc
Name of the target file and storage path on hda1:/test.cc

the device
The configuration roadmap is as follows:
1. Start the TFTP software on the TFTP server and set the location of the source file on the
server.
2. Use the tftp command to download the file to the FW.

Procedure
Step 1 Start the TFTP server. Specify the directory where test.cc resides as the base directory. Figure
1-65 shows the window.
Figure 1-65 Setting the base directory of the TFTP server
NOTE
The display varies with the TFTP server software running on the PC.
Step 2 Log in to the device through the PC and run the following commands to download the file:
<FW> tftp 10.111.16.160 get test.cc hda1:/test.cc
Transfer file in binary mode.
Now begin to download file from remote tftp server, please wait for a while...
\
TFTP: 86235884 bytes received in 42734 second.
TFTP: 15805100 bytes received in 42734 second.
File downloaded successfully.
----End
Verification
Check whether the downloaded file is in the specified directory of the device.
<FW> dir hda1:
Directory of hda1:/
0 -rw- 86211956 Jun 08 2009 15:20:14 test.cc
1 -rw- 40 Jun 24 2009 09:30:40 private-data.txt
2 -rw- 396 May 19 2009 15:00:10 rsahostkey.dat
3 -rw- 540 May 19 2009 15:00:10 rsaserverkey.dat
4 -rw- 2718 Jun 21 2009 17:46:46 1.cfg
5 -rw- 14343 May 19 2009 15:00:10 paf.txt
6 -rw- 1004 Feb 05 2009 09:30:22 vrp1.zip
7 -rw- 6247 May 19 2009 15:00:10 license.txt
8 -rw- 14343 May 16 2009 14:13:42 paf.txt.bak


This section describes the versions and changes in the file system feature.
1.15 Configuration File

This section describes how to save, back up, and remove a configuration file as well as
conduct a comparison between configuration files.
1.15.1 Overview
A configuration file defines the configuration items required for the startup of the FW. You
can save a configuration file on the device, modify and remove existing configuration files,
and specify the configuration file for the FW to load upon each startup.
Current Configuration
The current configuration is the configuration currently takes effect, not the configuration file.
A configuration file is generated only after you save the current configuration.
Configuration File
The configuration file is saved as a .txt file, and the requirements on its content are as follows:
l The configuration file is saved in commands.
l Only non-default parameters are saved. You can find the default value of each parameter
in relevant chapters of this document.
l Commands are organized by views. The commands available in the same view are listed
together to form a section, and adjacent sections are separated by a blank line or
comment line which starts with a number sign in a pair of square brackets ([#]). The
number of blank lines or comment lines can be one or more.
l Sections are usually arranged in the order from global configuration, physical interface
configuration, logical interface configuration, to routing protocol configuration.
NOTE
In a configuration file, the command that can be identified by the system must be a string of no more
than 510 characters. Directly modifying the configuration file may cause certain commands in the
configuration file to have more than 510 characters. Therefore, perform the operation with caution.
Concepts related to the configuration file are the configuration file for this startup,
configuration file for the next startup, and configuration file for disaster recovery.
l startup saved-configuration file
Indicates the configuration file for this startup.
l next startup saved-configuration file
Indicates the configuration file to be loaded for the next startup.

Related Operations
To manage configuration files, do as follows:
l Save current configurations to a configuration file.

l Clear a configuration file.
l Display the details on the configuration file for the next startup.
l Specify a configuration file for the next startup.
1.15.2 Managing Configuration Files Using the Web UI

This section describes how to use the Web UI to manage configuration files.
Restoring the Factory Defaults

You can restore the device to the factory default settings. The restoration exerts no impact on
saved configuration files. Before the restoration, you can determine whether to back up the
current configurations on the device.
NOTICE
Restore the factory configuration will reboot the device.
Step 1 Choose System > Configuration file Management.

The information displayed in Current Configuration is the current configurations of the FW.
Step 2 Click Restore Factory Settings.
Step 3 Optional: Back up the current configurations.

1. Select Back Up the Current Configuration File.
2. In File Name, enter the file name including the file name extension of the backup
configuration file.
Step 4 Click OK, and the device reboot and restore the factory defaults.
----End
Updating Configuration File

This operation has two steps:
1. Upload the configuration file to the firewall. Ensure that the firewall has enough storage
space. If not, delete unneeded files.
2. Specify the startup configuration file.
The configuration file name extension must be .zip or .cfg, and the file name cannot contain
Chinese.
Step 2 Click Select. The Configuration File Management dialog box is displayed.

Step 3 Click Upload. The Upload File dialog box is displayed.
Step 4 Click Browse and select the configuration file to be uploaded.
Step 5 Click Import to upload the configuration file.

After the configuration file is successfully uploaded, return to the Configuration File
Management page. The corresponding file is displayed in the list.
Step 6 Click to configure the current file as the startup configuration file.
The configuration takes effect only after the firewall is restarted.
----End
Displaying Configuration
You can display a maximum of 2000 configuration messages. To view more configuration
information, you must export the configuration information.
Step 2 Under Current Configuration, click Advanced Search, select search conditions on the
Query Condition dialog box, and click Search.
Filter Type l all: Display all configuration information.

l configuration: Display the configuration
information of a specified function module.
l interface: Displays the configuration of all
interfaces or a specified interface
Module This option is available only when the Filter Type is

configuration.
Interface This option is available only when the Filter Type is

interface. You can specify all or an interface number.
Matching Type Specify the position of the keyword.

l all: Display all configuration information.
l begin: Display the configuration information that
starts with the keyword.
l exclude: Display the configuration information
that does not contain the keyword.
l include: Display the configuration information
that contains the keyword.
Matching Keyword This option is unavailable when Matching Type is

all.
----End

Backing Up the Current Configurations

You can back up the current configurations of the FW to the terminal.
The file name extension of a configuration file can be .zip or .cfg.
Step 2 Click Export in Current Configuration.
Step 3 Click Save and select a path on the terminal to save the configuration file.
----End
Comparing Configurations
You can compare the current configurations with the configurations saved in configuration
files.
Step 2 Click Compare in Current Configuration.

The differences between the configurations are displayed in Differences Between the
Current Configurations and the Contents in the Configuration File.
----End
Saving the Current Configuration

NOTE
By default, only the system administrator has the configuration saving permission. If a non-system
administrator needs to save configuration, contact the system administrator for the permission.
You can save the current configurations on the FW.
The file name extension of a configuration file can be .zip or .cfg.
Step 2 Click Save in Current Configuration.
Step 3 Select Overwrite configuration file for next startup or Save as.
If you select Save as, enter a new file name.
----End

This section describes the versions and changes in the configuration file management feature.
The first version.

1.16 System Upgrade

You can upgrade the system or install patches.
1.16.1 Overview
This section describes basic concepts about the system software, patch files.
1.16.1.1 System Software

Administrator can change system software to upgrade device.
If no system software is specified for the startup or the file path or name is incorrectly
configured, the device cannot be normally started.
System software must be stored in the root directory of the device.

l The root directory of the USG6000V is hda1, and the system software is a .bin file.
During the device upgrade, replace system software and set the system software file for the
next startup. Then restart the device to make new configurations take effect.
1.16.1.2 Patch Management

You can install patches to improve system functions.
Patch Overview
During the operation of the device, you need to revise the system software sometimes such as
remove the system defects or add new functions for service requirements. We used to upgrade
the software after shutting down the system. This static upgrade affects the service on the
device and does not improve the communication. If we load a patch to the system software,
we can upgrade it online without interrupting the operation of the device. This dynamic
upgrade does not affect the service and can improve the communication.
Patch Area
In the memory of the Main Processing Unit (MPU) and Line Processing Unit (LPU), a certain
space is reserved to save the patch. This space is called patch area.
To install the patch, save the patch to the patch area in advance in the memory of the board.
The patch saved in the patch area is numbered uniquely. Up to 200 patches can be saved to the
patch area in the memory of the MPU or LPU.
Patch States
Patch status can be idle, deactivated, activated, and running. For details, see Table 1-56,

Table 1-56 Patch states
State Description States Conversion
Idle The patch file is not loaded to the When the patch is loaded to the patch
patch area in the memory. area, the patch status is set to
d deactivated.
Deactivated The patch is loaded to the patch The patch in the deactivated state can
area but disabled. be as follows:
l Uninstalled, that is, deleted from
the patch area.
l Enabled temporarily and turns to
the active state.
Activated The patch is loaded to the patch The patch in the activated state can be
area and enabled temporarily. as follows:
If the board is reset, the active l Uninstalled, that is, deleted from
patch on that board turns to the the patch area.
deactivated state. l Disabled and turns to the
deactivated state.
l Enabled permanently, and turns to
the running state.
Running The patch is loaded to the patch The patch in the running state can be
area and enabled permanently. uninstalled and deleted from the patch
If the board is reset, the patch on area.
the board keeps in the running
state.
Figure 1-66 shows the conversion between patch states.
Figure 1-66 Conversion between the statuses of a patch
Load
Idle Deactivated
Delete
Delete
Delete Active Deactive
Running Activated
Run

Patch Functions
Installing patches can improve system functions or fix bugs. By installing a patch, you can
upgrade the system without upgrading the system software.
In some special scenarios, you can install patches specific to an MPU or LPU to optimize
board functions.
Logic Relationships Between Configuration Tasks

Figure 1-67 shows the logic relationships between the configuration tasks.
Figure 1-67 Logical relationships between configuration tasks

Resort to
Run the system technical
software support for
new patch
No Enable patch No
Normally run Bug removed Disable patch
temporarily
Yes Yes
End Unload patch
1.16.2 Upgrading the System Using the Web UI

This section describes how to manage the signature database using the Web UI.
Viewing System Version Information

Step 1 Choose System > System Upgrade.
The Current Version is the system version information. For detailed information, click
Details on the right.
----End
Upgrading System Software

Perform the following two steps to upgrade the system software:
1. Upload the system software to the . Ensure that the free storage space is sufficient on
the . If the space is insufficient, delete unnecessary files first.

2. Specify the system software for the next startup.

The extension name of a system software file is .bin. The software file name cannot contain
any Chinese characters.

Step 2 Click Select. The System Software Management window is displayed.
Step 3 Click Upload. The Upload File window is displayed.
Step 4 Click Browse. Select the system software to be uploaded.
Step 5 Click Import to upload the system software.
After the system software is uploaded successfully, return to the System Software
Management page, and the new system software file is displayed in the list.
Step 6 Click to set the current file as the system software for the next startup.
The upgraded system software can be used only after you restart the .
----End
One-Touch Upgrading the System Software

If the free storage space on the is insufficient, the automatically deletes the system software
that is running.
The extension name of a system software file is .bin. The software file name cannot contain
any Chinese characters.

Step 2 Click One-Touch Version Upgrade. The One-Touch Version Upgrade wizard is displayed.
Step 3 Optional: Click the Export buttons in sequence to export the alarm information, log
information, and configuration information about the to the terminal.
Step 4 Optional: Click Save to save the current system configuration information.
You are advised to save the current system configuration information to the terminal.
Step 5 Click Browse and select the system software to be uploaded.
Step 6 Select Restart the system now or Do not restart the system according to whether the
current network allows the device to restart immediately after system upgrade.
Step 7 Click Next. The device automatically starts to upgrade the system software.
The upgraded system software can be used only after you restart the .
----End
Installing a Patch File

You can upgrade the system software without interrupting system running by installing
patches. A can have multiple patch files, but only one of them is loaded in the system. To load
a new patch file, you must uninstall the loaded one first.
The extension name of a patch file is .pat. The patch file name cannot contain any Chinese
characters.

Step 2 Click Select. The Patch Document Management window is displayed.
Step 3 Click Upload. The Upload File window is displayed.
Step 4 Click Browse. Select the patch file to be uploaded.
Step 5 Click Upload to upload the patch file.

After the patch file is successfully uploaded, return to the Patch Document Management
window. The patch file is displayed in the list but is in idle state.
Step 6 Click of the patch file in idle state and click Yes in the dialog box that is displayed to
upload, activate, and run the patch file.
----End
One-Touch Installing a System Patch File

You can upgrade the system software without interrupting the system running by one-touch
system patch file installation. A can have multiple patch files, but only one of them is loaded
in the system. To load a new patch file, you must uninstall the loaded one first.
The extension name of a patch file is .pat. The patch file name cannot contain any Chinese
characters.
Step 2 Click One-Touch Patch Upgrade. The One-Touch Patch Upgrade wizard is displayed.
Step 3 Click Browse. Select the patch file to be uploaded.
Step 4 Click Upgrade. The patch file is automatically installed.
----End
1.16.3 Upgrading the System Using the CLI

This section describes how to upgrade the system using commands.
1.16.3.1 Upgrading System Software

To upgrade the device, you can specify system software to be loaded for the next startup of
the device.
Context
To upgrade the system software of the USG6000V, you only need to load the system
software.
Procedure
Step 1 Configure the FW to load the system software upon the startup of FW.
startup system-software system-file
Step 2 In the user view, save the configurations.

save
Step 3 In the user view, check the running and startup systems and configuration files.
display startup
Step 4 In the user view, restart the device.

reboot
----End
1.16.3.2 Patch Management

Patch management covers checking patches on the current device, uploading patch files, and
patching the system.
Checking Whether Any Patch Is Running in the System

You need to confirm no patch is running in the current system before installing a patch. If a
patch runs, delete the patch before installing the new patch.
Step 1 View patch information.

display patch-information
All the information about the current patch is displayed, including information about the patch
units that are running, the patch units that are activated, and the patch units that are
deactivated.
If there are patches running, you must delete them before loading new patches.
Step 2 Optional: Delete the current patch.
patch delete all
----End
Loading a Patch
Upload the patch file to the root directory of the MPU before you install a patch.
Step 1 Upload the patch file to the root directory of the active MPU.
The FW supports FTP, TFTP, or SFTP.
NOTE
You are advised to use SFTP to upload the patch file as SFTP is more secure than FTP and TFTP.
Step 2 Check the files on the active MPU.

dir
----End
Patching the System

Make the uploaded patch file take effect.
l Load, activate, and run the patch to apply the patch in the running system.
l Specify the patch files to run after the system restart.

l Apply the patch file in a running device.

a. Load the patch.
patch load file-name all
The system checks whether the patch version is consistent with the system software
version when the patch is loaded. If they are inconsistent, the system displays a
message indicating a patch loading failure.
After the patch is loaded, the patch is still in the deactivated state, even after the
MPU is restarted.
b. Activate the patch.
patch active all
Only patches that are loaded and in the deactivated state can be activated. The
patches take effect after being activated. However, if the MPU is restarted, the
patches will go back to the deactivated state.
c. Run the patch.
patch run all
You can run the patch successfully only when the patch file has been activated.
After the patch is run, the patch will be running even after the MPU is restarted.
d. View the patch information.
display patch-information [ history ]
l Restart the device to apply the patch.

a. Specify the patch file that will take effect upon device restart for the active MPU.
startup patch file-name
b. View information about the patch file that will take effect upon device restart.
display startup
c. Restart the FW.

reboot
After the FW is restarted, the patch is in the running state. That is, the patch is
permanently active. During FW restart, the patch state is automatically synchronized to
the standby MPU.
----End
Uninstalling the Patch

Uninstall the patch that is no longer required.
NOTE
l The patch in any state can be deleted.

l The patch that has been deleted must be reloaded to take effect.
Step 1 Deactivate a patch.

patch deactive all
Step 2 Delete a patch from the system.

patch delete all
----End


This section describes the versions and changes in the System Upgrade.

100
1.17 System Restart

You need to restart the system if the device works improperly or needs to be upgraded or to
replace the startup file.
1.17.1 Overview
After you upgrade the system or load a host program or after an anomaly occurs in the
system, you need to restart the system.
You may need to restart the FW in the following cases:
l Upgrading the system.

l Loading the host program.
l The FW works improperly.
Restarting the FW interrupts services. Therefore, select off-peak hours in non-emergent cases,
such as in the early morning, to restart the FW.
You can restart the FW in either of the following modes:

l Immediate system restart
You need to run a certain command or power off the device to restart the system.
l Scheduled system restart
The FW allows you to restart the system at a scheduled time. You can set the time for
system restart in either of the following ways:
– Specify a specific time point for the FW to restart. For example, the FW
automatically resets the system at a specific time, such as 2:30 am.
– Specify a specific duration as the delay before the FW restarts. For example, the
FW automatically restarts after a specific time period, such as three hours later.
– Only configure this function by CLI .
Upon the restart, the FW loads the startup configuration file specified before the restart.
1.17.2 Upgrading the System Using the Web UI

This section describes how to use the Web UI to restart the system.

Context
NOTICE
l If the FW works improperly, try to rectify the fault. Do not restart the system frequently in
case that services are affected.
l If you must restart the system, select off-peak hours in non-emergent cases, such as in the
early morning.
l Restarting the FW may result in temporary data loss. Before the restart, make sure that the
configuration data is backed up.
You are advised to back up the configuration file in use before you restart the system.
Procedure
Step 1 Choose System > Setup > Restart.
Step 2 Select either of the following to restart the system.
l Click Save and Restart to save the configuration and restart the system.
l Click Restart to restart the system without saving the configuration.
----End

This section describes the versions and changes in the System Restart.

100
1.18 User Experience Plan

This section describes the content of the user experience plan.
Context
The user experience plan sends the data information collected by the FW to the data feedback
server for it to validate the signatures, reduce false positives, identify threat relationship, and
sense network threat status.
Procedure
Step 1 Choose System > Support.
Step 2 Select Enable for User Experience Plan and click Apply to enable the data feedback
function.

After the data feedback function is enabled, the FW will collect network threat information
and service statistics and sends them to the data feedback server. The data feedback server can
then analyze the data information to improve the threat prevention capability of the FW.
Table 1-57 lists the data that may be collected in data feedback.
Table 1-57 Data that may be collected in data feedback

Type Content Purpose
Threat log Threat detection time, threat type, To optimize IPS and antivirus
threat number, threat name, attack signatures and reduce false
source IP address and port, positives.
application-layer protocol type,
transport-layer protocol type,
country name and country code of
the attack source, and country
name and country code of the
attack target
Virus file Application-layer protocol type, To optimize IPS and antivirus

information IP-layer protocol type, attack signatures and reduce false
source IP address and port, file positives.
size, file type, file MD5, virus
detection time, virus name, threat
type, engine version, virus
signature database version, and
virus signature number
IPS engine IPS engine version, IPS signature To analyze the IPS engine
operating status database version, operating time, operating status and improve
current number of sessions, performance.
number of user-defined IPS
signatures, and engine ID
Device Product name, product version, To add supplementary

information ESN, and country/region code of information.
the device (set by the
administrator)
NOTE
To ensure that you can properly use the device, determine whether to enable the data feedback function
on the engine side. The data feedback function may collect network threat information and service
statistics on the device and sends them to the data feedback server for analysis so that the threat
prevention capability of the device can be improved. This function may involve transferring or
processing users' communication contents or personal data. Huawei Technologies Co., Ltd. alone is
unable to transfer or process the content of users' communications and personal data. It is suggested that
you activate the user data-related functions based on the applicable laws and regulations in terms of
purpose and scope of usage. You are obligated to take considerable measures to ensure that the content
of users' communications and personal data are fully protected when the content is being transferred and
processed.
----End

1.19 NQA
This chapter describes the Network Quality Analysis (NQA) mechanism, testing scenarios,
and general parameters and provides examples for configuring NQA.
1.19.1 Overview
The NQA function measures the performance of various protocols running on networks to
ensure that administrators can collect various network running indicators.
1.19.1.1 NQA
NQA tests the performance of various protocols running on networks and serves as an
effective tool for diagnosing and locating network faults.
Introduction to NQA
With the improving requirements regarding the QoS, especially after traditional IP networks
bear voice and video services, Service Level Agreements (SLAs) are commonly signed
between broadband service providers and their subscribers.
To ensure the committed bandwidth stated in the SLA, broadband service providers require
statistics on various network parameters, such as delay, jitter, and packet loss ratio and learn
about the performance status of the network in time. The NAQ function delivered by the FW
fulfills the requirements.
NQA measures the performance of various protocols running on networks to ensure that
broadband service providers can collect various network parameters in real time, for example,
the measurement of total HTTP latency, TCP latency, file transmission rate, and FTP latency.
Through network management based on these parameters, broadband service providers
provide users with services of different levels at different costs.
Comparison Between the NQA and Ping

NQA expands and enhances the Ping function.
Ping tests the round trip time of the Internet Control Message Protocol (ICMP) packet
between the local end and specified destination end. The NQA not only delivers the previous
function but also detects whether the TCP, UDP, DHCP, FTP, HTTP, and SNMP services are
enabled and tests the response time of these services. Figure 1-68 shows the networking
diagram for NQA tests.
Figure 1-68 Networking diagram for NQA tests

Server
IP/MPLS
Network
NQA Client

The information about the round trip time of each packet or whether the transmission of a
packet times out is not displayed on the console terminal in real time. You can run the display
nqa results command after the test to view the test result.
You can set the parameters of all NQA operations on the NMS and start the test.
1.19.1.2 NQA Server and NQA Client

The NQA function is implemented in client/server mode. To perform NQA tests, you need to
create proper NQA instance beforehand.
NQA Instance and NQA Client

You can perform multiple NQA tests of different types. However, each test requires an
individual NQA instance, and each instance applies to only one test type.
You need to create NQA instances on NQA clients. Each instance is identified by the
administrator who creates the instance and an operation tag.
In an instance view, you need to configure test parameters for related test. Note that not all
parameters apply to every test type.
NQA Server
For most tests, you need to configure only the NQA clients. For TCP, UDP, and Jitter tests,
however, you must configure the NQA server.
The NQA server processes the test packets from the clients. As shown in Figure 1-69, the
NQA server responds to the test request packet initiated by the client through the listening on
a specific port.
Figure 1-69 Relationship between the NQA client and the NQA server
IP/MPLS
Network
NQA Client NQA Server
You can create multiple TCP or UDP listening services on an NQA server. Each listening
service maps a specific destination address and a port. You can specify the same destination
address and port for multiple services.
Performing NQA Tests

After you specify the destination address and port, the NQA server can respond to test request
packets from the client. The IP address and port number specified on the server must be the
same as those configured on the client.

After creating an instance and configuring related test parameters, start the NQA test by
running the start command, and then run the display nqa results command to view the test
result.
1.19.2 Mechanism
For an NQA test, both the NQA client and NQA server are involved. The NQA client sends
test requests to the server to initiate the an NQA test. You can use commands to configure
NQA instances or configure the NMS to send relevant configuration instructions to the FW.
Then, the NQA module on the FW places configured NQA instances into proper test queues
for scheduling.
You can immediately start an NQA instance after it is configured or delay the start for a
period of time, or you can set a specific time point in the future for the NQA instance to
automatically start. After an NQA instance starts, test packets are generated based on the test
type of the instance. If the packet size specified during the configuration of the instance is
smaller than the required minimum size of the packets transmitted through the tested protocol,
the minimum packet size takes effect.
After receiving the test request packet from the client, the NQA server returns a response
packet. Then the client timestamps the received response packet with the current local system
time and sends the packet back to the NQA server. After receiving another response packet
from the server, the client calculates the round-trip time (RTT) of the packet.
NOTE
For a Jitter test instance, both the client and the server timestamp the packet with the local system time
of their own. In this way, the client can calculate the jitter time of the packet.
Based on the RTT of the packet, you can learn about the running status of the tested packet.
HTTP Test
An NQA HTTP test is used to test the response speed in three phases. Figure 1-70 shows
these phases.
l DNS resolution: It is the time for the client to receive a DNS resolution packet
containing an IP address after it sends a DNS packet to the resolver for domain name
resolution.
l Setting up a TCP connection: It is the time for the client to set up a TCP connection with
the HTTP server through a three-way handshake.
l Transaction: It is a period from the time at which the client sends a Get or Post packet to
the HTTP server to the time at which a response packet sent by the client reaches the
HTTP server.
Through an HTTP test, the following items can be calculated based on the information in the
packets received by the client:
l Minimum, maximum, and total time for DNS resolution

l Minimum, maximum, and total time for setting up a TCP connection
l Minimum, maximum, and total HTTP transaction time
You can use these statistics to assess HTTP performance over the network.

Figure 1-70 Applicable scenario of the HTTP test

server.com
10.2.1.1/24
IP Network
10.1.1.1/24
DNS Server
10.3.1.1/24
DNS Test
A DNS test is used to test the DNS resolution speed. The DNS test uses UDP packets. Figure
1-70 shows the process of a DNS test.
1. The client sends a query packet to the DNS server for domain name resolution.
2. After receiving the query packet, the DNS server returns a response packet to the client.
3. After receiving the response packet, the client calculates the time for DNS resolution
based on the time between the sending of the query packet and the receiving of the
response packet on the client. You can use the test result to assess the DNS performance
over the network.
FTP Test
An FTP test is used to test the response speed of the FTP server when you download a file
from or upload a file to the server. The FTP test uses TCP packets. You can obtain the
response speed in two phases. Figure 1-71 shows the process of an FTP test.
l Setting up and maintaining a control connection: It is the time that the client uses to set
up a TCP control connection with the FTP server through three-way handshake and
interchanges signals through the control connection.
l Setting up and maintaining a data transmission connection: It is the time that the client
uses to download a file from or upload a file to the FTP server through the data
transmission connection.
Through an FTP test, the following items can be calculated based on the information in the
packets received by the client:
l Minimum, maximum, and average time to set up a control connection
l Minimum, maximum, and average time to set up a data transmission connection
You can use these statistics to assess the FTP performance over the network.

Figure 1-71 Applicable scenario of the FTP test

192.168.0.1/24 192.168.0.100/24
GE0/0/0
FTP Client FTP Server
TCP Test
A TCP test is used to test the TCP connection rate between a host and a TCP server through a
three-way handshake. Figure 1-72 shows the process of a TCP test.
1. The client (device A) sends a SYN packet to the TCP server (device B).
2. After receiving the TCP SYN packet, the TCP server accepts the request and responds a
SYN-ACK packet.
3. After receiving the SYN-ACK packet, the client returns an ACK packet to the TCP
server. Then, a TCP connection is established.
The client can calculate the TCP connection rate based on the time between the sending
of the SYN packet and the receiving of the ACK packet on the client. You can use the
test result to assess the TCP performance over the network.
Figure 1-72 Applicable scenario of the TCP test

A B C
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24

NQA Server
UDP Test
A UDP test is used to test the packet transfer rate between a host and a UDP server. Figure
1-72 shows the process of a UDP test.
1. The client (device A) constructs a UDP packet and sends it to the UDP server (device B).
2. After receiving the UDP packet, the UDP server returns the packet to the client.
After receiving the returned packet, the client calculates the packet transfer rate between
the client and the UDP server based on the time between the sending and receiving of the
packet on the client. You can use the test result to assess the UDP performance over the
network.
ICMP Test
An ICMP test is used to test the reachability of the route between the NQA client and NQA
server. The ICMP test is similar to the ping command. However, the output of the test is more
diversified.

l By default, the FW stores the results of the latest five tests.

l The test result contains information about average ICMP latency, packet loss ratio, and
the time at which the last packet is correctly received.
Figure 1-73 shows the process of an ICMP test.

1. The client (device A) constructs an ICMP Echo Request packet and then sends it to the
server (device B).
2. After receiving the ICMP Echo Request packet, the server responds an ICMP Echo
Reply packet.
After receiving the ICMP Echo Reply packet, the client can calculate packet transfer rate
based on the time between the sending of the ICMP Echo Request packet and the
receiving of the ICMP Echo Request Reply packet. You can use the test result to test the
reachability of the route between the client and server.
Figure 1-73 Applicable scenario of the ICMP test
A B
Traceroute Test
A Traceroute test is used to detect the forwarding path between the NQA client and a
destination and collect statistics related to the routers along the forwarding path.Figure 1-74
shows the process of a Traceroute test.
1. The client (device A) constructs a UDP packet and sends the packet to the destination
(device B). The TTL of the packet is 1.
2. After the first-hop router (device C) receives the UDP packet, it checks the TTL field
and finds that the TTL is set to 0. Then, device C returns an ICMP Time Exceeded
packet.
3. After the client receives the ICMP Time Exceeded packet, it obtains the IP address of the
first-hop router and re-constructs a UDP packet. The TTL of this packet is 2.
4. After the second-hop router (device D) receives the UDP packet, it checks the TTL of
the packet and finds that the TTL is set to 0. Then, device D returns an ICMP Time
Exceeded packet.
5. The procedure repeats and after the packet reaches the last-hop router, the router returns
an ICMP Port Unreachable packet to the client.
The client can then obtain the forwarding path from the client to the destination and
collect statistics related to each router along the forwarding path based on the ICMP
packet returned by each hop. You can use this statistics to assess the network
performance.

Figure 1-74 Applicable scenario of the Traceroute test
A B
1.19.3 Setting ICMP Test Parameters

This section describes how to set ICMP test parameters on the NQA client.
Context
Do as follows on the NQA client:
Procedure
system-view
Step 2 Configure an NQA instance and access the NQA instance view.
nqa test-instance admin-name test-name
Step 3 Set the test type to ICMP.

test-type icmp
The default NQA test type is ICMP.
Step 4 Specify the destination IP address.

destination-address ipv4 ip-address
Step 5 Optional: Perform the following as required to set other ICMP test parameters.
l Configure the VPN instance to be tested.
vpn-instance vpn-instance-name
l Specify the source interface that sends test packets.
source-interface [ interface-type interface-number ]
l Specify the source IP address.
source-address ipv4 ip-address

NOTE
If the destination IP address is in a different network segment from the source IP address, you cannot use
this command. Otherwise, the NQA test fails.
l Set the packet TTL value. ttl value
ttl value
ttl equals the -h option in the ping command.
l Set the type of service (ToS) field in the IP packet header.
tos value
tos equals the -tos option in the ping command.
l Configure padding characters.
datafill string
datafill equals the -p option in the ping command.
l Specify the interval for sending test packets.
interval seconds interval
interval seconds equals the -m option in the ping command.
l Specify the percentage of the failed NQA tests.
fail-percent percent
l Configure the number of probes for one time.
probe-count number
l Configure the test period of the NQA test instance.
frequency interval
NOTE
If the following conditions are met, the Completion field in the test results will be displayed as no
result:
– The system CPU usage exceeds 90% and the configured timeout period is less than 6s.
– frequency configured ≤ (probe-count - 1) x interval + 6.
l Configure the NQA client to send test packets without querying the routing table.
sendpacket passroute
Step 6 Start the NQA test.
start
Use one of the following commands as required:

l Start the NQA test immediately.
start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { secondssecond | hh:mm:ss } |
lifetime { secondssecond | hh:mm:ss } ]
l Start the NQA test at a specified time point.
start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay
{ secondssecond | hh:mm:ss } | lifetime { secondssecond | hh:mm:ss } ]
l Start the NQA test after the delay of a specified period.
start delay { secondssecond | hh:mm:ss } [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay
----End

Follow-up Procedure
Run the display nqa results command. If the following output is displayed, the test succeeds.
l testFlag is inactive
l The test is finished
l Completion:success
[sysname] display nqa results
NQA entry(admin, icmp) :testFlag is inactive ,testtype is icmp
1 . Test 1 result The test is finished
Send operation times: 3 Receive response times: 3
Completion:success RTD OverThresholds number: 0
Attempts number:1 Drop operation number:0
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Operation sequence errors number:0 RTT Stats errors number:0
Destination ip address:10.1.1.2
Min/Max/Average Completion Time: 31/46/36
Sum/Square-Sum Completion Time: 108/4038
Last Good Probe Time: 2006-8-2 10:7:11.4
Last Packet Loss 0 %
NOTE
NQA test results cannot be automatically displayed on a terminal. You must run the display nqa results
command to view the test results. The command output contains the test results of only the last five
tests.
1.19.4 Setting DHCP Test Parameters

This section describes how to set DHCP test parameters on the NQA client.
Context
NOTE
You can configure the FW as a DHCP server. For details, refer to 4 Networks.
Procedure
system-view
Step 2 Configure an NQA instance and access the NQA instance view.
Step 3 Set the test type to DHCP.

test-type dhcp
Step 4 Specify the source interface that sends the DHCP request packet.
source-interface interface-type interface-number
The specified source interface can be an Ethernet interface connected to the DHCP server, an
Eth-Trunk interface, or a VLANIF interface.
Step 5 Optional: Run the following commands to configure other parameters for the DHCP test.
l Set the timeout of the NQA test.
timeout time

NOTE
For the DHCP test, the time between the sending of the probe packet and the receiving of the response
packet may last for 10 seconds. By default, the timeout period is 15 seconds. You are advised to set the
timeout period longer than 10 seconds.
l Set the percentage of the failed NQA test items.

start

start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { secondssecond | hh:mm:ss } |
lifetime { secondssecond | hh:mm:ss } ]
start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay
----End
Follow-up Procedure
l Number of disconnections from the server and number of timeout disconnection

operations.
l Number of times the server being busy and number of failed connections.
l Numbers of operations with incorrect sequences and number of packet discards.
l Number of incorrect statistics collections.
<sysname> display nqa results
NQA entry(admin, dhcp) :testFlag is inactive ,testtype is dhcp
1.19.5 Setting the FTP Download Test Parameters

During the FTP download test, the NQA client also serves as the FTP client.

Context
NOTE
If you set the FTP source port, you must set the FTP destination port at the same time. Ensure both ports
are the same.
Do as follows on the NQA client (FTP client):
Procedure
system-view
Step 2 Create an NQA test instance and access the test instance view.
Step 3 Set the test type to FTP.

test-type

Step 5 Optional: Perform the following operations as required to configure other parameters of the
FTP Download test:
l Specify the FTP source port.
source-port port-number
l Specify the FTP destination port.
destination-port port-number
Step 6 Set the FTP operation to GET.

ftp-operation get
The default FTP operation type is Get.
Step 7 Specify the FTP user name.

ftp-username name
Step 8 Specify the FTP password.

ftp-password password
Step 9 Perform the following as required to upload the file.

l To upload the file with a specified name, run the ftp-filename file-name command.

NOTE
– If no file path is specified, the system searches for the file in the current path. If the specified
file name does not exist, a file is created according to the specified file name, and the size of
the file is set to 1 MB.
– The file name cannot contain characters such as ~, *, /, \, ', ", but the file path can contain these
characters.
– The file name can contain the extension name but cannot contain the extension name only,
such as .txt.
l To upload the file with a specified size, run the ftp-filesize size command. The client
then automatically creates a file named "nqa-ftp-test.txt" for the upload.
NOTE
During the FTP test, select a file with a relatively small size. If the file is large, the test may fail
because of timeout.

start

start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds second | hh:mm:ss } |
lifetime { seconds second | hh:mm:ss } ]
start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds
second | hh:mm:ss } | lifetime { seconds second | hh:mm:ss } ]
{ seconds second | hh:mm:ss } | lifetime { seconds second | hh:mm:ss } ]
----End
Follow-up Procedure
l "CtrlConnTime"
l "DataConnTime"
l "SumTime"
NQA entry(admin, ftp) :testFlag is inactive ,testtype is ftp
SendProbe:1 ResponseProb:1
Completion :success RTD OverThresholds number: 0
MessageBodyOctetsSum: 448 Stats errors number: 0
Operation timeout number: 0 System busy operation number:0
Drop operation number:0 Disconnect operation number: 0
CtrlConnTime Min/Max/Average: 438/438/438
DataConnTime Min/Max/Average: 218/218/218
SumTime Min/Max/Average: 656/656/656
1.19.6 Setting the FTP Upload Test Parameters

During the FTP upload test, the NQA client also serves as the FTP client.

Context
NOTE
If you set the FTP source port , set the destination port at the same time. Ensure both ports are the same.
Do as follows on the NQA client (FTP client):
Procedure
system-view
Step 3 Set the test type to FTP.

test-type ftp

Step 5 Specify the source IP address.

Step 6 Optional: Perform the following operations as required to set other parameters for the FTP
upload test:
l Specify the source port.
l Specify the destination port.
Step 7 Set the FTP operation type to PUT.

ftp-operation put
The default FTP operation type is Get.
Step 8 Specify the FTP user name.

ftp-username name
Step 9 Specify the FTP password.

ftp-password password
Step 10 Perform the following operations as required to upload a file.

l Specify the name of a file to be uploaded if necessary. If you specify a file without
specific path, the system searches for the file in the current directory. If no matches are
found, the system constructs a file using the specified file name. The size of the file for
the upload test is 1 MB.
ftp-filename file-name

NOTE
– The file name cannot contain characters, such as ~, *, /, \, ', ", but the file path can contain
these characters.
– The file name can include the file name extension but cannot be the file name extension only,
such as .txt.
l Specify the size of the file to be uploaded if necessary.
ftp-filesize size
The client then automatically creates a file named nqa-ftp-test.txt for the upload.
NOTE
During the FTP test, select a file with a relatively small size. If the file is large, the test may fail because
of timeout.
Step 11 Start the NQA upload test.

start
Select the start modes as required.

start delay { seconds second | hh:mm:ss } [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay
----End
Follow-up Procedure
Run the display nqa results command. If the following items are displayed, the test succeeds.
l "CtrlConnTime"
l "DataConnTime"
l "SumTime"
1.19.7 Setting HTTP Test Parameters

During the HTTP test, the NQA client also serves as the HTTP client.

Context
Do as follows on the NQA client (HTTP client):
Procedure
system-view
Step 3 Set the test type to HTTP.

test-type http

Step 5 Optional: Perform the following operations as required to set other parameters for the HTTP
test:
NOTE
The default destination port is 80.

l Specify the percentage of the failed HTTP tests.
Step 6 Set the HTTP operation type.
http-operation { get | post }
The default HTTP operation type is Get.

Step 7 Specify the name of the web page to be accessed during the test and the HTTP version
http-url deststring [ verstring ]
NOTE
Specify the name of the web page in the http-url deststring [ verstring ] command. Do not use http://
and the domain name. Otherwise, the test may fail.
If the HTTP version is not specified, HTTP1.0 is applied by default. You can set the HTTP version to
HTTP 1.1.

start
Select one of the following operations as required.


----End
Follow-up Procedure
l "DNSRTT"
l "TCPConnectRTT"
l "TransactionRTT and RTT"
NQA entry(admin, http) :testFlag is inactive ,testtype is http
Completions: success OverThresholdsnumber: 0
MessageBodyOctetsSum: 0 TargetAddress: 10.2.2.2
DNSQueryError number: 0 HTTPError number: 0
TcpConnError number : 3 System busy operation number:0
DNSRTT Sum/Min/Max:0/0/0 TCPConnectRTT Sum/Min/Max: 7/2/3
TransactionRTT Sum/Min/Max: 11/3/4 RTT Sum/Min/Max: 18/5/7
DNSServerTimeout:0 TCPConnectTimeout:0 TransactionTimeout: 0
1.19.8 Setting the DNS Test Parameters

During the DNS test, the NQA client also serves as the DNS client.
Context
Do as follows on the NQA client (DNS client):
Procedure
system-view
Step 2 Enable dynamic DNS resolution. By default, the function is disabled.

dns resolve
Step 4 Set the test type to DNS.

test-type dns
Step 5 Specify the IP address of the DNS server.

dns-server ipv4 ip-address

Step 6 Specify the URL of the destination host.

destination-address url urlstring

start

----End
Follow-up Procedure
Run the display nqa results [ admin-name test-name ] command. If the following output is
displayed, the test succeeds.
NQA entry(admin, dns) :testFlag is inactive ,testtype is dns
1.19.9 Setting Traceroute Test Parameters

The output of the NQA traceroute test is more informative than that of the common traceroute
command.
Context
Procedure
system-view
Step 3 Set the test type to traceroute.

test-type traceroute
Step 4 Specify the destination address for the traceroute test.

Step 5 Perform the following operations as required to set other parameters for the Traceroute test:
l Specify the maximum hop failures.
tracert-hopfailtimes
l Specify the initial TTL and the maximum TTLof the test packets.
tracert-livetime first-ttl first-ttl max-ttl max-ttl
l Set the ToS field in the IP packet header.
tosvalue
start
Select one of the following start modes as required.

----End
Follow-up Procedure
Run the display nqa results command. If the statistics of each hop is displayed, the test
succeeds.
NQA entry(admin, trace) :testFlag is inactive ,testtype is trace
Completion:success Attempts number:1
Drop operation number:0
Last good path Time:2006-8-5 14:38:58.5

1 . Hop 1
OverThresholds number: 0
2 . Hop 2
RTD OverThresholds number: 0
1.19.10 Configuring the UDP Test

This section describes how to use the NQA to test the speed for establishing a UDP
connection.
1.19.10.1 Configuring the UDP Server

This section describes how to configure the UDP listening service on the NQA server.
Context
Do as follows on the NQA server:
Procedure
system-view
Step 2 Configure the UDP listening service.

nqa-server udpecho [ vpn-instance vpn-instance-name ] ip-address port-number
NOTICE
The IP address and port listened by the server must be the same as those specified on the
client.
----End
1.19.10.2 Configuring the UDP Client

This section describes how to configure the NQA test on the UDP client.
Context

Procedure
system-view
Step 3 Set the test type to UDP.

test-type udp

destination-address ipv4 ip-address [ lsp-masklen masklen | lsp-loopback loopback-
address ] *
Step 5 Specify the destination port.

Step 6 Optional: Perform the following operations as required to set other parameters for the UDP
test:
l Specify the interval for sending test packets.
interval seconds interval

start

The differences between the UDP Public test and the UDP Private test are as follows:

l For UDP Public tests, connection requests are initiated and sent to UDP port 7. You do
not need to specify the destination port on the client. However, you must configure the
server to listen in on UDP port 7.
l For UDP Private tests, you must specify the destination port on the client and enable the
listening service on the server.
----End
Follow-up Procedure
l Run the display nqa results [ admin-name test-name ] command to view the test results
on the NQA client.
l Run the display nqa-server command to display the information about the NQA server.
NQA entry(admin, udp) :testFlag is inactive ,testtype is udp
1.19.11 Configuring the Jitter Test

This section describes how to configure a UDP jitter test.
1.19.11.1 Configuring the NQA Server for the Jitter Test

This section describes how to configure the UDP listening service on the NQA server.
Context
The jitter time refers to the interval for sending two adjacent packets minus the interval for
receiving the two packets.
The process of a Jitter test is as follows:
1. The client sends packets to the destination at a specified interval.
2. After receiving each packet, the server timestamps the packet and returns it to the client.
3. After receiving the returned packet, the client calculates the jitter time based on the time
subtraction between the interval for sending two adjacent packets and the interval for
receiving the two packets.
You can use the maximum, minimum, and average jitter time calculated based on the
information received on the source to assess network performance.
In a Jitter test, you can set the number of packets to be sent consecutively. Through this
setting, you can simulate traffic of certain types within a short period. For example, you can
set 3000 UDP packets to be sent at an interval of 20 milliseconds for the simulation of G711
traffic.

Procedure
system-view
Step 2 Configure the UDP listening service.

nqa-server udpecho [ vpn-instance vpn-instance-name ] ip-address port-number
Note that the IP address and port listened by the NQA server must be the same as those
specified on the client.
NOTE
To improve the test accuracy, you can configure the Network Time Protocol (NTP) on both the client
and the server.
----End
1.19.11.2 Configuring the NQA Client for the Jitter Test

This section describes how to configure the jitter test on the NQA client.
Context
NOTE
The system supports the collection of the statistics on the maximum unidirectional transmission delay.
Procedure
system-view
Step 3 Set the test type to jitter.

test-type jitter

Step 5 Specify the destination port.

Step 6 Optional: Perform the following operations as required to set other parameters for the Jitter
test:
l Set the number of test packets sent each time.
jitter-packetnum number number

The Jitter test collects statistics on and performs analysis on the transmission delay of the
UDP packets. The system sends multiple test packets for each test to calibrate the
statistics and analysis. The more test packets are sent, the more accurate the statistics and
analysis are. This process, however, is time consuming.
NOTE
The number of the Jitter tests performed depends on the settings in the probe-count command.
The number of test packets sent during each test depends on the settings in the jitter-packetnum
command. During the actual configuration, note that the number of tests being multiplied by the
number of the test packets for each test must be less than 3000.
l Set the interval for sending test packets.
interval { milliseconds interval | seconds interval }
The shorter the interval for sending the Jitter test packets is, the faster the test is
completed. If the interval, however, is set to a very small value, the test result may be
inaccurate.
start

----End
Follow-up Procedure
The configurations for jitter tests are complete.
l Run the display nqa results command to view the test results on the NQA client.
l Run the display nqa-server command to display the information about the NQA server.
If the following output is displayed, the jitter test succeeds.
<sysname> display nqa results test-instance admin jitter
NQA entry(admin, jitter) :testFlag is inactive ,testtype is jitter
SendProbe:100 ResponseProbe:100
Completion :success RTD OverThresholds number:0
OWD OverThresholds SD number:0 OWD OverThresholds DS number:0
Min/Max/Avg/Sum RTT:1/13/2/211 RTT Square Sum:589
NumOfRTT:100 Drop operation number:0


System busy operation number:0 Operation timeout number:0
Min Positive SD:1 Min Positive DS:1
Max Positive SD:1 Max Positive DS:11
Positive SD Number:11 Positive DS Number:22
Positive SD Sum:11 Positive DS Sum:36
Positive SD Square Sum :11 Positive DS Square Sum :154
Min Negative SD:1 Min Negative DS:1
Max Negative SD:1 Max Negative DS:11
Negative SD Number:11 Negative DS Number:20
Negative SD Sum:11 Negative DS Sum:35
Negative SD Square Sum :11 Negative DS Square Sum :157
Max Delay SD:6 Max Delay DS:6
Packet Loss SD:0 Packet Loss DS:0
Packet Loss Unknown:0 Average of Jitter:1
Average of Jitter SD:1 Average of Jitter DS:1
jitter out value:0.1960239 jitter in value:0.5825673
NumberOfOWD:100
OWD SD Sum:10 OWD DS Sum:101
NOTE
If the delay for the source end to send packets is longer than that for the destination end to receive
packets, the jitter is a negative value.
1.19.12 Setting General NQA Test Parameters

This section describes how to set the general NQA test parameters.
Context
Procedure
system-view
Step 2 Create an NQA test instance and access the instance view.
Step 3 Perform the following operations as required to set the general parameters:
l Specify the description of the instance.
description string
l Specify the timeout period of the test.
timeout time
l Specify the number of probe packets sent during each test.
probe-count number
NOTE
The number of probe packets for each test does not apply to FTP and DNS tests.
l Specify the NQA test interval.
frequency interval
l Prohibit packet fragmentation.
set-df
NOTE
The set-df command applies only to traceroute tests.

l Specify the maximum number of test history entries.

records history number
l Specify the maximum number of recorded test results.
records result number
l Set the test aging time.
agetime hh:mm:ss
----End
Follow-up Procedure
The configurations of general NQA test parameters are complete.
l Run the display nqa-agent,to display the configured general parameters on the NQA
client.
<sysname> display nqa-agent
NQA Tests Max:2000 NQA Tests Number: 2
NQA Flow Max:1000 NQA Flow Remained:1000
nqa test-instance a a
test-type pwe3trace
local-pw-id 1
vc-type bgp
nqa status : normal
nqa test-instance a b
test-type icmpjitter
destination-address ipv4 10.1.1.201
source-address ipv4 10.1.1.200
hardware-based enable
ttl 100
tos 100
timeout 20
nqa status : normal
1.19.13 Setting Round-Trip Delay Thresholds

This section describes how to set the round-trip delay threshold on the device where the NQA
test is performed.
Context
Procedure
system-view
Step 3 Specify the round-trip delay threshold for test packets.

threshold rtd value
----End

Follow-up Procedure
l Run the display nqa-agent [ admin-name operation-tag ] [ verbose ] command to
display the configured round-trip delay threshold on the NQA client.
<sysname> diplay nqa-agent test jitter verbose
1 NQA entry(admin, icmp):
test type:icmp current flag:inactive
current status:finished current completion:success
start at : no start time end at : no end time
nqa status : normal
configuration :
test-type icmp
threshold rtd 2
send-trap rtd
1.19.14 Configuring the Trap Function

This section describes how to configure the trap function for an NQA test.
1.19.14.1 Sending Trap Messages When Tests Failed

After the configuration is complete, if an NQA test fails, the FW sends a trap message.
Procedure
system-view
Step 3 Enable the trap function for the FW to send trap messages if a test fails.
send-trap
By default, the trap function is disabled.

Step 4 Specify the number of failed tests that triggers the sending of the trap message.
test-failtimes times
By default, a trap message is sent for each failed test.
----End
1.19.14.2 Sending Trap Messages When Probes Failed

After the configuration is complete, if an NQA test fails, the FW sends a trap message.
Procedure
system-view
Step 3 Enable the trap function for the FW to send trap messages when a probe fails.
send-trap probefailure


Step 4 Configure the number of probe failures that triggers the sending of the trap message.
probe-failtimes times
By default, a trap message is sent for each failed probe.
----End
1.19.14.3 Sending Trap Messages When Probes Are Complete

This section describes how to enable the trap function for the FW to send a trap message after
the NQA test is complete.
Procedure
system-view
Step 3 Enable the trap function for the FW to send a trap message after the NQA test is complete.
send-trap testcomplete
----End
1.19.15 Maintaining NQA

This section describes how to maintain network quality analysis (NQA) by restarting test
cases, clearing statistics, and debugging.
1.19.15.1 Restarting an NQA Test Instance

This section describes how to terminate a running instance by restarting it.
Context
NOTICE
Restarting an NQA test instance interrupts the running of the test.
To restart an NQA test instance, run the following command in the NQA test instance view.
Table 1-58 Restarting NQA test instances

Operation Command
Restart an NQA test instance. restart

1.19.15.2 Clearing NQA Statistics

This section describes how to clear historical statistics in the NQA view.
Context
NOTICE
NQA statistics cannot be restored after you clear them. Therefore, confirm the action before
you use the command.
To clear NQA statistics, run the following command in the NQA view.
Table 1-59 Clearing NQA statistics

Operation Command
Clear the history statistics clear-records

and test result of an NQA
test.
1.19.15.3 Debugging NQA

This section describes how to debug the NQA when a fault occurs.
Context
Before you enable the debugging function, you must run the terminal monitor and terminal
debugging commands in the user view to enable the display of terminal information and
terminal debugging messages, so that the debugging messages can be displayed on the
terminal.
NOTICE
Enabling the debugging affects system performance. Therefore, after debugging, you must
run the undo debugging all command to disable the debugging function.
For details on the debugging commands, refer to the Debugging Reference.

Table 1-60 shows the related operation of debugging NQA.
Table 1-60 Debugging NQA

Operation Command
Debug NQA. debugging nqa


This section provides examples for configuring NQA tests.
1.19.16.1 Example for Performing an ICMP Test

This section provides an example on how to perform an ICMP test on the NQA client to test
whether the peer device is reachable.
As shown in Figure 1-75, FW_A functions as the NQA client to test whether FW_B is
routable.
Figure 1-75 Networking diagram of the ICMP test

FW_A FW_B
GE1/0/1 GE1/0/1
10.1.1.1/24 10.1.1.2/24
NQA agent
1. Perform an ICMP test to check whether the packet sent by FW_A can arrive atFW_B
and obtain the round-trip time (RTT) of the packet.
Procedure
Step 1 Set the IP addresses.
# Set the IP address for the FW_A.
<FW_A> system-view
[FW_A] interface GigabitEthernet 1/0/1
[FW_A-GigabitEthernet1/0/1] ip address 10.1.1.1 24
[FW_A-GigabitEthernet1/0/1] quit
# Set the IP address for the FW_B.

<FW_B> system-view
[FW_B] interface GigabitEthernet 1/0/1
[FW_B-GigabitEthernet1/0/1] ip address 10.1.1.2 24
[FW_B-GigabitEthernet1/0/1] quit
Step 2 Add interfaces to corresponding security zones and configure security policy between security
zones to ensure normal network communication. Details are omitted.
Step 3 Start the NQA client and create an ICMP test.
<FW_A> system-view
[FW_A] nqa test-instance admin icmp
[FW_A-nqa-admin-icmp] test-type icmp
[FW_A-nqa-admin-icmp] destination-address ipv4 10.1.1.2
Step 4 Start the test immediately.

[FW_A-nqa-admin-icmp] start now
----End
Result
[FW_A-nqa-admin-icmp] display nqa results test-instance admin icmp
NQA entry(admin, icmp) :testFlag is inactive ,testtype is icmp
1.19.16.2 Example for Performing a DHCP Test

This section provides an example on how to perform a DHCP test on two adjacent FWs to test
the time for the DHCP server (one of the FWs) to assign an IP address to the other FW.
As shown in Figure 1-76,
l FW_B functions as the DHCP server.
l Performing a DHCP test is required to obtain the time that the DHCP server to assign an
IP address to the client (FW_A).
Figure 1-76 Configuration Roadmap

FW_A FW_B
GE1/0/1 GE1/0/1
10.2.1.1/24 10.2.1.2/24
NQA agent DHCP Server
1. Configure FW_A as the NQA client.
2. Create a DHCP instance and perform the DHCP test on FW_A to check whether FW_A
can set up a connection with FW_B and obtain an IP address from FW_B.
Procedure

<FW_A> system-view

<FW_B> system-view
Step 3 Enable the NQA client and create a DHCP instance.
<FW_A> system-view
[FW_A] undo dhcp enable
[FW_A] nqa test-instance admin dhcp
[FW_A-nqa-admin-dhcp] test-type dhcp
[FW_A-nqa-admin-dhcp] source-interface GigabitEthernet 1/0/1
[FW_A-nqa-admin-dhcp] timeout 20

[FW_A-nqa-admin-dhcp] start now
----End
Result
[FW_A-nqa-admin-dhcp] display nqa results test-instance admin dhcp
NQA entry(admin, dhcp) :testFlag is active ,testtype is dhcp
1.19.16.3 Example for Performing an FTP Download Test

This section provides an example on how to perform an FTP download test on two adjacent
FWs. One FW functions as the FTP server, and the other functions as the FTP client.
As shown in Figure 1-77, FW_A serves as the NQA client, and FW_B serves as the FTP
server. FW_A logs in to FW_B for downloading a test file.
Figure 1-77 Networking diagram of the FTP download test

FW_A FW_B
GE1/0/1 GE1/0/1
10.1.1.1/24 10.1.1.2/24

Item Data
FTP user name and password user name: user1

password: hello@123
Test file of the FTP test test.txt
2. Create an FTP instance and start the test on FW_A to check whether FW_A can set up a
connection with the FTP server and obtain the time that FW_A uses to download the test
file from the FTP server.
Procedure
Step 1 Set IP addresses.
# Set IP address for the FW_A.
<FW_A> system-view
# Set IP address for the FW_B.

<FW_B> system-view
Step 3 Configure FW_B as the FTP server.
[FW_B] ftp server enable
[FW_B] aaa
[FW_B-aaa] manager-user user1
[FW_B-aaa-manager-user-user1] password
Enter Password:
Confirm Password:
[FW_B-aaa-manager-user-user1] level 3
[FW_B-aaa-manager-user-user1] service-type ftp
[FW_B-aaa-manager-user-user1] ftp-directory hda1:/
[FW_B-aaa-manager-user-user1] quit
[FW_B-aaa] quit
Step 4 Create an FTP instance on FW_A.

<FW_A> system-view
[FW_A] nqa test-instance admin ftp
[FW_A-nqa-admin-ftp] test-type ftp
[FW_A-nqa-admin-ftp] destination-address ipv4 10.1.1.2
[FW_A-nqa-admin-ftp] source-address ipv4 10.1.1.1
[FW_A-nqa-admin-ftp] ftp-operation get
[FW_A-nqa-admin-ftp] ftp-username user1

[FW_A-nqa-admin-ftp] ftp-password hello@123

[FW_A-nqa-admin-ftp] ftp-filename test.txt

[FW_A-nqa-admin-ftp] start now
----End
Result
After the test, you can run the display nqa results admin command to view the test result.
[FW_A-nqa-admin-ftp] display nqa results test-instance admin ftp
1.19.16.4 Example for Performing an FTP Upload Test

This section provides an example on how to perform an FTP upload test on the FW.
As shown in Figure 1-78, FW_A serves as the FTP client and tests the speed of uploading a
file to the FTP server (FW_C).
Figure 1-78 Networking diagram of the FTP upload test

FW_A FW_B FW_C
GE1/0/2 GE1/0/1
10.1.1.1/24 10.2.1.1/24
GE1/0/2 GE1/0/2
10.1.1.2/24 10.2.1.2/24
Item Data
FTP user name and password user name: user1

password: hello@123
Name of the test file to be nqa-ftp-test.txt

uploaded

1. Configure FW_A (NQA client) as an FTP client.

2. Create an FTP instance and start the test on FW_A to check whether FW_A can set up a
connection with the FTP server and obtain the time that FW_A uses to upload the test
file to the FTP server.
3. Enter the password to log in to the FTP server to upload a file.
Procedure
# Set IP address for the FW_A.
<FW_A> system-view
# Set IP addresses for the FW_B.

<FW_B> system-view
# Set IP address for the FW_C.

<FW_C> system-view
[FW_C] interface GigabitEthernet 1/0/2
[FW_C-GigabitEthernet1/0/2] ip address 10.2.1.2 24
[FW_C-GigabitEthernet1/0/2] quit
zones. Details are omitted.
Step 3 Configure reachable routes between FW_A and FW_C. The detailed procedure is omitted.
Step 4 Configure FW_C as the FTP server.

[FW_C] ftp server enable
[FW_C] aaa
[FW_C-aaa] manager-user user1
[FW_C-aaa-manager-user-user1] password
Enter Password:
Confirm Password:
[FW_C-aaa-manager-user-user1] level 3
[FW_C-aaa-manager-user-user1] service-type ftp
[FW_C-aaa-manager-user-user1] ftp-directory hda1:/
[FW_C-aaa-manager-user-user1] quit
[FW_C-aaa] quit
Step 5 Create an FTP instance on FW_A and create a 10 KB file for uploading.
<FW_A> system-view
[FW_A] nqa test-instance admin ftp
[FW_A-nqa-admin-ftp] test-type ftp
[FW_A-nqa-admin-ftp] destination-address ipv4 10.2.1.2
[FW_A-nqa-admin-ftp] source-address ipv4 10.1.1.1
[FW_A-nqa-admin-ftp] ftp-operation put
[FW_A-nqa-admin-ftp] ftp-username user1
[FW_A-nqa-admin-ftp] ftp-password hello@123
[FW_A-nqa-admin-ftp] ftp-filesize 10

[FW_A-nqa-admin-ftp] start now
----End
Result
l You can run the display nqa resultsadmin ftp command on FW_A to view the test
result.
[FW_A-nqa-admin-ftp] display nqa results test-instance admin ftp
1 . Test 1 result The test is
finished
SendProbe:1 ResponseProbe:
1
Completion :success RTD OverThresholds number:
0
MessageBodyOctetsSum: 86 Stats errors number:
0
Operation timeout number: 0 System busy operation number:
0
Drop operation number:0 Disconnect operation number:
0
CtrlConnTime Min/Max/Average:
50/50/50
DataConnTime Min/Max/Average:
20/20/20
l On FW_C, you can view that a file named nqa-ftp-test.txt is added.

<FW_C> dir
Directory of hda1:/
0 -rw- 331 Jul 06 2009 18:34:34 private-data.txt
1 -rw- 10240 Jul 06 2009 18:37:06 nqa-ftp-test.txt
2540 KB total (1536 KB free)
1.19.16.5 Example for Performing an HTTP Test

This section provides an example on how to test HTTP response speed on the FW.
As shown in Figure 1-79, the FW connects to the HTTP server through the WAN. Perform an
HTTP test to test the response speed of the HTTP server.
Figure 1-79 Networking diagram of the HTTP test

HTTP Server
10.2.1.1/24
FW
IP Network
GE1/0/1
10.1.1.1/24

1. Configure the FW as the NQA client.

2. Create an HTTP instance and start the HTTP test on the FW to check whether theFW can
set up a connection with the HTTP server and obtain the time for transferring a file
between the FW and the HTTP server.
Procedure
Step 1 Set the IP address.
<FW> system-view
Step 3 Create an HTTP instance on FW.

<FW> system-view
[FW] nqa test-instance admin http
[FW-nqa-admin-http] test-type http
[FW-nqa-admin-http] destination-address ipv4 10.2.1.1
[FW-nqa-admin-http] http-operation get
[FW-nqa-admin-http] http-url www.example.com

[FW-nqa-admin-http] start now
----End
Result
After the test, you can run the display nqa resultsadmin http command to view the test
result.
[FW-nqa-admin-http] display nqa results test-instance admin http
NQA entry(admin, http) :testFlag is inactive ,testtype is http
Completions: failed RTD OverThresholdsnumber: 0
MessageBodyOctetsSum: 0 TargetAddress: 10.2.1.1
DNSQueryError number: 0 HTTPError number: 0
TcpConnError number : 0 System busy operation number:0
DNSRTT Sum/Min/Max:0/0/0 TCPConnectRTT Sum/Min/Max: 0/0/0
TransactionRTT Sum/Min/Max: 0/0/0 RTT Sum/Min/Max: 0/0/0
DNSServerTimeout:0 TCPConnectTimeout:3 TransactionTimeout: 0
1.19.16.6 Example for Performing a DNS Test

This section provides an example on how to perform a DNS test on the FW.
As shown in Figure 1-80, theFW functions as a DNS client and accesses the host at
10.2.1.1/24 using domain name example.com.

Figure 1-80 Networking diagram of the DNS test

server.com
10.2.1.1/24
FW
IP Network
GE1/0/1
10.1.1.1/24
DNS Server
10.3.1.1/24
1. Configure the FW as the NQA client.
2. Create a DNS instance and start the test on theFW to check whether theFW can set up a
connection with the DNS server and obtain the speed that the DNS server responds to an
address resolution request.
Procedure
Step 1 Set the IP address.
<FW> system-view
Step 3 Configure reachable routes between the FW, the DNS server, and the host to be accessed.
(The detailed procedure is omitted.)
Step 4 Create a DNS instance.
<FW> system-view
[FW] dns server 10.3.1.1
[FW] nqa test-instance admin dns
[FW-nqa-admin-dns] test-type dns
[FW-nqa-admin-dns] dns-server ipv4 10.3.1.1
[FW-nqa-admin-dns] destination-address url example.com

[FW-nqa-admin-dns] start now
----End
Result
After the test, you can run the display nqa resultsadmin dns command to view the test
result.

[FW-nqa-admin-dns] display nqa results test-instance admin dns

NQA entry(admin, dns) :testFlag is inactive ,testtype is dns
Destination ip address: 10.3.1.1
1.19.16.7 Example for Performing a Traceroute Test

This section provides an example on how to perform a traceroute test on the FW.
As shown in Figure 1-81, FW_A connects to FW_C through FW_B and serves as the NQA
client. Perform the traceroute test on FW_A to trace the routing path to GigabitEthernet 1/0/1
on FW_C.
Figure 1-81 Networking diagram of the traceroute test

FW_A FW_B FW_C
GE1/0/2 GE1/0/1
10.1.1.1/24 10.2.1.1/24
GE1/0/2 GE1/0/2
10.1.1.2/24 10.2.1.2/24
2. Create a traceroute instance and perform the traceroute test on FW_A to obtain the
statistics on each hop along the path fromFW_A to FW_C.
Procedure
<FW_A> system-view

<FW_B> system-view


# Set the IP address for the FW_C.

<FW_C> system-view
Step 3 Configure reachable routes between FW_A and FW_C. (The detailed procedure is omitted.)
Step 4 Create a traceroute instance on FW_A and set the destination IP address of the test packets to
10.2.1.2.
<FW_A> system-view
[FW_A] nqa test-instance admin trace
[FW_A-nqa-admin-trace] test-type trace
[FW_A-nqa-admin-trace] destination-address ipv4 10.2.1.2

[FW_A-nqa-admin-trace] start now
----End
Result
After the test, you can run the display nqa resultsadmin trace command on FW_A to view
the test result.
[FW_A-nqa-admin-trace] display nqa resultsadmin trace
[FW_A-nqa-admin-trace] display nqa results test-instance admin trace
NQA entry(admin, trace) :testFlag is inactive ,testtype is trace
Completion:success Attempts number:1
Drop operation number:0
Last good path Time:2009-8-5 14:38:58.5
1 . Hop 1
2 . Hop 2
1.19.16.8 Example for Performing a UDP Test

This section provides an example on how to perform a UDP Public test to test the round-trip
time of the UDP packet between two FWs.

As shown in Figure 1-82, FW_A connects to FW_C through FW_B. Start an UDP Public test
to test the round-trip time of the UDP packet transmitted between FW_A and FW_C.
Figure 1-82 Networking diagram of the UDP test

FW_A FW_B FW_C
GE1/0/2 GE1/0/1
10.1.1.1/24 10.2.1.1/24
GE1/0/2 GE1/0/2
10.1.1.2/24 10.2.1.2/24
Item Data
IP address of the NQA server 10.2.1.2/24
UDP service listening port on 6000

the server
1. FW_A functions as the NQA client and FW_C functions as the NQA server.
2. Configure the listening port on the NQA server and create a UDP test instance on the
NQA client.
Procedure
<FW_A> system-view

<FW_B> system-view
# Set the IP address for the FW_C.

<FW_C> system-view

Step 3 Configure reachable routes between FW_A and FW_C. (The detailed procedure is omitted.)
Step 4 Configure FW_C as the NQA server.
# Set the IP address and port that the NQA server listens in on.
<FW_C> system-view
[FW_C] nqa-server udpecho 10.2.1.2 6000
Step 5 Configure FW_A.
# Enable the NQA client and create a UDP Public instance.

<FW_A> system-view
[FW_A] nqa test-instance admin udp
[FW_A-nqa-admin-udp] test-type udp
[FW_A-nqa-admin-udp] destination-address ipv4 10.2.1.2
[FW_A-nqa-admin-udp] destination-port 6000

[FW_A-nqa-admin-udp] start now
----End
Result
After the test, you can run the display nqa resultsadmin udp command to view the test
result.
[FW_A-nqa-admin-udp] display nqa results test-instance admin udp
NQA entry(admin, udp) :testFlag is inactive ,testtype is udp

This section provides NQA references.

This section describes the versions and changes in the NQA feature.
This section provides the specifications of the NQA.

Function Sub-function Supported or Not
ICMP Test - All
DHCP Test - All
FTP Test Upload All
Upload
HTTP Test - All
Traceroute Test - All
DNS Test - All
Jitter Test Test Server All
Test Client
TCP Test Test Server All
Test Client
UDP Test Test Server All
Test Client
Round-Trip - All
Delay Thresholds
1.19.17.3 Standards and Protocols

This section provides NQA-related standards and protocols.
The standards and protocols used for NQA are as follows:
l RFC 1889: RTP: A Transport Protocol for Real-Time Applications

l RFC 2925: Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
Operations
l RFC 2131: Dynamic Host Configuration Protocol
l RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
l RFC 414: FILE TRANSFER PROTOCOL (FTP) STATUS AND FURTHER
COMMENTS
l RFC 1945: Hypertext Transfer Protocol - HTTP/1.0
l RFC 2616: Hypertext Transfer Protocol - HTTP/1.1
l RFC 792: INTERNET CONTROL MESSAGE PROTOCOL
l IEEE 802.1AG DRAFT6.1: IEEE 802.1AG DRAFT6.1
l RFC 792: INTERNET CONTROL MESSAGE PROTOCOL
l RFC 1157: A Simple Network Management Protocol (SNMP)

l RFC 1905: Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)
l RFC 3414: User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)
l RFC793\RFC862: Echo Protocol
l RFC 1393: Traceroute Using an IP Option

Administrator Guide 2 High Availability
2 High Availability
About This Chapter
This section describes what high availability is and how to configure it.
2.1 Hot Standby

Hot standby allows the standby device to take over if the active device fails to ensure service
continuity.
2.2 IP-Link
IP-link, automatic service link reachability detection, detects the status of the links indirectly
connected to the device.
2.3 Link-Group
In link-group, multiple physical interfaces are bound to a logical group to ensure the status
consistency of the interfaces in the group.
2.4 BFD
As an independent hello protocol, BFD implements low-overhead and rapid fault detection.
By interworking with upper-layer protocols, BFD enables them to rapidly identify and recover
from faults.

2.1 Hot Standby

Hot standby allows the standby device to take over if the active device fails to ensure service
continuity.
2.1.1 Overview
This section provides the background and definition of hot standby.
Nowadays, non-stop forwarding (NSF) is becoming increasingly crucial with the exponential
development of such services as mobile office, online shopping, IM, e-finance, and e-
education on networks.
As shown in the left figure in Figure 2-1, the FW is deployed at the enterprise network egress
to forward intranet and extranet service traffic. A single point of failure on the FW will
interrupt services between the intranet and extranet.
Therefore, in network architecture design, key places on the network usually require two
network devices for high availability. As shown in the right figure in Figure 2-1, when one
FW fails, another FW takes over services to ensure service continuity.
Figure 2-1 Networking diagram of device redundancy
Router
Firewall
Switch
Intranet user
Fault
Traffic
For traditional network devices, such as routers and Layer-3 switches, you need only to back
up routes on the two devices to ensure high availability.

FWs are stateful inspection devices that completely check the first packet of each flow and set
up sessions to record packet status information (such as quintuples). Subsequent packets of
each flow can pass FWs only when matching sessions. Therefore, when network devices are
FWs, you need to additionally configure status information (such as sessions) backup.
The hot standby function of the FW perfectly resolves this problem.
As shown in Figure 2-2, the hot standby function provides a dedicated backup channel for
status negotiation and status information and configuration command backup between the
FWs.
Hot standby can be deployed in two modes: active/standby backup and load balancing.
In active/standby mode, as shown in Figure 2-2, the active FW processes services, and the
standby FW stays in standby state. If a fault occurs on the interface or link of the active FW or
the active FW is faulty, the standby FW becomes active and takes over services.
Figure 2-2 Networking diagram of hot standby to prevent service interruption
FTP server FTP server

1.1.1.10/24 1.1.1.10/24
R2 R2
Subsequent packets
The first SYN packet matches the session on
sets up a session on FW_B, and no service
FW_A. interruption occurs.
Session Session
backup backup
FW_A FW_B FW_A FW_B

Active Standby Active Standby
R1 R1 Fault
Heartbeat link
FTP client FTP client Backup traffic

192.168.1.10/24 192.168.1.10/24
Service traffic
As shown in Figure 2-3, load balancing means that two FWs serve as backup for each other
and both process services. When one FW is faulty, the other FW takes over all the services.

Figure 2-3 Load balancing
FTP server Web server FTP server Web server
After active/standby
switchover,
subsequent FTP
R2 R2 and HTTP packets
match sessions on
FW_B, and no
Set up an FTP Set up an HTTP
service interruption
session on FW_A Mutual session session on FW_B Session
occurs.
backup backup
FW_A FW_B FW_A FW_B

Active Active Standby Active
R1 R1
PC1 PC2 PC1 PC2
Fault
Heartbeat link
Backup traffic
FTP traffic
HTTP traffic
2.1.2 Application Scenarios

This section describes the three application scenarios of hot standby.
2.1.2.1 In-line Deployment of Hot Standby

This section describes the in-line deployment of two FWs in hot standby mode.
In in-line deployment, the service interfaces of the two FWs work at Layer 3 and directly
connect to upstream and downstream devices. Routing protocols run between each FW and its
upstream and downstream devices. All service traffic from upstream and downstream devices
pass through the FWs.
l Service interfaces work at Layer 3 and connect to switches.
As shown in Figure 2-4, the service interfaces of the FW work at Layer 3 and directly
connect to switches. Static routes are configured for each FW to communicate with the
routers or PCs connected to the downstream and upstream switches.
This networking scheme is commonly used and recommended for deploying the FW.
The networking scheme applies to small- and medium-sized networks and networks
where the FW functions as a gateway.

Figure 2-4 Networking diagram of in-line deployment when service interfaces work at
Layer 3 and connect to switches
Internet
Switch3 Switch4
Layer-3 Layer-3
interface interface
FW_A FW_B
Layer-3 Layer-3
interface interface
Switch1 Switch2
Intranet
Based on Figure 2-4, you can connect the upstream and downstream interfaces on
FW_A respectively to Switch4 and Switch2 and the upstream and downstream interfaces
on FW_B respectively to Switch3 and Switch1.
In this way, a full redundancy hot standby network is deployed, as shown in Figure 2-5.
Full redundancy hot standby improves network availability and service continuity in case
multiple links fail. For example, when GE1/0/1 and GE1/0/2 on FW_A and GE1/0/1 on
FW_B become faulty, service traffic can be forwarded through GE1/0/2 on FW_B.

Figure 2-5 Networking diagram of full redundancy hot standby
Switch3 Switch4
GE1/0/2 GE1/0/2
GE1/0/1 GE1/0/1
FW_A FW_B
Switch1 Switch2
l Service interfaces work at Layer 3 and connect to routers.

As shown in Figure 2-6, the service interfaces of the FWs work at Layer 3 and directly
connect to routers. The FWs directly connected routers use OSPF to communicate.
This networking scheme is commonly used and recommended for deploying the FW.
The networking scheme applies to large- and medium-sized networks.
You can combine this networking scheme with the networking scheme in which service
interfaces work at Layer 3 and connect to switches. In the new networking scheme,
routers serve as upstream devices, and switches serve as downstream devices.
Figure 2-6 Networking diagram of in-line deployment when service interfaces work at
Layer 3 and connect to routers
Router3 Router4
OSPF
Layer-3 Layer-3
interface interface
FW_A FW_B
Layer-3 Layer-3
interface interface
OSPF
Router1 Router2

2.1.2.2 Transparent Deployment of Hot Standby

This section describes the transparent deployment of two FWs in hot standby mode, with
service interfaces working at Layer 2.
In transparent deployment, the service interfaces of the two FWs work at Layer 2 and connect
the two FWs to upstream and downstream devices in transparent mode. The FWs do not
participate in route calculation. You can directly add them to an existing network without
modifying configurations on upstream and downstream devices.
l Service interfaces work at Layer 2 and connect to switches.

As shown in Figure 2-7, the upstream and downstream service interfaces on the FW
work at Layer 2 and directly connect to Layer-2 switches. The upstream and downstream
service interfaces on each FW are added to the same VLAN.
On this network, the FWs are connected to the original switch network transparently
without changing the network topology.
The service interfaces of the FWs work at Layer 2 and therefore cannot run IP address-
related services, such as VPN.
Figure 2-7 Networking diagram of transparent deployment when service interfaces work
at Layer 2 and connect to switches
Switch3 Switch4
Layer-2 Layer-2
interface interface
FW_A FW_B
Layer-2 Layer-2
interface interface Traffic flow when the
network is normal
Traffic flow when a
fault occurs
Switch1 Switch2
Heartbeat link
l Service interfaces work at Layer 2 and connect to routers.

As shown in Figure 2-8, the service interfaces of the FWs work at Layer 2 and directly
connect to routers. The FWs and their directly connected routers use OSPF to
communicate. The upstream and downstream service interfaces on each FW are added to
the same VLAN.
On this network, the FWs are connected to the original router network transparently
without changing the network topology.
The service interfaces of the FWs work at Layer 2 and therefore cannot run IP address-
related services, such as VPN.

Figure 2-8 Networking diagram of transparent deployment when service interfaces work
at Layer 2 and connect to routers
Router3 Router4
OSPF
Layer-2 Layer-2
interface interface
FW_A FW_B
Layer-2 Layer-2
interface interface
Traffic forwarded by FW1
OSPF Traffic forwarded by FW2
Router1 Router2 Heartbeat link
2.1.2.3 Off-line Deployment of Hot Standby

This section describes the off-line deployment of two FWs in hot standby mode.
In off-line deployment, the service interfaces of the two FWs work at Layer 3 and connect the
FWs to Layer-2 or Layer-3 devices in offline mode.
The off-line deployment has two advantages:
l FWs can be deployed without changing the existing network topology.
l Traffic can be selectively diverted to the FW. That is, only traffic requiring security
check is diverted to the FW. Traffic not requiring security check is directly forwarded by
the device to which the FW is connected.
l The FWs are connected to Layer-3 devices in off-line mode.
As shown in Figure 2-9, two FWs are connected to Layer-3 switches in off-line mode.
Traffic received by the switches can be diverted to the FWs for security checks.

Figure 2-9 Networking diagram for connecting the FWs to Layer-3 devices in off-line
mode
Internet
Heartbeat link
Layer-3 switch
FW_A Switch1 Switch2 FW_B
Intranet
PC
l The FWs are connected to Layer-2 devices in off-line mode.

As shown in Figure 2-10, two FWs are connected to Layer-2 switches in off-line mode.
If the default gateway of intranet hosts is the FW, intranet users' Internet access traffic
will be diverted to the FW for security check.

Figure 2-10 Networking diagram for connecting the s to Layer-2 devices in off-line
mode
Internet
Heartbeat link
Layer-2 switch
FW_A FW_B
PC Intranet
As shown in Figure 2-10, this networking works similarly as the in-line deployment
where the FWs connect to Layer-2 devices.
2.1.3 Mechanism
This section describes the mechanism of hot standby.
2.1.3.1 VRRP
This section describes the basic concepts and problems of Virtual Router Redundancy
Protocol (VRRP).
Basic Concepts
VRRP enables a standby router to automatically replace a faulty active router (default
gateway) to forward packets, ensuring service continuity and availability.

As shown in Figure 2-11, the downstream interfaces of a group of routers on a LAN are
added to a VRRP group. The VRRP group works as a virtual router with its own virtual IP
and MAC addresses. The MAC address is in the format of 00-00-5E-00-01-{VRID}. (The
VRID is the ID of the VRRP group.)
On hosts on the LAN, the default gateway address can be set to the virtual IP address of the
VRRP group. These hosts seem to communicate with the Internet through the virtual router.
The VRRP group status depends on the priority specified by the administrator. The one with
the highest priority is the active group, and others are standby groups.
The VRRP group status determines the status of the router. The router whose VRRP group
status is active is the active router, and the other router is the standby router.
When the active router works properly, hosts on the LAN communicate with extranets
through the active router. When the active router fails, the backup router becomes the new
active router and takes over services.
Figure 2-11 Basic concepts
Router1 Router2
Active Standby
Priority: 110 Priority: 100
Virtual router
(VRRP group 1) GE1/0/1 GE1/0/1
Virtual IP address: 10.1.1.3/24 10.1.1.1/24 10.1.1.2/24
Virtual MAC address: 00-00-5E-00-01-01
Host

Problems
Running VRRP on downstream interfaces ensures gateway availability. What if VRRP runs
on both upstream and downstream interfaces of the gateway?
As shown in Figure 2-12, the downstream interfaces of the two routers (gateways for intranet
and extranet users) are added to VRRP group 1, upstream interfaces are added to VRRP group
2. In normal cases, VRRP groups 1 and 2 of Router1 are both active. Router1 is the active
router in both groups, and all service traffic between the intranet and extranet is forwarded
through Router1.
Figure 2-12 Multiple VRRP groups on one router
PC2
Internet
MAC address Port

Eth0/0/1 00-00-5E-00-01-02 Eth0/0/1
Eth0/0/2
LSW2
VRRP group 2
GE1/0/3 GE1/0/3
Virtual IP address: 1.1.1.1/24
Master Backup
Router1 Router2
GE1/0/1 VRRP group 1 GE1/0/1

Master Virtual IP address: Backup
10.1.1.1/24
LSW1
Eth0/0/2
Eth0/0/1
MAC address Port
Gateway address 00-00-5E-00-01-01 Eth0/0/1
of PC1:
10.1.1.1/24
Intranet
Internet access traffic
Return traffic
As shown in Figure 2-13, if GE1/0/1 on Router1 becomes faulty, VRRP group 1 of Router1
enters the Initialize state, and VRRP group 1 of Router2 enters the active state. Router2
becomes the active router in VRRP group 1 and sends gratuitous ARP packets to LSW1 to
refresh the MAC address entries on LSW1. In this case, packets from PC1 to PC2 (Internet
access packets) are forwarded by Router2. However, the link between Router1 and LSW2 is
normal. Therefore, the status of VRRP group 2 does not change. That is, Router1 is still the
active router in VRRP group 2. Packets from PC2 to PC1 is still forwarded to Router1.

However, Router1 discards the packets because GE1/0/1 is faulty, causing service
interruption.
Figure 2-13 Multiple VRRP groups being independent from each other
PC2
Internet
MAC address Port

Eth0/0/1 00-00-5E-00-01-02 Eth0/0/1
Eth0/0/2
LSW2
VRRP group 2
GE1/0/3 Virtual IP address: GE1/0/3
Master 1.1.1.1/24 Backup
Router1 Router2

Master Virtual IP address: Backup
10.1.1.1/24
LSW1
Eth0/0/2
Eth0/0/1
MAC address Port
Gateway address 00-00-5E-00-01-01 Eth0/0/1
of PC1:
10.1.1.1/24
Intranet
Return traffic
The cause of the problem is that VRRP groups are independent from each other. Status
synchronization cannot be implemented when multiple VRRP groups exist on one device.
2.1.3.2 VGMP
This section describes the mechanism of VGMP and its usage in resolving VRRP problems.
VGMP Resolving VRRP Problems

To ensure the status consistency between VRRP groups, the FW uses VRRP Group
Management Protocol (VGMP) to centrally manage VRRP groups.
All VRRP groups on the FW are added to a VGMP group for centralized status monitoring
and management. When detecting a status change in one VRRP group, the VGMP group

forces all VRRP groups to perform status switchover, ensuring the status consistency between
them.
As shown in Figure 2-14, VRRP groups 1 and 2 on FW_A are active and added to the active
VGMP group. VRRP groups 1 and 2 on FW_B are standby and added to the standby VGMP
group. In this case, FW_A is the active router in VRRP groups 1 and 2 (active device between
the two FWs), and FW_B is the standby router in VRRP groups 1 and 2 (standby device
between the two FWs). Therefore, all upstream and downstream traffic will be diverted to
FW_A.
Figure 2-14 Adding VRRP groups to VGMP groups
PC2
Internet
MAC address Port

00-00-5E-00-01-02 Eth0/0/1
Eth0/0/1 Eth0/0/2

Active 1.1.1.1/24 Standby
VGMP VGMP
FW_A Active Standby FW_B
GE1/0/1 GE1/0/1
VRRP group 1
Active Standby
10.1.1.1/24
Eth0/0/1 Eth0/0/2
MAC address Port
00-00-5E-00-01-01 Eth0/0/1
Gateway
address of PC1:
10.1.1.1/24 Intranet

Return traffic
Heartbeat link
As shown in Figure 2-15, when an interface on FW_A becomes faulty, VGMP forces VRRP
groups to change status as follows:

1. When GE1/0/1 on FW_A fails, VRRP group 1 on it changes from active to initialize.
2. The VGMP group on FW_A senses the fault, decreases its priority, and compares
priority with the VGMP group on FW_B to negotiate active/standby status.
3. After negotiation, the VGMP group on FW_A becomes standby, and the one on FW_B
becomes active.
4. Meanwhile, the VGMP group on FW_A forces its VRRP group 2 to enter the standby
state, and the one on FW_B forces its VRRP groups 1 and 2 to enter the standby state. In
so doing, FW_B becomes the active router in VRRP groups 1 and 2 (active device
between the two FWs), and FW_A becomes the standby router in VRRP groups 1 and 2
(standby device between the two FWs).
5. FW2 sends gratuitous ARP packets to LSW1 and LSW2 to update their MAC address
forwarding tables, so that forward and return packets are forwarded to FW2. In this way,
the status of VRRP groups centrally switches over, preventing service interruption.
Figure 2-15 VGMP resolving VRRP problems
PC2
Internet
MAC address Port

00-00-5E-00-01-02 Eth0/0/2
Eth0/0/1 Eth0/0/2
VRRP group 2 GE1/0/3

1.1.1.1/24 Active
VGMP GE1/0/2 GE1/0/2 VGMP

FW_A Standby Active FW_B
GE1/0/1
GE1/0/1 VRRP group 1
Active
Initialize 10.1.1.1/24
Eth0/0/1 Eth0/0/2
MAC address Port
00-00-5E-00-01-01 Eth0/0/2
Gateway
address of PC1:
10.1.1.1/24
Intranet
Internet access packet

Return packet
Heartbeat link

VGMP Overview
As shown in Figure 2-16, each FW has a VGMP group. Each VGMP group can be in any of
the following statuses:
l Initialize: It is the temporary initial status of a VGMP group after hot standby is
enabled.
l Load Balance: When the priorities of the local and peer VGMP groups are the same,
both VGMP groups are in Load Balance state.
l Active: When the priority of the local VGMP group is higher than that of the peer
VGMP group, the local VGMP group is in Active state.
l Standby: When the priority of the local VGMP group is lower than that of the peer
VGMP group, the local VGMP group is in Standby state.
After two FWs are deployed in hot standby mode, the VGMP groups on them have the same
priority, and both are in Load Balance state. In this case, the two FWs are in load balancing
state.
Figure 2-16 VGMP group in load balance state
FW_A VGMP FW_B

packet
Status: Load Status: Load
Balance Balance
VGMP
packet
You can configure the active/standby status using VRRP configuration or by manually
designate the standby device.
The VRRP configuration method applies to networks where the FW connects to Layer-2
switches, and the manual designation method applies to other networks.
VGMP Group Status Switchover

1. As shown in Figure 2-17, the VGMP groups on the two FWs are in standby state after
being enabled and send VGMP packets to each other to notify their priorities and status.
Figure 2-17 VGMP groups temporarily in standby state after being enabled
FW_A VGMP FW_B

packet
Status: Standby Status: Standby

VGMP
packet

2. As shown in Figure 2-18, after receiving the VGMP packets from the peer ends, the
VGMP groups compare priorities and find that their priorities are the same. Therefore,
both enter the Load Balance state. In this way, the two FWs form a load balancing
network.
Figure 2-18 Two FWs forming a load balancing network
NGFW_A Active VGMP NGFW_B Active

packet
Balance Balance
VGMP
packet
3. As shown in Figure 2-19, you can designate FW_B as the standby device.
FW_A learns about FW_B's standby status from the VGMP packets regularly sent by
FW_B.
Then FW_A is the active device that forwards downstream and upstream traffic. The two
FWs form an active/standby backup network.
Figure 2-19 Performing configurations to enable two FWs to form an active/standby

backup network
hrp standby-device
NGFW_A Active VGMP NGFW_B Standby
packet
Balance Balance
VGMP
packet
4. As shown in Figure 2-20, if a service interface on FW_A fails, the VGMP group on
FW_A decreases its priority by 2.
After priority comparison, FW_A switches to the standby state and immediately sends a
VGMP packet to FW_B to inform its status and priority change.
After receiving the VGMP packet, FW_B performs priority comparison and switches to
the active state.
In this way, FW_B is active, and FW_A is standby. FW_B diverts and forwards
upstream and downstream traffic.

Figure 2-20 Active/Standby switchover when an interface becomes faulty on the active
FW
NGFW_A Standby VGMP NGFW_B Active

packet
Status: Standby Status: Active

If the FW_A (active device) fails, the VGMP group on FW no long sends HRP heartbeat
packets. If the VGMP group on FW_B (standby device) cannot receive HRP heartbeat
reply packets in 5 consecutive attempts, it considers the peer as faulty and switches to the
active state.
5. As shown in Figure 2-21, when a service interface on FW_A (original active device)
recovers from a fault, the priority of the VGMP group on FW_A increases.
The VGMP group on FW_A compares priorities and find that the priority of the VGMP
group on FW_B is the same. If preemption is configured, the preemption delay will be
enabled in this case. After the preemption delay times out, the VGMP group on FW_A
switches to the load balance state and immediately sends a VGMP packet to FW_B to
inform its status and priority change.
After receiving the VGMP packet, FW_B performs priority comparison and switches to
the load balance state.
FW_B is the designated standby device. Therefore, FW_A and FW_B regularly
exchange VGMP packets to confirm each other's identity. That is, FW_A will become
the active device, and FW_B will become the standby device again.
Figure 2-21 Original active FW recovering from a fault and becoming active again
through preemption
NGFW_A Active VGMP NGFW_B Standby

packet
Balance Balance
In conclusion, after VGMP status switchover, the active VGMP group diverts and forwards
traffic. The traffic diversion method varies depending on networks. For details on its
configuration method and mechanism, see 2.1.4 Analysis of Typical Hot Standby Networks.
VGMP Packet Structure

As shown in Figure 2-22, a VGMP packet is encapsulated by a UDP header and a VGMP
header (also called HRP extension header). In this sense, VGMP packets are a type of UDP
packet. They are unicast packets that can be transferred by Layer-3 devices, such as routers.

Figure 2-22 VGMP packet structure
You can define various VGMP and HRP packets by setting the Type field in packet headers:
l VGMP packets: used to exchange VGMP group information and negotiate active/
standby status between two FWs.
l HRP heartbeat packets: used to detect whether the peer device is working.
l HRP data packets: used to back up data, including command line configuration and
status information, between the active and standby devices.
l HRP link detection packets: used to detect whether peer heartbeat interfaces can receive
packets from the local end to determine whether any peer heartbeat interface is available.
l Consistency check packets: used to check whether the two FWs in hot standby mode
have the same policy configurations.
This section describes the VGMP and HRP heartbeat packets. The next section will deliberate
on the rest three types of packets.
The VGMP groups of the two FWs exchange VGMP packets regularly (at one second
intervals). The local VGMP group compares the local information with the peer information
to determine whether the device status is stable and whether a switchover is required.
Besides, VGMP packets are also sent in the following conditions:
l The hot standby function is enabled or disabled.
l The priority increases or decreases.
l The preemption times out.
l Link detection packets time out.
The two VGMP groups regularly exchange VGMP packets. Therefore, both know each
other's priority and status. When an interface or a link of one FW fails, the local VGMP group
priority decreases and compares with the peer VGMP group priority recorded locally. If the
local VGMP group priority is lower, the local VGMP group switches to the standby state and
sends a VGMP packet to the peer to inform its status and priority change.
The Data part of a VGMP packet includes the following contents:
l Whether the local device is busy: If the local device is busy in loading patches or
accelerating policies, it may fail to send heartbeat packets. Therefore, it request the peer
not to switch status for failures in receiving heartbeat packets.

l Whether the local device needs to send gratuitous ARP packets: If the local device has a
VRRP group configured and its status is active, it needs to send gratuitous ARP packets
to upstream and downstream devices to declare its active status and divert and forward
traffic.
l Local VGMP group status
l Priority of the peer VGMP group
l Status designated by the administrator: If hrp standby-device is run on the local device,
the local device is the standby device.
l Whether manual switchover is performed: If hrp switch {active | standby} is run on the
local device, the local device is forced to be the active or standby device. If it is forced to
be the active device, it diverts and forwards traffic; if it is forced to be the standby
device, the peer device diverts and forwards traffic.
VGMP Status Machine
Figure 2-23 VGMP status machine
Active
7 4
2
Load
Initialize 6 5 Balance
0 1
8 3
Standby
As shown in Figure 2-23, the VGMP status machine switches status as follows:
1. After hot standby is enabled, the VGMP group enters the standby state.
2. If the local device is working and finds that the local VGMP group priority is the same
as the peer VGMP group priority (the peer VGMP group is also in standby state), the
local VGMP group switches to the load balance state. If the local device recovers from a
fault and finds that the local VGMP group priority is the same as the peer VGMP group
priority (the peer VGMP group is in active state) and preemption is configured, the local
VGMP group switches to the load balance state from the standby state after the
preemption delay times out.
3. If the peer device fails and the local VGMP group finds that its priority is higher than
that of the peer end, it switches to the active state.

4. If the local device fails and the local VGMP group finds that its priority is lower than
that of the peer end, it switches to the standby state.
5. If the peer device recovers from a fault and has preemption configured, the local VGMP
group finds that its priority is the same as that of the peer VGMP group, it switches to
the load balance state. If the heartbeat link recovers from fault (it can receive heartbeat
packets from the peer), the local VGMP group finds that its priority is the same as that of
the peer VGMP group, it also switches to the load balance state.
6. If the peer device fails or recovers from a fault and the local VGMP group finds that its
priority is lower than that of the peer end, it switches to the standby state.
7. If the peer device fails and the local VGMP group finds that its priority is higher than
that of the peer end, it switches to the active state. If the heartbeat link becomes faulty (it
cannot receive heartbeat packets from the peer), the local VGMP group switches to the
active state.
8. Disable hot standby.
2.1.3.3 HRP
This section describes the mechanism of HRP.
Function
The FW delivers various functions based on the configuration commands on the CLI or web
UI. If the configuration commands are not synchronized to the standby FW before an active/
standby switchover, the standby FW fails to provide required functions, causing service
interruption.
The FW is a stateful firewall. It produces a session entry corresponding to each connection

that is dynamically generated. The active FW generates massive dynamic session entries, but
the standby FW does not because no traffic passes it. If the session entries are not
synchronized to the standby FW before it switches to the active state, it fails to provide
required functions, causing service interruption.
To ensure the smooth failover between two FWs, key configuration commands and session
status information must be synchronized between them in advance.
For this reason, Huawei FW uses Huawei Redundancy Protocol (HRP) to synchronize key
configuration commands and session status information between two FWs.
On active/standby backup networks, the active FW synchronizes its configuration commands

and status information to the standby FW.
On load balancing networks, the two FWs are active. Therefore, if both FWs synchronize
commands to each other, command overwrite or conflict problems may occur. To centrally
manage the configurations of the two FWs, you need to configure the designated active and
standby devices.
On load balancing networks, the sender of the configuration backup command is the
designated active device (identified by HRP_M), and the receiver is the designated standby
device (identified by HRP_S).

Configuration commands can be synchronized only from the designated active device to the
designated standby device, and status information is mutually backed up between the two
devices.
On load balancing networks, the FW with a smaller sysname American Standard Code for
Information Interchange (ASCII) character is the designated active device. For example, when
FW_A and FW_B share load, FW_A is the designated active device.
Mechanism
The FWs exchange HRP data packets to synchronize configuration and status information
through the heartbeat link.
Figure 2-24 shows the HRP data backup process:
1. When sending HRP data packets, FW_A writes the ID of the feature module (ASPF
module in this example) into the usSrcModuleID and ulDstModuleID fields and
encapsulates the feature module configuration and entry information into the HRP data
packets.
2. FW_A sends the HRP data packets to FW_A through the heartbeat link.
3. After receiving the HRP data packets, FW_B sends the configuration and entry
information to the local feature module based on the usSrcModuleID and
ulDstModuleID fields and delivers the configurations and entries.
Figure 2-24 Mechanism
FW_A FW_B
HRP data
packet
Backup tunnel
Configuration and Status Information That Can Be Backed Up by HRP

The FW can back up the following configurations:
l Policies: security, NAT, bandwidth management policies, attack defense, blacklist, and
ASPF
l Objects: address, region, service, application, user, authentication server, time range,
signature, and security configuration profile (such as antivirus and intrusion prevention
profiles)
l Network: new logical interface, security zone, DNS, and IPSec

l System: administrator and log configuration

NOTE
In most cases, display, reset, and debugging commands cannot be backed up.
To conclude, the FW cannot back up basic network configurations, such as interface addresses
or routes. Therefore, you need to configure them before the hot backup status is set up. The
preceding supported configurations need only to be configured on the active FW after the hot
backup status is set up.
The FW can back up the following status information:
l Session table
l Server map
l Static ARP table
l Blacklist
l Whitelist
l PAT-based port mapping table
l NO-PAT-based address mapping table
l Layer-2 forwarding table (static MAC backup)
l AAA user table (default user admin is not backed up)
l PKI certificate, CRL
l IPSec
– IKE and IKEv2 SAs
– Batch tunnel backup
– Real-time backup of tunnels and sequence numbers
Three Backup Methods

HRP supports the following backup methods:
l Automatic backup
By default, automatic backup is enabled on the FW to automatically back up
configuration commands in real time and status information regularly. This backup
method applies to various hot standby networks.
After automatic backup is enabled, any command that can be backed up and that is run
on the designated active device is immediately synchronized to the designated standby
device.
If you run a command that does not support backup on the designated active device, it is
not synchronized to the designated standby device.
On the designated standby device, you can configure only configuration commands that
do not support backup, but not those that support backup.
After automatic backup is enabled, the designated active device can synchronized status
information to the designated standby device regularly but not immediately.
The following types of session cannot be backed up in automatic backup (but can be
backed up in quick session backup):
– Sessions created by traffic destined for the FW, for example, sessions created by
administrator login to the FW

– TCP half-open connection sessions

– Sessions created by UDP first packets but not matching subsequent packets
l Manual batch backup
Manual batch backup needs to be triggered by the configuration of the manual batch
backup command. Such backup starts immediately and applies to scenarios where
manual backup is required when the configuration between two devices is not
synchronous.
After the manual batch backup command is executed, the designated active device
immediately synchronizes its configuration commands to the designated standby device.
After the manual batch backup command is executed, the designated active device
immediately synchronizes its status information to the designated standby device with no
need to wait for an automatic backup period.
l Quick session backup
Quick session backup applies when the forward and return paths are inconsistent on load
balancing networks. Inconsistent forward and return paths may occur on load balancing
networks because both devices are active and able to forward packets. If status
information is not synchronized in a timely manner, return packets may be discarded
when they match no session, causing service interruption. Therefore, quick session
backup is required by the FWs to back up status information in real time.
For timely synchronization, only status information but not configuration commands are
synchronized in this function. The synchronization of configuration commands must be
undertaken by automatic backup.
After quick session backup is enabled, the active FW can synchronize all status
information, including those not supported by automatic session backup, to the standby
FW. That is, sessions can be synchronized to the standby FW immediately when they are
set up on the active FW.
Heartbeat Interface and Heartbeat Link Detection Packet

The two FWs exchange backup data through the heartbeat interfaces over the heartbeat link.
As shown in Figure 2-25, a heartbeat interface must be an independent interface with an IP
address. It can be a physical interface (such as a GE interface) or a logical Eth-Trunk
interface. (Usually, the backup data is 20% to 25% of the service traffic. You can determine
the number of member Eth-Trunk interfaces based on the backup data volume.)

Figure 2-25 Physical or logical interface being the heartbeat interface

Physical interface being
the heartbeat interface
FW1 GE1/0/1 running running GE1/0/1 FW2

1.1.1.1 1.1.1.2
Eth-Trunk interface being

the heartbeat interface
running running
FW1 GE1/0/1 GE1/0/1
FW2
Eth-Trunk1 GE1/0/2 GE1/0/2 Eth-Trunk1
1.1.1.1 1.1.1.2
GE1/0/3 GE1/0/3
Heartbeat interface
HRP Data packet
A heartbeat interface can be in any of the following status:
l invalid: The local heartbeat interface is incorrectly configured (the physical status is UP
and protocol status is DOWN). For example, the heartbeat interface is a Layer-2
interface, or no IP address is configured for the heartbeat interface.
l down: The physical and protocol statuses of the local heartbeat interface are both
DOWN.
l peerdown: The local heartbeat interface (physical and protocol statuses are both UP)
cannot receive heartbeat link detection reply packets from the peer heartbeat interface. In
this case, the FW sets the status of the local heartbeat interface to peerdown. Even so,
the local heartbeat interface continues sending heartbeat link detection packets and
expects to resume the heartbeat link when the peer heartbeat interface is brought up .
l ready: The local heartbeat interface (physical and protocol statuses are both UP)
receives heartbeat link detection reply packets from the peer heartbeat interface. In this
case, the FW sets the status of the local heartbeat interface to ready, indicating that it is
ready to send and receive heartbeat packets. Besides, it continues sending heartbeat link
detection packets to keep the heartbeat link status.
l running: When multiple local heartbeat interfaces are in ready state, the FW sets the
status of the first configured one to running. If only one interface is in ready state, the
FW sets its status to running. The running interface is used to send and receive HRP
heartbeat packets, HRP data packets, HRP consistency check packets, and VGMP
packets.
Other local heartbeat interfaces in ready state serve as backups and take up services in
sequence (based on the order of configuration) when the running heartbeat interface or the
heartbeat link fails.

Among the heartbeat links shown in Figure 2-26, their interface IDs indicate the order of
configuration. Therefore, when GE1/0/2 fails and GE1/0/3 and GE1/0/4 are both in ready
state, GE1/0/3 switches to the running state.
Figure 2-26 Heartbeat interface status

invalid peerdown
GE1/0/1 GE1/0/1
FW1 FW2
1.1.1.2
GE1/0/2 peerdown down
GE1/0/2
2.2.2.1
GE1/0/3 running running GE1/0/3
3.3.3.1 3.3.3.2
GE1/0/4 ready ready GE1/0/4
4.4.4.1 4.4.4.2
Interface
Heartbeat link
HRP heartbeat link
detection packets
HRP data packets
To conclude, heartbeat link detection packets are used to detect whether the peer heartbeat
interface can receive packets and determine whether the heartbeat link is available. The local
heartbeat interface sends heartbeat link detection packets as long as its physical and protocol
statuses are UP.
As described in previous sections, HRP heartbeat packets are used to detect and sense whether
the peer device (peer VGMP group) is working properly. These packets can be sent only by
the running heartbeat interface in the VGMP group on the active device.
HRP Consistency Check Packets

HRP consistency check packets are used to check whether the hot standby and policy
configurations of the two FW in hot standby mode are consistent.
The hot standby configurations to be checked include whether the same service interfaces are
monitored and whether the same heartbeat interfaces are configured on the two FWs.
The policy configurations to be checked include whether the same policies (such as security,
bandwidth, NAT, authentication policies) are configured on the two FWs.
The mechanism of HRP consistency check is as follows:
1. After the HRP consistency check command is configured on a FW, the FW sends an
HRP consistency check request packet to the peer end and collect a configuration
information digest of local related modules.
2. After receiving the request packet, the peer end collects a configuration information
digest of local related modules and encapsulates it into the reply packet.

3. The local end compares its and the peer end's configuration information digests and
records the comparison information. You can run display hrp configuration check to
check the consistency check result.
2.1.4 Analysis of Typical Hot Standby Networks

This section describes how to deploy typical hot standby networks and corresponding traffic
diversion mechanisms.
2.1.4.1 In-line Deployment with Upstream and Downstream Switches

This section describes the networking where the service interfaces of the FWs work at Layer 3
and connect to switches.
As shown in Figure 2-27, the upstream and downstream service interfaces of the FWs work
at Layer 3 and connect to Layer-2 switches directly.
This network supports both active/standby backup and load balancing.

Active/Standby Backup
Figure 2-27 Networking diagram of active/standby backup when service interfaces work at
Next-hop address of
the router: 1.1.1.1/24
GE1/0/3 GE1/0/3
Status: Status:
Active VRRP group 2 Standby
Virtual IP address:
Active 1.1.1.1/24 Active
NGFW_A NGFW_B
VRRP group 1
GE1/0/1 GE1/0/1
Virtual IP address:
Status: Status:
10.1.1.1/24
Active Standby
Virtual MAC address:
ARP reply packet 0000-5e00-0101
0000-5e00-0101
Eth0/0/2
Eth0/0/1 MAC address Port
0000-5e00-0101 Eth0/0/1
Gateway
address of the
PC: 10.1.1.1/24
Intranet VRRP group
Service traffic
ARP reply
Heartbeat link
As shown in Figure 2-27, a VRRP group is configured on each service interface of FW_A,
and its status is set to active. a VRRP group is configured on each service interface of FW_B,
and its status is set to standby. The virtual IP address of the corresponding VRRP group is
configured as the gateway address of the PC on the intranet.
The analysis on network operating is as follows:
1. The PC sends an ARP packet to the directly connected switch for requesting the MAC
address of the gateway (address of VRRP group 1). The switch broadcasts the ARP
packet.
2. Only FW_A whose VRRP group is in active state responds to the ARP packet and sends
the virtual MAC address of VRRP group 1.

3. The switch records the mapping between the virtual MAC address and Eth0/0/1 and
sends the MAC address to the PC.
4. The PC sends a service packet with the virtual MAC address of VRRP group 1 as the
destination address to the switch.
5. Based on the mapping between the MAC address and port, the switch sends the packet to
FW_A from Eth0/0/1.
Normally, the traffic sent from the PC is forwarded by FW_A (active device).
Figure 2-28 Networking where the active device goes faulty
Next-hop address of
GE1/0/3 GE1/0/3
Status: Standby VRRP group 2 Status: Active
Virtual IP address:
Standby 1.1.1.1/24 Active
NGFW_A NGFW_B
VRRP group 1
GE1/0/1
Virtual IP address: GE1/0/1
Status: Standby
10.1.1.1/24 Status: Active
Virtual MAC address:
0000-5e00-0101 Gratuitous ARP packet
0000-5e00-0101
Eth0/0/2
Eth0/0/1 MAC address Port
0000-5e00-0102 Eth0/0/2
Gateway
address of the
PC: 10.1.1.1/24
Intranet VRRP group
Service traffic
Gratuitous ARP packets
Heartbeat link
Fault
The analysis on the operating of the network where FW_A goes faulty, as shown in Figure
2-28, is as follows:

1. When a service interface of FW_A goes faulty, FW_A becomes the standby device, and
FW_B becomes the active device.
2. FW_B sends gratuitous ARP packets, containing the virtual IP and MAC addresses of
the VRRP group.
3. The switch updates the mappings between MAC addresses and ports (such as the
mapping between the virtual MAC address of VRRP group 1 and Eth0/0/2) after
receiving the gratuitous ARP packets.
4. When the PC sends a service packet to the switch, the switch forwards the packet to
FW_B from Eth0/0/2.
If FW_A becomes faulty, traffic sent by the PC is diverted to FW_B (new active device).
Load Balancing
As shown in Figure 2-29, the load balancing networking is configured as follows:
l VRRP groups 1 and 2 are configured on GE1/0/1 of FW_A. GE1/0/1 is in active state in
VRRP group 1 and in standby state in VRRP group 2.
l VRRP groups 1 and 2 are configured on GE1/0/1 of FW_B. GE1/0/1 is in standby state
in VRRP group 1 and in active state in VRRP group 2.
l Set the gateway of some PCs to the virtual IP address of VRRP group 1 and that of other
PCs to the virtual IP address of VRRP group 2.
l VRRP groups 3 and 4 are configured on GE1/0/1 of FW_A. GE1/0/3 is in active state in
VRRP group 3 and in standby state in VRRP group 4.
l VRRP groups 3 and 4 are configured on GE1/0/1 of FW_B. GE1/0/3 is in standby state
in VRRP group 3 and in active state in VRRP group 4.
l Two static routes are configured on the router. The next-hop addresses of the two routes
are the virtual IP addresses of VRRP groups 3 and 4 respectively.
GE1/0/1 of FW_A uses the virtual IP address of VRRP group 1 as the next-hop address to
forward packets. GE1/0/1 of FW_B uses the virtual IP address of VRRP group 2 as the next-
hop address to forward packets. Some PC traffic is forwarded by FW_A, while the other PC
traffic is forwarded by FW_B, implementing load balancing.

Figure 2-29 Networking diagram of load balancing when service interfaces work at Layer 3
and connect to switches
Next-hop address of
VRRP group 4
Virtual IP address:
1.1.1.2/24
Virtual IP address: Active
Active
1.1.1.1/24
NGFW_A NGFW_B

Virtual IP address:
10.1.1.1/24
VRRP group 2
Virtual IP address:
10.1.1.2/24
Gateway address Gateway address

of PC1: of PC2:
10.1.1.1/24 10.1.1.2/24
Intranet
VRRP group
Traffic from PC1
Traffic from PC2
Heartbeat link
2.1.4.2 In-line Deployment with Upstream and Downstream Routers

and connect to routers.
As shown in Figure 2-30, the upstream and downstream interfaces on the FWs work at Layer
3 and connect to routers directly. The FWs and their directly connected routers use OSPF to
communicate.
This network supports both active/standby backup and load balancing.

Router_C Router_D
OSPF
NGFW_A NGFW_B
OSPF
Router_A Router_B
Traffic flow when no fault occurs

Traffic flow when a fault occurs
Heartbeat link
As shown in Figure 2-30, FW_A (active device) advertises routes properly. FW_B (standby
device) increases the cost of each route to be advertised by 65500.
The routers connected to the FWs use the path with the smaller cost to forward traffic.
Therefore, traffic is forwarded by FW_A (active device).
When a service interface of FW_A goes faulty, FW_A becomes the standby device, and
FW_B becomes the active device.
FW_B advertises routes properly, whereas FW_A increases the cost of each route to be
advertised by 65500. After route reconvergence, traffic is forwarded by FW_B.

Load Balancing
Figure 2-31 Networking diagram of load balancing when service interfaces work at Layer 3
and connect to switches
Router_C Router_D
Cost10 Cost10
OSPF
NGFW_A NGFW_B
OSPF
Cost10 Cost10
Router_A Router_B
Traffic to be forwarded by NGFW_A

Traffic to be forwarded by NGFW_B
Heartbeat link
As shown in Figure 2-31, FW_A and FW_B that work in load balancing mode are both active
devices and properly advertise routes.
Therefore, you need to set the same cost for the interfaces that connect Routers A and C to
FW_A and the interfaces that connect Routers B and D to FW_B. This setting allows traffic to
be balanced between FW_A and FW_B.
Precautions
As shown in Figure 2-30 and Figure 2-31, the upstream router uses OSPF to advertise default
routes to the FW, and the FWadvertises learned default routes to the downstream router. In
this networking, you need to configure routing policies to filter default routes on the FW and
downstream router. Otherwise, loops may occur between the FW and downstream router.
2.1.4.3 Transparent Deployment with Upstream and Downstream Switches

and connect to switches.
As shown in Figure 2-32, the upstream and downstream interfaces on the FW work at Layer
2 and connect to Layer-2 switches directly. The upstream and downstream service interfaces
on each FW are added to the same VLAN.
This network supports only active/standby redundancy.

Switch_C Switch_D
NGFW_A NGFW_B
Switch_A Switch_B
Service link
Heartbeat link
VLAN
Traffic flow when no fault occurs
Traffic flow when a fault occurs
As shown in Figure 2-32, the VLAN on FW_A (active device) is enabled and can forward
traffic. The VLAN on FW_B (standby device) is disabled and cannot forward traffic.
Therefore, all traffic is forwarded by FW_A.
NOTICE
This network does not support load balancing. If FW_A and FW_B work in load balancing
mode, the VLANs on both devices are enabled and can forward traffic, causing a loop on the
network.
When FW_A goes faulty, FW_A becomes the standby device, and FW_B becomes the active
device.
When FW_A becomes the standby device, all interfaces on the VLAN of the FW_A goes
Down and then Up. Because of interface status changes, all switches update their MAC
forwarding tables. Therefore, traffic is diverted to FW_B.

2.1.4.4 Transparent Deployment with Routers

and connect to routers.
As shown in Figure 2-33, the upstream and downstream interfaces on the FW work at Layer
2 and connect to routers directly. The FWs and their directly connected routers use OSPF to
communicate. The upstream and downstream service interfaces on each FW are added to the
same VLAN.
This network supports only load balancing redundancy.
Figure 2-33 Networking diagram for load balancing when service interfaces working at Layer
2 and connect to routers
Router_C Router_D
OSPF
NGFW_A NGFW_B
OSPF
Router_A Router_B
Service link
Heartbeat link
VLAN
Traffic to be forwarded by NGFW_A
Traffic to be forwarded by NGFW_B
Load Balancing
The VLANs on FW_A and FW_B are enabled and can forward traffic. FW_A, FW_B, and
their directly connected routers need to run OSPF to divert traffic.
Therefore, you need to set the same cost for the interfaces that connect Routers A and C to
FW_A and the interfaces that connect Routers B and D to FW_B. This setting allows traffic to
be balanced between FW_A and FW_B.

NOTICE
This network does not support active/standby. If FW_A and FW_B work in active/standby
mode, the VLAN on the standby device is disabled. The routers directly connected to the
standby device cannot communicate and cannot establish an OSPF neighbor relationship.
During an active/standby switchover, the standby device cannot take over services from the
active device, causing service interruptions.
When FW_A goes faulty, FW_A becomes the standby device, and FW_B becomes the active
device.
When FW_A becomes the standby device, all interfaces on the VLAN of the FW_A goes
Down and then Up. As a result, all routers need to recalculate routes. In this case, the VLAN
on FW_A is disabled, and the cost of the path that passes through FW_A increases. Therefore,
all traffic is forwarded by FW_B.
2.1.4.5 Off-line Deployment

This section describes the networking where the FWs connect to Layer-3 switches in off-line
mode.
Connecting FWs to Layer-3 Switches in Off-line Mode Using VRRP and Static
Routing
As shown in Figure 2-34, to divert traffic passing core switches to the FWs using static
routing, static routes need to be configured on core switches, with the next hop being the
interface addresses of the FWs. However, core switches generally use OSPF to communicate
with upstream routers and downstream aggregation switches. OSPF routes have higher
priorities than static routes. Therefore, core switches directly forward received traffic to
upstream or downstream devices using OSPF routes, but do not divert traffic to the FWs using
static routes.

Figure 2-34 Networking diagram for deploying FWs in off-line mode using VRRP and static
routing
GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1
GE1/0/1
10.1.0.1/24 GE1/0/2
Public Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0
GE1/0/0 10.0.0.2/24
FW_A Core switch FW_B
10.0.0.1/24
Traffic
Static route
Therefore, virtual routing and forwarding (VRF) must be configured on core switches to
virtualize each core switch into a public switch for connecting upstream switches and a virtual
switch for connecting downstream switches, as shown in Figure 2-35. The two virtualized
switches are isolated. Therefore, traffic can be diverted to the FWs based on static routes.
Figure 2-35 Diverting traffic to the FWs using static routing and VRF
GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1
GE1/0/1
10.1.0.1/24 GE1/0/2
Public Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0
GE1/0/0 10.0.0.2/24
FW_A Core switch FW_B
10.0.0.1/24
Traffic
Static route

For easy understanding, you can transform the off-line deployment shown in Figure 2-35 into
the in-line deployment shown in Figure 2-35. Figure 2-36 shows a typical networking
described in 2.1.4.1 In-line Deployment with Upstream and Downstream Switches. In this
networking, VRRP groups need to be configured on the service interfaces of the FWs.
Static routes need to be configured on the VRF and public virtual switches with the next hop
being the virtual addresses of VRRP groups 1 and 2 respectively, so that the two virtual
switches can forward traffic to the FWs. Besides, two static return routes also need to be
configured on each FW with the next hops being the virtual addresses of VRRP group 3 of the
VRF virtual switch and VRRP group 4 of the public virtual switch. Actually, the two FWs use
the virtual addresses of the VRRP groups to communicate with the two virtual switches.

Figure 2-36 Transforming off-line deployment to in-line deployment
Internet/WAN
GE1/0/7 GE1/0/7
10.10.0.1/24 Heartbeat link 10.10.0.2/24
10.1.0.1/24 10.1.0.2/24
GE1/0/2
GE1/0/1 GE1/0/1 GE1/0/1 GE1/0/1
GE1/0/2
GE1/0/4
GE1/0/4 GE1/0/3 GE1/0/0
GE1/0/3 10.0.0.2/24
NGFW_A GE1/0/0 Core switch NGFW_B
10.0.0.1/24
Server cluster
Traffic
Static route
Connecting FWs to Layer-3 Devices in Off-line Mode Using OSPF and PBR
On the network shown in Figure 2-37, to divert traffic passing core switches to the FWs using
policy-based routing (PBR), policy-based routes need to be configured on the core switches
with the redirect next hops being the interface addresses of the FWs. However, core switches
generally use OSPF to communicate with upstream routers and downstream aggregation
switches. Policy-based routes have higher priorities than the routes of all routing protocols.
Therefore, core switches can divert received traffic to the FWs based on the policy-based
routes, but not upstream or downstream devices using OSPF routes.

The FWs check the traffic and return it to the core switches. For this reason, the OSPF must
run on the FWs and core switches, so that the FWs can return traffic to the core switches
using OSPF routes. However, each FW connects to a core switch through two interfaces.
Therefore, the FW can find two equal-cost OSPF routes in the routing table and may return
traffic to the switch through the interface where the traffic is received. If the incoming and
outgoing interfaces are the same, the FW cannot comprehensively check and control traffic.
To resolve this problem, allocate two OSPF processes to each core switch and FW and import
them to each other on the FWs. In this way, after a core switch diverts traffic to an interface
on the FW based on PBR, the FW finds only the OSPF route from the imported process and
returns the traffic to the switch through the other interface.
Figure 2-37 Networking diagram for deploying FWs in off-line mode using OSPF and PBR
Internet/WAN
Egress
router
GE1/0/7 OSPF200 GE1/0/7

10.10.0.1/24 Switch1 GE1/0/4 GE1/0/4 Switch2 10.10.0.2/24
GE1/0/1 GE1/0/3 10.4.0.1/24 10.5.0.1/24 GE1/0/3 GE1/0/1
10.1.0.1/24 10.1.0.2/24 GE1/0/1 10.3.0.2/24 10.3.0.1/24
172.16.3.2/24
GE1/0/1
GE1/0/0 GE1/0/2 172.16.3.1/24 GE1/0/2 GE1/0/0
10.0.0.1/24 10.0.0.2/24 GE1/0/0 GE1/0/0 10.2.0.2/24 10.2.0.1/24
FW_A 172.16.1.1/24 172.16.2.1/24 FW_B
OSPF100
Aggregation
switch
Server cluster
PBR
Actual traffic

For easy understanding, you can transform the off-line deployment shown in Figure 2-37 into
the in-line deployment shown in Figure 2-37. The networking shown in Figure 2-36 is
similar to the typical networking described in 2.1.4.2 In-line Deployment with Upstream
and Downstream Routers with the following differences: Two OSPF processes need to be
configured on the FWs and import each other, and PBR needs to be configured together with
OSPF on the switches.
Figure 2-38 Transforming off-line deployment to in-line deployment by connecting the FWs
to routers
GE1/0/4 OSPF200 GE1/0/4

10.4.0.1/24 10.5.0.1/24
Switch1 Switch2
GE1/0/3 GE1/0/3
10.1.0.2/24 10.3.0.2/24
GE1/0/1 OSPF200
GE1/0/1
10.1.0.1/24 10.3.0.1/24
GE1/0/7
10.10.0.1/24
FW_A FW_B
GE1/0/7
GE1/0/0 10.10.0.2/24
GE1/0/0
10.0.0.1/24
OSPF100 10.2.0.1/24
GE1/0/2 GE1/0/2
10.0.0.2/24 10.2.0.2/24
GE1/0/1
172.16.3.2/24
Switch1 Switch2
GE1/0/1
172.16.3.1/24
GE1/0/0 GE1/0/0
172.16.1.1/24 OSPF100 172.16.2.1/24
PBR
Actual traffic

This section describes the restrictions on hot standby, including hardware restrictions,
software restrictions, and restrictions on interworking with NAT and IPSec.

Hardware Restrictions
l Currently, hot standby can be implemented between only two devices.
l The active and standby devices must have the same product model and version.
Software Restriction
l The active and standby devices must run software of the same version. Otherwise, some
configurations or session table structures on the two devices may be different. As a
result, faults may occur when the active and standby devices synchronize configurations
and status.
l The BootROM versions on the active and standby devices must be the same.
l If configuration commands are executed manually on the active and standby devices
after the automatic backup function is disabled, the configuration contents are the same
but the configuration order is not. For example, the policy matching conditions on the
active and standby devices are different. In such cases, the consistency check function
will determine that the active and standby device configurations are different. However,
this impacts neither the hot standby service nor the performance. You just need to re-
configure the commands.
l It is recommended that the active and standby devices use their initial configuration files.
Otherwise, faults may occur after an active/standby switchover because of configuration
conflicts.
l The service interfaces and heartbeat interfaces used by active and standby devices must
be the same. For example, if the active device uses GigabitEthernet1/0/1 as the service
interface and GigabitEthernet1/0/7 as the heartbeat interface, the standby device must
use the same interfaces.
l The interfaces on the same slot of the active and standby devices must be added to the
same security zone. For example, if GigabitEthernet1/0/1 interface on the active device
is added to the Trust zone,GigabitEthernet1/0/1 on the standby device must also be
added to the Trust zone.
l The interfaces with vrrp virtual-mac enable configured cannot function as heartbeat
interfaces.
l The MTU of the heartbeat interfaces must be set to 1500.
l The service interfaces of the active and standby devices use fixed IP addresses.
Therefore, you cannot use the hot standby function together with such features as PPPoE
and DHCP which use dynamic IP addresses.
l Before changing the working mode on the web page after hot standby is established, you
must clear all hot standby-related configurations.
l When hot standby is used with virtual systems, ensure that the two devices have the
same VSYS name and ID.
Restrictions on the Interworking with NAT

l When hot standby interworks with NAT, the upstream and downstream service interfaces
on the active and standby devices must be Layer-3 interfaces.
l In load balancing mode, if a NAT address pool is required on both FWs, you must run
hrp nat resource primary-group on one FW and hrp nat resource secondary-group
on the other FW to prevent port conflicts during NAT.
l In the load balancing networking, if you configure only one NAT address pool and do
not configure port translation in the address pool-based source NAT policy, the two FWs

may translate the source IP addresses of traffic from different hosts to the same IP
address, causing address conflicts.
In this case, you are advised to create two NAT address pools for the FWs to translate
source IP addresses to addresses in different address pools. For example, FW_A and
FW_B are deployed in hot standby mode and process traffic from 10.1.1.1 to 10.1.1.128
and 10.1.1.129 to 10.1.1.254 respectively. Configure address pool-based source NAT
without port translation, create NAT address pools addressgroup1 and addressgroup2,
and configure two source NAT policies for the FWs to translate the source IP addresses
of the traffic from 10.1.1.1 to 10.1.1.128 to addresses in addressgroup1 and those of the
traffic from 10.1.1.129 to 10.1.1.254 to addresses in addressgroup2.
Restrictions on the Interworking with IPSec

l When hot standby interworks with IPSec, the upstream and downstream service
interfaces used by the active and standby devices to establish an IPSec tunnel must be
Layer-3 interfaces.
l The configurations of hot standby and IPSec are respectively the same no matter when
hot standby interworks with IPSec or they are used separately.
l When hot standby is used with IPSec, ensure that the forward and return paths are the
same in load balancing mode.
l Only the IPSec policy configuration, not the interface configuration, is synchronized
from the active device to the standby device. Therefore, you need only to apply IPSec
policies in the outgoing interface of the standby device.
l If the FW initiates the establishment of an IPSec tunnel, you must run the tunnel local
ip-address command to specify the virtual VRRP IP address as the local IP address for
initiating the IPSec negotiation.
2.1.6 Configuring Hot Standby Using the Web UI

This section describes how to configure dual-system hot backup on the web UI.
Prerequisites
l Interfaces at Layer 3 are specified with IP addressed.
l Interfaces at Layer 2 are added to the VLAN.
l Interfaces are assigned to security zones.
l Configure the action as permit in the security policy implemented between the Local
zone and the security zone to which the heartbeat interfaces are assigned.
Context
Dual-system hot backup configurations vary with networking.
Networking Configurations
Service interfaces work at Layer 3 and Configure virtual IP addresses and add
connect to switches. upstream and downstream service interfaces
to the VRRP backup group.

Networking Configurations
Service interfaces work at Layer 3 and Configure interface status monitoring in

connect to routers. interface monitoring to monitor upstream
and downstream service interfaces.
Service interfaces work at Layer 2 and Configure VLAN status monitoring in

connect to switches. interface monitoring to monitor the VLAN
on which both upstream and downstream
service interfaces reside.
Service interfaces work at Layer 2 and Configure VLAN status monitoring in

connect to routers. interface monitoring to monitor the VLAN
on which both upstream and downstream
service interfaces reside.
Service interfaces work at Layer-3 and Configure virtual IP addresses and add
connect to the upstream router and downstream service interfaces to the VRRP
downstream switch. backup group.
Configure interface status monitoring in
interface monitoring to monitor upstream
service interfaces.
Procedure
Step 1 Choose System > High Availability > Dual-System Hot Backup.
Step 2 On the Dual-System Hot Backup page, click to configure basic dual-system hot backup
functions.
Dual-System Hot Backup Enables dual-system hot backup.
Working Mode Two backup modes are available:

l Active/Standby
l Load balancing
State Determines whether the device is active or standby.
Heartbeat Interface Indicates the heartbeat interface.
Proactive Preemption Configures the proactive preemption of the VGMP

management group.
By default, the preemption function of the VGMP management
group is enabled.
When you configure no preemption, you can deselect this item
only on active device.
Hello Packet Interval Indicates the interval for sending hello packets.

Step 3 Configure the virtual IP address.
1. Click to create a virtual IP address.
VRID Indicates the ID of the VRRP backup group.
Interface Indicates the interface added to the VRRP backup group.
Interface IP Address/ Indicates the IP address and mask of the interface added to
MASK the VRRP backup group.
Virtual IP Address/ Indicates the virtual IP address and mask of the VRRP
MASK backup group.
A virtual IP address represents both devices working in
dual-system hot backup. The next-hop IP address of the
upstream and downstream devices must be the virtual IP
address if they are connected to both devices through static
routes. The subnet mask is required if the virtual IP address
does not reside on the same subnet of the actual IP address
of the interface.
2. Click OK.
Step 4 Configure interface monitoring.

1. To monitor the VLAN status, select VLAN from the drop-down list and create a VLAN
ID.
2. To monitor the interface status, select Interface from the drop-down list and set the
interface name.
3. Click .
Step 5 Optional: Configure IP-link monitoring.

1. Select an IP-link ID from the drop-down list.
2. Click .
Step 6 Optional: Configure BFD monitoring.

1. Select the BFD local discriminator from the drop-down list.
2. Click .
Step 7 Click OK.
----End
Follow-up Procedure
After you compete the preceding operations, choose System > High Availability > Dual-
System Hot Backup to view the operating status of hot standby. The parameters related to
hot standby are described as follows:

Current Working Mode l Single Device: is displayed if hot standby is not enabled.
l Active/Standby Backup: is displayed when the devices
work in active/standby mode.
l Load Balancing: is displayed when the devices work in load
balancing mode.
Current State l Initialization: is displayed after the configuration is

complete and before hot standby is established,
l Active: is displayed on the active device after hot standby is
established.
l Standby: is displayed on the standby device after hot
standby is established.
Click Details to view records about the active/standby
switchover, including Time, Description and Reason.
Click Manual Switchover to manually switchover the state of
device.
Current HeartBeat Heartbeat interface and its bandwidth usage.

Interface
Proactive Preemption Whether the preemption function is enabled.
Configuration Whether the configurations of the active and standby devices

Consistency are consistent.
Click Check to check whether the configurations of the
devices are consistent.
Click Details to view the check results, check date, and
inconsistent items. In the dialog box that is displayed, click
Synchronize Configuration to synchronize device
configurations.
Click Recheck to check whether the configurations of the
devices are consistent.
Virtual IP State of a monitored VRRP group
Interface State of a monitored interface
Monitored Remote IP address/domain name of an indirectly connected interface

Detection IP Address/ that is monitored
Domain Name
2.1.7 Configuring Hot Standby Using the CLI

This section describes how to configure hot standby using the CLI.

2.1.7.1 Configuration Flow

This section describes the flow for configuring hot standby. You can read the section of each
configuration step according to the following flowchart.
For details about the flow for configuring hot standby, see Figure 2-39.
Figure 2-39 Configuration flowchart

Basic network
1
configuration
Interface
Security zone
Route
Security policy
Layer-3 interfaces Layer-2 service
connect to switches interfaces
Layer-3 interfaces
connect to routers
Configuring VRRP Groups Configuring Interface Monitoring Configuring VLAN Monitoring
vrrp vrid(interface view) hrp track interface hrp track vlan
Configuring Remote Interface

Monitoring
2 hrp track ip-link
Configuring
VGMP Groups hrp track bfd-session
3 Configuring Heartbeat
Interfaces
hrp interface
4 Enabling Hot Standby

hrp enable
5 Configuring the Backup

Mode
hrp auto-sync
hrp sync
hrp mirror session enable
Configuring security
6
services
2.1.7.2 Configuring VGMP Groups

This section describes how to configure VGMP groups to monitor the interface, VLAN, IP-
link, and BFD status.

2.1.7.2.1 Configuring VRRP Groups

If the service interfaces of each FW work at Layer 3 and are directly connected to switches,
you need to configure VRRP groups.
Prerequisites
Complete service interface configurations, such as IP address and security zone
configurations.
Context
l In active/standby mode, the configuration roadmap is as follows:
a. Configure a VRRP group on each service interface of the active device and add the
VRRP groups to the active VGMP group.
As shown in Figure 2-40, VRRP group 2 configured on GE1/0/1 and VRRP group
1 configured on GE1/0/3 of FW_A are added to the active VGMP group.
b. Configure a VRRP group on each service interface of the standby device and add
the VRRP groups to the standby VGMP group.
As shown in Figure 2-40, VRRP group 2 configured on GE1/0/1 and VRRP group
1 configured on GE1/0/3 of FW_B are added to the standby VGMP group.
c. On the hosts or devices that are directly connected to each switch, set the gateway
address or next-hop address of the static route to the virtual IP address of the
corresponding VRRP group.
Figure 2-40 Configuring VRRP groups in active/standby mode
FW_A
SwitchA GE1/0/3 GE1/0/1 SwitchC
10.3.0.1/24 10.2.0.1/24
Active Active
VRRP group 1 VRRP group 2
Standby Standby
SwitchB GE1/0/3 GE1/0/1 SwitchD

10.3.0.2/24 10.2.0.2/24
FW_B
l In load balancing mode, the configuration roadmap is as follows:

a. Configure two VRRP groups on each service interface of FW_A and add the VRRP
groups of one interface to the active VGMP group and those of the other interface
to the standby VGMP group.
As shown in Figure 2-41, on the downstream interface GE1/0/3 of FW_A,
configure VRRP group 1 and add it to the active VGMP group; configure VRRP
group 3 and add it to the standby VGMP group. On the upstream interface GE1/0/1,

configure VRRP group 2 and add it to the active VGMP group; configure VRRP
group 4 and add it to the standby VGMP group.
b. On the service interfaces of FW_B, configure the same VRRP groups but add them
to the opposite VGMP groups.
As shown in Figure 2-41, on the downstream interface GE1/0/3 of FW_B,
configure VRRP group 1 and add it to the standby VGMP group; configure VRRP
group 3 and add it to the active VGMP group. On the upstream interface GE1/0/1,
configure VRRP group 2 and add it to the standby VGMP group; configure VRRP
group 4 and add it to the active VGMP group.
c. On the hosts or devices that are directly connected to each switch, configure two
static routes, with the next hop addresses being the virtual IP addresses of the two
VRRP groups respectively.
Figure 2-41 Configuring VRRP groups in load balancing mode

NGFW_A
SwitchA GE1/0/3 GE1/0/1 SwitchC
10.3.0.1/24 10.2.0.1/24
Standby Active Active Standby
VRRP VRRP VRRP VRRP

group 3 group 1 group 2 group 4
10.3.0.4/24 10.3.0.3/24 10.2.0.3/24 10.2.0.4/24
Active Standby Standby Active
SwitchB GE1/0/3 GE1/0/1 SwitchD

10.3.0.2/24 10.2.0.2/24
NGFW_B
Procedure
Step 1 In the user view, access the system view.
system-view
Step 2 Access the interface view.

interface interface-type interface-number
The interfaces that support VRRP groups include Layer-3 Ethernet interfaces and their
subinterfaces, Layer-3 Eth-Trunk interfaces, and VLANIF interfaces.
Step 3 Run the following commands to configure a VRRP or VRRPv6 group as required:
l Configure a VRRP group.
vrrp vrid virtual-router-id virtual-ip virtual-address [ ip-mask | ip-mask-length ]
{ active | standby }
l Configure a VRRPv6 group.
a. Configure a link-local address.
vrrp6 vrid virtual-router-id virtual-ip virtual-ipv6-address link-local { active |
standby }

b. Configure a virtual IPv6 address.

vrrp6 vrid virtual-router-id virtual-ip virtual-ipv6-address
Note the following points when using the previous commands:
l virtual-router-iD specifies the VRRP group ID. The two hot standby FWs must be
configured with the same VRID.
l virtual-ipv6-address link-local specifies the link-local address of the VRRPv6 group.
The link-local address is an IPv6 address whose prefix is FE80::/10. This address is used
for communication between adjacent nodes on a link and is valid only for the link. When
configuring a virtual IPv6 address for a VRRPv6 group, you must also configure a link-
local address for the group.
l The virtual IP addresses of VRRP groups specified by virtual-address and virtual-ipv6-
address must not be the same as physical interface addresses.
Both FWs use the virtual IP address to communicate with other devices. For upstream
and downstream devices, the two FWs serve as one device, with the virtual IP address
being the interface address. If you configure static routes on upstream and downstream
devices, configure the virtual IP address as the next hop.
l ip-mask | ip-mask-length specifies the subnet mask of the virtual IPv4 address of the
VRRP group. If the virtual IP address and interface IP address are on different network
segments, configure the subnet mask for the virtual IP address.
Step 4 Optional: Configure VRRP authentication.

vrrp vrid virtual-router-ID authentication-mode { simple | md5 } key
By default, VRRP packets are not authenticated by the FW. VRRP packet authentication is
not required on a secure network.
You can enable VRRP packet authentication if necessary. The NGFW supports simple text
authentication (with parameter simple configured) and MD5 authentication.
NOTE
Set the same VRRP authentication key on the service interfaces that are added to the same VRRP group.
VRRPv6 groups do not support VRRP authentication.
Step 5 Optional: Enable the virtual MAC address function.

vrrp virtual-mac enable
Enable this function on interfaces when the directly connected device is a Layer-4 switch.
Step 6 Optional: In the system view, configure the interval at which the active device sends
gratuitous ARP packets.
vrrp gratuitous-arp timeout time
By default, the active device sends gratuitous ARP packets every 300s (5 minutes).
The time value must be smaller than the aging time of the MAC address entries on the
switches directly connected to the FW. A small time value enables switches to update the
MAC address table rapidly an active/standby switchover of the FWs.
----End

Example
On the active/standby backup network shown in Figure 2-40, the VRRP group configurations
are as follows:
[FW_A-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 10.2.0.3 active
[FW_B-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 10.2.0.3 standby
On the load balancing network shown in Figure 2-41, the VRRP group configurations are as
follows:
[FW_A-GigabitEthernet1/0/1] vrrp vrid 4 virtual-ip 10.2.0.4 standby
[FW_B-GigabitEthernet1/0/1] vrrp vrid 4 virtual-ip 10.2.0.4 active
2.1.7.2.2 Configuring Interface Monitoring

You need to configure interface monitoring if service interfaces work at Layer 3 and connect
to routers.
Prerequisites
1. Complete service interface configurations, such as IP address and security zone
configurations.
2. OSPF is configured on the FWs and their downstream and upstream routers.
3. A security policy is configured to permit legitimate traffic.
Context
In active/standby mode, the configuration roadmap is as follows:
1. Configure VGMP groups on the active and standby FWs to monitor all service
interfaces.

As shown in Figure 2-42, a VGMP is configured on each FW to monitor corresponding

their respective GE1/0/1 and GE1/0/3 interfaces.
2. On FW_B, configure FW_B as the standby FW.
3. Adjust the costs of routes on FW_A and FW_B based on their active/standby status.
Figure 2-42 Configuring VGMP groups to monitor interfaces
RouterA FW_A RouterC

GE1/0/3 GE1/0/1
10.3.0.1/24 10.2.0.1/24
GE1/0/7
10.10.0.1/24
OSPF GE1/0/7 OSPF
10.10.0.2/24
GE1/0/3 GE1/0/1
10.3.1.1/24 10.2.1.1/24
RouterB FW_B RouterD
In load balancing mode, you need only to configure VGMP groups on both FWs to monitor
all service interfaces.
Procedure
Step 1 In the user view, access the system view.
system-view
Step 2 Configure a VGMP group to monitor service interfaces.

hrp track interface interface-type interface-number
VGMP groups can monitor Layer-3 Ethernet interfaces and subinterfaces and Layer-3 Eth-
Trunk interfaces.
Step 3 On FW_B, configure FW_B as the standby FW.
hrp standby-device
NOTE
l You must run this command in active/standby scenario and must not in load balancing scenario.
l If this command is run on a FW where a VRRP group is configured, the status of the FW is determined
by the VRRP group configuration.
Step 4 Enable OSPF, OSPFv3, or BGP cost adjustment based on VGMP group status.
hrp adjust { ospf-cost | ospfv3-cost | bgp-cost } enable [ slave-cost ]
NOTICE
This command is not required on load balancing networks but must be configured on active/
standby backup networks where the service interfaces of the FW work at Layer 3 and connect
to routers.

The cost can be the default value or a user-defined one. In this way, when upstream and
downstream routers calculate routes, the next hop is pointed to the active device, and packets
are forwarded to the active device.
After this command is run:
l If the routing protocol is OSPF or OSPFv3, the active FW directly advertises the learned
OSPF or OSPFv3 routes, and the standby FW adds a specific slave-cost value to the cost
of the learned routes. By default, the standby FW advertises OSPF or OSPFv3 routes
whose costs are 65500.
l If the routing protocol is EBGP or IBGP, the active FW directly advertises the learned
EBGP or IBGP routes, and the standby FW adds a specific slave-cost value to the MED
value in the learned routes. By default, the slave-cost value is 100.
NOTE
hrp adjust ospfv3-cost enable cannot adjust OSPFv3 cost on loopback interfaces.
----End
Example
On the active/standby backup network shown in Figure 2-42, the interface monitoring
configurations are as follows:
[FW_A] hrp track interface GigabitEthernet 1/0/1
[FW_A] hrp adjust ospf-cost enable
[FW_B] hrp track interface GigabitEthernet 1/0/1
[FW_B] hrp standby-device
[FW_B] hrp adjust ospf-cost enable
On the load balancing network shown in Figure 2-42, the interface monitoring configurations
are as follows:
2.1.7.2.3 Configuring VLAN Monitoring

When service interfaces work at Layer 2, you need to configure VGMP groups to monitor
VLANs. By default, the VGMP groups monitor all VLANs except VLAN1 after hot standby
is enabled.
Prerequisites
1. Service interfaces are configured, including configuring interfaces as Layer 2 interfaces
and assigning interfaces to security zones.
2. The upstream and downstream service interfaces are added to the same VLAN (not
VLAN1).
3. A security policy is configured to permit legitimate traffic.
Context
As shown in Figure 2-43, when the upstream and downstream service interfaces work at
Layer 2 and connect to switches, VLAN monitoring can be implemented only in active/
standby mode. The configuration roadmap is as follows:

1. Configure VGMP groups on the active and standby FWs to monitor the VLANs of
service interfaces.
As shown in Figure 2-43, configure a VGMP group respectively on FW_A and FW_B
to monitor VLAN2.
2. On FW_B, configure FW_B as the standby FW.
Figure 2-43 Configuring VGMP groups to monitoring VLANs (service interfaces connect to
switches)
Switch A FW_A Switch C
GE1/0/3 GE1/0/1
VLAN2 VLAN2
GE1/0/3 GE1/0/1
Switch B FW_B Switch D
Service link
Heartbeat link
VLAN
As shown in Figure 2-44, when the upstream and downstream service interfaces work at
Layer 3 and connect to routers, VLAN monitoring can be implemented only in load balancing
mode. The configuration roadmap is as follows:
1. Configure VGMP groups on both FWs to monitor the VLANs of service interfaces.
As shown in Figure 2-44, configure a VGMP group respectively on FW_A and FW_B
to monitor VLAN2.
2. Configure the same route cost on the interfaces of the upstream or downstream routers.
As shown in Figure 2-44, configure the same OSPF cost on the Router A (Router C) and
Router B (Router D) interfaces connecting to the FWs.

Figure 2-44 Configuring VGMP groups to monitoring VLANs (service interfaces connect to
routers)
Router A FW_A Router C

VLAN2
GE1/0/3 GE1/0/1
OSPF
area
GE1/0/3 GE1/0/1
VLAN2
Router B FW_B Router D
Service link
Heartbeat link
VLAN
Procedure
Step 1 Access the system view from the user view.
system-view
Step 2 Configure VGMP groups to monitor VLANs.

hrp track vlan vlan-id
Step 3 On FW_B, configure FW_B as the standby FW.

hrp standby-device
NOTE
You must run this command in active/standby scenario and must not in load balancing scenario.
----End
Example
As shown in Figure 2-43, when service interfaces work at Layer 2 and connect to switches
(active/standby), the configurations of VLAN monitoring by VGMP groups are as follows:
[FW_A] VLAN 2
[FW_A-vlan-2] port GigabitEthernet 1/0/1
[FW_A-vlan-2] quit
[FW_A] hrp track VLAN 2
[FW_B] VLAN 2
[FW_B-vlan-2] port GigabitEthernet 1/0/1
[FW_B-vlan-2] quit
[FW_B] hrp track VLAN 2
As shown in Figure 2-44, when service interfaces work at Layer 3 and connect to routers
(load balancing), the configurations of VLAN monitoring by VGMP groups are as follows:
[FW_A] VLAN 2


[FW_A-vlan-2] quit
[FW_A] hrp track VLAN 2
[FW_B] VLAN 2
[FW_B-vlan-2] quit
[FW_B] hrp track VLAN 2
2.1.7.2.4 Configuring IP-Link Monitoring

After you configure VGMP groups to monitor IP-link status, the FW can detect the status of
the links that are directly or not directly connected to the FW.
Context
In a hot standby scenario, after you enable IP-link and configure a VGMP group to monitor
IP-link status, if a link that IP-link monitors is faulty, the priority of the VGMP group is
reduced by 2.
Procedure
system-view
Step 2 Enable the IP-link function.

ip-link check enable
Step 3 Create an IP-link and access the IP-link view.

ip-link name ip-link name
Step 4 Set a destination IPv4 address or domain name to be monitored by IP-link.

destination { ip-address | domain-name } [ interface interface-type interface-
number ] [ mode { icmp [ next-hop { nexthop-address | dhcp | dialer } ] | arp } ]
Step 5 Set a destination IPv6 address or domain name to be monitored by IP-link.

ipv6 destination { ipv6-address | domain-name } [ interface interface-type
interface-number ] [ mode { icmpv6 [ next-hop nexthop-ipv6-address ] | ns } ]
Step 6 In the system view, configure a VGMP group to monitor IP-link status.
hrp track ip-link ip-link name [ vsys vsys-name ]
----End
2.1.7.2.5 Configuring BFD Monitoring

After you create BFD sessions and configure VGMP groups to monitor BFD session status,
the FW can rapidly detect link faults on the network and trigger active/standby switchover.
Context
In a hot standby scenario, after you enable BFD and configure a VGMP group to monitor IP-
link status, if a link that BFD monitors is faulty, the priority of the VGMP group is reduced by
2.
You need to configure BFD on the devices at both ends of the link to be monitored.

Procedure
system-view
Step 2 Configure a static BFD session.

1. Enable global BFD and access the BFD global view.
bfd

quit
3. Create a BFD session.

bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [ source-
ip source-ip [ auto ] ]
4. Configure discriminators.
– Run the discriminator local discr-value command to configure a local
discriminator.
– Run the discriminator remote discr-value command to configure a remote
discriminator.
NOTE
The local discriminator on one end of a BFD session must be the same as the remote discriminator
on the other end of the BFD session. Otherwise, the session fails to be established. The local and
remote discriminators cannot be changed once they are created.
5. Commit the configurations.
commit
NOTE
After all necessary parameters (such as the local and remote discriminators) are specified, you
must run the commit command to successfully create a BFD session.
Step 3 Quit to the system view.

quit
Step 4 Configure VGMP groups to monitor BFD status.
hrp track bfd-session bfd-session-id
Parameter bfd-session-id indicates the local discriminator of the BFD session to be monitored.
On hot standby networks, if the hrp track bfd-session command is executed, running the
shutdown command on a BFD session does not trigger active/standby VGMP groups
switchover. Closing a BFD session does not really turning the link down. Therefore, the status
of VGMP groups is not changed.
----End
2.1.7.3 Configuring Heartbeat Interfaces

This section describes how to configure a heartbeat interface on each FW and connect the two
heartbeat interfaces with a heartbeat cable.
Context
The FWs use the heartbeat interfaces to exchange heartbeat packets and synchronize
configuration and status information.

You are advised to directly connect the heartbeat interfaces on the FWs.
You can also use an Eth-Trunk interface as the heartbeat interface to improve network
availability and increase the bandwidth of the heartbeat link.
Procedure
Step 1 Set an IP address for each heartbeat interface.
1. Access the interface view from the system view.
A heartbeat interface can be a Layer-3 Ethernet interface or its subinterface, Layer-3 Eth-
Trunk interface, PoS interface or VLANIF interface.
2. Set an IP address for each heartbeat interface.
ip address ip-address mask-length
You can set a private IP address because the heartbeat interface does not advertise routes
or forward service traffic.
Step 2 Assign the heartbeat interfaces to a security zone.

1. Access the security zone view from the system view.
firewall zone zone-name
You must assign the heartbeat interfaces on the two FWs to the same security zone.
2. Assign the heartbeat interfaces to a security zone.
add interface interface-type interface-number
Step 3 Specify the heartbeat interface in the system view.
hrp interface interface-type interface-number remote { ip-address | ipv6-address }

[ heartbeat-only ]
l The type and ID of the heartbeat interfaces on the FWs must be the same. For example,
if you set GigabitEthernet 1/0/7 as the heartbeat interface on FW_A, you must also set
GigabitEthernet 1/0/7 as the heartbeat interface on FW_B.
l You can run the remote { ip-address | ipv6-address } command to specify the IP address
of the remote heartbeat interface.
l GigabitEthernet 0/0/0 on the MPU cannot be used as the HRP backup channel interface.
l The interface on which the vrrp virtual-mac enable command is executed cannot be
used as the HRP backup channel interface.
l When a service interface is used as a heartbeat link interface and backing up connection
status exhausts too much bandwidth, the total of service traffic and HRP traffic may
overload the service interface, causing unstable hot standby status. You can set parameter
heartbeat-only for the heartbeat link to transmit only HRP packets.
Step 4 Optional: Configure the action as permit in the security policy implemented between the
Local zone and the security zone to which the heartbeat interfaces are assigned.
1. Access the security policy view from the system view.
security-policy

2. Create a security policy rule and access the security policy rule view.
rule name rule-name
3. Specify the source security zone.
source-zone { zone-name &<1-6> | any }
Set zone-name &<1-6> to local and the security zone to which the heartbeat interfaces
are assigned.
NOTE
Specify two security zones for both source-zone and destination-zone to permit bidirectional traffic
between the Local zone and the security zone to which the heartbeat interfaces are assigned.
4. Specify the destination security zone.
destination-zone { zone-name &<1-6> | any }
Set zone-name &<1-6> to local and the security zone to which the heartbeat interfaces
are assigned.
5. Set the action to permit.
action permit
----End
Example
Figure 2-45 Configuring heartbeat interfaces
Router1 NGFW_A Router3

GE1/0/3 GE1/0/1
10.3.0.1/24 10.2.0.1/24
GE1/0/7
10.10.0.1/24
OSPF GE1/0/7 OSPF
10.10.0.2/24
GE1/0/3 GE1/0/1
10.3.1.1/24 10.2.1.1/24
Router2 NGFW_B Router4
As shown in Figure 2-45, FW_A and FW_B are connected using heartbeat interfaces
GigabitEthernet1/0/7, and GigabitEthernet1/0/7 is assigned to the DMZ.
The heartbeat interface configuration on FW_A is as follows:
[FW_A] firewall zone dmz
[FW_A-zone-dmz] add interface GigabitEthernet 1/0/7
[FW_A-zone-dmz] quit
[FW_A] security-policy
[FW_A-policy-security] rule name ha

[FW_A-policy-security-rule-ha] source-zone local dmz

[FW_A-policy-security-rule-ha] destination-zone local dmz
[FW_A-policy-security-rule-ha] action permit
[FW_A-policy-security-rule-ha] quit
[FW_A-policy-security] quit
[FW_A] hrp interface GigabitEthernet 1/0/7 remote 10.10.0.2
The heartbeat interface configuration on FW_B is the same as that on FW_A except the
interface IP address.
2.1.7.4 Enabling Hot Standby

A hot standby network is established only after you enable the hot standby function.
Context
In active/standby mode, after you enable hot standby, the HRP_M command prompt is
displayed on the active device, and the HRP_S command prompt is displayed on the standby
device.
In load balancing mode, both devices process services. The HRP_M command prompt is
displayed on the device on which hot standby is enabled first, and the HRP_S command
prompt is displayed on the other device.
NOTICE
In normal cases, HRP_M or HRP_S is not displayed on both devices at the same time.
You must enable hot standby for the devices to establish active/standby status before you
configure other services, such as NAT and IPSec. Then the configurations and status
information can be synchronized from the active device to the standby device.
Procedure
Step 1 Optional: In the system view, set the Hello interval.
hrp timer hello interval
The default Hello interval for the active VGMP group is 1000 milliseconds.
NOTICE
You are advised to use the default interval. If you set the interval to a smaller value, active/
standby switchover may be triggered when no fault occurs.
If you need to change this value, ensure that the intervals specified on active and standby FWs
are the same. Otherwise, the active/standby status of the FWs may frequently change.
Step 2 Optional: Set the preemption delay for the VGMP group.
hrp preempt [ delay interval ]

The preemption function of the VGMP group is enabled by default, and the default
preemption delay is 60 seconds.
NOTICE
In hot standby mode, if VRRP and dynamic routing protocols run on the FWs and their
upstream and downstream devices, ensure that the preemption delay for the VGMP groups is
longer than the convergence period of the dynamic routing protocols (such as OSPF) to
prevent service interruptions. Or you can disable the preemption function.
Step 3 Optional: Set a delay for TCP session status detection.

hrp tcp link-state check delay delay-time
When the upstream and downstream service interfaces on the FWs work in hot standby mode
at Layer 2 and TCP session status detection is enabled on the FWs, run the hrp tcp link-state
check delay command on active and standby FWs to set a delay for TCP session status
detection. Otherwise, the new active FW upon a switchover fails to establish sessions because
it cannot immediately learn the MAC address table. After a delay is set, TCP session status
detection is postponed on the new active FW after a switchover for a period of time specified
in delay-time, ensuring that the new active FW has enough time to learn the MAC address
table.
By default, TCP session status detection is not delayed.
Step 4 Optional: Configure the key for encrypting specific backup packets (configuration
commands) between the active and standby FWs.
hrp encryption-key
By default, the backup packets are transferred in plain texts. When the heartbeat interfaces of
the two FWs are not directly connected, you are advised to run this command to configure an
encryption key for security reasons. You need to configure the key on both the active and
standby FWs. Ensure that the keys on the two FWs are the same. Otherwise, backup between
the FWs may fail.
Step 5 Optional: Allow configurations on the standby FW.
hrp standby config enable
This command applies only to the standby FW.
This function is disabled by default. All information to be backed up must be configured on
the active FW.
After enabling this function, you can configure all information that can be backed up on the
standby FW, and the configurations can be synchronized to the active FW.
If conflicting settings are configured on the active and standby FWs, the settings configured
later overrides previously configured settings.
Step 6 Enable hot standby in the system view.
hrp enable
You must run this command on both FWs.

Step 7 Optional: Configure the priority in the IP header of heartbeat packets.

hrp ip-packet priority priority-number
The default priority in the IP header of heartbeat packets is 6.
A larger value of priority-number indicates a higher priority. Packets with a higher priority are
forwarded first.
----End
2.1.7.5 Configuring the Backup Mode

This section describes how to configure the backup modes, including automatic, manual, and
quick session backup.
Prerequisites
Enabling Hot Standby is complete before you enable automatic or manual backup.
Context
The FW supports three backup modes shown in Table 2-1.

Table 2-1 Backup modes supported by the FW

Backup Mode Configuration Status Description
Command Information
Automatic backup With automatic When both FWs are Automatic backup is
backup enabled and running properly enabled on the FW
both the active and and status by default. The
standby FWs information that active FW
working properly, needs to be backed automatically
each command that up is generated on synchronizes the
is executed on the the active FW, the configuration
active FW is active FW commands and
synchronized to the automatically status information to
standby FW if the synchronizes the the standby FW.
command can be status information to This function
backed up. The the standby FW. applies to various
commands that Automatic backup hot standby
cannot be backed up of the status networks.
are executed only on information fails
the active FW. when the standby
Commands that can FW is faulty.
be backed up are
configured only on
the active FW.
The commands that
cannot be backed up
can be configured on
both FWs.
Automatic backup
of configuration
commands fails
when the standby
FW is faulty.


Command Information
Manual batch When both the When both the Manual batch
backup active and standby active and standby backup is required
FWs are working FWs are working when the
properly, you can properly, you can configurations
execute commands execute commands between the active
to instruct the active to instruct the active and standby FWs are
FW to synchronize FW to synchronize different.
the configuration the status
commands that can information that can
be backed up to the be backed up to the
standby FW. Then standby FW.
the commands Manual batch
executed on the backup of status
active FW are information fails
executed on the when the standby
standby FW at the FW is faulty.
same time.
Manual batch
backup of
configuration
commands fails
when the standby
FW is faulty.


Command Information
Quick session No backup When the FWs work For timely

backup in load-balancing synchronization,
mode, the forward only status
and return packets information is
may pass through synchronized in
different FWs. If the quick session
session information backup.
is not timely Configuration
synchronized to the command backup is
standby FW, the implemented using
standby FW discards the automatic
packets. backup function.
To resolve this issue, Quick session
you can use quick backup applies to
session backup to load-balancing mode
synchronize the in which both the
status information active and standby
from the active FW devices process
to the standby FW, services.
so that the return
packets can match
the session table on
the standby FW.
Quick session
backup ensures
service continuity on
networks where the
forward and return
paths of packets are
different.
Therefore, you need
to enable quick
session backup on
networks where the
forward and return
paths of packets are
different.
Procedure
l Enable automatic backup of commands and status information in the system view.
hrp auto-sync [ config | connection-status ]
By default, this function is enabled.
When you run the hrp auto-sync command without specifying parameter config or
connection-status, both the commands and status information are automatically backed
up.

l Enable manual batch backup in the user view.
hrp sync [ config | connection-status ]
Enable manual batch backup when automatic backup fails or when configurations are out
of sync.
l Enable quick session backup in the system view.
hrp mirror session enable
When the FWs work in load-balancing mode, the forward and return packets may pass
through different FWs. To ensure service continuity, you must enable quick session
backup to ensure that the session information on one FW is timely synchronized to the
other FW.
When the FWs work in active/standby mode, enabling quick session backup is optional.
NOTE
Quick session backup synchronizes only session status information.
----End
2.1.7.6 Configuring Mirroring Mode

In dual-system hot backup, remote deployment means that you can configure one device and
synchronize the configuration to its peer.
Prerequisites
The following requirements must be met before configuring mirroring mode:
l The peer device is started successfully and works properly.

l Initial value of items such as the interface IP address is not specified on the peer device.
l The hardware configuration and layout on the peer device are the same with those on the
local device.
l The interface monitoring is configured on the two devices though the command hrp
track interface interface-type interface-number.
l The heartbeat interfaces of the two devices must be directly connected. The interface can
be the Eth-trunk interface, but not the subinterface or VLANIF interface.
l The heartbeat interface is configured on the two devices, and the hrp enable command
is configured.
Context
In the mirroring mode, all the configuration commands (except for a few) are configured on
only one device on the dual-system hot backup network because all these configurations are
automatically synchronized to the peer device. Ensure that the peer device is connected to the
local device and started successfully.
Procedure
Step 1 Run the system-view command to access the system view.

Step 2 Run the hrp mirror config enable command to enable the mirroring mode.
Step 3 Run the quit command to exit the system view.
Step 4 Run the hrp sync config command to manually back up the configuration commands in
batches.
----End
2.1.7.7 Binding NAT to VRRP

In load balancing hot standby, if addresses in the NAT address pool or NAT Server reside on
the same subnet as the VRRP group address, you need to manually bind the NAT address pool
or NAT Server to VRRP.
2.1.7.7.1 Binding NAT Address Pools to VRRP Groups

In load balancing hot standby, if addresses in a NAT address pool reside on the same subnet as
the address of a VRRP group, you need to manually bind the NAT address pool to a VRRP
group.
Prerequisites
Before you bind a NAT address pool to a VRRP group, ensure that:
l Hot standby has been configured on the FWs.
l The NAT policy configured on the active FW has been backed up to the standby FW.
Binding NAT Address Pools to VRRP Groups in Active/Standby Mode

As shown in Figure 2-46, upon receiving a packet from an intranet user to the Internet, the
FW translates the packet source IP address to an IP address in the NAT address pool.
If the IP address in the NAT address pool resides on the same subnet as the IP address of the
VRRP group on the upstream interface of the FW, the Router broadcasts an ARP packet to
request for the MAC address corresponding to the address in the NAT address pool after
receiving the return packet from the Internet.
The two FWs have the same NAT address pool configuration. Therefore, both of them reply
the MAC addresses of their upstream interfaces to the Router.
As a result, the Router may sometimes encapsulate return packets with the MAC address of
the upstream interface on FW_A and send the return packets to FW_A, and sometimes
encapsulate return packets with the MAC address of the upstream interface on FW_B and
send the return packets to FW_B, which apparently affects normal service processing.

Figure 2-46 Not binding NAT address pools to VRRP groups
Internet
Router
Broadcasts an ARP GE0/0/1
packet to request for the 1.1.1.100/24
MAC address of 1.1.1.5.
Eth0/0/1 Eth0/0/2
Replies to the Replies to the ARP
ARP request with request with
S1
0000-00d8-9a01 0000-0011-4901.
GE1/0/1 GE1/0/1
1.1.1.2/24 VRRP group 1 1.1.1.3/24
0000-00d8-9a01 1.1.1.1/24 0000-0011-4901
State: Active 0000-5e00-0101 State: Standby
Active FW_A FW_B Standby
NAT address pool VRRP group 2 NAT address pool

1.1.1.5-1.1.1.10 1.1.1.5-1.1.1.10
Intranet user
10.1.1.10/24
Intranet
In such scenarios, you need to bind the NAT address pools to the VRRP groups on the FWs.
As shown in Figure 2-47, after the configuration is complete, only the FW with the active
VRRP group (FW_A) can reply to the ARP request from the Router. FW_A replies the virtual
MAC address (for example, 0000-5e00-0101) of VRRP group 1 in the ARP reply packet to
the Router. As a result, all return packets from the Internet to intranet users are forwarded
only to FW_A.
The system can automatically bind the NAT address pool to the VRRP group with the
smallest VRID if the NAT address pool and VRRP group reside on the same subnet.
Therefore, in active/standby mode, you do not need to manually bind the NAT address
pool to any VRRP groups.

Figure 2-47 Binding NAT address pools to VRRP groups
Internet
Router
packet to request for the 1.1.1.100/24
Eth0/0/1 Eth0/0/2
Replies to the ARP
request with
S1
0000-5e00-0101.
GE1/0/1 GE1/0/1
1.1.1.2/24 VRRP group 1 1.1.1.3/24
0000-00d8-9a01 1.1.1.1/24 0000-0011-4901
Active Standby
FW_A FW_B
NAT address pool NAT address pool

1.1.1.5-1.1.1.10 VRRP group 2 1.1.1.5-1.1.1.10
bound to VRRP group 1 bound to VRRP group 1
Intranet users
10.1.1.10/24
Intranet
Binding NAT Address Pools to VRRP Groups in Load Balancing Mode

As shown in Figure 2-48, in the load balancing mode, intranet users in area 1 set their
gateway address to the address of VRRP group 3, and intranet users in area 2 set their
gateway address to the address of VRRP group 4. Then packets from area 1 to the Internet
will be forwarded to FW_A, and packet source addresses will be translated to addresses in
NAT address pool 1. Similarly, packets from area 2 to the Internet will be forwarded to
FW_B, and packet source addresses will be translated to addresses in NAT address pool 2.
If the IP addresses of VRRP groups 1 and 2 reside on the same subnet as those in NAT
address pools 1 and 2 and the return packets of intranet users in area 1 (or 2) reach the Router,
the Router will request the MAC address corresponding to the IP address in NAT address pool
1 (or 2).
The two FWs then reply the MAC addresses of their upstream interfaces to the Router,
causing MAC address conflict.
In such cases, you need to bind NAT address pool 1 to VRRP group 1 and NAT address pool
2 to VRRP group 2, as shown in Figure 2-48. Then the return packets of users in area 1 are

forwarded only to FW_A, and the return packets of users in area 2 are forwarded only to
FW_B.
Figure 2-48 Binding NAT address pools to VRRP groups
Internet
Router
Broadcasts an ARP
MAC address Port GE0/0/1 packet to request for the
0000-00d8-9a01 Eth0/0/1 1.1.1.1.15/24 MAC address of
0000-5e00-0101 Eth0/0/1 1.1.1.15.
Eth0/0/1 Eth0/0/2
0000-0011-4901 Eth0/0/2
0000-5e00-0102 Eth0/0/2 Replies to the
S1 ARP request with
0000-5e00-0102.
1.1.1.3/24 1.1.1.1/24 1.1.1.4/24
0000-00d8-9a01 0000-5e00-0101 0000-0011-4901
VRRP1: Active VRRP1: Standby
VRRP group 2
VRRP2: Standby VRRP2: Active
1.1.1.2/24
FW_A 0000-5e00-0102
Active FW_B Active
VRRP group 3
NAT address pool 1 10.1.1.1/24 NAT address pool 2
1.1.1.5 1.1.1.10 VRRP group 4 1.1.1.11 1.1.1.15
bound with VRRP group 1 10.1.1.2/24 bound with VRRP group 2
Sets the default Sets the default

gateway to gateway to
10.1.1.1/24. 10.1.1.2/24.
Area 1 Area 2
Procedure
system-view
Step 2 Access the NAT address pool view.

nat address-group group-number [ group-name ]
Step 3 Bind NAT address pools to VRRP groups.

vrrp virtual-router-id

quit

Step 5 Set the respective IP address or port ranges available for the NAT address pools on the FWs.
hrp nat resource { primary-group | secondary-group }
NOTICE
In load balancing scenarios, both FWs process service traffic. If NAPT is configured, the FWs
may have conflicting public ports. If NAT No-PAT is configured, the FWs may have
conflicting public IP addresses. To prevent such conflicts, configure respective NAT resources
(including public IP addresses and ports) for the FWs. You can run the hrp nat resource
primary-group command on the active FW. The standby FW will automatically generate the
hrp nat resource secondary-group command (if you run the hrp nat resource secondary-
group command on the active FW, the standby FW will automatically generate the hrp nat
resource primary-group command).
In active/standby scenarios, you do not need to run the command.
----End
2.1.7.7.2 Binding NAT Server to VRRP

In load balancing hot standby, if a NAT Server address resides on the same subnet as the
address of a VRRP group, you need to manually bind NAT Server to a VRRP group.
Prerequisites
Before you bind NAT server to a VRRP group, ensure that:
l Hot standby has been configured on the FWs.
l The NAT policy configured on the active FW has been backed up to the standby FW.
Binding NAT Server to VRRP Groups in Active/Standby Mode

As shown in Figure 2-49, upon receiving a packet from an Internet user to the intranet, the
FW translates the packet destination IP address to an IP address after NAT Server.
If the NAT Server address resides on the same subnet as the IP address of the VRRP group on
the upstream interface of the FW, the Router broadcasts an ARP packet to request for the
MAC address corresponding to the NAT Server address after receiving the return packet from
the intranet.
The two FWs have the same NAT Server configuration. Therefore, both of them reply the
MAC addresses of their upstream interfaces to the Router.
As a result, the Router may sometimes encapsulate return packets with the MAC address of
the upstream interface on FW_A and send the return packets to FW_A, and sometimes
encapsulate return packets with the MAC address of the upstream interface on FW_B and
send the return packets to FW_B, which apparently affects normal service processing.

Figure 2-49 Not binding NAT Server to VRRP
Internet
Router
Broadcasts an ARP packet GE0/0/1
to request for the MAC 1.1.1.100/24
address of 1.1.1.10.
Eth0/0/1 Eth0/0/2
Replies to the Replies to the ARP
ARP request with S1 request with
0000-00d8-9a01. 0000-0011-4901.
GE1/0/1 GE1/0/1
1.1.1.2/24 VRRP group 1 1.1.1.3/24
0000-00d8-9a01 1.1.1.1/24 0000-0011-4901
Active Standby
FW_A FW_B
nat server global 1.1.1.10 nat server global 1.1.1.10
inside 10.1.1.10 inside 10.1.1.10
VRRP group 2
Server
10.1.1.10/24
Intranet
In such scenarios, you need to bind NAT Server to the VRRP groups on the FWs.
As shown in Figure 2-50, after the configuration is complete, only the FW with the active
VRRP group (FW_A) can reply to the ARP request from the Router. FW_A replies the virtual
MAC address (for example, 0000-5e00-0101) of the VRRP group in the ARP reply packet to
the Router. As a result, all packets from Internet users to the intranet are forwarded only to
FW_A.
The system can automatically bind NAT Server to the VRRP group with the smallest
VRID if the NAT Server and VRRP group reside on the same subnet. Therefore, in
active/standby mode, you do not need to manually bind NAT Server to any VRRP
groups.

Figure 2-50 Binding NAT Server to VRRP
Internet
Router
packet to request for the 1.1.1.100/24 MAC address Port
MAC address of 1.1.1.10. 0000-00d8-9a01 Eth0/0/1
Eth0/0/1 Eth0/0/2 0000-5e00-0101 Eth0/0/1
Replies to the 0000-0011-4901 Eth0/0/2
ARP request with
S1
0000-5e00-0101.
GE1/0/1 GE1/0/1
1.1.1.2/24 VRRP group 1 1.1.1.3/24
0000-00d8-9a01 1.1.1.1/24 0000-0011-4901
Active Standby
FW_A FW_B
nat server global 1.1.1.10 nat server global 1.1.1.10

inside 10.1.1.10 vrrp 1 VRRP group 2 inside 10.1.1.10 vrrp 1
Server
10.1.1.10/24
Intranet
Binding NAT Server to VRRP Groups in Load Balancing Mode

As shown in Figure 2-51, two FWs back up each other in load balancing mode. VRRP group
1 on FW_A is in Active state, and VRRP group 2 on FW_B is also in Active state. To enable
the FWs to forward traffic concurrently, bind NAT Server1 to VRRP group 1 (command: nat
server global 1 1.1.1.10 inside 10.1.1.10 vrrp 1) and NAT Server2 to VRRP group 2
(command: nat server global 1 1.1.1.11 inside 10.1.1.11 vrrp 2). Then the packets from
Internet users to intranet server 1 will be forwarded to FW_A, and the packets from Internet
users to intranet server 2 will be forwarded to FW_B.

Figure 2-51 Binding NAT Server to VRRP groups in load balancing mode
Internet
Router
MAC address Port GE0/0/1 Broadcasts an ARP
0000-00d8-9a01 Eth0/0/1 1.1.1.100/24 packet to request for the
0000-5e00-0101 Eth0/0/1
Eth0/0/1 Eth0/0/2
0000-0011-4901 Eth0/0/2
0000-5e00-0102 Eth0/0/2 Replies to the
S1 ARP request with
0000-5e00-0102.
1.1.1.3/24 1.1.1.1/24 1.1.1.4/24
0000-00d8-9a01 0000-5e00-0101 0000-0011-4901
VRRP1: Active VRRP1: Standby
VRRP group 2
VRRP2: Standby VRRP2: Active
1.1.1.2/24
Active FW_A 0000-5e00-0102 FW_B Stand
by
nat server 1 global 1.1.1.10 nat server 1 global 1.1.1.10
inside 10.1.1.10 vrrp 1 inside 10.1.1.10 vrrp 1
nat server 2 global 1.1.1.11 nat server 2 global 1.1.1.11
inside 10.1.1.11 vrrp 2 inside 10.1.1.11 vrrp 2
Server 1 Server 2
10.1.1.10/24 10.1.1.11/24
Intranet
Procedure
system-view
Step 2 Configure NAT Server.
nat server name [ id ] [ vpn-instance vpn-instance-name1 ] global { global-address [ global-

address-end ] | interface interface-type interface-number } inside host-address [ host-
address-end ] [ vrrp virtual-router-id ] [ no-reverse ] [ vpn-instance vpn-instance-name2 ]
[ description description ]
----End
2.1.7.8 Maintaining Hot Standby

After hot standby configuration is complete, you need to verify the configuration.

Procedure
Step 1 Check command prompts.
After the HRP active/standby relationship is established, the FW whose command line prompt
is HRP_M is the active device, and the NGFW whose command prompt is HRP_S is the
standby device.
Step 2 Verify hot standby configuration based on Table 2-2.
Table 2-2 Checklist for verifying hot standby configuration
No. Man Check Item Check Method Expected

dator Result
y or
Opti
onal
General items
1 Mand Models and software versions of the <sysname> display version □Passed
atory active and standby FWs are the □Not passed
same.
2 Mand Types and slots of interface cards on <sysname> display device □Passed
atory the active and standby FWs are the □Not passed
same.
3 Mand Service interfaces of the active and <sysname> display hrp state □Passed
atory standby FWs are the same. verbose □Not passed
4 Mand Heartbeat interfaces of the active <sysname> display hrp interface □Passed
atory and standby FWs are the same. □Not passed
4.a Optio If the Eth-Trunk is used as the <sysname> display eth-trunk □Passed
nal heartbeat link, member interfaces of trunk-id □Not passed
the active and standby FWs are the
same.
4.b Optio If the service link is used as the <sysname> display current- □Passed
nal heartbeat link, both the heartbeat configuration | include hrp □Not passed
interface and the IP address of the interface
peer heartbeat interface are
specified.
5 Mand Interfaces of the active and standby <sysname> display zone □Passed
atory FWs are assigned to the same □Not passed
security zone.
6 Optio Service interfaces of the active and l IPv4: <sysname> display vrrp □Passed
nal standby FWs are added to the same interface interface-type □Not passed
VRRP group and share the same interface-number
virtual IP address. l IPv6: <sysname> display vrrp6
interface interface-type
interface-number


dator Result
y or
Opti
onal
7 Optio Service interfaces of the active and <sysname> display hrp state □Passed
nal standby FWs are added to VGMP verbose □Not passed
groups.
8 Mand The preemption function of the <sysname> display hrp state □Passed
atory active FW is enabled or disabled. verbose □Not passed
9 Optio If forward and return packets go <sysname> display current- □Passed

nal through different paths, the quick configuration | include hrp mirror □Not passed
session backup function is enabled.
Service interfaces work at Layer 2
10 Mand The upstream and downstream <sysname> display port vlan □Passed
atory service interfaces are added to the [ interface-type interface-number ] □Not passed
same VLAN.
11 Mand VGMP groups are configured to <sysname> display hrp state □Passed
atory monitor the status of service verbose □Not passed
interfaces.
12 Optio If FWs are connected to switches, <sysname> display hrp state □Passed
nal the FWs work in active/standby □Not passed
mode.
13 Optio If FWs are connected to routers, the <sysname> display hrp state □Passed
nal FWs work in load bandaging mode. □Not passed
Service interfaces work at Layer 3
14 Mand IP addresses are set for the interfaces <sysname> display ip interface □Passed
atory of the active and standby FWs. brief □Not passed
15 Optio If FWs are connected to switches, Check the static route configurations □Passed
nal the switches are configured to of the upstream and downstream □Not passed
consider the virtual IP address of the devices.
VRRP group as their next hop.
16 Optio If FWs are connected to routers, <sysname> display ospf [ process- □Passed
nal OSPF runs between the FWs and the id ] brief □Not passed
heartbeat interfaces are not in the
OSPF area.
17 Optio If FWs are connected to routers and <sysname> display current- □Passed
nal work in active/standby mode, route configuration | include hrp ospf- □Not passed
costs of the FWs are adjusted cost
according to the status of hot
standby.


dator Result
y or
Opti
onal
Load balancing
18 Mand Quick session backup is enabled. <sysname> display current- □Passed

atory configuration | include hrp mirror □Not passed
19 Optio The port range of the NAT address <sysname> display current- □Passed
nal pool is specified. configuration | include hrp nat □Not passed
Step 3 In the interface view of the active device, check whether active/standby switchover can be
implemented.
shutdown
After you run the shutdown command on a service interface of the active device, the
interface goes down and other service interfaces are working properly. If the command
prompt on the active device begins with HRP_S, the command prompt on the standby device
begins with HRP_M, and traffic is forwarded properly, the active/standby switchover
succeeds.
After you run the undo shutdown command on the same interface of the active device, the
interface goes up. After the preemption delay expires, the preemption succeeds if the
command prompt on the active device begins with HRP_M, the command prompt on the
standby device begins with HRP_S and traffic is forwarded properly.
Step 4 In the interface view of the active device, restart the active device and check whether the
active/standby failover is performed.
reboot
After you run the reboot command on the active device, the active/standby switchover
succeeds if the command prompt on the standby device begins with HRP_M and packets are
properly forwarded.
The active device continues to work upon restart. After the preemption delay expires, the
preemption succeeds if the command prompt on the active device begins with HRP_M, the
command prompt on the standby device begins with HRP_S and traffic is forwarded
properly.
----End

This section provides examples of how to configure hot standby.

2.1.8.1 Web: Active/Standby Networking in Which the FWs Are Connected In-
line to Layer-2 Upstream and Downstream Devices
This section provides an example of how to configure hot standby in active/standby mode in
which the service interfaces of each FW work at Layer 3 and are directly connected to
switches.
On the network shown in Figure 2-52, the service interfaces of two FWs work at Layer 3 and
are directly connected to switches.
The upstream switch is connected to the carrier network and the public IP address assigned to
the enterprise is 1.1.1.1.
The FWs are expected to work in active/standby mode. Normally, traffic is forwarded by
FW_A. When FW_A goes faulty, FW_B takes over.
Figure 2-52 Active/standby networking in which the service interfaces of each FW work at
Layer 3 and are directly connected to switches
Router
1.1.1.2/24
VRRP group 1
GE1/0/1 1.1.1.1/24 GE1/0/1
10.2.0.1/24 10.2.0.2/24
GE1/0/7
10.10.0.2/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1/24 GE1/0/3
10.3.0.1/24 VRRP group 2 10.3.0.2/24
10.3.0.3/24
Intranet Service link
Heartbeat link

Procedure
Step 1 Complete interfaces and basic network configurations.
1. Configure interfaces on FW_A.
a. Choose Network > Interface.
b. Click GE1/0/1 and set the parameters as follows:
Zone untrust
IPv4
IP Address 10.2.0.1/24
Default Gateway 1.1.1.2
c. Click OK.
d. Repeat the preceding steps to configure GE1/0/3.
Zone trust
IPv4
e. Repeat the preceding steps to configure GE1/0/7.
Zone dmz
IPv4
IP Address 10.10.0.1/24
2. Configure interfaces on FW_B.

Zone untrust
IPv4
Default Gateway 1.1.1.2
c. Click OK.
d. Repeat the preceding steps to configure GE1/0/3.
Zone trust
IPv4

e. Repeat the preceding steps to configure GE1/0/7.

Zone dmz
IPv4
IP Address 10.10.0.2/24
3. Configure the action as permit in the security policy implemented between the Local
zone and the security zone to which the heartbeat interfaces are assigned on FW_A and
FW_B.
NOTE
Only need to configure this security policy, but do not need to.
a. Choose Policy > Security Policy > Security Policy.
b. Click Add.
c. Configure security policy ha and set the parameters as follows:
Name ha
Source Zone local,dmz
Destination Zone local,dmz
Action Permit
d. Click OK.
Step 2 Configure hot standby.
1. Configure hot standby on FW_A.
a. Choose System > High Availability > Dual-System Hot Backup.
b. Click Edit.
c. Select the Enable check box and set the parameters as follows:

d. Click OK.
2. Configure hot standby on FW_B.
b. Click Edit.
d. Click OK.
Step 3 Configure the default route whose next hop is the virtual IP address (10.3.0.3) of VRRP group
2.
Step 4 Configure the security policies.
Security policies configured on FW_A are automatically backed up to FW_B.
1. Choose Policy > Security Policy > Security Policy.

2. Click Add.
3. Configure security policy policy_sec and set the parameters as follows:
Name policy_sec
Source Zone trust
Destination Zone untrust
Action Permit
4. Click OK.
Step 5 Configure a NAT policy to allow intranet users to access the Internet.
NAT policies configured on FW_A are automatically backed up to FW_B.
1. Choose Policy > NAT Policy > Source NAT.

2. Click the NAT Address Pool tab.
3. Click Add.
4. Configure a NAT address pool and set the parameters as follows:

Name 1
IP Address Range 1.1.1.1-1.1.1.1
5. Click OK.
6. Click the Source NAT tab.
7. Click Add.
8. Configure NAT policy policy_nat and set the parameters as follows:
Name policy_nat
Source Zone trust
Action NAT
After NAT
Source Address IP address of the outbound interface
Address pool 1
9. Click OK.
----End
Configuration Verification
Choose System > High Availability > Dual-System Hot Backup to view the operating
status of hot standby.
l Normally, the Current Working Mode of FW_A is Active/Standby Backup and the
Current State is Active. The Current Working Mode of FW_B is Active/Standby
Backup and the Current State is Standby. This shows that traffic is forwarded by
FW_A.
l When FW_A goes faulty, the Current Working Mode of FW_A is Active/Standby
Backup and the Current State is Standby. The Current Working Mode of FW_B is
Active/Standby Backup and the Current State is Active. This shows that traffic is
forwarded by FW_B.

FW_A FW_B
# #
hrp enable hrp enable
hrp standby-device
hrp interface GigabitEthernet 1/0/7 hrp interface GigabitEthernet 1/0/7
# #
interface GigabitEthernet 1/0/1 interface GigabitEthernet 1/0/1
ip address 10.2.0.1 255.255.255.0 ip address 10.2.0.2 255.255.255.0
vrrp vrid 1 virtual-ip 1.1.1.1 vrrp vrid 1 virtual-ip 1.1.1.1
255.255.255.0 active 255.255.255.0 standby
# #
vrrp vrid 2 virtual-ip 10.3.0.3 active vrrp vrid 2 virtual-ip 10.3.0.3
# standby
interface GigabitEthernet 1/0/7 #
ip address 10.10.0.1 255.255.255.0 interface GigabitEthernet 1/0/7
# ip address 10.10.0.2 255.255.255.0
firewall zone trust #
set priority 85 firewall zone trust
add interface GigabitEthernet 1/0/3 set priority 85
# add interface GigabitEthernet 1/0/3
firewall zone untrust #
set priority 5 firewall zone untrust
firewall zone dmz #
set priority 50 firewall zone dmz
# add interface GigabitEthernet1/0/7
ip route-static 0.0.0.0 0.0.0.0 #
GigabitEthernet1/0/1 1.1.1.2 ip route-static 0.0.0.0 0.0.0.0
# GigabitEthernet1/0/1 1.1.1.2
nat address-group 1 #
section 0 1.1.1.1 1.1.1.1 nat address-group 1
# section 0 1.1.1.1 1.1.1.1
security-policy #
rule name ha security-policy
source-zone local rule name ha
source-zone dmz source-zone local
destination-zone local source-zone dmz
destination-zone dmz destination-zone local
action permit destination-zone dmz
rule name policy_sec action permit
source-zone trust rule name policy_sec
destination-zone untrust source-zone trust
action permit destination-zone untrust
# action permit
nat-policy #
rule name policy_nat nat-policy
source-zone trust rule name policy_nat
action nat address-group 1 destination-zone untrust
action nat address-group 1
2.1.8.2 Web: Load Balancing Networking in Which the FWs Are Connected In-
This section provides an example of configuring hot standby in load balancing mode in which
the service interfaces work at Layer 3 and are upstream and downstream connected to
switches.

As shown in Figure 2-53, service interfaces of the two FW devices work at Layer 3, having
upstream and downstream connections to Layer-2 switches.
Now the FW devices are supposed to work in load sharing mode. Normally, both FW_A and
FW_B forward traffic. If either FW fails, the other FW forwards all traffic to ensure service
continuity.
Figure 2-53 Load balancing networking in which the service interfaces work at Layer 3 and
are upstream and downstream connected to switches
GE1/0/1 GE1/0/1
1.1.1.1/24 1.1.1.2/24
GE1/0/7
10.10.0.2/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1/24 GE1/0/3
10.3.0.1/24 10.3.0.2/24
Intranet
Service path
Backup path
Procedure
Step 1 Configure interfaces and perform the basic network configurations.
b. Click GE1/0/1 and set the following parameters:

Security zone untrust
IPv4
c. Click OK.
d. Repeat the preceding steps to set the following parameters for the GE1/0/3
interface.
Security zone trust
IPv4
e. Repeat the preceding steps to set the following parameters for the GE1/0/7
interface.
Security zone dmz
IPv4
IP Address 10.10.0.1/24
2. Configure the interfaces on FW_B.

b. Click GE1/0/1 and set the following parameters:
Zone untrust
IPv4
c. Click OK.
d. Repeat the preceding steps to set the following parameters for the GE1/0/3
interface.
Security zone trust
IPv4
e. Repeat the preceding steps to set the following parameters for the GE1/0/7
interface.
Security zone dmz
IPv4

IP Address 10.10.0.2/24
FW_B.
NOTE

b. Click Add.
Name ha
Action Permit
d. Click OK.
Step 2 Configure dual-system hot standby.
1. Configure dual-system hot standby on FW_A.
b. Click Edit.
d. Click OK.
2. Configure dual-system hot standby on FW_B.
b. Click Edit.

d. Click OK.
Step 3 Configure default routes on the Intranet devices to set virtual IP address 10.3.0.3 of VRRP
backup group 3 as the next hop for certain devices and virtual IP address 10.3.0.4 of VRRP
backup group 4 as the next hop for the other devices.
The security policy configurations on FW_A will be automatically backed up to FW_B.

2. Click Add.
3. Set the following parameters to configure security policies:
Name policy_sec
Source Zone trust
Action Permit
4. Click OK.
----End
Verification
Choose System > High Availability > Dual-System Hot Standby.
l Normally, Working Mode is Load Sharing for both FW_A and FW_B; Current Status
is Active for FW_A and Standby for FW_B. In this case, both FW forward traffic.
l If FW_A malfunctions, Working Mode is Active/Standby Backup for both FW_A and
FW_B; Current Status is Standby for FW_A and Active for FW_B. In this case,
FW_B only forwards traffic.

FW_A FW_B
# #
hrp mirror session enable hrp mirror session enable
# #
vrrp vrid 1 virtual-ip 1.1.1.3 active vrrp vrid 1 virtual-ip 1.1.1.3 standby
vrrp vrid 2 virtual-ip 1.1.1.4 standby vrrp vrid 2 virtual-ip 1.1.1.4 active
# #
vrrp vrid 4 virtual-ip 10.3.0.4 standby
standby vrrp vrid 4 virtual-ip 10.3.0.4 active
# #
# #
firewall zone trust firewall zone trust
set priority 85 set priority 85
add interface GigabitEthernet 1/0/3 add interface GigabitEthernet 1/0/3
# #
firewall zone dmz firewall zone dmz
add interface GigabitEthernet1/0/7 add interface GigabitEthernet1/0/7
# #
firewall zone untrust firewall zone untrust
# #
security-policy security-policy
rule name ha rule name ha
source-zone local source-zone local
source-zone dmz source-zone dmz
destination-zone local destination-zone local
destination-zone dmz destination-zone dmz
action permit action permit
rule name policy_sec rule name policy_sec
source-zone trust source-zone trust
destination-zone untrust destination-zone untrust
which the service interfaces of each FW work at Layer 3 and are directly connected to routers.
are directly connected to routers. The FWs and directly connected routers run OSPF.

Layer 3 and are directly connected to routers
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
GE1/0/7
10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 GE1/0/3
10.3.0.1/24 10.3.1.1/24
OSPF
Service link
Heartbeat link
Procedure
Step 1 Configure interfaces and basic network configurations.
Zone untrust
IPv4
c. Click OK.
d. Repeat the preceding steps to set the parameters of GE1/0/3.
Zone trust
IPv4
e. Repeat the preceding steps to set the parameters of GE1/0/7.

Zone dmz
IPv4
IP Address 10.10.0.1/24

Zone untrust
IPv4
c. Click OK.
Zone trust
IPv4
Zone dmz
IPv4
IP Address 10.10.0.2/24
FW_B.
NOTE

b. Click Add.
Name ha
Action Permit

d. Click OK.
Step 2 Configure OSPF to ensure IP connectivity.

1. Configure OSPF on FW_A.
a. Choose Network > Router > OSPF.
b. Click Add.
c. Create an OSPF process and set the parameters as follows:
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
g. Create an OSPF area and set the parameters as follows:
Area 0.0.0.0
IP Network 10.2.0.0
Mask/Wildcard 255.255.255.0
Mask
h. Click OK.
i. Choose Basic Configuration > Network Settings.
j. Click Add.
k. Create a network and set the parameters as follows:
Area 0.0.0.0
IP Network 10.3.0.0
Mask
l. Click OK.
2. Configure OSPF on FW_B.
b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.

e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.1.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.1.0
Mask
l. Click OK.
b. Click Edit.
d. Click OK.


b. Click Edit.
d. Click OK.
2. Click Add.
Name policy_sec
Source Zone local,trust,untrust
Destination Zone local,trust,untrust
Action Permit
4. Click OK.
----End
FW_A.

forwarded by FW_B.
FW_A FW_B
# #
hrp interface GigabitEthernet 1/0/7 hrp standby-device
remote 10.10.0.2 hrp interface GigabitEthernet 1/0/7
hrp track interface GigabitEthernet remote 10.10.0.1
1/0/1 hrp track interface GigabitEthernet
hrp track interface GigabitEthernet 1/0/1
# 1/0/3
# ip address 10.2.1.1 255.255.255.0
# ip address 10.3.1.1 255.255.255.0
# ip address 10.10.0.2 255.255.255.0
add interface GigabitEthernet1/0/3 set priority 85
firewall zone dmz #
ospf 10 #
area 0.0.0.0 ospf 10
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.1.0 0.0.0.255
security-policy #
source-zone local rule name policy_sec
source-zone trust source-zone local
source-zone untrust source-zone trust
destination-zone local source-zone untrust
destination-zone trust destination-zone local
destination-zone untrust destination-zone trust
action permit

This section provides an example of how to configure hot standby in the load balancing mode
in which the service interfaces of each FW work at Layer 3 and are directly connected to
routers.
are directly connected to routers. The FWs and directly connected routers run OSPF.
The FWs are expected to work in load balancing mode. Normally, both FW_A and FW_B
forward traffic. When one FW goes faulty, the other FW takes over all the traffic load.
Figure 2-55 Load balancing networking in which the service interfaces of each FW work at
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
GE1/0/7
10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 GE1/0/3
10.3.0.1/24 10.3.1.1/24
OSPF
Service link
Heartbeat link
Procedure
Zone untrust

IPv4
c. Click OK.
Zone trust
IPv4

Zone dmz
IPv4
IP Address 10.10.0.1/24

Zone untrust
IPv4
c. Click OK.
Zone trust
IPv4

Zone dmz
IPv4
IP Address 10.10.0.2/24
FW_B.

NOTE

b. Click Add.
Name ha
Action Permit
d. Click OK.
b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.0.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.0.0
Mask

l. Click OK.
b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.1.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.1.0
Mask
l. Click OK.
b. Click Edit.

d. Click OK.
b. Click Edit.
d. Click OK.

2. Click Add.
Name policy_sec

Action Permit
4. Click OK.
----End
l Normally, the Current Working Mode of FW_A is Load Balancing and the Current
State is Active. The Current Working Mode of FW_B is Load Balancing and the
Current State is Standby. This shows that traffic is forwarded by FW_A.
forwarded by FW_B.
l s

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
hrp track interface GigabitEthernet hrp track interface GigabitEthernet
1/0/1 1/0/1
1/0/3 1/0/3
# #
# #
# #
# #
# #
# #
# #
ospf 10 ospf 10
area 0.0.0.0 area 0.0.0.0
network 10.2.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
network 10.3.0.0 0.0.0.255 network 10.3.1.0 0.0.0.255
# #
source-zone untrust source-zone untrust
destination-zone trust destination-zone trust
line to Layer-3 Upstream and Layer-2 Downstream Devices
This section provides an example of how to configure hot standby in the active/standby mode
in which the service interfaces of each FW work at Layer 3 with routers as upstream devices
and switches as downstream devices.

On the network shown in Figure 2-56, the service interfaces of two FWs work at Layer 3,
with routers as upstream devices and switches as downstream devices. The FWs and directly
connected routers run OSPF.
Layer 3 with routers as upstream devices and switches as downstream devices
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
NGFW_A NGFW_B
GE1/0/7 GE1/0/7
GE1/0/3 10.10.0.1 10.10.0.2
GE1/0/3
10.3.0.1/24 10.3.0.2/24
Master VRRP group 1 Slave
10.3.0.3/24
Service link
Heartbeat link
Procedure
Zone untrust
IPv4
c. Click OK.

Zone trust
IPv4
Zone dmz
IPv4
IP Address 10.10.0.1/24

Zone untrust
IPv4
c. Click OK.
Zone trust
IPv4
Zone dmz
IPv4
IP Address 10.10.0.2/24
FW_B.
NOTE

b. Click Add.

Name ha
Action Permit
d. Click OK.
b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.0.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.0.0
Mask
l. Click OK.
b. Click Add.


Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.1.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.0.0
Mask
l. Click OK.
b. Click Edit.

d. Click OK.
b. Click Edit.

d. Click OK.
Step 4 Configure the default route whose next hop is the virtual IP address (10.3.0.3) of VRRP group
1.

2. Click Add.
Name policy_sec
Action Permit
4. Click OK.
----End

FW_A.
forwarded by FW_B.
FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
1/0/1 1/0/1
# #
# #
# standby
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ospf 10 #
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.0.0 0.0.0.255
security-policy #
rule name policy_sec1 action permit
source-zone trust rule name policy_sec1
source-zone local rule name policy_sec2
source-zone untrust source-zone local
destination-zone untrust destination-zone local
action permit

This section provides an example of how to configure hot standby in load balancing mode in
which the service interfaces of each FW work at Layer 3, with routers as upstream devices
and switches as downstream devices.
On the network shown in Figure 2-57, the service interfaces of two FWs work at Layer 3,
with routers as upstream devices and switches as downstream devices. The FWs and directly
connected routers run OSPF.
Layer 3, with routers as upstream devices and switches as downstream devices
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
NGFW_A NGFW_B
GE1/0/7 GE1/0/7
GE1/0/3 10.10.0.1 10.10.0.2
GE1/0/3
10.3.0.1/24 10.3.0.2/24
10.3.0.3/24
VRRP group 2
Slave Master
10.3.0.4/24
Service link
Heartbeat link
Procedure


Zone untrust
IPv4
c. Click OK.
Zone trust
IPv4

Zone dmz
IPv4
IP Address 10.10.0.1/24

Zone untrust
IPv4
c. Click OK.
Zone trust
IPv4

Zone dmz
IPv4
IP Address 10.10.0.2/24

FW_B.
NOTE

b. Click Add.
Name ha
Action Permit
d. Click OK.

b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.0.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0

IP Network 10.3.0.0
Mask
l. Click OK.
b. Click Add.
Type OSPF v2
Process ID 10
d. Click OK.
e. Click .
f. Click Add.
Area 0.0.0.0
IP Network 10.2.1.0
Mask
h. Click OK.
j. Click Add.
Area 0.0.0.0
IP Network 10.3.0.0
Mask
l. Click OK.

b. Click Edit.

d. Click OK.
b. Click Edit.

d. Click OK.
Step 4 Configure the default routes on intranet devices. You can set the next hop of some devices to
the virtual IP address (10.3.0.3) of VRRP group 1 and that of other devices to the virtual IP
address (10.3.0.4) of VRRP group 2.
2. Click Add.
Name policy_sec
Action Permit
4. Click OK.
----End

forwarded by FW_B.

FW_A FW_B
# #
hrp enable hrp mirror session enable
hrp interface GigabitEthernet 1/0/7 hrp enable
hrp mirror session enable remote 10.10.0.1
hrp track interface GigabitEthernet hrp mirror session enable
# 1/0/1
# ip address 10.2.1.1 255.255.255.0
vrrp vrid 1 virtual-ip 10.3.0.3 active ip address 10.3.0.2 255.255.255.0
standby standby
# vrrp vrid 2 virtual-ip 10.3.0.4 active
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ospf 10 #
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.0.0 0.0.0.255
security-policy #
action permit
2.1.8.7 Web: Load Balancing Networking in Which the FWs Are Connected
Transparently to Layer-3 Upstream and Downstream Devices
This section provides an example of how to configure hot standby in load balancing mode in

are directly connected to routers. The uplink and downlink service interfaces of each FW are
added to VLAN2.
The FWs and directly connected routers run OSPF. The FWs transparently transmit OSPF
packets and do not calculate routes.
OSPF
GE1/0/1 VLAN2 GE1/0/7 GE1/0/1

10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 VLAN2 GE1/0/3
OSPF
Service link
Heartbeat link
VLAN
Procedure
b. Click Edit.
d. Click OK.
b. Click Edit.

d. Click OK.
2. Click Add.
Name policy_sec
Source Zone trust,untrust
Destination Zone trust,untrust
Action Permit
4. Click OK.
----End
forwarded by FW_B.

FW_A FW_B
# #
hrp track vlan 2 hrp track vlan 2
# #
vlan batch 2 vlan batch 2
# #
portswitch portswitch
port default vlan 2 port default vlan 2
# #
# #
# #
# #
# #
# #
rule name policy_sec1 rule name policy_sec1
2.1.8.8 Web: Active/Standby Networking in Which the FWs Are Connected Off-
line to Layer-3 Devices (Static Routing Mode)
This section provides an example for configuring the active/standby FWs connected in off-
line mode to the core switches in the data center to process the traffic that the core switches
divert to the FWs using static routing.
As shown in Figure 2-59, two FWs are connected off-line to the core switches in the data
center to secure the data center network. All traffic on the core switches is diverted to the
FWs based on static routes for security checks.

FW_A. If FW_A is faulty, FW_B takes over to ensure service continuity.
Figure 2-59 Networking diagram for configuring hot standby when the FWs are deployed in
off-line mode (using static routing for traffic diversion)
Internet/WAN
Data center core area
GE1/0/7 GE1/0/7
10.10.0.1/24 Heartbeat Link 10.10.0.2/24
10.1.0.1/24 10.1.0.2/24
GE1/0/2
GE1/0/1 GE1/0/1 GE1/0/1 GE1/0/1
GE1/0/2
GE1/0/4
GE1/0/4 GE1/0/3 GE1/0/0
GE1/0/0 GE1/0/3
10.0.0.2/24
10.0.0.1/24
NGFW_A NGFW_B
Server area
192.168.0.0/16
1. As shown in Figure 2-60, if the core switches need to use static routes to divert traffic to
the FWs, you need to configure static routes and set the next hops to the IP addresses of
the FW interfaces. However, the core switches and upstream routers and downstream
aggregation switches run OSPF. Therefore, traffic cannot be diverted to the FWs after

reaching the core switches. Instead, the traffic is directly forwarded to the upstream and
downstream devices.
Therefore, you must configure the virtual routing and forwarding (VRF) function on the
core switches to virtualize each core switch into a public switch (Public) for connecting
to the upstream switch and a virtual switch (VRF) for connecting to the downstream
switch. The two virtualized switches are isolated. Therefore, traffic can be diverted to the
FWs.
Figure 2-60 Configuring VRF on the switches
GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1 GE1/0/1
10.1.0.1/24 Public GE1/0/2 Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0 GE1/0/0
10.0.0.1/24 SW1 SW2 10.0.0.2/24
NGFW_A NGFW_B
2. Figure 2-60 can be abstracted as Figure 2-61. The FWs run static routes with upstream
and downstream switches (Public and VRF). Therefore, you need to configure VRRP
groups on the FWs and switches for them to communicate using the virtual IP addresses
of VRRP groups.
As shown in Figure 2-61, configure static routes on the FWs and set the next hops to the
IP addresses of VRRP groups 3 and 4. Configure a static route on the Public switch and
set the next hop to the IP address of VRRP group 2. Configure a static route on the VRF
switch and set the next hop to the IP address of VRRP group 1.

Figure 2-61 Configuring VRRP on the FWs and switches
OSPF
GE1/0/2 GE1/0/2
Public Public
VLAN3
VRRP4 GE1/0/1 GE1/0/1
10.1.0.6/24 Active VLANIF3 VLANIF3 Standby
10.1.0.4/24 10.1.0.5/24
GE1/0/1 GE1/0/1
VRRP2
Active 10.1.0.1/24 10.1.0.2/24 Standby
10.1.0.3/24
GE1/0/7
10.10.0.1/24
GE1/0/7
VRRP1 10.10.0.2/24
10.0.0.3/24 Active GE1/0/0 GE1/0/0 Standby
10.0.0.1/24 10.0.0.2/24
VRRP3 Active VLANIF2 VLANIF2 Standby

10.0.0.6/24 10.0.0.4/24 10.0.0.5/24
GE1/0/3 GE1/0/3
VLAN2
VRF VRF
GE1/0/4 GE1/0/4
OSPF
NOTE
The core switches run static routes with the FWs and OSPF with other devices. Figure 2-61 lists only
the core switch interfaces related to the FWs.
3. Specify GE1/0/7 on the FW as the heartbeat interface and enable hot standby.
4. Configure security functions, such as security policies, on FW_A. FW_A will
automatically synchronizes its configurations to FW_B. This section describes only
security policy configurations as an example.
Procedure
Step 1 Create static routes.
# This section uses the configurations on FW_A as an example. The configurations on FW_B
are the same as those on FW_A.
1. Choose Network > Router > Static Route.
2. Click Add.
3. Configure a static route (default route) for the upstream direction and set the next hop to
the IP address of VRRP group 4.

Destination Address 0.0.0.0
Mask 0.0.0.0
Next Hop 10.1.0.6
4. Click OK.
5. Configure a static route for the downstream direction and set the destination address to
an address in the server area and the next hop to the IP address of VRRP group 3.
Mask 255.255.0.0
Next Hop 10.0.0.6

b. Click Edit.
d. Click OK.
b. Click Edit.

d. Click OK.
Step 3 Configure security functions.
Configure a security policy on FW_A to allow Internet users to access the server area (subnet:
192.168.0.0/16, port: 80) in the data center. Security policies configured on FW_A will be
automatically backed up to FW_B.
2. Click Add.
3. Configure security policy policy_sec1 and set the parameters as follows:
Name policy_sec1
Source Zone untrust
Destination Zone trust
Destination Address 192.168.0.0/16
Service http
Action Permit
4. Click OK.
Step 4 Configure the core switches.
NOTE
This example describes only the switch configurations related to FW connection.
# Configure Switch1.
[Switch1] ip vpn-instance VRF //Create VRF.
[Switch1-vpn-instance-VRF] ipv4-family
[Switch1-vpn-instance-VRF-af-ipv4] route-distinguisher 100:1
[Switch1-vpn-instance-VRF-af-ipv4] vpn-target 111:1 both
[Switch1-vpn-instance-VRF-af-ipv4] quit
[Switch1-vpn-instance-VRF] quit
[Switch1] vlan 2
[Switch1-vlan2] port gigabitethernet 1/0/3 to 1/0/4 //Add the interface to
VLAN2.
[Switch1-vlan2] quit
[Switch1] interface Vlanif 2
[Switch1-Vlanif2] ip binding vpn-instance VRF //Bind VLANIF2 to VRF.

[Switch1-Vlanif2] ip address 10.0.0.4 24

[Switch1-Vlanif2] vrrp vrid 3 virtual-ip 10.0.0.6 //Create VRRP group 3.
[Switch1-Vlanif2] vrrp vrid 3 priority 120 //Set the priority to 120. The
VRRP group with high priority is active.
[Switch1-Vlanif2] quit
[Switch1] vlan 3
VLAN3.
[Switch1] ip route-static vpn-instance VRF 0.0.0.0 0.0.0.0 10.0.0.3 //
Configure a default route on the VRF and set the next hop to the virtual IP
address of VRRP group 1.
[Switch1] ip route-static 192.168.0.0 255.255.0.0 10.1.0.3 //Configure a
static route on the Public switch and set the next hop to the virtual IP address
of VRRP group 2.
[Switch2] vlan 2
VLAN2.
VRRP group with low priority is standby.
[Switch2] vlan 3
VLAN3.
of VRRP group 2.
----End

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
# #
# standby
# vrrp vrid 2 virtual-ip 10.1.0.3
interface GigabitEthernet 1/0/7 standby
ip address 10.10.0.1 255.255.255.0 #
# interface GigabitEthernet 1/0/7
firewall zone trust ip address 10.10.0.1 255.255.255.0
set priority 85 #
add interface GigabitEthernet 1/0/0 firewall zone trust
# set priority 85
firewall zone dmz add interface GigabitEthernet 1/0/0
set priority 50 #
add interface GigabitEthernet1/0/7 firewall zone dmz
# set priority 50
firewall zone untrust add interface GigabitEthernet1/0/7
set priority 5 #
add interface GigabitEthernet 1/0/1 firewall zone untrust
# set priority 5
ip route-static 0.0.0.0 0.0.0.0 add interface GigabitEthernet 1/0/1
10.1.0.6 #
ip route-static 192.168.0.0 ip route-static 0.0.0.0 0.0.0.0
255.255.0.0 10.0.0.6 10.1.0.6
# ip route-static 192.168.0.0
security-policy 255.255.0.0 10.0.0.6
rule name ha #
source-zone local security-policy
source-zone dmz rule name ha
destination-zone local source-zone local
destination-zone dmz source-zone dmz
action permit destination-zone local
rule name policy_sec1 destination-zone dmz
source-zone untrust action permit
destination-zone trust rule name policy_sec1
destination-address 192.168.0.0 16 source-zone untrust
service http destination-zone trust
action permit destination-address 192.168.0.0 16
service http
action permit
2.1.8.9 Web: Load Balancing Networking in Which the FWs Are Connected Off-
This section provides an example for configuring the load balancing FWs connected in off-

forward traffic. If either FW fails, the other FW forwards all traffic to ensure service
continuity.
Internet/WAN
GE1/0/7 GE1/0/7
10.10.0.1/24 Heartbeat link 10.10.0.2/24
10.1.0.1/24 10.1.0.2/24
GE1/0/2
GE1/0/1 GE1/0/1 GE1/0/1 GE1/0/1
GE1/0/2
GE1/0/4
GE1/0/0 GE1/0/3 GE1/0/4 GE1/0/3 GE1/0/0
10.0.0.1/24 10.0.0.2/24
FW_A FW_B
Server area
192.168.0.0/16

downstream devices.
FWs.

GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1 GE1/0/1
10.1.0.1/24 Public GE1/0/2 Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0 GE1/0/0
10.0.0.1/24 SW1 SW2 10.0.0.2/24
FW_A FW_B
of VRRP groups.
As shown in Figure 2-64, the FWs work in load balancing mode. You need to configure
two equal-cost static routes in the same direction on the FWs and set the next hops
respectively to the IP addresses of the two peer VRRP groups. Configure another two
equal-cost static routes on the Public or VRF switch and set the next hops respectively to
the IP addresses of the two VRRP groups on the FW interfaces.

OSPF
GE1/0/2 GE1/0/2
Public Public
VLAN3
GE1/0/1 GE1/0/1 VRRP group 4
Active 10.1.0.6/24
VLANIF3 VLANIF3 Standby
Standby 10.1.0.4/24 10.1.0.5/24 Active
VRRP group 8
VRRP group 6 10.1.0.8/24
10.1.0.7/24 Standby Active
GE1/0/1 GE1/0/1
Active 10.1.0.1/24 10.1.0.2/24 Standby
10.1.0.3/24 10.10.0.1/24
GE1/0/7
VRRP group 1 10.10.0.2/24
10.0.0.1/24 10.0.0.2/24
VRRP group 5Standby Active
10.0.0.7/24
VRRP group 7
Standby Active
10.0.0.8/24
Active VLANIF2 VLANIF2 Standby
10.0.0.4/24 10.0.0.5/24 VRRP group 3
GE1/0/3 GE1/0/3 10.0.0.6/24
VLAN2
VRF VRF
GE1/0/4 GE1/0/4
OSPF
NOTE
Procedure

2. Click Add.

3. Configure a static route (default route) for the upstream direction and set the next hop to
the IP address of VRRP group 4.
Mask 0.0.0.0
Next Hop 10.1.0.6
4. Click OK.
5. Configure a static route for the downstream direction and set the destination address to
an address in the server area and the next hop to the IP address of VRRP group 3.
Mask 255.255.0.0
Next Hop 10.0.0.6

b. Click Edit.
d. Click OK.
b. Click Edit.

d. Click OK.
2. Click Add.
Name policy_sec1
Source Zone untrust
Service http
Action Permit
4. Click OK.
NOTE
This example describes only the switch configurations related to FW connection.
[Switch1] vlan 2
VLAN2.

[Switch1] vlan 3
VLAN3.
of VRRP group 2.
of VRRP group 6.
[Switch2] vlan 2
VLAN2.
[Switch2] vlan 3
VLAN3.


of VRRP group 2.
of VRRP group 6.
----End

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
# #
# #
# #
# #
# #
# #
# #
ip route-static 0.0.0.0 0.0.0.0 ip route-static 0.0.0.0 0.0.0.0
10.1.0.6 10.1.0.6
10.1.0.8 10.1.0.8
ip route-static 192.168.0.0 ip route-static 192.168.0.0
255.255.0.0 10.0.0.6 255.255.0.0 10.0.0.6
255.255.0.0 10.0.0.8 255.255.0.0 10.0.0.8
# #
destination-address 192.168.0.0 16 destination-address 192.168.0.0 16
service http service http

2.1.8.10 Web: Active/Standby Networking in Which the FWs Are Connected Off-
line to Layer-3 Devices (Dynamic Routing Mode)
divert to the FWs using PBR.
center to secure the data center network and isolate areas on the intranet. All traffic on the
core switches is diverted to the FWs based on PBR for security checks.

Figure 2-65 Networking diagram for configuring hot standby when the s are deployed in off-
line mode (using PBR for traffic diversion)
Internet/WAN
GE1/0/7 GE1/0/7
10.10.0.1/24 Switch1 OSPF GE1/0/4 Switch2 10.10.0.2/24
GE1/0/4
GE1/0/1 GE1/0/3 10.4.0.1/24 10.5.0.1/24 GE1/0/3 GE1/0/1
10.1.0.1/24 10.1.0.2/24 GE1/0/1 10.3.0.2/24 10.3.0.1/24
172.16.3.2/24
GE1/0/1
GE1/0/0 GE1/0/2 172.16.3.1/24 GE1/0/2 GE1/0/0
10.0.0.1/24 10.0.0.2/24 GE1/0/0 GE1/0/0 10.2.0.2/24 10.2.0.1/24
FW_A 172.16.1.1/24 172.16.2.1/24 FW_B
OSPF
Server area
192.168.0.0/16
PBR
Actual traffic
1. As shown in Figure 2-65, the traffic on the core switches is diverted to the FW using
PBR. The FW detects the traffic and injects the traffic back to the core switch. In such
cases, the FW and core switch need to run a dynamic routing protocol (OSPF is used as
an example).
To ensure that traffic is forwarded in the direction shown in Figure 2-65, configure two
OSPF processes on the FW, import them to each other, and then configure another two
OSPF processes on the core switches.

2. Figure 2-65 can be abstracted to Figure 2-66. Figure 2-66 is typical load balancing
networking in which the FWs are connected to Layer-3 devices. You can understand the
relationship between the two figures based on the interface numbers and the actual traffic
direction.
Figure 2-66 Networking diagram for configuring hot standby when the FWs are
connected to Layer-3 devices
GE1/0/4 OSPF GE1/0/4

10.4.0.1/24 10.5.0.1/24
Switch1 Switch2
GE1/0/3 GE1/0/3
10.1.0.2/24 10.3.0.2/24
GE1/0/1 OSPF
GE1/0/1
10.1.0.1/24 10.3.0.1/24
GE1/0/7
10.10.0.1/24
FW_A FW_B
GE1/0/7
GE1/0/0 10.10.0.2/24
GE1/0/0
10.0.0.1/24
OSPF 10.2.0.1/24
GE1/0/2 GE1/0/2
10.0.0.2/24 10.2.0.2/24
GE1/0/1
172.16.3.2/24
Switch1 Switch2
GE1/0/1
172.16.3.1/24
GE1/0/0 GE1/0/0
172.16.1.1/24 OSPF 172.16.2.1/24
PBR
Actual traffic
3. The configuration roadmap is as follows:

a. Configure VGMP groups to monitor upstream and downstream service interfaces.
b. Run the hrp standby-device command on FW_B to configure it as the standby
device.
c. Enable the function of adjusting OSPF costs based on HRP status.
d. Specify the heartbeat interface and enable hot standby.
4. Configure security functions, such as security policies on FW_A. FW_A will

5. Configure the core switches.

a. As shown in Figure 2-66, create two OSPF processes (blue and green cycles in the
figure) and advertise OSPF routes to ensure IP connectivity.
b. Configure PBR for the core switches to divert traffic to the FWs.
Procedure
b. Click Add.
c. Create an OSPF process 100 and set the parameters as follows:
Process ID 100
d. Click OK.
e. Click of the OSPF process 100.
f. Choose Basic Configuration > Area Settings.
g. Click Add.
h. Create the area 0 and set the parameters as follows:
Area 0
IP Network 10.0.0.0
Mask/Wildcard Mask 255.255.255.0
i. Click OK.
j. Click Close.
k. Click Add.
l. Create an OSPF process 200 and set the parameters as follows:
Process ID 200
m. Click OK.
n. Click of the OSPF process 200.
o. Choose Basic Configuration > Area Settings.
p. Click Add.
q. Create the area 0 and set the parameters as follows:
Area 0
IP Network 10.1.0.0

r. Click OK.
s. Click Close.
t. Click of the OSPF process 100.
u. Choose Advanced > Route Import.
v. Click Add.
w. Set the parameters to import OSPF 200 as follows:
Route Type OSPF
Process ID 200
x. Click OK.
y. Click Close.
z. Click of the OSPF process 200.
aa. Choose Advanced > Route Import.
ab. Click Add.
ac. Set the parameters to import OSPF 100 as follows:
Route Type OSPF
Process ID 100
ad. Click OK.

ae. Click Close.
b. Click Add.
Process ID 100
d. Click OK.
g. Click Add.
Area 0
IP Network 10.2.0.0
i. Click OK.

j. Click Close.
k. Click Add.
Process ID 200
m. Click OK.
p. Click Add.
Area 0
IP Network 10.3.0.0
r. Click OK.
s. Click Close.
v. Click Add.
Route Type OSPF
Process ID 200
x. Click OK.
y. Click Close.
ab. Click Add.
Route Type OSPF
Process ID 100
ad. Click OK.

ae. Click Close.



b. Click Edit.
d. Click OK.
b. Click Edit.
d. Click OK.

2. Click Add.
Name policy_sec1
Source Zone untrust
Service http
Action Permit
4. Click OK.
1. Assign IP addresses to interfaces.

Set an IP address for each interface based on Figure 2-65. GE1/0/0 is used as an
example.
<Switch1> system-view
[Switch1] interface GigabitEthernet 1/0/0
[Switch1-GigabitEthernet1/0/0] ip address 172.16.1.1 24
[Switch1-GigabitEthernet1/0/0] quit
2. Configure OSPF.
As shown in Figure 2-66, create two OSPF processes (blue and green cycles in the
figure) and advertise OSPF routes.
[Switch1] router id 3.3.3.3
[Switch1] ospf 100
[Switch1-ospf-100] area 0
[Switch1-ospf-100-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[Switch1-ospf-100-area-0.0.0.0] quit
[Switch1-ospf-100] quit
[Switch1] ospf 200
3. Configure PBR.
Configure policy-based route in for incoming traffic and set the next hop to the IP
address of GE1/0/1 on the FW so that the incoming traffic is diverted to the FW.
[Switch1] acl 3000
[Switch1-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch1-acl-adv-3000] quit
[Switch1] traffic classifier in
[Switch1-classifier-in] if-match acl 3000
[Switch1-classifier-in] quit
[Switch1] traffic behavior in
[Switch1-behavior-in] redirect ip-nexthop 10.1.0.1
[Switch1-behavior-in] quit
[Switch1] traffic policy in
[Switch1-trafficpolicy-in] classifier in behavior in

[Switch1-trafficpolicy-in] quit
[Switch1] interface gigabitethernet 1/0/4
[Switch1-GigabitEthernet1/0/4] traffic-policy in inbound
Configure policy-based route out for outgoing traffic and set the next hop to the IP
address of GE1/0/0 on the FW so that the outgoing traffic is diverted to the FW.
[Switch1] acl 3001
[Switch1-acl-adv-3001] rule permit ip source 192.168.0.0 0.0.0.255
[Switch1] traffic classifier out
[Switch1-classifier-out] if-match acl 3001
[Switch1-classifier-out] quit
[Switch1] traffic behavior out
[Switch1-behavior-out] redirect ip-nexthop 10.0.0.1
[Switch1-behavior-out] quit
[Switch1] traffic policy out
[Switch1-trafficpolicy-out] classifier out behavior out
[Switch1-trafficpolicy-out] quit
[Switch1-GigabitEthernet1/0/0] traffic-policy out inbound

example.
2. Configure OSPF.
[Switch2] ospf 100
[Switch2] ospf 200
3. Configure PBR.
[Switch2] acl 3000

[Switch2] acl 3001
----End

FW_A FW_B
# #
router id 1.1.1.1 router id 2.2.2.2
# #
hrp track interface remote 10.10.0.1
GigabitEthernet1/0/0 hrp track interface
hrp track interface GigabitEthernet1/0/0
# GigabitEthernet1/0/1
# ip address 10.2.0.1 255.255.255.0
# ip address 10.3.0.1 255.255.255.0
# ip address 10.10.0.1 255.255.255.0
firewall zone dmz #
ospf 100 #
import-route ospf 200 ospf 100
area 0.0.0.0 import-route ospf 200
network 10.0.0.0 0.0.0.255 area 0.0.0.0
ospf 200 network 10.2.0.0 0.0.0.255
network 10.1.0.0 0.0.0.255 area 0.0.0.0
# network 10.3.0.0 0.0.0.255
security-policy #
source-zone untrust rule name policy_sec1
destination-zone trust source-zone untrust
destination-address 192.168.0.0 16 destination-zone trust
service http destination-address 192.168.0.0 16
action permit service http
action permit

2.1.8.11 Web: Load Balancing Networking in Which the FWs Are Connected Off-
continuity.

Internet/WAN
GE1/0/7 GE1/0/7
GE1/0/4
GE1/0/1 GE1/0/3 10.4.0.1/24 10.5.0.1/24 GE1/0/3 GE1/0/1
10.1.0.1/24 10.1.0.2/24 GE1/0/1 10.3.0.2/24 10.3.0.1/24
172.16.3.2/24
GE1/0/1
GE1/0/0 GE1/0/2 172.16.3.1/24 GE1/0/2 GE1/0/0
10.0.0.1/24 10.0.0.2/24 GE1/0/0 GE1/0/0 10.2.0.2/24 10.2.0.1/24
NGFW_A 172.16.1.1/24 172.16.2.1/24 NGFW_B
OSPF
Server area
192.168.0.0/16
PBR
Traffic
an example).

direction.

10.4.0.1/24 10.5.0.1/24
Switch1 Switch2
GE1/0/3 GE1/0/3
10.1.0.2/24 10.3.0.2/24
GE1/0/1 OSPF
GE1/0/1
10.1.0.1/24 10.3.0.1/24
GE1/0/7
10.10.0.1/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/0 10.10.0.2/24
GE1/0/0
10.0.0.1/24
OSPF 10.2.0.1/24
GE1/0/2 GE1/0/2
10.0.0.2/24 10.2.0.2/24
GE1/0/1
172.16.3.2/24
Switch1 Switch2
GE1/0/1
172.16.3.1/24
GE1/0/0 GE1/0/0
172.16.1.1/24 OSPF 172.16.2.1/24
PBR
Traffic

b. Enable the function of adjusting OSPF costs based on HRP status.
c. Specify the heartbeat interface and enable hot standby.
d. In load balancing networking, you also need to enable quick session backup.

Procedure
b. Click Add.
Process ID 100
d. Click OK.
g. Click Add.
Area 0
IP Network 10.0.0.0
i. Click OK.
j. Click Close.
k. Click Add.
Process ID 200
m. Click OK.
p. Click Add.
Area 0
IP Network 10.1.0.0
r. Click OK.
s. Click Close.


v. Click Add.
Route Type OSPF
Process ID 200
x. Click OK.
y. Click Close.
ab. Click Add.
Route Type OSPF
Process ID 100
ad. Click OK.

ae. Click Close.
b. Click Add.
Process ID 100
d. Click OK.
g. Click Add.
Area 0
IP Network 10.2.0.0
i. Click OK.
j. Click Close.
k. Click Add.

Process ID 200
m. Click OK.
p. Click Add.
Area 0
IP Network 10.3.0.0
r. Click OK.
s. Click Close.
v. Click Add.
Route Type OSPF
Process ID 200
x. Click OK.
y. Click Close.
ab. Click Add.
Route Type OSPF
Process ID 100
ad. Click OK.

ae. Click Close.

b. Click Edit.

d. Click OK.
b. Click Edit.
d. Click OK.

2. Click Add.
Name policy_sec1

Source Zone untrust
Service http
Action Permit
4. Click OK.
example.
2. Configure OSPF.
[Switch1] ospf 100
[Switch1] ospf 200
3. Configure PBR.
[Switch1] acl 3000

[Switch1] acl 3001


example.
2. Configure OSPF.
[Switch2] ospf 100
[Switch2] ospf 200
3. Configure PBR.
[Switch2] acl 3000

[Switch2] acl 3001

----End

FW_A FW_B
# #
# #
remote 10.10.0.2 remote 10.10.0.1
hrp track interface hrp track interface
GigabitEthernet1/0/0 GigabitEthernet1/0/0
# #
# #
# #
# #
# #
# #
# #
ospf 100 ospf 100
import-route ospf 200 import-route ospf 200
area 0.0.0.0 area 0.0.0.0
network 10.0.0.0 0.0.0.255 network 10.2.0.0 0.0.0.255
ospf 200 ospf 200
area 0.0.0.0 area 0.0.0.0
network 10.1.0.0 0.0.0.255 network 10.3.0.0 0.0.0.255
# #

2.1.8.12 CLI: Active/Standby Networking in Which the FWs Are Connected In-
which the service interfaces of each FW work at Layer 3 and are directly connected to
switches.
are directly connected to switches.
The upstream switch is connected to the carrier network, and the public IP address the carrier
assigns to the enterprise is 1.1.1.1.
Figure 2-69 Networking diagram for configuring active/standby when service interfaces work
at Layer 3 and connect to switches
Router
1.1.1.2/24
VRRP group 1
GE1/0/1 1.1.1.1/24 GE1/0/1
10.2.0.1/24 10.2.0.2/24
GE1/0/7
10.10.0.2/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1/24 GE1/0/3
10.3.0.1/24 VRRP group 2 10.3.0.2/24
10.3.0.3/24
Intranet Service link
Heartbeat link

Procedure
Step 1 Complete basic network configurations on FW_A.
# Set IP addresses for the interfaces.

<FW_A> system-view
# Assign the interfaces to security zones.

[FW_A] firewall zone trust
[FW_A-zone-trust] add interface GigabitEthernet 1/0/3
[FW_A-zone-trust] quit
[FW_A] firewall zone untrust
[FW_A-zone-untrust] add interface GigabitEthernet 1/0/1
[FW_A-zone-untrust] quit
# Create a default route with next hop 1.1.1.2.

[FW_A] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2
# Configure the action as permit in the security policy implemented between the Local zone
and the security zone to which the heartbeat interfaces are assigned.
Step 2 Configure VRRP groups on FW_A.
# Configure VRRP group 1 on upstream service interface GE1/0/1 and set the VRRP group
status to Active. Note that if the interface IP address resides on a different subnet from the
address of the VRRP group, you need to specify a subnet mask when setting the address of
the VRRP group.
[FW_A-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 1.1.1.1 24 active
# Configure VRRP group 2 on downstream service interface GE1/0/3 and set the VRRP
group status to Active.
Step 3 Specify the heartbeat interface and enable hot standby on FW_A.
[FW_A] hrp enable

Step 4 Complete configurations on FW_B to establish the hot standby relationship.

# The configurations on FW_B are the same as those on FW_A except that:
1. The IP addresses of interfaces on FW_B are different from those of interfaces on FW_B.
2. The VRRP group status of service interfaces GE1/0/1 and GE1/0/3 on FW_B must be set
to Standby.
Step 5 Create a security policy on FW_A. After hot standby relationship is established, the security
policy on FW_A will be automatically backed up to FW_B.
# Configure a security policy to allow intranet users to access the Internet.
HRP_M[FW_A] security-policy
HRP_M[FW_A-policy-security] rule name trust_to_untrust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] source-zone trust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] destination-zone untrust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] action permit
HRP_M[FW_A-policy-security-rule-trust_to_untrust] quit
HRP_M[FW_A-policy-security] quit
Step 6 Configure a NAT policy on FW_A. After hot standby relationship is established, the NAT
# Configure a NAT policy to translate source addresses on subnet 10.3.0.0/16 to an IP address
in the NAT address pool (1.1.1.2 to 1.1.1.5) when intranet users access the Internet.
HRP_M[FW_A] nat address-group group1
HRP_M[FW_A-address-group-group1] section 0 1.1.1.2 1.1.1.5
HRP_M[FW_A-address-group-group1] quit
HRP_M[FW_A] nat-policy
HRP_M[FW_A-policy-nat] rule name policy_nat1
HRP_M[FW_A-policy-nat-rule-policy_nat1] source-zone trust
HRP_M[FW_A-policy-nat-rule-policy_nat1] destination-zone untrust
HRP_M[FW_A-policy-nat-rule-policy_nat1] source-address 10.3.0.0 16
HRP_M[FW_A-policy-nat-rule-policy_nat1] action nat address-group group1
----End
Verification
1. Run the display vrrp command on FW_A to check the status information about the
interfaces in the VRRP group. If the following information is displayed, the VRRP group
is successfully created.
HRP_M<FW_A> display vrrp
GigabitEthernet1/0/1 | Virtual Router
1
State :
Active
Virtual IP :
1.1.1.1
Master IP :
10.2.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
Preempt : YES Delay Time : 0
s
TimerRun : 60
s
TimerConfig : 60
s

Auth type :
NONE
Virtual MAC :
0000-5e00-0101
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:00
Last change time : 2015-03-22 16:01:56 UTC+08:00

2
State :
Active
Virtual IP :
10.3.0.3
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0102
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:01
2. Run the display hrp state verbose command on FW_A to check the VGMP group
status. If the following information is displayed, hot standby relationship is successfully
established.
HRP_M<FW_A> display hrp state verbose
Role: active, peer:
standby
Running priority: 46004, peer: 46004
Core state: normal, peer: normal
Backup channel usage:
30%
Stable time: 1 days, 13 hours, 35
minutes
Last state change information: 2015-03-22 16:01:56 HRP core state changed,
old_
state = normal(standby), new_state = normal(active), local_priority = 46002,
peer_priority = 46002.
Configuration:

hello interval:
1000ms
preempt:
60s
mirror configuration:
off
mirror session:
off
track trunk member:
on
auto-sync configuration:
on
auto-sync connection-status:
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
GigabitEthernet1/0/1 vrrp vrid 1: active
3. Ping the Router in the Untrust zone from the PC in the Trust zone, and display session
information on FW_A and FW_B.
HRP_M<FW_A> display firewall session table
Current Total Sessions : 1

icmp VPN: public --> public 10.3.0.10:0[1.1.1.2:10298] --> 1.1.1.10:2048
HRP_M<FW_B> display firewall session table

icmp VPN:public --> public Remote 10.3.0.10:0[1.1.1.2:10298] -->
1.1.1.10:2048
The command output shows that sessions tagged with Remote are created on FW_B,
indicating that sessions are successfully backed up after you configure hot standby.
4. Run the ping 1.1.1.10 -t command on the PC, pull out the cable from GE1/0/1 on
FW_A, and then check whether active/standby switchover is performed and whether
ping packets are discarded. Insert the cable back to GE1/0/1 on FW_A and check again
whether active/standby switchover is performed and whether ping packets are discarded.

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
# #
255.255.255.0 active 255.255.255.0 standby
# #
# standby
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ip route-static 0.0.0.0 0.0.0.0 #
1.1.1.2 ip route-static 0.0.0.0 0.0.0.0
# 1.1.1.2
nat address-group group1 1 #
section 0 1.1.1.2 1.1.1.5 nat address-group group1 1
# section 0 1.1.1.2 1.1.1.5
security-policy #
rule name trust_to_untrust action permit
source-zone trust rule name trust_to_untrust
# action permit
nat-policy #
rule name policy_nat1 nat-policy
source-zone trust rule name policy_nat1
source-address 10.3.0.0 16 destination-zone untrust
action nat address-group group1 source-address 10.3.0.0 16
action nat address-group group1
2.1.8.13 CLI: Load Balancing Networking in Which the FWs Are Connected In-
This section provides an example for configuring hot standby in load balancing mode in
which the service interfaces of each FW work at Layer 3 and directly connect to switches.

As shown in Figure 2-70, the service interfaces of the FWs work at Layer 3 and are directly
connected to switches.
continuity.
Figure 2-70 Networking diagram for configuring load balancing when service interfaces
work at Layer 3 and connect to switches
GE1/0/1 GE1/0/1
1.1.1.1/24 1.1.1.2/24
GE1/0/7
10.10.0.2/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1/24 GE1/0/3
10.3.0.1/24 10.3.0.2/24
Intranet
Service path
Backup path
Procedure
<FW_A> system-view



# Create a default route with next hop 1.1.1.10.

Step 2 Configure VRRP groups on FW_A.
# To implement load balancing, configure two VRRP groups on each service interface and set
the status of one VRRP group to Active and the other to Standby.
# Configure VRRP groups 1 and 2 on upstream service interface GE1/0/1 and set the status of
VRRP group 1 to Active and status of VRRP group 2 to Standby.
[FW_A-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 1.1.1.3 24 active
[FW_A-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 1.1.1.4 24 standby
# Configure VRRP groups 3 and 4 on downstream service interface GE1/0/3 and set the status
of VRRP group 3 to Active and status of VRRP group 4 to Standby.
Step 3 On FW_A, configure quick session backup, specify the heartbeat interface, and enable hot
standby.
# Configure quick session backup on both FWs in case of inconsistent forward and return
packet paths.
[NGFW_A] hrp mirror session enable
# Specify the heartbeat interface and enable hot standby.

[FW_A] hrp enable

Step 4 Complete basic network configurations on FW_B.

# The basic network configurations on FW_B are the same as those on FW_A, except that the
IP addresses of interfaces on FW_B are different from those of the interfaces on FW_A. For
details, see Figure 2-70.
Step 5 Configure VRRP groups on FW_B.
# To implement load balancing, the VRRP group status on FW_B must reflect that on FW_A.
That is, for the same VRRP group, if the status on FW_A is Active, the status on FW_B must
be Standby.
# Configure VRRP groups 1 and 2 on upstream service interface GE1/0/1 and set the status of
VRRP group 1 to Standby and status of VRRP group 2 to Active.
[NGFW_B] interface GigabitEthernet 1/0/1
[NGFW_B-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 1.1.1.3 24 standby
[NGFW_B-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 1.1.1.4 24 active
[NGFW_B-GigabitEthernet1/0/1] quit
of VRRP group 3 to Standby and status of VRRP group 4 to Active.
[NGFW_B] interface GigabitEthernet 1/0/3
[NGFW_B -GigabitEthernet1/0/3] vrrp vrid 3 virtual-ip 10.3.0.3 standby
[NGFW_B -GigabitEthernet1/0/3] vrrp vrid 4 virtual-ip 10.3.0.4 active
[NGFW_B -GigabitEthernet1/0/3] quit
Step 6 On FW_B, configure quick session backup, specify the heartbeat interface, and enable hot
standby.
packet paths.
[NGFW_B] hrp mirror session enable

[FW_B] hrp interface GigabitEthernet 1/0/7 remote 10.10.0.1
[FW_B] hrp enable
HRP_M[FW_A-policy-security] rule name trust_to_untrust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] source-zone trust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] destination-zone untrust
HRP_M[FW_A-policy-security-rule-trust_to_untrust] action permit
HRP_M[FW_A-policy-security-rule-trust_to_untrust] quit
Step 8 Configure a NAT policy on FW_A. After hot standby relationship is established, the NAT
# Configure a NAT policy to translate source addresses on subnet 10.3.0.0/16 to an IP address
in the NAT address pool (1.1.1.5 to 1.1.1.8) when intranet users access the Internet.
HRP_M[FW_A] nat address-group group1
HRP_M[FW_A-address-group-group1] section 0 1.1.1.2 1.1.1.5
HRP_M[FW_A-address-group-group1] quit
HRP_M[FW_A] nat-policy
HRP_M[FW_A-policy-nat] rule name policy_nat1

HRP_M[FW_A-policy-nat-rule-policy_nat1] source-zone trust

HRP_M[FW_A-policy-nat-rule-policy_nat1] destination-zone untrust
HRP_M[FW_A-policy-nat-rule-policy_nat1] source-address 10.3.0.0 16
HRP_M[FW_A-policy-nat-rule-policy_nat1] action nat address-group group1
HRP_M[FW_A-policy-nat-rule-policy_nat1] quit
HRP_M[FW_A-policy-nat] quit
# To prevent port conflicts in address translation on the FWs in load balancing mode,
configure available port ranges respectively on FW_A and FW_B. The configuration on
FW_A is as follows:
HRP_M[NGFW_A] hrp nat resource primary-group
The configuration on FW_B is as follows:

HRP_S[NGFW_B] hrp nat resource secondary-group
Step 9 Configure the switches and PCs.

# Add the three interfaces of the switches to the same VLANs accordingly. For configuration
commands, refer to related documents of the switches.
# On some intranet PCs, specify the IP address (10.3.0.3) of VRRP group 3 as the default
gateway address and on some other intranet PCs, specify the IP address (10.3.0.4) of VRRP
group 4 as the default gateway address to implement load balancing of intranet traffic.
----End
Verification
HRP_M<FW_A> display vrrp
1
State :
Active
Virtual IP :
1.1.1.3
Master IP :
1.1.1.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0101
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:00


2
State :
Standby
Virtual IP :
1.1.1.4
Master IP :
1.1.1.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0102
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:01

3
State :
Active
Virtual IP :
10.3.0.3
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0103
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:02


4
State :
Standby
Virtual IP :
10.3.0.4
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0104
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:03
2. Run the display hrp state verbose command on FW_A to check the VGMP group
status. If the following information is displayed, hot standby relationship is successfully
established.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on

on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
GigabitEthernet1/0/1 vrrp vrid 2: standby
3. Ping the Router in the Untrust zone from the PC in the Trust zone, and display session
information on FW_A and FW_B.
HRP_M<FW_A> display firewall session table

icmp VPN: public --> public 10.3.0.10:0[1.1.1.2:10298] --> 1.1.1.10:2048
HRP_M<FW_B> display firewall session table

icmp VPN:public --> public Remote 10.3.0.10:0[1.1.1.2:10298] -->
1.1.1.10:2048
The command output shows that sessions tagged with Remote are created on FW_B,
indicating that sessions are successfully backed up after you configure hot standby.
4. Run the ping 1.1.1.10 -t command on the PC, pull out the cable from GE1/0/1 on
FW_A, and then check whether active/standby switchover is performed and whether
ping packets are discarded. Insert the cable back to GE1/0/1 on FW_A and check again
whether active/standby switchover is performed and whether ping packets are discarded.

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
hrp nat resource primary-group hrp nat resource secondary-group
# #
vrrp vrid 1 virtual-ip 1.1.1.3 active vrrp vrid 1 virtual-ip 1.1.1.3 standby
vrrp vrid 2 virtual-ip 1.1.1.4 standby vrrp vrid 2 virtual-ip 1.1.1.4 active
# #
# #
# #
# #
# #
# #
1.1.1.10 1.1.1.10
# #
nat address-group group1 1 nat address-group group1 1
section 0 1.1.1.2 1.1.1.5 section 0 1.1.1.2 1.1.1.5
# #
rule name trust_to_untrust rule name trust_to_untrust
# #
nat-policy nat-policy
rule name policy_nat1 rule name policy_nat1
source-address 10.3.0.0 16 source-address 10.3.0.0 16
action nat address-group group1 action nat address-group group1

This section provides an example for configuring hot standby in active/standby mode in
connected to routers. OSPF runs between the FWs and upstream and downstream routers.
at Layer 3 and connect to routers
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
GE1/0/7
10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 GE1/0/3
10.3.0.1/24 10.3.1.1/24
OSPF
Service link
Heartbeat link
Procedure
<FW_A> system-view
[NGFW_A] interface GigabitEthernet 1/0/1
[NGFW_A-GigabitEthernet1/0/1] ip address 10.2.0.1 24
[NGFW_A-GigabitEthernet1/0/1] quit



# Configure OSPF to ensure IP connectivity.

[NGFW_A] ospf 101
[NGFW_A-ospf-10] area 0
[NGFW_A-ospf-10-area-0.0.0.0] network 10.2.0.0 0.0.0.255
[NGFW_A-ospf-10-area-0.0.0.0] quit
[NGFW_A-ospf-10] quit
Step 2 Configure hot standby on FW_A.
# Configure VGMP groups to monitor upstream and downstream service interfaces.

[NGFW_A] hrp track interface GigabitEthernet 1/0/1
# Configure the function of adjusting the OSPF cost based on VGMP status. After you enable
this function, FW_A determines whether it is the active or standby FW when advertising
OSPF routes. If FW_A is the active device, it directly advertises the routes that it have
learned. If it is the standby device, it advertises the routes after increasing the cost values. In
this way, when upstream and downstream routers calculate routes, the next hop is pointed to
the active device, and packets are forwarded to the active device.
[NGFW_A] hrp adjust ospf-cost enable

[NGFW_A] hrp interface GigabitEthernet 1/0/7 remote 10.10.0.2
[NGFW_A] hrp enable
Configurations on FW_B and FW_A are the same except that:
1. The IP addresses of interfaces on FW_B are different from those of interfaces on FW_A.
2. The subnets to which FW_B advertises OSPF routes to are different from those to which
FW_A advertises OSPF routes to.
3. You need to specify the standby device on FW_B (hrp standby-device).

HRP_M[NGFW_A] security-policy
HRP_M[NGFW_A-policy-security] rule name policy_sec
HRP_M[NGFW_A-policy-security-rule-policy_sec] source-zone local trust untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec ] destination-zone local trust
untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec ] action permit
Step 5 Configure the routers.
Configure OSPF on the routers to advertise routes. For configuration commands, refer to the
related documents of the routers.
----End
Verification
Run the display hrp state verbose command on FW_A and FW_B to check the VGMP
group status. If the following information is displayed, hot standby relationship is successfully
established.
Role: active, peer: standby
Backup channel usage: 30%
Stable time: 1 days, 13 hours, 35 minutes
Last state change information: 2015-03-22 16:01:56 HRP core state changed, old_
Configuration:
hello interval: 1000ms
preempt: 60s
mirror configuration: off
mirror session: off
track trunk member: on
auto-sync configuration: on
auto-sync connection-status: on
adjust ospf-cost: on
adjust ospfv3-cost: on
adjust bgp-cost: on
nat resource: off
Detail information:
GigabitEthernet1/0/1: up
ospf-cost: +0
HRP_S<FW_B> display hrp state verbose
Role: standby, peer: active
state = normal(standby), new_state = normal(standby), local_priority = 46004,
Configuration:
preempt: 60s
mirror session: off


adjust bgp-cost: on
nat resource: off
Detail information:
ospf-cost: +65500
FW_A FW_B
# #
hrp track interface GigabitEthernet remote 10.10.0.1
# 1/0/3
# ip address 10.2.1.1 255.255.255.0
# ip address 10.3.1.1 255.255.255.0
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ospf 10 #
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.1.0 0.0.0.255
security-policy #
source-zone local rule name policy_sec
source-zone trust source-zone local
source-zone untrust source-zone trust
destination-zone trust destination-zone local
destination-zone untrust destination-zone trust
action permit

connected to routers. OSPF runs between the FWs and upstream and downstream routers.
continuity.
work at Layer 3 and connect to routers
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
GE1/0/7
10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 GE1/0/3
10.3.0.1/24 10.3.1.1/24
OSPF
Service link
Heartbeat link
Procedure
<FW_A> system-view



[NGFW_A] firewall zone trust
[NGFW_A-zone-trust] add interface GigabitEthernet 1/0/3
[NGFW_A-zone-trust] quit
[NGFW_A] firewall zone dmz
[NGFW_A-zone-dmz] add interface GigabitEthernet 1/0/7
[NGFW_A-zone-dmz] quit
[NGFW_A] firewall zone untrust
[NGFW_A-zone-untrust] add interface GigabitEthernet 1/0/1
[NGFW_A-zone-untrust] quit

[NGFW_A] ospf 10

# Configure VGMP groups to monitor upstream and downstream service interfaces.
packet paths.

[NGFW_A] hrp enable

HRP_M[NGFW_A-policy-security] rule name policy_sec

HRP_M[NGFW_A-policy-security-rule-policy_sec] source-zone local trust untrust

HRP_M[NGFW_A-policy-security-rule-policy_sec ] destination-zone local trust
untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec ] action permit
HRP_M[NGFW_A-policy-security-rule-policy_sec ] quit
----End
Verification
Run the display hrp state verbose command on FW_A and FW_B to check the VGMP
group status. If the following information is displayed, hot standby relationship is successfully
established.
Configuration:
preempt: 60s
mirror session: on
adjust bgp-cost: on
nat resource: off
Detail information:
ospf-cost: +0
Role: standby, peer: active
Configuration:
preempt: 60s
mirror session: on

adjust bgp-cost: on
nat resource: off
Detail information:
ospf-cost: +0
FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
1/0/1 1/0/1
1/0/3 1/0/3
# #
# #
# #
# #
# #
# #
# #
ospf 10 ospf 10
area 0.0.0.0 area 0.0.0.0
network 10.2.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
network 10.3.0.0 0.0.0.255 network 10.3.1.0 0.0.0.255
# #

This section provides an example for configuring hot standby in active/standby mode in
which the service interfaces of each FW work at Layer 3 and are connected to upstream
routers and downstream switches.
As shown in Figure 2-73, the service interfaces of the FWs work at Layer 3 and are
connected to upstream routers and downstream switches. OSPF runs between the FWs and
upstream routers.
at Layer 3 and connect to upstream routers and downstream switches
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
NGFW_A NGFW_B
GE1/0/7 GE1/0/7
GE1/0/3 10.10.0.1 10.10.0.2
GE1/0/3
10.3.0.1/24 10.3.0.2/24
10.3.0.3/24
Service link
Heartbeat link
Procedure
<FW_A> system-view



[NGFW_A] ospf 10
# Configure a VGMP group on FW_A to monitor the upstream interface and configure a
VRRP group on the downstream interface.
# Configure a VGMP group to monitor the upstream service interface.

# Configure VRRP group 1 on downstream service interface GE1/0/3 and set the VRRP
group status to Active.
[NGFW_A-GigabitEthernet1/0/3] vrrp vrid 1 virtual-ip 10.3.0.3 active
# Configure the function of adjusting the OSPF cost based on VGMP status.
[NGFW_A] hrp adjust ospf-cost enable

[NGFW_A] hrp enable

3. The status of VRRP group 1 on downstream service interfaces GE1/0/3 on FW_B must
be set to Standby.
Step 4 Create security policies on FW_A. After hot standby relationship is established, the security
policies on FW_A will be automatically backed up to FW_B.
HRP_M[NGFW_A-policy-security] rule name policy_sec1
HRP_M[NGFW_A-policy-security-rule-policy_sec1] source-zone trust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] destination-zone untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] action permit
HRP_M[NGFW_A-policy-security-rule-policy_sec1] quit
# Configure a security policy to allow FW_A and the upstream router (in the Untrust zone) to
exchange OSPF packets.
HRP_M[NGFW_A-policy-security-rule-policy_sec2] source-zone local untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec2] destination-zone local untrust
Step 5 Configure the routers and switches.

# Configure OSPF on the routers to advertise routes. For configuration commands, refer to the
----End
Verification
HRP_M<NGFW_A> display vrrp
1
State :
Active
Virtual IP :
10.3.0.3
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :

0000-5e00-0101
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:00
2. Run the display hrp state verbose command on FW_A and FW_B to check the VGMP
group status. If the following information is displayed, hot standby relationship is
successfully established.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0
Role: standby, peer:
active
30%

minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +65500

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
1/0/1 1/0/1
# #
# #
# standby
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ospf 10 #
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.0.0 0.0.0.255
security-policy #
action permit
which the service interfaces of each FW work at Layer 3 and are connected to upstream
routers and downstream switches.

As shown in Figure 2-74, the service interfaces of the FWs work at Layer 3 and are
connected to upstream routers and downstream switches. OSPF runs between the FWs and
upstream routers.
continuity.
work at Layer 3 and connect to upstream routers and downstream switches
OSPF
GE1/0/1 GE1/0/1
10.2.0.1/24 10.2.1.1/24
NGFW_A NGFW_B
GE1/0/7 GE1/0/7
GE1/0/3 10.10.0.1 10.10.0.2
GE1/0/3
10.3.0.1/24 10.3.0.2/24
10.3.0.3/24
VRRP group 2
Slave Master
10.3.0.4/24
Service link
Heartbeat link
Procedure

<FW_A> system-view


[NGFW_A-zone- dmz] add interface GigabitEthernet 1/0/7
[NGFW_A-zone- dmz] quit
[NGFW_A-zone- untrust] add interface GigabitEthernet 1/0/1
[NGFW_A-zone- untrust] quit

[NGFW_A] ospf 10

# Configure a VGMP group on FW_A to monitor the upstream interface and configure a
VRRP group on the downstream interface.
# Configure a VGMP group to monitor the upstream service interface.
of VRRP group 1 to Active and status of VRRP group 2 to Standby to implement load
balancing.
[NGFW_A-GigabitEthernet1/0/3] vrrp vrid 1 virtual-ip 10.3.0.3 active
[NGFW_A-GigabitEthernet1/0/3] vrrp vrid 2 virtual-ip 10.3.0.4 standby
# Configure quick session backup.


[NGFW_A] hrp enable

3. To implement load balancing, the VRRP group status on FW_B must reflect that on
FW_A. That is, for the same VRRP group, if the status on FW_A is Active, the status on
FW_B must be Standby.

Step 4 Create security policies on FW_A. After hot standby relationship is established, the security
policies on FW_A will be automatically backed up to FW_B.
HRP_M[NGFW_A-policy-security-rule-policy_sec1] source-zone trust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] destination-zone untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] quit
# Configure a security policy to allow FW_A and the upstream router (in the Untrust zone) to
exchange OSPF packets.
HRP_M[NGFW_A-policy-security-rule-policy_sec2] source-zone local untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec2] destination-zone local untrust
Step 5 Configure the routers and switches.

# Configure OSPF on the routers to advertise routes. For configuration commands, refer to the
----End
Verification
HRP_M<NGFW_A> display vrrp
1
State :
Active
Virtual IP :
10.3.0.3
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0101
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled

Create time : 2015-03-17 17:35:54 UTC

+08:02

2
State :
Standby
Virtual IP :
10.3.0.4
Master IP :
10.3.0.1
PriorityRun :
120
PriorityConfig :
100
MasterPriority :
120
s
TimerRun : 60
s
TimerConfig : 60
s
Auth type :
NONE
Virtual MAC :
0000-5e00-0102
Check TTL :
YES
Config type : vgmp-
vrrp
Backup-forward :
disabled
Create time : 2015-03-17 17:35:54 UTC
+08:03
2. Run the display hrp state verbose command on FW_A and FW_B to check the VGMP
group status. If the following information is displayed, hot standby relationship is
successfully established.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
on
track trunk member:
on

on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0
active
30%
minutes
old_
state = initial, new_state = normal(standby), local_priority = 46004,
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
on
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0

FW_A FW_B
# #
hrp enable hrp mirror session enable
hrp interface GigabitEthernet 1/0/7 hrp enable
hrp mirror session enable remote 10.10.0.1
hrp track interface GigabitEthernet hrp mirror session enable
# 1/0/1
# ip address 10.2.1.1 255.255.255.0
standby standby
# vrrp vrid 2 virtual-ip 10.3.0.4 active
# ip address 10.10.0.2 255.255.255.0
firewall zone dmz #
ospf 10 #
network 10.2.0.0 0.0.0.255 area 0.0.0.0
network 10.3.0.0 0.0.0.255 network 10.2.1.0 0.0.0.255
# network 10.3.0.0 0.0.0.255
security-policy #
action permit
2.1.8.18 CLI: Load Balancing Networking in Which the FWs Are Connected
Transparently to Layer-3 Upstream and Downstream Devices

connected to routers. The upstream and downstream service interfaces on the FWs are added
to VLAN2.
OSPF runs between the upstream and downstream routers. The FWs work as Layer-2 devices
and transparently forward OSPF packets.
continuity.
work at Layer 2 and connect to routers
OSPF
GE1/0/1 VLAN2 GE1/0/7 GE1/0/1

10.10.0.2
NGFW_A NGFW_B
GE1/0/7
GE1/0/3 10.10.0.1 VLAN2 GE1/0/3
OSPF
Service link
Heartbeat link
VLAN
Procedure
# Use the upstream and downstream service interfaces as Layer-2 interfaces and add them to
the same VLAN.
[NGFW_A-GigabitEthernet1/0/1] portswitch
[NGFW_A-GigabitEthernet1/0/3] portswitch
[NGFW_A] vlan 2
[NGFW_A-vlan2] port GigabitEthernet 1/0/1
[NGFW_A-vlan2] port GigabitEthernet 1/0/3
[NGFW_A-vlan2] quit

# Set an IP address for the heartbeat interface.


# To implement load balancing, configure active and standby VGMP groups to monitor the
VLANs.
# Configure a VGMP group to monitor VLAN2.

[NGFW_A] hrp track vlan 2
packet paths.

[NGFW_A] hrp enable
Configurations on FW_B and FW_A are the same except that the heartbeat interface on
FW_B has a different IP address from that on FW_A.
# Configure a security policy to allow OSPF packets transmitted between the upstream and
downstream routers and the packets exchanged between the intranet and Internet.
HRP_M[NGFW_A-policy-security-rule-policy_sec1] source-zone trust untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] destination-zone trust untrust

----End
Verification
# Run the display hrp state verbose command on FW_A to check the VGMP group status. If
the following information is displayed, hot standby relationship is successfully established.
Configuration:
preempt: 60s
mirror session: on
adjust bgp-cost: on
nat resource: off
Detail information:
vlan 2: enabled

FW_A FW_B
# #
hrp track vlan 2 hrp track vlan 2
# #
vlan batch 2 vlan batch 2
# #
# #
# #
# #
# #
# #
# #
2.1.8.19 CLI: Active/Standby Networking in Which the FWs Are Connected Off-

Internet/WAN
GE1/0/7 GE1/0/7
10.10.0.1/24 Heartbeat Link 10.10.0.2/24
10.1.0.1/24 10.1.0.2/24
GE1/0/2
GE1/0/1 GE1/0/1 GE1/0/1 GE1/0/1
GE1/0/2
GE1/0/4
GE1/0/4 GE1/0/3 GE1/0/0
GE1/0/0 GE1/0/3
10.0.0.2/24
10.0.0.1/24
NGFW_A NGFW_B
Server area
192.168.0.0/16

downstream devices.
FWs.
GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1 GE1/0/1
10.1.0.1/24 Public GE1/0/2 Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0 GE1/0/0
10.0.0.1/24 SW1 SW2 10.0.0.2/24
NGFW_A NGFW_B
of VRRP groups.
As shown in Figure 2-78, configure static routes on the FWs and set the next hops to the
IP addresses of VRRP groups 3 and 4. Configure a static route on the Public switch and
set the next hop to the IP address of VRRP group 2. Configure a static route on the VRF
switch and set the next hop to the IP address of VRRP group 1.

OSPF
GE1/0/2 GE1/0/2
Public Public
VLAN3
VRRP4 GE1/0/1 GE1/0/1
10.1.0.6/24 Active VLANIF3 VLANIF3 Standby
10.1.0.4/24 10.1.0.5/24
GE1/0/1 GE1/0/1
VRRP2
Active 10.1.0.1/24 10.1.0.2/24 Standby
10.1.0.3/24
GE1/0/7
10.10.0.1/24
GE1/0/7
VRRP1 10.10.0.2/24
10.0.0.1/24 10.0.0.2/24
VRRP3 Active VLANIF2 VLANIF2 Standby

10.0.0.6/24 10.0.0.4/24 10.0.0.5/24
GE1/0/3 GE1/0/3
VLAN2
VRF VRF
GE1/0/4 GE1/0/4
OSPF
NOTE
Procedure
Step 1 Set interface IP addresses and assign the interfaces to security zones.
# Set IP addresses for the interfaces of FW_A and FW_B based on the parameters in Figure
2-78.
<FW_A> system-view

# Assign the interfaces to security zones. This section uses the configurations on FW_A as an
example. The configurations on FW_B are the same as those on FW_A.
and the security zone to which the heartbeat interfaces are assigned on FW_A and FW_B.

# Configure a static route (default route) for the upstream direction and set the next hop to the
IP address of VRRP group 4.
# Configure a static route for the downstream direction and set the destination address to an
address in the server area and the next hop to the IP address of VRRP group 3.

# Configure VRRP groups on FW_A.
# Configure VRRP groups on FW_B.

# Specify the heartbeat interface and enable hot standby on FW_A.

[FW_A] hrp enable
# Specify the heartbeat interface and enable hot standby on FW_B.

[FW_B] hrp enable


HRP_M[NGFW_A-policy-security-rule-policy_sec1] source-zone untrust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] destination-zone trust
HRP_M[NGFW_A-policy-security-rule-policy_sec1] destination-address 192.168.0.0 16
HRP_M[NGFW_A-policy-security-rule-policy_sec1] service http

NOTE
This example describes only the switch configurations related to firewall connection.
[Switch1] vlan 2
VLAN2.
[Switch1] vlan 3
VLAN3.
of VRRP group 2.
[Switch2] vlan 2
VLAN2.


[Switch2] vlan 3
VLAN3.
of VRRP group 2.
----End
Verification
1. Run the display hrp state verbose command on FW_A and FW_B to view hot standby
status.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off

Detail
information:
active
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
2. Run the display firewall session table command on FW_A and FW_B. You can view
that FW_A has sessions, indicating that the traffic on the core switch is diverted to the
FW, and hot standby in active/standby mode is successfully configured.

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
# #
# standby
# vrrp vrid 2 virtual-ip 10.1.0.3
interface GigabitEthernet 1/0/7 standby
ip address 10.10.0.1 255.255.255.0 #
# interface GigabitEthernet 1/0/7
firewall zone trust ip address 10.10.0.1 255.255.255.0
set priority 85 #
add interface GigabitEthernet 1/0/0 firewall zone trust
# set priority 85
firewall zone dmz add interface GigabitEthernet 1/0/0
set priority 50 #
add interface GigabitEthernet1/0/7 firewall zone dmz
# set priority 50
firewall zone untrust add interface GigabitEthernet1/0/7
set priority 5 #
add interface GigabitEthernet 1/0/1 firewall zone untrust
# set priority 5
ip route-static 0.0.0.0 0.0.0.0 add interface GigabitEthernet 1/0/1
10.1.0.6 #
ip route-static 192.168.0.0 ip route-static 0.0.0.0 0.0.0.0
255.255.0.0 10.0.0.6 10.1.0.6
# ip route-static 192.168.0.0
security-policy 255.255.0.0 10.0.0.6
rule name ha #
source-zone local security-policy
source-zone dmz rule name ha
destination-zone local source-zone local
destination-zone dmz source-zone dmz
action permit destination-zone local
rule name policy_sec1 destination-zone dmz
source-zone untrust action permit
destination-zone trust rule name policy_sec1
destination-address 192.168.0.0 16 source-zone untrust
service http destination-zone trust
action permit destination-address 192.168.0.0 16
service http
action permit
2.1.8.20 CLI: Load Balancing Networking in Which the FWs Are Connected Off-

continuity.
Internet/WAN
GE1/0/7 GE1/0/7
10.10.0.1/24 Heartbeat link 10.10.0.2/24
10.1.0.1/24 10.1.0.2/24
GE1/0/2
GE1/0/1 GE1/0/1 GE1/0/1 GE1/0/1
GE1/0/2
GE1/0/4
GE1/0/0 GE1/0/3 GE1/0/4 GE1/0/3 GE1/0/0
10.0.0.1/24 10.0.0.2/24
FW_A FW_B
Server area
192.168.0.0/16

downstream devices.
FWs.

GE1/0/7 GE1/0/7
10.10.0.1/24 10.10.0.2/24
GE1/0/1 GE1/0/1
10.1.0.1/24 Public GE1/0/2 Public 10.1.0.2/24
GE1/0/1 GE1/0/2 GE1/0/1
GE1/0/3 GE1/0/4 GE1/0/3
VRF GE1/0/4 VRF
GE1/0/0 GE1/0/0
10.0.0.1/24 SW1 SW2 10.0.0.2/24
FW_A FW_B
of VRRP groups.
As shown in Figure 2-81, the FWs work in load balancing mode. You need to configure
two equal-cost static routes in the same direction on the FWs and set the next hops
respectively to the IP addresses of the two peer VRRP groups. Configure another two
equal-cost static routes on the Public or VRF switch and set the next hops respectively to
the IP addresses of the two VRRP groups on the FW interfaces.

OSPF
GE1/0/2 GE1/0/2
Public Public
VLAN3
GE1/0/1 GE1/0/1 VRRP group 4
Active 10.1.0.6/24
VLANIF3 VLANIF3 Standby
Standby 10.1.0.4/24 10.1.0.5/24 Active
VRRP group 8
VRRP group 6 10.1.0.8/24
10.1.0.7/24 Standby Active
GE1/0/1 GE1/0/1
Active 10.1.0.1/24 10.1.0.2/24 Standby
10.1.0.3/24 10.10.0.1/24
GE1/0/7
VRRP group 1 10.10.0.2/24
10.0.0.1/24 10.0.0.2/24
VRRP group 5Standby Active
10.0.0.7/24
VRRP group 7
Standby Active
10.0.0.8/24
Active VLANIF2 VLANIF2 Standby
10.0.0.4/24 10.0.0.5/24 VRRP group 3
GE1/0/3 GE1/0/3 10.0.0.6/24
VLAN2
VRF VRF
GE1/0/4 GE1/0/4
OSPF
NOTE
Procedure
2-81.
<FW_A> system-view


# Configure two equal-cost static routes (default routes) for the upstream direction and set the
next hop s respectively to the IP addresses of VRRP groups 4 and 8.
# Configure two static routes for the downstream direction and set the destination addresses to
addresses in the server area and the next hops respectively to the IP addresses of VRRP
groups 3 and 7.

# Configure VRRP groups on FW_A.
# Configure VRRP groups on FW_B.

# Specify the heartbeat interface and enable hot standby on FW_A.


[FW_A] hrp enable
# Specify the heartbeat interface and enable hot standby on FW_B.

[FW_B] hrp enable
packet paths.
[FW_A] hrp mirror session enable
[FW_B] hrp mirror session enable


NOTE
This example describes only the switch configurations related to firewall connection.
[Switch1] vlan 2
VLAN2.
[Switch1] vlan 3
VLAN3.

of VRRP group 2.
of VRRP group 6.
[Switch2] vlan 2
VLAN2.
[Switch2] vlan 3
VLAN3.
of VRRP group 2.
of VRRP group 6.
----End
Verification
status.
Role: active, peer:

standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
on
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
active
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s

off
mirror session:
on
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
FW, and hot standby in load balancing mode is successfully configured.

FW_A FW_B
# #
remote 10.10.0.2 remote 10.10.0.1
# #
# #
# #
# #
# #
# #
# #
10.1.0.6 10.1.0.6
10.1.0.8 10.1.0.8
255.255.0.0 10.0.0.6 255.255.0.0 10.0.0.6
255.255.0.0 10.0.0.8 255.255.0.0 10.0.0.8
# #

2.1.8.21 CLI: Active/Standby Networking in Which the FWs Are Connected Off-

Internet/WAN
GE1/0/7 GE1/0/7
GE1/0/4
GE1/0/1 GE1/0/3 10.4.0.1/24 10.5.0.1/24 GE1/0/3 GE1/0/1
10.1.0.1/24 10.1.0.2/24 GE1/0/1 10.3.0.2/24 10.3.0.1/24
172.16.3.2/24
GE1/0/1
GE1/0/0 GE1/0/2 172.16.3.1/24 GE1/0/2 GE1/0/0
10.0.0.1/24 10.0.0.2/24 GE1/0/0 GE1/0/0 10.2.0.2/24 10.2.0.1/24
FW_A 172.16.1.1/24 172.16.2.1/24 FW_B
OSPF
Server area
192.168.0.0/16
PBR
Actual traffic
an example).

direction.

10.4.0.1/24 10.5.0.1/24
Switch1 Switch2
GE1/0/3 GE1/0/3
10.1.0.2/24 10.3.0.2/24
GE1/0/1 OSPF
GE1/0/1
10.1.0.1/24 10.3.0.1/24
GE1/0/7
10.10.0.1/24
FW_A FW_B
GE1/0/7
GE1/0/0 10.10.0.2/24
GE1/0/0
10.0.0.1/24
OSPF 10.2.0.1/24
GE1/0/2 GE1/0/2
10.0.0.2/24 10.2.0.2/24
GE1/0/1
172.16.3.2/24
Switch1 Switch2
GE1/0/1
172.16.3.1/24
GE1/0/0 GE1/0/0
172.16.1.1/24 OSPF 172.16.2.1/24
PBR
Actual traffic

b. Run the hrp standby-device command on FW_B to configure it as the standby
device.
c. Enable the function of adjusting OSPF costs based on HRP status.
d. Specify the heartbeat interface and enable hot standby.


Procedure
2-83.
<FW_A> system-view
Step 2 Configure OSPF.
# Configure OSPF on FW_A.

[FW_A] router id 1.1.1.1
[FW_A] ospf 100
[FW_A-ospf-100] area 0
[FW_A-ospf-100-area-0.0.0.0] network 10.0.0.0 0.0.0.255
[FW_A-ospf-100-area-0.0.0.0] quit
[FW_A-ospf-100] quit
[FW_A] ospf 200
[FW_A] ospf 100
[FW_A-ospf-100] import-route ospf 200
[FW_A] ospf 200
# Configure OSPF on FW_B.

[FW_B] router id 2.2.2.2

[FW_B] ospf 100
[FW_B-ospf-100] area 0
[FW_B-ospf-100-area-0.0.0.0] network 10.2.0.0 0.0.0.255
[FW_B-ospf-100-area-0.0.0.0] quit
[FW_B-ospf-100] quit
[FW_B] ospf 200
[FW_B] ospf 100
[FW_B-ospf-100] import-route ospf 200
[FW_B] ospf 200

# Configure hot standby on FW_A.
1. Configure VGMP groups to monitor upstream and downstream service interfaces.
2. Enable the function of adjusting OSPF costs based on HRP status.

3. Specify GE1/0/7 as the heartbeat interface and enable hot standby.

[FW_A] hrp enable
# Configure hot standby on FW_B.

2. Configure FW_B as the standby device.



[FW_B] hrp enable




example.
2. Configure OSPF.
[Switch1] ospf 100
[Switch1] ospf 200
3. Configure PBR.
[Switch1] acl 3000
[Switch1] acl 3001


example.
2. Configure OSPF.
[Switch2] ospf 100
[Switch2] ospf 200
3. Configure PBR.
[Switch2] acl 3000
[Switch2] acl 3001
----End

Verification
status.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0
active
30%
minutes
old_
Configuration:

hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +65500
FW, and hot standby in active/standby mode is successfully configured.

FW_A FW_B
# #
# #
hrp track interface remote 10.10.0.1
hrp track interface GigabitEthernet1/0/0
# GigabitEthernet1/0/1
# ip address 10.2.0.1 255.255.255.0
# ip address 10.3.0.1 255.255.255.0
# ip address 10.10.0.1 255.255.255.0
firewall zone dmz #
ospf 100 #
network 10.0.0.0 0.0.0.255 area 0.0.0.0
ospf 200 network 10.2.0.0 0.0.0.255
network 10.1.0.0 0.0.0.255 area 0.0.0.0
# network 10.3.0.0 0.0.0.255
security-policy #
source-zone untrust rule name policy_sec1
destination-zone trust source-zone untrust
destination-address 192.168.0.0 16 destination-zone trust
service http destination-address 192.168.0.0 16
action permit service http
action permit

2.1.8.22 CLI: Load Balancing Networking in Which the FWs Are Connected Off-
continuity.

Internet/WAN
GE1/0/7 GE1/0/7
GE1/0/4
GE1/0/1 GE1/0/3 10.4.0.1/24 10.5.0.1/24 GE1/0/3 GE1/0/1
10.1.0.1/24 10.1.0.2/24 GE1/0/1 10.3.0.2/24 10.3.0.1/24
172.16.3.2/24
GE1/0/1
GE1/0/0 GE1/0/2 172.16.3.1/24 GE1/0/2 GE1/0/0
10.0.0.1/24 10.0.0.2/24 GE1/0/0 GE1/0/0 10.2.0.2/24 10.2.0.1/24
NGFW_A 172.16.1.1/24 172.16.2.1/24 NGFW_B
OSPF
Server area
192.168.0.0/16
PBR
Traffic
an example).

direction.

10.4.0.1/24 10.5.0.1/24
Switch1 Switch2
GE1/0/3 GE1/0/3
10.1.0.2/24 10.3.0.2/24
GE1/0/1 OSPF
GE1/0/1
10.1.0.1/24 10.3.0.1/24
GE1/0/7
10.10.0.1/24
NGFW_A NGFW_B
GE1/0/7
GE1/0/0 10.10.0.2/24
GE1/0/0
10.0.0.1/24
OSPF 10.2.0.1/24
GE1/0/2 GE1/0/2
10.0.0.2/24 10.2.0.2/24
GE1/0/1
172.16.3.2/24
Switch1 Switch2
GE1/0/1
172.16.3.1/24
GE1/0/0 GE1/0/0
172.16.1.1/24 OSPF 172.16.2.1/24
PBR
Traffic

b. Enable the function of adjusting OSPF costs based on HRP status.
c. Specify the heartbeat interface and enable hot standby.
d. In load balancing networking, you also need to enable quick session backup.

Procedure
2-85.
<FW_A> system-view

# Configure OSPF on FW_A.
[FW_A] ospf 100
[FW_A] ospf 200
[FW_A] ospf 100
[FW_A] ospf 200
# Configure OSPF on FW_B.

[FW_B] ospf 100

[FW_B] ospf 200
[FW_B] ospf 100
[FW_B] ospf 200

# Configure hot standby on FW_A.


[FW_A] hrp enable
4. Enable quick session backup.

[FW_A] hrp mirror session enable
# Configure hot standby on FW_B. Hot standby configurations on FW_B and FW_A are the
same except that a different remote parameter is specified in heartbeat interface
configuration.


[FW_B] hrp enable
4. Enable quick session backup.

[FW_B] hrp mirror session enable




example.
2. Configure OSPF.
[Switch1] ospf 100
[Switch1] ospf 200
3. Configure PBR.
[Switch1] acl 3000
[Switch1] acl 3001


example.
2. Configure OSPF.
[Switch2] ospf 100
[Switch2] ospf 200
3. Configure PBR.
[Switch2] acl 3000
[Switch2] acl 3001
----End

Verification
status.
Role: active, peer:
standby
30%
minutes
old_
Configuration:
hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0
active
30%
minutes
old_
Configuration:

hello interval:
1000ms
preempt:
60s
off
mirror session:
off
track trunk member:
on
on
on
adjust ospf-cost:
on
adjust ospfv3-cost:
on
adjust bgp-cost:
on
nat resource:
off
Detail
information:
ospf-cost: +0
FW, and hot standby in load balancing mode is successfully configured.

FW_A FW_B
# #
# #
remote 10.10.0.2 remote 10.10.0.1
# #
# #
# #
# #
# #
# #
# #
ospf 100 ospf 100
area 0.0.0.0 area 0.0.0.0
network 10.0.0.0 0.0.0.255 network 10.2.0.0 0.0.0.255
ospf 200 ospf 200
area 0.0.0.0 area 0.0.0.0
network 10.1.0.0 0.0.0.255 network 10.3.0.0 0.0.0.255
# #

This section describes the reference information about hot standby.

This section describes hot standby specifications.
Function Sub-function Description
Hot standby Hot standby mode The FW supports two hot standby
modes:
l Active/Standby mode: The
active device processes
services, and the standby
device stays in standby state. If
an error occurs on the interface
or link of the active device or
the active device is faulty, the
standby device becomes active
and takes over services.
l Load balancing mode:
Normally, both devices process
services. If one device is faulty,
the other device takes over all
the services to ensure service
continuity.
VRRP interface types The VRRP interface can be a

Layer-3 GE interface or its
subinterface, Layer-3 Eth-Trunk
interface or its subinterface, or
VLAN interface.
Virtual IP address of Both FWs use the virtual IP

VRRP address to communicate with other
devices. For upstream and
downstream devices, the two FWs
are one device and the interface
address is the virtual IP address.
Simple and MD5 The FW authenticates the received

authentication for VRRP and transmitted VRRP packets.
Virtual MAC address If an upstream or downstream

device is a Layer-4 device, you
need to enable the virtual MAC
address function.
VGMP monitoring of The FW provides VGMP groups

device faults to monitor interface and device
faults. The VGMP group decreases
its priority by 2 if an interface fault
occurs.

VGMP control of active/ VGMP status determines FW

standby switchover status. The two FWs compare their
VGMP priorities to determine
whether to switch their device
(VGMP) status.
Adjusting OSPF/ The active FW (VGMP status is

OSPFv3/BGP cost based Active) advertises routes properly.
on VGMP status The standby FW (VGMP status is
Standby) increases the cost of each
route to be advertised by 65500.
Controlling VLANs to The VLAN on the active FW

forward traffic based on (VGMP status is Active) can
VGMP status forward traffic, whereas the
VLAN on the standby FW (VGMP
status is Standby) cannot forward
traffic
Enabling/Disabling the The original active FW recovers

preemption function and from a fault and becomes active
setting the preemption again through preemption.
delay
VRRP6/VGMP6 The FW supports VRRP and

VGMP for IPv6.
Configuration backup The FW can back up the following

configurations:
l Policies: security, NAT,
bandwidth management
policies, attack defense,
blacklist, and ASPF
l Objects: address, region,
service, application, user,
authentication server, time
range, signature, and security
configuration profile (such as
antivirus and intrusion
prevention profiles)
l Network: new logical interface,
security zone, DNS, and IPSec
l System: administrator and log
configuration

Data (status information) The FW can back up data of the

backup following features:
l Session table
l Server map
l Static ARP table
l Blacklist
l Whitelist
l PAT-based port mapping table
l NO-PAT-based address
mapping table
l Layer-2 forwarding table (static
MAC backup)
l AAA user table (default user
admin is not backed up)
l PKI certificate, CRL
l IPSec
– IKE and IKEv2 SAs
– Batch tunnel backup
– Real-time backup of tunnels
and sequence numbers
Type of the heartbeat The heartbeat interface can be a

interface Layer-3 GE interface or its
subinterface, Layer-3 Eth-Trunk
interface or its subinterface, or
VLAN interface.
Backup mode l Automatic backup: The active

FW automatically synchronizes
configuration commands and
status information to the
standby FW.
l Manual batch backup: When
the configurations on the active
and standby FWs are out of
sync, you need to enable
manual batch backup.
l Quick session backup: The FW
synchronizes only session
status information.
Mutual backup of -
configurations between
the active and standby
devices

Networking with You need to enable quick session

inconsistent forward and backup on networks with
return packet paths inconsistent forward and return
packet paths.
Hot standby Maximum number of VRRP 255

groups on each interface
Maximum number of virtual 1

IP addresses for each VRRP
group on each interface.
Preemption delay The default preemption

delay is 60 seconds.

This section describes the versions and changes in the hot standby feature.
Version Description

This section describes the standards and protocols used in hot standby.
The standards are as follows:
l RFC2338: Virtual Router Redundancy Protocol (version number One 1998)

l RFC3768: Virtual Router Redundancy Protocol (version number Two 2004)
The protocols are as follows:
l VRRP: Virtual Router Redundancy Protocol

l VGMP: VRRP Group Management Protocol
l HRP: Huawei Redundancy Protocol
2.1.10 Hot Standby FAQ

This section provides FAQs about hot standby.

2.1.10.1 FAQs on Failures
Why Are Services Interrupted After the Original Active FW Preempts?

Services are normal after the active/standby switchover, but services are interrupted after the
active FW preempts. because the cause might be that the network has not converged or
sessions are not completely backed up. Besides, if a switch fails, its interfaces may go up and
down repeatedly when the switch restarts. If the FW preempts during the process, services
may be interrupted.
In this case, adjust the preemption delay of the original active FW.
Why Does Active/Standby Switchover Occurs Repeatedly?

Check service interface status. If the interfaces go up and down repeatedly, active/standby
switchover occurs repeatedly. If service interfaces are normal, the constant status change may
be caused by different heartbeat intervals on the two FWs. In this case, change the intervals to
the same value.
Why Does Not the Original Active FW Preempt After Recovery?

Possible causes are as follows:
l The preemption function is disabled.
l The preemption conditions are not met. The original active FW does not immediately
preempt after recovery. Instead, it waits for a delay before the preemption. The
preemption delay is set to avoid unstable active/standby switchover.
Why Are the Same Configuration Items Arranged in Different Orders in the
Configuration Files on the Active and Standby FWs?
The fault usually results from inconsistent initial configurations of the two FWs. You need to
delete the configuration items in different orders and reconfigure them.
You are advised to configure hot standby based on the default settings.
Why Are the Session Tables on the Active and Standby FWs Different?
Check the status of the heartbeat link. If the heartbeat link fails, the sessions on the active FW
cannot be synchronized to the standby FW.
If the automatic session backup function is disabled, the sessions on the two FWs are
different. Even when the automatic session backup function is enabled, sessions are not
synchronized in real time. Only when the sessions to be synchronized are detected by the
session aging thread, the sessions are synchronized to the standby FW. Therefore, established
sessions are synchronized to the standby FW after a period (about 10 seconds).
The FWs do not back up sessions of the following types when the automatic session backup
function is enabled:
l Sessions to the FW
l Half-open TCP connections
l Sessions in which the first packets are UDP packets and subsequent packets are not (such
as the BitTorrent packets)

What Are the Differences Between Automatic Session Backup and Quick
Session Backup? Why Is Quick Session Backup Required in Case of Inconsistent
Forward and Return Paths?
The differences between quick session backup and automatic session backup are as follows:
l In quick session backup, sessions are synchronized to the standby FW immediately after
being set up. In automatic session backup, only sessions that require backup and are
detected by the session aging thread are synchronized to the standby FW.
l The quick session backup function can back up half-open TCP sessions and sessions to
the FW.
If the forward and return paths are different, enable quick session backup to ensure that the
sessions on the two FWs are the same.
Why Does TCP Services Are Interrupted When Quick Session Backup Is
Enabled in Case of Inconsistent Forward and Return Paths?
In case of inconsistent forward and return paths, the synchronization may fail or be delayed
due to traffic bursts, result in service delay or interruption. For example, one FW forwards
TCP SYN packets, and the other forwards TCP ACK packets. If the session table is not
synchronized, ACK packets may be discarded.
If this condition poses great impacts on services, disable stateful inspection on the FW.
Why Are the Sessions of the Current Active FW Marked with Remote After
Active/Standby Switchover?
The sessions marked with remote are synchronized from the original active FW. After active/
standby switchover, the synchronized sessions are still marked with remote until the sessions
age out.
Why Cannot I Run Commands on the Standby FW?

After the active/standby status is set up on the two FWs, you can run the commands that can
be automatically synchronized only on the active FW, not on the standby FW.
To manually run these commands on the standby FW, run the undo hrp auto-sync config
command to disable the automatic synchronization function.
Why Are Not Commands Executed on the Active FW Synchronized to the

Standby FW?
If you disable the automatic configuration synchronization function, the configurations are not
synchronized. Besides, not all commands can be synchronized. For example, interface and
routing configurations cannot be synchronized.
For commands that can be synchronized, see 2.1.9.1 Specifications.

Why Does the Log Server Receive NAT Session Logs from Both the Active and
Standby FWs?
Log configuration on the active FW is automatically synchronized to the standby FW. If the
log configuration is synchronized to the standby FW, the standby FW sends logs to the log
server.
You can perform the following steps to negate the log configuration on the standby FW:
1. Run the undo hrp auto-sync config command to disable the automatic configuration
synchronization function.
2. Negate the log server configuration.
3. Run the hrp auto-sync config command to enable the automatic configuration
synchronization. This ensures that subsequent configurations can be automatically
synchronized to the standby FW.
Why Does the Ping to the Virtual IP Address of the VRRP Group Fail?
Possible causes are as follows:
l VRIDs conflict.
l Pinging virtual IP addresses is disabled. Huawei FWs enable you to ping virtual IP
addresses by default. If ping virtual IP address is disabled, run the vrrp virtual-ip ping
enable command.
2.1.10.2 FAQs on Configurations
Must I Set a Physical IP Address for the Uplink or Downlink Interface After I
Set the Virtual IP Address of the VRRP Group on the Interface?
Yes. You must set a physical IP address for the interface before you set the virtual IP address
of the VRRP group on the interface. The physical IP address and the virtual address of the
VRRP group can reside on the same network segment or different network segments.
Why Does the Active FW Require a Longer Preemption Delay Than That on the
Standby FW?
Preemption starts after the original active FW recovers. If the preemption delay of the active
FW is too shorter than that on the standby FW, the active FW may switch status before the
session entries on the standby FW are completely synchronized to the active FW. As a result,
some services may be interrupted. Therefore, the active FW requires a longer preemption
delay.
Preemption does not start after the standby FW recovers. Therefore, preemption delay is
meaningless for the standby FW and you can use the default preemption delay.
Does a Long Preemption Delay for the Active FW Affect the Failure Response
Speed?
No. When the active FW fails, services are immediately switched to the standby FW. After
the original active FW recovers, it must wait for the preemption delay before preempting
During the process, the standby FW is working. Therefore, the long preemption delay of the
active FW does not affect the failure response speed.

How Does the Adjustment to the VGMP Hello Interval Affect the Network?
VGMP Hello packets are known as heartbeat packets and are used to check the operating
status of the active and standby FWs. If the standby VGMP group does not receive any
VGMP Hello packet from the peer within three consecutive Hello intervals, the standby
VGMP group considers that the peer fails and switches to the active state. Therefore, a short
VGMP Hello interval enhances the failure response speed of the FW.
However, if the interval is too short, the hot standby status may become unstable. When the
CPU is overloaded, the task of sending VGMP Hello packets cannot be scheduled, resulting
in a false switchover. Therefore, the default value, 1 second, is recommended.
What Should I Pay Attention to When Configuring IPSec VPN in Hot Standby
Networking?
l The service interfaces (including VLANIFs) connecting the FW to upstream and
downstream devices must work at Layer 3.
l Before configuring IPSec VPN, you must establish the hot standby status. The IPSec
policy configured on the active FW will be automatically synchronized to the standby
one. On the standby FW, you only need to apply the synchronized IPSec policy to the
outgoing interface.
l If the FW serves as the initiator of the IPSec tunnel, you must run the tunnel local ip-
address command to specify the virtual IP address of the VRRP group as the IP address
for IPSec negotiation.
l Configure DPD to delete the tunnel that has been established on the original active FW
after an active/standby switchover to prevent packet loss.
Must the Heartbeat Interfaces Be Directly Connected?

No. The heartbeat interfaces can be connected either directly or through intermediate devices,
such as switches or routers. Directly connection between the heartbeat interfaces is
recommended.
Is Security Policy Required to Permit Packets Between the Local Zone and the
Zone Where the Heartbeat Interface Resides?
Yes.
2.1.10.3 FAQs on Mechanism
On a Hot Standby Network, What Do Designated Active Device and Designated

Standby Device Stand For?
On load balancing networks, the two FWs are active. Therefore, if both FWs synchronize
commands to each other, command overwrite or conflict problems may occur. To centrally
manage the configurations of the two FWs, you need to configure the designated active and
standby devices.
On load balancing networks, the sender of the configuration backup command is the
designated active device (identified by HRP_M), and the receiver is the designated standby
device (identified by HRP_S).

Configuration commands can be synchronized only from the designated active device to the
designated standby device, and status information is mutually backed up between the two
devices.
On load balancing networks, the FW with a smaller sysname American Standard Code for
Information Interchange (ASCII) character is the designated active device. For example, when
FW_A and FW_B share load, FW_A is the designated active device.
On a Hot Standby Network, Which Packets Are Used by Upstream and

Downstream Layer-2 Devices to Learn the Port for the Virtual MAC Addresses?
The active FW periodically sends VRRP advertisement messages. The source MAC address
of these packets is the virtual MAC address of the VRRP group. The upstream and
downstream Layer-2 devices learn the port mapped to the virtual MAC address through the
VRRP advertisement messages.
On a Hot Standby Network, Which Packets Are Used by Upstream and

Downstream Layer-3 Devices to Learn the MAC Address of a Virtual IP Address?
To forward packets, upstream and downstream Layer-3 devices look up the routing table for
the next hop, that is, the virtual IP address of the VRRP group. Then the devices look up the
ARP table for the MAC address of the virtual IP address. If no match is found, the devices
broadcast an ARP request. Only the active FW responds to ARP requests.
In the ARP reply, the source MAC address in the Ethernet header is the MAC address of the
interface that sends the reply, and the sender MAC address in the reply payload is the virtual
MAC address of the VRRP group. Upstream and downstream Layer-3 devices learn the
virtual MAC address mapped to the virtual IP address through the ARP reply.
Upstream and downstream use the virtual MAC address as the destination MAC address
when sending packets to the FW.
What Are Differences Between hrp auto-sync and hrp sync?

hrp auto-sync automatically synchronizes all subsequent configurations and status entries to
the standby FW. hrp auto-sync is enabled by default. The command does not synchronize
existing configurations and status entries.
hrp sync immediately synchronizes the existing configurations and status entries from the
active FW to the standby FW. The command takes effect immediately and does not affect
subsequent configurations and status entries.
How Interface Priorities Are Calculated?

The priority of the VGMP group is lowered by 2 only when:
l A physical interface in the VGMP group fails.
l A Eth-Trunk interface in the VGMP group fails. The failure of a member interface of the
Eth-Trunk does not affect the priority of the VGMP group.
l A member interface of the VGMP group in a VLAN fails.
l A member interface of an IP-Link fails.

Why Cannot Easy IP Be Deployed with Hot Standby?

You cannot specify the VRID in Easy IP implementation. In normal cases, the active FW uses
the IP address of its outgoing interface as the public address to set up sessions. After active/
standby switchover, the standby FW also uses the IP address of its outgoing interface as the
public address. In this case, the sessions synchronized from the active FW do not match the IP
address of the outgoing interface on the standby FW. As a result, services are interrupted.
2.1.10.4 FAQs on Specifications
How Long Does Active/Standby Switchover Take?

The duration of active/standby switchover depends on the triggering condition.
l If the active/standby switchover is caused by an interface or link fault, the switchover
completes within milliseconds.
l If the active/standby switchover is caused by a device failure, the switchover completes
within five heartbeat intervals.
Can the Virtual IP Address of a VRRP Group Be Added to the NAT Address
Pool?
Yes. If the virtual IP address of the VRRP group is the only public IP address for the intranet,
you can add the virtual IP address to the NAT address pool.
Can the Virtual MAC Address Be Used as the Source MAC Address of Packets?
Yes. By default, the FW uses the physical MAC address to encapsulate Layer-3 service
packets. To use the virtual MAC address, run the vrrp virtual-mac enable command in the
interface view.
On a Hot Standby Network, Can Upstream and Downstream Devices Be Layer-4

Switches?
Yes. In this situation, the FW must use the virtual MAC address to encapsulate service
packets. Otherwise, services are interrupted after active/standby switchover.
By default, the FW uses the physical MAC address to encapsulate service packets. On hot
standby networks, Layer-4 switches establish a connection status table to record the source
MAC address (that is, the MAC address of the service interface on the active FW) in the
packets forwarded by the FW. Layer-4 switches forward packets based on the connection
status table. During active/standby switchover, Layer-4 switches do not automatically refresh
MAC addresses in the connection status table. Therefore, packets are sent to the original
active FW if the physical MAC address is used. As a result, services are interrupted.
If the virtual MAC address is used, the connection status tables on Layer-4 switches record
the virtual MAC address. After active/standby switchover, Layer-4 switches can forward
service packets to the new active FW.
Corresponding to the virtual IP address, the virtual MAC address is automatically generated
based on the VRID in either of the following formats:
l IPv4: 00-00-5E-00-01-{VRID}

l IPv6: 00-00-5E-00-02-{VRID}
On a service interface of the FW, you can run the following command to use the virtual MAC
address to encapsulate service packets.
[sysname] interface GigabitEthernet 1/0/1
[sysname-GigabitEthernet1/0/1] vrrp virtual-mac enable
2.1.10.5 FAQs on Miscellaneous Issues
How Can I Test Active/Standby Switchover?

Active/standby switchover is performed once the priorities of VGMP groups change. The
priorities cannot be manually changed. You can use either of the following methods to change
the priorities:
l Manually disable a member interface in the VRRP group on the active FW to trigger
active/standby switchover. If the switchover fails, services are interrupted.
l Manually disable an idle interface on the active FW and add the interface to the VGMP
group.
How to Update the Signature Database on the Standby FW?

The commands for online signature database updates can be automatically synchronized to
the standby FW. The active and standby FWs download the latest signature database as
scheduled from the security center. Besides, when you manually update the signature database
on the active FW, the update is automatically implemented on the standby FW.
Does Hot Standby Require a License?

The hot standby function does not require a license.
If other services require a license, ensure that licenses with the same specifications are
activated on both the active and standby FWs. Otherwise, services may be interrupted.
2.2 IP-Link
connected to the device.
2.2.1 Overview
This section describes the definition and purpose of IP-link.
Definition
With IP-link, the FW periodically transmits ICMP echo request or ARP request to a specific
destination IP address and waits for the response. If not receiving any response packet within
the specified interval (three seconds by default), the FW considers that the current link is
faulty, and then performs link-related subsequent operations. If receiving three successive
response packets within the time limit specified later through the link that is considered to be
faulty, the FW considers that the link recovers, and then performs the subsequent operations
of link recovery.

Objective
connected to the FW to ensure service continuity.

This chapter describes the application scenarios of IP-link.
2.2.2.1 IP-Link in the Hot Standby Environment

This section describes the IP-link in the hot standby environment.
If the FW works in dual-system hot backup networking and identifies a fault affecting
services, you can set the VGMP management group to monitor IP-link. In this case, the FW
adjusts the priority of VGMP management group to trigger the active/standby switchover,
ensuring service continuity.
After VGMP management group monitor IP-link is configured, the status of links or
interfaces indirectly connected to the FW can be identified. As shown in Figure 2-86, if the
interface (with IP address 1.1.1.1/24) of the router in the Untrust zone is faulty and IP-link is
enabled, the system automatically triggers the active/standby switchover to ensure service
continuity.
Figure 2-86 IP-link in the hot standby environment

FW_A
1.1.1.1/24
Trust Untrust
FW_B
2.2.2.2 IP-Link in the Static Routing Environment

This section describes the IP-link in the static routing environment.
When IP-link identifies link faults, the FW adjusts its static routes accordingly to ensure that
the link used every time enjoys the highest priority and is routable, which keeps service
continuity.
As shown in Figure 2-87, when intranet users access the Internet, two static routes are
available. One route is bound with IP-link. When this link is faulty, the traffic is switched to
the other, ensuring the normal running of services.

Figure 2-87 IP-link in the static routing environment

Router 1
10.10.1.2/24
IP-Link 1
FW
Switch
Intranet GE1/0/2 GE1/0/1
192.168.1.1/24 10.10.1.1/24
10.10.1.3/24
Router 2
2.2.2.3 IP-Link in the Policy-based Routing Environment

This section describes the IP-link in the policy-based routing environment.
PBR cannot sense the reachability of the links of the next hop and default next hop. When the
link of the next hop or default next hop is unreachable and the device adopts the settings of
the next hop or the default next hop for packet forwarding, the packet forwarding may fail.
Interworking PBR with IP-link solves the previous problem and improves the flexibility of
PBR applications and the dynamic network environment sensation of PBR. When you
configure IP-link, ensure that the destination IP address of the monitored link is consistent
with the specified next hop or default next hop of PBR and associate policy-based routes with
IP-link. IP-link monitors the reachability of the links of the next hop and default next hop and
dynamically determines the availability of policy-based routes by IP-link state.
l When an IP-link is Up, the link is reachable, and the settings of the next hop and default
next hop take effect for packet forwarding.
l When an IP-link is Down, the link is unreachable, and the settings of the next hop and
default next hop are invalid, packet forwarding is performed without the policy-based
route. The device continues to search for routes to forward packets and ensure service
continuity.
2.2.2.4 IP-Link in the DHCP Environment

This section describes the IP-link in the DHCP environment.
As shown in Figure 2-88, the FW serves as the egress gateway and adopts dual uplinks. On
the active link, the FW serves as the DHCP client to obtain an IP address. The standby link is
a PPPoE one. When IP-link is performed on the link behind the DHCP server, the FW obtains
the gateway address as the next hop for IP-link. If you identify that the link after the DHCP
server is faulty, switch the FW to the backup link.

Figure 2-88 IP-link in the DHCP environment
DHCP Client DHCP Server

IP-Link 1
Intranet
FW
PPPoE
2.2.3 Configuring IP-Link Using the Web UI

This section describes how to configure IP-link on the web UI.
Prerequisites
Before you configure IP-link, ensure that:
l IP addresses are specified for interfaces.

l Interfaces are assigned to security zones.
Procedure
Step 1 Choose System > High Availability > IP-Link.
Step 2 Click to create IP-link on the Add IP-Link page.
IP-Link ID Indicates an IP-link ID, which uniquely identifies an IP-link.
Detected IP/Domain Indicates the destination IP address or domain name to be

detected.
Bound Interface Indicates the interface type and interface number of the local
end of the IP-link.
Transmit interval Indicates the interval for sending detection packets.
Max failed times Indicates the maximum allowed timeout counts.
Step 3 Click OK.
----End
2.2.4 Configuring IP-Link Using the CLI

This section describes how to configure IP-link.

Context
connected to the FW to ensure service continuity.
Procedure
system-view
Step 2 Enable the IP-link check function.
Step 3 Set up an IP-link and access the IP-link view.
ip-link name ip-link-name [ vpn-instance vpn-instance-name ]
Step 4 Configure the destination IPv4 address or domain name for IP-link.
destination { ip-address | domain-name } [ interface interface-type interface-number ]
[ mode { icmp [ next-hop { nexthop-address | dhcp | dialer } ] | arp } ]
Step 5 Configure the destination IPv6 address or domain name for IP-link.
ipv6 destination { ipv6-address | domain-name } [ interface interface-type interface-
number ] [ mode { icmp6 [ next-hop nexthop-ipv6-address ] | ns } ]
Step 6 Configure the source address for IP-link.
source-ip
Step 7 Configure the IP-link detection interval.

tx-interval interval
Step 8 Configure the maximum number of IP-link detection timeout failures.

times times
The FW sends a detection packet every interval seconds. If the FW does not receive any
response packet after sending times packets, the FW considers the detected link to be faulty.
Step 9 Configure the minimum number of UP members affecting IP-link status.
least active-linknumber link-number
The minimum number of UP members affecting IP-link status needs to be configured when
IP-link is used to detect multiple destination addresses or domain names. If the actual number
of detected destination addresses or domain names is lower than the minimum number, the IP-
link becomes down.
----End
Follow-up Procedure
Run the display ip-link verbose command to view the detailed information about IP-link.
<sysname> display ip-link verbose
Current Total Ip-link Number : 1

-------------------------------------------------------------------------------
Name : test
Index : 2
Enable Flag : 1
Vrf : public/0
Member Number : 2
Tx-interval (default is 5) : 5
Times (default is 3) : 3
Least active-linknumber (default is 1) : 1
State : up
Init State Number : 0
DOWN State Number : 0
UP State Number : 2
-------------------------------------------------------------------------------
State : up
Destination Type/Destination Info : IP/1.1.1.1
Protocol/Port : icmp/0
Healthcheck detect index : 8
State : up
Destination Type/Destination Info : IP/2.2.2.2
Protocol/Port : icmp/0
Out If Index : GigabitEthernet1/0/1
Healthcheck detect index : 9
-------------------------------------------------------------------------------

This section describes the configuration examples of IP-link.
2.2.5.1 CLI: Example for Configuring the Interworking Between IP-Link and Hot
Standby
This section describes how to configure the interworking between IP-link and hot standby
according to the example for configuring active/standby hot standby.
Network Requirements
The FW's upstream and downstream devices are routers. FW_A and FW_B work in active/
standby mode
Figure 2-89 shows the networking diagram. The detailed description is as follows:
l OSPF is applied among the router and two FWs. The router sends service packets to the
Active FW according to the route calculation result.
l The upstream and downstream ports of the FW are added to the same link-group. The
route convergence rate is accelerated if a link is faulty.
l FW monitor the network egress through the interworking function between IP-link and
hot standby. When the network egress on the link where FW_A resides is down, FW_B
can switch to active device and the service packets are sent to FW_B.

Figure 2-89 Networking diagram of the example for configuring the interworking between
IP-link and hot standby
GE1/0/1 GE1/0/3
FW_A
10.100.10.2/24 10.100.30.2/24
Trust 1.1.1.1/24 Untrust
GE1/0/2 GE1/0/2
10.100.50.2/24 10.100.50.3/24
GE1/0/1 GE1/0/3 2.2.2.2/24

PC1 10.100.20.2/24 10.100.40.2/24 PC2
192.168.1.3/24 FW_B 3.3.3.3/24
IP-Link
Procedure
Step 1 Complete the basic configurations on FW_A.
# Set an IP address for GigabitEthernet 1/0/1.

<FW_A> system-view
# Add GigabitEthernet 1/0/1 to the Trust zone.


# Add GigabitEthernet 1/0/3 to the Untrust zone.

# Add GigabitEthernet 1/0/1 and GigabitEthernet 1/0/3 to the same link-group management
group.
[FW_A-GigabitEthernet1/0/1] link-group 1
[FW_A-GigabitEthernet1/0/3] link-group 1


# Add GigabitEthernet 1/0/2 to the DMZ.

# Run the OSPF dynamic routing protocol on FW_A.

[FW_A] ospf 101
# Enable the function of adjusting the related cost value of OSPF according to the HRP status.
NOTICE
When the FW is deployed on the OSPF network to work in hot standby mode, this command
must be configured.
[FW] hrp adjust ospf-cost enable
# Configure the VGMP group to monitor the status of interfaces.

# Configure the IP-link to monitor the network egress.

[FW_A] ip-link check enable
[FW_A] ip-link name test
[FW_A-iplink-test] destination 1.1.1.1 interface GigabitEthernet 1/0/3
[FW_A-iplink-test] quit
# Configure the interworking between IP-link and hot standby. When the network egress is
down, the IP-link status turns to down and the priority of VGMP group reduces 2.
[FW_A] hrp track ip-link test
# Configure an HRP backup channel.

# Enable HRP.
[FW_A] hrp enable
Step 2 Configure the hot standby function on FW_B.

The configuration on the FW_B is similar to that on the FW_A. The differences are as
follows:
l The IP addresses of interfaces on FW_B should be different from those of interfaces on
FW_A; moreover, the IP addresses of the service interfaces corresponding to FW_B and
FW_A should not be on the same network segment.
l When OSPF is executed on FW_B, the route to the network segment directly connected
to the service interface on FW_B should be advertised.

l Run the hrp standby-device command on FW_B to specify FW_B as a standby device.
Step 3 Configure the interworking between IP-link and hot standby on FW_B.
[FW_B] ip-link check enable
[FW_B] ip-link name test
[FW_B-iplink-test] destination 2.2.2.2 interface GigabitEthernet 1/0/3
[FW_B-iplink-test] quit
[FW_B] hrp track ip-link test
Step 4 Enable automatic backup of configuration commands, and configure the interzone packet-
filtering rules for the Trust zone and Untrust zone on FW_A.
NOTE
When HRP is enabled on both FW_A and FW_B, and the automatic backup of configuration commands
is enabled on FW_A, the security policy configured on FW_A are automatically backed up to FW_B.
# Enable automatic backup of configuration commands.

HRP_M[FW_A] hrp auto-sync config
# Configure security policy to ensure that the users on network segment 192.168.1.0/24 can
access the Untrust zone.
HRP_M[FW_A-policy-security] rule name ha
HRP_M[FW_A-policy-security-rule-ha] source-zone trust
HRP_M[FW_A-policy-security-rule-ha] destination-zone untrust
HRP_M[FW_A-policy-security-rule-ha] source-address 192.168.1.0 24
HRP_M[FW_A-policy-security-rule-ha] action permit
Step 5 Configure the router.

Configure OSPF on the router. For detailed configuration commands, refer to documents
related to the router.
----End
Configuration script of FW_A:
#
sysname FW_A
#
hrp enable
hrp interface GigabitEthernet 1/0/2 remote 10.100.50.3
hrp track ip-link test
#
ip-link name test
destination 1.1.1.1 interface GigabitEthernet1/0/3
#
interface GigabitEthernet 1/0/1
ip address 10.100.10.2 255.255.255.0
link-group 1
#
ip address 10.100.50.2 255.255.255.0
#
ip address 10.100.30.2 255.255.255.0
link-group 1
#
firewall zone trust

add interface GigabitEthernet 1/0/1

#
firewall zone dmz
#
firewall zone untrust
#
ospf 101
area 0.0.0.0
network 10.100.10.0 0.0.0.255
network 10.100.30.0 0.0.0.255
#
security-policy
rule name ha
source-zone trust
action permit
#
return
Configuration script of FW_B:

#
sysname FW_B
#
hrp enable
hrp standby-device
hrp track ip-link test
#
ip-link name test
destination 2.2.2.2 interface GigabitEthernet1/0/3
#
ip address 10.100.20.2 255.255.255.0
link-group 1
#
ip address 10.100.50.3 255.255.255.0
#
ip address 10.100.40.2 255.255.255.0
link-group 1
#
firewall zone trust
#
firewall zone dmz
#
#
ospf 101
area 0.0.0.0
network 10.100.20.0 0.0.0.255
network 10.100.40.0 0.0.0.255
#
security-policy
rule name ha
source-zone trust
action permit

#
return
2.2.5.2 CLI: Example for Configuring the Interworking Between Static Routes
and IP-Link
This section describes the example for configuring IPv4 static routes binding with IP-link.
As shown in Figure 2-90, the switch is connected to two routers and the company has two
links to access the Internet. Two IP-links are configured. IP-link 1 is from the FW to router 1
and IP-link 2 is from the FW to router 2. IP-link 1 is the primary link. Two static routes are
installed, one bound to IP-link 1, the other to IP-link 2. If IP-link 1 fails, traffic will be
switched to IP-link 2 so that Internet access will not be interrupted.
Figure 2-90 Networking of configuring the interworking between static routes and IP-link
Router 1
10.10.1.2./24
IP-Link 1
FW
Switch
Intranet
GE1/0/2 GE1/0/1
192.168.1.1/24 10.10.1.1./24
10.10.1.3./24
Router 2
Procedure
Step 1 Configure two IP-links to detect the links from FW to router 1 and router 2.
[FW] ip-link check enable
[FW] ip-link name test1
[FW-iplink-test1] destination 10.10.1.2
[FW-iplink-test1] quit
Step 2 Install two static routes to reach the Internet and bind them to the two IP-links. Set the
preferences of the two links to ensure that the link to router 1 has a higher preference.
[FW] ip route-static 0.0.0.0 0.0.0.0 10.10.1.2 track ip-link test1
[FW] ip route-static 0.0.0.0 0.0.0.0 10.10.1.3 preference 70 track ip-link test2
----End
Verify the configuration on the FW as follows:
When the links between the FW and the two routers are both normal, run the display ip-link
command. The output resembles:

[FW] display ip-link

Name Member State Up/Down/Init
test1 1 up 1 0 0
test2 1 up 1 0 0
Run the display ip routing-table command, the output shows that the default route to the
Internet is the one directed to router 1.
[FW] display ip routing-
table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost Flags NextHop Interface

0.0.0.0/0 Static 60 0 RD 10.10.1.2
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0

10.10.1.0/24 Direct 0 0 D 10.10.1.1

192.168.1.0/24 Direct 0 0 D 192.168.1.1
Run the display ip routing-table verbose command. The output resembles:

[FW] display ip routing-table
verbose

------------------------------------------------------------------------------
Destination: 0.0.0.0/0
Protocol: Static Process ID: 0
Preference: 60 Cost: 0
NextHop: 10.10.1.2 Neighbour: 0.0.0.0
State: Active Adv Relied Age: 00h03m29s
Tag: 0 Priority: 0
Label: NULL QoSInfo: 0x0
IndirectID: 0x80000004
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet1/0/1
TunnelID: 0x0 Flags: RD
State: Invalid Adv Relied Age: 00h00m08s
Tag: 0 Priority: 0
TunnelID: 0x0 Flags: R
The output shows that when the two links are normal, the preference value of the route to
10.10.1.2 is 60 (the default preference value). Therefore, the link is in the Active state and is
installed in the routing table. The route to 10.10.1.3 has a preference value of 70 and is in the
Inactive state. This route is the backup route and is not installed in the routing table.

When the link to router 1 breaks, run the display ip-link command. The output shows that the
IP-link to 10.10.1.2 is down.
[FW] display ip-link
Name Member State Up/Down/Init
test1 1 down 0 1 0
test2 1 up 1 0 0
Run the display ip routing-table command, the output shows that the default route to the
Internet is the one directed to router 2.
[FW] display ip routing-
table
------------------------------------------------------------------------------

0.0.0.0/0 Static 70 0 RD 10.10.1.3

10.10.1.0/24 Direct 0 0 D 10.10.1.1

192.168.1.0/24 Direct 0 0 D 192.168.1.1
Run the display ip routing-table verbose command. The output resembles:

[FW] display ip routing-table verbose
------------------------------------------------------------------------------
State: Active Adv Relied Age: 00h00m08s
Tag: 0 Priority: 0
TunnelID: 0x0 Flags: R
State: Invalid Adv Relied Age:
00h03m29s
Tag: 0 Priority: 0
TunnelID: 0x0 Flags: RD
The output shows that when the link to 10.10.1.2 breaks, the state of IP-link 1 is Down and
the route to 10.10.1.2 is set to Invalid. The route to 10.10.1.3, which has a preference value of
70, is set to Active and installed in the routing table.

The outputs show that the configuration is correct.
#
sysname FW
#
ip-link name test1
destination 10.10.1.2
ip-link name test2
destination 10.10.1.3
#
ip route-static 0.0.0.0 0.0.0.0 10.10.1.2 track ip-link test1
ip route-static 0.0.0.0 0.0.0.0 10.10.1.3 preference 70 track ip-link
test2
#
return
2.2.5.3 CLI: Example for Configuring the Interworking Between PBR and IP-Link
This example describes how to configure PBR to select next hops for various packets and
balance link traffic. It also describes how to use IP-link for monitoring the reachability of
links where the next hops of the packets on policy-based routes reside and dynamically
determining the availability of the policy-based routes by IP-link state. When a policy-based
route is unavailable, the device can search for standby routes to ensure link continuity.
As shown in Figure 2-91, an enterprise has departments A and B. Departments A and B,
acting as service departments, have heavy traffic and require different links for traffic
balancing. In addition, the departments require high stability and continuity.
To meet their requirements, the enterprise applies for two links that access the Internet,
namely, ISP1 and ISP2 to balance link traffic. The two links are mutually backed up to ensure
link continuity.
The requirements are as follows:
l Department A resides on network segment 10.1.0.0/16 and its packets for accessing the
Internet pass through link ISP1 in normal cases.
l Department B resides on network segment 10.2.0.0/16 and its packets for accessing the
Internet pass through link ISP2 in normal cases.
l The links of departments A and B are mutually backed up. When the link (active link) of
a department is faulty, traffic is switched to the link (standby link) of another department.

Figure 2-91 Networking diagram of configuring PBR to interwork with IP-link
Router_A
Switch 1.1.2.1/24
Department A GE1/0/4 nk1
IP-Li
10.1.0.1/16 ISP1
GE1/0/2
FW 1.1.2.2/24
GE1/0/3
1.1.3.2/24
ISP2
Department B GE1/0/1 IP-Li
10.2.0.1/16 nk2
Switch Router_B
1.1.3.1/24
NOTE
This example describes only PBR-related configurations, but not configurations (such as NAT and route
reachability among Router_A, Router_B, and FW) required by the FW for providing Internet access
services.
The roadmap for configuring PBR to interwork with IP-link is as follows:
1. To balance traffic on different links, configure source IP address-based PBR, so that

packets for accessing the Internet from department A pass through ISP1 and packets for
accessing the Internet from department B pass through ISP2.
2. To ensure the continuity and mutual standby of links at which departments A and B
reside, do as follows:
a. Configure PBR to interwork with IP-link. IP-link monitors the reachability of the
active links of departments A and B. When the active links are faulty, PBR becomes
invalid. The device searches for standby routes to ensure service continuity.
b. Configure static routes from department A to link ISP2 and from department B to
link ISP1 as the standby routes of departments A and B. Moreover, configure static
routes to interwork with IP-link. IP-link monitors the reachability of the standby
links of departments A and B.
Procedure
Step 1 Configure IP-link.
NOTE
To ensure interworking between PBR and IP-link, the destination IP address detected by IP-link must be
consistent with the setting of the next hop of packets.
# Enable IP-link.
# Create IP-link 1 for detecting link reachability from the FW to destination address 1.1.2.1.


# Create IP-link 2 for detecting link reachability from the FW to destination address 1.1.3.1.
Step 2 Configure policy-based routing and associate it with IP-link.

# Configure rule A_1, so that packets sent from 10.1.0.0/16 to 10.2.0.0/16 are not pbr.
[FW] policy-based-route
[FW-policy-pbr] rule name A_1
[FW-policy-pbr-rule-A_1] ingress-interface GigabitEthernet 1/0/4
[FW-policy-pbr-rule-A_1] source-address 10.1.0.0 16
[FW-policy-pbr-rule-A_1] destination-address 10.2.0.0 16
[FW-policy-pbr-rule-A_1] action no-pbr
[FW-policy-pbr-rule-A_1] quit
# Configure rule A_2, so that packets sent from 10.1.0.0/16 are sent to next-hop 1.1.2.1.
[FW-policy-pbr-rule-A_2] action pbr next-hop 1.1.2.1
Configure rule A_2 to interwork with IP-link 1

[FW-policy-pbr-rule-A_2] track ip-link test1
# Configure rule B_1, so that packets sent from 10.2.0.0/16 to 10.1.0.0/16 are not pbr.
[FW-policy-pbr] rule name B_1
[FW-policy-pbr-rule-B_1] ingress-interface GigabitEthernet 1/0/1
[FW-policy-pbr-rule-B_1] source-address 10.2.0.0 16
[FW-policy-pbr-rule-B_1] destination-address 10.1.0.0 16
[FW-policy-pbr-rule-B_1] action no-pbr
[FW-policy-pbr-rule-B_1] quit
# Configure rule B_2, so that packets sent from 10.2.0.0/16 are sent to next-hop 1.1.3.1.
[FW-policy-pbr-rule-B_2] action pbr next-hop 1.1.3.1
Configure rule B_2 to interwork with IP-link 2

[FW-policy-pbr-rule-B_2] track ip-link test2
[FW-policy-pbr]quit
Step 3 Configure default routes and associate them with IP-link.

# Configure the default route, set the next hop to 1.1.2.1/24, and associate the route with IP-
link 1.
# Configure the default route, set the next hop to 1.1.3.1/24, and associate the route with IP-
link 2.
----End

Verification
1. When active links are reachable, packets for accessing the Internet from department A
are forwarded by the FWto ISP1, and packets for accessing the Internet from department
B are forwarded by the FW to ISP2.
# Run the display ip-link command. You can view that the IP-links are Up.
[FW] display ip-
link
Current Total Ip-link Number :
2
Name Member State Up/Down/
Init
test1 1 up 1 0 0
test2 1 up 1 0 0
# Run the ping 1.1.2.1 command in department A. The ping attempt is successful. Then
run the ping 1.1.3.1 command. The pinging attempt is unsuccessful.
C:\Documents and Settings\DepartA>ping 1.1.2.1
Pinging 1.1.2.1 with 32 bytes of data:
Reply from 1.1.2.1: bytes=32 time=9ms TTL=254

Ping statistics for 1.1.2.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 9ms, Average = 4ms
Request timed out.

Request timed out.
Request timed out.
Request timed out.

# Run the ping 1.1.3.1 command in department B. The pinging attempt is successful.
Then run the ping 1.1.2.1 command. The pinging attempt is unsuccessful.
C:\Documents and Settings\DepartB>ping 1.1.3.1


Request timed out.

Request timed out.
Request timed out.
Request timed out.


2. When the active link is faulty, the FW searches for the standby route and forwards the
packets of departments to the corresponding standby link. Active link ISP1 of
department A is used as an example for explanation.
# Run the display ip-link command. The IP-link where department A resides is Down.
[FW] display ip-
link
2
Init
test1 1 down 0 1 0
test2 1 up 1 0 0
# Run the ping 1.1.2.1 command in department A. The pinging attempt is unsuccessful.
Then run the ping 1.1.3.1 command. The pinging attempt is successful.


Request timed out.

Request timed out.
Request timed out.
Request timed out.

3. When active links restore to normal, the FW forwards all packets to the active links.
Active link ISP1 of department A is used as an example.
# Run the display ip-link command. Both IP-links of department A are Up.
[FW] display ip-
link
2
Init
test1 1 up 1 0 0
test2 1 up 1 0 0
# Run the ping 1.1.2.1 command in department A. The pinging attempt is successful.
Then run the ping 1.1.3.1 command. The pinging attempt is unsuccessful.



Request timed out.

Request timed out.
Request timed out.
Request timed out.

4. The mutual access of departments A and B is successful. The pinging attempt from
department A to B is used as an example.


Configuration scripts of FW
#
sysname FW
#
ip-link name test1
destination 1.1.2.1
ip-link name test2
destination 1.1.3.1
#
ip address 10.2.0.1 255.255.0.0
#
ip address 1.1.2.2 255.255.255.0
#
ip address 1.1.3.2 255.255.255.0
#
ip address 10.1.0.1 255.255.0.0
#
#
policy-based-route
rule name A_1
ingress-interface GigabitEthernet1/0/4

action no-pbr
rule name A_2
track ip-link
test1
action pbr next-hop 1.1.2.1
rule name B_1
action no-pbr
rule name B_2
track ip-link
test2
#
return
2.2.5.4 CLI: Example for Configuring the Interworking Between DHCP and IP-
Link
By binding the link where DHCP runs to IP-link, you can resolve the problem that the
automatically delivered static route cannot be bound to the IP-link.
As shown in Figure 2-92, the router is the gateway of a building. All enterprises in the
building access the Internet through the router. FW_A acts as the gateway of an enterprise in
the building. To ensure network continuity, the enterprise uses the dual-uplink networking.
The active link accesses the Internet through DHCP, that is, FW_A as the DHCP client
accesses the Internet by obtaining the IP address from the DHCP server. The standby link
accesses the Internet through 3G, that is, 3G dial-on-demand.
Because the DHCP client cannot sense link reachability, FW_A cannot switch the traffic to
the standby link in the event of link faults. To interwork with IP-link, check the availability of
the link where the DHCP client resides. Upon link faults, service traffic is switched to the
standby link.
Figure 2-92 Networking diagram of configuring the interworking between DHCP and IP-link
IP-Link 1 Building
Enterprise
PC
DHCP client Router
GE1/0/2 DHCP server
10.1.1.2/24 8.8.8.1/24
Intranet 10.1.1.1/24 8.8.8.2/24
GE1/0/1
FW
PPPoE dialer

Procedure
Step 1 Configure IP-link.
NOTE
To ensure interworking between DHCP and IP-link, the destination IP address detected by IP-link must
be consistent with the IP address of the Router.
# Enable IP-link.
<FW> system-view
# Create IP-link test for detecting link reachability from the FW_A to destination address
8.8.8.1.
[FW] ip-link name test
[FW-iplink-test]destination 8.8.8.1 interface GigabitEthernet 1/0/2 mode icmp
next-hop dhcp
[FW-iplink-test]quit
Step 2 Configure the DHCP client function, and associate DHCP with the IP-link.
# Enable the DHCP client function on interface GigabitEthernet 1/0/2, and associate DHCP
with the IP-link 1.
[FW] dhcp enable
[FW-GigabitEthernet1/0/2] ip address dhcp-alloc
[FW-GigabitEthernet1/0/2] dhcp client track ip-link test
Step 3 Configure the default route.

# Configure the default route with outbound interface Dialer 0 and route priority 255.
NOTE
When the FW acts as the DHCP client, the priority of the default route obtained from the DHCP server
is 245. When PPPoE is used for backup access, the priority of the default route must be larger than 245.
The higher the priority value, the lower the priority.
[FW] ip route-static 0.0.0.0 0.0.0.0 Dialer 0 preference 255
----End
Verification
1. When the active link is reachable, access packets are forwarded by FW to the active link.
# Run the display ip-link command. You can view that IP-link is created and it is in Up
state.
[FW] display ip-
link
1
Init
test 1 up 1 0 0
# Run the display ip routing-table command on FW You can view that the default route
to FW is the gateway address obtained through the DHCP server and the route priority is
245.

------------------------------------------------------------------------------

0.0.0.0/0 Static 245 0 RD 10.1.1.1

10.1.1.0/24 Direct 0 0 D 10.1.1.2
192.168.0.0/24 Direct 0 0 D 192.168.0.100
2. When the active link is faulty, FW switches the traffic to the standby link.
# Run the display ip-link command. You can view that the status of the IP-link is Down.
[FW] display ip-
link
1
Init
test 1 down 0 1 0
# Run the display ip routing-table command. You can view that default route obtained
through the DHCP server is deleted and the backup default route with outbound interface
Dialer 0 is loaded to the routing table.
Route Flags: R - relay, D - download to
fib
------------------------------------------------------------------------------
Routing Tables:
Public
Destination/Mask Proto Pre Cost Flags NextHop

Interface
0.0.0.0/0 Static 255 0 D 0.0.0.0

Dialer0
127.0.0.0/8 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
192.168.0.0/24 Direct 0 0 D 192.168.0.100
192.168.0.100/32 Direct 0 0 D 127.0.0.1
InLoopBack0
3. When the active link recovers, run the display ip-link command on FW. You can view
that the status of the IP-link turns to Up. Run the display ip routing-table command.
You can view that the default route to FW obtained through the DHCP server is re-
loaded to the routing table.
#
sysname FW

ip-link name test

destination 8.8.8.1 interface GigabitEthernet1/0/2 mode icmp next-hop dhcp
#
ip address dhcp-alloc
dhcp client track ip-link test
#
ip route-static 0.0.0.0 0.0.0.0 Dialer 0 preference 255
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1 preference 245 track ip-link test
#
return

This section describes the reference information about IP-link.
This section describes IP-link specifications.
IP-link ICMP and ICMPv6 Ping packets are used to detect

detection modes link reachability.
APP and NS detection ARP or NS packets are used to

modes detect link reachability.
Destination address- The device periodically sends

based detection detection packets to a specific
destination IP address to determine
whether the link is working
properly.
Domain name-based The device periodically sends

detection detection packets to a specific
domain name to determine
whether the link is working
properly.
HRP switchover The HRP switchover is performed

triggered by IP-link based on IP-link status changes.
Static route switchover The static route switchover is

triggered by IP-link performed based on IP-link status
changes.
Policy-based route The policy-based route switchover

switchover triggered by is performed based on IP-link
IP-link status changes.

IP-link Number of detection objects 16

for each IP-link
Minimum number of The value ranges from 1 to

detection objects in Up state -16. The default value is 1.
of each IP-link
Interval for sending IP-link The value ranges from 3 to

detection packets -10. The default value is 3.
Number of failed IP-link The value ranges from 2 to

detection packets -10. The default value is 3.

This section describes the versions and changes in the IP-link feature.
Version Description
2.3 Link-Group
In link-group, multiple physical interfaces are bound to a logical group to ensure the status
consistency of the interfaces in the group.
2.3.1 Overview
This section describes the definition and purpose of link-group.
Definition
A link-group is used to bind the state of several physical interfaces to form a logical group. If
one of the interfaces within the logical group is faulty, the system sets the state of the other
interfaces as Down. After all the interfaces are functional, the system resets the state of the
interfaces within the logical group as Up.
Objective
The Link-group management group ensures the status consistency of the physical interfaces in
the group, and accelerates the route convergence when the link is faulty.
2.3.2 Configuring Link-Group Using the Web UI

A link-group is used to allocate multiple interfaces to a logical group, ensuring the
consistency of the status of interfaces in the group.

Context
Link-group is to bind several physical interfaces to form a logical group. If any interface in
the logical group is faulty, the system sets the status of the other interfaces to Down. The
system changes the status of all the interfaces back to Up only after all the interfaces in the
link-group recover.
Procedure
Step 1 Choose System > High Availability > Link-Group.
Step 2 Click to the right of the link-group to be configured.

Link-Group ID Indicates the ID of the current link-group.
Link-Group Enables or disables link-group on an interface.

Configuration
Step 3 Click OK.
----End
2.3.3 Configuring Link-Group Using the CLI

A link-group is used to allocate multiple interfaces to a logical group, ensuring the
consistency of the status of interfaces in the group.
Prerequisites
Set the IP addresses of interfaces and add the interfaces to security zones.
Context
The link group function binds the status of several interfaces to form a logical group. If one
interface in the logical group is faulty, the system changes the status of the other interfaces to
Down. After all the interfaces recover, the system changes the status of the interfaces to Up.
The link group function ensures that the status of the upstream and downstream interfaces are
consistent with each other, avoiding the inconsistency of upstream and downstream paths
upon active/standby switchover.
Procedure
system-view
Step 3 Add the interface to the link-group.
link-group link-group-id

By default, the system is not configured with the link-group management group.
----End
Follow-up Procedure
Run the display link-group link-group-id command to check the configuration of the link-
group.
<FW> display link-group 1
link group 1, total 2, fault 0
GigabitEthernet1/0/2 : up
GigabitEthernet1/0/1 : up

This section describes the reference information about Link-Group.
This section describes Link-Group specifications.
Link-Group Supported interface types Link-group bundles multiple

include Ethernet physical interfaces into a logical
interfaces, Eth-Trunk group and ensures the status
interfaces. consistency of the interfaces in the
group.
Link-Group Number of link-groups 12
Maximum number of 224

interfaces in each link-
group.

This section describes the versions and changes in the Link-Group feature.
Version Description

2.4 BFD
As an independent hello protocol, BFD implements low-overhead and rapid fault detection.
By interworking with upper-layer protocols, BFD enables them to rapidly identify and recover
from faults.
2.4.1 Overview
This section describes the definition and purpose of BFD.
Definition
Bidirectional Forwarding Detection (BFD) quickly detects communications faults between
systems and reports corresponding faults to the upper-layer protocol.
Objective
To minimize the impact of failures and improve network availability, network devices need to
rapidly detect communication failures to take early remedial actions to ensure service
continuity.
The current fault detection mechanisms include:
l Hardware detection: For example, the Synchronous Digital Hierarchy (SDH) alarms are
used to detect faults on links. This mechanism features quick identification of faults;
however, not all medium can provide this mechanism.
l Slow Hello mechanism: It usually refers to the Hello mechanism offered by a routing
protocol. The slow Hello mechanism can detect a fault in seconds. In high-speed data
transmission, for example, at Gbit/s rate, the detection delay of more than one second
causes the loss of a large amount of data. In delay-sensitive services such as the voice
service, the delay of more than one second is unacceptable.
l Other detection mechanisms: Specific detection mechanisms may be provided by
different protocols or device vendors. If a network has devices from multiple vendors,
these detection mechanisms are difficult to implement.
BFD overcomes the limitations of earlier detection mechanisms.
BFD provides the following functions:
l Provides low-overhead and quick fault detection for channels between adjacent
forwarding engines. The detected faults may occur on interfaces, data links, or
forwarding engines.
l Provides a single mechanism to detect any media and protocol layers in real time. In
addition, the detection duration and overhead range are variable.

This section describes the application scenarios of BFD.
2.4.2.1 Interworking Between BFD and Hot Standby

This section describes the application scenario of interworking between BFD and hot standby.

Applicable Environment
The hot standby function enables the standby device to take over services from the faulty
active device to ensure service continuity.
Virtual Router Redundancy Protocol (VRRP) Group Management Protocol (VGMP) groups
determine the active/standby status of devices.
When BFD works with hot standby, VGMP groups are used to monitor static BFD sessions,
and the priorities of VGMP groups change based on the status of BFD sessions. The change
of the priorities of VGMP groups triggers active/standby switchover.
Typical Application
As shown in Figure 2-93, FW_A and FW_B are deployed on a hot standby network. FW_A
functions as the active device, and FW_B functions as the standby device.
To improve network reliability and enable the FWs to monitor the status of indirectly-
connected links, you need to create BFD sessions between the FW_A and the router_A and
use active VGMP group on the FW_A to monitor the status of BFD session. And you need to
create BFD sessions between the FW_B and the router_B and use standby VGMP group on
the FW_B to monitor the status of BFD session.
As shown in Figure 2-93, if interface GE1/0/1 on Router_A is faulty, the BFD session detects
the interface fault (changes the status from Up to Down) and notifies the VGMP group on
FW_A of the fault. Then the priority of the VGMP group on FW_A is lower than the priority
of the VGMP group on FW_B and triggers active/standby switchover. Therefore, FW_A
becomes the standby device, and FW_B becomes the active device.
Figure 2-93 Networking diagram of interworking between BFD and hot standby
FW_A BFD Session Router_A
GE1/0/1
FW_B BFD Session
2.4.2.2 Interworking Between BFD and Static Routes

This section describes the application scenario of interworking between BFD and static
routes.
Static route is manually configured by administrators for a known path. Different from
dynamic route, static route does not have the detection mechanism. When the network fails,
administrator intervention is needed.

By interworking, the static route is bound to a static BFD session. Therefore, the status of the
static route changes with the status of the BFD session.
Typical Application
As shown in Figure 2-94, Router_A connects Router_B with a Layer-2 switch, and can
communicate with the Internet through a static route. The link from Router_A to Router_B
serves as the active link while the link from Router_A to Router_C to Router_B serves as the
standby link.
To increase the network reliability and shorten the route convergence time, you can establish a
BFD session between Router_A and Router_B to check the link status.
l If the BFD session on the static route detects a fault (the status changes from Up to
Down), BFD reports the fault to the system. The system deletes this route from the
routing table, and the traffic switches to the standby link.
l If the BFD session on the static route is successfully created (the status changes from
Down to Up), BFD reports to the system. The system adds this route to the routing table,
and the traffic switches back to the active link.
Figure 2-94 Networking diagram of interworking between BFD and static routes (one-hop
detection)
BFD session
Router_A Router_B
Traffic flow when the

network is normal
Traffic flow when a fault
occurs
Router_C BFD session
The interworking between BFD and static route supports two detection modes:
l One-hop detection
Devices on both ends of the BFD session connect directly or with a Layer-2 switch, that
is, the BFD session and the static route share the same outbound interface, and the IP
address of the peer end is the next hop of the route. Figure 2-94 shows the typical
application of the one-hop detection networking.
l Multi-hop detection

As Figure 2-95 shows, the devices on both ends of the BFD session are indirectly
connected with multi-hop routing channels. In this case, the BFD session binds the IP
address of the peer end but not the outbound interface of the static route.
Figure 2-95 Networking diagram of interworking between BFD and static routes (multi-
hop detection)
BFD Session
Router_A Switch Router_D Router_B

network is normal
occurs
Router_C BFD session
2.4.2.3 Interworking Between BFD and OSPF

This section describes the application scenario of interworking between BFD and OSPF.
A link fault or the change of topology may lead to rerouting in a network. The short-duration
convergence of a routing protocol is important for the improvement of availability of the
network. A feasible solution is to fast detect the fault and notify the fault to the routing
protocol immediately.
In the BFD-OSPF interworking, OSPF is associated with a BFD session. The BFD session
fast detects a link fault and notifies OSPF of the fault. In this manner, OSPF speeds up the
response to the change of the network topology.
Table 2-3 shows statistics of convergence speeds when OSPF is and is not associated with a
BFD session.

Table 2-3 Statistics of OSPF convergence speeds

Associated with Link Fault Detection Mechanism Convergence
BFD or Not Speed
Not associated with Timeout of the OSPF Hello keepalive timer At the second level
BFD
Associated with BFD session in the Down state At the millisecond

BFD level
Typical Application
As shown in Figure 2-96, OSPF runs among Router_A, Router_B, and Router_C which are
mutual neighbors. The link from Router_A to Router_B serves as the active link while the
link from Router_A to Router_C to Router_B serves as the standby link.
Create a BFD session on the link between Router_A and Router_B. Therefore, when the link
status changes, the convergence speed of OSPF increases. If the link between Router_A and
Router_B fails, BFD rapidly identifies the fault and notifies OSPF of the fault. Therefore, the
service traffic is switched to the standby link.
Figure 2-96 Networking diagram of BFD-OSPF interworking
BFD Session
Router_A Router_B
Area 0
Router_C

network is normal
occurs
BFD session

2.4.2.4 Interworking Between BFD and BGP

This section describes the application scenario of interworking between BFD and BGP.
BGP enables the device to periodically send packets to the neighboring devices for fault
detection, but detecting a fault takes more than 1s. When traffic is transmitted at Gbit/s rates,
long-time fault detection will cause data loss, failing to meet the high reliability requirements
of carrier-class networks.
Therefore, BFD interworking with BGP is introduced to quickly identify link faults between
BGP peers (faults can be detected within milliseconds) and report the faults to BGP,
implementing fast BGP route convergence.
Typical Application
As shown in Figure 2-97, Router_A and Router_B respectively belong to AS100 and AS200
and establish EBGP connections in between.
BFD is configured to detect the BGP neighboring relationship between Router_A and
Router_B. When the link between Router_A and Router_B fails, BFD can rapidly detect the
fault and report it to the BGP protocol.
Figure 2-97 Networking diagram of BFD-BGP interworking
AS100 AS200
EBGP
BFD Session
Router_A Router_B
2.4.2.5 Interworking Between BFD and IS-IS

This section describes the application scenario of interworking between BFD and IS-IS.
When interworking with IS-IS, BFD can rapidly sense link changes and converges routes.
As shown in Figure 2-98, when the link between Router_A and Router_B fails, BFD can
rapidly detect the fault and report it to the IS-IS protocol. Then IS-IS shuts down the
interfaces connecting to the neighbors and deletes the neighboring IP protocols to trigger
topology calculation and update the Link State PDUs (LSP) so that other neighbors (such as
neighbors Router_C of Router_B) can receive the updated LSP of Router_B in time to
complete fast network topology convergence.

Figure 2-98 Networking diagram of interworking between BFD and IS-IS
BFD Session
Router_A Router_B

network is normal
occurs
BFD session
2.4.2.6 Interworking Between BFD and PBR

This section describes the application scenario of interworking between BFD and PBR.
Policy-Based Routing (PBR) is a mechanism, which selects routes based on the customized
policy rather than forwards packets by searching the FIB table based on the destination
addresses of IP packets. The PBR can be used for the purpose of security or load balancing.
PBR supports route selection based on packet information such as the source IP addresses and
packet types of received packets. Packets that meet certain conditions are forwarded
according to packet information such as the outbound interface and next hop, and the default
outbound interface and next hop.
PBR cannot sense the availability of the link where the PBR is enabled. When the link is
unreachable and the device forwards the packet, the packet forwarding may fail.
The BFD-PBR interworking resolves the previous problems, and improves the flexibility of
PBR applications and the dynamic network environment sensation of PBR. After the actions
of PBR are associated with the static BFD session, the BFD can monitor the reachability of
the next hop or outbound interface and dynamically detect the availability of the policy-based
routes.
Typical Application
As shown in Figure 2-99, Router_A serves as the egress gateway of a company. There are
two links connecting to the Internet. Normally, the service initiated by Department A travels
from Router_A to Router_B. When a fault occurs, the service traffic is switched to the other
link.
To ensure that Router_A can rapidly and dynamically sense the availability of PBR, you can
create a BFD session between Router_A and Router_B. When the link between Router_B and

the Layer-2 switch fails, the BFD can identify the fault and notify Router_A rapidly, and the
PBR bound to the BFD session becomes invalid. In this way, Router_A searches for standby
routes to ensure service continuity.
Figure 2-99 Networking diagram of BFD-PBR interworking
sion
D Ses
BF Router_B
PC
Department A Router_A
PC Router_C
PC

network is normal
occurs
BFD session
2.4.2.7 Interworking Between BFD and DHCP

This section describes the application scenario of interworking between BFD and DHCP.
To ensure network reliability, some enterprises use the dual-uplink networking. Usually, the
DHCP link serves as the active link. In such case, the egress gateway of the company serves
as the DHCP client, and the company obtains IP addresses from the DHCP server to access
the Internet. Links such as PPPoE link serve as the standby links.
As the DHCP client, the egress gateway cannot sense the availability of the link on which the
egress gateway resides. When the link fails, the gateway cannot switch the service traffic to
the standby link rapidly, resulting in service interruptions.
The BFD-DHCP interworking resolves this problem. The association of the DHCP client with
the BFD session enables BFD to dynamically determine the availability of the DHCP link
according to BFD session status.
Typical Application
As shown in Figure 2-100, Router_A serves as the egress gateway of a building. All
companies in the building access the Internet through Router_A. Router_B serves as the
egress gateway of a company in the building. To ensure network continuity, the company uses
the dual-uplink networking, with DHCP and PPPoE links as the active and standby link
respectively.

Figure 2-100 Networking diagram of BFD-DHCP interworking
BFD Session
PC
Router_B DHCP Server Router_A
Intranet
DHCP Client
PPPoE

network is normal
occurs
BFD session
To ensure that the DHCP client can sense the fault and perform the link switch quickly when
the active link fails, you can establish a static BFD session between Router_A and Router_B,
and bind the DHCP to BFD on Router_B.
By BFD-DHCP interworking, Router_B delivers the following functions:

l When BFD detects a fault on the active link, the system disables the DHCP link and
switches the service traffic to the standby link.
l When BFD detects that the active link is recovered, service traffic is switched back to the
active link.
2.4.3 Mechanism
This section describes the mechanism of BFD.
2.4.3.1 BFD Packet

This section describes the format of the BFD packet.
BFD packets fall into two types, namely, BFD control packet and BFD echo packet.
BFD Control Packet

BFD control packets are encapsulated in UDP packets for transmission, and the destination
port of UDP is port 3784.
A BFD control packet consists of a mandatory part and an optional authentication part.
Figure 2-101 shows the format of the BFD control packet.

Figure 2-101 Format of the BFD control packet
0 7 16 23 31
Vers Diag Sta P F C A D R Detect Mult Length
My Discriminator
Your Discriminator
Desired Min TX Interval
Required Min RX Interval
Required Min Echo RX Interval

Auth Type Auth Len Authentication Data…
(Optional) (Optional) (Optional)
NOTE
FW does not support the BFD function.
Table 2-4 shows the description of each field in the packet.
Table 2-4 Description of each field in the BFD control packet

Field Lengt Description
h
Vers (Version) 3 bits Indicates the version number of the protocol. The current
version number is 1.
Diag 5 bits Indicates the cause that the status of the latest session changes
(Diagnostic) from Up to other status in the local system. Different values
indicate different causes:
l 0: No Diagnostic
l 1: Control Detection Time Expired
l 2: Echo Function Failed
l 3: Neighbor Signaled Session Down
l 4: Forwarding Plane Reset
l 5: Path Down
l 6: Concatenated Path Down
l 7: Administratively Down
l 8: Reverse Concatenated Path Down
l 9 to 31: Reserved for future use


h
Sta (State) 2 bits Indicates the status of the current BFD session. Different
values indicate different statuses:
l 0: AdminDown. Indicates that the BFD session is in
administrative Down state.
l 1: Down. Indicates that the BFD session is Down or just
established.
l 2: Init. Indicates that the BFD session can communicate
with the peer end and the local end expects the session to
enter the Up state.
l 3: Up. Indicates that the BFD session is successfully
established.
P (Poll) 1 bit Indicates the bit for connection request confirmation. Different
values indicate different meanings:
l 1: indicates that the sending system requests the
confirmation of the connection or the parameter changes.
l 0: indicates that the sending system does not request the
confirmation of the connection or the parameter changes.
F (Final) 1 bit Indicates the bit determining whether the sending system
responds to a BFD control packet with P bit as 1. Different
values indicate different meanings:
l 1: indicates that the sending system responds to a BFD
control packet with P bit as 1.
l 0: indicates that the sending system does not respond to a
BFD control packet with P bit as 1.
C (Control 1 bit Indicates the bit determining whether BFD control packets are
Plane transmitted on the control plane. Different values indicate
Independent) different meanings:
l 1: indicates that the sending system implements BFD
independent of the control plane. That is, BFD packets are
transmitted on the forwarding plane. BFD continues to
work even if the control plane fails.
l 0: indicates that BFD packets are transmitted on the control
plane.


h
A 1 bit Indicates the bit determining whether BFD control packets

(Authentication contain the authentication field. Different values indicate
Present) different meanings:
l 1: indicates that the BFD control packet contains the
authentication field, and the session needs to be
authenticated.
l 0: indicates that the BFD control packet does not contain
the authentication field, or the session does not need to be
authenticated.
NOTE
FW does not provide the BFD authentication function currently. The A
bit is set to 0 all the time.
D (Demand) 1 bit Indicates the demand mode operation bit. Different values
indicate different meanings:
l 1: indicates that the sending system expects to run in
demand mode.
l 0: indicates that the sending system does not expect to or
cannot run in demand mode.
R (Reserved) 1 bit This field is set to 0 when a BFD control packet is sent. This
field is ignored when a BFD control packet is received.
Detect Mult 1 byte Indicates the detection time multiplier, that is, the maximum
(Detect time number of continuous loss of packets permitted by the packet
multiplier) receiver. The bit is used to check whether the link is normal.
l Demand mode: uses the local detection time multiplier.
l Asynchronous mode: uses the detection time multiplier of
the peer end.
Length 1 byte Indicates the length of a BFD control packet, in bytes.
My 4 Indicates a unique non-zero discriminator value generated by

Discriminator bytes the sending system. The value is used to differentiate multiple
BFD sessions of a system.
Your 4 Indicates the value of My Discriminator sent from the remote

Discriminator bytes system. If this value is not received, the field is set to 0.
Desired Min Tx 4 Indicates the desired minimum interval for sending BFD
Interval bytes control packets by the local system, in microseconds.
Required Min 4 Indicates the minimum interval required between receiving two
Rx Interval bytes BFD control packets, in microseconds.
Required Min 4 Indicates the minimum interval required between receiving two
Echo Rx bytes BFD echo packets, in microseconds. If the interval is set to 0,
Interval the sending system cannot receive BFD echo packets.


h
Auth Type 1 byte Indicates the authentication type of BFD control packets.
Different values indicate different authentication types:
l 0: Reserved
l 1: Simple Password
l 2: Keyed MD5
l 3: Meticulous Keyed MD5
l 4: Keyed SHA1
l 5: Meticulous Keyed SHA1
l 6 to 255: Reserved for future use
Auth Len 1 byte Indicates the length of the authentication field, including the
authentication type field and the authentication length field, in
bytes.
Authentication 2 Indicates the authentication data.

Data bytes
BFD Echo Packet

BFD echo packets provide a fault detection mechanism independent from BFD control
packets. The local end sends and receives the packets. The peer end returns the packets over
the reverse channel without processing the packets. Therefore, the format of BFD echo packet
is not defined by the BFD protocol. The only requirement is that the sender can distinguish
sessions according to packet contents.
BFD echo packets are encapsulated in UDP packets for transmission. The destination port
number is 3784. The destination IP address is the address of the sending interface. The source
IP address is specified manually.
2.4.3.2 BFD Mechanism

This section describes the BFD mechanism, including detection mode, detection time and
detection parameter negotiation.
In the BFD mechanism, a BFD session is established between two systems, and BFD control
packets are sent periodically along the path. If one system does not receive any BFD control
packets in a certain period, it is regarded that a fault occurs on the path.
BFD control packets are encapsulated in UDP packets for transmission. At the beginning of a
session, two systems negotiate with each other through the parameters (including the session
identifier, minimum expected packet sending/receiving interval, and BFD session status on
the local end) in BFD control packets. After the negotiation succeeds, BFD control packets
are transmitted along the path on the basis of the negotiated packet sending/receiving interval.
To ensure fast detection, the packet sending/receiving interval is specified to the microsecond
level by the BFD protocol. Limited by device processing capability, BFD only reaches the
millisecond level on the devices of most vendors, and is further converted to the microsecond
level during internal processing.

Detection Mode
BFD supports the following detection modes:
l Asynchronous mode
In this mode, two systems periodically transmit BFD control packets to each other on the
basis of the negotiated packet sending/receiving interval. If one system does not receive
any BFD control packets from the other system in the detection period, it is regarded that
the BFD session is Down. The asynchronous mode is the most frequently used BFD
mode.
l Demand mode
In this mode, once a BFD session is established, the system does not periodically send
BFD control packets. Instead, other detection mechanisms (such as the Hello mechanism
of routing protocols and hardware detection mechanism) are adopted to reduce the costs
caused by BFD sessions. In demand mode, there is a timer in the system. When the timer
expires, the system sends a query packet with short sequence to check the link. If the
system does not receive the reply packet, it is regarded that the session is Down.
A supplementary function for the previous modes is the echo function. When the echo
function is enabled, a BFD control packet is transmitted in this method: The local system
sends a BFD control packet, and the remote system loops it back through the forwarding
channel. If none of several consecutive echo packets is received, it is regarded that the BFD
session is Down. The echo function can interwork with the asynchronous mode or demand
mode.
Currently, the system supports only the passive echo function for the one-hop session in
asynchronous mode. If devices supporting the echo function are available on the network, you
need to configure the BFD passive echo function on the device to enable its compatibility
with other devices. When the device enters the passive echo mode, the interval for
transmitting BFD control packets is increased. The devices on both ends of the BFD session
send the BFD echo packets (the source and destination IP address are both the IP address of
the outbound interface on the local end) which returns to the local end through ICMP
redirection. In this way, the link status is checked.
Detection Time
The BFD time is determined by the following three values:
l Desired Min Tx Interval (DMTI): the minimum interval for the transmission of BFD
control packets desired by the local end
l Required Min Rx Interval (RMRI): the minimum interval for the reception of BFD
control packets required by the local end
l Detect time multiplier (Detect Mult): the detect time multiplier
After one system receives the BFD control packet from the peer end, it compares the RMRI
attached in the packet with the local DMTI, and uses the larger value as the interval for the
transmission of BFD control packets. That is, the system with a slower speed determines the
transmission rate of BFD control packets.
The value of Detect Mult is not negotiated. It is configured by the two systems on both ends.
The detection time in asynchronous mode equals to the value of the received Detect Mult
from the peer end times the larger value of the local RMRI and the received DMTI.
The detection time in demand mode equals to the value of the local Detect Mult times the
larger value of the local DMTI and the received RMRI.

For example, the value of the local RMRI is 400 milliseconds; the value of the local DMTI is
300 milliseconds; the value of the received DMTI is 300 milliseconds, the value of the
received RMRI is 400 milliseconds, the value of the received Detect Mult is 4, and the value
of the local Detect Mult is 5.
The detection time in asynchronous mode = 4 x maximum (400 milliseconds and 300
milliseconds) = 1600 milliseconds. And the detection time in demand mode = 5 x maximum
(300 milliseconds and 400 milliseconds) = 2000 milliseconds.
The values of DMTI, RMRI, and Detect Mult can be configured independently. Therefore, the
two systems may differ in the transmission rate of BFD control packets.
You are advised to configure the same value on both ends for hardware using the same
transmission medium.
Detection Parameter Negotiation

After a BFD session is established, you can dynamically modify the detection parameters,
without changing the current session status. After you modify the detection parameters, the
device performs the following actions:
l DMTI change
a. The local end immediately sends a BFD control packet (carries a new DMTI) with
P bit as 1 in the transmission interval.
b. The local end recounts the transmission interval, and compares it with the current
one.
If the transmission interval needs to be changed to a smaller value, the following
occurs:
n The local end immediately restarts the sending timer, and sends BFD control
packets with P bit as 1 based on the new transmission interval.
n After receiving the BFD control packet with P bit as 1, the peer end replies a
BFD packet with F bit as 1. The peer end recounts the detection time, restarts
the detection timer immediately, and detects the link based on the new
detection time.
n After receiving the BFD packet with F bit as 1 from the peer end, the local end
stops sending BFD control packets with P bit as 1.
If the transmission interval needs to be changed to a larger value, the following
occurs:
n The local end sends BFD control packets (carries a new DMTI) with P bit as 1
based on the current transmission interval.
n After receiving the BFD control packet with P bit as 1, the peer end replies a
BFD packet with F bit as 1. The peer end recounts the detection time, restarts
the detection timer immediately, and detects the link based on the new
detection time.
stops sending BFD control packets with P bit as 1. The local end restarts the
sending timer, and sends BFD control packets based on the new transmission
interval.
If the recalculated transmission interval and the current transmission interval are
equal, the local end does not change the transmission interval.
l RMRI change

a. The local end immediately sends a BFD control packet (carries a new RMRI) with
P bit as 1 in the transmission interval.
b. The local end recounts the detection time, and compares it with the current one.
If the detection time becomes greater, the following situation occurs:
n The local end restarts the detection timer, and detects links based on the new
detection time. The local end continues sending BFD control packets (carries a
new RMRI) with P bit as 1.
n After receiving the BFD control packets with P bit as 1, the peer end
immediately replies a BFD control packets with F bit as 1, recounts the
transmission interval, and restarts the sending timer.
stops sending BFD control packets with P bit as 1.
If the detection time becomes smaller, the following occurs:
n The local end sends BFD control packets (carries a new RMRI) with P bit as 1
based on the current transmission interval.
n After receiving the BFD control packets with P bit as 1, the peer end
immediately replies a BFD control packets with F bit as 1, recounts the
transmission interval, and restarts the sending timer.
stops sending BFD control packets with P bit as 1, updates the detection time,
and restarts the detection timer.
If the recalculated detection time and the current detection time are equal, the local
end does not change the detection time.
c. Detect Mult change
i. The local end immediately sends a BFD control packet (carries a new detect
time multiplier) with P bit as 1 in the transmission interval. The new detect
time multiplier is attached in every packet from then on.
ii. After receiving the BFD control packet, the peer end recounts the detection
time, and detects links based on the new detection time.
2.4.3.3 BFD Session Management

This section describes the BFD session management, including session establishment mode
and session establishment process.
Session Establishment Mode

BFD distinguishes sessions according to the My Discriminator and Your Discriminator of
the control packets. According to the differences of My Discriminator and Your
Discriminator in their establishment modes, FW supports the following types of BFD
sessions.
l Static BFD session with a manually designated discriminator
You need to set BFD session parameters manually, including the configuration of My
Discriminator and Your Discriminator, and deliver a BFD session establishment
request manually.
Manual configuration errors may occur in this mode, for example, the incorrect
configuration of My Discriminator and Your Discriminator results in the failure of the

BFD session. Meanwhile, the establishment and deletion of the BFD session is manually
triggered, and lacks flexibility.
The interworking between BFD and PBR, DHCP, or FRR requires the static BFD session
with manually designated discriminators. In the application of interworking between
BFD and static routes, you can choose the static BFD session with manually designated
discriminators or the static BFD session with negotiated discriminators according to the
network status.
l Static BFD session with an automatically negotiated discriminator
You need to manually establish the BFD session, but do not need to configure My
Discriminator and Your Discriminator. Both discriminators are negotiated through the
BFD session.
In the application of interworking between BFD and static routes, the BFD session with
an automatically negotiated discriminator is required in the scenario where the device at
the peer end does not support static BFD session, and the dynamic BFD session is
adopted; meanwhile, the local device is routable to the peer end, and ensures the
application of interworking between BFD and static routes.
l Dynamic BFD session triggered by protocols
Dynamic BFD session triggered by protocols refers to the BFD session dynamically
triggered by routing protocols.
In dynamic establishment mode, the system processes My Discriminator and Your
Discriminator in the following ways:
– Dynamically assigning My Discriminator
When an application program triggers the dynamic establishment of BFD sessions,
the system assigns a value from the dynamic session discriminators as the My
Discriminator of the BFD session. The system sends a BFD control packet with
the value of Your Discriminator as 0 (the value of My Discriminator is the
assigned value, and the state is Down) to the peer system to negotiate a session.
NOTE
The system distinguishes static BFD session and dynamic BFD session according to the
classification of discriminators. The value of My Discriminator for static BFD session
ranges from 1 to 8191, and the value of My Discriminator for dynamic BFD session ranges
from 8192 to 16,383.
– Self-learning Your Discriminator
Upon receiving the BFD control packet with the value of Your Discriminator as 0,
the system on one end of the BFD session determines whether the packet matches
the local BFD session according to the quadruplet (source IP address, destination IP
address, outbound interface, and VPN index). If yes, the system learns the value of
My Discriminator in the received packet to obtain the value of Your
Discriminator.
Session Establishment Process

BFD establishes a session by using three-way handshake. When sending the BFD control
packet, the sender fills the Sta field with the current session status on the local end. The
receiver transfers the BFD state machine and establishes the session according to the Sta field
of the received BFD control packet and the current session status on the local end. Taking the
establishment of BFD session as an example, Figure 2-102 shows the transference of the state
machine.

Figure 2-102 BFD session establishment
Router_A Router_B
Sta: Down Sta: Down

Down Down
Down-> Init Down-> Init

Sta: Init Sta: Init
Init-> Up
Sta: Up Init-> Up
Sta: Up
1. After receiving the message from the upper-layer protocol, BFDs of Router_A and
Router_B send BFD control packets with the status as Down. In static BFD session with
manually designated discriminator, the value of Your Discriminator in the packet is
manually designated. In static BFD session with negotiated discriminator, the value of
Your Discriminator in the packet is negotiated by both parties. In the dynamic
establishment of BFD sessions, the value of Your Discriminator is 0.
2. After receiving the BFD control packet with the status as Down, Router_B switches the
session status to Init, and sends a BFD control packet with the status as Init. The change
of BFD sessions of Router_A is the same as Router_B.
3. After receiving the BFD control packet with the status as Init, Router_B switches the
session status to Up, and sends a BFD control packet with the status as Up. The change
of BFD sessions of Router_A is the same as Router_B.
4. When the statuses of Router_A and Router_B are both Up, the session is successfully
established and starts to detect the link.
After the status switches from Down to Init, a timeout timer is enabled on Router_A and
Router_B respectively. If the routers do not receive the BFD control packet whose status is
Init or Up within the timeout, the BFD session status in the local system automatically
switches to Down.
2.4.4 Configuring BFD Using the Web UI

This section describes how to configure BFD using the web UI.
Procedure
Step 1 Choose System > High Availability > BFD.

Step 2 Enable global BFD.

1. On the BFD Global Configuration page, select the Enable check box of BFD Global
Enable.
2. Set the multicast default IP address for BFD.
3. Click Apply.
Step 3 Click to refresh and display global BFD statistics.
Step 4 Click . The New BFD page is displayed.
Step 5 Set BFD parameters.

BFD Name Indicates the name of a BFD session.
Description Indicates the description of a BFD session.
Probing Type Two probing types are available:

l Peer IP address-based probing
l Broadcast IP address-based probing
Peer IP Address Indicates the peer IP address bound to a BFD session.
Bind Interface Indicates the interface bound to a BFD session.
Interface Status Determines whether the BFD status is bound to the interface
Synchronization status.
This item is displayed only when the probing type is set to
Broadcast IP address-based probing.
Source IP Indicates the source IP address of a BFD session.

When Probing Type is set to Broadcast IP, the xxx is
displayed as 169.254.255.254, indicating that the source IP
address used to send probe packets is the reserved address
169.254.255.254 as stipulated by RFC.
Local Discriminator Indicates the local discriminator of a BFD session.
Remote Discriminator Indicates the remote discriminator of a BFD session.
Advanced Displays advanced configuration items.
Sending Interval Indicates the sending interval of a BFD session.
Receiving Interval Indicates the receiving interval of a BFD session.
Local Detection Multiple Indicates the local detection multiple of a BFD session.
Waiting for Recovery Indicates the recovery waiting time of a BFD session.
Time
Step 6 Click OK.
----End

2.4.5 Configuring BFD Using the CLI

This section describes how to configure BFD using the CLI.
2.4.5.1 Configuring Global BFD Functions

You need to globally configure the functions required for static and dynamic BFD, including
enabling the global BFD function (mandatory) and delaying the Up state change of the BFD
session (optional), configuring the default multicast address for one-hop BFD (optional), and
enabling passive echo (optional).
Context
Enabling the global BFD function is mandatory when configuring BFD. When you enable the
global BFD function, the BFD view is displayed. In the BFD view, you can configure the
following global optional functions based on your network requirements:
Delaying the Up State Change of the BFD Session
In actual networking, some devices enable traffic switchover based on the BFD session status.
However, the routing protocol becomes Up later than the interface. As a result, traffic fails to
find the route when switched back, and is therefore lost. After you delay the Up state change
of the BFD session, the session will become Up a period after the fault is rectified, making up
the defect that the routing protocol becomes Up later than the interface.
Configuring the Default Multicast Address for One-hop BFD
When you perform one-hop BFD on the Layer-3 physical interfaces without IP addresses or
Layer-2 interfaces, use the default multicast IP address.
By default, the default multicast IP address for BFD is 224.0.0.184.
The default multicast IP address must be changed in the following situations:
l Other protocols on the network use this multicast IP address.
l If there are overlapping BFD sessions on the BFD path, for example, Layer-3 interfaces
are connected by BFD-enabled Layer-2 switching devices, the devices where different
devices reside must be configured with different default multicast IP addresses. This
prevents BFD packets from being forwarded incorrectly.
l If the Layer-2 interfaces of the two devices are connected through a Layer-2 switch that
provides the BFD function, and multicast IP addresses are used to set up BFD sessions,
when the global BFD function is enabled on the switch, run the default-ip-address
command to configure different default multicast IP addresses for the two devices and
switch. Otherwise, the switch cannot forward the BFD multicast packets, resulting in
BFD session interruption.
Enabling Passive Echo
The BFD passive echo function enables the device to communicate with an echo-supported
device on the network. This function applies only to one-hop detection.
Procedure
system-view

Step 2 Enable the global BFD function and access the BFD global view.
bfd
Step 3 Set the Up state change delay of the BFD session.

delay-up seconds
By default, the Up state change delay of the BFD session is 0 second. That is, the Up state
change of the BFD session is not delayed.
Step 4 Optional: Set the default multicast IP address for BFD.
default-ip-address ip-address
Step 5 Enable the BFD passive echo function.

echo-passive { all | acl basic-acl-number }
l If you configure all, the passive echo function of all BFD sessions is enabled.
l If you configure acl basic-acl-number, the passive echo function of BFD sessions is
determined by the ACL rule. That is, the passive function of only ACL-compliant BFD
sessions is enabled.
NOTE
BFD echo packets loop back through ICMP redirection on the peer end. In an IP packet
encapsulating the BFD echo packet, the destination address and source address are both the IP
address of the local outbound interface. Therefore, the ACL rule must allow the source IP
addresses of both the local end and peer end.
Step 6 Run:
peer-ip peer-ip mask-length ttl { single-hop | multi-hop } ttl-value
Set the TTL of the BFD packet.

The default TTL of the BFD packet varies with the BFD session type. In static BFD sessions,
the TTL of the single-hop BFD packet is 255 and the TTL of the multi-hop BFD packet is
254. In dynamic BFD sessions, the TTL of the single-hop BFD packet is 255; the TTL of the
multi-hop BFD packet is 253.
NOTE
You can use this command to set the TTL globally to enable Huawei devices running different FW versions to
interwork with each other and non-Huawei devices.
Step 7 Run:
multi-hop destination-port { 3784 | 4784 }
Configure the number of the default destination port for the multi-hop BFD control packet.
By default, destination port 3784 is used for the multi-hop BFD control packet.
NOTE
According to the BFD draft, 4784 is the destination port number of multi-hop BFD session packets.
During interworking with devices of earlier versions, the FW chooses 3784 as the destination port number of
multi-hop BFD session packets. During interworking with the devices of other vendors, the FW uses 4784 as
the destination port number of multi-hop BFD session packets.
----End
2.4.5.2 Configuring Static BFD

This section describes how to configure static BFD including creating and configuring static
BFD sessions and adjusting static BFD session parameters.

2.4.5.2.1 Creating a Static BFD Session

By creating BFD sessions on both ends of an IP link, you can detect faults on the link rapidly.
Static BFD sessions support one-hop detection and multi-hop detection. You can use the
detection method according to the network of a session.
Prerequisites
Before you configure a static BFD session, complete the following tasks:
l Correctly connecting interfaces and setting IP addresses.
l Configuring routing protocols for the reachability of the network layer.
l Configure global BFD functions, including enabling BFD and adjusting global
parameters. For details, see 2.4.5.1 Configuring Global BFD Functions.
Context
One-hop detection and multi-hop detection of static BFD sessions are described as follows:
l One-hop detection detects the connectivity of the IP link between two directly-connected
systems. One-hop refers to a hop of the IP address.
Only one BFD session exists on the specified interface between the two systems going
through BFD one-hop detection.
l Multi-hop detection detects any paths between two systems. The paths may cover
multiple hops or even overlap in certain parts.
To detect and monitor direct links (or links connected by a Layer-2 switch) rapidly, you can
configure either BFD one-hop detection or multi-hop detection. However, the former is
recommended.
If the peer IP address resides on different network segments from the IP address of the local
outbound interface, you can configure only multi-hop detection to rapidly detect and monitor
the connectivity of IP links. By creating BFD sessions on both ends of a multi-hop path, you
can detect faults on the path rapidly.
To detect the physical link status using BFD, static BFD sessions can be configured in the
following ways:
l Specifying the peer IP address
If the peer IP address is known, bind the BFD session to this IP address and send BFD
control packets to the IP address.
l Using the default IP address
If the peer IP address cannot be specified (in some cases, the peer end does not have an
IP address), bind the BFD session to a multicast address and send BFD control packets
to the multicast address. The multicast address can be adjusted as required. For details,
see 2.4.5.1 Configuring Global BFD Functions.
Creating a BFD session through the default IP address is valid only for one-hop
detection.
NOTE
When multiple protocols are bound to one static BFD session, the change of the session status affects all
related protocols.

Procedure
system-view
Step 2 Select the following configuration methods according to the network status of both ends
where the static BFD session is created.
l For the Layer-3 interfaces with IP addresses, create a BFD binding and set up BFD
sessions:
bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [ interface
interface-type interface-number ] [ source-ip source-ip [ auto ] ]
l For Layer-2 interfaces and the Layer-3 interfaces without IP addresses, create a static
BFD session (by using the default multicast IP address) and access the BFD session
view:
bfd cfg-name bind peer-ip default-ip interface interface-type interface-number
[ source-ip source-ip ]
Step 3 Configure the discriminator.
l Configure a local discriminator.
discriminator local local-discr-value
l Configure a remote discriminator.

discriminator remote remote-discr-value
NOTE
l The local discriminator must correspond to the remote discriminator on both ends of a BFD session.
Otherwise, the session cannot be established.
l For a BFD session bound to the default multicast address, the local discriminator cannot be the same
as the remote one.
l The local and remote discriminators cannot be changed once they are created.
Step 4 Commit the configuration.

commit
NOTE
After all necessary parameters (such as the local and remote discriminators) are specified, you must run
the commit command to successfully create a BFD session.
----End
Example
# Create static BFD session test on FW_A, set the peer IP address to 10.1.1.1, and set the
local discriminator to 10 and remote one to 20.
<FW_A> system-view
[FW_A] bfd
[FW_A-bfd] quit
[FW_A] bfd test bind peer-ip 10.1.1.1
[FW_A-bfd-session-test] discriminator local 10
[FW_A-bfd-session-test] discriminator remote 20
[FW_A-bfd-session-test] commit
# Create static BFD session test on FW_B, set the peer IP address to 10.1.1.2, and set the
local discriminator to 20 and remote one to 10.
<FW_B> system-view
[FW_B] bfd

[FW_B-bfd] quit
[FW_B] bfd test bind peer-ip 10.1.1.2
[FW_B-bfd-session-test] discriminator local 20
[FW_B-bfd-session-test] discriminator remote 10
[FW_B-bfd-session-test] commit
Follow-up Procedure
l Run the display bfd configuration command to display the configuration information
about the static BFD session. The following uses the information that is displayed on
FW_A as an example.
<FW_A> display bfd configuration static verbose
------------------------------------------------------------------------------
--
BFD Session Configuration Name :
test
------------------------------------------------------------------------------
--
Local Discriminator : 10 Remote Discriminator : 20
BFD Bind Type : Peer IP Address
Bind Session Type : Static
Bind Peer IP Address : 10.1.1.1
Bind Interface : -
Select Board : -
Track Interface : -
TOS-EXP : 6 Local Detect Multi : 3
Min Tx Interval (ms) : 1000 Min Rx Interval (ms) : 1000
Proc interface status : Disable WTR Interval (ms) : -
Bind Application : No Application Bind
Session Description : -
------------------------------------------------------------------------------
--
Total Commit/Uncommit CFG Number : 1/0
The local and remote discriminators, interface bound to the session, and peer IP address
configured on FW_A are displayed in the output information. According to the statistics,
the configuration of the session is submitted.
l Run the display bfd session command to display the information about the static BFD
session. The following uses the information that is displayed on FW_A as an example.
<FW_A> display bfd session static
------------------------------------------------------------------------------
--
Local Remote PeerIpAddr State Type InterfaceName
------------------------------------------------------------------------------
--
10 20 10.1.1.1 Up S_IP_PEER -
According to the output, if the BFD session is in Up state, the BFD session between two
devices is established. If the BFD session is in Down state, it failed to be established.
2.4.5.2.2 (Optional) Adjusting Session Detection Parameters

When you create a BFD session, adjust the BFD control packet sending interval, receiving
interval, and local detection multiple of the device according to the network status and
performance. The parameter adjustment does not affect the status of existing BFD sessions.
Context
The detection parameters of a BFD session includes the BFD control packet sending interval,
receiving interval, and local detection multiple. After detection parameters are changed, the
mapping between valid parameters and configured parameters on the local and peer devices is
as follows:

l Actual BFD control packet sending interval in the local = maximum (configured local
sending interval and configured peer receiving interval)
l Actual BFD control packet receiving interval in the local = maximum (configured peer
sending interval and configured local receiving interval)
l In asynchronous mode, actual BFD control packet detection interval in the local = Actual
local receiving interval x Configured peer BFD detection multiple
l In demand mode, actual BFD control packet detection interval in the local = Actual local
sending interval x Configured local BFD detection multiple
NOTE
When the network is in poor quality or overloaded, increase the BFD detection interval as required.
A larger BFD detection interval is required when a low-speed interface (such as virtual template, dialer, or
tunnel interface), the IPSec or L2TP tunnel, or traffic limiting through QoS is used.
For example:
l The configured local sending interval is 300 ms, receiving interval is 300 ms, and
detection multiple is 4.
l The configured peer sending interval is 400 ms, receiving interval is 600 ms, and
detection multiple is 5.
Then,
l The actual sending interval in the local is the maximum value between 300 ms and 600
ms, namely, 600 ms. The actual receiving interval is the maximum value between 400
ms and 300 ms, namely, 400 ms. The actual detection interval in asynchronous mode is
2000 ms (400 ms x 5). The actual detection interval in demand mode is 2400 ms (600 ms
x 4).
l The actual sending interval on the peer end is the maximum value between 400 ms and
300 ms, namely, 400 ms. The actual receiving interval is the maximum value between
300 ms and 600 ms, namely, 600 ms. The actual detection interval in asynchronous mode
is 2400 ms (600 ms x 4). The actual detection interval in demand mode is 2000 ms (400
ms x 5).
NOTE
The system automatically changes the local sending interval and receiving interval to random values
ranging from 2,000 ms to 3,000 ms upon detecting the BFD session in Down state. When the BFD
session becomes Up, the system restores the intervals to the configured values. This limits the
consumption over system resources.
Procedure
system-view
Step 2 Access the BFD session view.

bfd cfg-name
Step 3 Set the BFD control packet sending interval.

min-tx-interval interval
By default, the minimum sending interval is 1000 ms.
Step 4 Set the BFD control packet receiving interval.

min-rx-interval interval

By default, the minimum receiving interval is 1000 ms.
Step 5 Set the local detection multiple.

detect-multiplier multiplier
By default, the local detection multiple is 3.

commit
NOTE
To change session parameters (by using the min-tx-interval, min-rx-interval, detect-multiplier, tos-
exp, wtr, or description command) after a BFD session is created, you must run the commit command.
In this case, the configurations can take effect.
----End
2.4.5.2.3 (Optional) Configuring Auto-negotiation of Static Discriminators

By configuring the auto-negotiation of static discriminators, you can enable the connection to
the device that establishes BFD sessions dynamically. The auto-negotiation function of static
discriminators is mainly applied to static routes.
Context
This function is used, when BFD interworks with the static route and the local device needs to
communicate with the peer device, which uses the dynamic BFD session.
Local and remote discriminators cannot be configured on the device when you configure the
auto-negotiation of static discriminators.
The configuration difference between the static auto-negotiated BFD session and the static
BFD session lies in:
l After you create the static auto-negotiation configuration by running the bfd bind peer-
ip source-ip auto command, the BFD session can be established without the commit
command executed.
l After the parameters (such as the BFD control packet sending interval, receiving interval,
and local detection multiple) of the static auto-negotiated BFD session are changed, they
take effect without the commit command executed.
Procedure
system-view
Step 2 Enable the global BFD function and access the BFD global view.
bfd

quit
Step 4 Create a static auto-negotiated BFD session with the static discriminator.
bfd cfg-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [ interface
interface-type interface-number ] source-ip source-ip auto
l The peer-ip value cannot be a multicast IP address.

l If both interface and source-ip are specified, the source IP address must be the same as
the IP address of the interface.
----End
2.4.5.2.4 (Optional) Configuring Session Descriptions

By configuring session descriptions when you create static BFD sessions, you can better
understand the configurations. Generally, a description explains the devices on both ends of a
session.
Context
NOTE
The description command is valid only for statically configured BFD sessions, but invalid for the
dynamically configured BFD sessions and the auto-negotiated BFD sessions with static discriminators.
Procedure
system-view

bfd cfg-name
Step 3 Set a BFD session description.

description description
By default, the BFD session description is empty.

commit
NOTE
----End
2.4.5.2.5 (Optional) Configuring the Priority for Sending BFD Packets

Adjusting the priority for sending BFD packets changes the sending order in the case of
congestion at the interface.
Procedure
system-view

bfd cfg-name
Step 3 Set the priority for sending BFD packets.

tos-exp tos-value
By default, the priority is 6, namely, the highest priority.

In the case of congestion, the system preferentially sends the BFD packet with a higher
priority. You are advised to change the default configuration only after you have known the
related affects.
commit
NOTE
----End
2.4.5.2.6 (Optional) Configuring the BFD WTR Time

The status change of the static BFD session will take effect after the Wait to Recovery (WTR)
time, which avoids the affects caused by BFD session flapping on upper-layer protocols.
Context
If a BFD session flaps, BFD-related applications will be frequently switched between active
and standby devices. To avoid this case, you can configure the WTR time for the BFD
session. When a BFD session changes from Down to Up, the BFD will notify this status
change to upper-layer applications only after the WTR time.
Procedure
system-view

bfd cfg-name
Step 3 Set the WTR time for the BFD session.

wtr wtr-value
By default, the time of waiting for recovery of the BFD session is 0, indicating no waiting.
NOTE
The BFD session is bidirectional. The detection is performed by BFD sessions set up on both ends
respectively. If WTR is needed, configure it on two ends manually. Or, when the status of the session on
one end changes, the applications on both ends can find that the status of the BFD sessions are
inconsistent.

commit
NOTE
----End
2.4.5.3 Configuring Interworking Between BFD and Other Functions

BFD interworking includes static and dynamic BFD interworking. Static BFD interworking
refers to interworking between BFD and hot standby, static route, policy-based routing (PBR),

and DHCP. Dynamic BFD interworking refers to interworking between BFD and RIP, OSPF,
OSPFv3, BGP, and BGP4+. BFD and IS-IS can carry out either static or dynamic
interworking.
2.4.5.3.1 Configuring Interworking Between BFD and Hot Standby

This section describes the procedure and precautions for configuring interworking between
BFD and hot standby.
Prerequisites
Before you configure interworking between BFD and hot standby, complete the following
tasks on devices at both ends:
l Manually configuring the static BFD session. For details, see 2.4.5.2.1 Creating a Static
BFD Session.
l Configuring the hot standby. For details, see 2.1 Hot Standby.
Procedure
system-view
Step 2 Configure a VGMP group to monitor the status of a BFD session.
hrp track bfd-session local-discr-value
----End
2.4.5.3.2 Configuring Interworking Between BFD and Static Routes

To provide IP-link for public IPv4 static routes by using BFD sessions, you can bind static
routes to BFD sessions. One static route can be bound to only one session.
Prerequisites
Before you configure interworking between BFD and static routes, perform the following on
devices at both ends:
l Setting the IP addresses of interfaces to ensure reachable adjacent nodes.
l Configuring a static route. For details, see 5.3.4 Configuring Static Route-CLI.
BFD Session.
The static BFD session can be one-hop or multi-hop.
Procedure
system-view
Step 2 Configure interworking between BFD and a static route.

ip route-static [ vpn-instance vpn-instance-name ] ip-address { mask | mask-
length } { nexthop-address | interface-type interface-number [ nexthop-address ]

| vpn-instance vpn-instance-name nexthop-address } [ preference preference ]

track bfd-session cfg-name [ description description ]
l Before you configure the interworking, make sure that the destination IP address and
next-hop IP address (or outbound interface) are the same as those of the static route.
Generally, configure the static route, and then bind it to the BFD session.
l cfg-name specifies the BFD session, where the link to be monitored is specified.
----End
2.4.5.3.3 Configuring BFD-PBR Interworking

This section describes the procedure and precautions for configuring BFD-PBR interworking.
Prerequisites
Before you configure BFD-PBR interworking, complete the following tasks on devices at
both ends:
BFD Session.
The static BFD session can be of the one-hop or multi-hop type.
l Configuring the IP unicast PBR. For details, see 6.2.5 Configuring PBR Using the
CLI.
Context
You need to configure the interworking function only on the device where the PBR function is
enabled.
When the interworking function is configured and the BFD session is deleted from the remote
device, the interworking function fails. In this case, the local device continues forwarding
traffic based on the PBR.
Procedure
system-view
Step 2 Accesses the view of the PBR policy.

policy-based-route
Step 3 Create a PBR rule and access its view.

rule name rule-name
Step 4 Configure interworking between PBR and BFD.

track bfd-session local-discr-value
NOTE
A PBR rule can interwork with either IP-link or BFD.
----End
2.4.5.3.4 Configuring BFD-DHCP Interworking

This section describes the procedure and precautions for configuring BFD-DHCP
interworking.

Prerequisites
Before you configure BFD-DHCP interworking, complete the following tasks:
1. Configuring the device as the DHCP client and enable the device to obtain the IP address
from the DHCP server. For details, see 4.7.5.3 Configuring the Device as a DHCP
Client.
2. Manually configuring static BFD sessions on devices at both ends. For details, see
2.4.5.2.1 Creating a Static BFD Session.
The neighbor relationship can be successfully negotiated only if static BFD sessions
(excluding auto-negotiated static sessions), must be specified with local and remote
discriminators.
When one end of the BFD session is the DHCP client, the next hop of the static BFD
session needs to be specified as nexthop dhcp. That is, when the device acts as the
DHCP client, the obtained gateway address serves as the next-hop IP address for
forwarding BFD packets.
For the peer DHCP client for BFD interworking, you need to specify the peer IP address
in the static BFD session as the IP address of the DHCP client. If the IP address obtained
by the DHCP client changes, you need to re-create a BFD session.
Context
In dual-uplink networking, if active/standby switchover between links is required, the active
link must be assigned a high-priority route. The smaller the value, the higher the priority.
When the device acts as the DHCP client, the priority of the default route obtained from the
DHCP server is 245. In dual-uplink networking, if the active link is in DHCP mode and the
standby link is in 4G LTE mode, the route priority of the standby link must be larger than 245.
Thereby, in DHCP-BFD interworking, the system disconnects the DHCP link upon
identifying its fault. In this way, traffic is switched to the standby link.
NOTE
To implement DHCP-BFD interworking, you need to only configure the device serving as the DHCP
client.
Procedure
system-view

Step 3 Associate DHCP with a BFD session.

dhcp client track bfd-session local-id
During DHCP-BFD interworking, the bound local-id value is the local discriminator of the
monitored BFD session, not the BFD configuration name.
----End
2.4.5.3.5 Configuring BFD-RIP Interworking

On a network that runs high-rate data services, BFD for RIP can be configured to quickly
detect and respond to network faults.

Prerequisites
Before configuring BFD for RIP, complete the following tasks:
l Assigning an IP address to each interface to ensure reachability between neighboring

nodes at the network layer
l Establishing the RIP Neighbor Relationship
Context
Generally, RIP uses timers to receive and send Update messages to maintain neighbor
relationships. If a RIP device does not receive an Update message from a neighbor after the
Age timer expires, the RIP device will announce that this neighbor goes Down. The default
value of the Age timer is 180s. If a link fault occurs, RIP can detect this fault after 180s. If
high-rate data services are deployed on a network, a great deal of data will be lost during the
aging time.
BFD provides millisecond-level fault detection. It can rapidly detect faults in protected links
or nodes and report them to RIP. This speeds up RIP processes' response to network topology
changes and achieves rapid RIP route convergence.
In BFD for RIP, BFD session establishment is triggered by RIP. When establishing a neighbor
relationship, RIP will send detection parameters of the neighbor to BFD. Then, a BFD session
will be established based on these detection parameters. If a link fault occurs, the local RIP
process will receive a neighbor unreachable message within seconds. Then, the local RIP
device will delete routing entries in which the neighbor relationship is Down and use the
backup path to transmit messages.
Either of the following methods can be used to configure BFD for RIP:
l Enable BFD in a RIP process: This method is recommended when BFD for RIP needs to
be enabled on most RIP interfaces.
l Enable BFD on RIP interfaces: This method is recommended when BFD for RIP needs
to be enabled on a small number of RIP interfaces.
Procedure
l Enable BFD in a RIP process.
a. Access the system view.
system-view
b. Enable BFD.
bfd
c. Return to the system view.

quit
d. Access the RIP view.

rip process-id
e. Enable BFD in the RIP process and establish a BFD session.

bfd all-interfaces enable
If BFD is enabled globally, RIP will use default BFD parameters to establish BFD
sessions on all the interfaces where RIP neighbor relationships are in the Up state.

f. Optional: Configure BFD session parameters.

bfd all-interfaces { min-rx-interval min-receive-value | min-tx-
interval min-transmit-value | detect-multiplier detect-multiplier-
value } *
BFD parameter values are determined by the actual network situation and network
reliability requirement.
n If links have a high reliability requirement, reduce the interval at which BFD
packets are sent.
n If links have a low reliability requirement, increase the interval at which BFD
packets are sent.
Running the bfd all-interfaces command changes BFD session parameters on all
RIP interfaces. The default detection multiplier and interval at which BFD packets
are sent are recommended.
g. (Optional) Perform the following operations to prevent an interface in the RIP
process from establishing BFD sessions:
n Run the quit command to return to the system view.
n Run the interface interface-type interface-number command to access the
view of a specified interface.
n Run the rip bfd block command to prevent the interface from establishing
BFD sessions.
l Enable BFD on RIP interfaces.
system-view
b. Enable BFD.
bfd
c. Return to the system view.

quit
d. Access the interface view.

e. Enable BFD.
rip bfd enable
f. (Optional) Configure BFD session parameters.

rip bfd { min-rx-interval min-receive-value | min-tx-interval min-
transmit-value | detect-multiplier detect-multiplier-value } *
----End
2.4.5.3.6 Configuring BFD-OSPF Interworking

You can configure BFD features on the link running OSPF in the scenarios where data
transmission poses high requirements on timeliness and OSPF convergence needs to be sped
up upon link status changes.
Prerequisites
Before you configure BFD-OSPF interworking, complete the following tasks on devices at
both ends:

l Configuring basic OSPF functions to enable neighbor relationship in Full state. For
details, see 5.6.5 OSPF Configuration Using the CLI.
Context
NOTE
Note that BFD-OSPF interworking needs to be configured on devices at both ends.
You can select one of the following modes to configure BFD-OSPF interworking:
l Enable BFD in the OSPF process.
To enable BFD on all interfaces in the OSPF process, enable BFD on all interfaces of
devices at both ends of the link where the BFD session is to be established.
l Enable BFD on the interface.
The priority of BFD on the interface is higher than that of BFD in the OSPF process.
To enable BFD on certain interfaces or enable certain interfaces to rapidly identify link
faults in the case that BFD is enabled in the OSPF process, you can enable BFD on the
specified interface.
Procedure
system-view
Step 2 Select one of the following configuration modes as required.

l Enable BFD in the OSPF process.
a. Access the OSPF view.
ospf [ process-id ]
b. Enable BFD in the OSPF process and create BFD sessions.

After BFD is enabled in the OSPF process, BFD sessions are created on all
interfaces whose neighbor status is Full in the process.
c. (Optional) Configure BFD session parameters.
bfd all-interfaces { detect-multiplier multiplier-value | min-rx-
interval receive-interval | min-tx-interval transmit-interval } *
n By default, the local detection multiple is 3, the minimum receiving interval is

1000 ms, and the minimum sending interval is 1000 ms.
n If no BFD packet is received from the peer end at the value of receive-interval
× multiplier-value (the value of receive-interval is negotiated based on the
local min-rx-interval and remote min-tx-interval), BFD mistakenly considers
that the neighbor becomes Down.
n If only parameters for the BFD session are specified, no BFD session is
created.
d. Return to the system view.
quit
e. Access the interface view.


f. (Optional) Disable the function of dynamically creating BFD sessions on the

interface.
ospf bfd block
After BFD is enabled on all interfaces in the OSPF process, you can run this
command on certain interfaces to reduce monitored links. This improves
performance.
l Enable BFD on the interface.
a. Access the interface view.
b. Enable BFD on the OSPF-enabled interface.

ospf bfd enable
c. (Optional) Configure BFD session parameters.

ospf bfd { detect-multiplier multiplier-value | min-rx-interval receive-
interval | min-tx-interval transmit-interval } *
n By default, the local detection multiple is 3, the minimum receiving interval is

1000 ms, and the minimum sending interval is 1000 ms.
n Because the priority of BFD on the interface is higher than that of BFD in the
OSPF process, the parameters of the BFD session on the interface enjoy higher
priorities than those of the BFD session in the OSPF process.
----End
2.4.5.3.7 Configuring BFD-BGP Interworking

BFD for BGP speeds up fault detection and therefore increases the route convergence speed.
Prerequisites
Before you configure BFD-BGP interworking, complete the following tasks on devices at
both ends:

l Configuring basic BGP functions to enable neighbor relationship in Full state. For
details, see 5.10.4 Configuring BGP-CLI.
Context
As technologies develop, voice and video services are widely applied. These services are
sensitive to the packet loss and delay. BGP periodically sends Keepalive packets to its peers
to detect the status of its peers. The detection mechanism, however, takes more than one
second. When the data transmission rate reaches the level of Gbit/s, such slow detection will
cause a large amount of data to be lost. As a result, the requirement for high reliability of
carrier-class networks cannot be met.
BFD for BGP can be used to reduce packet loss and delay. BFD for BGP detects faults on
links between BGP peers within 50 milliseconds. The fast detection speed ensures fast BGP
route convergence and minimizes traffic loss.

Procedure
system-view
Step 2 Access the BGP view.

bgp { as-number-plain | as-number-dot }
Step 3 (Optional) Access the BGP-VPN instance IPv4 address family view.
ipv4-family vpn-instance vpn-instance-name
NOTE
BFD for BGP can be configured for the VPN in this view. To configure BFD for BGP for the public
network, skip this step.
Step 4 (Optional) Configure BFD session parameters.

peer { group-name | ipv4-address } bfd { min-tx-interval min-tx-interval | min-rx-
interval min-rx-interval | detect-multiplier multiplier | wtr wtr-value } *
NOTE
The BFD parameters of peers take precedence over those of peer groups. If BFD parameters are
configured on peers, they will be used in BFD session establishment.
The default interval for transmitting BFD packets and the default detection multiplier are
recommended. When changing the default values, pay attention to the network status and the
network reliability requirement. A short interval for transmitting BFD packets can be
configured for a link that has a higher reliability requirement. A long interval for transmitting
BFD packets can be configured for a link that has a lower reliability requirement.
NOTE
There are three formulas: Actual interval for the local device to send BFD packets = max {Locally
configured interval for transmitting BFD packets, Remotely configured interval for receiving BFD
packets}, Actual interval for the local device to receive BFD packets = max {Remotely configured
interval for transmitting BFD packets, Locally configured interval for receiving BFD packets}, and
Local detection period = Actual interval for receiving BFD packets x Remotely configured BFD
detection multiplier.
For example:
l On the local device, the configured interval for transmitting BFD packets is 200 ms, the interval for
receiving BFD packets is 300 ms, and the detection multiplier is 4.
l On the peer device, the configured interval for transmitting BFD packets is 100 ms, the interval for
Then:
l On the local device, the actual interval for transmitting BFD packets is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval for receiving BFD packets is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying
300 ms by 5.
l On the peer device, the actual interval for transmitting BFD packets is 300 ms calculated by using
600 ms by 4.
wtr wtr-value can be specified in the command to suppress frequent BFD and BGP session
flapping caused by link flapping. If a BFD session over a link goes Down, it does not go Up
immediately after the link recovers. Instead, the BFD session waits for the WTR timer to
expire before going Up. If the link fails again before the WTR timer expires, BFD does not
send a link fault message to BGP, and the BGP session status is stabilized.

The default value of wtr-value is 0, which means that the WTR timer will not be started.
Step 5 Enable BFD for the peer or peer group and create a BFD session using default parameters.
peer { group-name | ipv4-address } bfd enable [ single-hop-prefer ]
single-hop-prefer takes effect only on IBGP peers. By default, if single-hop-prefer is not

specified, multi-hop sessions are established between direct IBGP peers (Huawei devices). To
interconnect a Huawei device and a non-Huawei device that defaults the sessions between
IBGP peers to single-hop, configure single-hop-prefer in the command.
After BFD is enabled for a peer group, BFD sessions will be created on the peers that belong
to this peer group and are not configured with the peer bfd block command.
Step 6 (Optional) Disable the peer from inheriting the BFD function of the peer group to which it
belongs.
peer ipv4-address bfd block
If a peer joins a peer group enabled with BFD, the peer inherits the BFD configuration of the
group and creates a BFD session. To prevent the peer from inheriting the BFD function of the
peer group, perform this step.
NOTE
The peer bfd block command and the peer bfd enable command are mutually exclusive. After the peer
bfd block command is run, the BFD session is automatically deleted.
----End
2.4.5.3.8 Configuring BFD-BGP4+ Interworking

BFD for BGP4+ speeds up fault detection and therefore increases the route convergence
speed.
Prerequisites
Before you configure BFD-BGP4+ interworking, complete the following tasks on devices at
both ends:
l Configuring basic BGP4+ functions to enable neighbor relationship in Full state. For
details, see 5.11.3 BGP4+ Configuration.
Context
BFD can rapidly detect IPv6 forwarding failures. By adopting the BFD fast detection
mechanism, an IPv6 network can transmit voice services, video services, and VoD services
with high QoS. This enables service provides to provide their customers with highly available
and reliable voice over IP (VoIP) and other real-time services.
BGP periodically sends Keepalive messages to the peer to detect faults on the neighbor. This
mechanism, however, takes more than one second to detect a fault. When the data rate is up to
Gbit/s, the detection mechanism causes a great packet loss. This mechanism fails to meet the
requirement on the reliability of core networks.
BGP introduces BFD for BGP4+. The fast detection mechanism of BFD can faster detect
faults on the links between BGP peers. The convergence of networks therefore speeds up.

Procedure
system-view
Step 2 Access the BGP view.

bgp { as-number-plain | as-number-dot }
Step 3 (Optional) Access the BGP-VPN instance IPv6 address family view.
ipv6-family vpn-instance vpn-instance-name
NOTE
BFD for BGP can be configured for the VPN in this view. To configure BFD for BGP for the public
network, skip this step.
Step 4 Enable BFD for the peer or peer group and create a BFD session using default parameters.
peer { group-name | ipv6-address } bfd enable [ single-hop-prefer ]
single-hop-prefer takes effect only on IBGP peers. By default, if single-hop-prefer is not

specified, multi-hop sessions are established between direct IBGP peers (Huawei devices). To
interconnect a Huawei device and a non-Huawei device that defaults the sessions between
IBGP peers to single-hop, configure single-hop-prefer in the command.
After BFD is enabled for a peer group, BFD sessions will be created on the peers that belong
to this peer group and are not configured with the peer bfd block command.
Step 5 (Optional) Modify BFD session parameters.
peer { group-name | ipv6-address } bfd { min-tx-interval min-tx-interval | min-rx-
interval min-rx-interval | detect-multiplier multiplier | wtr wtr-value } *
NOTE
The BFD parameters of peers take precedence over those of peer groups. If BFD parameters are
configured on peers, they will be used in BFD session establishment.
The default interval for transmitting BFD packets and the default detection multiplier are
recommended. When changing the default values, pay attention to the network status and the
network reliability requirement. A short interval for transmitting BFD packets can be
configured for a link that has a higher reliability requirement. A long interval for transmitting
BFD packets can be configured for a link that has a lower reliability requirement.

NOTE
There are three formulas: Actual interval for the local device to send BFD packets = max {Locally
configured interval for transmitting BFD packets, Remotely configured interval for receiving BFD
packets}, Actual interval for the local device to receive BFD packets = max {Remotely configured
interval for transmitting BFD packets, Locally configured interval for receiving BFD packets}, and
Local detection period = Actual interval for receiving BFD packets x Remotely configured BFD
detection multiplier.
For example:
l On the local device, the configured interval for transmitting BFD packets is 200 ms, the interval for
l On the peer device, the configured interval for transmitting BFD packets is 100 ms, the interval for
Then:
l On the local device, the actual interval for transmitting BFD packets is 600 ms calculated by using
300 ms by 5.
l On the peer device, the actual interval for transmitting BFD packets is 300 ms calculated by using
600 ms by 4.
wtr wtr-value can be specified in the command to suppress frequent BFD and BGP session
flapping caused by link flapping. If a BFD session over a link goes Down, it does not go Up
immediately after the link recovers. Instead, the BFD session waits for the WTR timer to
expire before going Up. If the link fails again before the WTR timer expires, BFD does not
send a link fault message to BGP, and the BGP session status is stabilized.
The default value of wtr-value is 0, which means that the WTR timer will not be started.
Step 6 (Optional) Disable the peer from inheriting the BFD function of the peer group to which it
belongs.
peer ipv6-address bfd block
If a peer joins a peer group enabled with BFD, the peer inherits the BFD configuration of the
group and creates a BFD session. To prevent the peer from inheriting the BFD function of the
peer group, perform this step.
NOTE
The peer bfd block command and the peer bfd enable command are mutually exclusive. After the peer
bfd block command is run, the BFD session is automatically deleted.
----End
2.4.5.3.9 Configuring BFD-IS-IS Interworking

You can configure BFD interworking with IS-IS in the scenarios with high requirements on
data transmission and IS-IS convergence needs to be sped up upon link status changes.
Prerequisites
Before you configure BFD-IS-IS interworking, complete the following tasks on devices at
both ends:

l Configuring basic IS-IS functions to enable neighbor relationship in Full state. For
details, see 5.8.3 IS-IS Configuration.
l To configure static BFD interworking with IS-IS, manually configure static BFD
sessions first. For details, see 2.4.5.2.1 Creating a Static BFD Session.
Context
Connection status between an IS-IS device and its neighbors can be monitored by exchanging
Hello packets at intervals. The minimum allowable sending interval is 3s, and a neighbor is
declared Down after at least three intervals during which no response Hello packet is received
from the neighbor. IS-IS takes more than one second to detect that a neighbor becomes Down,
resulting in loss of a large amount of high-speed data.
To solve this problem, BFD must be configured for IS-IS. BFD provides millisecond-level
fault detection. After detecting a link or node failure, BFD will notify IS-IS of the failure,
accelerating the IS-IS route convergence speed.
BFD interworking with IS-IS can be static or dynamic.
A static BFD session can only be established and released manually. A configuration error
will lead to a BFD failure. For example, if a local or remote discriminator is incorrectly
configured, a BFD session will not work properly.
Dynamic BFD for IPv4 IS-IS implements dynamic setup of BFD sessions. When a new IS-IS
neighbor relationship is set up, BFD is notified of the neighbor parameters and the detection
parameters (including source and destination IP addresses). Then a BFD session will be
established based on the received neighbor parameters. Dynamic BFD is more flexible than
static BFD.
Procedure
l Enable static BFD on an interface.
system-view
b. Access the interface view.

c. Enable static BFD.
isis bfd static

l Enable dynamic BFD for an IS-IS IPv4 process.
system-view
b. Access the IS-IS view.
isis [ process-id
c. Enable BFD for IS-IS.

After BFD is enabled globally and the neighbor status becomes Up, IS-IS adopts
default BFD parameters to establish BFD sessions on all interfaces.
d. (Optional) Set the parameters for establishing BFD sessions for all interfaces.
bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value } *
The command execution result is applicable to BFD session parameters on all IS-IS
interfaces.
e. Return to the system view.
quit
To disable the BFD function on an interface, run the isis bfd block command in the
interface view to disable the interface from establishing BFD sessions.
l Enable dynamic BFD on an IPv4 interface.
system-view
b. Access the interface view.
c. Enable BFD.
isis bfd enable
After BFD is configured globally and the neighbor status is Up (on a broadcast
network, DIS is in the Up state), default BFD parameters will be used to establish
BFD sessions on the specified interface.
d. (Optional) Configure BFD session parameters.
isis bfd { min-rx-interval receive-interval | min-tx-interval transmit-interval |
detect-multiplier multiplier-value } *
NOTE
The priority of BFD configured on an interface is higher than that of BFD configured for a
process. If BFD session parameters are configured for both a process and an interface, the
parameters on the interface will be used to establish a dynamic BFD session.
----End
2.4.5.4 Maintaining BFD

After configuring BFD, you can run the display commands to view the configuration result,
session information, and related statistics. You can also clear statistics or enable debugging if
necessary.
Checking BFD Information

During routine maintenance, you can run the following commands in any view to learn about
BFD running status.
NOTE
You can view the information about BFD session statistics and BFD sessions only after parameters for
BFD sessions are specified and BFD sessions are successfully created.

Table 2-5 Checking BFD information

Action Command
Check the configuration of display bfd configuration { all | dynamic | peer-ip peer-ip
the BFD session. [ vpn-instance vpn-instance-name ] | static [ name cfg-
name ] | static-auto } [ verbose ]
Check the information display bfd interface [ interface-type interface-number ]

about the BFD-enabled
interface.
Check the information display bfd session { all | discriminator local-discr-value |

about the BFD session. dynamic | peer-ip peer-ip [vpn-instance vpn-instance-
name ] | static | static-auto } [ verbose ]
Check global BFD display bfd statistics

statistics.
Check statistics on BFD display bfd statistics session { all | discriminator local-
sessions. discr-value | dynamic | peer-ip peer-ip [ vpn-instance vpn-
instance-name ] | static | static-auto }
Check the information display ospf [ process-id ] bfd session interface-type

about the BFD session interface-number [ router-id ]
triggered by the OSPF display ospf [ process-id ] bfd session { router-id | all }
neighbor.
Check the information display rm bfd-session [ vpn-instance vpn-instance-name ]

about the BFD session [ destination destination-address ] [ source source-address ]
stored in RM. [ interface interface-type interface-number ] [ protocol
ospf ]
display rm bfd-session all
Clearing BFD Statistics

To diagnose and locate BFD faults, you need to perform DHCP statistics for a period of time
to check the consistency between received and sent packets. Therefore, before you restart a
statistics operation, run the reset command to clear historical statistics.
NOTICE
BFD statistics cannot be restored after you clear them. Therefore, perform the operation with
caution.

Table 2-6 Clearing BFD statistics

Action Command
Clear statistics on received reset bfd statistics { all | discriminator discriminator-

and sent BFD packets. value }
Debugging BFD
When a BFD running fault occurs, you can run the debugging commands in the user view to
debug BFD, view the debugging information, and locate and analyze the fault.
Before you enable debugging functions, run the terminal monitor and terminal debugging
commands in the user view to enable terminal information display and debugging information
display on the terminal.
Enabling debugging functions will deteriorate system performance. After debugging
processes are complete, run the undo debugging all command in a timely manner to disable
the debugging functions.
For the description of debugging commands, refer to the Debugging Reference.
Table 2-7 Debugging BFD

Action Command
Enable all BFD debugging debugging bfd all

functions.
Enable the BFD defect debugging bfd defect-detect

detection debugging.
Enable the BFD error debugging bfd error

debugging.
Enable the BFD event debugging bfd event

debugging.
Enable the BFD state debugging bfd fsm

machine debugging.
Enable the BFD packet debugging bfd packet

debugging.
Enable the BFD process debugging bfd process

debugging.
Enable the BFD product debugging bfd product-interface

interface debugging.
Enable the BFD session debugging bfd session-management

management debugging.
Enable the BFD timer debugging bfd timer

debugging.


This section describes the configuration examples of BFD.
2.4.6.1 CLI: Example for Configuring Interworking Between BFD and Hot
Standby
Introduce the example for configuring interworking between BFD and hot standby according
to the example for configuring active/standby mode.
Network Requirements
The FW is deployed on the service node as a security device. Upstream and downstream
devices are routers. FW_A and FW_B work in active/standby mode
Figure 2-103 shows the networking diagram. The detailed description is as follows:
l OSPF is applied among the router and two FWs. The router sends service packets to the
Active FW according to the route calculation result.
l FW monitor the network egress through the interworking function between BFD and hot
standby. When the network egress on the link where FW_A resides is down, FW_B can
switch to active device and the service packets are sent to FW_B.
Figure 2-103 Networking diagram of the example for configuring interworking between BFD
and hot standby
FW_A
GE1/0/1 GE1/0/3
10.100.10.2/24 10.100.30.2/24 Router_A
192.168.1.0/24
1.1.1.2
GE1/0/2
10.100.50.2/24 GE1/0/2
10.100.50.3/24
2.2.2.2
GE1/0/1 GE1/0/3 Router_B

10.100.20.2/24 10.100.40.2/24
FW_B
BFD Session
Procedure
Step 1 Configure the hot standby function on FW_A.
<FW_A> system-view
# Add GigabitEthernet 1/0/1 to the Trust zone.



# Add GigabitEthernet 1/0/3 to the Untrust zone.


# Add GigabitEthernet 1/0/2 to the DMZ zone.

# Run the OSPF dynamic routing protocol on FW_A.

[FW_A] ospf 101
# Enable the function of adjusting the related cost value of OSPF according to the HRP status.
NOTICE
When the FW is deployed on the OSPF network to work in dual-system hot backup mode,
this command must be configured.
[FW] hrp adjust ospf-cost enable
# Configure the VGMP group to monitor the status of interfaces.

# Configure an HRP backup channel.

# Enable HRP.
[FW_A] hrp enable
Step 2 Configure the hot standby function on FW_B.
The configuration on the FW_B is similar to that on the FW_A. The differences are as
follows:

l The IP addresses of interfaces on FW_B should be different from those of interfaces on

FW_A; moreover, the IP addresses of the service interfaces corresponding to FW_B and
FW_A should not be on the same network segment.
l When OSPF is executed on FW_B, the route to the network segment directly connected
to the service interface on FW_B should be advertised.
l Run the hrp standby-device command on FW_B to specify FW_B as a standby device.
Step 3 Configure IP addresses and OSPF on the router to ensure the network is reachable. For
detailed configuration commands, refer to documents related to the router.
Step 4 Configure security policy to ensure that the users on network segment 192.168.1.0/24 can
access the Untrust zone.
The security policy configured on FW_A are automatically backed up to FW_B.

HRP_M[FW_A-policy-security] rule name ha
HRP_M[FW_A-policy-security-rule-ha] source-zone trust
HRP_M[FW_A-policy-security-rule-ha] destination-zone untrust
HRP_M[FW_A-policy-security-rule-ha] source-address 192.168.1.0 24
HRP_M[FW_A-policy-security-rule-ha] action permit
HRP_M[FW_A-policy-security-rule-ha] quit
Step 5 Configure BFD sessions on FW_A and Router_A.
# Configure BFD session 1 with peer IP address 1.1.1.2, local discriminator 10, and remote
discriminator 20 on FW_A.
HRP_M[FW_A] bfd
HRP_M[FW_A-bfd] quit
HRP_M[FW_A] bfd 1 bind peer-ip 1.1.1.2
HRP_M[FW_A-bfd-session-1] discriminator local 10
HRP_M[FW_A-bfd-session-1] discriminator remote 20
HRP_M[FW_A-bfd-session-1] commit
HRP_M[FW_A-bfd-session-1] quit
# Configure BFD session 1 with peer IP address 10.100.30.2, local discriminator 20, and
remote discriminator 10 on Router_A.
<Router_A> system-view
[Router_A] bfd
[Router_A-bfd] quit
[Router_A] bfd 1 bind peer-ip 10.100.30.2
[Router_A-bfd-session-1] discriminator local 20
[Router_A-bfd-session-1] discriminator remote 10
[Router_A-bfd-session-1] commit
[Router_A-bfd-session-1] quit
Step 6 Configure interworking between BFD and hot standby on FW_A.

HRP_M[FW_A] hrp track bfd-session 10
Step 7 Configure BFD sessions on FW_B and Router_B.
discriminator 20 on FW_B.
HRP_S[FW_B] bfd
HRP_S[FW_B-bfd] quit
HRP_S[FW_B] bfd 1 bind peer-ip 2.2.2.2
HRP_S[FW_B-bfd-session-1] discriminator local 10
HRP_S[FW_B-bfd-session-1] discriminator remote 20
HRP_S[FW_B-bfd-session-1] commit
HRP_S[FW_B-bfd-session-1] quit

remote discriminator 10 on Router_B.
<Router_B> system-view
[Router_B] bfd
[Router_B-bfd] quit
[Router_B] bfd 1 bind peer-ip 10.100.40.2
[Router_B-bfd-session-1] discriminator local 20
[Router_B-bfd-session-1] discriminator remote 10
[Router_B-bfd-session-1] commit
[Router_B-bfd-session-1] quit
Step 8 Configure interworking between BFD and hot standby on FW_B.

HRP_S[FW_B] hrp track bfd-session 10
----End
Configuration script of FW_A:
#
sysname FW_A
#
bfd
#
hrp enable
hrp track bfd-session 10
#
ip address 10.100.10.2 255.255.255.0
#
ip address 10.100.50.2 255.255.255.0
#
ip address 10.100.30.2 255.255.255.0
#
firewall zone trust
#
firewall zone dmz
#
#
bfd 1 bind peer-ip 1.1.1.2
discriminator local 10
discriminator remote 20
commit
#
ospf 101
area 0.0.0.0
network 10.100.10.0 0.0.0.255
network 10.100.30.0 0.0.0.255
#
security-policy
rule name ha
source-zone trust
action permit
#
return

Configuration script of FW_B:

#
sysname FW_B
#
bfd
#
hrp enable
hrp standby-device
hrp track bfd-session 10
#
ip address 10.100.20.2 255.255.255.0
#
ip address 10.100.50.3 255.255.255.0
#
ip address 10.100.40.2 255.255.255.0
#
firewall zone trust
#
firewall zone dmz
#
#
commit
#
ospf 101
area 0.0.0.0
network 10.100.20.0 0.0.0.255
network 10.100.40.0 0.0.0.255
#
security-policy
rule name ha
source-zone trust
action permit
#
return
2.4.6.2 CLI: Example for Configuring Interworking Between BFD and Static
Routes
If two static routes with different priorities to the same destination are configured, active and
standby links can be automatically switched through the probing over the reachability of the
gateway.
As shown in Figure 2-104, a company accesses the Internet through dual links. Static routes
are configured respectively between FW_A and FW_B as well as between FW_A and FW_C.
FW_A->FW_B is the active link, and FW_A->FW_C is the standby link. It is required that
traffic can be immediately switched to the standby link when the active link is faulty, and it
can be also switched back after the active link is recovered.

Figure 2-104 Networking diagram of configuring interworking between BFD and static
routes
ion FW_B
ss
Se /1 GE
D 1/0 24 19 1/0/
BF E
G .2/ 2.1 2
1 68
0 .1. .1.
1 1 /24
/1
1/0 /24
GE .1.1.1
10
GE
10 1/0/
.1. 2
2.1
4
FW_A /2
/2
4
10 GE1
1
16 1
2.
2. /0/
.1.
2.2 /0/2
8.
19 E1
/24
G
FW_C
The roadmap is as follows:
1. Configure static routes to different destinations between FW_A and FW_B as well as
between FW_A and FW_C. Configure the priorities for the routes, distinguishing the
active and standby links.
2. To better switch traffic on the active link, manually configure the BFD function between
FW_A and FW_B.
Procedure
NOTE
This example describes only major BFD-related configurations, with IP address and security zone
configurations omitted.
# Configure a static route, and set the priority of the static route between FW_A and FW_C to
100. In this case, FW_A->FW_B is the active link, and FW_A->FW_C is the standby link.
<FW_A> system-view
[FW_A] ip route-static 192.168.2.0 255.255.255.0 10.1.2.2 preference 100
# Configure the BFD session for FW_B.

[FW_A] bfd
[FW_A-bfd] quit
[FW_A] bfd ab bind peer-ip 10.1.1.2
[FW_A-bfd-session-ab] discriminator local 10
[FW_A-bfd-session-ab] discriminator remote 20
[FW_A-bfd-session-ab] commit
[FW_A-bfd-session-ab] quit
# Configure interworking between the static route and BFD.

[FW_A] ip route-static 192.168.1.0 255.255.255.0 10.1.1.2 track bfd-session ab
Step 2 Configure FW_B.

# Configure the BFD session for FW_A.
<FW_B> system-view
[FW_B] bfd
[FW_B-bfd] quit
[FW_B] bfd ab bind peer-ip 10.1.1.1
[FW_B-bfd-session-ab] discriminator local 20
[FW_B-bfd-session-ab] discriminator remote 10
[FW_B-bfd-session-ab] commit
[FW_B-bfd-session-ab] quit
----End
1. After the configurations are complete, view the information in the routing table.
# Run the display ip routing-table command on FW_A. In the routing table, there are
two static routes to different destinations.
<FW_A> display ip routing-table
fib
------------------------------------------------------------------------------
Routing Tables:
Public
Destinations : 8 Routes :
8

Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
10.1.2.0/24 Direct 0 0 D 10.1.2.1
10.1.2.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.0/8 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
192.168.1.0/24 Static 60 0 RD 10.1.1.2
192.168.2.0/24 Static 100 0 RD 10.1.2.2
If the Pre field has a smaller value, the route to destination IP address 192.168.1.0/24
has a higher priority, and serves as the active link. When the link is normal, traffic is
forwarded from this link.
2. View the BFD session status on FW_A or FW_B.
# Run the display bfd session all command. You can view that the status of the BFD
session is Up. The following uses the information that is displayed on FW_A as an
example.
<FW_A> display bfd session all
------------------------------------------------------------------------------
--
Local Remote Peer IP Address Interface Name State

Type
------------------------------------------------------------------------------
--
10 20 10.1.1.2 -- Up
Static
------------------------------------------------------------------------------
--
3. Stimulate that the active link is faulty.

# Run the shutdown command on interface GigabitEthernet 1/0/1 of FW_A.
fib
------------------------------------------------------------------------------
Routing Tables:
Public
Destinations : 5 Routes :
5

Interface
10.1.2.0/24 Direct 0 0 D 10.1.2.1

10.1.2.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.0/8 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1
InLoopBack0
192.168.2.0/24 Static 100 0 RD 10.1.2.2
When you check the routing table on FW_A, you can view that the static route to
192.168.1.0/24 is deleted and the standby link is used in this case.
After the undo shutdown command is configured, the active link is recovered, and the
static route to 192.168.1.0/24 is added to the routing table again.
l Configuration scripts of FW_A
#
sysname FW_A
#
bfd
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
bfd ab bind peer-ip
10.1.1.2
discriminator local
10
discriminator remote
20
commit
#
ip route-static 192.168.1.0 255.255.255.0 10.1.1.2 track bfd-session ab
ip route-static 192.168.2.0 255.255.255.0 10.1.2.2 preference 100
#
return

l Configuration scripts of FW_B

#
sysname FW_B
#
bfd
#
ip address 10.1.1.2 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
bfd ba bind peer-ip
10.1.1.1
discriminator local
20
discriminator remote
10
commit
#
return
l Configuration scripts of FW_C

#
sysname FW_C
#
ip address 10.1.2.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
return
2.4.6.3 CLI: Example for Configuring BFD-OSPF Interworking

In OSPF networking with multiple devices, BFD delivers rapid fault detection.
As shown in Figure 2-105, FW_A carries main services of an enterprise and OSPF runs
between FW_B and FW_C. The link from FW_A to FW_B is an active link, whereas the link
from FW_A, FW_C, to FW_B is a standby link. It is required that traffic can be immediately
switched to the standby link when the active link is faulty, and it can be also switched back
after the active link is recovered.

Figure 2-105 Networking diagram of configuring BFD-OSPF interworking
FW_A FW_B
Loopback 0 BFD Session Loopback 0
172.16.1.1/32 172.16.1.2/32
GE1/0/3 GE1/0/1 GE1/0/1
192.168.1.1/24 10.1.1.1/24 10.1.1.2/24
.1 /2
G 0.1
.2 /0
E1 .3
4
1
.1 E1
/2
/0 .1/2
10
G
G .3.2
4
/2 4
.2 1
E1 /2
/2
.1 /0/
.1
.2
/0 4
10 E1
10
/2
G
Loopback 0
172.16.1.3/32
FW_C
Area 0
1. OSPF runs among FW_A, FW_B, and FW_C. The OSPF neighbor status is Full.
2. To monitor the active link, enable BFD for the OSPF process on each device.
3. To better switch traffic on the active link, enable BFD between FW_A and FW_B.
Procedure
NOTE
# Configure basic OSPF functions.

<FW_A> system-view
[FW_A] ospf 100
# Enable BFD for OSPF process 100.

[FW_A] bfd
[FW_A-bfd] quit

[FW_A] ospf 100

[FW_A-ospf-100] bfd all-interfaces enable
# Enable BFD for interface GigabitEthernet 1/0/1. Set the minimum sending and receiving
interval to 500 ms, and the local detection multiple to 4.
[FW_A-GigabitEthernet1/0/1] ospf bfd enable
[FW_A-GigabitEthernet1/0/1] ospf bfd min-tx-interval 500 min-rx-interval 500
detect-multiplier 4

<FW_B> system-view
[FW_B] ospf 100

[FW_B] bfd
[FW_B-bfd] quit
[FW_B] ospf 100
[FW_B-ospf-100] bfd all-interfaces enable
# Enable BFD for interface GigabitEthernet 1/0/1. Set the minimum sending and receiving
interval to 500 ms, and the local detection multiple to 4.
[FW_B-GigabitEthernet1/0/1] ospf bfd enable
[FW_B-GigabitEthernet1/0/1] ospf bfd min-tx-interval 500 min-rx-interval 500
detect-multiplier 4
Step 3 Configure FW_C.

<FW_C> system-view
[FW_C] ospf 100
[FW_C-ospf-100] area 0
[FW_C-ospf-100-area-0.0.0.0] network 172.16.1.3 0.0.0.0
[FW_C-ospf-100-area-0.0.0.0] quit
[FW_C-ospf-100] quit

[FW_C] bfd
[FW_C-bfd] quit
[FW_C] ospf 100
[FW_C-ospf-100] bfd all-interfaces enable
[FW_C-ospf-100] quit
----End

1. After configurations are complete, view the next-hop address of the external route in the
OSPF process on FW_B, to determine whether to use the active link.
# Run the display ospf routing command. You can view the next hop of 192.168.1.1 is
10.1.1.1. In this case, the active link is used.
<FW_B> display ospf routing
OSPF Process 100 with Router ID

172.16.1.2
Routing
Tables
Routing for
Network
Destination Cost Type NextHop AdvRouter
Area
10.1.3.0/24 2 Transit 10.1.1.1 172.16.1.3
0.0.0.0
10.1.3.0/24 2 Transit 10.1.2.2 172.16.1.3
0.0.0.0
10.1.2.0/24 1 Transit 10.1.2.1 172.16.1.3
0.0.0.0
172.16.1.3/32 2 Stub 10.1.2.2 172.16.1.3
0.0.0.0
172.16.1.2/32 1 Stub 172.16.1.2 172.16.1.2
0.0.0.0
10.1.1.0/24 1 Transit 10.1.1.2 172.16.1.2
0.0.0.0
172.16.1.1/32 2 Stub 10.1.1.1 172.16.1.1
0.0.0.0
192.168.1.0/24 2 Stub 10.1.1.1 172.16.1.1 0.0.0.0
Total Nets:
8
Intra Area: 8 Inter Area: 0 ASE: 0 NSSA:
0
2. View the OSPF neighbor status on one device. The following uses the information
displayed on FW_A as an example.
# Run the display ospf peer command to view the OSPF neighbor status. You can view
that OSPF neighbor status is Full. Therefore, the BFD session is automatically
established after BFD for the OSPF process is enabled.
<FW_A> display ospf peer

172.16.1.1
Neighbors
Area 0.0.0.0 interface 10.1.1.1(GigabitEthernet1/0/1)'s

neighbors
Router ID: 172.16.1.2 Address: 10.1.1.2 GR State:
Normal
State: Full Mode:Nbr is Master Priority:
1
DR: 10.1.1.1 BDR: 10.1.1.2 MTU:
0
Dead timer due in 28
sec
Neighbor is up for

00:20:00
Authentication Sequence:
[ 0 ]
Neighbors
Area 0.0.0.0 interface 10.1.3.1(GigabitEthernet1/0/2)'s

neighbors
Router ID: 172.16.1.3 Address: 10.1.3.2 GR State:
Normal
State: Full Mode:Nbr is Master Priority:
1
DR: 10.1.3.2 BDR: 10.1.3.1 MTU:
0
Dead timer due in 38
sec
Neighbor is up for
00:11:43
Authentication Sequence:
[ 0 ]
# Run the display ospf bfd session all command. You can view that the status of the
BFD session is Up.
<FW_B> display ospf bfd session all

172.16.1.2
NeighborId:172.16.1.1 AreaId:0.0.0.0
Interface:GigabitEthernet1/0/1
BFDState:up rx :1000 tx :
1000
Multiplier:3 BFD Local Dis:8192 LocalIpAdd:
10.1.1.2
RemoteIpAdd:10.1.1.1 Diagnostic
Info:Init
1000
10.1.2.1
Info:Init
3. BFD-related parameters are modified after interface-based BFD is enabled on FW_A

and FW_B.
# Run the display ospf bfd session all command to display BFD-related parameters.
<FW_A> display ospf bfd session all

172.16.1.1
500
10.1.1.1

Info:Init
1000
10.1.3.1
RemoteIpAdd:10.1.3.2 Diagnostic Info:Init
4. Stimulate that the active link is faulty.

# Run the shutdown command on interface GigabitEthernet 1/0/1 of FW_A. On FW_B,
you can view that the next hop of 192.168.1.1 in the OSPF routing table is route
10.1.2.2. In this case, the standby link is used.
<FW_B> display ospf routing

172.16.1.2
Routing
Tables
Routing for
Network
Destination Cost Type NextHop AdvRouter
Area
10.1.3.0/24 2 Transit 10.1.2.2 172.16.1.3
0.0.0.0
10.1.2.0/24 1 Transit 10.1.2.1 172.16.1.3
0.0.0.0
172.16.1.3/32 2 Stub 10.1.2.2 172.16.1.3
0.0.0.0
172.16.1.2/32 1 Stub 172.16.1.2 172.16.1.2
0.0.0.0
172.16.1.1/32 3 Stub 10.1.2.2 172.16.1.1
0.0.0.0
192.168.1.0/24 3 Stub 10.1.2.2 172.16.1.1 0.0.0.0
Total Nets:
6
Intra Area: 6 Inter Area: 0 ASE: 0 NSSA:
0
# Run the undo shutdown command on GigabitEthernet 1/0/1 of FW_A. The traffic is
switched to the active link. 1 shows the routing table.
l Configuration scripts of FW_A
#
sysname FW_A
#
bfd
#
ip address 10.1.1.1 255.255.255.0
ospf bfd
enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier
4
#
ip address 10.1.3.1 255.255.255.0

#
ip address 192.168.1.1 255.255.255.0
#
interface Loopback 0
ip address 172.16.1.1 255.255.255.255
#
ospf
100
bfd all-interfaces
enable
area
0.0.0.0
network 172.16.1.1
0.0.0.0
network 10.1.1.0
0.0.0.255
network 10.1.3.0
0.0.0.255
network 192.168.1.0 0.0.0.255
#
return
l Configuration scripts of FW_B

# sysname FW_B
#
bfd
#
ip address 10.1.1.2 255.255.255.0
ospf bfd
enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier
4
#
ip address 10.1.2.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.255
#
ospf
100
bfd all-interfaces
enable
area
0.0.0.0
network 172.16.1.2
0.0.0.0
network 10.1.1.0
0.0.0.255
network 10.1.2.0
0.0.0.255
#
return
l Configuration scripts of FW_C

#
sysname FW_C
#
bfd
#
ip address 10.1.2.2 255.255.255.0
#
ip address 10.1.3.2 255.255.255.0

#
ip address 172.16.1.3 255.255.255.255
#
ospf
100
bfd all-interfaces
enable
area
0.0.0.0
network 172.16.1.3
0.0.0.0
network 10.1.2.0
0.0.0.255
network 10.1.3.0
0.0.0.255
#
return
2.4.6.4 CLI: Example for Configuring BFD-PBR Interworking

By binding the specified PBR to the BFD session, you can adjust the PBR dynamically
according to the network status.
As shown in Figure 2-106, an enterprise has departments A and B. Departments A and B,
acting as service departments, generate heavy traffic and require different links for traffic
balancing. In addition, the departments require high stability and service continuity.
To meet their requirements, the enterprise has two links (ISP1 and ISP2) to access the
Internet. The two links share the traffic and can back up for each other to ensure service
continuity.
The requirements are as follows:
l Department A resides on network segment 10.1.0.0/16 and its packets pass through link
ISP1 in normal cases.
l Department B resides on network segment 10.2.0.0/16 and its packets pass through link
ISP2 in normal cases.
l The links of departments A and B are mutually backed up. When the link (active link) of
a department is faulty, traffic is switched to the link (standby link) of another department.
Figure 2-106 Networking diagram of configuring interworking between PBR and BFD
PC
BFD session 1
ISP1 Router_A
Department A GE1/0/1 1.1.2.1/24
GE1/0/3
10.1.0.1/16 1.1.2.2/24
PC
PC PC FW
Department B GE1/0/2 GE1/0/4

10.2.0.1/16 1.1.3.2/24 Router_B
ISP2
1.1.3.1/24
PC BFD session 2
PC

NOTE
This example describes only PBR-related configurations, but not configurations (such as NAT and route
reachability among Router_A, Router_B, and FW) required by the FW for providing Internet access.

1. To balance traffic on different links, configure the PBR based on source IP addresses, so
that packets from department A pass through ISP1 and those from department B pass
through ISP2.
2. To ensure the continuity and mutual backup of links at which departments A and B
reside, perform the following:
a. Configure static BFD sessions respectively on the FW, Router_A, and Router_B to
detect the link connectivity between the FW and Router_A, and between the FW
and Router_B.
b. Configure interworking between PBR and BFD. BFD monitors the availability of
the active links of departments A and B. When the active links are faulty, PBR
becomes invalid. The device searches for standby routes to ensure service
continuity.
c. Configure static routes from department A to link ISP2 and from department B to
link ISP1 as the backup routes of departments A and B. Moreover, configure static
routes to interwork with BFD. BFD monitors the availability of the standby links of
departments A and B.
Procedure
NOTE
1. Configure static BFD sessions.
remote discriminator 20.
[FW] bfd
[FW-bfd] quit
[FW] bfd 1 bind peer-ip 1.1.2.1
[FW-bfd-session-1] discriminator local 10
[FW-bfd-session-1] discriminator remote 20
[FW-bfd-session-1] commit
[FW-bfd-session-1] quit
[FW] bfd 2 bind peer-ip 1.1.3.1
2. Configure PBRs and associate them with BFD sessions.

# Configure rule A_1, so that packets sent from 10.1.0.0/16 to 10.2.0.0/16 are not pbr.

[FW] policy-based-route
[FW-policy-pbr-rule-A_1] destination-address 10.2.0.0 16
[FW-policy-pbr-rule-A_1] action no-pbr
# Configure rule A_2, so that packets sent from 10.1.0.0/16 are sent to next-hop 1.1.2.1.
[FW-policy-pbr-rule-A_2] action pbr next-hop 1.1.2.1
Configure rule A_2 to interwork with BFD session 1

[FW-policy-pbr-rule-A_2] track bfd-session 10
# Configure rule B_1, so that packets sent from 10.2.0.0/16 to 10.1.0.0/16 are not pbr.
[FW-policy-pbr-rule-B_1] destination-address 10.1.0.0 16
[FW-policy-pbr-rule-B_1] action no-pbr
# Configure rule B_2, so that packets sent from 10.2.0.0/16 are sent to next-hop 1.1.3.1.
[FW-policy-pbr-rule-B_2] action pbr next-hop 1.1.3.1
Configure rule B_2 to interwork with BFD session 2

[FW-policy-pbr-rule-B_2] track bfd-session 30
[FW-policy-pbr] quit
3. Configure default routes and associate them with BFD sessions.

# Configure a default route, set the next hop to 1.1.2.1/24, and associate the route with
BFD session 1.
[FW] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1 track bfd-session 1
# Configure a default route, set the next hop to 1.1.3.1/24, and associate the route with
BFD session 2.
[FW] ip route-static 0.0.0.0 0.0.0.0 1.1.3.1 track bfd-session 2
Step 2 Create BFD session 1 on Router_A.

discriminator 10.
<Router_A> system-view
[Router_A] bfd
[Router_A-bfd] quit
[Router_A] bfd 1 bind peer-ip 1.1.2.2
[Router_A-bfd-session-1] discriminator local 20
[Router_A-bfd-session-1] discriminator remote 10
[Router_A-bfd-session-1] commit
[Router_A-bfd-session-1] quit
Step 3 Create BFD session 2 on Router_B.

discriminator 30.
<Router_B> system-view
[Router_B] bfd
[Router_B-bfd] quit
[Router_B] bfd 2 bind peer-ip 1.1.3.2
[Router_B-bfd-session-1] discriminator local 40
[Router_B-bfd-session-1] discriminator remote 30
[Router_B-bfd-session-1] commit
[Router_B-bfd-session-1] quit
----End
1. When active links are reachable, packets from department A are forwarded by the FW to
ISP1, and those from department B are forwarded by the FW to ISP2.
# Run the display bfd session all command. You can view that BFD sessions are created
and they are in Up state.
[FW] display bfd session all
------------------------------------------------------------------------------
--
Type
------------------------------------------------------------------------------
--
10 20 1.1.2.1 -- Up
Static
30 40 1.1.3.1 -- Up
Static
------------------------------------------------------------------------------
--
# Run the ping 1.1.2.1 command in department A. The ping succeeds. Then run the ping
1.1.3.1 command. The ping fails.


Request timed out.

Request timed out.
Request timed out.
Request timed out.

# Run the ping 1.1.3.1 command in department B. The ping succeeds. Then run the ping



Request timed out.

Request timed out.
Request timed out.
Request timed out.

2. When the active link is faulty, the FW searches for the standby route and forwards the
packets of departments to the corresponding standby link. The following uses active link
ISP1 of department A as an example.
# Run the display bfd session all command. The status of BFD session 1 of the link
where department A resides is Down.
------------------------------------------------------------------------------
--
Type
------------------------------------------------------------------------------
--
10 20 1.1.2.1 -- Down
Static
30 40 1.1.3.1 -- Up
Static
------------------------------------------------------------------------------
--
# Run the ping 1.1.2.1 command in department A. The ping fails. Then run the ping
1.1.3.1 command. The ping succeeds.


Request timed out.

Request timed out.
Request timed out.
Request timed out.


3. When active links restore to normal, the FW forwards all packets to the active links. The
following uses active link ISP1 of department A as an example.
# Run the display bfd session all command. The status of the BFD session of the link
where department A resides is Up.
------------------------------------------------------------------------------
--
Type
------------------------------------------------------------------------------
--
10 20 1.1.2.1 -- Up
Static
30 40 1.1.3.1 -- Up
Static
------------------------------------------------------------------------------
--
# Run the ping 1.1.2.1 command in department A. The ping succeeds. Then run the ping


Request timed out.

Request timed out.
Request timed out.
Request timed out.

4. Departments A and B can communicate with each other. In the following example, the
user in department A pings that in department B.



l Configuration scripts of FW
#
sysname FW
#
bfd
#
ip address 10.1.0.1 255.255.0.0
#
ip address 10.2.0.1 255.255.0.0
#
ip address 1.1.2.2 255.255.255.0
#
ip address 1.1.3.2 255.255.255.0
#
commit
#
commit
#
ip route-static 0.0.0.0 0.0.0.0 1.1.2.1 track bfd-session 1
ip route-static 0.0.0.0 0.0.0.0 1.1.3.1 track bfd-session 2
#
policy-based-
route
rule name
A_1
ingress-interface
16
16
action no-
pbr
rule name
A_2
ingress-interface
16
track bfd-session
10
action pbr next-hop
1.1.2.1
rule name
B_1
ingress-interface
16
16
action no-
pbr
rule name
B_2
ingress-interface

16
track bfd-session
30
#
return
l Configuration scripts of Router_A

#
sysname Router_A
#
bfd
#
commit
#
return
l Configuration scripts of Router_B

#
sysname Router_B
#
bfd
#
commit
#
return
2.4.6.5 CLI: Example for Configuring BFD-DHCP Interworking

By binding the link where DHCP runs to BFD, you can resolve the problem that the
automatically delivered static route cannot be bound to the BFD session.
As shown in Figure 2-107, the router is the gateway of a building. All enterprises in the
building access the Internet through the router. FW acts as the gateway of an enterprise in the
building. To ensure network continuity, the enterprise uses the dual-uplink networking. The
active link accesses the Internet through DHCP, that is, FW as the DHCP client accesses the
Internet by obtaining the IP address from the DHCP server. The standby link accesses the
Internet through PPPoE.
Because the DHCP client cannot sense link reachability, FW cannot switch the traffic to the
standby link in the event of link faults. To interwork with BFD, check the availability of the
link where the DHCP client resides. Upon link faults, service traffic is rapidly switched to the
standby link.

Figure 2-107 Networking diagram of configuring DHCP-BFD interworking

BFD session
PC
DHCP client DHCP server Router
GE1/0/1
10.1.1.2/24 8.8.8.2/24
Intranet 10.1.1.1/24 8.8.8.1/24
FW
PPPoE
Procedure
Step 1 Configure static BFD sessions.
NOTE
discriminator 20.
[FW] bfd
[FW-bfd] quit
[FW] bfd 1 bind peer-ip 8.8.8.1 interface GigabitEthernet 1/0/1 nexthop dhcp
Step 2 Configure the DHCP-BFD interworking.
# Associate DHCP with the BFD session.

[FW] dhcp enable
[FW-GigabitEthernet1/0/1] dhcp client track bfd-session 10
Step 3 Configure the default route.
# Configure the default route with outbound interface Dialer 0 and route priority 255.
NOTE
When the FW acts as the DHCP client, the priority of the default route obtained from the DHCP server
is 245. When PPPoE is used for backup access, the priority of the default route must be larger than 245.
The higher the priority value, the lower the priority.
[FW] ip route-static 0.0.0.0 0.0.0.0 Dialer 0 preference 255
Step 4 Configure the router.

1. Configure static BFD sessions.

<Router> system-view
[Router] bfd
[Router-bfd] quit
[Router] bfd 1 bind peer-ip 10.1.1.2
[Router-bfd-session-1] discriminator local 20
[Router-bfd-session-1] discriminator remote 10
[Router-bfd-session-1] commit
[Router-bfd-session-1] quit
2. Configure a static route with destination IP address 10.1.1.0/24 and next hop 8.8.8.2 to
FW.
[Router] ip route-static 10.1.1.0 255.255.255.0 8.8.8.2
----End
1. When the active link is reachable, access packets are forwarded by FW to the active link.
# Run the display bfd session all command. You can view that BFD sessions are created
and they are in Up state. The following uses the information displayed on FW as an
example.
------------------------------------------------------------------------------
--
Type
------------------------------------------------------------------------------
--
10 20 8.8.8.1 GigabitEthernet1/0/1 Up
Static
------------------------------------------------------------------------------
--
# Run the display ip routing-table command on FW. You can view that the default
route to FW is the gateway address obtained through the DHCP server and the route
priority is 245.
------------------------------------------------------------------------------

0.0.0.0/0 Static 245 0 RD 10.1.1.1

2. When the active link is faulty, FW switches the traffic to the standby link.
# Run the display bfd session all command. You can view that the status of the BFD
session is Down. The following uses the information displayed on FW as an example.
------------------------------------------------------------------------------
--
Type
------------------------------------------------------------------------------
--
10 20 8.8.8.1 GigabitEthernet1/0/1 Down
Static
------------------------------------------------------------------------------
--

# Run the display ip routing-table command. You can view that default route obtained
through the DHCP server is deleted and the backup default route with outbound interface
Dialer 0 is loaded to the routing table.
fib
------------------------------------------------------------------------------
Routing Tables:
Public

Interface
0.0.0.0/0 Static 255 0 D 0.0.0.0

Dialer0
3. When the active link recovers, run the display bfd session all command on FW. You can
view that the status of the BFD session turns to Up. Run the display ip routing-table
command. You can view that the default route to FW obtained through the DHCP server
is re-loaded to the routing table.
l Configuration scripts of FW
#
sysname FW
#
bfd
#
dhcp client track bfd-session 10
#
bfd 1 bind peer-ip 8.8.8.1 interface GigabitEthernet1/0/1 nexthop dhcp
commit
#
ip route-static 0.0.0.0 0.0.0.0 Dialer 0 preference 255
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1 preference 245 track bfd-session 1
#
return
l Configuration scripts of the router

#
sysname Router
#
bfd
#
ip address 8.8.8.1 255.255.255.0
#
commit
#
ip route-static 10.1.1.0 255.255.255.0 8.8.8.2
#
return


This section describes the reference information about BFD.
This section describes BFD specifications.
BFD Asynchronous mode In asynchronous mode, two

detection systems periodically exchange
BFD control packets at the
negotiated interval. If one system
does not receive any BFD control
packet from the other within a
certain period, it considers the
BFD session Down.
Dynamically changing -
BFD session parameters
Interworking with Supports interworking with static

routing protocols routing, OSPF, BGP, IS-IS, and
PBR.
Interworking of static Hot standby switchovers are

BFD and HRP (hot triggered based on BFD detection
standby) results.
Types of links in BFD Ethernet interfaces and Eth-Trunk

detection interfaces and their subinterfaces
BFD Range of identifiers 8192 to 8192x2-1

automatically assigned by
dynamic BFD sessions
Identifier range of static 1 to 8191

BFD sessions
Period for sending and The default period ranges

receiving packets when a from 100 ms to 1000 ms.
dynamic BFD session is
established

Packet detection range when The default detection range

a dynamic BFD session is is 3 to 50 times of the
established detection interval.
Minimum detection interval The minimum BFD

detection cycle within the
specifications is 10 ms, with
triple detection intervals.
Maximum number of 8000

detected sessions
Actual session detection 3 to 50

range (how many times of
the detection interval)
Link MTU of the BFD 52 bytes

interface

This section describes the versions and changes in the BFD feature.
Version Description

This section describes the standards and protocols used in BFD.
The standards and protocols are as follows:
l RFC 5880: Bidirectional Forwarding Detection (BFD)
l RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
l RFC 5882: Generic Application of Bidirectional Forwarding Detection (BFD)
l RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths

Administrator Guide 3 Virtual System
3 Virtual System
About This Chapter
This chapter describes the concepts and configurations of virtual system.
3.1 Overview
A virtual system is a logical device created on a physical device. Virtual systems are
independent from each other.
3.2 Application Scenario
This section describes the application scenarios of virtual systems.
3.3 Mechanism
This section describes the mechanism of the virtual system.
3.4 Restrictions and Precautions
This section describes the restrictions and precautions that apply to the use of virtual systems.
3.5 Deploying a Virtual System Using the Web UI
This section describes how to deploy a virtual system using the web UI as a public system
administrator.
3.6 Deploying a Virtual System Using the CLI
This section describes how to deploy a virtual system using the CLI as a public system
administrator.
3.7 Configuring Virtual System Services
This section describes how to configure services for a virtual system.
3.8 Configuration Examples
This section provides examples for configuring virtual systems in multiple application
scenarios.
3.9 Feature Reference
This section provides virtual system references.
3.10 Virtual System FAQ
This section describes frequently asked questions (FAQs) about virtual system.

3.1 Overview
A virtual system is a logical device created on a physical device. Virtual systems are
independent from each other.
A FW can be logically divided into multiple virtual systems. Each virtual system has its
resources and configurations, such as interface, address set, user/user group, and routing table
and policies, and provides the same functions as a physical system.
Virtual systems have the following features:
l Each virtual system has its own administrators and can be managed independently. With
virtual systems, a large network can be divided into smaller subnets with each being
served by a virtual system, simplifying the network management.
l Each virtual system has its own configurations and routing table so that networks
connected to different virtual systems can have overlapping private addresses.
l Each virtual system has its own resource quota so that a busy virtual system has no
impact on other virtual systems.
l The traffic of different virtual systems is separated to ensure security. However, different
virtual systems can still communicate with each other if needed.
l Virtual system technology reduces hardware investment, power consumption, and
equipment footprint.
3.2 Application Scenario

This section describes the application scenarios of virtual systems.
Virtual systems apply to the following scenarios:
Device Leasing
Some small enterprises cannot afford dedicated network security devices, the related license,
and after-sales services, but require network protection for service expansion. In such cases,
the network service provider or dedicated device leasing vendor can purchase a network
security device, divide this device to multiple logically independent virtual devices using the
virtual system technology, and provide security functions for different enterprises. Then
multiple enterprises share the hardware resource, but the actual traffic is isolated, which saves
the cost for purchasing and maintaining the devices and secures enterprise networks. For
network service providers and device leasing vendors, this service yields profits.
The small enterprises who lease the FW are equipped with basic firewall functions. In this
way, intranet and Internet resources are available.
As shown in Figure 3-1, enterprise A and enterprise B lease one FW. Enterprise A and
enterprise B use Virtual system A and Virtual system B respectively. Both enterprises can
access Internet.

Figure 3-1 Network isolation for device leasing
FW
Enterprise A
Virtual system A
Enterprise B
Virtual system B
Service data flow
Network Isolation for Large and Medium-sized Enterprises

Networks of large and medium-sized enterprises are usually geographically dispersed, with a
large number of devices and complex configurations. Departments of enterprises have
different security requirements. Meeting such security requirements on large and medium-
sized networks involve complex firewall configurations, which are prone to errors. In
contrast, the firewall virtualization technology allows you to divide a network into multiple
smaller subnets and configure a virtual system for each subnet, making network boundaries
clearer and network management easier.
As shown in Figure 3-2, virtual systems are created on the FW for the R&D, financial, and
administrative departments of an enterprise. The administrators of each department have
clearly defined permissions, and the departments can communicate based on the policies. The
departments can also have different Internet access permissions.
Figure 3-2 Network isolation for large and medium-sized enterprises

Intranet
FW
R&D
department
Virtual system for

the R&D department
Financial
department
Virtual system for the

financial department
Administrative
department
Virtual system for the

Service data flow
administrative department

Security Gateway for Cloud Computing Centers

Cloud computing provides computing and storage capabilities over the Internet. To ensure
reliable cloud-based services, traffic of different customers must be isolated, protected, and
served by necessary resources. With virtual system technology, you can deploy a FW at the
egress of a cloud computing center and create a virtual system for each customer to isolate
and protect the traffic of different customers.
As shown in Figure 3-3, enterprises A and B have servers at the cloud computing center. The
FW functions as the security gateway at the egress of the cloud computing center. It isolates
the traffic of different enterprises and protects the cloud computing center based on the
configured security policies.
Figure 3-3 Security gateway for the cloud computing center
Cloud computing center

FW
Enterprise A Enterprise A
Virtual
system A
Enterprise B Enterprise B
Virtual
system B Service data flow
3.3 Mechanism
This section describes the mechanism of the virtual system.
3.3.1 Virtual System and Administrator

This section describes the concepts of public system, virtual system, and administrator.
Virtual System
The FW has two types of virtual systems: public system (public) and virtual system (VSYS).
l Public system (public)
The public system is a special virtual system on the FW and is available even if the
virtual system function is disabled. After the virtual system function is enabled on the
FW, the public system inherits all the configurations of the FW.
The public system manages other virtual systems and forwards data between them.
l Virtual system (VSYS)

Virtual systems are independent logical systems created on a FW.

Figure 3-4 shows the logical structure of the public system and virtual systems.
Figure 3-4 Logical structure of the public system and virtual systems
Virtual system N
Virtual system A
Virtual system B
……
Public system
To forward, isolate, and independently manage traffic of different virtual systems, the FW
implements virtualization in the following aspects:
l Resources: Each virtual system has dedicated resources, including interfaces, VLANs,
policies, and sessions. The resources are assigned by public system administrators and
managed by virtual system administrators.
l Configuration: Each virtual system has its own configuration interface and
administrators and cannot be accessed by administrators of other virtual systems.
l Security function virtualization: Each virtual system has independent security policies
and other security functions which apply only to packets of the virtual system.
l Route virtualization: Each virtual system maintains separate routing tables, independent
and isolated from each other. Currently, only static routes are supported.
With the preceding virtualization techniques, each virtual system can function as a dedicated
firewall that is exclusively managed by its administrator.
Virtual System and VPN Instance

Besides virtual systems, the FW also supports VPN instances. Virtual systems can isolate
services and static routes, whereas VPN instances isolate only routes. For the functions that
cannot be virtualized, such as dynamic routing, multicast, IPSec VPN, and L2TP VPN, you
can use VPN multi-instance to implement virtualization.
The FW provides two types of VPN instances:
l VPN instances automatically generated when virtual systems are created
When you create a virtual system on the FW, the FW automatically generates a VPN
instance with the same name.
l VPN instances manually created
You can run the ip vpn-instance command to create VPN instances. Such instances are
mainly used to isolate routes in MPLS scenarios. Usually, the VPN instances used for
route isolation refer to those manually created ones.
The FW provides both types of VPN instances. You can use either type of VPN instances
based on the scenario.

Administrator
Administrators are classified into public system administrators and virtual system
administrators. Figure 3-5 illustrates the permissions of the two types of administrators.
Figure 3-5 Permissions of public system and virtual system administrators
…… Create virtual system

system services.
Configure virtual
Administrator of Administrator of Administrator of administrators. Public

virtual system A virtual system B virtual system N administrator
Create virtual systems

and allocate virtual
system N
system A
system B
Virtual
Virtual
Virtual
system resources.
……
Public system
Configure public system services/Configure

the communication between virtual systems.
l Public system administrator

After the virtual system function is enabled, the administrators of the FW will become
administrators of the public system. Public system administrators can manage the FW
and the public system, using the same login and authentication methods and with the
same permissions.
A public system administrator can configure virtual systems, such as creating or deleting
virtual systems, and allocating resources to virtual systems, only when virtual system
management permission is assigned to the public system administrator. Public system
administrators thereafter all have virtual system management permission unless
otherwise specified.
l Virtual system administrator
Each virtual system has one or multiple administrators. A virtual system administrator
can manage only the virtual system on which the administrator is created.
To relate administrators with virtual systems, virtual system administrator accounts are
named in the format of administrator name@@virtual system name.
3.3.2 Virtual System Resource Allocation

This section describes the virtual system resource allocation mechanism. Limiting the amount
of resources of each virtual system prevents a virtual system from preempting too much
resources from other virtual systems.
Basic resources, such as security zones, policies, and sessions, can be either automatically or
manually assigned to virtual systems, whereas other resources are preempted by all virtual
systems.

Resource Allocation
Table 3-1 lists the resources that are automatically and manually assigned.
Table 3-1 Automatically and manually assigned resources
Resource Name Allocation Description

Method
Security Zones Automatically -

assigned
Sessions Manually assigned -
New Session Rate Manually assigned The new session rate indicates the number of
new sessions a virtual system can create in one
second.
Users Manually assigned -
Policies Manually assigned Specifies the maximum total number of all

policies, including security, NAT, bandwidth,
and routing policies.
Bandwidth Manually assigned Specifies the maximum bandwidth for the

upstream, downstream, or both directions of a
virtual system.
Manually assigned resources have a guaranteed value and maximum value.
l Guaranteed value: specifies the amount of a resource committed to a virtual system and
cannot be preempted by other virtual systems.
l Maximum value: specifies the maximum allowed amount of resource that a virtual
system can have. Whether the virtual system can achieve the maximum value depends on
available resources and competition between virtual systems.
For example, 10 virtual systems are configured on the FW and the total number of sessions
available for the FW is 500,000. If virtual system A is configured with a guaranteed number
of 10,000 sessions and a maximum number of 50,000 sessions, then virtual system A can
establish 10,000 sessions without preemption. However, whether virtual system A can
establish 50,000 sessions depends on the competition of other nine virtual systems and the
public system. If the total number of sessions established by the other nine virtual systems and
the public system is less than 450,000, then virtual system A can establish a maximum
number of 50,000 sessions.
Public system administrators can assign resources to virtual systems based on their purpose.
For example, virtual system 1 connects to the zone where the enterprise servers reside to
protect the servers and virtual system 2 connects to the zone created for a department of 20
employees to control Internet access. In this case, the two virtual systems have different needs
for resources. Virtual system 1 needs more sessions than virtual system 2, but does not need
any users, whereas virtual system 2 needs a quota of 20 users but needs fewer sessions than
virtual system 1.

Resource Preemption
The following resources are preempted by all virtual systems:
l Address and address group
l Region and region group
l User-defined service and service group
l User-defined application and application group
l NAT address pool
l Schedule
l Traffic profile
l Static route
l Various types of tables, including the server-map, IP-MAC binding, ARP, and MAC
address table
3.3.3 Virtual System Traffic Sorting

This section describes how the FW forwards traffic of different virtual systems.
If no virtual systems are configured on the FW, the FW forwards packets based on policies
and various tables (such as session, MAC address, and routing table) of the public system.
After virtual systems are configured on the FW, each virtual system functions as a dedicated
device and has its own policies and tables for packet processing. In this case, after receiving a
packet, the FW must first determine the destination virtual system of the packet. This process
is called traffic sorting.
The FW sorts traffic based on interface (for Layer-3 interface) or VLAN (for Layer-2
interfaces).
Interface-based Traffic Sorting

After an interface (a GE interface or GE subinterface) is bound to a virtual system, all packets
received at this interface belong to the bound virtual system, and the FW processes the
packets based on the configuration of the virtual system.
In Figure 3-6, the three virtual systems, VSYSA, VSYSB, and VSYSC, have their dedicated
inside interfaces, which are respectively GigabitEthernet 1/0/1, GigabitEthernet 1/0/2, and
GigabitEthernet 1/0/3. After receiving packets, the FW forwards them to their virtual systems
for routing and policy matching.

Figure 3-6 Interface-based traffic sorting
GE1/0/4
VSYSA VSYSB VSYSC
Traffic sorting
GE1/0/1(VSYSA) GE1/0/3(VSYSC)
GE1/0/2(VSYSB)
10.3.0.0/24 10.3.2.0/24
10.3.1.0/24
VLAN-based Traffic Sorting

If a VLAN is bound to a virtual system, the FW forwards packets from this VLAN to the
bound virtual system.
In Figure 3-7, the inside interface GigabitEthernet 1/0/1 of the FW is a Layer-2 trunk
interface and is configured to permit packets from VLAN10, VLAN20, and VLAN30, which
are bound to VSYSA, VSYSB, and VSYSC respectively. After receiving a packet on
GigabitEthernet 1/0/1, the FW checks the VLAN tag carried in the packet header to determine
the source VLAN of the packet and then forwards the packet to the virtual system to which
the VLAN is bound.
After the packet enters the virtual system, the FW checks the MAC address table to obtain the
outgoing interface and then forwards or discards the packet based on the inter-zone policy.

Figure 3-7 VLAN-based traffic sorting
GE1/0/2
Trunk VLAN10,20,30
VSYSA VSYSB VSYSC
VLAN10 VLAN20 VLAN30
Traffic sorting
GE1/0/1
Trunk VLAN10,20,30
VLAN Tag: 10 VLAN Tag: 20 VLAN Tag: 30
VLAN 10 VLAN 30
VLAN 20
3.3.4 Communication Between Virtual Systems

Virtual systems can communicate using virtual interfaces.
Virtual Interface
Virtual interfaces are logical interfaces used for inter-virtual system communication. After a
virtual system is created, the system automatically creates a virtual interface for the virtual
system. Virtual interfaces are named in the format of Virtual-if+number, with the virtual
interface of the public system numbered 0 (Virtual-if0). Other virtual interfaces are
automatically numbered from 1.
As shown in Figure 3-8, the virtual interfaces (Virtual-if1 to Virtual-ifN) of all virtual
systems are connected to the virtual interface (Virtual-if0) of the public system through a
virtual link. You can add virtual interfaces to secure zones and configure routes and security
policies to enable and control the communication between the public system and virtual
systems.
You can compare the public system to a router that forwards traffic for virtual systems.

Figure 3-8 Virtual interface
Virtual system A Virtual-if1
Virtual-if2
Virtual system B Virtual-if0
Virtual system N Virtual-ifN

Public system
Virtual interface
The communication between virtual systems and between a virtual system and the public
system is described as follows.
Traffic Diversion Table

The traffic diversion table specifies the mappings between destination addresses and virtual
systems. The FW determines whether the public system will create sessions based on the
traffic diversion table. If a packet matches the traffic diversion table, the public system will
not create any session. Otherwise, the public system will create a session. Using the traffic
diversion table simplifies the processing and saves session resources.
The traffic diversion table applies only to communication between the public system and
virtual systems.
Communication Between the Public System and Virtual Systems

Configure communication between the public system and virtual systems in the following
scenarios:
l Hosts served by virtual systems need to communicate with hosts served by the public
system.
l The number of public IP addresses is insufficient and all virtual systems need to access
the Internet through the public system. In this case, the traffic of the virtual systems must
be forwarded by the public system.
As shown in Figure 3-9, you can configure routes and security policies to allow private
network 10.3.0.0/24 connected to virtual system A (VSYSA) to access the server at 3.3.3.3 on
the Internet through interface GE1/0/1 of the public system.

Figure 3-9 Communication between a virtual system and the public system
2 Forwards packets VSYSA routing table Public routing table
based on the Destination Destination Outgoing Destination Destination Outgoing
firewall processing Next hop Next hop
Address VSYS interface Address VSYS interface
flow and find the
destination VSYS in 3.3.3.3/32 public - - 3.3.3.3/32 public GE1/0/1 1.1.1.254
the routing table 10.3.0.0/24 VSYSA GE1/0/2 - 10.3.0.0/24 VSYSA - -
based on the
destination address. …… …… …… …… …… …… …… ……
4 Forwards packets based on the
firewall processing flow and find
1
Se the outgoing interface and next
req nds hop in the routing table based on
ue an a
st. cc the destination address.
e ss 3 Sends
2 Forwards 4 Forwards 5 Access the Internet.
packets.
packets. packets.
GE1/0/2 Virtual-if1 Virtual-if0 GE1/0/1

10.3.0.0/24
Virtual ISP
Public
system A Gateway
system
(VSYSA) 1.1.1.254
3.3.3.3
Configure routes as follows to enable communication between VSYSA and the public system:
1. Configure a static route on VSYSA. Set the destination IP address to 3.3.3.3 and
destination virtual system to public.
2. Configure a static route on the public system. Set the destination IP address to 3.3.3.3,
the outgoing interface to GE1/0/1, and the next hop to the gateway IP address obtained
from the carrier. The static routes in steps 1 and 2 are used to forward traffic from hosts
connected to VSYSA to the Internet.
3. Configure a static route on the public system. Set the destination IP address to
10.3.0.0/24 and destination virtual system to VSYSA.
4. Configure a static route on VSYSA. Set the destination IP address to 10.3.0.0/24 and the
outgoing interface to GE1/0/2. The static routes in steps 3 and 4 are used to forward
traffic from the Internet to hosts connected to VSYSA.
Configure security policies as follows to enable communication between VSYSA and the
public system:
1. On VSYSA, add interface GE1/0/2 to the Trust zone and Virtual-if1 to the Untrust zone,
and configure a security policy to allow the Trust zone to access the Untrust zone.
2. On the public system, add interface GE1/0/1 to the Untrust zone and Virtual-if0 to the
Trust zone, and configure a security policy to allow the Trust zone to access the Untrust
zone.
Network 10.3.0.0/24 is a private network. Therefore, a NAT policy must be configured for the
network to access the Internet. The NAT policy can be configured on VSYSA or the public
system, whichever the public IP addresses are configured.
Communication Between Two Virtual Systems

Two virtual systems can communicate with each other through the public system. As shown
in Figure 3-10, users connected to VSYSA need to access the server connected to VSYSB
through the public system.

Figure 3-10 Communication between two virtual systems

VSYSA routing table Public routing table
2 Forwards packets Destination Destination Outgoing Destination Destination Outgoing
based on the firewall Next hop Next hop
Address VSYS interface Address VSYS interface
processing flow and
10.3.1.3/32 public - - 10.3.1.3/32 VSYSB - -
find the destination
VSYS in the routing 10.3.0.0/24 VSYSA GE1/0/2 - 10.3.0.0/24 VSYSA - -
table based on the
destination address. …… …… …… …… …… …… …… ……
1 Sends an access
Virtual
request.
system A
2 Forwards
(VSYSA)
packets. 3 Finds the outgoing
GE1/0/2 interface in the
10.3.0.0/24 Virtual-if1
routing table of the
public system.
Virtual-if0
4 Sends packets.
10.3.1.0/24 GE1/0/3 Virtual-if2
Public
5 Forwards Virtual system
packets. system B
Server 6 Access the (VSYSB)
10.3.1.3 server.
VSYSB routing table 5 Forwards packets based on

Destination Destination Outgoing the firewall processing flow
Next hop
Address VSYS interface and find the outgoing interface
10.3.1.3/32 VSYSB GE1/0/3 - in the routing table based on
the destination address.
10.3.0.0/24 public - -
…… …… …… ……
Configure routes as follows to enable communication between VSYSA and VSYSB:
1. Configure a static route on VSYSA. Set the destination IP address to 10.3.1.3 and
2. Configure a static route on the public system. Set the destination IP address to 10.3.1.3
and destination virtual system to VSYSB.
3. Configure a static route on VSYSB. Set the destination IP address to 10.3.1.3 and the
outgoing interface to GE1/0/3. The static routes in steps 1, 2, and 3 are used to forward
traffic from hosts connected to VSYSA to the server connected to VSYSB.
4. Configure a static route on VSYSB. Set the destination IP address to 10.3.0.0/24 and
5. Configure a static route on the public system. Set the destination IP address to
10.3.0.0/24 and destination virtual system to VSYSA.
6. Configure a static route on VSYSA. Set the destination IP address to 10.3.0.0/24 and the
outgoing interface to GE1/0/2. The static routes in steps 4, 5, and 6 are used to forward
traffic from VSYSB to hosts connected to VSYSA.
Configure security policies as follows to enable communication between VSYSA and

VSYSB:

1. On VSYSA, add interface GE1/0/2 to the Trust zone and Virtual-if1 to the Untrust zone,
and configure a security policy to allow the Trust zone to access the Untrust zone.
2. On VSYSB, add interface GE1/0/3 to the Trust zone and Virtual-if2 to the Untrust zone,
and configure a security policy to allow the Untrust zone to access the Trust zone.
NOTE
The public system only forwards packets between virtual systems based on the routing table and does
not implement any security functions. Therefore, you do not need to configure any security policies on
the public system.
Similarly, if address translation is needed, a NAT policy must be configured on VSYSA,

VSYSB, or the public system.
Communication Between Virtual Systems with Overlapping Private Addresses

As virtual systems are isolated from each other and are independently managed, IP address
overlapping may occur if administrators of different virtual systems assign the same private
addresses to hosts in their networks. Overlapping addresses can cause the following
communication problems:
l For communication between virtual systems and the public system
For example, a host connected to VSYSA and a host connected to VSYSB have the same
private IP address 10.3.0.2, and the two hosts need to communicate with a server (IP
address: 192.168.1.1) connected to the public system.
Packets originating from both virtual systems can be correctly forwarded to the server.
However, return packets originating from the server and destined for the IP address
10.3.0.2 cannot be correctly forwarded by the public system, because both VSYSA and
VSYSB have a host whose IP address is 10.3.0.2.
To resolve this problem, configure NAT policies on the two virtual systems to translate
the source IP addresses of their packets into non-conflicting IP addresses before the
packets are forwarded to the public system. Then, configure routes on the public system
for the translated IP addresses so that the public system can correctly forward packets to
hosts connected to VSYSA and VSYSB that have the same private IP address.
l For communication between two virtual systems
For example, a network connected to VSYSA and a network connected to VSYSB use
the same private IP address segment 10.3.0.0/24 and need to communicate with each
other. Without NAT, hosts connected to VSYSA cannot communicate with hosts
connected to VSYSB because the packets they send carry the same source and
destination IP address or address segment.
To resolve this problem, configure NAT policies on the public system to translate the
source or destination IP addresses of packets for VSYSA and VSYSB.
For example, to allow a host connected to VSYSA need to access a server (IP address:
10.3.0.3) connected to VSYSB, configure a NAT policy on VSYSA to translate the
source IP addresses of packets to 192.168.1.1, and configure IP address mapping on
VSYSB to map the private IP address (10.3.0.3) of the server on VSYSB to 192.168.2.1.
The detailed route and NAT configurations are as follows:
a. On VSYSA, configure a NAT policy for source IP address translation.

Source IP Address Before Source IP Address After

Translation Translation
10.3.0.0/24 192.168.1.1
b. On VSYSA, configure a static route to the public system.
Source Virtual Destination IP Destination Outgoing

System Address Virtual System Interface
- 192.168.2.1 public -
c. On the public system, configure a static route to VSYSB.
Source Virtual Destination IP Destination Outgoing

System Address Virtual System Interface
- 192.168.2.1 VSYSB -
d. On VSYSB, configure IP address mapping for the server.
Type Public IP Address Private IP Address
Static mapping 192.168.2.1 10.3.0.3
e. On VSYSB, configure a static route to 10.3.0.3.

Refer to the preceding steps to configure static routes for the return traffic from VSYSB
to VSYSA.
3.4 Restrictions and Precautions

This section describes the restrictions and precautions that apply to the use of virtual systems.
Restrictions
The FW provides a specific quantity of virtual systems by default. If the administrators need
more, they must purchase a license. For details, see 3.9.2 Specifications.
Most functions of the FW are available in virtual systems. For detailed function availability,
see 3.9.1 Function Availability for Virtual Systems. Table 3-2 describes the usage
restrictions for some functions available on virtual systems.
Table 3-2 Usage restrictions for virtual system functions
Function Restrictions
Administrator Virtual system administrators cannot log in to the device using

the console port.

Function Restrictions
Signature database and The signature database and system software can only be
system software update updated on the public system.
Configuration file Virtual system administrators can configure a virtual system

management using the Web UI or CLI of the virtual system. However, they
can only use the Web UI to import or export the virtual system
configuration file.
SSH Virtual system administrators can use STelnet to log in to a

virtual system. However, the passwords used for the login can
only be generated on the public system. The SSH
configurations of the public system apply to all virtual systems.
Port management The ports for services, including HTTP, HTTPS, and SSH, can
only be set on the public system.
Certificate Certification-related operations can only be performed on the

public system. The operations include certificate application,
import, deletion, and filtering, and certificate revocation list
(CRL) uploading. The certification configurations of the public
system apply to all virtual systems.
Precautions
A Layer-3 GE, VLAN, or VLANIF interface cannot be assigned in any of the following
situations:
l The GE interface or VLAN has been assigned to a virtual system.

l The GE or VLANIF interface is used as the source interface which sends the signature
databases upgrade request packets.
l The GE or VLANIF interface is referenced by a policy.
l The GE interface is an Eth-trunk member interface or switched to a Layer-2 interface.
The management interface GigabitEthernet 0/0/0 cannot be assigned to virtual system.
The following configurations of an interface are automatically cleared when the interface is
assigned to a virtual system:
l IP address
l IPSec
Exercise caution when assigning an interface to a virtual system to prevent service

interruption.
Note the following rules when you assign public IP addresses:
l In exclusive mode, a public IP address can be assigned only to one virtual system. In free
mode, an public IP address can be assigned to multiple virtual systems.
l The public IP address differs from the global IP address for NAT Server in the public
system.

l The public IP address differs from the IP addresses in the NAT address pool in the public
system.
Trunk and hybrid Layer-2 interfaces and Layer-3 interfaces on which subinterfaces are created
may be simultaneously used by multiple virtual systems. Therefore, the Traffic History
displayed on the Dashboard of each virtual system is the total traffic of all virtual systems
that use the interfaces.
Virtual systems can forward only session logs and packet discard logs (excluding policy
matching logs) to the log server of the public system.
3.5 Deploying a Virtual System Using the Web UI

This section describes how to deploy a virtual system using the web UI as a public system
administrator.
3.5.1 Enabling the Virtual System Function

This section describes how to enable the virtual system function. You can configure resource
classes and create virtual systems only after the virtual system function is enabled.
Procedure
Step 1 Access the Dashboard page. Click Configure next to Virtual System in the System
Information group area.
Step 2 Select Enable.
Step 3 Click Apply.
----End
Changes to the Web UI

After the virtual system function is enabled, the Web UI changes as follows:
l The Virtual System drop-list box is displayed at the upper right corner of the page. If
multiple virtual systems, such as vsysa and vsysb, are created on the FW, you can select
the name of a virtual system to access the configuration page of the virtual system. In the
drop-list box, public indicates the public system, vsysa and vsysb are the virtual systems
that the administrator has created.
l The Virtual System node is displayed in the navigation tree on the System page.
3.5.2 Configuring a Resource Class

This section describes how to configure a resource class. You are advised to configure
resource classes before creating any virtual system.
Context
All virtual systems created on a FW share the resources available on the FW. To ensure the
availability of system resources for all virtual systems and prevent a virtual system from
overusing system resources, restrict the amount of system resources available for each virtual
system.

To do so, add a resource class, configure the system resources for the resource class, and bind
the resource class to a virtual system.
NOTE
A resource class can be bound to multiple virtual system. If multiple virtual systems require the same type
and amount of system resources, bind the same resource class to each of these virtual systems.
NOTE
Resource class r0 is bound to the public system by default and cannot be deleted or renamed.
Procedure
Step 1 Check resource usage.
Before allocating resources for virtual systems, check the available resources using a public
system administrator account.
1. Choose System > Virtual System > Resource Class.

2. Click Remained Resource to view information about available resources.
Name -
Remained Number Ensure that the amount of system resources to be allocated

does not exceed the amount of available system resources.
Step 2 Click Add to create and configure a resource class.
Name Name of the resource class.
Description Description of the resource class.

The description must clearly indicate the function of the
resource class so that virtual systems can be easily searched
for.
Resource Name Name of the resources to be allocated.
Reserved Number Minimum amount of a specified resource item available for a

virtual system. Once the amount of system resources are
assigned to a virtual system, they are exclusively used by the
virtual system.
Maximum Maximum allowed amount of a specified resource item

available for a virtual system. The actual amount of a specified
resource item a virtual system can obtain depends on the
competition of other virtual systems.
Step 3 Click OK.
----End

3.5.3 Creating a Virtual System and Allocating Resources

This section describes how to create a virtual system and allocate resources to it.
Context
A resource class must be specified for a virtual system to allocate resources, such as policy
and concurrent sessions quota.
In addition, public IP addresses, interfaces and VLANs must be allocated as required after a
virtual system has been added.
Procedure
Step 1 Choose System > Virtual System > Virtual System.
Step 2 Click Add. Then click the Basic Configuration tab and configure necessary parameters.
Name Name of the virtual system.
Description Description of the virtual system.

The description must clearly indicate the function of the virtual
system so that virtual systems can be easily searched for.
Resource Class Resource class to be bound. Values are as follows:

l If no resource class is selected, or if NONE is selected, the
virtual system preempts resources, such as concurrent
sessions and policy quota, from the public system. If the
public system does not have any resource available, the
virtual system will have no resource to use.
l Select New Resource Class to create a new resource class
and bind it to the virtual system.
l Select a resource class and bind it to the virtual system.
Step 3 Allocate interfaces or VLANs for the added virtual system.

l Click the Assignment and Public Setting tab. Then allocate the interfaces for the virtual
system as required.
The interface must be an available Layer-3 Ethernet interface or subinterface. When you
configure bandwidth management, you need to set an interface as the public interface in
the public system to collect traffic statistics of virtual systems.
l Click the Assign VLAN tab. Then allocate the VLANs for the virtual system as required.
The Layer-2 interface or VLANIF interfaces of the VLAN are also assigned to the
virtual system.
l Click the Public IP Address Setting tab. Then allocate the public IP addresses for the
virtual system as required.
The public IP address allocated to the virtual system is applied to the NAT, NAT Server,
and interface.
Exclusive the following IP Address Ranges: The public IP address assigned to a virtual
system cannot be assigned to other virtual systems.

Share the following IP Address Ranges: The public IP address assigned to a virtual
system can still be assigned in share mode only to other virtual systems.
After a public IP address is assigned in exclusive or share mode to a virtual system, the
public system cannot use the address any more.
Step 4 Click OK.
----End
Follow-up Procedure
After configurations are complete, perform the following operations:
l Check the created virtual system and system resources allocated to it in Virtual System
List.
l Select a virtual system in Virtual System List and click Resource Usage to view the
usage of the resources allocated to the virtual system.
l Select a virtual system and click to access the virtual system configuration page.
To delete a virtual system, select the virtual system in the Virtual System List, and click
Delete. Then, click OK in the dialog box that is displayed. All configurations of the deleted
virtual system are cleared, and all resources allocated to the virtual system are reclaimed.
3.5.4 Enabling Communication Between Virtual Systems

This section describes how to configure communication between virtual systems.
3.5.4.1 Enabling Communication Between a Virtual System and the Public

System
This section describes how to configure routes and security policies for the communication
between a virtual system and the public system.
Context
To enable the communication between the virtual system and public system, you need to
correctly configure the routes and security policies on the virtual system and public system,
just as on two physical devices.
Before the actual configuration, you are advised to read Communication between a virtual
system and the public system and learn about the mechanism for the communication
As shown in Figure 3-11, routes and security policies must be configured to enable the users
of vsysa to access the Internet server at IP address 3.3.3.3 through public interface GE1/0/1 of
the public system.

Trust Untrust
FW
GE1/0/3 GE1/0/1
10.3.0.1/24 1.1.1.1/24
10.3.0.0/24
vsysa public
ISP Gateway
1.1.1.254 3.3.3.3
Virtual interface
Procedure
Step 1 Configure routes and security policies on vsysa.
1. Select vsysa in the Virtual System drop-down list at the upper right corner of the page
to access virtual system vsysa.
3. Click Add and configure a static route to the Internet as follows:
Source Virtual Router vsysa
Destination Address/ 3.3.3.3/255.255.255.255

Mask
Destination Virtual public

Router
Next Hop -
Interface -
4. Click OK.
6. Click next to the Virtual-if1 interface to set an IP address, add the interface to the
Untrust zone. The IP address can be any value as long as it does not conflict with the IP
address on any other interface.
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore, in
actual configurations, the interface might not be Virtual-if1. You can view the mapping between the
virtual system and virtual interface in Interface List.
8. Click Add and configure a security policy as follows:
Name to_internet
Source Zone trust
Source Address/ 10.3.0.0/24

Region

Destination Address/ 3.3.3.3/32

Region
Action Permit
9. Click OK.
Step 2 Configure routes and security policies on the public system.

1. Select public in the Virtual System drop-down list at the upper right corner of the page
to access the public system.
3. Click Add and configure a default route to the Internet as follows:
Protocol IPv4
Source Virtual Router public

Mask

Router
Next Hop 1.1.1.254
Interface -
4. Click OK.
5. Repeat the preceding step and configure a static route to the users of vsysa.
Protocol IPv4

Mask
Destination Virtual vsysa

Router
Next Hop -
Interface -
Trust zone. The IP address can be any value as long as it does not conflict with the IP

Name vsys_to_internet
Source Zone trust
Source Address/ any

Region
Destination Address/ any

Region
Action Permit
10. Click OK.
----End
3.5.4.2 Enabling Communication Between Virtual Systems

between two virtual systems.
Context
As shown in Figure 3-12, users of virtual system vsysa must use the public system to access
the server connected to virtual system vsysb. The public system acts as a router that connects
both virtual systems and forwards packets from one virtual system to the other.
Before the configuration, you are advised to read Communication Between Two Virtual
Systems and learn about the mechanism for the communication between two virtual systems.
Figure 3-12 Communication between virtual systems
Trust FW
GE1/0/3
10.3.0.1/24
10.3.0.0/24 vsysa
Virtual interface
Trust
GE1/0/4 public
10.3.1.0/24 10.3.1.1/24
vsysb
10.3.1.3
Procedure
Step 1 Configure the routes for the communication between vsysa and vsysb on the public system.

NOTE
The public system only forwards packets between virtual systems based on the routing table and does not
implement any security functions. Therefore, you do not need to configure any security policies in the public
system.
1. Select public in the Virtual System drop-down list at the upper right corner of the page
to access the public system.
3. Click Add and configure a static route to vsysb as follows:
Protocol IPv4

Mask
Destination Virtual vsysb

Router
Next Hop -
Interface -
4. Click OK.
5. Repeat the preceding step and configure a static route to the users of vsysa.
Protocol IPv4

Mask
Destination Virtual vsysa

Router
Next Hop -
Interface -
Trust zone. The IP address can be any value as long as it does not conflict with the IP

to access vsysa.
3. Click Add and configure a static route to the server on vsysb as follows:
Source Virtual Router vsysa


Mask

Router
Next Hop -
Interface -
4. Click OK.
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore, in
actual configurations, the interface might not be Virtual-if1. You can view the mapping between the
virtual system and virtual interface in Interface List.
Name to_server
Source Zone trust

Region

Region
Action Permit
9. Click OK.
Step 3 Configure routes and security policies on vsysb.

1. Select vsysb in the Virtual System drop-down list at the upper right corner of the page
to access vsysb.
3. Click Add and configure a static route to the users of vsysa:
Source Virtual Router vsysb

Mask

Router

Next Hop -
Interface -
4. Click OK.
Name vsysa_to_server
Source Zone untrust

Region

Region
Action Permit
9. Click OK.
----End
3.5.5 Creating a Virtual System Administrator

This section describes how to configure a virtual system administrator, the login method for
the configured administrator, and the interface for the administrator to log in to the virtual
system.
Context
Once a virtual system is created, the public system administrator can configure one or more
administrators for the virtual system. You can log in to and manage the virtual system using
the accounts of these administrators. The public system administrator can create system
administrators for a virtual system only on the configuration page of the virtual system. The
method for creating a virtual system administrator is the same as that for creating a public
system administrator.

Data Planning
Item Data
Administrator User name: admin@@vsysa

Authentication type: Local authentication
Password: Vsysadmin@123
Role: System administrator
Trusted hosts: 10.3.0.99/32 and 10.3.0.100/32
Login interface Interface: GE1/0/3

Security zone: Trust
IP address: 10.3.0.1/24
Virtual system: vsysa
NOTE
If an interface has been assigned to a virtual system, you can use this
interface to log in to the virtual system and public system (the name of
the administrator must be suffixed with @@public). If the interface is
not assigned to any virtual system and belongs to the public system,
you can log in to the public system and virtual systems from this
interface.
Login method HTTPS
NOTE
The following assumes that vsysa has already been created and interface GE1/0/3 has already been allocated
for the virtual system as the login interface.
Procedure
Step 1 Create a virtual system administrator.
to access vsysa.
2. Choose System > Administrator > Administrator.
3. Click Add and set the parameters.
User Name admin@@vsysa
Authentication Type Local Authentication
Password Vsysadmin@123
Confirm Password Vsysadmin@123
Role system-admin
Trusted Host #1 10.3.0.99/32
Trusted Host #2 10.3.0.100/32

NOTE
The name of a virtual system administrator must be suffixed with @@Virtual system name.
If a third-party authentication server is used to authenticate the virtual system administrator, the user
name configured on the authentication server does not need to carry the suffix "@@virtual system
name". For example, if the authentication server needs to authenticate administrator admin@@vsysa of
virtual system vsysa, configure user name admin on the authentication server.
NOTE
Trusted hosts are the IP addresses of the hosts that are allowed to log in to the virtual system. If the IP
address of the administrator PC is fixed, add the IP address as a trusted host so that the administrator
can log in to the virtual system using the PC. If the IP address of the administrator PC is dynamically
allocated, do not configure any trusted hosts. Otherwise, the administrator may fail to log in to the
virtual system if the IP address of the administrator PC changes.
4. Click OK.
Step 2 Configure the login interface.
2. Click next to GE1/0/3 and configure necessary parameters.
IP Address 10.3.0.1/255.255.255.0
Management Access HTTPS, Ping
NOTE
Select HTTPS in Access management so that the virtual system administrator can log in to the Web UI
over HTTPS. Another option is HTTP. However, you are advised to select HTTPS for security
reasons.
Select Ping so that the interface can be pinged to test the connectivity between the administrator PC and
the login interface.
3. Click OK.
----End
Follow-up Procedure
After the configuration is complete, you can log in to the virtual system as the virtual system
administrator as follows:
1. Open a browser and enter https://10.3.0.1:Port number. Port number indicates the port
number specified when you enable the HTTPS service.
NOTE
If the browser displays a certificate error page, ignore it and continue to the website.
2. On the login page, enter the user name (admin@@vsysa) and password
(Vsysadmin@123) of the virtual system administrator and click Login to log in to the
virtual system.
3.6 Deploying a Virtual System Using the CLI

This section describes how to deploy a virtual system using the CLI as a public system
administrator.

3.6.1 Enabling the Virtual System Function

This section describes how to enable the virtual system function. You can configure resource
classes and create virtual systems only after the virtual system function is enabled.
Procedure
Step 1 Access the system view and run the following command to enable the virtual system function.
vsys enable
----End
Changes to the CLI

After the virtual system function is enabled, the CLI has changed in following aspects:
l All commands related to the virtual system function are available.

l The virtual system view is enabled so that the public system administrator can run
switch vsys to access and configure a virtual system.
<FW> system-view
[FW] switch vsys vsysa //vsysa is a created virtual system
<FW-vsysa>
3.6.2 Configuring a Resource Class

This section describes how to configure a resource class. You are advised to configure
resource classes before creating any virtual system.
Context
All virtual systems created on a FW share the resources available on the FW. To ensure the
availability of system resources for all virtual systems and prevent a virtual system from
overusing system resources, restrict the amount of system resources available for each virtual
system.
To do so, add a resource class, configure the system resources available for the resource class,
and bind the resource class to the virtual system.
NOTE
A resource class can be bound to multiple virtual system. If multiple virtual systems require the same type
and amount of system resources, configure a single resource class and bound the resource class to each of
these virtual systems.
Procedure
Step 1 Run the following command to check resource usage.
display resource global-resource [ resource-item { bandwidth | policy | session | session-

rate | user } ]
Check the available resources as the public system administrator before allocating resources
for virtual systems.

The following is a sample command output of the display resource global-resource

command:
<FW> display resource global-resource
Global resource table:
------------------------------------------------------------
Global-Number Remained-Number
session 4000000 4000000
session-rate 80000 80000
bandwidth 3500 3500
policy 15000 14980
user 6000 5996
------------------------------------------------------------
The fields in the preceding command output are described as follows:

l Global-Number: Total number of resources
l Remained-Number: Number of available resources.
Ensure that the guaranteed amount of a specified resource allocated to a virtual system must
not exceed the amount of available resources.
Step 2 In the system view, run the following command to create a resource class and access the
resource class view.
resource-class resource-class-name
Step 3 Configure the guaranteed and maximum amount of resources available for a virtual system.
NOTE
l Guaranteed value: Minimum amount of a specified resource item available for a virtual system. Once the
amount of system resources are allocated to a virtual system, they are exclusively used by the virtual
system.
l Maximum value: Maximum allowed amount of a specified resource item available for a virtual system.
Whether the resources used by a virtual system can reach the maximum amount is determined by the
resources used by other virtual systems.
Configure the guaranteed and resource-item-limit session reserved-number

maximum number of sessions session-reserved-number [ maximum { maximum-
available for a virtual system. number | equal-to-reserved | unlimited } ]
Configure the maximum number resource-item-limit session-rate session-rate-

of new sessions available for a maximum-number
virtual system.
Configure the guaranteed quota of resource-item-limit policy reserved-number policy-

policies. reserved-number
NOTE
Available policies are security policies, NAT policies,
bandwidth policies, and routing policies.
Configure the maximum upstream resource-item-limit bandwidth bandwidth { entire |

bandwidth. inbound | outbound }
----End
3.6.3 Creating a Virtual System and Allocating Resources

This section describes how to create a virtual system and allocate resources to it.

Context
A resource class must be specified for a virtual system to allocate resources, such as policy
and concurrent sessions quota.
In addition, public IP addresses, interfaces and VLANs must be allocated as required after a
virtual system has been added.
Procedure
Step 1 Optional: Set the public interface in the interface view.
NOTE
In cross-virtual system forwarding, the Virtual-if interface is a public interface by default.
set public-interface
When you configure bandwidth management, you need to set an interface as the public
interface in the public system to collect traffic statistics of virtual systems and then assign the
interface to virtual systems.
After the configuration is complete, the traffic entering virtual systems from this interface is
inbound traffic, and the traffic exiting virtual systems from this interface is outbound traffic. If
a virtual system has multiple public interfaces, the traffic entering the virtual system and the
traffic exiting the virtual system from these public interfaces is the entire traffic.
Step 2 Run the following command in the system view to create a virtual system and access the
management view of the virtual system.
vsys name vsys-name
Step 3 Optional: Run the following command to configure the description of a virtual system.
description description
The description must clearly indicate the function of the virtual system so that virtual systems
can be easily searched for.
Step 4 Bind a resource class to the virtual system.
assign resource-class resource-class-name
Step 5 Allocate public IP address, interfaces or VLANs for the added virtual system.
l Run the following command to allocate public IP addresses for the added virtual system.
assign global-ip start-address end-address { exclusive | free }
The public IP address allocated to the virtual system is applied to the NAT, NAT Server,
and interface.
After a public IP address is assigned in exclusive or free mode to a virtual system, the
public system cannot use the address any more.
l Run the following command to allocate interfaces for the added virtual system.
assign interface interface-type interface-number
The interface must be an available Layer-3 interface or subinterface.
The management interface GigabitEthernet 0/0/0 cannot be assigned to virtual system.
l Run the following command to allocate the VLAN to the added virtual system.
assign vlan vlan-id

The Layer-2 interface or VLANIF interfaces of the VLAN are also available for the
virtual system.
Step 6 Save the current configuration in the user view.
save [ configuration-file ]
You are advised to save the current configuration after the virtual system is created.
----End
Follow-up Procedure
After configurations are complete, perform the following:
l Run the display vsys [ verbose ] [ vsys-name ] command to view the configuration of
the created virtual system.
l Run the display resource resource-usage vsys vsys-name command to view the
resources used by the virtual system.
l Run the switch vsys vsys-name command in the system view to access the virtual system
view and configure services on the virtual system.
l Run the undo vsys name vsys-name command in the system view to delete a virtual
system. All configurations of the deleted virtual system are cleared, and all resources
allocated to the virtual system are reclaimed.
3.6.4 Enabling Communication Between Virtual Systems

This section describes how to configure communication between virtual systems.
3.6.4.1 Enabling Communication Between a Virtual System and the Public

System
Context
To enable the communication between the virtual system and public system, you need to
correctly configure the routes and security policies on the virtual system and public system,
just as on two physical devices.
Before the actual configuration, you are advised to read Communication between a virtual
system and the public system and learn about the mechanism for the communication
As shown in Figure 3-13, routes and security policies must be configured to enable the users
of vsysa to access the Internet server at IP address 3.3.3.3 through public interface GE1/0/1 of
the public system.

Trust Untrust
FW
GE1/0/3 GE1/0/1
10.3.0.1/24 1.1.1.1/24
10.3.0.0/24
vsysa public
ISP Gateway
1.1.1.254 3.3.3.3
Virtual interface
Procedure
# Access the vsysa view.
<FW> system-view
[FW] switch vsys vsysa
# Configure a static route to the server on the Internet.
NOTE
Users connected to vsysa access the Internet through the public interface of the public system. Therefore, the
destination VPN of the static route must be the VPN instance named public of the public system.
<FW-vsysa> system-view
[FW-vsysa] ip route-static 3.3.3.3 32 public
# Set an IP address for the virtual interface Virtual-if1 on the virtual system vsysa and add
the interface to the Untrust zone. The IP address can be any value as long as it does not
conflict with the IP address on any other interface.
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore, the
actual interface may not be Virtual-if1. To view the virtual interface of the virtual system, run display
interface brief.
[FW-vsysa] interface Virtual-if 1
[FW-vsysa-Virtual-if1] ip address 172.16.1.1 24
[FW-vsysa-Virtual-if1] quit
[FW-vsysa] firewall zone untrust
[FW-vsysa-zone-untrust] add interface Virtual-if1
[FW-vsysa-zone-untrust] quit
# Configure the policies for users of vsysa to access the server on the Internet.
[FW-vsysa] security-policy
[FW-vsysa-policy-security] rule name to_internet
[FW-vsysa-policy-security-rule-to_internet] source-zone trust
[FW-vsysa-policy-security-rule-to_internet] destination-zone untrust
[FW-vsysa-policy-security-rule-to_internet] source-address 10.3.0.0 24
[FW-vsysa-policy-security-rule-to_internet] destination-address 3.3.3.3 32
[FW-vsysa-policy-security-rule-to_internet] action permit
[FW-vsysa-policy-security-rule-to_internet] quit
[FW-vsysa-policy-security] quit
Step 2 Configure routes and security policies on the public system.

# Return to the system view of the public system.
[FW-vsysa] quit
<FW-vsysa> quit

# Configure a default route to the Internet and set the next hop of the default route to
1.1.1.254.
[FW] ip route-static 3.3.3.3 32 1.1.1.254
# Configure a static route to users of vsysa.
NOTE
After a virtual system is created, the FW creates a VPN instance of the same name for the virtual system.
When configuring the static route to a specified virtual system, set the destination VPN of the static route to
the VPN instance corresponding to the virtual system.
[FW] ip route-static 10.3.0.0 24 vpn-instance vsysa
# Set an IP address for the virtual interface Virtual-if0 on the public system and add the
interface to the Trust zone. The IP address can be any value as long as it does not conflict with
the IP address on any other interface.
[FW] interface Virtual-if 0
[FW-Virtual-if0] ip address 172.16.0.1 24
[FW-Virtual-if0] quit
[FW-zone-trust] add interface Virtual-if0
# Configure the policies for users of vsysa to access the server on the Internet.
[FW-policy-security] rule name vsys_to_internet
[FW-policy-security-rule-vsysa_to_internet] source-zone trust
[FW-policy-security-rule-vsysa_to_internet] destination-zone untrust
[FW-policy-security-rule-vsysa_to_internet] source-address any
[FW-policy-security-rule-vsysa_to_internet] destination-address any
[FW-policy-security-rule-vsysa_to_internet] action permit
[FW-policy-security-rule-vsysa_to_internet] quit
----End
3.6.4.2 Enabling Communication Between Virtual Systems

between two virtual systems.
Context
As shown in Figure 3-14, users of virtual system vsysa must use the public system to access
the server connected to virtual system vsysb. The public system acts as a router that connects
both virtual systems and forwards packets from one virtual system to the other.
Before the configuration, you are advised to read Communication Between Two Virtual
Systems and learn about the mechanism for the communication between two virtual systems.

Figure 3-14 Communication between virtual systems
Trust FW
GE1/0/3
10.3.0.1/24
10.3.0.0/24 vsysa
Virtual interface
Trust
GE1/0/4 public
10.3.1.0/24 10.3.1.1/24
vsysb
10.3.1.3
Procedure
Step 1 Configure the routes for the communication between virtual systems vsysa and vsysb on the
public system.
NOTE
The public system only forwards packets between virtual systems based on the routing table and does not
implement any security functions. Therefore, you do not need to configure any security policies in the public
system.
NOTE
After a virtual system is created, the FW creates a VPN instance of the same name for the virtual system.
When configuring the static route to a specified virtual system, set the destination VPN of the static route to
the VPN instance corresponding to the virtual system.
<FW> system-view
# Configure a static route to users of vsysb.

[FW] ip route-static 10.3.1.0 24 vpn-instance vsysb
interface to the Trust zone. The IP address can be any value as long as it does not conflict with
the IP address on any other interface.
[FW-zone-trust] add interface Virtual-if0
# Access the vsysa view.

# Configure a static route to the server connected to vsysb.

NOTE
The traffic destined for vsysb passes the public system. Therefore, configure the destination VPN of the static
route to the VPN instance named public of the public system.
# Configure a static route to users of vsysa with interface GE1/0/3 as the outgoing interface.
[FW-vsysa] ip route-static 10.3.0.0 24 GigabitEthernet 1/0/3
# Set an IP address for the virtual interface Virtual-if1 on the virtual system vsysa and add
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore, the
actual interface may not be Virtual-if1. To view the virtual interface of the virtual system, run display
interface brief.
[FW-vsysa-zone-untrust] add interface Virtual-if1
# Configure the policies for users of vsysa to access the server connected to vsysb.
[FW-vsysa-policy-security] rule name to_server
[FW-vsysa-policy-security-rule-to_internet] source-address 10.3.0.0 24
[FW-vsysa-policy-security-rule-to_internet] destination-address 10.3.1.3 32

# Access the vsysb view.
[FW-vsysa] quit
<FW-vsysa> quit
[FW] switch vsys vsysb
# Configure a static route to the server connected to vsysb with interface GE1/0/4 as the
outgoing interface.
<FW-vsysb> system-view
[FW-vsysb] ip route-static 10.3.1.0 24 GigabitEthernet 1/0/4
NOTE
The traffic destined for vsysa passes the public system. Therefore, configure the destination VPN of the static
route to the VPN instance named public of the public system.
[FW-vsysb] ip route-static 10.3.0.0 24 public
# Set an IP address for the virtual interface Virtual-if2 on the virtual system vsysb and add
[FW-vsysb] interface Virtual-if 2
[FW-vsysb-Virtual-if1] ip address 172.16.2.1 24

[FW-vsysb-Virtual-if1] quit
[FW-vsysb] firewall zone untrust
[FW-vsysb-zone-untrust] add interface Virtual-if2
[FW-vsysb-zone-untrust] quit
# Configure the policies for users of vsysa to access the server connected to vsysb.
[FW-vsysb] security-policy
[FW-vsysb-policy-security] rule name vsysa_to_server
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] source-zone untrust
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] destination-zone trust
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] source-address 10.3.0.0 24
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] destination-address 10.3.1.3 32
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] action permit
[FW-vsysb-policy-security-rule-vsysa_to_vsysb] quit
[FW-vsysb-policy-security] quit
----End
3.6.5 Creating a Virtual System Administrator

This section describes how to configure a virtual system administrator, the login method for
the configured administrator, and the interface for the administrator to log in to the virtual
system.
Context
Once a virtual system is created, the public system administrator can configure one or more
administrators for the virtual system. You can log in to and manage the virtual system using
the accounts of these administrators. The public system administrator can create system
administrators for a virtual system only on the configuration page of the virtual system. The
method for creating a virtual system administrator is the same as that for creating a public
system administrator.
Data Planning
Item Data
Administrator User name: admin@@vsysa

Authentication type: Local authentication
Password: Vsysadmin@123
Role: System administrator
Trusted hosts: 10.3.0.99/32 and 10.3.0.100/32
Login interface Interface: GE1/0/3

IP address: 10.3.0.1/24
Virtual system: vsysa
NOTE
If an interface has been assigned to a virtual system, you can use this
interface to log in to the virtual system and public system (the name of
the administrator must be suffixed with @@public). If the interface is
not assigned to any virtual system and belongs to the public system,
you can log in to the public system and virtual systems from this
interface.

Item Data
Login method Telnet

NOTICE NOTE
Telnet login is not secure. The FW supports the login over Stelnet. For details, see 1.3.5.6
You are advised to log in to Example for Logging in to the CLI Using STelnet (Password
the CLI using STelnet. Authentication) and 1.3.5.7 Example for Logging In to the CLI
Using STelnet (RSA Authentication). Note that the local key in the
two preceding examples can be generated only on the public system.
All virtual systems share the configuration of the public system.
The ssh user command cannot distinguish cases. Therefore, when you
create SSH users for a virtual system, admin@@vsysa and
admin@@VSYSA are the same. However, after you run the ssh user
command to create an SSH account admin@@vsysa, the account can
be used to log in to both vsysa and VSYSA with their respective
passwords.
NOTE
The following assumes that vsysa has already been created and interface GE1/0/3 has already been allocated
for the virtual system as the login interface.
If you have already configured the administrators that log in to the CLI using Telnet, perform only the
operations in Step 4 through Step 6.
Procedure
Step 1 Enable Telnet.
<FW> system-view

# Configure five VTY administrator interfaces that support AAA and Telnet and set the level
of the VTY administrator interfaces to 3.
[FW-ui-vty0-4] quit
NOTE
To ensure that the administrator can log in to the device, you are advised to set the level of the VTY
administrator interfaces to 3 or larger.
Step 3 Configure the automatic lockout function for failed login attempts.
By default, an account is locked for 30 minutes after three consecutive login failures. In the
following example, the account is locked for 10 minutes after five consecutive login failures.
[FW] aaa
Step 4 Access the vsysa view.

Step 5 Create an administrator account.

# Configure a trusted host.

[FW-vsysa] acl 2001
[FW-vsysa-acl-basic-2001] rule permit source 10.3.0.99 0.0.0.0
[FW-vsysa-acl-basic-2001] rule permit source 10.3.0.100 0.0.0.0
[FW-vsysa-acl-basic-2001] quit
# Set the administrator account to admin@@vsysa, VTY administrator interface level to 3,

login method to telnet and the maximum number of connections for the account to 5.
[FW-vsysa] aaa
[FW-vsysa-aaa] manager-user admin@@vsysa
[FW-vsysa-aaa-manager-user-admin@@vsysa] password
Enter Password:
Confirm Password:
[FW-vsysa-aaa-manager-user-admin@@vsysa] level 3
[FW-vsysa-aaa-manager-user-admin@@vsysa] service-type telnet
[FW-vsysa-aaa-manager-user-admin@@vsysa] acl-number 2001
[FW-vsysa-aaa-manager-user-admin@@vsysa] access-limit 5
[FW-vsysa-aaa-manager-user-admin@@vsysa] quit
[FW-vsysa-aaa] quit
NOTE
The name of a virtual system administrator must be suffixed with @@Virtual system name.
If a third-party authentication server is used to authenticate the virtual system administrator, the user name
configured on the authentication server does not need to carry the suffix "@@virtual system name". For
example, if the authentication server needs to authenticate administrator admin@@vsysa of virtual system
vsysa, configure user name admin on the authentication server.
NOTE
To ensure that the administrator can log in to the device properly, you are advised to set the administrator
level to 3 or larger.
The maximum number of the connections for the account must be smaller than the number of online users
configured for the virtual system.
# Associate the administrator with the system administrator role.

[FW-vsysa-aaa] bind manager-user admin@@vsysa role system-admin
[FW-vsysa-aaa] quit
NOTE
Trusted hosts are the IP addresses of the hosts that are allowed to log in to the virtual system. If the IP address
of the administrator PC is fixed, add the IP address as a trusted host so that the administrator can log in to the
virtual system using the PC. If the IP address of the administrator PC is dynamically allocated, do not
configure any trusted hosts. Otherwise, the administrator may fail to log in to the virtual system if the IP
address of the administrator PC changes.
Step 6 Configure the login interface.

# Configure the interface IP address and interface-based access control and enable the
administrator to log in to the device through HTTPS.
[FW-vsysa] interface GigabitEthernet 1/0/3
[FW-vsysa-GigabitEthernet1/0/3] ip address 10.3.0.1 255.255.255.0
[FW-vsysa-GigabitEthernet1/0/3] service-manage enable
[FW-vsysa-GigabitEthernet1/0/3] service-manage telnet permit
[FW-vsysa-GigabitEthernet1/0/3] quit
# Add the interface to a security zone.

[FW-vsysa] firewall zone trust
[FW-vsysa-zone-trust] add interface GigabitEthernet1/0/3
[FW-vsysa-zone-trust] quit
----End

Follow-up Procedure
After the configuration is complete, the virtual system administrator can log in to the virtual
system as follows:
1. The following uses the Windows operating system as an example. Choose Start > Run.
The Run dialog box is displayed. Then enter telnet 10.3.0.1 in Open.
2. Click OK. The PC starts to connect to the FW.
3. Enter admin@@vsysa as the user name and press Enter.
4. Enter Vsysadmin@123 as the password and press Enter to access the CLI of the virtual
system.
3.6.6 Managing Virtual System Logs
Context
The system, session, packet discard, and service logs of the public system can be sent to the
log server of the public system. The session, packet discard, and service logs can also be sent
to the log server of a virtual system.
The system logs of a virtual system can be sent to the log server of the virtual system using
the information center (info-center loghost). The session, packet discard, and service logs of
a virtual system can be sent to the log server of the virtual system using the log host (firewall
log host). For configurations of the information center and log host, see Logs.
The session and packet discard logs can also be sent to the log server of the public system.
This section describes how to configure the function of sending session and packet discard
logs of virtual systems to the log server of the public system.
Procedure
Step 1 In the system view, switch to the user view of a virtual system.
switch vsys vsys-name
Step 2 Access the virtual system view.
system-view
Step 3 Configure the sending of virtual system logs to the log server of the public system.
session-log send-to-public log-type { all | nat | none }
By default, session and packet discard logs are sent to the log server of the public system.
----End
3.6.7 Maintaining a Virtual System

After virtual systems are configured, you can check the configuration results.
Table 3-3 lists the commands for checking virtual system configurations.

Table 3-3 Checking virtual system configurations

Action Command
View virtual system display vsys [ verbose ] [ vsys-name ]

configurations.
View global resource display resource global-resource [ resource-item

information. { bandwidth | policy | session | session-rate | user } ]
View current resource display resource resource-usage [ { all-systems | vsys vsys-

usage. name } [ resource-item { bandwidth | policy | session |
session-rate | user } ] ]
View resource display resource resource-class [ resource-class-name ]

information of a resource
class.
View interface allocation display assign interface { interface-type interface-number |

information. vsys vsys-name | all }
View VLAN allocation display assign vlan { vlan-id | vsys vsys-name | all }
information.
View information about display firewall import-flow public { ip-address | vpn-

the IPv4 traffic diversion instance vpn-instance-name }
table.
View the configured display public-interface

public interface.
3.7 Configuring Virtual System Services

This section describes how to configure services for a virtual system.
Context
As shown in Figure 3-15, each virtual system has independent resources, such as interfaces,
security zones, and users quota, and acts as a separate device. Configuring services for virtual
system is the same as configuring service for the public system. However, certain functions
may be restricted due to the limit of resources for the virtual system and permissions of virtual
system administrators.

Figure 3-15 Configuring virtual system services

FTP Server Web Server
10.2.0.3/24 10.2.0.5/24
10.2.0.0/24
DMZ
Trust Untrust
GE1/0/6
10.3.0.0/24
GE1/0/3 GE1/0/1
VSYSA
The following procedure covers only the key points and precautions in configuring virtual
system services. For details, see corresponding sections in the administrator guide.
Procedure
Step 1 Access the configuration page of the virtual system.
Virtual system services can be configured by the public system or virtual system
administrator. The public system and virtual system administrators access the virtual system
in different ways. For details, see Table 3-4.
l For the public system administrator
– If the Web UI is used
Select a virtual system from the Virtual System drop-down list at the upper right
corner, or
– If the CLI is used
Run the switch vsys vsys-name command in the system view.
l To log in to the virtual system as a virtual system administrator, log in to the Web UI of
the virtual system using a browser or to the CLI using a remote login tool.
Step 2 Configure the service interface.
The key step in the configuration of a service interface is to add the configured interface to a
proper security zone. After interfaces are assigned into proper security zones, the networks
connected to these interfaces are divided. Then, you can configure services specific to security
zones. By default, security zones Trust, Untrust, DMZ, and Local are created on each virtual
system. Plan the security zones on a virtual system by following the same rules that apply to
the public system.
Table 3-4 lists the interface types that may be available on a virtual system and their
configuration descriptions.

Table 3-4 Interface types

Interface Type Configuration Description
Layer-3 Ethernet interface Involves the configuration of security zones, IP

address, packet rate, and duplex mode.
If the interface serves as a login interface for
administrators, enable access management.
Layer-2 Ethernet interface Involves the configuration of security zones.
VLANIF interface Involves the configuration of security zones and IP

addresses.
Ethernet subinterface Involves the configuration of security zones and IP

addresses.
Virtual interface Involves the configuration of security zones and IP

addresses.
NOTE
The public system administrator has already completed the configuration of the interface before assigning
them to virtual systems. Therefore, these interfaces are not configurable on the virtual system.

In common cases, security policies are required for following types of traffic:
l Traffic destined from intranet users to the Internet in the Untrust zone
l Traffic destined from intranet users in the Trust zone to the intranet server in the DMZ
zone
l Traffic destined from Internet users in the Untrust zone to the intranet server in the DMZ
zone
Each security policy can reference different content security profiles to implement content
security functions, such as antivirus and intrusion prevention.
Step 4 Configure the NAT policy.
If the number of public IP addresses is insufficient, you can configure NAT policies to support
Internet access of intranet users. You can also use NAT policies to hide network topology.
For example, you can configure a NAT policy for the virtual system in Table 3-4 as follows:
l Configure a source NAT policy in the Trust->Untrust interzone so that intranet users can
access the Internet by sharing a few public IP addresses.
l Configure the NAT Server in the Untrust->DMZ interzone so that public network users
can access the server on the intranet.
Step 5 Configure other security functions as required.

Table 3-5 Configure other security function for the created virtual system.
Configure policy-based routing Policy-based routing enables the virtual system to
control packet routing and forwarding. In many
scenarios, policy-based routing is used to specify the
outgoing interface or next hop of a traffic flow.
Configure traffic policies. Traffic policies ensure user-specific or application-

specific bandwidth allocation, avoiding network
congestion.
Configure anti-DDoS. Anti-DDoS prevents DDoS attacks, such as the SYN,

UDP, ICMP, HTTP, HTTPS, DNS, and SIP flood
attacks.
Configure IP/MAC binding IP/MAC binding is usually implemented at Layer 2 to

prevent IP spoofing. After IP/MAC binding is
configured, only source IP addresses bound to the
source MAC addresses are valid.
Configure blacklists. After a blacklist is configured, the virtual system

discards all packets that match the blacklist.
Compared with security policies, blacklist is easier
and faster.
----End
3.8 Configuration Examples

This section provides examples for configuring virtual systems in multiple application
scenarios.
3.8.1 CLI Example for Configuring Virtual Systems to Isolate

Enterprise Departments (Layer-3 Access, Virtual Systems Having
Independent WAN Interfaces)
The FW functions as the access gateway of the office area of a large campus network to
protect the intranet. The intranet has multiple service departments, and the administrator
configures virtual systems for each department to implement independent management over
department networks.
As shown in Figure 3-16, a FW is deployed in area of the large campus network as the access
gateway. The network of area A comprises the R&D and non-R&D departments, and the two
departments have different network access permissions. Requirements are as follows:
l Some employees in the R&D department can access the Internet, and all employees in
the non-R&D department can access the Internet.
l The R&D and non-R&D departments are isolated from each other and cannot
communicate.

l The service volumes of the R&D and non-R&D departments are nearly the same.
Therefore, the same virtual system resources are allocated to them.
Figure 3-16 Networking diagram of network isolation (Layer-3 access, virtual systems having
independent WAN interfaces)
Area A Intranet FW
Trust
GE1/0/3 GE1/0/1
R&D 10.3.0.1/24 10.1.1.8/24
department
10.3.0.0/24
vsysa
Trust
GE1/0/4 GE1/0/2
Non-R&D 10.3.1.1/24 10.1.1.9/24
department
10.3.1.0/24
vsysb 10.1.1.1/24
Data Planning
vsysa l Virtual system name: -

vsysa
l Outside interface:
GE1/0/1
l Inside interface IP
address: 10.1.1.8/24
l Security zone to which
the outside interface
belongs: Untrust
l Inside interface: GE1/0/3
address: 10.3.0.1/24
l Private IP address range:
10.3.0.0/24
the inside interface
belongs: Trust
l IP addresses allowed to
access the Internet:
10.3.0.2 to 10.3.0.10

vsysb l Virtual system name: -

vsysb
GE1/0/2
address: 10.1.1.9/24
belongs: Untrust
address: 10.3.1.1/24
10.3.1.0/24
belongs: Trust
Resource class l Name: r1 -

l Reserved Number for
Session: 10000
l Maximum for Session:
50000
l User: 300
l User Group: 10
l Policy: 300
l Maximum Bandwidth:
20 Mbit/s
1. The public system administrator creates two virtual systems vsysa, and vsysb, assigns
resources.
2. The public system administrator configures IP addresses, routes, security policies, and
NAT policies for vsysa.
NAT policies for vsysb.
Procedure
Step 1 The public system administrator creates virtual systems vsysa, and vsysb, and assigns
resources to them.
# Use the account of the public system administrator to log in to the FW.
# Enable the virtual system function.

<FW> system-view
[FW] vsys enable
# Configure a resource class.

[FW] resource-class r1
[FW-resource-class-r1] resource-item-limit session reserved-number 10000 maximum
50000
[FW-resource-class-r1] resource-item-limit policy reserved-number 300
[FW-resource-class-r1] resource-item-limit user reserved-number 300
[FW-resource-class-r1] resource-item-limit user-group reserved-number 10
[FW-resource-class-r1] resource-item-limit bandwidth 20 entire
[FW-resource-class-r1] quit
# Create virtual systems and allocate resources to them.

[FW] vsys name vsysa
[FW-vsys-vsysa] assign resource-class r1
[FW-vsys-vsysa] assign interface GigabitEthernet 1/0/1
[FW-vsys-vsysa] quit
[FW] vsys name vsysb
[FW-vsys-vsysb] assign resource-class r1
[FW-vsys-vsysb] assign interface GigabitEthernet 1/0/2
[FW-vsys-vsysb] quit
Step 2 The public system administrator configures IP addresses, routes, security policies, and NAT
policies for vsysa.
# The public system administrator configures interfaces for vsysa.

[FW-vsysa-GigabitEthernet1/0/1] ip address 10.1.1.8 24
[FW-vsysa-zone-trust] add interface GigabitEthernet 1/0/3
[FW-vsysa-zone-untrust] add interface GigabitEthernet 1/0/1
# The public system administrator configures a static route for vsysa.

[FW-vsysa] ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
# The public system administrator configures an address set for vsysa.

[FW-vsysa] ip address-set ipaddress1 type object
[FW-vsysa-object-address-set-ipaddress1] address range 10.3.0.2 10.3.0.10
[FW-vsysa-object-address-set-ipaddress1] quit
# The public system administrator configures a security policy for vsysa. This security policy
allows intranet users of a specific network segment to access the Internet.
[FW-vsysa-policy-security-rule-to_internet] source-address address-set ipaddress1

prohibits all employees from accessing the Internet. The priority of this policy is lower than
that of the previous policy, and therefore no address range needs to be specified.
[FW-vsysa-policy-security] rule name
to_internet2
[FW-vsysa-policy-security-rule-to_internet2] source-zone
trust
[FW-vsysa-policy-security-rule-to_internet2] destination-zone
untrust
[FW-vsysa-policy-security-rule-to_internet2] action deny
[FW-vsysa-policy-security-rule-to_internet2]
quit
# The public system administrator configures a NAT policy for vsysa.

[FW-vsysa] nat-policy
[FW-vsysa-policy-nat] rule name nat1
[FW-vsysa-policy-nat-rule-nat1] source-zone trust
[FW-vsysa-policy-nat-rule-nat1] egress-interface GigabitEthernet 1/0/1
[FW-vsysa-policy-nat-rule-nat1] source-address address-set ipaddress1
[FW-vsysa-policy-nat-rule-nat1] action nat easy-ip
[FW-vsysa-policy-nat-rule-nat1] quit
[FW-vsysa-policy-nat] quit
policies for vsysb.
The configuration is similar as that of the R&D department except the following:
l The IP address of the inside interface is different.
l You do not need to create an IP address range for the non-R&D department. You only
need to configure a security policy to allow all IP addresses to access the Internet.
l The outbound interface of the NAT policy must be set to GE1/0/2, and the source address
must be set to any.
----End
Verification
l Use a PC that is allowed to access the Internet and a PC that is not allowed to access the
Internet from the R&D department and use the PCs to access the Internet. If the results
are as expected, the IP addresses, security policies and NAT policies of vsysa are
correctly configured.
l Access the Internet from the non-R&D department. If the access succeeds, the IP
addresses, security policies and NAT policies of vsysb are correctly configured.
Configuration script of the public system
#
sysname FW
#
vsys enable
#
resource-class r1
resource-item-limit session reserved-number 10000 maximum 50000
resource-item-limit policy reserved-number 300
resource-item-limit user reserved-number 300
resource-item-limit user-group reserved-number 10

resource-item-limit bandwidth 20 entire

#
vsys name vsysa 1
assign resource-class r1
assign interface GigabitEthernet1/0/1
#
vsys name vsysb 2
#
return
Configuration script of vsysa

#
ip address 10.1.1.8 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
ip address-set ipaddress1 type object
address 0 range 10.3.0.2 10.3.0.10
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
#
security-policy
rule name to_internet
source-zone trust
source-address address-set ipaddress1
action permit
rule name to_internet2
source-zone trust
action deny
#
nat-policy
rule name nat1
source-zone trust
egress-interface GigabitEthernet1/0/1
action nat easy-ip
#
return
Configuration script of vsysb

#
ip address 10.1.1.9 255.255.255.0
#
ip address 10.3.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#

set priority 5
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
#
security-policy
source-zone trust
action permit
#
nat-policy
rule name nat1
source-zone trust
action nat easy-ip
#
return

Enterprise Departments (Layer-3 Access, Virtual Systems Sharing
the WAN Interface of the Public System)
An enterprise may have multiple departments, and each department has specific functions and
responsibilities and requires specific network management policies, which complicates the
configuration. As the egress gateway of the enterprise network, the FW uses virtual systems
to manage departments separately, simplifying the configuration.
Medium-sized enterprise A deploys a firewall as the network gateway. The network of this
enterprise is divided into three subnets respectively for the R&D, financial, and administrative
department. The security policies for the three departments are different and must meet the
following requirements:
l The intranet has only one public IP address and one outside interface. Therefore, all
departments must use the same interface to access the Internet.
l Internet access is granted to all employees of the administrative department, some
employees of the R&D department, but none of the employees of the financial
department.
l The three departments have similar traffic volumes and therefore are assigned the same
amount of virtual system resources.
Configure virtual systems to meet the preceding requirements. Figure 3-17 shows the
networking diagram.

Figure 3-17 Networking diagram of network isolation (Layer-3 access, virtual systems
sharing the WAN interface of the public system)
Intranet
Trust FW
GE1/0/3
R&D 10.3.0.1/24
department
10.3.0.0/24
vsysa
Trust
GE1/0/4
Financial 10.3.1.1/24
department
10.3.1.0/24 GE1/0/1
1.1.1.1/24
vsysb public
Trust
GE1/0/5
Administrative 10.3.2.1/24
department
10.3.2.0/24
vsysc
Data Planning
public l Outside interface: In the example, all

GE1/0/1 departments must access the
l Security zone to which Internet from their own
the outside interface virtual systems through the
belongs: Untrust public system. The
departments do not have
l Outside interface IP overlapping private IP
address: 1.1.1.1/24 addresses. Therefore, you
l Inside interface: virtual are advised to configure the
interface Virtual-if0 of NAT policies on the public
the public system system.
belongs: Trust
l IP address of the carrier
network gateway:
1.1.1.254/24


vsysa
l Outside interface: vsysa's
virtual interface
belongs: Untrust
address: 10.3.0.1/24
10.3.0.0/24
belongs: Trust
l Administrator:
admin@@vsysa
10.3.0.2 to 10.3.0.10

vsysb
vsysb's virtual interface
belongs: Untrust
address: 10.3.1.1/24
10.3.1.0/24
belongs: Trust
l Administrator:
admin@@vsysb

vsysc l Virtual system name: -

vsysc
l Outside interface: vsysc's
virtual interface
belongs: Untrust
address: 10.3.2.1/24
10.3.2.0/24
belongs: Trust
l Administrator:
admin@@vsysc
Resource class l Name: r1 The three departments have

l Reserved Number for similar traffic volumes and
Session: 10000 therefore are assigned the
same resource class.
50000
l User: 300
l User Group: 10
l Policy: 300
20 Mbit/s
1. The public system administrator creates three virtual systems vsysa, vsysb, and vsysc,
assigns resources, and configures an administrator for each virtual system.
2. The public system administrator configures routes and NAT policies for intranet users to
access the Internet.
3. The administrator of the R&D department logs in to the FW to configure IP addresses,
routes, and security policies for vsysa.
4. The administrator of the financial department logs in to the FW to configure IP
addresses, routes, and security policies for vsysb.
5. The administrator of the administrative department logs in to the FW to configure IP
addresses, routes, and security policies for vsysc.

Procedure
Step 1 The public system administrator creates virtual systems vsysa, vsysb, and vsysc and assigns
resources to them.

<FW> system-view
[FW] vsys enable

50000

[FW] vsys name vsysc
[FW-vsys-vsysc] assign resource-class r1
[FW-vsys-vsysc] assign interface GigabitEthernet 1/0/5
[FW-vsys-vsysc] quit
Step 2 The public system administrator configures administrators for virtual systems.
# The public system administrator creates administrator account admin@@vsysa for vsysa.
[FW-vsysa] aaa
Enter Password:
Confirm Password:
[FW-vsysa-aaa-manager-user-admin@@vsysa] service-type web telnet ssh
[FW-vsysa-aaa] quit
[FW-vsysa] quit
<FW-vsysa> quit
Configure administrators admin@@vsysb and admin@@vsysc respectively for the vsysb

and vsysc by referring to the preceding substeps.
Step 3 The public system administrator configures routes, security policies, and NAT policies for
intranet users to access the Internet.
# Set IP addresses for interfaces and add the interfaces to security zones. The IP address of
Virtual-if0 can be any value as long as it does not conflict with the IP address on any other
interface.


[FW-zone-trust] add interface Virtual-if 0
# Create a default route with the next hop being 1.1.1.254.

# Configure a static route. This static route is used to divert to vsysa the Internet traffic
requested by users of vsysa.
# Configure a static route. This static route is used to divert to vsysc the Internet traffic
requested by users of vsysc.
[FW] ip route-static 10.3.2.0 24 vpn-instance vsysc
# Configure a security policy. This security policy allows intranet users to access the Internet.
A virtual system administrator can configure security policies specific to intranet users' IP
addresses. Therefore, the public system administrator does not need to specify IP address
ranges when configuring a security policy.
[FW-policy-security] rule name to_internet
[FW-policy-security-rule-to_internet] source-zone trust
[FW-policy-security-rule-to_internet] destination-zone untrust
[FW-policy-security-rule-to_internet] action permit
[FW-policy-security-rule-to_internet] quit

[FW] nat-policy
[FW-policy-nat] rule name nat1
[FW-policy-nat-rule-nat1] source-zone trust
[FW-policy-nat-rule-nat1] egress-interface GigabitEthernet 1/0/1
[FW-policy-nat-rule-nat1] source-address 10.3.0.0 16
[FW-policy-nat-rule-nat1] action nat easy-ip
[FW-policy-nat-rule-nat1] quit
Step 4 The administrator of the R&D department configures IP addresses, routes, and security
policies for vsysa.
# Use the virtual system administrator account admin@@vsysa to log in to the FW. Change
the login password before performing the following operations.
# Set IP addresses for interfaces and add the interfaces to security zones. The IP address of
Virtual-if1 can be any value as long as it does not conflict with the IP address on any other
interface.
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore,
the actual interface may not be Virtual-if1.

NOTE
<vsysa> system-view
[vsysa] interface GigabitEthernet 1/0/3
[vsysa-GigabitEthernet1/0/3] ip address 10.3.0.1 24
[vsysa-GigabitEthernet1/0/3] quit
[vsysa] interface Virtual-if 1
[vsysa-Virtual-if1] ip address 172.16.1.1 24
[vsysa-Virtual-if1] quit
[vsysa] firewall zone trust
[vsysa-zone-trust] add interface GigabitEthernet 1/0/3
[vsysa-zone-trust] quit
[vsysa] firewall zone untrust
[vsysa-zone-untrust] add interface Virtual-if 1
[vsysa-zone-untrust] quit
# Configure a static route. This static route is used to divert the Internet traffic requested by
users of vsysa to the public system.
NOTE
For simplicity, this example is based on the assumption that vsysa only processes the Internet access of
intranet users. Therefore, in this example, Destination Address/Mask is set to 0.0.0.0 0.0.0.0 so that all
packets are sent to the public system by default. In real-world configurations, to ensure correct routing,
you must set Destination Address/Mask to a specific IP address range that is allowed to access the
Internet. If the routing configuration is incorrect, the private networks attached to vsysa may not
communicate with each other.
[vsysa] ip route-static 0.0.0.0 0.0.0.0 public
# Configure an address set.

[vsysa] ip address-set ipaddress1 type object
[vsysa-object-address-set-ipaddress1] address range 10.3.0.2 10.3.0.10
[vsysa-object-address-set-ipaddress1] quit
# Configure a security policy to prohibit employees on the specified subnets from accessing
the administrative department network. A route is configured in the public system to divert
the return traffic to vsysa and vsysc. Therefore, vsysa and vsysc can communicate with the
communication packets relayed by the public system. To isolate vsysa from vsysc, you need
to configure a security policy in vsysa to prohibit employees in vsysc from accessing vsysa.
[vsysa] security-policy
[vsysa-policy-security] rule name
to_admin_department
[vsysa-policy-security-rule-to_admin_department] source-zone
trust
[vsysa-policy-security-rule-to_admin_department] destination-zone
untrust
[vsysa-policy-security-rule-to_admin_department] source-address address-set
ipaddress1
[vsysa-policy-security-rule-to_admin_department] destination-address 10.3.2.0 24
[vsysa-policy-security-rule-to_admin_department] action
deny
[vsysa-policy-security-rule-to_admin_department] quit
# Configure a security policy. This security policy allows intranet users of a specific network
segment to access the Internet.
[vsysa-policy-security] rule name to_internet
[vsysa-policy-security-rule-to_internet] source-zone trust
[vsysa-policy-security-rule-to_internet] destination-zone untrust
[vsysa-policy-security-rule-to_internet] source-address address-set ipaddress1
[vsysa-policy-security-rule-to_internet] action permit
[vsysa-policy-security-rule-to_internet] quit

# Configure a security policy. This security policy prohibits all employees from accessing the
Internet. The priority of this policy is lower than that of the previous policy, and therefore no
address range needs to be specified.
[vsysa-policy-security] rule name to_internet2
[vsysa-policy-security-rule-to_internet2] source-zone trust
[vsysa-policy-security-rule-to_internet2] destination-zone untrust
[vsysa-policy-security-rule-to_internet2] action deny
[vsysa-policy-security-rule-to_internet2] quit
[vsysa-policy-security] quit
Step 5 The financial department administrator admin@@vsysb and administrative department

administrator admin@@vsysc log in to the FW and configure IP addresses, security zones,
and security policies for vsysb and vsysc, respectively.
l You do not need to create an IP address range for the financial department. You only
need to configure a security policy to prevent all IP addresses from accessing the
Internet.
l You do not need to create an IP address range for the administrative department. You
only need to configure a security policy to prohibit all IP addresses from accessing the
R&D department network and another security policy to allow all IP addresses to access
the Internet.
----End
Verification
l Access the Internet from the administrative department. If the access succeeds, the IP
addresses, security policies of vsysc, and NAT policy of the public system are correctly
configured.
l Access the Internet from the financial department. If the access fails, the IP addresses
and security policies of vsysb are correctly configured.
Internet from the R&D department to access the Internet. If the results are as expected,
the IP addresses and security policies of vsysa are correctly configured.
#
sysname FW
#
vsys enable
#
resource-class r1
#
vsys name vsysa 1
#
vsys name vsysb 2

#
vsys name vsysc 3
#
ip address 1.1.1.1 255.255.255.0
#
interface Virtual-if0
ip address 172.16.0.1 255.255.255.0
#
firewall zone trust
set priority 85
add interface Virtual-if0
#
set priority 5
#
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet1/0/1 1.1.1.254
ip route-static 10.3.0.0 255.255.255.0 vpn-instance vsysa
ip route-static 10.3.2.0 255.255.255.0 vpn-instance vsysc
#
security-policy
source-zone trust
action permit
#
nat-policy
rule name nat1
source-zone trust
action nat easy-ip
#
return

#
ip address 10.3.0.1 255.255.255.0
service-manage ping permit
#
ip address 172.16.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
aaa
manager-user admin@@vsysa
password cipher %@%@@~QEN4"Db/xmvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]X%@%@
service-type web telnet ssh
level 15
bind manager-user admin@@vsysa role system-admin

#
address 0 range 10.3.0.2 10.3.0.10
#
ip route-static 0.0.0.0 0.0.0.0 public

#
security-policy
rule name to_admin_department
source-zone trust
action deny
source-zone trust
action permit
source-zone trust
action deny
#
return

#
ip address 10.3.1.1 255.255.255.0
#
ip address 172.16.2.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
aaa
manager-user admin@@vsysb
password cipher %@%@zG{;O|!gEN4"Db/xmvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]
level 15
bind manager-user admin@@vsysb role system-admin

#
#
security-policy
source-zone trust
action deny
#
return
Configuration script of vsysc

#
ip address 10.3.2.1 255.255.255.0
#
ip address 172.16.3.1 255.255.255.0
#
firewall zone trust
set priority 85
#


set priority 5
#
aaa
manager-user admin@@vsysc
password cipher %@%@zG{;x|!gEN5"Db/6dvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]
level 15
bind manager-user admin@@vsysc role system-admin

#
#
security-policy
rule name to_rd_department
source-zone trust
action deny
source-zone trust
action permit
#
return

Enterprise Departments (Layer-2 Access)
When the FW connects to an intranet through Layer-2 access, configure virtual systems to
isolate enterprise departments and facilitate configuration management by different
administrators.
Medium-sized enterprise A deploys a firewall as the network gateway. The network of this
enterprise is divided into three subnets respectively for the R&D, financial, and administrative
department. The security policies for the three departments are different and must meet the
following requirements:
l The FW connects to an existing intranet through Layer-2 access, without changing the
intranet's network topology.
l Internet access is granted to all employees of the administrative department, some
employees of the R&D department, but none of the employees of the financial
department.
l The three departments have similar traffic volumes and therefore are assigned the same
amount of virtual system resources.
networking diagram.

Figure 3-18 Networking diagram of network isolation (Layer-2 access)

Intranet
FW
Trust
R&D
department
10.3.0.2~
99 vsysa
vlan10 vlan10
Trust
Financial
department
10.3.0.100~
199 GE1/0/2 vsysb GE1/0/1
vlan20 vlan10,20,30 vlan20 vlan10,20,30
Trust
Administrative
department
10.3.0.200~
254 vsysc
vlan30 vlan30
Data Planning
vsysa l Virtual system name: Both the outside interface

vsysa GE1/0/1 and inside interface
l Outside interface: GE1/0/2 are trunk interfaces
GE1/0/1 and can be assigned to
multiple virtual systems
l Security zone to which based on VLAN assignment.
belongs: Untrust
belongs: Trust
l VLAN assigned:
VLAN10
l Administrator:
admin@@vsysa
10.3.0.2 to 10.3.0.10


vsysb
GE1/0/1
belongs: Untrust
belongs: Trust
l VLAN assigned:
VLAN20
l Administrator:
admin@@vsysb
vsysc l Virtual system name: -

vsysc
GE1/0/1
belongs: Untrust
belongs: Trust
l VLAN assigned:
VLAN30
l Administrator:
admin@@vsysc
Resource class l Name: r1 The three departments have

l Reserved Number for similar traffic volumes and
Session: 10000 therefore are assigned the
same resource class.
50000
l User: 300
l User Group: 10
l Policy: 300
20 Mbit/s

1. Configure GE1/0/1 and GE1/0/2 as trunk interfaces and add them to VLANs.
2. The public system administrator creates three virtual systems vsysa, vsysb, and vsysc,
assigns VLANs and resources, and configures an administrator for each virtual system.
3. The administrator of the R&D department logs in to the FW to configure security
policies for vsysa.
4. The administrator of the financial department logs in to the FW to configure security
policies for vsysb.
5. The administrator of the administrative department logs in to the FW to configure
security policies for vsysc.
Procedure
Step 1 Configure GE1/0/1 and GE1/0/2 as trunk interfaces and add them to VLANs.
# Create VLANs.
<FW> system-view
[FW] vlan 10
[FW-vlan-10] quit
[FW] vlan 20
[FW-vlan-20] quit
[FW] vlan 30
[FW-vlan-30] quit
# Configure interfaces.
[FW-GigabitEthernet1/0/1] port link-type trunk
[FW-GigabitEthernet1/0/1] port trunk allow-pass vlan 10 20 30
[FW-GigabitEthernet1/0/2] port trunk allow-pass vlan 10 20 30
Step 2 The public system administrator creates virtual systems vsysa, vsysb, and vsysc and assigns
VLANs to them.
[FW] vsys enable

50000


[FW-vsys-vsysa] assign vlan 10

[FW-vsys-vsysb] assign vlan 20
[FW] vsys name vsysc
[FW-vsys-vsysc] assign resource-class r1
[FW-vsys-vsysc] assign vlan 30
[FW-vsys-vsysc] quit
Step 3 The public system administrator configures administrators for virtual systems.
# The public system administrator creates administrator account admin@@vsysa for vsysa.
[FW-vsysa] aaa
Enter Password:
Confirm Password:
[FW-vsysa-aaa-manager-user-admin@@vsysa] service-type web telnet ssh
[FW-vsysa-aaa] quit
[FW-vsysa] quit
<FW-vsysa> quit
Configure administrators admin@@vsysb for vsysb and admin@@vsysc for vsysc by

referring to the preceding substeps.
Step 4 The administrator of the R&D department configures security zones and security policies for
vsysa.
# Use the administrator account admin@@vsysa of vsysa to log in to the firewall. Change
the login password before performing the following operations.
# Configure security zones.

<vsysa> system-view
[vsysa] firewall zone trust
[vsysa-zone-trust] add interface GigabitEthernet 1/0/2
[vsysa-zone-trust] quit
[vsysa] firewall zone untrust
[vsysa-zone-untrust] add interface GigabitEthernet 1/0/1
[vsysa-zone-untrust] quit
# Configure an address set.

[vsysa] ip address-set ipaddress1 type object
[vsysa-object-address-set-ipaddress1] address range 10.3.0.2 10.3.0.10
[vsysa-object-address-set-ipaddress1] quit
# Configure a security policy. This security policy allows intranet users of a specific network
segment to access the Internet.
[vsysa] security-policy
[vsysa-policy-security] rule name to_internet
[vsysa-policy-security-rule-to_internet] source-zone trust
[vsysa-policy-security-rule-to_internet] destination-zone untrust
[vsysa-policy-security-rule-to_internet] source-address address-set ipaddress1
[vsysa-policy-security-rule-to_internet] action permit
[vsysa-policy-security-rule-to_internet] quit

# Configure a security policy. This security policy prohibits all employees from accessing the
Internet. The priority of this policy is lower than that of the previous policy, and therefore no
address range needs to be specified.
[vsysa-policy-security] rule name to_internet2
[vsysa-policy-security-rule-to_internet2] source-zone trust
[vsysa-policy-security-rule-to_internet2] destination-zone untrust
[vsysa-policy-security-rule-to_internet2] action deny
[vsysa-policy-security-rule-to_internet2] quit
[vsysa-policy-security] quit
Step 5 The financial department administrator admin@@vsysb and administrative department

administrator admin@@vsysc log in to the FW and configure IP addresses, security zones,
and security policies for vsysb and vsysc, respectively.
The configuration is similar to that of the R&D department except the following:
l You do not need to create an IP address range for the financial department. You only
need to configure a security policy to prevent the IP address segment 10.3.0.0/24 from
accessing the Internet.
l You do not need to create an IP address range for the administrative department. You
only need to configure a security policy to allow the IP address segment 10.3.0.0/24 to
access the Internet.
----End
Verification
Internet from the R&D department to access the Internet. If the results are as expected,
the security policies of vsysa are correctly configured.
l Access the Internet from the financial department. If the access fails, the security policies
of vsysb are correctly configured.
l Access the Internet from the administrative department. If the access succeeds, the
security policies of vsysc are correctly configured.
#
sysname FW
#
vlan batch 10 20 30
#
vsys enable
#
resource-class r1
#
vsys name vsysa 1
assign vlan 10
#
vsys name vsysb 2
assign vlan 20

#
vsys name vsysc 3
assign vlan 30
#
portswitch
undo shutdown
port link-type trunk
port trunk allow-pass vlan 10 20 30
#
portswitch
undo shutdown
port trunk allow-pass vlan 10 20 30
#
return

#
firewall zone trust
set priority 85
#
set priority 5
#
aaa
manager-user admin@@vsysa
password cipher %@%@@~QEN4"Db/xmvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]X%@%@
level 15
bind manager-user admin@@vsysa role system-admin

#
address 0 range 10.3.0.2 10.3.0.10
#
security-policy
source-zone trust
action permit
source-zone trust
action deny
#
return

#
firewall zone trust
set priority 85
#
set priority 5
#
aaa
manager-user admin@@vsysb
password cipher %@%@zG{;O|!gEN4"Db/xmvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]
level 15

bind manager-user admin@@vsysb role system-admin

#
security-policy
source-zone trust
action deny
#
return
Configuration script of vsysc

#
firewall zone trust
set priority 85
#
set priority 5
#
aaa
manager-user admin@@vsysc
password cipher %@%@zG{;x|!gEN5"Db/6dvR'5@=5)^`WN]~h`Mwn-{BNPy#ZYE>`6`f]
level 15
bind manager-user admin@@vsysc role system-admin

#
security-policy
source-zone trust
action permit
#
return
3.8.4 CLI Example for Configuring Virtual Systems on a Cloud

Computing Gateway
This section provides an example for configuring virtual systems to protect a cloud computing
data center.
A cloud computing data center uses a FW for security protection of the egress gateway to
meet the following requirements:
l Customers of the data center can independently manage and access their server
resources.
l The FW has only one outside interface but provides sufficient public IP addresses. NAT
polices are configured on the FW so that customers have independent public IP
addresses to access their own server resources.
l Enterprises A and B have similar traffic volumes and purchase the same amount of
resources.
networking diagram.

Figure 3-19 Security gateway for cloud computing centers

Cloud computing
center
Trust FW
GE1/0/2.1
… 10.3.0.1/24
Enterprise A
10.3.0.2/24
Enterprise A vsysa
10.3.0.0/24
Trust GE1/0/1
public 1.1.1.1/24
… GE1/0/2.2
10.3.1.1/24 Enterprise B
10.3.1.2/24
Enterprise B
10.3.1.0/24 vsysb
Data Planning
public l Outside interface: In this example, all intranet

GE1/0/1 servers provide services to
l Outside interface IP Internet users through the
address: 1.1.1.1/24 public system's outside
interface.
belongs: Untrust
l Inside interface: public's
virtual interface Virtual-
if0
belongs: Trust
l IP address of the carrier
network gateway:
1.1.1.254/24

vsysa l Virtual system name: In this example, IP address

vsysa mapping must be configured
l Outside interface: vsysa's so that the server at the
virtual interface private address 10.3.0.2 can
use the public address
l Security zone to which 1.1.1.2 to provide services
the outside interface to users of enterprise A.
belongs: Untrust
The public system
l Inside interface: administrator configures and
GE1/0/2.1 manages virtual systems,
l Inside interface IP and no virtual system
address: 10.3.0.1/24 administrator is required.
10.3.0.0/24
belongs: Trust
l Private address and port
of the internal server for
Internet users:
10.3.0.2:80
l Public address and port
mapped to the internal
server for Internet users:
1.1.1.2:8080

vsysb l Virtual system name: In this example, IP address

vsysb mapping must be configured
l Outside interface: so that the server at the
vsysb's virtual interface private address 10.3.1.2 can
use the public address
l Security zone to which 1.1.1.3 to provide services
the outside interface to users of enterprise B.
belongs: Untrust
The public system
l Inside interface: administrator configures and
GE1/0/2.2 manages virtual systems,
l Inside interface IP and no virtual system
address: 10.3.1.1/24 administrator is required.
10.3.1.0/24
belongs: Trust
l Private address and port
of the internal server for
Internet users:
10.3.1.2:80
l Public address and port
mapped to the internal
server for Internet users:
1.1.1.3:8080
Resource class l Name: r1 In the example, the

l Reserved Number for requirements of both
Session: 10000 enterprises are the same.
Therefore, create only one
l Maximum for Session: resource class and bind it to
50000 the two virtual systems.
20 Mbit/s
1. The public system administrator creates virtual systems vsysa and vsysb and allocates
resources to them.
2. Create subinterfaces GE1/0/2.1 and GE1/0/2.2 on the GE1/0/2 and configure these two
subinterfaces as inside interfaces of vsysa and vsysb, respectively.
3. The public system administrator configures IP address mapping for vsysa and vsysb.
4. The public system administrator configures routes and security policies for vsysa and
vsysb.

Procedure
Step 1 The public system administrator creates virtual systems vsysa and vsysb and allocates
resources to them.
# Use the public system administrator account to log in to the FW.
# Create subinterfaces.
<FW> system-view
[FW] interface GigabitEthernet 1/0/2.1
[FW-GigabitEthernet1/0/2.1] vlan-type dot1q 10
[FW-GigabitEthernet1/0/2.1] quit

[FW] vsys enable

50000

[FW-vsys-vsysa] assign interface GigabitEthernet 1/0/2.1
[FW-vsys-vsysb] assign interface GigabitEthernet 1/0/2.2
Step 2 Configure inside interfaces, outside interfaces, and virtual interfaces on the public system.
# On the public system, set IP addresses for interfaces and add the interfaces to security
zones. The IP address of Virtual-if0 can be any value as long as it does not conflict with the IP
# On vsysa, set IP addresses for interfaces and add the interfaces to security zones. The IP
address of Virtual-if1 can be any value as long as it does not conflict with the IP address on
any other interface.
NOTE
The ID of a virtual interface is automatically assigned based on existing IDs in the system. Therefore,
the actual interface may not be Virtual-if1 or Virtual-if2.


[FW-vsysa] interface GigabitEthernet 1/0/2.1
[FW-vsysa-GigabitEthernet1/0/2.1] ip address 10.3.0.1 24
[FW-vsysa-GigabitEthernet1/0/2.1] quit
[FW-vsysa-zone-trust] add interface GigabitEthernet 1/0/2.1
[FW-vsysa-zone-untrust] add interface Virtual-if 1
[FW-vsysa] quit
<FW-vsysa> quit
# On vsysb, set IP addresses for interfaces and add the interfaces to security zones. The
procedure is similar to that on vsysa.
Step 3 Configure routes, security policies, and NAT policies on the public system.
# Create a default route with the next hop being 1.1.1.254.

# Configure a static route. This static route is used to divert to vsysa the server traffic
requested by users of enterprise A.
# Configure a static route. This static route is used to divert to vsysb the server traffic
requested by users of enterprise B.
# Configure a security policy. This security policy allows intranet users to access servers on
the intranet.
[FW-policy-security] rule name
internet_to_server
[FW-policy-security-rule-internet_to_server] source-zone
untrust
[FW-policy-security-rule-internet_to_server] destination-zone trust
[FW-policy-security-rule-internet_to_server] destination-address 10.3.0.0 16
[FW-policy-security-rule-internet_to_server] action
permit
[FW-policy-security-rule-internet_to_server]
quit
# Configure server mappings.

[FW] nat server publicserver_vsysa protocol tcp global 1.1.1.2 8080 inside
10.3.0.2 www no-reverse
[FW] nat server publicserver_vsysb protocol tcp global 1.1.1.3 8080 inside
10.3.1.2 www no-reverse
# Configure a static route. This static route is used to divert to the public system the server
traffic requested by users of enterprise A.
[FW-vsysa] ip route-static 0.0.0.0 0.0.0.0 public

# Configure a security policy. This security policy allows intranet users to access servers on
the intranet.
[FW-vsysa-policy-security] rule name internet_to_server
[FW-vsysa-policy-security-rule-internet_to_server] source-zone
untrust
[FW-vsysa-policy-security-rule-internet_to_server] destination-zone trust
[FW-vsysa-policy-security-rule-internet_to_server] destination-address 10.3.0.0 24
[FW-vsysa-policy-security-rule-internet_to_server] action
permit
[FW-vsysa-policy-security-rule-internet_to_server] quit
[FW-vsysa] quit
<FW-vsysa> quit

The details are omitted because the configurations are the same as those of vsysa, except the
IP addresses.
----End
Verification
l Access http://1.1.1.2:8080 from enterprise A. If the access succeeds, IP address mapping
and security policies are correctly configured.
l Access http://1.1.1.3:8080 from enterprise B. If the access succeeds, IP address mapping
and security policies are correctly configured.
#
sysname FW
#
vsys enable
#
nat server publicserver_vsysa 0 protocol tcp global 1.1.1.2 8080 inside 10.3.0.2
www no-reverse
nat server publicserver_vsysb 1 protocol tcp global 1.1.1.3 8080 inside 10.3.1.2
www no-reverse
#
resource-class r1
#
vsys name vsysa 1
assign interface GigabitEthernet1/0/2.1
#
vsys name vsysb 2
assign interface GigabitEthernet1/0/2.2
#
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet1/0/2.1
vlan-type dot1q 10
ip binding vpn-instance vsysa
#
vlan-type dot1q 20
ip binding vpn-instance vsysb

#
ip address 172.16.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
ip route-static 10.3.0.0 255.255.255.0 vpn-instance vsysa
ip route-static 10.3.1.0 255.255.255.0 vpn-instance vsysb
#
security-policy
rule name internet_to_server
source-zone untrust
destination-zone trust
action permit
#
return

#
vlan-type dot1q 10
ip address 10.3.0.1 255.255.255.0
ip binding vpn-instance vsysa
#
ip address 172.16.1.1 255.255.255.0
#
firewall zone trust
set priority 85
add interface GigabitEthernet1/0/2.1
#
set priority 5
#
#
security-policy
source-zone untrust
action permit
#
return

#
vlan-type dot1q 20
ip address 10.3.1.1 255.255.255.0
ip binding vpn-instance vsysb
#
ip address 172.16.2.1 255.255.255.0
#
firewall zone trust
set priority 85
#


set priority 5
#
#
security-policy
source-zone untrust
action permit
#
return
3.8.5 CLI Example for Configuring the Communication Between

Virtual Systems
The FW uses virtual systems to manage departments separately, simplifying the configuration.
This section describes how to implement communication between virtual systems.
As shown in Figure 3-20, a FW is deployed in area of the large campus network as the access
gateway. The network of area A comprises the R&D and non-R&D departments, and the two
departments have different network access permissions. Requirements are as follows:
l Some employees in the R&D department can access the Internet, and all employees in
the non-R&D department can access the Internet.
l The R&D department is isolated from non-R&D departments, but specific employees in
the two departments can communicate.
l The service volumes of the R&D and non-R&D departments are nearly the same.
Therefore, the same virtual system resources are allocated to them.
Figure 3-20 Networking diagram of communication between virtual systems

Area A Intranet FW
Trust
GE1/0/3 GE1/0/1
R&D 10.3.0.1/24 10.1.1.8/24
department
10.3.0.0/24
vsysa
Trust
GE1/0/4 GE1/0/2
Non-R&D 10.3.1.1/24 10.1.1.9/24
department
10.3.1.0/24
vsysb 10.1.1.1/24

Data Planning

vsysa
GE1/0/1
address: 10.1.1.8/24
belongs: Untrust
address: 10.3.0.1/24
10.3.0.0/24
belongs: Trust
10.3.0.2 to 10.3.0.10

vsysb
GE1/0/2
address: 10.1.1.9/24
belongs: Untrust
address: 10.3.1.1/24
10.3.1.0/24
belongs: Trust

Resource class l Name: r1 -

l Reserved Number for
Session: 10000
50000
l User: 300
l User Group: 10
l Policy: 300
20 Mbit/s
1. The public system administrator creates two virtual systems vsysa, and vsysb, assigns
resources.
2. The public system administrator configures routes for the employees that can
communicate.
NAT policies for vsysa.
NAT policies for vsysb.
Procedure
Step 1 The public system administrator creates virtual systems vsysa, and vsysb, and assigns
resources to them.
<FW> system-view
[FW] vsys enable

50000



interface to the Trust zone. The IP address of Virtual-if0 can be any value as long as it does
not conflict with the IP address on any other interface.
Step 2 The public system administrator configures routes for the employees that can communicate.
policies for vsysa.
# The public system administrator configures interfaces for vsysa. The IP address of Virtual-
if1 can be any value as long as it does not conflict with the IP address on any other interface.
[FW-vsysa-zone-trust] add interface GigabitEthernet 1/0/3
[FW-vsysa-zone-untrust] add interface GigabitEthernet 1/0/1
[FW-vsysa] firewall zone dmz
[FW-vsysa-zone-dmz] add interface Virtual-if1
[FW-vsysa-zone-dmz] quit
# The public system administrator configures a static route for vsysa to access the Internet.
[FW-vsysa] ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
# The public system administrator configures a static route for vsysa to access vsysb.
# The public system administrator configures an address set for vsysa.

[FW-vsysa] ip address-set ipaddress1 type object
[FW-vsysa-object-address-set-ipaddress1] address range 10.3.0.2 10.3.0.10
[FW-vsysa-object-address-set-ipaddress1] quit
allows intranet users of a specific network segment to access the Internet.

[FW-vsysa-policy-security-rule-to_internet] source-address address-set ipaddress1

prohibits all employees from accessing the Internet. The priority of this policy is lower than
that of the previous policy, and therefore no address range needs to be specified.
[FW-vsysa-policy-security] rule name
to_internet2
[FW-vsysa-policy-security-rule-to_internet2] source-zone
trust
[FW-vsysa-policy-security-rule-to_internet2] destination-zone
untrust
[FW-vsysa-policy-security-rule-to_internet2] action deny
[FW-vsysa-policy-security-rule-to_internet2]
quit
allows specific employees in vsysa and vsysb to communicate.
[FW-vsysa-policy-security] rule name to_vsysb
[FW-vsysa-policy-security-rule-to_vsysb] source-zone trust
[FW-vsysa-policy-security-rule-to_vsysb] destination-zone dmz
[FW-vsysa-policy-security-rule-to_vsysb] source-address range 10.3.0.20 10.3.0.30
[FW-vsysa-policy-security-rule-to_vsysb] destination-address range 10.3.1.20
10.3.1.30
[FW-vsysa-policy-security-rule-to_vsysb] action permit
[FW-vsysa-policy-security-rule-to_vsysb] quit
# The public system administrator configures a NAT policy for vsysa.

[FW-vsysa] nat-policy
[FW-vsysa-policy-nat] rule name nat1
[FW-vsysa-policy-nat-rule-nat1] source-zone trust
[FW-vsysa-policy-nat-rule-nat1] egress-interface GigabitEthernet 1/0/1
[FW-vsysa-policy-nat-rule-nat1] source-address address-set ipaddress1
[FW-vsysa-policy-nat-rule-nat1] action nat easy-ip
[FW-vsysa-policy-nat-rule-nat1] quit
[FW-vsysa-policy-nat] quit
policies for vsysb.

l You do not need to create an IP address range for the non-R&D department. You only
need to configure a security policy to allow all IP addresses to access the Internet and
another security policy to allow employee communication.
l The outbound interface of the NAT policy must be set to GE1/0/2, and the source address
must be set to any.
----End
Verification
Internet from the R&D department and use the PCs to access the Internet. If the results
are as expected, the IP addresses, security policies and NAT policies of vsysa are
correctly configured.

l Access the Internet from the non-R&D department. If the access succeeds, the IP
addresses, security policies and NAT policies of vsysb are correctly configured.
#
sysname FW
#
vsys enable
#
resource-class r1
#
vsys name vsysa 1
#
vsys name vsysb 2
#
ip address 172.16.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
ip route-static 10.3.0.0 24 vpn-instance vsysa
ip route-static 10.3.1.0 24 vpn-instance vsysb
#
return

#
ip address 10.1.1.8 255.255.255.0
#
ip address 10.3.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#
firewall zone dmz
set priority 50
#
set priority 5
#
address 0 range 10.3.0.2 10.3.0.10
#

ip route-static 10.3.1.0 24 public

ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
#
security-policy
source-zone trust
action permit
source-zone trust
action deny
rule name to_vsysb
source-zone trust
source-address range 10.3.0.20 10.3.0.30
destination-address range 10.3.1.20 10.3.1.30
action permit
#
nat-policy
rule name nat1
source-zone trust
action nat easy-ip
#
return

#
ip address 10.1.1.9 255.255.255.0
#
ip address 10.3.1.1 255.255.255.0
#
ip address 172.16.2.1 255.255.255.0
#
firewall zone trust
set priority 85
#
firewall zone dmz
set priority 50
#
set priority 5
#
ip route-static 10.3.0.0 24 public
ip route-static 0.0.0.0 0.0.0.0 10.1.1.1
#
security-policy
source-zone trust
action permit
rule name to_vsysa
source-zone trust
source-address range 10.3.1.20 10.3.1.30
destination-address range 10.3.0.20 10.3.0.30
action permit
#
nat-policy
rule name nat1

source-zone trust
action nat easy-ip
#
return
3.9 Feature Reference

This section provides virtual system references.
3.9.1 Function Availability for Virtual Systems

This section describes the function availability for virtual systems.
Table 3-6 describes the function availability for virtual systems.
Table 3-6 Function availability for virtual systems

Function Supported or Not Description
System Administrat Supported -

ors
Time Not supported -
SNMP Not supported -
Across- Supported The SNMP server access

Layer-3 interval and timeout period
MAC can be set only on the public
Identificatio system, not on virtual
n systems.
File System Not supported -
Signature Not supported -

Database
Update
System Not supported -

Upgrade
Configuratio Supported -
n File
Management
High Hot Standby Not supported Hot standby cannot be

Availability configured on virtual
systems, but you can
configure it on the root
system for virtual systems to
use.
Link-group Not supported -
IP-Link Supported -

BFD Not supported -
Networks Interfaces Supported -
Security Supported -
Zones
DNS Not supported -
DHCP Supported The DHCP client function

can only be configured on
interfaces.
PPP Not supported -
PPPoE Not supported -
Intelligent Global Not supported -

Uplink Route
Selection Selection
Policies
ISP Link Not supported -

Selection
PBR Supported Link selection based on

policy-based routes is not
supported.
Router IP Static Supported -

Route
Dynamic Not supported -

route
Object User Supported L2TP/L2TP over IPSec user

authentication and IPSec
user authentication are not
supported. Creating and
importing users/user groups/
security groups are not
supported.
Address and Supported -

Address
Group
Domain Supported -
Group
Region and Supported -

Region
Group

Service and Supported -

Service
Group
Application Supported -
and
Application
Group
Certificate Supported Certificates can be

referenced or viewed but not
configured on virtual
systems.
Schedule Supported -
ACL Supported -
Health Not supported -

Check
Policy Security Supported -

Policy and
Security
Profile
NAT Policy Supported -
Server Load Supported -

Balancing
Bandwidth Supported -
Management
Policy
VPN IPSec Not supported -
L2TP Not supported -
GRE Not supported -
BGP/MPLS Not supported -

IP VPN
Security Attack Supported Only DDoS attack defense

Protection Defense is supported.
Ping proxy Supported -
Blacklist Supported -
IP-MAC Supported -
Binding
ASPF Supported -

Monitoring Logs and Supported -

Reports
Session Supported -
Table
Server Map Supported -
System Not supported -

Statistics
Diagnosis Supported -
Center
Traffic Map Supported -
Threat Map Supported -
Quintuple Not supported -

Packet
Capture
Quintuple Not supported -

Packet
Statistics
IPv6 IPv6 Not supported -
Maintenance Port Not supported -

Mirroring,
System
Restart,
NTP, NQA,
and LLDP
3.9.2 Specifications
This section provides the specifications of the virtual system.
Function specifications
function
Resource Allocating Allocating interface The interfaces include GE

allocation interface resources to virtual interfaces and their
resources systems subinterfaces, Eth-Trunk
interface and their subinerfaces,
tunnel interfaces, and loopback
interfaces.


function
Allocating Allocating VLAN Supported by all models.

VLAN resources to virtual
resources systems
Allocating Allocating public IP Supported by all models.

public IP addresses to virtual
addresses systems
Allocating Allocating resource Supported by all models.

resource classes to virtual systems
classes
Communic Communicati - Supported by all models.

ation on between
between virtual
virtual systems and
systems the public
system
Communicati - Supported by all models.

on between
two virtual
systems
WAN - Setting WAN interfaces Supported by all models.

interface in the interface view
Login - Telnet, STelnet, and Supported by all models.

mode of HTTPS
virtual
system
administrat
ors

Maximum number of virtual systems l USG6000V1: 10 by default, and can be

(excluding the root system) increased to 20 after an upgrade of the
license.
l USG6000V2: 10 by default, and can be
increased to 50 after an upgrade of the
license.
license.
license.
Maximum number of VPN instances 1024

manually created
Maximum number of VLANs and interfaces 1000

allocated to each virtual system
After a VLAN is allocated to a virtual
system, the corresponding VLANIF
interface is also automatically allocated to
the virtual system.
Maximum number of security zones 8

(including the default ones) for each virtual
system
Number of traffic diversion tables 32*1024
Number of IP addresses in each traffic 32*1024

diversion table

This section describes the versions and changes in the virtual system feature.
3.10 Virtual System FAQ

This section describes frequently asked questions (FAQs) about virtual system.

How Can I Use VPN Instances to Isolate Sessions When Packets Pass Through
the FW Twice?
As shown in Figure 3-21, the gateway address of the PC is set to the IP address (192.168.0.1)
of VLANIF10 on the Layer-3 switch. The PC logs in to the FW with the Layer-3 switch as the
relay for management.
At the first time, the packets from the PC to the FW traverse the FW through VLAN10. At the
second time, the packets are forwarded to the FW from VLANIF20. The packets pass through
the FW twice, but the FW cannot distinct the two sessions, causing the PC login failure.
Figure 3-21 Scenario 1: Packets passing through the FW twice

VLANIF20 VLANIF20
192.168.0.2
192.168.1.1 192.168.1.2
L3 VLAN20 VLAN10
Switch VLAN10
VLANIF10
192.168.0.1 FW PC
In such cases, you can configure a VPN instance to isolate the sessions.
[sysname] ip vpn-instance vpn1
[sysname-vpn-instance-vpn1] ipv4-family
[sysname-vpn-instance-vpn1-af-ipv4] route-distinguisher 1:1
[sysname-vpn-instance-vpn1-af-ipv4] vpn-target 2:1
[sysname-vpn-instance-vpn1-af-ipv4] quit
[sysname-vpn-instance-vpn1] quit
Then bind the VPN instance to VLANIF20.

[sysname] interface Vlanif 20
[sysname-Vlanif20] ip binding vpn-instance vpn1
[sysname-Vlanif20] quit
At last, configure a route to the specified VPN instance and set the next hop to the IP address
(192.168.1.1) of VLANIF20 on the Layer-3 switch.
[sysname] ip route-static vpn-instance vpn1 192.168.0.0 24 192.168.1.1
After you configure a VPN instance to isolate the sessions, the PC can log in to the FW.
You may also encounter another scenario. As shown in Figure 3-22, the gateway address of
the PC is set to the IP address (192.168.0.1) of VLANIF10 on the Layer-3 switch. The PC
logs in to the FW with the Layer-3 switch as the relay.

Figure 3-22 Scenario 2: Packets passing through the FW twice
VLANIF20 GE1/0/1
192.168.1.1 192.168.0.2
192.168.1.2
L3 VLAN10 VLAN10
Switch
VLANIF10
192.168.0.1 FW PC
Similar with scenario 1, you need to bind a VPN instance on GE1/0/1 to isolate sessions.
How Can I Configure Virtual Systems to Isolate Services of Different VLANs

When the FW Is Transparently Connected?
As shown in Figure 3-23, VLAN10 and VLAN20 have overlapping IP addresses. Before the
FW is transparently connected, VLANs are used to isolate services. After the FW is
transparently connected, there may be two traffic flows with the same source IP address,
source port, destination IP address, and destination port. If so, the FW fails to distinct the
sessions, affecting normal services.
Figure 3-23 Transparent FW connection
VLAN10 VLAN10
1.1.1.0/24 1.1.1.0/24
VLAN10 VLAN10
VLAN20 VLAN20
VLAN20 L2 Switch L2 Switch VLAN20

1.1.1.0/24 1.1.1.0/24
In such cases, you can configure two virtual systems (or configure one public system and one
virtual system) on the FW and allocate VLAN10 and VLAN20 to different virtual systems. In
this way, the traffic of the two VLANs is separated.

Administrator Guide 4 Networks
4 Networks
About This Chapter
This chapter describes network features and their configurations.
4.1 Interfaces
This section describes basic interface concepts and configuration procedure and provides
configuration examples.
4.2 Interface Pairs
This section describes interface pair concepts and how configure interface pairs, as well as
provides configuration examples.
4.3 Security Zones
This section describes security zone concepts and how to configure a security zone.
4.4 PPP
This section describes Point-to-Point Protocol (PPP) concepts and how to configure PPP.
4.5 PPPoE
This section describes Point-to-Point Protocol over Ethernet (PPPoE) concepts and how to
configure PPPoE, as well as provides configuration examples.
4.6 DNS
This chapter describes the principles, basic functions and configuration procedures of DNS,
and provides configuration examples.
4.7 DHCP
This section describes DHCP concepts and how to configure DHCP, as well as provides
4.8 DHCP Snooping
This section describes concepts and the configuration procedure of Dynamic Host
Configuration Protocol (DHCP) snooping, as well as provides configuration examples.
4.9 MAC Address Table
This section describes MAC address table concepts and how to configure a MAC address
table, as well as provides a configuration example.
4.10 ARP

This section describes Address Resolution Protocol (ARP) concepts and how to configure
ARP, as well as provides configuration examples.
4.11 VLAN
This section describes virtual local area network (VLAN) concepts and how to configure a
VLAN, as well as provides configuration examples.
4.12 IPv6 Neighbor Discovery
This section describes IPv6 neighbor discovery (ND) concepts and how to configure IPv6
ND, as well as provides configuration examples.
4.13 IP Performance
This section describes IP performance parameter concepts and how to configure the
parameters.

4.1 Interfaces
This section describes basic interface concepts and configuration procedure and provides
4.1.1 Overview
An interface on a device serves for the data exchange between devices on the network.
4.1.1.1 Supported Interface Types

This section describes interface types, physical interface numbering rules, interface views and
prompts to help you easily operate and configure the device.
Interface Type
Interfaces of a device are used to exchange data and interact with other network devices.
Interfaces are classified into physical interface, and logical interfaces, as shown in Table 4-1.
Table 4-1 Interface Type

Interface Description Configuration Methods
Type
Web CLI
Phys Layer-3 Works at the network Configured by Configured by

ical Ethernet layer to process Layer 3 following the following the
Inter interface packets with an IPv4 or procedure in 4.1.2.1 procedure in 4.1.3.1
face IPv6 address specified Configuring a Configuring a
s and supports routing Layer 3 Ethernet Layer 3 Ethernet
functions. Interface Interface
Layer-2 Works at the data link Configured by Configured by

Ethernet layer and processes following the following the
interface Layer 2 packets, procedure in 4.1.2.2 procedure in 4.1.3.2
implementing rapid Configuring a Configuring a
Layer 2 forwarding. Layer 2 Ethernet Layer 2 Ethernet
Interface Interface


Type
Web CLI
Logi Eth- Multiple Layer-2 or Configured by Configured by

c Trunk Layer-3 Ethernet following the following the
Inter Interfac interfaces can be bundled procedure in 4.1.2.6 procedure in 4.1.3.6
face e into an Eth-Trunk Configuring an Configuring an
s NOTE interface. The Eth-Trunk Eth-Trunk Eth-Trunk
This interface provides all Interface Interface
type is functions that Ethernet
support interfaces have and
ed only
higher bandwidth and
in the
direct reliability, compared with
SR- a single Ethernet
IOV interface.
mode.
Sub- Sub-interfaces are virtual Configured by Configured by

interface interfaces configured on following the following the
an interface for procedure in 4.1.2.3 procedure in 4.1.3.3
communicating with Configuring a Configuring a
remote ends. Layer 3 Ethernet Layer 3 Ethernet
Subinterface and Subinterface and
4.1.2.4 Configuring 4.1.3.4 Configuring
a Layer 2 Ethernet a Layer 2 Ethernet
Subinterface Subinterface
VLAN VLAN interfaces are Configured by Configured by

Interfac Layer 3 logical following the following the
e interfaces. IP addresses procedure in 4.1.2.5 procedure in 4.1.3.5
can be configured for the Configuring a Configuring a
VLAN interfaces for VLAN Interface VLAN Interface
inter-VLAN
communication.
Loopbac Loopback interfaces Configured by Configured by

k remain Up after they are following the following the
Interfac created and can be procedure in 4.1.2.7 procedure in 4.1.3.7
e configured with 32-bit Configuring a Configuring a
subnet masks. Loopback Interface Loopback Interface
NULL Any packets transmitted NULL0 exists on the NULL0 exists on the
Interfac over a null interface are FW by default. FW by default. For
e discarded. It is used for details, see 4.1.3.8
route filtering. Configuring a Null
NULL0 exists on the FW Interface.
by default.


Type
Web CLI
Tunnel Tunnel interfaces are Tunnel interfaces are Configured by

Interfac logical interfaces that automatically following the
e have Layer 3 features. created and procedure in 4.1.3.9
Devices on the two ends configured when Configuring a
of a tunnel use the tunnel you configure GRE Tunnel Interface
interfaces to send, on the web
receive, identify, and management page.
process tunnel packets. Configured by
Tunnel interfaces apply following the
to GRE and tunnel procedure in
features for IPv6 Configuring GRE
transition.
Virtual- Virtual-if interface: The Configured by Configured by

if interface is used by the following the following the
Interfac virtual system to procedure in 3.5 procedure in 3.6
e communicate with Deploying a Virtual Deploying a Virtual
another virtual system for System Using the System Using the
packet forwarding. A Web UI CLI
Virtual-if interface is a
logical interface, each of
which corresponds to one
virtual system.
l A Virtual-if interface
is automatically
generated and no
manual configuration
is required. You must
set an IP address for
the Virtual-if interface
to take effect. The
interface ID is the
same as the
automatically
generated VPN
instance ID.
l The Virtual-if
interface of the public
system is Virtual-if0.
NOTE
For details on virtual
systems, see Virtual
System.


Type
Web CLI
Virtual- Virtual-Template Virtual-Template Configured by

Templat interfaces apply to L2TP interfaces are following the
e for PPP negotiation and automatically procedure in
Interfac tunnel encapsulation. created and 4.1.3.10
e configured when Configuring a
you configure L2TP Virtual Template
on the web Interface
management page.
Configured by
following the
procedure in 9.3.5.2
Configuring an
LNS
Interface Views and Prompts

Command views and prompts of interfaces supported by the FW are shown in Table 4-2
Table 4-2 Interface Views and Prompts
Interface Command Command Prompt

Line View
Ethernet GigabitEthernet Run the interface [FW-

Interface of the 0/0/0 view gigabitEthernet 0/0/0 GigabitEthernet0/0/0]
SRU command in the system
view.
Eth-Trunk Eth-Trunk Run the interface eth- [FW-Eth-Trunk0]

interface interface view trunk 0 command in the
NOTE system view.
This type is
supported only
in the direct SR-
IOV mode.
Sub-interface Sub-interface Run the interface [FW-

view Gigabitethernet 1/0/0.1 gigabitethernet1/0/0.1]
command in the system
view.
VLAN interface VLAN interface Run the interface vlanif [FW-Vlanif1]

view 1 command in the system
view.
Loopback Loopback Run the interface [FW-LoopBack2]

interface interface view loopback 2 command in
the system view.

Interface Command Command Prompt

Line View
NULL interface NULL interface Run the interface null 0 [FW-NULL0]

view command in the system
view.
Tunnel Tunnel Run the interface tunnel [FW-Tunnel0]

interface interface view 0 command in the system
view.
Virtual interface Virtual interface Run the interface [FW-virtual-if0]

view virtual-if0 command in
the system view.
Virtual- Virtual template Run the interface [FW-Virtual-Template1]

Template view virtual-template 1
interface command in the system
view.
4.1.1.2 IP Addresses
This section describes the concepts and features related to IPv4 addresses and IPv6 addresses.
IPv4 Addresses
An IPv4 address consists of four binary octets separated by dots. Each octet can be expressed
in a decimal number. For example, 10.0.0.1 is an IPv4 address.
l IPv4 address classes
An IPv4 address consists of the following fields:
– Network ID field: distinguishes a networks from each other. The network ID is
called a class field, and network ID bits are called class bits.
– Host ID field: identifies a host on a network.
IPv4 addresses have five classes to facilitate address management and networking.
Figure 4-1 shows classes of IPv4 addresses.
Figure 4-1 IPv4 address classes

0 7 15 23 31
A 0 Net-id Host-id
B 10 Net-id Host-id
C 110 Net-id Host-id
D 1110 Multicast-address
E 11110 Reserved

Most IPv4 addresses in use belong to class A, B, or C. Class D addresses are multicast
addresses. Class E addresses are reserved. For more information, see RFC 1166 "Internet
Numbers."
Some IPv4 addresses are reserved for special use. Table 4-3 lists the range of each class
of IPv4 addresses.
Table 4-3 IPv4 address classes and ranges

Netw Address Available Description
ork Range IPv4
Network
Range
Class 0.0.0.0 to 1.0.0.0 to Special class A IPv4 addresses are as

A 127.255.255.25 126.255.255. follows:
5 0 l IPv4 address with a host ID that is all
0s: a network address used for routing.
l IPv4 address with a host ID that is all
1s: a broadcast address used to send
packets to all hosts on a network.
l 0.0.0.0: an ineffective destination
address only used by a FW to send a
Dynamic Host Configuration Protocol
(DHCP) Discovery request.
l 127.0.0.0.0 to 127.255.255.255:
reserved for loopback tests. A FW
sends a packet with an address within
this range to the FW itself and
processes the packet without
forwarding it.
Class 128.0.0.0 to 128.0.0.0 to Special class B IPv4 addresses are as

B 191.255.255.25 191.255.255. follows:
Class 192.0.0.0 to 192.0.0.0 to Special class C IPv4 addresses are as

C 223.255.255.25 223.255.255. follows:
Class 224.0.0.0 to None Class D IPv4 addresses are multicast

D 239.255.255.25 addresses.
5

Netw Address Available Description

ork Range IPv4
Network
Range
Class 240.0.0.0 to None Class E IPv4 addresses are reserved for

E 255.255.255.25 future use. 255.255.255.255 is a LAN
5 broadcast address.
l Special IPv4 addresses

Some special IPv4 addresses exist in real-world situations. Table 4-4 lists special IPv4
addresses.
Table 4-4 Special IPv4 addresses
Net Subnet Host Used as Used as a Description

ID ID ID a Source Destinatio
Address n Address
All 0s - 0 Yes No Used by all hosts on a

network.
All 0s - host-id Yes No Used by specified hosts

on a network.
127 - Any Yes Yes Used as loopback

value addresses.
All 1s - All 1s No Yes Used to broadcast

packets but not to
forward them.
net-id - All 1s No Yes Used to broadcast

packets to networks with
specified net IDs.
net-id subnet- All 1s No Yes Used to broadcast

id packets to subnets with
specified net and subnet
IDs.
net-id All 1s All 1s No Yes Used to broadcast

packets to all subnets
with specified net IDs.
NOTE
net-id and subnet-id are non-0 values.

l Private IPv4 addresses
To help alleviate the problem of exhausting IPv4 addresses, private networks and their
hosts, not public networks, are assigned private IPv4 addresses. As defined in RFC 1918,

the Internet Assigned Numbers Authority (IANA) has reserved three IPv4 address blocks
for private networks.
Table 4-5 lists private network IPv4 addresses.
Table 4-5 Private IPv4 addresses

Network IPv4 Address Range
Class A 10.0.0.0 to 10.255.255.255
Class B 172.16.0.0 to 172.31.255.255
Class C 192.168.0.0 to 192.168.255.255
IPv4 Address Assignment

You can use one of the following methods to assign IPv4 addresses to interfaces:
l Static IP
Specify IPv4 addresses for Layer 3 Ethernet interfaces and their subinterfaces, VLAN
interfaces, Eth-Trunk interfaces, and loopback interfaces.
To defend against IP address spoofing, you need to configure the IP-MAC binding on the
FW.
l DHCP
Configure DHCP to automatically obtain IPv4 addresses for Layer 3 Ethernet interfaces
and their subinterfaces, VLAN interfaces, and Eth-Trunk interfaces.
l PPPoE
Configure PPPoE to perform PPP negotiation to obtain IPv4 addresses for Layer 3
Ethernet interfaces and their subinterfaces, VLAN interfaces, and Eth-Trunk interfaces.
l Unnumbered IPv4 address mechanism
Use IP addresses of other interfaces as the IP addresses of tunnel and VT interfaces.
IPv6 Addresses
Internet Protocol Version 6 (IPv6), also called IP Next Generation (IPng), is a set of
specifications designed by the Internet Engineering Task Force (IETF).
IPv6 is a second-generation network protocol and an upgraded version of IPv4. Different
from IPv4, IPv6 extends an address to 128 bits long.
l IPv6 address formats
IPv6 addresses are expressed in either of the following formats:
– X:X:X:X:X:X:X:X
An IPv6 address is divided into eight groups, separated by colons. Each group has
16 bits. Each 16–bit group is represented by four hexadecimal digits, including 0 to
9 and A to F. For example, 2031:0000:130F:0000:0000:09C0:876A:130B is an
IPv6 address.
For convenience, all 0s in a group are displayed as a single 0. The example address
can be written as 2031:0:130F:0:0:9C0:876A:130B.

Two or more consecutive groups of 0s can be replaced with an empty group using a
pair of colons (::), which helps minimize the IPv6 address length. The example
address can also be written as 2031:0:130F::9C0:876A:130B.
NOTE
An IPv6 address can only contain a single pair of colons (::). If an IPv6 address contains
more than one pair of colons, a FW cannot restore the compressed address to the original
128-bit address because it cannot identify the number of zeros in the IPv6 address.
– X:X:X:X:X:X:d.d.d.d
Each "X" is 16 bits long and consists of four hexadecimal digits. Each "d" is 8 bits
long and is presented by a decimal number. "d.d.d.d" is an IPv4 address. The
following addresses are expressed in this format:
n 0:0:0:0:0:0:IPv4-address: an IPv4-compatible IPv6 address. The most
significant 96 bits of 0s precede a 32-bits IPv4 address. The IPv4 address must
be reachable on an IPv4 network and can only be a unicast address, but not a
multicast address, a broadcast address, a loopback address, or an unspecified
address (0.0.0.0, for example).
An IPv4-compatible IPv6 address is used to configure an IPv6 over IPv4
tunnel.
n 0:0:0:0:0:FFFF:IPv4-address: IPv4-mapped IPv6 address that is mapped to
an IPv4 address of an IPv4 node.
An IPv6 address is divided into two parts:
– Network prefix: equivalent to the network ID of an IPv4 address.
– Interface ID: equivalent to the host ID in an IPv4 address. The interface ID length is
as follows:
Interface ID length = 128 bits – n bits, where n is the length of the network ID
Figure 4-2 illustrates the structure of IPv6 address
2001:A304:6101:1::E0:F726:4E58 /64.
Figure 4-2 IPv6 address 2001:A304:6101:1::E0:F726:4E58 /64
Network Prefix Interface Identifier
64 bits 64 bits
2001:A304:6101:0001 0000:00E0:F726:4E58
l IPv6 address classification

IPv6 addresses are classified into unicast, anycast, and multicast addresses.
– Unicast address: uniquely identifies an interface. An IPv6 unicast address is similar
to an IPv4 unicast address. Packets bound for a unicast address are transmitted to an
interface uniquely identified by the unicast address.
Unicast addresses are classified into the following types:
n Link-local IPv6 unicast addresses
n Site-local IPv6 unicast addresses

n Loopback address
n Unspecified address
n Global unicast address
Table 4-6 lists these five types of addresses.
– Anycast address: identifies a group of interfaces on different nodes. Packets bound
for an anycast address reach the interface that is nearest to the source node among
interfaces in the interface group identified by the anycast address. A routing
protocol determines the shortest path.
NOTE
A FW currently does not support anycast addresses.

– Multicast address: identifies a group of interfaces on different nodes. A multicast
IPv6 address is similar to an IPv4 multicast address. Packets bound for a specified
multicast address reach all interfaces identified by the multicast address.
Although no IPv6 broadcast addresses exist, IPv6 multicast addresses provide
broadcast address functions.
l Unicast address types
A unicast address is used for one-to-one transmission. Similar to a unicast IPv4 address,
a unicast IPv6 address only identifies a single interface. Table 4-6 lists types of IPv6
unicast addresses.
Table 4-6 IPv6 unicast addresses

Type Binary Prefix IPv6 Prefix Remarks
Notation
Link-local IPv6 1111111010 FE80::/10 Used by a neighbor

unicast address discovery protocol or by
nodes on a local link to
perform stateless address
autoconfiguration. Packets
with a link-local IPv6
unicast address as a source
or destination address are
forwarded only on a local
link. A link-local IPv6
unicast address can be
automatically configured
on any interface using a
link-local prefix FE80::/10
(1111 1110 10 in binary)
and an EUI-64 interface ID.
Site-local IPv6 1111111011 FEC0::/10 Defined in RFC 4291 and

unicast address used as a global unicast
address.

Type Binary Prefix IPv6 Prefix Remarks

Notation
Loopback address 00...1 (128 bits) ::1/128 Functions similarly to IPv4

loopback address 127.0.0.1.
A node sends an IPv6
packet with the loopback
address to itself. An IPv6
loopback address is not
allocated to any interface.
Site-local unicast addresses
can be global unicast
addresses, unless otherwise
specified.
Unspecified 00...0 (128 bits) ::/128 Used in the Source Address

address field of an IPv6 packet sent
by an initializing host
before the host obtains an
address. a Neighbor
Solicitation (NS) packet
carries an unspecified
unicast address in the
Source Address field to
perform Duplicate Address
Detection (DAD). An
unspecified address cannot
be allocated to any host or
used as a destination
address.
Global unicast Others - Equivalent to an IPv4

address public address. Network
service providers use global
unicast addresses to
aggregate links. The
structure of a global unicast
address enables route prefix
aggregation, which
maximizes the number of
global routing entries. A
global unicast address
consists of a 48-bit routing
prefix that is managed by
an operator, a 16-bit subnet
ID that is managed by a
local site, and a 64-bit
interface ID.
l Interface ID in EUI-64 format

A 64-bit interface ID in an IPv6 address identifies a unique interface on a link. The

interface ID is derived from a 48–bit MAC address. The process for converting a MAC
address into an EUI-64 interface ID is as follows:
a. The hexadecimal number FFFE (1111 1111 1111 1110 in binary) is inserted in the
middle of a MAC address.
b. The U/L bit (the most significant seventh bit) is set to 1.
c. An EUI-64 interface ID is obtained.
Figure 4-3 shows the process for converting a MAC address to an EUI-64 interface ID.
Figure 4-3 Converting a MAC address to an EUI-64 interface ID
MAC: 0012-3400-ABCD
Binary： 0000000000010010 0011010000000000 1010101111001101
Insert FFFE：0000000000010010 0011010011111111 1111111000000000 1010101111001101
Set U/L bit: 0000001000010010 0011010011111111 1111111000000000 1010101111001101
EUI-64: 0212:34FF:FE00:ABCD
IPv6 Address Assignment

You can use one of the following methods to assign IPv4 addresses to interfaces:
l Static IP
Specify IPv6 addresses for Layer 3 Ethernet interfaces and their subinterfaces, VLAN
interfaces, Eth-Trunk interfaces, and loopback interfaces.
l DHCP
Configure DHCP to automatically assign IPv6 addresses for Layer 3 Ethernet interfaces
and their subinterfaces, VLAN interfaces, and Eth-Trunk interfaces.
l PPPoE
Configure PPPoE to perform PPP negotiation to assign IPv6 addresses to Layer 3
Ethernet interfaces and their subinterfaces, VLAN interfaces, and Eth-Trunk interfaces.
l Neighbor Discovery (ND) Router Advertisement (RA)
Configure stateless address autoconfiguration to enable interfaces to obtain IPv6 prefixes
from RA messages. The interfaces then use IPv6 prefixes and local interface IDs to form
EUI-64 IPv6 addresses.
The interfaces can be Layer 3 Ethernet interfaces or their subinterfaces, VLAN
interfaces, or Eth-Trunk interfaces.

4.1.2 Interface Configuration Using the Web UI

This section describes how to configure interfaces on web pages.
4.1.2.1 Configuring a Layer 3 Ethernet Interface

This section describes how to configure a Layer 3 Ethernet interface. A Layer 3 Ethernet
interface supports the routing functions and uses routes to forward packets.
Context
A Layer 3 Ethernet interface uses an IPv4 address to connect to an IPv4 network or an IPv6
address to connect to an IPv6 network.
Procedure
Step 1 Choose Network > Interface.
Step 2 Click in the same line as the interface to be configured.
Step 3 Set the following Ethernet interface parameters.

Interface Name Interface type and number.

The parameter cannot be modified.
Alias Another interface name specified by an administrator.

An alias name appears in parentheses next to an interface name
but does not appear in logs.
Virtual System Name of a virtual system for an interface.

The virtual system must exist on the device.
This parameter can only be set when Mode is set to Route.
Zone Security zone to which an interface is to be assigned.

You can directly add an interface to an existing security zone.
If the desired security zone does not exist, create one and add
the interface to the created security zone..
Mode Working mode:

l Route: The interface works at Layer 3. Route is selected in
this example.
l Switch: The interface works at Layer 2.
IPv4

Connection Type Method used by the interface to obtain an IPv4 address in

routing mode.
Perform one of the following steps to set a connection type:
l Static IP: specifies an IPv4 address for the interface. For
information about static IP address parameters, see Table
4-7.
l DHCP: allows the interface to run DHCP to automatically
obtain an IPv4 address.
l PPPoE: allows the interface to obtain an IPv4 address
through PPP negotiation. For PPPoE parameters, see Table
4-8.
Multi-egress options After you select Multi-egress options, the interface will
function as an intelligent uplink selection member interface.
For details on intelligent uplink selection, see Intelligent
Uplink Selection.
Carrier Select the name of the ISP directly connected to the interface.
Selecting the ISP of the interface equals to binding an interface
to an ISP interface group.
Default Route After you select this option, the FW will generate a default
route in its routing table.
A default route is a special static route. When the destination
address of a data packet does not match any routing table of
the FW, the FW will use the default route to forward the data
packet. Both the destination network address and the subnet
mask of the default route are 0.0.0.0.
If the interface serves as an intranet interface and has the sticky
load balancing function enabled, the default route must be
canceled. Otherwise, the interface cannot access extranets.
Carrier Route After you enable the ISP route function, the FW will generate
static routes in a batch to the ISP network. In the generated
static routes, the destination is an IP address in the ISP address
file, and the next hop is the gateway address specified on the
outbound interface. These static routes are called ISP routes.
They have the same priority as common static routes, and the
default priority is 60.
Choose Network > Router > Routing Table. You can view
the generated ISP route entries.

Sticky load balancing In the multi-ISP load balancing NAT server scenario, the FW
looks up the routing table for an outgoing interface to send the
return traffic from a server. As a result, the return traffic from
the server may take a path on ISP2, although the request to the
server takes a link on ISP1. The inconsistent forward and
return paths may slow down or even interrupt services. To
resolve this issue, configure the sticky load balancing function
on the incoming interface of ISP1.
The FW uses the incoming interface of the forward packets as
the outgoing interface of return packets instead of looking up
the routing table.
NOTE
If equal-cost multipath (ECMP) routes are configured, the sticky load
balancing function is enabled by default. Otherwise, configure the
sticky load balancing function.
Health Check Apply the health check to the interface.
IPv6
IPv6 Enable the IPv6 capability on the specified interface.

Enabling IPv6 is a prerequisite of using IPv6 functions.
Choose Dashboard > System Information and enable IPv6
globally to allow the FW to forward IPv6 packets.
Connection Type Method used by a VLAN interface to obtain an IPv4 address:

l Static IP: manually specifies an IPv6 address for the
VLAN interface. For static IP address parameter
descriptions, see Table 4-9.
l PPPoE: uses PPP negotiation to obtain an IPv6 address.
For PPPoE parameter descriptions, see Table 4-10.
l ND-RA: uses ND-RA to obtain an IPv6 address.
Static Neighbor Static neighbor address for a VLAN interface.

This setting allows a neighbor relationship to be established
and enables a device to resolve the neighbor IPv6 address into
a data link layer address.
Interface Bandwidth
Upstream Bandwidth Maximum bandwidth for upstream traffic on the interface.
Downstream Bandwidth Maximum bandwidth for downstream traffic on the interface.
Overload Protection Bandwidth usage of the link.

Threshold After you select Multi-egress options, you can set overload
protection thresholds for the inbound and outbound bandwidths
of the interface. If an interface is overloaded, the interface no
longer participate in intelligent uplink selection.
Management Access

Management Access This function allows an administrator to access an interface

using HTTP, HTTPS, Ping, SSH, Telnet, SNMP, and
NETCONF before managing a device. Interface access control
takes precedence over security policies. This means that an
administrator can use an access control-enabled interface to
manage a device even if no security policy is configured for
communication between the zone of the interface and a local
zone.
Select one of the following parameters:
l HTTP: allows an administrator to use the web browser
(HTTP) to access a device. If HTTP is not selected, the
interface discards HTTP packets after receiving them. This
parameter takes effect only after the HTTP service is
enabled.
l HTTPS: allows an administrator to use the web browser
(HTTPS) to access a device. If HTTPS is not selected, the
interface discards HTTPS packets after receiving them.
This parameter takes effect only after the HTTPS service is
enabled.
l Ping: allows a VLAN interface to respond to ping requests.
A ping checks interface connectivity. If Ping is not
selected, the ping function is disabled.
l SSH: allows an administrator to use SSH to access a
device. If SSH is not selected, the interface discards SSH
packets after receiving them.
l Telnet: allows an administrator to use Telnet to access a
device through a VLAN interface. If Telnet is not selected,
the interface discards them after receiving them.
l SNMP: allows administrators to use an SNMP NMS to
access a device. If SNMP is not selected, the interface
discards SNMP packets after receiving them.
l NETCONF: allows administrators to use an NETCONF
NMS to access a device. If NETCONF is not selected, the
interface discards NETCONF packets after receiving them.
By default, the management interface (GE0/0/0) allows HTTP,
HTTPS, Ping access to a FW, and a non-management interface
denies HTTP, HTTPS, ping, SSH, Telnet, SNMP, and
NETCONF access to a FW.
Advanced

Negotiation If you deselect this parameter, the interface is disabled from

working in auto-negotiation mode.
Disable the interface from working in auto-negotiation mode
before you configure the interface rate and duplex mode.
This configuration takes effect on the Ethernet electrical
interface.
Speed Transmission rate of the Ethernet interface:

l 10M: 10 Mbit/s
l 100M: 100 Mbit/s
l 1000M: 1000 Mbit/s
The transmission rate of an Ethernet interface must be the
same as that on the peer end.
Duplex Working mode of the Ethernet interface:

l Half: enables the interface to work in half-duplex mode. An
interface works in half-duplex mode can only send or
receive data packets at the same time.
l Full: enables the interface to work in full-duplex mode. An
interface works in full-duplex mode can send and receive
data packets at the same time.
The working mode of an Ethernet interface must be the same
as that on the peer end.
This parameter is required only when Speed is set to 10M or
100M.
MTU Maximum transmission unit of the interface. After the MTU of

an interface is modified, you need to restart the interface to
validate the MTU.
Table 4-7 Static IPv4 address parameters

IP Address IPv4 address of an interface.

The value must be different from IPv4 addresses of other
interfaces on the same device or other devices on the same
network.
Default Gateway IP address of the default gateway of an interface.

The default gateway must be on the same network segment as
the IPv4 address of the interface.
This setting allows the device to generate a default IPv4 route,
in which the current interface functions as an outbound
interface, and the default gateway functions as a next hop.

Preferred DNS server IP address of the preferred DNS server.

The configurations completed here will be automatically
synchronized to DNS Server List in Network > DNS > DNS.
Alternate DNS server IP address of the alternate DNS server.

Table 4-8 IPv4 PPPoE parameters

User Name User name for PPPoE dial-up.

The user name is provided by an ISP.
Password Password for PPPoE dial-up.

The password is provided by an ISP.
Online Mode PPPoE dial-up mode:

l Always Online: A device automatically attempts to dial up
to a peer end once a physical link connected to the peer end
is Up. If the dial-up connection attempt fails, the device
automatically re-attempts to dial up at specified intervals.
Automatic dial-up applies when the traffic volume and
online duration are not restricted, such as with the yearly-
payment service.
l Automatic disconnection after an idle period: A device
sets up a link only when there is data to be transmitted. If
an established PPPoE link has no traffic to transmit and the
specific link idle period elapses, the device disconnects the
PPPoE link. This dial-up mode applies when the traffic
volume and online duration are set, such as with the
payment-by-traffic service. The payment-by-traffic service
allows a specified amount of traffic to be transmitted within
a specified period.
If you select Automatic disconnection after an idle
period, you must also specify a link idle period.
Obtain an IP Address Obtain an IPv4 address that a PPPoE server assigns after
Automatically negotiating with a PPPoE client on a PPP link. The IPv4
address to be assigned must be specified on the PPPoE server.
Use the Following IP Set an IPv4 address statically. This method requires the input
Address of an IPv4 address in IP Address. The IPv4 address must be
one that a PPPoE server can assign.

IPv6 Address IPv6 address of a VLAN interface.

The IPv6 address must be unique on a network.
Advertising RA Enable a device to periodically advertise RA messages, which

Messages contain the prefix option and flag bits, to announce the
existence of the device.



payment service.
a specified period.
Step 4 Click OK.
----End
Follow-up Procedure
l Check the interface status.

b. Verify that the physical, IPv4, and IPv6 statuses of the VLAN interface are Up.
l Enable or disable the interface.
b. Perform either of the following operations as needed:
n To enable the interface, select the Enable check box of the interface.
n To disable the interface, clear the Enable check box of the interface.

This section describes how to configure a Layer 2 Ethernet interface that forwards Layer 2
frames.
Context
Ensure that you have performed the following operations:
l Select an Ethernet interface and switch it to Layer 2 mode.
l Assign the interface to a specific VLAN. For more information about VLANs, see 4.11
VLAN.
l Configure interface parameters, such as a duplex mode and a transmission rate.
NOTICE
If the interfaces work at Layer 2 and IPv6 needs to be processed on FW, you need to choose
Dashboard > System Information to enable the global IPv6 function.
Procedure
Step 2 Click for the interface.
Step 3 Set the following Ethernet interface parameters.

Interface Name Interface type and number.

The parameter cannot be modified.
Alias Another name for an interface.

The alias is not part of the interface name. A configured alias
appears in the (alias) format by the side of the interface name,
but does not appear in logs.
Zone Security zone, to which an interface is to be assigned.

You can directly add an interface to an existing security zone.
If the desired security zone does not exist, create one and
assign the interface to it.

Mode Layer at which the interface works when the interface works at
Layer 2:
l Select Switch to enable the interface to work at Layer 2.
l Select Interface Pair to enable the interface work as a
member of an interface pair.
When a Layer 3 Ethernet interface is configured to work in
Layer 2 mode, the device automatically clears specific
configurations, such as, DHCP, DDNS, androute
configurations of the interface and retains specific
configurations, such as HRP heartbeat interface configurations
of the interface. If the interface is specified as a heartbeat
interface, the interface cannot be configured to work in Layer 2
mode. Therefore, before you configure a Layer 3 Ethernet
interface to work in Layer 2 mode, ensure that the interface has
no configuration.
Connection Type Link type of a Layer 2 Ethernet interface:

l Access: Access interfaces belong to a single VLAN and
send and receive packets within this VLAN. These
interfaces are connected to PCs.
NOTE
When the link type of a Layer 2 Ethernet interface is Access, the
virtual system to which the VLAN of the interface belongs and the
virtual system to which the configured security zones belong are
the same one.
l Trunk: Trunk interfaces belong to multiple VLANs and
send and receive packets between these VLANs. These
interfaces are connected to devices.
l Hybrid: Hybrid interfaces belong to multiple VLANs and
send and receive packets in these VLANs. These interfaces
can be connected to both PCs and devices.
A hybrid interface sends untagged packets of multiple VLANs,
whereas a trunk interface sends untagged packets only from the
default VLAN.
Access VLAN ID ID of a VLAN, to which an access interface belongs. This

parameter is set only when Connection Type is set to Access.
Trunk VLAN ID ID of a VLAN, to which a trunk interface belongs. This

parameter is set only when Connection Type is set to Trunk.
A Trunk interface joins multiple VLANs and connects to a
network device. To allow all packets from one or more VLANs
to pass through a trunk interface, specify VLAN IDs in Trunk
VLAN ID.
Default VLAN ID Default VLAN ID of a trunk interface. This parameter is set

only when Connection Type is set to Trunk.

Hybrid VLAN ID (With ID of a VLAN, to which a hybrid interface belongs. A hybrid

VLAN Tag) interface sends tagged frames with the specified VLAN ID.
This parameter is set only when Connection Type is set to
Hybrid.
Hybrid VLAN ID ID of a VLAN, to which a hybrid interface belongs. A hybrid

(Without VLAN Tag) sends untagged frames with the specified VLAN ID. This
parameter is set only when Connection Type is set to Hybrid.
Default VLAN ID Default VLAN ID of a hybrid interface. This parameter is set

only when Connection Type is set to Hybrid.
Interface Bandwidth
Advanced
Negotiation If you deselect this parameter, the interface is disabled from

working in auto-negotiation mode.
Disable the interface from working in auto-negotiation mode
before you configure the interface rate and duplex mode.
This configuration takes effect on the Ethernet electrical
interface.
Speed Transmission rate of a Layer 2 Ethernet interface:

l 10M: 10 Mbit/s
l 100M: 100 Mbit/s
l 1000M: 1000 Mbit/s
The transmission rate of the Layer 2 Ethernet interface must be
the same as that on the peer end.
Duplex Duplex mode of the Layer 2 Ethernet interface:

l Half: enables the interface to only send or receive data
packets at a time.
l Full: enables the interface to send and receive data packets
simultaneously.
An Ethernet interface must work in the same mode as its peer
interface.
This parameter is required only when Speed is set to 10M or
100M.
Step 4 Click OK.
----End

Follow-up Procedure
b. Check the physical status of the interface.
n To enable the interface, select the Enable check box.
n To disable the interface, clear the Enable check box.
4.1.2.3 Configuring a Layer 3 Ethernet Subinterface

This section describes how to configure a Layer 3 Ethernet subinterface.
Context
Subinterfaces are logical or virtual interfaces created on a physical interface. Subinterfaces
share the physical parameters of the physical interface on which they are created. However,
subinterfaces have their own data link layer and network layer parameters. A subinterface
status change does not affect the main interface status, whereas a main interface status change
affects the subinterface status. Subinterfaces work properly only when their main interface is
in the Up state.
Subinterfaces can be created on Layer 3 Ethernet and Eth-Trunk interfaces. To distinguish

VLAN packets on a Layer 3 Ethernet interface or an Eth-Trunk interface, configure
subinterfaces with different VLAN IDs. Each subinterface with a specific VLAN ID forwards
packets carrying the VLAN ID, which provides configuration flexibility.
Procedure
Step 2 Click Add.
Step 3 Set the following subinterface parameters.
Interface Name Alias name for a subinterface.
Type Type of a subinterface to be created.

When creating a subinterface, set this parameter to
Subinterface.
Primary Interface Type and number of a interface to which the new subinterface
belongs.
Virtual System Name of a virtual system for a subinterface.


Zone Security zone to which a subinterface is to be added.

You can directly add a subinterface to an existing security
zone. However, if the desired security zone does not exist,
create one and then add the interface to it. For details, see 4.3
Security Zones.
Mode Subinterface working mode:

l Route: The interface works at Layer 3. In this example,
Route is selected.
l Switch: The interface works at Layer 2.
VLAN Tag ID of a VLAN to which a subinterface belongs. Traffic on

subinterfaces of a physical interface is distinguished by
VLANs.
IPv4
Connection Type Method for a subinterface to obtain an IPv4 address:

l Static IP: allows an administrator to specify an IPv4
address for the interface. For static IP address parameter
l DHCP: uses DHCP to automatically obtain an IPv4
address.
For details on intelligent uplink selection, see 6 Intelligent
Uplink Selection.

The FW uses the incoming subinterface of the forward packets
as the outgoing subinterface of return packets instead of
looking up the routing table.
NOTE
IPv6
IPv6 Enable the IPv6 capability.

Enabling the IPv6 capability is the prerequisite for using IPv6
functions. Choose Dashboard > System Information and
enable IPv6 globally to allow the FW to forward IPv6 packets.
Connection Type NOTE

Only the supports to configure this parameter.
Method for a subinterface to obtain an IPv4 address:
interface. For static IP address parameter descriptions, see
Table 4-13.
Static Neighbor Static neighbor address for a subinterface.

Interface Bandwidth


Management Access


zone.
enabled.
enabled.


IP Address IPv4 address of a subinterface.

Default Gateway IP address of the default gateway of a subinterface.

the IPv4 address of the subinterface.
in which the current subinterface functions as an outbound
interface, and the default gateway functions as a next hop.







payment service.
a specified period.
Use the Following IP Set an IPv4 address statically. This method requires the input
Address of a fixed IPv4 address in IP Address. The IPv4 address to be
entered is the one that a PPPoE server can assign.

IPv6 Address IPv6 address of a subinterface.

Default Gateway IP address of the default gateway of a subinterface.

in which the default gateway functions as a next hop.





payment service.
a specified period.
Step 4 Click OK.
If the operation is successful, the new subinterface is displayed among Layer 3 interfaces in
Interface List.
Repeat previous steps to create other subinterfaces.
----End
Follow-up Procedure
l Check the subinterface status.
b. Verify that the physical, IPv4, and IPv6 statuses of the subinterface are Up.


Context
in the Up state.
The device supports creating subinterfaces on Layer 2 Ethernet and Layer 2 Eth-Trunk
interfaces. Using a subinterface to terminate a VLAN allows for inter-VLAN forwarding.
Procedure
Step 2 Click Add.
Step 3 Set the following subinterface parameters.

Interface Name Alias name for a subinterface.
Type Type of a subinterface to be created.

When creating a subinterface, set this parameter to
Subinterface.
Primary Interface Type and number of a Layer 2 interface to which the new
subinterface belongs.
Virtual System Name of a virtual system for a subinterface.

Zone Security zone to which a subinterface is to be added.

You can directly add a subinterface to an existing security
zone. However, if the desired security zone does not exist,
create one and then add the interface to it.
Mode Layer at which the interface works and whether to enable

bypass detection when the interface works at Layer 2:
l Select Switch to enable the interface to work at Layer 2 and
disable bypass detection.
l Select Bypass to enable the interface to work at Layer 2
and enable bypass detection
After bypass detection is enabled, the device detects
packets received on this interface and then discards them.

VLAN Tag Specifies the VLAN tag (ID of the VLAN to which the new
subinterface belongs). Each subinterface receives or forwards
only packets that carry the specified VLAN tag.
Access VLAN ID Specifies the access VLAN ID. Subinterfaces must be added to
the same VLAN to communicate with each other.
Interface Bandwidth
Step 4 Click OK.

If the operation is successful, the new subinterface is displayed among Layer 2 interfaces in
Interface List.
Repeat previous steps to create other subinterfaces.
----End
Follow-up Procedure
l Check the subinterface status.
b. Verify that the physical, IPv4, and IPv6 statuses of the subinterface are Up.
4.1.2.5 Configuring a VLAN Interface

This section describes how to configure a virtual local area network (VLAN) interface.
VLAN interfaces transmit packets between VLANs.
Context
A LAN can be divided into logical broadcast domains. A broadcast domain is a VLAN.
Devices on a LAN logically belong to different VLANs, regardless of their physical locations.
When hosts on a VLAN need to communicate with a device at the network layer, you can
create a VLAN interface on the device. The VLAN interface functions as a Layer 3 interface
to provide Layer 3 functions, such as IPv4 or IPv6 address settings.
Procedure

Step 2 Click Add.
Step 3 Set the following VLAN parameters.

Interface Name Alias name for a VLAN interface.
Type Type of a VLAN interface to be created.

When you create a VLAN interface, set this parameter to
VLAN.
Virtual System Name of a virtual system for a VLAN interface.

The virtual system must exist.
Zone Security zone to which a VLAN interface is to be assigned.

You can directly assign a VLAN interface to an existing
security zone. If the desired security zone does not exist, create
one and assign the VLAN interface to it.
VLAN ID ID of a VLAN interface. If the specified VLAN does not exist,

the system automatically creates a VLAN when the VLAN
interface is created.
Interface Members Number of a Layer 2 interface to be assigned to a VLAN.

A Layer 2 interface can only be assigned to a single VLAN. If
a Layer 3 interface is used, switch its Mode from Route to
Switch before assigning the interface to a VLAN.
Select either of the following operations:
l In Available, select the desired interface and click to

add it to the VLAN.
l In Select, select the desired interface and click to

remove the interface from a VLAN.
IPv4

address for the VLAN interface. For static IP address
parameter descriptions, see Table 4-15.
address.
For details on intelligent uplink selection, see 6 Intelligent
Uplink Selection.

The FW uses the incoming subinterface of the forward packets
as the outgoing subinterface of return packets instead of
looking up the routing table.
NOTE
IPv6



VLAN interface. For static IP address parameter
Static Neighbor Static neighbor address for a VLAN interface.

Interface Bandwidth

Management Access


zone.
enabled.
enabled.



Default Gateway IPv4 address of the default gateway of an interface.

This setting allows the device to generate a default IPv4 route
with the current interface as an outbound interface and the
default gateway as a next hop.







payment service.
a specified period.
Use the Following IP Statically set an IPv4 address. This method requires the input
Address of an IPv4 address in IP Address. The IPv4 address must be
one that a PPPoE server can assign.
Obtain DNS Server Obtain a DNS address that a PPPoE server assigns after
Address Automatically negotiating with a PPPoE client on a PPP link.
Use the Following DNS Statically set a DNS address. This method requires the input of
Server Addresses DNS server addresses in Primary DNS Server and
Secondary DNS Server.

IPv6 Address IPv6 address of a VLAN interface.






payment service.
a specified period.
Step 4 Click OK.
If the operation is successful, the new interface is displayed in Interface List.
Repeat previous steps to create other VLAN interfaces.
----End
Follow-up Procedure
l Check the VLAN interface status.
b. Verify that the physical, IPv4, and IPv6 statuses of the VLAN interface are Up.

4.1.2.6 Configuring an Eth-Trunk Interface

This section describes how to configure an Eth-Trunk interface. An Eth-Trunk interface
balances traffic loads across devices, increases bandwidth, and improves traffic reliability.
Context
This configuration is supported only in the direct SR-IOV mode.
Many Ethernet interfaces are bundled into an Eth-Trunk interface. An Eth-Trunk interface
provides bandwidth that is equal to the total bandwidth of all its member interfaces. If a
member interface goes Down, traffic transmission over other member interfaces continues,
which increases link reliability.
An Eth-Trunk interface directs traffic to different links to balance traffic loads.
A physical interface can only be assigned to a single Eth-Trunk at a time. Before assigning the
physical interface to another Eth-Trunk, you must first remove it from the Eth-Trunk to which
it is currently attached.
Procedure
Step 2 Click Add.
Step 3 Set the following Eth-Trunk interface parameters.

Interface Name Alias name for an Eth-Trunk interface.
Type Type of an Eth-Trunk interface to be created.

Before creating an Eth-Trunk interface, set this parameter to
Aggregate Interface.
Virtual System Name of a virtual system for an Eth-Trunk interface.

The virtual system must exist.
This parameter is set only when Mode is set to Route.
Zone Security zone to which an Eth-Trunk interface is to be

assigned.
You can directly assign an Eth-Trunk interface to an existing
security zone. If the desired security zone does not exist, create
one and assign an Eth-Trunk interface to it.
Mode Layer at which the interface works when the interface works at
Layer 2:
l Select Route to enable the interface to work at Layer 3.
l Select Switch to enable the interface to work at Layer 2.
For the description of parameter Connection Type in
switching mode, see Table 4-23.
l Select Interface Pair to enable the interface work as a
member of an interface pair.

Interface Members Ethernet interface to be bundled to an Eth-Trunk interface.

A physical interface can only be added to a single Eth-Trunk
interface. If Mode is set to Route, the interface to be bundled
works at Layer 3. If Mode is set to Switch, the interface to be
bundled works at Layer 2.
Perform either of the following operations as needed:
l In Available, select a desired physical interface and click
to bundle it into the Eth-Trunk interface.
l In Select, select a desired physical interface and click to

remove the physical interface from the Eth-Trunk interface.
IPv4
Connection Type Method used by an Eth-Trunk interface to obtain an IPv4

address in routing mode.
address.
For PPPoE parameter descriptions, seeTable 4-20.
Uplink Selection.

The FW uses the incoming Eth-Trunk interface of the forward
packets as the outgoing Eth-Trunk interface of return packets
instead of looking up the routing table.
NOTE
IPv6

Connection Type Method used by an Eth-Trunk interface to obtain an IPv4

address:
Static Neighbor Static neighbor address for an Eth-Trunk interface.

Interface Bandwidth


Management Access


zone.
enabled.
enabled.
Advanced

Lower Limit of Up Links Lower limit of member interfaces in the Up state before an
Eth-Trunk interface goes Down. If the number of member links
in the Up state is smaller than the lower limit, the Eth-Trunk
interface goes Down, and all its member interfaces cannot
forward data. This prevents a small number of member links in
the Up state from discarding packets due to overload.
To ensure proper forwarding, configure the same lower limit
for an Eth-Trunk interface on both ends of a link.
MAC Address MAC address of an Eth-Trunk interface. If multiple Eth-Trunk

interfaces are created on a device, you can re-define a unique
MAC address for each interface to prevent MAC address
conflicts.
MTU Maximum transmission unit of an Eth-Trunk interface.

Increase the MTU to prevent packet loss or increase the
transmission speed if a great number of fragments are
generated.
After the MTU of an interface is modified, restart the interface
to make the MTU take effect.
Directly connected interfaces must have the same MTU.

IP Address IPv4 address of an Eth-Trunk interface.

Default Gateway IPv4 address of the default gateway of an Eth-Trunk interface.

This setting allows the device to generate a default IPv4 route
with the current interface as an outbound interface and the
default gateway as a next hop.







payment service.
a specified period.
Use the Following IP Statically set an IPv4 address. This method requires the input
Address of a fixed IPv4 address in IP Address. The IPv4 address must
be one that a PPPoE server can assign.
Obtain DNS Server Obtain a DNS address that a PPPoE server assigns after
Address Automatically negotiating with a PPPoE client on a PPP link.
Use the Following DNS Statically set a DNS address. This method requires the input of
Server Addresses DNS server addresses in Primary DNS Server and
Secondary DNS Server.

IPv6 Address IPv6 address of an interface.







payment service.
a specified period.

Table 4-23 Parameters of the switching mode
Connection Type Lnk type of an Eth-Trunk interface:

l Access: Access interfaces belong to a single VLAN and
send and receive packets within this VLAN. These
interfaces are connected to PCs.
l Trunk: Trunk interfaces belong to multiple VLANs and
send and receive packets between these VLANs. These
interfaces are connected to devices.
l Hybrid: Hybrid interfaces belong to multiple VLANs and
send and receive packets in these VLANs. These interfaces
can be connected to both PCs and devices.
A hybrid interface sends untagged packets of multiple VLANs,
whereas a trunk interface sends untagged packets only from the
default VLAN.
Access VLAN ID ID of a VLAN to which an Access interface belongs. This

parameter is set only when Connection Type is set to Access.
Trunk VLAN ID ID of a VLAN, to which a trunk interface belongs. This

parameter is set only when Connection Type is set to Trunk.
A Trunk interface joins multiple VLANs and connects to a
network device. To allow all packets from one or more VLANs
to pass through a trunk interface, specify VLAN IDs in Trunk
VLAN ID.
Default VLAN ID Default VLAN ID of a trunk interface. This parameter is set

only when Connection Type is set to Trunk.
Hybrid VLAN ID (With ID of the VLAN to which the hybrid interface belongs. Frames
VLAN Tag) on the VLAN are sent from this interface in Tagged mode. This
Hybrid VLAN ID ID of a VLAN, to which a hybrid interface belongs. Frames on

(Without VLAN Tag) the VLAN are sent from this interface in Untagged mode. This
Default VLAN ID Default VLAN ID of a hybrid interface. This parameter is set

only when Connection Type is set to Hybrid.
Step 4 Click OK.
If the operation is successful, the new Eth-Trunk interface is displayed in Interface List.
Repeat previous steps to create other Eth-Trunk interfaces.
----End
Follow-up Procedure
l Check interface status.


b. Verify that the physical, IPv4, and IPv6 statuses of the interface are Up.
n To enable the interface, select the Enable check box of the interface.
n To disable the interface, clear the Enable check box of the interface.
4.1.2.7 Configuring a Loopback Interface

This section describes how to configure a loopback interface. Once created, a loopback
interface remains in the Up state. Loopback interface characteristics are used to improve
reliability.
Context
This section describes how to configure a loopback interface. A loopback interface is a virtual
interface. The IP address of a loopback interface is specified as a source address for packets to
improve network reliability.
Procedure
Step 2 Click Add.
Step 3 Configure the following loopback interface parameters.
Interface Name Alias name for a loopback interface.
Type Type of an interface to be created.

When creating a loopback interface, set this parameter to
Loopback Interface.
Virtual System Name of a virtual system for an interface.

IPv4
Connection Type Method used by an interface to obtain an IPv4 address.

Only Static IP is available to manually set an IPv4 address and
subnet mask for the interface.

This value must be unique on a network.
IPv6

IPv6 Enable the IPv6 capability on the specified interface.

Enabling IPv6 is a prerequisite for using IPv6 functions.
Choose Dashboard > System Information and enable IPv6
globally to allow the FW to forward IPv6 packets.
Connection Type Method used by an interface to obtain an IPv6 address.

Only Static IP is available to manually set an IPv6 address and
subnet mask for the interface.
IPv6 Address IPv6 address of an interface.

This value must be unique on a network.
Step 4 Click OK.

If the operation is successful, the new loopback interface is displayed in Interface List.
Repeat previous steps to create other loopback interfaces.
----End
Follow-up Procedure
Check the interface status.
2. Verify that the physical, IPv4, and IPv6 statuses of the interface are Up.
4.1.2.8 Configuring the Tunnel Interface

Tunnel interfaces enable packet encapsulation and forwarding through tunnels.
Context
A tunnel interface is a logical interface for packet encapsulation. By default, tunnel interfaces
created through the Web use only IPSec, that is, supporting only IPSec tunnels. GRE is
another common encapsulation protocol. When configuring GRE through the Web, tunnel
interfaces are automatically created and configured. For details, see 9.4.3 Configuring GRE
Using the Web UI.
Procedure
Step 2 Click Add.
Step 3 Set tunnel interface parameters.

Interface Name Another name specified for the tunnel interface, facilitating
memorization and identification.

Type Type of the interface to be created.

Select Tunnel when you need to create a tunnel interface.
Zone Security zone to which the interface is to be assigned.

You can assign an interface to an existing security zone or
create a security zone and assign the interface to it.
IPv4
IP Address/Mask Ensure that the IP addresses of the tunnel interfaces at the two
ends of the IPSec tunnel are routable.
Uplink Selection.

The FW uses the incoming interface of the forward packets as
the outgoing interface of return packets instead of looking up
the routing table.
NOTE
Source IP Address for Source IP address of the quality detection packet.

Link Check NOTE
The quality detection source IP address and Tunnel interface IP address
must reside on the same subnet and must be available and routable IP
addresses. The quality detection source IP address must be permitted
by the IPSec ACL rules to enter the tunnels. Otherwise, the quality
detection result does not indicate the transmission quality of the IPSec
tunnels.
Interface Bandwidth

Management Access


zone.
enabled.
enabled.
Step 4 Click OK.
If the operation succeeds, Interface List displays the new tunnel interface.
Repeat the preceding steps to create other tunnel interfaces.
----End

Follow-up Procedure
b. Check the physical status of the interface.
l Disable or enable an interface.
b. Disable or enable an interface.
n Deselect the Enable check box corresponding to an interface to disable it.
n Select the Enable check box corresponding to an interface to enable it.
4.1.3 Interface Configuration Using the CLI

This section describes how to use the command line interface (CLI) to configure interfaces.

This section describes how to configure a Layer 3 Ethernet interface that supports the routing
and forwarding functions.
Basic Layer 3 Ethernet Interface Configuration

A Layer 3 Ethernet interface uses an IPv4 address to connect to an IPv4 network or an IPv6
address to connect to an IPv6 network.

system-view
Step 2 Display the specified interface view.
Step 3 Assign an IPv4 address to the interface.
ip address ip-address { mask | mask-length } [ sub ]
To assign the second and subsequent IPv4 addresses to the interface, configure the sub
parameter in the ip address command.
1. Enable the IPv6 capability on the interface.
ipv6 enable
By default, the IPv6 capability is disabled on the interface.
Before performing IPv6 configurations in the interface view, enable the IPv6 capability
in the interface view.
To allow the interface to forward IPv6 packets, run the ipv6 command in the system
view.
2. Perform either of the following operations to configure an IPv6 link-local address:
– To enable the system to automatically generate an IPv6 link-local address, run:
ipv6 address auto link-local

This is a recommended way to configure an IPv6 link-local address because the

link-local address is only used for protocol-based communication between link-
local nodes, regardless of communication between users.
If no IPv6 link-local address is specified for an interface, the device automatically
generates an IPv6 link-local address for the interface after an IPv6 global unicast
address is specified for the interface.
– To specify an IPv6 link-local address, run:
ipv6 address ipv6-address link-local
The prefix of an IPv6 link-local address is FE80::/10.
NOTE
Only a single link-local address can be configured on an interface. If you configure multiple link-local
addresses on the same interface, only the last configuration takes effect.
3. Assign a global unicast IPv6 address to the interface.
ipv6 address { ipv6-address | ipv6-address/prefix-length } [ eui-64 ]
An EUI-64 address supports the same function as a global unicast address. The
difference between the two addresses is as follows:
– Only the network bits need to be specified for the EUI-64 address, because the host
bits are transformed from the MAC addresses of the interface. The prefix length of
the network bits in an EUI-64 address must not be longer than 64 bits.
– A complete 128-bit address needs to be specified for the global unicast address.
The EUI-64 address and global unicast address can be configured simultaneously or
separately. However, IP addresses configured for the same interface cannot be on the
same network segment.
Step 5 Optional: Disable an interface from working in auto-negotiation mode.
undo negotiation auto
By default, an interface works in auto-negotiation mode. To set parameters duplex and speed
to adjust the duplex mode and rate of an interface, run the undo negotiation auto command
to disable the interface from working in auto-negotiation mode.
This command applies only to Ethernet electrical interfaces and Ethernet optical interfaces
that work in electrical interface mode.
Step 6 Optional: Specify a duplex mode.

duplex { full | half }
Step 7 Optional: Set a working rate.

speed { 10 | 100 | 1000 }
Step 8 Optional: Set the interface MTU.

l To set an IPv4 MTU for the interface, run:
mtu mtu

l To set an IPv6 MTU for the interface, run:

ipv6 mtu mtu
NOTE
If a packet is added with a non-fragment flag and the packet length exceeds the interface MTU, the FW
drops the packet. To ensure service continuity, you can run the clear ip df command to enable the
clearing function, delete non-fragment flags, and forward packets in fragments.
Step 9 Optional: Configure an interface description.

description interface-description
Step 10 Optional: Specify the alias for an interface.

alias alias
Step 11 Optional: Set the maximum bandwidth for upstream traffic on the interface.
bandwidth ingress bandwidth-number
Step 12 Optional: Set the maximum bandwidth for downstream traffic on the interface.
bandwidth engress bandwidth-number
Step 13 Optional: Enable access control on an interface.

By default, access control is enabled on interfaces.
Step 14 Optional: Allow or block HTTP, HTTPS, Ping, SSH, Telnet, SNMP, and NETCONF access
to the FW.
service-manage { http | https | ping | ssh | snmp | NETCONF | telnet } { permit | deny }
The service-manage command allows an administrator to manage a FW through a specified

interface even if no security policy is enforced for traffic between the Local zone and the
security zone to which the interface belongs.
By default, the management interface (GE0/0/0) allows HTTP, HTTPS, Ping access to a FW,
and a non-management interface denies HTTP, HTTPS, ping, SSH, Telnet, SNMP, and
Step 15 Optional: Restore the access control management function of an interface to the default
setting.
reset service-manage
After you run this command, the access control management function of the management
interface (GE0/0/0) is enabled, and the administrator is allowed to use HTTP, HTTPS, Ping to
access the device. For non-management interfaces, the access control management function is
enabled, but the administrator is not allowed to use HTTP, HTTPS, Ping, SSH, Telnet, SNMP,
and NETCONF to access the device.
Step 16 Optional: Set a gateway address for the interface.
gateway gateway-address
When you configure sticky load balancing, you need to set the gateway address, that is, to
specify the next-hop IP address of the outbound interface.
Step 17 Optional: Enable the sticky load balancing function.
redirect-reverse enable

In the multi-ISP load balancing NAT server scenario, the FW looks up the routing table for an
outgoing interface to send the return traffic from a server. As a result, the return traffic from
the server may take a path on ISP2, although the request to the server takes a link on ISP1.
The inconsistent forward and return paths may slow down or even interrupt services. To
resolve this issue, configure the sticky load balancing function on the incoming interface of
ISP1.
The FW uses the incoming interface of the forward packets as the outgoing interface of return
packets instead of looking up the routing table.
NOTE
If equal-cost multipath (ECMP) routes are configured, the sticky load balancing function is enabled by
default. Otherwise, configure the sticky load balancing function.
----End
Advanced Layer 3 Ethernet Interface Configuration

A Layer 3 Ethernet interface supports interface flapping control, and loopback.
l Interface flapping control
This function prevents interfaces from frequently alternating between Up and Down,
which helps devices and networks to operate stably.
The interface flapping control mechanism operates using the following parameters:
– Penalty value: a suppress penalty value. A suppression algorithm calculates this
value based on the interface status. The suppress penalty value increases each time
the interface status changes and decreases by half when the interface in a stable
state.
– Suppress: a suppress threshold. If the suppress penalty value reaches the suppress
threshold, the interface is suppressed.
– Reuse: a reuse threshold. If the suppress penalty value is less than or equal to the
reuse threshold, the interface is not suppressed.
– Ceiling: a maximum suppress penalty value. The suppress penalty value stops
increasing after it reaches the maximum suppress penalty value.
– Decay-ok: half-life time in seconds when an interface remains Up. A suppress
penalty value reduces by half after the specified half-life time elapses.
– Decay-ng: half-life time in seconds when an interface remains Down. A suppress
penalty value reduces by half after the specified half-life time elapses.
Note that the following formula applies:
Reuse < Suppress < Ceiling
Configure interface flapping control.
control-flap [ suppress reuse ceiling decay-ok decay-ng ]
By default, flapping control is disabled.
Run the reset control-flap command to clear existing flapping control statistics before
you collect statistics in a specified period.
l Ethernet interface loopback
Loopback helps you check whether an interface works properly.
Enable loopback.
loopback

When an interface works properly, disable the loopback. By default, the loopback is
disabled.

This section describes how to configure a Layer 2 Ethernet interface that forwards Layer 2
frames.
Basic Layer 2 Ethernet Interface Configuration

system-view
Step 3 Switch the Layer 3 Ethernet interface to Layer 2 mode.
portswitch
An Ethernet interface works at Layer 3 by default. To use the Layer 3 Ethernet interface as a
Layer 2 interface, switch the Ethernet interface to Layer 2 mode.
When a Layer 3 Ethernet interface is configured to work in Layer 2 mode, the device
automatically clears specific configurations, such as, DHCP, DDNS, and route configurations
of the interface and retains specific configurations, such as HRP heartbeat interface
configurations of the interface. If the interface is specified as a heartbeat interface, the
interface cannot be configured to work in Layer 2 mode. Therefore, before you configure a
Layer 3 Ethernet interface to work in Layer 2 mode, ensure that the interface has no
configuration.
To switch Layer 3 Ethernet interfaces to Layer 2 mode in a batch, run the portswitch batch
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the
system view.
By default, a Layer 2 Ethernet interface belongs to VLAN 1 and works as a hybrid port.
NOTICE
If the interfaces work at Layer 2 and IPv6 needs to be processed on FW, you need to run the
ipv6 command to enable the global IPv6 function.
Step 4 Optional: Enable the bypass detection function on the interface.

bypass-detection
After bypass detection is enabled, the device detects packets received on this interface and
then discards them.
Step 5 Optional: Disable an interface from working in auto-negotiation mode.
undo negotiation auto
By default, an interface works in auto-negotiation mode. To set parameters duplex and speed
to adjust the duplex mode and rate of an interface, run the undo negotiation auto command
to disable the interface from working in auto-negotiation mode.

Step 6 Optional: Specify a duplex mode.
duplex { full | half }
Step 7 Optional: Set a working rate.
speed { 10 | 100 | 1000 }
alias alias
----End
Advanced Layer 2 Ethernet Interface Configuration

A Layer 2 Ethernet interface supports loopback. For information about traffic suppression and
loopback, see Advanced Layer 3 Ethernet Interface Configuration.

Context
in the Up state.
Subinterfaces can be created on Layer 3 Ethernet and Eth-Trunk interfaces. To distinguish
VLAN packets on a Layer 3 Ethernet interface or an Eth-Trunk interface, configure
subinterfaces with different VLAN IDs. Each subinterface with a specific VLAN ID forwards
packets carrying the VLAN ID, which provides configuration flexibility.
Procedure

system-view
Step 2 Display the Ethernet subinterface view.

interface interface-type interface-number.subinterface-number
The subinterface-number parameter specifies the number of an Ethernet subinterface.
Step 3 Specify an encapsulation mode and a VLAN ID for the subinterface.

vlan-type dot1q vlan-id
By default, no encapsulation mode or VLAN ID is configured on a subinterface.
To ensure VLAN connectivity, set the same VLAN ID on two subinterfaces at two ends of a
link.


1. Enable the IPv6 capacity on the interface.
ipv6 enable
Before performing IPv6 configurations in the interface view, enable the IPv6 capability
in the interface view.
view.
– To enable the system to automatically generate an IPv6 link-local address, run:ipv6
address auto link-local
Allowing the system to automatically generate a link-local address is recommended.
This is because the link-local address is only used for protocol-based
communication between link-local nodes, regardless of communication between
users.
address of the interface is specified.
– To specify an IPv6 link-local address, run:ipv6 address ipv6-address link-local
NOTE
Only a single link-local address can be configured on an interface. If you repeatedly configure link-
local addresses, the last configuration takes effect.

alias alias
to the FW.
and a non-management interface denies HTTP, HTTPS, Ping, SSH, Telnet, SNMP, and
setting.

ISP1.
The FW uses the incoming subinterface of the forward packets as the outgoing subinterface of
return packets instead of looking up the routing table.
NOTE
----End

This section describes how to configure a Layer-2 Ethernet subinterface.
Context
in the Up state.
Procedure
Step 2 Run the interface interface-type interface-number command to access the interface view.
Step 3 Run the portswitch command to configure a Layer 3 Ethernet interface to work in Layer 2
mode.
Step 4 Run the quit command to return to the system view.
Step 5 Run the interface interface-type interface-number.subinterface-number command to create a

subinterface and access the subinterface view.
Step 6 Run the vlan-type dot1q vlan-id command to configure the encapsulation type for the
subinterface and associate a VLAN ID with the subinterface.
Step 7 Run the portswitch command to configure the subinterface as a Layer 2 subinterface.
Step 8 Run the port default vlan vlan-id command to add the Layer 2 subinterface to a specific
VLAN,

Step 11 Optional: Run the bypass-detection command to enable the bypass detection function on the
interface.
After bypass detection is enabled, the device detects packets received on this interface and
then discards them.
----End
4.1.3.5 Configuring a VLAN Interface

This section describes how to configure a VLAN interface for inter-VLAN communication.
Context
A LAN can be divided into several logical LANs. Each logical LAN is a broadcast domain,
which is called a VLAN. Devices on a LAN logically belong to different VLANs, regardless
of their physical locations. VLANs separate broadcast domains within a LAN from each
other.
When hosts on a VLAN need to communicate with a device at the network layer, you can
create a VLAN interface on the device. The VLAN interface functions as a Layer 3 interface
to provide Layer 3 functions, such as IPv4 or IPv6 address settings.
Procedure
system-view
portswitch
quit
Step 5 Create a VLAN and display the VLAN view.
vlan vlan-id
If a VLAN already exists, running this command directly displays the VLAN view.
Step 6 Assign specified interfaces to the VLAN.
port interface-type { interface-number1 [ to interface-number2 ] } &<1-10>
Only access interfaces can be added to a VLAN using this command.
quit
Step 8 Create a Vlanif interface for a specific VLAN and display the Vlanif interface view.
interface vlanif vlan-id

If a Vlanif interface already exists, running this command directly displays the Vlanif
interface view.
A VLAN must exist before a Vlanif interface is created for it.
1. Enable the IPv6 capability on the interface.
ipv6 enable
Enable the IPv6 capability in the interface view before performing IPv6 configurations in
the interface view.
view.
– To enable the system to automatically generate an IPv6 link-local address, run:ipv6
address auto link-local
Allowing the system to automatically generate a link-local address is recommended.
This is because the link-local address is only used for protocol-based
communication between link-local nodes, regardless of communication between
users.
address of the interface is specified.
– To specify an IPv6 link-local address, run:ipv6 address ipv6-address link-local
NOTE
Only a single link-local address can be configured on an interface. If you repeatedly configure link-
local addresses, the last configuration takes effect.

alias alias
to the FW.
and a non-management interface denies HTTP, HTTPS, Ping, SSH, Telnet, SNMP, and
setting.
ISP1.
The FW uses the incoming Vlanif interface of the forward packets as the outgoing Vlanif
interface of return packets instead of looking up the routing table.

NOTE
----End
4.1.3.6 Configuring an Eth-Trunk Interface

This section describes how to configure an Eth-Trunk interface, which can load-balance
traffic between devices, increase bandwidth, and improve link reliability.
4.1.3.6.1 Configuration Procedure

This section describes how to configure Layer 3 Eth-Trunk interfaces, Layer 2 Eth-Trunk
interfaces, Eth-Trunk sub-interfaces
This configuration is supported only in the direct SR-IOV mode.
Figure 4-4 shows the procedure for configuring Eth-Trunk interfaces.

Eth-Trunk interfaces mainly include Layer 3 Eth-Trunk interfaces, Layer 2 Eth-Trunk
interfaces, and Eth-Trunk sub-interfaces.
To use basic Eth-Trunk interface functions only, configure Layer 3 Eth-Trunk interfaces,
Layer 2 Eth-Trunk interfaces, or Eth-Trunk sub-interfaces and add Ethernet interfaces to
them.
The FW allows you to configure a lower threshold for the number of member links in Up
state of an Eth-Trunk link and load balancing among member interfaces of an Eth-Trunk
interface.

Figure 4-4 Flowchart for configuring Eth-Trunk interfaces
Start
Select one of the three types

of Eth-Trunk interfaces.
Configuring a Layer 3 Configuring a Layer 2 Configuring a Eth-Trunk

Eth-Trunk Interface Eth-Trunk Interface Sub-interface
Configuring a
Working Mode
Adding Physical
Interfaces to an
Eth-Trunk Interface
This option is required when

the Eth-Trunk interface works Configuring Static
in static LACP mode. LACP Parameters
Configuring the Lower

Limit of Up Member
Interface
Configuring a Load
Balancing Mode
End
Mandatory Optional
4.1.3.6.2 Configuring a Layer 3 Eth-Trunk Interface

To use an Eth-Trunk link to carry Layer 3 data packets, configure Layer 3 Eth-Trunk
interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface eth-trunk trunk-id
An Eth-Trunk interface is created, and the Eth-Trunk interface view is displayed.

Step 3 Configure an IP address for the Eth-Trunk interface.

l Configure an IPv4 address for the Eth-Trunk interface.
To configure an IPv4 address for the Eth-Trunk interface, run the ip address ip-address
{ mask | mask-length } [ sub ] command.
l Configure an IPv6 address for the Eth-Trunk interface.
Configure an IPv6 address for the Eth-Trunk interface based on actual situations:
– To configure an automatic link-local address for the interface, run the ipv6 address
auto link-local command.
– To configure a link-local address for the interface, run the ipv6 address ipv6-
address link-local command.
– To configure a global unicast address for the interface, run the ipv6 address { ipv6-
address | prefix-length } command.
– To configure an IPv6 address in the EUI-64 format for the interface, run the ipv6
address ipv6-address/prefix-length [ eui-64 ] command.

mac-address mac-address
A MAC address is configured for the Eth-Trunk interface.
If the FW has multiple Layer 3 Eth-Trunk interfaces directly connected to Layer 2 interfaces
of switches, change the MAC addresses of the Layer 3 Eth-Trunk interfaces to ensure that
return packets sent from the switches are forwarded to correct Layer 3 Eth-Trunk interfaces.
NOTE
The mac-address command can be used only on the Eth-Trunk interface that works in Layer 3 mode.
If an Eth-Trunk interface has a large number of Eth-Trunk sub-interfaces, changing the MAC address of
the Eth-Trunk interface causes the local device to send a large number of gratuitous ARP packets to the
peer device. If CPCAR is configured on the peer device, increase the bandwidth for transmitting
gratuitous ARP packets, which prevents gratuitous ARP packets from being discarded.
Step 5 Optional: Configure an MTU for the Eth-Trunk interface.

l Configure an IPv4 MTU for the Eth-Trunk sub-interface.
To configure an IPv4 MTU for the interface, run the mtu mtu command.
The MTU is expressed in bytes. The default value is 1500.
NOTICE
– The mtu mtu command cannot be used on Layer 2 Eth-Trunk interfaces.
– The same MTU must be set for two directly connected interfaces. To use the mtu
command to change the MTU of an interface, ensure that the MTUs on both ends are
the same. Otherwise, services may be interrupted.
– If you run the mtu command to change the MTU to be smaller than 1280 bytes for
the Eth-Trunk interface running IPv6, IPv6 cannot properly run on the interface.
When IPv6 runs on an Eth-Trunk interface, set the MTU to be greater than or equal to
1280 for the interface.

a. To enable IPv6 for the interface, run the ipv6 enable command
b. To configure an IPv6 MTU for the interface, run the ipv6 mtu mtu command.
----End
Follow-up Procedure
After configuring a Layer 3 Eth-Trunk interface, view the status of the Eth-Trunk, member
interface information, and forwarding table of the Eth-Trunk interface.
l Run the display interface eth-trunk [ trunk-id ] command to check the status of the
Eth-Trunk interface.
l Run the display trunkmembership eth-trunk trunk-id command to check the member
interfaces of the Eth-Trunk interface.
l Run the display trunkfwdtbl eth-trunk trunk-id [ slot slot-id ] command to check the
forwarding table of the Eth-Trunk interface.
Example
Run the display interface eth-trunk command. The command output shows information
about Eth-Trunk sub-interfaces, including IP addresses, MAC addresses, and hash algorithms.
<sysname> display interface Eth-Trunk 1
Eth-Trunk1 current state : UP
Line protocol current state : UP
Last line protocol up time : 2011-09-30 01:45:43 UTC+08:00
Description : Eth-Trunk1 Interface
Route Port,Hash arithmatic : According to flow,Maximal BW: 2G, Current BW: 2G,
The Maximum Transmit Unit is 1500
Internet Address is 100.1.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc09-9722
Physical is ETH_TRUNK
Last 300 seconds input rate 0 bytes/sec, 0 packets/sec
Last 300 seconds output rate 0 bytes/sec, 0 packets/sec
Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec
Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec
Input: 1 packets,3 bytes,
7 unicast,9 broadcast,8 multicasts
10 errors,5 drops,11 unknowprotocol
Output: 2 packets,4 bytes,
12 unicast,14 broadcast,13x multicasts
15 errors,6 drops
Input bandwidth utilization : 0.00%
Output bandwidth utilization : 0.00%
-----------------------------------------------------
PortName Status Weight
-----------------------------------------------------
GigabitEthernet1/0/1 UP 1
-----------------------------------------------------
The Number of Ports in Trunk : 2
The Number of UP Ports in Trunk : 2
Run the display trunkmembership eth-trunk command. The command output shows
information about the member interfaces of an Eth-Trunk interface, including the status and
working mode.
<sysname> display trunkmembership eth-trunk 0
Trunk ID: 0
used status: VALID
TYPE: ethernet
Working Mode : Normal
Working State: Normal

Number Of Ports in Trunk = 2

Number Of UP Ports in Trunk = 1
Operate status: up
Interface GigabitEthernet1/0/1, valid, operate up, weight=1

Interface GigabitEthernet1/0/2, valid, operate down, weight=1
Run the display trunkfwdtbl eth-trunk command. The command output shows the active
and standby Ethernet interface numbers in the forwarding table of an Eth-Trunk interface.
<sysname> display trunkfwdtbl eth-trunk 1
Show the Trunk Forwarding Table
Eth-Trunk1's forwarding table is:
MASTER SLAVE
4.1.3.6.3 Configuring a Layer 2 Eth-Trunk Interface

The Layer 2 attributes of an Eth-Trunk interface defines the link layer attributes of the
interface.
Context
To add an Eth-Trunk interface to a VLAN, configure Layer 2 functions for the Eth-Trunk
interface.
Layer 2 Eth-Trunk interfaces are mainly used in trunk interfaces in VLANs to increase the
bandwidth for communication between the VLANs of two devices.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run: portswitch The Eth-Trunk interface is switched from the Layer 3 mode to the Layer 2
mode.
By default, the Eth-Trunk interface works in Layer 3 mode.
After the Eth-Trunk is switched to the Layer 2 mode, the Layer 3 tag and functions of the Eth-
Trunk interface are displayed, and the Eth-Trunk interface uses a MAC address.

To add an Eth-Trunk interface to a VLAN, switch the Eth-Trunk interface from the Layer 3
mode to the Layer 2 mode. During the switching, only the shutdown, undo shutdown, and
description commands can be run on the interface. If other command configurations exist on
the interface, delete them.
The undo portswitch command switches an Eth-Trunk interface from the Layer 2 mode to
the Layer 3 mode.
NOTE
l The minimum interval for running the portswitch and undo portswitch commands in consecutive
order is 30s.
l Changing the working mode of an Eth-Trunk interface has no impact on interface addition to the
Eth-Trunk interface. Interfaces can be added to either a Layer 2 or Layer 3 Eth-Trunk interface.
----End
Follow-up Procedure
After configuring a Layer 2 Eth-Trunk interface, view the brief information about the
interface, including the physical state, protocol state, and bandwidth utilization.
l Run the display interface eth-trunk [ trunk-id ] command to check the status of the
Eth-Trunk interface.
l Run the display interface brief command to check the brief information of the Eth-
Trunk interface, including physical state, protocol state, and bandwidth utilization.
Example
Run the display interface eth-trunk command. The command output shows the Hash
algorithm of an Eth-Trunk interface.
Eth-Trunk1 current state : UP
Description : Eth-Trunk1 Interface
Route Port,Hash arithmatic : According to flow,Maximal BW: 2G, Current BW: 2G,
The Maximum Transmit Unit is 1500
Internet protocol processing : disabled
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc09-9722
Physical is ETH_TRUNK
Output: 2 packets,4 bytes,
12 unicast,14 broadcast,13x multicasts
15 errors,6 drops
-----------------------------------------------------
-----------------------------------------------------
-----------------------------------------------------
Run the display interface brief command. The command output shows the physical state,
link-layer protocol status, bandwidth utilization of an Eth-Trunk interface and the number of
error packets.

<sysname> display interface brief | begin Eth-Trunk

PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Eth-Trunk1 up up 0% 0% 0 0
GigabitEthernet1/0/1 up up 0% 0% 0 0
GigabitEthernet1/0/2 up up 0% 0% 0 0
Eth-Trunk1.1 up up 0% 0% 0 0
4.1.3.6.4 Configuring a Eth-Trunk Sub-interface

The FW allows you to configure sub-interfaces for Layer 3 Eth-Trunk interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
quit
Exit the Eth-Trunk interface view.
Step 4 Run:
interface eth-trunk trunk-id.subnumber
An Eth-Trunk sub-interface is created, and the Eth-Trunk sub-interface view is displayed.
subnumber specifies the number of an Eth-Trunk sub-interface. The number ranges from 1 to
4096 on the FW. A maximum of 1024 sub-interfaces can be created on each Eth-Trunk
interface.
Step 5 Configure an IP address for the Eth-Trunk sub-interface.

l Configure an IPv4 address for the Eth-Trunk sub-interface.
To configure an IPv4 address for the Eth-Trunk sub-interface, run the ip address ip-
address { mask | mask-length } [ sub ] command.
l Configure an IPv6 address for the Eth-Trunk sub-interface.
Configure an IPv6 address for the Eth-Trunk sub-interface based on actual situations:
– To configure an automatic link-local address for the sub-interface, run the ipv6
address auto link-local command.
– To configure a link-local address for the sub-interface, run the ipv6 address ipv6-
address link-local command.
– To configure a global unicast address for the sub-interface, run the ipv6 address
{ ipv6-address | prefix-length } command.

– To configure an IPv6 address in the format of EUI-64 for the sub-interface, run the
ipv6 address ipv6-address/prefix-length [ eui-64 ] command.
Step 6 Run:
An encryption type and associated VLAN ID are configured for the Eth-Trunk sub-interface.
NOTE
The FW allows you to associate an Eth-Trunk sub-interface with a maximum of one VLAN.
By default, the sub-interface has no encryption types or associated VLAN IDs.

Ensure that the sub-interfaces at both ends of a link have the same VLAN ID, which ensures
VLAN connectivity.
Step 7 Optional: Configure an MTU for the Eth-Trunk sub-interface.
To configure an IPv4 MTU for the sub-interface, run the mtu mtu command.
The MTU is expressed in bytes. The MTU of an Eth-Trunk sub-interface ranges from 46
to 9600. The default value is 1500.
NOTICE
If you run the mtu command to set an MTU to be smaller than 1280 for an Eth-Trunk
sub-interface running IPv6, IPv6 cannot work properly on the sub-interface. When IPv6
runs on an Eth-Trunk sub-interface, set the MTU of the sub-interface to be greater than
or equal to 1280.

a. To enable IPv6 for the sub-interface, run the ipv6 enable command
b. To configure an IPv6 MTU for the sub-interface, run the ipv6 mtu mtu command.
The MTU is expressed in bytes. The MTU range of an Eth-Trunk sub-interface
depends on devices. The default MTU is 1500.
----End
Follow-up Procedure
After configuring an Eth-Trunk sub-interface, view information about the sub-interface,
including the IP address and MAC address.
l Run the display interface eth-trunk [ trunk-id [.subnumber ] ] command to check the
status of the Eth-Trunk sub-interface.
Example
Run the display interface eth-trunk command. The command output shows the IP address
and MAC address of an Eth-Trunk sub-interface.
<sysname> display interface eth-trunk 1.1
Eth-Trunk1.1 current state : UP

Description : Eth-Trunk1.1 Interface

Hash arithmetic : According to IP, The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-3f60-ec00
Encapsulation dot1q Virtual LAN, The number of Vlan is 1, Vlan ID 2
Output:0 packets,0 bytes,
0 errors,0 drops
-----------------------------------------------------
-----------------------------------------------------
Ethernet6/0/0 UP 1
-----------------------------------------------------
4.1.3.6.5 Adding Physical Interfaces to an Eth-Trunk Interface

After creating an Eth-Trunk interface, add physical interfaces to the Eth-Trunk interface to
increase link bandwidth, improve reliability, and carry out load balancing.
Context
A physical interface can be added to one Eth-Trunk interface only. If the physical interface
needs to be added to other Eth-Trunk interfaces, you should remove it from the former Eth-
Trunk interface.
NOTE
USG6000V have the independent management interfaces, so they cannot add GigabitEthernet 0/0/0 to
the Eth-Trunk.
Procedure
l Configure either of the following methods:
– In the Eth-Trunk interface view:
i. Run system-view, The system view is displayed.
ii. Run interface eth-trunk trunk-id. The Eth-Trunk interface view is displayed.
iii. Run either of the following commands to add physical interfaces to the Eth-
Trunk interface.
○ To add a single physical interface to the Eth-Trunk interface, run the
trunkport interface-type interface-number command.
○ To add multiple physical interfaces to the Eth-Trunk interface in batches,
run the trunkport interface-type { interface-number1 [ to interface-
number2 ] } &<1-16> command.
A maximum 16 interfaces can be added to the Eth-Trunk interface at a time.
– In the member interface view:
i. Run system-view The system view is displayed.

ii. Run interface interface-type interface-number The view of the interface to be

added to the Eth-Trunk interface is displayed.
iii. Run eth-trunk trunk-id The interface is added to the Eth-Trunk interface.
Note the following points when adding physical interfaces to an Eth-Trunk
interface:
○ Each Eth-Trunk interface contains a maximum of 16 member interfaces.
○ Member interfaces cannot have any services or Layer 3 configurations,
such as IP addresses.
○ Member interfaces cannot have static MAC addresses.
○ Eth-Trunk interfaces cannot be added to Eth-Trunk interfaces.
○ An Ethernet interface can be added to only one Eth-Trunk interface.
Delete an Ethernet interface in an existing Eth-Trunk interface before
adding it to another Eth-Trunk interface.
○ Ethernet interfaces on different LPUs can be added to the same Eth-Trunk
interface.
○ If the interfaces to be added to an Eth-Trunk interface are Layer 2
interfaces on the FW, run the undo portswitch command to change the
interfaces to Layer 3 interfaces before adding them to the Eth-Trunk
interface.
○ An Eth-Trunk interface can work in either Layer 2 or Layer 3 mode.
Changing the working mode of an Eth-Trunk interface has no impact on
interface addition to the Eth-Trunk interface. For example, Ethernet
interfaces can be added to either Layer 2 or Layer 3 Eth-Trunk interfaces.
○ If a member interface of an Eth-Trunk interface is connected to the peer
device, the directly connected interface on the peer must also be a
member interface of the Eth-Trunk interface; otherwise, the devices
cannot communicate with each other.
----End
4.1.3.6.6 Configuring the Lower Limit of Up Member Interface for an Eth-Trunk

Interface
When the number of Up member links falls below the lower limit, the Eth-Trunk interface
goes Down. Setting the lower limit ensures the minimum bandwidth of the Eth-Trunk
interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The Eth-Trunk interface is displayed.
Step 3 Run:
least active-linknumber link-number

The lower limit of Up member interfaces is configured for the Eth-Trunk interface.
The default value is 1. The Eth-Trunk interface is Up as long as one member interface is Up.
NOTE
l The lower limit can be set in either Layer 2 or Layer 3 mode.

l To ensure normal forwarding, set the same lower limit for the Eth-Trunk interfaces on both ends of a
trunk link.
----End
4.1.3.6.7 Configuring a Load Balancing Mode for an Eth-Trunk Interface

To implement load balancing on an Eth-Trunk interface, configure a load balancing mode for
the Eth-Trunk interface and assign load balancing weights to its member interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The Eth-Trunk interface is displayed.
Step 3 Run:
load-balance { src-dst-ip | packet-all }
A load balancing mode is configured for the Eth-Trunk interface.
By default, an Eth-Trunk interface implements per-destination load balancing.
To ensure the bandwidth use efficiency of each member link, you can configure packet-all.
l In per-packet load balancing, traffic is evenly distributed to member links by packet, not
by data flow.
l Per-packet load balancing ensures bandwidth use efficiency, but not packet order, and
therefore applies to the scenarios where packet order is not strictly required.
To ensure that packets arrive at the destination in order, configure src-dst-ip.
l Per-destination load balancing differentiate data flows based on IP addresses to allow the
packets of one data flow to travel along the same member link.
l Per-destination load balancing ensures packet order, but not bandwidth use efficiency.
Step 4 Run:
quit
Return to the system view.
Step 5 Run:
interface interface-type interface-number interface-number
The Eth-Trunk member interface is displayed.

Step 6 Run:
distribute-weight weight-value
The load balancing weight is configured for the member interface.

For one Eth-Trunk interface, the total weights of its member interfaces cannot exceed 16.
Load balancing is implemented on an Eth-Trunk interface based on the weights of Eth-Trunk
member interfaces. A greater weight value indicates a heavier traffic load.
The default weight value is 1.
NOTE
If an Eth-Trunk interface carries multicast traffic and the distribute-weight command is used to change the
load balancing weight for a member interface, run the shutdown and then undo shutdown commands to
restart the member interface.
----End
4.1.3.7 Configuring a Loopback Interface

As loopback interfaces remain Up after being created, they are often used to improve
configuration reliability.
Context
As the loopback interface always remains in the Up state once created and has the loopback
characteristic, it can be used to improve the reliability.
The loopback interface is usually used in two situations.
l The IP address of the loopback interface is designated as the source address of packets.
l Controlling the access interface and filtering log based on the IP address simplify
information.
Generally, BGP uses the optimal local address to set up the TCP connection with its neighbor.
If the interface turns to Down, the BGP neighbor relationship cannot be set up. In practice,
often more than one link can reach the same neighbor. In this situation, using the loopback
interface as the BGP neighbor of the local FW can ensure the reliable connection.
Do as follows on the FW.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface loopback loopback-number
A loopback interface is created and the loopback interface view is displayed.

You can create or delete loopback interface dynamically. Once a loopback interface is created,
it keeps Up all the time until it is deleted.
Step 3 Run:
ip address ip-address [ mask | mask-length ]

The IPv4 address of the loopback interface is configured.

For the procedure of configuring the IPv6 address for the interface, refer to the chapter
"Configuring an IPv6 Address for an Interface".
----End
Follow-up Procedure
After loopback interfaces are configured, you need to check whether the configuration is
correct. In addition, you can view the statistics about loopback interfaces.
l Run the display interface loopback [ loopback-number ] command to check the status
of a loopback interface.
Example
Run the display interface loopback command, and you can view that the link layer protocol
status of the interface is Up.
<sysname> display interface loopback 6
LoopBack6 current state : UP
Line protocol current state : UP (spoofing)
Description : LoopBack6 Interface
Route Port,The Maximum Transmit Unit is 1500
Physical is Loopback
Statistics last cleared: never
Last 300 seconds input rate 0 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
0 unicast,0 broadcast,0 multicast
0 errors,0 drops,
0 errors,0 drops
4.1.3.8 Configuring a Null Interface
Context
The Null interface is like the null devices supported by some operating systems. All packets,
which are sent to the Null interface, are dropped. The system creates a Null interface NULL0.
Since all packets sent to the Null interface are dropped, you can directly send packets to be
filtered out to the Null interface. In this case, you may not configure a security policy.
For example, using the following command will discard all packets that are sent to the
192.101.0.0 network segment.
[sysname] ip route-static 192.101.0.0 255.255.0.0 null 0
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface NULL 0
The null interface view is displayed.

The null interface remains in the Up state all the time. It cannot forward data packet. You can
neither configure an IP address for it nor encapsulate it with protocols.
----End
Follow-up Procedure
After null interfaces are configured, you need to check whether the configuration is correct. In
addition, you can view statistics about null interfaces.
Run the display interface null [ 0 ] command to check the status of a null interface.
Example
l Run the display interface null command, and you can view that the status of the null
interface is Up.
<sysname> display interface null 0
NULL0 current state : UP
Line protocol current state :UP (spoofing)
Description: NULL0 Interface
Internet protocol processing : disabled
Physical is NULL DEV
0 errors,0 drops,
0 errors,0 drops
4.1.3.9 Configuring a Tunnel Interface

Tunnel interfaces are logical interfaces that have Layer 3 features. Devices on the two ends of
a tunnel send, receive, identify, and process tunnel packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface tunnel interface-number
A tunnel interface is created.

Step 3 Run:
tunnel-protocol { gre | ipsec | ipsec4-ipsec6 | ipsec6-ipsec4 | ipv4-ipv6 | ipv6-
ipv4 [ 6to4 | auto-tunnel | isatap ] | none }

The encapsulation type of the tunnel is configured.
By default, the encapsulation protocol of a tunnel interface is GRE. For details, refer to the
related configuration of each specified protocol. For one tunnel, the same encapsulation mode
needs to be configured on the interfaces at both ends.
Step 4 (Optional) Run:

mtu mtu
The MTU is configured.
After running the mtu command, run the shutdown command and then the undo shutdown
command to restart the interface to validate the MTU configuration. The interval between
shutdown and undo shutdown command must be longer than 15 seconds.
Step 5 Run:
An IP address is set for the interface.
Step 6 Run:
source { interface-type interface-number | source-ip-address }
The source address of the tunnel interface is configured.
The source address of the tunnel interface can be of the interface name or the IP address type.
If the interface name is adopted, the value can be GigabitEthernet, Eth-Trunk.
Step 7 Run:
destination [ vpn-instance vpn-instance-name ] dest-ip-address
The destination address of the tunnel interface is configured.
The destination address of the tunnel interface must be different from the source address.
----End
4.1.3.10 Configuring a Virtual Template Interface
Context
When PPP is required to bear other link layer protocols, VT interfaces are created to realize
the intercommunication. The VT interface is used in VPN applications.
The link layer of VT interfaces only supports the PPP protocol and the network layer only
supports IP.
NOTICE
l The newly configured or modified parameters of a VT interface can take effect only after
the shutdown and the undo shutdown command are run.
l To configure or modify services such as MTU or IS-IS, configure or modify those
services, and then perform related VT interface configuration on the other interfaces.

Procedure
Step 1 Run:
system-view

Step 2 Run:
interface virtual-template vt-number
A VT interface is created, and the VT interface view is displayed.

vt-number specifies the virtual template number. The value ranges from 0 to 1023.
Step 3 Run:
An IP address is configured.
Step 4 Run:
broadcast-limit link number
The maximum number of links that support the sending of multicast or broadcast packets is
configured.
When a VT interface has many links, multicast or broadcast packets are sent through each
link, affecting system performance. In this case, you can run the broadcast-limit link
command to allow a specified number of links to send multicast or broadcast packets. If every
link works at the highest speed, excess multicast or broadcast packets will be discarded.
NOTE
For one VT interface, configure only one type of service, if possible.
By default, up to 30 links on a VT interface can send multicast or broadcast packets.
----End
Follow-up Procedure
After VT interfaces are configured, you need to check whether the configuration is correct. In
addition, you can view the statistics about VT interfaces.
l Run the display interface virtual-template [ vt-number ] command to check the status
of a VT interface.
Example
Run the display interface virtual-template command. If the configuration of a VT interface
is displayed, it means the configuration succeeds.
<sysname> display interface virtual-template 1
Virtual-Template1 current state : UP
Line protocol current state :UP (spoofing)
Description: Virtual-Template1 Interface
Physical is None, baudrate is 64000 bps


0 errors,0 drops,
0 errors,0 drops
4.1.3.11 Maintaining Interfaces

This section describes how to display the configuration and status of a specific interface.
4.1.3.11.1 Displaying Interface Information

Displaying interface information helps you know the traffic volume and rate on interfaces,
and thus analyze network conditions.
You can run a display command to check the configuration and status of a specific interface.
Table 4-24 lists the display commands.
Table 4-24 Displaying the interface configuration and status

Action Command
Display the status of a specified Ethernet display interface [ interface-type

interface. [ interface-number ] ] [ | { begin | exclude |
include } regular-expression ]
Display brief information about Ethernet display interface ethernet brief [ | { begin
interfaces. | include | exclude } regular-expression ]
Display brief information about interfaces. display interface brief [ | { begin | include
| exclude } regular-expression ]
Display the status of the null interface. display interface null [ number ] [ | { begin
| include | exclude } regular-expression ]
Display the status of the loopback interface. display interface loopback [ number ] [ |
{ begin | include | exclude } regular-
expression ]
Display the configuration and statistics display ip interface [ interface-type

related to the IPv4 address of the interface. interface-number ]
display ip interface brief [ interface-type ]
[ interface-number ]
Display the configuration and statistics display ipv6 interface [ interface-type

related to the IPv6 address of the interface. interface-number ]
display ipv6 interface brief
4.1.3.11.2 Clearing Interface Statistics

After interface statistics are cleared, you can start the statistics again, which helps you know
the traffic volume and rate on interfaces at any time.

NOTICE
Statistics cannot be restored after you clear it. So, confirm the action before you use the
command.
To clear the interface statistics collected through the NMS or with the display interface
command, run the following reset counters commands in the user view. After that, you can
clear the traffic statistics on the interfaces again.
NOTE
For details on how to view the traffic statistics collected through the NMS, refer to the related manual
about the NMS.
You can run a reset command in the user view to clear the statistics of interfaces. Table 4-25
lists the display commands.
Table 4-25 Clearing Interface Statistics
Action Command
Clear the interface statistics collected with reset counters interface [ interface-type
the display interface command. [ interface-number ] ]
clear the interface statistics collected reset counters if-mib interface [ interface-
through the NMS. type [ interface-number ] ]
4.1.3.11.3 Debugging an Interface

When a fault occurs on an interface, you can run the following debugging commands in the
user view to view the debugging information, locate the fault, and analyze the cause.
Context
NOTICE
Debugging affects the performance of the system. So, after debugging, run the undo
debugging all command to disable it immediately.
When a fault occurs on an interface, run the following debugging commands in the user view
to locate the fault.
Procedure
l Run the debugging ethernet packet [ arp | error | ip | ipv6 | isis ] [ verbose ]
[ interface interface-type interface-number ] in the user view to debug the Ethernet
interface.

l Run the debugging ethernet packet process [ interface interface-type interface-

number ] in the user view to debug the related process after Ethernet packets are
received.
l Run the debugging ethernet packet mac { dest_mac dest-mac | src_mac src_mac } in
the user view to debug the Ethernet interface based on the MAC address.
l Run the debugging trunk error [ slot slot-number ] command in the user view to enable
debugging for errors on Eth-Trunk interfaces.
l Run the debugging trunk event [ slot slot-number ] command in the user view to enable
debugging for events on Eth-Trunk interfaces.
l Run the debugging trunk msg [ slot slot-number ] command in the user view to enable
debugging for Eth-Trunk packets.
l Run the debugging trunk state-machine [ slot slot-number ] command in the user view
to enable debugging for the Eth-Trunk state machine.
l Run the debugging trunk updown [ slot slot-number ] command in the user view to
enable debugging for Up/Down events of LAGs.
----End
4.1.3.11.4 Configuring the Loopback Function on Interfaces

To test an interface itself or This section describes how to use the web UI to configure a
security zone.
Testing the Loopback of Ethernet Interfaces

To test an Ethernet interface itself, you can run the loopback command in the Ethernet
interface view. When the interface works normally, you must disable the loopback function.
The loopback of Ethernet interfaces is generally used to test the interfaces. Run the following
command in the Ethernet interface view.
When interfaces work normally, disable the loopback.
l For the USG6000V, run the loopback command in the Ethernet interface view to enable
the loopback on interfaces.
----End

This section provides examples for configuring various interfaces to access networks.
4.1.4.1 CLI: Example for Accessing the Internet Using a Static IPv4 Address
A FW is assigned a static IPv4 address to access the Internet and provides access services for
intranet users.
An enterprise deploys a FW as a security gateway on the network shown in Figure 4-5 and
purchases broadband services from an ISP.
The networking requirements are as follows:

l Intranet PCs communicate with each other using addresses on the network segment
10.3.0.0/24. The FW allocates private network addresses and a DNS server address to
the PCs.
l Intranet PCs are able to access the Internet.
Figure 4-5 Ethernet link connecting intranet PCs to the Internet
Trust Untrust
PC
1.1.1.254
GE1/0/3 GE1/0/1
10.3.0.1/24 1.1.1.1/24
Intranet
FW Router
PC
The following information is used as an example. Obtain the desired service information from
your local ISP.
Table 4-26 Parameters provided by an ISP
Enterprise 1.1.1.1/24 Public network address that the

address ISP assigns to the enterprise
Default 1.1.1.254 Provided by the ISP

gateway
address
DNS server 9.9.9.9 Provided by the ISP

address
1. Assign IP addresses to interfaces and add the interfaces to security zones. Set the default
gateway address to 1.1.1.254 for GigabitEthernet 1/0/1.
2. Configure the DHCP server function on the FW to allocate IP addresses and a DNS
server address to intranet PCs.
3. Configure security policies to allow PCs to access the Internet.
4. Configure NAT policies for source address translation. As the FW translates private
addresses into a fixed public network address that is assigned by the ISP, easy-IP is used
to simplify the configuration.

Procedure
Step 1 Set the IP addresses of interfaces, and then assign the interfaces to security zones.
<FW> system-view
Step 2 Configure the FW as a DHCPv4 Server.

# Enable the DHCP function.
[FW] dhcp enable
# Create an interface address pool and specify the default gateway IP address and the DNS
server address for PCs on the intranet.
[FW-GigabitEthernet1/0/3] dhcp select interface
[FW-GigabitEthernet1/0/3] dhcp server dns-list 9.9.9.9
[FW-GigabitEthernet1/0/3] dhcp server gateway-list 10.3.0.1
Step 3 Configure security policies, allowing PCs on the intranet to access the Internet.
[FW-security-policy] rule name policy_sec_1
[FW-security-policy-sec_policy_1] source-address 10.3.0.0 mask 255.255.255.0
[FW-security-policy-sec_policy_1] source-zone trust
[FW-security-policy-sec_policy_1] destination-zone untrust
[FW-security-policy-sec_policy_1] action permit
[FW-security-policy-sec_policy_1] quit
[FW-security-policy] quit
Step 4 Configure a NAT policy, allowing PCs on the intranet to access the Internet by using the
resulting public IP address of translation.
[FW] nat-policy
[FW-policy-nat] rule name policy_nat_1
[FW-policy-nat-rule-policy_nat_1] source-address 10.3.0.0 mask 255.255.255.0
[FW-policy-nat-rule-policy_nat_1] source-zone trust
[FW-policy-nat-rule-policy_nat_1] egress-interface GigabitEthernet 1/0/1
[FW-policy-nat-rule-policy_nat_1] action nat easy-ip
[FW-policy-nat-rule-policy_nat_1] quit
Step 5 Configure the default route whose next hop IP address is 1.1.1.254.
----End
1. View details about GigabitEthernet 1/0/1 and check whether interface GigabitEthernet
1/0/1 has obtained a public IP address and both the physical and IPv4 states are Up.
[FW] display interface GigabitEthernet 1/0/1
GigabitEthernet 1/0/1 current state :
UP


GigabitEthernet 1/0/1 current firewall zone : untrust
Description : GigabitEthernet 1/0/1 Interface, Route Port
The Maximum Transmit Unit is 1500 bytes, Hold timer is 10(sec)
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0022-a100-
a101
Media type is twisted pair, loopback not set, promiscuous mode not set
100Mb/s-speed mode, full-duplex mode, link type is auto negotiation
QoS max-bandwidth : 100000 Kbps
Output queue : (Urgent queue : Size/Length/Discards) 0/50/0
Output queue : (Frag queue : Size/Length/Discards) 0/1000/0
Output queue : (Protocol queue : Size/Length/Discards) 0/1000/0
Output queue : (FIFO queue : Size/Length/Discards) 0/256/0
Input: 1149 packets, 99478 bytes
12 unicasts, 4 broadcasts, 1133 multicasts, 0 pauses
0 overruns, 0 runts, 0 jumbos, 0 FCS errors
0 length errors, 0 code errors, 0 align errors
0 fragment errors, 0 giants, 0 jabber errors
0 dribble condition detected, 0 other errors
Output: 1104 packets, 94646 bytes
0 underruns, 0 runts, 0 jumbos, 0 FCS errors
0 collisions, 0 late collisions
0 ex. collisions, 0 deferred, 0 other errors
2. Run the ipconfig/all command on a PC to verify that the PC has obtained a valid IP
address and DNS address. The following example uses a PC running Windows XP. The
actual command output may vary.
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network
Connection
Physical Address. . . . . . . . . : 00-1B-21-B4-0B-35
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.3.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.3.0.1
DHCP Server . . . . . . . . . . . : 10.3.0.1
DNS Servers . . . . . . . . . . . : 9.9.9.9
Lease Obtained. . . . . . . . . . : Tuesday, December 6, 2011,
05:58:28 AM
Lease Expires . . . . . . . . . . : Friday, December 16, 2011,
05:58:28 AM
3. Check whether an intranet PC can use a domain name to access the Internet. If the PC
can access the Internet, the configuration is successful. If the PC fails to access the
Internet, modify the configuration and try again.
#
dhcp enable
#
undo shutdown
ip address 1.1.1.1 255.255.255.0
#
undo shutdown
ip address 10.3.0.1 255.255.255.0
dhcp select interface
dhcp server ip-range 10.3.0.1 10.3.0.254

dhcp server gateway-list 10.3.0.1

dhcp server dns-list 9.9.9.9
#
firewall zone trust
set priority 85
#
set priority 5
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#
security-policy
rule name policy_sec_1
source-zone trust
action permit
#
nat-policy
rule name policy_nat_1
source-zone trust
action nat easy-ip
#
return
4.1.4.2 CLI: Example for Accessing the Internet Using DHCP

This section provides an example for configuring a FW as a DHCP client that applies for an
IPv4 address to access the Internet.
Applicable Products
USG6000V
Figure 4-6 shows that a FW functions as an egress gateway and connect PCs in an intranet to
the Internet. The network plan is as follows:
l An administrator manually specifies an IPv4 address for each PC on the network
segment 10.3.0.0/24.
l An interface with a static IPv4 address connects the FW to the intranet.
l Another interface on the FW that functions as a DHCP client applies for a client IPv4
address and a DNS server IP address from a DHCP server and connects the intranet to
the Internet.

Figure 4-6 Networking diagram for accessing the Internet using DHCP
Trust Untrust
PC FW
Intranet
GE1/0/3 GE1/0/1
10.3.0.1/24 DHCP Client
DHCP Server
PC
1. Enable the DHCP client function on GigabitEthernet 1/0/1 of the FW to obtain a client
IPv4 address and a DNS server address from a DHCP server.
2. Specify a static IPv4 address on GigabitEthernet 1/0/3 that connects the FW to the
intranet.
3. Configure a security policy and a NAT policy (easy-IP) on the FW.
4. Set the IP addresses of the PCs' gateway and a DNS server to 10.3.0.1. This example
provides the configuration procedure on the FW. The configuration procedure for the
PCs is not provided.
NOTE
After the FW obtains an IPv4 address from a DHCP server, the DHCP server issues a default route to the
FW that function as a DHCP client. The next hop of the default route is a carrier's device. Therefore,
there is no need to configure a default route.
Procedure
Step 1 Configure the IP address of the interface and assign the interfaces to the security zones.
<FW> system-view
Step 2 Configure the DNS proxy function.

[FW] dns proxy enable
[FW] dns resolve
[FW] dns server unnumbered interface GigabitEthernet1/0/1
Step 3 Configure GigabitEthernet 1/0/3 as a DHCP client.

Step 4 Configure a security policy to allow the PCs to access the Internet.

[FW-policy-security] rule name policy_sec_1
[FW-policy-security-rule-policy_sec_1] source-zone trust
[FW-policy-security-rule-policy_sec_1] source-address 10.3.0.0/24
[FW-policy-security-rule-policy_sec_1] egress-interface GigabitEthernet1/0/1
[FW-policy-security-rule-policy_sec_1] action permit
[FW-policy-security-rule-policy_sec_1] quit
Step 5 Configure a NAT policy to translate private network IP addresses into public network IP
addresses before PCs access the Internet.
[FW] nat-policy
[FW-policy-nat-rule-policy_nat_1] destination-zone untrust
[FW-policy-nat-rule-policy_nat_1] source-address 10.3.0.0 24
----End
1. Check the status of GigabitEthernet 1/0/1 (uplink).
b. Verify that the physical status and IPv4 status of GigabitEthernet 1/0/1 are Up, the
connection type is DHCP, and the interface obtained an IPv4 address.
2. Check whether the PC on the intranet can use domain names to access the Internet. If the
PC can access the Internet, the configuration is successful. If the PC fails to access the
#
dns resolve
dns server unnumbered interface GigabitEthernet1/0/1
#
dns proxy enable
#
undo shutdown
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
#
security-policy
source-zone trust
action permit
#
nat-policy

source-zone trust
action nat easy-ip
#
return
4.1.4.3 CLI: Example for Accessing the Internet Using IPv4 PPPoE
This section provides an example for the device, working as a PPPoE client, to obtain an IP
address by dialing up to the carrier's server through PPPoE for Internet access.
As shown in Figure 4-7, FW works as an egress gateway, providing an Internet egress for
PCs on the LAN. The company network is planned as follows:
l All PCs on the LAN are deployed on network segment 10.1.1.0/24, and they
dynamically obtain IP addresses through DHCP.
l The device connects to all PCs of the company over the downstream link.
l The device applies for Internet service from the carrier over the upstream link. The
Internet access service is provided using the PPPoE protocol.
According to the previous requirements, specify the FW as a PPPoE client. After the client
obtains IP and DNS addresses from the carrier's server, the Intranet users can access the
Internet.
Figure 4-7 Networking diagram of accessing the Internet through PPPoE
Trust Untrust
FW
GE1/0/5
10.0.0.1 GE1/0/1
Intranet
PPPoE Client PPPoE Server
In this example, the information provided by the carrier is used only for reference.
Data Description
Interface number: GigabitEthernet The device obtains IP and DNS addresses from the
1/0/1 PPPoE server (deployed by the carrier) through
Security zone: untrust dial-up.
l Dial-up user name: user
l Dial-up password: password

Data Description
Interface number: GigabitEthernet DHCP is used to dynamically assign IP addresses

1/0/5 to PCs on the LAN.
IP address: 10.0.0.1/24
1. Configure the downstream link.
Enable DHCP server on the GigabitEthernet 1/0/5 interface so that it dynamically
assigns IP addresses to PCs, and specify the GigabitEthernet 1/0/5 interface's IP address
as the gateway and DNS server addresses for the PCs.
During Internet access, a PC usually requires domain name resolution. This is why a
DNS server shall be specified. In this example, FW works as a DNS relay.
2. Configure the upstream link and use PPPoE to obtain IP and DNS addresses.
3. Add the interfaces into security zones and configure security policies.
Add the interface connected to the LAN to a high-priority security zone (Trust zone), and
the upstream interface connected to the Internet to a low-priority security zone (Untrust
zone).
4. The IP addresses used on LANs are private IP addresses, which shall be converted by
NAT to public IP addresses for Internet access, if needed. In this example, the upstream
interface obtains its IP address by dial-up. This IP address may vary for each dial-up.
Therefore, easy IP is recommended.
Procedure
Step 1 Configure the IP address of the interface GigabitEthernet 1/0/5.
<FW> system-view
Step 2 Assign the interfaces to the security zones.

Step 3 Configure the device as a DHCP server to assign IP addresses to PCs on the LAN.
# Enable the DHCP function.
[FW] dhcp enable
# Create an interface address pool on the interface and specify the DNS server for the Intranet
PCs.
[FW-GigabitEthernet1/0/5] dhcp server dns-list unnumbered interface
GigabitEthernet 1/0/5

[FW-GigabitEthernet1/0/5] dhcp server gateway-list 10.0.0.1

Step 4 Configure interface GigabitEthernet 1/0/1 so that it obtains IP and DNS addresses using
PPPoE.
[FW] dialer-rule 1 ip permit
[FW] interface Dialer 1
[FW] link-protocol ppp
[FW-Dialer1] dialer user user
[FW-Dialer1] ip address ppp-negotiate
[FW-Dialer1] ppp ipcp dns admit-any
[FW-Dialer1] dialer-group 1
[FW-Dialer1] dialer bundle 1
[FW-Dialer1] ppp pap local-user user password cipher password
[FW-Dialer1] quit
[FW-zone-untrust] add interface Dialer 1
[FW-GigabitEthernet1/0/1] pppoe-client dial-bundle-number 1 ipv4
Step 5 Configure a security policy to allow Intranet PCs to access the Internet.
[FW-security-policy] rule name sec_policy_1
[FW-security-policy-sec_policy_1] source-address 10.3.0.0 mask 255.255.255.0
[FW-security-policy-sec_policy_1] source-zone trust
[FW-security-policy-sec_policy_1] destination-zone untrust
[FW-security-policy-sec_policy_1] action permit
[FW-security-policy-sec_policy_1] quit
[FW-security-policy] quit
Step 6 Configure a NAT policy to allow Intranet users to access the Internet.
[FW] nat-policy
[FW-policy-nat-rule-policy_nat_1] source-address 10.0.0.0 mask 255.255.255.0
[FW-policy-nat-rule-policy_nat_1] egress-interface GigabitEthernet 1/0/1
[FW-policy-nat-rule-policy_nat_1] quit
Step 7 Configure a default route to ensure that the LAN users are routable to the Internet. The next
hop shall be the gateway address assigned by the carrier to the enterprise.
[FW] ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet 1/0/1
----End
Verification
1. Display the detailed information of GigabitEthernet 1/0/1 and check whether the
physical status and IPv4 status of the interface is up and whether the link type is PPPoE.
[FW] display interface GigabitEthernet 1/0/1
GigabitEthernet 1/0/1 current state :
UP
GigabitEthernet 1/0/1 current firewall zone : untrust
Description : GigabitEthernet 1/0/1 Interface, Route Port
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0022-a100-
a101
QoS max-bandwidth : 100000 Kbps


0 ex. collisions, 0 deferred, 0 other errors
2. On a LAN PC, run the ipconfig/all command to check whether the private IP and DNS
addresses have been correctly configured for the network adapter. The following uses
Windows XP for example.
Ethernet adapter Local:
Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network
Connection
Physical Address. . . . . . . . . : 00-1B-21-B4-0B-35
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 10.0.0.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.0.1
DHCP Server . . . . . . . . . . . : 10.0.0.1
DNS Servers . . . . . . . . . . . : 2.2.2.2
Lease Obtained. . . . . . . . . . : 2012-8-2 9:38:14
Lease Expires . . . . . . . . . . : 2012-8-13 9:38:14
3. Check whether LAN PCs can use a domain name to access the Internet. If so, the
configurations are correct. If not, check and correct the configurations.
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.0.0.1 24
#
interface Dialer1
link-protocol ppp
ppp chap user user
ppp chap password cipher %$%$8*YSTS6T4Xon5,*wo<v~0>5,%$%$
ppp pap local-user user password cipher %$%$8*YSTS6T4Xon5,*wo<v~0>5,%$%$
ppp ipcp dns admit-any
ip address ppp-negotiate
dialer user user
dialer bundle 1
dialer-group 1
#
pppoe-client dial-bundle-number 1 ipv4
#
firewall zone trust
set priority 85

#
set priority 5
add interface Dialer1
#
#
security-policy
rule name sec_policy_1
source-zone trust
action permit
#
nat-policy
source-zone trust
action nat easy-ip
#
return
4.1.4.4 CLI: Example for Configuring Static IPv6 Addresses for Devices to
Communicate
This section describes how to configure static IPv6 addresses for devices to communicate.
The interfaces connecting two devices are configured with IPv6 addresses.
FW_A and FW_B are connected, as shown in Figure 4-8. Global unicast IPv6 addresses can
be assigned to interfaces that directly connect FW_A and FW_B to allow the two devices to
Figure 4-8 Communication between FWs using IPv6 addresses
Untrust
GE1/0/1 GE1/0/1
3000::1/64 3000::2/64
FW_A FW_B
1. Assign IPv6 addresses to interfaces that directly connect FW_A to FW_B.

2. Configure a security policy on FW_A and FW_B.

Procedure
1. Enable IPv6 globally to allow the FW to forward IPv6 packets.
<FW> system-view
[FW] sysname FW_A
[FW_A] ipv6
2. Configure the IPv6 address of GigabitEthernet 1/0/1.

[FW_A-GigabitEthernet1/0/1] ipv6 enable
[FW_A-GigabitEthernet1/0/1] ipv6 address 3000::1/64
[FW_A-GigabitEthernet1/0/1] undo shutdown
[FW_A-zone-untrust] add interfaceGigabitEthernet 1/0/1
[FW_A] quit
3. Configure a security policy.

[FW_A-policy-security] rule name policy_sec_1
[FW_A-policy-security-rule-policy_sec_1] source-zone local
[FW_A-policy-security-rule-policy_sec_1] source-zone untrust
[FW_A-policy-security-rule-policy_sec_1] destination-zone local
[FW_A-policy-security-rule-policy_sec_1] destination-zone untrust
[FW_A-policy-security-rule-policy_sec_1] action permit
[FW_A-policy-security-rule-policy_sec_1] quit

The configuration of FW_B is similar to that of FW_A. Therefore, the configuration details
are not provided.
----End
1. Check the status of GigabitEthernet 1/0/1. The following example uses GigabitEthernet
1/0/1 on FW_A. If the configuration is successful, the configured global unicast address
can be displayed. In addition, the physical status and IPv6 status of the interface is up.
[FW_A] display ipv6 interface GigabitEthernet 1/0/1
GigabitEthernet1/0/1 current state :
UP
IPv6 protocol current state :
UP
IPv6 is enabled, link-local address is
FE80::2A6E:D4FF:FE48:3EF
Global unicast
address(es):
3000::1, subnet is
3000::/64
Joined group
address(es):
FF02::1:FF00:1
FF02::2
FF02::1
FF02::1:FF48:3EF
MTU is 1500
bytes
ND DAD is enabled, number of DAD attempts:

1
ND reachable time is 30000
milliseconds
ND retransmit interval is 1000
milliseconds
ND stale time is 1200
seconds
ND advertised reachable time is 0
milliseconds
ND advertised retransmit interval is 0
milliseconds
ND router advertisement max interval 600 seconds, min interval 200
seconds
ND router advertisements live for 1800
seconds
ND router advertisements hop-limit
64
ND default router preference
medium
Hosts use stateless autoconfig for
addresses
2. Run the ping command on FW_A to test the connectivity between the devices.
Configuration script for FW_A:
#
ipv6
#
sysname FW_A
#
ipv6 enable
ipv6 address 3000::1 64
#
set priority 5
#
security-policy
source-zone local
source-zone untrust
action permit
#
return
Configuration script for FW_B:

#
ipv6
#
sysname FW_B
#
ipv6 enable
#
set priority 5
#
security-policy
source-zone local

source-zone untrust
action permit
#
return
4.1.4.5 CLI: Example for Configuring VLAN Interfaces to Allow VLANs to

Communicate
In the networking, users belong to different VLANs. To implement the communication
between devices in different VLANs, you can assign IP addresses to VLANIF interfaces.
As shown in Figure 4-9, two project teams in the same R&D department which need to be
isolated belong to different VLANs. To enable project teams to coordinate with each other,
ensure that PCs in these project teams can communicate.
l VLAN 2 includes the ports GE 1/0/0 and GE 1/0/1.

l VLAN 3 includes the ports GE 1/0/2 and GE 1/0/3.
Figure 4-9 Networking diagram for configuring inter-VLAN communication by using

VLANIF interfaces
FW
GE1/0/0 GE1/0/2
GE1/0/1 GE1/0/3
VLANIF2 VLANIF3
10.1.1.1/24 10.2.1.1/24
VLAN2 VLAN3
10.1.1.0/24 10.2.1.0/24
1. Configure VLANs and add Layer-2 Ethernet interfaces.

2. Configure Vlanif interfaces.
3. Add the interfaces to security zones and configure interzone security policies.

4. Configure the host gateway.

NOTE
The default gateway address of each PC in a VLAN must be the IP address of the corresponding
VLANIF interface. Otherwise, inter-VLAN communication will fail.
Data Preparation
To complete the configuration, you need the following data:
l GigabitEthernet 1/0/0 and GigabitEthernet 1/0/1 belong to VLAN 2.
l GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 belong to VLAN 3.
l GigabitEthernet 1/0/0 and GigabitEthernet 1/0/1 belong to the Trust zone.
l GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 belong to the Untrust zone.
l The IP address of VLANIF 2 is 120.1.1.1/24.
l The IP address of VLANIF 3 is 130.1.1.1/24.
Procedure
Step 1 Configure VLANs and add interfaces.
# Create VLAN2.
<FW> system-view
[FW] vlan 2
[FW-vlan-2] quit
# Add GigabitEthernet 1/0/0 to VLAN2.

[FW-GigabitEthernet1/0/0] port default vlan 2

# Create VLAN3.
<FW> system-view
[FW] vlan 3
[FW-vlan-3] quit


Step 2 Configure Vlanif interfaces.

# Set the IP address of Vlanif 2.

[FW] interface Vlanif 2
[FW-Vlanif2]ip address 120.1.1.1 24
[FW-Vlanif2]quit
# Set the IP address of Vlanif 3.

[FW-Vlanif3]ip address 130.1.1.1 24
[FW-Vlanif3]quit
Step 3 Add interfaces to corresponding security zones and configure interzone packet filtering to
ensure normal network communication. Details are omitted.
Step 4 Set the IP address of the host gateway that belongs to VLAN2 to 120.1.1.1 and set that
belongs to VLAN3 to 130.1.1.1.
After the configuration, the hosts in VLAN2 and VLAN3 can ping through each other.
Suppose that a host at IP address 130.1.1.5 exists on VLAN3, and you run the ping command
on a certain host on VLAN2 to test the communications with the host on VLAN3.
C:\Documents and Settings\Administrator> ping 130.1.1.5


----End
Configuration Files
#
vlan batch 2 to 3
#
interface Vlanif2
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif3
ip address 10.2.1.1 255.255.255.0
#
portswitch
undo shutdown
port link-type access
port default vlan 2
#
portswitch
undo shutdown
port default vlan 2
#
portswitch
undo shutdown
port default vlan 3
#

portswitch
undo shutdown
port default vlan 3
#
firewall zone trust
set priority 85
add interface Vlanif2
#
set priority 5
add interface Vlanif3
#
security-policy
source-zone trust
source-zone untrust
action permit
#
return
4.1.4.6 CLI: Example for Configuring VLANs on Ethernet Subinterfaces to Allow

the VLANs to Communicate
This section provides an example for configuring VLANs on Layer 3 subinterfaces to allow
the VLANs to communicate. As the number of physical interfaces is limited, you can
configure multiple subinterfaces on a physical interface. Each subinterface belongs to a
specific VLAN. VLANs can communicate with each other on a single physical interface.
Three project teams in the R&D department shown in Figure 4-10 are deployed separately
and belong to VLAN10, VLAN20, and VLAN30, respectively. PCs of these project teams
need to communicate with each other to enable project teams to work with each other.

Figure 4-10 Networking diagram for configuring VLANs on Layer 3 subinterfaces to allow
the VLANs to communicate with each other
FW
GE1/0/3
Trust
GE1/0/3.1 GE1/0/3.2 GE1/0/3.3

10.3.1.1/24 10.3.2.1/24 10.3.3.1/24
Switch
R&D1 R&D2 R&D3

VLAN10 VLAN20 VLAN30
10.3.1.0/24 10.3.2.0/24 10.3.3.0/24
1. Enable the subinterface function on GigabitEthernet 1/0/3 of the FW and create a

subinterface for each VLAN to allow inter-VLAN communication, which enables Layer
3 communication between different VLANs.
2. Configure a VLAN on the switch and assign interfaces to VLANs. The configuration
details are not provided.
3. Use the IP address of a VLAN-specific subinterface as the gateway address for the PCs
on a specific VLAN. The configuration details on PCs are not provided.
Procedure
Step 1 Configure the Lay-3 Ethernet sub-interfaces.
<FW> system-view
[FW-GigabitEthernet1/0/3.1] alias GigabitEthernet1/0/3.1
[FW-GigabitEthernet1/0/3.1] ip address 10.3.1.1 255.255.255.0


Step 2 Assign the created sub-interfaces to the security zone.

[FW-zone-trust] add interface GigabitEthernet 1/0/3.1
----End
1. Display the status of GigabitEthernet 1/0/3.1, GigabitEthernet 1/0/3.2 and
GigabitEthernet 1/0/3.3. Check whether the physical status and the IPv4 status of each
sub-interface is up. Now set the GigabitEthernet 1/0/3.1 of USG6000V as an example.
[FW] display interface GigabitEthernet 1/0/3.1
GigabitEthernet1/0/3.1 current state : UP
Line protocol current state :
UP
Last line protocol up time : 2015-05-26 18:09:59 UTC
+08:00
Description:Huawei, Series, GigabitEthernet1/0/3.1 Interface
Route Port,The Maximum Transmit Unit is
1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 286e-
d448-03f9
Encapsulation dot1q Virtual LAN, The number of Vlan is 1, Vlan ID
10
Current system time: 2015-05-30
17:11:17+08:00
Last 300 seconds input rate 0 bits/sec, 0 packets/
sec
Last 300 seconds output rate 8 bits/sec, 0 packets/
sec
Realtime 0 seconds input rate 0 bits/sec, 0 packets/
sec
Realtime 0 seconds output rate 0 bits/sec, 0 packets/
sec
Input: 0 packets,0
bytes,
0 unicast,0 broadcast,0
multicast
0 errors,0
drops,
Output:8558 packets,547712
bytes,
0 unicast,2856 broadcast,5702
multicast
0 errors,0
drops
Input bandwidth utilization :
0%
Output bandwidth utilization : 0%
2. Check whether PCs in VLAN10, VLAN20, and VLAN30 can communicate. If they can
communicate, the configuration is successful. If they fail to communicate, modify the
configuration and try again.
#

vlan-type dot1q 10
alias GigabitEthernet1/0/3.1
ip address 10.3.1.1 255.255.255.0
#
vlan-type dot1q 20
ip address 10.3.2.1 255.255.255.0
#
vlan-type dot1q 30
ip address 10.3.3.1 255.255.255.0
#
firewall zone trust
set priority 85
#
return
4.1.4.7 CLI Example for Configuring VLAN Trunk Interfaces to Enable VLANs
on Different Network Segments to Communicate
This section provides an example for configuring VLAN trunk interfaces when VLANs are
deployed across devices. Data of a specific VLAN is identified by an 802.1q tag and is
transmitted over trunk links formed by connected trunk interfaces.
As shown in Figure 4-11, PCs of the financial and marketing departments of an enterprise are
distributed in two buildings, each of which is connected to a FW. The two FWs are connected
to each other. To improve service security, the FWs can be configured to forbid inter-
department communication so that only PCs of the same department can communicate with
each other.
Figure 4-11 Networking diagram for configuring VLAN trunk interfaces
VLAN5 VLAN5
Financial Financial
Department Trust Trust
Department
GE1/0/2 VLAN5 GE1/0/2
GE1/0/1 GE1/0/1
FW_A FW_B
GE1/0/3 VLAN9 GE1/0/3
VLAN9 VLAN9
Marketing Marketing
Department Department

1. Create VLAN5 and VLAN9 on both FW_A and FW_B. Add interfaces of each FW to
two VLANs so that PCs connected to each interface can access separate VLANs.
2. Configure trunk interfaces on FW_A and FW_B to allow VLAN5 and VLAN9 packets
through.
Procedure
l Configure FW_A.
# Create VLANs.
<FW> system-view
[FW] sysname FW_A
[FW_A] vlan batch 1 5 9
# Add the interfaces to the VLANs.

[FW_A-GigabitEthernet1/0/1] portswitch
[FW_A-GigabitEthernet1/0/1] port link-type trunk
[FW_A-GigabitEthernet1/0/1] port trunk allow-pass vlan 5 9
[FW_A-GigabitEthernet1/0/2] port link-type access
[FW_A-GigabitEthernet1/0/2] port default vlan 5
[FW_A-GigabitEthernet1/0/3] port link-type access
[FW_A-GigabitEthernet1/0/3] port default vlan 9
# Assign the interfaces to the trust zone.

l Configure FW_B.
The configuration of FW_B is similar to that of FW_A. The configuration details are not
provided.
----End
1. Run the display interface command in the system view to display the information of
GigabitEthernet 1/0/1, GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3, then you can
check whether the physical status of each interface is up.
2. After completing the configuration, verify that PCs only in the same department can

#
vlan batch 1 5 9
#
sysname FW_A
#
portswitch
port trunk permit vlan 5 9
#
portswitch
port default vlan 5
#
portswitch
port default vlan 9
#
firewall zone trust
set priority 85
#
return

#
vlan batch 1 5 9
#
sysname FW_B
#
portswitch
port trunk permit vlan 5 9
#
portswitch
port default vlan 5
#
portswitch
port default vlan 9
#
firewall zone trust
set priority 85
#
return
4.1.4.8 CLI Example for Configuring Link Aggregation in Manual Mode

This section provides an example for configuring link aggregation in manual mode to increase
link bandwidth.
A company has two branches on LAN 1 and LAN 2. LAN 1 is connected to FW_A, and LAN
2 is connected to FW_B, as shown in Figure 4-12.

A large amount of traffic continuously goes between LAN 1 and LAN 2. Links can be
bundled in to an Eth-Trunk interface to increase the link bandwidth. LAN 1 and LAN 2 are on
the same network segment 192.168.0.1/24.
Figure 4-12 Link aggregation in manual mode

FW_A FW_B
GE1/0/1 GE1/0/1
GE1/0/2 GE1/0/2
Eth-Trunk 1 Eth-Trunk 1
GE1/0/3 Untrust Untrust GE1/0/3
Trust Trust
LAN 1 LAN 2
1. Create a Layer-2 Eth-Trunk interface. Because LAN 1 and LAN 2 are on the same
network segment, the Layer-2 Eth-Trunk interface is used.
2. Assign interfaces to security zones and configure security policies.
Procedure
# Create a Layer-2 Eth-Trunk interface.
<FW> system-view
[FW] sysname FW_A
[FW_A] interface eth-trunk 1
[FW_A-Eth-Trunk1] portswitch
[FW_A-Eth-Trunk1] port link-type access
[FW_A-Eth-Trunk1] quit
# Add a physical interface into the Eth-Trunk interface.

[FW_A-GigabitEthernet1/0/1] eth-trunk 1
[FW_A-GigabitEthernet1/0/2] eth-trunk 1
# Assign interfaces to security zones.

[FW_A-zone-untrust] add interface eth-trunk 1

# Configure security policies.

[FW_A-policy-security-rule-policy_sec_1] source-zone trust
[FW_A-policy-security-rule-policy_sec_1] destination-zone trust

The configuration of FW_B is similar to that of FW_A. The configuration details are not
provided.
----End
View Eth-Trunk 1 information on FW_A.
<FW_A> display trunkmembership eth-trunk 1
Trunk ID : 1
Used Status : VALID
TYPE : Ethernet
Working Mode : Load-balance
Working State : Normal
Number Of Ports In Trunk : 2
Number Of Up Ports In Trunk : 2
Operate Status : Up
Interface GigabitEthernet1/0/1, valid, operate up, weight=1,standby interface NULL

Interface GigabitEthernet1/0/2, valid, operate up, weight=1,standby interface NULL
The previous information shows that GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 have
already become member interfaces of Eth-Trunk 1.
Use a PC in LAN 1 and a PC in LAN 2 to ping each other. Check whether the two PCs can
ping each other. If they fail to ping each other, modify the configuration and try again.
#
sysname FW_A
#
interface Eth-Trunk1
portswitch
#
portswitch
eth-trunk 1
portswitch
eth-trunk 1
#
firewall zone trust
set priority 85
#

set priority 5
add interface Eth-Trunk1
#
security-policy
source-zone trust
source-zone untrust
action permit
#
return
4.1.5 Troubleshooting for Interface Faults

This section describes how to troubleshoot interface problems.
4.1.5.1 Physical Status of an Electronic Ethernet Interface Cannot Be Up

This section describes the troubleshooting flow when the physical status of the electronic
Ethernet interface cannot go Up.
Symptom
Figure 4-13 shows the networking diagram for the Ethernet interface. The indicator
connected to the interface is off, or the physical status of the FW is Down.
Figure 4-13 Networking diagram for the Ethernet interface
GE1/0/1 GE1/0/1
NGFW_A NGFW_B
Possible Causes
The possible causes are as follows:
l Cause one: Faults occur in the cable.

l Cause two: The shutdown command is executed on an interface.
l Cause three: The auto negotiation protocols of the forwarding layer chips on the devices
on both ends are inconsistent.
l Cause four: The interfaces on both ends are configured with different rates or working
modes.
l Cause five: A subcard of the FW fails.
Fault Diagnosis
Figure 4-14 shows the troubleshooting flow when the electronic interface cannot go Up.

Figure 4-14 Flowchart for troubleshooting the fault that the electronic interface cannot go Up
The indicator of the
interface is off.
Yes Yes
Is the cable faulty? Replace the cable. Is the fault rectified?
No
No
Is the shutdown Yes Yes

Run the undo
command executed on Is the fault rectified?
shutdown command.
the interface?
No
No
Is auto Yes Configure the
negotiation adopted by
mandatory rate and
interfaces at both
duplex mode. Yes
ends?
Is the fault rectified?
No
Are the rates

Yes Configure the same
and working modes of
rate and duplex mode
interfaces at both ends
respectively.
inconsistent?
No
No
Yes Replace the local Yes

Is the interface card
interface or interface Is the fault rectified?
faulty?
card.
No
No
Replace the remote Yes

interface or interface Is the fault rectified?
card.
No
Seek technical
End
support
Procedure
l Run the display interface GigabitEthernet interface-number command in the user or
system view to view the current running status of the interfaces of FWs on both ends.
For example, run the display interface GigabitEthernet 1/0/1 command on FW_A.

<FW_A> display interface GigabitEthernet

1/0/1
UP
Line protocol current state : Administratively
DOWN
Description : GigabitEthernet1/0/1 Interface, Route Port
The Maximum Transmit Unit is 1500 bytes, Hold timer is
10(sec)
Internet Address is
10.11.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0022-
b130-0001
Media type is twisted pair, loopback not set, promiscuous mode not
set
1000Mb/s-speed mode, Full-duplex mode, link type is auto negotiation
Max-bandwidth : 1000000 Kbps
Output queue : (Urgent queue : Size/Length/Discards)
0/50/0
Output queue : (Frag queue : Size/Length/Discards)
0/1000/0
Output queue : (Protocol queue : Size/Length/Discards)
0/1000/0
Output queue : (FIFO queue : Size/Length/Discards)
0/256/0
---- More ----
The preceding command output shows the following information:

– auto negotiation: the negotiation mode of the current interface
– 1000Mb/s: the interface rate after auto negotiation is performed
– full-duplex mode: the working mode of the interface
The preceding command output contains the following fields:
– current state: current interface physical status:
n UP: The physical status of the interface is normal.
n Administratively DOWN: The interface is shut down manually. The
shutdown command is executed on an interface.
If Administratively DOWN is displayed, go to Cause two.
n DOWN: The interface is not started.
If the status of the interface is Down, perform all steps except Cause two.
– Link type: negotiation mode of the interface:
n auto negotiation: The interface is enabled with auto negotiation.
If auto negotiation is displayed and the cable and subcard hardware are
working properly, go to Cause three.
n negotiation disable: The interface is configured with the mandatory rate and
mandatory working mode, and no negotiation is needed.
If negotiation disable is displayed and the cable and subcard hardware are
working properly, go to Cause four.
– Current BW: rate of the interface.
– full-duplex mode: The interface is working in full-duplex mode.
– Loopback: none: The loopback function is disabled. The loopback command is
used to test whether the hardware of the interface is faulty. If not fault occurs,
disable the Loopback function.
l Cause one: Faults occur in the cable.

a. Run the loopback command in the interface view.

b. Run the display interface interface-type interface-number command to view the
physical status of the interface.
If the physical status of the interface is Up, local hardware works properly. The
cable may be abnormal and needs to be replaced.
l Cause two: The shutdown command is executed on an interface.
a. Run the undo shutdown command on the interface to start the interface.
l Cause three: The auto negotiation protocols of the bottom chips on the devices on both
ends are inconsistent.
a. Run the speed and duplex commands in the interface view on both ends.
For example, you can configure the rate as 100 Mbit/s and the negotiation mode as
full-duplex on FW_A.
Run the speed 100 and duplex full commands in the interface view of FW_A. Run
the display this command in the interface view of FW_A to view the interface
configuration.
[FW_A-GigabitEthernet 1/0/1] display
this
#
interface GigabitEthernet
1/0/1
speed
100
duplex
full
return
l Cause four: The interfaces on both ends are configured with different rates or working
modes.
a. Check whether the configured rates and working modes of the interfaces on both
ends are consistent. If the rates and working modes are inconsistent, change them to
the same settings.
l Cause five: A subcard of the FW fails.
a. Run the loopback command in the interface view.
b. Run the display interface interface-type interface-number command to view the
physical status of the interface.
If the physical status of the interface is Down, hardware is abnormal.
c. Run the undo loopback command to disable the loopback function.
NOTE
After testing and troubleshooting the cable or hardware, run the loopback command to
disable the loopback function.
d. Replace the interface on the local device. If possible, replace the original interface
with an interface of another subcard of the same type. Then, check whether the fault
is removed.
n If the fault persists, go to e.
n If the fault does not occur on other subcards, contact technical support
personnel to repair the faulty subcard.

e. Replace the interface on the remote device. If possible, replace the original interface
with an interface of another subcard of the same type. Then, check whether the fault
is removed. If the fault persists, contact technical support personnel to repair the
faulty subcard.
----End
4.1.5.2 Physical Status of an Optical Interface Cannot Be Up

This section describes the troubleshooting flow when the physical status of an optical
interface cannot be Up.
Symptom
NOTICE
When maintaining devices that have optical modules or interfaces, note the following issues:
l Do not look into the fiber connector when installing and maintaining fibers.
l Do not look into the fiber connector without eye protection when replacing a pluggable
optical module.
l Wear an electrostatic discharge (ESD) wrist strap when replacing a pluggable optical
module.
l Only engineers with professional training are allowed to operate optical modules or fibers.
Configure the subcard on which the optical interface resides on the FW with the SFP optical
or electronic module.
After optical interfaces are interconnected, the LINK indicator is off, or the interface is in
Down state. Figure 4-15 shows the typical networking.
Figure 4-15 Networking diagram for the optical interface

ODF ODF
Receive Send
Send Receive
NGFW_A NGFW_B
Possible Causes
l Cause one: The optical modules or fibers on both ends are inconsistent.
l Cause two: An optical fiber or module is abnormal.
l Cause three: The interface configurations on both ends are inconsistent.
l Cause four: An interface or a subcard fails.

Fault Diagnosis
Figure 4-16 Flowchart for troubleshooting the fault that the physical status of the optical
interface cannot be Up
The optical interface
cannot be in Up state.
Change to the
Does the optical No Yes
optical module and
module match the LPU Is the fault rectified?
fibers that match
and fibers? each other.
No
Yes
No Yes
Are the fibers normal? Replace the fibers. Is the fault rectified?
No
Yes
Adjust the received

Is the sent optical No and sent optical Yes
power of the optical power of the optical Is the fault rectified?
module normal? module or replace
the optical module.
No
Yes
Are the No Configure the Yes

configurations of rate and duplex Is the fault rectified?
interfaces at both ends mode.
consistent?
Yes No
No Yes
Is the interface card or Replace the
Is the fault rectified?
slot normal? interface card.
No
Yes
Seek technical End

support.
When troubleshooting faults, you may use tools, meters, and materials listed in Table 4-27.

Table 4-27 Tools, meters, and materials
Tools, Meters, and Model Mandatory Accessories or

Materials Remarks
Optical power meter OLP-55 (ACTERNA) The model is included.
Procedure
l Run the display interface command on both ends to view the current status of the
interfaces.
For example, run the display interface GigabitEthernet 1/0/1 command on FW_A.
[FW_A] display interface GigabitEthernet 1/0/1
GigabitEthernet1/0/1 current state : DOWN
Line protocol current state : Administratively DOWN
a100-0008
Media type is SFP,Loopback not set,promiscuous mode not set
Vendor Name: huawei
Vendor PN: 02310CRM
SN: AD1342R001C
Transceiver max BW: 1G
Transceiver Mode: SingleMode
WaveLengh: 1310nm
Transmission Distance: 52km
Current SFP module temperature(0.00c/75.00c): 30.00 c
Current SFP module supply(3.09/3.50V): 3.25 V
Current SFP module Tx bias(0.00/39.95mA): 10.45
mA
Current SFP module Rx power(<8.129dBm): -4.98
dBm
Default Rx Power High Threshold: -2.97
dBm
Default Rx Power Low Threshold: -6.96
dBm
Current SFP module Tx power(<8.129dBm): -1.84 dBm
Default Tx Power High Threshold: -2.97 dBm
Default Tx Power Low Threshold: -12.19 dBm
Max-bandwidth : 1000000 Kbp
---- More ----
The preceding command output contains the following fields:
– current state: current interface physical status:

n UP: The physical status of the interface is normal.
n Administratively DOWN: The interface is shut down manually. The
shutdown command is executed on an interface.
If Administratively DOWN is displayed, go to next step.
n DOWN: The interface is not started.
If the status of the interface is Down, perform all steps except Cause one.
– Link type: negotiation mode of the interface:
n auto negotiation: The interface is enabled with auto negotiation.

n negotiation disable: The interface is configured with the mandatory rate and
mandatory working mode, and no negotiation is needed.
– full-duplex mode: The interface is working in full-duplex mode.
l Cause one: The optical modules or fibers are inconsistent.
a. Verify that the fibers for sending and receiving packets are correctly connected. If
the fibers are reversely inserted, reconnect the fibers and tightly insert the fibers to
prevent bad connections.
b. Verify that the subcard of the interface supports the module type. For example,
some interfaces only support optical modules.
c. Verify that the optical modules of the interfaces on both ends are consistent. For
example, a single-mode module cannot be connected to a multi-mode module, and
an FE optical module cannot be connected to a GE optical module.
d. Verify that the optical module and fiber are consistent. For example, a single-mode
optical module does not match a multi-mode fiber (orange), and a multi-mode
optical module does not match a single-mode fiber (light yellow).
l Cause two: The fibers or optical modules are abnormal.
You can test the input optical power based on segments by using the optical power meter
to locate the segment on which the fault occurs. If the input optical power is not in the
sensitivity range of the optical interface, a fault of the optical power may occur on the
remote end, or a fault may occur in the optical cable.
a. Remove the receiving fiber from the interface on FW_A.

b. Measure the input optical power on FW_A.
n If the input optical power is normal, the output optical power of FW_B, the
optical cable, and the packet-receiving fiber of FW A are working properly.
The optical module on FW_A may receive packets abnormally. Check whether
the optical module is tightly inserted.
If the optical module is correctly installed, replace it with a new one.
○ If the physical status of the interface is Up after the replacement, the
original optical module is abnormal, and the fault is rectified.
○ If the physical status of the interface is still Down after the replacement,
the fault is irrelevant to the optical module. Go to Cause three.
n If the input optical power is abnormal, go to c.
c. Measure the input optical power on the ODF of FW_A.
n If the input optical power is normal, the output optical power of FW_B, and
the optical cable are working properly. The packet-receiving fiber connected to
the interface of FW_A may be damaged. Replace the fiber. After the
replacement, check the physical status of the interface.
○ If the physical status of the interface is Up, the fault is rectified.
○ If the status of the interface is still Down, go to Cause three.
○ If the input optical power is abnormal, the optical cable, fiber of FW_B,
or optical module of FW_B may be abnormal. Go to d.
d. Measure the input optical power on the ODF of FW_B.
n If the input optical power is normal, a fault may occur in the optical cable.
Check the optical cable to troubleshoot the fault. After troubleshooting the
fault in the optical cable, check the physical status of the interface.


n If the input optical power is abnormal, the fiber or optical module of FW_B
may be abnormal. Replace the fiber.
After the replacement, check whether the physical status of the interface is Up.
○ If the physical status of the interface is still Down, replace the optical
module. After the replacement, check whether the physical status of the
interface is Up.
e. Repeat the previous steps to troubleshoot the fault in the optical cable of the input
optical power of FW_B.
Perform the following based on the input optical power:
– If the input optical power is lower than the indicator, clean with dust-free cotton to
ensure that the optical interface for the output optical power is free of dust.
The coupling of the optical signal in optical cables may be affected by dust or even
the optical cables are blocked. This may cause faults, such as low optical power,
low sensitivity, and no optical power.
– If the input optical power is too high, the optical module at the receiving end
receives the overload optical power. The input optical power is higher than packet-
receiving sensitivity, the bit error ratio increases, and the LINK indicator is off. Add
an optical attenuator to the packet-receiving optical fiber.
– If the input optical power is too low, the fiber or optical module at the sending end
may be damaged. Replace the fiber or optical module of the sending end.
l Cause three: The configurations of the interfaces on both ends are inconsistent.
a. Verify that interfaces on both ends have the same the negotiation mode, rate, and
duplex mode.
n If the value of the Link type field is auto negotiation, the negotiation mode of
the interfaces on both ends is auto negotiation. perform the following
operations:
○ Run the speed command in the interface view on both ends to configure
the rate.
○ Run the duplex command in the interface view on both ends to configure
the duplex mode.
In auto negotiation mode, the rates of the interfaces on both ends are different.
This may be due to that the auto negotiation protocols of the forwarding layer
chips on the devices on both ends are inconsistent. In this case, configure the
same rate and duplex mode on the devices on both ends.
For example, set the rate to 1000 Mbit/s and the negotiation mode to full-duplex on
FW_A.
[FW_A] display interface GigabitEthernet 1/0/1
DOWN
Line protocol current state : Administratively
DOWN

The Maximum Transmit Unit is 1500 bytes, Hold timer is

10(sec)
Internet Address is
10.1.8.1/24
a100-0008
Media type is SFP,Loopback not set,promiscuous mode not
set
1000Mb/s-speed mode, full-duplex mode, link type is auto
negotiation
Vendor Name: huawei
Vendor PN: 02310CRM
SN: AD1342R001C
Transceiver max BW:
1G
Transceiver Mode:
SingleMode
WaveLengh:
1310nm
Transmission Distance:
52km
Current SFP module temperature(0.00c/75.00c): 30.00 c
Current SFP module supply(3.09/3.50V): 3.25 V
Current SFP module Tx bias(0.00/39.95mA): 10.45
mA
Current SFP module Rx power(<8.129dBm): -4.98
dBm
Default Rx Power High Threshold: -2.97
dBm
Default Rx Power Low Threshold: -6.96
dBm
Current SFP module Tx power(<8.129dBm): -1.84 dBm
Default Tx Power High Threshold: -2.97 dBm
Default Tx Power Low Threshold: -12.19 dBm
Max-bandwidth : 1000000
Kbp
---- More ----
Run the display this command in GigabitEthernet 1/0/1 view of FW_A to view the
interface configuration.
[FW_A-GigabitEthernet 1/0/1] display this
#
speed 1000
duplex full
#
return
l Cause four: Faults occur on interfaces or cards.

a. Insert the optical module into other interfaces of the same type, and check whether
the status is Up.
If the status of the interface is still Down after several changes, perform the
following operations to check whether faults occur on the subcard.
b. Run the display device command onFWs on both ends to view the current status of
the subcard on which the interface resides.
<FW_A> display device
USG6000V4's Device status:
Slot # Type Online Register Status

Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
1 2XG8GE Present Registered Normal N/
A

The Status field shows the subcard status. If the status of the subcard is Normal,
the subcard is working properly.
If the status of the subcard is abnormal, contact technical support personnel.
----End
Suggestion and Summary

During device deployment, technical support personnel must verify that the optical module
and fiber connector comply with specified requirements and that the connection is correct,
which prevents mistakes caused by human factors.

This section provides the references about interfaces.

This section provides link aggregation references.
4.2 Interface Pairs

This section describes interface pair concepts and how configure interface pairs, as well as
provides configuration examples.
4.2.1 Overview
This section describes the basic concepts about interface pairs.
An interface pair is a pair of incoming and outgoing interfaces.
After an interface pair is formed, the traffic enters the incoming interface of the interface pair
is forwarded out of the outgoing interface in the interface pair, without routing table or MAC
address table lookup.
If the incoming and outgoing interfaces are the same interface, the packets entering the
interface are forwarded out of the same interface after being processed.
Interfaces that can form an interface pair include Layer 2 Ethernet interfaces and Layer 2 Eth-
Trunk interfaces.
4.2.2 Configuring an Interface Pair Using the Web UI

This section describes how to configure an interface pair.

Context
An interface pair is a pair of incoming and outgoing interfaces. After an interface pair is
formed, the traffic enters the incoming interface of the interface pair is forwarded out of the
outgoing interface in the interface pair, without MAC address table lookup.
Trunk interfaces.
Procedure
Step 1 Choose Network > Interface Pair.
Step 2 Click Add and create an interface pair.

Name Specifies the name of the interface pair.
Working mode Specifies the working mode of the interface.

l Inject via another interface: An interface pair has two
interfaces. Packets entering on one interface exit on the
other.
l Inject via the same interface: The interface pair has only
one interface. Packets entering the interface are forwarded
out of the same interface after being processed.
Member Select members for an interface pair.

When the working mode of the interface pair is Inject via
another interface, the two interfaces must be of the same
type.
Allowed VLAN Specifies the scope of the VLAN ID.
Status Synchronization Enables the function of status synchronization.
Advanced
Default VLAN ID Specifies the default VLAN ID.
Step 3 Click OK.
----End
4.2.3 Configuring Interface Pairs Using CLI

This section describes how to configure interface pairs using the CLI.

Context
An interface pair is a pair of incoming and outgoing interfaces. After an interface pair is
formed, the traffic enters the incoming interface of the interface pair is forwarded out of the
outgoing interface in the interface pair, without MAC address table lookup.
Trunk interfaces.
Procedure
Step 2 Run the pair-interface name name command to access the system view.
Step 3 Run the pair { interface-name1 | interface-type1 interface-number1 } { interface-name2 |

interface-type2 interface-number2 } command to add an interface to the existing interface
pair.
The interface 1 and interface 2 to be added to the interface pair must be Layer 2 interfaces.
Their working mode must has been configured to be interface pair mode by the detect-mode
inline command.
----End
4.2.4 Feature References

This section describes the references about the interface pair feature.
This section describes interface pair specifications.
Configuring Interface pairs An interface pair is a pair of Supported by all the models.
incoming and outgoing
interfaces.
After an interface pair is
formed, the traffic enters the
incoming interface of the
interface pair is forwarded
out of the outgoing interface
in the interface pair, without
routing table or MAC
address table lookup.


This section describes the versions and changes in the interface pair feature.
4.3 Security Zones

This section describes security zone concepts and how to configure a security zone.
4.3.1 Overview
A security zone or zone is a security concept introduced by the device. Most security policies
are implemented based on security zones.
Definition
A security zone is a set of the networks connected by interfaces. Users on these networks have
the same security attributes.
Purpose
In the application of network security, if the network security device checks all packets one by
one, a large number of resources are consumed and performance is severely degraded.
Moreover, it is unnecessary to check all packets. Therefore, a packet check mechanism based
on the security zone is brought forward in the network security field.
Then the network administrator can classify the network devices at the same security level
into one security zone. Since the network devices in the same security zone are at the same
security level, the FW considers that data flows in the same security zone bring no security
risks and thus no security policy is required. The FW triggers the security check and
implements security policies only on data flows between security zones.
All in all, in addition to the direct forwarding of packets, the FW supports creating security
zones, and allows the network administrator to implement security check on special packets
and enable the security function on the basis of security zones.
4.3.2 Mechanism
This section describes the security zone mechanism.
Security Zones
A security zone is a set of the networks connected by interfaces. Users on these networks have
same security attributes.
The FW considers that data flows within a single security zone are trustful and require no
security policy. The FW enforces security policies only on data flows between security zones.

The security level value ranges from 1 to 100. The larger the value, the higher the security
level.
Table 4-28 lists default security zones on the FW.
NOTE
Default security zones cannot be deleted, and their security levels cannot be reset.
You can create security zones and specify their security levels as needed.
Table 4-28 Default security zones

Zone Security Description
Name Level
Untrust 5 Defines insecure networks, such as the Internet.

zone
DMZ 50 Short for demilitarized zone. It is an area in which intranet

servers reside. Intranet servers are frequently accessed by
extranet devices but cannot proactively access the extranet,
which causes huge security risks. These servers are deployed
in a DMZ with a lower level than a Trust zone but a higher
level than an Untrust zone.
NOTE
A DMZ is an intermediate zone between a military zone and a public
zone. A DMZ zone configured on a FW is logically and physically
separated from internal and external networks.
Devices that provide network services for external users are deployed
in a DMZ zone. These devices include WWW and FTP servers. The
servers run security risks if they are placed on an external network. If
the servers are placed on an internal network, their security
vulnerabilities may provide an opportunity for external malicious
users to attack the internal network. The DMZ zone is developed to
solve the preceding problems.
Trust zone 85 An area in which intranet terminal users reside.

Zone Security Description

Name Level
Local area 100 A local zone is a device itself, including interfaces on the
(highest) device. All packets constructed on and proactively sent from
the device are regarded as from the Local area; those to be
responded and processed by the device (including the packets
to be detected or directly forwarded) are regarded as to the
Local area.
Users cannot change Local area configurations, for example,
adding interfaces to the Local area.
NOTE
A security policy for exchanging packets between the Local zone and
the security zone of a peer can be configured in the following
scenarios:
l A local device itself requires management using Telnet, web, or
SNMP NMS.
l A local device serves as a client to initiate requests or as a server
to processes requests in the FTP, PPPoE dial-up, NTP, or IPSec
VPN scenario.
An interface is added to a security zone. A network connected to the
interface is in the security zone, and the interface is in the Local zone.
Security Interzone and Directions

A security interzone describes a single traffic transmission channel that connects security
zones. A security policy is used to control traffic that passes along a channel. A security
policy delivered to an interzone takes effect on traffic that passes along the interzone, but not
on traffic traveling within the interzone.
An interzone connects any two security zones. An interzone provides a specific view, in
which firewall configurations are performed.
Traffic travels through an interzone in the following directions:
l Inbound: An interzone forwards traffic from a lower-level security zone to a higher-level
security zone.
l Outbound: An interzone forwards traffic from a higher-level security zone to a lower-
level security zone.
Although an interzone forwards packets to both parties that exchange packets, the interzone
determines a traffic direction based on the first packet.
For example, a client in a Trust zone sends the first packet to request for an HTTP connection
to a web server in an Untrust zone with a security level lower than that of the Trust zone. The
FW considers that the packet is transmitted in the outbound direction and uses an outbound
security policy to determine whether to permit or deny the packet. After the HTTP connection
is successfully established, the FW creates a session table, which records the quintuple of the
connection in a session entry. The quintuple includes the source and destination IP addresses,
source and destination port numbers, and protocol type.

If packets exchanged between the client and web server match the quintuple, the FW
processes the packets based on the outbound security policy, without re-checking the packet
transmission direction.
If a user only enables an outbound security policy for Trust-to-Untrust traffic in an interzone,
the following situations occur:
l A terminal in a Trust zone proactively initiates a connection to another terminal in an
Untrust zone. Packets replied by the Untrust zone can pass through the interzone.
l Terminals in an Untrust zone can only receive requests for connections initiated by
terminals in a Trust zone.
4.3.3 Zone Configuration Using the Web UI

This section describes how to use the web UI to configure a security zone.
Creating a Security Zone

A FW has four default security zones. You can create security zones and define security
levels.
Step 1 Choose Network > Zone.
Step 2 Click Add.
Step 3 Set the following security zone parameters.

Zone Name Name of a security zone. The name of the security zone cannot
be changed once it is configured.
The value must be different from the name of an existing
security zone.
Priority Priority of a security zone. The priority cannot be changed

once it is configured. The higher the priority, the higher the
security level.
The value must be different from the priority of an existing
security zone.
Description Description of a security zone.

To help users learn about a security zone, enter a meaningful
description. Use a specific description for each security zone.
Step 4 Click OK.

Repeat the previous operations to create more security zones with different security levels.
----End
Assigning Interfaces to Security Zones

You have to add interfaces to a security zone, except a local zone, before using the security
zone. After that, all packets on the interface are considered as in the security zone.

An interface can only be assigned to a single security zones.
NOTE
A Local zone defines a device itself, including the interfaces on the device. Although an interface is
assigned to a security zone, only the network connected to the interface is in the security zone, and the
interface is in the Local zone.
Step 1 Choose Network > Zone.
Step 2 Perform either of the following methods to enter the operation page before adding interfaces
to security zones:
l When creating a security zone, perform operations on the Add Zone page.
l Click of the line where the entry to be modified resides and enter the Modify Zone
operation page.
Step 3 In Select Zone Interface, perform one of the following operations:
l On the Un-Added Interface page, double-click a desired interface. This interface
appears in the Added Interface window.
l On the Un-Added Interface page, select a desired interface and click . This interface
appears in the Added Interface window.
l Click to assign all interfaces to the current security zone.

Step 4 Click OK.
----End
4.3.4 Zone Configuration Using the CLI

This section describes how to use a command line interface (CLI) to configure a security
zone.
Creating a Security Zone and Adding an Interface to It

A system has four default security zones. You can create security zones and define security
levels. After creating a security zone, add an interface to it. After that, all packets on the
interface are considered as in the security zone. An interface does not belong to any security
zone by default and is unable to communicate with interfaces in security zones.
Specify the priority after creating a security zone. If no priority is set, you cannot proceed
with other security zone configurations.

system-view
Step 2 Create a security zone and display the security zone view.
firewall zone [ name ] zone-name
The name parameter is configured based on the following situations:

l A security zone already exists.
Run this command without the name parameter configured to enter the security zone
view.

l No security zone exists.

Run this command with the name parameter to create a security zone and enter the
security zone view.
Default security zones cannot be deleted.
Step 3 Set a priority value for the created security zone.

set priority security-priority
Set a security level (priority) for a security zone based on the following rules:
l A security level is only set for a user-defined security zone. A new security zone without
a security level configured cannot take effect.
l A security level cannot be changed after being configured.
Step 4 Assign an interface to a security zone.

add interface interface-type interface-number
Add an interface to a security zone based on the following rules:
l Interfaces can only be manually assigned to security zone, except for the Local zone.
l Either a physical or logical interface can be assigned to a security zone.
l A maximum of 1024 interfaces can be assigned to a security zone.
Step 5 Optional: Configure the description of the security zone.

description text
Appropriate descriptions help the administrator learn system configurations and device
maintenance.
----End
Entering the Security Interzone View

The device performs security checks only on data flows between security zones. Before
controlling traffic between security zones, enter the security interzone and apply various
security policies.
Two related security zones must be already created. For details, see Creating a Security
Zone and Adding an Interface to It.
After a new security zone is created, the view of the interzone between the security zone and
another security zone is automatically created.

system-view
Step 2 Display the view of the interzone between two security zones.
firewall interzone zone-name1 zone-name2
Security policy checks are triggered when the data flows in security interzones. After entering
the security interzone view, you can configure security functions, such as application specific
packet filter (ASPF).
----End

Maintaining Security Zones

By checking the configurations and traffic status of security zones, you can learn the network
status and determine how to deploy security policies in an interzone.
Table 4-29 lists the commands used to display security zone configurations.
Table 4-29 Displaying security zone configurations
Action Command
Display information about display zone [ zone-name ] [ interface | priority ]

existing security zones, their
security levels, and added
interfaces.
Display information about display interzone [ zone-name1 zone-name2 ]

security policies configured in
a security interzone.
4.3.5 Feature References
This section describes security zone specifications.
Default security zone Untrust, DMZ, Trust, and Supported by all models.
Local
Number of default security zones 4
Maximum user-defined security zone 100

priority

This section describes the versions and changes in the security zone feature.

4.4 PPP
This section describes Point-to-Point Protocol (PPP) concepts and how to configure PPP.
4.4.1 Overview
The Point-to-Point Protocol (PPP) is a data link-layer protocol used to transmit and
encapsulate network layer packets on point-to-point (P2P) links.
Definition
A P2P connection is a simple WAN connection. Link layer protocols for PPP links are as
follows:
l PPP: supports both synchronous and asynchronous transmission.
l High-level Data Link Control protocol (HDLC): only supports synchronous
transmission.
PPP defines a set of protocols:
l Link Control Protocol (LCP): used to establish, monitor, and terminate data links.
l Network Control Protocol (NCP): used to establish and configure different network layer
protocols and negotiate the format and type of packets transmitted over data links.
l Authentication protocols: include Password Authentication Protocol (PAP) and
Challenge-Handshake Authentication Protocol (CHAP).
Objective
Located at the data link layer of the Open Systems Interconnection (OSI) model, PPP
supports both synchronous or asynchronous full-duplex links to transmit data. PPP is widely
used because it has the following advantages:
l Provides user authentication.
l Supports synchronous and asynchronous communications.
l Is easily expanded.
4.4.2 Applications
This section describes the application scenario of PPP.
Application Environment
When a FW functions as the enterprise egress gateway, the LAN-side interface connects to a
host on the intranet and the WAN-side interface connects to a carrier's device. The carrier's
device can be a digital subscriber line access multiplexer (DSLAM), an optical line terminal
(OLT), or a wireless base station, depending on the WAN-side interface type.

Typical Application
PPP can be used in the following scenarios:
l FW_A connects to the WAN-side interface of FW_B using a PPP link. FW_A obtains
the IP address allocated by a carrier's device, through IPCP negotiation in the PPP link
establishment process, and connects to the WAN. PPP links are widely used for
communication between enterprise branches and the headquarters.
Figure 4-17 Communication over a PPP link
POS1/0/0 POS1/0/0
Branch Headquarters
FW_A FW_B
l PPP can be used with other technologies to provide various services. such as PPPoE.
4.4.3 Mechanism
This section describes the mechanism of Point-to-Point Protocol (PPP).
PPP Operation Process

The PPP link is established through a series of negotiation.
PPP-enabled devices on two ends of a link must send LCP packets to set up a P2P link. After
the LCP configuration parameters have been negotiated, the two communicating devices
choose the authentication mode according to the authentication parameters in the Configure-
Request packets.
By default, the devices on the two ends do not authenticate each other. After the negotiation
of the LCP configuration parameters, the devices negotiate NCP configuration parameters
without any authentication. After all the negotiations, the two devices on the P2P link can
transmit network-layer packets, and the whole link is available.
A link is torn down and a PPP session ends if one of the following situations occurs:
l The device on either end receives an LCP or an NCP Terminate frame that aims at
closing the link.
l The physical layer cannot detect a carrier.
l The network administrator shuts down the link.
Typically, NCP should not necessarily have the capability in closing links. Therefore, the
packet used to close a link is usually sent during the LCP negotiation or application program
session.
Figure 4-18 shows the setup process of a PPP session and status transition.

Figure 4-18 PPP operation process
UP OPENED
Dead Establish Authenticate
SUCCESS/NONE
FAIL FAIL
DOWN CLOSING
Terminate Network
The PPP operation process is described as follows:
l the Link Establishment phase is the first phase to set up a PPP link.
l LCP negotiation is performed, during which the working mode, MRU, authentication
mode, magic number, and asynchronous character mapping are negotiated. The working
mode can be Single-link PPP (SP) or Multilink PPP (MP). If the LCP negotiation is
successful, the LCP status turns to Opened.
l If no authentication is configured, the communicating devices directly enter the NCP
negotiation phase. If authentication is configured, the communicating devices enter the
Authentication phase and perform CHAP or PAP authentication.
l If the authentication fails, the devices enter the Terminate phase and disconnect the link,
and LCP status becomes Down. If the authentication is successful, the devices enter the
NCP negotiation phase. The LCP status remains Opened, whereas the NCP status
changes from Inital to Starting.
l The devices run an NCP protocol to negotiate parameters. The NCP suite includes the
Internet Protocol Control Protocol (IPCP), Multiprotocol Label Switching Control
Protocol (MPLSCP), and Open System Interconnection Control Protocol (OSCICP).
Devices run IPCP to negotiate IP addresses. A network layer protocol is selected during
NCP negotiation. The network layer protocol sends packets over the PPP link only after
negotiation of the network layer protocol is successful.
l The PPP link remains in Up until an LCP or NCP frame is generated to close the link or
traffic is interrupted.
A PPP link undergoes the following phases:
l Link Dead phase

The Link Dead phase is also called the unavailable phase. During this phase, there is no
physical layer link established between two devices. PPP link setup always begins and
ends with the Link Dead phase.
After the communicating devices on both ends detect that a physical link is activated,
generally, the carrier signal is detected on the link, and the devices enter the Link
Establishment phase.
In the Establish phase, link parameters are set mainly by using LCP. The state machine
of LCP changes according to the events. If a link is in the Link Dead phase, the LCP
status is Initial or Starting. After the link becomes available, the LCP status changes.

After a link is torn down, the link returns to the Link Dead phase. In real-world
situations, this state does not last long and is only used to detect the existence of a peer
device.
l Link Establishment phase
The Link Establishment phase is the most complex PPP phase.
The two devices on both ends of a PPP link exchange packets, which do not include
network layer protocol parameters. Both devices enter the next phase.
The next phase can be Authentication phase or Network-Layer Protocol phase. The next
phase is selected according to the configuration on both the devices. It is usually
configured by the user.
In the Link Establishment phase, the LCP state machine changes twice:
– When the link is in the Link Dead phase, the LCP state machine is in the status of
Initial or Starting. If the link is Up, the physical layer sends an Up event in a packet
to the data link layer. The data link layer changes the LCP status to Request-Sent.
LCP then sends Configure-Request packets to configure a data link.
– After one end receives the Configure-Ack packet, the LCP status changes to
Opened. The link enters the next phase.
Note that the link configurations on both ends are mutually independent. In the Link
Establishment phase, devices discard non-LCP packets.
l Authentication phase
Authentication is performed before devices on both ends enter the Network-Layer
Protocol phase.
PPP authentication is disabled by default. To enable authentication, specify an
authentication protocol in the Link Establishment phase.
PPP authentication is used on the following two types of links:
– Non-leased lines between hosts and devices
– Leased lines
PPP provides the following two authentication modes:
– PAP: Password Authentication Protocol
– CHAP: Challenge-Handshake Authentication Protocol
The authentication mode used is determined based on negotiation performed during the
Link Establishment phase. Link quality detection is also performed in the Link
Establishment phase. According to the PPP protocol, detection delays the authentication
process within a specified period of time.
The link control protocol, authentication protocol, and quality detection packets are
supported in the Authentication phase. The packets of other types are discarded. If a
device receives a Configure-Request packet in the Authentication phase, the link restores
the Link Establishment phase.
l Network-Layer Protocol phase
Network protocols, such as IP, IPX, and AppleTalk, are negotiated using NCPs, which
can be enabled or disabled during any phase. After an NCP state machine turns to
Opened, PPP links can transmit network layer packets.
If a device receives a Configure-Request packet in the Network-Layer Protocol phase,
the device and its peer device enter the Link Establishment phase.
l Termination phase

PPP can terminate links at any time. In addition, a network administrator can manually
disconnect links. Carrier connection loss, authentication failures, or link-quality
detection failures can cause link disconnections. When devices exchange LCP Terminate
frames during the Link Establishment phase, the link in question is torn down. Therefore,
NCP does not need to close a PPP link.
PAP
PAP supports two-way handshake authentication and simple passwords. The authentication
process is performed in the Link Establishment phase.
After the Link Establishment phase is complete, the user name and password of a supplicant
are repeatedly sent to the authenticator until authentication is successful or the link is ended.
PAP authentication is the optimal option when a password transmitted in plain text must be
used to simulate logging into a remote host.
Figure 4-19 shows the PAP authentication process.
Figure 4-19 PAP authentication process
Authenticated Authenticator
Authenticate-Request
My user name and password are……
Authenticate-Ack
I found your name and password in my user

list. Authertication succeeded!
Authenticate-Nak
Sorry,your user name and

password are wrong.
Authentication failed!
The PAP authentication process is as follows:
1. The supplicant sends the local user name and password to the authenticator.

2. The authenticator checks the user list for the user name and whether the password is
correct and returns an appropriate response.
PAP is an unsecured protocol. Simple passwords are sent over links. After a PPP link is
established, the supplicant repeatedly sends the user name and password until authentication
is complete, which could leave the system vulnerable to malicious attacks.
CHAP
CHAP is a three-way handshake authentication protocol. CHAP authentication only allows
user names to be transmitted over a network. Compared with PAP, CHAP provides higher
security because passwords are not transmitted.
CHAP authentication is generally performed before the link is set up. However, it can be
performed at any time using CHAP negotiation packets.
After the Link Establishment phase ends, an authenticator sends a Challenge packet to a
supplicant. After performing the "one-way hash" algorithm, the supplicant returns a calculated
value to the authenticator.
The authenticator compares the value it itself has calculated using the hash algorithm with the
value provided by the supplicant. If the two values match, authentication is successful. If the
values do not match, the authentication fails, and the link is torn down.
Figure 4-20 shows the CHAP authentication process.
Figure 4-20 CHAP authentication process
Authenticated Authenticator
Challenge
My user name (optional) and

Challenge packet are……
Response
My user name and

encrypted packet are
Success
Authentication succeeds and

a Success packet returns
Failure
Authentication fails and a

Failure packet returns

CHAP authentication is performed in either of the following modes:
l Unidirectional: One end acts as the authenticator, while the other end acts as a
supplicant.
l Bidirectional: Two ends act as both the authenticator and supplicant.
Unidirectional authentication is usually used.
There are two possible scenarios for unidirectional CHAP authentication: the authenticator is
configured with a user name and the authenticator is not configured with a user name.
Configuring a user name for the authenticator is recommended for improved connection
security.
l When the authenticator is configured with a user name, the authentication process is as
follows:
a. The authenticator sends a randomly generated Challenge packet and the host name
to the supplicant.
b. The supplicant searches for the local password in the local user list according to the
user name of the authenticator. Based on the found password and the Challenge
packet, a supplicant obtains a value calculated using the message digest algorithm 5
(MD5) algorithm. The supplicant then sends its host name and the calculated value
in a response packet to the authenticator.
c. After receiving the response packet, the authenticator searches for the supplicant's
password in the local user list based on the supplicant's host name. After locating
the password, the authenticator uses the Challenge packet and the password of the
authenticated to obtain a value through the MD5 algorithm, compares the value
with that in the received Response packet, and then returns the authentication result,
that is, allow or deny.
l When the authenticator is not configured with a user name, the authentication process is
as follows:
a. The authenticator sends the Challenge packet to a supplicant.
b. The supplicant uses the message digest algorithm 5 (MD5) algorithm to calculate a
value based on the local password and the Challenge packet. The supplicant then
sends its host name and the calculated value in a response packet to the
authenticator.
c. The authenticator searches for the supplicant's password in the local user list based
on the supplicant's host name.
4.4.4 Configuring PPP

PPP provides communications on point-to-point links and supports PAP and CHAP
authentication.
4.4.4.1 Encapsulating the Interface with PPP

This section describes how to encapsulate the interface with PPP. You can configure PPP to
use PPP encapsulation to transmit packets over a point-to-point link at the data link layer.

Procedure
system-view
Step 2 Display the interface view.

Only the dialer interface supports PPP.

Step 3 Configure PPP as a data link layer protocol.
link-protocol ppp
By default, PPP is used as a data link layer protocol of dialer interfaces.
----End
4.4.4.2 Configuring PAP Authentication

This section describes how to configure Password Authentication Protocol (PAP)
authentication. PAP uses simple passwords.
Prerequisites
A FW functions as an authenticator and uses PAP to authenticate its peer. PAP authentication
is performed locally on the authenticator or on a remote authentication server. To implement
PAP authentication, configure user accounts and the authentication mode. If remote
authentication is used, configure an authentication server as well.
Context
PAP uses simple passwords and is the least secure authentication protocol. After a PPP link is
established, the device to be authenticated repeatedly sends a user name and a password until
authentication is complete. During PAP authentication, the transmitted user name and
password are susceptible to monitoring.
By default, PPP packets are not authenticated.
Procedure
l Configure an authenticator to authenticate the peer end in PAP mode.
a. Display the system view.
system-view
b. Display the interface view.

c. Configure the local end to authenticate its peer end in PAP mode.
ppp authentication-mode [ chap ] pap
The ppp authentication-mode chap pap command enables CHAP negotiation to

take precedence over PAP negotiation during LCP negotiation. If the authenticator
supports neither of these two modes, negotiation fails.
l Configure the peer end to perform PAP authentication.
a. Display the system view.
system-view

b. Display the interface view.

c. Enable the local end to be authenticated by the peer end in PAP mode and send a
PAP user name and a password.
ppp pap local-user user-name password cipher password
4.4.4.3 Configuring CHAP Authentication

This section describes how to configure Challenge Handshake Authentication Protocol
(CHAP) authentication. CHAP is a three-way handshake authentication protocol.
Prerequisites
A FW functioning as an authenticator supports local and remote authentication. If local
authentication is used, you must configure a user account and an authentication mode. If
remote authentication is used, you must also configure an authentication server.
If the FW is a supplicant, you must configure a user name and an authentication mode. And
an authentication server also needs to be configured if remote authentication is used.
Context
Devices enabled with CHAP authentication only transmit user names over a network. CHAP
supports higher security than the Password Authentication Protocol (PAP) because passwords
are not transmitted.
By default, Point-to-Point Protocol (PPP) packets are not authenticated using CHAP.
Procedure
l Configure an authenticator to use CHAP to authenticate the peer end when the user name
is specified.
NOTE
When an authenticator sets a user name, the authenticator must set the same password the same as
that for the authenticated end.
– Configure a FW that authenticates a peer end.
i. Display the system view.
system-view
ii. Display the interface view.

iii. Configure a local end to use CHAP to authenticate the peer end.
ppp authentication-mode chap [ pap ]
The ppp authentication-mode chap pap command enables CHAP

negotiation to take precedence over PAP negotiation during Link Control
Protocol (LCP) negotiation. If the authenticator does not support CHAP or
PAP, LCP negotiation between the two devices fails.
iv. Specify a local user name.
ppp chap user user-name
– Configure a FW that is authenticated by the local FW.


system-view

iii. Specify a local user name.

l Configure the authenticator to authenticate the peer end in CHAP mode if the user name
is not specified.
During authentication, the authenticator searches locally configured AAA user names. If
the user name and password configured on the peer interface match those on the local
end, authentication succeeds.
– Configure a FW that authenticates a peer end.
system-view

iii. Configure a local end to use CHAP to authenticate the peer end.
ppp authentication-mode chap [ pap ]
The ppp authentication-mode chap pap command enables CHAP

negotiation to take precedence over PAP negotiation during LCP negotiation.
If the authenticator does not support CHAP or PAP, LCP negotiation between
the two devices fails.
– Configure a FW that is authenticated by the local FW.
system-view

iii. Specify a local user name.

iv. Set a password for the peer end to use CHAP to authenticate the local end.
ppp chap password cipher password
4.4.4.4 Configuring Optional Functions of PPP

This section describes the configuration methods and examples of PPP negotiation
parameters, negotiation polling interval and the function of preventing the peer host route
from being added to the local routing table as a direct route.
4.4.4.4.1 Configuring the Negotiation DNS Server Address

This section describes how to configure the negotiation DNS server address.
Context
When the FW connects to a carrier's access server using PPP, the device must be configured
to accept the DNS server address specified by the access server or to request a DNS server
address from the access server. In this way, the device can connect to the network using a
domain name.

Procedure
system-view

Step 3 Configure the local end to request the peer end for the IP address of the DNS server.
ppp ipcp dns request
Step 4 Enable the device to use any DNS server address proposed by the peer end.
ppp ipcp dns admit-any
By default, the DNS server address proposed by the peer end is not accepted.
----End
4.4.4.4.2 Configuring the Negotiation WINS Server Address

This section describes how to configure the negotiation WINS server address.
Procedure
system-view

Step 3 Enable the device to use any WINS server address proposed by the peer end.
ppp ipcp nbns request
By default, the device does not request for the IP address of the WINS server from the peer
end.
----End
4.4.4.4.3 Configuring the Negotiation Timeout Period

This section describes how to configure the negotiation timeout period.
Context
In PPP negotiation, if the local end does not receive any response from the remote end within
the specified timeout period, it resends a packet. This specified timeout period is called
timeout interval.
If the negotiation timeout period is too long, link transmission efficiency decreases. If the
negotiation timeout period is too short, unnecessary packet retransmission occurs, increasing
the link load.
Therefore, the negotiation timeout period must be set properly.
Procedure

system-view

Step 3 Set the negotiation timeout period.

ppp timer negotiate seconds
By default, the PPP negotiation timeout period is 3 seconds.
----End
4.4.4.4.4 Configuring the Negotiation Polling Interval

This section describes how to configure the negotiation polling interval.
Context
The polling interval of an interface is the interval at which the interface sends Keepalive
packets.
Keepalive packets are used to monitor and maintain the link status. If an interface does not
receive any Keepalive packet after five Keepalive intervals, it considers that the link fails.
On a low-speed link, the seconds parameter cannot be set to a small value because it may take
a long time to transmit oversized packets on the link. If the interval for sending Keepalive
packets is set to a small value, transmission of Keepalive packets is delayed. If an interface
does not receive any Keepalive packet from the remote interface after five Keepalive
intervals, the interface considers that the link fails.
The negotiation polling interval must be set based on the site requirements.
Procedure
system-view

Step 3 Set the pooling interval.

timer hold seconds
----End
4.4.5 Maintaining PPP

After configuring PPP, you can run the display command to view the configuration. You can
also enable the debugging function if necessary.
Displaying the PPP Configuration

After configuring PPP, you can run the display command to view the configuration.
You can display the PPP configurations by run the command listed in Table 4-30 in any view.

Table 4-30 Displaying the PPP configuration
Action Command
Display the PPP configuration. display interface [ interface-type

[ interface-number ] ]
Debugging PPP
If PPP running faults occur, you can run the debugging commands in the user view to debug
PPP, view the debugging information, and locate and analyze faults.
Before enabling the debugging, you must run the terminal monitor command in the user
view to enable the terminal information display and the terminal debugging command in the
user view to terminal debugging information display functions.
NOTICE
Enabling the debugging deteriorates system performance. After the debugging is complete,
run the undo debugging all command to disable the debugging immediately.
For the description of the debugging commands, see Debugging Reference.
Table 4-31 lists the commands to debug PPP information.
Table 4-31 Debugging PPP
Action Command
Enable the debugging of all PPP debugging ppp all [ verbose ] [ interface
information. interface-type interface-number ]
Enable the debugging of PPP control debugging ppp { ccp | chap | ipcp | ipv6cp
protocols. | lcp | pap } { all | error | event | packet
core [ verbose ] | state } [ interface interface-
type interface-number ]
Enable the debugging of PPP EAP packets. debugging ppp eap { all | error | event |
packet [ verbose ] | state } [ interface
interface-type interface-number ]
Enable the debugging of PPP packets. debugging ppp { ip | ipv6 } packet

[ verbose ] [ interface interface-type
interface-number ]
Enable the debugging of PPP core events. debugging ppp core event [ interface
interface-type interface-number ]


This section describes the application scenarios and configuration commands of PPP in
details.
4.4.6.1 Example for Configuring PAP Authentication

This example shows how to configure two devices so that one end (the authenticator) can
authenticate the other end (the authenticated) in PAP mode in typical networking.
As shown in Figure 4-21, FW_A and FW_B are connected through the Pos interface. FW_A
(the authenticator) is required to authenticate FW_B (the authenticated) in PAP mode.
Figure 4-21 Networking diagram of PAP authentication

POS1/0/0
FW_A 10.110.0.2/24
POS1/0/0
10.110.0.1/24 FW_B
1. Add the user name and password of FW_B to the local user list of FW_A.
2. Configure FW_A to authenticate FW_B in PAP mode.
3. Configure the local user name and password on FW_B.
Data Preparation
l The user name and password of FW_B
l The IP address of the interface on FW_A
l The IP address of the interface on FW_B
Procedure
Step 1 Configure FW_A
# Add the username and password of FW_B to the local user list of FW_A.
<FW> system-view
[FW] sysname FW_A
[FW_A] user-manage user userb
[FW_A-localuser-userb] password Admin@123
[FW_A-localuser-userb] quit

# Configure an IP address for Pos1/0/0 and configure the link-layer encapsulation protocol as
PPP.
[FW_A] interface pos 1/0/0
[FW_A-Pos1/0/0] ip address 10.110.0.1 255.255.255.0
NOTE
l When you configure an IP address for an interface on a PPP link, if you delete the IP address of the
interface on the PPP link that fulfills the IPCP negotiation and assign this IP address to an interface
on another PPP link, the IPCP negotiation of the later PPP link is definitely unsuccessful. To solve
this problem, you can run the shutdown and undo shutdown commands on the former interface to
restore the IPCP negotiation or assign a new IP address to the later interface.
l When you configure an IP address for an interface on a PPP link, if the configuration is correct but
the negotiation is always unsuccessful, it is recommended that you assign a new IP address to the
interface.
[FW_A-Pos1/0/0] link-protocol ppp
# Authenticate FW_B in the PAP mode.

[FW_A-Pos1/0/0] ppp authentication-mode pap
# Restart the interface.

[FW_A-Pos1/0/0] shutdown
[FW_A-Pos1/0/0] undo shutdown
[FW_A-Pos1/0/0] quit
# Add Pos1/0/0 to the Trust zone.

[FW_A-zone-trust] add interface pos 1/0/0


PPP.
<FW> system-view
[FW] sysname FW_B
[FW_B] interface pos 1/0/0
[FW_B-Pos1/0/0] ip address 10.110.0.2 255.255.255.0
[FW_B-Pos1/0/0] link-protocol PPP
# Configure the username and password sent to the authentication object in the PAP mode.
[FW_B-Pos1/0/0] ppp pap local-user userb password cipher Admin@123

[FW_B-Pos1/0/0] shutdown
[FW_B-Pos1/0/0] undo shutdown
[FW_B-Pos1/0/0] quit

[FW_B] firewall zone trust

[FW_B-zone-trust] add interface pos 1/0/0
[FW_B-zone-trust] quit

[FW_B] security-policy
[FW_B-policy-security] rule name policy_sec_1
[FW_B-policy-security-rule-policy_sec_1] source-zone local
[FW_B-policy-security-rule-policy_sec_1] source-zone trust
[FW_B-policy-security-rule-policy_sec_1] destination-zone local
[FW_B-policy-security-rule-policy_sec_1] action permit
[FW_B-policy-security-rule-policy_sec_1] quit
[FW_B-policy-security] quit
Step 3 Verify the configuration.

After the configuration is completed, executing the display interface command on every
FW_A, you can see both LCP and IPCP are in Opened state.
Take FW_A as an example.
[FW_A] display interface pos 1/0/0
Pos1/0/0 current state : UP
Last up time: 2007-11-03, 12:36:19
Description: Pos1/0/0 Interface
Route Port,The Maximum Transmit Unit is 4470, Hold timer is 10(sec)
Link layer protocol is PPP
LCP opened, IPCP opened
The Vendor PN is FTRJ1321P1BTL
Port BW: 2.5G, Transceiver max BW: 2.5G, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 5km
Rx Power: -3.91dBm, Tx Power: -1.87dBm
Physical layer is Packet Over SDH
Scramble enabled, clock master, CRC-32, loopback: none
Flag J0 "NetEngine "
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
section layer: B1 21424008
line layer: B2 1093838510 REI 705143440
path layer: B3 45521365
Statistics last cleared:never
Input error: 10 shortpacket, 0 longpacket, 143 CRC, 0 lostpacket
Output error: 0 lostpackets
Output error: 0 overrunpackets, 0 underrunpackets
----End
Configuration Files
l Configuration file of FW_A
#
sysname FW_A
#
interface Pos1/0/0
link-protocol ppp
undo shutdown

ppp authentication-mode pap

ip address 10.110.0.1 255.255.255.0
#
firewall zone trust
set priority 85
add interface Pos1/0/0
#
security-
policy
default action permit
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action permit
#
return
l Configuration file of FW_B

#
sysname FW_B
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp pap local-user userb password cipher %$%$nJ2sJbBsp7pHX:7h{[\>,.%y%$%$
ip address 10.110.0.2 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action permit
#
return
4.4.6.2 Example for Configuring Bidirectional PAP Authentication

This example shows how to configure bidirectional PAP authentication between two devices
in typical networking.
As shown in Figure 4-22,Pos1/0/0 of FW_A connects to Pos1/0/0 of FW_B.
Users want that FW_A performs simple authentication on FW_B and FW_B performs simple
authentication on FW_A.

Figure 4-22 Networking diagram of bidirectional PAP authentication

POS1/0/0
FW_A 10.110.0.2/24
POS1/0/0
10.110.0.1/24 FW_B
1. Configure PAP authentication because PAP authentication meets user's requirements of
simple authentication and low security.
2. Configure both FW_A and FW_B as the PAP authenticator and authenticated party to
meet the bidirectional authentication requirement.
NOTE
In PAP authentication, passwords are transmitted in plain text on the network, bringing potential security
risks.
Procedure
Step 1 Configure FW_A
# Assign an IP address to Pos1/0/0 and configure PPP as the link layer protocol of Pos1/0/0.
<FW> system-view
[FW] sysname FW_A
[FW_A-Pos1/0/0] ip address 10.110.0.1 24
# Set the PPP authentication mode to PAP authentication.

[FW_A-Pos1/0/0] ppp authentication-mode pap
# Configure a local user.

[FW_A] user-manage user usera
[FW_A-localuser-usera] password Huawei1
[FW_A-localuser-usera] quit
# Configure the user name and password sent from FW_A to FW_B in PAP authentication
and restart the interface.
[FW_A-Pos1/0/0] ppp pap local-user userb password cipher Huawei2



Step 2 Configure FW_B

# Assign an IP address to Pos1/0/0 and configure PPP as the link layer protocol of Pos1/0/0.
<FW> system-view
[FW] sysname FW_B
[FW_B-Pos1/0/0] link-protocol ppp
[FW_B-Pos1/0/0] ip address 10.110.0.2 24
# Set the PPP authentication mode to PAP authentication.

[FW_B-Pos1/0/0] ppp authentication-mode pap
# Configure a local user.

[FW_B] user-manage user userb
[FW_B-localuser-userb] password Huawei2
[FW_B-localuser-userb] quit
# Configure the user name and password sent from FW_B to FW_A in PAP authentication
and restart the interface.
[FW_B-Pos1/0/0] ppp pap local-user usera password cipher Huawei1


Step 3 Verify the configurations.

# Run the display interface pos 1/0/0 command to check the interface configuration. The
command output shows that both the physical layer status and link layer status of the interface
are Up and that both LCP and IPCP are in Opened state. This indicates that PPP negotiation
succeeds and that FW_A and FW_B can ping each other successfully.
[FW_B] display interface pos 1/0/0


Last line protocol up time : 2011-03-25 11:35:10
Description:HUAWEI, FW Series, Pos1/0/0 Interface
Last physical up time : 2011-03-25 11:35:10
Last physical down time : 2011-03-25 11:35:01
Current system time: 2011-03-25 17:30:07
Physical layer is synchronous, Virtualbaudrate is 64000 bps
Interface is DTE, Cable type is V35, Clock mode is DTECLK1
Last 10 seconds input rate 7 bytes/sec 56 bits/sec 0 packets/sec
Last 10 seconds output rate 7 bytes/sec 56 bits/sec 0 packets/sec
Broadcast: 0, Multicast: 0
Errors: 0, Runts: 0
Giants: 0, CRC: 0
Alignments: 0, Overruns: 0
Dribbles: 0, Aborts: 0
No Buffers: 0, Frame Error: 0

Total Error: 0, Overruns: 0
Collisions: 0, Deferred: 0
No Buffers: 0
DCD=UP DTR=UP DSR=UP RTS=UP CTS=UP

----End
Configuration Files
#
sysname FW_A
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp pap local-user userb password cipher %$%$nJ2sbcJp7pHX:7h{[\>,.%sh%$%$
ip address 10.110.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action permit
#
return

#
sysname FW_B
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp pap local-user usera password cipher %$%$nJ2sJbBsp7pHX:7h{[\>,.%y%$%$
ip address 10.110.0.2 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action permit
#
return
4.4.6.3 Example for Configuring Unidirectional CHAP Authentication

This example shows how to configure two devices so that one end (the authenticator) can
authenticate the other end (the authenticated) in CHAP mode in typical networking.
As shown in Figure 4-23, FW_A is required to authenticate FW_B in CHAP mode and
should be configured with a user name.
Figure 4-23 Networking diagram of unidirectional CHAP authentication

POS1/0/0
FW_A 10.110.0.2/24
POS1/0/0
10.110.0.1/24 FW_B
1. Add the user name and password of FW_B to the local user list of FW_A.
2. Configure the local user name for FW_A.
3. Configure FW_A to authenticate the peer in CHAP mode.

4. Add the user name and password of FW_A to the local user list of FW_B.
5. Configure the local user name for FW_B.
Data Preparation
l Local user name of FW_A
l Local user name and password of FW_B
l IP address of the interface on FW_A
l IP address of the interface on FW_B
Procedure
<FW> system-view
[FW] sysname FW_A
[FW_A-localuser-userb] password Password1
PPP.
NOTE
interface.
# Configure the local to authenticate the peer in CHAP mode.

[FW_A-Pos1/0/0] ppp authentication-mode chap
# Configure the local username of FW_A

[FW_A-Pos1/0/0] ppp chap user usera



Step 2 Configure FW_B

# Add the user name of FW_A and the local password to the local user list of FW_B.
[FW] sysname FW_B
[FW_B] user-manage user usera
[FW_B-localuser-usera] password Password1
# Configure the IP address for Pos1/0/0 and configure the link-layer encapsulation protocol as
PPP.
NOTE
interface.
# Configure the peer to authenticate the local in CHAP mode.

[FW_B-Pos1/0/0] ppp chap user userb



[FW_B-policy-security-rule-policy_sec_1] destination-zone trust

After the configuration is complete, running the display interface command on every FW,
you can find the LCP state is LCP opened. Take the FW_A as the example.


Last up time: 2007-11-03, 12:36:19
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
line layer: B2 1093838510 REI 705143440
----End
Configuration Files
#
sysname FW_A
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp authentication-mode chap
ppp chap user usera
ip address 10.110.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action

permit
return

#
sysname FW_B
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp chap user userb
ip address 10.110.0.2 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action
permit
#
return
4.4.6.4 Example for Configuring Bidirectional CHAP Authentication

This example shows how to configure bidirectional CHAP authentication between two
devices in typical networking.
As shown in Figure 4-24, FW_A and FW_B need to perform bidirectional CHAP
authentication.
Figure 4-24 Networking diagram of bidirectional CHAP authentication

POS1/0/0
FW_A 10.110.0.2/24
POS1/0/0
10.110.0.1/24 FW_B

1. Configure the local user lists on FW_A and Route B.

2. Configure local user names for FW_A and FW_B.
3. Enable CHAP authentication on the interfaces of FW_A and Route B.
Data Preparation
l The user names of FW_A and FW_B

l The passwords of FW_A and FW_B
l The IP address of the interface on FW_A
l The IP address of the interface onFW_B
NOTE
FW_A and FW_B must be configured with the same password, or the authentication fails.
Procedure
<FW> system-view
[FW] sysname FW_A
[FW_A-localuser-userb] password Password1
# Configure an IP address for POS 1/0/0 and configure the link-layer encapsulation protocol
as PPP.
NOTE
interface.
# Configure the username of FW_A used in its authentication by FW_B in the CHAP mode.
[FW_A-Pos1/0/0] ppp chap user usera
# Configure the authentication in CHAP mode.

[FW_A-Pos1/0/0] ppp authentication-mode chap

# Add POS1/0/0 to the Trust zone.




# Add the username of FW_A and the local password to the local user list of FW_B.
<FW> system-view
[FW] sysname FW_B
# Configure an IP address for POS 1/0/0 and configure the link-layer encapsulation protocol
as PPP.
NOTE
interface.
# Configure the user name of FW_B used in its authentication by FW_A in the CHAP mode.
[FW_B-Pos1/0/0] ppp chap user userb
# Configure the authentication in CHAP mode.

[FW_B-Pos1/0/0] ppp authentication-mode chap

# Add POS1/0/0 to the Trust zone.





After the configuration is completed, running the display interface command on every FW,
you can see the LCP status is Opened. Now set the displayed information of the FW_A as an
example.
Last up time: 2007-11-03, 12:36:19
Flag C2 22(0x16)
SDH alarm:
section layer: none
line layer: none
path layer: none
SDH error:
line layer: B2 1093838510 REI 705143440
----End
Configuration Files
#
sysname FW_A
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp chap user usera
ip address 10.110.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
security-

policy
rule name
policy_sec_1
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action
permit
#
return

#
sysname FW_B
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ppp chap user userb
ip address 10.110.0.2 255.255.255.0
#
firewall zone trust
set priority 85
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone
trust
destination-zone
local
destination-zone
trust
action
permit
#
return

This section provides PPP references.
This section describes PPP specifications.

Negotiation function PAP, CHAP, and IPCP Supported by all models.

negotiation functions are
supported.
Supported interface type - Dialer and VT interfaces

This section describes the versions and changes in the PPP feature.
4.4.7.3 Reference Standards and Protocols

This section provides PPP standards and protocols, which can be the reference materials for
understanding the related knowledge about this feature deeply.
PPP standards and protocols are as follows:
RFC 1661: The Point-to-Point Protocol (PPP)
4.5 PPPoE
This section describes Point-to-Point Protocol over Ethernet (PPPoE) concepts and how to
configure PPPoE, as well as provides configuration examples.
4.5.1 Overview
PPPoE describes the method used to set up PPPoE sessions and encapsulate PPP datagram
over the Ethernet. These functions require a point-to-point (P2P) relationship between the
peers instead of the multi-point relationships that are available in the Ethernet and other multi-
access environments.
Definition
PPPoE is the short for Point-to-Point Protocol over Ethernet. It connects a network of hosts
formed by the Ethernet to a remote access device to gain access to the Internet. It allows you
to perform access control and accounting on a per-host basis. As it is highly cost-effective,
PPPoE is widely adopted, for example, in network construction for residential areas.
Purpose
PPPoE performs the following functions when multiple users access a server using PPP links:

l Provides cost effective access services for users and allows a few or no configuration
changes. An Ethernet is the most cost-effective networking mode.
l Allows a service provider to connect multiple hosts at a remote site to the same access
server and supports access control and accounting functions in a way similar to dial-up
services using Point-to-Point Protocol (PPP).
Although PPP is widely used, it does not apply to an Ethernet. Therefore, the PPPoE
technology was introduced. PPPoE is an extension to PPP and applies PPP to an Ethernet.
PPPoE enables a bridged access server to connect multiple hosts on a network to a remote
access server.
NOTE
A FW currently supports IPv4 PPPoE server and client functions and IPv6 client functions.
4.5.2 Mechanism
This section describes the Point-to-Point Protocol over Ethernet (PPPoE) mechanism.
PPPoE works in the client/server mode. PPPoE provides point-to-point connectivity over
Ethernet networks by encapsulating PPP packets in Ethernet frames.
Figure 4-25 shows the process for establishing an IPv4 PPPoE connection.
Figure 4-25 Process for establishing an IPv4 PPPoE connection

PPPoE Client PPPoE Server
PADI
PADO
Discovery
phase PADR
PADS
Session PPP Negotiation

phase
Discovery Phase
After the Discovery phase is complete, both ends of a connection obtain the PPPoE
Session_ID and peer Ethernet address. The PPPoE Session_ID and peer Ethernet address
together define a unique PPPoE session.
The Discovery phase consists of the following steps:

1. A host broadcasts a PPPoE Active Discovery Initial (PADI) packet within a local
Ethernet. This packet contains service information required by the host.
NOTE
A PPPoE server checks service names as follows:

l If a PPPoE server is configured with a service name, a PPPoE client sends a PADI packet at
the Discovery phase to the server to request for a connection.
l If this PADI packet contains a non-null service name, the server examines whether the
configured service name matches the service name in this packet. If the service names match,
the server provides follow-up services. If the service names do not match, the server does not
provide services.
The preceding situation applies when two service names are not null. If either of the service names
is null, the server does not check the service names and proceeds with the packet processing.
2. After receiving this PADI packet, the servers on the Ethernet compare the requested
services with the services the servers can provide. Then, the server that can provide the
requested services send back a PPPoE Active Discovery Offer (PADO) packet.
3. Upon receipt, the host obtains information from the PADO packet and sends a PPPoE
Active Discovery Request (PADR) packet to the server.
4. The server generates a unique session identifier to identify a PPPoE session. Then, the
server sends this session identifier in a PPPoE Active Discovery Session-confirmation
(PADS) packet to the host. If there is no error, both the ends enter the PPPoE session
phase.
If the server successfully sends and the host received the PADS packet, both the server
and host enter the PPPoE Session phase.
Session Phase
The host encapsulates a PPP packet as the payload of a PPPoE frame into an Ethernet frame
before sending the Ethernet frame to its peer. The Ethernet frame carries a Session_ID
determined at the Discovery phase and a peer MAC address. The PPP packet section in the
frame begins at the Protocol ID. An Ethernet packet is a unicast packet.
In the Session phase, either the host or server may send PPPoE Active Discovery Terminate
(PADT) packets to instruct the other to end this session.
4.5.3 Configuring PPPoE

This section describes how to configure the device as a PPPoE server or a PPPoE client.
4.5.3.1 Configuring the IPv4 PPPoE Server

This section describes how to configure the basic functions of an IPv4 PPPoE server and how
to set PPPoE parameters.
Prerequisites
PPPoE authentication works in either local or remote mode. You must configure a user
account and an authentication mode to implement authentication. If remote authentication is
used, you must also configure an authentication server..
After the basic PPPoE functions of are configured, you can set PPPoE parameters of as
required to optimize links.

Context
You can use PPPoE to allow many hosts on a single Ethernet to connect to a peer server and
create PPPoE sessions to implement access control and the accounting.
NOTICE
A FW serves both as a PPPoE server to provide local access services and as a Layer 2
Tunneling Protocol (L2TP) access concentrator (LAC) to provide remote dial-up services.
After a PPPoE server is started and LAC configuration is implemented on the FW, L2TP
configuration takes precedence over PPPoE server configuration. For example, if a user name
is set to user123 in both L2TP and PPPoE configurations, the FW initiates a dial-up using the
user name user123 and performs L2TP authentication, not PPPoE authentication.
Procedure
Step 1 Configure a Virtual-Template (VT) interface.
A PPPoE server communicates with its clients using a VT interface. If no IP address is
specified on a client, the PPPoE server allocates an IP address to the client. The IP address to
be allocated must be specified on the VT interface.
1. Display the system view.
system-view
2. Create a VT interface and display the VT interface view.

interface virtual-template number
3. Set an IP address.
ip address ip-address { mask | mask-length }
4. Optional: Enable local PPP authentication.

ppp authentication-mode { chap | eap | pap } *
By default, no authentication is performed.

NOTE
PAP is not a secure protocol, and CHAP is recommended.
5. Optional:
Prevent the client from using its own IP address when the server is configured to assign
an IP address to it.
ppp ipcp remote-address forced
By default, the peer is allowed to use its own IP address.

6. Optional:
Specify the IP address pool that is used when IP addresses are assigned to users.
remote { address ip-address | service-scheme service-scheme }
7. Optional:
Set an IP address of the DNS server for the peer end.
ppp ipcp dns { admit-any | request }
By default, no IP address of a DNS server is configured.

quit

Step 2 Bind the VT interface to an Ethernet interface.

1. Display the Ethernet interface view.
2. Bind a VT interface to the Ethernet interface.

pppoe-server bind virtual-template number
3. Optional:
Specify a PPPoE service name.
pppoe-server service-name service-name
The server name identifies a service type required by a client. If the server name is
rejected by the client, the client replies with service error information to the server. Upon
receipt, the server terminates the connection to the client.
– The interface must be bound to the VT interface before you configure the PPPoE
server name on the server interface.
– After specifying the PPPoE server name, restart the interface to allow the clients to
be reconnected.
quit
Step 3 Configure PPPoE parameters.

l Configure to log the status changes of PPPoE users.
pppoe up-down-log enable
By default, the device logs the status changes of PPPoE users.

When there are many PPPoE users and the status of the users change frequently, to log a
plenty of logs may impact the normal system monitoring. You can run the pppoe up-
down-log disable command to not to log the status changes of the PPPoE users.
l Specify the maximum number of sessions that can be created using a local MAC
address.
pppoe-server max-sessions local-mac number
l Specify the maximum number of sessions that can be created using a peer MAC address.
pppoe-server max-sessions remote-mac number
l Specify the maximum number of sessions that can be created in the system is specified.
pppoe-server max-sessions total number
----End
4.5.3.2 Configuring an IPv4 PPPoE Client

This section describes how to configure the device an IPv4 PPPoE client.
Context
Before establishing a PPPoE session, configure a dialer interface and its dialer bundle.
Each PPPoE session maps to a single dialer bundle, and each dialer bundle maps to a single
dialer interface. A PPPoE session can be created using a dialer interface.

Procedure
system-view
Step 2 Configure a dialer ACL for the dialer access group.

dialer-rule rule-number { ip { deny | permit } | acl acl-number }
Step 3 Create a dialer interface.

interface dialer number
Step 4 It is recommended that both PAP and CHAP user names and passwords be specified on the
client. Configure an authentication mode using either of the following methods:
l Configure PAP authentication.
Specify a PAP user name and a password.
l Configure CHAP authentication.

– Specify a user name for the peer end to use CHAP to authenticate the local end.
– Set a password for the peer end to use CHAP to authenticate the local end.
Step 5 Specify a dial-up user name.

dialer user username
You can set username to any value within the range.
Step 6 Enable the IP address negotiation function.

NOTE
The IP address negotiated by the device is a host IP address with a 32-digit mask. If the device needs to
communicate with other PPPoE clients, run the ip route-static command to manually configure the
static route to the network segment.
Step 7 Configure the dialer bundle.

dialer bundle bundle-number
Step 8 Configure a dialer group.

dialer-group group-number
NOTE
The same group-number value must be specified in the dialer-rule and dialer-group commands.

quit
Step 10 Display the Ethernet interface view.

Step 11 Create a PPPoE session and specify the dialer bundle for the session.
pppoe-client dial-bundle-number number [ no-hostuniq ] [ idle-timeout seconds
[ queue-length packets ] ] [ ipv4 ]
----End

4.5.3.3 Configuring an IPv6 PPPoE Client

This section describes how to configure an IPv6 PPPoE client.
Context
Before establishing a PPPoE session, configure a dialer interface and its dialer bundle.
Each PPPoE session maps to a single dialer bundle, and each dialer bundle maps to a single
dialer interface. A PPPoE session can be created using a dialer interface.
Procedure
system-view
Step 2 Configure a dialer ACL for the dialer access group.

dialer-rule rule-number { ipv6 { deny | permit } | acl6 acl6-number }
Step 3 Create a dialer interface and display the dialer interface view.
interface dialer number
Step 4 Configure an authentication mode. The server may use PAP or CHAP authentication.
Configuring both PAP and CHAP user names and passwords is recommended.
l Configure PAP authentication.
Specify a PAP user name and a password.
l Configure CHAP authentication.

– Specify a CHAP user name.
– Set a CHAP password.

Step 5 Specify a dial-up user name.

dialer user username
You can set username to any value within the range.

Step 6 Configure the device to automatically obtain an IPv6 address as follows:
Configures an interface to automatically generate a link-local address.
Step 7 Configure the dialer bundle.

dialer bundle bundle-number

quit
Step 9 Display the Ethernet interface view.

Step 10 Create a PPPoE session.

pppoe-client dial-bundle-number number [ no-hostuniq ] [ idle-timeout seconds

[ queue-length packets ] ] [ ipv6 ]
----End
4.5.4 Maintaining PPPoE

After configuring PPPoE, you can run the display commands to view the PPPoE
configuration information. You can also clear PPPoE statistics if necessary.
4.5.4.1 Displaying the PPPoE Configuration

After configuring PPPoE, you can run the display commands to view the configurations.
Procedure
l In any view, you can check the PPPoE configuration by running the commands listed in
Table 4-32.
Table 4-32 Displaying the PPPoE configuration

Action Command
Display display pppoe-server session { all | packet | statistic interface

information interface-type interface-number }
about all
PPPoE
sessions.
Display display pppoe-client session packet [ dial-bundle-number dial-

statistics bundle-number ]
about PPPoE
session
packets.
Display brief display pppoe-client session summary [ dial-bundle-number dial-

information bundle-number ]
about PPPoE
session
packets.
----End
4.5.4.2 Clearing Statistics About PPPoE Sessions

This section describes how to clear statistics about PPPoE sessions on a specified interface.

Context
NOTICE
Cleared PPPoE statistics cannot be recovered. Exercise caution when performing this
operation.
Procedure
l You can run the command in Table 4-33 in the user view to clear PPPoE statistics.
Table 4-33 Clearing PPPoE statistics
Action Command
Clear statistics about PPPoE sessions on a reset pppoe-server session statistic

specified interface. interface interface-type interface-number
----End
4.5.4.3 Resetting a PPPoE Session

This section describes how to reset a PPPoE session.
Procedure
l You can run the command in Table 4-34 in the user view to reset a PPPoE session.
Table 4-34 Resetting a PPPoE session
Action Command
Reset a session on a PPPoE client and re- reset pppoe-client { all | dial-bundle-
establish a session later. number number }
----End

This section provides examples for configuring IPv4 and IPv6 PPPoE clients.
4.5.5.1 Example for Configuring IPv4 PPPoE

This section provides an example for configuring basic IPv4 PPPoE functions.

As shown in Figure 4-26, FW_A functions as a PPPoE client, and FW_B functions as a
PPPoE server. FW_B assigns an IP address to FW_A allowing PCs on networks A and B to
communicate.
FW_B (server) runs PAP to authenticate FW_A (client). The user name is set to usera, and
the password is set to Password1. FW_B assigns FW_A an IP address 10.2.0.2.
Figure 4-26 IPv4 PPPoE networking
Trust Untrust Trust

PC PC
FW_A FW_B
GE1/0/1
NetworkA NetworkB
GE1/0/3 GE1/0/1 GE1/0/3
10.3.0.1/24 PPPoE Client 10.4.0.1/24
PPPoE
PC Server PC
Procedure
Step 1 # Configure FW_B.
# Configure interfaces and assign them to security zones.

<FW_B> system-view
[FW_B] firewall zone untrust
[FW_B-zone-untrust] add interface GigabitEthernet 1/0/1
[FW_B-zone-untrust] quit
[FW_B-zone-trust] add interface GigabitEthernet 1/0/3
# Add a PPPoE user.

[FW_B-localuser-usera] quit
# Configure an IP address pool.

[FW_B] ip pool global1
[FW_B-ip-pool-global1] section 1 10.2.0.2
[FW_B-ip-pool-global1] quit
# Configure a service scheme to adopt the IP address pool.

[FW_B] aaa
[FW_B-aaa] service-scheme scheme1
[FW_B-aaa-service-scheme1] ip-pool global1
[FW_B-aaa-service-scheme1] quit
[FW_B-aaa] quit
# Set VT interface parameters.

NOTE
PAP is not a secure protocol, and CHAP is recommended.
[FW_B] interface virtual-template 1
[FW_B-Virtual-Template1] ppp authentication-mode pap
The command is used to configure the PPP authentication mode on the local end.
Confirm that the peer end adopts the corresponding PPP authentication. Continue[Y/
N]: y
[FW_B-Virtual-Template1] ip address 10.2.0.1 24
[FW_B-Virtual-Template1] remote service-scheme scheme1
[FW_B-Virtual-Template1] quit
[FW_B-zone-untrust] add interface virtual-template 1
# Bind the VT interface to the physical interface.

[FW_B-GigabitEthernet1/0/1] pppoe-server bind virtual-template 1

[FW_B-policy-security-rule-policy_sec_1] source-address 10.4.0.0 24
[FW_B-policy-security-rule-policy_sec_1] destination-zone untrust
[FW_B-policy-security-rule-policy_sec_1] destination-address 10.3.0.0 24
[FW_B-policy-security-rule-policy_sec_2] source-zone untrust
[FW_B-policy-security-rule-policy_sec_2] source-address 10.3.0.0 24
[FW_B-policy-security-rule-policy_sec_2] destination-address 10.4.0.0 24
# Configure a static route.

[FW_B] ip route-static 10.3.0.0 24 virtual-template 1

# Configure interfaces and assign them to security zones.
<FW_A> system-view
# Configure PPPoE dial-up.

[FW_A] dialer-rule 1 ip permit
[FW_A] interface dialer 1
[FW_A-Dialer1] dialer user usera
[FW_A-Dialer1] dialer-group 1
[FW_A-Dialer1] dialer bundle 1
[FW_A-Dialer1] ip address ppp-negotiate
[FW_A-Dialer1] ppp pap local-user usera password cipher Password1
[FW_A-Dialer1] quit

[FW_A-zone-untrust] add interface dialer 1

# Configure a PPPoE session.

[FW_A-GigabitEthernet1/0/1] pppoe-client dial-bundle-number 1 ipv4

[FW_A-policy-security-rule-policy_sec_1] source-address 10.3.1.0 24
[FW_A-policy-security-rule-policy_sec_1] destination-address 10.4.1.0 24
[FW_A-policy-security-rule-policy_sec_2] source-address 10.4.1.0 24
[FW_A-policy-security-rule-policy_sec_2] destination-address 10.3.1.0 24
# Configure a static route.

[FW_A] ip route-static 10.4.0.0 24 dialer 1
----End
Example
After completing the configuration, check statistics about PPPoE session packets.
l Check statistics about PPPoE packets of the PPPoE server.
[FW_B] display pppoe-server session all
SID Intf State OIntf RemMAC LocMAC
1 Virtual-Template1:0 UP GE1/0/1 0022.a100.11ab
0018.82cf.ebed
l Check statistics about PPPoE packets of the PPPoE client.

[FW_A] display pppoe-client session summary dial-bundle-number 1
PPPoE Client Session:
ID Bundle Dialer Intf Client-MAC Server-MAC State
1 1 1 GE1/0/1 0022a10011ab 001882cfebed PPPUP
#
sysname FW_A
#
dialer-rule 1 ip permit
#
interface Dialer1
link-protocol ppp
ppp pap local-user usera password cipher %$%$UQ"HLOehx>*n^PPqyBQVaNE<%$%$
dialer user usera
dialer-group 1
dialer bundle 1
#

undo shutdown
#
undo shutdown
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
ip route-static 10.4.0.0 24 Dialer1
#
security-policy
source-zone trust
action permit
source-zone untrust
action permit
#
return

#
sysname FW_B
#
aaa
service-scheme scheme1
ip-pool global1
#
interface Virtual-Template1
remote service-scheme
scheme1
ip address 10.2.0.1 255.255.255.0
#
pppoe-server bind Virtual-Template 1
undo shutdown
#
undo shutdown
ip address 10.4.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
add interface Virtual-Template1
#
ip pool global1
section 1 10.2.0.2
#
ip route-static 10.3.0.0 255.255.255.0 Virtual-Template1 10.2.0.2

#
security-policy
source-zone trust
action permit
source-zone untrust
action permit
#
return
4.5.5.2 Example for Configuring an IPv6 PPPoE Client (Stateless Address

Autoconfiguration)
This section describes how to configure an IPv6 PPPoE client. A FW functions as an IPv6
PPPoE client to obtain an IPv6 address and access the Internet.
The FW shown in Figure 4-27 functions as an IPv6 PPPoE client and uses stateless address
autoconfiguration to obtain an IPv6 address from an IPv6 PPPoE server.
Figure 4-27 Networking diagram for configuring an IPv6 PPPoE client
GE1/0/1 GE0/0/1
Trust 3001::1/64 IPv6
Network
FW
IPv6 PPPoE Server
IPv6 PPPoE Client
1. Create a PPPoE session and bind it to GigabitEthernet 1/0/1 of the FW to enable the
interface to access an IPv6 network.
2. Create a PPPoE user on a PPPoE server.
3. Enable stateless address autoconfiguration on FW so that a dialer interface can
automatically obtain an IPv6 address.
4. Configure a global unicast address for GigabitEthernet 1/0/1 on the PPPoE server and
enable RA advertisement to advertise the IPv6 prefix to GigabitEthernet 1/0/1 of the FW
using a router advertisement (RA) message.

Procedure
# Configure the FW as an IPv6 PPPoE client.
<FW> system-view
[FW] interface Dialer1
[FW-Dialer1] link-protocol ppp
[FW-Dialer1] ppp pap local-user admin-example password cipher Admin@123
[FW-Dialer1] dialer user admin-example
[FW-Dialer1] dialer bundle 1
[FW-Dialer1] quit
# Enable IPv6.
[FW] ipv6
# Assign a link-local IPv6 address to a dialer interface.

[FW]interface Dialer1
[FW-Dialer1] ipv6 enable
[FW-Dialer1] ipv6 address auto link-local
# Enable stateless address autoconfiguration.

[FW-Dialer1] ipv6 address auto global
[FW-Dialer1] quit
# Configure a PPPoE session.

[FW-GigabitEthernet1/0/1] pppoe-client dial-bundle-number 1 ipv6
# Assign the dialer interface to a security zone.

[FW-zone-trust] add interface Dialer 1
Step 2 Configure a PPPoE server. The actual configuration varies depending on devices.
# Create a PPPoE user and set the user name to admin-example and the password to
Admin@123, which are the same as those specified on the PPPoE client.
# Set the global unicast address to 3001::1/64 for the interface that directly connects the
PPPoE server to the PPPoE client.
# Enable RA message advertisement.
----End
#
sysname FW
#
ipv6
#
interface Dialer1
link-protocol ppp
ppp pap local-user admin-example password cipher %$%$(TT8F ] Y\5SQ=^Q`MAF4<1!!%$%
$
ipv6 enable
dialer user admin-example

dialer bundle 1
ipv6 address auto global
#
undo shutdown
#
firewall zone trust
set priority 85
#
return

This section provides PPPoE references.
This section describes PPPoE specifications.
PPPoE client Applying PPPoE to the Supported by all the models.

interfaces of the following
types:
l FE interface
l GE interface
l Eth-Trunk interface
l Subinterface
l VLANIF interface
PPPoE server Applying PPPoE to the .Supported by all the

interfaces of the following models.
types:
l FE interface
l GE interface
l Eth-Trunk interface
l Subinterface
l VLANIF interface
Configurable service name Supported by all the models.

PPPoE server Maximum number of

concurrent PPPoE client
connections
4.5.6.2 Featurea History

This section describes the versions and changes in the PPPoE feature.

This section provides PPPoE standards and protocols.
PPPoE standards and protocols are as follows:

l RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE)
l RFC 1661: The Point-to-Point Protocol (PPP)
4.6 DNS
This chapter describes the principles, basic functions and configuration procedures of DNS,
and provides configuration examples.
4.6.1 Overview
The Domain Name System (DNS) establishes the mapping between domain names and IP
addresses.
Definition
TCP/IP uses IP addresses to connect to devices. Users find it is difficult to memorize the IP
address of each device. Therefore, the host naming mechanism is specially designed to match
IP addresses with host names in the string format. The DNS provides the conversion and
query mechanism between IP addresses and host names.
Objective
The DNS uses a hierarchical naming mode to specify a meaningful name for each device on a
network, set the DNS server, and establish the mapping between the domain name and the IP
address.

4.6.2 Application Scenario

This section describes the applicable scenario of DNS.
4.6.2.1 Typical Application of the Device as a DNS Client

This section describes the application scenario of the FW working as a DNS client.
The FW can use the protocol of DNS to dynamically obtain the IP address of the domain
name from the DNS server, which is convenient for user communication.
Typical Application
Figure 4-28 shows the typical networking in which FW serves as a DNS Client.
Figure 4-28 Typical networking of the FW serving as a DNS Client

NGFW
DNS Client DNS Server
When the FW performs the following services, it can send DNS request packets to the DNS
server as a DNS client.
l Perform ping or tracert by domain name.
l Access to the Security Service Center by domain name to update the signature databases.
l Access to the CA server to obtain the certificate online by domain name.
4.6.2.2 Typical Application of the Device as a DNS Proxy

This section describes the application scenario of the FW working as a DNS proxy.
After the DNS proxy function is enabled, the device can forward DNS request and response
packets between the internal DNS clients and external DNS server. When the DNS server
address changes, you only need to configure the DNS proxy, not all the DNS clients on the
LAN. Therefore, the DNS proxy simplifies network management.
Typical Application
Figure 4-29 shows the typical networking in which FW serves as a DNS Proxy.

Figure 4-29 Typical networking of the FW serving as a DNS Proxy
Host_A DNS Server

DNS Client
FW
Branch Headquarters
DNS Proxy
Host_B
DNS Client FTP Server
In the network environment shown in Figure 4-29, FW works as the egress gateway of the
branch. In the headquarters, the network is configured with DNS server and FTP server, and
the mappings between the domain names and the IP address of the FTP server is recorded on
the DNS server. In addition, the routes between both the servers and the FW are reachable. In
order to realize that users of the branch to access to the FTP server of the headquarters by
domain name, the FW can be configured to forward the request and response packets between
the user hosts of the branch and the DNS server of the headquarters as a DNS proxy.
4.6.2.3 The Device Serving as a DDNS Client to Realize Updates by the DDNS
Server
This section describes the application scenario in which the device serves as a DDNS client to
make the DNS server dynamically update the mapping between domain names and IP
addresses by the DDNS server.
Take the scenario in which the Internet users access to the Web server by domain names.
When the IP address of the Web server changes, to make users access to the Web server by
domain name normally, you can configure the Web server as a DDNS client to send the
request of updating the mapping between the domain name and the IP address. After the
DDNS server receives the DDNS request from the Web server, it notifies the DNS server to
dynamically update the mapping between the domain name and the IP address. In this way,
although the IP address of the application server changes, the Internet users can also access to
the server by the same domain name.
Typical Application
Figure 4-30 shows the networking in which FW serving as a DDNS Client realizes the
mapping between domain names and IP addresses by the DDNS server.

Figure 4-30 Typical networking of the FW serving as a DDNS client
Web DMZ Untrust

DDNS
Server Server
FW
Interface 1
Intranet
DDNS Client
DNS PC
Server
At the boarder of the enterprise network, the FW serves as a gateway. The Internet users can
access to the internal Web server with the help of the NAT server by domain name. However,
the public IP address of Interface 1 of the FW always changes as it obtain an IP address
through dial-up. If the mapping between the domain name and the IP address of the FW,
which is also the domain name of the internal Web server can cannot be updated in time, the
Internet users will fail to access to the Web server by domain name. At this time, you can
configure the FW as a DDNS client to send the request of updating the mapping between
domain names and IP addresses. Finally, the Internet users can access to the Web server of the
internel enterprise network by domain name.
4.6.2.4 DNS Transparent Proxy

This section describes the typical application scenario of the DNS transparent proxy.
An enterprise rents multiple ISP links as network egresses, and each ISP network deploys the
same Web servers. Generally speaking, the same DNS server address (such as the DNS server
address of ISP1) is configured on the clients of all intranet users. The DNS server then
resolves domain names to the address of the Web server (such as the Web server address of
ISP1) on the same ISP network. Therefore, the Internet access traffic from all intranet users is
forwarded on the same ISP link, causing link congestion and compromising users' Internet
access experiences. At the same time, other ISP links are not used, causing resource waste.
Typical Application
The DNS transparent proxy function on the FW can change the destination address of some
DNS query messages to the DNS server addresses on other ISP networks (such as the DNS
server address on ISP2 network). The DNS requests are then forwarded to different ISP
networks, and the resolved Web server addresses belong to different ISPs. Therefore, the
Internet access traffic will be forwarded over different ISP links. In this way, all link resources
are made full use of, as shown in Figure 4-31.

Figure 4-31 Typical Application of the DNS Transparent Proxy

www.example.com
Web server on ISP1 Web server on ISP2
ISP1 ISP2
DNS server on ISP1 DNS server on ISP2
FW
Intranet
DNS requests
4.6.3 Mechanism
This section describes the implementation of DNS.
4.6.3.1 DNS Client-Server Exchange

This section describes the basic concepts about the DNS protocol and the principle of the
DNS client-server exchange.
DNS over the Internet

Host names constitute a non-hierarchical namespace. Each name contains a character
sequence. The network information center (NIC) manages the namespace and processes new
names. The non-hierarchical namespace cannot manage a large number of names for the
following reasons:
l Names consist of characters, which allows for name overlapping.
l The namespace management architecture resides at a specific site. As the number of host
names increases, so does the management workload.
l The mapping between names and IP addresses frequently changes. Therefore,
maintaining the domain namespace is a huge undertaking.

TCP/IP designs a hierarchical DNS structure. The domain name structure of the Internet is
defined by the DNS in the TCP/IP protocol stack. The DNS divides the Internet into multiple
top-level domains (TLDs). Table 4-35 lists the domain name of each TLD. TLDs are
classified in either organization or geography mode. The geography mode is used to classify
domain names based on countries. Each country must register a TLD with the NIC before
joining the Internet. For example, "cn" represents China, and "us" represents the United
States.
Table 4-35 TLDs and their meanings

TLD Meaning
com Commercial organizations
edu Educational agencies
gov Governmental agencies
mil Military departments
net Main network support centers
int International organizations
org Other organizations
country code Other countries (classified in geography mode)
NOTE
The first seven domains are defined in organization mode, and the country code domain is defined in
geography mode.
The NIC authorizes management agencies to classify domains into subdomains. The agencies
in charge of this can authorize subordinate agencies to continue classifying domains. As a
result, the Internet has a hierarchical domain architecture.
Static Domain Name Resolution

DNS supports dynamic and static domain name resolution. Static domain name resolution is
used to resolve a domain name. If it fails, dynamic domain name resolution is used.
Static domain name resolution requires a static domain name resolution table, which lists the
mapping created manually between domain names and IP addresses. This table is similar to
the hosts file in a Windows 9X. The table contains commonly used domain names. After
searching for a specified domain name in the resolution table, clients can obtain the IP address
mapped to it. This process improves domain name resolution efficiency.
Dynamic Domain Name Resolution

Dynamic domain name resolution requires a special DNS server. This server runs the domain
name resolution program, maps domain names to IP addresses, and collects DNS requests
from clients.
The following shows the DNS client-server exchange, which is also the process of dynamic
domain name resolution.

Figure 4-32 Principle diagram of dynamic domain name resolution
Request Request
User
Resolver
Program
Response Response
Save Read
DNS Server
Cache
DNS Client Local Host
In Figure 4-32, the DNS client, consisting of the resolver and the cache, is used to accept and
respond to the DNS queries from user programs. Generally, user programs (ping, Tracert), the
cache, and the resolver are on the same host; whereas the DNS server is on another host.
1. A client uses a specific application, such as ping or Telnet, to send a DNS request to a
device.
2. The device queries a local cache for the required mapping entry. The resolver first check
the local cache.
– If the resolver finds a mapping entry in the local cache, it directly return the IP
address mapping the domain name to the user program.
– If the resolver does not find a mapping entry in the local cache, it sends a query
packet to the DNS server.
3. The DNS server first checks whether the requested domain name is within the sub-
domain it manages and responds to the device according to different results.
– If the requested domain name is within the sub-domain it manages, this DNS server
query the IP address corresponding to the domain name in its own database.
– If the requested domain name is not within the sub-domain it manages, this DNS
server forward the request to the DNS sever of the upper level till the resolution is
finished and the result of resolution is returned.
4. The resolver of the DNS client receives and resolves the packet returned by the DNS
server, and return the result to the user program.
When resolving a domain name that is stored in the cache, the DNS client obtains the
corresponding IP address from the cache directly and does not send a query message to the
DNS server. Mappings stored in the cache will be deleted when the aging time expires to
ensure that the latest mappings can be obtained from the DNS server. The aging time is set by
the DNS server. The DNS client obtains the aging time from protocol packets.
Domain Name Suffix List

Dynamic domain name resolution also supports a domain name suffix list. Pre-defining some
domain name suffixes allows you to enter only a field of a domain name to be resolved. The
system automatically adds a specific suffix to the domain name before resolving the domain
name.

For instance, If you configure "com" in the suffix list and enter "example" in a domain name
query, the system automatically associates "example" with the suffix "com" and searches for
"example.com."
You may encounter the following situations during a resolution process:
l If you enter a domain name without a dot (.), such as "example", the system considers it
as a host name and adds suffixes one by one used for search. If there are no matched
domain names, the system searches for an IP address mapped to "example."
l If you enter a domain name with a dot (.), such as "www.example", the system
immediately searches for it. If the system does not find a matched entry, the system adds
every configured suffix to the domain name to search for an IP address mapped to the
domain name.
l If you enter a domain name with a dot (.) at the end, such as "example.com.", the system
removes the last dot (.) before searching for an IP address mapped to the domain name.
If the search fails, the system adds every configured suffix to the domain name without
the last dot to search for an IP address mapped to the domain name.
Query Type of DNS

Currently, the FW supports the function of DNS Client and the query types of Class-A and
PTR in the IPv4 network.
Class-A query is a common type of query, which is used to obtain the IP address
corresponding to a specified domain name. For example, when you ping or tracert a domain
name, the ping or tracert, as a user program, sends a query to the DNS client for the IP
address corresponding to the domain name. If the corresponding IP address does not exist on
the DNS client, the DNS client sends a Class-A query to the DNS server to obtain the
corresponding IP address.
PTR query means that the DNS client obtains the corresponding domain name with the help
of PTR records of the according to the IP address. The PTR records means the table of the
mapping between the domain names and the IP addresses on the DNS server provided to PRT
query.
4.6.3.2 Working Principle of DNS Proxy/Relay

DNS proxy or relay is used to forward DNS request and reply packets between the DNS client
and DNS server.
In the network where DNS proxy or DNS relay is used, the DNS client sends DNS request
packets to the DNS proxy or relay. The DNS proxy or relay forwards request packets to the
DNS server and sends reply packets to the DNS client, and domain resolution is realized.
After DNS proxy or relay is enabled, if the IP address of the DNS server changes, you only
need to change the configuration on the DNS proxy or relay. In this way, the network
management is simplified.
Difference of Function Implementation Between the DNS Proxy and the DNS
Relay
DNS relay is similar to DNS proxy. The difference is whether they search for DNS entries
saved in the local domain name resolution table, including the static domain name resolution
table and the local domain name cache after receiving DNS query messages from DNS
clients.

The DNS proxy searches for DNS entries saved in the local domain name cache after
receiving DNS query messages from DNS clients. If requested DNS entries are not saved in
the cache, DNS query messages are forwarded to the DNS server.
The DNS relay does not searches for DNS entries saved in the local domain name cache after
receiving DNS query messages from DNS clients. It forwards the messages directly to the
DNS server for resolution. On one hand, it can save the cost for the cache on the DNS relay.
On the other hand, it guarantees the real-time requirements for that the DNS client obtain
resolution results. (If the domain names and IP addresses on the DNS server changes and the
cache on the DNS proxy is not updated in time, the resolution result obtained by the DNS
Client is incorrect.)
Working Principle of DNS Proxy

The application environments and working principles of DNS relay and DNS proxy are
similar. Taking DNS Proxy as an example, Figure 4-33 shows the working principles of DNS
Proxy and DNS Relay.
Figure 4-33 Working Principle of DNS Proxy

Query the local domain
name resolution table
FW
Request Request
Respons Respons
e e
DNS Client DNS Proxy DNS Server
The working process of DNS proxy is as follows:

1. The DNS client sends a request packet to the DNS proxy. The DNS proxy IP address is
the destination address of the request packet.
2. After receiving the request packet, the DNS proxy searches for DNS entries saved in the
local domain name resolution tables.
– If mapping information exists, the DNS proxy sends a reply packet carrying the
resolution result to the DNS client.
– If no mapping information exists, the DNS proxy sends the request packet to the
DNS server for resolution.
3. After receiving the reply packet from the DNS server, the DNS proxy records the
resolution result and forwards the reply packet to the DNS client.
NOTE
Only when the IP address of the DNS server and the route to the DNS server exist on the DNS proxy,
the DNS proxy sends domain name resolution requests to the DNS server. Otherwise, the DNS proxy
neither sends any domain name resolution request to the DNS server nor replies any request from the
DNS client.

4.6.3.3 DDNS Client-Server Exchange

DDNS can dynamically update the mapping on a DNS server, which ensures that the resolved
IP address is correct.
DDNS Overview
DNS resolves domain names into IP addresses so that you can access network nodes using
domain names. DNS provides static mappings between domain names and IP addresses.
When IP addresses of nodes change, DNS cannot dynamically update mappings. If a user uses
the original domain name to access the node, the user will fail to access the node because the
IP address mapping the domain name is incorrect. The Dynamic Domain Name System
(DDNS) updates mappings between domain names and the IP addresses on the DNS server to
ensure that the IP address can be resolved correctly.
DDNS Working Mode

DDNS works in client/server mode. Two update modes are available:
l DDNS update mode (defined by the RFC2136): The device functioning as a DDNS
client dynamically updates the mapping between domain names and IP addresses on the
DNS server.
l Update mode implemented through the DDNS server: The device functioning as a
DDNS client sends the mapping between domain names and IP addresses to the DDNS
server with a specified URL. The DDNS server then informs the DNS server to
dynamically update the mapping between domain names and IP addresses.
NOTE
l Deploying the DDNS service needs the support from the DDNS service providers, namely DDNS
servers. Currently, the device supports to communicate with the following DDNS service providers:
www.3322.org, dyndns.org, freedns.afraid.org, zoneedit.com and no-ip.com.
l The DDNS Server is usually deployed in the Internet, so you need to guarantee that the FW
functioning as teh DDNS client can access to the Internet normally when applying the DDNS
service.
Implementation of Updating Through the DDNS Server
Figure 4-34 Typical DDNS networking for the update mode implemented through the DDNS
server
DDNS Server
FW 1
2
DDNS Client DNS Server

HTTP Server
PC

As shown in Figure 4-34, the interface that connects theFW functioning as the DDNS Client
to the Internet obtains the IP address from the network carrier. The IP address obtained each
time is different, so the PCs need to access to the FW functioning as the HTTP server and
providing services of application layer by domain name. However, traditional DNS cannot
dynamically update the mapping between the domain names and the IP addresses, which can
make PCs fail to access to the FW. To deploy the DDNS server can solve the problem.
1. DDNS client: updates the mapping between the domain name and IP address when an IP
address changes.
To make users can access to the FW by domain name when the IP address of the FW
changes, configure the FW to function as a DDNS client and sends a request for updating
the mapping between the domain name and the IP address to the DDNS server.
2. DDNS server: is responsible to instructsthe DNS server to dynamically update the
mapping between the domain name and the IP address on the DNS server.
After receiving the DDNS update request, the DDNS server instructs the DNS server to
reestablish the mapping between the domain name and the IP address on the DNS server
to ensure that Internet users can access the DDNS client using the same domain name
when the IP address changes.
4.6.3.4 DNS Transparent Proxy

This section describes the implementation of DNS transparent proxy.
Figure 4-35 shows how DNS transparent proxy processes the packet from an intranet user to
a specific domain name.

Figure 4-35 Packet processing workflow of DNS transparent proxy
Start
Match a DNS transparent

proxy policy
No Is DNS transparent
proxy required?
Yes
Is the Yes Is any DNS No

domain name an server specified for
exception? exceptions?
No Yes
Mark DNS transparent Replace the destination

proxy on the DNS request address of the DNS request
Search for a route
Is any DNS
server bound to the
No outgoing interface and
the DNS request
marked?
Yes
Replace the destination

address of the DNS request
with the DNS server address
bound to the interface
End
The process is described as follows:
1. An administrator determines which DNS requests require DNS transparent proxy based
on a DNS transparent proxy policy. As the policy is matched based only on the source
and destination addresses of the DNS requests, DNS transparent proxy works no matter
what DNS server address is on the client (an extreme situation is that no DNS server
address is set), implementing DNS server redirection and error correction functions.

If the FW has multiple DNS transparent proxy policies, DNS requests are matched in the
policy configuration order. As long as one policy is matched, the action specified in this
policy is taken, and the policy matching activity finishes. Therefore, you are advised to
first configure policies with narrow matching scopes.
2. When a DNS request matches a DNS transparent proxy policy, if the DNS request
requires DNS transparent proxy, the FW first checks whether the domain name is an
exception. If so, the FW does not perform DNS transparent proxy. If not, the FW marks
DNS transparent proxy on the DNS request for the subsequent process.
For an exception, if another DNS server is required to parse this domain name, the FW
changes the destination address of the DNS request to the desired DNS server address.
3. The FW searches for a route for the DNS request (the route can be a policy-based route,
static route, or dynamic route) to determine the outgoing interface.
If intelligent uplink selection (Global Route Selection Policy or PBR-based Intelligent
Uplink Selection) is configured on the FW and the DNS request matches the
corresponding equal-cost route or policy-based route, the FW forwards the DNS request
based on the intelligent uplink selection result. Note that the intelligent uplink selection
result is dynamic and determined by the uplink selection mode and real-time link status.
The result may vary even if a user accesses the same domain name twice.
4. A maximum of two DNS servers can be bound to each outgoing interface on the FW,
with one primary DNS server and the other secondary DNS server. Both DNS servers
belong to the ISP network directly connected to the outgoing interface. After the FW
determines the outgoing interface of the DNS request, the DNS transparent proxy
function preferentially replaces the destination address of the DNS request with the
primary DNS server address. The secondary DNS server address is used only when the
primary DNS server is Down.
The FW performs DNS transparent proxy only when a DNS server is bound to the
outgoing interface and the DNS request has a DNS transparent proxy mark.
Figure 4-36 shows the DNS transparent proxy process.

Figure 4-36 DNS transparent proxy on the FW

www.example.com
Web server on ISP1 Web server on ISP2
3.3.3.3
ISP2
ISP1
DNS server on ISP1

Preferred:8.8.8.8 The user accesses the
Alternative: 8.8.8.9 5 DNS server on ISP2
Web server of ISP1.
Preferred: 9.9.9.8
The destination address of Alternative: 9.9.9.9
the DNS query message is 3
substituted to 8.8.8.8.
GE1/0/0 GE1/0/1
The FW queries route and
selects interface GE1/0/0 as the
FW 2 outbound interface for forwarding
DNS query messages.
A user accesses website

The resolved Web server
4 1 www.example.com. The DNS
address is 3.3.3.3.
server address is 10.1.1.10.
Intranet
1. After receiving a DNS request, the FW first matches the DNS request with the DNS
transparent proxy policy.
2. If the DNS request matches the policy, the FW selects an outgoing interface based on the
route search result.
3. The FW replaces the destination address of the DNS request with the DNS server
address bound to the outgoing interface.
4. The DNS server returns the parsed web server address to the user. The web server and
DNS server reside on the same ISP network.
5. The user accesses the web server based on the returned address. The ISP Uplink
Selection function is required to ensure that the user accesses the web server through the
ISP network where the web server resides, preventing cross-ISP network access.
4.6.4 DNS Configuration Using the Web UI

This section describes how to configure DNS and DDNS on the web UI.
4.6.4.1 DNS
After you specify a DNS server address on a device, the device can serve as a DNS client or
DNS proxy agent to send domain name resolution requests to a specific DNS server.

Context
A DNS server accepts the domain name resolution requests initiated by a DNS client. You can
manually set an address for the DNS server connected to a device. The DNS server address is
generally provided by an Internet Service Provider (ISP). The address can also be
automatically obtained using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point
Protocol over Ethernet (PPPoE) on an interface. For information about how to configure
interfaces, see Interface.
The DNS server whose address is manually configured has a higher priority than the one
whose address is dynamically obtained. If two DNS servers obtain addresses in the same way,
the one that obtains an address earlier enjoys a higher priority. When resolving domain names,
the device sends query packets (based on the priorities) to DNS servers until the query
succeeds.
Procedure
Step 1 Choose Network > DNS > DNS.
Step 2 In DNS Server List, click Add.
Step 3 Set an IP address for the DNS server.

l If you do not select a WAN interface, the specified DNS server address is a global
address. In the DNS server address text box, enter the IPv4 or IPv6 address of the DNS
server and click OK.
l If you select a WAN interface, the specified DNS server address is the address bound to
the interface (applicable only to this interface). For configuration and description, see
Configuring DNS Transparent Proxy.
If the operation succeeds, the new configuration with Obtaining Mode of Manual is
displayed in DNS Server List.
Repeat the previous operations to assign IPv4/IPv6 addresses to multiple DNS servers.
NOTE
In addition to Manual, the following address allocation modes can be selected from DNS Server List:
l DHCP: The address of the DNS server is obtained dynamically using DHCP.
l PPPoE: The address of the DNS server is obtained dynamically using PPPoE.
----End
Follow-up Procedure
When deleting a DNS server, you can delete only the DNS server addresses that are obtained
manually, but not those obtained using DHCP or PPPoE. If the interface that is connected
using DHCP or PPPoE is physically Down, or the interface fails to be connected using DHCP
or PPPoE, the corresponding DNS server address is deleted automatically from the DNS
server list.
4.6.4.2 Configuring DNS Transparent Proxy

This section describes how to configure DNS transparent proxy on the web UI.

Prerequisites
l One or two DNS server addresses are obtained from each ISP as the DNS server
addresses bound on interfaces.
l You cannot deploy any DNS server on the intranet. If a DNS server is deployed on the
intranet, the DNS transparent proxy function does not take effect, because DNS query
messages are forwarded to the intranet DNS server for domain name analysis, and the
FW is not used for DNS transparent proxy on these DNS query messages.
Context
DNS transparent proxy and ISP Link Selection are used together. ISP link selection ensures
that users access a server through the ISP network where the server resides, preventing cross-
ISP network access. For the implementation of DNS transparent proxy, see DNS Transparent
Proxy.
Procedure
Step 1 Choose Network > DNS > DNS.
Step 2 Click the DNS Server tab.
Step 3 Click Add in DNS Server List.
Step 4 Bind interfaces to the DNS servers.
WAN interface Interface on the FW connecting to different ISP links.

When a DNS query message is forwarded through this
interface, the packet destination address is substituted with the
DNS server address bound on the interface.
NOTE
The WAN interface can be bound only to the root firewall, not to
virtual systems.
Preferred DNS server Address of the DNS server on the ISP network connecting to
the WAN interface.
The FW substitutes the destination addresses of DNS query
messages with the address of the preferred DNS server
preferentially.
Alternate DNS server Address of the DNS server on the ISP network connecting to
the WAN interface.
When the preferred DNS server is Down, the FW will
substitute the destination addresses of DNS query messages
with the address of the alternate DNS server.
Health Check Apply health check to the interface.
Check interval Interval for sending probe packets.
Failure count Number of probe failures

Step 5 Click OK.

Step 6 Click the DNS Transparent Proxy tab.
Step 7 Enable the DNS transparent proxy function and specify the DNS server addresses requiring
proxy processing as well as the domain names to be excluded.
DNS Transparent Proxy Select Enable to enable the DNS transparent proxy function.
Enter domain name Specify the domain names that do not require DNS transparent
exceptions proxy.
You can specify the DNS server address for the domain name.
Then the DNS query message will be forwarded to the
specified DNS server.
Step 8 Click Apply.

Step 9 In DNS Transparent Proxy Policy List, click Add to configure a DNS transparent proxy
policy.
Name Name of the DNS transparent proxy policy rule
Description Description of the DNS transparent proxy policy rule
Source Address Set the source IP address as a matching condition of the PBR
rule.
Destination Address Set the destination IP address as a matching condition of the

PBR rule.
Action Action that will be taken on packets matching the PRB rule:
l Proxy
l No proxy
Step 10 Click OK.
----End
4.6.4.3 Configuring DDNS

When a FW serves as a DDNS client, a DNS server dynamically updates the mapping
between domain names and IPv4 addresses after being notified by a DDNS service provider.
This process ensures that domain names are resolved into correct IPv4 addresses.
Context
A DDNS policy is a collection of such information as the DDNS server address, login user
name, password, DDNS client domain name, and bound interface. After a DDNS policy is
created, the same DDNS policy can be bound to different interfaces, which simplifies the
DDNS configuration.

Procedure
Step 1 Choose Network > DNS > DDNS.
Step 2 Click Add in DDNS Policy List.
Step 3 Set the following DDNS policy parameters.
Policy Name Unique DDNS policy name.

IIf the specified policy name is the same as an existing one, the
new configuration overwrites the previous one.
To identify DDNS policies easily, you can configure easy-to-
remember and meaningful names.
Domain Name Register the DDNS client domain name to the DDNS service
provider.
Service Provider Domain name of the supported DDNS service provider.
URL Enter the URL in DDNS update requests.

This parameter can be configured only when Service Provider
is set to Customization.
If the URL contains a question mark (?), the value ranges from
20 to 254 characters, and you must use double quotation marks
("") to enclose it.
User Name User name used by the DDNS client to access the DDNS
service provider.
The user name must be registered to the DDNS service
provider in advance.
Password Password for the user name used by the DDNS client to access
the DDNS service provider.
Confirm Password Enter a value in Password.
Bound Interface Bind a DDNS policy to an existing interface.

You can perform either of the following operations:
l To bind another interface to the DDNS policy, click .
l To delete a binding entry, click .
Step 4 Click OK.

If the operation is successful, the new configuration is displayed in DDNS Policy List.
Repeat the previous operations to create multiple DDNS policies.
----End
4.6.5 Configuring DNS Using the CLI

This section describes how to configure DNS and DDNS on the CLI.

4.6.5.1 Configuring the Device as a DNS Client

To ensure that the device adopts the domain name to access the website or communicate with
other devices, you need to configure the device as a DNS client.
4.6.5.1.1 Configuring IPv4 Static Domain Name Resolution

If the FW need to communicate with other devices by using domain names, you can configure
static domain name resolution on the FW. A DNS entry maps a domain name to an IPv4
address.
Context
If the FW need to communicate with other devices by using domain names, you can configure
static domain name resolution on the FW. A DNS entry maps a domain name to an IPv4
address.
Prior to configuring IPv4 static domain name resolution, you must know the mapping
between the domain name and the IPv4 address. In case of a change in the mapping, you must
modify the DNS entry manually.
Procedure
Step 1 Run:
system-view
Access the system view.
Step 2 Specify a host name and an IPv4 address mapped to the host name.
ip host host-name ip-address
The host-name parameter is case insensitive.
A host name is mapped to only a single IPv4 address. When you configure an IPv4 address
for a host several times, only the IPv4 address configured at the latest is valid. Repeat Step 2
to allow the device to resolve several host names.
----End
4.6.5.1.2 Configuring IPv4 Dynamic Domain Name Resolution

To implement dynamic DNS, you need to enable dynamic DNS resolution, configure the IP
address of DNS server, configure a source IP address for the local device to receive DNS
packets, and configure a domain name suffix.The DNS server IP address and domain name
suffix can be dynamically obtained using DHCP.
Prerequisites
Before configuring IPv4 dynamic domain name resolution, complete the following tasks:
l Configure routes between the FW and DNS server.

l Configure a DNS server.

Context
Dynamic domain name resolution supports the domain name suffix list function. You can
configure specific domain name suffixes and enter some fields of a domain name before the
system automatically adds different suffixes to the domain name for resolution.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dns resolve
Dynamic domain name resolution is enabled.

By default, dynamic DNS resolution is disabled.
Step 3 Specify the DNS server.
l Run:
The IP address of the DNS server is configured.

By default, no IP address of the DNS server is configured.
l Run:
dns server unnumbered interface { interface-name | interface-type interface-
number }
The DNS server IP address obtained by the specific interface to be the DNS server IP
address of the local device is borrowed.
dns server source-ip ip-address
The source IP address is configured for the local device to receive DNS packets.
By default, no source IP address is configured for the local device to receive DNS packets.
NOTICE
Make sure that the configured source IP address is the IP address of the local FW (the IP
address of an interface or logical interface on the local FW), and there is a reachable route
between the interface and the DNS server.

dns-server-select-algorithm { fixed | auto }
The mode in which the device selects a DNS server is configured.

By default, the device selects a DNS server in auto mode.
dns domain domain-name

A domain name suffix is configured.

By default, no domain name suffix is configured on a DNS client.
dns application cache ttl maximum max-value minimum minimum-value
The maximum value or minimum value of the lifetime for the DNS application cache is A
domain name suffix is configured.
----End
4.6.5.2 Configuring the Device as a DNS Proxy/Relay

The device can function as a DNS proxy or relay to forward DNS request and reply packets
and provide domain name resolution for DNS clients, when the DNS client and DNS server
are on different LANs.
4.6.5.2.1 Configuring the Device as an IPv4 DNS Proxy/Relay

This section describes how to configure the device as an IPv4 DNS Proxy/Relay.
Context
DNS Relay is similar to DNS Proxy. The difference is that the DNS Proxy searches for DNS
entries saved in the domain name cache after receiving DNS query messages from DNS
clients. The DNS Relay, however, directly forwards DNS query messages to the DNS server,
reducing the cache usage.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dns proxy enable or dns relay enable
DNS Proxy or Relay is enabled.

Step 3 Choose either of the following methods to configure domain name resolution.
l Configure static domain name resolution.
Run:
ip host host-name ip-address
A static DNS entry is configured.

By default, no static DNS entry is configured.
You can manually configure the mappings between domain names and IP addresses by
configuring static DNS entries. When a DNS client requests the IP address
corresponding to a domain name, the device does not forward the request to the DNS
server but searches the static domain name resolution table for the IP address and returns
the IP address to the DNS client.
l Configure dynamic domain name resolution.

a. Run:
dns resolve
Dynamic domain name resolution is enabled.

By default, dynamic DNS resolution is disabled.
After dynamic domain name resolution is enabled, the DNS proxy searches the
dynamic domain name resolution table after receiving a DNS request packet and
checks whether the requested IP address exists. If yes, the DNS proxy returns a
DNS reply packet that carries the resolution result to the DNS client. If not, the
DNS proxy forwards the DNS request packet to the DNS server.
b. Select one of the following steps to configure the DNS server.
n Run:
The DNS server that the DNS Proxy or Relay connects to is configured.
By default, no IP address is configured for the DNS server.
n Run:
dns server unnumbered Interface { interface-name | interface-type
interface-number }
The interface that obtain the IP address of the DNS Server is configured.
c. (Optional) Run:
dns server source-ip ip-address
The source IP address that the device uses to exchange packets with the DNS server
is configured.
By default, no source IP address is configured for the device.

dns forward retry-number number
The number of times for the device to retransmit query requests to the destination DNS server
is set.

dns forward retry-timeout time
The retransmission timeout period that the device sends Query packets to the destination DNS
server is set.
By default, the retransmission timeout period for which the device sends DNS query requests
to the destination DNS server is 3 seconds.
The total query timeout period is determined by the retransmission times and retransmission
timeout interval.
l When the auto algorithm is used for selecting the destination DNS server, the total query
timeout period is calculated based on the following formula: Total query timeout period
= (Retransmission times +1) * Retransmission timeout interval
l When the fixed algorithm is used for selecting the destination DNS server, the total
query timeout period is calculated based on the following formula: Total query timeout
period = (Retransmission times +1) * Retransmission timeout interval *Number of DNS
servers

NOTE
The total timeout period for DNS query requests configured by dns forward retry-number and dns
forward retry-timeout cannot be too short. Generally, it is recommended to use the default value. If the
time of waiting for the resolution response from the DNS server is too long, and the service exception is
caused, you can prolong the retransmission timeout period as required.
----End
4.6.5.3 Configuring the Device as a DDNS Client

The device functions as the DDNS client. When the IP address corresponding to the domain
name changes, the DDNS client can notify the DNS server to update the mapping between the
domain name and the IP address on the DNS server. This ensures that users can successfully
access servers on the network using domain names.
4.6.5.3.1 Configuring a DDNS Policy

This section describes the methods and procedure for configuring DDNS policies.
Context
You can specify the DDNS or DNS server to which update requests are sent when configuring
the DDNS policy.
When the FW functioning as a DDNS client needs to update the mapping between domain
names and IP addresses on the DNS server, the following update modes are supported:
l DDNS update mode (defined by the RFC2136): The FW functioning as a DDNS client
dynamically updates the mapping between domain names and IP addresses on the DNS
server. To configure this mode, run the method ddns [ both ] command.
l Update mode implemented through the DDNS server: The FW functioning as DDNS
client sends the mapping between domain names and IP addresses to the DDNS server
with a specified URL. The DDNS server then informs the DNS server to dynamically
update the mapping between domain names and IP addresses.
– To use the Siemens DDNS server or DDNS servers provided at www.3322.org,
www.dyndns.com, or www.oray.cn, run the method vendor-specific command.
– To use an HTTP-based common DDNS server, run the method http command.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ddns policy policy-name
A DDNS policy is created and the DDNS policy view is displayed.

By default, no DDNS policy is created in the system.
A maximum of 10 DDNS policies can be configured on the FW.
Step 3 Run:
method { ddns [ both ] | http | vendor-specific }

The update mode is configured for the FW functioning as the DDNS client.
By default, the update mode is vendor-specific for the FW functioning as the DDNS client
l Configuring the update mode to ddns when hoping to select the DDNS update mode
defined by the RFC2136
a. Run:
name-server name-server
The DNS server for receiving update messages from the DDNS client is configured.
By default, no DNS server for receiving DDNS update messages is configured on
the FW.
b. Optional:
Run:
interval interval-time
The interval for sending DDNS update requests is set.

By default, the interval for sending DDNS update requests is 3600 seconds.
After the interval for sending DDNS update requests is set in the configured DDNS
policy, the DDNS client sends DDNS update requests at intervals.
l Configuring the update mode to vendor-specific when hoping to make the FW
communicate with the DDNS servers provided at www.3322.org, www.dyndns.com, and
www.oray.cn) or http when hoping to make the FW communicate with an HTTP-based
common DDNS server
a. Run:
url request-url [ username username password password ]
The URL in DDNS update requests is specified.

To ensure password security, you are advised to run the username username
password password command to configure a user name and password. The
password information in the configuration file is displayed in cipher text.
After a DDNS policy is created, enter the URL and specify a DDNS server in the
URL. The processes for the device to request DDNS updates from different DDNS
servers are different; therefore, the URL configurations of DDNS servers are
different.
NOTE
After the TCP login and registration of the FW to the DDNS server provided by
www.oray.cn is completed. The FW needs to cut the TCP connection to enter the state of
keeping heartbeat in a long term. The protocol of keeping heartbeat uses UDP port 6060.
The FW must send the updated packets to the DDNS server every 60 seconds. If the DDNS
server does not receive the update requests sent by the FW, it deletes all the domain named
registered by the FW. During the period of keeping heartbeat, the FW will not regularly send
the DDNS update packets to the DDNS server actively.
n If username username password password is not specified, the URL contains
the user name and password, and their configurations are displayed in plain
text.
The different modes of configuring URLs in which the FW sends requests for
updating the DNS entries to different DDNS servers are shown as follows:

Sending Requests for Updates Mode of Configuring the URL

to the DDNS Server of the DDNS Server
Using HTTP to communicate with http://

the DDNS server provided at www. username:password@members.
3322.org 3322.org/dyndns/update?
system=dyndns/update?
system=dyndns&hostname=<h>&m
yip=<a>

the DDNS server provided at www. username:password@update.dyndns.
3322.org com/nic/update?
hostname=<h>&myip=<a>
Using TCP to communicate with the oray://

DDNS server provided at username:password@phddnsdev.ora
www.oray.cn y.net
Using HTTP to communicate with a http://

common DDNS server username:password@merri.s.dnaip.fi
/reg/h=<h>&a=<a>
NOTE
In the preceding URLs, username and password indicate the user name and password for
logging in to the DDNS server. Set these parameters based on the registry information. For
example, in http://huawei1:huawei2@merri.s.dnaip.fi/reg/h=<h>&a=<a>, huawei1 and
huawei2 indicate the user name and password for logging in to the DDNS server.
n If username username password password is specified, the URL only
contains the fixed format <username>:<password>, not the user name and
password. The user name and password are specified by username and
password, and the password configuration is displayed in cipher text.
The different modes of configuring URLs in which the FW sends requests for
updating the DNS entries to different DDNS servers are shown as follows:

the DDNS server provided at www. <username>:<password>@members.
3322.org 3322.org/dyndns/update?
system=dyndns/update?
system=dyndns&hostname=<h>&m
yip=<a>

the DDNS server provided at www. <username>:<password>@update.dy
3322.org ndns.com/nic/update?
hostname=<h>&myip=<a>


Using TCP to communicate with the oray://

DDNS server provided at <username>:<password>@phddnsde
www.oray.cn v.oray.net
Using HTTP to communicate with a http://

common DDNS server <username>:<password>@merri.s.d
naip.fi/reg/h=<h>&a=<a>
NOTE
○ If the URL needs to include a question mark (?), enter the first part of double quotation
marks (""), the URL including a question mark (?), and the last part of double quotation
marks ("") in sequence. That is, the URL must be enclosed by double quotation marks
("").
○ In the preceding URLs, <username> and <password> are fixed formats, which cannot
be modified.
○ The DDNS service is provided by DDNS servers from different vendors. When the
DDNS server URL changes or the DDNS server stops providing service, the device
used as the DDNS client cannot exchange packets with the DDNS server. The DDNS
function may not take effect.If you fail to update the mapping entries between the
DDNS domain name and IP address, you are advised to upgrade the router to the latest
version.
b. Optional:
Run:
interval interval-time
The interval for sending DDNS update requests after the DDNS update is enabled is
set on the FW.
After the interval for sending DDNS update requests is set in the configured DDNS
policy, the device sends DDNS update requests at intervals. By default, the interval
for sending DDNS update requests is 3600 seconds.
----End
4.6.5.3.2 Applying a DDNS Policy

This section describes the methods and procedure for applying DDNS policies.
Context
You can bind a DDNS policy to an interface to update the mapping between the domain name
and an IP address and to start DDNS update.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The interface view is displayed.

Step 3 Run:
ddns apply policy policy-name
The DDNS policy is bound to the interface.

By default, no DDNS policy is bound to an interface.
----End
4.6.5.3.3 Manually Updating DDNS

This section describes the methods and procedure for manually updating DDNS.
Context
To update DDNS manually can complete the update of the mapping between domain names
and IPv4 addresses in time. The DNS server can obtain the latest information to provide to the
DNS client.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ddns refresh
The DDNS client is triggered manually to send a request to the DDNS server for updating the
mapping between domain names and IP addresses.
NOTE
When the network is stable, it is recommended that you do not run this command to update DDNS for
many time within a short period of time. For the DDNS updates can be completely performed every time
you manually update DDNS, it may result in the unstable status of the connection between the DDNS
client and the DDNS server.
----End
4.6.5.4 Configuring DNS Transparent Proxy

This section describes how to configure DNS transparent proxy on the CLI.
Prerequisites
l One or two DNS server addresses are obtained from each ISP as the DNS server
addresses bound on interfaces.

l You cannot deploy any DNS server on the intranet. If a DNS server is deployed on the
intranet, the DNS transparent proxy function does not take effect, because DNS query
messages are forwarded to the intranet DNS server for domain name analysis, and the
FW is not used for DNS transparent proxy on these DNS query messages.
Context
DNS transparent proxy and ISP Link Selection are used together. ISP link selection ensures
that users access a server through the ISP network where the server resides, preventing cross-
ISP network access. For the implementation of DNS transparent proxy, see DNS Transparent
Proxy.
Procedure
system-view
Step 2 Enable the DNS transparent proxy function.
dns transparent-proxy enable
By default, the DNS transparent proxy function is enabled.
Step 3 Set the IP address of the DNS server bound to the interface.
dns server bind interface interface-type interface-number preferred preferred-dns-address
[ alternate alternate-dns-address ] [ healthchk { enable [ times times | tx-interval tx-
interval ] * | disable } ]
The FW uses the address of the preferred DNS server (preferred preferred-dns-address) to
replace the destination addresses of DNS query messages. When the preferred DNS server is
down, the FW will replace the destination addresses of DNS query messages with the address
of the alternate DNS server (alternate alternate-dns-address).
Step 4 Specify the domain names that do not require DNS transparent proxy.
dns transparent-proxy exclude domain domain-name [ server server-address ]
If you exclude a domain name from DNS transparent proxy, even if DNS transparent proxy is
configured on the DNS server specified on the client, the FW directly forwards the DNS
query messages without honoring the messages. If you specify the DNS server address for
resolving this domain name (server server-address), the DNS query messages are forwarded
to this server, not to the DNS server specified on clients.
If multiple domain names do not require DNS transparent processing, you need to perform
this step for these domain names.
Step 5 Configure a DNS transparent proxy policy.
1. Access the DNS transparent proxy policy view.
dns-transparent-policy
2. Create a DNS transparent proxy policy rule or access the view of an existing DNS
transparent proxy policy.
rule name rule-name
3. Configure a description for the DNS transparent proxy policy rule.

description text
4. Enable the transparent DNS proxy policy rule.
enable
By default, the DNS transparent proxy policy rule is enabled.
5. Configure an action for the DNS transparent proxy policy rule.
action { tpdns | no-tpdns }
6. Configure a source IP address for the DNS transparent proxy policy rule.
source-address { address-set address-set-name &<1-6> | ipv4-address { ipv4-mask-
length | mask mask-address } | range ipv4-start-address ipv4-end-address | any }
7. Configure a destination IP address for the DNS transparent proxy policy rule.
destination-address { address-set address-set-name &<1-6> | ipv4-address { ipv4-
mask-length | mask mask-address } | range ipv4-start-address ipv4-end-address | any }
----End
4.6.5.5 Maintaining DNS

After configuring DNS, you can run the display commands to view the configuration or
monitor DNS running status. You can also clear DNS entries or enable the debugging function
if necessary.
Displaying DNS Configuration

Table 4-36 lists the commands to display DNS configuration.
Table 4-36 Displaying DNS configuration

Action Command
Display the global DNS display dns configuration

configurations.
Display information about static display ip host

DNS entries.
Display information about DNS display dns server

servers.
Check the configurations about display dns domain

domain name suffixes.
Display information about dynamic display dns dynamic-host

DNS entries in the domain name
cache.
Display the DNS forwarding table. display dns forward table
Displays statistics on DNS packets. display dns statistics
Display the cache of application display dns application cache


Action Command
Display the requests of application display dns application table

Table 4-37 lists the commands to display DDNS configuration.
Table 4-37 Displaying DDNS configuration
Action Command
Display information about DDNS display ddns policy [ policy-name ]

policies.
Display information about a display ddns interface interface-type interface-

DDNS policy applied to a specific number
interface.
Table 4-38 lists the operation for checking information about DNS transparent proxy policies.
Table 4-38 Checking information about DNS transparent proxy policies
Action Command
Check information about DNS display dns-transparent-policy { all [ slot slot-id

transparent proxy policies. cpu cpu-id ] | rule rule-name }
Clearing DNS Entries

Table 4-39 lists the commands run in the user view to clear DNS entries.
Table 4-39 Clearing DNS entries
Action Command
Clear dynamic DNS entries reset dns dynamic-host

statistics in the domain name cache.
Debugging DNS

NOTICE
For details on the description of the debugging commands, see Debugging Reference.
Table 4-40 lists the commands to debug DNS information.
Table 4-40 Debugging DNS

Action Command
Enable the DNS debugging. debugging dns
Table 4-41 lists the commands to debug DDNS.
Table 4-41 Debugging DDNS

Action Command
Enable the debugging of all DDNS debugging ddns all

information.
Enable the DDNS error debugging ddns error

debugging.
Enable the DDNS event debugging ddns event

debugging.
Enable the DDNS packet debugging ddns packet

debugging.

This section provides examples for configuring DNS, DDNS, DNS Proxy.
4.6.6.1 CLI: Example for Configuring the Device as a DNS Client

This section provides an example for configuring the device as a DDNS CLient.
A FW functioning as a gateway connects PCs on an intranet to the Internet. The interface IP
addresses, a security zone, a security policy, and a NAT policy are configured on the FW. The
DNS function needs to be configured on the FW. The FW functions as a DHCP relay agent
and sends domain names that users on PCs enter to a DNS server on the Internet. Upon
receipt, the DNS server translates the domain names into IP addresses to allow the PCs to
access the Internet. The IP address of a DNS server on the Internet is 2.2.2.2.

Figure 4-37 Networking diagram of configuring the FW as a DNS Client
Trust Untrust
DNS Server
PC FW 2.2.2.2
Intranet
GE1/0/3 GE1/0/1
10.3.0.1/24 1.1.1.1/24
PC
1. Configure the FW to function as a DNS Client to realize dynamic domain resolution and
communicate with the specific DNS server.
2. Configure the domain name suffix on the FW to support a domain name suffix list.
3. Set the IP address of the gateway of the internal PCs and the IP address of the DNS
server to 10.3.0.1. This example provides the configuration procedure on the FW, not on
PCs.
Data Planning
Interface number: IP address: 1.1.1.1/24 -

GigabitEthernet 1/0/1 Security zone: Untrust
Interface number: IP address: 10.3.0.1/24 -

GigabitEthernet 1/0/3 Security zone: rust
DNS Server IP address: 2.2.2.2/24 -
Procedure
Step 1 Configure IP addresses for interfaces and assign them to security zones.
# Configure the IP address for GigabitEthernet 1/0/3 and assign it to the Trust zone.
<FW> sysname-view
# Configure an IP address for GigabitEthernet 1/0/1 and assign it to the Untrust zone.


Step 2 Configure the function of dynamic domain resolution on the FW.

# Enable the function of dynamic domain resolution.
[FW] dns resolve
# Specify the DNS server.

# Configure the DNS domain suffix.

[FW] dns domain net
[FW] dns domain com
----End
1. Run the command display dns server on the FW to check the configuration information
of the DNS server.
[FW] display dns server
Type:
D:Dynamic
S:Static
No. Type Status IP

Address
0 S - 2.2.2.2
2. Run the command display dns dynamic-host on the FW to check the information of
dynamic DNS entries in the cache of domain names.
[FW] display dns dynamic-host
Host TTL Type
Address(es)
example.com 114 IP 2.2.2.1
Total : 1
3. Check whether the internal PCs can access to the Internet by domain names. If they can,
it means that the configuration is successful. Otherwise, please check the configuration.
#
dns resolve
dns server 2.2.2.2
dns domain net
dns domain com
#
undo shutdown
ip address 10.3.0.1 255.255.255.0
#
undo shutdown
ip address 1.1.1.1 255.255.255.0
#
firewall zone trust
set priority 85

#
set priority 5
#
return
4.6.6.2 CLI: Example for Configuring the Device as a DNS Proxy

This section provides an example for configuring the device as a DNS Proxy.
As shown in Figure 4-38, the enterprise has many brach LAN in its network. There are the
DNS server and the FTP server deployed in the headquarters. In this way, users of the
branches can access to the FTP server of the headquarter by domain name. However, when
the IP address of the DNS server changes, all the DNS clients in the LANs can be affected,
which can make network maintenance difficult. The FW can be deployed on the link between
which the branch LAN and the headquarters communicate with each other, and can be
configured to function as a DNS proxy to forward the requests and response packets between
the hosts in the branch LAN and the DNS server of the headquarters. In this way, when the IP
address of the DNS server changes, only the configuration on the FW needs to be changed,
and the internal users of the LAN are not affected.
Figure 4-38 Networking diagram of configuring the FW as a DNS Proxy

DNS Server
Host_A
2.2.2.2/24
FW
GE1/0/1 GE1/0/1
1.1.1.1/24 1.1.1.2/24
Brach Headquarters
DNS Proxy
Host_B FTP Server

example.com
DNS Client
2.2.2.1/24
Enable the function of DNS proxy of the FW to realize the forward of DNS packets between
the DNS server and the DNS client.
NOTE
After the function of DNS proxy is enabled on the FW, the FW can be considered as the DNS server of
Host_A and Host_B. On both the hosts, the IP address of the DNS server needs to be specified to the IP
address of the FW. The IP address of the DNS server on the FW needs to be configured to the IP address of
the DNS server of the headquarter, 2.2.2.2. In this way, when the IP address of the DNS server changes, only
the configuration on the FW_A needs to be changes, which the internal users cannot be aware of.
Procedure
Step 1 Configure the IP address of the interfaces on the FW and assign them to security zones.
# Configure the IP address of GigabitEthernet 1/0/1 and assign it to the Trust zone.

<FW> sysname-view
[FW-GigabitEthernet 1/0/1] ip address 1.1.1.1 24
[FW-GigabitEthernet 1/0/1] quit
Step 2 Configure the function of DNS proxy on theFW.

[FW] dns resolve
Step 3 Configure the default route to the DNS server on theFW.

Assume that the next-hop address of the FW to the DNS Server is 1.1.1.2/24.
Step 4 On the hosts of the branch intranet, taking Host_A as an example, configure the IP address of
the DNS server to 1.1.1.1.
----End
# Run the command display current-configuration on the FW to display the related
configuration of DNS proxy. The following only shows the configuration related to DNS.
<FW> display current-configuration
------------------------------------------------------------------------------
#
dns resolve
dns server 3.3.3.3
dns server 2.2.2.2
dns proxy enable
------------------------------------------------------------------------------
#
dns resolve
dns server 2.2.2.2
dns proxy enable
#
undo shutdown
ip address 1.1.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2
#
return
4.6.6.3 CLI: Example for Configuring the Device as a DDNS Client (Using the
Update Mode Defined by the RFC2136)
This section provides an example for configuring the device as a DDNS Client using the
update mode defined by the RFC2136.

As shown in Figure 4-39, the Web Server is deployed at the border of the enterprise intranet.
The FW functions as the gateway to connect the intranet to the Internet. The Internet users can
access to the intranet Web server through the function of NAT server of the FW. The domain
name of the Web Server is www.example.com, which is mapped to the IP address of the
interface of the FW. However, the interface of the FW that connects to the Internet obtain the
public address through dialer-up, which can result in frequent changes of the IP address.
Configure the FW as a DDNS Client using the update mode of ddns defined by the RFC2136,
In this way, when the IP address of the FW changes, it can dynamically update the
information on the DNS server, that is, the mapping between the interface IP address of the
FW and the domain name of the internal Web server. The Internet user can access to the Web
server in the enterprise intranet normally.
Figure 4-39 Networking diagram of configuring FW as a DDNS Client

Web Server Trust Untrust
10.1.1.3/24 DNS Server
FW 2.2.2.2
1.1.1.254/24
Intranet
GE1/0/2 GE1/0/1
10.1.1.1/24
DDNS Client
PC
By configuring the FW to function as a DDNS client using the update mode of ddns, you can
realize to dynamically update the mapping between the IP address and the domain name of
the Web server on the DNS server, when the interface IP address of the FW changes.
Procedure
Step 1 Configure the IP address of the interface and assign it to the security zone.
<FW> sysname-view
Step 2 Configure a security policy to allow users of external networks to access the internal Web
server.
[FW-policy-security] rule name policy1
[FW-policy-security-rule-policy1] source-zone untrust
[FW-policy-security-rule-policy1] destination-zone trust
[FW-policy-security-rule-policy1] destination-address 10.1.1.3 24
[FW-policy-security-rule-policy1] action permit
[FW-policy-security-rule-policy1] quit

Step 3 Configure a static mapping based on interface to map the public IP address of GigabitEthernet
1/0/1 to the private IP address of the Web server 10.1.1.3, with the public port of 80 and the
private port of 8080.
[FW] nat server policy_web protocol tcp global interface GigabitEthernet 1/0/1 80
inside 10.1.1.3 8080
Step 4 Configure a DDNS policy.

# Create a DDNS policy.
<FW> system-view
[FW] ddns policy mypolicy
[FW-ddns-policy-mypolicy] method ddns both
[FW-ddns-policy-mypolicy] name-server 2.2.2.2
[FW-ddns-policy-mypolicy] interval 3600
[FW-ddns-policy-mypolicy] quit
# Apply the DDNS policy to GigabitEthernet1/0/1.

[FW] interface GigabitEthernet1/0/1
[FW-GigabitEthernet1/0/1] ddns apply policy mypolicy fqdn www.example.com
NOTE
After the configuration is completed, when the IP address of GigabitEthernet1/0/1 changes, theFW notifies
the DNS server to update the mapping between the domain name www.example.com and the new IP address.
In this way, users on the Internet can access the new IP address by the domain name www.example.com.
Step 5 Configure the default route on the FW to the DNS server. Assume the IP address of the peer
of the FW is 1.1.1.254/24.
----End
Run the command display ddns policy mypolicy on the FW to display the information of the
DDNS policy named mypolicy.
<FW> display ddns policy mypolicy
Policy name : mypolicy
Server : 2.2.2.2
User name : -
Password : -
Update method : ddns both
Update interval : 3600 seconds
Apply interface : GigabitEthernet1/0/1
#
ddns policy mypolicy
method ddns both
name-server 2.2.2.2
#
undo shutdown
ddns apply policy mypolicy
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
firewall zone trust
set priority 85

#
set priority 5
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#
nat server policy_web 0 protocol tcp global interface GigabitEthernet1/0/1 www
inside 10.1.1.3 8080
#
security-policy
rule name policy1
source-zone trust
action permit
#
return
4.6.6.4 CLI Example for Configuring the Device as a DDNS Client (Using the
Update Mode Implemented Through the DDNS Server)
This section provides an example for configuring the device as a DDNS Client using the
update mode implemented through the DDNS server.
As shown in Figure 4-40, the Web Server is deployed at the border of the enterprise intranet.
The FW functions as the gateway to connect the intranet to the Internet. The Internet users can
access to the intranet Web server through the function of NAT server of the FW. The domain
name of the Web Server is www.example.com, which is mapped to the IP address of the
interface of the FW. However, the interface of the FW that connects to the Internet obtain the
public address through dialer-up, which can result in frequent changes of the IP address.
Configure the FW as a DDNS Client using the update mode of http or vendor-specific,
which is implemented through the DDNS server. In this way, when the IP address of the FW
changes, it send the request of updating domain to the DDNS server. The DDNS server
notifies the DNS server to update the mapping between the interface IP address of the FW and
the domain name of the internal Web server. The Internet user can access to the Web server in
the enterprise intranet normally.
Figure 4-40 Networking diagram of configuring FW as a DDNS Client
Web Server Trust Untrust

10.1.1.3/24 DNS Server
FW 2.2.2.2
1.1.1.254/24
Intranet
GE1/0/2 GE1/0/1
10.1.1.1/24
DDNS Client
PC

1. By configuring the FW to function as a DDNS client using the update mode of ddns,
you can realize to dynamically update the mapping between the IP address and the
domain name of the Web server on the DNS server, when the interface IP address of the
FW changes.
2. Assign 10.3.0.1 to the FW that functions as a gateway for the web server on the intranet.
This example provides the configuration procedure on the FW. The configuration details
on the web server are not provided.
Procedure
Step 1 Configure the IP address of the interface and assign it to the security zone.
<FW> sysname-view
Step 2 Configure a security policy to allow users of external networks to access the internal Web
server.
[FW-policy-security] rule name policy1
[FW-policy-security-rule-policy1] source-zone untrust
[FW-policy-security-rule-policy1] destination-zone trust
[FW-policy-security-rule-policy1] destination-address 10.1.1.3 24
[FW-policy-security-rule-policy1] action permit
[FW-policy-security-rule-policy1] quit
Step 3 Configure a static mapping based on interface to map the public IP address of GigabitEthernet
1/0/1 to the private IP address of the Web server 10.1.1.3, with the public port of 80 and the
private port of 8080.
[FW] nat server policy_web protocol tcp global interface GigabitEthernet 1/0/1 80
inside 10.1.1.3 8080
Step 4 Configure a DDNS policy.

# Create a DDNS policy.
<FW> system-view
[FW] ddns policy mypolicy
[FW-ddns-policy-mypolicy] method vendor-specific
[FW-ddns-policy-mypolicy] url oray://steven:nevets@phddnsdev.oray.net
[FW-ddns-policy-mypolicy] interval 3600
[FW-ddns-policy-mypolicy] quit
NOTE
By default, the update mode of the DDNS client is vendor-specific. If the default update mode is not
modified by running the method command, do not run the method vendor-specific command.
# Enable the function of DNS and specify the DNS server.

[FW] dns resolve
# Apply the DDNS policy to GigabitEthernet1/0/1.

[FW-GigabitEthernet1/0/1] ddns apply policy mypolicy

NOTE
After the configuration is completed, when the IP address of GigabitEthernet1/0/1 changes, theFW notifies
the DNS server to update the mapping between the domain name www.example.com and the new IP address.
In this way, users on the Internet can access the new IP address by the domain name www.example.com.
Step 5 Configure the default route on the FW to the DNS server. Assume the IP address of the peer
of the FW is 1.1.1.254/24.
----End
Run the command display ddns policy mypolicy on the FW to display the information of the
DDNS policy named mypolicy.
[FW] display ddns policy mypolicy
Server : url oray://steven:nevets@phddnsdev.oray.net
User name : -
Password : -
Update method : vendor-specific
Apply interface : GigabitEthernet1/0/1
# Run the command display ddns interface GigabitEthernet 1/0/1 on the FW, you can
check the information of GigabitEthernet 1/0/1 related to the DDNS policy. Presume that the
public IP address obtained by GigabitEthernet 1/0/1 is 1.1.10.10.
[FW] display ddns interface GigabitEthernet 1/0/1
Policies applied on interface GigabitEthernet1/0/1 :
------------------------------------------------------------------------------
Server : oray://steven:nevets@phddnsdev.oray.net
User name : -
Password : -
Update method : vendor-specific
Current status : INIT
Client IP : 1.1.10.10
Server IP : 3.3.3.3
The configuration script of FW.
#
dns resolve
dns server 2.2.2.2
#
ddns policy mypolicy
interval 300
url oray://steven:nevets@phddnsdev.oray.net
#
undo shutdown
ddns apply policy mypolicy
#
firewall zone trust
set priority 85
#
set priority 5

#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#
nat server policy_web 0 protocol tcp global interface GigabitEthernet1/0/1 www
inside 10.1.1.3 8080
#
security-policy
rule name policy1
source-zone unrust
action permit
#
return
4.6.6.5 CLI: Example for Configuring DNS Transparent Proxy

This section provides an example for configuring DNS transparent proxy.
As shown in Figure 4-41, an enterprise rents links from both ISP1 and ISP2. The bandwidth
of ISP1 link is 100M, and that of ISP2 link is 50M. The DNS server addresses of ISP1 are
8.8.8.8 and 8.8.8.9, and the DNS server addresses of ISP2 are 9.9.9.8 and 9.9.9.9. The DNS
server address specified on all intranet user clients is 10.2.0.70.
l The enterprise requires that the Internet access traffic of intranet users residing on
network segment 10.3.0.0/24 can be distributed to ISP1 and ISP2 links in the ratio of 2:1
to ensure that the links are made full use of but not congested to improve users' Internet
access experience.
l When intranet users access domain name www.example.com, FW does not perform DNS
transparent proxying, but the Web server address of the domain name must be resolved
by the specified DNS server (8.8.8.10).
l When one link is overloaded (the threshold is 90%), follow-up traffic will be forwarded
on the other link.

Figure 4-41 Intranet users accessing DNS servers
www.example.com
DNS server Web server on ISP1 Web server on ISP2
8.8.8.10
ISP2
ISP1
100M 50M
DNS server on ISP1 GE1/0/1 GE1/0/7 DNS server on ISP2
8.8.8.8 1.1.1.1 2.2.2.2 9.9.9.8
8.8.8.9 9.9.9.9
FW
GE1/0/3
10.3.0.1
Set the DNS server

address on all PCs to
10.2.0.70.
Intranet
DNS requests
Modified DNS requests
Configure the transparent proxy function on the FW to distribute DNS query messages from
intranet users in the ratio of 2:1 to the DNS servers on ISP1 and ISP2 networks. In this case,
the Internet access traffic from intranet users can also be distributed to ISP1 and ISP2 links in
the ratio of 2:1. When processing DNS query messages, the DNS transparent proxy function
replaces the destination addresses of the messages with the DNS server address bound to the
outbound interface. The selection of the outbound interface depends on the intelligent uplink
selection function. Because the enterprise requires that the Internet access traffic can be
distributed in the ratio of 2:1 to both links, you need to set the intelligent uplink selection
mode to load balancing by link bandwidth. In the example, global link selection policies are
configured. To ensure that the Internet access traffic is directly forwarded to the Web server
on the ISP network of the destination address without taking a detour on other ISP networks,
you need to configure ISP address database link selection.
1. Optional: Configure the health check function. Configure a health check respectively for
ISP1 and ISP2.

2. Set the interface IP address, security zone, gateway, bandwidth, and overload protection
threshold, and apply the health check respectively on the interfaces.
3. Configure ISP link selection function. Make two ISP address files, isp1.csv and isp2.csv,
and upload the two ISP address files to the FW.
4. Configure DNS transparent proxy. Bind the DNS server address on the outbound
interface, specify the DNS server addresses requiring DNS transparent proxy, and
specify the domain names to be excluded.
5. Configuring a global link selection policy. Set the intelligent uplink selection mode to
load balancing by link bandwidth and configure the outbound interfaces on the FW
connecting to ISP1 and ISP2 as intelligent uplink selection member interfaces.
6. Configure a basic security policy to allow intranet users to access the Internet.
Procedure
Step 1 Optional: Enable the health check function and create a health check for ISP1 and ISP2 link
respectively. It is assumed that the destination network segment for health check is
3.3.10.0/24 on ISP1 network and is 9.9.20.0/24 on ISP2 network.
<FW> system-view
[FW] healthcheck enable
[FW] healthcheck name isp1_health
[FW-healthcheck-isp1_health] destination 3.3.10.10 interface GigabitEthernet
1/0/1 protocol tcp-simple destination-port 10001
[FW-healthcheck-isp1_health] quit
[FW] healthcheck name isp2_health
[FW-healthcheck-isp2_health] quit
Step 2 Configure IP addresses, gateway addresses, bandwidth, overload protection thresholds for
interfaces and apply health check on the interfaces.
[FW-GigabitEthernet1/0/1] gateway 1.1.1.254
[FW-GigabitEthernet1/0/1] bandwidth ingress 100000 threshold 90
[FW-GigabitEthernet1/0/1] bandwidth egress 100000 threshold 90
[FW-GigabitEthernet1/0/1] healthcheck isp1_health
[FW-GigabitEthernet1/0/7] gateway 2.2.2.254
[FW-GigabitEthernet1/0/7] bandwidth ingress 50000 threshold 90
[FW-GigabitEthernet1/0/7] bandwidth egress 50000 threshold 90
[FW-GigabitEthernet1/0/7] healthcheck isp2_health
Step 3 Upload ISP address files to the FW using SFTP. Details are omitted.
Step 4 Create ISP name isp1_ifgrp for ISP1 and ISP name isp2_ifgrp for ISP2 and associate them
with the corresponding ISP address files.
[FW] isp name isp1_ifgrp
[FW] isp name isp1_ifgrp set filename isp1.csv
[FW] isp name isp2_ifgrp
[FW] isp name isp2_ifgrp set filename isp2.csv

Step 5 Create an ISP interface group for ISP1 and ISP2 respectively and add interfaces to
corresponding ISP interface groups. Then ISP routes will be delivered by default.
[FW] interface-group 1 isp isp1_ifgrp
[FW-interface-isp-group-1] add interface GigabitEthernet 1/0/1
[FW-interface-isp-group-1] quit
[FW] interface-group 2 isp isp2_ifgrp
[FW-interface-isp-group-2] add interface GigabitEthernet 1/0/7
[FW-interface-isp-group-2] quit
Step 6 Configure DNS transparent proxy. Bind the DNS server address to the outbound interface,
implement DNS transparent proxy for traffic whose source address belongs to network
segment 10.3.0.0/24, and configure excluded domain names.
[FW] dns transparent-proxy enable
[FW] dns server bind interface GigabitEthernet 1/0/1 preferred 8.8.8.8 alternate
8.8.8.9
[FW] dns server bind interface GigabitEthernet 1/0/7 preferred 9.9.9.8 alternate
9.9.9.9
[FW] dns transparent-proxy exclude domain www.example.com server 8.8.8.10
[FW] dns-transparent-policy
[FW-policy-dns] rule name abc
[FW-policy-dns-rule-abc] action tpdns
[FW-policy-dns-rule-abc] source-address 10.3.0.0 24
[FW-policy-dns-rule-abc] quit
[FW-policy-dns] quit
Step 7 Configure a global route selection policy to load balance traffic by link bandwidth.
[FW] multi-interface
[FW-multi-inter] add interface GigabitEthernet1/0/1
[FW-multi-inter] add interface GigabitEthernet1/0/7
[FW-multi-inter] mode proportion-of-bandwidth
[FW-multi-inter] quit
Step 8 Assign the interfaces to security zones.

Step 9 Configure a security policy between the Trust and Untrust zones to allow intranet users to
access extranet resources. It is assumed that the intranet user network segment is 10.3.0.0/24.
[FW-policy-security] rule name policy_sec_trust_untrust
[FW-policy-security-rule-policy_sec_trust_untrust] source-zone trust
[FW-policy-security-rule-policy_sec_trust_untrust] destination-zone untrust
[FW-policy-security-rule-policy_sec_trust_untrust] source-address 10.3.0.0 24
[FW-policy-security-rule-policy_sec_trust_untrust] action permit
[FW-policy-security-rule-policy_sec_trust_untrust] quit
----End
#
isp name isp1_ifgrp
isp name isp1_ifgrp set filename isp1.csv
isp name isp2_ifgrp
isp name isp2_ifgrp set filename isp2.csv
#
dns transparent-proxy enable
dns server bind interface GigabitEthernet1/0/1 preferred 8.8.8.8 alternate
8.8.8.9

dns server bind interface GigabitEthernet1/0/7 preferred 9.9.9.8 alternate

9.9.9.9
dns transparent-proxy exclude domain www.example.com server 8.8.8.10
#
healthcheck enable
healthcheck name isp1_health
destination 3.3.10.10 interface GigabitEthernet1/0/1 protocol tcp-simple
destination-port 10001
healthcheck name isp2_health
#
ip address 1.1.1.1 255.255.255.0
healthcheck isp1_health
gateway 1.1.1.254
bandwidth ingress 100000 threshold 90
bandwidth egress 100000 threshold 90
#
ip address 10.3.0.1 255.255.255.0
#
ip address 2.2.2.2 255.255.255.0
healthcheck isp2_health
gateway 2.2.2.254
bandwidth ingress 50000 threshold 90
bandwidth egress 50000 threshold 90
#
firewall zone trust
set priority 85
#
set priority 5
#
interface-group 1 isp isp1_ifgrp
#
interface-group 2 isp isp2_ifgrp
#
multi-interface
mode proportion-of-bandwidth
#
security-policy
rule name policy_sec_trust_untrust
source-zone trust
action permit
#
dns-transparent-policy
rule name abc
action tpdns
#
return

4.6.7 Troubleshooting for DNS

This section describes how to troubleshoot DNS problems.
4.6.7.1 Dynamic Domain Name Resolution Cannot Be Implemented on a DNS

Client
Fault Description
The FW functions as a DNS client that is configured with dynamic domain name resolution
but cannot resolve domain names to IP addresses correctly.
Procedure
Step 1 Run the display dns dynamic-host command check whether the specified domain name
exists in the dynamic domain name cache.
l If not, check whether the DNS client communicates with the DNS server properly, the
DNS server runs properly, and dynamic domain name resolution is enabled.
l If so, but the IP address is incorrect, go to step 2.
Step 2 Run the display dns server command to verify that the IP address of the DNS server is
correct on the DNS client.
If the DNS server IP address is incorrect, run the undo dns server ip-address command to
delete the configured DNS server IP address, and run the dns server ip-address command to
reconfigure a correct IP address for the DNS server.
----End

This section provides DNS references.
This section provides DNS specifications.
Configuring the device to The DNS client is used for Supported by all models.
serve as a DNS client online signature database
upgrade and PKI CRL
download.

Configuring the device to The DNS proxy forwards a Supported by all models.
serve as a DNS proxy DNS request packet from a
DNS client to a DNS server
and a response packet from
the DNS server to the DNS
client. It searches the local
domain name resolution
table before forwarding a
DNS request.
Configuring the device to The DNS relay forwards a Supported by all models.
serve as a DNS relay DNS request packet from a
DNS client to a DNS server
and a response packet from
the DNS server to the DNS
client. However, it does not
search the local domain
name resolution table before
forwarding a DNS request.
Instead, it directly forwards
the packet to the DNS
server.
Function Sub-Function Specifications
DNS Client Maximum number of 6

configurable DNS servers
Number of configurable 50
static DNS entries
Number of configurable 10
domain name suffixes in a
domain name list
Maximum number entries in 50

a dynamic domain name
cache

This section describes the versions and changes in the DNS feature.


This section provides DNS standards and protocols as the reference for you to further study
the knowledge about this feature.
DNS standards and protocols are as follows:
l RFC 1034: Domain Names - Concepts and Facilities
l RFC 1035: Domain Names - Implementation and Specification
4.7 DHCP
This section describes DHCP concepts and how to configure DHCP, as well as provides
4.7.1 Introduction
The Dynamic Host Configuration Protocol (DHCP) applies to IPv4 networks to dynamically
assign information, such as IPv4 addresses to clients.
Definition
DHCP is a technology used to dynamically manage and configure IPv4 addresses for clients.
DHCP uses the client/server model. A client applies to a server for parameters, such as the
IPv4 address, default gateway address, DNS server address, and WINS server address. The
server replies with corresponding configuration parameters based on policies. DHCP dynamic
allocates IPv4 addresses and allows you to configure and manage other network parameters
on a server before delivering the parameters to clients.
Objective
As the network expands and network complexity increases, the number of PCs usually
exceeds the number of available IPv4 addresses. Furthermore, with the popularity of laptops
and wireless networks, PC locations and IPv4 addresses are changeable. To dynamically and
properly assign IPv4 addresses to hosts, DHCP is introduced.
DHCP is developed based on the Bootstrap Protocol (BOOTP). BOOTP runs in a static
environment where each host has a fixed network connection. An administrator configures a
specific BOOTP parameter file for each host, and the file keeps unchanged in a long period.
DHCP extends BOOTP in the following aspects:
l DHCP provides automatic allocation of reused network addresses and configuration
options, which enables a PC to obtain required configurations by sending a request.
l DHCP dynamically assigns an IPv4 address to each host, instead of specifying an IPv4
address for each host.
DHCP dynamically manages and configures IPv4 addresses for clients in a concentrated
manner, which simplifies manual configuration and enables enterprise users to adapt to
frequent network changes.
4.7.2 Application Scenario

This section describes the application scenarios of DHCP.

4.7.2.1 The Device Serving as a DHCP Server

This section describes the application scenario in which the device serves as a DHCP Server.
Generally, the DHCP server is used to assign IP addresses in the following scenarios:
l On a large network, manual configurations take a long time and bring difficulties to
centralized management over the entire network.
l Only a few hosts on the network require fixed IP addresses, and most hosts can avoid
using fixed IP addresses.
l Hosts on the network are more than available IP addresses. Thus, not every host has a
fixed IP address. Many hosts must share a few IP addresses through the DHCP server.
Typical Application
A DHCP server is used in the following two application scenarios:
l The DHCP server and clients reside on the same network segment.
The FW functions as a DHCP server to connect to DHCP clients using a Layer 2 switch
(or hub) on the network shown in Figure 4-42.
Figure 4-42 Typical network where the DHCP server and clients reside on the same
network segment
WINS DHCP DHCP DHCP

Server Client Client Client
FW
Layer 2 Layer 2
LAN switch LAN switch
DHCP Server
DNS FTP DHCP DHCP

Server Server Client Client
Network Segment 1 Network Segment 2
l The DHCP server and clients reside on different network segments.

When the DHCP server and clients reside on different network segments, the DHCP
server needs to assign IP addresses to clients across network segments with the help of a
DHCP relay.
As shown in Figure 4-43, the DHCP server and clients reside on different network
segment. A DHCP relay is deployed on the same network segment as the clients. In this

way, the DHCP clients communicate with the DHCP server through the DHCP server.
For the detailed scenario description, please refer to 4.7.2.2 The Device Serving as a
DHCP Relay.
Figure 4-43 Typical network where the DHCP server and clients reside on different
network segments
FW_A FW_B
DHCP Client DHCP Relay DHCP Server

Network Segment 1 Network Segment 2
A DHCP server can provide the following services:

l Configure address pools and an address lease, which enables the DHCP server to
dynamically allocate IP addresses to DHCP clients.
l Reserve IP addresses for devices with fixed IP addresses, such as an FTP server.
l Assign fixed IP addresses to application servers and special hosts to realize static
allocation of IP addresses.
l Configure IP address detection to prevent the DHCP server from allocating a single IP
address to different clients.
l Configure network parameters on the DHCP server for the clients. The parameters
include DNS server addresses, default gateway addresses, and WINS server addresses.
4.7.2.2 The Device Serving as a DHCP Relay

This section describes the application scenario in which the device serves as a DHCP Relay.
A DHCP client sends a DHCP Request packet to apply for a dynamic IP address in broadcast
mode. This means that the DHCP server can receive the request only if the server is on the
same network segment as the client. Deploying a DHCP server on each network segment to
assign IP addresses is uneconomical.
DHCP relay can be used to address this problem. DHCP relay allows DHCP clients on
different network segments to communicate with a single DHCP server and obtain IP
addresses. This function helps reduce costs and facilitate centralized management.
Typical Application
The DHCP server and clients reside on different network segments, as shown in Figure 4-44.
A DHCP relay agent is deployed to enable DHCP clients to obtain configuration information,
such as IP addresses, from the DHCP server.

Figure 4-44 Typical networking application of DHCP relay

DHCP Client
Network
Segment 1
FW_A FW_B
Network
Segment 2 DHCP Relay DHCP Server
Network
DHCP Clients Segment 3
4.7.2.3 The Device Serving as a DHCP Client or BOOTP Client

This section describes the application scenario in which the device works as a DHCP Client
or BOOTP Client.
Some network border devices cannot obtain fixed IP addresses because IP addresses are
insufficient. To address this problem, the network devices can be configured as DHCP clients
or BOOTP clients and dynamically obtain configuration information, such as IP addresses,
from a DHCP server.
The DHCP Server can communicate with BOOTP clients, so there is no need for users to
configure BOOTP server. The DHCP server can be configured to allocate IP addresses for
BOOTP clients.
Typical Application
This typical application only set the case in which the FW functions as a DHCP client as an
example. The case in which the FW functions as a BOOTP client is similar, and thus omitted.
A building shown in Figure 4-45 accesses the Internet through a router, and the router also
works as a DHCP server to assign IP addresses to enterprise users in the building. The FW
functions as a gateway for a small enterprise in the building. The DHCP client function is
enabled on Interface 1 of the FW to enable Interface 1 to dynamically obtain network
parameters, including an IP address, from the DHCP server and to provide online services for
enterprise users.

Figure 4-45 Typical networking application of a DHCP client
FW
Enterprise Network
边缘网络
Interface 2 Interface 1
DHCP Server DHCP Client DHCP Server
A FW that functions as a DHCP client provides the following services:

l Dynamically obtains network parameters, such as an IP address, an egress gateway, a
DNS server, a domain name suffix, and a static route.
l Proactively refreshes network parameters, such as an IP address, an egress gateway, a
DNS server, a domain name suffix, and a static route.
The DHCP client and server functions can be enabled on different interfaces of the same
device. For example, the DHCP client function is enabled on the FW Interface 1 that connects
to the network shown in Figure 4-45. The DHCP client function enables the interface to
obtain an IP address and configurations from the DHCP server. Meanwhile, the DHCP server
function is enabled on the FW Interface 2 that connects to the enterprise network. The DHCP
server function enables Interface 2 to allocate IP addresses to PCs on the enterprise network.
4.7.3 Mechanism
This section describes the implementation of DHCP.
4.7.3.1 Introduction to DHCP Packets

This section describe DHCP packet format and DHCP packet types.
Format of a DHCP Packet

The DHCP packets format is based on the BOOTP message format. The packets are
encapsulated using UDP. Figure 4-46 shows the format of a DHCP packet.

Figure 4-46 DHCP packet format
In Figure 4-46, numbers in the round brackets indicate the field length in bytes. Table 4-42
shows the description of each field in the DHCP packet.
Table 4-42 Description of each field in the DHCP packet

Field Length Description
op 1 byte Indicates the operation types of packets. Types are as follows:

(Message l 1: The client request packet
op code)
l 2: The server response packet
htype 1 byte Indicates the type of hardware addresses. It is valid only for
(Hardware Ethernet now. The value is 1.
Address
Type)
hlen 1 byte Indicates the length of hardware addresses, in bytes. It is valid

(Hardware only for Ethernet now. The value is 6.
Address
Length)

hops 1 byte Indicates the number of DHCP relays that current DHCP packets
pass. This field is set to 0 by the client. When passing a DHCP
relay, this field increases by 1. This field is used to limit the
number of DHCP relays that DHCP packets pass.
NOTE
The number of DHCP relays between the server and client cannot exceed
4. That is, the value of hops cannot be greater than 4. Otherwise, DHCP
packets are discarded.
xid 4 bytes Indicates the random number selected by clients. This number
(Transactio associates the packet replied by the server with the packet sent by
n ID) the client.
secs 2 bytes Indicates the seconds that elapse since a client begin address
(Seconds) acquisition or renewal process, in seconds.
flags 2 bytes Indicates the Flag field. Only the most significant bit has meaning,
and the rest bits are 0. The most significant bit is the broadcast
response flag bit. It determines whether the DHCP server
responds to packets in unicast or broadcast mode. The meaning of
each value is as follows:
l 0: in unicast mode
l 1: in broadcast mode
ciaddr 4 bytes Indicates the IP address of the client. The address can either be a
(Client IP client IP address assigned by the server or an existing client IP
Address) address. In the initial state, the client does not have an IP address.
This field is 0.0.0.0.
NOTE
The IP address 0.0.0.0 is used only for temporary communication after the
system in DHCP mode starts up. It cannot be an effective destination
address.
yiaddr 4 bytes Indicates the IP address assigned to the client by the server.
(Your
(Client) IP
Address)
siaddr 4 bytes Indicates the IP address of the server.

(Server IP
Address)

giaddr 4 bytes Indicates the IP address of the first DHCP relay. The client sends
(Relay a DHCP request. If the server and client are in different networks,
Agent IP the first DHCP relay fills this field with its IP address when
Address) forwarding this DHCP request. The server determines the network
segment address based on this field, and then selects the address
pool to be assigned to the client. The server also sends this
response packet to this first DHCP relay. Then, the DHCP relay
sends this packet to the client.
NOTE
If the packet passes more than one DHCP relay before arriving at the
DHCP server, the relay after the first DHCP relay adds 1 to the number of
hops without changing this field.
chaddr 16 Indicates the MAC address of the client. This field is the same as
(Client bytes the preceding "Hardware Type" and "Hardware Length". When a
Hardware DHCP request is sent, the client fills this field with its hardware
Address) address. For the Ethernet, this field must be filled with a 6-byte
Ethernet MAC address when the "Hardware Type" and "Hardware
Length" are 1 and 6 respectively.
sname 64 Indicates the server name of the configuration information

(Server bytes obtained by the client. This field is optional and is filled by the
Host DHCP server with a string of characters ending with 0.
Name)
file (Boot 128 Indicates the startup configured file name of the client. This field
File Name) bytes is optional and is filled by the DHCP server with a string of
characters ending with 0.
options Variabl Indicates the Option field of DHCP. It cannot be less than 312
e bytes. This field contains the configuration information, such as
the IP address of the gateway, DNS server, and NetBIOS server,
assigned by the server to the client. The client can use information
such as the valid lease time of IP addresses. For details, refer to
Format and Functions of the Options Field.
DHCP Packet Types

DHCP packets are of eight types. The communication between the DHCP server and client is
performed through these eight types of packets.
Table 4-43 DHCP packet types

Message Description
Name
DHCP A DHCP Discover packet is broadcast by a DHCP client to locate a

DISCOVER DHCP server when the client attempts to connect to a network for the
first time.

Message Description
Name
DHCP OFFER A DHCP Offer packet is sent by a DHCP server to respond to a DHCP
Discover packet. A DHCP Offer packet carries various configuration
information.
DHCP A DHCP Request packet is sent in the following conditions:

REQUEST l After a DHCP client is initialized, it broadcasts a DHCP Request
packet to respond to the DHCP Offer packet sent by a DHCP server.
l After a DHCP client restarts, it broadcasts a DHCP Request packet to
confirm the configuration including the assigned IP address.
l After a DHCP client obtains an IP address, it unicasts or broadcasts a
DHCP Request packet to update the IP address lease.
DHCP ACK A DHCP ACK packet is sent by a DHCP server to acknowledge the
DHCP Request packet from a DHCP client. After receiving a DHCP
ACK packet, the DHCP client obtains the configuration parameters
including the IP address.
DHCP NAK A DHCP NAK packet is sent by a DHCP server to reject the DHCP
Request packet from a DHCP client. For example, after a DHCP server
receives a DHCP Request packet, it cannot find matching lease records.
Then the DHCP server sends a DHCP NAK packet, notifying that no IP
address is available for the DHCP client.
DHCP A DHCP Decline packet is sent by a DHCP client to notify the DHCP
DECLINE server that the assigned IP address conflicts with another IP address.
Then the DHCP client applies to the DHCP server for another IP address.
DHCP A DHCP Release packet is sent by a DHCP client to release its IP

RELEASE address. After receiving a DHCP Release packet, the DHCP server can
assign this IP address to another DHCP client.
DHCP A DHCP Inform packet is sent by a DHCP client to obtain other network
INFORM configuration parameters such as the gateway address and DNS server
address after the DHCP client has obtained an IP address.
Format and Functions of the Options Field

Format of the Options Field
Figure 4-47 shows the format of the Options field.
Figure 4-47 Format of the Options field
0 7 15
Code Length Value

The Options field consists of Code, Length, and Value. Table 4-44 shows the description of
each field in the Options field.
Table 4-44 Description of each field in the Options field

Code 1 byte Indicates option code. It uniquely

identifies the following information.
Length 1 byte Indicates the length of the following

information.
Value Its value is specified by the Indicates the information contained.

Length field.
The value of the Options field ranges from 1 to 255. Table 4-45 lists common DHCP options.
Table 4-45 Description of the Options field in DHCP packets

Options No. Function
1 Specifies the subnet mask.
3 Specifies the gateway address.
6 Specifies the DNS server IP address.
12 Specifies the hostname.
15 Specifies the domain name.
33 Specifies a group of classful static routes. This option

contains a group of classful static routes. When a DHCP
client receives DHCP packets with this option, it adds the
classful static routes contained in the option to its routing
table. In classful routes, masks of destination addresses are
natural masks and masks cannot be used to divide subnets. If
Option 121 exists, this option is ignored.
44 Specifies the NetBIOS name.
46 Specifies the NetBIOS object type.
50 Specifies the requested IP address.
51 Specifies the IP address lease.
52 Specifies the additional option.
53 Specifies the DHCP packet type.
54 Specifies the server identifier.
55 Specifies the parameter request list. It is used by a DHCP

client to request specified configuration parameters.

Options No. Function
58 Specifies the lease renewal time (T1), which is 50% of the

lease time.
59 Specifies the lease renewal time (T2), which is 87.5% of the

lease time.
60 Specifies the vendor classification information option, which

identifies the DHCP client type and configuration.
61 Specifies Client identifier.
66 Specifies the TFTP server name allocated to DHCP clients.
67 Specifies the Bootfile name allocated to DHCP clients.
77 Specifies the user type.
121 Specifies a group of classless routes. This option contains a

group of classless static routes. After a DHCP client receives
DHCP packets with this option, it adds the classless static
routes contained in the option to its routing table. Classless
routes are routes of which masks of destination addresses can
be any values and masks can be used to divide subnets.
Functions of the Options Field

The Options field in DHCP packets can be used to carry the control information and
parameters that are not defined in some common protocols. If the DHCP server is configured
with options, the DHCP client obtains the configuration information in the Options field
through DHCP response packets that are replied by the server when applying for an IP
address.
The objects of this field vary with the functions of the Options field. For example, Option 77
is used on the DHCP client to identify user types or applications of the DHCP client.
According to the User Class in the Option field, the DHCP server selects a proper address
pool and configuration parameters. Option 77 is configured on the DHCP client by the users,
and not on the server through the command.
For the meaning and usages of DHCP Option Code, refer to RFC 2132.
4.7.3.2 Typical Networking of DHCP

DHCP adopts the mode of Client and Server. The DHCP clients send requests to the DHCP
servers to obtain network configuration information. The DHCP server response with the
corresponding configuration information of network parameters, such as IP addresses, sub-
network masks and default gateways, according to the policies.
The typical networking diagram of DHCP is shown in Figure 4-48.

Figure 4-48 Typical networking diagram of DHCP
FW_A
FW_C FW_B
DHCP DHCP
Relay Server
DHCP Client
DHCP involves the following roles:

l DHCP Client:
A DHCP client exchanges packets with a DHCP server to obtain an IP address and other
configuration parameters.
On the FW, an interface can function as a DHCP client to dynamically obtain
configuration parameters such as an IP address from a DHCP server. This facilitates
configurations and centralized management.
l DHCP Server
A DHCP server processes requests of address allocation, address lease extending, and
address releasing from a DHCP client or a DHCP relay agent, and allocates IP addresses
and other network configuration parameters to the DHCP client.
l (Optional) DHCP Relay
A DHCP relay forwards DHCP packets between a DHCP server and DHCP clients to
help the DHCP server to dynamically allocate network parameters to the DHCP clients.
When a DHCP client broadcasts DISCOVER packets with the destination IP address
255.255.255.255, only the DHCP server on the same network segment as the DHCP
client can receive the DISCOVER packets. If a DHCP server is on a different network
segment from the DHCP client, a DHCP relay agent must be deployed to forward DHCP
packets to the DHCP server. Different from traditional IP packet forwarding, the DHCP
relay agent changes the format of a DHCP DISCOVER or OFFER message, generates
the new DHCP packets, and then forwards it.
On an enterprise network where terminals are located on multiple network segments, you
can deploy a DHCP relay agent if the terminals need to obtain network parameters
through DHCP. The terminals can apply to one DHCP server for required configurations,
saving server resources and facilitating unified management.
4.7.3.3 How a DHCP Server Allocates Network Parameters to New DHCP Clients
This section describes the mechanism of the interaction between the DHCP server and clients
which access to a network for the first time.
The following parts introduce the mechanism of DHCP clients accessing to a network for the
first time in the scenarios of having a DHCP relay deployed or not respectively.

l Network Parameter Allocation Without a DHCP Relay Agent

l Network Parameter Allocation with DHCP Relay Agents
Network Parameter Allocation Without a DHCP Relay Agent

Upon the first access to a network, a DHCP client exchanges DHCP messages with the DHCP
server in four stages to obtain network parameters, as shown in Figure 4-49.
NOTE
DHCP messages are transmitted using the User Datagram Protocol (UDP). A DHCP client sends
messages with UDP port 67 to a DHCP server, and a DHCP server sends messages with UDP port 68 to
a DHCP client.
Figure 4-49 Message exchange between a DHCP server and a new DHCP client when no
DHCP relay agent is deployed
Discovering stage: DHCP DISCOVER

Step 1
Offering stage: DHCP OFFER

Step 2
Selecting stage: DHCP REQUEST
Step 3
Acknowledge stage: DHCP ACK/DHCP NAK
Step 4
1. Discovery stage: The DHCP client detects DHCP servers.

The DHCP client broadcasts a DHCP Discover message (with destination IP address
255.255.255.255) to detect DHCP servers because the client does not know IP addresses
of DHCP servers. All DHCP servers and relay agents on the same network segment as
the DHCP client can receive the DHCP Discover message. Information carried in a
DHCP Discover message includes the client's MAC address (Chaddr field), parameter
request list (Option 55 field, indicating the network parameters required by the client),
and broadcast flag (Flags field, determining whether the response should be sent in
unicast or broadcast mode).
NOTE
l The Options field in a DHCP Discover message defines network parameters that a client requires.
Each option identifies a parameter. For example, Option 3 indicates the requested gateway address.
(A client adds Option 3 in the Option 55 field when it requests the gateway address.) Option 53
indicates the DHCP message type (such as Discover message). Options are classified into well-
known and self-defined options. For more information about well-known DHCP options, see RFC
2132. Vendors can define their own options, for example, Option 43 is defined to indicate vendor-
specific information. For details on options, see Format and Functions of the Options Field.
l The Flags field is defined in RFC 2131. The leftmost bit of this field indicates whether the server is
required to send the DHCP Offer/ACK message in unicast or broadcast mode. The value 0 indicates
the unicast mode, and the value 1 indicates the broadcast mode.

2. Offer stage: A DHCP server offers network parameters to the DHCP client.
All DHCP servers on the same network segment as the DHCP client can receive the
DHCP Discover message. Each DHCP server may have multiple address pools to
manage network parameters including allocatable IP addresses. A DHCP server selects
an address pool on the same network segment as the IP address of the interface receiving
the DHCP Discover message, and selects an idle IP address from the address pool. The
DHCP server then sends a DHCP Offer message carrying the allocated IP address (in the
Yiaddr field) to the DHCP client. The DHCP Offer message also carries other network
parameters such as the IP address lease.
In most cases, an address pool specifies the leases of IP addresses in it. If the DHCP
Discover message carries an expected lease, the DHCP server compares the expected
lease with the specified lease and allocates the IP address with a smaller lease to the
DHCP client.
IP addresses in an address pool are added to different IP address lists based on the IP
address status. Unallocated IP addresses belong to the allocatable IP address list.
Allocated IP addresses belong to the in-use IP address list. Conflicting IP addresses
belong to the conflicting IP address list. IP addresses that cannot be allocated belong to
the unallocatable IP address list. The DHCP server selects an IP address for the client
from the address pool in the following sequence:
a. IP address statically bound to the MAC address of the client on the DHCP server
b. IP address that has been allocated to the client
c. IP address specified in the Option 50 field (requested IP address) in the DHCP
Discover message
d. Largest allocatable IP address
e. If the DHCP server does not find any allocatable IP address, it searches for the
expired IP addresses and conflicting IP addresses in turn, and then allocates a valid
IP address to the client. If all the IP addresses are in use, the DHCP server replies
with a DHCP NAK message to notify the client that no IP address is available.
After receiving the DHCP NAK message, the DHCP client sends a DHCP Discover
message to apply for a new IP address.
NOTE
The FWcan exclude some IP addresses that cannot be allocated through DHCP from address
pools. For example, if 192.168.1.100/24 has been manually configured for the DNS server,
the DHCP server needs to exclude this IP address from the address pool on network segment
192.168.1.0/24. In this way, IP address 192.168.1.100 will not be allocated through DHCP,
preventing IP address conflicts.
To prevent conflicts between a newly allocated IP address with existing IP addresses, the
DHCP server sends an ICMP Echo Request packet with the IP address to be allocated in
both the source and destination IP address fields before sending a DHCP Offer messages.
If the DHCP server receives no ICMP Echo Reply packet within the detection period, no
client is using this IP address, and the DHCP server can allocate it. If the DHCP server
receives an ICMP Echo Reply packet within the detection period, this IP address has
been used by another client, and the DHCP server lists this IP address as a conflicting IP
address. The DCHP server then waits for the next DHCP Discover message to start the
IP address selection process again.
NOTE
The IP address allocated in this stage may not be the final IP address used by the client. This is
because the IP address may be allocated to another client if the DHCP server receives no response
16 seconds after the DHCP Offer message is sent. The IP address for the client can be determined
only after the request and acknowledge stages.

3. Request stage: The DHCP client selects an IP address.

The client sends a DHCP Discover message in broadcast message, so all DHCP servers
on the local network segment can receive the message. When multiple DHCP servers
send DHCP Offer messages to the DHCP client, the client accepts only the first received
DHCP Offer message. The client then broadcasts a DHCP Request message carrying the
selected DHCP server identifier (Option 54) and IP address (Option 50, with the IP
address specified in the Yiaddr field of the accepted DHCP Offer message).
The DHCP Request message notifies all the DHCP servers that the DHCP client has
selected the IP address offered by a DHCP server. Then the other servers can allocate IP
addresses to other clients.
4. Acknowledgment stage: The DHCP server acknowledges the IP address offered to the
client.
After the DHCP server receives the DHCP Request message, it sends a DHCP ACK
message to the client, carrying the IP address specified in the Option 50 field of the
Request message.
After receiving the DHCP ACK message, the DHCP client broadcasts gratuitous ARP
packets to check whether any other terminal is using the IP address allocated by the
DHCP server. If no response is received within the specified time, the DHCP client can
use the IP address. If the DHCP client receives a response within the specified time, this
IP address has been used by other terminal . The client then sends a DHCP Decline
message to the DHCP server and applies for a new IP address. The DHCP server lists
this IP address as a conflicting IP address. The DHCP server allocates conflicting IP
addresses only when no idle IP address exists in the address pools, minimizing IP
address conflicts.
Sometimes, the DHCP server may fail to allocate the IP address specified in the Option
50 field because, for example, an error occurs during negotiation or it takes a long time
to receive the DHCP Request message. In this case, the DHCP server replies with a
DHCP NAK message to notify the DHCP client that the requested IP address cannot be
allocated. The DHCP client then sends a DHCP Discover message to apply for a new IP
address.
Network Parameter Allocation with DHCP Relay Agents

After a DHCP client connects to the network for the first time, the DHCP client exchanges
DHCP messages with the DHCP relay agent and DHCP server in four stages to obtain
network parameters, as shown in Figure 4-50. The interaction between the DHCP client and
server is similar to that described in Network Parameter Allocation Without a DHCP
Relay Agent. The following describes the working mechanism of the DHCP relay agent.

Figure 4-50 Process of applying an IP address of a DHCP Client through a DHCP relay
DHCP DISCOVER (Broadcast) DHCP DISCOVER (Unicast)

Step 1
DHCP OFFER (Unicast) DHCP OFFER (Unicast)

Step 2
DHCP REQUEST (Broadcast) DHCP REQUEST (Unicast)

Step 3
DHCP ACK/DHCP NAK (Unicast) DHCP ACK/DHCP NAK (Unicast)

Step 4
1. Discovery stage
The DHCP Client sends a DHCP DISCOVER broadcast packet on the local network.
When receiving a DHCP DISCOVER broadcast packet on the local network where no
DHCP server exists, the device functioning as a DHCP relay agent performs the
following steps:
a. Check whether the value of the Hops field exceeds 32. If so, the DHCP relay agent
discards the message. If not, the DHCP relay agent increases this value by 1 and
proceeds to the next step.
The Hops field indicates the number of DHCP relay agents that a DHCP message
has passed through. This field is set to 0 by a DHCP client or a server. Its value
increases by 1 each time the message passes through a DHCP relay agent. This field
can limit the number of DHCP relay agents that a DHCP message can pass through.
Currently, the FW supports a maximum of 32 DHCP relay agents are allowed
between a DHCP client and server.
b. Check whether the value of the Giaddr field is 0. If so, the DHCP relay agent sets
the Giaddr field to the IP address of the interface receiving the DHCP Discover
message. If not, the DHCP relay agent does not change the field and proceeds to the
next step.
The Giaddr field indicates the gateway IP address. If the DHCP server and client
are located on different network segments, the first DHCP relay agent fills this field
with its own IP address and forwards the message to the DHCP server. Other DHCP
relay agents on the path forward the message without changing this field. The
DHCP server determines which network segment the client resides based on the
Giaddr field, and allocates an IP address on this network segment to the client.
c. Change the destination IP address of the DHCP Discover message to the IP address
of the DHCP server or the next-hop DHCP relay agent, and change the source IP
address to the IP address of the interface connecting the DHCP relay agent to the
client. The message is then sent to the DHCP server or the next-hop DHCP relay
agent through unicast routing.
After the process mentioned above, the DHCP relay forwards the unicast packets to the
specific DHCP server on the other network or the next DHCP relay.

NOTE
If multiple DHCP relay agents exist between the DHCP client and server, the DHCP relay agents
process the DHCP Discover message using the same method.
2. Offer stage
After receiving the DHCP Discover message, the DHCP server selects an address pool
on the same network segment as that specified in the Giaddr field and allocates an IP
address and other network parameters from the address pool. The IP address selection
rule is the same as that described in Network Parameter Allocation Without a DHCP
Relay Agent. The DHCP server then sends a unicast DHCP Offer message to the DHCP
relay agent specified in the Giaddr field.
When receiving the DHCP Offer message, the DHCP relay agent performs the following
steps:
– Check whether the value of the Giaddr field is the IP address of the interface
receiving the DHCP Offer message. If so, the DHCP relay agent proceeds to the
next step. If not, the DHCP relay agent discards the message.
– Check whether the value of the Flags field is 1. If so, the DHCP relay agent sends a
broadcast DHCP Offer message to the DHCP client. If not, the DHCP relay agent
sends a unicast the DHCP Offer message.
3. Request stage
The DHCP client sends DHCP REQUEST broadcast packets to the DHCP Relay as a
response. After receiving the packets, the DHCP relay processes the packets as described
in the first step and then sends them in the unicast mode to the DHCP server.
4. Acknowledgment stage
The DHCP server sends DHCP ACK or DHCP NAK packets to the DHCP client
through the DHCP relay. After receiving the packets, the DHCP relay processes the
packets as described in the second step and sends them to the DHCP client.
4.7.3.4 How a DHCP Client Reuses an IP Address

This section describes how the DHCP server interacts with a DHCP client which accesses to
the network not for the first time.
If a DHCP client connects to the network again, it can reuse an IP address that has been
allocated to it. This section describes how a DHCP client reuses an IP address when no DHCP
relay agent exists on the network. If a DHCP relay agent exists, the only difference is that the
DHCP relay agent processes DHCP messages. For details, see 4.7.3.3 How a DHCP Server
Allocates Network Parameters to New DHCP Clients.
NOTE
Not all clients can reuse IP addresses that have been allocated to them.
The DHCP client exchanges DHCP messages with a DHCP server, as shown in Figure 4-51.
After the two stages, the DHCP client can obtain the network parameters including IP
addresses that has been allocated to it.

Figure 4-51 Message exchange for IP address reuse between a DHCP client and a server
Selecting stage: DHCP REQUEST

Step 1
Acknowledge stage: DHCP ACK/DHCP NAK

Step 2
1. The DHCP client broadcasts a DHCP Request message carrying the IP address that the
client has used. The requested IP address is added in the Option 50 field.
2. After receiving the DHCP Request message, the DHCP server checks whether the lease
record exists based on the MAC address in the message. If so, the DHCP server replies
with a DHCP ACK message to notify the DHCP client that the requested IP address can
be used. If not, the DHCP server performs no operation and waits for a new DHCP
Discover message from the client.
4.7.3.5 How a DHCP Client Renews the IP Address Lease

This section describes the IP address lease, the function of the timers and the mechanism of
renewing the IP address lease by the DHCP client.
IP addresses that are dynamically allocated by a DHCP server have leases. A DHCP Discover
message from a DHCP client can carry an expected lease. When allocating network
parameters, the DHCP server compares the expected lease with the specified lease in the
address pool and allocates the IP address with a smaller lease to the DHCP client. When the
lease expires, the DHCP server reclaims the IP address, which can then be allocated to other
clients. This mechanism improves IP address utilization and releases IP addresses after clients
get offline. To keep using this IP address, the DHCP clients need to renew the IP address
leases.
Leases and Timers

A lease is the period beginning when a DHCP client obtains an IP address assigned by a
DHCP server and ending when the DHCP client stops using the IP address. The DHCP client
uses the Lease renewal timer, Rebinding timer, and Lease expiration timer to control leases.
The DHCP server defines a specific lease for each address pool, and the addresses in the same
DHCP address pool have the same lease.
Table 4-46 lists timers and their values.
Table 4-46 Timers and their values

Timer Value
Lease renewal 50% of a specific lease
Rebinding 87.5% of a specific lease

Timer Value
Lease expiration A configured value on a DHCP server (The

default lease is 1 day)
On a DHCP client assigned an IP address and changing to the binding status, the three timers
take effect as follows:
l After the Lease renewal timer expires, the DHCP client must renew its IP address. The
DHCP client automatically sends DHCP REQUEST packets to the DHCP server which
has ever allocated IP addresses for it, and it changes to the renewing status. If the IP
address is valid, the DHCP server replies with a DHCP ACK packet to the client to
renew the lease. The DHCP client then re-enters the binding status. If the DHCP client
receives a DHCP NAK packet, it changes to the initializing status.
l After the DHCP client sends DHCP REQUEST packets to renew the lease, it keeps in
the renewing status and waits for the response. After the Rebinding timer expires and the
client receives no response, the client considers the original DHCP server to be
unavailable and broadcasts a DHCP REQUEST message.
Any DHCP server on the network can respond to the request of the client and send a
DHCPACK or DHCPNAK message to the client.
If the client receives a DHCP ACK message, it enters the binding state and resets the
Lease renewal and Rebinding timers.
If the client receives a DHCP NAK message, it enters the initializing state, stops using
the existing IP address, and requests a new IP address.
l After the Lease expiration timer expires and the client receives no response, it stops
using this IP address immediately, returns to the initializing state, and requests a new IP
address.
IP Address Lease Renewal Without a DHCP Relay Agent

Figure 4-52 shows how a DHCP client renews its IP address lease.
Figure 4-52 Process of renewing the IP address lease

DHCP REQUEST
Step 1
DHCP ACK/DHCP NAK

Step 2

1. When the lease reaches 50% (T1), the DHCP client sends a unicast DHCP Request
message to the DHCP server to request lease renewal. If the DHCP client receives a
DHCP ACK message, the IP address lease is successfully renewed (counted from 0). If
the DHCP client receives a DHCP NAK message, the DHCP client needs to send a
DHCP Discover message to apply for a new IP address.
2. If no response is received from the DHCP server when the lease reaches 87.5% (T2), the
DHCP client sends a broadcast DHCP Request message to request lease renewal. If the
DHCP client receives a DHCP ACK message, the IP address lease is successfully
renewed (counted from 0). If the DHCP client receives a DHCP NAK message, the
DHCP client needs to send a DHCP Discover message to apply for a new IP address.
3. If no response is received when the lease expires, the DHCP client stops using the IP
address and sends a DHCP Discover message to apply for a new IP address.
NOTE
l If a DHCP client does not need to use the allocated IP address before the lease expires, the DHCP
client can send a DHCP Release message to the DHCP server to request IP address release. The
DHCP server saves the configuration of this DHCP client and records the IP address in the allocated
IP address list. This IP address can then be allocated to this DHCP client or other clients.
l A DHCP client can send a DHCP Inform message to the DHCP server to request configuration
update.
IP Address Lease Renewal with DHCP Relay Agents

Figure 4-53 shows how a DHCP client renews its IP address lease when a DHCP relay agent
is deployed.
Figure 4-53 Process of renewing the IP address lease through a DHCP relay agent
DHCP REQUEST (Unicast)

T1 Step 1
DHCP ACK/DHCP NAK (Unicast) Step 2
DHCP REQUEST (Broadcast) DHCP REQUEST (Unicast)

T2 Step 1
DHCP ACK/DHCP NAK (Unicast) DHCP ACK/DHCP NAK (Unicast)
Step 2
T1: indicates the moment when the lease renewal timer expires
T2: indicates the moment when the Rebinding timer expires
1. When the lease renewal timer of the DHCP client expires, the DHCP client can prolong
the lease by performing the following steps and the packets do not pass through DHCP
relay:
a. The DHCP client sends a unicast DHCP Request message to the same DHCP server
which assigned a IP address to it.

b. The DHCP server directly send the unicast DHCP ACK packets or DHCP NAK
packets to the DHCP client. If the DHCP client receives a DHCP ACK message,
the IP address lease is successfully renewed. If the DHCP client receives a DHCP
NAK message, the DHCP client needs to apply for a new IP address again.
2. If no response is received from the DHCP server when the lease rebinding timer of the
DHCP client expires, the DHCP client can prolong the lease by performing the following
steps and the packets pass through the DHCP relay:
a. The DHCP client sends a broadcast DHCP REQUEST packet. The DHCP relay
agent then sends the DHCP REQUEST packet to the DHCP server in unicast mode
after proper process.
b. The DHCP server sends the DHCP ACK packets or DHCP NAK packets to the
DHCP client through the DHCP relay. After the DHCP relay receives these packets,
it processes them and send them to the DHCP client. If the DHCP client receives a
DHCP ACK packet, the IP address lease is successfully renewed. If the DHCP
client receives a DHCP NAK packet, the DHCP client needs to send a DHCP
DISCOVER message to apply for a new IP address.
3. If no response is received when the lease expires, the DHCP client stops using the IP
address and sends a DHCP DISCOVER packet to apply for a new IP address.
4.7.3.6 Principles of IP Address Assignment

This section describes the concepts, principles and mechanism related to IP address
assignment.
Policies for IP Address Assignment

Different hosts may have different requirements for the IP address lease. For servers, a fixed
IP address is required for a long term; for some hosts, a certain IP address that is dynamically
assigned is needed for a long term; for some PCs, an IP address that is temporarily assigned
on demand.
To meet the preceding requirements, the DHCP server provides the following address
allocation policies:
l Manual address allocation: An administrator assigns fixed IP addresses to a few specific

hosts, such as the WWW server.
l Automatic address allocation: The server assigns fixed IP addresses to some hosts when
they are connected to the network for the first time. These IP addresses can be used by
the hosts for a long time.
l Dynamic address allocation: The server assigns IP addresses with leases to clients. The
clients need to apply for new IP addresses when the leases expire. This address
allocation policy is widely accepted by most clients.
Sequence of IP Address Assignment

The DHCP server assigns IP addresses to clients in the following sequence:
1. IP address in the database of the DHCP server that is statically bound with the client's
MAC address
2. IP address assigned to the client before, that is, the IP address in the requested IP Addr
option of the DHCP Discover packet sent by the client

3. IP address specified in the Option 50 (IP address option) field in the DHCPDISCOVER
packets sent by the client.
4. IP address first found when the server searches for available IP addresses in the DHCP
address pool
5. If the DHCP address pool has no available address, the DHCP server searches the
timeout IP addresses and the conflict IP addresses in turn for the unused IP address and
assigns the unused IP address to the client. If all the IP addresses are used, the server
sends an error message.
Address Conflict Detection

Before assigning an IP address to a client, the DHCP server needs to ping the IP address to
avoid address conflicts.
Using the ping command, you can check if there is a ping response of the address to be
assigned within the specific time. If there is no response after a specific time, it indicates that
the IP address is not in use. In this way, it is ensured that a unique IP address is assigned to the
client.
By default, two ping packets can be sent and the longest time to wait for a response is 500 ms.
4.7.4 Configuring DHCP Using the Web UI

This section describes how to configure DHCP.
4.7.4.1 Configuring the Device as a DHCP Server

A DHCP server provides dynamic and static address allocation and supports customized
configurations of DNS servers, gateways, WINS servers, NetBIOS node types, and Option
fields for clients.
Context
If a DHCP server and clients are on the same network segment, the DHCP server provides the
clients with dynamically assigned IP addresses, statically configured IP addresses, designated
DNS servers, gateways, and WINS servers.
The DHCP server and relay services cannot coexist on the same interface.
NOTE
The sum of the number of IP addresses being in use and that of expired IP addresses equals to the
number of DHCP clients. When the sum of the number of IP addresses being in use and that of expired
IP addresses reaches to the maximum of DHCP client specification, the device can automatically release
some of the expired IP addresses to reduce the memory usage.
Procedure
Step 1 Choose Network > DHCP Server > Service.
Step 2 Click Add.

NOTE
For the DHCP server configuration on the web UI, only the interface address pool is supported, and the
assigned addresses in the address pool must belong to the same network segment as the specified
interface IP address. Therefore, IP address assignment across network segments cannot be configured
for the DHCP server on the web UI.
Interface Name Name of the interface on which the DHCP server function is
configured.
The interface must be an existing one and Connection Type
must be set to Static IP.
Service Type Enable either the DHCP server or relay service on this
interface.
When the DHCP server is enabled on the interface, the Service
Type must be set to Server.
IP Addresses Range Range of IP addresses assigned to a DHCP client.

By default, the system takes the IP address mask range for the
interface as the assignable IP address range. For example, the
IP address of an interface is 192.168.1.5 255.255.255.0. When
you create a DHCP server on the interface, the system
considers IP Addresses Range to be 192.168.1.1 to
192.168.1.254 by default. Because 192.168.1.5 is the IP
address of the interface, this IP address will not be assigned. If
the assignable IP address range is different from the default
value, you can specify this parameter.
To assign a correct IP address, configure the range to be the
same as the network segment on which the IP address of the
interface for the DHCP server resides.
Subnet Mask Subnet mask of the IP address assigned to a DHCP client. The
subnet mask determines which part of an IP address serves as
the network/subnet ID and which part serves as a host ID.
By default, the system uses the mask of the interface IP
address as the subnet mask. If necessary, you can change the
subnet mask.
Default Gateway Default gateway assigned to a DHCP client.

the IP address of the DHCP client.
NOTICE
The default gateway address cannot be a broadcast address or network
address.

DNS Service Method used to set the DNS server address:

l Use System DNS Setting: enables DNS proxy on the
DHCP server and takes the default gateway address as a
DNS server address.
l Specify: specifies a DNS server address.
This parameter must be specified when the DHCP client
accesses the Internet by using domain names. The DNS and
DHCP servers must be routable.
Primary DNS Server Primary DNS server address assigned to a DHCP client.
This parameter needs to be specified when DNS Service is
Specify.
Secondary DNS Server Secondary DNS server address assigned to a DHCP client.
When the DHCP client fails to resolve domain names using the
primary DNS server, the DHCP client requests the secondary
DNS server for domain name resolution.
This parameter can be specified when DNS Service is Specify.
The secondary DNS server address must be different from the
primary one.
Advanced
Domain Name Domain name suffix assigned to a DHCP client.

After a DHCP client obtains a domain name suffix assigned by
a server and accesses network resources using domain names,
the client automatically adds the domain name suffix to an
incomplete domain name that a user enters to form a complete
domain name.
Lease Duration Lase for an address assigned to a DHCP client. The lease
specifies how long the DHCP client can use the IP address
assigned by the server.
You can set an address lease based on the duration of a
connection between a client and a physical network in an
address pool. If clients on a wireless network frequently
disconnect from the network, you can decrease the address
lease, such as to 0 days 8 hours 0 minutes. If clients are
connected to the network for a stably long period of time, you
can increase the lease or even set an infinite period.
Primary WINS Server Primary WINS server address assigned to a DHCP client.
Hosts running the Windows operating system and NetBIOS
resolve NetBIOS host names to IP addresses. The resolution
methods for NetBIOS host name include local name resolution,
broadcast query, and WINS server resolution. WINS server
resolution is implemented by a WINS server.
The primary WINS server and DHCP server must be routable.

Secondary WINS Server Secondary WINS server address assigned to a DHCP client.
When the DHCP client fails to resolve NetBIOS host names
using the primary WINS server, the client requests the
secondary WINS server for host name resolution.
The secondary WINS server and DHCP server must be
routable.
Reserved IP Address IP addresses that cannot be automatically assigned.

The IP addresses that are already assigned, such as to a DNS
server, cannot be automatically assigned to clients. You reserve
the assigned IP addresses. This configuration prevents address
conflicts and shortens the detection time during address
assignment, which improves DHCP address assignment
efficiency.
Before you designate IP addresses as reserved, enable the
DHCP and DHCP server function on the interface. If these
prerequisites are not addressed, perform operations on the
dialog box that is displayed when you create a reserved IP
address.
Bound Host MAC Bind IP addresses to be assigned in IP Addresses Range to

Address MAC addresses of clients.
When the DHCP server receives an IP address request with a
MAC address of a client, the DHCP server assigns a unique IP
address bound to the MAC address to the client.
Before you configure static address binding, enable the DHCP
service and the DHCP server function on the interface. If these
prerequisites are not addressed, perform operations on the
dialog box that is displayed when you create static address
binding.
Step 4 Click OK.

If the operation is successful, DHCP Service List is displayed on the page, and new
configuration items are added to the list.
Repeat as needed to configure the DHCP server function on multiple interfaces.
----End
4.7.4.2 Configuring the Device as a DHCP Relay

This section describes how to configure DHCP relay. DHCP relay helps a DHCP client on a
specific network segment obtain an IP address from a DHCP server on another network
segment. DHCP relay also allows DHCP clients on different network segments to share a
DHCP server.

Prerequisites
l A DHCP server has been configured based on a global address pool.
No interface address pool can be configured for the DHCP server interface that connects
to the DHCP relay agent.
l The DHCP server and DHCP relay interface are reachable to each other.
l The DHCP relay interface and client reside on the same network segment.
The IP address of the DHCP relay interface must be on the same network segment as the
IP address that the DHCP server assigns to the client.
l The default gateway address of the DHCP client must be the IP address of the DHCP
relay interface.
Context
The DHCP server and relay cannot be configured on the same interface.
Procedure
Step 1 Choose Network > DHCP Server > Service.
Step 2 Click Add.

Interface Name Name of the interface on which the DHCP relay function is
configured.
The interface must exist. Connection Type can be set only to
Static IP, and the interface IP address must be on the same
network segment as the DHCP client.
Service Type Enable either the DHCP server or relay service on this
interface.
When DHCP relay is enabled on the interface, the Service
Type must be Relay.
IPv4 Server IP Address IP address that a DHCP server assigns and the DHCP relay
agent forwards to a client.
Step 4 Click OK.

If the operation is successful, DHCP Service List is displayed on the page, and new
configuration items are added to the list.
Repeat previous operations to configure the DHCP relay function on multiple interfaces.
----End

4.7.4.3 Monitoring DHCP

By querying address lease information on a DHCP server, you can view the IP address
assigned by the DHCP server, user MAC addresses, and IP address binding type. You can also
determine whether the lease has expired.
Refreshing the Address Lease

Step 1 Choose Network > DHCP Server > Monitor.
Step 2 Click Refresh to refresh the latest information about address lease duration.
----End
Querying Address Leases

You can query only the IP addresses that are assigned by a DHCP server and do not expire, as
well as the static IP addresses that are not assigned to clients yet.
Step 1 Choose Network > DHCP Server > Monitor.
Step 2 Perform either of the following operations to query address leases:

l Select All from the search box.
l Select Interface Name from the search box and select interface names.
l Select IP Address from the search box and enter IP addresses.
Step 3 Click Query.
IP Address IP address that a DHCP server assigns to a client.
MAC Address MAC address of a client to which a DHCP server that assigns
an IP address.
Lease Expiration Expiration date and time of the lease for an IP address assigned
by a DHCP server. Values and their meanings are as follows:
l Specific time (such as 2011-11-7 18:01:20): Date and time
when a lease expires.
l NOT used: A statically bound lease is not assigned to the
specific client yet.
l Unlimited: A lease does not expire.

Status Binding status of an IP address assigned by a DHCP server.

Values and their meanings are as follows:
l Static address binding: The DHCP server statically
assigns a fixed IP address to the client with a specified
MAC address.
l Dynamic assignment: To be confirmed: The DHCP
server assigns an IP address dynamically, and the binding
between the IP address and MAC address is temporarily
specified after the DHCP server sends a DHCPOFFER
packet.
l Dynamic assignment: Succeeded: The DHCP server
assigns an IP address dynamically, and the binding between
the IP address and MAC address is successfully specified
after the DHCP server sends a DHCPACK packet.
l Released: After the client applies for IP address release, the
DHCP server cancels the binding between the IP address
and MAC address.
----End
4.7.5 DHCP Configuration Using the CLI

This section describes how to use a command line interface (CLI) to configure DHCP.
4.7.5.1 Configuring the Device as a DHCP Server

A DHCP server dynamically allocates network parameters including IP addresses to network
hosts.
4.7.5.1.1 Planning Data

This section describes how to plan data for configuring the device as a DHCP server.
Planning DHCP Servers

A client broadcasts DHCP Discovery messages. When multiple DHCP servers (or DHCP
relay agents) exist on a network segment, the client accepts only the first received DHCP
Offer message and therefore may obtain an unexpected IP address. Properly planning DHCP
servers can ensure that a client obtains network parameters from the correct DHCP server.
Note the following when planning servers:
l Plan VLANs to ensure that only one DHCP server (or a DHCP relay agent) can receive
DHCP Discovery messages in a VLAN.
l Configure DHCP snooping on client access devices to ensure that the clients can apply to
the correct DHCP servers for network parameters.

Planning IP Addresses
l IP address range that can be automatically allocated
The IP address range needs to be properly planned based on the number of concurrent
online clients on the network. If the number of IP addresses in this range is too small,
some clients cannot obtain IP addresses. If the number of IP addresses in this range is too
large, IP addresses are wasted.
l (Optional) IP addresses that cannot be automatically allocated
Some IP addresses in the address pool are reserved for devices that require static IP
addresses. For example, in an address pool ranging from 192.168.100.1 to
192.168.100.254, 192.168.100.2 is reserved for the DNS server. Exclude the IP address
192.168.100.2 from the address pool so that the DHCP server will not allocate
192.168.100.2 to other clients.
l IP address allocation
DHCP supports two mechanisms for IP address allocation. Network administrators can
select different mechanisms for hosts based on network requirements.
– Dynamic allocation: DHCP allocates an IP address with a limited validity period
(known as a lease) to a client. This mechanism applies to hosts that temporarily
connect to a network with fewer IP addresses than the total number of hosts. For
example, this mechanism can be used to allocate IP addresses to laptops used by
employees on business trips or mobile terminals in cafes.
– Static allocation: A network administrator allocates fixed IP addresses to specified
clients, and DHCP is used simply to convey the allocated addresses to the clients.
This mechanism applies to hosts with special IP address requirements. For example,
the file server of an enterprise needs to use a fixed IP address to provide services for
extranet users. Compared to manual IP address configuration, DHCP static
allocation prevents manual configuration errors and helps network administrators
perform unified maintenance and management.
NOTE
DHCP servers can allocate IP addresses as well as other network parameters to clients. Administrators can
plan other network parameters based on network requirements. For example, to enable a client to
communicate with other network devices through the domain name and obtain DNS parameters using DHCP,
plan the IP address of the DNS server and domain name of the client.
Planning Leases
Plan an IP address lease for a client based on the online duration of the client. By default, the
IP address lease is one day.
l In locations where clients often move and stay online for a short period of time, for
example, cafes, airports, and hotels, plan a short-term lease to ensure that IP addresses
are released quickly after the clients go offline.
l In locations where clients seldom move and stay online for a long period of time, for
example, office areas of an enterprise, plan a long-term lease to prevent services from
being affected by frequent lease or address renewals.
4.7.5.1.2 Enabling DHCP
Context
Before enabling the DHCP server function, you must enable DHCP in the system view.

Procedure
Step 1 Run:
system-view

Step 2 Run:
dhcp enable
DHCP is enabled.
By default, DHCP is disabled.
----End
4.7.5.1.3 Configuring an Address Pool
Context
Address pools allow DHCP servers to allocate network parameters including IP addresses to
clients. You can specify network parameters in an address pool, including the IP address
range, gateway address, and the IP address of the DNS server.
Address pools are classified into interface address pools and global address pools.
l Interface address pool: After an IP address is configured for an interface on a DHCP
server, you can create an address pool on the same network segment as this interface.
Addresses in the address pool can be allocated only to clients connected to the interface.
The interface address pool is easy to configure and can allocate IP addresses to clients on
the same network segment as the DHCP server, that is, when no DHCP relay agent
exists. A DHCP server allocates IP addresses to clients connected to one interface or IP
addresses on different network segments to clients connected to multiple interfaces.
l Global address pool: On a DHCP server, you can create an address pool on the specified
network segment in the system view. Addresses in the address pool can be allocated to
all clients connected to the DHCP server. The global address pool is applicable to the
following scenarios:
– The DHCP server and clients are not on the same network segment, that is, a DHCP
relay agent exists.
– The DHCP server and clients are on the same network segment, and the DHCP
server needs to allocate IP addresses to clients connected to one interface or IP
addresses to multiple interfaces.
NOTE
When a DHCP server and clients are on the same network segment, interface address pools are recommended
because the configuration is simple.
A DHCP server selects address pools according to the following rules:

l When no DHCP relay agent is deployed, the DHCP server selects the address pool on the
same network segment as the IP address of the interface receiving DHCP Request
messages. If the interface has a secondary IP address configured, the DHCP server
selects the address pool on the same network segment as the primary IP address.
l When DHCP relay agents are deployed, the DHCP server selects the address pool on the
same network segment as the IP address specified in the Giaddr field of received DHCP
Request messages.

NOTE
The sum of the number of IP addresses being in use and that of expired IP addresses equals to the
number of DHCP clients. When the sum of the number of IP addresses being in use and that of expired
IP addresses reaches to the maximum of DHCP client specification, the device can automatically release
some of the expired IP addresses to reduce the memory usage.
Procedure
l Creating an interface address pool
a. Run:
system-view

b. (Optional) Configuring the DHCP server to dynamically allocate IP addresses to
BOOTP clients
i. Run:
dhcp server bootp
The DHCP server is enabled to respond to BOOTP requests.

By default, a DHCP server responds to a BOOTP request.
ii. Run:
dhcp server bootp automatic
The DHCP server is enabled to dynamically allocate IP addresses to BOOTP

clients.
By default, a DHCP server does not dynamically allocate IP addresses to
BOOTP clients.
In addition to dynamically allocating IP addresses to BOOTP clients, the
device functioning as the DHCP server can also allocate IP addresses to the
BOOTP clients in static binding mode using the dhcp server static-bind ip-
address ip-address mac-address mac-address command.
c. Run:

d. Run:
An IP address is configured for the interface.
NOTE
The IP address segment of the interface is the interface address pool.

e. Run:
The interface is enabled to use the interface address pool.

By default, an interface is disabled from using the interface address pool.
The IP address range which can be dynamically allocated by the interface address
pool is the network segment where the IP address of the interface resides. The range
takes effective only on the interface.
If the device provides DHCP service for the clients on multiple interfaces as a
DHCP server. You need to run this step on each interface to enable DHCP service.

f. Run:
dhcp server ip-range start-ip-address end-ip-address
The range of IP addresses that a DHCP server pre-allocates to DHCP clients is

configured.
g. Run:
dhcp server mask { mask | mask-length }
The subnet mask of IP addresses that a DHCP server pre-allocates to DHCP clients
is configured.
h. Optional: Run:
dhcp server logging [ allocation-fail | allocation-success | release |
renew-fail | renew-success | detect-conflict | recycle-conflict ] *
The logging function during IP address allocation of the DHCP server is enabled.
By default, the logging function during IP address allocation of the DHCP server is
disabled.
l Creating a global address pool
a. Run:
system-view

b. (Optional) Configuring the DHCP server to dynamically allocate IP addresses to
BOOTP clients
i. Run:
dhcp server bootp
The DHCP server is enabled to respond to BOOTP requests.

By default, a DHCP server responds to a BOOTP request.
ii. Run:
dhcp server bootp automatic
The DHCP server is enabled to dynamically allocate IP addresses to BOOTP

clients.
By default, a DHCP server does not dynamically allocate IP addresses to
BOOTP clients.
In addition to dynamically allocating IP addresses to BOOTP clients, the
device functioning as the DHCP server can also allocate IP addresses to the
BOOTP clients in static binding mode using the dhcp server static-bind ip-
address ip-address mac-address mac-address command.
c. Run:
ip pool ip-pool-name
A global address pool is created and the global address pool view is displayed.
By default, no global address pool is created on the device.
The parameter ip-pool-name uniquely specifies the name of an address pool. For
example, create a global address pool named global_f1 for employees on the first
floor.
[sysname] ip pool global_f1
d. Run:
network ip-address [ mask { mask | mask-length } ]

The range of IP addresses that can be dynamically allocated from the global address
pool is specified.
By default, the range of IP addresses that can be allocated dynamically to clients is
not specified.
An address pool can be configured with only one IP address segment. The IP
address range is determined by the mask length.
NOTE
When specifying the IP address range, ensure that IP addresses within the range are on the same
network segment as the interface IP address of the DHCP server or DHCP relay agent to avoid
incorrect IP address allocation.
e. Optional: Run:
section section-id | start-address [ end-address ]
The IP address segment of the global address pool is specified.

A IP address pool consists of one or more IP address segments and IP address
segments cannot overlap with each other.
NOTE
When running both the network and section commands, ensure that the address segment
specified in the section command is included in the address range specified in the network
command.
f. Optional: Run:
logging [ allocation-fail | allocation-success | release | renew-fail |
renew-success | detect-conflict | recycle-conflict ] *
The logging function during IP address allocation of the DHCP server is enabled.
g. Enabling an interface to use the global address pool.
i. Run:

ii. Run:
The primary and secondary interface IP addresses are configured.

○ If the device and client are located in the same network segment (that is,
no relay exists), the device first selects the address pool in the same
network segment as the primary interface IP address to assign an IP
address. If this address pool is used up or no mapping address pool is
configured for the primary IP address, the device uses the address pool
mapping the secondary IP address.If the interface is not configured with
an IP address or no address pool is in the same network segment as the
interface address, the client cannot obtain an IP address.
NOTE
The device can select the global address pool based on the primary and secondary
interface IP addresses only when the DHCP client and server are located in the same
network segment.
○ If the device and client are located in different network segments (that is,
a relay exists), the DHCP server parses the IP address specified by the
giaddr field in the received DHCP request packet and selects the address

pool in the same network segment as this IP address to assign an IP

address to the client. If no address pool matches the parsed IP address, the
client cannot obtain an IP address.
iii. Run:
dhcp select global
The interface is enabled to use the global address pool to provide the DHCP
server function.
By default, an interface does not use the global address pool to provide the
DHCP server function.
Clients connected to the interface can obtain network parameters including IP
addresses from the global interface pool.
NOTE
This step is optional if a DHCP relay agent exists between the device and clients; this step is
mandatory if no relay agent exists.
----End
4.7.5.1.4 Configuring the Range of IP Addresses That Cannot Be Automatically

Allocated to Clients from an Address Pool
Context
Some IP addresses in an address pool may be used by servers and other clients, or some
clients may require special IP addresses. In these cases, you need to exclude these IP
addresses from the address pool so that the DHCP server does not automatically allocate these
IP addresses to clients, therefore preventing IP address conflicts. For example, in an
enterprise, a DHCP server allocates IP addresses on the network segment 192.168.1.0/24 to
employee PCs. On this network segment, 192.168.1.1 is used as the gateway IP address, and
192.168.1.10 is used as the DNS server IP address. The DNS server IP address is manually
configured to ensure stability, and other hosts obtain IP addresses using DHCP. Therefore,
192.168.1.10 must be excluded from the range of IP addresses that can be automatically
allocated.
NOTE
You do not need exclude the IP addresses of interfaces connecting to clients or the gateway address
configured using the gateway-list command. The DHCP server automatically adds these addresses to the list
of IP addresses that cannot be automatically allocated.
Procedure
l Excluding IP addresses from an interface address pool
a. Run:
system-view

b. Run:

c. Run:
dhcp server excluded-ip-address start-ip-address [ end-ip-address ]

The range of IP addresses that are not automatically allocated from the address pool
is configured.
By default, all IP addresses are automatically allocated from the address pool.
If you run this command multiple times, you can set multiple IP address ranges that
cannot be automatically allocated from the address pool.
For example, exclude 192.168.1.10 from the range of IP addresses that can be
automatically allocated.
[sysname-GigabitEthernet1/0/1] dhcp server excluded-ip-address
192.168.1.10
l Excluding IP addresses from a global address pool

a. Run:
system-view

b. Run:
The global address pool view is displayed.

c. Run:
excluded-ip-address start-ip-address [ end-ip-address ]
The range of IP addresses that are not automatically allocated from the address pool
is configured.
By default, all IP addresses are automatically allocated from the address pool.
If you run this command multiple times, you can set multiple IP address ranges that
cannot be automatically allocated from the address pool.
For example, exclude 192.168.1.10 from the range of IP addresses that can be
automatically allocated.
[sysname-ip-pool-global_f1] excluded-ip-address 192.168.1.10
----End
4.7.5.1.5 Configuring a DHCP Server to Allocate Fixed IP Addresses to Specified Clients
Context
A DHCP server leases IP addresses to clients. The clients need to apply for new IP addresses
when the lease expires. To ensure stability, some hosts need to use fixed IP addresses. In this
case, configure the DHCP server to allocate fixed IP addresses to specified clients. The MAC
addresses of the specified clients are bound to fixed IP addresses. When such a client applies
to the DHCP server for an IP address, the DHCP server searches the binding entries for the
MAC address of the client and allocates the matched IP address to the client. DHCP static
allocation prevents manual configuration errors and helps network administrators perform
unified management.
NOTE
Before performing this configuration task, ensure that the DHCP server has not allocated the IP addresses for
static allocation (using the display ip pool command). If an IP address has been allocated, change an IP
address or release the allocated address using the reset ip pool command and perform the binding again.

Procedure
l Configuring a DHCP server to allocate fixed IP addresses from an interface address pool
a. Run:
system-view

b. Run:

c. Run:
dhcp server static-bind ip-address ip-address mac-address mac-address
The DHCP server is configured to allocate fixed IP addresses to specified clients.

By default, a DHCP server does not allocate fixed IP addresses to specified clients.
The fixed IP addresses to be allocated must be within the range of IP addresses that
can be dynamically allocated from the interface address pool.
l Configuring a DHCP server to allocate fixed IP addresses from a global address pool
a. Run:
system-view

b. Run:

c. Run:
static-bind ip-address ip-address mac-address mac-address
The DHCP server is configured to allocate fixed IP addresses to specified clients.

By default, a DHCP server does not allocate fixed IP addresses to specified clients.
The fixed IP addresses to be allocated must be within the range of IP addresses that
can be dynamically allocated from the global address pool.
d. Run:
reserved ip-address mac
IP address reservation for a DHCP client is configured based on MAC addresses.

By default, IP addresses are not reserved for DHCP client.
----End
4.7.5.1.6 Configuring the Address Lease Time
Context
NOTE
This task does not take effect for BOOTP clients.
Except for allocating fixed IP addresses to specified clients, a DHCP server can
dynamically allocate IP addresses with leases to clients. This mechanism applies to scenarios

where hosts temporarily access the network and the number of idle IP addresses is less than
the total number of hosts.
The lease time varies depending on network access requirements. By default, the IP address
lease is one day.
l In locations where clients often move, for example, cafes, airports, and hotels, plan a
short-term lease to ensure that IP addresses are released quickly after the clients go
offline.
l In locations where clients seldom move, for example, office areas of an enterprise, plan a
long-term lease to prevent services from being affected by frequent address renewals.
Different address pools on a DHCP server can be configured with different IP address leases,
but the IP addresses in an address pool must be configured with the same lease.
Procedure
l Configuring the lease time based on an interface address pool
a. Run:
system-view

b. Run:

c. Run:
dhcp server lease { day day [ hour hour [ minute minute ] ] | unlimited }
The IP address lease is set.

By default, the IP address lease is one day.
l Configuring the lease time based on a global address pool
a. Run:
system-view

b. Run:

c. Run:
lease { day day [ hour hour [ minute minute ] ] | unlimited }
The IP address lease is set.

By default, the IP address lease is one day.
----End

4.7.5.1.7 Configuring IP Address Conflict Detection Before a DHCP Server Allocates IP

Addresses
Context
Before allocating an IP address to a client, the DHCP server can be configured with IP
address conflict detection to prevent address conflicts.
After IP address conflict detection is configured, a DHCP server sends an ICMP Echo
Request packet in which the source and destination IP addresses are both the specified IP
address before sending DHCP Offer messages. If the DHCP server does not receive an ICMP
Echo Reply packet after the maximum waiting period (specified using the dhcp server ping
timeout milliseconds command), the DHCP server continues to send the ICMP Echo Request
packet until the maximum number of detection times (specified using the dhcp server ping
packet number command) has been reached.
l If the DHCP server receives no ICMP Echo Reply packet within the detection period
(number of detection times x maximum waiting period), this IP address is not used by
any client and the DHCP server allocates the IP address to the client by sending a DHCP
Offer message to the client.
l If the DHCP server receives an ICMP Echo Reply packet within the detection period
(number of detection times x maximum waiting period), this IP address is being used by
a client, and the DHCP server lists this IP address as a conflicting IP address and waits
for the next DHCP Discover message.
This configuration task takes effect for both the interface and global address pools.
NOTE
If the detection period is too long, clients may fail to obtain IP addresses. Set the detection period to less than
8 seconds.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dhcp server ping packet number
The number of times the device detects IP address conflicts before allocating IP addresses is
set.
By default, the device detects IP address conflicts twice before allocating IP addresses.
Step 3 Run:
dhcp server ping timeout milliseconds
The maximum wait time for each conflict detection is set.
By default, the maximum wait time for each conflict detection is 500 milliseconds.
----End

4.7.5.1.8 Configuring Automatic Saving of IP Address Allocation Information
Context
If a DHCP server is restarted upon an upgrade or is faulty, IP address allocation information
on the DHCP server is lost. After the restart, the DHCP server needs to re-allocate IP
addresses. To prevent data loss and support data recovery upon a restart, you can configure
automatic saving of IP address allocation information (including address leases and
conflicting IP addresses) so that IP address allocation information is periodically saved in a
set of files. When the DHCP server restarts, data can be recovered from the files in storage.
This configuration task takes effect for both the interface and global address pools.
Procedure
Step 1 Run:
system-view

Step 2 Run:
dhcp server database enable
Automatic saving of IP address allocation information is enabled.

By default, the device does not periodically save IP address allocation information.
After this function is enabled, the DHCP server generates lease.txt and conflict.txt files in the
DHCP folder in storage. The lease.txt file stores lease information, and the conflict.txt file
stores conflicting IP addresses. To view information about the DHCP database, run the
display dhcp server database command.
Step 3 Run:
dhcp server database write-delay interval
The interval at which IP address allocation information is saved is set.

By default, IP address allocation information is saved every 3600 seconds in data files. The
new data files overwrite the earlier data files.
Step 4 Run:
dhcp server database recover
The device is enabled to recover IP address allocation information.

After this command is executed, the device can recover IP address allocation information
from the data files in storage.
----End
4.7.5.1.9 Configuring the Gateway Address for Clients
Context
When a DHCP client connects to a DHCP server or host outside the local network segment,
data must be forwarded through the egress gateway. You can configure the gateway address
for clients. This configuration is required only when the global address pool is used. When the

interface address pool is used, the gateway address is the IP address of the interface
connecting the DHCP server to the DHCP client.
NOTE
l In global address pool mode, if a gateway address is configured on the DHCP server, a DHCP client
obtains the gateway address from the DHCP server and automatically generates a default route to the
gateway address. If you run the option121 command on the DHCP server to allocate classless static
routes to DHCP clients, the DHCP client uses an allocated classless static route and does not
automatically generate a default route to the gateway address.
l In interface address pool mode, the egress gateway address is the IP address of the interface
connecting the DHCP server to the DHCP client. The DHCP client obtains the IP address as the
gateway address and automatically generates a default route to the gateway address. If you run the
dhcp server option121 command on the DHCP server to allocate classless static routes to DHCP
clients, the DHCP client uses an allocated classless static route and does not automatically generate a
default route to the gateway address.
You do not need to configure the gateway address for DHCP clients in the following
scenarios:
l When no DHCP relay agent is deployed, the gateway address is the IP address of the
interface connecting the DHCP server to the DHCP client.
l When a DHCP relay agent is deployed, the gateway address is the IP address of the
interface connecting the DHCP relay agent to the client.
In a scenario where Virtual Router Redundancy Protocol (VRRP) and DHCP are deployed, if
the VRRP group functions as the DHCP server, perform this task to configure the group
virtual IP address as the gateway address.
To load balance traffic and improve network reliability, you can configure multiple egress
gateways. Each address pool can be configured with a maximum of eight gateway addresses.
Depending on clients' requirements, IP addresses in address pools can be allocated using the
dynamic or static allocation mode.
l Dynamic allocation: A DHCP server dynamically allocates IP addresses to clients from
the global address pool. This mode is often used to allocate IP addresses to clients
without special requirements. This type of client is called a dynamic client. IP addresses
obtained by dynamic clients have leases.
l Static allocation: A DHCP server allocates fixed IP addresses to specified clients by
binding the IP addresses to MAC addresses of the clients. This mode is often used to
allocate IP addresses to clients with special requirements. This type of client is called a
static client.
When a global address pool is used to allocate network parameters, configuration commands
are different for dynamic and static clients.
Procedure
l Based on an interface address pool:
a. Run:
system-view

b. Run:

c. Run:
dhcp server gateway-list ip-address &<1-8>
The default gateway IP address that a DHCP server pre-allocates to DHCP clients is
configured.
l Based on a global address pool:
a. Run:
system-view

b. Run:

c. Run:
gateway-list ip-address &<1-8>
The gateway address for DHCP clients is configured.

By default, no egress gateway address is configured in the IP address pool view.
----End
4.7.5.1.10 Configuring DNS and the NetBIOS Service on the DHCP Clients
Context
When DHCP clients need to communicate with devices on other networks through host
names, you can configure the DNS or NetBIOS service.
DNS, defined by RFC 1034, is a host naming mechanism provided by TCP/IP that can
translate host names into IP addresses.
NetBIOS, defined by IBM, is applicable to small LANs with dozens of PCs to provide the
following services:
l Host naming service on a network segment through UDP port 137

l Data services (through UDP port 138), including transmitting data between programs,
notifying browser services, and setting up network neighbors on users' desktop systems
l Session services (through TCP port 139), including file sharing and printing
Clients running on the Microsoft Windows operating system use the NetBIOS protocol for
communication. When such clients are used, the Windows Internet Naming Service (WINS)
server translates host names into IP addresses. NetBIOS is vulnerable to attacks, so NetBIOS
is optional on Windows operating systems later than Windows 2000. That is, users can enable
or disable NetBIOS as required.
When a DHCP client uses the NetBIOS protocol for communication, its host name must be
mapped to an IP address. Based on the modes to obtain mapping, NetBIOS nodes are
classified into the following types:
l b-node: indicates a node in broadcast mode. This node obtains its mapping in broadcast
mode.
l p-node: indicates a node in peer-to-peer mode. This node obtains its mapping by
communicating with the NetBIOS server in unicast mode.

l m-node: indicates a node in mixed mode. An m-node is a p-node that has some broadcast
features. The node first sends broadcast packets to obtain its mapping. If no mapping is
obtained, the node sends unicast packets.
l h-node: indicates a node in hybrid mode. An h-node is a b-node enabled with an end-to-
end communication mechanism. The node first sends unicast packets to obtain its
mapping. If no mapping is obtained, the node sends broadcast packets.
NOTE
When installing a Microsoft Windows operating system on a PC, you must define a host name. Otherwise, the
system generates a host name at random. Host names are unique on a network.
static client.
Procedure
l Based on an interface address pool:
– Configuring the DNS service
i. Access the system view.
system-view
ii. Access the interface view.

iii. Run the following commands to configure the IP address of the DNS server
and domain name for the DHCP clients.
○ Configure the IP address of the DNS server for DHCP clients.
dhcp server dns-list { ip-address &<1-8> | unnumbered interface
interface-type interface-name }
By default, no DNS server IP address is configured in an address pool.

Each address pool can be configured with a maximum of eight DNS
server IP addresses.
○ Allocate the domain name to DHCP clients.
dhcp server domain-name domain-name
By default, no domain name is allocated.

– Configuring the NetBIOS service
system-view
ii. Access the interface view.


iii. Run the following commands to configure the IP address of the NetBIOS
server and NetBIOS node type for the DHCP clients.
○ Configure the IP address of the NetBIOS server for DHCP clients.
dhcp server nbns-list ip-address &<1-8>
By default, no NetBIOS server IP address is configured in an address

pool.
Each address pool can be configured with a maximum of eight NetBIOS
○ Configure the NetBIOS node type for DHCP clients.
dhcp server netbios-type { b-node | h-node | m-node | p-node }
By default, no NetBIOS node type is configured for DHCP clients.

l Based on a global address pool:
– Configuring the DNS service
system-view
ii. Access the global address pool view.

iii. Run the following commands to configure the IP address of the DNS server
and domain name for the DHCP clients.
○ Configure the IP address of the DNS server for DHCP clients.
dns-list { ip-address &<1-8> | unnumbered interface interface-
type interface-number }
By default, no DNS server IP address is configured in an address pool.

Each address pool can be configured with a maximum of eight DNS
○ Allocate the domain name to DHCP clients.
domain-name domain-name
By default, no domain name is allocated.

– Configuring the NetBIOS service
system-view
ii. Access the global address pool view.

iii. Run the following commands to configure the IP address of the NetBIOS
server and NetBIOS node type for the DHCP clients.
○ Configure the IP address of the NetBIOS server for DHCP clients.
nbns-list ip-address &<1-8>
By default, no NetBIOS server IP address is configured in an address

pool.
Each address pool can be configured with a maximum of eight NetBIOS
○ Configure the NetBIOS node type for DHCP clients.
netbios-type { b-node | h-node | m-node | p-node }
By default, no NetBIOS node type is configured for DHCP clients.

----End

4.7.5.1.11 Configuring the Configuration File for a DHCP Client
Context
Some clients can work normally only after network parameters are configured in addition to
obtained IP addresses. A DHCP server can allocate configuration information such as the
startup configuration file to clients. Configuration files may be saved on the DHCP server or
dedicated file server. The DHCP server can specify the address of the file server so that clients
can easily obtain files from the file server.
NOTE
When the startup configuration file is saved on a specified file server, the route between a DHCP client and
the file server must be reachable.
static client.
Procedure
l Configuring configuration files based on an interface address pool
a. Run:
system-view

b. Run:

c. Run:
dhcp server bootfile bootfile
The name of the startup configuration file for DHCP clients is configured.
By default, the name of the startup configuration file for DHCP clients is not
configured.
d. Run:
dhcp server sname sname
The name of the server from which DHCP clients obtain the startup configuration
file is configured.
By default, the name of the server from which a DHCP client obtains the startup
configuration file is not configured.

e. (Optional) Run:
dhcp server next-server ip-address
The IP address of a server is configured to provide the network service for the client
after the client automatically obtains the IP address.
By default, the server IP address is not configured for the client after the client
automatically obtains the IP address.
To obtain files from the file server, perform this step.
l Configuring configuration files based on a global address pool
a. Run:
system-view

b. Run:

c. Run:
bootfile bootfile
The name of the startup configuration file for DHCP clients is configured.
By default, the name of the startup configuration file for DHCP clients is not
configured.
d. Run:
sname sname
The name of the server from which DHCP clients obtain the startup configuration
file is configured.
By default, the name of the server from which a DHCP client obtains the startup
configuration file is not configured.
e. (Optional) Run:
next-server ip-address
The IP address of a server is configured to provide the network service for the client
after the client automatically obtains the IP address.
By default, the server IP address is not configured for the client after the client
automatically obtains the IP address.
To obtain files from the file server, perform this step.
----End
4.7.5.1.12 Configuring User-defined Options for Clients
Context
Vendors can define DHCP options. A device functioning as the DHCP server can allocate
vendor-defined network parameters to clients using the following methods:

static client.
The configuration commands for dynamic DHCP clients and static DHCP clients are
different, when the IP addresses are configured based on a global address pool.
Procedure
l Configuring user-defined options for clients based on an interface address pool:
a. Run:
system-view

b. (Optional) Run:
dhcp server trust option82
The DHCP server is enabled to trust Option 82.
By default, the device is enabled to trust Option 82.
The Option 82 field is called the DHCP relay agent information field. It records the
location of a DHCP client, based on which a DHCP server can select address
allocation policies including IP addresses and other network parameters. Vendors
can define Option 82 based on their requirements. Currently, a device functioning
as the DHCP server cannot allocate network parameters to clients based on policies.
After the device is enabled to trust Option 82, the device normally allocates IP
addresses to clients. If the device is disabled from trusting Option 82, the device
discards received messages carrying Option 82.
c. Run:

d. Run:
dhcp server option code [ sub-option sub-code ] { ascii ascii-string |
hex hex-string | cipher cipher-string | ip-address ip-address &<1-8> }
DHCP options are configured.
By default, no option is configured.
NOTE
When an option carries a password, ascii and hex are insecure. The cipher type is recommended.
For security, the password must consist of at least six characters and contain at least two of the
following: digits, lowercase letters a to z, uppercase letters A to Z, and special characters.
After an option is configured, the device provides this option only when requested
by clients.
Some options are configured using other commands, as described in the following
table.

Table 4-47 Commands for configuring options

Option Configuration Description
Command
Option1 mask-length in the ip Specifies the subnet

address ip-address mask.
{ mask | mask-length }
command
Option3 ip-address in the ip Specifies the gateway

address ip-address address.
command
Option6 dhcp server dns-list Specifies the DNS server

(interface view) ip- IP address.
address &<1-8>
Option15 dhcp server domain- Specifies the domain

name domain-name name.
Option44 dhcp server nbns-list Specifies the NetBIOS

ip-address &<1-8> server IP address.
Option46 dhcp server netbios- Specifies the NetBIOS

type { b-node | h-node | node type.
m-node | p-node }
Option50 Does not need to be Specifies the requested

configured on the DHCP IP address.
server
Option51 dhcp server lease { day Specifies the IP address

day [ hour hour lease.
[ minute minute ] ] |
unlimited }
Option52 Does not need to be Specifies the additional

configured on the DHCP option.
server
Option53 Does not need to be Specifies the DHCP

configured on the DHCP message type.
server
Option54 Does not need to be Specifies the server

configured on the DHCP identifier.
server
Option55 Does not need to be Specifies the parameter

configured on the DHCP request list.
server
Option57 Does not need to be Specifies the maximum

configured on the DHCP length of a DHCP
server message.


Command
Option58 Does not need to be Specifies the lease

configured on the DHCP renewal time (T1), which
server is 50% of the lease time.

configured on the DHCP renewal time (T2), which
server is 87.5% of the lease
time.
Option61 Does not need to be Specifies the client

configured on the DHCP identifier.
server
Option82 Does not need to be Specifies relay agent

configured on the DHCP information.
server
Option121 dhcp server option121 Specifies a group of

ip-address { ip-address classless routes.
mask-length gateway-
address } &<1-8>
Option184 dhcp server option184 Specifies voice

{ as-ip ip-address | fail- parameters.
over ip-address dialer-
string | ncp-ip ip-address
| voice-vlan vlan-id }
e. Run:
dhcp server option121 ip-address { ip-address mask-length gateway-
address } &<1-8>
A classless static route allocated to a DHCP client is configured.

By default, no classless static route allocated to DHCP clients is configured.
f. Run:
dhcp server option184 { as-ip ip-address | fail-over ip-address dialer-
string | ncp-ip ip-address | voice-vlan vlan-id }
Option 184 allocated to DHCP clients is configured.

By default, the Option 184 field is not configured.
l Configuring user-defined options for clients based on a global address pool
– In the global address pool view:
i. Run:
system-view

ii. (Optional) Run:
dhcp server trust option82
The DHCP server is enabled to trust Option 82.

By default, the device is enabled to trust Option 82.

The Option 82 field is called the DHCP relay agent information field. It
records the location of a DHCP client, based on which a DHCP server can
select address allocation policies including IP addresses and other network
parameters. Vendors can define Option 82 based on their requirements.
Currently, a device functioning as the DHCP server cannot allocate network
parameters to clients based on policies. After the device is enabled to trust
Option 82, the device normally allocates IP addresses to clients. If the device
is disabled from trusting Option 82, the device discards received messages
carrying Option 82.
iii. Run:
The IP pool view is entered.

iv. Run:
option code [ sub-option sub-code ] { ascii ascii-string | hex hex-
string | cipher cipher-string | ip-address ip-address &<1-8> }
DHCP options are configured.

By default, no option is configured.
NOTE
When an option carries a password, ascii and hex are insecure. The cipher type is
recommended. For security, the password must consist of at least six characters and contain
at least two of the following: digits, lowercase letters a to z, uppercase letters A to Z, and
special characters.
Some options are configured using other commands, as described in the
following table.
Table 4-48 Commands for configuring options

Command
Option1 mask-length in the Specifies the subnet

network (IP address mask.
pool view) ip-address
command
Option3 gateway-list ip-address Specifies the gateway

&<1-8> address.
Option6 dns-list ip-address Specifies the DNS

&<1-8> server IP address.
Option15 domain-name domain- Specifies the domain

name name.
Option44 nbns-list ip-address Specifies the NetBIOS

&<1-8> server IP address.
Option46 netbios-type { b-node Specifies the NetBIOS

| h-node | m-node | p- node type.
node }


Command
Option50 Does not need to be Specifies the requested

configured on the IP address.
DHCP server
Option51 lease { day day [ hour Specifies the IP address

hour [ minute lease.
minute ] ] | unlimited }
Option52 Does not need to be Specifies the additional

configured on the option.
DHCP server
Option53 Does not need to be Specifies the DHCP

configured on the message type.
DHCP server
Option54 Does not need to be Specifies the server

configured on the identifier.
DHCP server
Option55 Does not need to be Specifies the parameter

configured on the request list.
DHCP server
Option57 Does not need to be Specifies the maximum

configured on the length of a DHCP
DHCP server message.

configured on the renewal time (T1),
DHCP server which is 50% of the
lease time.

configured on the renewal time (T2),
DHCP server which is 87.5% of the
lease time.
Option61 Does not need to be Specifies the client

configured on the identifier.
DHCP server
Option82 Does not need to be Specifies relay agent

configured on the information.
DHCP server
Option121 option121 ip-address Specifies a group of

{ ip-address mask- classless routes.
length gateway-
address } &<1-8>


Command
Option184 option184 { as-ip ip- Specifies voice

address | fail-over ip- parameters.
address dialer-string |
ncp-ip ip-address |
voice-vlan vlan-id }
v. Run:
option121 ip-address { ip-address mask-length gateway-address }
&<1-8>
A classless static route allocated to a DHCP client is configured.

By default, no classless static route allocated to DHCP clients is configured.
vi. Run:
option184 { as-ip ip-address | fail-over ip-address dialer-string |
ncp-ip ip-address | voice-vlan vlan-id }
Option 184 allocated to DHCP clients is configured.

By default, the Option 184 field is not configured.
----End
4.7.5.2 Configuring the Device as a DHCP Relay

A DHCP client communicates with and obtains an IP address from a DHCP server on another
network segment through a DHCP relay agent. DHCP relay allows DHCP clients on different
network segments to share a DHCP server, which reduces costs and manage information
uniformly.
Prerequisites
l A DHCP server has been configured based on a global address pool.
No interface address pool can be configured for the DHCP server interface that connects
to the DHCP relay.
l The DHCP server and the DHCP relay interface are routable to each other.
l The DHCP relay interface and the DHCP client reside on the same network segment.
The IP address of the DHCP relay interface is on the same network segment as the IP
address of the client that is assigned by the DHCP server.
l The default gateway address of the DHCP client must be the IP address of the DHCP
relay interface.
Context
During certain phases in DHCP configuration, the DHCP client sends broadcast packets;
therefore, the DHCP relay interface must support the broadcast mode.
A DHCP relay interface supports a maximum of 20 DHCP server addresses.
Perform the following steps to configure one DHCP relay interface.

NOTE
A DHCP message sent from a client to a server can be relayed for a maximum of four times. If more
than four times, the packet will be discarded. If more than one DHCP relay agent exists on the network,
the DHCP relay function must be enabled on each DHCP relay agent, and the client, relay agents, and
DHCP server are routable to each other. The last DHCP relay agent specifies the IP address of the
DHCP server as the source IP address. The other DHCP relay agents specify the IP address of the next
DHCP relay as the source IP address.
Procedure
system-view
Step 2 Enable DHCP.

dhcp enable
By default, the DHCP service is enabled.

Step 3 Access the DHCP relay interface view.
interface interface-type interface-number [ .sub-interface-number ]
NOTE
The interface can be a GE interface or its subinterface, a Vlanif interface, or an Eth-trunk interface.
Step 4 Specify the DHCP server IP address for the DHCP relay interface.
ip relay address ip-address
NOTE
When more than one DHCP relay agents exist on a network, the last DHCP relay agent specifies the IP
address of the DHCP server. The other DHCP relay agents specify the IP address of the next DHCP
relay agent.
Step 5 Apply the DHCP relay interface configurations to the current interface.
dhcp select relay
----End
Follow-up Procedure
1. Configure a DHCP client (using a Windows XP-based PC as an example).
Set the network connection properties.
Set Internet Protocol (TCP/IP) Properties to Obtain an IP address automatically
and Obtain DNS server address automatically.
2. On each DHCP client, run the ipconfig /all command to view the configuration of the
DHCP client. Check whether the DHCP client has obtained the key configuration,
including an IP address, a default gateway, and a DNS server.
– If all key information is displayed, no action is required.
– If some PCs fail to obtain the information, such as IP addresses, troubleshoot the
PC settings and network connections. Then, go to 2.
– If some PCs obtain IP addresses but fail to obtain other network parameters, restart
the PC NIC to disable and enable the network connection. Or, run the ipconfig /
release command and the ipconfig /renew command in sequence to apply for new
IP addresses and network parameters. Then, go to 2.
– If all PCs fail to obtain the information, such as IP addresses, go to 3.

3. On the DHCP relay agent, run the display dhcp relay statistics command to view
DHCP relay statistics, including the numbers of false packets and different types of
DHCP messages.
If the number of packets sent and received between the DHCP relay, server, and client is
0, the communication is down.
– If the number is 0, verify that the dhcp select relay command has been executed on
the relay interface. Run the display dhcp relay configuration command to check
whether the specified DHCP server address is correct. If the number remains 0, go
to 4, 5, and 6.
– If the number is not 0 but DHCP messages received from servers is 0, go to 5 and
6.
– If the number is not 0 but DHCP messages received from clients is 0, go to 4 and
6.
4. On the DHCP client, run the ping command to check whether the DHCP client and relay
agent are routable to each other. If they are not routable, troubleshoot the network
connection problem.
5. On the DHCP relay, run the ping command to check whether the DHCP relay interface
and the DHCP server are routable to each other. If they are not routable, troubleshoot the
network connection and routing problems.
6. Check whether the security policy rules are correct. Add the interfaces to security zones
and enable security policy between the security zone where the DHCP relay interface
resides and the Local zone, to allow packets through.
4.7.5.3 Configuring the Device as a DHCP Client

A device can function as a DHCP client and dynamically obtain network parameters including
the IP address from a DHCP server. This mechanism lowers manual costs, reduces errors, and
facilitates unified management.
4.7.5.3.1 Configuring an Expected Lease for a DHCP Client
Context
When a DHCP server dynamically allocates an IP address with a lease to a client, the DHCP
server compares the configured lease with the expected lease of the client and selects the
smaller value as the lease of the IP address. A device functioning as the DHCP client supports
the configuration of an expected lease.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
dhcp client expected-lease time

An expected lease is configured for the DHCP client.
By default, no expected lease is configured for a DHCP client.
Step 4 Run:
dhcp client renew
The lease of the IP address obtained by a DHCP client is renewed.
The dhcp client renew command can be normally run only after the DHCP client function is
enabled on the interface and an IP address is obtained.
----End
4.7.5.3.2 Enabling the DHCP Client Function
Context
After an interface is enabled with the DHCP client function, the device can obtain network
parameters including the IP address from the DHCP server.
If the allocated IP address and IP addresses of other interfaces are on the same network
segment, the interface does not use this IP address and does not re-apply for an IP address. To
allow the interface to re-apply for an IP address, run the shutdown and then the undo
shutdown command on the interface. Alternatively, you can run the undo ip address dhcp-
alloc and then the ip address dhcp-alloc command on the interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The DHCP client function is enabled.
By default, the DHCP client function is disabled.
----End
4.7.5.4 Configuring a BOOTP Client

A device can function as a BOOTP client and dynamically obtain network parameters
including the IP address from a DHCP server.
Prerequisites
Before configuring a BOOTP client, complete the following tasks:

l Configuring a DHCP server

l (Optional) Configuring a DHCP relay agent
l Configuring the routing protocol between the device and DHCP server to ensure that the
route between them is reachable
NOTE
Only interfaces on the wired side of a device can function as BOOTP clients.
Context
After an interface is enabled with the BOOTP client function, the device can obtain network
parameters including the IP address from the DHCP server.
If the allocated IP address and IP addresses of other interfaces are on the same network
segment, the interface does not use this IP address and does not re-apply for an IP address. To
allow the interface to re-apply for an IP address, you can run the shutdown and then the undo
shutdown command on the interface. Alternatively, you can run the undo ip address bootp-
alloc and then the ip address bootp-alloc command on the interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ip address bootp-alloc
The BOOTP client function is enabled.

By default, the BOOTP client function is disabled.
----End
4.7.5.5 Maintaining DHCP

This section describes how to clear DHCP statistics and monitor DHCP operation.
4.7.5.5.1 Viewing DHCP Configuration Informatin and Statistics About DHCP

Messages
Context
You can view DHCP configuration information and statistics about received and sent DHCP
messages to locate faults during routine maintenance.
Procedure
l Run the display dhcp server database command to display information about the
DHCP database.

l Run the display dhcp relay configuration command to display the configurations of the
DHCP relay agent.
l Run the display dhcp client command to displays DHCP/BOOTP client information.
l Run the display dhcp server statistics command to view statistics about DHCP
messages sent and received on a DHCP server.
l Run the display dhcp relay statistics command to view statistics about DHCP messages
sent and received on a DHCP relay agent.
l Run the display dhcp client statistics [ interface interface-type interface-number ]
command to view statistics about DHCP messages sent and received on a DHCP client.
----End
4.7.5.5.2 Clearing Statistics About DHCP Messages
Context
Before collecting statistics about DHCP messages for a period of time, clear statistics about
DHCP messages.
NOTICE
DHCP statistics cannot be restored after they are cleared. Exercise caution when performing
this operation.
Procedure
l In the user view, run the reset dhcp server statistics command to clear statistics about
DHCP messages sent and received on a DHCP server.
l In the system view, run the reset dhcp relay statistics command to clear statistics about
DHCP messages sent and received on a DHCP relay agent.
l In the user view, run the reset dhcp client statistics [ interface interface-type interface-
number ] command to clear statistics about DHCP messages sent and received on a
DHCP client.
----End
4.7.5.5.3 Resetting a DHCP Address Pool
Context
You can reset an address pool when the DHCP server needs to re-allocate IP addresses to
clients or set IP addresses in the address pool to idle. Idle IP addresses will be preferentially
allocated.
Procedure
l Run the following commands to reset address pools on the device.
– Interface address pool:
reset ip pool interface pool-name { start-ip-address [ end-ip-address ] | all |
conflict | expired | used }

– Global address pool:

reset ip pool name ip-pool-name { start-ip-address [ end-ip-address ] | all |
conflict | expired | used }
Parameters in the commands are described in the following table.
start-ip-address [ end-ip-address ] Resets a range of IP addresses in an

address pool.
all Resets all IP addresses in an address pool.
conflict Resets conflicting IP addresses in an

address pool.
expired Resets expired IP addresses in an address

pool.
used Resets used IP addresses in an address

pool.
l Configure a device that functions as the DHCP relay agent to request the DHCP server to
release IP addresses of clients.
After the DHCP relay agent is configured to request the DHCP server to release IP
addresses of clients, the DHCP relay agent sends DHCP Release messages to the
specified DHCP server. After receiving the message, the DHCP server restores specified
IP addresses to the idle status. In this way, released IP addresses can be allocated to other
clients. Run the following commands to configure the DHCP relay agent to request the
DHCP server to release IP addresses of clients:
a. Run the system-view command to enter the system view.

b. (Optional) Run the interface interface-type interface-number command to enter the
interface view.
c. Run the dhcp relay release client-ip-address mac-address [ server-ip-address ]
command to request the DHCP server to release IP addresses allocated to DHCP
clients.
NOTE
This command can only take effect on the DHCP relay which is connected to the DHCP server
directly.
n When you run the preceding command in the system view:
○ If no DHCP server is specified, the DHCP relay agent sends DHCP
Release messages to all DHCP servers connected to DHCP relay
interfaces.
○ If a DHCP server is specified, the DHCP relay agent sends DHCP
Release messages to only the specified DHCP server.
n When you run the preceding command in the interface view:
○ If no DHCP server is specified, the DHCP relay agent sends DHCP
Release messages to all the DHCP relay connected to this interface.

○ If a DHCP server is specified, the DHCP relay agent sends DHCP

Release messages to only the specified DHCP server.
----End
4.7.5.5.4 Locking a DHCP Address Pool
Context
When a DHCP server is migrated, address pools on the DHCP server need to be transferred to
a DHCP server on the live network. To prevent impacting clients that have obtained IP
address from the to-be-migrated DHCP server, you can lock the address pools on the DHCP
server. When new users get online, they will apply for IP addresses from the new address
pool.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the ip pool ip-pool-name command to enter the global address pool view.
Step 3 Run the lock command to lock the address pool.

By default, address pools on a device are not locked.
----End

4.7.6.1 CLI Example for Configuring a Device as the DHCP Server (Based on the
Interface Address Pool)
As shown in Figure 4-54, an enterprise plans two network segments for office terminals:
10.1.1.0/24 for fixed terminals and 10.1.2.0/24 for terminals used by staff on business trips.
To facilitate unified management, the enterprise requires that terminals automatically obtain
IP addresses and the IP address of the DNS server (if users need to access the DNS server
using the domain name) from the Switch. A PC (DHCP Client_1) requires fixed IP address
10.1.1.100/24 to meet service requirements.

Figure 4-54 Networking diagram for configuring a device as the DHCP server
DNS Server
10.1.3.1/24
IP Network
GE1/0/1 GE1/0/2
VLANIF10 VLANIF11
10.1.1.1/24 10.1.2.1/24
FW
DHCP Server
DHCP Client_1 ... DHCP DHCP ... DHCP

MAC：286e-d488-b684 Client_n Client_s Client_t
IP：10.1.1.100/24
Configure the Switch as the DHCP server to dynamically allocate IP addresses on the two
network segments and the IP address of the DNS server to enterprise terminals. IP addresses
on 10.1.1.0/24 are allocated to fixed terminals and have a lease of 30 days. The fixed IP
address 10.1.1.100/24 is statically allocated to DHCP Client_1. IP addresses on 10.1.2.0/24
are allocated to terminals used by staff on business trips and have a lease of two days.
Procedure
Step 1 Enable the DHCP service.
<FW> system-view
[FW] dhcp enable
Step 2 Configure the IP addresses of the interfaces and assign the interfaces to security zones.

Step 3 Configure interface address pools.

# Configure the DHCP clients under GigabitEthernet 1/0/1 to obtain the network parameters,
such as IP addresses from the interface address pool.
[FW-GigabitEthernet1/0/1] dhcp server lease day 30
[FW-GigabitEthernet1/0/1] dhcp server domain-name huawei.com
[FW-GigabitEthernet1/0/1] dhcp server excluded-ip-address 10.1.1.2
[FW-GigabitEthernet1/0/1] dhcp server static-bind ip-address 10.1.1.100 mac-
address 286e-d488-b684
# Configure the DHCP clients under GigabitEthernet 1/0/2 to obtain the network parameters,
such as IP addresses from the interface interface address pool.
[FW-GigabitEthernet1/0/2] dhcp server lease day 2
[FW-GigabitEthernet1/0/2] dhcp server domain-name huawei.com

[FW-policy-security] rule name sec_policy
[FW-policy-security-rule-sec_policy] source-zone trust
[FW-policy-security-rule-sec_policy] source-zone local
[FW-policy-security-rule-sec_policy] destination-zone local
[FW-policy-security-rule-sec_policy] destination-zone trust
[FW-policy-security-rule-sec_policy] action permit

# On the Switch, run the display ip pool command to view IP address allocation in address
pools. The Used field displays the number of used IP addresses in an address pool.
[FW] display ip pool interface GigabitEthernet 1/0/1
Pool-name : GigabitEthernet1/0/1
Pool-No : 0
Lease : 30 Days 0 Hours 0 Minutes
Domain-name : www.huawei.com
DNS-server0 : 10.1.1.2
NBNS-server0 : -
Netbios-type : -
Position : Interface Status : Unlocked
Gateway-0 : -
Network : 10.1.1.0
Mask : 255.255.255.0
Logging : Disabled
Address Statistic: Total :252 Used :0
Idle :252 Expired :0
Conflict :0 Disable :0
-----------------------------------------------------------------------------
Network section
Start End Total Used Idle(Expired) Conflict Disabled
-----------------------------------------------------------------------------
10.1.1.1 10.1.1.254 254 0 254(0) 0 0
-----------------------------------------------------------------------------
[FW] display ip pool interface GigabitEthernet 1/0/2
Pool-name : GigabitEthernet1/0/2
Pool-No : 3
Lease : 2 Days 0 Hours 0 Minutes
Domain-name : huawei.com
DNS-server0 : 10.1.1.2

NBNS-server0 : -
Netbios-type : -
Position : Interface Status : Unlocked
Gateway-0 : -
Network : 10.1.2.0
Mask : 255.255.255.0
Logging : Disabled
Address Statistic: Total :252 Used :0
Idle :252 Expired :0
Conflict :0 Disable :0
-----------------------------------------------------------------------------
Network section
Start End Total Used Idle(Expired) Conflict Disabled
-----------------------------------------------------------------------------
10.1.2.1 10.1.2.254 254 0 254(0) 0 0
-----------------------------------------------------------------------------
----End
Configuration Files
Configuration file of the FW
#
dhcp enable
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
dhcp server excluded-ip-address 10.1.1.2
dhcp server static-bind ip-address 10.1.1.100 mac-address 286e-d488-b684
dhcp server lease day 30 hour 0 minute 0
dhcp server domain-name huawei.com
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
dhcp server lease day 2 hour 0 minute 0
dhcp server domain-name huawei.com
#
firewall zone trust
set priority 85
#
security-
policy
rule name sec_policy

source-zone local
source-zone trust
action permit
#
return

4.7.6.2 CLI Example for Configuring the Device as a DHCP Server (Using the
Global Address Pool-based Layer-3 Ethernet Interface)
After learning this configuration example, you can understand how to use the Layer-3
Ethernet Interfaces to configure the device as a DHCP server based on global address pools,
and enable the DHCP server to provide services for clients, including dynamic address
allocation, static address allocation, egress gateway address, DNS server address, and WINS
server address.
As shown in Figure 4-55, an enterprise has two offices, which are connected to the FW using
the Layer 2 switches. To save resources, the FW also works as the DHCP server for the hosts
in the two offices to assign IP addresses, gateways, DNS servers, and WINS servers.
The network topology is as follows:
l Fixed IP addresses have been assigned to the four hosts (DNS server, WINS server, and
two hosts in the offices). The IP addresses are respectively are 10.1.1.2/25, 10.1.1.4/25,
10.1.1.126/25, and 10.1.1.254/25.
l The two hosts require higher access permissions, and apply for new fixed IP addresses
10.1.1.5/25 and 10.1.1.253/25.
l Office 1 resides on network segment 10.1.1.0/25. Its address lease is 10 days and 12
hours, domain name suffix is example.com, DNS server address is 10.1.1.2/25, WINS
server address is 10.1.1.4/25, and egress gateway address is 10.1.1.1/25.
l Office 2 resides on network segment 10.1.1.128/25. Its address lease is 5 days, domain
name suffix is example.com, DNS server address is 10.1.1.2/25, no WINS server is
configured, and egress gateway address is 10.1.1.129/25.
Figure 4-55 Networking diagram for configuring a global address pool-based DHCP server
using the Layer-3 Ethernet Interfaces
WINS DHCP DHCP DHCP

Server Client Client Client
GE1/0/1 GE1/0/2
Layer-2 Trust Trust Layer-2
LAN switch LAN switch
FW
DNS DHCP
Host1 Host2
Server Client
Network: 10.1.1.0/25 Network: 10.1.1.128/25

FW Interface number: Interface GigabitEthernet

GigabitEthernet 1/0/1 1/0/1 connected to network
IP address: 10.1.1.1/25 segment 10.1.1.0/25 where
office 1 resides
Interface number: Interface GigabitEthernet

GigabitEthernet 1/0/2 1/0/2connected to network
IP address: 10.1.1.129/25 segment 10.1.1.128/25
where office 2 resides
WINS server IP address: 10.1.1.4/25 WINS server allocated to

DHCP clients on network
segment 10.1.1.0/25
DNS server IP address: 10.1.1.2/25 DNS server allocated to

segments 10.1.1.0/25 and
10.1.1.128/25
Domain name suffix example.com Domain name suffix

assigned to DHCP clients on
network segments
10.1.1.0/25 and
10.1.1.128/25
Address lease 10 days 12 hours Address lease assigned to

segment 10.1.1.0/25
5 days Address lease assigned to

segment 10.1.1.128/25
Egress gateway IP address: 10.1.1.1/25 Egress gateway allocated to

segment 10.1.1.0/25
IP address: 10.1.1.129/25 Egress gateway allocated to

segment 10.1.1.128/25
Host1 IP address: 10.1.1.5/25 Host requiring a fixed IP

MAC address: address
0021-97cf-2238
Host2 IP address: 10.1.1.253/25 Host requiring a fixed IP

MAC address: address
00e0-4c86-58eb

The configuration roadmap of DHCP server is as follows:
1. Enable DHCP service.
2. Reserve the IP addresses that have been specified (such as DNS server address, WINS
server address, and two host addresses) to avoid reassigning them.
3. Dynamically allocate IP addresses and other network parameters.
On the network, the FW connects to clients using a Layer 2 switch and multiple
interfaces; therefore, you are advised to assign IP addresses based on global address
pools. To simplify the configuration, you can employ three address pools. Address pool 0
(network segment 10.1.1.0/24) specifies the common attributes of all clients (such as
their domain name suffix and DNS server). Address pool 1 (network segment
10.1.1.0/25) and address pool 2 (network segment 10.1.1.128/25) specify the unique
attributes of each network segment (such as their address ranges, address lease, gateway
addresses, and WINS servers).
NOTE
You can also employ two address pools, pool 1 and pool 2. The two address pools cannot inherit
the configurations of their parent node; therefore, their unique attributes must be configured
separately.
4. To meet the requirement of the hosts for using fixed IP addresses, allocate IP addresses
statically and configure other network parameters.
Create two global address pools 3 and 4, each of which has one IP address (10.1.1.5/25
and 10.1.1.253/25 respectively) for static address allocation. Address pool 3 inherits the
common attributes of address pool 0 and address pool 1. Address pool 4 inherits
common attributes of address 0 and address 2. No other network parameter needs to be
configured for address pools 3 and 4.
5. Set Internet Protocol (TCP/IP) Properties to Obtain an IP address automatically
and Obtain DNS server address automatically on each DHCP client, enabling the
DHCP clients to automatically obtain IP addresses and other network parameters
allocated by the DHCP server.
NOTE
It is recommended to centrally plan and configure important network parameters, such as domain name
suffix, DNS server, and egress gateway, for the DHCP clients on the DHCP server, to avoid network access
errors caused by incorrect configurations of the DHCP client network parameters.
Procedure
Step 1 Enable DHCP service.
<FW> system-view
[FW] dhcp enable
Step 2 Configure the global address pool attributes of the DHCP server.
# Configure the attributes of address pool 1 (the IP address range of the address pool, the
egress gateway, and the address lease).
[FW] ip pool 1
[FW-ip-pool-1] network 10.1.1.0 mask 255.255.255.128
[FW-ip-pool-1] domain-name example.com
[FW-ip-pool-1] dns-list 10.1.1.2
[FW-ip-pool-1] excluded-ip-address 10.1.1.4

[FW-ip-pool-1] gateway-list 10.1.1.1

[FW-ip-pool-1] lease day 10 hour 12
[FW-ip-pool-1] quit
# Configure the attributes of address pool 2 (the IP address range of the address pool, the
egress gateway, the WINS server address, and the address lease).
[FW] ip pool 2
[FW-ip-pool-2] nbns-list 10.1.1.4
[FW-ip-pool-2] lease day 5
[FW-ip-pool-2] quit
# Configure the attributes of address pool 3, and perform IP-MAC address binding in the
address pool.
[FW] ip pool 3
[FW-ip-pool-3] static-bind ip-address 10.1.1.5 mac-address 0021-97cf-2238
[FW-ip-pool-3] reserved ip-address mac
[FW-ip-pool-3] quit
# Configure the attributes of address pool 4, and perform IP-MAC address binding in the
address pool.
[FW] ip pool 4
[FW-ip-pool-4] static-bind ip-address 10.1.1.253 mac-address 00e0-4c86-58eb
[FW-ip-pool-4] reserved ip-address mac
[FW-ip-pool-4] quit
Step 3 Specify the interface IP address, and configure the clients under the interface to obtain IP
addresses from global address pools.
# Configure the clients under interface GigabitEthernet 1/0/1 to obtain IP addresses from
global address pools.
[FW-GigabitEthernet1/0/1] dhcp select global
# Configure the clients under interface GigabitEthernet 1/0/2 to obtain IP addresses from
global address pools.
[FW-GigabitEthernet1/0/2] dhcp select global
Step 4 Add interfaces to corresponding security zones and configure the security policy.


Step 5 Configure DHCP clients (using a Windows XP-based PC as an example).

1. Right-click Network Neighborhood on the desktop, and choose Attributes > Network
Connections.
2. Right-click Local Area Connection of the connected network adapter, and choose
Properties.
3. Select Internet Protocol (TCP/IP) and click Properties. The Internet Protocol
(TCP/IP) Properties window is displayed. Select Obtain an IP address automatically
----End
1. On any PC on the two network segments where office 1 and office 2 reside, run the cmd
command to enter the DOS environment. Run the ipconfig /all command to verify
whether the client has obtained the network parameters, such as an IP address, default
gateway address, WINS server address, and DNS server address. If the configurations
are correct, host 1 and host 2 are specified with fixed IP addresses.
NOTE
If the information obtained by the DHCP client is incomplete (for example, only the IP address is
obtained but other network parameters are not), run the ipconfig /release command to lease the
dynamic IP address, and then run the ipconfig /renew command to apply for a new IP address and
other network parameters.
C:\Documents and Settings\Administrator> ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : example

Primary Dns Suffix . . . . . . . : example.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : example.com
Ethernet adapter Local Area Connection :
Connection-specific DNS Suffix . : example.com

Description . . . . . . . . . . . : Realtek RTL8139/810x Family Fast
Eth
ernet NIC
Physical Address. . . . . . . . . : 00-1B-B9-7A-7D-61
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 10.1.1.3
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 10.1.1.1
DHCP Server . . . . . . . . . . . : 10.1.1.1
DNS Servers . . . . . . . . . . . : 10.1.1.2
Primary WINS Server . . . . . . . : 10.1.1.4
Lease Obtained. . . . . . . . . . : 2015-5-15 15:56:34
Lease Expires . . . . . . . . . . : 2015-5-26 03:56:34

2. On the DHCP server FW, run the display dhcp server statistics command to view the
statistics information.
[FW] display dhcp server statistics
Global Pool:
Pool Number: 5
Binding
Auto: 2
Manual: 2
Expire: 0
Interface Pool:
Pool Number: 0
Binding
Auto: 0
Manual: 0
Expire: 0
Boot Request: 46
Dhcp Discover: 16
Dhcp Request: 22
Dhcp Decline: 0
Dhcp Release: 0
Dhcp Inform: 8
Boot Reply: 32
Dhcp Offer: 8
Dhcp Ack: 22
Dhcp Nak: 2
Bad Messages: 0
HA Message:
BatchBackup send msg: 0
BatchBackup recv msg: 0
BatchBackup send lease: 0
BatchBackup recv lease: 0
#
dhcp enable
#
ip pool 1
network 10.1.1.0 mask 255.255.255.128
dns-list 10.1.1.2
domain-name example.com
gateway-list 10.1.1.1
lease day 10 hour 12
#
ip pool 2
network 10.1.1.128 mask 255.255.255.128
dns-list 10.1.1.2
nbns-list 10.1.1.4
lease day 5
#
ip pool 3
dns-list 10.1.1.2
lease day 10 hour 12
static-bind ip-address 10.1.1.5 mac-address 0000-e03f-0305
#
ip pool 4
dns-list 10.1.1.2
nbns-list 10.1.1.4
lease day 5

static-bind ip-address 10.1.1.253 mac-address 00e0-4c86-58eb

#
ip address 10.1.1.1 255.255.255.128
#
ip address 10.1.1.129 255.255.255.128
#
firewall zone local
set priority 100
#
firewall zone trust
set priority 85
#
security-policy
source-zone local
source-zone trust
action permit
#
return
4.7.6.3 CLI Example for Configuring a Global Address Pool-based DHCP Server
(Using Sub-interfaces)
After learning this configuration example, you can understand how to use theFW sub-
interfaces to configure a DHCP server based on global address pools, and enable the DHCP
server to provide services for DHCP clients on VLANs, including dynamic address allocation,
egress gateway address, DNS server address, and WINS server address.
An enterprise attempts to divide different VLANs for different departments using a Layer 2
switch. To save resources, the FW works as the DHCP server to specify network parameters
to all hosts on VLANs, including allocating IP addresses, configuring domain names, DNS
server addresses, WINS server addresses, and egress gateway addresses.
As shown in Figure 4-56, the FW connects to the Layer 2 switch using interface
GigabitEthernet 1/0/1, and divides interface GigabitEthernet 1/0/1 to two subinterfaces that
connect to VLAN 10 and VLAN 20 respectively.
NOTE
To focus on how to assign IP addresses to DHCP clients on VLANs using sub-interfaces, this section
highlights a part of the network.
The network topology is as follows:
l Two servers are specified with fixed IP addresses: 10.1.2.2/24 and 10.1.1.4/24.
l For hosts on VLAN 10, their address lease is 10 days and 12 hours, domain name is
example.com, DNS server address is 10.1.2.2/24, WINS server address is 10.1.1.4//24,
and egress gateway address is 10.1.1.1/24.
l For hosts on VLAN 20, their address lease is 5 days, domain name is example.com, DNS
server address is 10.1.2.2/24, no WINS server is configured, and egress gateway address
is 10.1.2.1/24.

Figure 4-56 Networking diagram for configuring a global address pool-based DHCP server
using subinterfaces
WINS server
DHCP client
10.1.1.4/24
VLAN10
FW
GE1/0/1.1
Layer-2 Trust
LAN switch GE1/0/1.2
Trust
DHCP
VLAN20 server
10.1.2.2/24
DHCP client
DNS server
FW Interface number: Sub-interface

GigabitEthernet 1/0/1.1 GigabitEthernet 1/0/1.1 is
IP address: 10.1.1.1/24 associated with VLAN 10.
The DHCP server assigns IP
Security zone: Trust addresses and specifies
network parameters using
this sub-interface to DHCP
clients on VLAN 10.
Interface number: Sub-interface

GigabitEthernet 1/0/1.2 GigabitEthernet 1/0/1.2 is
IP address: 10.1.2.1/24 associated with VLAN 20.
The DHCP server assigns IP
Security zone: Trust addresses and specifies
network parameters using
this sub-interface to DHCP
clients on VLAN 20.
WINS server IP address: 10.1.1.4 WINS server assigned to

DHCP clients on VLAN 10.
DNS server IP address: 10.1.2.2 DNS server assigned to

Domain name suffix example.com Domain name suffix

assigned to DHCP clients on
VLAN 10 and VLAN 20.
Address lease 10 days and 12 hours Address lease assigned to


5 days Address lease assigned to

Egress gateway IP address: 10.1.1.1 Egress gateway assigned to

IP address: 10.1.2.1 Egress gateway assigned to

1. To assign IP addresses and specify network parameters for DHCP clients on VLANs
using interfaces, you need to configure the following items on DHCP servers.
a. Enable the DHCP service.
b. Dynamically allocate IP addresses and other network parameters.
You can employ two address pools, address pool 1 (network segment 10.1.1.0/24)
and address pool 2 (network segment 10.1.2.0/24) specify the unique properties of
each network segment (such as their address ranges, address lease, gateway
addresses, and WINS servers).
Both the two IP address pools specify the common properties of all clients (such as
their domain name suffix and DNS server). In addition, you need to reserve the IP
addresses that have been specified (such as DNS server address and WINS server
address) to avoid reassigning them.
c. Associate two sub-interfaces to VLAN 10 and VLAN 20. Enable global address
pools for the two sub-interfaces.
2. Set the switch interface connected to the FW as a Trunk interface. Add the switch
interfaces connected to PCs to related VLANs in default mode. (The configuration
procedure is not mentioned here. )
and Obtain DNS server address automatically on each DHCP client, enabling the
DHCP clients to automatically obtain IP addresses and other network parameters
NOTE
It is recommended to centrally plan and configure important network parameters, such as domain name
suffix, DNS server, and egress gateway, for the DHCP clients on the DHCP server, to avoid network
access errors caused by incorrect configurations of the DHCP client network parameters.
Procedure
Step 1 Enable DHCP service.
<FW> system-view
[FW] dhcp enable
Step 2 Configure the global address pool attributes of the DHCP server.
# Configure the IP address pool 1.

[FW] ip pool 1
[FW-ip-pool-1] quit
# Configure the IP address pool 2.

[FW] ip pool 2
[FW-ip-pool-2] quit
Step 3 Configure sub-interfaces, and assign IP addresses and specify network parameters to clients in
VLANs.
# Configure sub-interface GigabitEthernet 1/0/1.1, and assign IP addresses and specify

network parameters to clients on VLAN 10.
[FW-GigabitEthernet1/0/1.1] dhcp select global
# Configure subinterface GigabitEthernet 1/0/1.2, and assign IP addresses and specify

network parameters to clients on VLAN 20.
[FW-GigabitEthernet1/0/1.2] dhcp select global
Step 4 Add interfaces to corresponding security zones and configure the security policy.

Connections.
Properties.

----End
1. On any PC on a VLAN, run the cmd command to enter the DOS environment. Run the
ipconfig /all to verify whether the client has obtained the network parameters, such as an
IP address, default gateway address, WINS server address, and DNS server address.
NOTE
If the information obtained by the DHCP client is incomplete (for example, only the IP address is
obtained but other network parameters are not), run the ipconfig /release command to lease the
dynamic IP address, and then run the ipconfig /renew command to apply for a new IP address and
other network parameters.
Windows IP Configuration
Host Name . . . . . . . . . . . . : example

Primary Dns Suffix . . . . . . . : example.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : example.com

Eth
ernet NIC
Physical Address. . . . . . . . . : 00-1B-B9-7A-7D-61
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 10.1.1.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.1.1
DHCP Server . . . . . . . . . . . : 10.1.1.1
DNS Servers . . . . . . . . . . . : 10.1.2.2
Primary WINS Server . . . . . . . : 10.1.1.4
Lease Obtained. . . . . . . . . . : Monday, January 10, 15:00:34 PM
Lease Obtained. . . . . . . . . . : Friday, January 21, 03:00:34 AM
2. On the DHCP server FW, run the display dhcp server statistics command to view the
statistics information.
[FW] display dhcp server statistics
Global Pool:
Pool Number: 3
Binding
Auto: 2
Manual: 0
Expire: 0
Interface Pool:
Pool Number: 0
Binding
Auto: 0
Manual: 0
Expire: 0
Boot Request: 131
Dhcp Discover: 125
Dhcp Request: 5
Dhcp Decline: 0
Dhcp Release: 1

Dhcp Inform: 0
Boot Reply: 38
Dhcp Offer: 33
Dhcp Ack: 5
Dhcp Nak: 0
Bad Messages: 0
HA Message:
BatchBackup send msg: 0
BatchBackup recv msg: 0
BatchBackup send lease: 0
BatchBackup recv lease: 0
Configuration scripts of FW:
#
dhcp enable
#
ip pool 1
network 10.1.1.0 mask 255.255.255.0
excluded-ip-address 10.1.1.4
dns-list 10.1.2.2
nbns-list 10.1.1.4
lease day 10 hour 12 minute 0
#
ip pool 2
network 10.1.2.0 mask 255.255.255.0
dns-list 10.1.2.2
#
vlan-type dot1q 10
ip address 10.1.1.1 255.255.255.0
#
vlan-type dot1q 20
ip address 10.1.2.1 255.255.255.0
#
firewall zone local
set priority 100
#
firewall zone trust
set priority 85
#
security-policy
source-zone local
source-zone trust
action permit
#
return

4.7.6.4 CLI Example for Configuring the Device as a DHCP Relay
The IP address plan of a department on the network shown in Figure 4-57 is as follows:
l IP addresses are available on network segment 192.168.20.0/24. An FTP server is

deployed and assigned 192.168.20.254.
l A DHCP server is on another network segment 10.1.1.0/24.
l The domain name extension of a DHCP client is example.com, and the IP address of a
DNS server is 3.3.3.3.
l The address release is 10 days.
A DHCP relay agent needs to be deployed on the same network segment as a DHCP client to
connect the DHCP client and server across network segments. DHCP relay enables the DHCP
client to request the DHCP server for configurations, such as the IP address and DNS server
address.
Figure 4-57 DHCP relay networking
Trust DMZ
DHCP Client FW_A FW_B
(DHCP Relay) (DHCP Server)
GE1/0/1
10.1.1.2/24
GE1/0/1 GE1/0/2
192.168.20.1/24 10.1.1.1/24
FTP server
0021-97cf-2238
1. To enable the DHCP server to assign network parameters, including an IP address, to the
DHCP client across different network segments, configure an available IP address range
(includes the DHCP relay interface address) on FW_B and specify DHCP client
parameters, such as an egress gateway, a domain name suffix, and a DNS server address.
a. Enable DHCP.
b. Configure dynamic IP address allocation and other network parameters assigned to
the DHCP client.
c. Configure static IP address allocation and other network parameters assigned to the
FTP server.
d. Configure a route between the DHCP server and the relay interface.
2. Enable the DHCP relay function on FW_A to enable communication between the DHCP
client and server across different network segments:
a. Enable DHCP.
b. Specify a DHCP server IP address on the relay interface.


and Obtain DNS server address automatically on the DHCP client, which enables the
DHCP client to automatically obtain the IP address and other network parameters
Procedure
Step 1 Configure the IP addresses for the interface of FW_B and assign the interface to the specified
security zone.
<FW> system-view
[FW] sysname FW_B
[FW_B-GigabitEthernet1/0/1] ip address 10.1.1.2 255.255.255.0
[FW_B] firewall zone dmz
Step 2 Configure FW_B as a DHCP Server.

[FW_B] dhcp enable
2. Configure the global address pool.

[FW_B] ip pool 1
[FW_B-ip-pool-1] network 192.168.20.0 mask 24
[FW_B-ip-pool-1] section 1 192.168.20.1 192.168.20.254
[FW_B-ip-pool-1] domain-name example.com
[FW_B-ip-pool-1] dns-list 3.3.3.3
[FW_B-ip-pool-1] gateway-list 192.168.20.1
[FW_B-ip-pool-1] lease day 10
[FW_B-ip-pool-1] static-bind ip-address 192.168.20.254 mac-address
0021-97cf-2238
[FW_B-ip-pool-1] quit
3. Configure the clients under the interface GigabitEthernet 1/0/1 to obtain IP addresses
from global address pools.
[FW_B-GigabitEthernet1/0/1] dhcp select global
4. Add a static route between the DHCP server and the DHCP relay interface, enabling the
two are routable to each other.
NOTE
The IP address of the DHCP relay interface and the IP address of the DHCP server reside on
different network segments, you need to configure a static route or employ a dynamic route
protocol on the DHCP server to route the DHCP relay interface and the DHCP server.
[FW_B] ip route-static 192.168.20.1 255.255.255.0 10.1.1.1
Step 3 Configure the IP addresseses for the interfaces of FW_A and assign the interfaces to the
specified security zones.
<FW> system-view
[FW] sysname FW_A
[FW_A-GigabitEthernet1/0/1] ip address 192.168.20.1 255.255.255.0

[FW_A-zone-dmz] add interface GigabitEthernet1/0/2

Step 4 Configure FW_A as a DHCP Relay.

<FW_A> system-view
[FW_A] dhcp enable
2. Specify a DHCP server address and enable the relay interface configurations.
[FW_A-GigabitEthernet1/0/1] ip relay address 10.1.1.2
[FW_A-GigabitEthernet1/0/1] dhcp select relay
Step 5 Add interfaces to corresponding security zones and configure interzone packet filtering to
ensure normal network communication. Details are omitted.
NOTE
To realize mutual access between the DHCP relay and the DHCP server, you need to configure the
packet filtering on the FW for the interzone between the Local zone and the zone where the DHCP client
resides to allow packets through. To realize mutual access between the DHCP client and the DHCP
relay, as well as between the DHCP relay and the DHCP server, you need to configure the packet
filtering on FW_A and FW_B for the interzone between the Local zone and the zone where the interface
resides to allow packets through.

Connections.
Properties.
----End
1. On any PC in the department, press Start > Run and enter cmd to display the DOS
screen. Run the ipconfig /all command to view the network parameters obtained by the
client, such as an IP address, a default gateway address, a WINS server address, and a
DNS server address. Also, verify that the FTP server has obtained a fixed IP address
192.168.20.254.
NOTE
If the DHCP client obtains incomplete information (for example, only the IP address is obtained),
run the ipconfig /release command to lease the dynamic IP address, and run the ipconfig /renew
command to apply for a new IP address and other network parameters.

Ethernet NIC
Physical Address. . . . . . . . . : 00-50-ba-50-73-25
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.20.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.20.1

DHCP Server . . . . . . . . . . . : 10.1.1.2

DNS Servers . . . . . . . . . . . : 3.3.3.3
Primary WINS Server . . . . . . . :
Lease Obtained. . . . . . . . . . : Tuesday, December 13, 2011,
17:52:10 PM
Lease Expires . . . . . . . . . . : Friday, December 23, 2011,
17:52:10 PM
2. Check the address lease duration list of the DHCP server to determine whether the
DHCP server assigns IP addresses to the PC and FTP server on the LAN.
a. Choose Network > DHCP Server > Monitor.
b. Verify the client IP address assigned by the DHCP server.
Configuration scripts of FW_A
#
sysname FW_A
#
ip address 192.168.20.1 255.255.255.0
ip relay address 10.1.1.2
dhcp select relay
#
ip address 10.1.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#
firewall zone dmz
set priority 50
#
security-policy
source zone local
source zone dmz
destination zone local
destination zone dmz
action permit
#
security-policy
source zone local
source zone trust
destination zone trust
action permit
#
return
Configuration scripts of FW_B

#
sysname FW_B
#
dhcp enable
#
ip pool 1
network 192.168.20.0 mask 24
section 1 192.168.20.1 192.168.20.254
static-bind ip-address 192.168.20.254 mac-address 0021-97cf-2238

dns-list 3.3.3.3
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
dhcp select global
#
firewall zone dmz
set priority 50
#
ip route-static 192.168.20.0 255.255.255.0 10.1.1.1
#
security-policy
source zone local
source zone dmz
destination zone dmz
action permit
#
return
4.7.6.5 CLI Example for Configuring the Device as an DHCP Client
Applicable Products
USG6000V
Figure 4-58 shows that a FW functions as an egress gateway and connect PCs in an intranet
to the Internet. The network plan is as follows:
l An administrator manually specifies an IPv4 address for each PC on the network

segment 10.3.0.0/24.
l An interface with a static IPv4 address connects the FW to the intranet.
l Another interface on the FW that functions as a DHCP client applies for a client IPv4
address and a DNS server IP address from a DHCP server and connects the intranet to
the Internet.
Figure 4-58 Networking diagram for accessing the Internet using DHCP
Trust Untrust
PC FW
Intranet
GE1/0/3 GE1/0/1
10.3.0.1/24 DHCP Client
DHCP Server
PC

1. Enable the DHCP client function on GigabitEthernet 1/0/1 of the FW to obtain a client
IPv4 address and a DNS server address from a DHCP server.
2. Specify a static IPv4 address on GigabitEthernet 1/0/3 that connects the FW to the
intranet.
3. Configure a security policy and a NAT policy (easy-IP) on the FW.
4. Set the IP addresses of the PCs' gateway and a DNS server to 10.3.0.1. This example
provides the configuration procedure on the FW. The configuration procedure for the
PCs is not provided.
NOTE
After the FW obtains an IPv4 address from a DHCP server, the DHCP server issues a default route to the
FW that function as a DHCP client. The next hop of the default route is a carrier's device. Therefore,
there is no need to configure a default route.
Procedure
Step 1 Configure the IP address of the interface and assign the interfaces to the security zones.
<FW> system-view
Step 2 Configure the DNS proxy function.

[FW] dns resolve
[FW] dns server unnumbered interface GigabitEthernet1/0/1
Step 3 Configure GigabitEthernet 1/0/3 as a DHCP client.

Step 4 Configure a security policy to allow the PCs to access the Internet.
[FW-policy-security] rule name policy_sec_1
[FW-policy-security-rule-policy_sec_1] source-zone trust
[FW-policy-security-rule-policy_sec_1] source-address 10.3.0.0/24
[FW-policy-security-rule-policy_sec_1] egress-interface GigabitEthernet1/0/1
[FW-policy-security-rule-policy_sec_1] action permit
[FW-policy-security-rule-policy_sec_1] quit
Step 5 Configure a NAT policy to translate private network IP addresses into public network IP
addresses before PCs access the Internet.
[FW] nat-policy
[FW-policy-nat-rule-policy_nat_1] destination-zone untrust
[FW-policy-nat-rule-policy_nat_1] source-address 10.3.0.0 24
----End

1. Check the status of GigabitEthernet 1/0/1 (uplink).
b. Verify that the physical status and IPv4 status of GigabitEthernet 1/0/1 are Up, the
connection type is DHCP, and the interface obtained an IPv4 address.
2. Check whether the PC on the intranet can use domain names to access the Internet. If the
PC can access the Internet, the configuration is successful. If the PC fails to access the
#
dns resolve
dns server unnumbered interface GigabitEthernet1/0/1
#
dns proxy enable
#
undo shutdown
#
ip address 10.3.0.1 255.255.255.0
#
firewall zone trust
set priority 85
#
set priority 5
#
#
security-policy
source-zone trust
action permit
#
nat-policy
source-zone trust
action nat easy-ip
#
return
This section describes DHCP specifications.

Configuring the device to The device can serve as a Supported by all models.
serve as a DHCP server DHCP server and allocate
IP addresses to DHCP
clients.
Global address pool The device can serve as the Supported by all models.
DHCP server and allocate
IP addresses in a global
address pool to DHCP
clients.
Configuring gateway, DNS - Supported by all models.

server, and NetBIOS server
addresses in a global address
pool
Interface address pool The device can serve as the Supported by all models.
DHCP server and allocate
IP addresses in an interface
address pool to DHCP
clients.
Static and dynamic address Static address allocation Supported by all models.
allocation refers to allocating fixed IP
addresses to some clients.
DHCP Option DHCP options 1, 3, 6, 12, Supported by all models.

15, 33, 43, 44, 46, 50, 51, 53
to 55, 58 to 61, 121, 141 to
150, and 184 are supported.
Configuring the device to The DHCP client can Supported by all models.
serve as a DHCP relay communicate with a DHCP
server on a different
network segment through
the DHCP relay and obtain
an IP address from the
server.
Configuring the device to The device can serve as a Supported by all models.
serve as a DHCP client DHCP client and obtain
parameters, such as an IP
address from the DHCP
server.

Function Sub-Function Specifications
DHCP Server Maximum number of global l USG6000V1: 128

address pools l USG6000V2: 256
l USG6000V4: 256
l USG6000V8: 256
Maximum number of l USG6000V: 1024

interface address pools
Number of addresses l USG6000V: not

supported by a global restricted
address pool
Number of addresses l USG6000V1: 3072

supported by an interface l USG6000V2: 12288
address pool
l USG6000V4: 24576
l USG6000V8: 24576
Maximum number of l USG6000V1: 3072

addresses that can allocated l USG6000V2: 12288
to a device
l USG6000V4: 24576
l USG6000V8: 24576
DHCP Client Maximum number of DHCP 16

clients

This section describes the versions and changes in the DHCP feature.

DHCP standards and protocols are as follows:
l RFC 1534: Interoperation Between DHCP and BOOTP

l RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
l RFC 2131: Dynamic Host Configuration Protocol
l RFC 2132: DHCP Options and BOOTP Vendor Extensions

l RFC 2241: DHCP Options for Novell Directory Services

l RFC 2485: DHCP Option for The Open Group's User Authentication Protocol
l RFC 2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
l RFC 2610: DHCP Options for Service Location Protocol
l RFC 2937: The Name Service Search Option for DHCP
l RFC 2939: Procedures and IANA Guidelines for Definition of New DHCP Options and
Message Types
l RFC 3004: The User Class Option for DHCP
l RFC 3011: The IPv4 Subnet Selection Option for DHCP
l RFC 3046: DHCP Relay Agent Information Option
l RFC 3361: Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session
Initiation Protocol (SIP) Servers
l RFC 3397: Dynamic Host Configuration Protocol (DHCP) Domain Search Option
l RFC 3442: The Classless Static Route Option for Dynamic Host Configuration Protocol
(DHCP) version 4
l RFC 3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client
Configuration
4.8 DHCP Snooping

This section describes concepts and the configuration procedure of Dynamic Host
Configuration Protocol (DHCP) snooping, as well as provides configuration examples.
4.8.1 Overview
DHCP snooping defends against the attacks launched using DHCP messages.
Definition
The Dynamic Host Configuration Protocol (DHCP) snooping, a DHCP security feature, filters
untrusted DHCP messages by creating and maintaining a binding table. This binding table
contains the following items:
l MAC addresses
l IP addresses
l IP leases
l Binding types
l VLAN IDs
l Interface information
DHCP snooping acts as a firewall between a DHCP client and a DHCP server.
Objective
DHCP snooping is used to prevent the following problems:
l DHCP denial of service (DoS) attacks

l Bogus DHCP server attacks

l Address Resolution Protocol (ARP) middleman attacks
l IP/MAC spoofing attacks
A DHCP-enabled device supports the following features to secure data transmission:
l MAC address limitation
l DHCP snooping binding table
l Bindings of IP and MAC addresses
l Option 82
DHCP snooping can apply to both Layer 2 and Layer 3 interfaces as shown in Figure 4-59
and Figure 4-60.
Figure 4-59 DHCP snooping application on Layer 2 Interfaces
L3 network
DHCP DHCP Relay

Snooping L2 network
enable
DHCP Server
Trusted
Untrusted
User network

Figure 4-60 DHCP snooping application on Layer 3 Interfaces
DHCP
Snooping L3
enable network
Trusted
Untrusted
DHCP Relay
L2
network DHCP Server
User network
DHCP snooping is used to prevent the following attacks:
l DHCP exhaustion attacks

l Bogus DHCP server attacks
l Middleman attack and IP/MAC spoofing attacks
l DoS attacks initiated by changing CHADDRs
The DHCP snooping working modes vary with the types of attacks, as shown in Table 4-49.
Table 4-49 Attack types and DHCP snooping working modes

Attack Type DHCP Snooping Working Mode
DHCP exhaustion attack MAC address limitation
Bogus DHCP server attack Trusted/untrusted
Middleman attack or IP/MAC address DHCP snooping binding table

spoofing attack
DoS attack initiated by changing Check on CHADDR fields in DHCP

CHADDRs messages
4.8.2 Mechanism
This section describes the mechanism of Dynamic Host Configuration Protocol (DHCP)
snooping.

Bogus DHCP Server Attacks

A bogus DHCP server revices a broadcast DHCPREQUEST message and replies to a DHCP
client with a message with an incorrect gateway IP address, an incorrect Domain Name
System (DNS) server address, or an incorrect client IP addresses. The bogus DHCP server
uses this approach to launch denial of service (DoS) attacks. Figure 4-61 shows a bogus
DHCP server attack.
Figure 4-61 Bogus DHCP server attack

DHCP Server
DHCP Client
DHCP pseudo Server
DHCP discovery (broadcast)

DHCP offer (unicast from the pseudo server)
DHCP request (broadcast)
DHCP ack (unicast from the pseudo server)
To prevent bogus DHCP server attacks, configure DHCP snooping, which works in either
trusted or untrusted mode.
You can configure a trusted or untrusted physical or VLAN interface. DHCPRESPONSE
messages (Offer, ACK, or NAK messages) received by an untrusted interface are directly
discarded to prevent bogus DHCP server attacks. Figure 4-62 shows DHCP snooping that
works in trusted or untrusted mode.
Figure 4-62 DHCP snooping

DHCP Snooping
Enable DHCP Server
DHCP Client
Untrusted Trusted
Untrusted
DHCP pseudo
Server
Middleman Attacks
A middleman sends a packet carrying its own MAC address and the IP address of a DHCP
server. Upon receipt, the client learns the IP and MAC addresses and considers the middleman
as a DHCP server and sends all packets to the middleman, not the DHCP server. After

receiving the packets, the middleman forwards the packet carrying its own MAC and IP
addresses to the server. The DHCP server learns the IP and MAC address and considers the
middleman a client. The DHCP server sends packets to the middleman, not the client. Figure
4-63 shows a middleman attack.
A middleman relays data between the DHCP server and client. The DHCP server and client
assume that they have exchanged packets with each other.
Figure 4-63 Diagram for a middleman attack

(3)
Middleman
(2) (1)
DHCP Server DHCP Client
IP/MAC Spoofing Attacks

An attacker sends a packet carrying the valid IP and MAC addresses of a client to a DHCP
server. The DHCP server mistakes the attacker as a legitimate client and learns the IP and
MAC addresses. The actual client, however, cannot access services provided by the DHCP
server. Figure 4-64 shows an IP/MAC spoofing attack.
Figure 4-64 IP/MAC spoofing attack

DHCP Server
10.1.1.1/32
MAC:1-1-1
10.1.1.2/32
MAC:2-2-2
10.1.1.3/32 10.1.1.2/32
MAC:3-3-3 MAC:2-2-2
Attacker DHCP Client
A DHCP snooping binding table can be used to prevent IP/MAC spoofing and middleman
attacks.

When an interface receives an ARP or IP packet, the interface matches the source IP and
MAC addresses of the packet with entries in a local DHCP snooping binding table. Packets
that match the entries are forwarded, whereas unmatched packets are discarded. Figure 4-65
shows data transmission based on a DHCP snooping binding table.
ARP packets or IP packets sent by clients with static IP addresses are discarded. This is
because these clients do not obtain IP addresses by sending DHCPREQUEST messages, and
no DHCP snooping binding entry exists for them. As a result, these clients are prevented from
accessing the network illegally. To allow the users with statically allocated IP addresses to
access the network, configuring a static DHCP snooping binding table is mandatory.
Similarly, packets from a client that embezzle a legal IP address of other clients are discarded.
The client does not obtain IP addresses by sending DHCPREQUEST messages. Hence the
MAC address and interface information in the DHCP snooping binding table corresponding to
the IP address are inconsistent with those of the embezzler. In this way, these clients are
prevented from accessing the network illegally.
Figure 4-65 Data transmission based on a DHCP snooping binding table

Matched in the
binding table
DHCP snooping
enable
ISP network
Not matched in the

binding table
Entries in a DHCP snooping binding table are classified into the following types:
l Static entries: manually configured on a FW. These entries can only be manually deleted.
l Dynamic entries: automatically learned by a FW using DHCP snooping. These entries
age after IP address leases expire.
Dynamic entries in a DHCP snooping binding table are automatically generated based on
DHCPACK messages sent by a DHCP server. The procedure for generating dynamic entries is
as follows:
l On a Layer 2 device:
– An Option 82-enabled Layer 2 device receives a DHCPREQUEST message and
appends Option 82 to the message. The Layer 2 device determines an outbound
interface to which a DHCPRESPONSE message is sent based on Option 82 and
generates a DHCP snooping binding entry.
– An Option 82-disabled Layer 2 device identifies interface information in messages
based on a MAC address table.
l On a Layer 3 device
A device obtains the IP address of an untrusted interface assigned by a DHCP server, the
MAC address of the interface, and the interface through which messages pass by
monitoring a DHCPRESPONSE message. An IP and MAC binding entry of the
untrusted interface is then generated. The dynamic binding entry has the same lease as

the IP address of the client. After the lease expires or the client releases the IP address,
the entry is automatically deleted.
DoS Attacks Initiated by Changing CHADDRs

An attacker may change Client Hardware Addresses (CHADDRs), not source MAC
addresses, in the frame header of DHCP messages in an attempt to continually apply for IP
addresses. This approach causes a device to fail to verify packets because the device checks
only source MAC addresses.
Figure 4-66 DoS attacks initiated by changing CHADDERs

0 7 15 23 31
OP Code Hardware Type Hardware Length HOPS
Transaction ID (XID)
Seconds Flags
Client IP Address (CIADDR)
Your IP Address (YIADDR)
Server IP Address (SIADDR)
Gateway IP Address (GIADDR)
Client Hardware IP Address (CHADDR)-16 bytes
Server Name (SNAME)-64 bytes
Filename-128 bytes
DHCP Options
To prevent DoS attacks, enable DHCP snooping to check the CHADDR field in a
DHCPREQUEST message. If the CHADDR field matches the source MAC address in the
frame header, the message is forwarded. If the CHADDR field does not match the source
MAC address, the message is discarded.
Option 82
l Format of a packet with an Option 82 field
Option 82 is a DHCP Relay Agent Information option that records location information
about a DHCP client. It is a special field contained in a DHCP message.
When a DHCPREQUEST message sent by a DHCP client passes through a DHCP relay
agent, the relay agent adds an Option 82 field to this DHCPREQUEST message. Upon
receipt, a DHCP server replies with a DHCPRESPONSE message containing the same
Option 82 field to the DHCP relay agent. The DHCP relay agent then determines for
which interface the DHCPRESPONSE message is destined based on the Option 82 field.
Figure 4-67 shows the format of a DHCP message with Option 82 field.

Figure 4-67 Format of a packet with an Option 82 field

Code Length Agent Information Field
82 N i1 i2 i3 i4 i5 … iN
The message contains the following fields:

– Code field: 82, a fixed value.
– Length field: the total number of bytes in the Agent Information field.
– iN field: sub-options in the Agent Information field, and each sub-option is a
SubOpt/Length/Value tuple.
Figure 4-68 shows the format of the Agent Information field.
Figure 4-68 Format of the Agent Information field

SubOpt Length Sub-Option Value
1 N a1 a2 a3 a4 a5 … aN
2 N b1 b2 b3 b4 b5 … bN
9 N c1 c2 c3 c4 c5 … cN
The Agent Information field contains the following fields:

– SubOpt field: a sub-option number.
– Length field: the number of bytes.
In an Option 82 field, at least one sub-option must be defined and can be set to null. The
minimum length of an Option 82 field is 2 bytes.
The initially assigned DHCP relay agent sub-options are agent circuit ID sub-option and
agent remote ID sub-option. A DHCP server uses the agent circuit ID sub-option for IP
and other parameter assignment policies.
The device also supports Sub-option 9, in addition to Sub-option 1. Sub-option 9 is used
to show added circuit IDs.
Sub-option 9 in a DHCPRESPONSE message supports the following functions:
– Enables a device to parse the Option 82 field and obtain interface information. The
device strips the Device Identifier field off Sub-option 9 before forwarding the
DHCPRESPONSE message.
– Enables a device to create a DHCP snooping binding table based on interface
information obtained from Sub-option 9.
Option 82 can be used on Layer 2 and Layer 3 devices. Layer 3 devices use Option 82 to
define address assignment or other policies for a DHCP server. Layer 2 devices
determine interfaces to which DHCPRESPONSE messages are sent and generate IP and

MAC binding entries based on Option 82. The following describes how to use Option 82
on Layer 2 devices and Layer 3 devices.
l Option 82 appended by a Layer 2 device
The client shown in Figure 4-69 accesses a Layer 2 device, and the Layer 2 device
connects the client to the DHCP relay agent and server over a Layer 2 network.
If DHCP snooping is enabled on the Layer 2 device, the Layer 2 interface may receive
broadcast DHCPRESPONSE messages. Upon receipt, the Layer 2 device performs the
following operations:
– Searches for a VLAN based on the MAC address carried in each message.
– Determines an outbound interface for the message.
– Generates an entry for the binding between the IP and MAC address.
If the DHCP Option 82 function is enabled, the Layer 2 device can monitor DHCP
messages and append Option 82 to a DHCPDISCOVERY message. After receiving a
DHCPDISCOVERY message, a DHCP server replies with the DHCPRESPONSE
message carrying Option 82. The Layer 2 device determines the interface to which the
DHCPRESPONSE message is sent based on Option 82 and generates DHCP snooping
binding entries. The Layer 2 device removes Option 82 before forwarding the
DHCPRESPONSE message to the client.
Figure 4-69 Option 82 appended by a Layer 2 device

Client DHCP Relay DHCP Server
Discover
Discover+Option82
Offer+Option82
Offer
Request
Request+Option82
Ack+Option82
Ack
Data exchange
l Option 82 appended by a Layer 3 device

Option 82 can be appended to message by Layer 3 DHCP relay agents.

After Option 82 is enabled on the DHCP relay agent shown in Figure 4-70, the DHCP
relay agent appends Option 82 to the DHCPREQUEST message to a DHCP server. The
DHCP server assigns an IP address and delivers network parameters based on Option 82.
The DHCP server also adds Option 82 into a DHCPRESPONSE message sent to the
DHCP relay agent. After the DHCPRESPONSE message arrives, the DHCP relay agent
removes Option 82 before forwarding the message to a client.
Figure 4-70 Option 82 appended by a Layer 3 device

Client Switch DHCP Relay DHCP Server
Discover
Discover+Option82
Offer+Option82
Offer
Request
Request+Option82
Ack+Option82
Ack
Data exchange
l Option 82 implementation
After the Option 82 function is enabled, a DHCP relay agent must check whether an
Option 82 field is carried in a DHCPREQUEST message sent by a client.
– If the DHCPREQUEST message contains an Option 82 field, the agent checks the
mode Option 82 information was added in:
n Rebuild mode: The agent does not trust the Option 82 field contained in the
received message and modifies Sub-option 1 contained in the Option 82 field.
n Insert mode: The agent trusts the Option 82 field contained in a received
message and does not need to modify Sub-option 1 contained in the Option 82
field. The agent checks whether there is Sub-option 9. If Sub-option 9 is not
contained, the agent adds Sub-option 9 to the message. If the message contains
Sub-option 9, the agent checks whether this option contains the Device
Identifier field. If there is no Device Identifier field, the agent adds the field
that follows the manufacturer information field in the message.

– If the DHCPREQUEST message does not contain an Option 82 field, the agent
adds an Option 82 field with Sub-option 1, regardless of the Insert or Rebuild mode.
The agent checks whether the message contains Sub-option 1 or Sub-option 9 and
whether a sub-option contains the Device Identifier field. If the message contains Sub-
option 1 or Sub-option 9 or if a sub-option contains the Device Identifier field, the agent
properly parses the Option 82 field. It strips the Device Identifier field off Sub-option 1
or Sub-option 9 before forwarding the DHCPRESPONSE message.
4.8.3 Configuring Defense Against Attacks Initiated by a Bogus

DHCP Server
A bogus DHCP server attack means that an attacker forges itself as a DHCP server to prevent
a target from accessing a network.
4.8.3.1 Configuring a Layer 2 Interface to Defend Against Attacks Initiated by a

Bogus DHCP Server
This section describes how to prevent an attacker connected to a Layer 2 interface from
launching bogus DHCP server attacks.
Prerequisites
Before preventing a bogus DHCP server attack on a Layer 2 interface, configure a DHCP
server.
Context
NOTE
Note the following issues

l When DHCP snooping is disabled, only the VLAN or interface connected to a DHCP server is
trusted by default.
l When DHCP snooping is enabled, the VLAN or interface connected to a DHCP server is untrusted
by default.
The device discards messages sent by the untrusted VLAN or interface. To configure the VLAN or
interface to be trusted, run the dhcp snooping trusted command.
Procedure
system-view
Step 2 Enable DHCP snooping.

dhcp snooping enable
Enable DHCP snooping globally before enabling DHCP snooping on a VLAN.

Step 3 Access the VLAN view.
vlan vlan-id
Step 4 Assign a Layer 2 interface to the VLAN.

Only Layer 2 interfaces can be assigned to a VLAN.


dhcp snooping enable interface interface-type interface-number
Step 6 Trust the VLAN or interface connected to a DHCP server.

dhcp snooping trusted [ interface interface-type interface-number ]
DHCP messages sent by the trusted VLAN and interface are all forwarded properly.
----End
Follow-up Procedure
l Run the display dhcp snooping global command to view global DHCP snooping
information.
l Run the display dhcp snooping { vlan vlan-id [ interface interface-type interface-
number ] } command to view DHCP snooping information on a specified interface.
If the following results are displayed, the configuration is successful:

l DHCP snooping is enabled in both the system and interface views.
l The interface connected to a client is untrusted, whereas the interface connected to a
network is trusted.
l Statistics about the discarded ARP, IP, and DHCP packets are displayed.
<sysname> display dhcp snooping vlan 10 interface GigabitEthernet 1/0/1
dhcp snooping enable interface GigabitEthernet
1/0/1
dhcp snooping trusted interface GigabitEthernet 1/0/1

arp total 0
ip total 0
dhcp-request total 0
chaddr&src mac total 0
dhcp-reply total 0
4.8.3.2 Configuring a Layer 3 Interface to Defend Against Attacks Initiated by a

Bogus DHCP Server
launching bogus DHCP server attacks.
Prerequisites
Before preventing a bogus DHCP server attack on a device, complete the following tasks:
l Configure the DHCP server.

l Configure a DHCP relay agent.
Context
Note the following issues
l When DHCP snooping is disabled, only the VLAN or interface connected to a DHCP
server is trusted by default.
l When DHCP snooping is enabled, the VLAN or interface connected to a DHCP server is
untrusted by default.

The device discards messages sent by the untrusted VLAN or interface. To configure the
VLAN or interface to be trusted, run the dhcp snooping trusted command.
Procedure
system-view

Enable DHCP snooping globally before enabling DHCP snooping on a Layer 3 interface.

DHCP snooping can be enabled on the following Layer 3 interfaces:
l Ethernet interfaces
l Ethernet sub-interfaces
l Vlanif interfaces
l Layer 3 Eth-Trunk interfaces
Step 4 Enable DHCP snooping on the interface.

Step 5 Trust the interface connected to a DHCP server.

dhcp snooping trusted
----End
Follow-up Procedure
information.
l Run the display dhcp snooping interface interface-type interface-number command to
view DHCP snooping information on a specified interface.

l The interface connected to a client is untrusted, whereas the interface connected to a
network is trusted.
<sysname> display dhcp snooping interface GigabitEthernet 1/0/1
arp total 0
ip total 0
dhcp-reply total 0

4.8.4 Configuring Defense Against Man-in-the-Middle and

A man-in-the-middle attack means that an attacker pretends to be the server and client at the
same time, transmits packets between the real server and client, and obtains user data.
4.8.4.1 Configuring a Layer 2 Interface to Defend Against Man-in-the-Middle and

This section describes how to prevent an attacker connected to the Layer 2 interface from
launching man-in-the-middle or IP/MAC spoofing attacks.
Prerequisites
Before preventing the man-in-the-middle and IP/MAC spoofing attacks on a Layer 2
Interface, configure a DHCP server.
Context
Dynamic entries in the DHCP snooping binding table do not need to be manually configured.
They are automatically generated after DHCP snooping is enabled. Static entries must be
manually configured.
NOTE
l If an IP address is dynamically assigned to a client, a device automatically learns the MAC address
of the client and generates an IP and MAC binding entry. This binding table requires no
configuration.
l If an IP address is statically assigned to a client, a device cannot automatically learn the MAC
address of the client or generate an IP and MAC binding entry. You need to create IP and MAC
binding table manually.
If you do not create an IP and MAC binding table manually, the following two cases may
occur:
l If the device is configured to forward packets without matching entries, packets from all
static IP addresses are forwarded, and all static clients can access the DHCP server
properly. By default, the device forwards mismatching packets.
l If the device is configured to discard packets without matching entries, packets from all
static IP addresses are discarded, and no static clients can access the DHCP server.
After receiving an ARP or an IP packet, the interface matches its source IP and MAC
addresses with entries in the DHCP snooping binding table and verify information about the
MAC, IP, interface and VLAN.
l If they do not match, the packet is discarded.

l If they totally match, the packet is forwarded.
Procedure
system-view



vlan vlan-id
Step 4 Assign a Layer 2 interfaces to the VLAN.


Step 6 Trust the VLAN or interface connected to a DHCP server.

dhcp snooping trusted interface interface-type interface-number
DHCP messages sent by the trusted VLAN and interface are all forwarded properly.
Step 7 Enable the VLAN packet check.

dhcp snooping check { arp | ip | dhcp-chaddr | dhcp-request } enable interface
interface-type interface-number
Step 8 Configure a static IP and MAC binding entry.

dhcp snooping bind-table static ip-address ip-address mac-address mac-address

l To enable the device to add Option 82 information into packets, run:
dhcp option82 insert enable interface interface-type interface-number
If the original message does not carry Option 82, Option 82 is appended to DHCP
messages. If the message carries Option 82, Sub-option 9 is added to DHCP messages.
l Enable the device to forcibly add Option 82 into packets, run:
dhcp option82 rebuild enable interface interface-type interface-number
Option 82 is appended to DHCP messages if the original DHCP message is not

appended with Option 82. If the original DHCP message is appended with Option 82, the
original Option 82 is forcibly removed, and new Option 82 is appended.
A binding table with accurate interface information can be created after Option 82 is enabled.
Step 10 Configure how to process the IP and ARP packets if the DHCP snooping binding table does
not contain mapping entries.
1. Specify a rule for processing mismatching packets in the VLAN view.
dhcp snooping nomatch-packet { arp | ip } action { forward | discard }

quit
3. Specify a rule for processing mismatching packets in the system view.

dhcp snooping nomatch-packet [ arp | ip ] action { forward | discard }
If there is no matching entry for a packet in the DHCP snooping binding table, the device
processes the packet using a user-defined method.
----End

Follow-up Procedure
information.
l Run the display dhcp snooping bind-table { ip-address ip-address | mac-address mac-
address | vlan vlan-id [ interface interface-type interface-number ] | static | dynamic |
all } command to view information about the DHCP snooping binding table.
number ] } command to view DHCP snooping information on a specified interface.
l Run the display dhcp option82 { [ vlan vlan-id ] interface interface-type interface-
number } command to view the Option 82 status.

l Option 82 is enabled on the interface.
l Interface names and the matching MAC and IP addresses in the DHCP snooping binding
table are displayed.
dhcp snooping enable interface GigabitEthernet
1/0/1
dhcp snooping trusted interface GigabitEthernet

1/0/1
dhcp snooping check ip enable interface GigabitEthernet 1/0/1

arp total 0
ip total 0
dhcp-reply total 0
4.8.4.2 Configuring a Layer 3 Interface to Defend Against Man-in-the-Middle and

launching man-in-the-middle or IP/MAC spoofing attacks.
Prerequisites
Before preventing the man-in-the-middle and IP/MAC spoofing attacks on a Layer 3
Interfaces, complete the following tasks:
l Configure a DHCP server.

Context
Dynamic entries in the DHCP snooping binding table do not need to be manually configured.
They are automatically generated after DHCP snooping is enabled. Static entries must be
manually configured.

NOTE
l If an IP address is dynamically assigned to a client, a device automatically learns the MAC address
of the client and generates an IP and MAC binding entry. This binding table requires no
configuration.
l If an IP address is statically assigned to a client, a device cannot automatically learn the MAC
address of the client or generate an IP and MAC binding entry. You need to create IP and MAC
binding table manually.
If you do not create an IP and MAC binding table manually, the following two cases may be
encountered:
l If the device is configured to forward packets without matching entries, packets from all
static IP addresses are forwarded, and all static clients can access the DHCP server
properly. By default, the device forwards mismatching packets.
l If the device is configured to discard packets without matching entries, packets from all
static IP addresses are discarded, and no static clients can access the DHCP server.
Procedure
system-view


l VlanIf interfaces
l Eth-Trunk interfaces
Step 5 Enable the device to check packets on the interface.

dhcp snooping check { arp | ip | dhcp-chaddr | dhcp-request } enable




Step 8 Configure how to process the IP and ARP packets if the DHCP snooping binding table does
not contain mapping entries.
1. Specify a rule for processing mismatching packets in the interface view.

quit
3. Specify a rule for processing mismatching packets in the system view.

If there is no matching entry for a packet in the DHCP snooping binding table, the device
processes the packet using a user-defined method.
----End
Follow-up Procedure
information.
view DHCP snooping information on an interface.
l Run the display dhcp option82 interface interface-type interface-number command to
view the Option 82 status.
dhcp snooping
enable
dhcp snooping
trusted
dhcp snooping check arp enable

arp total 0
ip total 0


dhcp-reply total 0
4.8.5 Configuring Defense Against Attacks Launched by

Changing the CHADDR Value
The attacker continuously applies for the IP address from the DHCP server by changing the
CHADDR value.
4.8.5.1 Configuring Defense on the Layer 2 Interfaces Against Attacks by

Changing CHADDRs
This section describes how to prevent the attacker connected to the Layer 2 interface from
changing the CHADDR value to launch attacks.
Procedure
system-view


vlan vlan-id


Step 6 Enable the device to check CHADDRs of packets from a specified VLAN.
dhcp snooping check dhcp-chaddr enable interface interface-type interface-number
----End
Follow-up Procedure
information.
number ] } command to view DHCP snooping information on an interface.
dhcp snooping enable interface GigabitEthernet 1/0/1
dhcp snooping check dhcp-chaddr enable interface GigabitEthernet 1/0/1
arp total 0

ip total 0
dhcp-reply total 0

Changing CHADDRs
changing the CHADDR value to launch attacks.
Prerequisites
Before preventing the attacker from changing CHADDR through a Layer 3 device, complete
the following tasks:
Procedure
system-view


l Vlanif interfaces
Step 5 Enable the device to checking CHADDRs of packets on the interface.

dhcp snooping check dhcp-chaddr enable
Enable checking CHADDRs. The device compares the CHADDR field in the received DHCP
Request message with the source MAC address in the frame header. If they are inconsistent,
the received DHCP request message is considered as an attack packet and is directly
discarded.
----End
Follow-up Procedure
information.

l Run the display dhcp snooping { interface interface-type interface-number } command

to check DHCP snooping information on a specified interface.

arp total 0
ip total 0
dhcp-reply total 0
4.8.6 Configuring Defense Against Attacks by Sending Bogus

Packets for Extending IP Leases
The attacker continuously sends DHCP request packets to pretend to be a user for leasing the
IP address again. As a result, the expired IP addresses cannot be reclaimed properly.

Sending Bogus Packets for Extending IP Leases
launching bogus DHCP extended-releasing packet attacks.
Context
The dynamic entries in the DHCP snooping binding table require no configuration. They are
automatically generated when Enable DHCP snooping. The static entries, however, require to
be manually configured.
NOTE
l If the IP address is dynamically assigned to the client, the device automatically learns the MAC
address of the client and generates IP and MAC binding table. This binding table requires no
configuration.
l If the IP address is statically assigned to the client, the device cannot automatically learn the MAC
address of the client and the IP/MAC binding table cannot be generated. You need to create IP and
MAC binding table manually.
If you do not create an IP and MAC binding table manually, the following two cases may be
encountered:
l If the packet without a matching entry is set to be forwarded, packets from all static IP
addresses are forwarded and all static clients can access the DHCP server properly. By
default, the device forwards mismatching packets.
l If the packet without a matching entry is set to be discarded, packets from all static IP
addresses are discarded, and no static clients can access the DHCP server.


Procedure
system-view

Step 3 Set the rate at which DHCP messages are sent.

dhcp snooping check dhcp-rate rate
Step 4 Enable the check of the rate at which DHCP messages are sent.
dhcp snooping check dhcp-rate enable

vlan vlan-id


Step 8 Enable the device to check DHCP Request messages from a specified VLAN.
dhcp snooping check dhcp-request enable interface interface-type interface-number



----End
Follow-up Procedure
information.

number ] } command to view DHCP snooping information on an interface.
l Run the display dhcp option82 { [ vlan vlan-id ] interface interface-type interface-
number } command to view the Option 82 status.

l Interface names and their matching MAC addresses and IP addresses in the DHCP
snooping binding table are displayed.
dhcp snooping enable interface GigabitEthernet 1/0/1
dhcp snooping check dhcp-request enable interface GigabitEthernet 1/0/1
arp total 0
ip total 0
dhcp-reply total 0

Sending Bogus Packets for Extending IP Leases
launching bogus DHCP extended-releasing packet attacks.
Prerequisites
Before preventing the attacker from sending bogus messages for extending IP leases,
complete the following tasks:

Context
The dynamic entries in the DHCP snooping binding table require no configuration. They are
automatically generated when Enable DHCP snooping. The static entries, however, require to
be manually configured.
NOTE
l If the IP address is dynamically assigned to the client, the device automatically learns the MAC
address of the client and generates IP and MAC binding table. This binding table requires no
configuration.
l If the IP address is statically assigned to the client, the device cannot automatically learn the MAC
address of the client and the IP/MAC binding table cannot be generated. You need to create IP and
MAC binding table manually.
If you do not create an IP and MAC binding table manually, the following two cases may
occur:

l If the packet without a matching entry is set to be forwarded, packets from all static IP
addresses are forwarded and all static clients can access the DHCP server properly. By
default, the device forwards mismatching packets.
l If the packet without a matching entry is set to be discarded, packets from all static IP
addresses are discarded, and no static clients can access the DHCP server.

Procedure
system-view

Step 3 Set the rate at which DHCP messages are sent.

dhcp snooping check dhcp-rate rate
Step 4 Enable the check of the rate at which DHCP messages are sent.

l Vlanif interfaces

Step 7 Enable the device to check DHCP Request messages sent by a specified interface.
dhcp snooping check dhcp-request enable




----End
Follow-up Procedure
information.
l Run the display dhcp snooping bind-table {ip-address ip-address | mac-address mac-
address | static | dynamic | all } command to view information about the DHCP
snooping binding table.
view DHCP snooping information on the interface.
l Run the display dhcp option82 interface interface-type interface-number command to
view the Option 82 status.

arp total 0
ip total 0
dhcp-reply total 0
4.8.7 Configuring Alarms Used to Discard Packets

This section describes how to notify the NMS of attacks.
Prerequisites
Before configuring alarms about discarded packets, complete the following tasks:

l Configure the device to discard DHCP reply messages sent by untrusted interfaces.
l Enable the device to check the DHCP snooping binding table.
l Enable the device to check CHADDRs of DHCP request messages.

Procedure
system-view
Step 2 Perform either of the following operations to access a specific view:

l To access the VLAN view, run:
vlan vlan-id
l To access the interface view, run:

Step 3 Enable the alarm function.

dhcp snooping alarm { arp | ip |dhcp-request | dhcp-chaddr | dhcp-reply } enable
[ interface interface-type interface-number ]
Step 4 Set the alarm threshold of the maximum number of discarded packets.
In the VLAN view, run:

dhcp snooping alarm { arp | ip | dhcp-request | dhcp-chaddr | dhcp-reply }
threshold threshold interface interface-type interface-number
Or in the interface view, run:

dhcp snooping alarm { arp | ip |dhcp-request | dhcp-chaddr | dhcp-reply }
threshold threshold
----End
Follow-up Procedure
information.
l Run the display dhcp snooping { interface interface-type interface-number | vlan vlan-
id [ interface interface-type interface-number ] } command to view DHCP snooping
information on a specified interface.

4.8.8 Maintaining DHCP Snooping

This section describes how to maintain DHCP snooping.
4.8.8.1 Maintaining a DHCP Snooping Binding Table

This section describes how to maintain a DHCP snooping binding table.
Displaying DHCP Snooping Configurations

Table 4-50 lists the commands run in all views to check DHCP snooping configurations.

Table 4-50 Displaying DHCP snooping configurations

Action Command
Display Option82 display dhcp option82 [ vlan vlan-id ] interface

information. interface-type interface-number
Display information about display dhcp snooping [ vlan vlan-id ] interface

DHCP snooping on a specific interface-type interface-number
interface.
Display information about display dhcp snooping bind-table { ip-address ip-

entries in a DHCP snooping address | mac-address mac-address | [ vlan vlan-id ]
binding table. interface interface-type interface-number | static |
dynamic | all }
Display global DHCP display dhcp snooping global

snooping information.
Maintaining a DHCP Snooping Binding Table

NOTE
Resetting the DHCP snooping binding table results in information loss in the binding table. Perform the
resetting of the DHCP snooping binding table with caution.
Table 4-51 lists the commands run in the system view to maintain a DHCP snooping binding
table.
Table 4-51 Maintaining a DHCP snooping binding table

Action Command
Back up a DHCP snooping dhcp snooping bind-table autosave filename

binding table.
Reset a DHCP snooping reset dhcp snooping bind-table { interface interface-

binding table. type interface-number | vlan vlanid [ interface interface-
type interface-number ] | static | dynamic }
4.8.8.2 Debugging the DHCP Snooping Function

If a fault occurs, you can run the following debugging command in the user view to enable the
debugging for locating the fault.

NOTICE
For the description of the debugging command, see Debugging Reference.

Table 4-52lists the commands to debug DHCP snooping information.
Table 4-52 Debugging DHCP snooping information

Action Command
Debug DHCP snooping debugging dhcp snooping

information.
4.8.9 Example for Configuring DHCP Snooping

This example describes how to adopt DHCP snooping to defend against DHCP packet attacks
launched by the attacker connected to the Layer 3 interface.
DHCP clients access the DHCP relay agent on the network shown in Figure 4-71. DHCP
snooping needs to be configured on Layer 3 interfaces GigabitEthernet 1/0/1 and
GigabitEthernet 1/0/2 on FW. The interface on the DHCP client side is untrusted, and the
interface on the DHCP server agent side is trusted.
In such a case, FW is capable of preventing the following attacks:
l Bogus DHCP server attack
l Middleman attack or IP/MAC address attack
l DoS attack by changing CHADDR
l Attack by generating bogus DHCP messages to extend IP leases
DHCP client1 uses the dynamically allocated IP address, and DHCP client2 uses the statically
configured IP address.

Figure 4-71 Networking diagram for configuring DHCP snooping on the device
DHCP Server
10.11.1.2/24
Trusted
GE1/0/2
NGFW
10.11.1.1/24
DHCP Relay
Trust
GE1/0/1
Untrusted 10.1.1.254/24
Trust
Switch
DHCP Client2
DHCP
IP:10.1.1.1/24
Client1
mac:00e0-fc5e-008a
1. Enable DHCP snooping globally and in the interface view.
2. Configure interfaces to be trusted or untrusted to prevent bogus DHCP server attacks.
3. Configure DHCP snooping binding tables and enable matching ARP packets, IP packets,
and DHCPREQUEST messages with entries in the DHCP snooping tables to prevent
middleman attack or IP/MAC address attacks and bogus DHCP messages to extend IP
leases.
4. Configure CHADDR check to prevent attackers from changing CHADDRs in the
messages.
5. Configure Option 82 and create a binding table covering accurate interface information.
6. Configure the sending of alarms to the network management station (NMS).
Procedure
Step 1 Configure basic DHCP relay function.
# Assign an IP address to GigabitEthernet 1/0/2.
<FW> system-view
[FW] sysname DHCP-Relay

[DHCP-Relay] interface GigabitEthernet 1/0/2

[DHCP-Relay-GigabitEthernet1/0/2] ip address 10.11.1.1 24
[DHCP-Relay-GigabitEthernet1/0/2] quit
# Configure the sub-interface on which the DHCP relay agent is to be enabled and configure
the IP address and mask for the sub-interface. Ensure that the sub-interface and the DHCP
client must be at the same network segment.
[DHCP-Relay-GigabitEthernet1/0/1] ip address 10.1.1.254 24
[DHCP-Relay-GigabitEthernet1/0/1] dhcp select relay
[DHCP-Relay-GigabitEthernet1/0/1] ip relay address 10.11.1.2

# Enable DHCP snooping in the system and interface views.
[DHCP-Relay] dhcp snooping enable
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping enable
[DHCP-Relay-GigabitEthernet1/0/2] dhcp snooping enable
Step 3 Configure the interface to be trusted.

# Configure the interface on the DHCP server side to be trusted and enable DHCP snooping
on all interfaces on the DHCP client side. If the interfaces on the DHCP client side are not set
to be trusted, they are untrusted by default after DHCP snooping is enabled. Configuring
trusted or untrusted interfaces prevents bogus DHCP server attacks.
[DHCP-Relay-GigabitEthernet1/0/2] dhcp snooping trusted
Step 4 Enable the interface to check specified types of packets and configure DHCP snooping
binding tables.
# Check ARP and IP packets on the interfaces on the DHCP client side to prevent IP/MAC
spoofing attacks.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping check arp enable
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping check ip enable
# Enable the interfaces on the DHCP client side to check DHCPREQUEST messages to
prevent attackers from sending bogus DHCP messages to extend IP leases.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping check dhcp-request enable
# Enable checking CHADDRs on the interfaces on the DHCP client side to prevent attackers
from changing CHADDRs in the messages.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping check dhcp-chaddr enable
# Configure static binding entries.

If you use the static IP address, configure static DHCP snooping entries.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping bind-table static ip-address
10.1.1.1 mac-address 00e0-fc5e-008a
Step 5 Limit the rate at which DHCP messages are sent.

# Set the rate of sending DHCPREQUEST messages to the protocol stack to prevent
excessive DHCPREQUEST messages.

[DHCP-Relay] dhcp snooping check dhcp-rate 90

[DHCP-Relay] dhcp snooping check dhcp-rate enable
Step 6 Configure Option 82.

# Configure interface information to be carried in DHCP messages to make the DHCP
snooping table more accurate.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp option82 insert enable
Step 7 Configure behaviors to process packets that do not match the entries.
# Configure the global behaviors to process ARP and IP packets that do not match the entries.
[DHCP-Relay] dhcp snooping nomatch-packet arp action discard
[DHCP-Relay] dhcp snooping nomatch-packet ip action discard
# Configure behaviors to process the ARP and IP packets that do not match the entries on the
interface.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping nomatch-packet arp action discard
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping nomatch-packet ip action discard
Step 8 Enable the interface to send alarms to the NMS.

# Enable the interface to send specified alarms to the NMS.
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-reply enable
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm arp enable
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-chaddr enable
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-request enable
[DHCP-Relay] dhcp snooping check dhcp-rate alarm enable
# Set the alarm threshold.

[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-reply threshold 10
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm arp threshold 10
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-chaddr threshold 10
[DHCP-Relay-GigabitEthernet1/0/1] dhcp snooping alarm dhcp-request threshold 10
[DHCP-Relay] dhcp snooping check dhcp-rate alarm threshold 40
Step 9 Assign interfaces to security zones.

[DHCP-Relay] firewall zone trust
[DHCP-Relay-zone-trust] add interface GigabitEthernet 1/0/1
[DHCP-Relay-zone-trust] add interface GigabitEthernet 1/0/2
[DHCP-Relay-zone-trust] quit
----End
Result
l Run the display dhcp snooping global command on the DHCP relay agent. You can see
that DHCP snooping is enabled in the system and interface views. You can also view
statistics about alarms sent to the NMS.
[DHCP-Relay] display dhcp snooping global
dhcp snooping nomatch-packet ip action discard
dhcp snooping nomatch-packet arp action discard
dhcp snooping check dhcp-rate alarm enable

dhcp snooping check dhcp-rate 90

dhcp snooping check dhcp-rate alarm threshold 40
l View information about the binding table of DHCP snooping.

[DHCP-Relay] display dhcp snooping bind-table static
bind-table:
ifname vrf vsi p/cvlan mac-address ip-address tp lease
-------------------------------------------------------------------------
GE1/0/1 0000 - 0000/0000 00e0-fc5e-008a 10.1.1.1 S 0
-------------------------------------------------------------------------
binditem count: 1 binditem total count: 1
l View DHCP snooping information on the interface.

[DHCP-Relay] display dhcp snooping interface GigabitEthernet 1/0/1
dhcp snooping alarm arp enable
dhcp snooping alarm arp threshold 10
dhcp snooping check ip enable
dhcp snooping alarm dhcp-reply enable
dhcp snooping alarm dhcp-reply threshold 10
dhcp snooping alarm dhcp-chaddr enable
dhcp snooping alarm dhcp-chaddr threshold 10
dhcp snooping alarm dhcp-request enable
dhcp snooping alarm dhcp-request threshold 10
arp total 0
ip total 0
dhcp-reply total 0
[DHCP-Relay] display dhcp option82 interface GigabitEthernet 1/0/1
dhcp option82 insert enable
[DHCP-Relay] display dhcp snooping interface GigabitEthernet 1/0/2
arp total 0
ip total 0
dhcp-reply total 0
#
dhcp snooping check dhcp-rate 90
dhcp snooping check dhcp-rate alarm threshold 40
#
sysname DHCP-Relay
#
ip address 10.1.1.254 255.255.255.0
ip relay address 10.11.1.2
dhcp select relay
dhcp snooping alarm arp enable
dhcp snooping alarm arp threshold 10
dhcp snooping check ip enable
dhcp snooping alarm dhcp-reply enable

dhcp snooping alarm dhcp-reply threshold 10

dhcp snooping alarm dhcp-chaddr enable
dhcp snooping alarm dhcp-chaddr threshold 10
dhcp snooping alarm dhcp-request enable
dhcp snooping alarm dhcp-request threshold 10
dhcp option82 insert enable
dhcp snooping bind-table static ip-address 10.1.1.1 mac-address 00e0-fc5e-008a
#
ip address 10.11.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#

This section provides DHCP snooping references.
This section provides DHCP snooping specifications.
Enabling DHCP Snooping - Supported by all models.

globally

on an interface

on a VLAN
Dynamic DHCP Snooping The DHCP Snooping Supported by all models.

binding table binding table is dynamically
generated by obtaining and
resolving the packets
received from the DHCP
server. The contents of the
binding table include IP
addresses, MAC addresses,
VLAN ID and interface
information.

Static DHCP Snooping You can manually configure Supported by all models.
binding table to generate the DHCP
Snooping binding table. The
contents of the binding table
include IP addresses, MAC
addresses, VLAN ID and
interface information.
Management of DHCP You can add, delete, modify, Supported by all models.
Snooping binding table query, save or restore the
dynamic or static DHCP
Snooping binding table by
commands.
Defense against attacks If the attacker changes the Supported by all models.
launched by changing the Client Hardware Address
CHADDR value (CHADDR) value of DHCP
packets instead of changing
the source MAC address of
the data frame header to
continuously apply for an IP
address, you can use the
function of checking the
CHADDR field in the
DHCP request packets by
DHCP Snooping. If the field
matches the source MAC
address of the data frame
header, the packet is
forwarded; otherwise, the
packet is discarded.
Defense against attacks by - Supported by all models.

sending bogus packets for
extending IP leases
Generating alarms for - Supported by all models.

attacks launched by
changing the CHADDR
value

attacks by sending bogus
packets for extending IP
leases

checking the rate at which
DHCP messages are sent to
the DHCP protocol stack

Transparent transmission of Option60 contains product Supported by all models.

the Option 60 information of DHCP
clients and is transmitted
transparently without any
changing during DHCP
snooping.
Processing and generating The process modes for IP Supported by all models.
alarms for illegitimate IP packets and ARP packets
packets and ARP packets which cannot be matched by
any entries in the DHCP
Snooping binding table can
be specified. The alarm
threshold for illegitimate IP
packets and ARP packets
can also be set.
None

This section describes the versions and changes in the dynamic host configuration protocol
(DHCP) snooping feature.

This section provides DHCP snooping standards and protocols.
l RFC 3046: DHCP Relay Agent Information Option

l RFC 2132: DHCP Options and BOOTP Vendor Extensions
4.9 MAC Address Table

This section describes MAC address table concepts and how to configure a MAC address
table, as well as provides a configuration example.

4.9.1 Overview
A MAC address table is an interface-based Layer 2 forwarding table. It stores information
about the MAC addresses learned by a device.
MAC Address Table

Before implementing the express packet forwarding, the MAC address table of a FW must be
maintained.
The maintenance items in the MAC address table are as follows:
l MAC address of a device connected to a FW
l Number and VLAN ID of an interface connecting the FW to the device
MAC Address Entries

MAC address entries are classified into the following types:
l Static MAC address entry: manually configured. It can be added or deleted manually and
never ages. Using static MAC address entries can reduce broadcast traffic on a network.
MAC address entries apply to networks where devices are seldom changed.
l Dynamic MAC address entry: manually configured by a user or learned by a device. It
ages after the specified aging time elapses.
l Blackhole MAC address entry: a special type of MAC addresses manually configured.
After receiving a packet whose source or destination MAC address is a blackhole MAC
address, the device discards the packet.
Table 4-53 lists the classifications and features of MAC address entries.
Table 4-53 Classifications and features of MAC address entries

MAC Address Configuration Aging Time Be Saved After the
Entry Method Device Restarts
(Configurations are
saved.)
Static MAC address Manually configured None Yes

entry
Dynamic MAC Manually configured A specified No

address entry by a user or learned value
by the device
Blackhole MAC Manually configured None Yes

address entry
The following rules apply:

l If a dynamic MAC address is used, it can be changed to a static or blackhole one, and the
VLAN ID in the entry is changed to a newly specified value.
l If a static or blackhole MAC address is used, a message indicating that the MAC address
already exists is displayed, and the entry is not changed.

Process for Learning MAC Address Entries

If a port (for example, port A) receives a data frame, a FW analyzes the source MAC address
of the data frame and allows the data frames with the MAC address as the destination to be
forwarded through port A.
l If the MAC address table contains this entry, the FW updates the related entry.
l If the MAC address table does not contain this entry, the FW adds the new MAC address
and port A mapped to the MAC address as a new entry to the MAC address table.
Figure 4-72 shows how the FW learns MAC addresses. In the MAC address table on the FW,
MAC A and MAC B map to port 1, and MAC C and MAC D map to port 2. A data frame
whose destination MAC address is MAC C, and source MAC address is MAC A is to travels
from port 1 to port 2 on the FW.
The process is as follows:
1. When the data frame arrives at the FW, the FW analyzes the source MAC address in the
data frame and searches for the matching address in the MAC address table.
2. As the MAC address entry already exists in the MAC address table, the FW updates the
entry.
3. The FW then checks the destination MAC address of the data frame.
4. As the destination address entry also already exists in the MAC address table and maps
to port 2, the FW forwards the data frame through port 2.
Figure 4-72 Process for learning MAC address entries
MAC Address Port

MAC A 1
MAC B 1
MAC C 2
MAC D 2
MAC A MAC C
MAC B MAC D
Port 1 Port 2
NGFW
When forwarding packets, the FW takes the following measures based on the mapping
between the destination MAC address in the received packet and the entry in the MAC
address table:

l If a mapping entry exists, the FW directly forwards the packet through the corresponding
port.
l If no mapping entry exists, the FW forwards the packet in broadcast mode.
After the broadcast packet is sent, the following situations may occur:
– The packet reaches the device with the destination MAC address. The destination
device replies to the broadcast packet, and the MAC address of the destination
device is included in the reply packet (namely, the source MAC address of the reply
packet).
After receiving the reply packet, the FW learns the source MAC address of the
reply packet and adds the MAC address to the MAC address table.
Therefore, packets with the source MAC address of the reply packet as the
destination MAC address are directly forwarded based on the entry.
– The packet cannot reach the device with the destination MAC address, the FW
broadcasts the packet.
4.9.2 Configuring a MAC Address Table

This section describes how to configure a static MAC address entry and the aging time of
dynamically learned MAC address entries.
4.9.2.1 Configuring the MAC Address Table Based on the VLAN and Layer 2
Interface
If user networks are connected through Layer 2 devices and do not forward data through
Layer 3 routing, you can configure a MAC address table based on Layer 2 interfaces and
VLANs for data forwarding. Thus, user networks can communicate with each other.
Context
To enhance the security of an interface and to prevent the invalid users from accessing the
interface, the network administrator can manually configure static MAC address entries and
bind MAC addresses to the interface, or discard the packets with specified destination MAC
addresses. The interface to which the MAC addresses are bound must be a Layer 2 interface,
and must be added to a specified VLAN, or the interface allows the packets with specified
VLAN IDs to pass through.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mac-address static mac-address interface-type interface-number vlan vlan-id [ ce-
vlan ce-vlan ]
MAC address entries are added.
You can add only unicast MAC addresses rather than multicast MAC addresses and special
MAC addresses to a MAC address table. Special MAC addresses are reserved for special
usage, such as MAC addresses of special packets.

The interface type can be physical interface such as Ethernet interface and GE interface, or
logical interface such as Eth-Trunk interface and MAC-Tunnel. The interface specified in the
this command must be an outbound interface for Layer 2 forwarding.
The vlan-id must be associated with ports. That is, the VLAN contains the port. Alternatively,
this interface allows the VLAN to pass through.
a maximum of 2048 non-dynamic entries can be added.
Step 3 Run:
mac-address blackhole mac-address vlan vlan-id
The blackhole MAC address entry is configured.
a maximum of 2048 non-dynamic entries can be added.
----End
4.9.2.2 Configuring the Aging Time of a MAC Address Table

After the network topology changes, dynamic MAC address entries are not automatically
updated in time. As a result, a device cannot learn new MAC addresses and thus user traffic
cannot be normally forwarded. To addresses this problem, you need to configure the aging
time of MAC address entries.
Context
After the aging time of MAC address entries is configured, the dynamic MAC address entries
are automatically deleted if the aging time expires.
Procedure
Step 1 Run:
system-view
Step 2 Run:
mac-address aging-time seconds [ vlan { vlan-id1 [ to vlan-id2 ] } &<1-10> ]
The aging time of a MAC address table is set.
In a MAC address table, only dynamic entries age.
the value can be zero or an integer ranging 10 to 1,000,000, in second. The default value is
300.
The aging time 0 means that no MAC address entry is aged.
----End
4.9.2.3 Configuring a Limit Rule for Learning MAC Addresses

You can configure a limit rule for learning dynamic MAC addresses.

Context
A limit rule for learning dynamic MAC addresses is applicable to insecure networks with
fixed access users, such as cell access network or intranet that lacks security management.
When the number of access users reaches the upper limit, the MAC addresses of new users
cannot be learned, and the packets of the new users are discarded.
NOTICE
Before configuring a limit rule for learning dynamic MAC addresses, if learned MAC
addresses exist on the port, run the undo mac-address dynamic command in the system view
to clear the MAC addresses. If this command is not run, the limit rule cannot function
properly.
Procedure
system-view
Step 2 Access the Ethernet interface view.


portswitch
Step 4 Configure a limit rule for learning MAC addresses.

mac-limit { maximum max | action { discard | forward } } *
NOTE
LPUF-21 and LPUF-40-A do not support to configure this function.
----End
4.9.3 Maintaining the MAC Address Table

After configuring the MAC address table, you can run the display commands to view the
configuration.
You can run the commands listed in Table 4-54 in any view to display the configurations of
the MAC address table.

Table 4-54 Displaying the MAC address table configuration

Action Command
Display information about MAC display mac-address mac-address [ vlan vlan-id ]

address entries. [ count ]
display mac-address blackhole [ vlan vlan-id ]
display mac-address static [ interface-type
interface-number | vlan vlan-id ] *
display mac-address dynamic [ interface-type
interface-number ] [ [ slot-id ] [ interface-type
interface-number | vlan vlan-id ] * | source-slot
source-slot-id ]
Display the aging time the MAC display mac-address aging-time

address entries.
Display the limit rules for learning display mac-limit [ interface-type interface-
MAC addresses. number ]

This section lists networking requirements, configuration roadmap, and data preparation to
describe the typical application scenarios of MAC address tables, and provides related
configuration files.
4.9.4.1 Example for Configuring the MAC Address Table Based on the Interface
and VLAN
In this networking, the network administrator binds MAC addresses of user devices to the
access interface, which can prevent invalid users from accessing the network through other
switching devices.
A device learns source MAC addresses and then creates a MAC address table. MAC address
learning, however, cannot identify whether the packets are from legal users or hackers, which
brings security threats.
To improve interface security, a network administrator can manually add specific MAC
address entries to the MAC address table. The MAC addresses of user devices and interfaces
are then bound to prevent illegal users from obtaining data.
On the network shown in Figure 4-73, static MAC address entries can be configured to be
bound to interfaces, preventing attacks.

Figure 4-73 Networking diagram of configuring the MAC address table based on the
interface and VLAN
FW
GE1/0/1 GE1/0/2
Switch1 Switch2
PC1 PC2 PC3 PC4

VLAN 2 VLAN 2
1. Configure the switch, and plan the VLAN where the users reside.
2. Configure interface attributes, and associate each interface with the VLAN on the FW.
3. Configure static MAC address entries on the FW, and bind them to interfaces.
Data Preparation
l User VLAN ID
l MAC address of each CE
In this example, Switch1's MAC address is 0011-2233-44aa, and Switch2's MAC
address is 0011-2233-44bb.
Procedure
Step 1 Configure the switch, and plan the VLAN where the users reside.
For details on switch configuration, refer to related product manuals.
Step 2 Configure interface attributes and associate the interface to the VLAN.
# Create VLAN 2.
<FW> system-view
[FW] vlan 2
[FW-vlan2] quit
# Configure the GigabitEthernet 1/0/1



[FW-GigabitEthernet1/0/1] port trunk allow-pass vlan 2
# Configure the GigabitEthernet 1/0/2

[FW-GigabitEthernet1/0/2] port trunk allow-pass vlan 2
Step 3 Configure static MAC address entries.

[FW] mac-address static 0011-2233-44aa gigabitethernet 1/0/1 vlan 2
[FW] mac-address static 0011-2233-44bb gigabitethernet 1/0/2 vlan 2
# After completing the preceding configurations, run the display mac-address static
command on the PE. The configured static MAC address entries are displayed.
[FW] display mac-address static
MAC address table of slot 1:
-------------------------------------------------------------------------------
MAC Address VLAN/ PEVLAN CEVLAN Port Type LSP/LSR-ID
VSI/SI MAC-Tunnel
-------------------------------------------------------------------------------
0011-2233-44aa 2 - - GE1/0/1 static -
0011-2233-44bb 2 - - GE1/0/2 static -
-------------------------------------------------------------------------------
Total matching items on slot 1 displayed = 2
----End
Configuration Files
Configuration file of FW
#
sysname FW
#
vlan batch 2
#
portswitch
undo shutdown
port trunk allow-pass vlan 2
#
portswitch
undo shutdown
port trunk allow-pass vlan 2
#
mac-address static 0011-2233-44aa GigabitEthernet1/0/1 vlan 2
mac-address static 0011-2233-44bb GigabitEthernet1/0/2 vlan 2
#
return

This section provides reference information about MAC address table.

This section describes the related specification of MAC address table.
Static MAC Statically configured MAC Supported by all models.

entries are not lost after the
firewall is restarted or
boards are removed and then
inserted.
Black-hole MAC Black-hole MAC entries are Supported by all models.

not lost after the firewall is
restarted or boards are
removed and then inserted.
With a black-hole MAC
entry configured, the
firewall discards the packets
destined to the specified
MAC address.
Dynamic MAC Dynamic MAC entries are Supported by all models.

leaned by the firewall during
forwarding in a broadcast
domain and aged after a
specific period of time.
Number of entries learnt dynamically l USG6000V1: 4096

l USG6000V2: 8192
l USG6000V4: 16384
l USG6000V8: 32786

This section describes the versions and changes in the MAC address table feature.

4.10 ARP
This section describes Address Resolution Protocol (ARP) concepts and how to configure
ARP, as well as provides configuration examples.
4.10.1 Overview
The Address Resolution Protocol (ARP) is at the link layer of the TCP/IP protocol suite. An
Ethernet device must support ARP. ARP dynamically map Layer 3 IP addresses and Layer 2
Medium Access Control (MAC) addresses.
Definition
ARP maps IP addresses to MAC addresses. ARP entries are classified as static and dynamic
ARP entries. In addition, ARP provides extension application functions, such as proxy ARP
and gratuitous ARP.
Objective
Each host or device in a local area network (LAN) has a 32-bit IP address for communicating
with other hosts. IP addresses are independent of hardware addresses. On an Ethernet, a host
or a router transmits Ethernet frames based on 48-bit MAC addresses. A MAC address is also
called a physical or hardware address. It is allocated to an Ethernet interfaces when a device is
produced. In actual networking, MAC and IP addresses must be mapped using an address
resolution mechanism.
ARP supports the following functions:
l Dynamic ARP
ARP dynamically resolves an IP address into an Ethernet MAC address based on ARP
packets. No network administrator interference is required.
l Static ARP
Static ARP establishes a fixed mapping between the IP and MAC addresses, which
cannot be dynamically adjusted on a host or router. Network administrator interference is
required.
l Proxy ARP
Also called routed proxy ARP. If a host is not configured with a default gateway address,
the host can send an ARP Request packet to request the destination host MAC address.
After the device enabled with proxy ARP receives the packet, it sends an ARP Reply
packet containing its own MAC address so that internal hosts on different physical
networks but on the same network segment can communicate.
l Gratuitous ARP
Gratuitous ARP checks existing IP addresses and declares new MAC addresses.
l Authorized ARP
Authorized ARP, valid on only devices enabled with the DHCP server function, applies
when the DHCP server and DHCP client reside on the same network segment to prevent
attackers from forging the IP addresses or MAC addresses of legitimate DHCP clients to
launch attacks.

4.10.2 Mechanism
This section describes the mechanism of the Address Resolution Protocol (ARP).
Address Resolution Process

ARP was developed for the Ethernet network that supports broadcast functions. A host can
use ARP to obtain the MAC address of a destination host on the same physical network
though the host only obtains the IP address of the destination host. The mapping between IP
and MAC addresses are dynamically updated. The dynamic mapping update allows IP
addresses to be translated into MAC addresses even if hosts change, for example, when the
number of hosts is changed or a network interface card (NIC) is replaced.
The address resolution process is as follows:
1. ARP request
Host A shown in Figure 4-74 knows only the IP address of host B. Host A broadcasts an
ARP request packet to request the MAC address of host B.
Figure 4-74 ARP request
Ethernet
ARP Request
Host A Host B
2. ARP reply
All hosts on the network, including host B, receive the ARP request packet. Only host B
responds to the ARP request packet. Host B shown in Figure 4-75 sends an ARP reply
packet carrying a local MAC address to host A.
Host A obtains host B's MAC address and uses this MAC address to communicate with
host B.

Figure 4-75 ARP reply
Ethernet
ARP Reply
Host A Host B
ARP Aging Mechanism

l ARP cache
Host A broadcasts an ARP Request packet before sending a packet to host B each time,
which causes traffic to increase. All hosts have to receive and process the ARP Request
packets, which decreases network efficiency.
To solve the preceding problems, each host maintains an ARP cache. This cache
maintains recently created mappings between IP and MAC addresses.
Before sending a packet, a sender searches the cache for a MAC address mapped to the
destination IP address. If the sender finds a matched MAC address, the sender directly
sends the packet to a host with the MAC address, without sending an ARP Request
packet. If the sender does not find a matching MAC address, the sender broadcasts an
ARP Request packet.
l Aging time of dynamic ARP entries
After host A shown in Figure 4-75 obtains host B's MAC address from an ARP Reply
packet sent by host B, host A generates a mapping entry between the IP and MAC
addresses of host B in the ARP cache. If host B fails or its NIC is replaced, host A fails
to update the mapping entry and keeps sending packets to host B.
A timer can be set to allow host A to delete cached ARP entries after the timer expires.
Using the timer helps only reduce address resolution errors because the sender can detect
a fault and delete invalid ARP entries only after the timer expires.
l Probes for aging dynamic ARP entries
A specified upper limit of probes can be set on a device to reduce errors that occur
during address resolution. If the device receives no response after the number of times
probes can be set on a device reaches the upper limit, the device deletes an ARP entry.
Static ARP
Static ARP supports the fixed mappings between IP and MAC addresses. Hosts and routers
involved cannot change mappings dynamically. Static ARP is configured manually by
network administrators.
Static ARP entries are used in the following situations:

l A gateway on a local network segment is used to forward packets with destination

addresses on other network segments.
l Packets with invalid IP addresses can be filtered out by binding these IP addresses to a
nonexistent MAC address.
l IP addresses are bound to MAC addresses to defend against attacks, such as ARP flood
attacks.
Static ARP entries have a higher priority than dynamic ARP entries. When you configure a
static ARP entry for an IP address that maps to a dynamic ARP entry in the ARP table, the
static ARP entry replaces the dynamic ARP entry.
Dynamic ARP
Dynamic ARP dynamically and automatically resolves IP addresses into Ethernet MAC
addresses. Dynamic ARP does not require the involvement of an administrator.
A FW creates or updates an ARP entry if a received ARP packet satisfies any of the following
conditions:
l The ARP packet carries a non-broadcast source address that is on the same network
segment as the inbound interface address. The ARP packet is bound for the IP address of
the inbound interface.
l The ARP packet carries a non-broadcast source address that is on the same network
segment as the inbound interface address. The ARP packet is bound for the virtual IP
address of a Virtual Router Redundancy Protocol (VRRP) backup group created on the
inbound interface.
l The ARP packet is bound for an address in a Network Address Translation (NAT)
address pool configured on the inbound interface.
If the source IP address of the received ARP packet maps to an ARP entry of the inbound
interface, the FW also updates the ARP entry.
Proxy ARP
A gateway runs proxy ARP to enable hosts to communicate with each other when the hosts
are on the same network segment but different physical networks.
Proxy ARP has the following characteristics:
l A proxy ARP-enabled subnet gateway processes all ARP packets, except for hosts
connected to the gateway.
l Proxy ARP enables hosts to communicate with each other over a single IP network,
regardless of physical subnets.
l Proxy ARP updates cached ARP entries only on hosts, but does not update entries in the
ARP cache and routing table on a gateway.
l The aging time of ARP entries must be reduced on hosts connected to a proxy ARP-
enabled gateway. This approach speeds up the aging of invalid ARP entries and
minimizes the number of packets that the gateway receives but fails to forward because
of invalid ARP entries.
The device supports routed proxy ARP. Routed proxy ARP enables communication between
PCs or routers on the same network segment but different physical networks. If a host
connected to a router is not configured with a default gateway address, the host cannot
forward data packets.

Routed proxy ARP was introduced to solve this problem. The host sends an ARP Request
packet requesting the MAC address of a destination host. After receiving the request, the
proxy ARP-enabled router replies with its own MAC address to the host. The host sends
packets to the router, and the router forwards the packets to the specific destination.
Gratuitous ARP
Gratuitous ARP enables a device to send an ARP Request packet to its own IP address.
Gratuitous ARP provides the following functions:
l IP address conflicts: If a device receives no reply to a gratuitous ARP request packet, the
device has a unique IP address. If the device receives an ARP reply packet in response to
a gratuitous ARP request packet, there is an IP address conflict.
l New MAC address advertising: If a device has its NIC replaced and its MAC address is
changed, the device sends a gratuitous ARP to notify all hosts of the MAC address
update before the ARP entry aging time elapses.
Authorized ARP
Authorized ARP allows a DHCP server to automatically add an ARP entry that contains the
MAC and IP addresses of the client after assigning an IP address to the client.
l Authorized ARP entries
Authorized ARP entries do not age. After a DHCP server logs out DHCP clients, the
DHCP server automatically deletes their authorized ARP entries from an ARP table.
Authorized ARP entries have higher priorities than dynamic ARP entries, but lower than
static ARP entries. A new authorized ARP entry overrides a duplicate dynamic ARP
entry, but not a duplicate static ARP entry. The authorized ARP entry can be overridden
by a duplicate static ARP entry.
l Working mechanism
Authorized ARP combines the ARP and DHCP working mechanisms. The authorized
ARP function is only available on devices with the DHCP server function enabled when
the DHCP server and client reside on the same network segment. Authorized ARP is not
applicable to DHCP relay scenarios.
The authorized ARP mechanism is as follows:
a. A DHCP client broadcasts a DHCPDISCOVER message. After receiving this
message, a DHCP server replies with a DHCPOFFER message carrying network
parameters, including an IP address.
b. If many DHCP servers send DHCPOFFER messages to the client at the same time,
the client accepts the first DHCPOFFER message. The client then broadcasts a
DHCPREQUEST message to all DHCP servers. The DHCPREQUEST message
contains the MAC address of the DHCP client and IP address request.
c. After the selected DHCP server receives the DHCPREQUEST message, the DHCP
server sends a DHCPACK message to the client. The message contains network
parameters, including the assigned IP address. Meanwhile, the DHCP server
automatically adds an authorized ARP entry that contains the IP and MAC
addresses of the DHCP client.
d. The DHCP server uses the authorized ARP entry to prevent DHCP clients from
dynamically learning MAC addresses in invalid ARP responses. An attacker forges
the IP or MAC address of a valid DHCP client to originate an ARP request. Upon
receipt, the DHCP server (gateway) finds that the IP or MAC address in the request

does not match an authorized ARP entry and sends no response. The attacker,
therefore, cannot access the network, which improves network security. The address
of the DHCP server is the same as the gateway address when the DHCP server and
client reside on the network segment.
4.10.3 Configuring ARP

This section describes the procedures for configuring ARP.
4.10.3.1 Configuring Static ARP

Static ARP entries record the fixed mapping between IP and MAC addresses. They are
configured manually.
Prerequisites
Before configuring ARP, complete the following tasks:
l Configuring the link layer protocol parameters for the interface and ensuring that the
status of the link layer protocol on the interface is Up
l Configuring the network layer protocol for the interface
Context
A static ARP entry is manually added. It does not age and cannot be overwritten by a dynamic
ARP entry. Static ARP entries are valid provided that the device works properly.
Static ARP entries improve communication security. Static ARP entries ensure
communication between a local device and a specified device using the specified MAC
address. Attack packets cannot modify the mapping between IP and MAC addresses in static
ARP entries.
Static ARP is used in the following situations:
l For the packets whose destination IP address is on another network segment, static ARP
can help these packets traverse a gateway of the local network segment so that the
gateway can forward the packets to their destination.
l When you need to filter out some packets with illegitimate destination IP addresses,
static ARP can bind these illegitimate addresses to a nonexistent MAC address.
If static ARP and the Virtual Router Redundancy Protocol (VRRP) are enabled on a device
simultaneously, the virtual IP address of the VRRP backup group configured on the VLANIF
interface cannot be the IP address contained in the static ARP entries; otherwise, incorrect
host routes are generated and packets cannot be normally forwarded.
NOTE
Static ARP entries keep valid when a device works normally.
Configuring Common Static ARP Entries

Step 1 Run:
system-view

Step 2 Run:
arp static ip-address mac-address
Configure common static ARP entries.
----End
Configuring Static ARP Entries in a VLAN

Step 1 Run:
system-view

Step 2 Configure static ARP entries in a Virtual Local Area Network (VLAN).
To configure static ARP entries in a VLAN, do as follows:
l Run the arp static ip-address mac-address [ vid vlan-id interface interface-type
interface-number ] command.
It is required to set parameters vid vlan-id and interface interface-type interface-number
when you configure static ARP entries in the VLAN.
If the interface corresponding to the VLAN is bound to a Virtual Private Network
(VPN), the device can automatically associate the configured static ARP entry with the
VPN. This command is applicable to port-based VLANs.
l Run the arp static ip-address mac-address [ vpn-instance vpn-instance-name ] vid
vlan-id command.
This command is applicable to the sub-interface that supports VLAN and can be bound
to the VPN.
----End
Configuring Static ARP Entries in a VPN Instance

Step 1 Run:
system-view

Step 2 Run:
arp static ip-address mac-address vpn-instance vpn-instance-name
Configure static ARP entries in a VPN instance.
----End
Checking the Configurations

l Run the display arp slot slot-id [ network net-number [ net-mask | mask-length ] ]
[ dynamic | static ] command to check information about ARP mapping tables based on
slots.
l Run the display arp vlan vlan-id interface interface-type interface-number command to
check information about ARP mapping tables based on VLANs.
l Run the display arp vpn-instance vpn-instance-name slot slot-id [ dynamic | static ]
command to check information about ARP mapping tables based on VPN instances.

l Run the display arp statistics { all | interface interface-type interface-number | slot
slot-id } command to check the statistics for ARP entries.
----End
4.10.3.2 Enabling a Device to Learn Multicast MAC Addresses and Generate ARP
Entries
If a device is enabled to learn multicast MAC addresses, it can generate ARP entries after
receiving ARP packets carrying multicast MAC addresses as source MAC addresses. This
section describes how to enable a device to learn multicast MAC addresses and generate ARP
entries.
Prerequisites
Before enabling a device to learn multicast MAC addresses, complete the following tasks:
l Connect interfaces and set their physical parameters to ensure that the physical interface
status is Up.
l Configure link layer protocol parameters for interfaces to ensure that the link layer
protocol on the interfaces is Up.
Context
A MAC address corresponding to an IP address may be a multicast MAC address. In this
case, a network administrator has to configure a static ARP entry. A device can generate
dynamic ARP entries if enabled to learn multicast MAC addresses. This way reduces a
network administrator's workload of configuring static ARP entries and reduces network
operation and maintenance costs.
Procedure
l Globally enable a device to learn multicast MAC addresses and generate dynamic ARP
entries.
a. Run:
system-view

b. Run:
arp learning multicast enable
The device is globally enabled to learn multicast MAC addresses.
By default, a device is globally disabled from learning multicast MAC addresses.
NOTE
If a device is globally enabled to learn multicast MAC addresses, the interfaces of this
device are enabled to learn multicast MAC addresses.
l Enable an interface to learn multicast MAC addresses.
a. Run:
system-view

b. Run:

c. Run:
The interface is enabled to learn multicast MAC addresses.
By default, if a device is globally enabled to learn multicast MAC addresses, all the
device interfaces are enabled to learn multicast MAC addresses. If a device is
globally disabled from learning multicast MAC addresses, all the device interfaces
are disabled from learning multicast MAC addresses.
NOTE
If the undo arp learning multicast enable command is run on a specific interface, the
interface is disabled from learning multicast MAC addresses but uses the global
configuration in the configuration file.
l Disable an interface from learning multicast MAC addresses after a device has been
globally enabled to learn multicast MAC addresses. The interface does not use the global
configuration.
a. Run:
system-view

b. Run:

c. Run:
arp learning multicast disable
The interface is disabled from learning multicast MAC addresses.
----End

Run the display arp all command to check the dynamic ARP entries corresponding to the
multicast MAC addresses.
<sysname> display arp all
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN/CEVLAN
PVC
------------------------------------------------------------------------------
192.168.1.1 0002-0002-0002 I - Vlanif100
192.168.2.2 0100-5e11-0302 20 D-0 Eth-Trunk2
10/-
192.168.3.3 0100-5e11-0302 20 D-0 Eth-Trunk2
20/-
192.168.4.4 0100-5e11-0302 20 D-0 Eth-Trunk2
30/-
------------------------------------------------------------------------------
Total:4 Dynamic:3 Static:0 Interface:1

4.10.3.3 Optimizing Dynamic ARP

Dynamic ARP is enabled without the need to be enabled. To optimize this function, you can
modify some dynamic ARP parameters.
Context
If the device needs to update ARP entries frequently, reduce the aging timeout period of ARP
entries and increase the aging detection frequency.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
arp expire-time expire-times
The timeout period for aging dynamic ARP entries is set.

By default, the aging timeout period is 1200 seconds.
Step 4 Run:
arp detect-times detect-times
The maximum number of ARP probe packets to be sent is set.

The default value is 3.
Each time the aging time of a dynamic ARP entry elapses, the device sends an ARP probe
packet to the peer device. If the device does not receive an ARP Reply packet from the peer
device after sending a maximum number of probe packets, it deletes the ARP entry.
For example, the aging time of dynamic ARP entries is 60s, and the maximum number of
ARP probe packets to be sent is 6. After 60s since an ARP entry is generated, the device
sends an ARP probe packet every 5s. If the device does not receive any response after sending
six ARP probe packets, it deletes the ARP entry. Therefore, the actual aging time of the ARP
entry is 90s (60 + 6 x 5).
If the number of aging detection times is set to 0, the device deletes dynamic ARP entries
immediately when the entries age.
Step 5 Run:
arp detect-mode unicast
The interface to send an ARP aging detection packet in unicast mode is set.
By default, an interface sends the last ARP aging detection packet in broadcast mode, and the
rest ARP aging detection packets are sent in unicast mode.
Step 6 Run:

The multicast MAC address learning is enabled.

If the multicast MAC address learning function is disabled, the FW can learn only unicast
MAC addresses from ARP packets.
----End
Follow-up Procedure
Run the display arp interface command to view all ARP entries on an interface.
<sysname> display arp interface GigabitEthernet 1/0/2
VLAN/CEVLAN PVC
------------------------------------------------------------------------
192.168.1.11 0000-0a41-0201 I GE1/0/2
192.168.1.1 0000-0a41-0200 15 D GE1/0/2
-------------------------------------------------------------------------
If the TYPE field is I in an ARP entry, the entry contains the mapping between the local IP
and MAC addresses of the interface. If the EXPIRE (M) field is null, the entry does not age.
If the TYPE field is D, the entry is dynamically learned and ages in 15 minutes.
4.10.3.4 Configuring a Device to Delete Dynamic ARP Entries after a Delay

By default, a device deletes dynamic ARP entries immediately after a VLAN interface goes
Down. If you configure a device to delete dynamic ARP entries after a delay, it sends ARP
detection packets and then deletes or updates ARP entries based on whether it receives ARP
reply packets within the ARP aging time.
Prerequisites
Before configuring delayed deletion of dynamic ARP entries, create a VLANIF interface.
Context
When a VLANIF interface serves as a gateway, the network planners usually deploy a ring or
dual-homing network to improve network reliability. If a faulty link causes an interface in a
VLAN to go Down, the device immediately deletes dynamic ARP entries learned by the
interface and updates and relearns ARP entries through newly sent user traffic. However, if
many users are connected to the gateway, user traffic may be interrupted for a long time due
to the affected performance in relearning ARP entries.
To minimize the service interruption time and accelerate user traffic convergence, network
administrators can enable the device to delete dynamic ARP entries after a delay if an
interface in a VLAN goes Down. After this function is enabled, the device does not
immediately delete dynamic ARP entries learned by the interface after it goes Down. Instead,
it sends ARP detection packets and then deletes or updates ARP entries depending on whether
it receives ARP reply packets within the ARP aging time.
Procedure
Step 1 Run:
system-view

Step 2 Run:
A VLANIF interface is created and the VLANIF interface view is entered.
Step 3 Run:
arp purge slowly
Delayed deletion of dynamic ARP entries is configured.
NOTE
To update ARP entries, a better alternative to ARP aging mechanism is associating MAC entries with
ARP entries, because the device learns MAC entries faster. Therefore, to accelerate user traffic
convergence, you are advised to enable ARP entry delayed deletion and associate MAC entries with
ARP entries.
----End
Follow-up Procedure
Run the display this command to check the configurations for delayed deletion of dynamic
ARP entries on a specified VLANIF interface.
[sysname-Vlanif1] display this
#
interface Vlanif233
arp purge slowly
ip address 10.1.1.1 255.255.255.0
#
4.10.3.5 Configuring ARP Automatic Scanning and Fixed ARP

ARP automatic scanning and fixed ARP enable a device to generate dynamic ARP entries and
convert the dynamic ARP entries to static ARP entries.
Prerequisites
Before configuring ARP automatic scanning and fixed ARP, create a VLANIF interface.
Context
To improve communication security, network administrators generally configure static ARP
entries on a small-sized LAN. However, if a gateway has multiple users attached, a network
administrator has to configure static ARP entries for each user. Current networks use dynamic
ARP for communication.
Dynamic ARP helps reduce a network administrator's workload but has its own limitations.
Dynamic ARP entries can be overwritten by subsequent ARP entries and are vulnerable to
network attacks. Therefore, dynamic ARP cannot provide reliability for network
communications.
ARP automatic scanning is generally used with fixed ARP to defend against network attacks:
l After ARP automatic scanning is configured, a device automatically scans all its
neighbor devices on a LAN. The device sends ARP request packets to its neighbor
devices, obtains the MAC addresses of its neighbor devices, and generates dynamic ARP
entries.

l After fixed ARP is configured, the device converts these dynamic ARP entries to static
ARP entries.
Procedure
Step 1 Run:
system-view
Step 2 Run:
NOTE
Before you configure ARP automatic scanning and fixed ARP, run the display arp all command to
check all ARP entries of the device. This allows you to compare the number and types of ARP entries
before and after ARP automatic scanning and fixed ARP are configured.
VLAN/CEVLAN
------------------------------------------------------------------------------
192.168.50.207 781d-ba56-355e I - GE0/0/0
192.168.56.2 781d-ba56-355e I - Vlanif2
1.1.1.1 781d-ba56-355e I - Vlanif30
------------------------------------------------------------------------------
Total:3 Dynamic:0 Static:0 Interface:3 Remote:0
Step 3 Run:
arp scan [ start-ip-address to end-ip-address ]
ARP automatic scanning is configured.
NOTE
After you configure ARP automatic scanning and before you configure fixed ARP, run the display arp
all command to check all ARP entries of the device. If only the number of ARP entries increases, the
ARP automatic scanning configuration takes effect.
VLAN/CEVLAN
------------------------------------------------------------------------------
192.168.50.207 781d-ba56-355e I - GE0/0/0
192.168.56.2 781d-ba56-355e I - Vlanif2
1.1.1.1 781d-ba56-355e I - Vlanif30
1.1.1.2 000b-09f7-4869 D-1 GE1/0/4
30/-
1.1.1.3 000b-09f7-4868 D-1 GE1/0/2
30/-
------------------------------------------------------------------------------
Step 4 Run:
arp fixup
Fixed ARP is configured.
----End

Follow-up Procedure
After the configuration is complete, run the display arp all command to check the
configurations of ARP automatic scanning and fixed ARP and compare the number and types
of ARP entries before and after ARP automatic scanning and fixed ARP are configured.
VLAN/CEVLAN
------------------------------------------------------------------------------
192.168.50.207 781d-ba56-355e I - GE0/0/0
192.168.56.2 781d-ba56-355e I - Vlanif2
1.1.1.1 781d-ba56-355e I - Vlanif30
1.1.1.2 000b-09f7-4869 S-- GE1/0/4
30/-
1.1.1.3 000b-09f7-4868 S-- GE1/0/2
30/-
------------------------------------------------------------------------------
4.10.3.6 Configuring the ARP Proxy

Proxy ARP implements communication between devices on the same network segment but on
different physical networks.
4.10.3.6.1 Configuring Routed Proxy ARP
Prerequisites
Before configuring routed proxy ARP, complete the following tasks:
l Configuring the physical parameters for the interface and ensuring that the status of the
physical layer of the interface is Up
l Configuring the link layer parameters for the interface and ensuring that the status of the
link layer protocol on the interface is Up
Context
The two physical networks of an enterprise are in different subnets of the same IP network,
and are separated by a device. You need to enable the proxy ARP on the device interface
connected to the physical networks. This enables communication between the two networks.
Network IDs of subnet hosts must be the same. You do not need to configure default gateways
for hosts.
Procedure
Step 1 Run:
system-view
Step 2 Run:

The interfaces supporting routed proxy ARP include Ethernet interfaces, Ethernet sub-
interfaces, GE interfaces, GE sub-interfaces, Eth-Trunk interfaces, Eth-Trunk sub-interfaces,
and VLANIF interfaces.
Step 3 Run:
The interface is configured with an IP address.

The IP address configured for the interface must be in the same network segment with that of
hosts in the LAN connected to this interface.
Step 4 Run:
arp-proxy enable
The routed proxy ARP function on an interface is enabled.

By default, the routed proxy ARP function is disabled on the interface.
After routed proxy ARP is enabled, you must reduce the aging time of ARP entries in the
device so that the number of packets received but cannot be forwarded by the device is
decreased. To configure the aging time of ARP entries.
----End
4.10.3.6.2 Configuring Proxy ARP Within a VLAN

By configuring proxy ARP on a VLAN, you can interconnect isolated hosts on a VLAN.
Prerequisites
Before configuring proxy ARP within a VLAN, complete the following tasks:
l Configuring the VLAN
l Configuring user isolation in the VLAN
Context
If two users are in the same VLAN but they are isolated from each other, to ensure the two
users can communicate, you need to enable proxy ARP within the VLAN on the interface
associated with the VLAN.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The vlanif interface view is displayed.

Step 3 Run:
The interface is configured with an IP address.

Step 4 Run:
arp-proxy inner-sub-vlan-proxy enable
Proxy ARP within a VLAN is enabled.
----End
4.10.3.7 Configuring Gratuitous ARP

A gratuitous ARP packet is a special ARP packet whose sender and destination IP addresses
are both the local IP addresses, the sender MAC address is the MAC address of the local
MAC address, and destination MAC address is the broadcast address. Configuring gratuitous
ARP enables a device to proactively learn and send gratuitous ARP packets.
4.10.3.7.1 Configuring the Learning of Gratuitous ARP Packets

After the learning of gratuitous ARP packets is configured, a device adds the source IP
address and source MAC address carried in gratuitous ARP packets to the dynamic ARP
mapping table when no ARP entry matches the source IP address in ARP packets.
Prerequisites
Before configuring gratuitous ARP, set the IP address of the interface enabled with gratuitous
ARP. For details on how to set the IP address, see 4.1.1 Overview.
Context
If an ARP entry matches the source IP address of ARP packets, the device updates this
dynamic ARP entry, regardless of the learning of gratuitous ARP packets.
Procedure
system-view

Step 3 Enable the device to learn gratuitous ARP packets.

gratuitous-arp learn enable
By default, this function is enabled on the interface.
----End
4.10.3.7.2 Configuring the Sending of Gratuitous ARP Packets

After the sending of gratuitous ARP packets is configured, the device can send user packets to
the correct gateway and prevent malicious attackers from obtaining these packets.
Prerequisites
Before configuring gratuitous ARP, set the IP address of the interface enabled with gratuitous
ARP. For details on how to set the IP address, see 4.1.1 Overview.

Context
A device functions as a gateway to send gratuitous ARP packets (using the IP address of the
gateway as the destination IP address) to update the gateway MAC address of valid ARP
entries, which ensures that packets are forwarded to the gateway and prevents malicious
obtaining by attackers.
Procedure
system-view

Step 3 Enable the interface to periodically send gratuitous ARP packets.

gratuitous-arp send enable [ interval interval ]
By default, this function is disabled.
After this function is enabled, the device sends gratuitous ARP packets every 60 seconds by
default. To customize the interval, set interval.
----End
4.10.3.8 Preventing Attacks on ARP Entries

Measures for preventing ARP entry attacks are strict ARP entry learning, ARP entry
restriction, and enabling alarm functions for potential attack behaviors.
4.10.3.8.1 Configuring Global Strict ARP Entry Learning

By configuring strict ARP entry learning in the system view, a device learns only address
information carried in the ARP Reply packets corresponding to the ARP Request packets sent
by the device. The device does not learn address information carried in the ARP Request
packets sent from other devices. Strict ARP entry ensures the security of the device.
Context
Perform the following steps on the FW that needs to be configured with ARP security
features:
Procedure
Step 1 Run:
system-view
The system view is displayed
Step 2 Run:
arp learning strict
Strict ARP learning is configured.
By default, strict ARP learning is disabled.

After the arp learning strict command is run, the FW learns only reply packets for the ARP
request packets sent itself.
----End
4.10.3.8.2 Configuring Strict ARP Entry Learning on Interfaces

By configuring strict ARP entry learning in the interface view, a device learns only address
information carried in the ARP Reply packets corresponding to the ARP Request packets sent
by the device. The device does not learn address information carried in the ARP Request
packets sent from other devices. Strict ARP entry ensures the security of the device.
Context
Perform the following steps on the FW whose ARP entries are to be prevented from being
attacked:
Procedure
Step 1 Run:
system-view
The system view is displayed

Step 2 Run:

FW supports strict ARP entry learning on the following interfaces:
l Ethernet interfaces and their sub-interfaces
l Eth-trunk interfaces and their sub-interfaces
l VLANIF interfaces
Step 3 Run:
arp learning strict { force-enable | force-disable | trust }
Strict ARP entry learning is configured on the interface.
NOTE
l If the key word force-enable of the command is selected, the FW learns only reply packets for the
ARP request packets sent itself.
l If the key word force-disable of the command is selected, the strict ARP entry learning function on
the interface is disabled.
l If the key word trust of the command is selected, the strict ARP entry learning function on the
interface is disabled and the global ARP entry learning function is enabled.
Strict ARP entry learning adopts the following longest-match rules:

l If strict ARP entry learning is configured both on the interface and globally, strict ARP
entry learning on the interface is preferred.
l If strict ARP entry learning is not configured on the interface, the global strict ARP entry
learning is enabled.
----End

4.10.3.8.3 Configuring Interface-based ARP Entry Restriction

By configuring interface-based ARP entry restriction, the number of ARP entries that an
interface can learn is restricted, which effectively prevents ARP entry overflow and ensures
ARP entry security.
Context
Perform the following steps on the FW that needs to be configured with ARP security
features:
Procedure
Step 1 Run:
system-view

Step 2 Run:

The following interfaces are supported:
l Layer 3 Ethernet interfaces and sub-interfaces
l Layer 3 GE interfaces and sub-interfaces
l Layer 3 Eth-Trunk interfaces and sub-interfaces
l Layer 2 Ethernet interfaces
l Layer 2 GE interfaces
l VLANIF interfaces
Step 3 Run:
arp-limit[ vlan vlan-id [ to vlan-id2 ] ] maximum maximum
Interface-based ARP entry restriction is configured.
----End
4.10.3.8.4 Enabling Alarm Functions for Potential Attack Behaviors

Through the log and alarms for potential attacks, the administrator can know the operation of
ARP in a real-time manner and make a decision and take effective measures against attacks.
Context
Perform the following steps on the FW that needs to be configured with ARP attack defense:
Procedure
Step 1 Run:
system-view

Step 2 Run:
arp anti-attack log-trap-timer time
The interval for sending ARP alarms is set.
----End
4.10.4 Maintaining ARP

The operations of ARP maintenance include clearing ARP statistics and monitoring ARP
operating status.
4.10.4.1 Displaying ARP Configuration

After configuring ARP, you can run the display commands in any view to view the ARP
configuration.
Table 4-55 lists commands used to display the ARP configuration.
Table 4-55 Displaying the ARP configuration

Action Command
Display information about ARP display arp [ network net-number [ net-mask ] ]

mapping tables. [ dynamic | static ]
Display information about ARP display arp vpn-instance vpn-instance-name { all |

mapping tables based on VPN slot slot-id [ dynamic | static ] }
instances.
Display information about ARP display arp interface interface-type interface-

mapping tables based on number [ vid vlan-id ]
interfaces.
4.10.4.2 Clearing ARP Entries

The mapping between IP and MAC addresses is deleted after you clear ARP entries. As a
result, users may fail to access some devices. Exercise caution when clearing ARP entries.
NOTE
Static ARP entries cannot be restored after being deleted. Exercise caution when you delete static ARP
entries.
Table 4-56 list the commands to clearing ARP entries. You need to perform this action in the
user view.
Table 4-56 Clearing ARP entries

Action Command
Clear ARP entries in the reset arp { all | dynamic ip ip-address [ vpn-instance vpn-
ARP mapping table. instance-name ] | interface interface-type interface-number
[ ip ip-address ] | slot slot-id | static }


This section provides examples for configuring ARP in different networking scenarios.
4.10.5.1 Example for Configuring Static ARP

This section describes how to configure static ARP. Static ARP helps provide communication
security between enterprise departments.
A FW shown in Figure 4-76 connects departments of a company, and each department joins
different VLANs. Hosts in the headquarters office and a file backup server are allocated
manually configured IP addresses. Hosts in departments dynamically obtain IP addresses
using DHCP.
Hosts in the marketing department can access the Internet and are often attacked by ARP
packets. Attackers attack the FW and modify dynamic ARP entries on the FW. As a result,
communication between hosts in the headquarters and external devices is interrupted, and
hosts in departments fail to access the file backup server. The company requires that static
ARP entries be configured on the FW. Static ARP allows hosts in the headquarters to
communicate with external devices and hosts in departments to access the file backup server.
Figure 4-76 Network diagram for configuring static ARP entries

File backup server
10.10.10.1/24
0025-1185-8C21
Trust PC_A
GE1/0/2
10.10.10.10/24 10.10.1.1/24
GE1/0/3 0021-97cf-2238
Marketing GE1/0/4 VLAN10
VLAN20 10.10.1.20/24
Headquarters
department office
GE1/0/5
VLAN30 FW
10.10.2.0/24 10.10.1.0/24
VLAN 20 VLAN 10
R&D
department
10.10.3.0/24
VLAN 30

NOTE
This example describes only ARP-related configurations, but not other configurations, such as DHCP.
1. Configure static ARP entries of hosts in the headquarters on the FW to prevent ARP
attack packets from altering ARP entries, which prevents communication interruptions.
2. Configure static ARP entries of the file backup server on the FW to prevent ARP attack
packets from altering ARP entries, which prevents failures in accessing the file backup
server.
Procedure
Step 1 Configure static ARP entries for the host in the headquarters.
# Create VLAN 10.
<FW> system-view
[FW] vlan 10
[FW-vlan-10] quit
# Add GigabitEthernet 1/0/3 to VLAN 10.

[FW-GigabitEthernet1/0/3] port link-type access
# Configure an IP address for Vlanif 10.

[FW-Vlanif10] ip address 10.10.1.20 255.255.255.0
[FW-Vlanif10] quit
# Configure static ARP entries for hosts in the headquarters. The following example uses the
configuration on PC_A(configuration on other PCs is omitted). In the static ARP entry, PC_A
IP address 10.10.1.1 is mapped to the MAC address 0021-97cf-2238, and the VLAN ID is 10.
[FW] arp static 10.10.1.1 0021-97cf-2238 vid 10
Step 2 Configure a static ARP entry for the file backup server.
# Configure an IP address for GigabitEthernet 1/0/2.
# Configure a static ARP entry for the file backup server to map the IP address 10.10.10.1/24
to the MAC address 0025-1185-8C21.
[FW] arp static 10.10.10.1 0025-1185-8C21
Step 3 Add interfaces to a security zones.

# Assign interfaces to the Trust zone.


----End
1. Run the display arp static command on the FW to view static ARP entries.
[FW] display arp static
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-
INSTANCE
VLAN
------------------------------------------------------------------------------
10.10.10.1 0025-1185-8c21 S--
10.10.1.1 0021-97cf-2238 S--
10
10.10.2.1 0021-97cf-2239 S--
20
10.10.3.1 0021-97cf-2240 S--
30
------------------------------------------------------------------------------
2. Headquarters devices properly communicate with other departments, without

interruptions.
3. All departments can access the file backup server.
#
sysname FW
#
vlan batch 10 20 30
#
interface Vlanif10
ip address 10.10.1.20 255.255.255.0
#
undo shutdown
ip address 10.10.10.10 255.255.255.0
#
portswitch
undo shutdown
port default vlan 10
#
firewall zone trust
set priority 85
#
arp static 10.10.10.1 0025-1185-8C21
arp static 10.10.1.1 0021-97cf-2238 vid 10
arp static 10.10.2.1 0021-97cf-2239 vid 20
arp static 10.10.3.1 0021-97cf-2240 vid 30
#
return
4.10.5.2 Example for Configuring ARP Automatic Scanning and Fixed ARP
This section describes how to configure ARP automatic scanning and fixed ARP. The
configuration enables a device to rapidly generate dynamic ARP entries and convert the

dynamic ARP entries to static ARP entries. This process ensures reliable and secure network
operations.
On a small-sized LAN, a network administrator configures static ARP entries on a gateway to
ensure network communications security. However, once a device MAC address is changed,
the network administrator has to reconfigure a static ARP entry on the gateway, which
increases network operation and maintenance costs.
If the network adapters of HostA, HostB, HostC, and HostD are replaced, the existing static
ARP entries for these devices on the PE become invalid on the network shown in Figure
4-77. To solve this problem and ensure network security, you can configure ARP automatic
scanning and fixed ARP on the PE. The two functions enable the PE to rapidly learn the MAC
address of each host, generate dynamic ARP entries, and convert the dynamic ARP entries to
static ARP entries.
Figure 4-77 Networking for ARP automatic scanning and fixed ARP configurations
PE
VLAN4
VLANIF4
GE1/0/1 GE1/0/2
CE1 CE2 … ... CE100
HostA HostB HostC HostD HostE HostF
1. Configure a VLAN, create a VLANIF interface, and configure an IP address for the
VLANIF interface.
2. Configure ARP automatic scanning on the VLANIF interface.
3. Configure fixed ARP on the VLANIF interface.
Data Preparation
l VLAN ID (4)

l Types and numbers of the interfaces (GE 1/0/1 and GE 1/0/2) that join the VLAN
l IP address (10.1.1.1/24) of the VLANIF interface
l IP addresses of HostA (10.1.1.2/24), HostB (10.1.1.3/24), HostC (10.1.1.4/24), and
HostD (10.1.1.5/24)
Procedure
Step 1 Configure an IP address for each host.
# Assign 10.1.1.2/24 to HostA.
# Assign 10.1.1.3/24 to HostB.
# Assign 10.1.1.4/24 to HostC.
# Assign 10.1.1.5/24 to HostD.
Step 2 Configure a VLAN and create a VLANIF interface.
<FW> system-view
[FW] sysname PE
[PE] interface GigabitEthernet 1/0/1
[PE-GigabitEthernet1/0/1] portswitch
[PE-GigabitEthernet1/0/1] quit
[PE] interface GigabitEthernet 1/0/2
[PE-GigabitEthernet1/0/2] portswitch
[PE-GigabitEthernet1/0/2] quit
[PE] vlan 4
[PE-vlan4] port GigabitEthernet 1/0/1 to 1/0/2
[PE-vlan4] quit
[PE] interface vlanif 4
[PE-Vlanif4] ip address 10.1.1.1 255.255.255.0
[PE-Vlanif4] quit
Run the display arp all command to view the ARP entries on the PE. The ARP entries on the
VLANIF interface are displayed only.
[PE] display arp all
VLAN
------------------------------------------------------------------------------
10.1.1.1 0018-82d4-04c3 I - Vlanif4
------------------------------------------------------------------------------
Step 3 Configure ARP automatic scanning.

[PE-Vlanif4] arp scan 10.1.1.2 to 10.1.1.5
[PE-Vlanif4] quit
Run the display arp all command to view the ARP entries on the PE. The ARP entries of
HostA, HostB, HostC, and HostD are displayed.
VLAN
------------------------------------------------------------------------------
10.1.1.1 1051-724a-e079 I - Vlanif4
10.1.1.2 1051-724a-e07b 20 D-0 GE1/0/1
4/-
10.1.1.3 1051-724a-e07d 20 D-0 GE1/0/1
4/-
10.1.1.4 1051-724a-e081 20 D-0 GE1/0/2
4/-
10.1.1.5 1051-724a-e083 20 D-0 GE1/0/2
4/-
------------------------------------------------------------------------------
Step 4 Configure fixed ARP.


[PE-Vlanif4] arp fixup
[PE-Vlanif4] quit
Run the display arp all command to view the ARP entries on the PE. The dynamic ARP
entries of HostA, HostB, HostC, and HostD have been converted to static ARP entries.
VLAN
------------------------------------------------------------------------------
10.1.1.1 0018-82d4-04c3 I - Vlanif4
10.1.1.2 0018-82d4-04c3 19 S-0 GE1/0/1
4/-
10.1.1.3 00e0-fc93-1015 19 S-0 GE1/0/1
4/-
10.1.1.4 00e0-fc93-1015 19 S-0 GE1/0/2
4/-
10.1.1.5 00e0-fc93-1015 19 S-0 GE1/0/2
4/-
------------------------------------------------------------------------------
----End
Configuration Files
Configuration file of PE
#
sysname PE
#
vlan batch 4
#
interface Vlanif4
ip address 10.1.1.1 255.255.255.0
#
portswitch
undo shutdown
port hybrid pvid vlan 4
undo port hybrid vlan 1
port hybrid untagged vlan 4
#
portswitch
undo shutdown
port hybrid pvid vlan 4
undo port hybrid vlan 1
port hybrid untagged vlan 4
#
4.10.5.3 Example for Configuring Proxy ARP

This section provides an example for configuring proxy ARP. Proxy ARP implements
communication between branches on the same network segment but on different physical
networks.
Branches A and B of a company shown in Figure 4-78 are located in different cities. Multiple
routing devices are deployed between branches, and routes are reachable. IP addresses of the
routing devices are on the same network segment 10.10.0.0/16. Branches A and B belong to
different broadcast domains and cannot communicate on a LAN. Hosts of branches with
default gateway addresses cannot communicate across network segments.

The company requires that branches A and B communicate without changing host
configurations.
Figure 4-78 Proxy ARP
Trust Trust
GE1/0/3 GE1/0/3
Branch A 10.10.1.1/24 10.10.2.1/24 Branch B
FW_A FW_B
Host_A Host_B
10.10.1.2/16 10.10.2.2/16
0021-97cf-2238 0025-1185-8C21
NOTE
This example describes only ARP-related configurations, but not configurations, such as routes between
branches A and B.
1. Enable proxy ARP on the interface of FW_A connected to branch A.
2. Enable proxy ARP on the interface of FW_B connected to branch B.
3. Configure routes to ensure that FW_A and branch B are reachable to each other, and
FW_B and branch A are reachable to reach other.
Procedure
<FW_A> system-view
# Enable proxy ARP.

[FW_A-GigabitEthernet1/0/3] arp-proxy enable


<FW_B> system-view

# Enable proxy ARP.

[FW_B-GigabitEthernet1/0/3] arp-proxy enable

----End
# Select host_A in branch A and select host_B in branch B. Run the ping command on
host_A to ping host_B. The ping is successful.
C:\Documents and Settings\Administrator>ping 10.10.2.2


# View the ARP table of host_A. You can see that the MAC address of host_B is the MAC
address of GigabitEthernet 1/0/3 on FW_A.
C:\Documents and Settings\Administrator>arp -a
Interface: 10.10.1.2 --- 0x3
Internet Address Physical Address Type
10.10.1.1 00-22-a1-01-b5-db dynamic
10.10.2.2 00-22-a1-01-b5-db dynamic
# View the ARP table of host_B. You can see that the MAC address of host_A is the MAC
address of GigabitEthernet 1/0/3 on FW_B.
C:\Documents and Settings\Administrator>arp -a
Interface: 10.10.2.2 --- 0x2

Internet Address Physical Address Type
10.10.1.2 00-e0-fc-00-00-00 dynamic
10.10.2.1 00-e0-fc-00-00-00 dynamic
#
sysname FW_A
#
ip address 10.10.1.1 255.255.255.0
arp-proxy enable
#
firewall zone trust
set priority 85
#
return

Configuration script for for FW_B:

#
sysname FW_B
#
ip address 10.10.2.1 255.255.255.0
arp-proxy enable
#
firewall zone trust
set priority 85
#
return
4.10.6 Troubleshooting ARP Faults

This section describes the procedure for troubleshooting ARP faults.
Symptom
Figure 4-79 shows the typical networking, The connection and configuration of physical links
are correct. The interface is in Up state, but cannot ping the remote device.
Figure 4-79 Typical ARP networking
GE1/0/3
FW Router
Possible Causes
VLAN attributes are incorrect.

Fault Diagnosis
Figure 4-80 Flowchart for troubleshooting ARP faults

The interface is in Up state but the
remote device cannot be pinged
through
Yes
Yes Is it a Vlanif No Check the ARP entries of the
Are remote ARP entries
learned? interface? specified Vlanif interface
No
Run the ping command to

trigger the receiving and Are the ARP
sending of ARP packets and No
entries of the interface
view debugging output correct?
information
Yes
Are the receiving No View the receiving and

and sending of ARP packets sending of ICMP packets
normal?
Yes
Are the statistics on Are the receiving

No No
received and sent packets and sending of ICMP
correct? packets normal?
Record the location
Yes process, displayed Yes
debugging information,
and statistics on the
interface
No Is the fault Yes

Seek technical support End
rectified?
Procedure
Step 1 Run the display arp command and check whether remote ARP entries are learned.
<FW> display arp
VLAN/PVC
------------------------------------------------------------------------------
10.1.196.208 0018-8239-1e63 I GE1/0/3
10.1.196.20 0021-97cf-cfc1 16 D GE1/0/3
10.1.196.4 001e-90a0-154f 16 D GE1/0/3

10.1.196.8 001e-9060-405a 20 D GE1/0/3

10.1.196.216 00e0-fcfc-1010 20 D GE1/0/3
------------------------------------------------------------------------------
Total:5 Dynamic:4 Static:0 Interface:1 Authorized:0
SNMP:0
The IP ADDRESS: IP address. The MAC ADDRESS: MAC address.

The TYPE field displays the following values:
l I: a MAC address of the interface itself.
l D: a dynamic entry obtained using ARP packets
l If remote ARP entries are learned by FW, verify the Vlanif interface configuration and
go to Step 4.
l If remote ARP entries are not learned by FW, go to Step 2.
Step 2 Check whether ARP packets are properly sent and received.
Run the debugging arp packet command on the FW.
<FW> debugging arp packet
Info:Current terminal monitor is on
Info:Current terminal debugging is on
If ARP packets are correctly sent and received, the following information is displayed.
*0.1090420 FW ARP/7/arp_send:Send an ARP Packet, operation : 1, send
er_eth_addr : 0018-8239-1e63,sender_ip_addr : 10.1.196.208, target_eth_addr :
00e0-4c84-0b04, target_ip_addr : 10.1.196.2
*0.1083955 FW ARP/7/arp_rcv:Receive an ARP Packet, operation : 2, se

nder_eth_addr : 00e0-fcfc-1010, sender_ip_addr : 10.1.196.216, target_eth_addr
: 0000-0000-0000, target_ip_addr : 10.1.196.216
If the remote end can be pinged, both request and reply packets are displayed. If a fault
occurs, only the request packets are displayed, or none of the request or reply packets is
displayed.
If packets are properly sent and received by the upper layer, run the debugging ethernet
packet arp interface GigabitEthernet 1/0/3 command and check whether packets are
properly sent at the data link layer.
<FW> debugging ethernet packet arp interface GigabitEthernet 1/0/3
Info:Current terminal monitor is on
Info:Current terminal debugging is on
*0.3743890 FW ETH/7/eth_rcv:Receive an Eth Packet, interface : GigabitEthernet

1/0/3, eth format: 0, length: 60, prototype: 0806 arp, src_eth_addr:
001e-9060-405a, dst_eth_addr: 0018-8239-1e63
*0.3743789 FW ETH/7/eth_send:Send an Eth Packet, interface : GigabitEthernet

1/0/3, eth format: 0, length: 42, prototype: 0806 arp, src_eth_addr : 0
018-8239-1e63, dst_eth_addr : ffff-ffff-ffff
The previous information shows that ARP request packets are properly sent at the data link
layer. Go to Step 3.
Step 3 Check whether statistics about sent and received packets are correct.
Run the display this interface command in the interface view or the display interface
interface-type interface-number command in any view to view packet statistics.

<FW> display interface GigabitEthernet 1/0/3

GigabitEthernet1/0/3 current state : UP
Description : Route Port
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0022-a106-0e5b
Max-bandwidth : 1000000 Kbps
0 ex. collisions, 0 deferred, * other errors
In the preceding command output, check the following fields:

l Input: the number of received packets
l Output: the number of sent packets
l unicasts: the number of unicast packets
l broadcasts: the number of broadcast packets
l multicasts: the number of multicast packets
l On ARP request packets, view broadcast packet statistics.
l On ARP reply packets, view unicast packet statistics.
If either of the following fault occurs, record the locating process, debugging information
(that is displayed), and statistics about the interface, and contact technical support personnel.
l The upper layer does not send or incorrectly sends ARP request or replay packets.
l The upper layer correctly sends ARP request or reply packets, but the data link layer
does not send or incorrectly sends ARP packets.
l The upper layer correctly sends ARP request or reply packets, and the data link layer
properly sends and receives these packets. The interface, however, does not collect
statistics about sent and received packets.
Step 4 Check the Vlanif interface.
On the Vlanif interface, synchronously update host routes. Run the display fib command to
check whether the FIB table is updated. On physical interfaces and other logical interface,
skip this step.
<FW> display fib
Fib Flags: B - blackhole, D - dynamic, G - gateway, H - host, S - static
U - up
------------------------------------------------------------------------------
FIB Table:
Total number of Routes : 4
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID

10.2.0.1/32 10.2.0.1 HU t[77] InLoop0 0x0

10.2.0.0/8 10.2.0.1 U t[77] InLoop0 0x0
10.3.1.1/32 10.2.0.1 HU t[105] InLoop0 0x0
10.3.1.0/24 10.3.1.1 U t[105] GE1/0/3 0x0
NOTE
Collect information, preserve the faulty scenario, and contact technical support personnel in either of the
following situations:
l ARP entries on the main processing unit (MPU) of the Vlanif interface are inconsistent with those
on a line interface processing unit (LPU).
l ARP entries are consistent but host routes are not updated.
Step 5 Check whether ICMP packets are properly sent and received.
Perform the following operations:
1. Run the debugging ip packet acl acl-number command in the user view and check
information about both sent and received IP packets.
2. Run the debugging ip icmp command and collect more information to locate the fault.
If the fault persists, contact technical support personnel.
----End

This section provides ARP references.
This section describes the related specifications of ARP.
Static ARP Static ARP entries can be Supported by all models.

configured to enhance
security. A static ARP entry
specifies a MAC address for
the communication with a
device using a specific IP
address. Attack packets
cannot modify the mapping
relationship between the IP
address and MAC address in
this entry.
Proxy ARP The following types of Supported by all models.

proxy ARP are supported:
l Routed proxy ARP
l Inner-VLAN proxy ARP
l Inter-VLAN proxy ARP

Gratuitous ARP A device uses its IP address Supported by all models.

as the destination address to
send ARP requests.
Deleting ARP entries Static, dynamic, and all Supported by all models.
ARP entries can be deleted.
Strict ARP learning Strict ARP learning can be Supported by all models.
configured to allow a device
to learn the response packets
only to the ARP requests
sent from this interface or
device.
Maximum number of static ARP entries l USG6000V: 2048
ARP aging time 20 minutes
Validity period of dynamic ARP entries 20 minutes
Maximum number of dynamic ARP entries l USG6000V1: 4096

l USG6000V2: 8192
l USG6000V4: 16384
l USG6000V8: 32786


This section provides ARP standards and protocols.
ARP standards and protocols are as follows:
l RFC 826: Ethernet Address Resolution Protocol
l RFC 903: Reverse Address Resolution Protocol
l RFC 1027: Using ARP to Implement Transparent Subnet Gateways

l RFC 1042: Standard for the Transmission of IP Datagrams over IEEE 802 Networks
4.11 VLAN
This section describes virtual local area network (VLAN) concepts and how to configure a
VLAN, as well as provides configuration examples.
4.11.1 Overview
The virtual local area network (VLAN) technology adds a VLAN tag to the traditional
Ethernet frame header to identify the VLAN in a data packet.
Definition
A LAN is divided into several logical "LANs" (VLANs), with each VLAN functioning as a
broadcast domain.
Objective
The following problems occur in a traditional LAN:
l Conflicts occur if more than one node attempts to send messages at the same time.
l The information from any node is sent to all other nodes. A method is required to send a
message that is destined for a node or multiple nodes, instead of all nodes.
l Information security is reduced because all hosts share the same transmission channel.
With the growth of computers on a network, the collisions increase, and network efficiency
deteriorates. As a result, collision areas form in the network. The Ethernet network uses the
Carrier Sense Multiple Access/Collision Detect (CSMA/CD) to detect collisions, which
cannot completely remove the collision impact.
The Ethernet network is also a broadcast network. If a large number of computers send
information at the same time, broadcast traffic consumes a great deal of bandwidth.
Therefore, two problems occur in the traditional network: collision area and broadcast area. In
addition, the traditional network cannot ensure information security.
To expand a traditional LAN to accommodate more computers and to prevent collisions, the
following methods are introduced:
l Bridge
l Layer 2 switch
Bridges and switches forward information from an inbound interface to an outbound interface
in switching mode. Collisions occurs only on ports and do not affect the shared media.
NOTE
The switch in this chapter refers to the Layer 2 LAN switch.
The introduction of switches into the networking solves the problem of the collision area
using the Layer 2 rapid switching. This, however, does not ensure information security caused
by the broadcast domain problem.
To reduce broadcast storms, the hosts that do not need to access each other must be isolated
from each other. Routers select a route based on IP addresses. Therefore, using a router to

connect two network segments can effectively control the broadcast problems. Routers,
however, are costly. In this case, the VLAN is introduced.
The VLAN technology divides a LAN into logical "LANs" (VLANs), with each VLAN
functioning as a broadcast area. Hosts in each VLAN communicate with each other in the
same way as hosts in a LAN. VLANs cannot interact with each other directly. Therefore,
broadcast packets are transmitted within a single VLAN.
VLANs can improve data security. For example, different enterprise clients rent a building
and require developing their own LANs. The total cost of LANs is high. If all clients share a
LAN, information security cannot be guaranteed.
VLANs allow different clients to share a LAN and improves information security.
Figure 4-81 VLAN networking
Router
Switch1 Switch2 Switch3
VLAN-A
VLAN-B
VLAN-C
As shown in Figure 4-81, the network is a typical VLAN application. Three switches are
placed at sites. This is more or less the same as different floors in a building. Each switch is
connected to three PCs. These PCs belong to three VLANs, which are enclosed by dashed
blocks. Each VLAN corresponds to an enterprise client.
4.11.2 Mechanism
This section describes the virtual local area network (VLAN) mechanism.

VLAN Frame Format

The IEEE 802.1q standard modifies the Ethernet frame format by adding a 4-byte 802.1q tag
between the source MAC address and the protocol type fields, as shown in Figure 4-82.
Figure 4-82 VLAN frame format defined in 802.1q
6 bytes 6 bytes 4 bytes 2 bytes 42-1500 bytes 4 bytes
Destination Source 802.1Q Length FCS

Data
Address Address Tag /Type （CRC-32)
Type PRI CFI VID
16 bits 3 bits 1 bit 12 bits
An 802.1q tag contains the following fields:

l Type field: a 16–bit frame type. The value 0x8100 indicates an 802.1q tagged frame,
which is discarded by devices that do not support the 802.1q standard.
l PRI field: a 3-bit priority value of a frame. The value ranges from 0 to 7. The greater the
value, the higher the priority. If a switch is blocked, the switch preferentially forwards
packets with high priorities.
l Canonical format indicator (CFI) field: This field is 1 bit long. The value 1 indicates the
non-canonical format, and the value 0 indicates the canonical format.
l VID field: specifies the ID of a VLAN to which a frame belongs. This field is 12 bits
long.
Link Types
VLAN links are classified into the following types:
l Access links: connect switches to hosts. The access links shown in Figure 4-83 connect
switches to PCs and transmit untagged Ethernet frames.
l Trunk links: connect switches. The trunk links shown in Figure 4-83 connect switches
and transmit tagged Ethernet frames.

Figure 4-83 Link types
Access Link
Trunk Link
VLAN2
VLAN3
Port Types
Ports only on some devices can identify VLAN frames defined in 802.1q. Based on their
ability of identifying VLAN frames, the ports are classified into the following types:
l Access ports
Access ports are switch ports that connect hosts only along access links. An access port
has the following characteristics:
– Only allows frames tagged with access port PVIDs to pass through. A PVID is a
default VLAN ID.
– Adds the port PVID to untagged frames that it receives.
– Sends untagged Ethernet frames to the peer device.
l Trunk ports
Trunk ports connect a local switch to other switches. In other words, trunk ports can only
connect to trunk links. A trunk port has the following characteristics:
– Allows tagged frames of many VLANs to pass through.
– Only removes a tag with a default VLAN ID from a frame before sending the
frame.
l Hybrid ports
Hybrid ports are switch ports that connect a local switch to hosts and to other switches.
Hybrid ports can be connected to both access and trunk links. A hybrid port allows

tagged frames of different VLANs to pass through and removes tags from some VLAN
frames before forwarding the frames.
VLAN Classification
VLANs can be classified into the following types:
l Port-based VLANs
A computer belongs to a VLAN that is connected to a network device port on the
computer. This method allows hosts to be easily grouped into VLANs. If a host of a
VLAN is moved to another place, the VLAN needs to be reconfigured.
l MAC address-based VLANs
Devices are allocated to VLANs based on MAC addresses of network interface cards.
VLAN settings remain even if hosts are moved to other places. All hosts within a VLAN
must be configured.
l Network layer protocol-based VLANs
Devices are allocated to VLANs based on network layer protocols. For example, hosts
running IP are grouped into a VLAN, and hosts running IPX are grouped into another
VLAN.
The FW supports only port-based VLANs.
VLAN Communication Principles

To help improve frame processing efficiency, frames are tagged when being processed within
a device.
The device processes frames based on the type of ports that receive the frames. Table 4-57
describes the VLAN packet processing on ports of the USG6000V.
Table 4-57 VLAN packet processing on different types of ports (USG6000V)

Port Type Processing a Received Frame Processing a Frame to
Be Sent
Access port 1. Checks whether the frame carries a Removes the PVID from
VLAN tag: the frame before sending
l If the frame does not carry a VLAN it.
tag, the port adds its PVID to the
frame and goes to step 2.
l If the frame carries a VLAN tag with a
PVID, the device goes to step 2. If the
tag does not contain a PVID, the port
discards the frame.
2. The device selects an outbound port based
on the destination MAC address and
VLAN ID carried in the frame.


Be Sent
Trunk port 1. Checks whether the frame carries a Checks the VLAN
VLAN tag: attribute of the port:
l If the frame is not tagged, the port l If the frame carries a
adds its PVID to the frame and goes to VLAN tag that
step 2. contains the port
l If the frame carries a VLAN tag, the PVID, the port
port checks whether the VLAN ID in removes the tag from
the tag is permitted. If the VLAN ID is the frame before
permitted, the switch goes to step 2. If sending the frame.
the VLAN ID is not permitted, the port l If the frame carries a
discards the frame. VLAN tag that does
2. The device selects an outbound port based not contain the port
on the destination MAC address and PVID, and the port
VLAN ID carried in the frame. supports the VLAN
ID, the port sends the
frame as it is. If the
port does not support
the VLAN tag with a
non-PVID, the port
discards the frame.


Be Sent
Hybrid port 1. Checks whether the frame carries a Checks the VLAN
VLAN tag: attribute of the port:
l If the frame is not tagged, the port l If the port supports
adds its PVID to the frame and goes to the tagged frame, the
step 2. port checks which
l If the frame carries a VLAN tag, the type of outgoing
port checks whether the VLAN ID in frame can be sent:
the tag is permitted. If the VLAN ID is – If it permits
permitted, the device goes to step 2. If untagged outgoing
the VLAN ID is not permitted, the port frames, the port
discards the frame. removes the tag
2. The device selects an outbound port based from the frame
on the destination MAC address and before sending the
VLAN ID carried in the frame. frame.
NOTE – If it permits tagged
Trunk and hybrid ports use the same rules to outgoing frames, it
process received data frames. sends the frame as
it is.
l If the port does not
support tagged
frames, the port
discards it.
NOTE
If a hybrid port permits
untagged frames, the
hybrid port removes the
VLAN Tag field the same
as the PVID Tag field from
a frame before sending it.
If a hybrid port permits
tagged frames, the hybrid
port still removes the
VLAN Tag field the same
as the PVID Tag field from
a frame before sending it.
Intra-VLAN Communication
Hosts on a VLAN in the same area can directly communicate with each other. Hosts on the
same VLAN but in different areas (with multiple devices between them) can communicate
with each other using trunk links.
Figure 4-84 shows that hosts in the same department of an enterprise communicate with each
other across two FWs. Each department belongs to a specific VLAN. You can configure trunk
links to isolate service data of different departments to ensure data communication within a
department.

Figure 4-84 VLAN trunk links
FW_A FW_B
Trunk Link
VLAN 2 VLAN 3 VLAN 2 VLAN 3
Inter-VLAN Communication
Hosts of different VLANs use VLAN interfaces or Ethernet subinterfaces to communicate
with each other.
l Inter-VLAN communication using VLAN interfaces

VLAN interfaces function as Layer 3 physical interfaces to implement Layer 3 functions,
such as IP address settings and inter-VLAN data communication.
Figure 4-85 shows hosts of two departments attached to a FW. Hosts of one department
belong to VLAN100, and hosts of the other department belong to VLAN200. You can
configure a VLAN interface for each VLAN on the FW to allow hosts of the two
departments to communicate with each other.
Figure 4-85 VLAN interfaces

FW
VLANIF100 VLANIF200
VLAN100 VLAN200
Note the following issues:

– Layer 2 Ethernet interfaces connect the FW to PCs and are added to separate
VLANs.
– Each interface on the FW can be connected to a single PC, which causes low data
transmission efficiency.
l Inter-VLAN communication using Ethernet subinterfaces
Unlike VLAN interfaces, Ethernet subinterfaces on a switch connect multiple PCs to a
single interface of a FW to implement inter-VLAN communication.
Figure 4-86 shows hosts of two departments attached to a FW. Hosts in one department
belong to VLAN5, and host in the other department belong to VLAN6. You can
configure two subinterfaces on a single physical interface and add these subinterfaces to
separate VLANs. This approach allows VLANs to communicate with each other using a
single physical interface on a FW.
Figure 4-86 Ethernet subinterfaces
FW
GE1/0/0
GE1/0/0.1 VLAN5
GE1/0/0.2 VLAN6
Switch
VLAN5 VLAN6
The configuration requirements are as follows:

– Create two subinterfaces on an Ethernet interface that connects the FW to the
switch and add a subinterface to VLAN5 and the other to VLAN6 to enable the two
VLANs to communicate with each other.
– Configure 802.1Q encapsulation and assign an IP address to each subinterface.
– Change the type of the Ethernet interface that connects the switch to the FW from
access to trunk or hybrid to permit packets from VLAN5 and VLAN6.
l Inter-VLAN communication using Layer 2 Ethernet subinterfaces
Inter-VLAN communication through VLANIF interfaces or Layer 3 Ethernet
subinterfaces applies only when hosts of VLANs are located in different network
segment. When the hosts of VLANs are located in the same network segment without a
conflict, inter-VLAN communication can be implemented through Layer 2 Ethernet
subinterfaces.
As shown in Figure 4-87, the intranet interface GE1/0/1 on FW works in Layer 2 mode
and it connects to two VLANs (VLAN100 and VLAN200). Two Layer 2 subinterfaces
(GE1/0/1.1 and GE1/0/1.2) are configured at GE1/0/1, and they are attributed to
VLAN100 and VLAN200, respectively. Then Layer 2 subinterfaces GE1/0/1.1 and

GE1/0/1.2 are added into the same VLAN (VLAN300, for example). The following uses
VLAN100–to-VLAN200 access to show how USG processes packets.
FW receives packets from VLAN100 hosts through GE1/0/1.1, strips VLAN tags from
the packets, and broadcasts the packets in VLAN200. After finding the destination host
in VLAN200, the device forwards the packets through GE1/0/1.2 with a VLAN tag
(VLAN200).
Figure 4-87 Layer 2 ethernet subinterfaces
FW
GE1/0/1
GE1/0/1.1 VLAN100
GE1/0/1.2 VLAN200
Switch
VLAN100 VLAN200
4.11.3 Configuring a VLAN

This section describes how to configure a VLAN.
4.11.3.1 Dividing a LAN into VLANs Based on Ports

Dividing a LAN into VLANs based on ports is the most simple and effective VLAN division
mode.
Context
After VLANs are configured based on ports, the VLANs can process tagged and untagged
frames in the following manners:
l After receiving an untagged frame, a port adds the PVID to the frame, searches the MAC
address table for an outbound port, and sends the tagged frame from the outbound port.
l After a port receives a tagged frame, it checks the VLAN ID carried in the frame:
– If the port allows frames with the specified VLAN ID to pass through, it forwards
the frame.
– If the port does not allow frames with the specified VLAN ID to pass through, it
discards the frame.
1. Create VLANs.

2. Configure the port type and features: access, trunk, or hybrid.

3. Add ports to VLANs.
Procedure
Step 1 Run:
system-view

Step 2 Run:
vlan vlan-id
A VLAN is created, and the VLAN view is displayed. If the specified VLAN has been
created, the VLAN view is directly displayed.
The VLAN ID ranges from 1 to 4094. If VLANs need to be created in batches, run the vlan
batch { vlan-id1 [ to vlan-id2 ] } &<1-10> command to create VLANs in batches, and then
run the vlan vlan-id command to enter the view of a specified VLAN.
Step 3 Run:
quit

Step 4 Configure the port type and features.
1. Run the interface { ethernet | gigabitethernet | xgigabitethernet | epon } interface-
number command to enter the view of an Ethernet port to be added to the VLAN.
2. Run the portswitch command to switch an Ethernet interface from the Layer 3 mode to
the Layer 2 mode
3. Run the port link-type { access | hybrid | trunk } command to configure the port type.
By default, the port type is hybrid.
– If a Layer 2 Ethernet port is directly connected to a terminal, set the port type to
access or hybrid.
– If a Layer 2 Ethernet port is connected to another switch, the port type can be set to
access, trunk, hybrid, or QinQ.
Step 5 Add ports to the VLAN.
Run either of the following commands as needed:
l For access ports:
Run the port default vlan vlan-id command to add a port to a specified VLAN.
To add ports to a VLAN in batches, run the port interface-type { interface-number1 [ to
interface-number2 ] } &<1-10> command in the VLAN view.
NOTE
The input port format must be correct. The port number following to must be greater than the port
number before to. If a group of ports are specified, ensure that these ports are of the same type and
all specified ports exist.
In one port command, a maximum of 10 groups of ports can be specified by using to.
l For trunk ports:
– Run the port trunk allow-pass vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
command to add the port to specified VLANs.

– (Optional) Run the port trunk pvid vlan vlan-id vlan-id command to specify the
default VLAN for a trunk port.
l For hybrid ports:
– Run either of the following commands to add a port to VLANs in untagged or
tagged mode:
n Run the port hybrid untagged vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> |
all } command to add a port to VLANs in untagged mode.
In untagged mode, a port removes tags from frames and then forwards the
frames. This is applicable to scenarios in which Layer 2 Ethernet ports are
connected to terminals.
n Run the port hybrid tagged vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
command to add a port to VLANs in tagged mode.
In tagged mode, a port forwards frames without removing their tags. This is
applicable to scenarios in which Layer 2 Ethernet ports are connected to
switches.
– (Optional) Run the port hybrid pvid vlan vlan-id command to specify the default
VLAN of a hybrid port.
By default, as for the USG6000V, after an interface is switched to a Layer 2 interface,
the IDs of the VLAN that the interface is added and the default VLAN of the interface
are both 1.
----End
4.11.3.2 Configuring Vlanif Interfaces to Enable VLANs to Communicate

This section describes how to configure VLANIF interfaces to enable VLANs to
communicate.
Context
You can create a VLANIF interface on a configured VLAN. The VLANIF interface functions
as a Layer 3 physical interface to implement Layer 3 features, such as IP address settings and
data communications among different VLANs.
Inter-VLAN communication through VLANIF interfaces applies only when the hosts in each
VLAN are located in different network segments. If the hosts of VLANs are located in the
same network segment, inter-VLAN communication can be implemented through Layer 2
interfaces. For details, see 4.11.3.4 Configuring Inter-VLAN Communication Using Layer
2 Subinterfaces.
Procedure
system-view
Step 2 Create a VLANIF interface and access the VLANIF interface view.
If a VLANIF interface already exists, the VLANIF interface view is directly displayed after
this command is run.
Before you create a VLANIF interface, the VLAN must exist.

Step 3 Assign an IP address to the VLANIF interface.

The IP addresses of different VLANIF interfaces must be on different network segments so
that users on different VLANs can communicate.
----End
4.11.3.3 Configuring Layer 3 Subinterfaces to Enable VLANs to Communicate

This section describes how to configure Layer 3 subinterfaces to enable VLANs to
communicate.
Context
The most direct method for inter-VLAN communication is connecting VLANs to different
Layer 3 interfaces to route the packets between VLANs. However, this method requires
physical interfaces. In contrast, creating Ethernet subinterfaces can avoid the use of more
physical interfaces.
Ethernet and Eth-Trunk interfaces support subinterfaces.
You can configure multiple subinterfaces on a single physical interface and ensure that each
subinterface is assigned to a specific VLAN. VLANs can communicate after being connected
to only as single physical interface.
Inter-VLAN communication through Layer 3 subinterfaces applies only when the hosts in
each VLAN are located in different network segments. If the hosts of VLANs are located in
the same network segment, inter-VLAN communication can be implemented through Layer 2
interfaces. For details, see 4.11.3.4 Configuring Inter-VLAN Communication Using Layer
2 Subinterfaces.
Procedure
system-view
Step 2 Create a subinterface and access the subinterface view.
interface interface-type interface-number.subinterface-number
Step 3 Set the encryption type and the VLAN ID of the subinterface.
Step 4 Assign an IP address to the subinterface.
The subinterface and its main interface can be on the same primary network segment but must
use different subnet masks.
----End
4.11.3.4 Configuring Inter-VLAN Communication Using Layer 2 Subinterfaces

This section describes how to implement inter-VLAN communication by configuring Layer 2
subinterfaces.

Context
Procedure
Step 2 Switch the Layer 3 Ethernet interface to a Layer 2 Ethernet interface.

1. Run the interface interface-type interface-number command to access the interface
view.
2. Run the portswitch command to configure a Layer 3 Ethernet interface to work in Layer
2 mode.
3. Run the quit command to return to the system view.
Step 3 Create Layer-2 subinterfaces.

1. Run the interface interface-type interface-number.subinterface-number command to
create a subinterface and access the subinterface view.
2. Run the vlan-type dot1q vlan-id command to configure the encapsulation type for the
subinterface and associate a VLAN ID with the subinterface.
Each subinterface receives or forwards only packets that carry the specified VLAN tag.
3. Run the portswitch command to configure the subinterface as a Layer 2 subinterface.
4. Run the quit command to return to the system view.
5. Repeat the previous substeps to create multiple Layer 2 subinterfaces.
Step 4 Add the subinterfaces created in Step 3 to a same VLAN so that the subinterfaces can
communicate.
1. Run the vlan vlan-id command to create a VLAN and access the VLAN view.
2. Run the port interface-type interface-number.subinterface-number command to add the
subinterfaces created in Step 3 to a same VLAN.
Subinterfaces must be added to the same VLAN to communicate with each other.
----End
4.11.4 Maintaining a VLAN

After the VLAN is configured, you can run the display commands to display the VLAN
configurations.
You can display the configuration information of VLAN by running the commands listed in
the following table in all views.
Table 4-58 Displaying the configuration information of VLAN

Operation Command
Display the configuration information of display vlan [ vlan-id [ verbose ] |

VLAN summary ]
Display the information of VLANIF display interface vlanif [ vlan-id | main ]

Operation Command
Display the information about interfaces of display port vlan [ interface-type interface-
the VLAN number ]
4.11.5 Example for Dividing a LAN into VLANs Based on Ports

It is easy to divide a LAN into VLANs based on ports. After ports are added to different
VLANs, users in the same VLAN can directly communicate with each other, whereas users in
different VLANs cannot directly communicate with each other.
It is required that on the network shown in Figure 4-88, employees in the same group be able
to communicate with each other, whereas employees in different groups not communicate
with each other.
Figure 4-88 Networking diagram for dividing a LAN into VLANs based on ports
FW
GE1/0/1 GE1/0/4
GE1/0/2 GE1/0/3
Group 1 Group 2
VLAN 2 VLAN 3
1. Create VLANs and determine mappings between employees and VLANs.

2. Configure port types to determine the device connected to each port.
3. Add the port connected to group 1 to VLAN 2 and the port connected to group 2 to
VLAN 3 to prevent employees in group 1 from communicating with employees in group
2.

Data Preparation
l Number of each port connecting a switch to a PC
l ID of each VLAN
Procedure
Step 1 Create VLANs.
<FW> system-view
[Switch] vlan batch 2 3
Step 2 Configure port types.

[FW-GigabitEthernet1/0/1] undo shutdown
Step 3 Add ports to VLANs.

# Add GE 1/0/1 and GE 1/0/2 to VLAN 2.
[FW] vlan 2
[FW-vlan2] port gigabitethernet 1/0/1 to 1/0/2
[FW-vlan2] quit
# Add GE 1/0/3 and GE 1/0/4 to VLAN 3.

[FW] vlan 3
[FW-vlan3] port gigabitethernet 1/0/3 to 1/0/4
[FW-vlan3]quit

After the configurations are complete, run the display vlan command to view the VLAN
status.
[FW] display vlan
The total number of vlans is : 2
VLAN ID Status Unknown-Unicast Description
------------------------------------------
2 enable forward VLAN 0010
3 enable forward VLAN 0020
Ping a PC in group 2 from a PC in group 1. The ping fails. PCs in the same group can ping
each other successfully.
----End

Configuration Files
#
sysname FW
#
vlan batch 2 3
#
portswitch
undo shutdown
port default vlan 2
#
portswitch
undo shutdown
port default vlan 2
#
portswitch
undo shutdown
port default vlan 3
#
portswitch
undo shutdown
port default vlan 3
#
return

This section provides VLAN references.
This section describes VLAN specifications.
Layer-2 port-based VLAN The following Layer-2 port Supported by all models.
types are supported:
l Access
l Trunk
l Hybrid

This section describes the versions and changes in the VLAN feature.


This section provides VLAN standards and protocols.
VLAN standards and protocols are as follows:

l RFC 3069: VLAN Aggregation for Efficient IP Address Allocation
l IEEE 802.1Q: IEEE Standards for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks
l IEEE 802.1ad: IEEE Standards for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks- Amendment 4
l IEEE 802.10: IEEE Standards for Local and Metropolitan Area Networks: Standard for
Interoperable LAN/MAN Security
l YD/T 1260-2003: Technical and Testing Specification of Virtual LAN Based on Port
4.12 IPv6 Neighbor Discovery

This section describes IPv6 neighbor discovery (ND) concepts and how to configure IPv6
ND, as well as provides configuration examples.
4.12.1 Overview
IPv6 Neighbor Discovery (ND) defines a group of messages and processes for discovering
neighboring nodes. The IPv6 Secure Neighbor Discovery (SEND) protocol is an enhancement
of IPv6 ND.
Definition
The IPv6 NDP uses Internet Control Message Protocol version 6 (ICMPv6) messages to
discover neighbors. NDP functions include IPv4 Address Resolution Protocol (ARP), ICMP
router discovery (RD), and ICMP redirection.
SEND uses a set of new ND options to implement the authorization delegation discovery
process, address ownership proof mechanism, and message verification, which secures
neighbor discovery.
Purpose
ND enables the address auto-configuration and information interaction between different
nodes of one link on the IPv6 network.
ND does not provide any security mechanisms and is vulnerable to the following threats:
l NS/NA spoofing
Neighbor Solicitation/Advertisement Spoofing (NS/NA spoofing) is similar to IPv4 ARP
spoofing. An attacker sends NS/NA messages containing a forged link-layer address to

update the neighbor cache of a target node. Consequently, the target node sends packets
to the forged address.
l DAD attack
On networks where the hosts obtain their addresses using stateless address
autoconfiguration, an attacker can respond every duplicate address detection (DAD)
attempt made by the host to launch an attack. If the attacker claims the address, the host
will never be able to obtain an address.
l Redirect attack
An attacker uses the link-layer address of the default gateway of a target node as a source
address to send a Redirect message to the target node. The message carries a nonexistent
next-hop address for the target node. Upon receiving the messagept, the target node
sends packets to the nonexistent next-hop address. As a result, the packets fail to reach
their destinations.
l Parameter spoofing
An attacker impersonates a local router and sends a forged Router Advertisement (RA)
message to a target node. The forged RA message contains a fake network prefix with a
set autonomous flag. After the message arrives, the target node performs stateless
address autoconfiguration and uses the fake prefix to generate an IPv6 address. When the
target node uses this IPv6 address as a source address to communicate with other hosts,
the traffic destined for the target node is discarded by the local router.
l Replay attack
An attacker obtains valid messages and replays them later to send expired messages to a
target node.
SEND effectively defends against these security threats to secure neighbor discovery.
4.12.2 Mechanism
This section describes the IPv6 ND and SEND mechanisms.
4.12.2.1 IPv6 ND
IPv6 neighbor discovery (ND) uses ICMPv6 messages to implement address resolution,
verify neighbor reachability, detect duplicate addresses, discover routers and prefixes,
automatically assign addresses, and perform the redirection function.
Before assigning an IPv6 address to a single node, a router checks whether the address is
available and unique and perform either of the following operations:
l If the node is a host, the router notifies the host of the ideal next-hop address for
forwarding messages to a specific destination address.
l If the node is another router, the router advertises its address, address prefix, and other
parameters to the router.
Before forwarding a IPv6 message, the node verifies the data link layer address of its
neighbor node and its reachability.
The IPv6 ND mechanism provides five types of ICMPv6 messages:
l Router solicitation (RS): After startup, a host sends an RS message to a router.
l Router advertisement (RA): A router replies with an RS message with an RA message to
a host and periodically sends RA messages carrying prefixes and some flag bits.

l Neighbor solicitation (NS): An IPv6 node sends NS messages to obtain data link layer
addresses of neighbors, check neighbor reachability, and perform address conflict
detection.
l Neighbor advertisement (NA): An IPv6 node responds NS messages with NA messages.
The IPv6 node also sends NA messages if the data link layer changes.
l Redirect: After a router finds that a received message carries the same inbound and
outbound interface name, the router sends Redirect messages to instruct a host to select a
better next hop.
Figure 4-89 shows the IPv6 ND process.
Figure 4-89 IPv6 ND process
IPv6 address: 3000::1 IPv6 address: 3000::2

MAC: 00e0-fe20-1f66 MAC: 00e0-fe20-1f67
Neighbor Solicitation
IPv6 source: 3000::1
Dest: ff02::1:ff 00:0002
Link source: 00e0-fe20-1f66
Dest: 3333-ff00-0002
Neighbor Advertisement
IPv6 source: 3000::2
Dest: 3000::1
Link source: 00e0-fe20-1f67
Dest: 00e0-fe20-1f66
The IPv6 ND protocol delivers the following functions:
Duplicate Address Detection

Duplicate Address Detection (DAD) is a detection mechanism that identifies whether the IPv6
address is available. The implementation process is as follows:
1. If an IPv6 address is specified for a node, the node sends the NS message to check
whether the address is used by any neighbor.
2. When receiving the message, a neighbor node checks whether the same IPv6 address
exists. If the local IPv6 address exists, the neighbor node replies a NA message that
contains the IPv6 address to the source node.
3. After the source node receives the reply message from the neighbor, the source node
considers that the IPv6 address is used by the neighbor. If the source node does not
receive the reply message from the neighbor, the IPv6 address is available.

Neighbor Discovery
The IPv6 ND function, similar to the IPv4 Address Resolution Protocol (ARP) function,
resolves neighbor addresses and detect neighbor reachability using NS and NA messages.
To obtain the data link layer address of another node on the same local link, a node sends an
ICMPv6 NS message of Type 135, which is similar to an IPv4 ARP request message. The
ICMPv6 NS message is transmitted using a multicast address, not a broadcast address. Only
the solicited node that has an IP address with the lest significant 24 bits the same as that of the
multicast address can receive the NS message, which minimizes broadcast storms. The
destination node adds its data link layer address to an NA message.
The NS message is also used to check the reachability of the neighbor with a known data link
layer address. The IPv6 NA message is sent in response to the IPv6 NS message. After
receiving the ICMPv6 NS message, the destination node replies with an ICMPv6 NA message
of Type 136 on the local link. After the ICMPv6 NA message is received, the source and
destination nodes can communicate. A node also sends an NA message if its data link layer
address on the local link is changed.
Router Discovery
The RD function locates neighbor routing devices and learns the prefixes and parameters for
address autoconfiguration. The IPv6 RD function is implemented using the following
mechanism:
l Router solicitation
When no unicast address is specified for a host (for example, when the system is just
restarted), the host sends an RS message. The RS message helps the router quickly
implement autoconfiguration without waiting for an RA message sent by the IPv6
routing device. The IPv6 RS message is an ICMPv6 message of Type 133.
l Router advertisement
After IPv6 RA is configured on interfaces of a routing device, the routing device
periodically sends an RA message. After receiving an RS message from an IPv6 node on
the local link, a routing device replies with an RA message. The IPv6 RA message is
sent to the multicast address (FF02::1) of all nodes or to the IPv6 unicast address of the
node that sends the RS message. The IPv6 RA message is an ICMPv6 message of Type
134. The IPv6 RA message includes the following contents:
– Whether address autoconfiguration is enabled or disabled
– Supported autoconfiguration type, stateless or stateful
– One or multiple local link prefixes: The nodes on the local link can implement
address autoconfiguration using these prefixes.
– Lifecycle of an advertised prefix of the local link
– Whether the router that sends an RA message can serve as a default routing device.
If the router serves as a default routing device, the time (in seconds) for the router
serving as the default routing device is included.
– Other information about the host, including the hop limit and MTU specified for
messages initiated by the host.
The IPv6 node on the local link receives an RA message and obtains the default routing
device, prefix list, and other settings.

Address Autoconfiguration
By using RA messages and identifying each prefix, a routing device can instruct the host how
to implement the address autoconfiguration. For example, the routing device can configure
the host to use the stateful address setting or stateless address autoconfiguration.
If the stateless address autoconfiguration is used and an RA message arrives, the host
automatically generates an IPv6 address by using the prefix and local interface ID carried in
the message and sets the default routing device.
Redirection
A redirection message notifies a host of the ideal next-hop IPv6 address to the destination.
Similar to IPv4, the IPv6 routing device sends a redirection message to only redirect the
message to a better routing device. The node that receives the redirection message sends
subsequent messages to the new routing device. The routing device sends the redirection
message only for the unicast flow. The redirection message is only sent to and processed by
the node (host) that initiates the redirection message.
4.12.2.2 IPv6 SEND

This section describes the IPv6 Secure Neighbor Discovery (SEND) protocol.
SEND, enhanced IPv6 ND, introduces the following new types of message and extension
fields:
The new types of message and extension fields are as follows:
l Extension fields: Cryptographically Generated Address (CGA), Revist-Shamir-Adleman
Algorithm (RSA), Timestamp, and Nonce
l Message types: Certification Path Solicitation (CPS) and Certification Path
Advertisement (CPA)
SEND supports the following enhanced security functions:
l Address ownership verification
A CGA binds IPv6 addresses to packets to prevent IPv6 address embezzlement.
Communication parties generate and authenticate CGA information. CGA information
helps prevent address spoofing and effectively defend against Neighbor Solicitation
(NS)/Neighbor Advertisement (NA) spoofing and duplicate address detection (DAD)
attacks.
l Message protection
The communication parties use RSA signatures and authentication to protect message
integrity. The parties also check the Timestamp and Nonce fields, which enhances the
time sequence of packets and defends against replay attacks.
l Router authorization
Certificate authentication helps verify router identities, which prevents malicious packets
in the name of routers and defends against Redirect attacks and parameter spoofing.
CGA
A CGA is an IPv6 address that a node uses a public key and the hash algorithm to generate. A
node discards packets that fail CGA authentication to defend against spoofing attacks. CGAs
are used with the RSA signature mechanism to protect packet integrity.

The procedure for generating a CGA and an RSA signature on a node is as follows:
1. Obtains an RSA key pair.

2. Generates the CGA parameter data structure, including a public key.
3. Computes a hash value based on the CGA parameter data structure. The least significant
64 bits in the data structure represent a network ID.
4. Generates a CGA based on the prefix and network ID.
5. Forges a packet with the CGA as a source IP address, fills the CGA parameters data
structure in the CGA option, assigns the packet a private key, and fills a signature in the
RSA option.
After receiving a packet with CGA and RSA options, a node authenticates the packet as
follows:
1. Obtains the CGA parameter data structure from the CGA option.
2. Computes a hash value based on the CGA parameters data structure, with the least
significant 64 bits as the network ID.
3. Checks whether the generated network ID matches that in the source IP address of the
packet.
4. Obtains the public key from the CGA parameter data structure to authenticate the RSA
signature.
After a CGA is generated, ND packets to be sent by the interface must meet the following
requirements:
l NS (excluding DAD messages), NA, RA, and Redirect messages carry CGAs as source
addresses.
l NS, NA, RA, and Redirect messages carry the following options:
– CGA option: contains the CGA parameter data structure.
– RSA option: contains signatures.
– Timestamp option: the current time of the device.
l The NS message carries the Nonce option that contains a random number. The NA
message responding to the NS message also carries the same Nonce option.
Timestamp
A SEND-enabled node uses timestamps carried in ND messages to defend against replay
attacks during non-NS/NA message transmission. After SEND is enabled, a node maintains
the Delta and Fuzz parameters, After receiving ND messages, the node checks for message
mis-sequence on RFC 3971 and discards incorrect messages.
Nonce
Nonce is a random value that serves as a label of a current session. Nonce is used to defend
against replay attacks during NS/NA message transactions. A node generates a random value
and adds it to NS messages before sending the NS messages to request link-layer addresses of
other nodes. After receiving the NS messages, the receivers send NA messages that carry the
same random value in the received NS messages.

Router Authorization
To prevent attackers from sending packets in the name of routers, SEND introduces CPS and
CPA messages to verify router identities.
Routers must apply for certificates from the Certificate Authority (CA). The certificates
contain routers' identity information, public keys, and CA digital signatures.
In the stateless address autoconfiguration scenario, after receiving an RA message, a host

sends a CPS message to request the certificate of a router. The router responds by sending its
certificate in a CPA message. After receiving the CPA message, the host attempts to
authenticate the certificate and considers the router as a default router only after the certificate
is successfully authenticated.
4.12.3 Configuring IPv6 ND

This section describes how to configure IPv6 ND.
4.12.3.1 Configuring a Static Neighbor

A neighbor relationship can be established between a local device and its neighbor after a
neighbor is manually configured.
Prerequisites
Before configuring a static neighbor, configure the IPv6 address for an interface.
Procedure
system-view

Step 3 Run one of the following commands as required:

l To configure a static neighbor entry on a common Layer 3 interface, run the ipv6
neighbor ipv6-address mac-address command.
l To configure a static neighbor entry on a VLANIF interface, run the ipv6 neighbor ipv6-
address mac-address vid vlan-id interface-type interface-number command.
l To configure a static neighbor entry on a sub-interface for QinQ VLAN tag termination
or Dot1q VLAN tag termination, run the ipv6 neighbor ipv6-address mac-address vid
vid [ cevid cevid ] command.
NOTE
If an interface is configured with dynamic QinQ, you cannot configure a static neighbor entry on
it.
Static neighbors can be configured for Ethernet, GE,and Eth-Trunk interfaces and their sub-
interfaces. You can configure up to 300 neighbors on each interface.
----End

Follow-up Procedure
Run the display ipv6 neighbors command to check the cache of the neighbor information
containing neighbors' IPv6 addresses and the specified interfaces.
<sysname> display ipv6 neighbors gigabitethernet 1/0/0
--------------------------------------------------------
IPv6 Address : 2001:DB8::2
Link-layer : 00e0-fc89-fe6e State : STALE
Interface : GE1/0/0 Age : 00h19m12s
VLAN : - CEVLAN: -
VPN name : vpn1 Is Router: TRUE
Secure FLAG : UN-SECURE
---------------------------------------------------------
Total: 1 Dynamic: 1 Static: 0
4.12.3.2 Configuring RA Message Advertisement

If no limit is set on RA message advertisement, a device periodically advertises RA messages,
which contain the prefix option and flag bits, to announce the existence of itself.
Procedure
system-view

Step 3 Enable the interface to advertise RA messages.

undo ipv6 nd ra halt
----End
Follow-up Procedure
Run the display ipv6 interface command to view the interval at which RA messages are
advertised.
<sysname> display ipv6 interface GigabitEthernet 1/0/1
UP

UP

FE80::2A6E:D4FF:FE48:3EF
Global unicast
address(es):
3000::1, subnet is
3000::/64
Joined group
address(es):
FF02::1:FF00:1

FF02::2
FF02::1
FF02::1:FF48:3EF
MTU is 1500
bytes

1

milliseconds

milliseconds
ND stale time is 1200

seconds
ND advertised reachable time is 0

milliseconds
ND advertised retransmit interval is 0

milliseconds
ND router advertisement max interval 600 seconds, min interval 200

seconds
ND router advertisements live for 1800
seconds
ND router advertisements hop-limit

64
ND default router preference

medium
Hosts use stateless autoconfig for addresses
4.12.3.3 Setting the Interval for Advertising RA Messages

The device periodically sends router advertisement messages containing information such as
prefixes and flag bits.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ipv6 nd ra { max-interval maximum-interval | min-interval minimum-interval }
The interval for advertising Router Advertisement(RA) messages is configured.

By default, the maximum interval is 600 seconds, and the minimum interval is 200 seconds.

The maximum interval cannot be shorter than the minimum interval.
When the maximum interval is less than 9 seconds, the minimum interval is set to the same
value as the maximum interval.
----End
4.12.3.4 Configuring the Address Prefixes to Be Advertised

Nodes of the local links can perform address auto-configuration by using prefixes of these
addresses.
Procedure
Step 1 Run:
system-view
Step 2 Run:

ipv6 nd ra prefix default no-advertise
RA messages are configured not to carry the default prefix generated based on the interface
IPv6 address.
By default, RA messages carry the default prefix generated based on the interface IPv6
address.
Step 4 Run:
ipv6 nd ra prefix { ipv6-address ipv6-prefix-length | ipv6-prefix/ipv6-prefix-
length } valid-lifetime preferred-lifetime [ no-autoconfig ] [ off-link ]
The prefix of Router Advertisement(RA) messages is configured.
The prefix configuring using the ipv6 nd ra prefix command takes precedence over the
default prefix generated based on the interface IPv6 address. An RA message can carry a
maximum of 10 prefixes. If exactly 10 prefixes have been manually configured, the default
prefix will not be carried.
NOTE
If stateless address allocation is used, you must specify the prefix length as 64. Otherwise, the address
does not take effect, and RA messages will be discarded.
----End
4.12.3.5 Configuring Other Information to Be Advertised

A FW advertisement message carries information such as the maximum number of hops,
prefix option, neighbor hold time, and keepalive time.

Context
Duplicate Address Detect (DAD) is a process of IPv6 automatic address configuration. You
can configure the number of DAD messages which are sent continuously.
Set the interval of sending Neighbor Solicitation (NS) messages on the device.
Neighbor Unreachability Detection (NUD) checks the reachability of neighbors.
The MTU of the interface determines whether to fragment IP packets on the interface.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 nd hop-limit limit
ND hop limit is configured.

The value of limit ranges from 1 to 255. By default, it is 64.
Step 3 Run:

Step 4 Run:
ipv6 nd ra hop-limit limit
ND hop limit is configured.

The value of limit ranges from 0 to 255. By default, it is 64.
NOTE
l If the ipv6 nd ra hop-limit command has been run on an interface, the hop limit for an Router
Advertisement(RA) message uses the value configured on the interface.
l If the ipv6 nd ra hop-limit command has not been run on an interface, the hop limit for an RA
message uses the value configured globally, that is, the value configured in the ipv6 nd hop-limit
command.
Step 5 Run:
ipv6 nd ra router-lifetime ra-lifetime
The life duration of RA messages is configured.
NOTE
l When the ipv6 nd ra command is run to set the interval for advertising RA messages, the interval
must be less than or equal to the life duration.
l By default, the maximum interval is 600 seconds, and the minimum interval is 200 seconds.
l By default, the life duration of RA messages is 1800 seconds. If the prefix is configured, the
duration is still 1800 seconds.
Step 6 Run:
ipv6 nd dad attempts value
Times to send DAD messages are configured.

Step 7 Run:
ipv6 nd ns retrans-timer interval
The interval for re-sending NS messages is set.

By default, NS re-transmitting time interval is 1000ms.
Step 8 Run:
ipv6 nd nud reachable-time value
The NUD reachable time is set.

By default, NUD value is 30000ms.
Step 9 Run:
ipv6 mtu mtu
MTU of the interface is configured.

Default MTUs vary with interface types. The MTU on an Ethernet or GigabitEthernet
interface defaults to be 1500 bytes.
Step 10 Run:
ipv6 nd neighbor-limit
The maximum number of dynamic neighbor entries that can be learned by a specified
interface is configured.
By default, an interface can learn a maximum of 1024 dynamic neighbor entries.
NOTE
You can set a maximum number of neighbor entries that can be learned by a VLANIF interface
dynamically using the ipv6 nd neighbor-limit command. The ipv6 nd neighbor-limit command takes
effect only on a VLANIF interface.
----End
4.12.3.6 Configuring the Default Router Priority and Route Information

Router Advertisement(RA) packets that carry the default router priority and route information
can be transmitted over the local link. In this manner, a proper router can be selected to
forward packets of a host.
Context
If a host is connected to multiple routers, the host must select a router to forward packets
based on the destination addresses of packets. The FW can advertise the default router priority
and specified route information to the host so that the host can select a proper forwarding
router based on the destination addresses of packets.
After receiving the RA packets carrying the route information, the host updates its routing
table. When sending packets to another device, the host queries the routing table and selects a
proper route to send packets.
When receiving the RA packets that carry the priority of default routers, the host updates its
default router table. When sending packets to another device, if there is no route to be
selected, the host queries the default router table. Then, the host selects a router with the
highest priority on the local link to send packets. If the router is faulty, the host selects another
router in descending order of priority.

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ipv6 nd ra preference { high | medium | low }
The default router priority is configured in RA packets.

Step 4 Run:
ipv6 nd ra route-information ipv6-address prefix-length lifetime route-lifetime
[ preference { high | medium | low } ]
Route information is configured in RA packets.
----End
4.12.3.7 Enabling IPv6 ND Strict Learning

This section describes how to enable IPv6 neighbor discovery (ND) strict learning to comply
with RFC 4861.
Context
A device uses neighbor advertisement (NA) packets to establish neighbor entries, which does
not comply with RFC 4861. To comply with RFC 4861, enable IPv6 ND strict learning. After
you enable IPv6 ND strict learning on a device, the device uses NA packets only in response
to neighbor solicitation (NS) packets to establish neighbor entries.
Procedure
l Enable IPv6 ND strict learning globally.
a. Run:
system-view

b. Run:
ipv6 nd learning strict
IPv6 ND strict learning is enabled globally.

l Enable IPv6 ND strict learning in the interface view.
a. Run:
system-view

b. Run:

NOTE
This command applies only to VLANIF interfaces, Eth-Trunk interfaces and Eth-trunk sub-
interfaces.
c. Run:
ipv6 nd learning strict { force-disable | force-enable | trust }
IPv6 ND strict learning is forcibly enabled on the interface.
----End
4.12.3.8 Setting an Aging Time for Neighbor Entries in the Stale State
This section describes how to set an aging time for neighbor entries in the stale state. A short
aging time allows the device to delete neighbor entries in the stale state quickly.
Procedure
l Set an aging time for a neighbor entry in the stale state in the system view.
a. Run:
system-view

b. Run:
ipv6 nd stale-timeout timeout-value
An aging time is set for a neighbor entry in the stale state.
The default aging time of neighbor entries in the stale state is 1200s in the system
view.
l Set an aging time for a neighbor entry in the stale state in the interface view.
a. Run:
system-view

b. Run:

c. Run:
ipv6 nd stale-timeout timeout-value
An aging time is set for a neighbor entry in the stale state on the interface.
By default, no aging time is set for neighbor entries in the stale state in the interface
view, and all interfaces use the global configuration.
----End
4.12.4 Configuring IPv6 SEND

The SEcure Neighbor Discovery (SEND) protocol is a security extension of the Neighbor
Discovery Protocol (NDP) in IPv6.

4.12.4.1 Configuring the CGA

The CGA is an IPv6 address generated using a public key and the hash algorithm. Two
communication parties can authenticate the CGA of each other to defend against spoofing
attacks. The Revist-Shamir-Adleman Algorithm (RSA) can be used to protect packet integrity.
Context
The procedure for generating the CGA and RSA signature on a node is as follows:
1. Obtains an RSA key pair.

2. Generates CGA parameters data structure, including a public key.
3. Computes the hash value based on the CGA parameters data structure, with the last 64-
bit of the value as a network ID.
4. Generates the CGA based on the prefix and network ID.
5. Forges a packet with the CGA as a source IP address, fills the CGA parameters data
structure in the CGA option, assigns the packet a private key, and fills a signature in the
RSA option.
After receiving a packet with CGA and RSA options, a node authenticates the packet as
follows:
1. Obtains the CGA parameters data structure from the CGA option.
2. Computes the hash value based on the CGA parameters data structure, with the last 64-
bit of the value as a network ID.
3. Check whether the generated network ID matches that in the source IP address of the
packet.
4. Obtains the public key from the CGA parameters data structure to authenticate the RSA
signature.
After CGAs are generated, the interface sends ND packets based on the following rules:
l The CGA is a source IP address of the NS (excluding DAD messages), NA, RA, and
Redirect messages sent by the interface.
l The NS, NA, RA, and Redirect messages sent by the interface all carry the following
information:
– CGA option: contains the CGA parameters data structure
– RSA option: contains signatures.
– Timestamp option: represents the current time of the device.
l The NS message sent by the interface carries the Nonce option containing a random
number. The NA message replied by the interface also carries the Nonce option
containing the Nonce value in the received NS message.
NOTE
Content in the Timestamp and Nonce options is automatically generated.
Procedure
system-view

Step 2 Set the local public and private key pair.
rsa local-key-pair create
NOTICE
After the command is executed, you are prompted to enter the length of host key. To enhance
security, the length of host key is recommended to be longer than 1024 bits.

Step 4 Run:
ipv6 security rsakey-pair key-label
The RSA key pair is bound to the interface to generate a CGA address.
Step 5 Run:
ipv6 security modifier sec-level sec-value [ modifier-value ]
The modifier value and security level are configured for the CGA address.
The modifier value can be manually configured only when the security level of the CGA
address is 0.
Step 6 Run:
ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length } cga
Or
ipv6 address ipv6-address link-local cga
A CGA IPv6 address is configured.
----End
Follow-up Procedure
Run the ipv6 nd security strict command to enable the strict security mode on the interface.
NOTE
If a local device is enabled with the strict security mode whereas the remote device is not, the local
device considers the messages sent by the remote device invalid and discards them.
4.12.4.2 Configuring Strict IPv6 SEND

After the rate limit for processing received ND messages, the key length allowed on the
interface, and the timestamp in the ND messages are set, the system considers the received
ND messages that do not meet these requirements invalid.
Context
When working in strict security mode, an interface regards the received ND message insecure
and discards it in the following cases:

l The rate of processing the received ND message exceeds the rate limit of the system.
l The key length in the received ND message is out of the length range allowed on the
interface.
l The difference between the receive time and the send time of the ND message is out of
the time range allowed on the interface.
NOTE
On a link, device A is configured with strict IPv6 SEND whereas device B is not. In this case, device A
regards the ND messages sent from device B insecure and rejects them.
Procedure
Step 1 Run:
system-view

ipv6 nd security rate-limit ratelimit-value
The rate limit for processing received ND messages is set.
Step 3 Run:

ipv6 nd security key-length { minimum keylen-value | maximum keylen-value } *
The key length allowed on the interface is set.

ipv6 nd security timestamp { fuzz-factor fuzz-value | delta delta-value | drift
drift-value } *
The timestamp configuration parameters are set
Step 6 Run:
ipv6 nd security strict
The strict security mode is enabled on the interface.
----End
4.12.5 Maintaining ND
After configuring IPv6 ND, you can run the display commands to view the related
configuration. You can also clear configuration information if necessary.
4.12.5.1 Displaying IPv6 ND Configuration

After configuring IPv6 ND, you can run the display commands in any view to view and verify
the ND configuration.
Table 4-59 lists the commands to display the IPv6 ND configuration.

Table 4-59 Displaying IPv6 ND configuration

Action Command
Display IPv6 neighbor display ipv6 neighbors [ ipv6-address | [ vid vlan-id ] interface-
information in the type interface-number ]
cache.
4.12.5.2 Clearing IPv6 ND Information

IPv6 ND cannot restore after you clear it. Exercise caution when using the commands.
Table 4-60 list the commands run in the user view to reset IPv6.
Table 4-60 Clearing IPv6 ND Information

Action Command
Clear IPv6 neighbor reset ipv6 neighbors { all | dynamic | static | vid vlan-id
entries in the cache. [ interface-type interface-number ] | interface-type interface-
number [ dynamic | static ] }

This section provides examples for configuring IPv6 ND and SEND.
4.12.6.1 Example for Configuring Stateless Address Autoconfiguration

This section provides an example for configuring stateless address autoconfiguration. An
interface on a device can automatically obtain an IPv6 address and can communicate with
another device.
FW_A and FW_B are connected on the network shown in Figure 4-90. GigabitEthernet 1/0/1
on FW_A automatically obtains an IPv6 address to communicate with FW_B.
Figure 4-90 Networking diagram for configuring stateless address autoconfiguration

Trust Trust
GE1/0/1
GE1/0/1 3001::1/64
FW_A FW_B

1. Enable stateless address autoconfiguration on FW_A to enable GigabitEthernet 1/0/1 to
automatically obtain an IPv6 address.
2. Configure a global unicast address on FW_B and enable RA advertisement to use an RA
message to advertise an IPv6 prefix to FW_A.
Procedure
# Enable IPv6.
<FW> system-view
[FW] sysname FW_A
[FW_A] ipv6
# Assign a link-local address to GigabitEthernet 1/0/1.

[FW_A-GigabitEthernet1/0/1] ipv6 address auto link-local
# Enable stateless address autoconfiguration.

[FW_A-GigabitEthernet1/0/1] ipv6 address global
# Assign GigabitEthernet 1/0/1 to a Trusted security zone.


[FW_A-policy-security-rule-policy_sec_1] source-zone local trust
[FW_A-policy-security-rule-policy_sec_1] destination-zone trust local

# Enable IPv6.
<FW> system-view
[FW] sysname FW_B
[FW_B] ipv6
# Assign a global unicast address to GigabitEthernet 1/0/1.

[FW_B-GigabitEthernet1/0/1] ipv6 enable
[FW_B-GigabitEthernet1/0/1] ipv6 address 3001::1 64
# Enable RA message advertisement.

[FW_B-GigabitEthernet1/0/1] undo ipv6 nd ra halt
# Assign GigabitEthernet 1/0/1 to a Trusted security zone.



[FW_B-policy-security-rule-policy_sec_1] source-zone local trust
[FW_B-policy-security-rule-policy_sec_1] destination-zone trust local
----End
1. Display the IPv6 address of GigabitEthernet 1/0/1. The IPv6 address prefix is 3001::/64.
Run the display this ipv6 interface command to view the IPv6 address of
GigabitEthernet 1/0/1.
[FW_A-GigabitEthernet1/0/1] display this ipv6 interface
UP
FE80::200:5EFF:FEB5:400
Global unicast
address(es):
3001::200:5EFF:FEB5:400, subnet is
3001::/64
Joined group
address(es):
FF02::1:FFB5:400
FF02::2
FF02::1
MTU is 1500
bytes
1
milliseconds
milliseconds
2. Display default routes in the IPv6 FIB table. The destination address is ::.
# Run the display ipv6 fib command to view the default routes in the IPv6 FIB table.
[FW_A] display ipv6 fib
IPv6 FIB
Table:
Total number of Routes :
5
Destination: ::1 PrefixLength :

128
Nexthop : ::1 Flag :
HU
Label : NULL Tunnel Token :
0
PortIndex : 4278190080 Tunnel ID :
0

TimeStamp : Date- 17:10:2011, Time- 14:28:23 reference :

1
Interface :
InLoopBack0
IP6Token :
0x0
Destination: FE80:: PrefixLength :

10
Nexthop : :: Flag :
BU
0
0
1
Interface :
NULL0
IP6Token :
0x0
Destination: :: PrefixLength : 0
Nexthop : FE80::200:5EFF:FE87:4003 Flag :
GSU
0
0
1
Interface : GigabitEthernet1/0/1
IP6Token :
0x0
Destination: 3001::200:5EFF:FEB5:400 PrefixLength :

128
Nexthop : ::1 Flag :
HU
0
0
1
Interface :
InLoopBack0
IP6Token :
0x0
Destination: 3001:: PrefixLength :

64
Nexthop : 3001::200:5EFF:FEB5:400 Flag :
U
0
0
1
Interface : GigabitEthernet1/0/1
IP6Token :
0x0

#
sysname FW_A
#
ipv6
#
ipv6 enable
ipv6 address autoconfig
#
firewall zone trust
set priority 85
#
security-policy
source-zone local
source-zone trust
action permit
#
return

#
sysname FW_B
#
ipv6
#
ipv6 enable
ipv6 address 3001::1/64
undo ipv6 nd ra halt
#
firewall zone trust
set priority 85
#
security-policy
source-zone local
source-zone trust
action permit
#
return

This section provides IPv6 ND and SEND references.
This section describes the specifications of neighbor discovery.

Receiving Router After a host starts, it sends Supported by all models.

Solicitation (RS) packets an RS packet to a routing
and replying with Router device, and the routing
Advertisement (RA) packets device replies with an RA
packet.
Periodically sending RA Routing devices periodically Supported by all models.

packets advertise router
advertisement (RA) packets
that contain prefix and
identifier information.
Receiving RA packets and - Supported by all models.

replying with ACK packets
Receiving Neighbor An IPv6 node obtains the Supported by all models.

Solicitation (NS) packets link-layer addresses of
and replying with Neighbor neighbors through NS
Advertisement (NA) packets packets, checks the
reachability of the
neighbors, and detects
duplicate addresses.
Receiving NA packets and An IPv6 node sends an NA Supported by all models.

updating the neighbor buffer packet as a reply to an NS
packet. In addition, the IPv6
node can initiatively send an
NA packet upon a link-layer
change.
Duplicate address detection DAD checks the availability Supported by all models.
(DAD) of IPv6 addresses.
Address autoconfiguration - Supported by all models.
Redirection packet When a routing device Supported by all models.

receives a packet with the
same incoming and
outgoing interfaces from a
host, it sends a redirection
packet to instruct the host to
reselect a next-hop address.



This section provides standards and protocols related to IPv6 neighbor discovery (ND) and
security neighbor discovery (SEND).
ND and SEND standards and protocols are as follows:
l RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)

l RFC 2462: IPv6 Stateless Address Autoconfiguration
l RFC 3756: IPv6 Neighbor Discovery (ND) Trust Models and Threats
l RFC 3971: SEcure Neighbor Discovery (SEND)
l RFC 3972: Cryptographically Generated Addresses (CGA)
4.13 IP Performance
This section describes IP performance parameter concepts and how to configure the
parameters.
4.13.1 Overview
On specific networks, IPv4/IPv6 parameters must be adjusted to achieve optimal network
performance.
IPv4 Performance
You can achieve better performance by adjusting parameters of some IPv4 features in
different application scenarios.
IPv4 performance optimization can be performed only after a device is enabled with specific
functions, such as the interface maximum transmission unit (MTU), Internet Control Message
Protocol (ICMP) function, and TCP attributes.
ICMP messages are used by either the IP layer or the higher layer protocol (TCP or UDP).
ICMP error messages require your attention.
IPv6 Performance
Because 32-bit IPv4 addresses may be exhausted, 128-bit IPv6 addresses are increasingly
used. Most IPv6 applications are the same as IPv4 applications. Only some commands,
interface configurations, and parts of applications are different.
IPv6 PMTU
The problem that different networks have different maximum transmission units (MTU) can
be solved in the following ways:

l Devices fragment packets as required. A source host only fragments packets. An

intermediate router not only fragments packets but reassembles packets.
l A source host sends packets based on a proper MTU so that packets do not be
fragmented on an intermediate router. This reduces packet processing burden on the
intermediate router. During IPv6 packet transmission, only this way can be used because
IPv6 intermediate routers do not support packet fragmentation.
The path MTU (PMTU) discovery mechanism aims to discover a proper MTU value on a
path from between the source and destination nodes.
4.13.2 Improving IPv4 Performance

This section describes how to configure IPv4 parameters to improve IPv4 performance.
4.13.2.1 Verifying the Source IPv4 Address

Source IP address verification helps defend against attacks, such as IP spoofing.
Context
IP spoofing enables an attacker changes its own IP address into that of an intranet user or a
trusted external user to obtain information without authorization.
Source IP address verification: After receiving an IP packet, an interface verifies the source IP
address of the packet. If the source IP address does not belong to the network segment on
which the interface resides, the packet is discarded; otherwise, the packet is allowed to pass.
Source IP address verification helps defend against IP spoofing attacks.
Procedure
system-view

Step 3 Enable source IP address verification on the interface.

ip verify source-address
By default, the function is disabled on all interfaces.

If the source IP address of a received packet contains a 31-bit mask, a node considers an IP
address with a 31-bit mask valid, without checking the source IP address.
----End
4.13.2.2 Configuring Direct Forwarding of Fragment Packets

By default, the FW caches fragment packets but supports configurations of direction
forwarding of fragment packets.
Context
When a network device transmits a packet, if the Maximum Transfer Unit (MTU) configured
on the device is shorter than the length of the packet, the packet is fragmented before

transmission. In an ideal case, fragment packets are transmitted in a fixed order. During actual
transmission, the initial fragment packet may not be the first to reach the FW.
To ensure that sessions work normally, the FW supports the fragment cache function by
default. After the fragment cache function is enabled, the system caches the follow-up
fragment packets that reach the firewall earlier than the initial fragment packet. When the
initial fragment packet reaches, the system forwards all the fragment packets. A maximum of
eight follow-up fragment packets can be cached before the initial fragment packet arrives.
You can configure direct forwarding of fragment packets on the FW according to the actual
network situations, instead of caching the fragment packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
firewall fragment-forward enable
Direct forwarding of fragment packets is enabled.
After direct forwarding of fragment packets is enabled, the FW directly forwards fragment
packets rather than caches them.
----End
4.13.2.3 Forwarding Broadcast Packet

This section describes how to configure a FW to forward broadcast packets.
Context
If the device is allowed to receive and forward broadcast packets with destination IP
addresses on the specific network where the interface resides, a hacker can use these packets
to attack the network system. By default, the device cannot receive or forward broadcast
packets with the destination IP addresses on the network segment, on which the interface
resides.
Procedure
system-view

Step 3 Configure the interface to forward broadcast packets.

ip forward-broadcast [ acl acl-number ]
By default, broadcast packets are not forwarded by any interface.
----End

4.13.2.4 Configuring the Maximum Transmission Unit of the Interface

The MTU of an interface determines whether a packet needs to be fragmented when passing
through this interface.
Context
The MTU of the interface has the effects on whether to fragment the packets on the interface.
The default MTU value varies with the interface type. Use the display interface command to
find out the value used.
NOTE
After configuring the MTU on an interface, you must restart the interface; otherwise, the configuration
cannot take effect. To restart the interface, run the restart command or the shutdown and then undo
shutdown commands.
Procedure
system-view

Step 3 Configure the maximum transmission unit of the interface.

mtu mtu
The MTU can be configured on Ethernet, GE, and Eth-Trunk interfaces and their sub-
interfaces, and POS interfaces.
----End
4.13.2.5 Configuring TCP Attributes

Configuring TCP attributes involves the adjustment in the TCP timer, the size of a TCP
sliding window, and TCP Maximum Segment Size (MSS).
Context
The TCP attributes are as follows:
l SYN-WAIT timer
TCP starts the SYN-WAIT timer before sending SYN packets. If no response packets are
received after the SYN-WAIT timer expires, a TCP connection is terminated.
l FIN-WAIT timer
The FIN-WAIT timer starts after a TCP connection changes from FIN_WAIT_1 to
FIN_WAIT_2. If no FIN packets are received after the FIN-WAIT timer expires, a TCP
connection is terminated. If FIN packets are received, the TCP connection changes to the
TIME_WAIT state. If non-FIN packets are received, TCP restarts the SYN-WAIT timer
upon receiving the last non-FIN packet and terminates the TCP connection after the
SYN-WAIT timer expires.
l TCP sliding window size

The TCP sliding window size is size of the buffer for sent and received packets on a TCP
socket.
l MSS
The MSS of a TCP packet is the maximum length allowed for a TCP packet sent from
the peer end to the local end. After a TCP connection is established, both ends notify
each other of their MSSs in TCP packets. After recording the peer end's MSS, the local
end only sends TCP packets smaller than the MSS. If a TCP packet from the peer end is
smaller than the local end's MSS, the packet is not segmented; otherwise, the peer end
must send the packet after segmenting it.
NOTICE
Modifying TCP attributes greatly affects the packet forwarding. Exercise caution when
performing this operation. Unless otherwise specified, use the default values.
Procedure
system-view
Step 2 Set the SYN-WAIT timer of setting up TCP connections.

tcp timer syn-timeout interval
The default SYN-WAIT time is 75 seconds.
Step 3 Set the FIN_WAIT timer of setting up TCP connections.

tcp timer fin-timeout interval
The default FIN-WAIT time is 675 seconds.
Step 4 Set the TCP window size of the TCP socket.

tcp window window-size
The default size is 8 KB.
Step 5 Set the MSS of TCP packets.

firewall tcp-mss mss-value
The default MSS is 1460 bytes.
The MSS is equal to the interface MTU deducted by 40 bytes (20-byte IP header and 20-byte
TCP header). If Point-to-Point Protocol over Ethernet (PPPoE) dialup is used, additional 8
bytes (PPPoE header) must be deducted. The interface MTU deducted by 48 bytes is the MSS
value.
For example:
If the interface MTU changes from 1500 bytes to 1450 bytes, the new MSS must be 1410
bytes (1450-20-20).
If the interface MTU is 1500 and PPPoE dialup is used, the MSS must be set to 1452 bytes
(1500-20-20-8).

NOTE
The firewall tcp-mss command only takes effect on subsequent TCP connections, not established ones.
----End
4.13.3 Improving IPv6 Performance

This section describes how to configure IPv6 parameters to improve IPv6 performance.
4.13.3.1 Configuring ICMPv6 Attributes

If many ICMPv6 error packets are sent on the network within a short period, network
congestion may occur. To prevent this situation, you can set the maximum number of ICMPv6
error packets that can be sent within a specified period.
Context
ICMPv6 error packets can be classifiedinto the following types:
l Destination unreachable error packet

Unreachable destination packets are as follows:
– No route to the destination
– Address unreachable
– Port unreachable
NOTE
Only port unreachable messages are supported.

l Datagram Too Big message
l Timeout error packet
l Parameter error packet
Procedure
system-view
Step 2 Set the capacity of the token bucket and refreshing cycle for sending ICMPv6 error packets.
ipv6 icmp-error { bucket bucket-size | ratelimit interval } *
----End
4.13.3.2 Configuring TCPv6 Attributes

This section describes how to configure IPv6 TCP attributes, including the SYN-Wait timer,
FIN-Wait timer, and buffer size.
Context
For details on the SYN-Wait timer, FIN-Wait timer, and buffer size of TCP attributes, see
Configuring TCP Attributes.

Procedure
system-view
Step 2 Set the TCP6 SYN-WAIT timer.

tcp ipv6 timer syn-timeout timer-value
The default SYN-WAIT time is 75s.

Step 3 Set the TCP6 FIN-WAIT timer.
tcp ipv6 timer fin-timeout timer-value
The default FIN-WAIT time is 675s.

Step 4 Set the size of the TCP IPv6 packet sending/receiving buffer.
tcp ipv6 window window-size
The default size of the TCP IPv6 packet sending/receiving buffer is 8 KB.
----End
4.13.3.3 Configuring a PMTU

This section describes now to set a path maximum transmission unit (PMTU) on an interface.
This setting enables a device to send packets based on proper MTUs across a network. This
helps prevent packet fragmentation, reduce the burden of the devices, and efficiently use
network resources.
Setting an IPv6 MTU on an interface

Context
The MTU on an interface determines whether IP packets on the interface need to be
fragmented.
The default value of the MTU on an interface varies with the interface type.

system-view

Step 3 Set the IPv6 MTU on the interface.

ipv6 mtu mtu
----End
Follow-up Procedure
If the IPv6 MTU value is changed, run the shutdown command and the undo shutdown
command in the interface view to make the configuration take effect.
Run the display ipv6 interface command to view the current IPv6 MTU on the interface.
<sysname> display ipv6 interface GigabitEthernet 1/0/1
IPv6 protocol current state : UP
IPv6 is enabled, link-local address is FE80::222:A1FF:FE00:2259

Global unicast address(es):

2001:1::1:1, subnet is 2001:1::/64
Joined group address(es):
FF02::1:FF01:1
FF02::1:FF00:2259
FF02::2
FF02::1
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND retransmit interval is 1000 milliseconds
Creating Static PMTU Entries

Context
Static PMTU entries are manually configured and do not age.

system-view
Step 2 Set the PMTU value of a specified IPv6 address.

ipv6 pathmtu ipv6-address [ path-mtu ]
By default, the PMTU of an IPv6 address is 1500 bytes.
----End
Follow-up Procedure
Run the display ipv6 pathmtu static command to view information about static PMTU
entries.
<sysname> display ipv6 pathmtu static
IPv6 Destination Address ZoneID PathMTU LifeTime(M) Type FF
2001:1::1:2 0 1500 - Static No
-------------------------------------------------------------------------------
Static: 1
Configuring the PMTU Aging Time

Context
The PMTU aging time is used to change the lifetime of a PMTU entry in the cache.

system-view
Step 2 Set the PMTU aging time.

ipv6 pathmtu age age-time
By default, the dynamic PMTU aging time is 10 minutes.
----End
Follow-up Procedure
Run the display ipv6 pathmtu dynamic command to view information about the dynamic
PMTU entries.
<sysname> display ipv6 pathmtu dynamic
IPv6 Destination Address ZoneID PathMTU LifeTime(M) Type

FF
fe80::12 0 1300 40 Dynamic
YES
-------------------------------------------------------------------------------
Total: 1 Dynamic: 1 Static: 0
4.13.4 Maintaining IP Performance

After configuring IP performance, you can run the display commands to view the
configuration. You can also clear statistics or enable the debugging function if necessary.
4.13.4.1 Checking IP Performance Configuration

After configuring IP performance, you can run the display commands in any view to view and
verify the related configuration.
Table 4-61 lists the commands to display the IP performance configuration.
Table 4-61 Displaying IP performance configuration

Action Command
Display the TCP display tcp status

connection status.
Display TCP traffic display tcp statistics

statistics.
Display UDP traffic display udp statistics

statistics.
Check the IP traffic display ip statistics

statistics.
Display ICMP traffic display icmp statistics

statistics.
Display current socket display ip socket [ monitor ] [ task-id task-id socket-id socket-
information. id | sock-type socket-type ]
Display TCP IPv6 display tcp ipv6 statistics

statistics.
Display the TCP IPv6 display tcp ipv6 status

connection status.
Display UDP IPv6 display udp ipv6 statistics

statistics.
Display information display ipv6 socket [ socktype socket-type | task-id task-id

about the socket. socket-id socket-id ]
Display PMTU display ipv6 pathmtu { ipv6-address | all | dynamic | static }

entries.

Action Command
Display IPv6 display ipv6 interface [ interface-type interface-number | brief ]

information about the
interface.
4.13.4.2 Clearing IP Performance Statistics

IP performance statistics cannot be restored after you clear it. Exercise caution when
performing this operation.
Table 4-62 list the commands run in the user view to clear IP performance statistics.
Table 4-62 Clearing IP performance statistics

Action Command
Clear the IP statistics. reset ip statistics [ interface interface-type interface-number ]
Clear information on reset ip socket monitor

the socket monitor.
Clear TCP traffic reset tcp statistics

statistics.
Clear UDP traffic reset udp statistics

statistics.
Clear IPv6 PMTU reset ipv6 pathmtu { all | dynamic | static }

entries in the cache.
Clear all TCPv6 reset tcp ipv6 statistics

statistics.
Clear all UDPv6 reset udp ipv6 statistics

statistics.

This section provides IP performance references.
This section describes the specifications of IP performance.
Verifying the source IPv4 - Supported by all models.

address

Direct forwarding of - Supported by all models.

fragment packets
Forwarding broadcast - Supported by all models.

packet
Configuring the maximum - Supported by all models.

transmission unit of the
Interface
Configuring ICMP attributes - Supported by all models.
Configuring TCP attributes - Supported by all models.
Configuring ICMPv6 - Supported by all models.

attributes
Configuring TCPv6 - Supported by all models.

attributes
Maximum number of public PMTU entries l USG6000V: 64
Maximum number of public static PMTU l USG6000V: 64

entries
Maximum number of PMTU entries for 96

each VPN instance
Maximum number of static PMTU entries 32

for each VPN instance
Maximum number of PMTU entries shared 30000

by all VPN instances

This section describes the versions and changes in the IP performance.

Administrator Guide 5 Routing
5 Routing
About This Chapter
This chapter describes the concepts of router and their configuration.
5.1 Routing Protocol Overview

Routing is the process of directing packets from a source node to a destination node along a
path.
5.2 Routing Basics Configuration
This section describes basic functions used by various routing procotols, for example, the
address prefix list and routing table.
5.3 IP Static Route
Static routes are mainly applied to simply-structured IP networks.
5.4 RIP
This section describes Routing Information Protocol (RIP) concepts and how to configure
RIP, as well as provides configuration examples.
5.5 RIPng
RIPng is mainly applied to small and simply-structured IPv6 networks. RIPng is a routing
protocol based on the distance vector and adopts the hop count to measure the distance to the
destination.
5.6 OSPF
This section describes the basic concepts and configuration of Open Shortest Path First
(OSPF) and provides OSPF configuration examples.
5.7 OSPFv3
By building Open Shortest Path First Version 3 (OSPFv3) networks, you can enable OSPFv3
to discover and calculate routes in ASs. OSPFv3 is applicable to a large-scale network that
consists of hundreds of routers.
5.8 IS-IS
Intermediate System to Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP)
and runs at the link layer. IS-IS features rapid aggregation and a hierarchical structure. IS-IS is
widely used on large-scale carrier networks.
5.9 IPv6 IS-IS

IS-IS supports multiple types networking layer protocols, including IPv6. In an IPv6 network,
you can implement interconnection by configuring IS-IS.
5.10 BGP
BGP is used between ASs to transmit routing information on large-scale and complex
networks.
5.11 BGP4+
BGP4+, which is applicable to the large-scale IPv6 network with a complicated structure, is
used between ASs to transmit routing information.
5.12 Routing Policy
Routing policies are used to filter routes to change the path through which network traffic
passes.

5.1 Routing Protocol Overview

Routing is the process of directing packets from a source node to a destination node along a
path.
5.1.1 Overview
Routing is the basic element of data communication networks. It is the process of selecting
paths on a network along which packets are sent from a source to a destination.
Routes are classified into the following types based on the destination address:
l Network segment route: The destination is a network segment. The subnet mask of an
IPv4 destination address is less than 32 bits or the prefix length of an IPv6 destination
address is less than 128 bits.
l Host route: The destination is a host. The subnet mask of an IPv4 destination address is
32 bits or the prefix length of an IPv6 destination address is 128 bits.
Routes are classified into the following types based on whether the destination is directly
connected to a router:
l Direct route: The router is directly connected to the network where the destination is
located.
l Indirect route: The router is indirectly connected to the network where the destination is
located.
Routes are classified into the following types based on the destination address type:
l Unicast route: The destination address is a unicast address.
l Multicast route: The destination address is a multicast address.
5.1.2 Static Routes and Dynamic Routes

FW support static routes and dynamic routes including Routing Information Protocol (RIP)
routes, Open Shortest Path First (OSPF) routes, Intermediate System-to-Intermediate System
(IS-IS) routes, and Border Gateway Protocol (BGP) routes.
Differences Between Static Routes and Dynamic Routes

Routing protocols are the rules used by routers to discover routes, generate and maintain
routing tables, and guide packet forwarding. Routes are classified into the following types
based on the origin:
l Direct route: is discovered by link layer protocols.
l Static route: is manually configured by network administrators.
l Dynamic route: is discovered by dynamic routing protocols.
Static routes are easy to configure, have low requirements on the system, and apply to simple,
stable, and small networks. The disadvantage of static routes is that they cannot automatically
adapt to network topology changes. Therefore, static routes require subsequent maintenance.
Dynamic routing protocols have their routing algorithms. Therefore, dynamic routes can
automatically adapt to network topology changes and apply to the networks on which Layer 3

devices are deployed. The configurations of dynamic routes are complex. Dynamic routes
have higher requirements on the system than static ones and consume network resources and
system resources.
Classification of Dynamic Routing Protocols

Based on the application range, dynamic routing protocols are classified into the following
types:
l Interior Gateway Protocol (IGP): runs inside an AS, such as RIP, OSPF, and IS-IS.
l Exterior Gateway Protocol (EGP): runs between different ASs, such as BGP.
Based on the type of algorithm they use, dynamic routing protocols are classified into the
following types:
l Distance-vector routing protocol: includes RIP and BGP. BGP is also called path-vector
protocol.
l Link-state routing protocol: includes OSPF and IS-IS.
The preceding algorithms differ mainly in route discovery and calculation methods.
5.1.3 Default Routes

Default routes are special routes. Generally, administrators can manually configure default
static routes. Default routes can also be generated through dynamic routing protocols such as
OSPF and IS-IS.
Default routes are used only when packets to be forwarded have no matching routing entry in
a routing table. In the routing table, a default route is the route to the network 0.0.0.0 (with the
mask also being 0.0.0.0). You can check whether the default route is configured by using the
display ip routing-table command.
If the destination address of a packet does not match any entry in the routing table, the packet
is sent through a default route. If no default route exists and the destination address of the
packet does not match any entry in the routing table, the packet is discarded. An Internet
Control Message Protocol (ICMP) packet is then sent, informing the originating host that the
destination host or network is unreachable.
5.1.4 Routing Table and FIB Table

The routing table is used to select routes, and the Forwarding Information Base (FIB) is used
to guide packet forwarding. Each router maintains one routing table and one FIB table at least.
Routes discovered by various routing protocols are stored in the routing table. According to
the sources, the routes in the routing table are divided into the following types:
l Directly connected route or interface route
The directly connected route, in another word, the interface route, refers to the route
discovered by the link layer protocols.
l Static route
The static route refers to the route manually configured by the network administrator.
l Dynamic route
The dynamic route refers to the route dynamically discovered by dynamic routing
protocols.

Each entry in the FIB table contains the physical or logical interface through which a packet is
sent to a network segment or a host, and then it can reach the next router. Besides, the entry
also indicates that the packet can be directly sent to a destination host in the directly
connected network.
Routing Table
Each router maintains the protocol routing table for each protocol and a local core routing
table (or routing management table).
l Protocol routing table
A protocol routing table stores the routing information discovered by the protocol.
A routing protocol can import and advertise the routes that are discovered by other
protocols. For example, if a router that runs the Open Shortest Path First (OSPF)
protocol needs to use OSPF to advertise direct routes, static routes, or Intermediate
System-Intermediate System (IS-IS) routes, the router must import the routes to the
OSPF routing table.
l Local core routing table
A router uses the local core routing table to store protocol routes and preferred routes.
The router then delivers the preferred routes to the FIB table to guide the packets
forwarding.
The router selects routes according to the priorities of protocols and costs in the routing
table. You can run the display ip routing-table command to view the local core routing
table of a router.
NOTE
The router that supports the Layer 3 Virtual Private Network (L3VPN) maintains a local core
routing table for each VPN instance.
Contents of the Routing Table

In the FW, by running the display ip routing-table command, you can view the brief routing
table of the router as below:
<FW> display ip routing-table
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 D 10.1.4.2 GigabitEthernet1/0/0

10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/1
10.1.4.0/30 OSPF 10 0 D 10.1.4.1 GigabitEthernet1/0/0
10.1.4.2/32 OSPF 10 0 D 10.1.4.2 GigabitEthernet1/0/0
A routing table has the following key entries:

l Destination address: is used to identify the destination IP address or the destination
network address of an IP packet.
l Network mask: is combined with the destination address to identify the address of the
network segment where the destination host or router resides.

– The network address of the destination host or the router is obtained through the
"AND" operation on the destination address and network mask. For example, if the
destination address is 10.1.1.1 and the mask is 255.255.255.0, the address of the
network where the host or the router resides is 10.1.1.0.
– The network mask is composed of several consecutive 1s. These 1s can be
expressed either in the dotted decimal notation or in the number of consecutive 1s
in the mask. For example, the network mask can be expressed either as
255.255.255.0 or as 24.
l Proto: indicates the protocol through which routes are learned.
l Pre: indicates the preference added to the IP routing table for a route. To the same
destination, multiple routes with different next hops and outgoing interfaces exist. These
routes may be discovered by different routing protocols, or they may just be the
manually configured static routes. The route with the highest preference (the smallest
value) is selected as the optimal route.
l Cost: indicates the route cost. When multiple routes to the same destination have the
same preference, the route with the smallest cost is selected as the optimal route.
NOTE
Preference is used to compare the preferences of various routing protocols, while cost is used to
compare the preferences of different routes of the same routing protocol.
l NextHop: indicates the IP address of the next router that an IP packet passes through.
l Interface: indicates the outgoing interface through which an IP packet is forwarded.
According to the destination, the routes can be divided into the following types:
l Subnet route: The destination is a subnet.
l Host route: The destination is a host.
In addition, based on whether the destination is directly connected to the router or not, routes
fall into the following types:
l Direct route: The router is directly connected to the network in which the destination
resides.
l Indirect route: The router is not directly connected to the network in which the
destination resides.
You can set a default route to reduce the number of entries in the routing table. All the packets
that fail to match entries in the routing table are forwarded through this default route. For
example, in the preceding routing table, the route whose destination address is 0.0.0.0/0 is a
default route.
As shown in Figure 5-1, FW_A is connected with three networks, so it has three IP addresses
and three physical interfaces. Figure 5-1 shows the routing table of FW_A.

Figure 5-1 Routing table
10.10.0.0/8
Destination Nexthop Interface 10.1.1.2/24 Router_B

10.10.0.0/8 10.1.1.2 GE1/0/0
10.20.0.0/8 10.2.2.2 GE2/0/0
GE1/0/0
10.30.0.0/8 10.3.3.2 GE3/0/0
10.1.1.1/24
GE2/0/0 GE3/0/0
10.2.2.1/24 10.3.3.1/24
FW_A
Router_C Router_D
10.2.2.2/24 10.3.3.2/24
10.20.0.0/8 10.30.0.0/8
Matching of FIB Table

After the route selection is complete, routers deliver the active routes in the routing table to
the FIB table. When receiving a packet, routers search the FIB table for the optimal route to
forward the packet.
The matching of the FIB table complies with the longest match. When searching the FIB
table, routers perform the "AND" operation on the destination address in the packet and the
network mask of each entry in the FIB table. routers then compare the result of the "AND"
operation with the entries in the FIB table. According to the comparison, routers choose the
optimal route to forward packets according to the longest match.
For example, the brief routing table of a router is as follows:
Routing Tables:
0.0.0.0/0 Static 60 0 D 10.0.0.2
172.16.0.0/16 RIP 100 3 D 10.0.0.2
10.0.0.0/8 OSPF 10 50 D 10.2.0.2
10.1.0.0/16 RIP 100 4 D 10.0.0.2
192.168.1.0/24 Direct 0 0 D 10.2.0.2

NOTE
The complete routing table contains active routes and inactive routes. The brief routing table contains
only active routes. You can run the display ip routing-table verbose command to view the complete
routing table.
After receiving a packet that carries the destination address 10.1.2.1, a router searches the
following table:
FIB Table:
Total number of Routes : 5
Destination/Mask Nexthop Flag TimeStamp Interface
TunnelID
0.0.0.0/0 10.0.0.2 SU t[37] GigabitEthernet1/0/0
0x0
172.16.0.0/16 10.0.0.2 DU t[37] GigabitEthernet1/0/0
0x0
0x0
0x0
192.168.1.0/24 10.2.0.1 U t[9992] GigabitEthernet1/0/1
0x0
The FW performs the "AND" operation on the destination address 10.1.2.1 and the masks 0,
8, 16, and obtains the network segment addresses: 0.0.0.0/0, 10.0.0.0/8, and 10.1.0.0/16. The
three addresses match the three entries, namely, 0.0.0.0/0, 10.0.0.0/8, and 10.1.0.0/16. At last,
the FW chooses the 10.1.0.0/16 entry according to the longest match and forwards the packet
through Pos 2/0/0.
5.1.5 Routing Protocol Preference

This section describes the preferences of all the routing protocols.
Routing protocols (including the static route) can learn different routes to the same
destination, but not all routes are optimal. Only one routing protocol at one time determines
the optimal route to a destination. To select the optimal route, each routing protocols
(including the static route) is configured with a preference (the smaller the value, the higher
the preference). When multiple routing information sources coexist, the route with the highest
preference is selected as the optimal route (the smaller the value is, the higher the preference
is). Table 5-1 lists the routing protocols and the default preferences of routes found by each
protocol.
In Table 5-1, 0 indicates the direct route, and 255 indicates any route learned from unreliable
sources.
Table 5-1 Routing protocols and their default preferences
Routing Protocol or Route Type Route Preference
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100

OSPF AS-External (ASE) 150
OSPF Not-So-Stubby Area (NSSA) 150
IBGP 255
EBGP 255
Except for direct routes, you can manually configure a routing protocol's preference. In
addition, the preference for each static route can be distinct from the other routes.
The FW also defines the external preference and internal preference. External preference is
the preference set by a user for each routing protocol. Table 5-1 shows the default external
preference.
If different routing protocols are configured with the same preference, the system determines
which routes discovered by these routing protocols become the preferred routes through an
internal preference. Table 5-2 shows the internal preferences of routing protocols.
Table 5-2 Internal preferences of routing protocols

DIRECT 0
OSPF 10
IS-IS Level-1 15
IS-IS Level-2 18
STATIC 60
UNR 65
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 200
EBGP 20
For example, two routes, an OSPF route and a static route, can reach the destination
10.1.1.0/24, and the preferences of both routes are set to 5. In this case, the FW determines the
optimal route according to the internal preferences listed in Table 5-2. The internal preference
value 10 of OSPF is higher than the internal preference value 60 of the static route. Therefore,
the system selects the route discovered by OSPF as the optimal route.

5.1.6 Route Import

Different routing protocols can import routes from each other.
Different routing protocols may discover different routes because they use different
algorithms. If multiple routing protocols run on a large network, the routing protocols need to
re-advertise the routes they discover.
Each routing protocol can import the routes discovered by other routing protocols, direct
routes, and static routes using its mechanism.
5.1.7 Route Metric

A route metric specifies the cost of a route to a specified destination address.
The following factors often affect the route metric:
l Path length
The path length is the most common factor affecting the route metric. Link-state routing
protocols allow you to assign a link cost for each link to identify the path length of a
link. In this case, the path length is the sum of link costs of all the links that packets pass
through. Distance-vector routing protocols use the hop count to identify the path length.
The hop count is the number of devices that packets pass through from the source to the
destination. For example, the hop count from a router to its directly connected network is
0, and the hop count from a router to a network that can be reached through another
router is 1. The rest can be deduced in the same manner.
l Network bandwidth
The network bandwidth is the transmission capability of a link. For example, a 10-
Gigabit link has a higher transmission capability than a 1-Gigabit link. Although
bandwidth defines the maximum transmission rate of a link, routes over high-bandwidth
links are not necessarily better than routes over low-bandwidth links. For example, when
a high-bandwidth link is congested, forwarding packets over this link will require more
time.
l Load
The load is the degree to which a network resource is busy. You can calculate the load by
calculating the CPU usage and packets processed per second. Monitoring the CPU usage
and packets processed per second continually helps learn about network usage.
l Communication cost
The communication cost measures the operating cost of a route over a link. The
communication cost is another important indicator, especially if you do not care about
network performance but the operating expenditure.
5.1.8 Load Balancing

When multiple routes have the same routing protocol preference and metric, these routes are
called equal-cost routes, among which load balancing can be implemented.
The FW supports the multi-route mode. Users can configure multiple routes with the same
destination and the same preference. If the destinations and costs of the multiple routes
discovered by a routing protocol are the same, you can implement load balancing among the
routes. To implement load balancing, run the maximum load-balancing number command in
each protocol view. The load balancing is classified into the following types:

l Packet-by-packet
When the packet-by-packet load balancing is configured, FW at the network layer
forward packets to the same destination through various equal-cost paths. That is, FW
always choose the next hop address that is different from the last one to send packets.
Figure 5-2 shows the networking for the packet-by-packet load balancing.
Figure 5-2 Networking for packet-by-packet load balancing
GE1/0/0 RouterB
P1, P3, P5 10.1.1.0/24

FW
P2, P4, P6
RouterD
GE1/0/1
RouterC
In the illustration, FW sends packets to the destination address 10.1.1.0/24. Packets P1,
P2, P3, P4, P5, and P6 need to be forwarded to the destination. To balance the load, FW
sends packets to the destination address by alternating between the two interfaces, as
follows:
– P1 through GE1/0/0
l Session-by-session
When session-by-session load balancing is configured, FW forward packets according to
the source address, destination address, source port, destination port, and protocol
contained in the packets. When the five factors are the same, FW always choose the
same next hop address as the last one used to send the packets. Figure 5-3 shows
networking for session-by-session load balancing.

Figure 5-3 Networking for session-by-session load balancing
RouterB
GE1/0/0
10.1.1.0/24
P1-P6 10.1.1.0/24
FW 10.2.1.0/24
10.2.1.0/24
P1-P6 RouterD
GE1/0/1
RouterC
FW forwards packets to the destinations at 10.1.1.0/24 and 10.2.1.0/24 respectively. The

routing policy of session-by-session load balancing is that packets in the same flow are
always transmitted along the previous path. The process for FW to forward packets is as
follows:
– The first packet P1 to the destination address 10.1.1.0/24 is forwarded through
GE1/0/0, so all the following packets to the destination are forwarded through the
interface.
– The first packet P1 to the destination address 10.2.1.0/24 is forwarded through
GE1/0/1, so all the following packets to the destination are forwarded through the
interface.
In real application, the protocols that support load balancing are RIP, OSPF, BGP, and IS-IS.
Besides, static routes also support load balancing.
5.1.9 Priority-based Route Convergence

Priority-based route convergence, which provides faster convergence of routes for key
services, is an important technology to improve network reliability.
Definition
Routes can be set with different convergence priorities, such as critical, high, medium, and
low. The system performs route convergence based on the convergence priorities and a
convergence rule. In other words, the system schedules the convergence of routes with
different convergence priorities in proportion to a weighting scheme.
Purpose
With the integration of network services, the services must be differentiated. As required by
operators, the routes for key services, such as Voice over IP (VoIP), video conferences, should
converge as fast as possible, while the routes for common services can be converged
relatively slowly. To improve network reliability, the system converges routes in a manner
based on their convergence priorities.

Principle
Table 5-3 shows the default convergence priorities of public routes. The routing protocols
first compute and deliver routes of high convergence priorities to the system. By default, the
system converges routes according to the scheduling weight values assigned to the
convergence priorities in the proportions of critical:high:medium:low = 8:4:2:1. You can re-
configure the scheduling weight values as required.
Table 5-3 Default convergence priorities of public routes

Routing Protocol or Route Type Convergence Priority
Direct High
Static Medium
32-bit host routes of OSPF and IS-IS Medium
OSPF route (except 32-bit host routes) Low
IS-IS route (except 32-bit host routes) Low
RIP Low
BGP Low
NOTE
For private routes, only 32-bit host routes of OSPF and IS-IS can be identified as medium and all other
routes are identifies as low.
5.2 Routing Basics Configuration

This section describes basic functions used by various routing procotols, for example, the
address prefix list and routing table.
5.2.1 Routing Basics Configuration Using the Web UI
5.2.1.1 Configuring Virtual Routers

This section describes how to configure a virtual router to isolate VPN routes.
Step 1 Choose Network > Route > Virtual Router.
Step 2 Click Add in Virtual Router List.
Step 3 Enter the name of the virtual router to be created.
Step 4 Click OK.

If the new virtual router entry is displayed, the operation succeeds.
----End

5.2.1.2 Monitoring OSPF and BGP

The OSPF and BGP route monitoring tables provide visibility into route details.
Monitoring the Status of OSPFv2 Routes

Step 1 Choose Network > Route > Dynamic Route Monitoring Table.
Step 2 View details on OSPFv2 routes on the OSPFv2 Route List page.
Destination Indicates the destination network of an OSPFv2 route.
Cost Indicates the cost of a route reaching the destination.
Type The value can be Stub, Rtr, Net, SNet, ASB, ASE, GM, or
NSSA.
Next Hop Indicates the next-hop IP address.
AdvRouter Indicates the routing device of the route.
Area Indicates the area to which the route belongs.
Details Indicates the details about OSPFv2 routes.
Step 3 Click of "Precess ID: ID Route ID: ID" to view details of the OSPF routing table.
Process ID Indicates the OSPFv2 process ID of the route.
Router ID Indicates the router ID of the routing table.
Total Nets Indicates the number of routes in the OSPFv2 process.
Intra Area Indicates the number of intra-area routes in the OSPFv2

process.
Inter Area Indicates the number of inter-area routes in the OSPFv2

process.
ASE Indicates the number of ASE routes introduced to the OSPFv2

process.
NSSA Indicates the number of NSSA routes in the OSPFv2 process.
----End
Monitoring the Status of OSPFv3 Routes

Step 2 In OSPFv3 Route List, check the details about OSPFv3 routes.

Destination Indicates the destination network of an OSPFv3 route.
Cost Indicates the cost of the route to the destination address.
Next Hop Indicates the next hop pointing to the destination address.
Interface Indicates the outbound interface of the packet.
----End
Monitoring the Status of BGP Routes

Step 2 View details on BGP routes on the BGP Route List page.
Status Indicates the BGP route status, such as valid and optimal.
Network Indicates the network of a BGP route.
Next Hop Indicates the next-hop IP address.
MED Indicates the MED value carried by the BGP route.
LocPrf Indicates the local priority of a BGP route.
PrefVal Indicates the preferred value of the route learned from the peer.
Path/Ogn Path indicates the AS number passed by the route.

Origin indicates the source attribute of the route, including the
following types:
l IGP: has the highest priority. Routing information is
obtained through IGP in the initiating AS. For example, a
route is injected to the BGP routing table by the network
command.
l EGP: has the higher priority. Routing information is
obtained through EGP.
l incomplete: has the lowest priority. Routing information is
obtained in other methods. For example, BGP imports
routes through the import-route command.
----End
5.2.1.3 Checking the Routing Table

When the network is disconnected, you can check whether a route to the specified destination
exists in the routing table.

Context
NOTE
You can view only the active routes in the routing table.
Procedure
Step 1 Choose Network > Route > Routing Table.
Step 2 Configure the search conditions.
Figure 5-4 Search conditions
VPN Instance Query route based on the VPN instance.
Protocol Type Select IPv4 or IPv6 to query IPv4 or IPv6 routes.
Route Type l Protocol: Query routes by protocol.

l Destination/Mask: Query routes by destination
address and mask.
Protocol/Destination (Mask) Select the protocol type when you query routes by
protocol.
l All: Query routes of all protocols.
l Direct: Query only the direct routes.
l Static: Query only the static routes.
l UNR: Query only the UNR routes.
l BGP: Query only the BGP routes.
l OSPF: Query only the OSPF routes.
l RIP: Query only the RIP routes.
Enter the destination IP address and mask when you
query routes by destination address and mask. If you
do not enter a mask, the route to a specific host is
displayed.
----End
5.2.2 Routing Basics Configuration-CLI

This section describes how to configure routing basic function using the CLI UI.
5.2.2.1 Configuring the Global Router ID

Certain dynamic routing protocols require router IDs. If the router IDs are not specified when
you enable the routing protocols, the default global router ID is employed. In this case, you

need to reset connections to set up the normal neighbor relationship after you specify the
router IDs.
Context
The global router ID to be configured must be different from other router IDs on the network.
Generally, the router ID is set to the IP address of an interface on the router.
Procedure
Step 2 Run the router id router-id command configure the global router ID.
By default, the global router ID is not configured.
----End
Follow-up Procedure
Run the display router id command to query the configured router ID.
<FW> system-view
[FW] router id 10.1.1.1
[FW] display router id
RouterID:1.1.1.1
5.2.2.2 Configuring the IP-Prefix List

IP prefix lists check IP prefixes of the source IP address, destination IP address, and next hop
address to filter routes. They can be used independently when routing protocols advertise and
receive routes.
5.2.2.2.1 Configuring the IPv4 IP-Prefix List

The control action for matched IPv4 routes can be flexibly controlled through the
configuration of the IPv4 IP-Prefix List.
Context
Before applying a routing policy, you should set the matching rules, that is, filters. Compared
with an ACL, an IP prefix list is more flexible. When the IP prefix list is used to filter routes,
it matches the destination address of a route.
A prefix list is identified by its list name. Each prefix list can include multiple entries. Each
entry can independently specify the matching range of a network prefix form and identify it
with an index number. For example, the following is a prefix list named abcd:
#
ip ip-prefix abcd index 10 permit 10.1.0.0 16
ip ip-prefix abcd index 20 permit 10.2.0.0 16
Procedure
Step 1 In the user view, run:

system-view
Step 2 Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-address mask-length
[ greater-equal greater-equal-value ] [ less-equal less-equal-value ]
A prefix list is configured.
The range of mask length can be specified as mask-length <= greater-equal-value <= less-
equal-value <= 32. If only greater-equal is specified, the range of the prefix is from greater-
equal-value to 32; if only less-equal is specified, the range of the prefix is from [ mask-length
to less-equal-value ].
During the matching, the system checks entries identified by the index number in the
ascending order. Once an entry meets the condition, it means that all entries pass the IP-prefix
filtering. The system does not match other entries.
If all entries are in deny mode, no routes can pass this filtering list. You are recommended to
define an permit 0.0.0.0/0 less-equal 32 entry after the multiple entries in the deny mode,
thus allowing all the other routes to pass the IP-Prefix filtering.
NOTE
l If more than one IP-Prefix entry is defined, at least one entry should be in permit matching mode.
----End
5.2.2.2.2 Configuring the IPv6 IP-Prefix List

The control action for matched IPv6 routes can be flexibly controlled through the
configuration of the IPv6 IP-Prefix List.
Context
The IPv6 IP-prefix list is identified by the list name. Each prefix list contains multiple entries.
Each entry independently specifies a matching range in the format of network prefixes, and
uses the index number for identification.
During the matching, the system checks every entry in turn according to the index number in
an ascending order. As long as the routing information matches one entry, the filtering list is
passed, and other entries are no longer matched.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip ipv6-prefix ipv6-prefix-name [ index index-number ] { permit | deny } ipv6-address
prefix-length [ greater-equal greater-equal-value ] [ less-equal less-equal-value ]
An IPv6 prefix list is configured.

A prefix list is identified by its list name. Each prefix list can include multiple entries. Each
entry can independently specify the matching range of a network prefix form and identify it
with an index number. For example, the following is a prefix list named abcd:
#
ip ipv6-prefix abcd index 10 permit 1:: 64
ip ipv6-prefix abcd index 20 permit 2:: 64
During the matching, the system checks entries identified by the index number in the
ascending order. Once an entry meets the condition, it means that all entries pass the IP-prefix
filtering. The system does not match other entries.
If all entries are in deny mode, no routes can pass this filtering list. You are recommended to
define an permit :: 0 less-equal 128 entry after the multiple entries in the deny mode, thus
allowing all the other IPv6 routes to pass the IP-Prefix filtering.
NOTE
If more than one IP-Prefix entry is defined, at least one entry should be in permit matching mode.
----End
5.2.2.3 Managing IP Routing Tables
5.2.2.3.1 Managing the Routing Table

After you configure routes, you can run the display commands to check the configurations.
You can also clear routes or enable debugging if necessary.
Displaying the Routing Table

After configuring routes, you can run the display commands in any view to display and verify
the configuration.
Table 5-4 and Table 5-5 list the commands for displaying the configurations of IP routes.
Table 5-4 Displaying IPv4 routing information

Action Command
Display the general information display ip routing-table

about the active routes in the
routing table.
Display the detailed information display ip routing-table verbose

about the routing table.
Display the routes to the specified display ip routing-table ip-address [ mask | mask-
destination IP address. length ] [ longer-match ] [ verbose ]
Display the routes to the addresses display ip routing-table ip-address1 { mask1 |

in the specified destination IP mask-length1 } ip-address2 { mask2 | mask-length2 }
address range. [ verbose ]
Display the routes defined in the display ip routing-table acl acl-number [ verbose ]
specified basic ACL.

Action Command
Display the route filtered by the display ip routing-table ip-prefix ip-prefix-name

specified prefix list. [ verbose ]
Display the route learned using the display ip routing-table protocol protocol
specified protocol. [ inactive | verbose ]
Display the comprehensive display ip routing-table statistics

information about the routing table.
Display the general information display ip routing-table vpn-instance vpn-instance-

about the routing table on a private name
network.
Display the detailed information display ip routing-table vpn-instance vpn-instance-

about the private network routing name verbose
table.
Table 5-5 Displaying IPv6 routing information

Action Command
Display the general information display ipv6 routing-table

about the active routes in the IPv6
routing table.
Display the detailed information display ipv6 routing-table verbose

about the IPv6 routing table.
Display the routes to the specified display ipv6 routing-table ipv6-address prefix-
destination IP address. length [ longer-match ] [ verbose ]
Display the routes to the addresses display ipv6 routing-table ipv6-address1 prefix-
in the specified destination IP length ipv6-address2 prefix-length } [ verbose ]
address range.
Display the routes defined in the display ipv6 routing-table acl acl-number
specified basic ACL. [ verbose ]
Display the route filtered by the display ipv6 routing-table ip-prefix ipv6-prefix-
specified prefix list. name [ verbose ]
Display the route learned using the display ipv6 routing-table protocol protocol
specified protocol. [ inactive | verbose ]
Display the comprehensive display ipv6 routing-table statistics

information about the IPv6 routing
table.
Display the general information display ipv6 routing-table vpn-instance vpn-

about the IPv6 routing table on a instance-name
private network.

Action Command
Display the detailed information display ipv6 routing-table vpn-instance vpn-

about the IPv6 private network instance-name verbose
routing table.
Clearing Routes
If you need to manually add a route, perform the following actions to clear the dynamic
routes. Statistics on cleared routes cannot be restored. Exercise caution before you clear any
routes.
Table 5-6 lists the commands for clearing routes. Perform these actions in the user view.
Table 5-6 Clearing routes

Action Command
Clear the statistics in the IPv4 reset ip routing-table statistics protocol [ vpn-
routing table. instance vpn-instance-name ] { all | direct | bgp |
isis | ospf | rip | unr | static }
Clear the statistics in the IPv6 reset ipv6 routing-table [ vpn-instance vpn-
routing table. instance-name ] statistics protocol { all | bgp |
direct | isis | ripng | static | ospfv3 | unr }
5.2.2.3.2 Managing the Routing Management Module
Checking information about the routing management module is also a measure to locate
routing faults. You can run the display commands in any view to display and verify the
configurations.
Table 5-7 lists the commands for displaying the information about the routing management
module.
Table 5-7 Displaying information about the routing management module

Action Command
Display the routing display rm interface [ interface-type interface-number ]

management information about
an interface.
Display the IPv6 routing display rm ipv6 interface [ interface-type interface-

management information about number ]
an interface.

Action Command
Display the configurations of display rm bfd-session [ all | [ [ vpn-instance vpn-

BFD sessions in routing instance-name ] [ destination destination-address ]
management information. [ source source-address ] [ interface interface-type
interface-number ] [ protocol { bgp | isis-l1 | isis-l2 | isis-
l1l2 | ospf | rip | pim } ] ] ]
5.3 IP Static Route

Static routes are mainly applied to simply-structured IP networks.
5.3.1 Overview
This section provides the definition and purpose of static route.
Definition
Static routes need to be manually configured by the administrator.
Purpose
On a simple network, the administrator just needs to configure static routes so that the
network can run properly. Properly configuring and using static routes can improve network
performance and guarantee the required bandwidth for important applications.
When a network fault occurs or the network topology changes, however, static routes cannot
automatically change and must be changed manually by the administrator.
The FW supports common static routes and the static routes associated with Virtual Private
Network (VPN) instances. The static routes associated with VPN instances are used to
manage VPN routes.
5.3.2 Mechanism
This section describes the mechanism of IP static route.
5.3.2.1 Components of Static Routes
On the FW, you can run the ip route-static command to configure a static route, which
consists of the following:
l Destination Address and Mask
l Outbound Interface and Next-Hop Address
Destination Address and Mask

In the ip route-static command, the IPv4 address is expressed in dotted decimal notation, and
the mask is expressed in dotted decimal notation or represented by the mask length (the
number of consecutive 1s in the mask).

Outbound Interface and Next-Hop Address

When configuring a static route, you can specify an outbound interface, a next-hop address, or
both the outbound interface and the next hop-address as required.
Actually, each routing entry requires a next-hop address. Before sending a packet, a device
needs to search its routing table for the route matching the destination address in the packet by
using the longest match rule. The device can find the associated link layer address to forward
the packet only after the next-hop address of the packet is specified.
When specifying an outbound interface, note the following:
l For a Point-to-Point (P2P) interface, the next-hop address is specified after you specify
the outbound interface. That is, the address of the remote interface connected to this
interface is the next-hop address. For example, when a POS interface is encapsulated
with the Point-to-Point Protocol (PPP) and obtains the remote IP address through PPP
negotiation, you need to specify only the outbound interface rather than the next-hop
address.
l Non-Broadcast Multiple-Access (NBMA) interfaces (such as an ATM interface) are
applicable to Point-to-Multipoint (P2MP) networks. Therefore, IP routes and the
mappings between IP addresses and link layer addresses are required. In this case, you
need to configure next-hop addresses.
l When configuring static routes, it is not recommended to specify the Ethernet interface
or the virtual-template (VT) interface as the outbound interface. This is because an
Ethernet interface is a broadcast interface and a VT interface can be associated with
several virtual access (VA) interfaces. If the Ethernet interface or the VT interface is
specified as the outbound interface, a unique next hop cannot be determined because
multiple next hops exist. In actual applications, to specify a broadcast interface (such as
an Ethernet interface) or a VT interface as the outbound interface, you are recommended
specify the associated next-hop address.
5.3.2.2 Applications of Static Routes
As shown in Figure 5-5, the network topology is simple, and network communication can be
implemented through static routes. It is required to specify an address for each physical
network, identify indirectly-connected physical networks for each router, and configure static
routes for the indirectly-connected physical networks.
Figure 5-5 Networking diagram of static routes
2 4
FW_B
1 5
FW_A FW_C

In Figure 5-5, static routes to networks 3, 4, and 5 need to be configured on FW_A; static
routes to networks 1 and 5 need to be configured on FW_B; static routes to networks 1, 2, and
3 need to be configured on FW_C.
Default Static Route

When the ip route-static command is run to configure a static route, if the destination address
and the mask are set to all 0s (0.0.0.0 0.0.0.0), it indicates that a default route is configured.
This simplifies the network configuration.
In Figure 5-5, because the next hop of the packets sent by FW_A to networks 3, 4, and 5 is
FW_B, a default route can be configured on FW_A to replace the three static routes destined
for networks 3, 4, and 5 in the preceding example. Similarly, only a default route from FW_C
to FW_B needs to be configured to replace the three static routes destined for networks 1, 2,
and 3 in the preceding example.
Floating Static Routes

Different static routes can be configured with different preferences so that routing
management policies can be flexibly applied. Specifying different preferences for multiple
routes to the same destination can implement route backup.
As shown in Figure 5-6, there are two static routes from FW_A to FW_C. Normally, in the
routing table, only the static route with the next hop being FW_B is in the Active state
because this route has a higher preference. The other static route with the next hop being
FW_D functions as a backup route. The backup route is activated to forward data only when
the primary link becomes faulty. After the primary link recovers, the static route with the next
hop being FW_B becomes active to forward data. Therefore, the backup route is also called a
floating static route. The floating static route becomes ineffective when a fault occurs on the
link between FW_B and FW_C.
Figure 5-6 Networking diagram of a floating static route
FW_B
Preference=60
Preference=100
FW_A FW_C
FW_D
Load Balancing Among Static Routes

Specifying the same preference for multiple routes to the same destination can implement
load balancing.

As shown in Figure 5-7, there are two static routes with the same preference from FW_A to
FW_C. The two routes exist in the routing table and forward data at the same time.
Figure 5-7 Load balancing among static routes
FW_B
Preference=60
Preference=60
FW_A FW_C
FW_D
5.3.2.3 Default Routes
Default routes are special routes. Generally, administrators can manually configure default
static routes. Default routes can also be generated through dynamic routing protocols such as
OSPF and IS-IS.
Default routes are used only when packets to be forwarded have no matching routing entry in
a routing table. In the routing table, a default route is the route to the network 0.0.0.0 (with the
mask also being 0.0.0.0). You can check whether the default route is configured by using the
display ip routing-table command.
If the destination address of a packet does not match any entry in the routing table, the packet
is sent through a default route. If no default route exists and the destination address of the
packet does not match any entry in the routing table, the packet is discarded. An Internet
Control Message Protocol (ICMP) packet is then sent, informing the originating host that the
destination host or network is unreachable.
5.3.2.4 BFD for Static Routes
Different from dynamic routing protocols, static routes do not have a detection mechanism.
As a result, when a fault occurs on the network, the administrator needs to handle it.
Bidirectional Forwarding Detection (BFD) for static route is introduced to bind a static route
to a BFD session so that the BFD session can detect the status of the link where the static
route resides.
After BFD for static route is configured, each static route can be bound to a BFD session.
l If the BFD session on the link of a static route detects that the link changes from Up to
Down, BFD reports it to the system. Then, the system deletes the route from the IP
routing table.

l When a BFD session is established on the link of a static route or the BFD session
changes from Down to Up, BFD reports it to the system. Then, the system adds the route
to the IP routing table.
BFD for static route has two modes:
l Single-hop detection
For a non-iterated static route, the configured outbound interface and next-hop address
are the information about the directly connected next hop. In this case, the outbound
interface bound to the BFD session is the outbound interface of the static route, and the
peer address is the next-hop address of the static route.
l Multi-hop detection
For an iterated static route, only the next-hop address is configured. Therefore, the
directly connected next-hop and outbound interface need to be iterated. In this case, the
peer address of the BFD session is the original next-hop address of the static route, and
the outbound interface is not specified. Generally, the original next hop to be iterated is
an indirect next hop. Therefore, multi-hop detection is performed on the static routes that
support route iteration.
5.3.3 Configuring Static Route Using the Web UI

This section describes how to configure IPv4 and IPv6 static routes on the Web UI.
Configuring the Default Priority

The default priority of a static route is 60. You can change the default priority as follows:
Step 1 Choose Network > Route > Static Route.
Step 2 Under Configure Default Priority, enter the default priority for static routes in Default
Priority.
Step 3 Click Apply.
If the priority is updated on the Web UI, the operation succeeds.
----End
Creating a Static Route

Step 1 Choose Network > Route > Static Route.
Step 2 Under Static Route List, click Add.
Step 3 Set the parameters of the static route.
If the new static route is displayed, the operation succeeds.
Protocol Protocol type of the static route. You can selectIPv4

or IPv6.
Source Virtual Router Source virtual router.

Destination IP address/mask Destination IP address and mask.

The destination IP address can be an IPv4 or IPv6
address.
For an IPv4 address, the format is similar to
10.1.1.1/24 or 10.1.1.1/255.255.255.0. For an IPv6
address, the format is similar to 3::3/64.
Destination Virtual Router Destination virtual router.
Interface Name of the outgoing interface.

During the configuration of static routes, you can
specify the next hop and the outgoing interface or
specify either of them based on actual situations.
l For point-to-point interface, specify the outgoing
interface.
l For NBMA, Ethernet, and Virtual-template
interfaces, specify the next hop.
Next-hop IP address Next-hop IP address.

You must specify the outgoing interface or the next-
hop IP address when you configure a static route.
The destination IP address can be an IPv4 or IPv6
address. For an IPv4 address, the format is similar to
10.1.1.1/24 or 10.1.1.1/255.255.255.0. For an IPv6
address, the format is similar to 3::3/64.
Priority Priority of static routes.

You can configure different priorities for static routes
as needed. If multiple routes to the same destination
have the same priority, you can load balance the
traffic among the routes. If the routes have different
priorities, you can implement route redundancy.
The configured priority overrides the default route
priority.
Reliability Detection Reliability Detection for the static route. You can
select the mode from the followings:
l No Detection
l Binding BFD
l Binding IP-Link
BFD Name Input or select the name of the BFD to be bound.

This option is only displayed after you select Binding
BFD under Reliability Detection.
IP-Link Name Input or select the name of the IP-Link to be bound.

This option is only displayed after you select Binding
IP-Link under Reliability Detection.

Description Description of the static route.
Step 4 Click OK.
----End
5.3.4 Configuring Static Route-CLI

Static routes are applicable to simple networks. Properly configuring and using static routes
improve the network performance and help ensure bandwidth for important services.
5.3.4.1 Configuring an IPv4 Static Route

You can configure a static outbound interface or next-hop address and priority for the IPv4
packet to the destination address to accurately control the IPv4 route selection.
Context
When configuring an IPv4 static route, you need to learn the following information:
l Destination address and mask
In the ip route-static command, the IPv4 destination address is in dotted decimal
notation. The mask can be in dotted decimal notation or can be represented by the mask
length, namely, the number of consecutive "1"s in the mask.
l Outbound interface and next hop address
When configuring a static route, you can specify either interface-type interface-number
or nexthop-address. Whether to specify the outbound interface or the next hop address
depends on the actual situation.
Actually, all routing entries must specify the next hop addresses. When sending a packet,
the router first searches the matched route in the routing table according to the
destination address. The link layer can find the corresponding link layer address and
forward the packet only when the next hop address is specified.
When specifying the outbound interface, note the following:
– For Point-to-Point (P2P) interfaces, if the outbound interface is specified, it
indicates that the next hop address is specified. The address of the peer interface
connected to this interface is the next hop address. For example, when a POS
interface is Point-to-Point Protocol (PPP) encapsulated, the peer IP address is
obtained through PPP negotiation. In this case, you need to specify only the
outbound interface.
– NBMA interface such as ATM interface supports Point-to-Multipoint (P2MP)
networks. In this case, you need to configure IP routes and set up the reroute table
on the link layer, namely, the mapping between IP addresses and link layer
addresses. In this case, the next hop IP address needs to be configured.
– When configuring static routes, you are recommended not to specify the Ethernet
interface as the outbound interface. The Ethernet interface is a broadcast interface .
In this case, multiple next hops occur and a unique next hop cannot be determined.
To specify a broadcast interface such as an Ethernet interface or an NBMA interface
as the outbound interface, you need to specify the next hop address of this interface.

l Other attributes
You can set different preferences for the static routes. This enables you to apply the RM
policy flexibly. For example, when configuring multiple routes to the same destination
address, you can set the same preference for these routes to implement load balancing.
You can also set different preferences to implement routing redundancy.
While configuring a static route by using the ip route-static command, if you set the
destination address and the mask to all "0"s (0.0.0.0 0.0.0.0), it indicates that a default
route is configured.
Procedure
system-view
Step 2 Run:
l ip route-static ip-address { mask | mask-length } { nexthop-address | interface-type
interface-number [ nexthop-address ] } [ preference preference | tag tag ] * [ track
{ bfd-session bfd-name | ip-link link-name | nqa admin-name test-name } | permanent ]
[ description text ]
l ip route-static ip-address { mask | mask-length } interface-type interface-number
[ nexthop-address ] [ preference preference | tag tag ] * ldp-sync [ description text ]
l ip route-static ip-address { mask | mask-length } vpn-instance vpn-instance-name
nexthop-address [ preference preference | tag tag ] * [ track { bfd-session bfd-name |
ip-link link-name | nqa admin-name test-name } | permanent ] [ description text ]
nexthop-address [ recursive-lookup host-route ] [ preference preference | tag tag ] *
[ inherit-cost | permanent ] [ description text ]
l ip route-static ip-address { mask | mask-length } nexthop-address [ recursive-lookup
host-route ] [ preference preference | tag tag ] * [ inherit-cost | permanent ]
A static route is configured.
By default, no static route is configured.
Step 3 Run:
ip route-static default-preference preference
The default preference is set for the static route.
By default, the preference of the static route is 60.
When a static route is configured, the default preference is used if no preference is explicitly
specified. The new default preference is valid for only the added static routes.
----End
5.3.4.2 Configuring an IPv6 Static Route

On an IPv6 network, you can accurately control route selection by configuring IPv6 static
routes.

Context
Do as follows on the router to be configured with static FWs:
Procedure
Step 1 Run:
system-view
Step 2 Run:
l ipv6 route-static dest-ipv6-address prefix-length interface-type interface-number
[ nexthop-ipv6-address ] [ preference preference | tag tag ] * [ description text ]
l ipv6 route-static dest-ipv6-address prefix-length nexthop-ipv6-address [ preference
preference | tag tag ] * [ inherit-cost ] [ description text ]
An IPv6 static route is configured.
When configuring a static route, you need to specify either the outbound interface or the next-
hop address according to the actual situation. If the outbound interface is a PPP interface, you
can simply specify the outbound interface. If the outbound interface is a broadcast interface,
you must also specify the next-hop address in addition to specifying the outbound interface.
NOTICE
Static routes with an outgoing interface do not support recursive routing.
If preference is not specified, the default preference is 60.

By configuring different tag values, you can classify static routes to implement different
routing policies. For example, other protocols can import static routes with specified tag
values through routing policies. By default, the value is 0.
By default, no IPv6 static route is configured.
ipv6 route-static default-preference preference
The default preference of IPv6 static routes is set.
By default, the preference of IPv6 static routes is 60.
When an IPv6 static route is configured, the default preference is used if the preference of the
static route is not explicitly specified. After the default preference is specified, the default
preference is valid for subsequent rather than existing IPv6 static routes.
----End
Follow-up Procedure
To view the configurations of IPv6 static routes, you can execute the following commands.

l Run the display ipv6 routing-table command to check brief information about the IPv6
routing table.
l Run the display ipv6 routing-table verbose command to check detailed information
about the IPv6 routing table.
l Run the display ipv6 routing-table protocol static command to check information of
the static IPv6 routes.
5.3.4.3 Configuring BFD for Static Routes

On an IPv4 network, configuring BFD for static routes on the public network can speed up
route convergence and improve network reliability.
Context
Note the following when configuring unicast static routes:
l When the destination IP address and the mask are both 0.0.0.0, the configured route is
the default route.
l For the configuration of different preferences, different RM policies are adopted. For
example, to configure multiple routes to the same destination, load balancing is
performed if the routes have the same preference. Route backup is performed if the
routes have different preferences.
l To configure a static route, specify the egress or the next hop address as required. For the
interface that supports the resolution from network address to the link layer address or
the address of the point-to-point (P2P) interface, specify the egress or the next hop
address.
l Specify the next hop address if the type of the egress is broadcast.
Procedure
system-view
Step 2 Run:
l ip route-static ip-address { mask | mask-length } { nexthop-address | interface-type
interface-number [ nexthop-address ] } [ preference preference | tag tag ] * track bfd-
session bfd-name [ description text ]
nexthop-address [ preference preference | tag tag ] * track bfd-session bfd-name
The BFD for static route is configured.
By default, the BFD for static route is not configured.
----End

Follow-up Procedure
To view the configurations of BFD for static routes, you can execute the following
commands.
l Run the display bfd session { all | discriminator discr-value } [ verbose ] [ slot slot-
id ] command to check the BFD sessions.
You can view the BFD session only after the parameters of the BFD session are
configured and the BFD session is set up.
l Run the display current-configuration | include bfd command to check the
configuration of BFD for static routes.
5.3.5 Checking Static Route Configuration

After configuring a static route, you can run the display commands in any view to view and
verify the related configuration.
Table 5-8 shows the commands for checking the static route configuration.
Table 5-8 Checking the IPv4 and IPv6 static route information
Action Command
Check the display current-configuration

configuration script.
Check the abstract of display ip routing-table

the IPv4 routing table.
Check the details on display ip routing-table verbose

Check the abstract of display ipv6 routing-table

Check the details on display ipv6 routing-table verbose


This section provides several configuration examples of IP static route.
5.3.6.1 CLI Example for Configuring an IP Static Route

This example describes how to configure the default gateway on hosts on a small IPv4
network and how to configure the default route and static routes on the FW.
Figure 5-8 shows the IP addresses and masks of each FW interface and host. Static routes
must be configured to ensure the communication between any two hosts.

Figure 5-8 Configuring static routes on an IPv4 network
PC2
10.1.2.2/24
GE1/0/3
10.1.2.1/24
GE1/0/1 GE1/0/2
10.1.5.2/24 10.1.4.5/30
FW_B
FW_A FW_C
GE1/0/1 GE1/0/1
10.1.5.1/24 10.1.4.6/30
GE1/0/2 GE1/0/2
10.1.1.1/24 10.1.3.1/24
PC1 PC3
10.1.1.2/24 10.1.3.2/24
Item Data
FW_A Interface: GigabitEthernet 1/0/1

IP address: 10.1.5.1/24
Interface: GigabitEthernet 1/0/2

IP address: 10.1.1.1/24
FW_B Interface: GigabitEthernet 1/0/1

IP address: 10.1.5.2/24

IP address: 10.1.4.5/30

IP address: 10.1.2.1/24
FW_C Interface: GigabitEthernet 1/0/1

IP address: 10.1.4.6/30

Item Data

IP address: 10.1.3.1/24
Perform the following procedures to configure IPv4 static routes:
1. Specify interface addresses for the FWs.

2. Configure the default route and static routes on the FW.
3. Configure the default gateway on the hosts.
Procedure
# Configure IP addresses for the interfaces and assign the interfaces to security zones.
<FW_A> system-view
# Configure security policies from FW_A to FW_B and FW_C.

[FW_A-security-policy] rule name sec_policy_1
[FW_A-security-policy-sec_policy_1] source-address 10.1.1.0 mask 255.255.255.0
[FW_A-security-policy-sec_policy_1] destination-address 10.1.2.0 mask
255.255.255.0
255.255.255.0
[FW_A-security-policy-sec_policy_1] source-zone trust
[FW_A-security-policy-sec_policy_1] destination-zone trust
[FW_A-security-policy-sec_policy_1] action permit
[FW_A-security-policy-sec_policy_1] quit
[FW_A-security-policy] rule name sec_policy_2
255.255.255.0
[FW_A-security-policy-sec_policy_2] source-zone trust
[FW_A-security-policy-sec_policy_2] destination-zone trust
[FW_A-security-policy-sec_policy_2] action permit
[FW_A-security-policy-sec_policy_2] quit
[FW_A-security-policy] quit
# Configure the default route.



<FW_B> system-view
# Configure security policies from FW_B to FW_A and FW_C.

[FW_B-security-policy] rule name sec_policy_1
[FW_B-security-policy-sec_policy_1] source-address 10.1.2.0 mask 255.255.255.0
[FW_B-security-policy-sec_policy_1] destination-address 10.1.1.0 mask
255.255.255.0
255.255.255.0
[FW_B-security-policy-sec_policy_1] source-zone trust
[FW_B-security-policy-sec_policy_1] destination-zone trust
[FW_B-security-policy-sec_policy_1] action permit
[FW_B-security-policy-sec_policy_1] quit
[FW_B-security-policy] rule name sec_policy_2
255.255.255.0
[FW_B-security-policy-sec_policy_2] source-zone trust
[FW_B-security-policy-sec_policy_2] destination-zone trust
[FW_B-security-policy-sec_policy_2] action permit
[FW_B-security-policy-sec_policy_2] quit
[FW_B-security-policy] quit
# Configure two static routes on the FW_B.


<FW_C> system-view
[FW_C-GigabitEthernet1/0/1] ip address 10.1.4.6 255.255.255.252
[FW_C-GigabitEthernet1/0/2] ip address 10.1.3.1 255.255.255.0
[FW_C] firewall zone trust
[FW_C-zone-trust] add interface GigabitEthernet 1/0/1
[FW_C-zone-trust] quit
# Configure security policies from FW_C to FW_A and FW_B.

[FW_C] security-policy
[FW_C-security-policy] rule name sec_policy_1
[FW_C-security-policy-sec_policy_1] source-address 10.1.3.0 mask 255.255.255.0

[FW_C-security-policy-sec_policy_1] destination-address 10.1.1.0 mask

255.255.255.0
255.255.255.0
[FW_C-security-policy-sec_policy_1] source-zone trust
[FW_C-security-policy-sec_policy_1] destination-zone trust
[FW_C-security-policy-sec_policy_1] action permit
[FW_C-security-policy-sec_policy_1] quit
[FW_C-security-policy] rule name sec_policy_2
255.255.255.0
[FW_C-security-policy-sec_policy_2] source-zone trust
[FW_C-security-policy-sec_policy_2] destination-zone trust
[FW_C-security-policy-sec_policy_2] action permit
[FW_C-security-policy-sec_policy_2] quit
[FW_C-security-policy] quit
# Configure the default route.

[FW_C] ip route-static 0.0.0.0 0.0.0.0 10.1.4.5
Step 4 Configuring the host.
Configure the default gateways of the host PC1, PC2, and PC3 to 10.1.1.1, 10.1.2.1, and
10.1.3.1 respectively. (The specific configuration command varies with host system. The
configuration details are not mentioned in this section.)
# Display the IP routing table of the FW_A.

------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 D 10.1.5.2

10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.5.0/24 Direct 0 0 D 10.1.5.1
# Verify connectivity by using the ping command.

<FW_A> ping 10.1.3.1
PING 10.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=254 time=62 ms
--- 10.1.3.1 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 62/62/63 ms

# Verify connectivity by using the tracert command.

<FW_A> tracert 10.1.3.1
traceroute to 10.1.3.1(10.1.3.1), max hops: 30 ,packet length: 40,press CTRL_C
to break
1 10.1.5.2 31 ms 32 ms 31 ms
2 10.1.4.6 62 ms 63 ms 62 ms
----End
#
sysname FW_A
#
undo shutdown
ip address 10.1.5.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
firewall zone trust
set priority 85
#
ip route-static 0.0.0.0 0.0.0.0 10.1.5.2
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
#
return

#
sysname FW_B
#
undo shutdown
ip address 10.1.5.2 255.255.255.0
#
undo shutdown
ip address 10.1.4.5 255.255.255.252
#
undo shutdown
ip address 10.1.2.1 255.255.255.0
#
firewall zone trust

set priority 85
#
ip route-static 10.1.1.0 255.255.255.0 10.1.5.1
ip route-static 10.1.3.0 255.255.255.0 10.1.4.6
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
#
return
Configuration script for FW_C:

#
sysname FW_C
#
undo shutdown
ip address 10.1.4.6 255.255.255.252
#
undo shutdown
ip address 10.1.3.1 255.255.255.0
#
firewall zone trust
set priority 85
#
ip route-static 0.0.0.0 0.0.0.0 10.1.4.5
#
security-policy
source-zone trust
action permit
source-zone trust
action permit
#
return

This section provides reference information about static routes.

This section describes static route specifications.
Specifying a next-hop Supported by all models.

address
Specifying an outgoing Note the following when Supported by all models.

interface specifying an outgoing
interface:
l For P2P interfaces,
specifying an outgoing
interface also specifies
the next-hop address.
That is, the address of
the interface connecting
to the outgoing interface
is the next-hop address.
l Non Broadcast Multiple
Access (NBMA)
interfaces, such as ATM
interfaces, cannot be
specified as outgoing
interfaces. In this case,
you must specify the
next-hop address.
l You are not advised to
specify broadcast
interfaces (such as
Ethernet interfaces) or
VT interfaces as
outgoing interfaces. If
such an interface must be
specified as an outgoing
interface, specify the
next-hop address.
IPv4 static route load - Supported by all models.

balancing
IPv6 static route load - Supported by all models.

balancing
Changing preference values Preference values of static Supported by all models.

to manage static routes routes can be changed to
manage the routes.
Equal-cost route - Supported by all models.

Making static route invalid - Supported by all models.

when interfaces are Down

This section describes the versions and changes in the IP static route feature.
5.4 RIP
This section describes Routing Information Protocol (RIP) concepts and how to configure
RIP, as well as provides configuration examples.
5.4.1 Overview
The Routing Information Protocol (RIP) applies to small and simply structured networks. RIP
is a routing protocol based on the distance vector and uses hop counts to measure distances to
destinations. There are two RIP versions: RIP-1 and RIP-2.
Definition
RIP is a simple Interior Gateway Protocol (IGP) and works based on the Distance-Vector
(DV) algorithm. It exchanges routing information using User Datagram Protocol (UDP)
packets. RIP uses port 520.
To prevent routing loops:

l RIP employs Hop Count (HC) to measure distances to destinations. The distance is
called the metric value. RIP defines that the default HC from a router to its directly
connected network is 0, and the HC from a router to a reachable network through another
router is 1, and so on. This means that the HC is equal to the number of routers passed
from the local network to the destination network. To speed up route convergence, RIP
defines the HC as an integer that ranges from 0 to 15. The HC equal to or greater than 16
is defined as infinity, which indicates that the destination network or the host is
unreachable. RIP does not apply to large networks.
l RIP supports split horizon and poison reverse.
Purpose
As an earliest IGP, RIP is used in small and simply structured networks such as campus
networks and regional networks. Unlike static routes, RIP automatically adapts to network
topology changes.

Implementing RIP is simple. Configuring and maintaining RIP are easier than the Open
Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS)
protocols. Therefore, RIP is widely used.
5.4.2 Mechanism
This section describes the RIP mechanism.
5.4.2.1 RIP-1
RIP version 1 (RIP-1) is a classful (as opposed to classless) routing protocol. It supports the
advertisement of protocol packets only in broadcast mode. Figure 5-9 shows the packet
format. A RIP packet can carry a maximum of 25 entries. RIP is based on UDP, and a RIP-1
data packet cannot be longer than 512 bytes. The RIP-1 protocol packet does not carry any
mask, so it can identify only the routes of the natural network segment such as Class A, Class
B, and Class C. Therefore, RIP-1 does not support route aggregation or discontinuous subnet.
Figure 5-9 RIP-1 packet format

0 7 15 31
Header Command Version Must be zero
Address family identifier Must be zero
IP address
Route
Entries Must be zero
Must be zero
Metric
5.4.2.2 RIP-2
RIP version 2 (RIP-2), is a classless routing protocol. Figure 5-10 shows the packet format.
Figure 5-10 RIP-2 packet format

0 7 15 31
Header Command Version Must be zero
Address Family Identifier Route Tag
IP Address
Route
Subnet Mask
Entries
Next Hop
Metric

Compared with RIP-1, RIP-2 has the following advantages:

l Supports route tag and can flexibly control routes on the basis of the tag in the routing
policy.
l Has packets that contain mask information and support route aggregation and Classless
Inter-domain Routing (CIDR).
l Supports the next hop address and can select the optimal next hop address in the
broadcast network.
l Uses multicast routes to send update packets. Only RIP-2 routers can receive protocol
packets. This reduces the resource consumption.
5.4.2.3 Timers
RIP mainly uses the following three timers:
l Update timer: triggers the sending of update packets every 30s.
l Age timer: sets and keeps track of the 180-second time limit. If a RIP router does not
receive an update packet from any of its neighbors within the aging time, the RIP router
detects the route as unreachable.
l Garbage-Collect timer: determines when to delete a packet entry. If the route is no longer
valid after the timer expires, the entry is removed from the RIP routing table.
The three timers work together in the following way:
The advertisement of RIP routing update is triggered by the update timer every 30 seconds.
Each entry is associated with the age timer and garbage-collect timer. When a route is learned
and added in the routing table, the age timer is initialized. If no Update packet is received
from the neighbor for 180 seconds, the metric value of the route is set to 16 (to specify the
route as unreachable). At the same time, the garbage-collect timer is initialized. If no Update
packet is received for 120 seconds, the entry is deleted after the garbage-collect timer expires.
5.4.2.4 Triggered Update

Triggered update occurs when the local routing information changes and the local router
immediately notifies its neighbors of the changes in routing information by sending the
triggered update packet.
Triggered update shortens the network convergence time. When the local routing information
changes, the local router immediately notifies its neighbors of the changes in routing
information rather than wait for a periodic update.

Figure 5-11 Triggered update
The network to
10.4.0.0 fails. The network to
10.4.0.0 fails.
10.1.0.0
10.2.0.0 RouterB
E0 S0 S0
RouterA S1
10.3.0.0
S0
E0 The network to
10.4.0.0 fails.
RouterC
10.4.0.0
In the example in Figure 5-11, when network 10.4.0.0 is unreachable, RouterC learns the
information first. Usually, the route update message is sent to neighbors every 30s. If the
update message of RouterB is sent to RouterC when RouterC is waiting for the route update
message, RouterC learns the faulty route to network 10.4.0.0 from RouterB. In this case, the
routes from RouterB or RouterC to network 10.4.0.0 point to RouterC or RouterB
respectively, which forms a route loop. If RouterC detects a network fault and immediately
sends a route update message to RouterB before the new update interval reaches RouterB. The
routing table of RouterB is updated in time, and routing loops are avoided.
Another scenario that triggers updates is when the next hop of the route is unavailable because
the link is faulty. The local device needs to notify neighboring device about the
routes'unreachability. The local device sets the cost the route to 16 and advertising the route.
This is also called route-withdrawal.
5.4.2.5 Route Aggregation

When different subnet routes in the same natural network segment are transmitted to other
network segments, these routes are aggregated into one route of the same segment. This
process is called route aggregation. RIP-1 packets do not carry mask information, so RIP-1
can advertise only the routes with natural masks. Because RIP-2 packets do carry mask
information, RIP-2 supports subnetting.
RIP-2 route convergence can improve extensibility and efficiency and minimize the routing
table of a large-scale network.
Route convergence is classified into two types as follows:

l Classful aggregation based on RIP processes:

Aggregated routes are advertised with natural masks. Classful convergence summarizes
the child routes to their classful address. When classful summary feature is enabled, a
classful route is advertised instead of child routes on the interfaces that have IP addresses
in different major network. Summary routes are advertised using the best metric of all
the child routes.
For example, router 10.1.1.0/24 (metric=2) and router 10.1.2.0/24 (metric=3) are
aggregated as an aggregated route (10.0.0.0/8(metric=2)) in the natural network segment.
Because RIP-2 aggregation is classful, obtains the optimal metric.
l Interface-based aggregation:
A user can specify an aggregation address.
For example, router 10.1.1.0/24(metric=2) and router 10.1.2.0/24 (metric=3) are
aggregated as an aggregated route (10.1.0.0/16(metric=2)).
5.4.2.6 Multi-process and Multi-instance

For easy management and effective control, RIP supports the features multi-process and
multi-instance. The multi-process feature allows a set of interfaces to be associated with a
specific RIP process. This ensures that the process performs all the protocol operations only
on this set of interfaces. Therefore, multiple RIP processes can work on a single router and
each process is responsible for a unique set of interfaces. In addition, the routing data is
independent between RIP processes. However, routes can be imported between processes.
For routers that support VPN, you can associate each RIP process with a specific VPN
instance. In this case, all the interfaces attached to the RIP process should be associated with
the RIP-process-related VPN instance.
5.4.3 RIP Configuration Using the Web UI

This section describes how to use the Web UI to configure RIP.
Creating a RIP Process

Step 1 Choose Network > Route > RIP.
Step 2 Click Add.
Step 3 Enter or select the parameters.

Process ID The system supports RIP multi-process. If multiple RIP

processes are enabled on one device, different process IDs
need to be specified. An RIP process ID is a local concept. The
devices with different process IDs can exchange packets in
between.
Virtual Router Indicates the virtual system.
Version Indicates the RIP version number.
Default Cost Indicates the cost of running the RIP protocol.
Balanced Paths Indicates the maximum number of equal-cost routes.

Update Interval Indicates the interval of updating packets regularly in the RIP
route.
Garbage Collection Indicates the interval for collecting RIP garbage routes.
Duration
Timeout Indicates the timeout interval of the RIP route.
Priority Indicates the preference of the RIP.
Enable Default Route Configures the default route for the situation that packets
cannot find corresponding routing entries in the routing table.
Default Route Cost Indicates the metric value of the default route.
This parameter is available when Enable Default Route is
enabled.
Source Address Verifies the source IP address of a received RIP route update
Verification packet.
Host Route Indicates that host routes can be added to the routing table.
Zero Field Check Checks the zero fields in a RIP-1 packet.

Certain fields in a RIP-1 packet must be zero. These fields are
called zero fields.
If the interface version is set to RIP-1, zero field check is
required on packets. This parameter is invalid for the RIP-2
packets because the zero field does not exist in RIP-2 packets.
Step 4 Click OK.
If the new RIP process is displayed on the page, the operation succeeds.
----End
Configuring a Network Segment for a RIP Process

Step 2 Click corresponding to the RIP process to be modified.
Step 3 In the RIP Process ID:ID navigation tree, choose Basic Configuration > Network Settings.
Step 4 Click Add.
Step 5 Enter a network segment address to be added.

NOTE
RIP supports the following natural network segments:

1 to 126.0.0.0, 128 to 191.x.0.0, 192 to 223.x.x.0.
Step 6 Click OK.

If the new network segment is displayed on the page, the operation succeeds.
----End
Modifying a RIP Interface

Step 3 In the RIP Process ID:ID navigation tree, choose Basic Configuration > Interface Settings.
Step 4 Click corresponding to the interface to be configured.

Interface Name Indicate the name of a RIP interface.
Authentication Mode Indicates the mode in which the interface authenticates

packets.
l NONE: indicates that authentication is not performed on
packets.
l Simple: indicates that simple authentication is performed on
packets.
l MD5: indicates that MD5 authentication is performed on
packets.
l HMAC-SHA256: indicates that HMAC-SHA256
authentication is performed on packets.
Key Indicates the identifier of the MD5 authentication key.

This parameter is required when Authentication Mode is the
MD5 authentication.
Password Indicates the authentication key.

MD5 authentication or simple authentication.
Confirm Password Confirms the password.

MD5 authentication.
Advanced Settings
Receiving of RIP Packets Indicates that the interface is allowed to receive RIP update
packets.
Sending of RIP Packets Indicates that the interface is allowed to send RIP update
packets.

Anti-Loop Mechanism Split Horizon: indicates that the interface does not send the
routes received by the interface.
Poison Reverse: RIP learns the route of the packet from an
interface, sets the route cost to 16 (unreachable), and sends the
packet to the neighbor router through the original interface.
Version Indicates the version of RIP packets received by the interface.

The RIP has two versions: RIP-1 and RIP-2. The RIP-1 is a
classful routing protocol, supporting the advertisement of
protocol packets in broadcast mode. The RIP-2 is a classless
routing protocol, supporting the transmission of packets in both
broadcast mode and multicast mode.
Sending Mode The RIP-2 packets can be transferred in two modes: broadcast
and multicast.
Receiving Offset Indicates the metric value added when the interface receives
routes.
Sending Offset Indicates the metric value added when the interface sends
routes.
Sending Interval Indicates the interval for the interface to send update packets.
Maximum Sending Indicates the number of update packets allowed on the

Packets interface each time.
Step 6 Click OK.
----End
Configuring Route Importing for a RIP Process

If a router runs the RIP and other routing protocols, you can configure the RIP to import
external route information, and to filter out unnecessary routes and specify a metric value. If
no metric value is specified, the default metric value takes effect.
Step 3 In the RIP Process ID:ID navigation tree, choose Advanced Settings > Route Import.
Step 4 Click Add.
Table 5-9 Adding a route import configuration

Route Type Indicates the imported source routing protocol.

Process ID The routing protocol process ID needs to be specified when the route type
is ospf, rip, or isis.
Cost Indicates the cost of an imported route.
Step 6 Click OK.

If the new route import configuration is displayed on the page, the operation succeeds.
----End
Configuring Route Filtering

A router provides a routing information filtering function. By specifying an ACL and an IP
address prefix list, you can configure an ingress or egress filtering policy to filter the received
and released routes.
Step 2 Click corresponding to the RIP progress to be modified.
Step 3 In the RIP Process ID:ID navigation tree, choose Advanced Settings > Route Filter.
Step 4 Click Add.

Filter Type Indicate the route filter type of the RIP. After this parameter is
set, it cannot be changed.
l Import: indicates that the RIP filters received routing
information.
l Export: indicates that the RIP filters advertised routing
information.
Route Type Advertise routes by the route type based filtering. This
parameter is required when the filter type is export. After this
parameter is set, it cannot be changed.
Process ID Specifies the process ID for OSPF, RIP, and ISIS. After this
Interface Name Advertises routes by the egress based filtering. After this
Either route type based filtering or egress based filtering can be
selected.

ACL Number Indicates the basic ACL number.

You can select an existed ACL or select Basic ACL to create a
new ACL.
Source Address, Schedule, and Action are available when
Filter Mode is ACL and ACL is Basic ACL.
Source Address Indicates the source IP address for filtering routes or the name
of the source address/address group.
You can select an existed address/address group or create a
new address/address group.
Schedule Indicates the time range during which route filtering takes
effect.
You can select an existed time range or create a new time
range.
Action Indicates the action taken by the device towards the route.
l permit: indicates the action configured by the policy is
performed on the route.
l deny: indicates that the action configured by the policy is
not performed on the route.
Step 6 Click OK.
If the new route filtering policy is displayed on the page, the operation succeeds.
----End
Configuring a RIP Peer

Usually, the RIP sends packets by using broadcast or multicast addresses.
To use the RIP as a routing protocol on a network that does not support broadcasting or
multicasting, you need to specify a RIP peer manually.
Step 3 In the RIP Process ID:ID navigation tree, choose Advanced Settings > Peer Settings.
Step 4 Click Add.
Step 5 Enter the IP address of the RIP peer.
Step 6 Click OK.
If the new RIP peer is displayed on the page, the operation succeeds.
----End

Configuring a Passive Interface

After an interface is configured not to send RIP update packets, the interface does not send
RIP updates to networks. This does not affect the advertisement of directly connected routes.
This function enhances the RIP networking capability and reduces the system resource
consumption.
Step 3 In the RIP Process ID:ID navigation tree, choose Advanced Settings > Passive Interface.
Step 4 Select the interface to be disabled.
Step 5 Click Apply.
----End
5.4.4 RIP Configuration Using the CLI

RIP can advertise and receive routes to affect the selection of data forwarding paths, and can
provide the network management function. RIP is commonly used on small-scale networks.
5.4.4.1 Establishing the RIP Neighbor Relationship

To implement RIP features, establishing the RIP neighbor relationship including enabling RIP,
specifying the network segment in which RIP runs, and setting the RIP version.
5.4.4.1.1 Enabling RIP

Creating RIP processes is the prerequisite to performing RIP configurations.
Prerequisites
Before enabling RIP, complete the following tasks:
l Configuring the link layer protocol
l Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
Context
If you run RIP-related commands in the interface view before enabling RIP, the
configurations take effect only after RIP is enabled.
Perform the following steps on the FW to be enabled with RIP:
Procedure
Step 1 Run:
system-view

Step 2 Run:

rip [ process-id ]
The RIP is enabled and the RIP view is displayed.
RIP supports multi-instance. To associate RIP processes with VPN instances, you can run the
rip [ process-id ] vpn-instance vpn-instance-name command.
NOTE
For easy management and effective control, RIP supports multi-process and multi-instance. The multi-
process feature allows a set of interfaces to be associated with a specific RIP process and an interface
can be associated with only one RIP process. This ensures that the specific RIP process performs all the
protocol operations only on this set of interfaces. Therefore, multiple RIP processes can work on a single
router and each process is responsible for a unique set of interfaces. In addition, the routing data is
independent between RIP processes; however, routes can be imported between processes.
For the routers that support the VPN, each RIP process is associated with a specific VPN instance. In
this case, all the interfaces attached to the RIP process should be associated with the RIP-process-related
VPN instance.

description text
Descriptions for RIP processes are configured.
----End
5.4.4.1.2 Enabling RIP on the Specified Network Segment

After enabling RIP, you need to specify the network segment in which RIP runs. RIP runs
only on the interfaces on the specified network segment. RIP does not receive, send, or
forward routes on the interfaces that do not reside on the specified network segment.
Context
By default, after RIP is enabled, it is disabled on all interfaces.
Perform the following steps on the FW to be enabled with RIP.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
The RIP process is enabled and the RIP view is displayed.
Step 3 Run:
network network-address
RIP is enabled in the specified network segment.
network-address specifies the address of a natural network segment.

NOTE
An interface can be associated with only one RIP process.

If any network segment in which an interface configured with multiple sub-interface IP addresses
resides is associated with a RIP process, the interface cannot be associated with any other RIP processes.
----End
5.4.4.1.3 Configuring RIP Version Number

RIP versions include RIPv1 and RIPv2. The two versions have different functions.
Context
Perform the following steps on the RIP FW.
Procedure
l Configuring the Global RIP Version Number
a. Run:
system-view

b. Run:
rip [ process-id ]

c. Run:
version { 1 | 2 }
The global RIP version number is specified.

The RIP-1 protocol poses a security risk, and therefore the RIP-2 protocol is
recommended.
l Configuring the RIP Version Number for an Interface
a. Run:
system-view

b. Run:

c. Run:
rip version { 1 | 2 [ broadcast | multicast ] }
The RIP version number of the packets received by the interface is specified.

NOTE
By default, an interface receives both RIPv1 and RIPv2 packets but sends only RIPv1
packets. When configuring RIPv2 on an interface, you can specify the mode in which the
interface sends packets. If no RIP version number is configured in the interface view, the
global RIP version is used. The RIP version set on an interface takes precedence over the
global RIP version.
The RIP-1 protocol poses a security risk, and therefore the RIP-2 protocol is recommended.
----End
5.4.4.2 Controlling the Advertising of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the advertising of RIP
routing information is essential.
5.4.4.2.1 Configuring RIP to Advertise Default Routes

A default route is a route destined for 0.0.0.0. By default, RIP does not advertise default
routes to its neighbors.
Context
Perform the following steps on the RIP FW:
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
default-route originate [ cost cost | tag tag | { match default | route-policy
route-policy-name [ advertise-tag ] } [ avoid-learning ] ] *
RIP is configured to generate a default route only if route permitted by the route policy is
present as active in the routing table.
----End
5.4.4.2.2 Disabling an Interface from Sending RIP Update Packets

Disabling interfaces from sending RIP Update packets is a method of preventing routing
loops and can be implemented in two ways.
Context

Procedure
l Disable an interface from sending RIP Update packets in a RIP process (with a high
priority).
a. Run:
system-view

b. Run:
rip [ process-id ]
The RIP process is enabled, and the RIP view is displayed.

c. Run:
silent-interface interface-type interface-number
A specified interface is disabled from sending RIP Update packets.

You can configure an interface as a silent interface so that it only receives RIP
Update packets to update its routing table.
NOTE
You can run the silent-interface all command to disable all RIP interfaces from sending RIP
Update packets.
The silent-interface command takes precedence over the rip output command configured
in the interface view. By default, an interface can both send and receive RIP Update packets.
l Disable an interface from sending RIP Update packets in the interface view (with a low
priority).
a. Run:
system-view

b. Run:

c. Run:
undo rip output
The interface is disabled from sending RIP Update packets.

By running this command, you can specify whether to send RIP Update packets on
an interface. The silent-interface command takes precedence over the undo rip
output command. By default, an interface is allowed to send RIP Update packets.
----End
5.4.4.2.3 Configuring RIP-2 Route Summarization

RIP-2 route summarization can reduce the size of a routing table and improve network
efficiency. By default, RIP-2 route summarization is enabled. To broadcast all subnet routes,
you can disable RIP-2 route summarization.
Context
Route summarization indicates that multiple subnet routes on the same natural network
segment are summarized into one route with the natural mask when being advertised to other

network segments. Therefore, route summarization reduces the network traffic and the size of
the routing table.
Route summarization is enabled for RIP-2 by default, but is invalid for RIP-1. To broadcast
all subnet routes, you can disable RIP-2 automatic route summarization.
NOTE
Route summarization is invalid when poison reverse is configured. When the summarized routes are
sent outside the natural network boundary, poison reverse in related views needs to be disabled.
Procedure
l Enable RIP-2 automatic route summarization
a. Run:
system-view

b. Run:
rip [ process-id ]

c. Run:
version 2
RIP-2 is configured.
d. Run:
summary [ always ]
Route summarization is enabled.
n Enable the RIP-2 automatic route summarization when split horizon is

disabled, there is no need to configure always.
n Enable the RIP-2 automatic route summarization irrespective of split horizon
configuration, always must be configured.
NOTE
The summary command is used in the RIP view to enable classful network-based route
summarization.
l Configure RIP-2 to advertise the summary address
a. Run:
system-view

b. Run:

c. Run:
rip summary-address ip-address mask [ avoid-feedback ]
The local summary address of RIP-2 is advertised.

NOTE
The rip summary-address ip-address mask [ avoid-feedback ] command is run in the

interface view to enable classless network-based route summarization.
----End
5.4.4.3 Controlling the Receiving of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the receiving of RIP
routing information is essential.
5.4.4.3.1 Disabling an Interface from Receiving RIP Update Packets

Disabling interfaces from receiving Update packets is a method of preventing routing loops.
Context
By default, an interface is allowed to receive RIP Update packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
undo rip input
The interface is disabled from receiving RIP Update packets.
----End
5.4.4.3.2 Disabling RIP from Receiving Host Routes

When you disable RIP from receiving host routes on a router, the router rejects to receive host
routes. This prevents the router from receiving a large number of unnecessary routes and
therefore avoiding wasting network resources.
Context
In certain situations, a FW may receive a large number of host routes from the same network
segment. These routes are not required in route addressing, but consume many network
resources. You can configure the FW to refuse to accept host routes by disabling RIP from
accepting host routes.
By default, host routes are added to the routing table.

Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
undo host-route
RIP is disabled from adding host routes to the routing table.
NOTE
undo host-route command will not be effective in RIP version 2. By default, RIP version 2 always
supports host-route.
----End
5.4.4.3.3 Configuring RIP to Filter the Received Routes

By specifying ACLs and IP prefix lists, you can configure the inbound policy to filter the
routes to be received. You can also configure a router to receive only RIP packets from a
specified neighbor.
Context
The FW can filter routing information. To filter the imported and advertised routes, you can
configure inbound and outbound routing policies by specifying ACLs and IP prefix lists.
You can also configure the FW to receive RIP packets only from a specified neighbor.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Depending on type of desired filtering, run one of following commands to configure RIP to
filter the received routes:
l Based on the basic ACL:
Run filter-policy acl-number import [ interface-type interface-number ], the learned
routing information is filtered based on an ACL.
l Based on the IP prefix:

– Run filter-policy gateway ip-prefix-name import, the routing information

advertised by neighbors is filtered based on the IP prefix list.
– Run filter-policy ip-prefix ip-prefix-name [ gateway ip-prefix-name ] import
[ interface-type interface-number ], the routes learned by the specified interface are
filtered based on the IP prefix list and neighbors.
----End
5.4.4.4 Configuring RIP to Import External Routes

RIP can import external routes to enrich routing information.
Prerequisites
Before configuring RIP to import external routes, complete the following tasks:
the network layer
Context
To access a device running a non-RIP protocol, an RIP-capable device needs to import routes
of the non-RIP protocol into the RIP network.
All the following commands can set the cost of the imported route, which are listed in
descending order of priorities.
l Run the apply cost command to set the cost of a route.
l Run the import-route (RIP)command to set the cost of the imported route.
l Run the default-cost (RIP) command to set the cost of the default route.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]

default-cost cost
The default cost of imported routes is set.

If no cost is specified, this command can be used to set the default cost for the external routes
imported by RIP from other routing protocols.
Step 4 Run:
import-route bgp [ permit-ibgp ] [ cost { cost | transparent } | route-policy
route-policy-name ] * or import-route { { static | direct | unr } | { { rip |
ospf | isis } [ process-id ] } } [ cost cost | route-policy route-policy-name ] *

NOTE
Import of IBGP routes in RIP process can lead to routing loops. Administrator should take care of
routing loops before configuring permit-ibgp.
----End
5.4.4.5 Configuring the RIP Routing

By setting RIP route attributes, you can change RIP routing policies to meet the requirements
of complex networks.
5.4.4.5.1 Configuring Additional Metrics of an Interface

The additional metric is the metric (hop count) to be added to the original metric of a RIP
route. You can specify commands to set additional metrics for incoming and outgoing RIP
routes.
Context
The additional metric is added to the original metric of the RIP route.
l The rip metricin command is used to add an additional metric to an incoming route.
After this route is added to the routing table, its metric in the routing table
changes.Running this command affects route selection on the local device and other
devices on the network.
l The rip metricout command is used to add an additional metric to an outgoing route.
When this route is advertised, an additional metric is added to this route, but the metric
of the route in the routing table does not change. Running this command does not affect
route selection on the local device or other devices on the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run any of the following commands as required:
Run rip metricin { value | acl-number value1 }, the metric added to an incoming route
is set.
Run rip metricin { value | ip-prefix ip-prefix-name value1 }.
NOTE
You can specify the value of the metricin to be added to the RIP route that passes the filtering policy by
specifying value1 through an ACL or an IP prefix list. If a RIP route does not pass the filtering, its
metric is not incremented.

Step 4 Run any of the following commands as required:

Run rip metricout { value | acl-number value1 }, the metric added to an outgoing route
is set.
Run rip metricout { value | ip-prefix ip-prefix-name value1 }.
NOTE
You can specify the value of the metricout to be added to the RIP route that passes the filtering policy by
specifying value1 through an ACL or an IP prefix list. If a RIP route does not pass the filtering, its
metric is increased by 1.
----End
5.4.4.5.2 Configuring RIP Preference

When there are routes discovered by multiple routing protocols on the same FW, you can set
RIP preferences to instruct the FW to prefer certain RIP routes over others.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
preference { preference | route-policy route-policy-name } *
The RIP preference is set.
By default, the RIP preference is 100.
----End
5.4.4.5.3 Setting the Maximum Number of Equal-Cost Routes

By setting the maximum number of equal-cost RIP routes, you can change the number of
routes for load balancing.
Context

Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]

Step 3 Run:
maximum load-balancing number
The maximum number of equal-cost routes is set.
NOTE
When the number of equal-cost routes is greater than number specified in the maximum load-
balancing command, valid routes are selected for load balancing based on the following criteria:
1. Interface index: If routes have the same priorities, routes with higher interface index values are
selected for load balancing.
2. Next hop IP address: If routes have the same priorities and interface index values, routes with larger
IP address are selected for load balancing.
----End
5.4.4.6 Optimizing a RIP Network

You can optimize the RIP network performance by configuring RIP functions in special
network environments, such as configuring RIP timers, setting the interval for sending
packets, and setting the maximum number of packets to be sent.
5.4.4.6.1 Configuring RIP Timers

RIP has three timers: Update timer, Age timer and Garbage-collect timer. Changing the values
of the three timers affects the RIP convergence speed.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]

Step 3 Run:
timers rip update age garbage-collect
RIP timers are configured.

NOTE
l RIP timers take effect immediately after being changed.

l Route flapping occurs if the values of the times are set improperly. The relationship between the
values is as follows: update must be smaller than age and update must be smaller than garbage-
collect. For example, if the update time is longer than the aging time, and a RIP route changes within
the update time, the FW cannot inform its neighbors of the change on time.
l You must configure RIP timers based on the network performance and uniformly on all the FW
running RIP. This avoids unnecessary network traffic or route flapping.
By default, the Update timer is 30s; the Age timer is 180s; the Garbage-collect timer is four
times the Update timer, namely, 120s.
In practice, the Garbage-collect timer is not fixed. If the Update timer is set to 30s, the
Garbage-collect timer may range from 90s to 120s.
Before permanently deleting an unreachable route from the routing table, RIP advertises this
route (with the metric being set to 16) by periodically sending Update packets four times.
Subsequently, all the neighbors know that this route is unreachable. Because a route may not
always become unreachable at the beginning of an Update period, the Garbage-collect timer is
actually three or four times the Update timer.
----End
5.4.4.6.2 Setting the Interval for Sending Packets and the Maximum Number of the Sent
Packets
By setting the interval for sending RIP Update packets and the maximum number of Update
packets to be sent each time, you can effectively control the memory used by a FW to process
RIP Update packets.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
rip pkt-transmit { interval interval | number pkt-count } *
The interval for sending Update packets and the maximum number of packets sent each time
are set on the interface.
----End
5.4.4.6.3 Configuring Split Horizon and Poison Reverse

You can configure split horizon and poison reverse to prevent routing loops.

Context
l The principle of split horizon is that a route learned by RIP on an interface is not sent to
neighbors from the interface. This reduces bandwidth consumption and avoids route
loops.
l The principle of poison reverse is that RIP sets the cost of the route learned from an
interface of a neighbor to 16 (to specify the route as unreachable) and then sends the
route from the interface back to the neighbor. In this way, RIP can delete useless routes
from the routing table of the neighbor and also avoid route loops.
If both split horizon and poison reverse are configured, only poison reverse takes effect.
On Non-Broadcast Multi-Access (NBMA) networks such as frame relay (FR) and X.25
networks, split horizon is disabled by default.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run the following command as required:
l Run:
rip split-horizon
Split horizon is enabled.

l Run:
rip poison-reverse
Poison reverse is enabled.
----End
5.4.4.6.4 Configuring RIP to Check the Validity of Update Packets

The check on RIP Update packets includes the check on zero fields in RIPv1 packets and the
check on source addresses of RIP Update packets. The two types of check have different
functions and applications.
Context
Procedure
l Configuring the Zero Field Check for RIPv1 Packets
a. Run:
system-view

b. Run:
rip [ process-id ]

c. Run:
checkzero
The zero field check is configured for RIPv1 packets.

Certain fields in a RIPv1 packet must be 0s, and these fields are called zero fields.
RIPv1 checks the zero fields on receiving a packet. If the value of any zero field in
a RIPv1 packet is not 0, this packet is not processed.
As a RIPv2 packet does not contain any zero field, configuring the zero field check
is invalid in RIPv2.
l Configuring the Source Address Check for RIP Update Packets
a. Run:
system-view

b. Run:
rip [ process-id ]

c. Run:
verify-source
The source address check is configured for RIP Update packets.

When receiving a packet, RIP checks the source address of the packet. If the packet
fails in the check, it is not processed.
By default, the source address check is enabled.
----End
5.4.4.6.5 Configuring RIP Neighbors

Generally, RIP sends packets by using broadcast or multicast addresses. To run RIP on the
links that do not support the forwarding of broadcast or multicast packets, you need to specify
RIP neighbors.
Context
Generally, RIP sends packets by using broadcast or multicast addresses. If RIP needs to run
on the links that do not support the forwarding of broadcast or multicast packets, you need to
configure the devices at both ends of the link as each other's neighbor.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]

Step 3 Run:
peer ip-address
The RIP neighbor is configured.
----End
5.4.4.7 Improve the RIP Network Security

If an RIP network requires high security, you can configure a RIP authentication mode to
improve network security.
5.4.4.7.1 Configuring Packet Authentication of RIP-2

RIP-2 supports the ability to authenticate protocol packets. By default, authentication is not
configured for RIP. Configuring authentication is recommended to ensure system security.
Context
RIP-2 supports the following authentication modes:
l Simple authentication
l MD5 authentication
l HMAC-SHA256 authentication
l Keychain authentication
In simple authentication mode, the unencrypted authentication key is sent in every RIP-2
packet. Therefore, simple authentication does not guarantee security, and cannot meet the
requirements for high security.
NOTICE
When configuring an authentication password, select the ciphertext mode becasue the
password is saved in configuration files in plaintext if you select plaintext mode, which has a
high risk. To ensure device security, change the password periodically.
Perform the following steps on the RIP FW.
Procedure
Step 1 Run:
system-view

Step 2 Run:


l Run:
rip authentication-mode simple { plain plain-text | [ cipher ] password-key }
Simple authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode md5 usual { plain plain-text | [ cipher ] password-
key }
MD5 usual authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode md5 nonstandard { keychain keychain-name | { plain
plain-text | [ cipher ] password-key } key-id }
MD5 nonstandard authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-
key } key-id
hmac-sha256 authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode keychain keychain-name
Keychain authentication is configured for RIP-2 packets.

NOTE
The MD5 type must be specified if MD5 authentication is configured. The usual type supports private
standard authentication packets, and the nonstandard type supports IETF standard authentication
packets.
When configuring an authentication password, select the ciphertext mode because the simple password
is saved in configuration file if you select the simple text mode, which poses a high risk. To improve
device security, change the password periodically.
----End
5.4.4.8 Enhancing the RIP Network Reliability

Configuring RIP GR and BFD for RIP improves RIP network convergence and enhances RIP
reliability.
5.4.4.8.1 Configuring RIP GR

This section describes how to configure RIP GR to avoid incorrect route calculation and
packet loss after a FW on which RIP has been enabled restarts.
Prerequisites
Before configuring RIP GR, complete the following tasks:
the network layer
l Establishing the RIP Neighbor Relationship, establish the neighbor relationship
successfully

Context
To avoid traffic interruption and route flapping caused by master/slave switchover, you can
enable RIP graceful restart (GR). GR is a technology used to ensure normal traffic forwarding
and non-stop forwarding of key services during the restart of routing protocols.
After a RIP process is restarted through GR, the Restarter and the Helper re-establish the
neighbor relationship and update the routing table and forwarding table. This ensures non-
stop traffic forwarding and stabilizes the network topology. During RIP GR, except the
neighbor of the device where master/slave switchover occurs, other FWs do not detect the
route change.
NOTE
In practice, you can configure RIP GR on the device with two main control boards to prevent service
forwarding from being affected by the fault on one main control board.
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]
The RIP view is displayed.

Step 3 Run:
graceful-restart [ period period | wait-time time | planned-only time ] *
RIP GR is enabled.
When most FWs on a network do not support RIP GR, setting wait-time time to a larger
value is recommended. This ensures that the Restart FW has enough time to learn correct
routes.
----End
Follow-up Procedure
If the Restarter finishes GR within the GR period specified by period period, the Restarter
automatically exits from GR. Otherwise, the Restarter is forced to exit from GR.
5.4.4.8.2 Configuring BFD for RIP

On a network that runs high-rate data services, BFD for RIP can be configured to quickly
detect and respond to network faults.
Prerequisites
Before configuring BFD for RIP, complete the following tasks:
l Assigning an IP address to each interface to ensure reachability between neighboring
nodes at the network layer

Context
Generally, RIP uses timers to receive and send Update messages to maintain neighbor
relationships. If a RIP device does not receive an Update message from a neighbor after the
Age timer expires, the RIP device will announce that this neighbor goes Down. The default
value of the Age timer is 180s. If a link fault occurs, RIP can detect this fault after 180s. If
high-rate data services are deployed on a network, a great deal of data will be lost during the
aging time.
BFD provides millisecond-level fault detection. It can rapidly detect faults in protected links
or nodes and report them to RIP. This speeds up RIP processes's response to network topology
changes and achieves rapid RIP route convergence.
In BFD for RIP, BFD session establishment is triggered by RIP. When establishing a neighbor
relationship, RIP will send detection parameters of the neighbor to BFD. Then, a BFD session
will be established based on these detection parameters. If a link fault occurs, the local RIP
process will receive a neighbor unreachable message within seconds. Then, the local RIP
device will delete routing entries in which the neighbor relationship is Down and use the
backup path to transmit messages.
Either of the following methods can be used to configure BFD for RIP:
l Enable BFD in a RIP process: This method is recommended when BFD for RIP needs
to be enabled on most RIP interfaces.
l Enable BFD on RIP interfaces: This method is recommended when BFD for RIP needs
to be enabled on a small number of RIP interfaces.
Procedure
l Enable BFD in a RIP process.
a. Run:
system-view

b. Run:
bfd
BFD is enabled globally.

c. Run:
quit

d. Run:
rip process-id
The RIP view is displayed.

e. Run:
BFD is enabled in the RIP process to establish a BFD session.
If BFD is enabled globally, RIP will use default BFD parameters to establish BFD
sessions on all the interfaces where RIP neighbor relationships are in the Up state.
f. Optional: Run:

bfd all-interfaces { min-rx-interval min-receive-value | min-tx-

interval min-transmit-value | detect-multiplier detect-multiplier-
value } *
The values of BFD parameters used to establish the BFD session are set.
BFD parameter values are determined by the actual network situation and network
reliability requirement.
n If links have a high reliability requirement, reduce the interval at which BFD
packets are sent.
n If links have a low reliability requirement, increase the interval at which BFD
packets are sent.
Running the bfd all-interfaces command changes BFD session parameters on all
RIP interfaces. The default detection multiplier and interval at which BFD packets
are sent are recommended.
g. (Optional) Perform the following operations to prevent an interface in the RIP
process from establishing a BFD session:
n Run the quit command to return to the system view.
n Run the interface interface-type interface-number command to enter the view
of a specified interface.
n Run the rip bfd block command to prevent the interface from establishing a
BFD session.
l Enable BFD on RIP interfaces.
a. Run:
system-view

b. Run:
bfd
BFD is enabled globally.

c. Run:
quit

d. Run:
The view of the specified interface is displayed.

e. Run:
rip bfd enable
BFD is enabled on the interface to establish a BFD session.

f. (Optional) Run:
rip bfd { min-rx-interval min-receive-value | min-tx-interval min-
transmit-value | detect-multiplier detect-multiplier-value } *
The values of BFD parameters used to establish the BFD session are set.
----End


After enabling BFD for RIP at both ends of a link, run the display rip process-id bfd session
{ interface interface-type interface-number | neighbor-id | all } command. You can see that
the BFDState field value on the local FW is displayed Up.For example:
<FW> display rip 1 bfd session all
LocalIp :10.1.0.1 RemoteIp :10.1.0.2 BFDState :Up
TX :1000 RX :1000 Multiplier:3
BFD Local Dis:8192 Interface :GigabitEthernet0/0/0
DiagnosticInfo: No diagnostic information
LocalIp :10.2.0.1 RemoteIp :10.2.0.2 BFDState :Up
TX :1000 RX :1000 Multiplier:3
BFD Local Dis:8193 Interface :GigabitEthernet0/0/1
DiagnosticInfo: No diagnostic information
5.4.4.9 Configuring the Network Management Function in RIP

By binding RIP to MIBs, you can view and configure RIP through the NMS.
Prerequisites
Before configuring the network management function in RIP, complete the following tasks:
the network layer
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip mib-binding process-id
RIP is bound to MIBs.

This command is used to bind a RIP process ID to MIBs and specify the ID of the RIP
process that accepts Simple Network Management Protocol (SNMP) requests.
----End
5.4.5 Maintaining RIP

The RIP route can be checked, cleared, and debugged after being configured.

Displaying the RIP Configuration
Table 5-10 Displaying the RIP configuration

Action Command
Display the current display rip [ process-id | vpn-instance vpn-instance-name ]

running status and
configuration
information of RIP.
Display all activated display rip process-id database [ verbose ]

routes in the RIP
advertising database.
Display RIP interface display rip process-id interface [ interface-type interface-

information. number ] [ verbose ]
Display RIP display rip process-id neighbor [ verbose ]

neighboring
information.
Display all RIP display rip process-id route

routes.
Clearing RIP
To clear RIP running information, run the following commands in the user view.
Table 5-11 Clearing RIP routing information

Action Command
Reset a RIP process. reset rip process-id configuration
Clear RIP process reset rip process-id statistics [ interface { all | interface-type
statistics. interface-number [ neighbor neighbor-ip-address ] } ]

This describes the examples for configuring RIP network interconnection and importing
external routes.
5.4.6.1 CLI: Example for Configuring RIP Version

You can configure RIP-2 on small IP networks to implement network interconnection.
As shown in Figure 5-12, it is required that RIP be enabled on all interfaces of FW_A,
FW_B, FW_C, and FW_D and the routers interconnect with each other through RIP-2.

Figure 5-12 Networking diagram of configuring the RIP version number
FW_C
GE1/0/0
172.16.1.2/24
GE2/0/0
172.16.1.1/24
GE1/0/0 GE3/0/0
192.168.1.1/24 10.1.1.2/24
GE1/0/0 GE3/0/0
192.168.1.2/24 10.1.1.1/24
FW_A FW_B FW_D
1. Configure the IP address of each interface to make the network layers accessible.
2. Enable RIP on each FW and configure basic RIP functions.
3. Configure RIP-2 on each FW and check the subnet masks.
Data Preparation
l RIP network segment 192.168.1.0 on FW_A
l RIP network segment 192.168.1.0, 172.16.0.0, and 10.0.0.0 on FW_B
l RIP network segment 172.16.0.0 on FW_C
l RIP network segment 10.0.0.0 on FW_D
l RIP-2 on FW_A, FW_B, FW_C, and FW_D
Procedure
Step 1 Set the IP addresses for the interfaces, add the interfaces to security zones, and configure the
interzone security policy. (Omitted)
Step 2 Configure basic RIP functions.
# Configure FW_A.
[FW_A] rip
[FW_A-rip-1] network 192.168.1.0
[FW_A-rip-1] quit
# Configure FW_B.
[FW_B] rip
[FW_B-rip-1] network 192.168.1.0
[FW_B-rip-1] quit

# Configure FW_C.
[FW_C] rip
[FW_C-rip-1] network 172.16.0.0
[FW_C-rip-1] quit
# Configure FW_D.
[FW_D] rip
[FW_D-rip-1] network 10.0.0.0
[FW_D-rip-1] quit
# Check the RIP routing table of FW_A.

[FW_A] display rip 1 route
Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.0.0.0/8 192.168.1.2 1 0 RA 14
172.16.0.0/16 192.168.1.2 1 0 RA 14
192.168.1.0/24 192.168.1.2 1 0 RA 14
From the routing table, you can view that the routes advertised by RIP-1 use natural masks.
Step 3 Configure the RIP version number.
# Configure RIP-2 on FW_A.
[FW_A] rip
[FW_A-rip-1] version 2
[FW_A-rip-1] quit
# Configure RIP-2 on FW_B.

[FW_B] rip
[FW_B-rip-1] version 2
[FW_B-rip-1] quit
# Configure RIP-2 on FW_C.

[FW_C] rip
[FW_C-rip-1] version 2
[FW_C-rip-1] quit
# Configure RIP-2 on FW_D.

[FW_D] rip
[FW_D-rip-1] version 2
[FW_D-rip-1] quit

# Check the RIP routing table of FW_A.
[FW_A] display rip 1 route
Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.1.1.0/24 192.168.1.2 1 0 RA 32
172.16.1.0/24 192.168.1.2 1 0 RA 32
192.168.1.0/24 192.168.1.2 1 0 RA 14
From the routing table, you can view that the routes advertised by RIP-2 contain accurate
subnet masks.
----End

#
sysname FW_A
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
#
return

#
sysname FW_B
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
network 172.16.0.0
network 10.0.0.0
#
return

#
sysname FW_C
#
undo shutdown
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return
Configuration script for FW_D:

#
sysname FW_D
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
rip 1
version 2
network 10.0.0.0

#
return
5.4.6.2 CLI: Example for Configuring RIP to Import External Routes

You can configure the router to implement route interaction among different RIP processes
and configure the ACL to filter imported routes.
As shown in Figure 5-13, two RIP processes, RIP 100 and RIP 200, run on FW_B. FW_B
exchanges routing information with FW_A through RIP 100. FW_B exchanges routing
information with FW_C through RIP 200.
It is required that the two processes of FW_B import the RIP routes from each other. The cost
of the imported RIP 200 routes defaults to 3.
It is required that a filtering policy be configured on FW_B to filter out the imported RIP 200
route 192.168.4.0/24 and prevent it from being advertised to FW_A.
Figure 5-13 Networking diagram of configuring RIP to import external routes
GE 2/0/0
192.168.0.1/24
GE 2/0/0
GE 1/0/0 GE 1/0/0 192.168.3.1/24
192.168.1.1/24 192.168.2.2/24
GE 1/0/0 GE 2/0/0 GE 3/0/0
192.168.1.2/24 192.168.2.1/24 192.168.4.1/24
FW_A FW_C
FW_B
RIP 100 RIP 200
1. Enable RIP 100 and RIP 200 on each FW and specify the network segments.
2. Configure the two processes on FW_B to import the routes from each other and set the
default cost of the imported RIP 200 routes to 3.
3. Configure an ACL on FW_B to filter the routes imported from RIP 200.
Data Preparation
l RIP 100 on FW_A and the network segment 192.168.1.0 and 192.168.0.0
l RIP 100 and RIP 200 on FW_B and the network segment 192.168.1.0 and 192.168.2.0
l RIP 200 on FW_C and the network segment 192.168.2.0, 192.168.3.0, and 192.168.4.0
l Default cost of the imported RIP 200 routes as 3; ACL 2000 to deny the route with the
source network segment of 192.168.4.0 and import RIP100 routes to RIP 200

Procedure
Step 2 Configure basic RIP functions.
# Enable RIP process 100 on FW_A.
[FW_A] rip 100
[FW_A-rip-100] network 192.168.0.0
[FW_A-rip-100] network 192.168.1.0
[FW_A-rip-100] quit
# Enable the two RIP processes, process 100 and process 200, on FW_B.
[FW_B] rip 100
[FW_B-rip-100] network 192.168.1.0
[FW_B-rip-100] quit
[FW_B] rip 200
[FW_B-rip-200] network 192.168.2.0
[FW_B-rip-200] quit
# Enable RIP process 200 on FW_C.

[FW_C] rip 200
[FW_C-rip-200] network 192.168.2.0
[FW_C-rip-200] network 192.168.3.0
[FW_C-rip-200] network 192.168.4.0
[FW_C-rip-200] quit
# Check the routing table of FW_A.

[FW_A] display ip routing-table
------------------------------------------------------------------------------
192.168.0.0/24 Direct 0 0 D 192.168.0.1
192.168.1.0/24 Direct 0 0 D 192.168.1.1
Step 3 Configure RIP to import external routes.

# Set the default route cost to 3 on FW_B and import the routes of the two RIP processes into
the routing table of each other.
[FW_B] rip 100
[FW_B-rip-100] default-cost 3
[FW_B-rip-100] import-route rip 200
[FW_B-rip-100] quit
[FW_B] rip 200
[FW_B-rip-200] import-route rip 100
[FW_B-rip-200] quit
# Check the routing table of FW_A after the routes are imported.
------------------------------------------------------------------------------


192.168.0.0/24 Direct 0 0 D 192.168.0.1
192.168.1.0/24 Direct 0 0 D 192.168.1.1
192.168.2.0/24 RIP 100 4 D 192.168.1.2
192.168.3.0/24 RIP 100 4 D 192.168.1.2
192.168.4.0/24 RIP 100 4 D 192.168.1.2
Step 4 Configure RIP to filter the imported routes.

# Configure an ACL on FW_B and set a rule to deny the packets with the source address of
192.168.4.0/24.
[FW_B] acl 2000
[FW_B-acl-basic-2000] rule deny source 192.168.4.0 0.0.0.255
[FW_B-acl-basic-2000] rule permit
[FW_B-acl-basic-2000] quit
# Filter out the imported route 192.168.4.0/24 of RIP 200 on FW_B according to the ACL
rule.
[FW_B] rip 100
[FW_B-rip-100] filter-policy 2000 export
[FW_B-rip-100] quit

# Check the routing table of FW_A after the filtering.
------------------------------------------------------------------------------
192.168.0.0/24 Direct 0 0 D 192.168.0.1
192.168.1.0/24 Direct 0 0 D 192.168.1.1
192.168.2.0/24 RIP 100 4 D 192.168.1.2
192.168.3.0/24 RIP 100 4 D 192.168.1.2
----End
#
sysname FW_A
#
undo shutdown
ip address 192.168.1.1 255.255.255.0

#
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
rip 100
network 192.168.0.0
network 192.168.1.0
#
return

#
sysname FW_B
#
acl number 2000
rule 5 deny source 192.168.4.0 0.0.0.255
rule 10 permit
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
rip 100
default-cost 3
network 192.168.1.0
filter-policy 2000 export
import-route rip 200
#
rip 200
network 192.168.2.0
import-route rip 100
#
return

#
sysname FW_C
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
#
undo shutdown
ip address 192.168.4.1 255.255.255.0
#
rip 100
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
#
return

This section provides reference information about RIP.

This section describes RIP specifications.
RIP-1 and RIP-2 RIP-1 is used by default. Supported by all models.
Disabling interfaces from - Supported by all models.

receiving RIP Update
packets
Disabling interfaces from The interfaces only receive Supported by all models.
sending RIP Update packets RIP packets to update the
RIP routing table.
Enabling RIP on interfaces - Supported by all models.

in specified network
segments
Disabling RIP from - Supported by all models.

receiving host routes
Importing external routes Direct, static, OSPF, and Supported by all models.
BGP routes can be imported
to the RIP routing table.
Supported interface type GE interfaces and Supported by all models.

subinterfaces, POS
interfaces and subinterfaces,
Eth-Trunk interfaces and
subinterfaces, tunnel
interfaces, and VLANIF
interfaces

RIP timer RIP uses the following Supported by all models.

timers:
l Update: This timer
triggers the sending of
Update packets.
l Age: If a RIP-enabled
firewall does not receive
Update packets from a
peer before the timer
expires, the firewall
considers the peer
unreachable.
l Garbage-collect: If no
Update packet is
received from an
unreachable peer before
the timer expires, the
route to the peer is
permanently deleted
from the routing table.
Request for a part of the - Supported by all models.

routing table
Split horizon Split horizon means that Supported by all models.

RIP does not send a route
through an interface from
which RIP learned the route.
This mechanism reduces
bandwidth consumption and
prevents routing loops.
Poison reverse After RIP learns a route Supported by all models.

from an interface, it sets the
route cost to 16 (indicating
that the route is
unreachable) and sends the
route back to the peer
through the incoming
interface. This mechanism
clears useless routes from
the peer's routing table.

Graceful restart After a RIP process is Supported by all models.

restarted through GR, the
Restarter and the Helper re-
establish the neighbor
relationship and update the
routing table and forwarding
table. This ensures non-stop
traffic forwarding and
stabilizes the network
topology. During RIP GR,
except the neighbor of the
device where master/slave
switchover occurs, other
routers do not detect the
route change.
Association between RIP BFD session establishment Supported by all models.

and BFD is triggered by RIP. If a link
fault occurs, the local RIP
process will receive a
neighbor unreachable
message within seconds.
Then, the FW will delete
routing entries in which the
neighbor relationship is
Down and use the backup
path to transmit messages.
Using routing policies to ACLs and prefix lists can be Supported by all models.
filter routes used to filter RIP routes.
Subnet mask of variable - Supported by all models.

length (RIP-2 only)
Classless routing (RIP-2 - Supported by all models.

only)
Multicast (RIP-2 only) - Supported by all models.
Encryption authentication Simple authentication and Supported by all models.

(RIP-2 only) MD5 authentication are
supported.
Disabling the route RIP-1 supports the Supported by all models.

aggregation (RIP-2 only) advertising of aggregation
routes. RIP-2 supports the
disabling of the route
aggregation function, and
therefore subnet routes can
be advertised.

Default priority 100
Maximum number of routes 1000 routes for each process
Maximum number of RIP peers 100 peers on each interface
Maximum number of Interfaces 200 interfaces for each process
Maximum number of VPN instances 1000

This section describes the versions and changes in the RIP feature.

This section provides RIP standards and protocols.
The RIP standards and protocols are as follows:
l RFC 1058: Routing Information Protocol
l RFC 1724: RIP Version 2 MIB Extension
l RFC 2083: PNG (Portable Network Graphics) Specification Version 1.0
l RFC 1723: RIP Version 2 - Carrying Additional Information
l RFC 2453: RIP Version 2
l RFC 2082: RIP-2 MD5 Authentication
5.5 RIPng
RIPng is mainly applied to small and simply-structured IPv6 networks. RIPng is a routing
protocol based on the distance vector and adopts the hop count to measure the distance to the
destination.
5.5.1 Overview
RIPng, also called RIP next generation, is the RIP-2 extension used on IPv4 networks. RIP
and RIPng share many concepts.
Definition
RIPng, based on the Distance Vector (D-V) algorithm, is a routing protocol that measures the
distance (metric or cost) to a destination host by Hop Count (HC). RIPng defines that the HC

from a router to its directly connected network is 0, and the HC from a router to a network
that is reachable through another router is 1, and so on. When the HC reaches 16, the
destination network or host is defined as unreachable.
RIPng is derived from RIP and applies to IPv6 networks. Unlike RIP, RIPng has the following
characteristics:
l UDP port number
RIPng uses UDP port number 521 (RIP uses UDP port number 520) to send and receive
routing information.
l Multicast address
RIPng uses FF02::9 as the multicast address on a RIPng router in the local link scope.
l Prefix length
RIPng uses a 128-bit (the mask length) prefix in a destination address.
l Next hop address
RIPng uses a 128-bit IPv6 address.
l Source address
RIPng uses link-local address FE80::/10 as a source address used to send RIPng Update
packets.
Objective
RIPng is developed by extending RIP and supports IPv6.
5.5.2 Mechanism
This section describes the RIPng mechanism.
Timer
RIPng uses the following three timers:
l Update timer: The timer triggers the sending of update packets every 30 seconds. This
timer synchronizes RIPng routes on the network.
l Age timer: If a RIPng router does not receive any update packet from its neighbors in the
aging time, the RIPng router considers the route to its neighbors unreachable.
l Garbage-Collect timer: If the route is no longer valid after the timer times out, the entry
is removed from the RIPng routing table.
The following describes the relationship among the three timers:
The advertisement of RIPng routing update is triggered by the update timer every 30 seconds.
Each entry is associated with two timers, the age timer and the garbage-collect timer. When a
route is learned and installed in the routing table, the age timer is initialized. If no Update
packet is received from the neighbor for 180 seconds, the metric of the route is set to 16. At
the same time, the garbage-collect timer is initialized. If no Update packet is received for 120
seconds, the entry is deleted after the garbage-collect timer times out.
Split Horizon
The principle of split horizon is that a route learnt by RIPng on an interface is not sent to
neighbors from the interface. This reduces bandwidth consumption and avoids route loops.

Figure 5-14 Schematic diagram of split horizon
123::45/64
RouterA RouterB
123::45/64
As shown in Figure 5-14, RouterB sends a route to network 123::45 to RouterA and RouterA
does not send the route back to RouterB.
Poison Reverse
The principle of poison reverse is that RIPng sets the cost of the route learnt from an interface
of a neighbor to 16 (specifying the route as unreachable) and then sends the route from the
interface to the neighbor. In this way, RIPng can delete useless routes from the routing table
of the neighbor.
Poison reverse of RIPng can also avoid route loops.
Figure 5-15 Schematic diagram of poison reverse

123::0/64
metric=16
RouterA RouterB
123::0/64
metric=16
As shown in Figure 5-15, if poison reverse is not configured, RouterB sends RouterA a route
that is learnt from RouterA. The cost of the route from RouterA to network 123::0/64 is 1.
When the route from RouterA to network 123::0/64 becomes unreachable and RouterB does
not receive the update packet from RouterA and thus keeps sending RouterA the route from
RouterA to network 123::0/64, a route loop occurs.
If RouterA sends RouterB a message that the route is unreachable after receiving a route from
RouterB, Router_B no longer learns the reachable route from RouterA, thus avoiding route
loops.
If both poison reverse and split horizon are configured, simple split horizon (the route learnt
from an interface is not sent back through the interface) is replaced by poison reverse.
Triggered Update
Triggered update occurs when local routing information changes and then the local router
immediately notifies its neighbors of the changes of routing information by sending the

Triggered update shortens the network convergence time. When local routing information
changes, the local router immediately notifies its neighbors of the changes of routing
information rather than waiting for periodical update.
Figure 5-16 Schematic diagram of triggered update
As shown in Figure 5-16, when network 123::0 is unreachable, RouterC learns the
information first. Usually, the route update message is periodically sent to neighbors. For
example, RIPng sends the route update message every 30s. If the update message of RouterB
is sent to RouterC when RouterC is waiting for the route update message, RouterC learns the
faulty route to network 123::0 from RouterB. In this case, the routes from RouterB or
RouterC to network 123::0 point to RouterC or RouterB respectively, thus forming a route
loop. If RouterC detects a network fault and immediately sends a route update message to
Router B before the new update interval reaches. Consequently, the routing table of Router B
is updated in time, and routing loops are avoided.
There is another mode of triggering updates: The next hop of the route is unavailable because
the link is faulty. The local router needs to notify neighboring router about the unreachability
of this route. This is done by setting the cost of the route as 16 and advertising the route. This
is also called route-withdrawal.
Route Aggregation
RIPng route aggregation is implemented by aggregating all routes advertised on an interface
according to the longest match rule.
RIPng route aggregation can improve extendibility and efficiency and minimize the routing
table of a large-scale network.
Implementation of route aggregation:

For example, RIPng advertises two routes, 11:11:11::24 Metric=2 and 11:11:12::34 Metric=3,
from an interface, and the aggregation route configured on the interface is 11::0/16. In this
manner, the finally advertised route is 11::0/16 Metric=2.
5.5.3 RIPng Configuration
5.5.3.1 Establishing RIPng Neighbor Relationships

This section describes how to establish RIPng neighbor relationships to form a RIPng
network.
5.5.3.1.1 Enabling RIPng

Creating RIPng processes is the prerequisite to performing RIPng configurations. When
creating RIPng processes, you can also enter the RIPng view to perform configurations.
Procedure
system-view
Step 2 Run:
ripng [ process-id ]
RIPng is enabled and the RIPng view is displayed.
When only one RIPng process is run, process-id is not specified. That is, process-id defaults
to 1.
After the RIPng process is cancelled, the ripng process-id enable command needs to be
reconfigured on an interface.
description
Descriptions for RIPng processes are configured.
----End
5.5.3.1.2 Enabling RIPng in the Interface View

After enabling RIPng in the system view, you need to run RIPng on the interface; otherwise,
RIPng does not take effect.
Procedure
system-view

Step 2 Run:
The interface is at the network side of the router. That is, the router is connected with other
routers through the interface. To enable the router to learn the routes of the network segment
where the interface resides, ensure that the link status of the interface is Up.
Step 3 Run:
ripng process-id enable
RIPng is enabled on the specified interface.
NOTE
In the interface view, this command cannot be executed if IPv6 is not enabled.
If multiple interfaces on a router connect other routers, repeatedly perform Step 2 and Step 3.
----End
5.5.3.2 Controlling the Advertising of RIPng Routing Information

To meet the requirements of complex networks, it is required to accurately control the
advertising of RIPng routing information.
5.5.3.2.1 Configuring RIPng to Advertise the Default Routes

There are two methods of advertising RIPng default routes. You can configure a router to
advertise RIPng default routes according to the actual networking. Additionally, you can
specify the cost of the default routes to be advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng default-route { only | originate } [ cost cost ]
RIPng is configured to advertise the default route.
The default RIPng route that is generated is advertised forcibly through the route update
packet from the specified interface. The advertising does not consider whether this route is in
By default, the RIPng process does not advertise the default route. You need to configure
RIPng to advertise the default route according to the actual networking.

l only: indicates that only the default IPv6 route (::/0) is advertised to suppress the
advertising of other routes.
l originate: indicates that only the default IPv6 route (::/0) is advertised without affecting
the advertising of other routes.
l cost: specifies the cost of the default route.
----End
5.5.3.2.2 Disabling Sending of RIPng Packets on an Interface

Disabling an interface from sending RIPng packets is a method of preventing routing loops.
Context
When a device running RIPng is connected to a network running other routing protocols, you
can run the undo ripng output command on the interface that connects the device to the
network to prevent the interface from sending useless packets to the network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo ripng output
The interface is disabled from sending RIPng packets.
By default, an interface is allowed to send RIPng packets.
----End
5.5.3.2.3 Configuring RIPng to Filter the Routes to be Sent

You can configure RIPng to filter the routes to be sent.
Procedure
system-view
Step 2 Run:


l filter-policy acl6-number export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the ACL.
l filter-policy ipv6-prefix ipv6-prefix-name export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the prefix list.
l filter-policy route-policy route-policy-name export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the route policy.
RIPng can filter the routes to be sent based on an IPv6 ACL, route-policy or an IPv6 prefix
list. Only the routes that meet the match conditions are advertised to neighbors. If protocol is
not specified in the command, all the routing information to be advertised will be filtered,
including the imported routes and local RIPng routes (directly connected routes).
----End
5.5.3.2.4 Configuring RIPng Route Summarization

By configuring a RIPng router to advertise the summarized IPv6 address on an interface, you
can save the space used by RIPng routes in the routing table. You can also set parameters to
prevent an interface from learning the same summarized route.
Context
This configuration is to configure the RIPng router to advertise the summarized IPv6 prefix
rather than specific routes on an interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng summary-address ipv6-address prefix-length [ avoid-feedback ]
RIPng route summarization is configured.
----End
5.5.3.3 Controlling the Receiving of RIPng Routing Information

To meet the requirements of complex networks, it is required to accurately control the
receiving of RIPng routing information.

5.5.3.3.1 Disabling Receiving of RIPng Packets on an Interface

Disabling interfaces from receiving RIPng packets is a method of preventing routing loops.
Context
When a device running RIPng is connected to a network running other routing protocols, you
can run the undo ripng input command on the interface that connects the device to the
network to prevent the interface from receiving useless packets from the network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo ripng input
The interface is disabled from receiving RIPng packets.
By default, an interface is allowed to receive RIPng packets.
----End
5.5.3.3.2 Configuring RIPng to Filter the Received Routes

You can configure a router to selectively receive routes.
Procedure
system-view
Step 2 Run:

l filter-policy acl6-number import
The imported routes are filtered based on the ACL.
l filter-policy ipv6-prefix ipv6-prefix-name import
The imported routes are filtered based on the prefix list.

l filter-policy route-policy route-policy-name import

The imported routes are filtered based on the route-policy.
RIPng can filter the received routes based on an IPv6 ACL, route-policy or an IPv6 prefix list.
Only the routes that meet the match conditions are added in the RIPng routing table.
----End
5.5.3.4 Configuring RIPng to Import External Routes

RIPng can import external routes to enrich routing information.
Context
To access a device running a non-RIPng protocol, an RIPng-capable device needs to import
routes of the non-RIPng protocol into the RIPng network.
All the following commands can set the cost of the imported route, which are listed in
descending order of priorities.

l Run the import-route (RIPng) command to set the cost of the imported route.
l Run the default-cost (RIPng) command to set the cost of the default route.
Procedure
system-view
Step 2 Run:
default-cost cost
The default cost is set for the external routes imported by RIPng.
If no cost is specified, this command can be used to set the default cost for the external routes
imported by RIPng from other routing protocols.
Step 4 Run:
import-route { { ripng | isis | ospfv3 } process-id | bgp [ permit-ibgp ] | unr | direct |

static } [ [ cost cost | inherit-cost ] | route-policy route-policy-name ] *
External routes are imported.
----End

5.5.3.5 Controlling RIPng Routing

You can control RIPng routing in a network with a complicated environment.
5.5.3.5.1 Configuring the RIPng Preference

When there are routes discovered by multiple routing protocols on the same router, you can
make the router prefer RIPng routes by setting the RIPng preference.
Context
Each routing protocol has its preference, according to which a routing policy selects the
optimal route. The RIPng preference can be set manually. The greater the value is, the lower
the preference is.
Procedure
system-view
Step 2 Run:
Step 3 Run:
preference { preference | route-policy route-policy-name } *
The RIPng preference is set.
----End
5.5.3.5.2 Configuring Additional Metrics of an Interface

You can set additional metrics for received and sent RIPng routes by using different
commands.
Context
The additional route metric is the metric (hop count) to be added to the original metric of a
RIPng route.
l The ripng metricin command is used to configure a device to add an additional metric
to a received route before the device adds the route to its routing table, causing the
metric of the route in the routing table to change. Running this command affects route
selection on the device and other devices.
l The ripng metricout command is used to configure a device to add an additional metric
to a route before the device advertises the route, keeping the metric of the route in the
routing table unchanged. Running this command does not affect route selection on the
local device but will affect route selection of other devices.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng metricin value
The metric added to a received route is set.
Step 4 Run:
ripng metricout { value | { acl6-number | ipv6-prefix ipv6-prefix-name } value1 }
The metric added to a sent route is set.
You can specify the value of the metric to be added to the RIPng route that passes the filtering
policy by specifying value1 through an IPv6 ACL or an IPv6 prefix list. If a RIPng route does
not pass the filtering, its metric is increased by 1.
NOTE
If the router connects to other RIPng routers through multiple interfaces, repeatedly perform Step 2 to
Step 4 until metrics of all links are set.
----End
5.5.3.5.3 Configuring the Maximum Number of Equal-Cost Routes

By setting the maximum number of equal-cost RIPng routes, you can change the number of
routes for load balancing.
Procedure
system-view
Step 2 Run:
Step 3 Run:
----End

5.5.3.6 Optimizing the RIPng Network

In specific network environments, you need to configure certain features and functions of
RIPng. In this way, the performance of the RIPng network is adjusted and optimized.
5.5.3.6.1 Configuring the RIPng Timer

RIPng has three timers: Update timer, Age timer and Garbage-collect timer. If the three RIPng
timers are configured improperly, routes become unstable.
Context
NOTE
Route flapping occurs if the values of the four RIPng timers are set improperly. The relationship
between the values is as follows: update < age, update < garbage-collect. For example, if the update time
is longer than the aging time, and a RIPng route changes within the update time, the router cannot
inform its neighbors of the change on time.
By default, the Update timer is 30s; the Age timer is 180s; the Garbage-collect timer is 120s.
Perform the following steps on the RIPng router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The RIPng view is displayed.
Step 3 Run:
timers ripng update age garbage-collect
The RIPng timer is configured.
----End
5.5.3.6.2 Setting the Interval for Sending Update Packets and the Maximum Number of
Packets Sent Each Time
By setting the interval for sending packets and the maximum number of packets to be sent
each time, you can optimize the RIPng performance.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ripng pkt-transmit { interval interval | number pkt-count }*

The interval for sending RIPng Update packets and the maximum number of packets sent
each time are set on the specified interface. Parent topic: Optimizing a RIPng Network
----End
5.5.3.6.3 Configuring Split Horizon and Poison Reverse

You can configure split horizon and poison reverse to prevent routing loops.
Context
Poison reverse is another method of preventing routing loops by enabling the router to
advertise a route as unreachable back through the interface from which the route is learned.
Poison reverse is another method of preventing routing loops by enabling the router to
advertise a route as unreachable back through the interface from which the route is learned.
If both split horizon and poison reverse are configured, only poison reverse takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
l Run:
ripng split-horizon
Split horizon is enabled.
l Run:
ripng poison-reverse
Poison reverse is enabled.
----End
5.5.3.6.4 Enabling the Zero Field Check for RIPng Packets

The check on the zero field of RIP packets is configured, and the RIP packets that do not pass
the check are not processed.

Context
Certain fields in the header of the RIPng packet must be set to 0, which is also called the zero
field. After the zero field check for the RIPng packet is enabled, but the value in the zero field
of the packet header is not 0, the packet is discarded without processing.
If all the packets are regarded to be reliable, this check is not needed, thus saving the
processing time for the system.
By default, the zero field check is enabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The RIPng view is displayed.
Step 3 Run:
checkzero
The zero field check for RIPng packets is enabled.
----End
5.5.4 Maintaining RIPng

After RIPng routes are built, you can view and clear RIPng routing information.
Displaying the RIPng Configuration
Table 5-12 Displaying the RIPng configuration

Operation Command
Display the current display ripng [ process-id | vpn-instance vpn-instance-name ]

RIPng running status
and configuration.
Display all activated display ripng process-id database [ verbose ]

routes in the RIPng
advertising database.
Display RIPng display ripng process-id interface [ interface-type interface-

interface information. number ] [ verbose ]
Display RIPng display ripng process-id neighbor [ verbose ]

neighboring router
information.

Operation Command
Display all RIPng display ripng process-id route

routes.
Clearing RIPng
NOTICE
RIPng information cannot be restored after it is cleared. Exercise caution when running the
commands.
Table 5-13 Clearing the RIPng configuration
Operation Command
Reset statistics on the reset ripng process-id statistics [ interface { all | interface-type
counters maintained a interface-number [ neighbor neighbor-ipv6-address ] } ]
RIPng process.
5.5.5.1 Example for Configuring RIPng to Connect Network Devices

This section describes how to configure OSPF in the dual-system hot backup scenario. After
OSPF is configured, if an active device fails, traffic is switched to a standby device using
OSPF routes.
As shown in Figure 5-17, the research and development department of an enterprise works
with an ISP to deploy an IPv6 network. The research and development department is dual-
homed to an ISP router and accesses the IPv6 network through the ISP router.
l The enterprise deploys two FWs on the intranet border to dual-home the research and
development department to the IPv6 network, which improves network reliability. FWs
use link-local addresses to communicate with the ISP router.
l The FWs and ISP router run RIPng to learn IPv6 network routes and advertise routes to
the IPv6 network.

Figure 5-17 RIPng networking

FW_B
GE1/0/3
Trust 2000::1/64 Untrust
GE1
Auto /0/1
Link FE8
loca 0:
l F:FE :222:A1
03:6 F
Research 079 IPv6
2000::/64 RIPng 1F Network
2:A
80 ::22 607A
FE E03 :
0/1 cal F:F
1 / ISP Router
GE Linklo
u t o
A
GE1/0/3
2000:2/64
FW_A
1. Assign IP addresses to FW interfaces and add the interfaces to security zones.
2. Configure RIPng on the FWs.
3. Configure security policies on the FWs so that the devices of the research and
development department can access the IPv6 network.
Procedure
1. Configure GigabitEthernet 1/0/1.
# Assign an IPv6 address to GigabitEthernet 1/0/1.
<FW_A> system-view
[FW_A] ipv6
[FW_A-GigabitEthernet1/0/1] ipv6 address auto link-local
# Assign GigabitEthernet 1/0/1 to the Untrust zone.


[FW_A-GigabitEthernet1/0/3] ipv6 address 2000::2 64

# Assign GigabitEthernet 1/0/3 to the Trust zone.

3. Configure RIPng.
[FW_A] ripng 1
[FW_A-ripng-1] quit
[FW_A-GigabitEthernet1/0/1] ripng 1 enable
[FW_A-GigabitEthernet1/0/3] ripng 1 enable
4. Configure security policies so that devices in the research and development department
can exchange RIPng packets and access the IPv6 network.
The following example provides basic security policy parameters. You can set other
parameters as necessary.
[FW_A-policy-security-rule-policy_sec_1] source-zone local untrust
[FW_A-policy-security-rule-policy_sec_1] destination-zone untrust local
[FW_A-policy-security-rule-policy_sec_2] source-address 2000:: 64


<FW_B> system-view
[FW_B] ipv6
[FW_B-GigabitEthernet1/0/1] ipv6 address auto link-local
# Assign GigabitEthernet 1/0/1 to the Untrust zone.


[FW_B-GigabitEthernet1/0/3] ipv6 address 2000::1 64
# Assign GigabitEthernet 1/0/3 to the Trust zone.


3. Configure RIPng.
[FW_B] ripng 1
[FW_B-ripng-1] quit
[FW_B-GigabitEthernet1/0/1] ripng 1 enable
[FW_B-GigabitEthernet1/0/3] ripng 1 enable
4. Configure security policies so that devices in the research and development department
can exchange RIPng packets and access the IPv6 network.
The following example provides basic security policy parameters. You can set other
parameters as necessary.
[FW_B-policy-security-rule-policy_sec_1] source-zone local untrust
[FW_B-policy-security-rule-policy_sec_1] destination-zone untrust local
[FW_B-policy-security-rule-policy_sec_2] source-address 2000:: 64
----End
The following example uses the display on FW_A.
l Check the IPv6 status of GigabitEthernet 1/0/1.
[FW_A] display ipv6 interface GigabitEthernet 1/0/1
UP
UP
FE80::222:A1FF:FE00:2
No global unicast address
configured
Joined group
address(es):
FF02::9
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500
bytes
1
milliseconds
milliseconds
The preceding command output shows that the IPv6 status of GigabitEthernet 1/0/1 is
UP.

l View the RIPng routing table.

[FW_A] display ripng 1 route
Route Flags: A - Aging, S - Suppressed, G - Garbage-
collect
----------------------------------------------------------------
Peer FE80::222:A1FF:FE03:607A on GigabitEthernet1/0/1

Dest
3000::/64,
via FE80::222:A1FF:FE03:607A, cost 1, tag 0, A, 15
Sec
Dest
3001::/64,
via FE80::222:A1FF:FE03:607A, cost 1, tag 0, A, 15
Sec
Dest
3002::/64,
via FE80::222:A1FF:FE03:607A, cost 1, tag 0, A, 3 Sec
The preceding command output shows that RIPng-enabled FW_A has learned routes
with destination addresses 3000::/64, 3001::/64, and 3002::/64 and next-hop address
FE80::222:A1FF:FE03:607A.
l Check whether PCs in the research and development department can use IPv6 addresses
to access the IPv6 network.
– If they can access the IPv6 network, the configuration is successful.
– If they cannot access the IPv6 network, modify the configuration and try again.
#
ipv6
#
sysname FW_A
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ripng 1
#
security-policy
source-zone local
source-zone untrust

action permit
source-zone trust
source-address 2000:: 64
action permit
#
return

#
ipv6
#
sysname FW_B
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ripng 1
#
security-policy
source-zone local
source-zone untrust
action permit
source-zone trust
action permit
#
return
5.5.6 Reference
This section provides reference information about RIPng.
This section describes RIPng specifications.

Enabling/disabling RIPng - Supported by all models

on an interface
Configuring an interface to - Supported by all models

add a metric to a routing
update to be sent
Configuring an interface to - Supported by all models

add a metric to a received
routing update
Configuring route Route aggregation enables a Supported by all models

aggregation on an interface device to aggregate routes
destined for different
subnets of a network
segment into one route
destined for one network
segment and then advertise
the summarized route to
other network segments.
This function reduces the
routing table size and
network traffic.
Configuring split horizon on A route learned by RIPng on Supported by all models

an interface an interface is not sent to
neighbors from the
interface.
Configuring poison reverse RIPng sets the cost of the Supported by all models
on an interface route learned from an
interface to 16 (indicating
that the route is
unreachable) and then sends
the route through this
interface to the neighbor. In
this way, RIPng can delete
useless routes from the
routing table of the
neighbor.
Limit on the maximum - Supported by all models

number of equal-cost routes
Multi-process - Supported by all models

Triggered update When the local routing Supported by all models

information changes, the
local router immediately
notifies its neighbors of the
changes by sending the
Imported Route The routes that RIPng can Supported by all models
import include direct, static,
OSPFv3, IS-ISv6, RIPng,
and BGP4+ routes.
Applying a routing policy to - Supported by all models

routes to be imported
Filtering routes to be - Supported by all models

received

advertised
Subnet mask - Supported by all models
Verifying packet validity - Supported by all models
Checking neighbor source - Supported by all models

addresses
Zero field check In RIPng packets, there are Supported by all models
some fields whose values
must be 0. These fields are
also called zero fields. After
zero field check is enabled
for RIPng packets, the
packets whose zero fields
are not zero will be
discarded.
Withdrawing advertised - Supported by all models

routes
Update timer and its value The update timer Supported by all models
setting periodically triggers the
sending of update packets.
Age timer and its value If a RIPng router does not Supported by all models
setting receive any update packet
from its neighbors in the
aging time, the RIP router
considers the route to its
neighbors unreachable and
starts the Garbage-Collect
timer.

Garbage Collection timer If a routing device does not Supported by all models
and its value setting receive any update packet
for an unreachable route
from the same neighbor
within the garbage-collect
time, the device will delete
the route from its routing
table.

This section describes the versions and changes in the RIPng feature.

This section provides RIPng standards and protocols.
The RIPng standards and protocols are as follows:
l RFC 2080: RIPng for IPv6

l RFC 1058: Routing Information Protocol
l RFC 2453: RIP Version 2
5.6 OSPF
This section describes the basic concepts and configuration of Open Shortest Path First
(OSPF) and provides OSPF configuration examples.
5.6.1 Overview
Open Shortest Path First (OSPF) applies to large IPv4 networks. OSPF is a routing protocol
based on link status. Compared with distance vector-based routing protocols, OSPF delivers a
higher convergence rate and supports larger network scale.
Definition
OSPF is an internal network gateway protocol developed by the Internet Engineering Task
Force (IETF) on the basis of link status. OSPF version 2 (RFC 2328) is for IPv4. OSPF does
not belong to any vendors or organizations and uses the Shortest Path First (SPF) algorithm to
calculate routes. The area concept is used in OSPF to help reduce the consumption of the
router CPU and memory resources by route selecting protocols and reduce communications
traffic. Large and hierarchical networks can be established using OSPF.

Objective
As the routers on the network increase, the Routing Information Protocol (RIP) cannot
support large networks due to routing loops and limited hop numbers. The IETF develops
OSPF to support the large network deployment.
OSPF has the following advantages:

l Wide application: OSPF is applicable to large-scale networks, including a network
consisting of hundreds of routers.
l Fast convergence: Once the network topology changes, update packets are transmitted to
synchronize the link-state databases (LSDBs) of all routers in an autonomous system
(AS).
l Loop-free: OSPF calculates loop-free routes using the shortest path tree algorithm and
the collected link status information.
l Area partition: An AS is divided into areas to simplify AS management. Area partition
reduces bandwidth consumption because only aggregated routing information is
transmitted between areas.
l Routing types: The following four types of routing are available in descending order by
priority: intra-area, inter-area, Type 1 external, and Type 2 external.
l Equal-cost routes: OSPF supports multiple equal-cost routes to the same destination.
l Authentication: Area- and interface-based OSPF packets can be authenticated to improve
packet exchange security.
l Multicast: Multicast packets are transmitted some types of links to reduce the
interference for other devices.
5.6.2 Mechanism
This section describes the OSPF mechanism.
5.6.2.1 OSPF Fundamentals

This section describes basic OSPF concepts, including OSPF packet types and router types.
OSPF has the following advantages:
l Divides an Autonomous System (AS) into one or multiple logical areas.

l Advertises routes by sending Link State Advertisements (LSAs).
l Synchronizes routing information by exchanging OSPF packets between routers in
OSPF areas.
l Encapsulates OSPF packets in IP packets and then sends the packets in unicast mode or
multicast mode.
OSPF Packet Type
Table 5-14 OSPF packet type

Packet Function
Hello packet Hello packets are sent periodically to discover and

maintain OSPF neighbor relationships.

Packet Function
Database Description (DD) packet DD packets carry brief information about the local
Link State Database (LSDB) and are used to
synchronize the LSDBs of two routers.
Link State Request (LSR) packet LSR packets are used to request the required LSAs
from neighbors.
LSR packets are sent only after DD packets are
exchanged successfully.
Link State Update (LSU) packet LSU packets are used to send the required LSAs to
neighbors.
Link State Acknowledgment LSAck packets are used to acknowledge the received
(LSAck) packet LSAs.
LSA Type
Table 5-15 OSPF LSA type

LSA Function
Router-LSA (Type1) Describes the link state and link cost of a router. It is
generated by each router and advertised in the area to which
the router belongs.
Network-LSA (Type2) Describes the link state of all routers in the local network
segment. It is generated by a designated router (DR) and
advertised in the area to which the DR belongs.
Network-summary-LSA Describes all routes in a certain area. It is generated by an

(Type3) Area Border Router (ABR) and advertised in related areas.
ASBR-summary-LSA Describes routes to an Autonomous System Boundary

(Type4) Router (ASBR). It is generated by an ABR and advertised in
the related areas except the area to which the ASBR
belongs.
AS-external-LSA (Type5) Describes routes to a destination outside the AS. It is

generated by an ASBR and advertised in all areas except
stub areas and Not-So-Stubby Areas (NSSAs).
NSSA-LSA (Type7) Describes routes to a destination outside the AS. It is

generated by an ASBR and advertised in NSSAs only.

LSA Function
Opaque-LSA (Type9/ Provides a general mechanism for OSPF extension:

Type10/Type11) Type9 LSAs are advertised in the network segment where
interfaces reside. Grace LSAs used to support GR are one
type of Type9 LSAs.
Type10 LSAs are advertised in an area. LSAs used to
support TE are one type of Type10 LSAs.
Type11 LSAs are advertised in an AS. At present, there are
no application examples of Type11 LSAs.
Router Type
Figure 5-18 lists the types of common routers in OSPF.
Figure 5-18 Router Type
Table 5-16 OSPF router type

Router Description
Internal router All interfaces of an internal router belong to the same

OSPF area.
Area Border Router (ABR) An ABR can belong to two or more areas, and one of the
areas must be a backbone area.
An ABR is used to connect the backbone area and non-
backbone areas. It can be physically or logically connected
to the backbone area.

Router Description
Backbone router At least one interface on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0, therefore, are
backbone routers.
AS Boundary Router An ASBR exchanges routing information with other ASs.

(ASBR) An ASBR may not reside at the boundary of an AS. It can
be an internal router or an ABR. If an OSPF router imports
external routes, the router is an ASBR.
OSPF Route Type

Inter-area routes and intra-area routes describe the network structure of an AS. External routes
describe how to select a route to a destination outside an AS. OSPF classifies the imported AS
external routes into Type1 and Type2 external routes.
Table 5-17 lists route types in descending order of priority.
Table 5-17 OSPF route type

Route Description
Intra area Intra-area routes
Inter area Inter-area routes
Type1 external route Because of the high reliability of Type1 external routes,
the calculated cost of external routes equals that of AS
internal routes, and can be compared with the cost of
OSPF routes.
That is, the cost of a Type1 external route equals the cost
of the route from the router to the corresponding ASBR
plus the cost of the route from the ASBR to the
destination.
Type2 external route Because of the low reliability of Type2 external routes,
their costs are considered greater than the cost of any
internal path to an ASBR.
Thus, the cost of a Type2 external route equals the cost of
the route from the ASBR to the destination.

Area Type
Table 5-18 OSPF area type

Area Function
Common area OSPF areas are common areas by default. Common areas include
standard areas and backbone areas.
l A standard area is the most common area and transmits intra-
area routes, inter-area routes, and external routes.
l A backbone area connects all the other OSPF areas. It is usually
named Area 0.
Totally stub area Allows the Type3 default routes advertised by an ABR, and denies
the routes outside an AS and inter-area routes.
Stub area Allows inter-area routes, which is different from a totally stub area.
NSSA Imports routes outside an AS, which is different from a stub area.
An ASBR advertises Type7 LSAs in the local area.
Totally NSSA Denies inter-area routes, which is different from an NSSA.
OSPF Network Type

According to link layer protocols, OSPF classifies networks into the following types, as
shown in Table 5-19.
Table 5-19 OSPF network type

Network Description
Broadcast If the link layer protocol is Ethernet or Fiber Distributed Data

Interface (FDDI), OSPF defaults the network type to broadcast.
In this type of networks,
l Hello packets, LSU packets, and LSAck packets are
transmitted in multicast mode. The address 224.0.0.5 is the
reserved IP broadcast address of the OSPF router, and the
address 224.0.0.6 is the reserved IP multicast address of the
OSPF DR.
l DD packets and LSR packets are transmitted in unicast
mode.
Non-Broadcast If the link layer protocol is frame relay (FR), ATM, or X.25,
Multiple Access OSPF defaults the network type to NBMA.
(NBMA) In this type of networks, protocol packets, such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets, are
transmitted in unicast mode.

Network Description
Point-to-Multipoint Regardless of the link layer protocol, OSPF does not default the
(P2MP) network type to P2MP. A P2MP network must be forcibly
changed from other network types. The common practice is to
change a non-fully connected NBMA network to a P2MP
network.
In this type of networks,
l Hello packets are transmitted in multicast mode through the
multicast address 224.0.0.5.
l Other protocol packets, such as DD packets, LSR packets,
LSU packets, and LSAck packets, are transmitted in unicast
mode.
Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPF
defaults the network type to P2P.
In this type of networks, protocol packets, such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets, are
transmitted in multicast mode through the multicast address
224.0.0.5.
OSPF Route Filtering

OSPF supports the filtering of routes through routing policies. By default, OSPF does not
filter routes.
Routing policies used by OSPF include the routing policy, ACL, and IP prefix list.
OSPF route filtering is applicable to the following situations:
l Import of routes
OSPF imports the routes that are learnt by other protocols. When OSPF imports routes,
you can filter the routes by configuring routing policies so that OSPF imports only
eligible routes.
l Advertisement of imported routes
OSPF advertises the imported routes to neighbors.
Routing information to be advertised to neighbors can be filtered through the configured
filtering rules. The filtering rules take effect only when being configured on ASBRs
because only the ASBRs can import routes.
l Learning of routes
Filtering rules can be configured to enable OSPF to filter the received intra-area, inter-
area, and AS external routes.
The filtering action determines whether to add routing entries to the routing table. That
is, only the routes that pass the filtering are added to the local routing table. All the
routes, however, can still be advertised from the OSPF routing table.
l Learning of inter-area LSAs
ABRs can be configured to filter the incoming summary-LSAs of the local area through
a command. This configuration takes effect only on ABRs because only the ABRs can
advertise summary-LSAs.

Table 5-20 Differences between inter-area LSA learning and route learning
Inter-area LSA Route Learning
Learning
Filters the incoming Filters only the calculated routes in LSAs to determine
LSAs of an area whether these routes are added to the local routing table.
directly.
l Advertisement of inter-area LSAs

ABRs can be configured to filter the outgoing summary-LSAs of the local area through a
command. This configuration takes effect only on ABRs.
Restriction on the Routes Imported by OSPF

Restriction on the imported routes means that the number of routes imported by OSPF from
other routing protocols is restricted.
In applications, a large number of external routes may be imported in OSPF because of
misoperation, thus causing network congestion. In addition, when importing a large number
of routes, low-performance nodes on networks may fail to effectively process these routes.
Restricting the number of imported routes can eliminate potential risks and thus improves the
stability of networks.
After being imported by OSPF, external routes are advertised in Type5 or Type7 LSAs.
Therefore, restriction on the imported routes is implemented by limiting the number of Type5
and Type7 LSAs in the LSDB. The implementation principle is as follows:
l Only the total number of Type5 and Type7 LSAs that are generated by a router itself is
restricted.
l The number of LSAs that are generated by default routes is not restricted. This can retain
as many external routes because default routes can match all the destinations.
l If the command for external route aggregation is configured, the number of LSAs that
are generated after route aggregation is restricted. For example, when 10 external routes
are aggregated to generate one LSA, the number of these external routes is calculated as
one.
By default, the number of imported routes is not restricted.
In the situations described in Table 5-21, OSPF processes the routes to be imported
differently.

Table 5-21 Restriction on the routes imported by OSPF
Scenario OSPF Processing
Restriction on the number of l If the number of routes to be imported is smaller than

imported routes is configured, the configured maximum number of imported routes,
and then external routes are the routes are imported normally.
imported. l If the number of routes to be imported is greater than
the configured maximum number of the imported
routes, only the LSAs of a maximum number of routes
allowed are generated. In this situation, the total
number of Type5 and Type7 LSAs in the LSDB equals
the configured maximum number of imported routes.
External routes are imported, l If the number of imported routes is smaller than the
and then restriction on the configured maximum number of imported routes, no
number of imported routes is processing is performed.
configured. l If the number of imported routes is greater than the
configured maximum number of imported routes, the
imported Type5 or Type7 LSAs are deleted, and then
the LSAs of a maximum number of routes allowed are
regenerated.
The number of routes to be If new routes are to be imported, these routes are not
imported is greater than the imported.
configured maximum number If the routes are to be deleted, the following situations
of imported routes. occur:
l If the routes to be deleted are the imported routes, the
routes are re-imported.
l If the routes to be deleted are the routes that are not
imported, these routes are ignored.
The number of routes to be The imported Type5 or Tpye7 LSAs are deleted, and then
imported is greater than the routes are re-imported. Further processing is performed
configured maximum number according to the relationship between the number of
of imported routes, and imported routes and configured maximum number of
restriction on the number of imported routes.
imported routes is
reconfigured after routes are
imported.
OSPF RFC 1583 Compatibility

RFC 1583 is an earlier version of OSPFv2.
When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC
1583 define different routing rules. To prevent routing loops, RFC 2328 introduces the RFC
1583 compatibility feature.
l After RFC 1583 compatibility is enabled, OSPF adopts the routing rules defined in RFC
1583.

l When RFC 1583 compatibility is disabled, OSPF adopts the routing rules defined in
RFC 2328.
OSPF calculates external routes according to Type5 LSAs. After the router enabled with RFC
1583 compatibility receives a Type5 LSA:
l The router selects the route to the ASBR that generates the LSA or to the forwarding
address that is specified by the LSA.
l The router selects the external route to the same destination.
By default, OSPF is compatible with RFC 1583.
Table 5-22 describes external route calculations performed when RFC 1583 compatibility is
enabled and disabled.
Table 5-22 Differences in the routing rules adopted when RFC 1583 compatibility is enabled
and disabled
Routing Rules Adopted Routing Rules Adopted When RFC 1583
When RFC 1583 Compatibility Is Disabled
Compatibility Is Enabled
l The least-cost route is l The intra-area route of a non-backbone area is

preferred. preferred.
l For the routes with the l If there is no intra-area route of a non-backbone area,
same cost, the route with among the intra-area routes of the backbone area or all
the greater area ID is the inter-area routes, the least-cost route is preferred.
preferred. l For the routes with the same cost, the route with the
greater area ID is preferred.
As shown in Figure 5-19, RouterA and RouterE, functioning as ASBRs, import the route
(with the cost 2) to the external network Network 1 and advertise Type 5 LSAs of Network 1.
RouterB adopts the routing rules defined in RFC 1583, and RouterC adopts the routing rules
defined in RFC 2328.
Figure 5-19 OSPF RFC 1583 compatibility

According to the routing rules described in Table 5-22, during the calculation of the route to
Network 1, RouterB prefers the cost-least route, namely, RouterB -> RouterC -> RouterD ->
RouterE -> Network 1, whereas RouterC prefers the intra-area route with the least cost of a
non-backbone area, namely, RouterC -> RouterB -> RouterA -> Network 1.
In this manner, the next hop of the route from RouterB to Network 1 is RouterC, whereas the
next hop of the route from RouterC to Network 1 is RouterB. As a result, a routing loop
occurs.
After RFC 1583 compatibility is enabled on RouterC, RouterC selects the least-cost route to
Network 1, namely, RouterC -> RouterD -> RouterE -> Network 1, whose next hop is not
RouterB. Consequently, routing loops are avoided.
OSPF Flooding Control

OSPF flooding control means that filtering policies are configured on the specified interface
or neighbor to filter specified LSAs.
By default, OSPF floods LSAs on all the eligible interfaces.
OSPF flooding control features the following advantages:
l Reduces the flooding of LSAs and network load in the case of network flapping.
l Prevents useless LSAs from being sent to neighbors, thus reducing the size of the LSDB
of neighbors and speeding up network convergence.
l Filters the outgoing LSAs on certain links between two routers, thus reducing the
unnecessary retransmission of LSAs and saving bandwidth resources.
l Uses fewer resources to meet the special routing requirements of routers.
OSPF flooding control is applied in the following situations:
l On broadcast, NBMA, or P2P networks, flooding policies need to be configured on the
specified interface to filter LSAs.
l On P2MP networks, flooding policies need to be configured on the specified neighbor to
filter LSAs.
Process of Calculating OSPF Routes

The process to calculate OSPF routes is described as follows:
l Every router supporting OSPF maintains a Link State Database (LSDB) that describes
the link state of the entire AS. According to the neighboring network topologies, each
router generates a Link State Advertisement (LSA), and floods its LSA through the
transmission of protocol packets among routers. In this way, every router receives the
LSAs of other routers and all the LSAs form the LSDB.
l The LSA describes a router's neighboring network topologies and the LSDB describes
the topology of the entire network. A router can translate the LSDB into a weighted and
directed graph, which describes the actual topology of the entire network. Obviously, all
routers have the same graph.
l Each router adopts the SPF algorithm to generate the Shortest Path Tree (SPT) with the
router itself as the root. Branches of the SPT indicate the routes to all the networks
within the autonomous system. External routes serve as the leaf nodes and outside
information is recorded through external routes labeled by the router advertising the
routes. Obviously, each router has a unique routing table.

5.6.2.2 Basic Principles of OSPF

This section describes the basic principles of OSPF, including neighbor state, adjacency
establishment and route calculation.
OSPF route calculation involves the following processes:
1. Adjacency establishment
The adjacency establishment process is as follows:
a. The local and remote routers use OSPF interfaces to exchange Hello packets to
establish a neighbor relationship.
b. The local and remote routers negotiate a master/slave relationship and exchange
Database Description (DD) packets.
c. The local and remote routers exchange link state advertisements (LSAs) to
synchronize their link state databases (LSDBs).
2. Route calculation
OSPF uses the shortest path first (SPF) algorithm to calculate routes, resulting in fast
route convergence.
OSPF Neighbor States

To exchange routing information on an OSPF network, neighbor routers must establish
adjacencies. The differences between neighbor relationships and adjacencies are described as
follows:
l Neighbor relationship: After the local router starts, it uses an OSPF interface to send a
Hello packet to the remote router. After the remote router receives the packet, it checks
whether the parameters carried in the packet are consistent with its own parameters. If
the parameters carried in the packet are consistent with its own parameters, the local and
remote routers establish a neighbor relationship.
l Adjacency: After the local and remote routers establish a neighbor relationship, they
exchange DD packets and LSAs to establish an adjacency.
OSPF has eight neighbor states: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and
Full, as shown in Figure 5-20. Down, 2-way, and Full are stable states. Attempt, Init, Exstart,
Exchange, and Loading are unstable states, which last only several minutes.

Figure 5-20 OSPF neighbor states
Down
Attempt Init
Loading
2-way Exstart Exchange
Full
Unstable state
Stable state
State change direction
Table 5-23 OSPF neighbor states and their meanings

OSPF Meaning
Neighbo
r State
Down This is the initial state of a neighbor conversation. This state indicates that a
router has not received any Hello packets from its neighbors within a dead
interval.
Attempt In the Attempt state, a router periodically sends Hello packets to manually
configured neighbors.
NOTE
This state applies only to non-broadcast multiple access (NBMA) interfaces.
Init This state indicates that a router has received Hello packets from its neighbors
but the neighbors did not receive Hello packets from the router.
2-way This state indicates that a router has received Hello packets from its neighbors
and neighbor relationships have been established between the routers.
If no adjacency needs to be established, the neighbors remain in the 2-way
state. If adjacencies need to be established, the neighbors enter the Exstart
state.
Exstart In the Exstart state, routers establish a master/slave relationship to ensure that
DD packets are sequentially exchanged.
Exchange In the Exchange state, routers exchange DD packets. A router uses a DD

packet to describe its own LSDB and sends the packet to its neighbors.
Loading In the Loading state, a router sends Link State Request (LSR) packets to its
neighbors to request their LSAs for LSDB synchronization.

OSPF Meaning
Neighbo
r State
Full In the Full state, a router establishes adjacencies with its neighbors and all
LSDBs have been synchronized.
NOTE
The neighbor state of the local router may be different from that of the remote router. For example, the
neighbor state of the local router is Full, but the neighbor state of the remote router is Loading.
Adjacency Establishment
Adjacencies can be established in either of the following situations:
l Two routers have established a neighbor relationship and communicate for the first time.
l The designated router (DR) or backup designated router (BDR) on a network segment
changes.
The adjacency establishment process is different on different networks.
Adjacency establishment on a broadcast network
On a broadcast network, the DR and BDR establish adjacencies with each router on the same
network segment, but DR others establish only neighbor relationships.
Figure 5-21 shows the adjacency establishment process on a broadcast network.
Figure 5-21 Adjacency establishment process on a broadcast network

RouterA RouterB
1.1.1.1 2.2.2.2
Down Hello (DR = 1.1.1.1, Neighbors Seen = 0) Down
Hello (DR = 2.2.2.2, Neighbors Seen = 1.1.1.1)
Init
Neighbor Hello (DR = 2.2.2.2, Neighbors Seen = 2.2.2.2)
Neighbor
DD (Seq=X, I=1, M=1, Master)
Exstart
DD (Seq=Y, I=1, M=1, Master)
Exchange Exstart
DD (Seq=Y, I=0, M=1, Slave)
Exchange
DD (Seq=Y+1, I=0, M=1, Master)
DD (Seq=Y+1, I=0, M=1, Slave)
LSR
LSU
LSAck
……
DD (Seq=Y+n, I=0, M=0, Master)
DD (Seq=Y+n, I=0, M=0, Slave)
Loading Full
LSR
LSU
Full LSAck

The adjacency establishment process on a broadcast network is as follows:

1. Neighbor relationship establishment
a. Router A uses the multicast address 224.0.0.5 to send a Hello packet to Router B
through the OSPF interface connected to a broadcast network. The packet carries
the DR field of 1.1.1.1 (ID of Router A) and the Neighbors Seen field of 0. A
neighbor router has not been discovered, and Router A regards itself as a DR.
b. After Router B receives the packet, it returns a Hello packet to Router A. The
returned packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors
Seen field of 1.1.1.1 (Router A's router ID). Router A has been discovered but its
router ID is less than that of Router B, and therefore Router B regards itself as a
DR. Then Router B's status changes to Init.
c. After Router A receives the packet, Router A's status changes to Exstart.
NOTE
The following procedures are not performed for DR others on a broadcast network.
2. Master/Slave negotiation and DD packet exchange
a. Router A sends a DD packet to Router B. The packet carries the following fields:
n Seq field: The value x indicates the sequence number is x.
n I field: The value 1 indicates that the packet is the first DD packet, which is
used to negotiate a master/slave relationship and does not carry LSA
summaries.
n M field: The value 1 indicates that the packet is not the last DD packet.
n MS field: The value 1 indicates that Router A declares itself a master.
To improve transmission efficiency, Router A and Router B determine which LSAs
in each other's LSDB need to be updated. If one party determines that an LSA of
the other party is already in its own LSDB, it does not send an LSR packet for
updating the LSA to the other party. To achieve the preceding purpose, Router A
and Router B first send DD packets, which carry summaries of LSAs in their own
LSDBs. Each summary identifies an LSA. To ensure packet transmission reliability,
a master/slave relationship must be determined during DD packet exchange. One
party serving as a master uses the Seq field to define a sequence number. The
master increases the sequence number by one each time it sends a DD packet. When
the other party serving as a slave sends a DD packet, it adds the sequence number
carried in the last DD packet received from the master to the Seq field of the packet.
b. After Router B receives the DD packet, Router B's status changes to Exstart and
Router B returns a DD packet to Router A. The returned packet does not carry LSA
summaries. Because Router B's router ID is greater than Router A's router ID,
Router B declares itself a master and sets the Seq field to y.
c. After Router A receives the DD packet, it agrees that Router B is a master and
Router A's status changes to Exchange. Then Router A sends a DD packet to Router
B to transmit LSA summaries. The packet carries the Seq field of y and the MS
field of 0. The value 0 indicates that Router A declares itself a slave.
d. After Router B receives the packet, Router B's status changes to Exchange and
Router B sends a new DD packet containing its own LSA summaries to Router A.
The value of the Seq field carried in the new DD packet is changed to y + 1.
Router A uses the same sequence number as Router B to confirm that it has received DD
packets from Router B. Router B uses the sequence number plus one to confirm that it
has received DD packets from Router A. When Router B sends the last DD packet, it sets
the M field of the packet to 0.

3. LSDB synchronization
a. After Router A receives the last DD packet, it finds that many LSAs in Router B's
LSDB do not exist in its own LSDB, so Router A's status changes to Loading. After
Router B receives the last DD packet from Router A, Router B's status directly
changes to Full, because Router B's LSDB already contains all LSAs of Router A.
b. Router A sends an LSR packet for updating LSAs to Router B. Router B returns an
LSU packet to Router A. After Router A receives the packet, it sends an LSAck
packet for acknowledgement.
The preceding procedures continue until the LSAs in Router A's LSDB are the same as
those in Router B's LSDB. Router A's status changes to Full. After Router A and Router
B exchange DD packets and update all LSAs, they establish an adjacency.
Adjacency establishment on an NBMA network
The adjacency establishment process on an NBMA network is similar to that on a broadcast
network. The blue part shown in Figure 5-22 highlights the differences from a broadcast
network.
On an NBMA network, all routers establish adjacencies only with the DR and BDR.
Figure 5-22 Adjacency establishment process on an NBMA network

RouterA RouterB
1.1.1.1 2.2.2.2
Down Down
Hello (DR = 2.2.2.2, Neighbors Seen = 0)
Init Attempt
Hello (DR = 2.2.2.2, Neighbors Seen = 2.2.2.2)
Init
DD (Seq=X, I=1, M=1, Master)
Exstart
DD (Seq=Y, I=1, M=1, Master)
Exchange Exstart
DD (Seq=Y, I=0, M=1, Slave)
Exchange
DD (Seq=Y+1, I=0, M=1, Master)
DD (Seq=Y+1, I=0, M=1, Slave)
LSR
LSU
LSAck
……
DD (Seq=Y+n, I=0, M=0, Master)
DD (Seq=Y+n, I=0, M=0, Slave)
Loading Full
LSR
LSU
Full LSAck
The adjacency establishment process on an NBMA network is as follows:

1. Neighbor relationship establishment
a. After Router B sends a Hello packet to a Down interface of Router A, Router B's
status changes to Attempt. The packet carries the DR field of 2.2.2.2 (ID of Router
B) and the Neighbors Seen field of 0. A neighbor router has not been discovered,
and Router B regards itself as a DR.
b. After Router A receives the packet, Router A's status changes to Init and Router A
returns a Hello packet. The returned packet carries the DR and Neighbors Seen

fields of 2.2.2.2. Router B has been discovered but its router ID is greater than that
of Router A, and therefore Router A agrees that Router B is a DR.
NOTE
The following procedures are not performed for DR others on an NBMA network.
2. Master/Slave relationship negotiation and DD packet exchange
The procedures for negotiating a master/slave relationship and exchanging DD packets
on an NBMA network are the same as those on a broadcast network.
3. LSDB synchronization
The procedure for synchronizing LSDBs on an NBMA network is the same as that on a
broadcast network.
Adjacency establishment on a point-to-point (P2P)/point-to-multipoint (P2MP) network
The adjacency establishment process on a P2P/P2MP network is similar to that on a broadcast
network. On a P2P/P2MP network, however, no DR or BDR needs to be elected and DD
packets are transmitted in multicast mode.
Route Calculation
OSPF uses an LSA to describe the network topology. A Type 1 LSA describes the attributes
of a link between routers. A router transforms its LSDB into a weighted, directed graph,
which reflects the topology of the entire AS. All routers in the same area have the same graph.
Figure 5-23 shows a weighted, directed graph.
Figure 5-23 Weighted, directed graph
Router A Router B
Cost = 1 1
A B
Cost = 2 Cost = 5
2 5
An LSDB is transformed into C
a weighted, directed graph.
Router C
Cost = 3 3
Router D D
Based on the graph, each router uses an SPF algorithm to calculate an SPT with itself as the
root. The SPT shows routes to nodes in the AS. Figure 5-24 shows an SPT.

Figure 5-24 SPT
1 1 1 1
A B A B A B A B
2 2 2 2
C C C C
3 3 3 3
D D D D
When a router's LSDB changes, the router recalculates a shortest path. Frequent SPF
calculations consume a large amount of resources and affect router efficiency. Changing the
interval between SPF calculations can prevent resource consumption caused by frequent
LSDB changes. The default interval between SPF calculations is 5 seconds.
The route calculation process is as follows:
1. A router calculates intra-area routes.

The router uses an SFP algorithm to calculate shortest paths to other routers in an area.
Type 1 and Type 2 LSAs accurately describe the network topology in an area. Based on
the network topology described by a Type 1 LSA, the router calculates paths to other
routers in the area.
NOTE
If multiple equal-cost routes are produced during route calculation, the SPF algorithm retains all
these routes in the LSDB.
2. The routercalculates inter-area routes.
The network segment of the routes in an adjacent area can be considered to be directly
connected to the area border router (ABR). Because the shortest path to the ABR has
been calculated in the preceding phase, the router can directly check a Type 3 LSA to
obtain the shortest path to the network segment. The autonomous system boundary
router (ASBR) can also be considered to be connected to the ABR. Therefore, the
shortest path to the ASBR can also be calculated in this phase.
NOTE
If the router performing an SPF calculation is an ABR, the router needs to check only Type 3
LSAs in the backbone area.
3. The router calculates AS external routes.
AS external routes can be considered to be directly connected to the ASBR. Because the
shortest path to the ASBR has been calculated in the preceding phase, the router can
check Type 5 LSAs to obtain the shortest paths to other ASs.
5.6.2.3 OSPF Packet Format

This section describes the format of OSPF packets.
Open Shortest Path First (OSPF) packets are encapsulated into IP packets. The OSPF protocol
number is 89. OSPF packets are classified into the following types:

l Hello packet
l Database Description (DD) packet
l Link State Request (LSR) packet
l Link State Update (LSU) packet
l Link State Acknowledgment (LSAck) packet
Packet Header Format

The five types of OSPF packets have the same packet header format. The length of an OSPF
packet header is 24 bytes. Figure 5-25 shows an OSPF packet header.
Figure 5-25 OSPF packet header
0 7 15 31
Version Type Packet length
Router ID
Area ID
Checksum AuType
Authentication
Table 5-24 describes packet header fields.
Table 5-24 Packet header fields

Version 8 bits OSPF version number. For OSPFv2, the value is 2.
Type 8 bits OSPF packet type. The values are as follows:

l 1: Hello packet
l 2: DD packet
l 3: LSR packet
l 4: LSU packet
l 5: LSAck packet
Packet 16 bits Length of the OSPF packet containing the packet header, in
length bytes.
Router ID 32 bits ID of the router that sends the OSPF packet.
Area ID 32 bits ID of the area to which the router that sends the OSPF packet
belongs.
Checksum 16 bits Checksum of the OSPF packet that does not contain the
Authentication field.

AuType 16 bits Authentication type. The values are as follows:

l 0: non-authentication
l 1: simple authentication
l 2: message digest algorithm 5 (MD5) authentication
Authenticati 64 bits This field has different meanings for different AuType values:
on l 0: This field is not defined.
l 1: This field defines password information.
l 2: This field contains the key ID, MD5 authentication data
length, and sequence number.
NOTE
MD5 authentication data is added to an OSPF packet and is not included in the Authentication field.
Hello Packet
Hello packets are commonly used packets, which are periodically sent on OSPF interfaces to
establish and maintain neighbor relationships. A Hello packet includes information about the
designated router (DR), backup designated router (BDR), timers, and known neighbors.
Figure 5-26 shows the format of a Hello packet.
Figure 5-26 Format of a Hello packet
0 7 15 31
Version Type=1 Packet length
Router ID
Area ID
Checksum AuType
Authentication
Network Mask
HelloInterval Options Rtr Pri
RouterDeadInterval
Designated Router
Backup Designated Router
Neighbor
…
Table 5-25 describes Hello packet fields.

Table 5-25 Hello packet fields

Network 32 bits Mask of the network on which the interface that sends the
Mask Hello packet resides.
HelloInterval 16 bits Interval at which Hello packets are sent.
Options 8 bits The values are as follows:

l E: Type 5 link state advertisements (LSAs) are flooded.
l MC: IP multicast packets are forwarded.
l N/P: Type 7 LSAs are processed.
l DC: On-demand links are processed.
Rtr Pri 8 bits DR priority. The default value is 1.

NOTE
If the DR priority of a router interface is set to 0, the interface cannot
participate in a DR or BDR election.
RouterDeadI 32 bits Dead interval. If a router does not receive any Hello packets
nterval from its neighbors within a specified dead interval, the
neighbors are considered Down.
Designated 32 bits Interface address of the DR.

Router
Backup 32 bits Interface address of the BDR.

Designated
Router
Neighbor 32 bits Router ID of the neighbor.
Table 5-26 lists the address types, interval types, and default intervals used when Hello
packets are transmitted on different networks.
Table 5-26 Hello packet characteristics for various network types

Networ Address Interval Type Default Interval
k Type Type
Broadcas Multicast HelloInterval 10 seconds

t address
Non- Unicast l HelloInterval for the DR, 30 seconds for HelloInterval

broadcas address BDR, and router that can 120 seconds for PollInterval
t become a DR
multiple l PollInterval for the case
access when neighbors become
(NBMA) Down and HelloInterval for
other cases

Networ Address Interval Type Default Interval

k Type Type
Point-to- Multicast HelloInterval 10 seconds

point address
(P2P)
Point-to- Unicast HelloInterval 30 seconds

multipoi address
nt
(P2MP)
NOTE
To establish neighbor relationships between routers on the same network segment, you must set the
same HelloInterval, PollInterval, and RouterDeadInterval values for the routers. PollInterval applies
only to NBMA networks.
DD Packet
During an adjacency initialization, two routers use DD packets to describe their own link state
databases (LSDBs) for LSDB synchronization. A DD packet contains the header of each LSA
in an LSDB. An LSA header uniquely identifies an LSA. The LSA header occupies only a
small portion of the LSA, which reduces the amount of traffic transmitted between routers. A
neighbor can use the LSA header to check whether it already has the LSA. When two routers
exchange DD packets, one functions as the master and the other functions as the slave. The
master defines a start sequence number. The master increases the sequence number by one
each time it sends a DD packet. After the slave receives a DD packet, it uses the sequence
number carried in the DD packet for acknowledgement.
Figure 5-27 shows the format of a DD packet.
Figure 5-27 Format of a DD packet
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Interface MTU Options 0000 I M M/S
DD sequence number
Designated Router
LSA Headers...
Table 5-27 describes DD packet fields.

Table 5-27 DD packet fields

Interface 16 bits Maximum length of the DD packet sent by the interface with
MTU packet fragmentation disabled.

l E: Type 5 LSAs are flooded.
I 1 bit If the DD packet is the first packet among multiple

consecutive DD packets sent by a router, this field is set to 1.
In other cases, this field is set to 0.
M (More) 1 bit If the DD packet is the last packet among multiple

consecutive DD packets sent by a router, this field is set to 0.
In other cases, this field is set to 1.
M/S 1 bit When two routers exchange DD packets, they negotiate a

(Master/ master/slave relationship. The router with a larger router ID
Slave) becomes the master. If this field is set to 1, the DD packet is
sent by the master.
DD sequence 32 bits Sequence number of the DD packet. The master and slave use
number the sequence number to ensure that DD packets are correctly
transmitted.
LSA - LSA header information included in the DD packet.

Headers
LSR Packet
After two routers exchange DD packets, they send LSR packets to request each other's LSAs.
The LSR packets contain the summaries of the requested LSAs. Figure 5-28 shows the
format of an LSR packet.

Figure 5-28 Format of an LSR packet
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
LS type
Link State ID
Advertising Router
...
Table 5-28 describes LSR packet fields.
Table 5-28 LSR packet fields

LS type 32 bits Type of the LSA
Link State 32 bits This field together with the LS type field describes an LSA in
ID an AS.
Advertising 32 bits Router ID of the router that generates the LSA.

Router
NOTE
The LS type, Link State ID, and Advertising Router fields can uniquely identify an LSA. If two LSAs
have the same LS type, Link State ID, and Advertising Router fields, a router uses the LS sequence
number, LS checksum, and LS age fields to obtain a required LSA.
LSU Packet
A router uses an LSU packet to transmit LSAs requested by its neighbors or to flood its own
updated LSAs. The LSU packet contains a set of LSAs. For multicast and broadcast networks,
LSU packets are multicast to flood LSAs. To ensure reliable LSA flooding, a router uses an
LSAck packet to acknowledge the LSAs contained in an LSU packet that is received from a
neighbor. If an LSA fails to be acknowledged, the router retransmits the LSA to the neighbor.
Figure 5-29 shows the format of an LSU packet.

Figure 5-29 Format of an LSU packet
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Number of LSAs
LSA...
Table 5-29 describes the LSU packet field.
Table 5-29 LSU packet field

Number of 32 bits Number of LSAs contained in the LSU packet

LSAs
LSAck Packet
A router uses an LSAck packet to acknowledge the LSAs contained in a received LSU packet.
The LSAs can be acknowledged using LSA headers. LSAck packets can be transmitted over
different links in unicast or multicast mode. Figure 5-30 shows the format of an LSAck
packet.
Figure 5-30 Format of an LSAck packet
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
LSAs Headers
Table 5-30 describes the LSAck packet field.

Table 5-30 LSAck packet field

LSAs Determine This field is used to acknowledge an LSA.

Headers d by the
header
length of
the LSA to
be
acknowled
ged.
5.6.2.4 OSPF LSA Format

This section describes the format of OSPF LSA.
Each router in an autonomous system (AS) generates one or more types of link state
advertisements (LSAs), depending on the router's type. Multiple LSAs form a link state
database (LSDB). Open Shortest Path First (OSPF) encapsulates routing information into
LSAs for transmission. Commonly used LSAs include:
l Router-LSAs (Type 1)
l Network-LSAs (Type 2)
l Summary-LSAs, including network-summary-LSAs (Type 3) and ASBR-summary-
LSAs (Type 4)
l AS-external-LSAs (Type 5)
LSA Header Format

All LSAs have the same header. Figure 5-31 shows an LSA header.
Figure 5-31 LSA header
0 15 23 31
LS age Options LS type
Link State ID
Advertising Router
LS sequence number
LS checksum length
Table 5-31 describes LSA header fields.

Table 5-31 LSA header fields

LS age 16 bits Time that elapses after the LSA is generated, in seconds. The
value of this field continually increases regardless of whether
the LSA is transmitted over a link or saved in an LSDB.

l E: Type 5 LSAs are flooded.
LS type 8 bits Type of the LSA. The values are as follows:

l Type1: Router-LSA
l Type2: Network-LSA
l Type3: Network-summary-LSA
l Type4: ASBR-summary-LSA
l Type5: AS-external-LSA
l Type7: NSSA-LSA
Link State 32 bits This field together with the LS type field describes an LSA in
ID an AS.
Advertising 32 bits Router ID of the router that generates the LSA.

Router
LS sequence 32 bits Sequence number of the LSA. Neighbors can use this field to
number identify the latest LSA.
LS 16 bits Checksum of all fields except the LS age field.

checksum
length 16 bits Length of the LSA including the LSA header, in bytes.
Router-LSA
A router-LSA describes the link status and cost of a router. Router-LSAs are generated by a
router and advertised within the area to which the router belongs. Figure 5-32 shows the
format of a router-LSA.

Figure 5-32 Format of a router-LSA
0 15 23 31
LS age Options LS type=1
Link State ID
Advertising Router
LS sequence number
LS checksum length
0 V E B 0 # links
Link ID
Link Data
Type # TOS metric
...
TOS 0 TOS metric
Link ID
Link Data
...
Table 5-32 describes router-LSA fields.
Table 5-32 Router-LSA fields

Link State 32 bits Router ID of the router that generates the LSA.
ID
V (Virtual 1 bit If the router that generates the LSA is located at one end of a
Link) virtual link, this field is set to 1. In other cases, this field is set
to 0.
E (External) 1 bit If the router that generates the LSA is an autonomous system
boundary router (ASBR), this field is set to 1. In other cases,
this field is set to 0.
B (Border) 1 bit If the router that generates the LSA is an area border router
(ABR), this field is set to 1. In other cases, this field is set to
0.
# links 16 bits Number of links and interfaces described in the LSA,

including all links and interfaces in the area to which the
router belongs.

Link ID 32 bits Object to which the router is connected. This field has
different meanings for different link types:
l 1: router ID
l 2: interface IP address of the designated router (DR)
l 3: network segment or subnet number
l 4: router ID of the neighbor on a virtual link
Link Data 32 bits Link data. This field has different meanings for different link
types:
l 1: interface index
l 3: subnet mask
l 2 and 4: interface address of the router
Type 8 bits Type of the router link. The values are as follows:
l 1: The router is connected to another router in point-to-
point (P2P) mode.
l 2: The router is connected to a transport network.
l 3: The router is connected to a stub network.
l 4: The router is connected to another router over a virtual
link.
# TOS 8 bits Number of types of service (ToSs).
metric 16 bits Cost of the link.
TOS 8 bits Type of service.
TOS metric 16 bits Metric for the specified ToS.
Network-LSA
A network-LSA describes the link status of all routers on the local network segment.
Network-LSAs are generated by a DR on a broadcast or non-broadcast multiple access
(NBMA) network and advertised within the area to which the DR belongs. Figure 5-33 shows
the format of a network-LSA.

Figure 5-33 Format of a network-LSA
0 15 23 31
Link State ID
Advertising Router
LS sequence number
LS checksum length
Network Mask
Attached Router
...
Table 5-33 describes network-LSA fields.
Table 5-33 Network-LSA fields

Link State 32 bits Interface IP address of the DR

ID
Network 32 bits Mask of the broadcast or NBMA network

Mask
Attached 32 bits Router IDs of all routers on the broadcast or NBMA network,
Router including the router ID of the DR
Summary-LSA
A network-summary-LSA describes routes on a network segment in an area. The routes are
advertised to other areas.
An ASBR-summary-LSA describes routes to the ASBR in an area. The routes are advertised
to all areas except the area to which the ASBR belongs.
The two types of summary-LSAs have the same format and are generated by an ABR. Figure
5-34 shows the format of a summary-LSA.

Figure 5-34 Format of a summary-LSA
0 15 23 31
LS age Options LS type=3 or 4
Link State ID
Advertising Router
LS sequence number
LS checksum length
Network Mask
0 metric
TOS TOS metric
...
Table 5-34 describes network-summary-LSA fields.
Table 5-34 Network-summary-LSA fields
Link State 32 bits Advertised network address

ID
Network 32 bits Mask of the broadcast or NBMA network

Mask
metric 24 bits Cost of the route to the destination address
TOS 8 bits Type of service
TOS metric 24 bits Metric for the specified ToS
NOTE
When a default route is advertised, both the Link State ID and Network Mask fields are set to 0.0.0.0.
Table 5-35 describes ASBR-summary-LSA fields.
Table 5-35 ASBR-summary-LSA fields
Link State 32 bits Router ID of the ASBR

ID
Network 32 bits Set to 0.0.0.0

Mask
metric 24 bits Cost of the route to the destination address
TOS 8 bits Type of service

TOS metric 24 bits Metric for the specified ToS
AS-External-LSA
An AS-external-LSA describes AS external routes. AS-external-LSAs are generated by an
ASBR. Among the five types of LSAs, only AS-external-LSAs can be advertised to all areas
except stub areas and not-so-stubby areas (NSSAs). Figure 5-35 shows the format of an AS-
external-LSA.
Figure 5-35 Format of an AS-external-LSA
0 15 23 31
Link State ID
Advertising Router
LS sequence number
LS checksum length
Network Mask
E 0 metric
Forwarding Address
External Route Tag
E TOS TOS metric
Forwarding Address
External Route Tag
...
Table 5-36 describes AS-external-LSA fields.
Table 5-36 AS-external-LSA fields
Link State 32 bits Advertised network address.

ID
Network 32 bits Mask of the advertised destination address.

Mask
E 1 bit Type of the external route. The values are as follows:

l 0: Type 1 external route
l 1: Type 2 external route
metric 24 bit Cost of the route to the destination address.

Forwarding 32 bits Packets destined for the advertised destination address are
Address forwarded to the address specified by this field.
External 32 bits Tag added to the external route. This field can be used to
Route Tag manage external routes. OSPF itself does not use this field.
TOS 8 bits Type of service.
TOS metric 24 bits Metric for the specified ToS.
NOTE
When AS-external-LSAs are used to advertise default routes, both the Link State ID and Network Mask
fields are set to 0.0.0.0.
5.6.2.5 OSPF Areas

This section introduces OSPF areas and describes the feature of OSPF areas.
Before Area Partition

Suppose that all routers in a large-scale network run OSPF and the number of routers
increases with the unceasing expansion of the network. The large number of routers results in
a large LSDB on each router. Such an LSDB occupies a great amount of memory, complicates
the operating of the SPF algorithm, and leads to the overload of routers.
With the expansion of networks, the possibility of topology changes is on the increase. That
is, the network usually confronts "turbulence". A great number of OSPF packets are
transmitted on the network, and the utilization of bandwidth is reduced. Each change in
topology requires all the routers to recalculate the routes.
After Area Partition

OSPF solves the preceding problem by dividing an AS into areas. An area is regarded as a
logical router group. Each group is identified by an area ID. At the border of an area resides a
router, rather than a link. A network segment (or a link) can belong to only one area. That is,
each OSPF interface must belong to an area, as shown in Figure 5-36.

Figure 5-36 OSPF area division
Backbone Area
After an OSPF network is divided into different areas, not all areas are equal. Among areas,
one area with area ID as 0 is called the backbone area. The backbone area is responsible for
forwarding the routes between areas. The routing information between the non-backbone
areas must be forwarded through the backbone area.
OSPF defines two rules for a backbone area as below:
l Connectivity must be available between non-backbone areas and the backbone area.
l Connectivity must be available over the backbone area.
Virtual Link
In actual applications, the physical connectivity between the backbone area and non-backbone
areas cannot be ensured due to various reasons. The problem can be solved by the
configuration of an OSPF virtual link.
Virtual link refers to a logical channel established between two ABRs through a non-
backbone area. The virtual link must be configured on both ends of a link. The transmit area
refers to the area that provides an internal route of a non-backbone area for the two ends of a
virtual link.
As shown in Figure 5-37, Area 2 is not directly connected to the backbone area. A virtual link
is configured on ABRs to provide the connectivity between Area 2 and the backbone area.
Figure 5-37 Schematic diagram 1 of the virtual link
Area0 Virtual Link Area2

Area1
Transit Area
ABR ABR

The virtual link also serves as a backup link. If a link fault occurs on the backbone area, the
virtual link provides the logical connectivity for the backbone area, as shown in Figure 5-38.
Figure 5-38 Schematic diagram 2 of the virtual link

Area1
Transit Area
Virtual Link
ABR ABR
Area0
The virtual link is similar to a point-to-point connection between two ABRs. Similar to
physical interfaces, the interfaces on the virtual link can be configured with parameters such
as the Hello interval.
When OSPF packets are transmitted between two ABRs, these packets are transparent for the
intermediate routers enabled with OSPF. That is, the intermediate routers forward the packets
as common IP packets without resolving them after detect that they are not the destinations of
the packets.
Stub Area
A stub area is a special area where the ABRs do not flood the received routes outside the AS.
In stub areas, the size of the routing tables of the routers and the routing information in
transmission are reduced.
A stub area is an optional configuration. Not all areas can be configured as stub areas.
Generally, a stub area is a non-backbone area with only one ABR and is located at the AS
boundary.
To ensure the reachability to a destination outside the AS, the ABR in the stub area originates
a default route and advertises it to the non-ABR routers in the stub area.
Note the following when configuring a stub area:
l The backbone area cannot be configured as the stub area.

l An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub
area.

l A virtual link cannot pass through a stub area.
NSSA
A new type of an area, Not-So-Stubby Area (NSSA), and a new type of an LSA, NSSA-LSA
(or Type 7 LSA) are defined in RFC 1587.
As the NSSA is derived from the stub area, it resembles the stub area in many ways. Type 5
LSA is not allowed in the NSSA. The Type 7 LSA is generated by the ASBR in the NSSA,
and is flooded only in the NSSA. When a Type 7 LSA reaches the ABR of the NSSA, the
ABR translates the Type 7 LSA into an AS-External-LSA and floods it to the other areas. The
ABR translating LSAs is also called the translator.
As shown in Figure 5-39, the AS that runs OSPF contains three areas, area 0, area 1, and area
2. The other two ASs run RIP. Area 1 is configured as the NSSA. After Area 1 transmits the
received RIP routes to the ASBR in the NSSA, the ASBR originates Type 7 LSAs and floods
them in Area 1. When Type 7 LSAs reach the ABR in the NSSA, the ABR translates them
into Type 5 LSAs, and then floods them to Area 0 and Area 2.
On the other hand, the RIP routes in the AS that runs RIP in Area 2 are transmitted in the AS
by Type 5 LSAs originated by ASBR in Area 2. Type 5 LSAs do not reach Area 1 because
Area 1 is an NSSA.
Similar to the stub area, an NSSA cannot be configured with virtual links.
Figure 5-39 NSSA
Features of Each Area

Figure 5-40 shows the differences between totally stub area, stub area, NSSA area, and
totally NSSA area.

Figure 5-40 Area features
The features of the areas are as follows:
l Totally stub area: allows the Type3 default routes advertised by ABR but not inter-area
routes or those outside ASs.
l Stub area: different from the totally stub area, the stub area allows inter-area routes.
l NSSA area: different from the stub area, the NSSA area allows the import of external
routes into the AS. The ASBR advertises Type 7 LSA to the NSSA area.
l Totally NSSA area: different from the stub area, the NSSA area does not allow inter-area
routes.
5.6.2.6 OSPF GR
This section described the related concepts and the implementation process of OSPF GR.
OSPF graceful restart (GR) allows packets to be forwarded during OSPF restart. OSPF GR
ensures service continuity and improves network reliability.
Background
When the router restarts or performs a master/slave main control board switchover, it
immediately ages all routing entries in the forwarding information base (FIB), which causes
route interruptions. An adjacent router deletes the router from its neighbor list and notifies
other routers of the restart or switchover. As a result, shortest path first (SPF) calculations are
performed on the entire network again. If the router recovers in a short time, a neighbor
relationship is reestablished. Frequent neighbor relationship changes cause route flapping.
To resolve this issue and avoid unnecessary SPF calculations, enable OSPF GR. After you
enable OSPF GR on the router, the router restarts OSPF in GR mode and notifies an adjacent
router that it will recover immediately. In this situation, the adjacent router does not delete the
OSPF GR-enabled router from its neighbor list and other routers do not detect that the OSPF

GR-enabled router is restarting. OSPF GR prevents route flapping caused by neighbor

relationship changes. As shown in Figure 5-41, router A, router B, router C, and router D run
OSPF, and router A and router B have OSPF GR enabled. When router A restarts in GR
mode, router B helps router A perform a GR without notifying router C or router D of the GR.
This process ensures service continuity.
Figure 5-41 OSPF GR
RouterC
RouterA RouterB
GR
Restarter Helper
RouterD
Related Concepts
l GR
GR is one of high availability (HA) technologies, which comprise a set of
comprehensive technologies, such as fault-tolerant redundancy, link protection, faulty
node recovery, and traffic engineering. GR, a fault-tolerant redundancy technology, has
been widely used for router upgrades and master/slave main control board switchovers.
GR ensures proper traffic forwarding and service continuity during a routing protocol
restart.
GR is classified into the following types by status:
– Totally GR: When a neighbor of a router does not support GR, the router leaves the
GR state.
– Partly GR: When a neighbor of a router does not support GR, only the router's
interface connected to this neighbor leaves the GR state.
GR is classified into the following types based on the implementation mode:
– Planned GR: allows you to configure the router to restart or perform a master/slave
main control board switchover. The restarter sends a grace link state advertisement
(LSA) before the restart or master/slave main control board switchover.
– Unplanned GR: allows the router to restart or perform a master/slave main control
board switchover when the router fails. The router immediately performs a master/
slave main control board switchover without sending a grace LSA. When the slave
main control board goes Up, the router enters the GR state.
l Grace LSA
When the router enters or leaves the GR state, it sends grace LSAs to notify its neighbors
of the GR period, cause, and interface address.
l Restarter
A restarter is a restarting router that can be configured to support totally or partly GR.
l Helper

A helper helps a restarter maintain routing information and can be configured to support
planned or unplanned GR. A policy can also be configured to enable the helper to
selectively support GR.
l GR period
A GR period is the time during which a GR is performed. The GR period cannot exceed
1800 seconds. A router can leave the GR state without waiting for GR to expire.
Implementation
Table 5-37 describes differences between master/slave main control board switchovers with
OSPF GR enabled and disabled.
Table 5-37 Differences between master/slave main control board switchovers with OSPF GR
enabled and disabled
Item Master/Slave Main Master/Slave Main Control Board
Control Board Switchover with OSPF GR Enabled
Switchover with OSPF
GR Disabled
Neighbor OSPF neighbor OSPF neighbor relationships are

establishment relationships are reestablished.
reestablished.
Route Routes are recalculated. Routes are recalculated.

calculation
FIB FIBs change. FIBs remain unchanged.
Route The entire network detects Except the neighbors of the router on which
flapping route changes, and route a master/slave main control board
flapping occurs for a short switchover occurred, other routers do not
period of time. detect route changes.
Impact on Packets are lost during No packets are lost during forwarding, and
services forwarding, and services services are not affected.
are interrupted.
Figure 5-42 shows an OSPF GR process.

Figure 5-42 OSPF GR process

RouterA RouterB
Restarter Helper
Before the active/ Grace-LSA Enter

standby switchover Helper
LSAck
Finish switchover Return LSAck packet
Grace-LSA
Grace-LSA
Enter GR Updates the GR period
Grace-LSAs
Send Hello packets, negotiate, exchange
DD packets, and synchronize LSDB
Full
Flush Grace-LSA
Exit GR successfully Exit the Helper successfully
An OSPF GR process includes the following procedures:

1. The restarter (router A) enters the GR state.
a. The restarter performs a master/slave main control board switchover.
NOTE
In planned GR mode, the restarter sends a grace LSA to each neighbor to notify them of the
GR start, period, and cause before performing a master/slave main control board switchover.
In unplanned GR mode, the restarter does not send grace LSAs.
b. Before the restarter enters the GR state, it sends a grace LSA to maintain OSPF
neighbor relationships.
c. When the slave main control board goes Up, the restarter immediately sends a grace
LSA to notify the helper (router B) of the GR start, period, and cause. Then, the
restarter sends five consecutive grace LSAs to the helper to ensure that the helper
can receive a grace LSA.
NOTE
Sending five consecutive grace LSAs is proposed by vendors and has not been defined by
OSPF.
During the GR, the helper retains a neighbor relationship with the restarter. Other routers
do not detect the master/slave main control board switchover performed by the restarter.
2. The restarter stays in the GR state.
a. The restarter and helper establish an OSPF adjacency.
b. The helper checks the restarter status. If the restarter status is Down, the helper
considers that the restarter can restore services within a specified GR period. Before
the specified GR period expires, the helper does not terminate sessions or delete the
topology or routing information obtained from the restarter.

c. When the restarter recovers, it sends a packet to the helper. After the restarter
receives a response, it reestablishes a neighbor relationship with the helper.
d. The restarter establishes a session with the helper to obtain topology or routing
information and uses the information to calculate its own routing table.
A master/slave main control board switchover or restarter restart can be manually
performed or automatically triggered by faults. During the master/slave main control
board switchover or restarter restart, the restarter does not delete the routing information
from its routing table or FIB or reset its interface boards. This process ensures service
continuity.
3. The restarter leaves the GR state.
– If the GR is successful, the restarter reestablishes a neighbor relationship with the
helper before the GR period expires. After the helper receives a grace LSA with an
aging time of 3600 seconds from the restarter, the status of the neighbor relationship
between the helper and restarter changes to Full.
– If the GR fails, several cases occur on the restarter and helper.
The following conditions occur on the restarter:
n The GR expires, and the neighbor relationship does not recover completely.
n Type 1 or Type 2 LSAs sent by the helper cause the restarter to fail to perform
a bidirectional check.
n The status of the interface that functions as the restarter changes.
n The restarter receives 1-way Hello packets from the helper.
n The restarter receives grace LSAs generated by another router on the same
network segment.
NOTE
Only one router can perform a GR on the same network segment at the same time.
n Different designated routers (DRs) or backup designated routers (BDRs) are
elected among the restarter and neighbors on the same network segment due to
topology changes.
The following conditions occur on the helper:
n The helper does not receive grace LSAs from the restarter before the neighbor
relationship expires.
n The status of the interface that functions as the helper changes.
n The helper receives LSAs, which are different from the LSAs in its own link
state database (LSDB), from other routers. You can configure the helper not to
perform a strict LSA check to avoid this issue.
n The helper receives grace LSAs from two routers on the same network
segment at the same time.
n The neighbor relationships between the helper and other routers change.
5.6.2.7 OSPF Packet Authentication

This section describes the classification and the application of OSPF packet authentication,
OSPF packet authentication encrypts OSPF packets by adding the authentication field to
packets to ensure network security. When a local device receives OSPF packets from a remote
device, the local device discards the packets if finding that the authentication passwords do
not match. This protects the local device.

Classification of Authentication
According to the types of packets, the authentication is classified into the following:
l Area authentication
This authentication is configured in the OSPF area view and applies to the packets
received by all the interfaces in the OSPF area.
l Interface authentication
This authentication is configured in the interface view and applies to all the packets
received by the interface.
According to the authentication modes of packets, the authentication is classified into the
following:
l Non-authentication
Authentication is not required.
l Simple authentication
The authenticated party directly adds the configured password to packets for
authentication. This imposes security threats.
l MD5 authentication
The authenticated party encrypts the configured password using a Message Digest 5
(MD5) algorithm and adds the ciphertext password to packets for authentication. This
authentication mode improves password security. The MD5 algorithms supported
includes MD5 and HMAC-MD5.
A keychain consists of multiple authentication keys, each of which contains an ID and a
password. Each key has the lifecycle. According to the life cycle of the key, you can
dynamically select different authentication keys from the keychain. A keychain can
dynamically select the authentication key to enhance attack defense.
Keychain provides authentication protection for OSPF by dynamically changing
algorithms and keys to improve the security of OSPF.
The HMAC-SHA256 algorithm use to encrypt a password before adding the password to
the packet, which improves password security.
OSPF carries authentication types in packet headers and authentication information in packet
tails.
The authentication types include:
l 0: Non-authentication
l 1: Simple authentication
l 2: Ciphertext authentication

Figure 5-43 Networking for OSPF packet authentication on a broadcast network
RouterA RouterB RouterC
RouterD RouterE

l OSPF neighbor relationships can be set up between multiple devices on the same
network only when interface authentication is configured in the same manner on all the
devices.
l When multiple devices are in the same area, you must configure area authentication in
the same manner on all the devices.
5.6.2.8 BFD for OSPF

This section describes the definition, the purpose and the principle of BFD for OSPF.
Definition
Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults
between forwarding engines.
To be specific, BFD detects connectivity of a data protocol on the same path between two
systems. The path can be a physical link, a logical link, or a tunnel.
In BFD for OSPF, a BFD session is associated with OSPF. The BFD session fast detects a link
fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of the
network topology.
Purpose
The link fault or the topology change may cause routers to recalculate routes. Therefore, the
convergence of routing protocols must be sped up to improve the network performance.
Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster
and notify the faults to routing protocols immediately. If BFD is associated with routing
protocols, once a link fault occurs, BFD can speed up the convergence of routing protocols.

Table 5-38 BFD for OSPF

Associated with BFD or Link Fault Detection Convergence Speed
Not Mechanism
Not associated with BFD An OSPF Dead timer At the second level
expires. By default, the
timeout period of the timer
is 40s.
Associated with BFD A BFD session goes Down. At the millisecond level
Principle
Figure 5-44 BFD for OSPF
FW_A FW_B
GE3/0/0
172.16.1.1/24
GE2/0/0 GE2/0/0
GE1/0/0 3.3.3.1/24 3.3.3.2/24
GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE2/0/0
1.1.1.2/24 2.2.2.1/24
Area0
FW_C
The principle of BFD for OSPF is as shown in Figure 5-44.
l OSPF neighbor relationships are established between these three Routers.

l After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session.
l The outbound interface on FW_A connected to FW_B is GE 2/0/0. If the link fails, BFD
detects the fault and then notifies FW_A of the fault.
l FW_A processes the event that a neighbor relationship becomes Down and re-calculates
routes. After calculation, the outbound interface is GE1 /0/0 passes through FW_C and
then reaches FW_B.

Read this section carefully before you configure OSPF.
Precautions
To establish OSPF neighboring relationship, devices need to exchange DD packets.
Therefore, you need to configure a security policy on the FW to permit the OSPF packets

between the Local zone and the security zone where the neighboring device resides.
Otherwise, the OSPF neighboring relationship fails to be established.
5.6.4 OSPF Configuration Using the Web UI

This section describes how to use the Web user interface (UI) to configure OSPF.
Adding an OSPF Process

Step 1 Choose Network > Route > OSPF.
Step 2 Click Add.
Table 5-39 Adding an OSPF process

Type OSPF version:

l OSPF v2: OSPF for IPv4.
In this example, OSPF v2 is used.
l OSPF v3: OSPF for IPv6.
Process ID The system supports OSPF multi-process. If multiple OSPF

processes are enabled on one device, different process IDs
need to be specified. An OSPF process ID is a local concept.
The devices with different process IDs can exchange packets in
between.
Router ID To ensure the OSPF running stability, during the network

planning, router IDs need to be planned and manually
configured. This ensures that each device in the autonomous
system (AS) has a unique router ID. A common undertaking is
to set the router ID to be the IP address of a certain interface on
the device.
If the router ID is not manually specified, the system
automatically selects one from the configured interface IP
addresses. The selection sequence is: The maximum IP address
of the LoopBack interface IP addresses is preferentially
selected as the route ID. If no LoopBack interface is available,
the maximum IP addresses of interfaces is selected as the
router ID.

SPF Calculation Interval The shortest path first (SPF) calculation period of an OSPF
route.
If the network topology keeps changing, the immediate
calculation of the shortest path affects the efficiency of a
router.
By adjusting the minimum interval between two contiguous
SPF calculations, the influence of network topology changes is
reduced.
You can change the value of this parameter based on the actual
network condition.
Internal Priority Indicates the default route priority of the OSPF routing
protocol.
ASE Priority Indicates the default route priority of the OSPF routing
protocol outside the AS.
BFD Function Enable the function of BFD for OSPF.
Local Detection Multiple Indicates the local detection multiple.
Sending Interval Indicates the interval for sending the BFD packets.
Receiving Interval Indicates the interval for receiving the BFD packets.
Default Route Advertises the default route in the OSPF route area. In this
case, active default routes of other OSPF processes must exist
in the routing table of the device.
You can specify this parameter when you need to import the
default route to the OSPF area.
Always Generates and advertises the default route regardless of

whether active default routes of other OSPF processes exist in
the routing table of the device.
You can configure this parameter only when Default Route is
selected.
Step 4 Click OK.

If the new OSPF process is displayed on the page, the operation succeeds.
----End
Configuring an OSPF Area

The network expansion results in a huge link state database (LSDB). This adds the routers'
workloads and reduces their performance.
This problem can be resolved by allocating OSPF areas, and performing route aggregation on
area border routers. In this way, the number of LSAs advertised to other areas is reduced,
network performance is enhanced, and adverse influence caused by network topology changes
is minimized.

Step 2 Click corresponding to the OSPF progress to be modified.
Step 3 In the OSPF Process ID:ID navigation tree, choose Basic Configuration > Area Settings.
Step 4 Click Add.

Area Indicates the area identifier.
IP Network Indicates the IP address of the network segment to be added to

the OSPF area.
The OSPF protocol takes effect only on an interface that meets
the following two requirements:
l The length of the interface IP address mask is not shorter
than the length of the IP Network mask. The OSPF uses a
reverse mask. For example, 0.0.0.255 indicates that the
length of the mask is 24 bits. If the mask is 0.0.0.0, it
indicates that all 32 bits of the address must be exactly
matched without considering the IP address mask length of
the interface. This method exactly controls the running of
OSPF on interfaces.
l The primary IP address of the interface is in the specified
network segment range.
Mask/Wildcard Mask Indicates the mask or reverse mask of an IP address.

The device supports both masks and inverse masks. For
example, after mask 255.255.128.0 is entered, the system
automatically identifies and displays the corresponding inverse
mask 0.0.127.255.
Authentication Mode Indicates the authentication mode towards packets in an OSPF

area.
l NONE: indicates none-authentication.
l Simple: indicates simple authentication.
l MD5: indicates MD5 authentication.
l HMAC-MD5: indicates HMAC-MD5 authentication.
l HMAC-SHA256: indicates HMAC-SHA256
authentication.
If authentication mode and password are configured both on an
OSPF area and interface, the settings on the interface take
precedence.
Password Type Selects a method for configuring passwords. This parameter is

required when Authentication Mode is Simple. Two methods,
Plain and Cipher, are available.

Simple Password Specifies the area authentication password.

This parameter is required when Authentication Mode is
Simple.
Confirm Password The password needs to be confirmed when Password Type is

Cipher.
MD5 Key Configures the identifier of the MD5 authentication key.

MD5.
MD5 Password Configures the MD5 authentication key.

MD5.
HMAC-MD5 Key Configures the identifier of the HMAC-MD5 authentication

key.
HMAC-MD5.
HMAC-MD5 Password Configures the HMAC-MD5 authentication key.

HMAC-MD5.
HMAC-SHA256 Key Configures the identifier of the HMAC-SHA256 authentication

key.
HMAC-SHA256.
HMAC-SHA256 Configures the HMAC-SHA256 authentication key.

Password This parameter is required when Authentication Mode is
HMAC-SHA256.
Area Type Indicates the area type.

l NONE: indicates that the OSPF area is a common area.
Other attributes are not set.
l Stub: indicates that the OSPF area is the stub area. The stub
area is special. The ABR in this type of area does not
advertise the received ASE routes. The scale of the routing
table and the quantity of the routing information to be
transmitted are greatly reduced.
l NSSA: Indicates that the OSPF area is the NSSA area,
which is an extension of the Stub area. This type of area
does not allow the import of the Type-5 LSA but allows the
import of the Type-7 LSA. The Type7 LSA is generated by
the ASBR in the NSSA area, and transmitted in the NSSA
area. When the Type7 LAS reaches the ABR of the NSSA,
the ABR changes the Type7 LSA to the Type5 LSA, and
then transmits the Type5 LSA to other areas.

Default Cost Indicates the cost of the default routes sent to the Stub area or
the NSSA area through OSPF.
This item is required when you set Area Type to Stub or
NSSA.
Stub Area Setting This parameter enables a stub area to be a totally stub area, and
denies Type3 LSAs from entering the stub area that connects to
the ABR. This reduces the number of LSAs sent to the stub
area.
This item is required when you set Area Type to Stub.
NSSA Settings If the area is an NSSA, you can perform the following
configurations:
l Advertise default route to NSSA: indicates that the default
Type-7 LSA is generated. On the ABR, the default Type-7
LSA is generated no matter whether the route 0.0.0.0 exists
in the routing table. On the ASBR, the default Type-7 LSA
is generated when the route 0.0.0.0 exists in the routing
table.
l Do not import external routes: indicates that the external
routes imported to the ASBR are not advertised to the
NSSA area.
l Totally NSSA: indicates that inter-area routes (Type-3
LSAs) are not imported to the totally NSSA. The ABR
automatically generates a default Type-3 LSA and
advertises it in the entire NSSA.
Step 6 Click OK.

If the new OSPF area is displayed on the page, the operation succeeds.
----End
Configuring an OSPF Network Segment

Step 3 In the OSPF Process ID:ID navigation tree, choose Basic Configuration > Network
Settings.
Step 4 Click Add.
Step 5 In the Area drop-down list, select an existed area.
Step 6 Enter a network segment address and a mask to be added.

NOTE
The device supports both masks and inverse masks. For example, after mask 255.255.128.0 is entered,
the system automatically identifies and displays the corresponding inverse mask 0.0.127.255.

Step 7 Click OK.

If the new network segment is displayed on the page, the operation succeeds.
----End
Configuring an OSPF Interface

Step 3 In the OSPFv2 Process ID:ID navigation tree, choose Basic Configuration > Interface
Settings.
Step 4 Click corresponding to the interface to be configured.

Interface Name Indicates the name of an OSPF interface.
Network Type Indicates the network type of an OSPF interface.

l Broadcast: indicates that the network type of the interface is
broadcast.
l NBMA: indicates that the network type of the interface is
nonbroadcast multiaccess (NBMA).
l P2MP: indicates that the network type of the interface is
point-to-multipoint (P2MP).
l P2P: indicates that the network type of the interface is
point-to-point (P2P).
Cost Indicates the cost of running the OSPF protocol on the

interface.
MTU Enables the interface to use the actual MTU value when it
sends DD packets.
Usually, the establishment of a peer relationship requires that
the Hello and Dead timers at the two ends of a link have same
values respectively and do not compare the MTU values of the
ports.
The MTU negotiation can be enabled for this function. Then if
the MTU values of the ports are different, a peer relationship
cannot be established.

Authentication Mode Indicates the mode in which the OSPF interface authenticates
packets.
l NONE: indicates that interface authentication is not
configured.
authentication.
precedence.

Simple Password Indicates the authentication password of the interface.

Simple.

Cipher.

MD5.

MD5.

key.
HMAC-MD5.

HMAC-MD5.

key.
HMAC-SHA256.

HMAC-SHA256.

Advanced Settings
DR Priority When the network type is broadcast or NBMA, you can

configure the interface DR priority to affect the DR/BDR
selection on the network.
This parameter is required when Network Type is Broadcast
or NBMA.
The DR priority value is in direct proportion to the priority. If
the priority is set to 0, the interface is unavailable for the DR
selection.
Transmission Delay Indicates the delay of transmitting the LSA on the interface.
The LSA in the local router LSDB is aging with time (its value
is increased by 1 every second); however, the network
transmission process does not age with time; therefore, you are
advised to add the latency to the LSA aging period before
sending the LSA. This is especially important for a low-speed
network.
Peer Timeout Indicates the timeout period.

The intervals for sending Hello packets and the peer timeout
periods of interfaces on the same network segment must have
same values respectively.
The poll interval or the peer timeout interval of the same
interface is at least four times longer than the interval for
sending Hello packets.
Hello Packet Interval Indicates the interval for sending Hello packets.
A shorter interval for sending Hello packets results in a faster
speed in detecting network topology changes and larger cost on
system resources.
Polling Interval Indicates the interval for sending polling Hello packets.
This parameter defines the interval for sending polling Hello
packets from an NBMA interface to peer routers with a Down
state.
Retransmission Interval After a router sends an LSA to its peer router, it waits for a
confirmation packet sent by the peer router. If no confirmation
packet is received within this interval, the router resends the
LSA.
This parameter defines the interval for resending an LSA.

BFD Block Indicates whether to configure BFD block:

l Select Block, indicating to enable the function of blocking
to prevent the dynamic creation of BFD sessions on an
interface.
l Select Enable, indicating to enable the BFD function. And
you need to further configure Sending Interval, Local
Detection Multiple and Receiving Interval.
l Select Inherit, indicating to enable the BFD function and
inherit the BFD configuration in the OSPF process.
Sending Interval Indicates the interval for sending the BFD packets.
Local Detection Multiple Indicates the local detection multiple.
Receiving Interval Indicates the interval for receiving the BFD packets.
Step 6 Click OK.
----End
Configuring Route Importing for an OSPF Process

If a router runs the OSPF and other routing protocols, you can configure the OSPF to import
routes generated by other protocols, such as RIP, ISIS, BGP, static route, or direct route.
These route information is advertised by using Type5 LSAs or Type7 LSAs.
Step 3 In the OSPF Process ID:ID navigation tree, choose Advanced Settings > Route Import.
Step 4 Click Add.

Process ID The routing protocol process number needs to be specified

when the Route Type is set to OSPF, RIP, or ISIS.
Route Policy Indicates the configured routing policy.
Tag Indicates the tag of an imported route.
Type Indicates the type of an imported route.
Step 6 Click OK.

If the new route import configuration is displayed on the page, the operation succeeds.
----End
Configuring a Virtual Link

You can establish a logical channel between two ABRs through a non-backbone area by
configuring OSPF virtual links.
NOTE
Note the following when you configure a virtual link:

l A virtual link must be configured between two ABRs.
l The transmit area that the virtual link goes through must have the complete route selection
information.
l The transmit area cannot be a Stub area or NSSA area.
Step 3 In the OSPFv2 Process ID:ID navigation tree, choose Advanced Settings > Virtual Link.
Step 4 Click Add.

Peer Router ID Indicates the ID of the peer router of the virtual link.
Transit Area Indicates the OSPF area which the virtual link goes through.
Advanced Settings
Transmission Delay Indicates the delay of transmitting the LSA on the interface.
The LSA in the local router LSDB is aging with time (its value
network.
Peer Timeout Indicates the timeout period.

The intervals for sending Hello packets and the peer timeout
periods of interfaces on the same network segment must have
same values respectively.
The poll interval or the peer timeout interval of the same
interface is at least four times longer than the interval for
sending Hello packets.
Hello Packet Interval Indicates the interval for sending Hello packets.
A shorter interval for sending Hello packets results in a faster
speed in detecting network topology changes and larger cost on
system resources.

Retransmission Interval After a router sends an LSA to its peer router, it waits for a
confirmation packet sent by the peer router. If no confirmation
packet is received within this interval, the router resends the
LSA.
This parameter defines the interval for resending an LSA.
Authentication Mode Indicates the authentication mode towards packets in an OSPF

area.
l NONE: indicates none-authentication.
authentication.
precedence.

Simple Password Specifies the area authentication password.

Simple.

Cipher.

MD5.

MD5.

key.
HMAC-MD5.

HMAC-MD5.


key.
HMAC-SHA256.

HMAC-SHA256.
Step 6 Click OK.
If the new virtual link is displayed on the page, the operation succeeds.
----End
Configuring OSPF Route Aggregation

Route aggregation refers to aggregating the routes that share the same prefix and releasing
only one route to other areas.
Step 3 In the OSPF Process ID:ID navigation tree, choose Advanced Settings > Route Summary.
Step 4 Click Add.
Aggregation Type Indicates the type of route aggregation.

l ABR: indicates that the route aggregation is configured on
the devices locating at the border of an area.
l ASBR: indicates that the route aggregation is configured
for the ASE routes.
Area Indicates the area where the local device to be configured with
the route aggregation resides.
This parameter is available when Summary Type is ABR.
IP Address Configure an aggregated route.
Mask Configure the mask of an aggregated route.
Cost Configure the cost of an aggregated route.
Aggregation Control Do not advertise routes that match the designated IP

address/mask. indicates that the aggregated route is not
advertised.

Tag Tags the aggregated ASEs.

This parameter is available when Summary Type is ASBR.
Step 6 Click OK.

If the new route aggregation configuration is displayed on the page, the operation succeeds.
----End
Prohibiting an Interface from Receiving and Sending OSPF Packets

You can prohibit some interfaces from receiving and sending OSPF packets. This does not
affect the advertisement of directly connected routes, but blocks the Hello packets, reduces
the consumption of system resources, and increases the OSPF network flexibility.
Step 3 In the OSPF Process ID:ID navigation tree, choose Advanced Settings > Passive Interface.
Step 4 Select the interface to be disabled.
Step 5 Click Apply.
----End
Configuring Route Filtering

A router provides a routing information filtering function. By specifying an ACL and an IP
address prefix list, you can configure an ingress or egress filtering policy to filter the received
and released routes.
Step 3 In the OSPF Process ID:ID navigation tree, choose Advanced Settings > Route Filter.
Step 4 Click Add.

Filter Type Indicate the route filter type of the OSPF. After this parameter
is set, it cannot be changed.
l Import: indicates the filtering of the routes calculated by
OSPF. Only the routes that match the filtering rules are
added to the routing table.
l Export: indicates the filtering of the routes imported by
OSPF. Only the routes that match the filtering rules are
advertised.
Route Type Advertise routes based on the route type based filtering.
This parameter is required when the Filter Type is Export.
After this parameter is set, it cannot be changed.
If NONE is selected, OSPF filters all the imported routing
information.
Process ID Specifies the process ID for OSPF, RIP, and ISIS. After this
Filter Mode Indicates the route filter mode. You can configure the mode to
either of the following:
l IP-Prefix: sets a matching rule based on the IP prefix list. It
is used for filtering routes according to the prefixes of
destination IP addresses.
l ACL: sets a matching rule based on the ACL. It is used for
filtering routes according to destination IP addresses.
IP-Prefix Indicates the name of the IP prefix list.

This parameter is required when Filter Mode is IP-Prefix.
ACL Indicates the basic ACL number.

You can select an existed ACL or select Basic ACL to create a
new ACL.
Source Address, Schedule, and Action are available when
Filter Mode is ACL and ACL is Basic ACL.
Source Address Indicates the source IP address for filtering routes or the name
of the source address/address group.
You can select an existed address/address group or create a
new address/address group.
Schedule Indicates the time range during which route filtering takes
effect.
You can select an existed time range or create a new time
range.

Action Indicates the action taken by the device towards the route.
l permit: indicates the action configured by the policy is
performed on the route.
l deny: indicates that the action configured by the policy is
not performed on the route.
Step 6 Click OK.
If the new route filtering policy is displayed on the page, the operation succeeds.
----End
5.6.5 OSPF Configuration Using the CLI

This section describes how to use the command line interface (CLI) to configure OSPF.
5.6.5.1 Establishing the OSPF Neighbor Relationship

To implement OSPF basic functions, enabling OSPF and establishing the OSOF neighbor
relationship including can realize the interconnection of all the nodes in the OSPF network.
5.6.5.1.1 Enabling OSPF

Enabling OSPF is the prerequisite for configuring OSPF.
Context
To ensure the stability of OSPF, you should determine the division of router IDs and manually
configure them when planning the network. When configuring router ID manually, you
should ensure that the router IDs of any two routers in a single AS are different. Generally, the
router ID is configured to be consistent with the IP address of an interface of this router.
The FW supports OSPF multi-processes. When multiple OSPF processes are enabled on a
FW, you must specify different process IDs. OSPF process ID is a local concept, with no
effect on its packet exchange with other routers. Therefore, different FWs can also exchange
packets, even with different process IDs.
Procedure
system-view
Step 2 Run:
ospf [ process-id ] [ router-id router-id ]
OSPF is enabled and the OSPF view is displayed.

The FW supports OSPF multi-instance. To configure OSPF in a VPN instance, run the ospf
[ process-id | router-id router-id | vpn-instance vpn-instance-name ] * command. If the VPN
instance is specified, the OSPF process belongs to the specified instance. Otherwise, the
OSPF process belongs to the global instance.
NOTE
The ID of the OSPF process is unique, including the OSPF multi-instance. That is, the process ID of the
OSPF multi-instance cannot be identical with the previously specified one.
----End
5.6.5.1.2 Configuring the Network Segments Included by Each Area

The interface running OSPF can normally receive and send OSPF packets only when the
network segments included by each area are correctly configured.
Context
Network segments mentioned in this section refer to the network segments where interfaces
running OSPF reside.
A network segment can belong to only one area. In other words, you need to specify an area
for each interface running OSPF.
Most configurations should be based on the area. Wrong configuration may disable
information transmission between the neighboring routers, and even lead to congestion or
self-loop of the routing information.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run:
area area-id
The OSPF area view is displayed.
Step 4 Run:
network ip-address wildcard-mask
The network segments are specified for this area.
OSPF can run on an interface only when the following conditions are satisfied:
l Mask length of the IP address of an interface is not shorter than that in the network
command.

l Master IP address of an interface must belong to the network segment specified by the
network command.
NOTE
The address segment of the MPU management interface GigabitEthernet 0/0/0 cannot be released to the
OSPF area through the network command.
For a loopback interface, by default, OSPF advertises its IP address in 32-bit host route,
regardless of the mask length of the IP address on the interface. To advertise the segment
route of the loopback interface, configure the network type as NBMA or broadcast in the
interface view.
----End
5.6.5.2 Configuring OSPF Areas

Large network scale results in huge LSDB, consuming much storage space and affecting
network performance. You can configure OSPF to divide the AS to different areas to solve
such a problem.
5.6.5.2.1 Configuring OSPF Stub Areas

The stub area is a special area defined by OSPF, which has only one ABR. When an area
meets certain requirements, you can configure it as a stub area. In this case, OSPF routes can
be quickly aggregated and effectively spread.
Context
After area partition, the number of LSAs in the network decreases, and the OSPF extensibility
is enhanced. To reduce its routing table size and the number of LSAs, you can configure some
non-backbone areas on the AS border as stub area.
You must use the stub command to configure the area with Stub functions on the FWs that
are connected to the stub area.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
stub [ no-summary ]

The current area is configured as a stub area.

The parameter in the stub command is valid only when you configure the command on
ABRs.
Step 5 Run:
default-cost cost
The cost of the default routes to the stub area is configured.
The default-cost command can be configured on ABRs only.
----End
5.6.5.2.2 Configuring OSPF NSSA Areas

External routes cannot be imported to the stub area. To import external routes to the OSPF
routing table and still keep other stub area features, the network administrator can configure
the area as the NSSA area.
Context
Stub areas cannot import external routes, thus leading to the concept of NSSA area. In NSSA
area, Type7 LSA transmission is allowed. Originated by ASBR in NSSA area, Type7 LSA is
transformed to AS-External LSA when it reaches the ABR of NSSA, and is further advertised
to other areas.
You must use the nssa command to configure the NSSA area with NSSA attribute on the
routers connected to the NSSA area.
The parameters in the nssa command are valid only when you configure the command on
ABRs.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
nssa [ { default-route-advertise | suppress-default-route } | flush-waiting-timer interval-
value | no-import-route | no-summary | set-n-bit | suppress-forwarding-address |
translator-always | translator-interval interval-value | zero-address-forwarding |
translator-strict ] *

An area is configured as NSSA area.
Step 5 Run:
default-cost cost
The cost of the default routes to the NSSA area is configured.
The default-cost cost command can be configured on ABRs only.
----End
5.6.5.2.3 Configuring OSPF Virtual Links

This describes how to configure a virtual link. Through the configuration, you can establish a
logical channel between non-adjacent areas to satisfy the requirements of OSPF for areas.
Context
After area partition, the OSPF routes between non-backbone areas are updated with the help
of the backbone area. OSPF stipulates that all the non-backbone areas should maintain the
connectivity with the backbone area, and the backbone area should maintain its own
connectivity.
However, in practical applications, the physical connectivity cannot be ensured due to the
network topology restrictions. OSPF virtual link can be configured to solve this problem.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
vlink-peer router-id [ dead dead-interval | hello hello-interval | retransmit retransmit-

interval | smart-discover | trans-delay trans-delay-interval | [ simple [ plain plain-text |
[ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text |
[ cipher ] cipher-text } ] | authentication-null | keychain keychain-name ] ] *
A virtual link is created and configured.
You must configure this command at the peer end of the virtual link.
----End

Follow-up Procedure
After virtual links are created, different default MTUs may be used on devices provided by
different vendors. To ensure consistency, the MTU is set to 0 by default when the interface
sends DD packets. For details, see Configuring the MTU in DD Packets.
5.6.5.3 Controlling OSPF Routing Information

Changing OSPF routing policy through the configuration of routing information can meet the
requirements in complicated networks. In addition, the advertising and receiving of OSPF
routing information can be controlled and the routes of other protocols can be imported.
5.6.5.3.1 Configuring ABR Route Aggregation

You can configure the ABR route aggregation to convert the routes with the same prefix to
one Type-3 LSA on the ABR and send it to other areas.
Context
You can choose whether to advertise the aggregated route, and configure the cost of the
aggregated Link State Advertisement (LSA).
This command is applicable only to ABRs and is used for the route aggregation in an area.
The ABR transmits only an aggregated route to other areas. Route aggregation refers to that
the ABR can aggregate routes with the same prefix, and send only one route to other areas.
You can configure multiple network segments in an area. OSPF can thus aggregate multiple
network segments.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF view is displayed.
Step 3 Run:
area area-id
Step 4 Run:
abr-summary ip-address mask [ cost { cost | inherit-minimum } | [ advertise [ generate-
null0-route ] | not-advertise | generate-null0-route [ advertise ] ] ] *
ABR route aggregation of OSPF is configured.
This command is valid for ABRs only.
----End

5.6.5.3.2 Configuring ASBR Route Aggregation

You can configure the ASBR route aggregation to convert the routes with the same prefix to
one route on the ASBR and send the route to other ASs.
Context
You can choose whether to advertise the aggregated route, and set the cost of the aggregated
route. When a lot of routes are imported, users can set the delay for advertising aggregated
routes. In this way, the aggregated route information advertised each time contains more valid
routes and the incorrect routing information caused by network flapping is avoided.
The command can be configured in the Autonomous System Border Router (ASBR). The
command is used to aggregate the imported external routers in the aggregation address range.
If the area is NSSA area, this command can also be configured on the ABR. ABR aggregates
the LSA that is switched from Type-7 to Type-5.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
asbr-summary ip-address mask [ [ not-advertise | generate-null0-route ] | tag tag | cost
cost | distribute-delay interval ] *
ASBR route aggregation of OSPF is configured.
This command is valid for ASBRs only.
not-advertise: Indicates that the aggregated route is not advertised. If the parameter is not
specified, the aggregated route is advertised.
distribute-delay: Specifies the delay for advertising the summarized route.
----End
5.6.5.3.3 Configuring OSPF to Filter Routes Received by OSPF

By configuring filtering conditions for the received routes, you can allow only the routes that
meet the filtering conditions to be added to the routing table.
Context
OSPF is a dynamic routing protocol based on the link state, and routing information is hidden
in the link state. Therefore, the filter-policy import command cannot be used to filter the
advertised and received LSAs. You can then run the filter-policy import command to filter
the routes calculated by OSPF. Only the routes that match the filtering rules are added to the
routing table.

The filter-policy import command is used to filter only the routes that match OSPF and are
installed to the local routing table. Routes that do not pass the filtering are neither added to the
OSPF routing table nor advertised. Therefore, whether the received routes pass the filtering or
not, the LSDB is not affected.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
filter-policy { acl-number | ip-prefix ip-prefix-name | route-policy route-policy-name
[ secondary ] } import
Routing filtering function is configured to filter the routes received.
----End
5.6.5.3.4 Configuring OSPF to Filter ABR Type3 LSA

Filtering LSAs in an area can prevent unnecessary LSA transmission. This reduces the size of
the LSDB on the neighboring router and speeds up network convergence.
Context
After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Summary LSAs)
in an area, only the Type 3 LSAs that meet the filtering conditions can be received or
advertised.
NOTE
This function is applicable only to the ABR.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id

Step 4 Run:
filter { acl-number | ip-prefix ip-prefix-name | route-policy route-policy-name } { export |

import }
The rule of filtering Type3 LSAs originated by the ABR is configured.
----End
5.6.5.3.5 Configuring OSPF to Import Routes of Other Protocols

If both OSPF and other routing protocols run on the router, you can configure OSPF to import
routes generated by other protocols such as RIP, ISIS, BGP, static routes, and direct routes,
and then advertise these routes through Type5 LSA or Type7 LSA.
Context
OSPF can ensure loop-free intra-area routes and inter-area routes; however, OSPF cannot
prevent external routes from loops. Therefore, you should be cautious when configuring
OSPF to import external routes.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
import-route { limit limit-number | { bgp [ permit-ibgp ] | direct | unr | rip [ process-id-

rip ] | static | isis [ process-id-isis ] | ospf [ process-id-ospf ] } [ cost cost | type type | tag tag |
route-policy route-policy-name ] * }
Routes of other protocols are imported.
Step 4 (Optional)Run:
filter-policy { acl-number | ip-prefix ip-prefix-name | route-policy route-policy-name }

export [ direct | static | unr | bgp | { rip | isis | ospf } [ process-id ] ]
The routes imported in 3 are filtered.
Only the routes that pass the filtering can be advertised.
You can configure OSPF to filter the routing information of a protocol or a process by
specifying the parameter direct, static, unr, bgp, rip [ process-id ], isis [ process-id ], ospf
[ process-id ]. If direct, static, unr, bgp, rip [ process-id ], isis [ process-id ], ospf [ process-
id ] is not specified, OSPF filters all the imported routing information.

NOTE
l The import-route command cannot be used to import the default routes of external routes.
l OSPF filters the imported routes; that is, OSPF transforms only eligible external routes to Type5
LSAs and advertises them.
----End
5.6.5.3.6 Configuring OSPF to Import a Default Route

The default route is widely applied on the OSPF network to reduce routing entries in the
routing table and filter specific routing information.
Context
If the default route is imported to the OSPF routing domain and an OSPF router within it is
configured with a static default route, you need to set the precedence of static default route
lower than that of the imported default route. Otherwise, the default route may not be assigned
the highest priority in the routing table.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
default-route-advertise [ [ always | permit-calculate-other ] | cost cost | type type | route-

policy route-policy-name [ match-any ] ] *
Default routes are imported to OSPF processes.
When always is selected, you can import a default route to OSPF forcibly; otherwise, the
routes can be imported only when local default routes exist.
To advertise Type-3 summary LSA of the specified default route, run:
default-route-advertise summary cost cost
When summary is selected, you must first enable VPN; otherwise, the route cannot be
aggregated.
----End
5.6.5.3.7 Configuring the Related Parameters for OSPF to Import Routes

In certain cases, when OSPF imports external routes, the default values of certain additional
parameters should be added.

Context
When OSPF imports external routes, you can configure the default values for some additional
parameters, such as the cost, number of routes, tag, and type. The route tag is used to tag the
protocol related information. For example, it is used to differentiate the number of the ASs
when OSPF receives BGP.
By default, the metric of the external routes imported by OSPF is 1; a maximum of
2147483647 routes can be imported each time; the type of the imported external routes is
Type 2; the default tag value of the imported routes is 1.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
default { cost { cost | inherit-metric } | limit limit | tag tag | type type } *
The default values are configured for parameters related to importing routes (cost, number of
routes, tag, and type).
NOTE
You can run one of the following commands to set the cost of the imported route. The following
commands are listed in the descending order of priorities.
l Run the import-route (OSPF) command to set the cost of the imported route.
l Run the default command to set the default cost of the imported route.
----End
5.6.5.4 Configuring OSPF Route Selection

This section describes how to configure OSPF route selection.
5.6.5.4.1 Configuring the Cost of OSPF Interfaces

You can specify the cost of an OSPF link by configuring the cost of an OSPF interface.
Context
To configure the cost of an OSPF link, you can directly configure the cost of an OSPF
interface.
If you do not set the cost of the OSPF interface directly, OSPF calculates the cost according to
the bandwidth of the interface. The calculation formula is as follows: cost of the interface =
bandwidth reference value/interface bandwidth. The integer of the calculated result is the cost

of the interface. If the result is smaller than 1, the cost value is 1. You can indirectly change
the cost of the interface by changing the bandwidth reference value.
Procedure
system-view
Step 2 Run:
Step 3 Run:
ospf cost value
The cost of OSPF interfaces is configured.
----End
5.6.5.4.2 Configuring the Maximum Number of Equal-Cost Routes

The configuration of the maximum number of equal-cost routes affects the load balancing of
such routes.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
----End
5.6.5.4.3 Configuring the OSPF Priority

When multiple routing protocols are used to select routes, you can set the OSPF priority to
maneuver route selection.
Context
Multiple dynamic routing protocol may run on a router at the same time. Thus, there is the
problem of routing information sharing and routing selection among routing protocols. The

system sets the priority for each routing protocol. When different protocols detect the same
route, the route with a higher priority is selected.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
preference [ ase ] { preference | route-policy route-policy-name } *
A protocol priority of OSPF is configured.
----End
5.6.5.4.4 Configuring the Priority for OSPF Equal-Cost Routes

By configuring the priority for OSPF equal-cost routes, you can select the route of high
priority as the next hop.
Context
The nexthop command selects the next hop with the highest priority from the equal-cost
routes calculated by OSPF. The smaller the weight is, the higher the routing priority is. By
default, the weight value is 255, indicating that load is balanced between the equal-cost
routes.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
nexthop ip-address weight value
The priority for load balancing of OSPF is configured.
----End

5.6.5.5 Configuring OSPF Network Types

OSPF classifies networks into several types according to link-layer protocols. The network
type should be correctly configured to prevent the fault that OSPF packets cannot be
transmitted normally.
5.6.5.5.1 Configuring Network Types of OSPF Interfaces

OSPF classifies networks into four types according to link layer protocols. By configuring
network types for interfaces, you can change the network types of interfaces.
Context
By default, the network type of an interface is determined by the physical interface. The
network type of Ethernet interface is broadcast, that of the serial interface and POS interface
(encapsulated with PPP or HDLC) is p2p, and that of ATM interface and Frame-relay
interface is nbma.
Procedure
system-view
Step 2 Run:
Step 3 Run:
ospf network-type { broadcast | nbma | p2mp | p2p [ peer-ip-ignore ] }
A network type is configured for the OSPF interface.
After a new network type is configured for the interface, the original network type is
automatically replaced.
NOTE
Generally, the network types of two OSPF interfaces on the both ends of the link must be identical.
Otherwise, the two interfaces cannot set up the neighbor relationship. Only when the network type of
one OSPF interface is broadcast and the network type of the other OSPF interface is P2P, the two
interfaces can still set up the neighbor relationship. The broadcast interface can learn the correct OSPF
routing information, but the P2P interface cannot learn the OSPF routing information from the peer.
----End
5.6.5.5.2 Configuring Neighbors for NBMA Networks

The NBMA network cannot discover neighboring routers through Hello packets. Therefore,
you need to manually set the IP address of the neighboring router and specify the election
priority to establish the neighbor relationship.

Context
For NBMA networks, if there are no directly reachable links between two routers, you can
configure the interface type to P2MP. If the router in NBMA networks has only one peer, you
can change the interface type to P2P.
Some special configurations are needed for NBMA networks. Because a router cannot detect
neighbor routers by broadcasting hello packets, you must manually configure the IP addresses
of its adjacent routers for this interface and their election rights.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
peer ip-address [ dr-priority priority ]
A neighbor is configured for the NBMA network.
----End
5.6.5.5.3 Configuring DR Priorities of OSPF Interfaces

On both broadcast and NBMA networks, you can configure the DR priorities of OSPF
interfaces to impact the DR/BDR election. In common cases, the router with high
performance and reliability is selected as the DR/BDR.
Context
When configuring broadcast networks or NBMA networks, you can specify the DR priority
for each interface to affect the DR/BDR election in the network. The greater the value is, the
higher the priority is.
By default, the priority of the interface that candidates for the DR is 1.
Procedure
system-view
Step 2 Run:

Step 3 Run:
ospf dr-priority priority
DR priorities are set for OSPF interfaces.
After the DR priority is changed, you can re-elect a DR or BDR through the following
methods, which, however, will result in the interruption of the OSPF neighbor relationship
between routers and therefore are used only when necessary.
l Restarting all routers.
l Running the shutdown and undo shutdown commands on the interface on which the
OSPF neighbor relationship is set up.
----End
5.6.5.6 Optimizing OSPF Networks

In certain special network environments, you need to configure certain features of OSPF. The
performance of OSPF networks need to be optimized.
5.6.5.6.1 Configuring OSPF Packet Timer

By changing the OSPF packet timer, you can adjust the convergence speed of the OSPF
network and the network overload caused by protocol packets.
Context
NOTICE
l Both Hello and Dead timer are restored to the default settings after the network type is
changed.
l It is necessary to keep the consistency of the Hello timers between OSPF neighbors.
l Note that the value of the Hello timer is inversely proportional to route convergence speed
and network load.
l For the same interface, the dead time should be at least four times as long as the interval of
Hello packets.
l Do not set the LSA retransmission interval too small. Otherwise, unnecessary
retransmission may be caused. It must be greater than the time for a packet to be
transmitted a round between two routers.
Procedure
system-view
Step 2 Run:
interface interface-type { interface-number | interface-number.subinterface-number }


Step 3 Run:
ospf timer hello interval
The interval for sending Hello packets on the interface is configured.
Step 4 Run:
ospf timer poll interval
The interval for sending Poll packets on the NBMA interface is configured.
Step 5 Run:
ospf timer dead interval
The dead time during which the adjacent relationship is invalid is configured.
Step 6 Run:
ospf timer retransmit interval
The interval for re-transmitting LSAs between the adjacent routers is configured.
After a router sends an LSA to its neighbor, it waits for the acknowledgement packet from its
neighbor. If no acknowledgement packet is received from its neighbor in the retransmission
interval, it retransmits the LSA.
----End
5.6.5.6.2 Configuring the Delay for Transmitting LSAs on the Interface

You can set the delay for transmitting LSAs on the interface according to the link rate.
Context
It takes time to transmit OSPF packets on a link; therefore, the delay is added to the aging
time of the LSAs before transmission.
By default, the delay is 1 second.
NOTICE
On low-speed links, you should focus on this configuration.
Procedure
system-view
Step 2 Run:

Step 3 Run:
ospf trans-delay interval
The delay of transmitting LSAs on the interface is set.
----End
5.6.5.6.3 Configuring the Interval for Updating LSA

To promote the route aggregation rate on the network, you can configure the interval for
updating LSAs as required.
Context
Complied with the OSPF protocol, the LSA update interval is five seconds. This prevents the
flapping of network connection or routes from occupying too much bandwidth and resource.
In a stable network or a network that requires fast routing aggregation, you can set the LSA
update interval to 0. Thus, once the topology or routes change, the change can be advertised to
the network through LSA immediately. The speed of route aggregation on the network is
increased.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
lsa-originate-interval { 0 | intelligent-timer max-interval start-interval hold-interval

[ other-type interval ] | other-type interval [ intelligent-timer max-interval start-interval
hold-interval ] }
The interval for updating the LSA is set.
By default, the intelligent timer is enabled. The interval for updating LSAs is expressed in
milliseconds. The maximum interval is 5000 milliseconds (ms), the initial interval is 500 ms,
and the Holdtime interval is 1000 ms. After an intelligent timer is enabled, the interval for
updating LSAs is as follows:
1. The initial interval for updating LSAs is specified by the parameter start-interval.
2. The interval for updating LSAs for the nth (n≥2) time is equal to hold-interval * 2(n-1).
3. When the interval specified by hold-interval * 2(n-1) reaches the maximum interval
specified by max-interval, OSPF updates LSAs at the maximum interval for three

consecutive times. Then, go back to Step 3.a, and OSPF updates LSAs at the initial
interval specified by start-interval.
----End
5.6.5.6.4 Configuring the Interval for Receiving LSA

To make topology changes be sensed immediately, you can configure the interval for
receiving LSA as 0.
Context
In a stable network or a network that requires fast routing aggregation, you can set the LSA
receive interval to 0. Thus, once the topology or routes change, the change can be advertised
immediately. The speed of route aggregation on the network is increased.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
lsa-arrival-interval { interval | intelligent-timer max-interval start-interval hold-interval }
The interval for receiving LSA is set.
By default, the intelligent timer is enabled. The interval for receiving LSAs is expressed in
milliseconds. The maximum interval for receiving LSAs is 1000 ms, the initial interval is 500
ms, and the Holdtime interval is 500 ms. After an intelligent timer is enabled, the interval for
receiving LSAs is as follows:
1. The initial interval for receiving LSAs is specified by the parameter start-interval.
2. The interval for receiving LSAs for the nth (n≥2) time is equal to hold-interval * 2(n-1).
3. When the interval specified by hold-interval * 2(n-1) reaches the maximum interval
specified by max-interval, OSPF receives LSAs at the maximum interval for three
consecutive times. Then, go back to Step 3.a, and OSPF receives LSAs at the initial
interval specified by start-interval.
----End
5.6.5.6.5 Configuring the Interval for SPF Calculation

Through the configuration of the interval for SPF calculation, the influence resulting from
network changes can be restrained.
Context
When the OSPF LSDB changes, the shortest path need be recalculated. Frequent network
changes occupy many system resources and affect the efficiency of routers. You can configure

an intelligent timer and rationally set the interval for the SPF calculation to avoid excessive
router memory and bandwidth resources from being occupied.
Adjusting the SPF calculation interval, however, can restrain the resource consumption due to
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
spf-schedule-interval { interval1 | intelligent-timer max-interval start-interval hold-interval
| millisecond interval2 }
The interval for SPF calculation is set.
By default, the intelligent timer is enabled. The interval for the SPF calculation is expressed
in milliseconds. The maximum interval for the SPF calculation is 10000 ms, the initial
interval is 500 ms, and the Holdtime interval is 1000 ms. After an intelligent timer is enabled,
the interval for the SPF calculation is as follows:
1. The initial interval for the SPF calculation is specified by the parameter start-interval.
2. The interval for the SPF calculation for the nth (n≥2) time is equal to hold-interval ×
2(n-1).
3. When the interval specified by hold-interval × 2(n-1) reaches the maximum interval
specified by max-interval, OSPF performs the SPF calculation at the maximum interval
for three consecutive times. Then, go back to Step 3.a, and OSPF performs the SPF
calculation at the initial interval specified by start-interval.
----End
5.6.5.6.6 Suppressing the Interface from Receiving and Sending OSPF Packets
You can configure the interface so that the receiving and sending of OSPF packets are
prohibited, and thus the networking adaptability of OSPF is enhanced and system resource
consumption is reduced.
Context
To prevent OSPF routing information from being acquired by the routers on a certain
network, and prevent the local router from receiving the route updates advertised by other
routers, use the silent-interface command to suppress the interface from receiving and
sending OSPF packets.
Different processes can suppress the same interface from sending and receiving OSPF
packets, but the silent-interface command is valid only for the OSPF interface on which the
specified process has been enabled, and has no effect on the interface of other processes.

After an OSPF interface is set to be in silent status, the interface can still advertise its direct
route. However, the Hello packets of the interface are blocked, and no neighbor relationship
can be established on the interface. Hence, the OSPF capability to adapt to the networking is
enhanced, which in turn reduces the consumption of system resources.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
silent-interface { all | interface-type interface-number }
The interface is suppressed from receiving and sending OSPF packets.
----End
5.6.5.6.7 Configuring Stub Router

You can configure the stub router to inform other OSPF routers that they cannot use the stub
router to forward data.
Context
Stub router is used to control the traffic. It informs other OSPF routers on the network not to
use it as a transit point, but still route to it.
Among the Router LSAs generated by the Stub router, all the metric of links are set equal to
or larger than 65535.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
stub-router [ on-startup [ interval ] ]
A Stub router is configured.

NOTICE
Stub router has nothing to do with the stub area.
----End
5.6.5.6.8 Configuring the MTU in DD Packets

This describes how to configure the interface to fill in the Interface MTU field of the DD
packets with the actual MTU value when the interface sends DD packets. By default, the
MTU field of DD packets adopts 0.
Context
Generally, an interface replaces the actual MTU value with 0 when sending DD packets. After
this command is configured, the interface fills in the Interface MTU field of the DD packets
with the actual MTU value.
NOTICE
After the MTU value in a DD packet is configured, the neighbor relationship is reestablished.
Procedure
system-view
Step 2 Run:
Step 3 Run:
ospf mtu-enable
The interface is enabled to fill in the MTU value in a DD packet when sending the DD
packets.
----End
5.6.5.6.9 Configuring the Maximum Number of External LSAs in the LSDB

By setting the maximum number of external LSAs in the LSDB, you can restrict the number
of routes within a proper range.

Context
NOTE
The configuration must be consistent in the entire AS.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
lsdb-overflow-limit number
The maximum number of external LSAs in LSDB is configured.
----End
5.6.5.6.10 Configuring RFC1583 Compatible External Routing

Because RFC2328 and RFC1583 adopt different route selection rules, you can configure the
external route selection rules that are compatible with RFC1583.
Context
RFC 2328 and RFC 1583 define the route selection rule differently. After OSPF is enabled on
the FW, specify a route selection rule based on the FW configuration. The FW complies with
the route selection rule defined in RFC 1583 by default. If the neighboring device complies
with the route selection rule defined in RFC 2328, configure the local FW to comply with that
defined in RFC 2328. This allows all devices in the OSPF area to comply with the same route
selection rule.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
undo rfc1583 compatible
The FW is configured to comply with the route selection rule defined in RFC 2328, not RFC
1583.

By default, the FW complies with route selection rule defined in RFC 1583.
----End
5.6.5.7 Improving OSPF Network Security

If an OSPF network requires high security, you can configure an OSPF authentication mode
to improve network security.
5.6.5.7.1 Configuring the Authentication Mode

OSPF supports packet authentication. Only the packets that pass the authentication can be
received. If packets fail to pass the authentication, the neighbor relationship cannot be
established.
Context
In area authentication, all the routers in an area must use the same area authentication mode
and password. For example, the authentication mode of all devices in Area 0 is simple
authentication and the password is abc.
The interface authentication mode is used among neighbor routers to set the authentication
mode and password. Its priority is higher than that of the area authentication mode.
NOTE
By default, authentication is not configured for OSPF area or interface. Configuring area authentication
is recommended to ensure system security.
Procedure
l Configuring the Area Authentication Mode
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
area area-id

d. Run the following commands to configure the authentication mode of the OSPF
area as required:
n Run:
authentication-mode simple [ plain plain-text | [ cipher ] cipher-
text ]
The simple authentication is configured for the OSPF area.

n Run:
authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ]
The MD5, HMAC-MD5 or HMAC-SHA256 authentication is configured for

the OSPF area.

All the routers in an area must agree on the same area authentication mode and
password. For example, the authentication mode of all routers in area 0 is
simple authentication, and the password is abc.
n Run:
authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF area.

NOTE
Before using the Keychain authentication, you must run the keychain command to
create a keychain. Then, run the key-id, key-string, and algorithm commands to
configure a key ID, a password, and an authentication algorithm for this keychain.
Otherwise, the OSPF authentication will fail.
l Configuring the Interface Authentication Mode
a. Run:
system-view

b. Run:

c. Run the following commands to configure the interface authentication mode as
required:
n Run:
ospf authentication-mode simple [ plain plain-text | [ cipher ]
cipher-text ]
The simple authentication is configured for the OSPF interface.

n Run:
ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ]
The MD5, HMAC-MD5 or HMAC-SHA256 authentication is configured for

the OSPF interface.
n Run:
ospf authentication-mode null
The non-authentication mode is configured for the OSPF interface.

n Run:
ospf authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF interface.

NOTE
Before using the Keychain authentication, you must run the keychain command to
create a keychain. Then, run the key-id, key-string, and algorithm commands to
configure a key ID, a password, and an authentication algorithm for this keychain.
Otherwise, the OSPF authentication will fail.
The authentication mode and password of interfaces in the same network segment
must be consistent except the Keychain authentication mode. If the interfaces are in
different network segments, the authentication mode and password of the interfaces
can be different.
----End

5.6.5.8 Enhancing OSPF Network Reliability

Configuring OSPF GR and BFD for OSPF improves OSPF network convergence and
enhances OSPF reliability.
5.6.5.8.1 Configuring OSPF GR

This section describes how to configure OSPF GR to avoid traffic interruption and route
flapping caused by the active/standby switchover.
Prerequisites
Before configuring OSPF GR, complete the following tasks:
l Configuring IP addresses for interfaces to ensure that neighboring routers are reachable
at the network layer.
l Establishing the OSPF Neighbor Relationship.
Context
To avoid traffic interruption and route flapping caused by the active/standby switchover, you
can enable OSPF GR.
After the OSPF process is restarted through Graceful Restart (GR), the Restarter and the
Helper reestablish the neighbor relationship, exchange routing information, synchronize the
LSDB, and update the routing table and forwarding table. These operations ensure the fast
convergence of OSPF and the stability the network topology.
NOTE
In practical applications, you can configure OSPF GR on the dual main control boards to avoid service
forwarding from being affected by the fault occurred on the main control board.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
opaque-capability enable
The opaque-LSA function is enabled.

Opaque LSAs provide a generic mechanism for OSPF extension:
l OSPF supports GR using Type 9 LSAs.
l OSPF supports TE using Type 10 LSAs.
Before configuring OSPF GR, you must enable opaque LSA capability running the opaque-
capability enable command.

NOTE
When enabling or disabling the opaque LSA function, OSPF process will go down in order to
renegotiate the new capability, which means that the traffic will be affected for few seconds.
Step 4 Run:
graceful-restart
The OSPF GR feature is enabled.
After the graceful-restart command is run to enable GR for a FW, the Helper function is also
enabled.
Step 5 Run:
graceful-restart [ period period | planned-only | partial ] *
The GR session parameters are set.
l Set period, the GR period on the Restarter is set. By default, the restart time is 120
seconds.
l Set planned-only, the Restarter supports only the planned GR. By default, the Restarter
supports both the planned GR and unplanned GR.
l Set partial, the Restarter supports the partial GR. By default, the Restarter supports the
totally GR.
Step 6 Configure GR Session Parameters on the Helper.

1. Run:
graceful-restart [ period period | partial | planned-only ] * helper-role { ip-prefix ip-

prefix-name | acl-number acl-number }
The local router can enter the Helper mode only after neighbors pass the filtering policies
of ip-prefix or acl.
2. Run:
graceful-restart [ period period | partial | planned-only ] * helper-role ignore-

external-lsa
The Helper does not check the LSAs outside the AS (AS-external LSA).
By default, the Helper checks the LSAs outside the AS.

3. Run:
graceful-restart [ period period | partial | planned-only ] * helper-role planned-only
The Helper supports only the planned GR.
By default, the Helper supports both the planned GR and unplanned GR.
NOTE
To configure multiple parameters at the same time, run the graceful-restart [ period period |
partial | planned-only ] * helper-role { { { ip-prefix ip-prefix-name | acl-number acl-number } |
ignore-external-lsa | planned-only } * | never } command.
----End

5.6.5.8.2 Configuring BFD for OSPF

After BFD for OSPF is enabled, when a link fails, the device rapidly detects the failure,
notifies the OSPF process or interface of the fault, and instructs OSPF to recalculate routes.
This speeds up OSPF network convergence.
Prerequisites
Before configuring BFD for OSPF, complete the following task:
l Configuring IP addresses for interfaces to ensure that neighboring routers are reachable
at the network layer.
l Establishing the OSPF Neighbor Relationship.
Context
After BFD for OSPF is configured, when detecting a link fault, BFD rapidly notifies the
routers on both ends of the link of the fault, triggering rapid OSPF convergence. When the
OSPF neighbor relationship goes Down, the BFD session will be dynamically deleted.
Before configuring BFD for OSPF, enable BFD globally.
Perform the following steps on the FWs between which a BFD session is to be created.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is globally configured.

Step 3 Run:
quit

Step 4 Run:
ospf [ process-id ]

Step 5 Run:
BFD for OSPF is configured. The default parameter values are used to create a BFD session.
If all the interfaces in a certain process are configured with BFD and their neighbor
relationships are in the Full state, OSPF creates BFD sessions with default parameter values
on all the interfaces in the process.
bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } *

BFD session parameters are modified.
You can skip this step. The default interval at which BFD packets are transmitted and the
default detection multiplier are recommended.
The parameters are configured based on the network status and network reliability
requirements. A short interval at which BFD packets are transmitted can be configured for a
link that has a higher requirement for reliability. A long interval at which BFD packets are
transmitted can be configured for a link that has a lower requirement for reliability.
NOTE
l Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
l Actual interval at which BFD packets are received on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the peer router, configured interval receive-
interval at which BFD packets are received on the local router }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
l On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the
configured interval at which BFD packets are received is 300 ms; the detection multiplier is 4.
l On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval
at which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
l On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by
using the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms
calculated by using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by
multiplying 300 ms by 5.
l On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by
using the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600
ms calculated by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms
calculated by multiplying 600 ms by 4.
Step 7 (Optional) Prevent an interface from dynamically creating a BFD session.
After BFD for OSPF is configured, all interfaces on which neighbor relationships are Full in
the OSPF process will create BFD sessions. To prevent specific interfaces from being enabled
with BFD, disable these interfaces from dynamically creating BFD sessions.
1. Run:
quit

2. Run:

3. Run:
ospf bfd block
An interface is prevented from dynamically creating a BFD session.
----End

5.6.5.9 Configuring the Network Management Function of OSPF

OSPF supports the network management function. You can bind the OSPF MIB to a certain
OSPF process, and configure the trap function and log function.
5.6.5.9.1 Configuring OSPF MIB Binding

The MIB is a virtual database of the device status maintained by the managed devices.
Context
When multiple OSPF processes are enabled, you can configure OSPF MIB to select the
process to be processed, that is, configure OSPF MIB to select the process to which it is
bound.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf mib-binding process-id
OSPF MIB binding is configured.
----End
5.6.5.9.2 Configuring OSPF Trap

Traps are the notifications sent from a router to inform the NMS of the fault detected by the
system.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name ospf [ trap-name
{ hwospfv2intraareadripaddressconflict | hwospfv2intraarearouteridconflict |
ospfifauthfailure | ospfifconfigerror | ospfifrxbadpacket | ospfifstatechange |
ospflsdbapproachingoverflow | ospflsdboverflow | ospfmaxagelsa |
ospfnbrrestarthelperstatuschange | ospfnbrstatechange |
ospfnssatranslatorstatuschange | ospforiginatelsa | ospfrestartstatuschange |
ospftxretransmit | ospfvirtifauthfailure | ospfvirtifconfigerror |
ospfvirtifrxbadpacket | ospfvirtifstatechange | ospfvirtiftxretransmit |
ospfvirtnbrrestarthelperstatuschange | ospfvirtnbrstatechange } ]
The trap function for the OSPF module is enabled.
To enable the traps of one or more events, you can specify type-name.
----End

5.6.5.9.3 Configuring OSPF Log

You can configure the OSPF log function to record OSPF configurations and error
information.
Procedure
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
enable log [ config | error | state | snmp-trap ]
The log function is enabled.
----End
5.6.6 Maintaining OSPF

Maintaining OSPF involves resetting OSPF and clearing OSPF statistics.
Clearing OSPF
NOTICE
OSPF information cannot be restored after being cleared. Exercise caution when running this
command.
After confirming the running information about the OSPF statistics, run the following
commands in the user view.
Table 5-40 Commands used for clearing OSPF
Action Command
Clear OSPF counters reset ospf [ process-id ] counters [ neighbor [ interface-type

interface-number ] [ router-id ] ]
Clear the routes reset ospf [ process-id ] redistribution

imported by OSPF

Resetting OSPF
Table 5-41 Commands used for resetting OSPF

Action Command
Restart the OSPF reset ospf process

process NOTE
After the reset ospf process command is used to restart OSPF, the
following situations may occur:
l If the router ID is changed, a new router ID will take affect after the
reset ospf process command is run.
l Re-elect DR and BDR after the reset ospf process command is run.
Clear invalid LSAs reset ospf process flush-waiting-timer time

within the set time
before LSAs time out
Restart the OSPF reset ospf [ process-id ] process [ graceful-restart ]

process in GR mode

This provides the configuration examples of OSPF networkings.
5.6.7.1 CLI Example for Configuring Basic OSPF Functions

You can divide OSPF backbone and non-backbone areas to reduce the number of LSAs on the
network and enhance the scalability of OSPF networks.
NOTE
This configuration example covers only OSPF-related configuration commands.
As shown in Figure 5-45, all the FWs run OSPF, and the whole Autonomous System (AS) is
divided into three areas. The FW_A and FW_B serve as ABRs to forward the routes between
these areas.
After the configuration, each FWcan learn the routes from AS to all network segments.

Figure 5-45 Networking of OSPF basic functions configuration
Area0
GE1/0/0
GE2/0/0 192.168.0.2/24 GE2/0/0
192.168.1.1/24 192.168.2.1/24
GE1/0/0
FW_A 192.168.0.1/24 FW_B
GE1/0/0 GE2/0/0
Area1 Area2
192.168.1.2/24 192.168.2.2/24
FW_C FW_D
GE3/0/0 GE3/0/0
172.16.1.1/24 172.17.1.1/24
1. Enabling OSPF on each FWand specifying the network segment in different area
2. Checking the routing list and database information
Data Preparation
l The router ID of the FW_A is 1.1.1.1. the OSPF process number is 1. Network segment
192.168.0.0 is specified in Area 0, and network segment 192.168.1.0 is specified in Area
1.
l The router ID of the FW_B is 2.2.2.2. the OSPF process number is 1. Network segment
2.
l The router ID of the FW_C is 3.3.3.3. the OSPF process number is 1. Network segment
192.168.1.0 and 172.16.1.0 are specified in Area 1.
l The router ID of the FW_D is 4.4.4.4. the OSPF process number is 1. Network segment
192.168.2.0 and 172.17.1.0. are specified in Area 2.
Procedure
security policy. (Omitted)
Step 2 Configure basic OSPF functions on the FW_A.
# Enter the system view.
<FW_A> system-view

# Set the router ID for the FW_A to 1.1.1.1.

# Enable OSPF on the FW_A.

[FW_A] ospf
# Set the area where network segment 192.168.0.0 resides as area 0.

# Return to the OSPF view.



Step 3 Configure basic OSPF functions on the FW_B.

<FW_B> system-view
# Set the router ID for the FW_B to 2.2.2.2.

# Enable OSPF on the FW_B.

[FW_B] ospf




Step 4 Configure basic OSPF functions on the FW_C.

<FW_C> system-view
# Set the router ID for the FW_C to 3.3.3.3.

[FW_C] router id 3.3.3.3
# Enable OSPF on the FW_C.

[FW_C] ospf
# Set the area where network segment192.168.1.0 and 172.16.1.0 reside as area 1.

Step 5 Configure basic OSPF functions on the FW_D.

<FW_D> system-view
# Set the route ID for the FW_D to 4.4.4.4.

[FW_D] router id 4.4.4.4
# Enable OSPF on the FW_D.

[FW_D] ospf
# Set the area where network segment 192.168.2.0 and 172.17.1.0 reside as area 2.
[FW_D-ospf-1] area 2
[FW_D-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255

[FW_D-ospf-1-area-0.0.0.2] quit

# Display OSPF neighbors of the FW_A.
[FW_A] display ospf peer
OSPF Process 1 with Router ID 1.1.1.1

Neighbors
Area 0.0.0.0 interface 192.168.0.1(GigabitEthernet1/0/0)'s neighbors

Router ID: 2.2.2.2 Address: 192.168.0.2 GR State: Normal
State: Full Mode:Nbr is Master Priority: 1
DR: None BDR: None MTU: 0
Dead timer due in 36 sec
Neighbor is up for 00:15:04
Authentication Sequence: [ 0 ]
Neighbors

State: Full Mode:Nbr is Slave Priority: 1
DR: None BDR: None MTU: 0
# Display the OSPF routing information of the FW_A.

[FW_A] display ospf routing

Routing Tables

Routing for Network

Destination Cost Type NextHop AdvRouter Area
172.16.1.0/24 2 Stub 192.168.1.2 3.3.3.3 0.0.0.1
172.17.1.0/24 3 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Transit 192.168.0.1 1.1.1.1 0.0.0.0
Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# Display LSDB of the FW_A.

[FW_A] display ospf lsdb

Link State Data Base
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 317 48 80000003 1
Router 1.1.1.1 1.1.1.1 316 48 80000003 1
Sum-Net 172.16.1.0 1.1.1.1 250 28 80000002 2
Sum-Net 172.17.1.0 2.2.2.2 203 28 80000002 2
Sum-Net 192.168.2.0 2.2.2.2 237 28 80000003 1
Sum-Net 192.168.1.0 1.1.1.1 295 28 80000003 1
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 3.3.3.3 3.3.3.3 217 60 80000006 1
Router 1.1.1.1 1.1.1.1 289 48 80000003 1
Sum-Net 172.17.1.0 1.1.1.1 202 28 80000002 3
Sum-Net 192.168.2.0 1.1.1.1 242 28 80000002 2
Sum-Net 192.168.0.0 1.1.1.1 300 28 80000002 1
# Display the routing table of the FW_D and test the connectivity by using the ping
command.
[FW_D] display ospf routing

Routing Tables
Routing for Network

172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Stub 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Transit 192.168.2.2 4.4.4.4 0.0.0.2
Total Nets: 5
[FW_D] ping 172.16.1.1
PING 172.16.1.1: 56 data bytes, press CTRL_C to break
--- 172.16.1.1 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 16/59/94 ms
----End

l Configuration script of FW_A
#
sysname FW_A
#
router id 1.1.1.1
#
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
security-policy
source-zone local
source-zone trust
action permit
source-zone trust
action permit
#
return
l Configuration script of FW_B

#
sysname FW_B
#
router id 2.2.2.2
#
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
security-policy
source-zone local
source-zone trust
action permit
source-zone trust
action permit
#
return

l Configuration script of FW_C

#
sysname FW_C
#
router id 3.3.3.3
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
security-policy
source-zone local
source-zone trust
action permit
source-zone trust
action permit
#
return
l Configuration script of FW_D

#
sysname FW_D
#
router id 4.4.4.4
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
security-policy
source-zone local
source-zone trust
action permit
source-zone trust
action permit
#
return

5.6.7.2 CLI Example for Configuring OSPF NSSA Areas

To import external routes to the OSPF routing table and still keep other stub area features, the
network administrator can configure the area as the NSSA area.
As shown in Figure 5-46, all the FWs run OSPF, and the whole AS is divided into three
areas. The FW_A and FW_B serve as ABRs to forward the routes between these areas. The
FW_D serves as ASBR to import external routes (static routes).
Configure Area 1 as an NSSA area and configure the FW_C as ASBR to import external
routes (static routes). The routing information can be transmitted correctly inside the AS.
Figure 5-46 Networking of OSPF NSSA areas configuration
Area0
GE1/0/0
GE2/0/0 192.168.0.2/24 GE2/0/0
192.168.1.1/24 GE1/0/0 192.168.2.1/24
FW_A 192.168.0.1/24 FW_B
GE1/0/0 GE2/0/0
192.168.1.2/24 192.168.2.2/24
Area1
NSSA FW_C FW_D
GE3/0/0
GE3/0/0
172.17.1.1/24
172.16.1.1/24
Area2
ASBR
1. Enabling OSPF on each FW and configuring the basic OSPF function

2. Configuring the static route on the FW_D and importing it into OSPF
3. Configuring Area 1 as the NSSA area and checking the OSPF routing information of the
FW_C
4. Configuring the static route on the FW_C and importing it into OSPF
5. Checking the OSPF routing information of the FW_D
Data Preparation

l The router ID of the FW_A is 1.1.1.1. the OSPF process number is 1. Network segment
1.
l The router ID of the FW_B is 2.2.2.2. the OSPF process number is 1. Network segment
2.
l The router ID of the FW_C is 3.3.3.3. the OSPF process number is 1. Network segment
192.168.1.0 and 172.16.1.0 are specified in Area 1.
l The router ID of the FW_D is 4.4.4.4. the OSPF process number is 1. Network segment
192.168.2.0 and 172.17.1.0. are specified in Area 2.
Procedure
Step 2 Configure basic OSPF functions (see 5.6.7.1 CLI Example for Configuring Basic OSPF
Functions).
Step 3 Configure the FW_D to import static routes.
<FW_D> system-view
# Set the destination address and outbound interface of the static route to 200.0.0.0 and null0.
[FW_D] ip route-static 200.0.0.0 8 null 0

[FW_D] ospf
# Specify a static route as the route of Type-1.

[FW_D-ospf-1] import-route static type 1
# Return to the system view.

[FW_D-ospf-1] quit
Step 4 Configure Area 1 as an NSSA area.

# Configure the FW_A and enter the system view.
<FW_A> system-view

[FW_A] ospf
# Configure Area 1 as an NSSA area.

[FW_A-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary
# Return to the system view.

[FW_A-ospf-1] quit

[FW_C] ospf

# Configure Area1 as an NSSA area.

[FW_C-ospf-1-area-0.0.0.1] nssa
NOTE
It is recommended to configure the ABR (refers to the FW_A here) with the default-route-advertise no-
summary parameter, thus reducing the size of the routing table of the NSSA router. Other NSSA routers only
need to be configured with the nssa command.
# Display the OSPF routing table of the FW_C.

[FW_C] display ospf routing
Routing Tables
Routing for Network

0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
172.16.1.0/24 1 Stub 172.16.1.1 3.3.3.3 0.0.0.1
192.168.1.0/24 1 Transit 192.168.1.2 3.3.3.3 0.0.0.1
Total Nets: 3
NOTE
When the area where the FW_C is located is configured as a nssa area, you see a default route rather
than external routes.
Step 5 Configure the FW_C to import the static route.
# Configure the static route.

[FW_C] ip route-static 100.0.0.0 8 null 0

[FW_C] ospf
# Import the static route.

[FW_C-ospf-1] import-route static
[FW_C-ospf-1] quit
# Display the OSPF routing table of the FW_D.

[FW_D] display ospf routing

Routing Tables
Routing for Network

172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Stub 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Transit 192.168.2.2 4.4.4.4 0.0.0.2
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
100.0.0.0/8 1 Type2 1 192.168.2.1 1.1.1.1
Total Nets: 6

You can see an external route imported by the NSSA area on the FW_D.
----End
#
sysname FW_A
#
router id 1.1.1.1
#
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
nssa default-route-advertise no-summary
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone trust
destination-zone
local
action permit
rule name
policy_sec_2
source-zone
trust
action permit
#
return

#
sysname FW_B
#
router id 2.2.2.2
#
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#

security-
policy
rule name
policy_sec_1
source-zone
local
source-zone trust
destination-zone
local
action permit
rule name
policy_sec_2
source-zone
trust
action permit
#
return
l Configuration script of FW_C
#
sysname FW_C
#
router id 3.3.3.3
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
ospf 1
import-route static
area 0.0.0.1
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
ip route-static 100.0.0.0 255.0.0.0 NULL0
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone trust
destination-zone
local
action permit
rule name
policy_sec_2
source-zone
trust
action permit
#
return
l Configuration script of FW_D
#
sysname FW_D
#
router id 4.4.4.4
#

undo shutdown
ip address 192.168.2.2 255.255.255.0
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
ospf 1
import-route static type 1
area 0.0.0.2
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
ip route-static 200.0.0.0 255.0.0.0 NULL0
#
security-
policy
rule name
policy_sec_1
source-zone
local
source-zone trust
destination-zone
local
action permit
rule name
policy_sec_2
source-zone
trust
action permit
#
return
5.6.7.3 CLI Example for Configuring OSPF Virtual Links

In certain cases, the direct physical connection between a backbone area and a non-backbone
area can hardly be realized. In this case, you can configure OSPF virtual links for the ABR
that is not directly connected to the backbone area.
As shown in Figure 5-47, Area 2 does not connect with the backbone area directly. Area 1
serves as a transit area to connect Area 2 and Area 0. A virtual link is configured between the
FW_A and the FW_B.
Figure 5-47 Networking of OSPF virtual link configuration
Area1
FW_A FW_B
GE1/0/0 GE1/0/0
192.168.1.1/24 192.168.1.2/24
GE2/0/0 GE2/0/0
10.1.1.1/8 172.16.1.1/16
Virtual
Area0 Link
Area2

1. Configuring basic OSPF functions on each FW
2. Configuring the virtual connections on the FW_A and the FW_B to connect the
backbone area with the non-backbone
Data Preparation
l The OSPF router ID of the FW_A is 1.1.1.1. The number of its area is Area 0 and Area
1. Network segments 192.168.1.0 and 10.0.0.0 are configured with OSPF.
l The OSPF router ID of the FW_B is 2.2.2.2. The number of its area is Area 1 and Area
2. Network segments 192.168.1.0 and 172.16.0.0 are configured with OSPF.
Procedure
<FW_A> system-view
# Enable OSPF on the FW_A and set the router ID for the FW_A to 1.1.1.1.
[FW_A] ospf 1 router-id 1.1.1.1
# Configure network segment 10.0.0.0 as Area 0.


# Configure network 192.168.1.0 as Area 1.


# Configure the FW_B and enter the system view.

<FW_B> system-view
# Enable OSPF on the FW_B and set the router ID for the FW_B to 2.2.2.2.
[FW_B] ospf 1 router-id 2.2.2.2




# Display the OSPF routing table of the FW_A.

<FW_A> display ospf routing

Routing Tables
Routing for Network

10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
NOTE
Area 2 does not connect directly to Area 0. Thus, there is no Area 2 route in the routing table of the
FW_A.
Step 3 Configure the virtual link.

<FW_A> system-view

[FW_A] ospf
# Configure a virtual link with the peer router ID 2.2.2.2.

[FW_A-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2


<FW_B> system-view

[FW_B] ospf
# Configure a virtual link with the peer router ID 1.1.1.1.

[FW_B-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1

# Display the OSPF routing table of the FW_A.

[FW_A] display ospf routing


Routing Tables
Routing for Network

172.16.1.1/32 2 Inter-area 192.168.1.2 2.2.2.2 0.0.0.0
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
----End
#
sysname FW_A
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
undo shutdown
ip address 10.1.1.1 255.0.0.0
#
firewall zone trust
set priority 85
#
set priority 5
#
ospf 1 router-id 1.1.1.1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 2.2.2.2
#
return

#
sysname FW_B
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.0.0
#
firewall zone trust
set priority 85
#
set priority 5
#
ospf 1 router-id 2.2.2.2
area 0.0.0.1
network 192.168.1.0 0.0.0.255

vlink-peer 1.1.1.1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return
5.6.7.4 CLI Example for Configuring DR Election of OSPF

On both broadcast and non-broadcast networks, you can configure the DR priorities of OSPF
interfaces to impact the DR/BDR election. In common cases, the router with high
performance and reliability is selected as the DR/BDR.
As shown in Figure 5-48, with the highest priority 100 in the network, the FW_A is elected
as DR. With the second highest priority, the FW_C is elected as BDR. The priority of the
FW_B is 0, so the FW_B cannot be elected as DR. The priority of the FW_D is not
configured and its default value is 1.
Figure 5-48 Networking of DR election configuration of OSPF

FW_A FW_B
GE1/0/0 GE1/0/0
192.168.1.1/24 192.168.1.2/24
GE1/0/0 GE1/0/0
192.168.1.3/24 192.168.1.4/24
FW_C FW_D
1. Configuring the router ID on each FW and enabling OSPF on the specified network
segment
2. Checking the DR/BDR state of each FW when the default priority is used
3. Configuring the DR priority on the interface and checking the DR/BDR state
Data Preparation
l The router ID of the FW_A is 1.1.1.1 and the DR priority is 100.
l The router ID of the FW_B is 2.2.2.2 and the DR priority is 0.

l The router ID of the FW_C is 3.3.3.3 and the DR priority is 2.

l The router ID of the FW_D is 4.4.4.4 and the DR priority is 1.
Procedure
Step 2 Enable OSPF.
<FW_A> system-view
# Set the router ID for the FW_A to 1.1.1.1.


[FW_A] ospf


<FW_B> system-view
# Set the router ID for the FW_B to 2.2.2.2.


[FW_B] ospf

# Configure the FW_C and enter the system view.

<FW_C> system-view
# Set the router ID for the FW_C to 3.3.3.3.

[FW_C] router id 3.3.3.3

[FW_C] ospf

# Configure the FW_D and enter the system view.

<FW_D> system-view
# Set the router ID for the FW_D to 4.4.4.4.

[FW_D] router id 4.4.4.4


[FW_D] ospf

[FW_D-ospf-1] area 0
# Display the state of DR/BDR.

[FW_A] display ospf peer
Neighbors

State: 2-Way Mode:Nbr is Master Priority: 1
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
# Check the neighbor information of the FW_A, you will find the priority of DR and the
neighbor status. Now the FW_D is DR, and the FW_C is BDR.
Step 3 Configure DR priorities on the interfaces.
<FW_A> system-view
# Enter the interface view.

# Set the priority of GE1/0/0 to 100 when electing the DR.

[FW_A-GigabitEthernet1/0/0] ospf dr-priority 100

<FW_B> system-view


[FW_B-GigabitEthernet1/0/0] ospf dr-priority 0
# Configure the FW_C and enter the system view.

<FW_C> system-view


[FW_C-GigabitEthernet1/0/0] ospf dr-priority 2
# Display the states of DR and BDR.

<FW_D> display ospf peer

Neighbors

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
NOTE
The DR priorities configured on the interfaces do not take effect instantly.
Step 4 Restart OSPF processes.

In the user view of each FW, run the reset ospf 1 process command to restart the OSPF
process.
# Display the states of OSPF neighbors.
<FW_D> display ospf peer

Neighbors

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

State: 2-Way Mode:Nbr is Master Priority: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0



DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
# Display the state of the OSPF interface.

<FW_A> display ospf interface

Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
# Display the state of the OSPF interface.

<FW_B> display ospf interface

Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
If all neighbors are in Full state, it indicates that the FW_A forms neighboring relationships
with all its neighbors. If the neighbor stays "2-Way", it indicates neither of them are DR or
BDR. Thus, they need not to exchange LSAs.
All other neighbors are DR Others. This indicates that they are neither DR nor BDR.
----End
5.6.7.5 CLI Example for Configuring OSPF Load Balancing

When there are several paths of the same cost to one destination, you can configure the load
balancing of equal-cost routes. In this way, load balancing is implemented on these links, thus
improving the link usage.
As shown in Figure 5-49:
1. FW_A, FW_B, FW_C, FW_D, and FW_E are interconnected to each other through
OSPF
2. FW_A, FW_B, FW_C, FW_D, and FW_E belong to Area 0.
3. Load balancing is required to transmit the traffic of FW_A to FW_E through FW_C and
FW_D.

Figure 5-49 Networking diagram of configuring OSPF load balancing
Area0
GE1/0/0 GE2/0/0
vRouter_B
GE1/0/0 GE1/0/0
GE2/0/0 GE2/0/0 GE4/0/0
GE4/0/0 GE1/0/0 GE2/0/0
GE3/0/0 FW_C GE3/0/0
vRouter_A vRouter_E
GE1/0/0 GE2/0/0
vRouter_D
Device Interface IP Address Device Interface IP Address
FW_A POS1/0/0 10.1.1.1/24 FW_C POS1/0/0 10.1.2.2/24
POS2/0/0 10.1.2.1/24 POS2/0/0 192.168.1.1/

24
POS3/0/0 10.1.3.1/24 FW_D POS1/0/0 10.1.3.2/24
GE4/0/0 172.16.1.1./ POS2/0/0 192.168.2.1/

24 24
FW_B POS1/0/0 10.1.1.2/24 FW_E POS1/0/0 192.168.0.2/

24
POS2/0/0 192.168.0.1/ POS2/0/0 192.168.1.2/

24 24
POS3/0/0 192.168.2.2/
24
GE4/0/0 172.17.1.1/2
4
1. Enable basic OSPF functions on each FW.

2. Configure load balancing on FW_A.
3. Configure the priority for equal-cost routes on FW_A.

Data Preparation
l For FW_A, the router ID is 1.1.1.1, the OSPF process number is 1, and the network
segment of Area 0 is 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, and 172.16.1.0/24.
l For FW_B, the router ID is 2.2.2.2, the OSPF process number is 1, and the network
segment of Area 0 is 10.1.1.0/8 and 192.168.0.0/8.
l For FW_C, the router ID is 3.3.3.3, the OSPF process number is 1, and the network
l For FW_D, the router ID is 4.4.4.4, the OSPF process number is 1, and the network
l For FW_E, the router ID is 5.5.5.5, the OSPF process number is 1, and the network
segment of Area 0 is 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, and 172.17.1.0/24.
l The number of load balancing paths on FW_A is 2.
l The weight values of the next hop routes from FW_A to FW_B, FW_C, and FW_D are
2, 1, and 1 respectively.
Procedure
Step 2 Configure basic OSPF functions. The configuration details are not mentioned here.
Step 3 View the routing table of FW_A.

As displayed in the routing table, FW_A has three valid next hops: 10.1.1.2 (FW_B), 10.1.2.2
(FW_C), and 10.1.3.2 (FW_D). This is because the default maximum number of equal-cost
routes is 6.
----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
OSPF 10 3 D 10.1.3.2 Pos3/0/0
NOTE
The maximum number of equal-cost routes varies with products and protocols.
Step 4 Configure a maximum of two routes on FW_A to perform load balancing.

[FW_A] ospf 1
[FW_A-ospf-1] maximum load-balancing 2
[FW_A-ospf-1] quit

# View the routing table of FW_A. As shown in the routing table, FW_A has only two valid
next hops, 10.1.1.2 (FW_B) and 10.1.2.2 (FW_C). This is because the maximum number of
equal-cost routes is set to 2.
----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
Step 5 Configure the priority for equal-cost routes on FW_A.

[FW_A] ospf 1
[FW_A-ospf-1] nexthop 10.1.1.2 weight 2
[FW_A-ospf-1] quit
# View the OSPF routing table of FW_A.

----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.2.2 Pos2/0/0
OSPF 10 3 D 10.1.3.2 Pos3/0/0
As shown in the display, the priority of the route with the next hops being 10.1.2.2 and
10.1.3.2 is higher than that of the route with the next hop being 10.1.1.2. Thus, FW_A has
only two valid next hops, 10.1.2.2 (FW_C) and 10.1.3.2 (FW_D).
----End

This section provides reference information about OSPF.
This section describes the specifications of OSPF.

Area partition - Supported by all models.
Stub area Allows type 3 default routes Supported by all models.

released by the ABR, but
not routes outside the
autonomous system.
Totally stub area Allows type 3 default routes Supported by all models.
released by the ABR, but
not routes outside the
autonomous system or
between areas.
Not-So-Stubby Area - Supported by all models.

(NSSA)
Multiprocessing - Supported by all models.
Multi-instance - Supported by all models.
OSPF running on point-to- - Supported by all models.

point networks
OSPF running on broadcast - Supported by all models.

networks
OSPF packet encryption Supports simple Supported by all models.

authentication authentication and MD5
authentication.
Virtual link Is a logical connection Supported by all models.

between non-adjacent area
border routers (ABRs) to
connect areas to backbone
areas or provide link
redundancy.
Route summarization Summarizes routes with the Supported by all models.

same prefix into a single
route and advertises only the
summarized route to other
areas.Route summarization
reduces the size of a routing
table and improves router
performance.
Using routing policies to ACLs and prefix lists can be Supported by all models.
filter routes used to filter OSPF routes.
Importing external routes Imports direct, static, OSPF, Supported by all models.
and BGP routes to the OSPF
routing table.

Importing default routes into - Supported by all models.

the OSPF routing table as
autonomy system-external
(ASE) routes
Adjusting the priorities of - Supported by all models.

routes in OSPF domains
Adjusting the priorities of - Supported by all models.

routes outside OSPF
domains
Standard MIB - Supported by all models.
Supported interface types GE interfaces and Supported by all models.

subinterfaces, POS
interfaces and subinterfaces,
Eth-Trunk interfaces and
subinterfaces, loopback
interfaces, tunnel interfaces,
VLANIF interfaces, and IP
unnumbered interfaces
Sham-Hello packets When a router cannot Supported by all models.

receive Hello packets
because its neighbor router
is in Exchange, Loading, or
Full state, the router
continues to maintain the
neighbor relationship when
receiving such packets as
Update packets to enhance
network stability.
Automatically calculating If no cost value is Supported by all models.

interface cost values configured for an OSPF
interface, OSPF
automatically calculates a
cost for it using the
following formula (The
integer part of the
calculation result is the
interface cost. If the result is
smaller than 1, the interface
cost is 1.): Interface cost =
Bandwidth reference value/
Interface bandwidth

Opaque LSA (Type9) Opaque LSAs provide a Supported by all models.

generalized mechanism to
allow for the future
extensibility of OSPF. Type
9 LSAs are transmitted
within the subnet where the
interface resides. Grace
LSAs used to support GR
are type 9 LSAs.
OSPF running between PEs - Supported by all models.

and CEs
OSPF backbone areas - Supported by all models.

connecting PEs and CEs
Multi-VPN-instance CE - Supported by all models.
Determining the preferred - Supported by all models.

next hop in equal-cost routes
based on weights
No mask check for Allows neglecting the masks Supported by all models.
neighbors on point-to- in Hello packets when
multipoint networks establishing OSPF neighbor
relationships on point-to-
multipoint networks to
enhance network flexibility.
Using timers to control the Reduces external route Supported by all models.
calculation of external routes calculation workload to
enhance system efficiency.
Releasing host routes Generates host links for Supported by all models.
loopback interfaces to
release host routes, but not
subnet routes.
Serving as stub routers - Supported by all models.
LSDB overflow - Supported by all models.
Allows filling the interface Filling the interface MTU Supported by all models.
MTU field in DD packets. field in DD packets leads to
the reestablishment of
Total number of processes per device 100

Number of areas per process 50
Number of neighbors 128
Number of interfaces in each area 128

This section describes the versions and changes in the OSPF feature.

This section provides OSPF standards and protocols.
The OSPF standards and protocols are as follows:
l RFC 2328: OSPF Version 2

l RFC 1850: OSPF Version 2 Management Information Base
l RFC 1587: The OSPF NSSA Option
l RFC 2370: The OSPF Opaque LSA Option
l RFC 3137: OSPF Stub Router Advertisement
l RFC 1765: OSPF Database Overflow
5.7 OSPFv3
By building Open Shortest Path First Version 3 (OSPFv3) networks, you can enable OSPFv3
to discover and calculate routes in ASs. OSPFv3 is applicable to a large-scale network that
consists of hundreds of routers.
5.7.1 Overview
OSPF version 3 (OSPFv3) is a routing protocol based on link status. Compared with distance
vector-based routing protocols, OSPFv3 delivers a higher convergence rate and supports
larger networks.
Definition
OSPF is an interior gateway protocol developed by the Internet Engineering Task Force
(IETF) on the basis of link status.
OSPFv2 (OSPF version 2) applies to IPv4, and OSPF version 3 to IPv6.

l OSPFv3 is an OSPF routing protocol running on IPv6 (see RFC 2740).

l OSPFv3 is the enhanced version of OSPFv2 and is an independent routing protocol.
Objective
OSPFv3 is a routing protocol independent of all specific network layers. To achieve the goal,
OSPFv3 router information is re-designed.
The differences between OSPFv3 and OSPFv2 are as follows:
l OSPFv3 does not insert IP address-based data in packet headers in data packets and link-
state advertisements (LSAs).
l OSPFv3 utilizes information independent of network protocols to carry out key tasks
that originally require the header data of an IP packet. The tasks include identifying and
advertising LSAs that contain routing data.
5.7.2 Mechanism
This section describes OSPFv3 mechanism.
5.7.2.1 Principle of OSPFv3
Running on IPv6, OSPFv3 (defined in RFC 2740) is an independent routing protocol whose
functions are enhanced on the basis of OSPFv2.
l OSPFv3 and OSPFv2 are the same in respect of the working principles of the Hello
message, state machine, link-state database (LSDB), flooding, and route calculation.
l OSPFv3 divides an Autonomous System (AS) into one or more logical areas and
advertises routes through LSAs.
l OSPFv3 achieves unity of routing information by exchanging OSPFv3 packets between
routers within an OSPFv3 area.
l OSPFv3 packets are encapsulated into IPv6 packets, which can be transmitted in unicast
or multicast mode.
Formats of OSPFv3 Packets
Table 5-42 Formats of OSPFv3 Packets

Packet Type Description
Hello message Hello messages are sent regularly to discover and maintain
OSPFv3 neighbor relationships.
Database Description A DD packet contains the summary of the local LSDB. It is

(DD) packet exchanged between two OSPFv3 routers to update the LSDBs.
Link State Request LSR packets are sent to the neighbor to request the required
(LSR) packet LSAs.
An OSPFv3 router sends LSR packets to its neighbor only
after they exchange DD packets.

Packet Type Description
Link State Update (LSU) The LSU packet is used to transmit required LSAs to the
packet neighbor.
Link State The LSAck packet is used to acknowledge the received LSA
Acknowledgment packets.
(LSAck) packet
LSA Type
Table 5-43 LSA Type
LSA Type Description
Router-LSA(Type1) Generated by a router for each area to which an OSPFv3

interface belongs, the router LSA describes the status and costs
of links of the router and is advertised in the area where the
OSPFv3 interface belongs.
Network-LSA(Type2) Generated by a designated router (DR), the network LSA

describes the link status and is broadcast in the area that the
DR belongs to.
Inter-Area-Prefix- Generated on the area border router (ABR), an inter-area prefix

LSA(Type3) LSA describes the route of a certain network segment within
the local area and is used to inform other areas of the route.
Inter-Area-Router- Generated on the ABR, an inter-area router LSA describes the

LSA(Type4) route to the autonomous system boundary router (ASBR) and
is advertised to all related areas except the area that the ASBR
belongs to.
AS-external-LSA(Type5) Generated on the ASBR, the AS-external LSA describes the

route to a destination outside the AS and is advertised to all
areas except the stub area and NSSA area.
NSSA-LSA (Type7) Describes routes to a destination outside the AS. It is generated

by an ASBR and advertised in NSSAs only.
Link-LSA(Type8) Each router generates a link LSA for each link. A link LSA
describes the link-local address and IPv6 address prefix
associated with the link and the link option set in the network
LSA. It is transmitted only on the link.
Intra-Area-Prefix- Each router or DR generates one or more intra-area prefix

LSA(Type9) LSAs and transmits it in the local area.
l An LSA generated on a router describes the IPv6 address
prefix associated with the router LSA.
l An LSA generated on a DR describes the IPv6 address
prefix associated with the network LSA.

Router Type
Figure 5-50 Router type

ISIS ASBR
Area4
Area1
Backbone Router
Internal Router Area0
Area2
Area3
ABR
Table 5-44 Router types and descriptions

Router Type Description
Internal router All interfaces on an internal router belong to the same OSPFv3
area.
Area border router An ABR can belong to two or more areas, but one of the areas
(ABR) must be a backbone area.
An ABR is used to connect the backbone area and the non-
backbone areas. It can be physically or logically connected to
the backbone area.
Backbone router At least one interface on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0, therefore, are
backbone routers.
AS boundary router A router that exchanges routing information with other ASs is
(ASBR) called an ASBR.
An ASBR may not locate on the boundary of an AS. It can be
an internal router or an ABR. If an OSPFv3 router imports the
external routing information, the router is an ASBR.
OSPFv3 Route Type

Inter-area routes and intra-area routes describe the network structure of an AS. External routes
describe how to select a route to the destination outside an AS. OSPFv3 classifies the
imported AS external routes into Type 1 routes and Type 2 routes.
Table 5-45 lists route types in a descending order of priority.

Table 5-45 Types of OSPFv3 routes

Route Type Description
Intra Area Intra-area routes
Inter Area Inter-area routes
Type1 external routes Because of the high reliability of Type 1 external routes, the
calculated cost of external routes is equal to that of AS internal
routes, and can be compared with the cost of OSPFv3 routes.
That is, the cost of a Type1 external route equals the cost of the
route from the router to the corresponding ASBR plus the cost
of the route from the ASBR to the destination address.
Type2 external routes Because of the low reliability of Type2 external routes, the cost
of the route from the ASBR to a destination outside the AS is
considered far greater than the cost of any internal path to an
ASBR.
Therefore, OSPFv3 only takes the cost of the route from the
ASBR to a destination outside the AS into account when
calculating route costs. That is, the cost of a Type2 external
route equals the cost of the route from the ASBR to the
destination of the route.
Area
When a large number of routers run OSPFv3, link state databases (LSDBs) become very large
and require a large amount of storage space. Large LSDBs also complicate shortest path first
(SPF) computation and are computationally intensive for the routers. Network expansion
causes the network topology to change, which results in route flapping and frequent OSPFv3
packet transmission. When a large number of OSPFv3 packets are transmitted on the network,
bandwidth usage efficiency decreases. Each change in the network topology causes all routers
on the network to recalculate routes.
OSPFv3 resolves this problem by partitioning an AS into different areas. An area is regarded
as a logical group, and each group is identified by an area ID. A router, not a link, resides at
the border of an area. A network segment or link can belong only to one area. An area must be
specified for each OSPFv3 interface.
OSPFv3 areas include common areas, stub areas, and not-so-stubby areas (NSSAs), as
described in Table 5-46.

Table 5-46 OSPF areas

Area Type Description Notes
Common By default, OSPFv3 areas are defined l The backbone area must
area as common areas. Common areas have all its devices
include: connected.
l Standard area: transmits intra-area, l All non-backbone areas must
inter-area, and external routes. remain connected to the
l Backbone area: connects to all other backbone area.
OSPFv3 areas and transmits inter-
area routes. The backbone area is
represented by area 0. Routes
between non-backbone areas must
be forwarded through the backbone
area.
Stub area A stub area is a non-backbone area with l The backbone area cannot be
only one ABR and generally resides at configured as a stub area.
the border of an AS. The area border l An autonomous system
router (ABR) in a stub area does not boundary router (ASBR)
transmit received AS external routes, cannot exist in a stub area.
which significantly decreases the Therefore, AS external
number of entries in the routing table routes cannot be advertised
on the ABR and the amount of routing within the stub area.
information to be transmitted. To
ensure the reachability of AS external l A virtual link cannot pass
routes, the ABR in the stub area through a stub area.
generates a default route and advertises
the route to non-ABRs in the stub area.
A totally stub area allows only intra-
area routes and ABR-advertised Type 3
link state advertisements (LSAs)
carrying a default route to be advertised
within the area.
NSSA An NSSA is similar to a stub area. An l ABRs in an NSSA advertise

NSSA does not advertise Type 5 LSAs Type 3 LSAs carrying a
but can import AS external routes. default route within the
ASBRs in an NSSA generate Type 7 NSSA. All inter-area routes
LSAs to carry the information about the are advertised by ABRs.
AS external routes. The Type 7 LSAs l A virtual link cannot pass
are advertised only within the NSSA. through an NSSA.
When the Type 7 LSAs reach an ABR
in the NSSA, the ABR translates the
Type 7 LSAs into Type 5 LSAs and
floods them to the entire AS.
A totally NSSA area allows only intra-
area routes to be advertised within the
area.

Network Types Supported by OSPFv3

OSPFv3 classifies networks into the following types according to link layer protocols.
Table 5-47 Types of OSPFv3 networks
Network Type Description
Broadcast If the link layer protocol is Ethernet or FDDI, OSPFv3 defaults

the network type to broadcast.
In this type of networks, the following situations occur:
l Hello messages, LSU packets, and LSAck packets are
transmitted in multicast mode (FF02::5 is the reserved IPv6
multicast address of the OSPFv3 router; FF02::6 is the
reserved IPv6 multicast address of the OSPFv3 DR or
BDR).
l DD packets and LSR packets are transmitted in unicast
mode.
Non-broadcast Multiple If the link layer protocol is frame relay, ATM, or X.25, OSPFv3
Access (NBMA) defaults the network type to NBMA.
In this type of networks, protocol packets such as Hello
messages, DD packets, LSR packets, LSU packets, and LSAck
packets, are transmitted in unicast mode.
Point-to-Multipoint Regardless of the link layer protocol, OSPFv3 does not default
(P2MP) the network type to P2MP. A P2MP network must be forcibly
changed from other network types. The common practice is to
change a non-fully connected NBMA to a P2MP network.
In this type of networks, the following situations occur:
l Hello messages are transmitted in multicast mode with the
multicast address as FF02::5.
l Other protocol packets, including DD packets, LSR packets,
LSU packets, and LSAck packets, are transmitted in unicast
mode.
Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPFv3
defaults the network type to P2P.
In this type of network, the protocol packets, including Hello
messages, DD packets, LSR packets, LSU packets, and LSAck
packets, are transmitted to the multicast address FF02::5.
OSPFv3 Route Aggregation

Routing information can be decreased after route aggregation so that the size of routing tables
is reduced, which improves the performance of routers.
The procedure for OSPFv3 route aggregation is as follows:
l Route summarization on an ABR

An ABR can summarize routes with the same prefix into one route and advertise the
summarized route in other areas.
When sending routing information to other areas, an ABR generates Type 3 LSAs based
on IPv6 prefixes. If consecutive IPv6 prefixes exist in an area and route summarization is
enabled on the ABR of the area, the IPv6 prefixes can be summarized into one prefix. If
there are multiple LSAs that have the same prefix, the ABR summarizes these LSAs and
advertises only one summarized LSA. The ABR does not advertise any specific LSAs.
l Route summarization on an ASBR
An ASBR can summarize imported routes with the same prefix into one route and then
advertise the summarized route to other areas.
After being enabled with route summarization, an ASBR summarizes imported Type 5
LSAs within the summarized address range. After route summarization, the ASBR does
not generate a separate Type 5 LSA for each specific prefix within the configured range.
Instead, the ASBR generates a Type 5 LSA for only the summarized prefix. In an NSSA,
an ASBR summarizes multiple imported Type 7 LSAs within the summarized address
range into one Type 7 LSA.
OSPFv3 Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-
backbone area.
l A virtual link must be set up on both ends of the link; otherwise, it does not take effect.
l The transmit area refers to the area that provides an internal route of a non-backbone
area for both the ends of the virtual link.
In actual applications, the physical connectivity between non-backbone areas and the
backbone area cannot be ensured owing to various limitations. To solve this problem, you can
configure OSPFv3 virtual links.
The virtual link is similar to a point-to-point connection between two ABRs. Similar to
physical interfaces, the interfaces on the virtual link can be configured with parameters such
as the hello interval.
Figure 5-51 OSPFv3 virtual link
Area0 Area2
Virtual Link
ABR Area1 ABR
Transit Area
As shown in Figure 5-51, OSPFv3 packets transmitted between two ABRs are only
forwarded by the OSPFv3 devices that reside between the two ABRs. The OSPFv3 devices
detect that they are not the destinations of the packets, so they forward the packets as common
IP packets.

OSPFv3 Multi-process
OSPFv3 supports multi-process. More than one OSPFv3 process can run on the same router
because processes are independent of each other. Route interaction between different OSPFv3
processes is similar to the route interaction between different routing protocols.
An interface of a router belongs to only a certain OSPFv3 process.
5.7.2.2 OSPFv3 Authentication
In Open Shortest Path First version 3 (OSPFv3) authentication, an authentication field is

added to each OSPFv3 packet for encryption. When a local device receives an OSPFv3 packet
from a remote device, the local device discards the packet if the authentication password
carried in the packet is different from the local one, which protects the local device against
potential attacks. Therefore, OSPFv3 authentication improves network security.
Based on the applicable scope, OSPFv3 authentication is classified as follows:
l Area authentication
This authentication is configured in the OSPFv3 area view and applies to packets
received by all interfaces in an OSPF area.
l Process authentication
This authentication is configured in the OSPFv3 view and applies to all packets in an
OSPF process.
l Interface authentication
This authentication is configured in the interface view and applies to all packets received
by the interface.
Based on the authentication types carried in packets, OSPFv3 authentication is classified as
follows:
A keychain consists of multiple authentication keys, each of which contains an ID and a
password. The keys in the keychain are dynamically selected for authentication based on
the key's lifetime, which enhances attack defense.
Keychain provides authentication for OSPFv3 and improves OSPFv3 security by
dynamically changing authentication algorithms and keys. Keychain can be used to
authenticate OSPFv3 packets and the process of establishing a Transmission Control
Protocol (TCP) connection.
In HMAC-SHA256 authentication, a password is encrypted using the HMAC-SHA256
algorithm before being added to a packet, which improves password security.
Each OSPFv3 packet carries an authentication type in the header and authentication
information in the tail.
The authentication types are as follows:
l 1: explicit authentication
l 2: ciphertext authentication
5.7.2.3 Association between OSPFv3 and BGP

When a new router is deployed in the network or a router is restarted, the network traffic may
be lost during BGP convergence. This is because IGP convergence is quicker than BGP
convergence. This problem can be solved through the association between OSPFv3 and BGP.
If a router on a BGP network recovers from a fault, BGP convergence is performed again and
certain packets may be lost during the convergence.
As shown in Figure 5-52, traffic from RouterA to RouterD traverses a BGP network.
Figure 5-52 Traffic traversing a BGP network
If a fault occurs on RouterC, traffic is redirected to RouterB after rerouting. Packets are lost
when RouterC is restored to the normal status.
Because OSPFv3 convergence is quicker than BGP convergence, OSPFv3 convergence is

complete when RouterC recovers. The next hop of the route from RouterA to RouterD is
RouterC, which, however, does not know the route to RouterD since BGP convergence on
RouterC is not complete.
Therefore, when the packets destined for RouterD are transmitted from RouterA to RouterC,
they are discarded by RouterC because RouterC has no route to RouterD, as shown in Figure
5-53.
Figure 5-53 Packet loss during the restart of the device not enabled with association between
OSPFv3 and BGP

When a router enabled with association between OSPFv3 and BGP restarts, the router
advertises a message in the local OSPFv3 area to instruct other routers not to use it as a transit
router. At the same time, the router sets the largest weight value of 65535 in its LSAs to
ensure that it is not used by other routers as the transit router. The BGP route, however, can
still reach the router.
5.7.2.4 OSPFv3 GR
Graceful restart (GR) is a technology used to ensure normal traffic forwarding when a routing
protocol restarts and guarantee that key services are not affected in the process.
GR is one of the high availability (HA) technologies, which comprise a series of
comprehensive technologies such as fault-tolerant redundancy, link protection, faulty node
recovery, and traffic engineering. As a redundancy technology, GR is widely used to ensure
uninterrupted forwarding of key data in active/standby switchover and system upgrade.
If GR is not enabled, the active/standby switchover occurring owing to various causes leads to
transient interruption of data forwarding, and as a result, route flapping occurs on the whole
network. Such route flapping and service interruption are unacceptable on a large-scale
network, especially on a carrier network.
In GR mode, the forwarding plane continues to direct data forwarding once a restart occurs,
and the actions no the control plane, such as reestablishment of neighbor relationships and
route calculation, do not affect the forwarding plane. In this manner, service interruption
caused by route flapping is prevented so that the network reliability is improved.
Basic Concepts
l Grace LSA
– OSPFv3 supports GR by flooding grace LSAs on the link.
– Grace LSAs are used to inform the neighbor of the GR time, cause, and interface
instance ID when GR starts and ends.
l Router function
– A router can function as a GR restarter.
– A router can function as a GR helper.
l GR implementation
– Planned-GR: This refers to the smooth restart of OSPFv3 through the reset ospfv3
graceful-restart command. In this mode, a grace LSA is sent to the neighbor
before the restart.
– Unplanned-GR: This refers to the active/standby switchover triggered by
commands or the restart or active/standby switchover because of router faults.
Unlike planned-GR, no grace LSA is sent before the active/standby switchover in
unplanned GR mode. Instead, the switchover is directly performed. When the
standby board becomes Up, a grace LSA is sent and the GR process starts. The
following procedure is the same as that of planned GR.

GR Process
Figure 5-54 OSPFv3 planned-GR process (reset ospfv3 graceful-restart)

FW_A FW_B
Restarter Helper
Restarter the
Grace-LSA
OSPFv3 process in
GR mode and enter Enter the Helper state
the GR state
LSAck
Responds to
LSAs with LSAcks
Send Hello packets, negotiate with

neighbors by exchanging DD
packets, and synchronize LSDBs Synchronize LSDBs
FULL with the Restarter
Exit from the GR Exit from the

Flush Grace-LSA
state, recalculate Helper state and
routes, and generate generate
LSAs RouteR-LSAs
Figure 5-55 OSPFv3 unplanned-GR process (active/standby switchover)

FW_A FW_B
Restarter Helper
Grace-LSA
Mster/slave
Switchover is complete Enter the Helper state
LSAck
Responds to
LSAs with LSAcks
Send Hello packets, negotiate with

neighbors by exchanging DD
packets, and synchronize LSDBs Synchronize LSDBs
FULL with the Restarter
Exit from the GR Exit from the

Flush Grace-LSA
state, recalculate Helper state and
routes, and generate generate
LSAs RouteR-LSAs

l On the GR restarter:
a. In planned-GR mode, when OSPFv3 is restarted through commands, the GR
restarter sends a grace LSA to all neighbors to inform them of the start of a GR
process and the period and cause of this process.
In unplanned GR mode, when a restart occurs after active/standby switchover or
owing to other causes other than commands, a grace LSA is sent to each neighbor
immediately after the standby board is Up to inform the neighbors of the start of a
GR process and the period and cause of the process.
b. The GR restarter performs negotiation with neighbors again to set up new neighbor
relationships.
c. When all the neighbor relationships between the GR restarter and the original
neighbors enter the Full state:
n The GR restarter exits from the GR process and OSPFv3 recalculates routes.
n The GR restarter updates the routing table on the main control board and the
FIBs on interface boards and deletes invalid routing entries.
n The GR restarter sends a grace LSA whose aging time is 3600 seconds to
instruct the GR helper to exit from the GR process.
Now, the GR process is complete.
d. If errors occur, the GR timer expires, or the neighbor relationship fails to enter the
Full state during a GR process, the GR restarter exits from the process and OSPFv3
is restarted in non-GR mode. In this case, packets are lost.
l On the GR helper:
a. If a router is configured to support the GR process on its neighbor, the router enters
the helper mode after receiving a grace LSA.
b. The GR helper maintains its neighbor relationship with the GR restarter, and the
status of the neighbor relationship does not change.
c. If the GR helper continues to receive grace LSAs whose GR period is different
from that on the GR helper, the GR helper updates its GR period.
d. Being informed of the successful GR process through a grace LSA whose aging
time is 3600 seconds from the GR restarter, the GR helper exits from the GR
process.
e. If errors occur during a GR process, the GR helper exits from the helper state and
deletes invalid routes after route calculation.

Comparison Between the GR Mode and the Non-GR Mode
Table 5-48 Comparison between the GR mode and the non-GR mode
Active/Standby Switchover in Non-GR Active/Standby Switchover in GR
Mode Mode
l OSPFv3 neighbor relationships are l OSPFv3 neighbor relationships are

reestablished. reestablished.
l Route are recalculated. l Routes are recalculated.
l The forwarding table changes. l The forwarding table remains the same.
l Route changes are sensed on the network l Except the neighbor of the device where
and route flapping occurs over a short the active/standby switchover occurs,
period of time. other routers do not sense the route
l Packets are lost during forwarding, and changes.
services are interrupted. l No packets are lost during forwarding,
and services are not affected.
5.7.2.5 Comparison Between OSPFv3 and OSPFv2
OSPFv3 and OSPFv2 are the same in the following aspects:

l Network type and interface type
l Interface state machine and neighbor state machine
l LSDB
l Flooding mechanism
l Five types of packets, including Hello, DD, LSR, LSU, and LSAck packets
l Route calculation
OSPFv3 and OSPFv2 are different in the following aspects:
l OSPFv3 is based on links rather than network segments.
OSPFv3 runs on IPv6, which is based on links rather than network segments.
Therefore, you need not to configure OSPFv3 on the interfaces in the same network
segment. It is only required that the interfaces enabled with OSPFv3 are on the same
link. In addition, the interfaces can set up OSPFv3 sessions without IPv6 global
addresses.
l OSPFv3 does not depend on IP addresses.
This is to separate topology calculation from IP addresses. That is, OSPFv3 can calculate
the OSPFv3 topology without knowing the IPv6 global address, which only applies to
virtual link interfaces for packet forwarding.
l OSPFv3 packets and LSA format change.
– OSPFv3 packets do not contain IP addresses.
– OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are
advertised by link LSAs and intra-area prefix LSAs.
– In OSPFv3, Router IDs, area IDs, and LSA link state IDs no longer indicate IP
addresses, but the IPv4 address format is still reserved.

– Neighbors are identified by Router IDs instead of IP addresses in broadcast,

NBMA, or P2MP networks.
l Information about the flooding scope is added in LSAs of OSPFv3.
Information about the flooding scope is added in the LSA Type field of LSAs of
OSPFv3. Thus, OSPFv3 routers can process LSAs of unidentified types, which makes
the processing more flexible.
– OSPFv3 can store or flood unidentified packets, whereas OSPFv2 just discards
unidentified packets.
– OSPFv3 floods packets in an OSPF area or on a link. It sets the U flag bit of packets
(the flooding area is based on the link local) so that unidentified packets are stored
or forwarded to the stub area.
For example, FW_A and FW_B can identify LSAs of a certain type. They are connected
through FW_C, which, however, cannot identify this type of LSAs. When FW_A floods
an LSA of this type, FW_C can still flood the received LSA to FW_B although it does
not identify this LSA. FW_B then processes the LSA.
If OSPFv2 is run, FW_C discards the unidentified LSA so that the LSA cannot reach
FW_B.
l OSPFv3 uses IPv6 link-local addresses.
IPv6 implements neighbor discovery and automatic configuration based on link-local
addresses. Routers running IPv6 do not forward IPv6 packets whose destination address
is a link-local address. Those packets can only be exchanged on the same link. The
unicast link-local address starts from FE80/10.
As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to
maintain neighbor relationships and update LSDBs. Except Vlink interfaces, all OSPFv3
interfaces use link-local addresses as the source address and that of the next hop to
transmit OSPFv3 packets.
The advantages are as follows:
– The OSPFv3 can calculate the topology without knowing the global IPv6 addresses
so that topology calculation is not based on IP addresses.
– The packets flooded on a link are not transmitted to other links, which prevents
unnecessary flooding and saves bandwidth.
l OSPFv3 packets do not contain authentication fields.
OSPFv3 directly adopts IPv6 authentication and security measures. Thus, OSPFv3 does
not need to perform authentication. It only focuses on the processing of packets.
l OSPFv3 supports two new LSAs.
– Link LSA: A router floods a link LSA on the link where it resides to advertise its
link-local address and the configured global IPv6 address.
– Intra-area prefix LSA: A router advertises an intra-area prefix LSA in the local
OSPF area to inform the other routers in the area or the network, which can be a
broadcast network or a NBMA network, of its IPv6 global address.
l OSPFv3 identifies neighbors based on router IDs only.
On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on IPv4
addresses of interfaces.
OSPFv3 identifies neighbors based on router IDs only. Thus, even if global IPv6
addresses are not configured or they are configured in different network segments,
OSPFv3 can still establish and maintain neighbor relationships so that topology
calculation is not based on IP addresses.

5.7.3 OSPFv3 Configuration Using the Web UI

This section describes how to use the Web user interface (UI) to configure OSPFv3.
Enabling IPv6
Choose Dashboard > System Information and enable IPv6 globally to allow the FW to
forward IPv6 packets.
Adding an OSPFv3 Process

Step 1 Choose Netwok > Route > OSPF.
Step 2 Click Add.
Table 5-49 OSPF parameters
Type OSPF version:

l OSPF v2: IPv4 OSPF.
l OSPF v3: IPv6 OSPF.
In this example, OSPF v3 is selected.
Process ID ID of an OSPF process. A device supports the OSPFv3 multi-

process. Each OSPFv3 process has a specific ID on a single
device. An OSPFv3 process ID is a local concept. Devices
with different process IDs can exchange packets.
Router ID Router ID for the OSPF process. A router ID is a 32-bit integer

without symbols in the format of an IPv4 address.
The OSPFv3 router ID is manually specified. If no ID is
specified, OSPFv3 cannot run.
The ID of each router in an AS must be unique. If multiple
OSPFv3 processes run on the same router, set a unique router
ID for each process. To ensure OSPFv3 stability, properly plan
and manually set router IDs when planning the network.
SPF Delay Time Delay time after which SPF calculation is performed even
though OSPFv3 receives network change notifications.
Each time the OSPFv3 link state database (LSDB) changes, a
router re-calculates the shortest path, which consumes many
network resources and adversely affects router efficiency. To
address the problems, set the SPF calculation and suppression
time.
SPF Suppression Time Interval between two consecutive SPF calculations.
Internal Priority OSPFv3 route preference value.
ASE Priority AS external route preference value.

Default Route Advertise default routes in an OSPFv3 area. Active default

routes for other OSPFv3 processes must exist in the routing
table of the device.
Specify this parameter before importing default routes to an
OSPFv3 area.
Always Generate and advertise the default route, regardless of whether

active default routes of other OSPFv3 processes exist in the
routing table of the device.
Configure this parameter only when Default Route is selected.
Step 4 Click OK.

If the new OSPFv3 process is displayed, the operation succeeds.
----End
Configuring an OSPFv3 Area

This section describes how to configure an OSPFv3 area. An OSPFv3 area is determined in
the same way as an OSPF area. You can configure a non-backbone area on the edge of an AS
as a stub area to reduce the number of LSAs transmitted over the network and improve
OSPFv3 scalability.
Some OSPFv3 areas are located on the border of an AS and connect to a backbone area.
These OSPFv3 areas use ABRs to exchange routing information with the backbone area.
Configuring the area as a stub area prevents Type 4 and Type 5 routing information from
spreading in the area, which reduces LSDB sizes in the area and improves OSPFv3 network
performance.
Step 2 Click for the OSPFv3 progress to be modified.
Step 3 In the OSPFv3 Process ID:ID navigation tree, choose Basic Configuration > Area Settings.
Step 4 Click Add.
Table 5-50 OSPFv3 process parameters

Area OSPF area identifier.

Area Type OSPF area type:

l Normal: An OSPFv3 area is a common area. Attributes are
not set.
l Stub: An OSPFv3 area is a stub area. The ABR in as stub
area does not advertise ASE routes after receiving them,
which reduces the routing table size and routing
information to be forwarded.
If Area is set to 0.0.0.0, Area Type is set to NONE, but
cannot be set to Stub.
Default Cost Cost of the default routes sent to a stub area using OSPFv3.
This parameter is set when you set Area Type to Stub.
Stub Area Configuration Enable a stub area to be a totally stub area and deny Type 3
LSAs from entering the stub area that connects to the ABR,
which reduces the number of LSAs sent to the stub area.
Configure this parameter when you set Area Type to Stub.
Interface Name of an interface that is enabled with OSPFv3.

OSPFv3 can only be enabled on an IPv6-enabled interface.
Step 6 Click OK.
----End
Configuring an OSPFv3 Interface

NOTE
Web configuration of OSPFv3 on interfaces has the following restrictions:

l Before you run the ipv6 enable command on the interface that needs to run OSPFv3, you must
ensure that an OSPFv3 process has been created in the system view.
l If you need to create an OSPFv3 process and enable OSPFv3 on an interface on which the ipv6
enable command has been executed and no OSPFv3 process has been created in the system view,
you need to run the undo ipv6 enable and ipv6 enable commands in sequence for OSPFv3 to run
properly.
Step 2 Click for the OSPFv3 progress to be modified.
Step 3 In the OSPFv3 Process ID:ID navigation tree, choose Basic Configuration > Interface
Settings.
Step 4 Click Add.

Table 5-51 OSPFv3 parameters

Interface Name Name of an OSPFv3 interface.
Area ID of an OSPFv3 area.
Cost OSPFv3 cost on the interface.
MTU Check Clear the check box to disable the MTU check for DD packets.
If there are a few LSAs, the MTU value is unnecessary to
check; therefore, you can configure to ignore the MTU check
for DD packets to improve performance.
If the MTU values on both ends of a link are different,
configure this parameter to help correctly establish an OSPFv3
neighbor relationship.
Advanced Settings
DR Priority DR priority for the OSPFv3 interface. When the network type
is broadcast or NBMA, set the interface DR priority to affect
the DR/BDR selection on the network.
A larger value allows for a higher DR priority. If the priority
value is set to 0, the interface does not participate in DR
selection.
Transmission Delay Delay time for transmitting LSAs on the interface.

An LSA in the local router LSDB is aging with time (its value
network.
Peer Timeout Neighbor timeout period.

An OSPF neighbor becomes invalid if a local device does not
receive Hello packets from its neighbor after the specified
period of time elapses.
Interfaces on the same network segment must have the same
neighbor timeout period and the same interval at which Hello
packets are sent.
The poll interval or the neighbor timeout interval on a single
interface is at least four times as long as the interval at which
Hello packets are sent.
Hello Packet Interval Interval at which Hello packets are sent.

A shorter interval results in a faster speed in detecting network
topology changes and larger system resource costs.

Retransmission Interval Interval at which an LSA is resent.

If a router sends an LSA to its neighbor router and receives no
confirmation packet after the retransmission interval elapses,
the router resends the LSA.
The interval must be longer than the round-trip time of a
packet between two routers, which prevents unnecessary
retransmissions.
Step 6 Click OK.
----End
Configuring Route Importing for an OSPFv3 Process

If OSPFv3 and other routing protocols run on the router, you can configure OSPFv3 to import
the routes generated by other protocols, and advertise the routing information through LSAs.
Step 2 Click corresponding to the OSPFv3 progress to be modified.
Step 3 In the OSPFv3 Process ID:ID navigation tree, choose Advanced Settings > Route Import.
Step 4 Click Add.

Process ID The routing protocol process number needs to be specified

when the Route Type is set to OSPF v3, RIPng, or ISIS.
Type Indicates the type of an imported route.
Step 6 Click OK.
----End
5.7.4 OSPFv3 Configuration Using the CLI

This section describes how to use a command line interface (CLI) to configure OSPFv3.
5.7.4.1 Establishing OSPFv3 Neighbor Relationships

An OSPFv3 network can be built only after OSPFv3 neighbor relationships are successfully
established among devices.

5.7.4.1.1 Enabling OSPFv3

Enable the OSPFv3 process and specify its router ID before configuring OSPFv3; otherwise,
other functions cannot take effect.
Context
OSPFv3 supports multiple processes. Multiple OSPFv3 processes running on one device are
differentiated by process IDs. OSPFv3 process ID is set when OSPFv3 is enabled and is only
locally valid. It does not affect the packet exchange with other routers.
In the format of an IPv4 address, a router ID is a 32-bit unsigned integer that uniquely
identifies a router within an AS. The router ID of OSPFv3 must be manually set. If no router
ID is set, OSPFv3 fails to run normally.
When manually setting the router ID, ensure that the router IDs of any two devices in an AS
are different. When multiple processes are enabled on a device, it is necessary to specify a
unique route ID for each process.
To ensure the stable running of OSPFv3, you need to allocate router IDs and set them in
network planning.
Procedure
system-view
Step 2 Run:
ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ]
OSPFv3 is enabled and the OSPFv3 view is displayed.
Step 3 Run:
router-id router-id
A router ID is set.
----End
5.7.4.1.2 Enabling OSPFv3 on an Interface

You must enable OSPFv3 and specify the interface and area ID before configuring other
functions. OSPFv3 configurations, however, are independent of interface-related features.
Context
After enabling OSPFv3 in the system view, you need to enable OSPFv3 on the interface.
Procedure
system-view


Step 2 Run:
Step 3 Run:
ospfv3 process-id area area-id [ instance instance-id ]
OSPFv3 is enabled on the interface.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the
IPv4 address format.
NOTE
When the routes to the network of the loopback interface are advertised by using OSPFv3, the prefixes
of the routes are advertised as 128-bit prefixes, regardless of the configured prefix of the loopback
address.
Step 4 Run:
ospfv3 network-type { broadcast | nbma | p2mp [ non-broadcast ] | p2p } [ instance
instance-id ]
The network type is configured of an interface.
When an interface supports multi-instances, you must specify the value of instance-id when
enabling OSPFv3 on the interface. If the value of instance-id is not specified, the default value
0 is adopted. In this case, the configured network type of an interface mismatches the actual
network type of the interface. This step is mandatory in such a case.
----End
5.7.4.1.3 Entering the OSPFv3 Area View

By dividing an AS into different areas, specifying OSPFv3 interfaces, and specifying areas to
which these interfaces belong, OSPFv3 can discover and calculate routes in an AS.
Context
You must configure the devices in the same area based on the area. Otherwise, the neighbor
devices cannot exchange information with each other. The congestion of routing information
or routing loop is therefore caused.
Procedure
system-view
Step 2 Run:

Step 3 Run:
area area-id
The OSPFv3 area view is displayed.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the
IPv4 address format.
An OSPFv3 area cannot be deleted directly. Only after all the configurations in the area view
are removed and the status of the related interfaces in this area become Down, this area is
automatically removed.
----End
5.7.4.2 Configuring OSPFv3 Areas

A large network scale leads to a huge LSDB size, causes routers to consume much storage
space, affects network performance. To prevent these problems, you can configure OSPFv3 to
divide an AS to different areas
5.7.4.2.1 Configuring OSPFv3 Stub Areas

A stub area is a special area in which ABRs do not flood the received AS external routes.
Therefore, the number of LSAs is greatly reduced.
Context
To reduce the number of LSAs in the network and enhance OSPFv3 extensibility, define
OSPFv3 areas. For some non-backbone areas at the edge of ASs, you can define them as stub
areas for further reducing the size of the routing table and the number of LSAs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ]
The OSPFv3 view is displayed.
Step 3 Run:
area area-id
Step 4 Run:
stub [ no-summary ]
An area is configured as the Stub area.

default-cost cost
The cost value of the default route sent to the Stub area is specified.
By default, the cost of the default route sent to the Stub area is set to 1.
You should set the cost of the default route sent to the Stub area only on the ABR in the Stub
area. In addition, the specified parameter no-summary of the stub command only takes effect
on the ABR. If parameter no-summary is specified, the ABR only sends the Summary-LSA
of a default route to the area, and does not generate other Summary-LSAs. An area without
AS-external-LSAs and Summary-LSAs is called a Totally Stub area.
----End
5.7.4.2.2 Configuring OSPFv3 NSSA Areas

Derived from a stub area, an NSSA allows AS external routes to be imported; an ASBR
advertises Type 7 NSSA LSAs in the local NSSA.
Context
NSSAs are introduced because stub areas cannot import external routes. An NSSA allows the
transmission of Type 7 LSAs, which are generated by ASBRs in an NSSA. When reaching the
ABR that is responsible for converting Type 7 LSAs into Type 5 LSAs in the NSSA, Type 7
LSAs with the P-bit being set and the forwarding address being a non-zero address are
converted to AS-external LSAs and advertised to other areas.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The OSPFv3 process view is displayed.
Step 3 Run:
area area-id
Step 4 Run:
nssa [ default-route-advertise [ cost cost | type type | tag tag ] * | no-import-route | no-
summary | translator-always | translator-interval translator-interval | set-n-bit ] *
An area is configured as an NSSA.
To connect routers to an NSSA, you need to run the nssa command to configure NSSA
attributes for the area to which the routers belong.

The area may be updated after NSSA attributes are configured or deleted. Thus, the NSSA
attributes can be re-configured or deleted only after the last update of NSSA attributes is
complete.
----End
5.7.4.2.3 Configuring OSPFv3 Virtual Links

In certain cases, the direct physical connection between a backbone area and a non-backbone
area can hardly be realized. Thus, you can configure virtual links for the ABR that is not
directly connected to the backbone area. Virtual links are mainly used for redundancy
backups. The other ends of virtual links also need corresponding configurations.
Context
Similar to OSPFv2, OSPFv3 defines that the route information of non-backbone areas must
be transmitted through backbone areas. To configure OSPFv3, comply with the following
principles:
l All non-backbone areas are connected with backbone areas.
l The connectivity of the backbone area must be kept.
In actual applications, the previous principles cannot be complied with due to various
restrictions. In this case, you can solve this problem by configuring virtual links.
Corresponding to the previous two principles, virtual links can be applied in the following
cases:
l Connecting an area to the backbone area through the non-backbone area
l Connecting to the segmented backbone area through the non-backbone area
NOTICE
To configure virtual links, comply with the following principles:
l Virtual links must be configured between two ABRs.
l The Transmit area cannot be the Stub area.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
area area-id


Step 4 Run:
vlink-peer neighbor-id [ hello hello-interval | retransmit retransmit-interval | trans-delay
trans-delay-interval | dead dead-interval | ipsec sa sa-name | { ipsec sa sa-name |
authentication-mode { hmac-sha256 key-id key-id { plain plain-text | [ cipher ] cipher-
text } | keychain keychain-name } } | authentication-mode { hmac-sha256 key-id key-id
{ plain plain-text | [ cipher ] cipher-text } | keychain keychain-name } | instance instance-
id ] *
The virtual link is created and configured.
----End
5.7.4.3 Controlling OSPFv3 Routing Information

In real-world situations, you need to subtly configure the OSPF routing information
sometimes to meet the requirements of complex networks, which implements the accurate
control on the OSPF routing information.
5.7.4.3.1 Configuring OSPFv3 Route Aggregation

An ABR can summarize routes with the same prefix into one LSA and advertise the
summarized route in other areas. An ASBR can also summarize imported routes with the
same prefix into one LSA and then advertise the summarized route to other areas. This can
reduce the size of the LSDB in other areas.
Context
If multiple continuous network segments exist in this area, use the abr-summary command to
summarize them into one network segment. In this way, the ABR only sends an LSA after
summarization. No LSA that belongs to the summarization network segment is separately
transmitted, therefore reducing the LSDB size of other areas.
When a large number of routes are imported, use the asbr-summary command to summarize
the imported routes and set the delay for advertising the summarized route. In this manner, the
summarized route advertised each time contains more valid routing information, and network
flapping caused by incorrect routing information is avoided.
Procedure
l Configure route summarization on an ABR.
Perform the following steps on the ABR that runs OSPFv3:
a. Run:
system-view
b. Run:
c. Run:

area area-id
d. Run:
abr-summary ipv6-address prefix-length [ cost cost | not-advertise ] *
Route summarization is configured in the OSPFv3 area.
cost cost set the cost of a summarized route. By default, the cost of a summarized
route is the maximum cost among those of routes that are summarized. The value
ranges from 1 to 16777214.
If not-advertise is set, no routing information of the network segment is advertised.
l Configure route summarization on an ASBR.
Perform the following steps on the ASBR that runs OSPFv3:
a. Run:
system-view
b. Run:
c. Run:
asbr-summary ipv6-address summary-prefix-length [ cost summary-cost | tag
summary-tag | distribute-delay dist-delay-interval | not-advertise ] *
Route summarization is configured on the ASBR.
cost cost specifies the cost of a summarized route. By default, the cost of a
summarized route is the maximum cost among those of routes that are summarized.
The value ranges from 1 to 16777214.
tag tag specifies the tag used to control route advertisement. The value of this
parameter ranges from 1 to 4294967295.
If not-advertise is specified in the command, the summarized IPv6 route that
matches a specified IPv6 prefix or prefix length is not advertised.
distribute-delay interval specifies the delay for advertising a summarized route.
----End
5.7.4.3.2 Configuring OSPFv3 to Filter the Received Routes

By configuring filtering conditions for routing information, you can allow only the routes that
pass the filtering to be received or advertised.
Context
After receiving LSAs, OSPFv3 determines whether to add the calculated routes to the local
routing table according to the filtering policy.
Procedure
Step 1 Run:
system-view


Step 2 Run:
Step 3 Run:
filter-policy { acl6-number | ipv6-prefix ipv6-prefix-name } import
The received routing information is filtered.
The filter-policy import command is only executed to filter the routes calculated by OSPFv3.
The routes that are filtered out are not added into the local routing table, and cannot guide
packet forwarding.
----End
5.7.4.3.3 Configuring OSPFv3 to Import External Routes

If not only OSPFv3, but also other routing protocols or OSPFv3 in other processes run on all
FW, you can configure OSPFv3 to import the routes generated by other routing protocols, and
advertise these routes using LSA.
Context
OSPFv3 is a routing protocol based on link status, the advertised LSAs cannot be filtered
directly. Therefore, LSAs can only be filtered when OSPFv3 imports routes, and only the
routes matching the conditions can be changed into LSAs and advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
default { cost cost | tag tag | type type } *

The default cost value of the route is imported.
By default, the cost value is 1, the tag value is 1, and the type value is Type2 for imported
external routes.
Step 4 Run:
import-route protocol [ process-id ] [ { cost cost | inherit-cost } | type type | tag tag | route-
policy route-policy-name ] *
The external route is imported.

l cost: Indicates the cost of the imported route. The value is an integer ranging from 0 to
16777214.
l type: Indicates the type of the imported route. The value is 1 or 2.
import-route bgp [ permit-ibgp ] [ { cost cost | inherit-cost } | type type | tag tag | route-
policy route-policy-name ] *
IBGP routes are imported in OSPFv3 process.
NOTE
Importing IBGP routes in OSPFv3 process can lead to routing loops.
default-route-advertise [ always | cost cost | type type | tag tag | route-policy route-policy-
name [ match-any ] ] *
Default routes are advertised to the OSPFv3 route area.
filter-policy { acl6-number | ipv6-prefix ipv6-prefix-name } export [ protocol [ process-id ] ]
The imported external routing information is filtered.
This step is optional.
If the import-route command is executed on the OSPFv3 router to import external routing
information, the OSPFv3 router turns into the ASBR.
You can specify parameter protocol to filter the routing information of a certain type. If
parameter protocol is not specified, all the imported routing information of OSPFv3 is
filtered.
NOTE
The filter-policy export command only takes effect when the import-route command is executed on
the local device to import routes (that is, when the local OSPFv3 router turns into the ASBR). The
device filters the routes when OSPF imports them. The routes filtered out cannot be turned into LSAs
and advertised by OSPF. If the import-route command is not executed to import external routes
(including the OSPFv3 routes of different processes), the filter-policy export command is invalid.
----End
5.7.4.3.4 Configuring OSPFv3 to Filter LSAs in an Area

Filtering LSAs in an area can prevent unnecessary LSA transmission. This reduces the size of
the LSDB on the neighboring router and speeds up network convergence.
Context
After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Inter-Area-Prefix
LSAs) in an area, only the Type 3 LSAs that meet the filtering conditions can be received or
advertised.
This function is applicable only to the ABR.

Procedure
system-view
Step 2 Run:
Step 3 Run:
area area-id
Step 4 Filter incoming or outgoing Type 3 LSAs in the area.
l Filter incoming Type 3 LSAs in the area
Run:
filter { acl6-number | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name }
import
The filter incoming Type 3 LSAs in the area are filtered.
l Filter outgoing Type 3 LSAs in the area
Run:
filter { acl6-number | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name }
export
The filter outgoing Type 3 LSAs in the area are filtered.
----End
5.7.4.4 Configuring OSPFv3 Route Selection

This section describes how to configure OSPFv3 route selection.
5.7.4.4.1 Setting the Cost of the OSPFv3 Interface

OSPFv3 can automatically calculate the link cost for an interface according to the interface
bandwidth. You can also set the link cost for the interface by using the related command.
Context
You can control route calculation by setting the link cost of OSPFv3 on different interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ospfv3 cost cost [ instance instance-id ]
The cost of the OSPFv3 interface is specified.
By default, the cost value of the OSPFv3 interface is 1.
----End
5.7.4.4.2 Setting the Maximum Number of Equal-Cost Routes

If the destinations and costs of the multiple routes discovered by one routing protocol are the
same, load balancing can be performed among these routes.
Context
The FW supports multi-route mode, In the multi-route mode, multiple routes to the same
destination can enjoy the same priority. If no other routes to the same destination enjoy higher
priority, all the routes are accepted. The HASH algorithm is applied to select a route among
others to transfer the packets based on the source and destination IP addresses of the packets.
As a result, the load on the network is in a balance.
Setting the maximum number of equal-cost routes can restrict the number of equal-cost routes
adding to the routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The maximum number of equal-cost routes is specified.
When the number of equal-cost routes is greater than number specified in the maximum
load-balancing command, valid routes are selected for load balancing based on the following
criteria:
1. Route preference: Routes with lower preferences are selected for load balancing. For
details about route preference configuration, see Step 4.
2. Interface index: If routes have the same priorities, routes with higher interface index
values are selected for load balancing.

3. Next hop IP address: If routes have the same priorities and interface index values, routes
with larger IP address are selected for load balancing.
nexthop router-id interface-type interface-number weight value
The route preferences are configured for load balancing.
To specify valid routes for load balancing, run the nexthop command to set the route
preference. Ensure that the preferences of valid routes to be used must be high.
The smaller the weight value, the higher the preference of the route. The default weight value
is 255, which indicates that load balancing is implemented regardless of the route preferences.
----End
5.7.4.5 Maintaining OSPFv3 Neighbor Relationship

By maintaining OSPFv3 neighbor adjacencies, you can build OSPFv3 networks.
5.7.4.5.1 Configuring the Interval for Sending Hello Packets

By adjusting the Hello interval set on OSPFv3 neighbors, you can change the speed of
establishing the neighbor relationship, therefore changing the speed of network convergence.
Context
Hello packets are periodically sent to the neighbor router to detect and maintain the neighbor
relationship and to elect the DR and the BDR. RFC 2328 requires that the Hello timer values
of neighbors be consistent. The value of the Hello timer is inversely proportional to the route
convergence speed and network load.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer hello interval [ instance instance-id ]
The interval for sending Hello packets is set on the interface.
----End
5.7.4.5.2 Configuring Dead Time of Neighbor Relationship

If a router does not receive a Hello packet from its neighbor within the Holddown time, the
router considers the neighbor relationship invalid.

Context
If a router does not receive any Hello packet from its neighbor during a specified period, the
neighbor router is considered invalid. The specified period is called the dead time of the
neighbor relationship. The dead time must be at least four times the Hello interval on an
interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer dead interval [ instance instance-id ]
The dead time of the neighbor relationship is specified.
----End
5.7.4.5.3 Configuring the Interval for Retransmitting LSAs to Neighboring Routers

After a router sends an LSA to its neighbor, the router expects to receive an LSAck packet
from its neighbor. If the router does not receive an LSAck packet within the LSA
retransmission interval, it retransmits the LSA to the neighbor.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer retransmit interval [ instance instance-id ]
The interval for retransmitting LSAs to the adjacent routers is set.
The value of seconds must be greater than the time taken to transmit a packet between two
routers.

NOTE
Do not set a value which is too small, for the interval between LSA retransmissions. Otherwise,
unnecessary retransmissions may occur.
----End
5.7.4.5.4 Configuring the Delay for Transmitting LSAs on the Interface

It takes time to transmit OSPFv3 packets on a link. Therefore, a certain delay is added to the
aging time of an LSA before the LSA is sent.
Context
The LSA ages out in the LSDB of a local router instead of in the transmission process. You
need to set the delay for an LSA before sending it. For a low-speed network, this
configuration is necessary.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 trans-delay interval [ instance instance-id ]
The delay in transmitting LSAs on the interface is set.
----End
5.7.4.6 Optimizing an OSPFv3 Network

By configuring OSPFv3 functions in special network environments, you can adjust and
optimize the OSPFv3 network performance.
5.7.4.6.1 Configuring the SPF Timer

By setting the interval for SPF calculation, you can reduce resource consumption caused by
Context
Whenever the LSDB of OSPFv3 changes, the shortest path should be recalculated.
Calculating the shortest path each time the LSDB changes consumes enormous resources and
lowers the efficiency of a router.
Adjusting the SPF delay and hold interval can suppress frequent network changes to avoid
resource consumption.

Procedure
l Configure an SPF normal timer.
a. Run:
system-view
b. Run:
c. Run:
spf timers delay-interval hold-interval
An SPF normal timer is configured.
l Configure an SPF intelligent timer.
a. Run:
system-view
b. Run:
c. Run:
spf-schedule-interval { delay-interval hold-interval | intelligent-timer max-
interval start-interval hold-interval-1
An SPF intelligent timer is configured.
NOTE
An SPF normal timer and an SPF intelligent timer are mutually exclusive.
----End
5.7.4.6.2 Setting the Interval for Receiving LSAs

Setting the interval for receiving LSAs prevents unnecessary LSA updates.
Context
When a network is unstable, control the minimum interval for receiving the same LSA
update. To prevent unnecessary LSA updates caused by network changes, by default, set the
interval for receiving the same LSA update to 1000 ms.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
lsa-arrival-interval arrival-interval
The interval for receiving LSAs is set.
----End
5.7.4.6.3 Configuring an Intelligent Timer for Generating LSAs

Configuring an intelligent timer for generating LSAs speeds up network convergence.
Context
Setting the millisecond-level interval for generating the same LSA speeds up network
convergence. When a network becomes unstable, reduce the interval for generating the same
LSA by using an intelligent timer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The OSPFv3 process view is displayed.
Step 3 Run:
lsa-originate-interval intelligent-timer max-interval start-interval hold-interval
The interval for generating the same LSA is set.
l max-interval specifies the maximum interval for updating LSAs.

l start-interval specifies the initial interval for updating LSAs.
l hold-interval specifies the hold interval for updating LSAs.
----End
5.7.4.6.4 Suppressing an Interface from Sending and Receiving OSPFv3 Packets

Prohibiting certain interfaces from receiving and sending OSPFv3 packets does not affect
advertising the direct route, consequently reducing the resource consumption and improving
the networking adaptability of OSPFv3.
Context
You can use the import command to import a direct route when advertising the direct route
on a router. In this way, however, External LSA is generated, and the direct route is advertised
to the entire AS (except the Stub area), with severe influence.

To restrict the direct route advertising, you can enable OSPFv3 on the interface, and run the
silent-interface command, lest that a Hello packet is sent on the interface to establish the
neighbor relationship. In this way, the direct route is advertised as an intra-area route, which
greatly decreases the capacity of the routing table in the OSPFv3 routing area. Moreover, a
Hello packet cannot be sent between interfaces to establish the neighbor relationship, which
lessens the processing capability load of the router and CPU.
When the interface running OSPFv3 is configured in Silent state, the direct route of the
interface can be advertised as the Intra-Area-Prefix-LSA by the same router, but the OSPFv3
neighbor relationship is not established on the interface. This feature improves the networking
adaptability of OSPFv3.
Different processes can suppress the same interface from sending and receiving OSPFv3
packets, but the silent-interface command is valid only for the OSPFv3 interface on which
the specified process is enabled, and does not take effect on the interface of other processes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
silent-interface interface-type interface-number
The interface is suppressed from receiving and sending OSPFv3 packets.
----End
5.7.4.6.5 Configuring DR Priority of an Interface

On both broadcast and NBMA networks, you can set the DR priority of OSPF interfaces to
impact the DR/BDR election. In common cases, the router with high performance and
reliability is selected as the DR/BDR.
Context
On broadcast and NBMA networks, if the neighbor relationship is established between every
two routers, a large number of unnecessary LSAs is generated on the networks, thus severely
affecting network performance.
To avoid this problem, you can elect specified routers respectively as the Designated Router
(DR) and Backup Designated Router (BDR). The other routers on the network are called
DROthers.
The following functions are implemented through DR/BDR election:
l A DROther only establishes neighbor relationships with the DR and BDR, and sends
data-updating packets to the DR and BDR in multicast mode.

l The DR spreads the data-updating packets to the DROther in multicast mode.

l When the DR is faulty, the BDR takes over the DR functions and acts as a new DR.
For a broadcast or an NBMA network, you can set the DR priority of the interface to impact
the DR/BDR election.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 dr-priority priority [ instance instance-id ]
The DR priority of the interface is specified.
By default, the DR priority of the interface is set to 1.
The DR priority of a router interface affects the qualification of the interface for the election
of the DR. The router whose priority is 0 is not elected as the DR or BDR.
----End
Follow-up Procedure
After the DR priority is changed, you can re-elect a DR or BDR through the following
methods, which, however, will result in the interruption of the OSPFv3 neighbor relationship
between routers and therefore are used only when necessary.
l Restarting all routers.
l Running the shutdown and undo shutdown commands on the interface on which the
OSPFv3 neighbor relationship is set up.
5.7.4.6.6 Configuring Stub Routers

When a router has a heavy load and cannot forward any other packets, you can configure it as
a stub router. After the router is configured as a stub router, other OSPFv3 devices do not use
this router to forward data but they can have a route to this stub router.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
stub-router [ on-startup [ interval ] ]
The stub router is configured.
NOTE
There is no correlation between the stub router configured through this command and the router in the
stub area.
----End
5.7.4.6.7 Ignoring MTU Check on DD Packets

By disabling an interface from checking the MTU field in the received DD packet, you can
enable an OSPFv3 device to receive the packet with the MTU field being 0.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 mtu-ignore [ instance instance-id ]
The MTU check on DD packets is ignored.
After the command is used, the interface does not check the MTU field of a received DD
packet.
----End
5.7.4.7 Improving OSPFv3 Network Security

If an Open Shortest Path First version 3 (OSPFv3) network requires high security, you can
configure an authentication mode to improve network security.
5.7.4.7.1 Configuring an Authentication Mode

Open Shortest Path First version 3 (OSPFv3) supports packet authentication, enabling routers
to receive only the OSPFv3 packets that are authenticated. If packets fail to be authenticated,
OSPFv3 neighbor relationships cannot be established. This section describes how to configure
an authentication mode.

Context
OSPFv3 supports keychain and HMAC-SHA256 authentications. The following procedure
uses keychain authentication as an example.
Before you configure keychain authentication, run the keychain command to configure a
keychain, the key-id command to configure a key ID, the key-string command to configure a
password, and the algorithm command to configure an algorithm. If these commands are not
run, OSPFv3 authentication fails.
NOTE
By default, authentication is not configured for OSPF process, area or interface. Configuring
authentication is recommended to ensure system security.
Procedure
l Configure OSPFv3 area authentication.
a. Run:
system-view
b. Run:
c. Run:
area area-id
d. Run:
authentication-mode { hmac-sha256 key-id key-id { plain plain-text | [ cipher ]
cipher-text } | keychain keychain-name }
OSPFv3 area authentication is configured.
NOTE
If you use OSPFv3 area authentication, the authentication and password configurations on
all routers in the same area must be the same.
l Configure OSPFv3 process authentication.
a. Run:
system-view
b. Run:
c. Run:
authentication-mode { hmac-sha256 key-id key-id { plain plain-text | [ cipher ]
cipher-text } | keychain keychain-name }

OSPFv3 process authentication is configured.

l Configure OSPFv3 interface authentication.
a. Run:
system-view
b. Run:
c. Run:
ospfv3 authentication-mode { hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] cipher-text } | keychain keychain-name } [ instance instance-id ]
OSPFv3 interface authentication is configured.
NOTE
OSPFv3 interface authentication takes precedence over OSPFv3 area authentication.

If you use HMAC-SHA256 authentication, the authentication and password configurations
on all the interfaces on the same network segment must be the same.
----End
5.7.4.8 Enhancing OSPFv3 Network Reliability

Configuring OSPFv3 GR and OSPFv3-BFD association improves OSPFv3 network
convergence and enhances OSPFv3 reliability.
5.7.4.8.1 Configuration OSPFv3 GR

By configuring OSPFv3 GR, you can avoid inaccurate route calculation and packet loss after
an OSPFv3 device restarts.
Context
To prevent route flapping and service interruption due to the restart of OSPFv3, you can
enable OSPFv3 GR.
After OSPFv3 restarts, the GR restarter and the GR helper keep the neighbor relationship,
exchange routing information, synchronize the database, and update the routing table and the
forwarding table. OSPFv3 fast convergence is therefore realized.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
graceful-restart [ period period | ack-time time | retransmit-interval interval | lsa-

checking-ignore | planned-only ] *
OSPFv3 GR is enabled.
By default, OSPFv3 GR is disabled.
ack-time is optional. After ack-time is specified, the restarter can discover more neighbors in
the time period.
Step 4 Run:
helper-role [ acl-number acl-number | ip-prefix ip-prefix-name | max-grace-period period |

planned-only | lsa-checking-ignore ] *
The helper of OSPFv3 GR is enabled.
By default, the helper of OSPFv3 GR is disabled.
----End
5.7.4.9 Configuring the Network Management Function of OSPFv3

OSPFv3 supports the network management function. You can bind the OSPFv3 MIB to a
certain OSPFv3 process.
5.7.4.9.1 Configuring OSPFv3 MIB Binding

The MIB is a virtual database of the device status maintained by the managed devices.
Context
When multiple OSPFv3 processes are enabled, you can configure OSPFv3 MIB to select the
process to be processed, that is, that is, configure OSPFv3 MIB to select the process to which
it is bound.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 mib-binding process-id
OSPFv3 MIB binding is configured.
----End

5.7.4.9.2 Configuring OSPFv3 Trap

Traps are the notifications sent from a router to inform the NMS of the fault detected by the
system.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name ospfv3 [ trap-name

{ authenticationsequencenumberwrap | ifconfigerror | ifrxbadpacket | ifstatechange |
lastauthenticationkeyexpiry | nbrrestarthelperstatuschange | nbrstatechange |
nssatranslatorstatuschange | restartstatuschange | virtifconfigerror | virtifrxbadpacket |
virtifstatechange | virtnbrrestarthelperstatuschange | virtnbrstatechange } ]
The trap function for the OSPFv3 module is enabled.
To enable the traps of one or more events, you can specify type-name.
Step 3 Run:
snmp-agent trap feature-name ospfv3 trap-name trap-name description description-text
The descriptions for OSPFv3 traps is configured.
----End
5.7.5 Maintaining OSPFv3

After OSPFv3 routes are built, you can view and clear OSPFv3 routing information.
Viewing OSPFv3
Table 5-52 Viewing OSPFv3 routing information
Operation Command
Check the summary display ospfv3 [ process-id

of an OSPFv3
process.
Check an OSPFv3 display ospfv3 [ process-id ] interface [ area area-id ]

interface. [ interface-type interface-number ]
Check the LSDB of display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-
an OSPFv3 process. router advertising-router-id | self-originate ] [ { router | network
| inter-router [ asbr-router asbr-router-id ] | { inter-prefix |
nssa } [ ipv6-address prefix-length ] | link | intra-prefix | grace }
[ link-state-id ] ]

Operation Command
Check OSPFv3 display ospfv3 [ process-id ] [ area area-id ] peer [ interface-type

neighbors. interface-number | neighbor-id ] [ verbose ]
Check the OSPFv3 display ospfv3 [ process-id ] routing [ ipv6-address prefix-

routing table. length ] | abr-routes | asbr-routes | intra-routes | inter-routes |
ase-routes | nssa-routes | [ statistics ] [ uninstalled ] | [ verbose ]
Check the path of an display ospfv3 [ process-id ] path

OSPFv3 process.
Resetting OSPFv3
NOTICE
OSPFv3 statistics cannot be restored after they are cleared. Exercise caution when running the
reset command.
Table 5-53 Resetting an OSPFv3 process

Operation Command
Reset an OSPFv3 l reset ospfv3 { process-id | all } [ graceful-restart [ extend-

process. period period ] ]
l reset ospfv3 { process-id | all } counters [ neighbor
[ interface-type interface-number ] [ router-id ] ]

This section provides several configuration examples of OSPFv3 together with the
Networking diagram. The configuration examples explain networking requirements, and
configuration roadmap.
5.7.6.1 Example for Configuring OSPFv3 to Connect Network Devices

This section provides an example for configuring OSPFv3 to implement connectivity between
IPv6 devices across departments.
As shown in Figure 5-56, an enterprise deploys FWs to connect to the research and
development, marketing, and financial departments respectively. The enterprise also deploys a
FW on the network border as a security gateway to connect the intranet to the IPv6 network
through an ISP network.

l OSPFv3 runs on the intranet to implement connectivity between IPv6 devices across
departments.
l Routers in the department belong to a totally stub area. These routers can only use a
default route to access the IPv6 network. They cannot learn external area routes. The
totally stub area minimizes external routing information distribution and improves router
performance and Research network quality.
l FW_A and the ISP router establish an OSPFv3 neighbor relationship so that FW_A can
learn IPv6 network routes.
l Devices in all departments can access the IPv6 network through the ISP router.
Figure 5-56 OSPFv3 networking
Trust
Finance
2001::/64
Area1 GE1/0/3
2001::1/64
FW_B
Trust Untrust Trust Untrust
GE1/0/1
2000::2/64
GE1/0/3 GE1/0/1 GE1/0/3 GE1/0/1

Research 2002::1/64 2000::3/64 2000::1/64 3000::1/64 IPv6
2002::/64 Network
Area2 Area4
Stub GE1/0/1 Area0
ISP Router
3000::2
2000::4/64
FW_C
FW_D FW_A
GE1/0/3
2003::1/64
Area3
Marketing
2003::/64
Trust
1. Assign IPv6 addresses to FW interfaces and add interfaces to security zones.

2. Configure OSPFv3 on each FW:

– FW_A: connects the ISP router in Area4 to the switch in Area0.
– FW_B: connects devices of the financial department in Area1 to the switch in
Area0.
– FW_C: connects devices of the research and development department in Area2 to
the switch in Area0.
– FW_D: connects devices of the marketing department in Area3 to the switch in
Area0.
3. Configure security policies on FWs so that devices in all departments can exchange
OSPFv3 packets and access the IPv6 network.
Procedure
1. Configure an IPv6 address for each interface and assign interfaces to specific security
zones.
# Configure an IPv6 address for each interface.
<FW> system-view
[FW] sysname FW_A
[FW_A] ipv6
[FW_A] interface gigabitEthernet 1/0/1

2. Configure an interzone security policy to allow devices to exchange OSPFv3 packets and
the R&D, marketing, and finance departments to access the IPv6 network.
NOTE
This section provides only required security policy parameters. Set other security policy parameters as
required.
[FW_A-policy-security-rule-policy_sec_1] source-zone local trust
[FW_A-policy-security-rule-policy_sec_1] destination-zone local trust
[FW_A-policy-security-rule-policy_sec_2] source-zone local untrust
[FW_A-policy-security-rule-policy_sec_2] destination-zone local untrust


3. Configure OSPFv3.
# Enable OSPFv3 and set the router ID to 1.1.1.1.
[FW_A] ospfv3
[FW_A-ospfv3-1] router-id 1.1.1.1
[FW_A-ospfv3-1] quit
# Enable OSPFv3 on each interface.

[FW_A-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.4
[FW_A-GigabitEthernet1/0/3] ospfv3 1 area 0.0.0.0

zones.
<FW> system-view
[FW] sysname FW_B
[FW_B] ipv6
[FW_B] interface gigabitEthernet 1/0/1
[FW_B-GigabitEthernet1/0/0] ipv6 address 2000::2/64
[FW_B-GigabitEthernet1/0/3] ipv6 address 2001::1/64

the finance department to access the R&D department, marketing department, and IPv6
network.
NOTE
required.
[FW_B-policy-security-rule-policy_sec_1] source-zone local trust
[FW_B-policy-security-rule-policy_sec_1] destination-zone local trust
[FW_B-policy-security-rule-policy_sec_2] source-zone local untrust
[FW_B-policy-security-rule-policy_sec_2] destination-zone local untrust


[FW_B-policy-security-rule-policy_sec_3] source-address 2001:: 64
[FW_B] ospfv3
[FW_B-ospfv3-1] router-id 2.2.2.2
[FW_B-ospfv3-1] quit

[FW_B-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
[FW_B-GigabitEthernet1/0/3] ospfv3 1 area 0.0.0.1

zones.
<FW> system-view
[FW] sysname FW_C
[FW_C] ipv6
[FW_C] interface gigabitEthernet 1/0/1
[FW_C-GigabitEthernet1/0/0] ipv6 enable
[FW_C-GigabitEthernet1/0/0] ipv6 address 2000::3/64
[FW_C-GigabitEthernet1/0/3] ipv6 enable
[FW_C-GigabitEthernet1/0/3] ipv6 address 2002::1/64

[FW_C] firewall zone trust
[FW_C-zone-trust] quit
[FW_C] firewall zone untrust
[FW_C-zone-untrust] add interface GigabitEthernet 1/0/1
[FW_C-zone-untrust] quit
the R&D department to access the finance department, marketing department, and IPv6
network.
NOTE
required.
[FW_C] security-policy
[FW_C-policy-security] rule name policy_sec_1
[FW_C-policy-security-rule-policy_sec_1] source-zone local trust
[FW_C-policy-security-rule-policy_sec_1] destination-zone local trust
[FW_C-policy-security-rule-policy_sec_1] action permit
[FW_C-policy-security-rule-policy_sec_1] quit
[FW_C-policy-security-rule-policy_sec_2] source-zone local untrust
[FW_C-policy-security-rule-policy_sec_2] destination-zone local untrust

[FW_C-policy-security-rule-policy_sec_3] source-zone trust
[FW_C-policy-security-rule-policy_sec_3] destination-zone untrust
[FW_C-policy-security-rule-policy_sec_3] source-address 2002:: 64
[FW_C-policy-security] quit
[FW_C] ospfv3
[FW_C-ospfv3-1] router-id 3.3.3.3
[FW_C-ospfv3-1] quit

[FW_C-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
[FW_C-GigabitEthernet1/0/3] ospfv3 1 area 0.0.0.2
Step 4 Configure FW_D.

zones.
<FW> system-view
[FW] sysname FW_D
[FW_D] ipv6
[FW_D] interface gigabitEthernet 1/0/1
[FW_D-GigabitEthernet1/0/0] ipv6 enable
[FW_D-GigabitEthernet1/0/0] ipv6 address 2000::4/64
[FW_D-GigabitEthernet1/0/0] quit
[FW_D-GigabitEthernet1/0/3] ipv6 enable
[FW_D-GigabitEthernet1/0/3] ipv6 address 2003::1/64

[FW_D] firewall zone trust
[FW_D-zone-trust] add interface GigabitEthernet 1/0/3
[FW_D-zone-trust] quit
[FW_D] firewall zone untrust
[FW_D-zone-untrust] add interface GigabitEthernet 1/0/1
[FW_D-zone-untrust] quit
the R&D department to access the finance department, marketing department, and IPv6
network.
NOTE
required.
[FW_D] security-policy
[FW_D-policy-security] rule name policy_sec_1
[FW_D-policy-security-rule-policy_sec_1] source-zone local trust
[FW_D-policy-security-rule-policy_sec_1] destination-zone local trust
[FW_D-policy-security-rule-policy_sec_1] action permit
[FW_D-policy-security-rule-policy_sec_1] quit
[FW_D-policy-security-rule-policy_sec_2] source-zone local untrust

[FW_D-policy-security-rule-policy_sec_2] destination-zone local untrust

[FW_D-policy-security-rule-policy_sec_3] source-zone trust
[FW_D-policy-security-rule-policy_sec_3] destination-zone untrust
[FW_D-policy-security-rule-policy_sec_3] source-address 2002:: 64
[FW_D-policy-security] quit
[FW_D] ospfv3
[FW_D-ospfv3-1] router-id 4.4.4.4
[FW_D-ospfv3-1] quit

[FW_D-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
[FW_D-GigabitEthernet1/0/3] ospfv3 1 area 0.0.0.3
----End
1. View the OSPFv3 neighbor status on the FW. The following command output shows the
OSPFv3 neighbor status on FW_A.
[FW_A] display ospfv3 peer
OSPFv3 Process (1)

OSPFv3 Area (0.0.0.1)
Neighbor ID Pri State Dead Time Interface Instance
ID
2.2.2.2 1 2-Way/DROther 00:00:34 GE1/0/3 0
3.3.3.3 1 Full/Backup 00:00:32 GE1/0/3 0
4.4.4.4 1 Full/DR 00:00:32 GE1/0/3 0
OSPFv3 Area (0.0.0.4)
Neighbor ID Pri State Dead Time Interface Instance
ID
5.5.5.5 1 Full/- 00:00:34 GE1/0/1 0
2. View the OSPFv3 routing table on the FW. The following command output shows the
OSPFv3 routing table on FW_A.
[FW_A] display ospfv3 peer
Codes : E2 - Type 2 External, E1 - Type 1 External, IA - Inter-Area,

N - NSSA, U - Uninstalled, D - Denied by Import Policy
OSPFv3 Process (1)
Destination Metric
Next-hop
IA 2000::/64 1
directly-connected, GE1/0/3
IA 2001::/64 2
via 2000::2, GE1/0/3
IA 2002::/64 2
via 2000::3, GE1/0/3
2003::/64 2
via 2000::4, GE1/0/3
IA 3000::/64 1
directly-connected, GE1/0/1

The preceding command output shows that FW_A learns the network segment routes of
the R&D, marketing, and finance departments and the IPv6 routes to the Internet.
#
ipv6
#
sysname FW_A
#
ipv6 enable
ospfv3 1 area 0.0.0.4
#
ipv6 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ospfv3 1
router-id 10.1.1.1
#
security-policy
source-zone local
source-zone trust
action permit
source-zone local
source-zone untrust
action permit
source-zone trust
action permit
#
return

#
ipv6
#
sysname FW_B
#
ipv6 enable
#

ipv6 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ospfv3 1
router-id 10.2.2.2
#
security-policy
source-zone local
source-zone trust
action permit
source-zone local
source-zone untrust
action permit
source-zone trust
action permit
#
return

#
ipv6
#
sysname FW_C
#
ipv6 enable
#
ipv6 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ospfv3 1
router-id 10.3.3.3
area 0.0.0.2
stub no-summary
#
security-policy
source-zone local

source-zone trust
action permit
source-zone local
source-zone untrust
action permit
source-zone trust
action permit
#
return
Configuration script for FW_D:

#
ipv6
#
sysname FW_D
#
ipv6 enable
#
ipv6 enable
#
firewall zone trust
set priority 85
#
set priority 5
#
ospfv3 1
router-id 10.4.4.4
#
security-policy
source-zone local
source-zone trust
action permit
source-zone local
source-zone untrust
action permit
source-zone trust
action permit
#
return

5.7.7 Reference
This section provides reference information about OSPFv3.
This section describes OSPFv3 specifications.
Area partition Through suitable area Supported by all models

partition, OSPFv3
effectively reduces the
network bandwidth used by
protocol data and speeds up
route calculation and
convergence.
Setting a default cost for an - Supported by all models

area
Stub area To reduce the sizes of the Supported by all models

LSDB and routing table, a
stub area uses a default
Inter-area Prefix LSA to
describe the destination
outside the area but still in
the AS.
Totally stub area Type3 LSAs are no longer Supported by all models
flooded in a totally stub area
and are replaced with a
default route.
Route aggregation on an If consecutive network Supported by all models

ABR segments exist in an area,
you can manually aggregate
these network segments into
a single network segment on
the ABR of the area. The
ABR generates and
advertises only one LSA for
the summarized network
segment, reducing the
LSDBs of devices in other
areas.
Configuring an ABR to After you configure this Supported by all models

aggregate routes but not function on an ABR, the
advertise the aggregated ABR will not advertise any
route aggregated route.

Enabling/disabling OSPFv3 - Supported by all models

on an interface
Suppressing an interface After you suppress an Supported by all models

from sending or receiving OSPFv3 interface on a
OSPFv3 packets router from sending or
receiving OSPFv3 packets,
the interface still uses the
Intra-Area-Prefix-LSA of
the router to advertise its
direct route but no longer
establish any OSPFv3
neighbor relationship. This
function enhances the
networking adaptability of
OSPFv3.
Setting a cost for an - Supported by all models

interface
Setting a DR priority for an The DR priority of an Supported by all models

interface interface determines the
qualification of the interface
in DR election. The
interface with the DR
priority value of 0 will not
be elected as a DR or BDR.
Disabling the MTU check If few LSAs exist or a great Supported by all models
on DD packets difference exists between
the MTUs of the interfaces
on both ends of a link, you
can disable the local
interface from checking the
MTUs of DD packets.
Setting the interval at which The LSAs age out in the Supported by all models
an interface transmits LSAs LSDB of the local device
but do not age during
transmission. Therefore, you
need to add a certain delay
to the aging time of an LSA
before sending the LSA.
Setting the interval at which OSPFv3 routing devices use Supported by all models
an interface sends Hello Hello packet to establish and
packets maintain neighbor
relationships and
adjacencies.

Setting a dead interval on an This interval is called an Supported by all models

interface OSPF neighbor dead
interval. If an interface does
not receive Hello packets
from an OSPF neighbor
within the specified interval,
the interface considers the
neighbor Down.
Setting the interval at which After a routing device sends Supported by all models
an interface retransmits an LSA to a neighbor, it
LSAs needs to wait for the LSAck
packet of the neighbor. If the
device does not receive the
LSAck packet within the
interval for retransmitting
LSAs, it retransmits the
LSA.
Multi-process - Supported by all models
Specifying a router ID A router ID is a 32-bit Supported by all models

unsigned integer, which
identifies a device in an
autonomous system (AS). It
is in an IPv4 address format.
False Hello packets The false Hello packet Supported by all models
function enables a routing
device to continue to
maintain its neighbor
relationships after the device
receives any valid OSPFv3
packets, enhancing network
stability.
Setting the SPF suppression - Supported by all models

time
Setting the SPF delay - Supported by all models
Network type The network types include Supported by all models

broadcast, NBMA, P2P, and
P2MP.
Virtual link A virtual link connects the Supported by all models

ABR that is not directly
connected to the backbone
area to the tunnel of the
backbone area for
redundancy.

Route import The routes that OSPFv3 can Supported by all models
import include direct, static,
OSPFv3, IS-ISv6, BGP4+,
and RIPng routes.
Importing Type 1 external Because a Type 1 external Supported by all models

routes route has high reliability, its
cost equals the cost of an AS
internal route. The cost of a
Type 1 external route is
calculated based on the
formula: Cost of a Type 1
external route = Cost of the
route from a routing device
to an ASBR + Cost of the
route from the ASBR to the
destination.
Importing Type 2 external Because a Type 2 external Supported by all models

routes route has low reliability, the
cost of the route from an
ASBR to the destination of
the Type 2 external route is
much greater than the cost
of any internal route to the
ASBR. Therefore, OSPFv3
only takes the cost of the
route from the ASBR to a
destination outside the AS
into consideration and
calculates the cost based on
the formula: Cost of a Type
2 external route = Cost of
the route from the ASBR to
the destination of the Type 2
external route.
Specifying a cost for a route - Supported by all models

to be imported
Applying a routing policy to - Supported by all models

routes to be imported

received

advertised
Limit on the maximum - Supported by all models

number of equal-cost routes


This section describes the versions and changes in the OSPFv3 feature.

This section provides OSPFv3 standards and protocols.
The OSPFv3 standards and protocols are as follows:
l RFC 2740: OSPF for IPv6
l RFC 4552: Authentication/Confidentiality for OSPFv3
l RFC 5187: OSPFv3 Graceful Restart
l RFC 7166: Supporting Authentication Trailer for OSPFv3
5.8 IS-IS
Intermediate System to Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP)
and runs at the link layer. IS-IS features rapid aggregation and a hierarchical structure. IS-IS is
widely used on large-scale carrier networks.
5.8.1 Overview
Intermediate System to Intermediate System (IS-IS) is a link status protocol that uses the
shortest path first (SPF) algorithm to calculate routes.
Definition
The Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol
initially designed by the International Organization for Standardization (ISO) for its
Connectionless Network Protocol (CLNP).
To support IP routing, the Internet Engineering Task Force (IETF) extends and modifies IS-IS
in RFC 1195. This enables IS-IS to be applied to TCP/IP and OSI environments. This type of
IS-IS is called Integrated IS-IS or Dual IS-IS.
IS-IS stated in this document refers to Integrated IS-IS, unless otherwise stated.
Purpose
As an Interior Gateway Protocol (IGP), IS-IS is used in Autonomous Systems (ASs). IS-IS is
a link state protocol. It uses the Shortest Path First (SPF) algorithm to calculate routes.
5.8.2 Principles
This section describes ISIS principles.

5.8.2.1 Basic Concepts of IS-IS
IS-IS Areas
To support large-scale routing networks, Intermediate System to Intermediate System (IS-IS)
uses a two-level hierarchical structure in a routing domain. A large domain can be divided
into areas. Figure 5-57 shows an IS-IS network. The entire backbone area covers all Level-2
routers in area 1 and Level-1-2 routers in other areas. The following describes three types of
routers on the IS-IS network.
Figure 5-57 IS-IS topology
Area2
Area3
L1
L1/2
L1/2
L2
L2
backbone Area1
L2 L2
Area5
Area4
L1/2 L1
L1/2
L1
L1
L1 L1
l Level-1 router
A Level-1 router manages intra-area routing. It establishes neighbor relationships with
only the Level-1 and Level-1-2 routers in the same area. It maintains a Level-1 LSDB.
The LSDB contains routing information of the local area. A packet to a destination
outside this area is forwarded to the nearest Level-1-2 router.
l Level-2 router
A Level-2 router manages inter-area routing. It can establish neighbor relationships with
Level-2 routers or Level-1-2 routers in other areas. It maintains a Level-2 LSDB. The
LSDB contains inter-area routing information.
All Level-2 routers form the backbone network of the routing domain. They are
responsible for communications between areas. The Level-2 routers in the routing
domain must be in succession to ensure the continuity of the backbone network. Only
Level-2 routers can exchange data packets or routing information with routers outside
the routing domain.
l Level-1-2 router

A router that belongs to both a Level-1 area and a Level-2 area is called a Level-1-2
router. It can establish Level-1 neighbor relationships with Level-1 routers and Level-1-2
routers in the same area. It can also establish Level-2 neighbor relationships with Level-2
routers and Level-1-2 routers in other areas. A Level-1 router must be connected to other
areas through a Level-1-2 router.
A Level-1-2 router maintains two LSDBs: Level-1 and Level-2. The Level-1 LSDB is
used for intra-area routing and the Level-2 LSDB is used for inter-area routing.
NOTE
Level-1 routers in different areas cannot establish neighbor relationships. Level-2 routers can
establish neighbor relationships with each other, regardless of the areas to which the Level-2
routers belong.
In general, Level-1 routers are located in an area, Level-2 routers are located among areas,
and Level-1-2 routers are located between the Level-1 and Level-2 routers.
Interface level
A Level-1-2 router may need to establish only a Level-1 neighbor relationship with the
remote end and only a Level-2 neighbor relationship with the other remote end. You can set
the level of an interface to restrict the setup of adjacencies on the interface. For example, only
a Level-1 adjacency can be established on a Level-1 interface and only a Level-2 adjacency
can be established on a Level-2 interface.
Address Structure of IS-IS

In OSI, the NSAP is an address used to locate resources. The ISO has adopted the NSAP
address structure shown in Figure 5-58. NSAP is composed of the Initial Domain Part (IDP)
and the Domain Specific Part (DSP). The IDP is equal to the network ID in an IP address, and
DSP is equal to the subnet number and host address in an IP address.
As defined by the ISO, the IDP consists of the Authority and Format Identifier (AFI) and the
Initial Domain Identifier (IDI). The AFI specifies the address assignment mechanism and
address format; the IDI identifies a domain.
The DSP consists of the High Order DSP (HODSP), system ID, and NSAP Selector (SEL).
The HODSP is used to divide areas, the system ID identifies a host, and the SEL indicates the
service type.
The lengths of the IDP and the DSP are variable. The maximum length of the NSAP is 20
bytes and its minimum length is 8 bytes.
Figure 5-58 Networking for IS-IS address structure
IDP DSP
AFI IDI High Order DSP System ID SEL(1 octet)
Area Address

l Area address
Together with the HODSP of the DSP, the IDP can identify a routing domain and the
areas in a routing domain. The combination of the IDP and HODSP is referred to as an
area address, which is equal to an area number in OSPF. An area address is used to
uniquely identify the area in the routing domain. The area addresses of routers in the
same Level-1 area must be the same.
In general, a router can be configured with only one area address. The area address of all
nodes in an area must be the same. In the implementation of a device, an IS-IS process
can be configured with a maximum of three area addresses to support seamless
combination, division, and transformation of areas.
l System ID
A system ID uniquely identifies a host or a router in an area. In the device, the fixed
length of the system ID is 48 bits (6 bytes).
In actual applications, a router ID corresponds to a system ID. If a router takes the IP
address 168.10.1.1 of Loopback 0 as its router ID, its system ID used in IS-IS can be
obtained in the following way:
– To extend each part of the IP address 168.10.1.1 to 3 digits, add 0 to the front of any
part that is shorter than 3 digits.
– Divide the extended address 168.010.001.001 into three parts, with each part
consisting of four decimal digits.
– The reconstructed address 1680.1000.1001 is the system ID.
You can specify a system ID in many ways. You need to ensure that the system ID
uniquely identifies a host or a router.
l SEL
The role of an SEL (also referred to as NSAP Selector or N-SEL) is similar to that of the
"protocol identifier" of IP. A transport protocol matches an SEL. The SEL is always "00"
in IP.
l NET
A Network Entity Title (NET) indicates the network layer information of an IS itself. It
does not contain the transport layer information (SEL = 0). A NET can be regarded as a
special NSAP. The length of the NET field is the same as that of an NSAP. Its maximum
length is 20 bytes and its minimum length is 8 bytes. When configuring IS-IS on a
router, you can configure only a NET instead of an NSAP.
In general, an IS-IS process is configured with only one NET. When an area needs to be
redefined, such as being combined with other areas or divided into sub-areas, you can
configure the router with multiple NETs to ensure the correctness of routes.
NOTE
A maximum of three area addresses can be configured in an IS-IS process, and therefore, you can
configure only a maximum of three NETs. When you configure multiple NETs, ensure that their
system IDs are the same.
The routers in an area must have the same area address.
IS-IS Network Types

IS-IS supports the following types of networks:
l Broadcast network
l Point-to-point (P2P) network

5.8.2.2 Basic Protocols of IS-IS
Related Concepts
DIS and Pseudo Node
A Designated Intermediate System (DIS) is an intermediate router elected in Intermediate
System to Intermediate System (IS-IS) communication. A pseudo node simulates a virtual
node on a broadcast network and is not an actual router. In IS-IS, a pseudo node is identified
by the system ID and 1-byte circuit ID (a non-zero value) of a DIS.
The DIS is used to create and update pseudo nodes and generate the link state protocol data
units (LSPs) of pseudo nodes. The routers advertise a single link to a pseudo node and obtain
routing information about the entire network through the pseudo node. The router does not
need to exchange packets with all the other routers on the network. Using the DIS and pseudo
nodes simplifies network topology and reduces the length of LSPs generated by routers.
When the network changes, fewer LSPs are generated. As a result, the SPF consumes fewer
resources.
SPF Algorithm
The SPF algorithm, also named Dijkstra's algorithm, is used in a link-state routing protocol to
calculate the shortest paths to other nodes on a network. In the SPF algorithm, a local router
takes itself as the root and generates a shortest path tree (SPT) based on the network topology
to calculate the shortest path to every destination node on a network. In IS-IS, the SPF
algorithm runs separately in Level-1 and Level-2 databases.
Implementation
All routers on the IS-IS network communicate by performing the following steps:
l Establishment of IS-IS Neighbor Relationships
l LSDB Synchronization
l Route Calculation
Establishment of IS-IS Neighbor Relationships
On different types of networks, the modes for establishing IS-IS neighbor relationships are
different.
l Establishment of a neighbor relationship on a broadcast link
Figure 5-59 Networking for a broadcast link

RouterA RouterB
RouterC RouterD

RouterA, RouterB, RouterC, and RouterD are Level-2 routers. RouterA is newly added
to the broadcast network. Figure 5-60 shows the process of establishing the neighbor
relationship between RouterA and RouterB, the process of establishing the neighbor
relationship between RouterA and RouterC or RouterD is similar to that between
RouterA and RouterB, and is not mentioned here.
Figure 5-60 Establishing a neighbor relationship on a broadcast link

RouterA RouterB
MAC:0000-c102-0103 MAC:0000-c102-0104
L2 LAN IIH
( Sys ID:RouterA neighbor:null ) neighbor RouterA
L2 LAN IIH initialized
neighbor RouterB ( Sys ID:RouterB neighbor:0000-c102-0103)
established L2 LAN IIH
( Sys id:RouterA neighbor:0000-c102-0104 )
neighbor RouterA
L2 LAN IIH established
L2 LAN IIH
As shown in Figure 5-60, the process for establishing a neighbor relationship on a

broadcast link consists of the following phases:
– Router A broadcasts a Level-2 local area network (LAN) IS-to-IS Hello PDU (IIH).
After Router B receives the IIH, Router B detects that the neighbor field in the IIH
does not contain its media access control (MAC) address, and sets its neighbor
status with Router A to Initial.
– Router B returns a Level-2 LAN IIH to Router A. After Router A receives the IIH,
Router A detects that the neighbor field in the IIH contains its MAC address, and
sets its neighbor status with Router B to Established.
– Router A sends a Level-2 LAN IIH to Router B. After Router B receives the IIH,
Router B detects that the neighbor field in the IIH contains its MAC address, and
sets its neighbor status with Router A to Established.
DIS Election
On a broadcast network, any two routers exchange information. If n (an integer) routers
are available on the network, n x (n - 1)/2 adjacencies must be established. Each status
change of a router is transmitted to other routers, which wastes bandwidth. IS-IS resolves
this problem by defining the DIS. All routers send information to the DIS, which then
broadcasts the network link status. Using the DIS and pseudo nodes simplifies network
topology and reduces the length of LSPs generated by routers. When the network
changes, fewer LSPs are generated. As a result, the SPF consumes fewer resources.
A DIS is elected after a neighbor relationship is established. Level-1 and Level-2 DISs
are elected separately. You can configure different priorities for DISs at different levels.
In DIS election, a Level-1 priority and a Level-2 priority are specified for every interface

on every router. A router uses every interface to send IIHs and advertises its priorities in
the IIHs to neighboring routers. The higher the priority is, the higher the probability is
that the router is elected as the DIS. If there are multiple routers with the same highest
priority on a broadcast network, the one with the highest MAC address is elected. The
DISs at different levels can be the same router or different routers.
In the DIS election procedure, IS-IS is different from Open Shortest Path First (OSPF) in
the following aspects:
– The router with the priority of 0 also takes part in the DIS election.
– When a new router that meets the requirements of being a DIS joins the broadcast
network, the router is selected as the new DIS. This change causes LSP flooding.
l Establishment of a neighbor relationship on a P2P link
The establishment of a neighbor relationship on a P2P link is different from that on a
broadcast link. A neighbor relationship on a P2P link can be established in 2-way or 3-
way mode, as shown in Table 5-54. By default, the 3-way handshake mechanism is used
to establish a neighbor relationship on a P2P link.

Table 5-54 Comparison between 2-way mode and 3-way mode

Mode Description Advantages and Reliability
Disadvantages
2-way mode When a router Disadvantages: Low

receives an IIH, it l The unstable
unidirectionally link status
sets up a neighbor causes the loss
relationship. of complete
sequence
numbers
protocol data
units (CSNPs)
that are sent
once an
adjacency is set
up. As a result,
the link state
databases
(LSDBs) of two
neighboring
routers are not
synchronized
during the LSP
update period.
l If two or more
links exist
between two
routers, an
adjacency
relationship can
still be set up
when one link
is Down and
another is Up in
the same
direction. A
router that fails
to detect the
faulty link may
also forward
packets over
this link.

Mode Description Advantages and Reliability

Disadvantages
3-way mode A neighbor Advantages: A High

relationship is neighbor
established after relationship is
IIHs are sent three established only
times. when both ends are
Up. This
mechanism ensures
that packets are
transmitted
securely.
IS-IS Strict Neighbor Check

In IS-IS, IPv4 and IPv6 share a standard topology. When both IPv4 and IPv6 are deployed in
a standard topology, a problem can occur: if only IPv4 goes Up, IPv6 traffic is interrupted; if
only IPv6 goes Up, IPv4 traffic is interrupted. Another problem occurs when a primary link
recovers after a switchover occurs between primary and backup links. In this scenario, IPv4
traffic is switched to the primary link first because IPv4 goes Up faster than IPv6. IPv6 is also
switched but discarded because IPv6 links are not Up. IS-IS strict neighbor check can resolve
these problems.
IS-IS must check the following items when establishing a neighbor relationship:
l Whether the address family configured on the local router is the same as that carried in a
received IIH. The address family status of neighboring routers is set to Up only when
both are the same.
l Whether the address family configured in the standard topology is Up in the case of
establishing a standard topology neighbor relationship identified by MT0, which is
carried in an IIH. The address family configured in the standard topology goes Up only
when all address families go Up.
LSDB Synchronization
IS-IS is a link-state protocol. An IS-IS router obtains first-hand information from other routers
running link-state protocols. Every router generates information about itself, directly
connected networks, and links between itself and directly connected networks. The router
then sends the generated information to other routers through adjacent routers. Every router
saves link state information but never modifies it. Finally, every router has the same network
interworking information, and LSDB synchronization is complete. The process of
implementing LSDB synchronization is named LSP flooding. In LSP flooding, a router sends
an LSP to its neighbors and the neighbors send the received LSP to their respective neighbors
except the router that first sends the LSP. The LSP is flooded among the routers at the same
level. This implementation allows each router at the same level to have the same LSP
information and keep a synchronized LSDB.
All routers in the IS-IS routing domain can generate LSPs. The following events trigger the
generation of a new LSP:
l Neighbor is Up or Down.
l A related interface is Up or Down.
l Imported IP routes change.

l Inter-area IP routes change.

l Interface is assigned a new metric value.
l Periodical updates occur.
A router's processing for a received LSP consists of the following phases:
l Updating the LSDB on a broadcast link
The DIS updates the LSDB to synchronize the LSDB on a broadcast network. Figure
5-61 shows the process of synchronizing the LSDB on a broadcast network.
a. When the DIS receives an LSP, it searches the LSDB for the related records. If the
DIS does not find the LSP in its LSDB, it adds the LSP to its LSDB and broadcasts
the contents of the new LSDB.
b. If the sequence number of the received LSP is greater than the sequence number of
the corresponding LSP, the DIS replaces the LSP with the received LSP in the
LSDB, and broadcasts the contents of the new LSDB.
c. If the sequence number of the received LSP is smaller than the sequence number of
the corresponding LSP, the DIS sends the LSP in the LSDB to the inbound
interface.
d. If the sequence number of the received LSP is equal to the sequence number of the
corresponding LSP, the DIS compares the Remaining Lifetime of the two LSPs. If
Remaining Lifetime of the received LSP is 0, the DIS replaces the LSP with the
received LSP, and broadcasts the contents of the new LSDB. If the Remaining
Lifetime of corresponding LSP is 0, the DIS sends the LSP to the inbound interface.
e. If the sequence number of the received LSP and that of the corresponding LSP in
the LSDB are the same and neither Remaining Lifetime is 0, the DIS compares the
checksum of the two LSPs. If the received LSP has a greater checksum than that of
the corresponding LSP in the LSDB, the DIS replaces the LSP in the LSDB with
the received LSP, and advertises the contents of the new LSDB. If the received LSP
has a smaller checksum than that of the corresponding LSP in the LSDB, the DIS
sends the LSP in the LSDB to the inbound interface.
f. If the checksum of the received LSP and that of the corresponding LSP are the
same, the LSP is not forwarded.

Figure 5-61 Process of updating the LSDB on a broadcast link

RouterA
RouterC
RouterB( DIS)
LSP
Router C.00-00
CSNP
Router A.00-00
Router B.00-00
Router B.01-00 PSNP
Router C.00-00 Router A.00-00
Router B.00-00
Router B.01-00
LSP
Router A.00-00
Router B.00-00
Router B.01-00
l Updating the LSDB on a P2P link

a. If the sequence number of the received LSP is greater than the sequence number of
the corresponding LSP in the LSDB, the router adds the LSP to its LSDB. The
router then sends a PSNP packet to acknowledge the received LSP. At last, the
router sends the LSP to all its neighbors except the neighbor that sends the LSP.
b. If the sequence number of the received LSP is smaller than the sequence number of
the corresponding LSP, the router directly sends its LSP to the neighbor and waits
for a PSNP from the neighbor as the acknowledgement.
c. If the sequence number of the received LSP is the same as the sequence number of
the corresponding LSP in the LSDB, the router compares the Remaining Lifetime
of the two LSPs. If Remaining Lifetime of the received LSP is 0, the router adds the
LSP to its LSDB. The router then sends a PSNP to acknowledge the received LSP.
If Remaining Lifetime of corresponding LSP is 0, the router directly sends its LSP
to the neighbor and waits for a PSNP from the neighbor.
d. If the sequence number of the received LSP and the corresponding LSP in the
LSDB are the same, and neither Remaining Lifetime is 0, router compares the
checksum of the two LSPs. If the received LSP has a greater checksum than that of
the corresponding LSP, the router adds the LSP to its LSDB. The router then sends
a PSNP to acknowledge the received LSP. If the received LSP has a smaller
checksum than that of the corresponding LSP, the router directly sends its LSP to
the neighbor and waits for a PSNP from the neighbor. At last, the router sends the
LSP to all its neighbors except the neighbor that sends the LSP.
e. If the checksum of the received LSP and that of the corresponding LSP are the
same, the LSP is not forwarded.
Route Calculation

When LSDB synchronization is complete and network convergence is implemented, IS-IS

performs SPF calculation by using LSDB information to obtain the SPT. IS-IS uses the SPT
to create a forwarding database, namely, establish a routing table.
In IS-IS, link costs are used to calculate shortest paths. The default cost for an interface on a
Huawei router is 10. The cost is configurable. The cost of a route is the sum of the cost of
every outbound interface along the route. There may be multiple routes to a destination,
among which the route with the smallest cost is the optimal route.
Level-1 routers can also calculate the shortest path to Level-2 routers to implement inter-area
route selection. When a Level-1-2 router is connected to other areas, the router sets the value
of the attachment (ATT) bit in its LSP to 1 to advertise this situation to neighboring routers. In
the route calculation process, a Level-1 router selects the nearest Level-1-2 router as an
intermediate router between the Level-1 and Level-2 areas.
5.8.2.3 IS-IS Routing Information Control
In practice, the routes calculated by using the shortest path first (SPF) algorithm in
Intermediate System to Intermediate System (IS-IS) cannot meet all carrier requirements. For
example, generating too many routing entries slows down route search, or link usage is
unbalanced. Because of these problems, IS-IS routing cannot meet carriers' network planning
and traffic management requirements.
Therefore, IS-IS routing information control is needed to refine control over route selection.
IS-IS routing information control is implemented by using the following methods:
l Route Leaking
l Route Summarization
l Load Balancing
l Administrative Tag
l IS-IS Mesh Group
Route Leaking
When Level-1 and Level-2 areas both exist on an IS-IS network, all Level-1 routing
information (except for default routes) can advertise to Level-2 area while Level-2 routers do
not advertise the learned routing information about a Level-1 area and the backbone area to
any other Level-1 area. Therefore, Level-1 routers do not know the routing information
outside the local area. As a result, the Level-1 routers cannot select the optimal routes to the
destination outside the area.
Route leaking allows you to define access control lists (ACLs), routing policies, and tags on
Level-1-2 routers so that Level-1-2 routers can select eligible routes. In this manner, a
Level-1-2 router can advertise some routing information about other Level-1 areas and the
backbone area to its Level-1 area. Figure 5-62 shows the typical networking for route
leaking.

Figure 5-62 Typical networking for route leaking

RouterA RouterC
Level-1 Level-1-2
cost 50
cost 10
cost 10
cost 10
RouterE RouterF
cost 10 Level-2 Level-2
cost 10
Area20
RouterB RouterD
Level-1 Level-1-2
Area10
l Router A, Router B, Router C, and Router D belong to area 10. Router A and Router B
are Level-1 routers. Router C and Router D are Level-1-2 routers.
l Router E and Router F belong to area 20 and are Level-2 routers.
If Router A sends a packet to Router F, the optimal route should be Router A -> Router B ->
Router D -> Router E -> Router F. This is because the cost of the route is 40 (10 + 10 + 10
+ 10 = 40). On Router A, view the route along which packets are transmitted to Router F. The
selected route is Router A -> Router C -> Router E -> Router F, of which the cost is 70 (10
+ 50 + 10 = 70). The route is not an optimal route from Router A to Router F.
This is because Router A does not know the routes outside the local area, so the packets sent
by Router A to other network segments are sent through the default route generated by the
nearest Level-1-2 router.
Enable route leaking on Level-1-2 routers (Router C and Router D) and view the route from
Router A to Router F. The selected route is Router A -> Router B -> Router D -> Router E ->
Router F. The route is the optimal route from Router A to Router F.
Route Summarization
On a large-scale IS-IS network, links connected to devices within an IP address range may
alternate between Up and Down. Route summarization allows multiple routes with the same
IP prefix to be summarized into one. This function prevents route flapping and efficiently
reduces routing entries, which minimizes system resource consumption and helps route
management. Figure 5-63 shows the typical networking for route summarization.

Figure 5-63 Typical networking for route summarization
Network1
172.1.1.0/24 172.1.1.1/24
RouterC Router B RouterA

L1 L1/L2 L2
172.1.2.1/24
Network2
172.1.2.0/24
Area20
Area10
172.1.3.1/24
Network3
172.1.3.0/24
l RouterA, RouterB, and RouterC use IS-IS to communicate with each other.
l RouterA belongs to area 20, and RouterB and RouterC belong to area 10.
l RouterA is a Level-2 router. RouterB is a Level-1-2 router. RouterC is a Level-1 router.
l RouterB maintains Level-1 and Level-2 link state databases (LSDBs) and leaks the
routes in three network segments (172.1.1.0/24, 172.1.2.0/24, and 172.1.3.0/24) in the
Level-1 area to the Level-2 area. A link fault causes the RouterC interface with the IP
address in the network segment 172.1.1.1/24 to frequently alternate between Up and
Down. The status change is advertised to the Level-2 area, triggering frequent Link State
Packet (LSP) flooding and SPF calculation on RouterA. As a result, the CPU usage on
RouterA increases and even network flapping occurs.
On RouterB, the summarization of the routes in three network segments (172.1.1.0/24,
172.1.2.0/24, and 172.1.3.0/24) in the Level-1 area to one route in network segment
172.1.0.0/16 reduces the number of routing entries on RouterB and minimizes the impact
of route flapping in the Level-1 area on route convergence in the Level-2 area.
Load Balancing
In the presence of multiple equal-cost routes on a network, load balancing improves link
usage and prevents network congestion caused by link overload. Load balancing is
implemented by distributing traffic evenly over multiple equal-cost links. Figure 5-64 shows
the typical networking for load balancing.

Figure 5-64 Typical networking for load balancing
Area10
RouterB
L2
RouterA RouterD
L2 L2
RouterC
L2
l Router A, Router B, Router C, and Router D communicate with each other on an IP

network using IS-IS.
l Router A, Router B, Router C, and Router D belong to area 10 and are Level-2 routers.
l If load balancing is not enabled, traffic on Router A is transmitted along the optimal
route after SPF calculation. Consequently, traffic on different links is unbalanced.
Enabling load balancing on Router A sends traffic to Router D through Router B and
Router C. This transmission mode relieves the load on the optimal route.
Administrative Tag
Administrative tags carry administrative information about IP address prefixes. When the cost
type is wide, wide-compatible, or compatible and the prefix of the reachable IP address to be
advertised by IS-IS has this cost type, IS-IS adds the administrative tag to the reachability
type-length-value (TLV) in the prefix. In this manner, the administrative tag is advertised
throughout the entire IS-IS area, which implements route import or filtering.
IS-IS Mesh Group

As defined in IS-IS, a router must flood the received LSP to all neighbors. On a network with
multiple connections and point-to-point (P2P) links, this flooding method causes repeated
LSP flooding and wastes bandwidth.
To avoid this situation, you can add certain interfaces to a mesh group. These interfaces do
not flood the LSPs received from a group to other interfaces in the same group, but flood
them outside the group or to the interfaces that are not configured with the mesh group. All
the interfaces that join a mesh group ensure the synchronization of the LSDBs in the entire
network segment by using the complete sequence numbers protocol data unit (CSNP) and
partial sequence numbers protocol data unit (PSNP) mechanisms.
5.8.2.4 IS-IS Multi-instance and Multi-process
For the routers that support the VPN, you can associate each IS-IS process with a specific
VPN instance. Therefore, you can configure multiple IS-IS processes to be associated with
multiple VPN instances at the same time.

l IS-IS multi-instance indicates that you can configure multiple IS-IS instances on the
same router.
l IS-IS multi-process indicates that you can create multiple IS-IS processes in a VPN or a
public network. As shown in Figure 5-65.
– The multi-process feature allows a set of interfaces to be associated with a specific
IS-IS process. This ensures that the specific IS-IS process performs all the protocol
operations only on the set of interfaces. Therefore, multiple IS-IS processes can
work on a single router and each process is responsible for a unique set of
interfaces.
– IS-IS multi-processes share an RM routing table. IS-IS multi-instances use the RM
routing tables of VPNs. Each VPN has its own RM routing table.
– When an IS-IS process is created, it can be associated with a VPN instance. Then,
the IS-IS process belongs to the VPN and processes events only in the VPN. The
IS-IS process is deleted when the associated VPN is deleted.
Figure 5-65 Networking diagram for IS-IS multi-instance and multi-process
vpn1
vpn2
vpn2
vpn1
Process1
Process2 vpn2
vpn1
For easy management and effective control, IS-IS supports multi-process and multi-instance
features.
In the scenario where IS-IS is applied to users on private networks, after a VPN is created,
interfaces bound to the VPN and routes in the VPN are isolated from other VPNs and public
network data. In this case, you can adopt IS-IS multi-instance to deploy IS-IS in the VPN.
For the routers that support the VPN, each IS-IS process is associated with a specific VPN
instance. All the interfaces attached to an IS-IS process, therefore, should be associated with
the VPN instance that this IS-IS process is associated to.
At present, the VPN instance is maintained by the VPN module. Therefore, IS-IS multi-
instance is implemented by associating an IS-IS process with a VPN instance when the IS-IS
process is created.
When configuring IS-IS multi-instance and multi-process, note the following:
l When creating IS-IS multi-instances, associate an IS-IS process with a VPN instance
when the IS-IS process is created. If an IS-IS process is not associated with a VPN
instance when the IS-IS process is created, the association cannot be configured later.

l An IS-IS process that is already associated with a VPN instance cannot be associated
with another VPN instance.
l Multiple IS-IS processes can be associated with one VPN instance.
l The interfaces where IS-IS multi-instance needs to be enabled must be associated with
the same VPN instance as IS-IS.
l The IS-IS process associated with a VPN instance belongs to the VPN. Therefore, the IS-
IS process is deleted when the VPN is deleted.
l Routes from different VPNs cannot be imported to each other.
5.8.2.5 IS-IS Fast Convergence
IS-IS fast convergence is an extended feature of IS-IS that is implemented to speed up the
convergence of routes. Fast convergence includes the following:
l Incremental SPF (I-SPF): recalculates only the routes of the changed nodes rather than
all the nodes when the network topology changes. This speeds up the calculation of
routes.
l Partial Route Calculation (PRC): calculates only the changed routes when the routes on
the network change.
l LSP fast flooding: speeds up the flooding of LSPs.
l Intelligent timer: is applicable to LSP generation and SPF calculation.
The first timeout period of the timer is fixed. If an event that triggers the timer happens
while the timer is set and unexpired, intelligent timer increases the interval it sets for
next time.
I-SPF
In ISO 10589, the Dijkstra algorithm was adopted to calculate routes. When a node changes
on the network, this algorithm is used to recalculate all routes. The calculation takes a long
time and consumes too many CPU resources, which affects the convergence speed.
I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all
nodes are involved in calculation. The shortest path tree (SPT) generated is the same as that
generated by the previous algorithm. This decreases CPU usage and speeds up network
convergence.
PRC
Similar to I-SPF, PRC calculates only the changed routes, but it does not calculate the shortest
path. It updates routes based on the SPT calculated by I-SPF.
In route calculation, a leaf represents a route, and a node represents a router. If the SPT
changes after I-SPF calculation, PRC processes all the leaves only on the changed node. If the
SPT remains unchanged, PRC processes only the changed leaves.
For example, if IS-IS is enabled on an interface of a node, the SPT calculated by I-SPF
remains unchanged. PRC updates only the routes of this interface, consuming less CPU
resources.
PRC working with I-SPF further improves the convergence performance of the network. It is
an improvement of the original SPF algorithm.

NOTE
In the implementation of a device, only I-SPF and PRC are used to calculate IS-IS routes.
LSP Fast Flooding

When IS-IS receives new LSPs from other routers, it updates the LSPs in the LSDB and
periodically floods out the updated LSPs based on a timer.
LSP fast flooding improves on the PRC mode. When the device configured with this feature
receives one or more new LSPs, before it calculates routes, it floods out the LSPs whose
amount is smaller than the specified number. Network convergence speed is significantly
improved.
Intelligent Timer
Although the route calculation algorithm is improved, the long interval for triggering route
calculation affects the convergence speed. Frequent network changes also consume too many
CPU resources. The SPF intelligent timer addresses both of these problems.
In general, an IS-IS network is stable under normal conditions. The probability of the
occurrence of many network changes is very minimal, and IS-IS does not calculate routes
frequently. The period for triggering the route calculation is very short (milliseconds). If the
topology of the network changes very often, the intelligent timer increases the interval for the
calculation times to avoid too much CPU consumption. The original mechanism uses a timer
with uniform intervals, which makes fast convergence and low CPU consumption impossible
to achieve.
The LSP generation intelligent timer is similar to the SPF intelligent timer. When the LSP
generation intelligent timer expires, the system generates a new LSP based on the current
topology. The LSP generation timer is designed as an intelligent timer to respond to
emergencies (such as the interface is Up or Down) quickly and speed up the network
convergence.
5.8.2.6 Priority-based IS-IS Convergence
Priority-based IS-IS convergence ensures that specific routes converge first in the case of a
great number of routes. Different routes can be set with different convergence priorities.
Priority-based IS-IS convergence enables specific routes (such as routes that match the
specified IP prefix) to converge first. You can assign a high convergence priority to routes for
key services so that these routes converge quickly. This decreases impact on key services and
improves network reliability.
5.8.2.7 IS-IS LSP Fragment Extension
When the LSPs to be advertised by IS-IS contain much information, they are advertised in
multiple LSP fragments of the same system. The IS-IS LSP fragment extension attribute
allows an IS-IS router to generate more LSP fragments and carry more IS-IS information.
As defined in RFC 3786, virtual system IDs can be configured and virtual LSPs that carry
routing information can be generated for IS-IS.

Terms
l Originating system: is a router that runs the IS-IS protocol. A single IS-IS process can
advertise its LSPs as multiple "virtual" routers, and the originating system represents the
"real" IS-IS process.
l Normal system ID: is the system ID of the originating system.
l Additional system ID: assigned by network administrators, is used to generate additional
or extended LSP fragments. Up to 256 additional or extended LSP fragments can be
generated. Like the normal system ID, the additional system ID must be unique in the
routing domain.
The additional system ID, assigned by network administrators, is used to generate
additional or extended LSP fragments. Up to 256 additional or extended LSP fragments
can be generated. Like the normal system ID, the additional system ID must be unique in
the routing domain.
l Virtual system: identified by an additional system ID, is used to generate extended LSP
fragments. These fragments carry the additional system IDs in their LSP IDs.
Principle
IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. The LSP
Number field is 1 byte. An IS-IS process can generate a maximum of 256 fragments that carry
a limited number of routes (when the fragment length is 1497 bytes, a maximum of 30,000
routes can be carried). With fragment extension, more information can be carried.
With additional system IDs (up to 50 virtual systems), an IS-IS process can generate a
maximum of 13056 LSP fragments.
When a virtual system and fragment extension are configured, an IS-IS router adds the
contents that cannot be contained in the LSPs advertised by the originating system to the
LSPs of the virtual system. The router notifies other routers of the relationship between the
virtual system and itself through a special TLV.
IS Alias ID TLV
A special TLV, IS Alias ID TLV, is defined in RFC 3786.
Table 5-55 IS Alias ID TLV

Type 1 byte Indicates the TLV type. If the value is 24, it

indicates the IS Alias ID TLV.
Length 1 byte Indicates the length of Value in the TLV.
System ID 6 bytes System ID
Pseudonode 1 byte pseudonode number

number
sub-TLVs 1 byte sub-TLVs length

length
sub-TLVs 0 to 247 bytes sub-TLVs

Regardless of the operation mode, the originating system and virtual system send the LSPs
with fragment number 0 carrying the IS Alias ID TLV to indicate the originating system.
Operation Modes
Figure 1 shows the networking for the LSP fragment extension feature, which can be run in
two different modes.
Figure 5-66 LSP fragment extension
RouterA 1
RouterB RouterA
RouterA 2
l The IS-IS router can run the LSP fragment extension feature in the following modes:
Mode-1: is used when some routers on the network do not support the LSP fragment
extension.
In this mode, virtual systems participate in the SPF calculation. The originating system
advertises LSPs that contain information about the links to each virtual system.
Similarly, each virtual system advertises LSPs that contain information about the links to
the originating system. This allows the virtual systems to appear to be like the actual
routers connected to the originating system on the network.
Mode-1 is a transitional mode for earlier IS-IS versions that do not support fragment
extension. In the earlier versions, IS-IS cannot identify the Alias ID TLV. The LSP sent
by a virtual system appears to be like a common IS-IS LSP.
The LSP sent by a virtual system contains the same area address and overload bit as that
in the common LSP. If the LSPs sent by a virtual system contain TLVs specified in other
features, they must be the same as those in common LSPs.
The virtual system carries neighbor information that specifies that the neighbor is the
originating system, with the metric being the maximum value minus 1. The originating
system carries neighbor information that specifies that the neighbor is the virtual system,
with the metric of 0. This ensures that the virtual system is the downstream node of the
originating system when other routers calculate routes.
As shown in Figure 5-66, RouterB does not support the LSP fragment extension;
RouterA is set to support the LSP fragment extension in mode-1; RouterA1 and
RouterA2 are virtual systems of RouterA. In this example, RouterA1 and RouterA2 send
LSPs carrying routing information of RouterA. After receiving LSPs from RouterA,
RouterA1, and RouterA2, RouterB detects that there are three individual routers at the

peer end and calculates routes normally. Because the cost of the route from RouterA to
RouterA1 and the cost of the route from RouterA to RouterA2 are both 0, the cost of the
route from RouterB to RouterA is equal to the cost of the route from RouterB to
RouterA1.
l Mode-2: is used when all routers on the network support LSP fragment extension.
In this mode, virtual systems do not participate in the SPF calculation. All routers on the
network detects that the LSPs generated by the virtual systems actually belong to the
originating system.
Working in mode-2, IS-IS identifies IS Alias ID TLV, which is used to calculate the SPT
and routes.
As shown in Figure 5-66, RouterB supports the LSP fragment extension; RouterA is set
to support the LSP fragment extension in mode-2; andRouterA1 and RouterA2 send
LSPs carrying routing information of RouterA. When receiving LSPs from RouterA1
and RouterA2, RouterB obtains IS Alias ID TLV and detects that the originating system
of RouterA1 and RouterA2 is RouterA. RouterB detects that information advertised by
RouterA1 and RouterA2 belongs to RouterA.
Whether LSP fragment extension is set to mode-1 or mode-2, LSPs in both modes can be
resolved. If LSP fragment extension is not supported, only LSPs in mode-1 can be resolved.
Table 5-56 Comparison between LSP fragment extension mode-1 and mode-2
LSP Content\Mode Mode-1 Mode-2
IS Alias ID Yes Yes
area Yes No
overload bit Yes Yes
IS NBR/IS EXTENDED NBR Yes No
Routing Yes Yes
ATT bits must be 0 must be 0
P bit must be 0 must be 0
Process
After LSP fragment extension is configured, if information is lost because LSPs are of full
lengths, the system prompts that the IS-IS router should be restarted. After the router is
restarted, the originating system loads as much routing information as possible. The
remaining information is added to the LSPs of the virtual systems for transmission.
NOTE
If there are devices of other manufacturers on the network, LSP fragment extension must be set to
mode-1. Otherwise, devices of other manufacturers cannot identify the LSPs.
Configure the LSP fragment extension and virtual systems before you set up IS-IS neighbors
or import routes. Then you must restart the IS-IS router for the configurations to take effect. If

you set up IS-IS neighbors or import routes first, it can cause IS-IS to carry more information
than cannot be loaded through 256 fragments
5.8.2.8 Dynamic Hostname Exchange Mechanism
The dynamic hostname exchange mechanism provides a mapping from the hostname to
system ID for IS-IS routers.
On an IS-IS router without hostname exchange, information about IS-IS neighbors and
LSDBs is represented by a system ID with 12 hexadecimal numbers, for example, aaaa.eeee.
1234. This representation is complicated and not easy to use.
To easily maintain and manage IS-IS networks easily, the dynamic hostname exchange
mechanism was introduced.
Dynamic hostname information is advertised in the form of a dynamic hostname TLV (type
137) in LSPs. The dynamic hostname exchange mechanism also provides a service to
associate a host name with the Designated IS (DIS) on a broadcast network. Then, this
mechanism advertises this association through LSPs in the form of a dynamic hostname TLV.
In the implementation of FW, routers with IS-IS dynamic hostname mapping enabled add the
Dynamic Hostname TLV (TLV type 137) that records the local host name to the LSPs they
generate before sending out the LSPs.
Dynamic Hostname TLV (TLV type 137) includes the following fields:
l Type: indicates the dynamic hostname exchange mechanism.

l Length: indicates the total length of the value field.
l Value: indicates a character string of 1 to 255 characters.
The Dynamic Hostname TLV is optional and can be inserted anywhere in an LSP. The
hostname value cannot be null. A router determines whether to carry the TLV in LSPs it
sends. The router that receives the LSPs determines whether to ignore the TLV or obtain the
TLV for its mapping table.
Implementation
l Matching rules
The dynamic hostname mechanism abides by the longest match rule. First, System ID
+NSEL is first compared. If that does not match, the system ID is then compared.
l Transmission of dynamic hostname
The dynamic hostname can be carried by the original LSP only.
l Transmission of DIS dynamic hostname
The DIS dynamic hostname is transmitted through the LSPs generated by the DIS.
l Priority of dynamic hostname
The dynamic hostname takes precedence over the static hostname. When both a dynamic
hostname and a static hostname are configured, the dynamic hostname replaces the static
hostname.
l Configuration and resolution of dynamic hostname
The dynamic hostname can be up to 64 bytes in length and a maximum of 255-byte
contents can be resolved.

In maintenance and management, the hostname is easier to identify and retain than the system
ID. After this function is configured, the hostname instead of the system ID is displayed when
you view information about IS-IS on the router.
The hostname exchange mechanism implemented on the FW includes dynamic hostname

mapping and static hostname mapping. The system ID is replaced by the hostname in the
following cases:
l When an IS-IS neighbor is displayed, the system ID of the IS-IS neighbor is replaced by
the dynamic hostname. If the IS-IS neighbor is the DIS, then the system ID of the DIS is
replaced by the dynamic hostname of the neighbor.
l When an LSP in the IS-IS LSDB is displayed, the system ID in the LSP ID is replaced
by the dynamic hostname of the router that advertises the LSP.
l When details about the IS-IS LSDB are displayed, the Host Name field is included for
the LSP generated by the router where dynamic hostname exchange is enabled; the
system ID is replaced by the dynamic hostname of the IS-IS neighbor.
5.8.2.9 IS-IS Wide Metric
A small range of metrics cannot meet the requirements of large-scale networks.
In the earlier ISO 10589, the greatest value of an interface metric was only 63. TLV type 128
and TLV type 130 contained information about routes; TLV type 2 contained information
about IS-IS neighbors.
As defined in RFC 3784, the value of an interface metric can be extended to 16777215, and
the metric of a route can reach 4261412864. With IS-IS wide metric enabled, TLV type 135
contains information about routes; TLV type 22 contains information about IS-IS neighbors.
l The following TLVs are used in narrow mode:
– IP Internal Reachability: carries internal routes.
– IP External Reachability: carries external routes.
– IS Neighbors: carries information about neighbors.
l The following TLVs are used in wide mode:
– Extended IP Reachability: replaces the earlier IP reachability TLV and carries
information about routes. This TLV expands the range of route cost to 4 bytes and
carries sub-TLVs.
– IS Extended Neighbors: carries information about neighbors.
NOTE
IS-IS in wide mode and IS-IS in narrow mode cannot communicate. If IS-IS in wide mode and IS-IS in
narrow mode need to communicate, you must change the mode to enable all routers on the network to
receive packets sent by other routers.
Table 5-57 Receiving and sending modes

Mode\Receiving and Receiving Sending
Sending
narrow narrow narrow

Mode\Receiving and Receiving Sending

Sending
narrow-compatible narrow&wide narrow
compatible narrow&wide narrow&wide
wide-compatible narrow&wide wide
wide wide wide
When the cost-style is set to compatible, IS-IS sends the information in narrow mode and then
in wide mode.
NOTICE
A cost-style change causes the IS-IS process to restart. Be cautious in your use of the cost-
style command.
l Changing the sending mode from narrow to wide

The information that used to be carried by TLV type 128, TLV type 130, and TLV type 2
is now carried by TLV type 135 and TLV type 22.
l Changing the sending mode from wide to narrow
The information that used to be carried by TLV type 135 and TLV type 22 is now carried
by TLV type 128, TLV type 130, and TLV type 2.
l Changing the sending mode from narrow/wide to narrow&wide
The information that used to be carried in narrow/wide mode is now carried by TLV type
128, TLV type 130, TLV type 2, TLV type 135, and TLV type 22.
5.8.2.10 IS-IS GR
IS-IS Graceful Restart (GR) implements non-stop forwarding by extending IS-IS to support
the GR capability. It is one of the high availability (HA) technologies. RFC 3847 defines the
IS-IS GR standard.
IS-IS is a link state routing protocol. All routers in an area must maintain the same network
topologies, that is, the same LSDBs.
After the master/slave switchover, no neighbor information is stored on the restarted router.
Thus, the first Hello packets sent by the router do not contain the neighbor list. After
receiving the Hello packets, the neighbor checks the 2-way neighbor relationship and finds
that it is not in the neighbor list of the Hello packets sent by the router. Thus, the neighbor
relationship is interrupted.
The neighbor then generates new LSPs and floods the topology changes to all other routers in
the area. Routers in the area then calculate routes based on the new LSDBs, which leads to
route interruption or routing loops.
Because no LSDB is stored on the restarted router, the router needs to synchronize its LSDB
with those of the neighbors after the master/slave switchover.

If IS-IS is not restarted in GR mode, IS-IS neighbor relationships are reset and LSPs are
regenerated and flooded. This triggers the SPF calculation in the entire area, which causes
route flapping and forwarding interruption in the area.
The IETF defined the GR standard, RFC 3847, for IS-IS. The restart of the protocol is
processed for both the reserved FIB tables and unreserved FIB tables. Thus, the route flapping
and interruption of the traffic forwarding caused by the restart can be avoided.
When a router fails, neighbors at the routing protocol layer detect that their neighbor
relationships are Down and then become Up again after a period of time. This is the flapping
of neighbor relationships. The flapping of neighbor relationships causes route flapping, which
leads to black hole routes on the restarted router or causes data services from the neighbors to
be looped on the restarted router. This decreases the reliability on the network. GR is thus
introduced to address route flapping.
Basic Concepts of IS-IS GR

IS-IS GR involves two roles, namely, GR restarter and GR helper.
l GR restarter
The GR restarter refers to the router that restarts in GR mode.
l GR- helper
The GR helper refers to another GR router that helps the restarter to complete the GR
process. The GR restarter must have the capability of the GR helper.
NOTE
By default, the device supports the GR helper.
To implement GR, IS-IS introduces the restart Type-Length-Value (TLV), T1 timer, T2 timer,
and T3 timer.
Restart TLV
The restart TLV is an extended part of an IS-to-IS Hello (IIH) PDU. All IIH packets of the
router that supports IS-IS GR contains the restart TLV. The restart TLV carries the parameters
for the protocol restart. Figure 5-67 shows the format of the restart TLV.
Figure 5-67 Format of the Restart TLV

0 1 2 3 4 5 6 7
Type(211)
Length(1 to 9)
Reserved SA RA RR
Remaining Time
Restarting Neighbor System ID

Table 5-58 describes the fields of the restart TLV.
Table 5-58 Description of the fields of the restart TLV

Type 1 byte Indicates the TLV type. If the value is 211,

the TLV is the restart TLV.
Length 1 byte Indicates the length of the TLV.
RR 1 bit Indicates the restart request bit. A router

sends an RR packet to notify the neighbors of
its restarting or starting and to require the
neighbors to retain the current IS-IS
adjacency and return CSNPs.
RA 1 bit Indicates the restart acknowledgement bit. A

router sends an RA packet to respond to the
RR packet.
SA 1 bit Indicates the suppress adjacency

advertisement bit. The starting router uses an
SA packet to require its neighbors to suppress
the broadcast of their neighbor relationships
to prevent routing loops.
Remaining Time 2 bytes Indicates the time during which the neighbor
does not reset the adjacency. The length of
the field is 2 bytes. The time is measured in
seconds. When RA is reset, the value is
mandatory.
Restarting 6 bytes Indicates the system ID of the neighboring

Neighbor System router that responds to the RA packet.
ID
Timers
Three timers are introduced to enhance IS-IS GR. They are T1, T2, and T3 timers.
l T1
Any interface enabled with IS-IS GR maintains a T1 timer. On a Level-1-2 router,
broadcast interfaces maintain a T1 timer for Level-1 and Level-2 neighbor relationships
respectively.
If the GR restarter has already sent an IIH packet with RR being set but does not receive
any IIH packet that carries the restart TLV and the RA set from the GR helper even after
the T1 timer expires, the GR restarter will reset the T1 timer and continues to send the
restart TLV.
If the ACK packet is received or the T1 timer expires for three times, the T1 timer is
deleted. The default value of a T1 timer is 3 seconds.
l T2
Level-1 and Level-2 LSDBs maintain separate T2 timers.

T2 is the maximum time that the system waits for the synchronization of various LSDBs.
T2 is generally 60 seconds.
l T3
The entire system maintains a T3 timer.
T3 timer can be considered as the maximum time for GR to complete.
If the T3 timer expires, GR fails.
The initial value of the T3 timer is 65535 seconds. After the IIH packets that carry the
RA are received from neighbors, the value of the T3 timer becomes the smallest value of
the Remaining Time field among the Remaining Time fields of the IIH packets.
The T3 timer applies to only restarting devices.
Session Mechanism of IS-IS GR

For differentiation, GR triggered by the master/slave switchover or the restart of an IS-IS
process is referred to as restarting. In this case, the FIB table remains unchanged. GR
triggered by router restart is referred to as starting. In this case, the FIB table is updated.
The following describes the process of IS-IS GR in restarting and starting modes:
IS-IS Restarting
Figure 5-68 shows the process of IS-IS restarting.
Figure 5-68 Process of IS-IS restarting

GR Restarter GR Helper
Active/standby
switchover
IIH(Restart TLV, RR=1, RA=0, SA=0)
Start T1, T2,
and T3 timers IIH(Restart TLV, RR=0, RA=1, SA=0)
Reset T3 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Flood LSPs Update the
Delete T3 timer and
Update the FIB table FIB table
1. After performing the protocol restart, the GR restarter performs the following actions:

– Starts T1, T2, and T3 timers.

– Sends IIH packets that contain the restart TLV from all interfaces. In such a packet,
RR is set to 1, and RA and SA are set to 0.
2. After receiving an IIH packet, the GR helper performs the following actions:
– Maintains the neighbor relationship and refreshes the current Holdtime.
– Replies an IIH packet containing the restart TLV. In the packet, RR is set to 0; RA is
set to 1, and the value of the Remaining Time field indicates the period from the
current moment to the timeout of the Holdtime.
– Sends CSNPs and all LSPs to the GR restarter.
NOTE
l On a P2P link, a neighbor must send CSNPs.

l On a LAN link, only the neighbor of the DIS sends CSNPs. If the DIS is restarted, a temporary
DIS is elected from the other routers on the LAN.
If the GR helper does not support GR, it ignores the restart TLV and resets the adjacency
with the GR restarter according to the normal processing of IS-IS.
3. After the GR restarter receives the IIH response packet, in which RR is set to 0 and RA
is set to 1, from the neighbor, it performs the following actions:
– Compares the current value of the T3 timer with the value of the Remaining Time
field in the packet. The smaller one is taken as the value of the T3 timer.
– Deletes the T1 timer maintained by the interface that receives the ACK packet and
CSNPs.
– If the interface does not receive the ACK packet or CSNPs, the GR restarter
constantly resets the T1 timer and resends the IIH packet that contains the restart
TLV. If the number of the timeouts of the T1 timer exceeds the threshold value, the
GR restarter forcibly deletes the T1 timer and turns to the normal IS-IS processing
to complete LSDB synchronization.
4. After the GR restarter deletes the T1 timers on all interfaces, the synchronization with all
neighbors is complete when the CSNP list is cleared and all LSPs are collected. The T2
timer is then deleted.
5. After the T2 timer is deleted, the LSDB of the level has been synchronized.
– In the case of a Level-1 or Level-2 router, the SPF caculation is triggered.
– In the case of a Level-1-2 router, determine whether the T2 timer on the router of
the other level is also deleted. If both the T2 timers are deleted, the SPF calculation
is triggered. Otherwise, the router waits for the T2 timer of the other level to expire.
6. After all T2 timers are deleted, the GR restarter deletes the T3 timer and updates the FIB
table. The GR restarter re-generates the LSPs of each level and floods them. During the
LSDB synchronization, the GR restarter deletes the LSPs generated before GR.
7. So far, the IS-IS restarting of the GR restarter is complete.
IS-IS Starting
The starting device does not keep the FIB table. Thus, the starting device hopes the neighbors,
whose adjacency with itself is Up before it starts, reset their adjacency, and suppress the
neighbors from advertising their adjacency. The IS-IS starting process is different from the IS-
IS restarting process, as shown in Figure 5-69.

Figure 5-69 Process of IS-IS starting

GR Restarter GR Helper
Starting
Start T2 timer for IIH(Restart TLV, RR=0, RA=0, SA=1)

various LSPDBs
Restablish the adjacency relationship
Start T1 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Update the Flood LSPs Update the

FIB table FIB table
1. After the GR restarter is started, it performs the following actions:

– Starts the T2 timer for the synchronization of LSDBs of each level.
– Sends IIH packets that contain the restart TLV from all interfaces. In such a packet,
RR is set to 0, and SA is set to 1.
If RR is set to 0, a router is started.
If SA is set to 1, the router requests its neighbor to suppress the advertisement of
their adjacency before the neighbor receives the IIH packet in which SA is set to 0.
2. After the neighbor receives the IIH packet that carries the restart TLV, it performs the
following actions according to whether GR is supported:
– GR is supported.
Re-initiates the adjacency.
Deletes the description of the adjacency with the GR restarter from the sent LSP.
The neighbor also ignores the link connected to the GR restarter when performing
SPF calculation until it receives an IIH packet in which SA is set to 0.
– GR is not supported.
Ignores the restart TLV and resets the adjacency with the GR restarter.
Replies an IIH packet that does not contain the restart TLV. The neighbor then turns
to the normal IS-IS processing. In this case, the neighbor does not suppress the
advertisement of the adjacency with the GR restarter. On a P2P link, the neighbor
also sends a CSNP.

3. After the adjacency is re-initiated, the GR restarter re-establishes the adjacency with the
neighbors on each interface. When an adjacency set on an interface is in the Up state, the
GR restarter starts the T1 timer for the interface.
4. After the T1 timer expires, the GR restarter sends an IIH packet in which both RR and
SA are set to 1.
5. After the neighbor receives the IIH packet, it replies an IIH packet in which RR is set to
0 and RA is set to 1 and sends a CSNP.
6. After the GR restarter receives the IIH ACK packet and CSNP from the neighbor, it
deletes the T1 timer.
If the GR restarter does not receive the IIH packet or CSNP, it constantly resets the T1
timer and resends the IIH packet in which RR and SA are set to 1. If the number of the
timeouts of the T1 timer exceeds the threshold value, the GR restarter forcibly deletes
the T1 timer and turns to the normal IS-IS processing to complete LSDB
synchronization.
7. After receiving the CSNP from the helper, the GR restarter synchronizes the LSDB.
8. After the LSDB of this level is synchronized, the T2 timer is deleted.
9. After all T2 timers are deleted, the SPF calculation is started and LSPs are regenerated
and flooded.
10. So far, the IS-IS starting of the GR restarter is complete.
5.8.2.11 BFD for IS-IS
BFD functions as a simple "Hello" protocol. It is similar to the adjacency test of a routing
protocol in many aspects.
Two systems periodically send BFD packets on the path between them. If one system does not
receive any BFD packet from its peer within the detection period, the system considers that
the bidirectional path to its peer is faulty. Under some conditions, systems need to negotiate
the sending and receiving rates to reduce the load.
BFD is classified into static BFD and dynamic BFD.
NOTE
BFD uses the local discriminator and remote discriminator to differentiate multiple BFD sessions
between the same pair of systems.
l Static BFD
In static BFD, BFD session parameters including local and remote discriminators are set
through commands, and the requests for establishing BFD sessions are manually
delivered.
l Dynamic BFD(including BFD for IPv4BFD for IPv6)
In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols.
The local discriminator is dynamically assigned, and the remote discriminator is learned
by a routing protocol.
BFD-for-IPv4 sessions and BFD-for-IPv6 sessions are established separately and do not
affect each other.
In BFD for IS-IS, the establishment of a BFD session is dynamically triggered by IS-IS
instead of being performed manually. When detecting a fault, BFD notifies IS-IS of the fault
through the RM module. IS-IS then sets the status of the associated neighbor relationship to

Down, rapidly advertises the changed Link State PDU (LSP), and performs incremental SPF.
In this manner, fast route convergence is implemented.
Generally, the interval for sending Hello packets is set to 10s. The interval for advertising that
a neighbor is Down, that is, the Holddown time for keeping the neighbor relationship, is three
times the interval for sending Hello packets. If a router does not receive any Hello packet
from its neighbor within the Holddown time, the router deletes the associated neighbor
relationship.
A router can detect a neighbor fault at only the second level. As a result, a large number of
packets may be lost on a high-speed network.
BFD, which can provide link fault detection of light load and high speed (in milliseconds), is
introduced to solve the preceding problem.
BFD can provide millisecond-level fault detection. BFD does not take the place of the Hello
mechanism of IS-IS, but works with IS-IS to more quickly detect the faults that occur on
neighboring devices or links, and instructs IS-IS to recalculate routes to correctly guide packet
forwarding.
Static BFD
In static BFD, BFD session parameters including local and remote discriminators are set
through commands, and the requests for establishing BFD sessions are manually delivered.
In this mode, the creation and deletion of BFD sessions need to be triggered manually, which
is inflexible. Moreover, manual configuration errors may occur, for example, the local
discriminator and the remote discriminator are incorrectly configured, which causes the
abnormal functioning of the BFD session.
Dynamic BFD
In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols.The
establishment of a BFD-for-IPv4 session is triggered by IS-IS when an IPv4 neighbor
relationship is set up.The establishment of a BFD-for-IPv6 session is triggered by IS-IS when
an IPv6 neighbor relationship is set up.
When setting up a new neighbor relationship, IS-IS sends parameters of the neighbors and
detection parameters (including source and destination IP addresses) to BFD. BFD then sets
up a session according to the received parameters. Dynamic BFD is more flexible than static
BFD.
The RM module provides related services for the association with the BFD module for IS-IS.
Through RM, IS-IS instructs BFD to set up or tear down BFD sessions by sending
notification messages. In addition, BFD events are transmitted to IS-IS through RM.
Establishment and Deletion of BFD Sessions

l Conditions for setting up a BFD session
– Basic IS-IS functions are configured on each router and IS-IS is enabled on the
interfaces of the routers.
NOTE
On an IPv6 network, basic IS-IS IPv6 functions need to be configured.

– BFD is enabled on each router, and BFD for IPv4 or BFD for IPv6 is enabled on
interfaces or processes of the routers.

– BFD for IPv4 or BFD for IPv6 is enabled on interfaces or processes, and the status
of the neighboring router is Up (the DIS must be elected on a broadcast network).
– Neighbors can adopt IPv4 and IPv6.
l Process of setting up a BFD session
– P2P network
After the conditions for setting up a BFD session are satisfied, IS-IS instructs BFD
through RM to directly set up a BFD session between neighbors.
– Broadcast network
After the conditions for establishing BFD sessions are met, and the DIS is elected,
IS-IS instructs BFD through RM to establish a BFD session between the DIS and
each router. No BFD session is established between non-DISs.
On a broadcast network, the routers (including non-DIS routers) of the same level on the
same network segment can set up neighbor relationships. In the implementation of IS-IS
BFD, however, BFD sessions are set up between the DIS and non-DIS devices rather
than between non-DISs. On a P2P network, BFD sessions are directly set up between
neighbors.
If a Level-1-2 neighbor relationship is set up between two routers on a link, IS-IS sets up
two BFD sessions for the Level-1 neighbor and the Level-2 neighbor on a broadcast
network, but sets up only one BFD session on a P2P network.
l If the IP protocol type of neighbors includes IPv4 and IPv6, IS-IS sets up two sessions: a
BFD-for-IPv4 session and a BFD-for-IPv6 session. The IPv6 link-local addresses of the
related interfaces are used to set up the BFD-for-IPv6 session.
l Conditions for tearing down a BFD session
– P2P network
When a neighbor relationship set up on P2P interfaces by IS-IS is torn down (that
is, the neighbor relationship is not in the Up state) or when the IP protocol type of a
neighbor is deleted, IS-IS tears down the BFD session.
– Broadcast network
When a neighbor relationship set up on P2P interfaces by IS-IS is torn down (that
is, the neighbor relationship is not in the Up state)when the IP protocol type of a
neighbor is deleted, or when the DIS is re-elected, IS-IS tears down the BFD
session.
When the configurations of a dynamically established BFD session are deleted or BFD
for IS-IS is disabled on an interface, all BFD sessions to which neighbor relationships
between devices or between devices and the DIS correspond on the interface are deleted.
After dynamic BFD is globally disabled in an IS-IS process, the BFD sessions on all the
interfaces in this IS-IS process are deleted.
NOTE
BFD detects only one-hop links between IS-IS neighbors, because IS-IS establishes only one-hop
l Response to the Down event of a BFD session
When detecting a link failure, BFD generates a Down event, and then notifies RM of the
event. RM then instructs IS-IS to deletes the neighbor relationship. IS-IS recalculates
routes to speed up route convergence on the entire network. After BFD for IPv4 informs
IS-IS of the link failure, IS-IS changes only the IPv4 route.After BFD for IPv6 notifies
IS-IS of the link failure, IS-IS changes only the IPv6 route.

When a router and its neighbor are Level-1-2 routers, they set up two neighbor
relationships, that is, the Level-1 neighbor relationship and the Level-2 neighbor
relationship. Then, IS-IS sets up two BFD sessions for the Level-1 neighbor relationship
and the Level-2 neighbor relationship. In this case, the RM module deletes the neighbor
relationship of a specific level.
NOTE
BFD needs to be configured according to the actual network environment. If timer parameters are set
improperly, network flapping may occur.
BFD for IS-IS can fast sense link changes to implement route convergence.
Figure 5-70 Networking diagram of BFD for IS-IS
FW_A Switch FW_B
Primary path
Backup path
FW_C

l Enable IS-IS on the routers, as shown in Figure 1.
NOTE
Before configuring BFD for IS-IS IPv6, you need to configure IS-IS IPv6.
l Enable BFD globally.
l Enable BFD for IS-IS on Router A and Router B.
Thus, when the link between Router A and Router B becomes faulty, BFD can fast detect the
fault and then notify it to IS-IS. IS-IS then turns the neighbor relationship on the interface
Down and deletes the IP protocol type to which the neighbor relationship corresponds, which
triggers route calculation. In addition, IS-IS updates LSPs so that the neighbors such as
Router C can receive updated LSPs from Router B. Fast convergence of IS-IS is thus
implemented.
5.8.2.12 IS-IS Authentication
Background
Internet development brings more frequent data, voice, and video information exchange over
the Internet. New services, such as e-commerce, online conferencing and auctions, video on

demand, and distance learning, emerge gradually. The new services have high requirements
for network security. Carriers must guarantee that data packets are not monitored and
modified by attackers and prohibit the access of unauthorized users. Intermediate System to
Intermediate System (IS-IS) authentication applies to the area or interface where packets need
to be protected to ensure packet transmission security. Using IS-IS authentication enhances
system security and helps carriers provide safe network services.
Related Concepts
Authentication Classification
Based on the types of packets, the authentication is classified as follows:
l Interface authentication: is configured in the interface view to authenticate Level-1 and
Level-2 IS-to-IS Hello PDUs (IIHs).
l Area authentication: is configured in the IS-IS process view to authenticate Level-1
CSNPs, PSNPs, and LSPs.
l Routing domain authentication: is configured in the IS-IS process view to authenticate
Level-2 CSNPS, PSNPs, and LSPs.
Based on the authentication modes of packets, authentication is classified into the following
types:
l Explicit authentication: is a explicit authentication mode in which passwords are directly
added to packets. The security of explicit text authentication is poorer than the other two
authentication types.
l MD5 authentication: uses the MD5 algorithm to encrypt a password before adding the
password to the packet, which improves password security.
l Keychain authentication: further improves network security with configurable key chain
that changes with time.
l HMAC-SHA256 authentication: uses the HMAC-SHA256 algorithm to encrypt a
password before adding the password to the packet, which improves password security.
Implementation
IS-IS authentication encrypts IS-IS packets by adding the authentication field to packets to
ensure network security. After receiving IS-IS packets from a remote router, a local router
discards the packets if the authentication passwords in the packets are different from the
locally configured authentication password. This mechanism protects the local router.
IS-IS provides a type-length-value (TLV) to carry authentication information. The TLV
components are as follows:
l Type: indicates the type of a packet, which is 1 byte. The value defined by ISO is 10,
while the value defined by IP is 133.
l Length: indicates the length of the authentication TLV, which is 1 byte.
l Value: indicates the contents of the authentication, including authentication type and
authenticated password, which ranges from 1 to 254 bytes.
– 0 is reserved.
– 1 indicates explicit authentication.
– 3 indicates the general authentication, and only HMAC-SHA256 authentication is
supported currently.

– 54 indicates MD5 authentication.

– 255 is used to route domain private authentication methods.
Interface Authentication
Authentication passwords for IIHs are saved on interfaces. The interfaces send authentication
packets with the authentication TLV. Interconnected router interfaces must be configured with
the same password.
Area Authentication
Every router in an IS-IS area must use the same authentication mode and have the same key
chain.
Routing Domain Authentication
Every Level-2 or Level-1-2 router in an IS-IS area must use the same authentication mode and
have the same key chain.
For area authentication and routing domain authentication, you can set a router to authenticate
SNPs and LSPs separately in the following ways:
l A router sends LSPs and SNPs that carry the authentication TLV and verifies the
authentication information of the LSPs and SNPs it receives.
l A router sends LSPs that carry the authentication TLV and verifies the authentication
information of the LSPs it receives. The router sends SNPs that carry the authentication
TLV and does not verify the authentication information of the SNPs it receives.
l A router sends LSPs that carry the authentication TLV and verifies the authentication
information of the LSPs it receives. The router sends SNPs without the authentication
TLV and does not verify the authentication information of the SNPs it receives.
l A router sends LSPs and SNPs that carry the authentication TLV but does not verify the
authentication information of the LSPs and SNPs it receives.
5.8.2.13 IS-IS Control Messages
Intermediate System to Intermediate System (IS-IS) routers implement routing by exchanging

control messages. This section describes IS-IS control messages.
IS-IS PDU Formats

Nine types of IS-IS protocol data units (PDUs) are available for processing control
information. Each PDU is identified by a 5-digit type code. IS-IS has three major types of
PDUs: Hello PDUs, link state PDUs (LSPs), and Sequence Number PDUs (SNPs). Table
5-59 shows the mapping between PDUs and type values.
Table 5-59 Mapping between PDUs and type values

PDU Type Acronym Type
Value
Level-1 LAN IS-IS Hello PDU L1 LAN IIH 15
Level-2 LAN IS-IS Hello PDU L2 LAN IIH 16

PDU Type Acronym Type

Value
Point-to-Point IS-IS Hello PDU P2P IIH 17
Level-1 Link State PDU L1 LSP 18
Level-2 Link State PDU L2 LSP 20
Level-1 Complete Sequence Numbers PDU L1 CSNP 24
Level-2 Complete Sequence Numbers PDU L2 CSNP 25
Level-1 Partial Sequence Numbers PDU L1 PSNP 26
Level-2 Partial Sequence Numbers PDU L2 PSNP 27
The first eight bytes in all IS-IS PDUs are public. Figure 5-71 shows the IS-IS PDU structure.
Figure 5-71 IS-IS PDU format

No. of Octets
Intradomain Routeing Protocol Discriminator 1
Length Indicator 1
Version/Protocol ID Extension 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Maximum Area Address 1
PDU exclusive 1
TLV
The main fields are as follows:

l Intradomain Routing Protocol Discriminator: network layer protocol identifier assigned
to IS-IS, which is always 0x83.
l Length Indicator: length of the fixed header in bytes.
l ID Length: length of the system ID of network service access point (NSAP) addresses or
NETs in this routing domain.
l PDU Type: type of a PDU. For details, see Table 5-59.
l Maximum Area Address: maximum number of area addresses permitted for this IS-IS
area. The value 0 indicates that a maximum of three area addresses are supported in this
IS-IS area.
l Type/Length/Value (TLV): encoding type that features high efficiency and expansibility.
Each type of PDU contains a different TLV. Table 5-60 shows the mapping between
TLV codes and PDU types.

Table 5-60 Mapping between TLV codes and PDU types

TLV Code TLV Code Name PDU Type
1 Area Addresses IIH, LSP
2 IS Neighbors (LSP) LSP
4 Partition Designated Level2 IS L2 LSP
6 IS Neighbors (MAC Address) LAN IIH
7 IS Neighbors (SNPA Address) LAN IIH
8 Padding IIH
9 LSP Entries SNP
10 Authentication Information IIH, LSP, or SNP
128 IP Internal Reachability Information LSP
129 Protocols Supported IIH or LSP
130 IP External Reachability Information L2 LSP
131 Inter-Domain Routing Protocol L2 LSP

Information
132 IP Interface Address IIH or LSP
Hello Packet Format

Hello packets, also called the IS-to-IS Hello PDUs (IIHs), are used to set up and maintain
neighbor relationships. Level-1 LAN IIHs are applied to the Level-1 routers on broadcast
LANs. Level-2 LAN IIHs are applied to the Level-2 routers on broadcast LANs. P2P IIHs are
applied to non-broadcast networks. IIHs in different networks have different formats.
l LAN IIHs: Figure 5-72 shows the format of IIHs on a broadcast network.

Figure 5-72 Level-1/Level-2 LAN IIH format

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Reserved/Circuit Type 1
Source ID ID Length
Holding Time 2
PDU Length 2
R Priority 1
LAN ID ID Length+1
Variable Length Fields
l P2P IIHs: Figure 5-73 shows the format of IIHs on a P2P network.
Figure 5-73 P2P IIH format

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Reserved/Circuit Type 1
Source ID ID Length
Holding Time 2
PDU Length 2
Local Circuit ID 1

As shown in Figure 5-73, most fields in a P2P IIH are the same as those in a LAN IIH.
The P2P IIH does not have the priority and LAN ID fields, but has a local circuit ID
field. The local circuit ID indicates the local link ID.
LSP Format
LSPs are used to exchange link-state information. There are two types of LSPs: Level-1 and
Level-2. Level-1 IS-IS transmits Level-1 LSPs. Level-2 IS-IS transmits Level-2 LSPs.
Level-1-2 IS-IS can transmit both Level-1 and Level-2 LSPs.
Level-1 and Level-2 LSPs have the same format, as shown in Figure 5-74.
Figure 5-74 Level-1 or Level-2 LSP

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
PDU Length 2
Remaining Lifetime 2
LSP ID ID Length+2
Sequency Number 4
Checksum 2
R ATT OL IS Type 1

l ATT: Attached bit
It is generated by a Level-1-2 router to identify whether the originating router is
connected to other areas. When a Level-1 router receives a Level-1 LSP with ATT as 1
from a Level-1-2 router, the Level-1 router generates a default route destined for the
Level-1-2 router so that data can be transmitted to other areas.
Although ATT is defined in both the Level-1 LSP and Level-2 LSP, it is set only in the
Level-1 LSP only by the Level-1-2 router.
l OL: LSDB overload
LSPs with the overload bit are still flooded on the network, but the LSPs are not used
when routes that pass through a router configured with the overload bit are calculated.
After a router is configured with the overload bit, other routers ignore the router when
performing shortest path first (SPF) calculation. Only the direct routes of the router are
considered.

l IS Type: type of the IS-IS generating the LSP

This field is used to specify whether the IS-IS type is Level-1 IS-IS or Level-2 IS-IS.
The value 01 indicates Level-1; the value 11 indicates Level-2.
SNP Format
SNPs describe the LSPs in all or some of the databases and are used to synchronize and
maintain all link-state databases (LSDBs). SNPs consist of complete SNPs (CSNPs) and
partial SNPs (PSNPs).
l CSNPs carry summaries of all LSPs in LSDBs, which ensures LSDB synchronization
between neighboring routers. On a broadcast network, the designated intermediate
system (DIS) sends CSNPs at regular intervals. The default interval is 10 seconds. On a
P2P link, neighboring devices send CSNPs only when a neighbor relationship is
established for the first time.
Figure 5-75 shows the CSNP format.
Figure 5-75 Level-1/Level-2 CSNP format

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
PDU Length 2
Source ID ID Length+1
Start LSP ID ID Length+2
End LSP ID ID Length+2

– Source ID: system ID of the router that sends SNPs
– Start LSP ID: ID of the first LSP in a CSNP
– End LSP ID: ID of the last LSP in a CSNP
l PSNPs list only the sequence numbers of recently received LSPs. A PSNP can
acknowledge multiple LSPs at a time. If an LSDB is not updated, PSNPs are also used to
request a neighbor to send a new LSP.
Figure 5-76 shows the PSNP format.

Figure 5-76 Level-1/Level-2 PSNP format

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
PDU Length 2
Source ID ID Length+1
5.8.3 IS-IS Configuration

By building IS-IS networks, you can enable IS-IS to discover and calculate routes in ASs.
5.8.3.1 Establishing IS-IS Neighbor Relationships

Establishing IS-IS neighbor relationships over an IS-IS IPv4 network enables IPv4 address
family-based nodes to communicate.
5.8.3.1.1 Starting an IS-IS Process

To enable IS-IS, you should create an IS-IS process and activate it on the interfaces that may
be associate with other devices.
Procedure
system-view
Step 2 Run:
isis [ process-id ]
An IS-IS process is started and the IS-IS view is displayed.
process-id identifies an IS-IS process. If process-id is not set, the system uses process 1 by
default. To associate the IS-IS process to a VPN instance, you can run the isis [ process-id ]
[ vpn-instance vpn-instance-name ] command.

description
Descriptions for the IS-IS process are configured.
----End
5.8.3.1.2 Configuring an NET

An NET defines the current IS-IS area address and the system ID of a router.
Context
You can configure a maximum of three NETs on a process of a router. The area addresses of
the NETs can be different, but their system IDs must be the same.
NET consists of three parts.
l Part one is the area ID that is variable (1 to 13 bytes), and the area IDs of the routers in
the same area are identical.
l Part two is the system ID (6 bytes) of this router, which must be unique in the whole area
and backbone area.
l Part three is the last byte "SEL", whose value must be "00".
Procedure
Step 1 In the user view,run:
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS view is displayed.
Step 3 Run:
network-entity net
An NET is configured.
NOTE
Configuring loopback interface addresses based on NETs is recommended to ensures that a NET is
unique on the network. If NETs are not unique, route flapping will easily occur.
System ID used in IS-IS can be obtained in the following way: extend each part of the IP address to 3
bits, add 0 to the front of any part that is shorter than 3 bits, divide the extended address into three parts,
with each part consisting of four decimal digits, and the reconstructed address is the system ID.
During the establishment of the Level-2 neighbor relationship, IS-IS does not check whether area
addresses are the same. During the establishment of the Level-1 neighbor relationship, area addresses
must be the same; otherwise, the Level-1 neighbor relationship cannot be established.
----End
5.8.3.1.3 Configuring the Device Level

Configuring a device level specifies an area for a routing device.

Context
Configure the device level according to network planning requirements:
l When the level of a device is Level-1, the device establishes neighbor relationships with
only Level-1 and Level-1-2 routers in the same area and maintains only Level-1 LSDBs.
l When the level of a device is Level-2, the device can establish neighbor relationship with
Level-2 routers in the same area or different areas and with Level-1-2 routers in different
areas and maintain only Level-2 LSDB.
l When the level of a device is Level-1-2, the device can establish neighbor relationships
with Level-1 and Level-2 routers and maintain Level-1 and Level-2 LSDBs.
Procedure
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS view is displayed.
Step 3 Run:
is-level { level-1 | level-1-2 | level-2 }
The level of a router is set.
By default, the level of the router device is level-1-2.
----End
5.8.3.1.4 Enabling IS-IS for Interfaces of Different Network Types

An interface can send Hello packets to establish neighbor relationships and floods LSPs only
after you enable IS-IS on it. You can configure different IS-IS attributes for interfaces of
different network types.
Context
The methods to establish IS-IS neighbor relationships on a broadcast network and a P2P
network are different. Therefore, you need to set different IS-IS attributes for interfaces of
different types:
On a broadcast network, IS-IS needs to select the designated intermediate system (DIS). You
can set the DIS priority for IS-IS interfaces to enable the device with the highest DIS priority
to be elected as the DIS.
On a P2P network, IS-IS does not need to select the DIS. Therefore, the DIS priority does not
need to be configured for interfaces. To ensure P2P link reliability, configure IS-IS to
establish a neighbor relationship on two P2P interfaces in 3-way mode for unidirectional link
fault detection.

Procedure
l Establish an IS-IS neighbor relationship on a broadcast link.
a. Run:
system-view

b. Run:

c. Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.
After this command is run, IS-IS establishes neighbor relationships and floods LSPs
through this interface.
NOTE
Loopback interfaces are not used to establish neighbor relationships. If IS-IS is enabled on a
loopback interface, IS-IS advertises the routes of the network segment where the interface
resides through other IS-IS interfaces.
d. Run:
isis circuit-level [ level-1 | level-1-2 | level-2 ]
The level of the interface is configured.
By default, the level of an interface is level-1-2.
When two Level-1-2 devices establish IS-IS neighbor relationship, they establish
both Level-1 and Level-2 neighbor relationships. To allow the two Level-1-2
devices to establish only Level-1 or Level-2 neighbor relationship, change the level
of interfaces.
NOTE
Changing the level of an IS-IS interface is valid only when the level of the IS-IS device is
Level-1-2. If the level of the device is not Level-1-2, the level of the device determines the
level of the established neighbor relationship.
e. (Optional) Run:
isis dis-priority priority [ level-1 | level-2
The DIS priority is set for the interface. A larger value indicates a higher priority.
By default, the DIS priority of Level-1 and Level-2 broadcast interfaces is 64.
f. (Optional) Run:
isis silent [ advertise-zero-cost ]
The interface is suppressed.
By default, an IS-IS interface is not suppressed.

When an IS-IS interface is suppressed, the interface no longer sends or receives IS-
IS packets. The routes of the network segment where the interface resides, however,
can still be advertised to other IS-IS devices within the same AS.
g. (Optional) Configure a delay for the IS-IS neighbor relationship establishment.
isis delay-peer track last-peer-expired[ delay-time
A delay is configured for the IS-IS neighbor relationship establishment.
By default, delay-interval is 60s.
If a new delay-interval is configured and it is less than the remaining time of the
ongoing delay, the new delay-interval takes effect immediately; if the new delay-
interval is greater than the remaining time of the ongoing delay, the ongoing delay
continues until the new delay-interval takes effect at the next delay.
l Establish an IS-IS neighbor relationship on a P2P link.
a. Run:
system-view
b. Run:
c. Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.
d. Run:
isis circuit-level [ level-1 | level-1-2 | level-2 ]
The level of the interface is configured.
By default, the level of an interface is level-1-2.
e. Run:
isis circuit-type p2p
The network type of the interface is set to P2P.
By default, the network type of an interface is determined by the physical type of
the interface.
When the network type of an IS-IS interface changes, the interface configuration
changes accordingly:
n After a broadcast interface is simulated as a P2P interface using the isis
circuit-type p2p command, the interval for sending Hello packets, number of
Hello packets that IS-IS does not receive from a neighbor before the neighbor
is declared Down, interval for retransmitting LSPs on a P2P link, and various
IS-IS authentication modes are restored to the default settings; other
configurations such as the DIS priority, DIS name, and interval for sending
CSNPs on a broadcast network become invalid.

n After the undo isis circuit-type command is run to restore the default network
type of an IS-IS interface, the interval for sending Hello packets, number of
Hello packets that IS-IS does not receive from a neighbor before the neighbor
is declared Down, interval for retransmitting LSPs on a P2P link, various IS-IS
authentication modes, DIS priority, and interval for sending CSNPs on a
broadcast network are restored to the default settings.
f. Run:
isis ppp-negotiation { 2-way | 3-way [ only ] }
The negotiation mode is specified for the interface.
By default, the negotiation mode is 3-way.

g. Run:
isis peer-ip-ignore
IS-IS is configured not to check the IP addresses of received Hello packets.
By default, IS-IS checks the IP addresses of received Hello packets.

h. Run:
isis ppp-osicp-check
OSICP negotiation status check is configured on the interface.
By default, the OSICP negotiation status of a PPP interface does not affect the
status of an IS-IS interface.
NOTE
This command applies only to PPP interfaces and is invalid for other P2P interfaces.
After this command is run, the OSICP negotiation status of a PPP interface affects the status
of an IS-IS interface. When PPP detects that the OSI network fails, the link status of the IS-
IS interface goes Down and the routes of the network segment where the interface resides
are not advertised through LSPs.
i. (Optional) Configure a delay for the IS-IS neighbor relationship establishment.
Run:
isis delay-peer track last-peer-expired[ delay-time delay-interval ]
A delay is configured for the IS-IS neighbor relationship establishment.
By default, delay-interval is 60s.
If a new delay-interval is configured and it is less than the remaining time of the
ongoing delay, the new delay-interval takes effect immediately; if the new delay-
interval is greater than the remaining time of the ongoing delay, the ongoing delay
continues until the new delay-interval takes effect at the next delay.
----End
5.8.3.2 Controlling IS-IS Routing Information

You need to subtly configure IS-IS routing information sometimes to meet the requirements
of complex networks, implementing accurate control on IS-IS routing information.

5.8.3.2.1 Configuring IS-IS to Generate Default Routes

This section describes how to configure Intermediate System to Intermediate System (IS-IS)
to generate default routes to control the advertising of IS-IS routing information.
Context
The destination address and mask of a default route are all 0s. If the destination address of a
packet does not match any entry in the routing table of a device, the device sends the packet
along the default route. If neither the default route nor the destination address of the packet
exists in the routing table, the device discards the packet and informs the source end that the
destination address or network is unreachable.
IS-IS can generate default routes using either of the following mode:
l Command-triggered default route generation mode

You can run the default-route-advertise command on a device so that the device adds a
default route to the LSP before sending the LSP to a neighbor. Therefore, the neighbor
can learn this default route.
l ATT bit 1-triggered default route generation mode
IS-IS defines that a Level-1-2 router sets the ATT bit to 1 in the LSP to be advertised to a
Level-1 area if the Level-1-2 router can reach more Level-1 areas through the Level-2
area than through the Level-1 area. After a Level-1 router in the Level-1 area receives
the LSP, it generates a default route destined for the Level-1-2 router. Based on the
network requirements, you can configure whether the Level-1-2 router sets the ATT bit
carried in the LS

Huawei Usg6000v v500r001c10spc100 Administrator Guide

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Huawei Usg6000v v500r001c10spc100 Administrator Guide

Cargado por

Copyright:

Formatos disponibles

HUAWEI USG6000V Series

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2015-12-8) Huawei Proprietary and Confidential i

About This Document

Product Name Product Version

Encryption Algorithm Declaration

l The encryption algorithms DES/3DES/RSA (RSA-1024 or lower)/MD5 (in digital

Issue 01 (2015-12-8) Huawei Proprietary and Confidential ii

l For the HMAC algorithm, use HMAC-SHA2.

Personal Data Declaration

Feature Usage Declaration

Issue 01 (2015-12-8) Huawei Proprietary and Confidential iii

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

NOTE Calls attention to important information, best practices and

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... } * Optional items are grouped in braces and separated by

Issue 01 (2015-12-8) Huawei Proprietary and Confidential iv

[ x | y | ... ] * Optional items are grouped in brackets and separated by

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Updates in Issue 01 (2015-12-08) of Product Version V500R001C10SPC100

Issue 01 (2015-12-8) Huawei Proprietary and Confidential v

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

Issue 01 (2015-12-8) Huawei Proprietary and Confidential vi

1.3.6.2 Feature History....................................................................................................................................................... 79

Issue 01 (2015-12-8) Huawei Proprietary and Confidential vii

Issue 01 (2015-12-8) Huawei Proprietary and Confidential viii

1.10.3 Configuring the FW to Output Alarms..................................................................................................................187

Issue 01 (2015-12-8) Huawei Proprietary and Confidential ix

1.14.1.2 File Transfer Mode............................................................................................................................................. 216

Issue 01 (2015-12-8) Huawei Proprietary and Confidential x

1.19.3 Setting ICMP Test Parameters...............................................................................................................................275

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xi

2.1.2.3 Off-line Deployment of Hot Standby................................................................................................................... 319

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xii

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xiii

2.2.2.4 IP-Link in the DHCP Environment...................................................................................................................... 555

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xiv

2.4.5.3 Configuring Interworking Between BFD and Other Functions........................................................................... 606

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xv

3.6.4 Enabling Communication Between Virtual Systems ..............................................................................................681

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xvi

4.1.3.6.3 Configuring a Layer 2 Eth-Trunk Interface.......................................................................................................810

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xvii

4.3.5.2 Feature History..................................................................................................................................................... 868

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xviii

4.6 DNS............................................................................................................................................................................ 914

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xix

4.7.1 Introduction............................................................................................................................................................. 961

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xx

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxi

Issue 01 (2015-12-8) Huawei Proprietary and Confidential xxii

4.11.3.3 Configuring Layer 3 Subinterfaces to Enable VLANs to Communicate......................................................... 1133