AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003 CLI-based Configuration Guide - VPN

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&
AR2200&AR3200&AR3600 Series Enterprise
Routers
V300R003
CLI-based Configuration Guide -

VPN Configuration
Issue 01
Date 2019-03-05
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. 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 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. i

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2200&AR3200&AR3600 Series Enterprise Routers
CLI-based Configuration Guide - VPN Configuration About This Document
About This Document
Intended Audience
This document describes VPN features on the device and provides configuration procedures
and configuration examples.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
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.

which, if not avoided, may result in minor
or moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. ii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Symbol Description
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.
[ 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.
Interface Numbering Conventions

Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Security Conventions
l Password setting
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. iii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– When configuring a password, the cipher text is recommended. To ensure device

security, change the password periodically.
– When you configure a password in plain text that starts and ends with %@%@, @
%@%, %#%#, or %^%# (the password can be decrypted by the device), the
password is displayed in the same manner as the configured one in the
configuration file. Do not use this setting.
– When you configure a password in cipher text, different features cannot use the
same cipher-text password. For example, the cipher-text password set for the AAA
feature cannot be used for other features.
l Encryption algorithm
Currently, the device uses the following encryption algorithms: 3DES, AES, RSA,
SHA1, SHA2, and MD5. 3DES, RSA and AES are reversible, while SHA1, SHA2, and
MD5 are irreversible. 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. The encryption algorithm depends on
actual networking. The irreversible encryption algorithm must be used for the
administrator password, SHA2 is recommended.
l Personal data
Some personal data may be obtained or used during operation or fault location of your
purchased products, services, features, so you have an obligation to make privacy
policies and take measures according to the applicable law of the country to protect
personal data.
l The terms mirrored port, port mirroring, traffic mirroring, and mirroring in this manual
are mentioned only to describe the product's function of communication error or failure
detection, and do not involve collection or processing of any personal information or
communication data of users.
Declaration
l This manual is only a reference for you to configure your devices. The contents in the
manual, such as web pages, command line syntax, and command outputs, are based on
the device conditions in the lab. The manual provides instructions for general scenarios,
but do not cover all usage scenarios of all product models. The contents in the manual
may be different from your actual device situations due to the differences in software
versions, models, and configuration files. The manual will not list every possible
difference. You should configure your devices according to actual situations.
l The specifications provided in this manual are tested in lab environment (for example,
the tested device has been installed with a certain type of boards or only one protocol is
run on the device). Results may differ from the listed specifications when you attempt to
obtain the maximum values with multiple functions enabled on the device.
l In this document, public IP addresses may be used in feature introduction and
configuration examples and are for reference only unless otherwise specified.
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. iv

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Mappings Between Product Software Versions and NMS

Versions
The mappings between product software versions and NMS versions are as follows.
AR100&AR120&AR150&AR160 eSight
&AR200&AR1200&AR2200&A
R3200&AR3600 Product
Software Version
V300R003 V300R010C00
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 01 (2019-03-05)

Initial commercial release.
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. v

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration Contents
Contents
About This Document.....................................................................................................................ii

1 Auto VPN Configuration............................................................................................................. 1
1.1 Overview of Auto VPN.................................................................................................................................................. 1
1.2 Understanding Auto VPN...............................................................................................................................................2
1.2.1 Auto VPN Fundamentals.............................................................................................................................................2
1.3 Application Scenarios for Auto VPN............................................................................................................................. 6
1.3.1 Implementing Auto VPN Tenant Isolation.................................................................................................................. 6
1.3.2 Using Backup PEs on an Auto VPN........................................................................................................................... 8
1.3.3 Routing Auto VPN Traffic Through a Hub Device...................................................................................................10
1.3.4 Routing Auto VPN Traffic Through a Hub-CE Device............................................................................................ 12
1.4 Licensing Requirements and Limitations for Auto VPN............................................................................................. 14
1.5 Configuring Auto VPN.................................................................................................................................................14
1.5.1 Prerequisites for Configuring Auto VPN.................................................................................................................. 15
1.5.2 Configuring Auto VPN Peer Relationships...............................................................................................................17
1.5.3 (Optional) Configuring an Auto VPN RR................................................................................................................. 18
1.5.4 Setting a Value for the Color Attribute...................................................................................................................... 19
1.5.5 Configuring EVPN Services......................................................................................................................................19
1.5.6 (Optional) Configuring an EVPN RR....................................................................................................................... 21
1.5.7 (Optional) Configuring a Primary Channel............................................................................................................... 22
1.5.8 Verifying the Auto VPN Configuration.....................................................................................................................22
1.6 References.................................................................................................................................................................... 23
2 L2TP Configuration.....................................................................................................................24
2.1 Overview of L2TP........................................................................................................................................................ 25
2.2 Understanding L2TP.....................................................................................................................................................26
2.2.1 Concepts.................................................................................................................................................................... 26
2.2.2 L2TP Implementation................................................................................................................................................29
2.2.3 Working Procedure.................................................................................................................................................... 31
2.3 Application Scenarios for L2TP................................................................................................................................... 34
2.3.1 Client-Initiated L2TP Connection............................................................................................................................. 34
2.3.2 LAC-Initiated L2TP Connection upon Receiving a Call Connection Request......................................................... 35
2.3.3 LAC-Initiated L2TP Connection upon Receiving a Call from a PPPoE User.......................................................... 35
2.3.4 L2TP Client-Initiated L2TP Connection................................................................................................................... 36
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. vi

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.3.5 LAC-Initiated L2TP Connection When Users from Multiple Domains Are Connected.......................................... 36
2.3.6 Authenticating VPDN Users Using the RADIUS Server..........................................................................................37
2.3.7 Allocating the Frame-IP and Frame-Route Attributes and the Specified Address Pool Name to L2TP Users by the
RADIUS Server.................................................................................................................................................................. 38
2.3.8 Setting Up a Secure Tunnel Connection Using L2TP over IPSec Encapsulation..................................................... 38
2.3.9 Setting Up a Secure Tunnel Connection Using IPSec over L2TP Encapsulation..................................................... 39
2.4 Licensing Requirements and Limitations for L2TP..................................................................................................... 40
2.5 Default Settings for L2TP.............................................................................................................................................40
2.6 Configuring L2TP.........................................................................................................................................................40
2.6.1 Configuring the LAC to Initiate Call-Triggered L2TP Connections.........................................................................41
2.6.1.1 Configuring AAA Authentication and Accounting................................................................................................43
2.6.1.2 Configuring the LAC to Accept Dial-Up Calls and Initiate L2TP Connections....................................................46
2.6.1.3 Configuring the LNS to Respond to the L2TP Connection Request......................................................................49
2.6.2 Configuring L2TP Client-Initiated L2TP Connections............................................................................................. 52
2.6.2.1 Configuring AAA Authentication and Accounting................................................................................................54
2.6.2.2 Configuring the L2TP Client to Dial Up and Initiate L2TP Connections..............................................................57
2.6.2.3 Configuring the LNS to Respond to the L2TP Connection Request......................................................................59
2.6.3 Configuring Other L2TP Functions...........................................................................................................................62
2.6.3.1 Configuring LCP Renegotiation............................................................................................................................. 63
2.6.3.2 Configuring CHAP Mandatory Authentication......................................................................................................63
2.6.3.3 Configuring Primary and Secondary LNSs............................................................................................................ 64
2.6.3.4 Configuring AVP Parameter Encryption................................................................................................................ 65
2.6.3.5 Configuring L2TP Tunnel Authentication..............................................................................................................65
2.6.3.6 Configuring L2TP Tunnel Connectivity.................................................................................................................66
2.6.4 Verifying the L2TP Configuration.............................................................................................................................67
2.7 Maintaining L2TP.........................................................................................................................................................67
2.7.1 Disconnecting an L2TP Tunnel Manually.................................................................................................................67
2.7.2 Monitoring the Running Status of L2TP................................................................................................................... 68
2.7.3 Collecting L2TP Packet Statistics............................................................................................................................. 68
2.8 Configuration Examples for L2TP............................................................................................................................... 69
2.8.1 Example for Configuring Client-Initiated L2TP Connections.................................................................................. 69
2.8.2 Example for Configuring the LAC to Initiate Call-Triggered L2TP Connections (Dial-Up Users).........................79
2.8.3 Example for Configuring the LAC to Initiate Call-Triggered L2TP Connections (PPPoE Users)...........................81
2.8.4 Example for Configuring an L2TP Client-Initiated L2TP Connection..................................................................... 85
2.8.5 Example for Configuring L2TP Client-Initiated L2TP Connections........................................................................ 89
2.8.6 Example for Configuring L2TP Client-Initiated L2TP Connections Using the 3G Interface...................................95
2.9 Troubleshooting L2TP................................................................................................................................................100
2.9.1 User Failed to Dial Up to the LNS.......................................................................................................................... 101
2.9.2 Data Transmission Fails After L2TP Connections Are Established........................................................................103
2.10 FAQ About L2TP..................................................................................................................................................... 104
2.10.1 Starting from Which Version Does the device Support NAT Traversal in L2TP?................................................ 104
2.10.2 L2TP Dialup Is Successful After Dozens of Attempts and Error 691 Is Displayed. Why?.................................. 104
2.10.3 How Can I Quickly Locate Why the LAC Cannot Set Up an L2TP Tunnel with the LNS?................................ 104
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. vii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.10.4 How Do I Configure the LNS That Trusts the LAC Not to Perform Second Authentication on Remote Users?
.......................................................................................................................................................................................... 105
2.10.5 What Can I Do If a PC Running the Windows 7 or XP Operating System Fails to Establish an L2TP over IPSec
Tunnel with the Device?................................................................................................................................................... 105
2.11 References for L2TP.................................................................................................................................................106
3 L2TPv3 Configuration.............................................................................................................. 107

3.1 Overview of L2TPv3.................................................................................................................................................. 107
3.2 Understanding L2TPv3...............................................................................................................................................108
3.3 Application Scenarios for L2TPv3............................................................................................................................. 110
3.4 Licensing Requirements and Limitations for L2TPv3................................................................................................111
3.5 Configuring L2TPv3...................................................................................................................................................112
3.5.1 Configuring a Static L2TPv3 Tunnel.......................................................................................................................112
3.5.2 Verifying the L2TPv3 Configuration.......................................................................................................................113
3.6 Monitoring the L2TPv3 Tunnel Running Status........................................................................................................ 114
3.7 Configuration Examples for L2TPv3......................................................................................................................... 114
3.7.1 Example for Establishing a Static L2TPv3 Tunnel..................................................................................................114
3.7.2 Example for Configuring L2TPv3 over IPSec to Implement Secure Communication Between Branches............ 119
3.8 References for L2TPv3...............................................................................................................................................126
4 GRE Configuration................................................................................................................... 128

4.1 Overview of GRE....................................................................................................................................................... 129
4.2 Understanding GRE....................................................................................................................................................129
4.2.1 Basic Concepts........................................................................................................................................................ 129
4.2.2 GRE Security Mechanisms......................................................................................................................................132
4.2.3 Keepalive Detection................................................................................................................................................ 133
4.2.4 Ethernet over GRE...................................................................................................................................................134
4.2.5 Ethernet over mGRE............................................................................................................................................... 135
4.3 Application Scenarios for GRE.................................................................................................................................. 137
4.3.1 Transmitting Data of Multi-Protocol Local Networks Through a GRE Tunnel......................................................137
4.3.2 Enlarging the Operation Scope of a Network with a Hop Limit............................................................................. 137
4.3.3 Combining GRE with IPSec to Protect Multicast Data...........................................................................................138
4.3.4 Setting Up an L2VPN and an L3VPN Using a GRE Tunnel.................................................................................. 138
4.3.5 Connecting CE Devices to an MPLS VPN Network.............................................................................................. 140
4.3.6 Ethernet over GRE Application...............................................................................................................................143
4.3.7 Ethernet over mGRE Application............................................................................................................................143
4.4 Licensing Requirements and Limitations for GRE.................................................................................................... 144
4.5 Default Settings for GRE............................................................................................................................................144
4.6 Configuring a GRE Tunnel.........................................................................................................................................144
4.6.1 Configuring a Tunnel Interface................................................................................................................................145
4.6.2 Configuring a Route on a Tunnel Interface............................................................................................................. 148
4.6.3 (Optional) Configuring the Link Bridge Function.................................................................................................. 149
4.6.4 (Optional) Configuring a Security Mechanism for GRE.........................................................................................153
4.6.5 (Optional) Enabling the Keepalive Detection Function for GRE............................................................................153
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. viii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.6.6 (Optional) Configuring Ethernet over GRE............................................................................................................ 154

4.6.7 (Optional) Configuring Ethernet over mGRE......................................................................................................... 156
4.6.8 (Optional) Configuring the DF Flag Bit for GRE Packets...................................................................................... 157
4.6.9 (Optional) Binding a GRE Tunnel to a BFD Session..............................................................................................158
4.6.10 Verifying the GRE Tunnel Configuration..............................................................................................................158
4.7 Maintaining the GRE Tunnel......................................................................................................................................159
4.7.1 Collecting and Viewing Statistics on Tunnel Interfaces..........................................................................................159
4.7.2 Monitoring the GRE Running Status.......................................................................................................................160
4.7.3 Resetting the Keepalive Packet Statistics on a Tunnel Interface.............................................................................160
4.8 Configuration Examples for GRE.............................................................................................................................. 161
4.8.1 Example for Configuring a Static Route for GRE to Implement Interworking Between IPv4 Networks.............. 161
4.8.2 Example for Configuring OSPF for GRE to Implement Interworking Between IPv4 Networks........................... 166
4.8.3 Example for Configuring a GRE Tunnel to Implement Interworking Between IPv6 Networks............................ 171
4.8.4 Example for Enlarging the Operation Scope of a Network with a Hop Limit........................................................ 175
4.8.5 Example for Configuring BGP/MPLS IP VPN to Use a GRE Tunnel....................................................................180
4.8.6 Example for Configuring VLL to Use a GRE Tunnel.............................................................................................188
4.8.7 Example for Connecting a CE to a VPN Through a GRE Tunnel over a Public Network..................................... 194
4.8.8 Example for Connecting a CE to a VPN Through a GRE Tunnel over a VPN.......................................................202
4.8.9 Example for Configuring GRE to Implement Communication Between FR Networks......................................... 210
4.8.10 Example for Configuring an Ethernet over GRE Tunnel...................................................................................... 213
4.8.11 Example for Configuring an Ethernet over mGRE Tunnel................................................................................... 218
4.9 Troubleshooting GRE................................................................................................................................................. 224
4.9.1 Failed to Ping the IP Address of the Remote Tunnel Interface............................................................................... 224
4.9.2 Tunnel Interface Alternates Between Up and Down States.................................................................................... 226
4.10 FAQ About GRE.......................................................................................................................................................226
4.10.1 Can the MTU of the GRE Tunnel Interface Take Effect?..................................................................................... 226
4.11 References for GRE.................................................................................................................................................. 226
5 DSVPN Configuration............................................................................................................. 228

5.1 Overview of DSVPN.................................................................................................................................................. 228
5.2 Understanding DSVPN...............................................................................................................................................233
5.2.1 Basic Concepts........................................................................................................................................................ 233
5.2.2 Implementation........................................................................................................................................................ 236
5.2.3 DSVPN NAT Traversal........................................................................................................................................... 244
5.2.4 DSVPN Protected by IPSec.....................................................................................................................................246
5.2.5 DSVPN Reliability.................................................................................................................................................. 248
5.2.5.1 Dual Hubs in Active/Standby Mode.....................................................................................................................248
5.2.5.2 Dual Hubs in Load Balancing Mode.................................................................................................................... 250
5.3 Application Scenarios for DSVPN............................................................................................................................. 252
5.3.1 DSVPN Deployment on a Small- or Medium-sized Network................................................................................ 252
5.3.2 DSVPN Deployment on a Large-sized Network.....................................................................................................254
5.3.3 Deploying DSVPN in Hierarchical Hub Networking............................................................................................. 256
5.4 Licensing Requirements and Limitations for DSVPN............................................................................................... 257
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. ix

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5.5 Default Settings for DSVPN.......................................................................................................................................258

5.6 Configuring DSVPN...................................................................................................................................................259
5.6.1 Configuring mGRE..................................................................................................................................................259
5.6.2 Configuring Routes..................................................................................................................................................260
5.6.3 Configuring NHRP.................................................................................................................................................. 262
5.6.4 (Optional) Configuring DSVPN QoS......................................................................................................................265
5.6.5 (Optional) Configuring an IPSec Profile................................................................................................................. 266
5.6.6 Verifying the DSVPN Configuration.......................................................................................................................267
5.7 Maintaining DSVPN...................................................................................................................................................267
5.7.1 Clearing DSVPN Running Statistics....................................................................................................................... 267
5.7.2 Monitoring DSVPN Running Statistics...................................................................................................................268
5.8 Configuration Examples for DSVPN......................................................................................................................... 268
5.8.1 Example for Configuring Non-Shortcut Scenario of DSVPN (Static Route)......................................................... 268
5.8.2 Example for Configuring Non-Shortcut Scenario of DSVPN (RIP).......................................................................275
5.8.3 Example for Configuring Non-Shortcut Scenario of DSVPN (OSPF)................................................................... 281
5.8.4 Example for Configuring Non-Shortcut Scenario of DSVPN (BGP)..................................................................... 288
5.8.5 Example for Configuring Shortcut Scenario of DSVPN (RIP)............................................................................... 295
5.8.6 Example for Configuring Shortcut Scenario of DSVPN (OSPF)............................................................................301
5.8.7 Example for Configuring Shortcut Scenario of DSVPN (BGP)............................................................................. 308
5.8.8 Example for Configuring DSVPN NAT traversal................................................................................................... 315
5.8.9 Example for Configuring Dual Hubs in Active/Standby Mode.............................................................................. 323
5.8.10 Example for Configuring DSVPN Protected by IPSec......................................................................................... 331
5.8.11 Example for Configuring a Dual-Hub DSVPN Protected by IPSec......................................................................342
5.8.12 Example for Configuring a DSVPN Based on the LTE Dialup Status..................................................................354
5.8.13 Example for Configuring DSVPN QoS.................................................................................................................369
5.9 Troubleshooting DSVPN............................................................................................................................................374
5.9.1 Spoke Fails to Register with a Hub......................................................................................................................... 375
5.9.2 Subnets Between Spokes Cannot Communicate Directly in Non-Shortcut Mode..................................................375
5.9.3 Subnets Between Spokes Cannot Communicate Directly in Shortcut Mode.......................................................... 376
5.9.4 Backup Hub Only Forwards Data After the Master Hub Fails............................................................................... 377
5.10 References for DSVPN.............................................................................................................................................377
6 IPSec Configuration.................................................................................................................. 378

6.1 Overview of IPSec......................................................................................................................................................379
6.2 Understanding IPSec.................................................................................................................................................. 380
6.2.1 Basic Concepts of IPSec..........................................................................................................................................380
6.2.1.1 Security Association............................................................................................................................................. 380
6.2.1.2 Security Protocol.................................................................................................................................................. 381
6.2.1.3 Encapsulation Mode............................................................................................................................................. 385
6.2.1.4 Encryption............................................................................................................................................................ 386
6.2.1.5 Authentication...................................................................................................................................................... 387
6.2.1.6 Key Exchange.......................................................................................................................................................389
6.2.1.7 IKE........................................................................................................................................................................389
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. x

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.2.2 IPSec Fundamentals................................................................................................................................................ 392

6.2.2.1 Defining IPSec Protected Data Flows.................................................................................................................. 392
6.2.2.2 Establishing an SA Through IKEv1 Negotiation................................................................................................. 392
6.2.2.3 Establishing an SA Through IKEv2 Negotiation................................................................................................. 395
6.2.3 IPSec Enhancements................................................................................................................................................397
6.2.3.1 L2TP over IPSec...................................................................................................................................................397
6.2.3.2 GRE over IPSec....................................................................................................................................................399
6.2.3.3 IPSec Multi-instance.............................................................................................................................................400
6.2.3.4 Efficient VPN....................................................................................................................................................... 401
6.2.4 IPSec Reliability...................................................................................................................................................... 404
6.2.4.1 Link Redundancy..................................................................................................................................................404
6.3 Application Scenarios for IPSec.................................................................................................................................406
6.3.1 Using IPSec VPN to Implement Secure Interconnection Between LANs.............................................................. 407
6.3.2 Using IPSec VPN to Provide Secure Remote Access for Mobile Users.................................................................409
6.3.3 Secure LAN Interconnection Through Efficient VPN............................................................................................ 410
6.4 Summary of IPSec Configuration Tasks.....................................................................................................................411
6.5 Licensing Requirements and Limitations for IPSec................................................................................................... 413
6.6 Default Settings for IPSec.......................................................................................................................................... 415
6.7 Using an ACL to Establish an IPSec Tunnel..............................................................................................................416
6.7.1 Defining Data Flows to Be Protected...................................................................................................................... 418
6.7.2 Configuring an IPSec Proposal................................................................................................................................422
6.7.3 Configuring an IPSec Policy................................................................................................................................... 424
6.7.3.1 Configuring an IPSec Policy in Manual Mode.....................................................................................................425
6.7.3.2 Configuring an IPSec Policy in ISAKMP Mode..................................................................................................427
6.7.3.3 Configuring an IPSec Policy Using an IPSec Policy Template............................................................................430
6.7.4 (Optional) Setting the IPSec SA Lifetime............................................................................................................... 433
6.7.5 (Optional) Enabling the Anti-replay Function.........................................................................................................435
6.7.6 (Optional) Configuring IPSec Fragmentation Before Encryption...........................................................................436
6.7.7 (Optional) Configuring Route Injection.................................................................................................................. 437
6.7.8 (Optional) Configuring IPSec Check...................................................................................................................... 439
6.7.9 (Optional) Enabling the QoS Function for IPSec Packets.......................................................................................439
6.7.10 (Optional) Configuring IPSec VPN Multi-instance.............................................................................................. 441
6.7.11 (Optional) Allowing New Users with the Same Traffic Rule as Original Branch Users to Access the Headquarters
Network............................................................................................................................................................................ 442
6.7.12 (Optional) Configuring the Device to Keep IPSec Tunnel Indexes Unchanged Based on the Peer IP Address
During IPSec Tunnel Re-establishment............................................................................................................................442
6.7.13 (Optional) Configuring a Multi-link Shared IPSec Policy Group......................................................................... 443
6.7.14 (Optional) Configuring Redundancy Control of IPSec Tunnels........................................................................... 444
6.7.15 (Optional) Configuring IPSec Gateway Redundancy Control.............................................................................. 445
6.7.16 (Optional) Configuring IPSec Mask Filtering....................................................................................................... 446
6.7.17 Applying an IPSec Policy Group to an Interface.................................................................................................. 447
6.7.18 Verifying the Configuration of IPSec Tunnel Establishment................................................................................ 449
6.8 Using a Virtual Tunnel Interface to Establish an IPSec Tunnel................................................................................. 449
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xi

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.8.1 Configuring an IPSec Proposal................................................................................................................................450

6.8.2 Configuring an IPSec Profile...................................................................................................................................451
6.8.3 (Optional) Setting the SA Lifetime......................................................................................................................... 453
6.8.4 (Optional) Enabling the Anti-replay Function.........................................................................................................454
6.8.5 (Optional) Configuring IPSec Fragmentation Before Encryption...........................................................................456
6.8.6 (Optional) Configuring IPSec Check...................................................................................................................... 456
6.8.7 (Optional) Enabling the QoS Function for IPSec Packets.......................................................................................457
6.8.8 (Optional) Configuring the Device to Keep IPSec Tunnel Indexes Unchanged Based on the Peer IP Address
During IPSec Tunnel Re-establishment............................................................................................................................458
6.8.9 (Optional) Configuring Requesting, Sending or Accepting of Subnet Route Information..................................... 459
6.8.10 Configuring a Tunnel Interface or a Tunnel Template Interface........................................................................... 464
6.8.11 Verifying the Configuration of IPSec Tunnel Establishment Using a Virtual Tunnel Interface............................467
6.9 Establishing an IPSec Tunnel Using an Efficient VPN Policy...................................................................................468
6.9.1 Configuring the Remote Device.............................................................................................................................. 469
6.9.2 Configuring the Efficient VPN Server.................................................................................................................... 475
6.9.3 Verifying the Efficient VPN Configuration.............................................................................................................477
6.10 Configuring an IPSec Tunnel in the Auto VPN Scenario........................................................................................ 478
6.10.1 Configuring an IPSec Proposal..............................................................................................................................478
6.10.2 Configuring an IPSec P2MP Security Policy........................................................................................................ 479
6.10.3 Enabling the IPSec P2MP Security Policy Function on a Tunnel Interface..........................................................480
6.10.4 Verifying the IPSec Tunnel Configuration............................................................................................................ 481
6.11 Configuring IKE....................................................................................................................................................... 481
6.11.1 Configuring an IKE Proposal................................................................................................................................ 482
6.11.2 Configuring an IKE Peer....................................................................................................................................... 484
6.11.3 (Optional) Setting the IKE SA Lifetime................................................................................................................ 491
6.11.4 (Optional) Configuring IKE Peer Status Detection............................................................................................... 492
6.11.4.1 (Optional) Configuring Heartbeat Detection...................................................................................................... 492
6.11.4.2 (Optional) Configuring DPD.............................................................................................................................. 494
6.11.5 (Optional) Configuring an Identity Filter Set........................................................................................................ 495
6.11.6 (Optional) Configuring DSCP Priority for IKE Packets....................................................................................... 498
6.11.7 (Optional) Configuring NAT Traversal................................................................................................................. 499
6.11.8 (Optional) Configuring IPSec VPN Multi-instance...............................................................................................500
6.11.9 (Optional) Configuring Network Resource Delivery............................................................................................ 502
6.11.10 (Optional) Configuring ACL Delivery................................................................................................................ 502
6.11.11 (Optional) Enabling Dependency Between IPSec SA and IKE SA During IKEv1 Negotiation.........................503
6.11.12 (Optional) Configuring Rapid Switchover and Revertive Switching of an IKE Peer......................................... 504
6.11.13 (Optional) Disabling Validity Verification on Certificates.................................................................................. 505
6.11.14 (Optional) Configuring IKEv2 Packet Fragmentation.........................................................................................506
6.11.15 (Optional) Disabling the Function of Instructing the Peer Device to Delete the Old Child SA..........................507
6.11.16 Verifying the IKE Configuration......................................................................................................................... 507
6.12 Maintaining IPSec.................................................................................................................................................... 508
6.12.1 Monitoring the IPSec Running Status................................................................................................................... 508
6.12.2 Clearing IPSec Statistics........................................................................................................................................509
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13 Configuration Examples for IPSec........................................................................................................................... 510

6.13.1 Example for Manually Establishing an IPSec Tunnel........................................................................................... 510
6.13.2 Example for Establishing an IPSec Tunnel in IKE Negotiation Mode Using Default Settings............................514
6.13.3 Example for Establishing an IPSec Tunnel Between the Enterprise Headquarters and Branch Using an IPSec
Policy Template................................................................................................................................................................ 519
6.13.4 Example for Establishing Multiple IPSec Tunnels Between the Enterprise Headquarters and Branches Using
IPSec Policy Groups......................................................................................................................................................... 526
6.13.5 Example for Establishing IPSec Tunnels for Branch Access to the Headquarters Using Different Pre-shared Keys
.......................................................................................................................................................................................... 534
6.13.6 Example for Establishing an IPSec Tunnel Between the Headquarters and Branch (One Tunnel Interface
Corresponds to One Branch)............................................................................................................................................ 541
6.13.7 Example for Establishing an IPSec Tunnel Between the Branch and Headquarters with a Redundant Gateway
.......................................................................................................................................................................................... 548
6.13.8 Example for Establishing an IPSec Tunnel Between the Enterprise Headquarters and Branch Using a Multi-Link
Shared IPSec Policy Group.............................................................................................................................................. 555
6.13.9 Example for Establishing an IPSec Tunnel Between the Enterprise Headquarters and Branch Through PPPoE
.......................................................................................................................................................................................... 560
6.13.10 Example for Establishing an IPSec Tunnel Through NAT Traversal..................................................................565
6.13.11 Example for Establishing an IPSec Tunnel in IKE Negotiation Mode by Specifying DNs................................570
6.13.12 Example for Establishing an IPSec Tunnel Through Negotiation Initiated by the Branch User That Dynamically
Obtains an IP Address...................................................................................................................................................... 577
6.13.13 Example for Establishing an IPSec Tunnel Using a Tunnel Interface.................................................................582
6.13.14 Example for Establishing GRE over IPSec Using a Tunnel Interface................................................................ 587
6.13.15 Example for Establishing IPSec over GRE Using a Tunnel Interface................................................................ 592
6.13.16 Example for Establishing an IPSec over GRE Tunnel Between the Headquarters and Branch (Based on ACL)
.......................................................................................................................................................................................... 597
6.13.17 Example for Establishing IPSec over DSVPN Tunnels Between Hub and Spokes (Based on ACL).................602
6.13.18 Example for Configuring L2TP Over IPSec to Implement Secure Communication Between the Headquarters
and Branch........................................................................................................................................................................ 611
6.13.19 Example for Configuring a Tunnel Template Interface for IPSec Tunnel Setup.................................................617
6.13.20 Example for Establishing an IPSec Tunnel Using an Efficient VPN Policy in Client Mode..............................623
6.13.21 Example for Configuring an IPSec Tunnel Using an Efficient VPN Policy in Network Mode..........................628
6.13.22 Example for Configuring an IPSec Tunnel Using an Efficient VPN Policy in Network-Plus Mode................. 632
6.13.23 Example for Configuring Efficient VPN in Network-auto-cfg Mode to Establish an IPSec Tunnel..................636
6.13.24 Example for Configuring Automatic Upgrade of the Efficient VPN Remote Device........................................ 641
6.13.25 Example for Configuring Rapid Switchover and Revertive Switching...............................................................647
6.13.26 Example for Configuring Redundancy Control of IPSec Tunnels...................................................................... 655
6.13.27 Example for Configuring IPSec Gateway Redundancy Control......................................................................... 667
6.14 Troubleshooting IPSec..............................................................................................................................................675
6.14.1 IKE SA Negotiation Failed....................................................................................................................................675
6.14.2 IPSec SA Negotiation Failed................................................................................................................................. 677
6.14.3 Services Are Interrupted After an IPSec Tunnel Is Established............................................................................678
6.15 FAQ About IPSec..................................................................................................................................................... 681
6.15.1 Private Network Communication Fails After IPSec Is Configured. What Are the Causes?.................................681
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xiii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.15.2 How Do I Rectify the Failure to View SA Information by Running the display ipsec sa Command After IPSec Is
Configured?...................................................................................................................................................................... 682
6.15.3 Does the Interface with a Dynamic IP Address Support IPSec?........................................................................... 682
6.15.4 IPSec Does Not Take Effect When Both IPSec and NAT Are Configured on a Device Interface. How This
Problem Is Solved?........................................................................................................................................................... 683
6.15.5 Why Cannot an IPSec Tunnel Be Established Until It Is Restarted?.................................................................... 683
6.16 References for IPSec................................................................................................................................................ 683
7 A2A VPN Configuration.......................................................................................................... 686

7.1 Overview of A2A VPN.............................................................................................................................................. 686
7.2 Understanding A2A VPN........................................................................................................................................... 687
7.2.1 Basic Networking.................................................................................................................................................... 687
7.2.2 Implementation........................................................................................................................................................ 689
7.2.2.1 GM Registering with the KS................................................................................................................................ 689
7.2.2.2 GM Data Protection..............................................................................................................................................690
7.2.2.3 Rekey.................................................................................................................................................................... 691
7.3 Application Scenarios for A2A VPN......................................................................................................................... 691
7.3.1 Typical A2A VPN Networking............................................................................................................................... 691
7.3.2 A2A VPN Redundancy........................................................................................................................................... 693
7.4 Licensing Requirements and Limitations for A2A VPN............................................................................................694
7.5 Default Settings for A2A VPN................................................................................................................................... 695
7.6 Configuring A2A VPN............................................................................................................................................... 695
7.6.1 Configuring a GM................................................................................................................................................... 695
7.6.1.1 Configuring IKE................................................................................................................................................... 696
7.6.1.2 (Optional) Defining Data Flows Not to Be Protected.......................................................................................... 696
7.6.1.3 Configuring a GDOI Policy..................................................................................................................................697
7.6.1.4 Configuring an IP Address for Multicast Rekey Messages..................................................................................698
7.6.1.5 (Optional) Configuring the Receive_Option Mode..............................................................................................699
7.6.1.6 (Optional) Configuring the QoS Function for A2A VPN.................................................................................... 699
7.6.1.7 (Optional) Configuring A2A VPN Multi-Link Sharing....................................................................................... 701
7.6.1.8 (Optional) Configuring Fragmentation Before Encryption.................................................................................. 701
7.6.1.9 Applying a GDOI Policy Group to an Interface...................................................................................................702
7.6.1.10 Verifying the GM Configuration........................................................................................................................ 703
7.7 Maintaining A2A VPN............................................................................................................................................... 703
7.7.1 Monitoring the A2A VPN Status.............................................................................................................................704
7.7.2 Clearing A2A VPN Statistics.................................................................................................................................. 704
7.8 Configuration Examples for A2A VPN......................................................................................................................704
7.8.1 Example for Configuring a Typical A2A VPN Networking................................................................................... 704
7.8.2 Example for Configuring GM Link Redundancy....................................................................................................713
7.9 Troubleshooting A2A VPN........................................................................................................................................ 720
7.9.1 GM Fails to Register with the KS........................................................................................................................... 720
7.10 A2A VPN FAQ.........................................................................................................................................................721
7.10.1 Why Some Service Packets Are Lost After A2A VPN Is Deployed?...................................................................721
7.11 References for A2A VPN......................................................................................................................................... 721
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xiv

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8 BGP/MPLS IP VPN Configuration........................................................................................ 723

8.1 Overview of BGP/MPLS IP VPN.............................................................................................................................. 724
8.2 Understanding BGP/MPLS IP VPN...........................................................................................................................725
8.2.1 Concepts.................................................................................................................................................................. 725
8.2.2 Implementation........................................................................................................................................................ 730
8.2.3 Basic Networking.................................................................................................................................................... 735
8.2.4 Inter-AS VPN.......................................................................................................................................................... 737
8.2.5 MCE.........................................................................................................................................................................744
8.2.6 HoVPN.................................................................................................................................................................... 747
8.2.7 VPN FRR.................................................................................................................................................................751
8.2.8 VPN GR...................................................................................................................................................................753
8.2.9 VPN NSR................................................................................................................................................................ 754
8.2.10 VPN Tunnel Policy................................................................................................................................................754
8.3 Application Scenarios for BGP/MPLS IP VPN......................................................................................................... 757
8.3.1 BGP/MPLS IP VPN Application............................................................................................................................ 757
8.3.2 Hub and Spoke Networking Application.................................................................................................................758
8.3.3 Interconnection Between VPNs and the Internet.....................................................................................................760
8.4 Summary of BGP/MPLS IP VPN Configuration Tasks............................................................................................. 763
8.5 Licensing Requirements and Limitations for BGP/MPLS IP VPN........................................................................... 767
8.6 Default Settings for BGP/MPLS IP VPN...................................................................................................................767
8.7 Configuring BGP/MPLS IP VPN...............................................................................................................................768
8.7.1 Configuring Basic BGP/MPLS IP VPN Functions................................................................................................. 768
8.7.1.1 Configuration Tasks..............................................................................................................................................768
8.7.1.2 Establishing MP-IBGP Peer Relationships Between PE Devices........................................................................770
8.7.1.3 Configuring a VPN Instance on a PE Device.......................................................................................................770
8.7.1.4 Binding a VPN Instance to an Interface............................................................................................................... 773
8.7.1.5 Configuring Route Exchange Between PE and CE Devices................................................................................ 774
8.7.1.6 Verifying the Configuration of Basic BGP/MPLS IP VPN Functions................................................................. 788
8.7.2 Configuring Hub and Spoke.................................................................................................................................... 789
8.7.2.1 Configuring MP-IBGP Between Hub-PE and Spoke-PE.....................................................................................789
8.7.2.2 Configuring VPN Instances on PE Devices......................................................................................................... 790
8.7.2.3 Binding a VPN Instance to an Interface............................................................................................................... 792
8.7.2.4 Configuring Route Exchange Between PE device and CE Devices.....................................................................793
8.7.2.5 Verifying the Hub and Spoke Configuration........................................................................................................ 794
8.7.3 Configuring Inter-AS VPN Option A......................................................................................................................795
8.7.4 Configuring Inter-AS VPN Option B...................................................................................................................... 795
8.7.4.1 Configuring MP-IBGP Between PE and ASBR in the Same AS.........................................................................796
8.7.4.2 Configuring MP-EBGP Between ASBRs in Different ASs................................................................................. 797
8.7.4.3 Disabling an ASBR from Filtering VPNv4 Routes by VPN Targets................................................................... 798
8.7.4.4 (Optional) Configuring Routing Policies to Control VPN Route Advertisement and Acceptance......................799
8.7.4.5 (Optional) Enabling Next-Hop-based Label Allocation on the ASBR................................................................ 800
8.7.4.6 Verifying the Inter-AS VPN Option B Configuration.......................................................................................... 801
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xv

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.5 Configuring Inter-AS VPN Option C (Solution 1)..................................................................................................802

8.7.5.1 Enabling the Labeled IPv4 Route Exchange........................................................................................................ 803
8.7.5.2 Configuring a Routing Policy to Control Label Distribution............................................................................... 804
8.7.5.3 Establishing an MP-EBGP Peer Relationship Between PE Devices................................................................... 806
8.7.5.4 Verifying the Inter-AS VPN Option C Configuration (Solution 1)......................................................................808
8.7.6 Configuring Inter-AS VPN Option C (Solution 2)..................................................................................................808
8.7.6.1 Establishing the EBGP Peer Relationship Between ASBRs................................................................................ 809
8.7.6.2 Advertising the Routes of the PE in the Local AS to the Remote PE.................................................................. 810
8.7.6.3 Enabling the Capability of Exchanging Labeled IPv4 Routes............................................................................. 811
8.7.6.4 Establishing an LDP LSP for the Labeled BGP Routes of the Public Network.................................................. 812
8.7.6.5 Establishing the MP-EBGP Peer Relationship Between PEs...............................................................................812
8.7.6.6 Verifying the Inter-AS VPN Option C Configuration (Solution 2)......................................................................813
8.7.7 Configuring an MCE Device................................................................................................................................... 814
8.7.7.1 Configure Route Exchange Between an MCE Device and VPN Sites................................................................ 814
8.7.7.2 Configure Route Exchange Between an MCE Device and a PE Device............................................................. 819
8.7.7.3 Verifying the MCE Configuration........................................................................................................................ 823
8.7.8 Configuring HoVPN................................................................................................................................................823
8.7.9 Configuring PBR to an LSP for VPN Packets........................................................................................................ 825
8.7.10 Configuring an OSPF Sham Link..........................................................................................................................826
8.7.11 Configuring Route Reflection to Optimize the VPN Backbone Layer................................................................. 830
8.7.11.1 Configuring the Client PEs to Establish MP IBGP Connections with the RR................................................... 830
8.7.11.2 Configuring the RR to Establish MP IBGP Connections with the Client PEs................................................... 831
8.7.11.3 Configuring Route Reflection for BGP IPv4 VPN Routes.................................................................................832
8.7.11.4 Verifying the Configuration of Route Reflection to Optimize the VPN Backbone Layer................................. 833
8.7.12 Configuring IP FRR for VPN Routes....................................................................................................................833
8.7.13 Configuring VPN FRR.......................................................................................................................................... 835
8.7.14 Configuring VPN GR............................................................................................................................................ 838
8.7.15 Configuring Tunnel Policies..................................................................................................................................839
8.7.15.1 Configuring and Applying a Tunnel Policy........................................................................................................840
8.7.15.2 Configuring and Applying a Tunnel Selector.....................................................................................................842
8.7.16 Connecting a VPN to the Internet..........................................................................................................................844
8.8 Maintaining BGP/MPLS IP VPN...............................................................................................................................846
8.8.1 Collecting Statistics About L3VPN Traffic.............................................................................................................846
8.8.2 Checking L3VPN Traffic.........................................................................................................................................847
8.8.3 Clearing L3VPN Traffic.......................................................................................................................................... 847
8.8.4 Displaying BGP/MPLS IP VPN Information..........................................................................................................847
8.8.5 Checking Network Connectivity and Reachability................................................................................................. 848
8.8.6 Viewing the Integrated Route Statistics of IPv4 VPN Instances.............................................................................849
8.8.7 Resetting BGP Statistics of a VPN Instance IPv4 Address Family........................................................................ 849
8.8.8 Resetting BGP Connections.................................................................................................................................... 850
8.8.9 Monitoring the Running Status of VPN Tunnels.....................................................................................................850
8.9 Configuration Examples for BGP/MPLS IP VPN..................................................................................................... 851
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xvi

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.9.1 Example for Configuring BGP/MPLS IP VPN....................................................................................................... 851

8.9.2 Example for Configuring BGP/MPLS IP VPNs with Overlapping Address Spaces.............................................. 863
8.9.3 Example for Configuring Communication Between Local VPNs.......................................................................... 872
8.9.4 Example for Configuring Hub and Spoke............................................................................................................... 877
8.9.5 Example for Configuring Inter-AS VPN Option A................................................................................................. 886
8.9.6 Example for Configuring Inter-AS VPN Option B................................................................................................. 897
8.9.7 Example for Configuring Inter-AS VPN Option C (Solution 1).............................................................................906
8.9.8 Example for Configuring Inter-AS VPN Option C (Solution 2).............................................................................917
8.9.9 Example for Configuring MCE............................................................................................................................... 929
8.9.10 Example for Configuring PBR to an LSP for VPN Packets..................................................................................939
8.9.11 Example for Configuring HoVPN......................................................................................................................... 945
8.9.12 Example for Configuring an OSPF Sham Link.....................................................................................................954
8.9.13 Example for Configuring BGP AS Number Substitution..................................................................................... 964
8.9.14 Example for Configuring the BGP SoO Attribute.................................................................................................970
8.9.15 Example for Configuring CE Dual-homing.......................................................................................................... 979
8.9.16 Example for Configuring VPN FRR..................................................................................................................... 994
8.9.17 Example for Configuring IP FRR for VPN Routes............................................................................................. 1003
8.9.18 Example for Configuring VPN GR..................................................................................................................... 1008
8.9.19 Example for Configuring Double RRs to Optimize the VPN Backbone Layer.................................................. 1019
8.9.20 Example for Connecting a VPN to the Internet...................................................................................................1029
8.9.21 Example for Configuring BGP/MPLS IP VPN to Use a GRE Tunnel................................................................1037
8.9.22 Example for Configuring L3VPN Using LDP Signaling over GRE...................................................................1045
8.9.23 Example for Configuring L3VPN with LDP Signals Carried by DSVPN..........................................................1054
8.9.24 Example for Configuring L3VPN with LDP Signals Carried by DSVPN and Protected by IPSec....................1068
8.9.25 Example for Configuring a Tunnel Policy for an L3VPN...................................................................................1086
8.10 FAQ About BGP/MPLS IP VPN............................................................................................................................1097
8.10.1 Why Routes Cannot Be Imported When AS Numbers on the BGP/MPLS IP VPN Are the Same?.................. 1098
8.11 References for BGP/MPLS IP VPN....................................................................................................................... 1098
9 MCE IPv6 Configuration........................................................................................................1099

9.1 Overview of MCE IPv6............................................................................................................................................ 1099
9.2 Licensing Requirements and Limitations for MCE IPv6......................................................................................... 1101
9.3 Configuring an MCE Device.................................................................................................................................... 1101
9.3.1 Configuring a VPN Instance..................................................................................................................................1101
9.3.2 Configure Route Exchange Between an MCE Device and VPN Sites..................................................................1103
9.3.3 Configure Route Exchange Between an MCE Device and a PE Device...............................................................1108
9.3.4 Verifying the MCE Configuration......................................................................................................................... 1112
9.4 Configuration Examples for MCE IPv6................................................................................................................... 1113
9.4.1 Example for Configuring an MCE IPv6 Device....................................................................................................1113
10 EVPN Configuration.............................................................................................................1130
10.1 Overview of EVPN.................................................................................................................................................1130
10.2 Understanding EVPN............................................................................................................................................. 1131
10.2.1 Implementation.................................................................................................................................................... 1131
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xvii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
10.3 Application Scenarios for EVPN............................................................................................................................1134

10.3.1 EVPN Applications..............................................................................................................................................1134
10.4 Licensing Requirements and Limitations for EVPN.............................................................................................. 1135
10.5 Configuring EVPN Functions.................................................................................................................................1136
10.5.1 Before You Start.................................................................................................................................................. 1136
10.5.2 Configuring a VPN Instance................................................................................................................................1137
10.5.3 Binding an Interface to a VPN Instance.............................................................................................................. 1138
10.5.4 Configuring an EVPN BGP Peer Relationship....................................................................................................1139
10.5.5 Verifying the EVPN Configuration......................................................................................................................1140
10.6 Maintaining EVPN................................................................................................................................................. 1143
10.6.1 Configuring EVPN BGP Soft Reset.................................................................................................................... 1143
10.6.2 Resetting EVPN BGP Connections..................................................................................................................... 1143
10.7 Configuration Examples for EVPN........................................................................................................................ 1144
10.7.1 Example for Dynamically Establishing a VXLAN Tunnel in BGP EVPN Mode to Implement Communication
Between Users in Different Network Segments............................................................................................................. 1144
10.8 References for EVPN..............................................................................................................................................1151
11 VLL Configuration................................................................................................................ 1152

11.1 Overview of VLL....................................................................................................................................................1153
11.2 Understanding VLL................................................................................................................................................ 1154
11.2.1 Implementation.................................................................................................................................................... 1154
11.2.2 VLL Modes..........................................................................................................................................................1157
11.2.2.1 VLL in CCC Mode........................................................................................................................................... 1157
11.2.2.2 VLL in Martini Mode....................................................................................................................................... 1158
11.2.2.3 VLL in SVC Mode............................................................................................................................................1163
11.2.2.4 Comparison of VLL Modes.............................................................................................................................. 1164
11.2.3 Inter-AS VLL.......................................................................................................................................................1165
11.2.4 VLL FRR............................................................................................................................................................. 1166
11.3 Application Scenarios for VLL...............................................................................................................................1169
11.3.1 Point-to-Point Layer 2 Connection Between Sites in Different Cities................................................................ 1169
11.3.2 Multi-service Transparent Transmission over PWs on a MAN...........................................................................1169
11.4 Summary of VLL Configuration Tasks.................................................................................................................. 1170
11.5 Licensing Requirements and Limitations for VLL................................................................................................. 1172
11.6 Default Settings for VLL........................................................................................................................................ 1172
11.7 Configuring VLL.................................................................................................................................................... 1172
11.7.1 Configuring the CCC VLL.................................................................................................................................. 1173
11.7.2 Configuring the Martini VLL.............................................................................................................................. 1173
11.7.3 Configuring the SVC VLL...................................................................................................................................1175
11.7.4 Configuring Inter-AS VLL.................................................................................................................................. 1176
11.7.5 Configuring VLL FRR.........................................................................................................................................1177
11.7.5.1 Configuring Primary and Secondary PWs........................................................................................................1178
11.7.5.2 (Optional) Configuring Fast Fault Notification - OAM Mapping.................................................................... 1179
11.7.5.3 (Optional) Configuring BFD for PW................................................................................................................1180
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xviii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.7.5.4 (Optional) Configuring a Revertive Switchover Policy....................................................................................1180

11.7.5.5 Verifying the VLL FRR Configuration.............................................................................................................1181
11.7.6 Configuring the Access of VLL to L3VPN......................................................................................................... 1182
11.7.6.1 Before You Start................................................................................................................................................1182
11.7.6.2 Creating an L2VE Interface.............................................................................................................................. 1184
11.7.6.3 Creating an L3VE Interface.............................................................................................................................. 1184
11.7.6.4 Associating the L2VE Interface with a VLL.................................................................................................... 1185
11.7.6.5 Configuring the Access of a User to L3VPN....................................................................................................1186
11.7.6.6 Verifying the configuration of Martini VLL to Access L3VPN....................................................................... 1187
11.7.7 Configuring and Applying a Tunnel Policy......................................................................................................... 1187
11.7.8 Configuring the Alarm Report Function..............................................................................................................1190
11.8 Maintaining VLL.................................................................................................................................................... 1191
11.8.1 Monitoring the Running Status of VLL...............................................................................................................1191
11.8.2 Checking Connectivity of the VLL Network.......................................................................................................1191
11.9 Configuration Examples for VLL...........................................................................................................................1193
11.9.1 Example for Configuring a Local CCC Connection............................................................................................1193
11.9.2 Example for Configuring a VLL Connection in SVC Mode...............................................................................1195
11.9.3 Example for Configuring a VLL Connection in Martini Mode...........................................................................1200
11.9.4 Example for Configuring Inter-AS Martini VLL (Option A)..............................................................................1206
11.9.5 Example for Configuring Martini VLL FRR (Asymmetrically Connected CEs)............................................... 1213
11.9.6 Example for Configuring VLL to Use a GRE Tunnel.........................................................................................1230
11.9.7 Example for Configuring a VLL Using an MPLS TE Tunnel.............................................................................1236
11.10 Troubleshooting VLL........................................................................................................................................... 1244
11.10.1 The VC of a Martini VLL Connection Cannot Go Up...................................................................................... 1244
11.11 References for VLL.............................................................................................................................................. 1246
12 PWE3 Configuration............................................................................................................. 1247

12.1 Overview of PWE3.................................................................................................................................................1248
12.2 Relationship Between PWE3 and L2VPN............................................................................................................. 1249
12.2.1 Extensions to the Control Plane...........................................................................................................................1249
12.2.2 Extensions at the Data Plane............................................................................................................................... 1249
12.3 Understanding PWE3............................................................................................................................................. 1250
12.3.1 Implementation.................................................................................................................................................... 1250
12.3.2 Control Word....................................................................................................................................................... 1254
12.3.3 VCCV.................................................................................................................................................................. 1255
12.3.4 PWE3 FRR.......................................................................................................................................................... 1256
12.3.5 Inter-AS Technology............................................................................................................................................1258
12.4 Application Scenarios for PWE3............................................................................................................................1259
12.4.1 PWE3 Carrying Enterprise Leased Line Services on a MAN.............................................................................1259
12.5 Summary of PWE3 Configuration Tasks............................................................................................................... 1260
12.6 Licensing Requirements and Limitations for PWE3.............................................................................................. 1262
12.7 Default Settings for PWE3..................................................................................................................................... 1263
12.8 Configuring PWE3................................................................................................................................................. 1263
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xix

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.8.1 Configuring a Static PW......................................................................................................................................1263

12.8.1.1 Enabling MPLS L2VPN................................................................................................................................... 1264
12.8.1.2 (Optional) Creating a PW Template and Setting Attributes for the PW Template ..........................................1264
12.8.1.3 Creating a Static PW.........................................................................................................................................1265
12.8.1.4 Verifying the Static PW Configuration.............................................................................................................1266
12.8.2 Configuring a Dynamic PW................................................................................................................................ 1267
12.8.2.1 Enabling MPLS L2VPN................................................................................................................................... 1267
12.8.2.2 (Optional) Creating a PW Template and Setting Attributes for the PW Template ..........................................1268
12.8.2.3 Creating a Dynamic PW................................................................................................................................... 1269
12.8.2.4 Verifying the Dynamic PW Configuration....................................................................................................... 1270
12.8.3 Configuring PW Switching................................................................................................................................. 1270
12.8.4 Configuring TDM PWE3.................................................................................................................................... 1272
12.8.4.1 Configuring an AC Interface to Transparently Transmit TDM Cells...............................................................1273
12.8.4.2 (Optional) Creating a PW Template and Setting Attributes for the PW Template...........................................1274
12.8.4.3 Configuring PW................................................................................................................................................1276
12.8.4.4 Verifying the TDM PWE3 Configuration........................................................................................................ 1278
12.8.5 Configuring Static BFD for PWs.........................................................................................................................1279
12.8.5.1 Enabling BFD Globally.................................................................................................................................... 1279
12.8.5.2 Configuring BFD for PWs................................................................................................................................1280
12.8.5.3 Verifying the Configuration of Static BFD for PWs........................................................................................ 1281
12.8.6 Configuring PWE3 FRR......................................................................................................................................1281
12.8.6.1 Configuring Primary and Secondary PWs........................................................................................................1282
12.8.6.2 (Optional) Configuring Fast Fault Notification - OAM Mapping....................................................................1283
12.8.6.3 (Optional) Configuring BFD for PW................................................................................................................1284
12.8.6.4 (Optional) Configuring a Revertive Switchover Policy................................................................................... 1284
12.8.6.5 Verifying the PWE3 FRR Configuration..........................................................................................................1285
12.8.7 Configuring Inter-AS PWE3............................................................................................................................... 1286
12.8.8 Configuring and Applying a Tunnel Policy.........................................................................................................1287
12.9 Maintaining PWE3................................................................................................................................................. 1290
12.9.1 Verifying Connectivity of a PW.......................................................................................................................... 1290
12.9.2 Locating a Fault on a PW.................................................................................................................................... 1292
12.10 Configuration Examples for PWE3...................................................................................................................... 1293
12.10.1 Example for Configuring a Dynamic Single-Segment PW...............................................................................1293
12.10.2 Example for Configuring a Static Multi-Segment PW......................................................................................1298
12.10.3 Example for Configuring a Dynamic Multi-Segment PW................................................................................ 1305
12.10.4 Example for Configuring a Mixed Multi-Segment PW.................................................................................... 1313
12.10.5 Example for Configuring Inter-AS PWE3 Option A........................................................................................ 1321
12.10.6 Example for Configuring TDM PWE3 (Using the 8E1T1-M Interface Card)..................................................1327
12.10.7 Example for Configuring TDM PWE3 (Using the 8SA interface card)........................................................... 1335
12.11 References for PWE3............................................................................................................................................1341
13 VPLS Configuration..............................................................................................................1343
13.1 Overview of VPLS................................................................................................................................................. 1344
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xx

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.2 Understanding VPLS.............................................................................................................................................. 1345

13.2.1 Implementation.................................................................................................................................................... 1345
13.2.2 PW Signaling Protocols.......................................................................................................................................1349
13.2.3 Packet Encapsulation........................................................................................................................................... 1350
13.2.4 MAC Address Management................................................................................................................................ 1354
13.2.5 Loop Prevention.................................................................................................................................................. 1357
13.2.6 Inter-AS VPLS.....................................................................................................................................................1357
13.3 Application Scenarios for VPLS............................................................................................................................ 1359
13.3.1 VPLS Application in Individual Services........................................................................................................... 1359
13.3.2 VPLS Application in Enterprise Services........................................................................................................... 1361
13.4 Licensing Requirements and Limitations for VPLS...............................................................................................1363
13.5 Default Settings for VPLS...................................................................................................................................... 1363
13.6 Configuring Martini VPLS..................................................................................................................................... 1364
13.6.1 Creating a VSI and Configuring LDP Signaling................................................................................................. 1364
13.6.2 Binding VSIs to AC Interfaces............................................................................................................................ 1366
13.6.3 Verifying the Martini VPLS Configuration......................................................................................................... 1368
13.7 (Optional) Configuring Inter-AS Martini VPLS.................................................................................................... 1368
13.7.1 Configuring Inter-AS Martini VPLS in OptionA Mode......................................................................................1369
13.7.2 Configuring Inter-AS Martini VPLS in OptionC Mode......................................................................................1370
13.8 (Optional) Setting Related Parameters for a VSI................................................................................................... 1373
13.8.1 Configuring a PE to Send MAC Withdraw Messages to Remove MAC Address Entries..................................1373
13.8.2 Configuring MAC Withdraw Loop Detection.....................................................................................................1374
13.8.3 Configuring MAC Address Learning.................................................................................................................. 1374
13.8.4 Configuring a VSI to Ignore the AC Status.........................................................................................................1376
13.9 Maintaining VPLS.................................................................................................................................................. 1377
13.9.1 Collecting Traffic Statistics on a VPLS PW........................................................................................................1377
13.9.2 Clearing the Traffic Statistics.............................................................................................................................. 1378
13.9.3 Checking Traffic Statistics on a VPLS PW......................................................................................................... 1378
13.9.4 Enabling or Disabling VSI.................................................................................................................................. 1379
13.9.5 Clearing MAC Address Entries........................................................................................................................... 1379
13.9.6 Checking Connectivity of the VPLS Network.................................................................................................... 1380
13.9.7 Configuring the Upper and Lower Alarm Thresholds for VPLS VCs................................................................ 1380
13.9.8 Checking MPLS L2VPN Usage Information...................................................................................................... 1381
13.10 Configuration Examples for VPLS.......................................................................................................................1381
13.10.1 Example for Configuring Martini VPLS........................................................................................................... 1381
13.10.2 Example for Configuring Inter-AS Martini VPLS in OptionA Mode...............................................................1388
13.11 Troubleshooting VPLS......................................................................................................................................... 1395
13.11.1 VSI Cannot Go Up in Martini VPLS Mode...................................................................................................... 1395
13.12 References for VPLS............................................................................................................................................ 1396
14 VXLAN Configuration......................................................................................................... 1397

14.1 Overview of VXLANs............................................................................................................................................1397
14.2 Understanding VXLANs........................................................................................................................................ 1399
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xxi

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
14.2.1 VXLAN Network Architecture........................................................................................................................... 1399

14.2.2 Packet Encapsulation Format.............................................................................................................................. 1403
14.2.3 VXLAN Implementation..................................................................................................................................... 1405
14.2.3.1 Packet Identification......................................................................................................................................... 1405
14.2.3.2 Tunnel Establishment....................................................................................................................................... 1409
14.2.3.3 Packet Forwarding............................................................................................................................................ 1410
14.3 Application Scenario.............................................................................................................................................. 1417
14.4 Licensing Requirements and Limitations for VXLAN.......................................................................................... 1418
14.5 Configuring VXLAN (in Static Mode).................................................................................................................. 1419
14.5.1 Configuring Deployment Mode for VXLAN Access Service.............................................................................1421
14.5.2 Configuring a VXLAN Tunnel............................................................................................................................1423
14.5.3 Configuring a Layer 3 VXLAN Gateway........................................................................................................... 1425
14.5.4 (Optional) Configuring Static ARP Entries.........................................................................................................1426
14.5.5 (Optional) Configuring a Static MAC Address Entry......................................................................................... 1427
14.5.6 (Optional) Configuring the IP Address of the Next Hop to Which Traffic Entering a Dynamic VXLAN Tunnel Is
Redirected....................................................................................................................................................................... 1428
14.5.7 Verifying the VXLAN Configuration in Centralized Gateway Mode Using Static Mode..................................1429
14.6 Configuring VXLAN (in BGP EVPN Mode)........................................................................................................ 1429
14.6.1 Configuring Deployment Mode for VXLAN Access Service.............................................................................1430
14.6.2 Configuring a VXLAN Tunnel............................................................................................................................1432
14.6.3 Configuring a Layer 3 VXLAN Gateway........................................................................................................... 1434
14.6.4 Checking the Configuration.................................................................................................................................1436
14.7 Configuration Examples for VXLANs...................................................................................................................1436
14.7.1 Example for Configuring Communication Within a Network Segment Through a VXLAN Tunnel.................1436
14.7.2 Example for Configuring a Layer 3 VXLAN Gateway to Enable Communication Between Users in Different
Network Segments..........................................................................................................................................................1441
14.7.3 Example for Dynamically Establishing a VXLAN Tunnel in BGP EVPN Mode to Implement Communication
Between Users in Different Network Segments............................................................................................................. 1447
14.7.4 Example for Configuring the Headquarters and Branch to Communicate Using VXLAN over IPSec Tunnels 1453
14.8 References for VXLANs........................................................................................................................................ 1464
14.9 Further Reading...................................................................................................................................................... 1464
14.9.1 Server Virtualization............................................................................................................................................1464
14.9.2 Large Layer 2 Network........................................................................................................................................1465
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xxii

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 1 Auto VPN Configuration
1 Auto VPN Configuration
About This Chapter
This chapter describes principles, applications, and configurations of the auto VPN.
1.1 Overview of Auto VPN
1.2 Understanding Auto VPN
1.3 Application Scenarios for Auto VPN
1.4 Licensing Requirements and Limitations for Auto VPN
1.5 Configuring Auto VPN
1.6 References
1.1 Overview of Auto VPN

Definition
Auto VPN is a VPN technology that is used to separate the overlay network from the
underlying transport network and separate service network routes from transport network
routes. Auto VPN uses a mechanism similar to BGP/MPLS IP VPN. It uses BGP extension
and reachability information after extension to make underlying transport networks of
different sites to interwork with each other. It controls protocols and advertises routes in a
unified manner through multiple VPN capabilities of BGP to transfer tunnel encapsulation
information between different site networks from the data plane to the control plane.
Figure 1-1 shows the basic usage scenario of auto VPN.
Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-1 Usage scenario of auto VPN
CE3
PE3
PE4 CE4
RR
CE1
PE1 PE2
CE2
Purpose
In a scenario where services are deployed on a carrier network, data needs to be transmitted
between CEs. When the networking scale is large, the configuration becomes complex.
Applying auto VPN can separate service network routes from transport network routes,
ensuring rapid and secure data transmission. Auto VPN implements full connection of tunnels
between sites, ensures data transmission on a service network, reduces the configuration
workload, reduces the number of links on the network, and improves the network
performance. Data is transmitted through tunnels, achieving rapid and secure transmission of
service traffic and guaranteeing carrier services.
Auto VPN carries extended community attributes through BGP extension to control the
network topology through routing policies. Auto VPN enables networks to have the plug-and-
play function and be easy-to-extend.
1.2 Understanding Auto VPN
1.2.1 Auto VPN Fundamentals
Definition
Auto VPN is a VPN technology that is used to separate the overlay network from the
underlying transport network and separate service network routes from transport network
routes. Auto VPN uses a mechanism similar to BGP/MPLS IP VPN. It uses BGP extension
and reachability information after extension to make underlying transport networks of
different sites to interwork with each other. It controls protocols and advertises routes in a
unified manner through multiple VPN capabilities of BGP to transfer tunnel encapsulation
information between different site networks from the data plane to the control plane.
Figure 1-2 shows the basic usage scenario of auto VPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-2 Usage scenario of auto VPN
CE3
PE3
PE4 CE4
RR
CE1
PE1 PE2
CE2
Auto VPN Routes

The format of NLRI specific to an auto VPN route is shown in Figure 1-3.
Figure 1-3 Format of NLRI specific to an auto VPN route
NLRI Length (1 byte)

Tunnel Type (2 bytes)
Distinguisher (4 bytes)
Color (4 bytes)
Endpoint (4 or 16 bytes)
The description of each field is as follows.
Field Description
NLRI Length Length of an address prefix.
Tunnel Type Tunnel type carried in the route.
Distinguisher Service ID of the tunnel.
Color ID of a PE and index of the

recursive tunnel on the PE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Field Description
Endpoint Destination node of the tunnel, 4

or 16 bytes. If the address family
identifier (AFI) is IPv4, this field
indicates an IPv4 address. If the
AFI is IPv6, this field indicates an
IPv6 address.
Tunnel Encapsulation Attribute

Tunnel Encapsulation Attribute, which is an optional transitive attribute, is added. The field is
used to carry tunnel encapsulation information.
Concepts of auto VPN

l DTLS: In an SD-WAN scenario, a CPE establishes a DTLS connection with an RR to set
up a control channel, so that transport network port (TNP) information can be exchanged
between the CPE and RR. The CPE-RR connection is calculated through sending and
reflecting TNP information to set up a management channel, namely, a BGP peer
relationship is established using the system ip between the RR and site.
l TNP: A CPE is connected to a WAN interface of the transport network. The key
information includes the site ID, transport network-ID, public IP address, private IP
address, and tunnel encapsulation. The key information is delivered by the Agile
Controller-Campus to the CPE. A site advertises local TNP information to the RR
through the route with Tunnel Type200, and the RR reflects the routing information to
another site, so that the site ID and tunnel encapsulation information can be transferred.
Auto VPN Route Advertisement Process

Auto VPN routes are advertised through the following process:
If no RR is deployed:
1. PE1 and PE2 establish an auto VPN peer relationship.
2. PE1 and PE2 use BGP to advertise routes.
3. After PE1 and PE2 receive routes from each other, the system saves the tunnel
encapsulation information carried in the routes.
If an RR is deployed:
1. PE1 and PE2 each establish an auto VPN peer relationship with the RR.
2. PE1 and PE2 use BGP to advertise routes to the RR, which then reflects the routes.
3. After PE1 and PE2 receive routes from each other, the system saves the tunnel
encapsulation information carried in the routes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-4 Auto VPN networking diagram
RR
or
PE1 PE2
PE1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1.3 Application Scenarios for Auto VPN
1.3.1 Implementing Auto VPN Tenant Isolation

Service Description
When a carrier provides services for tenants, the tenants need to be isolated to allow data
transmission between specific tenants.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-5 Auto VPN tenant isolation
PE3 PE4
Route-policy:
group_in
CE3 group_out
RR
CE1 PE1 PE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Networking Description
On the network shown in Figure 1-5, CE1 and CE2 belong to a tenant, and CE3 and CE4
belong to another tenant. The following requirement needs to be met:
l CE1 and CE2 can communicate with each other.
l CE3 and CE4 can communicate with each other.
l CE1 and CE3 are isolated from each other.
l CE2 and CE4 are isolated from each other.
To meet this requirement, the RR must reflect only a local tenant's routes and isolates routes
from the other tenants. Specifically, the following configurations need to be performed on the
RR:
l Add PE1 and PE2 to the peer group Group1, and add PE3 and PE4 to the peer group
Group2.
l Configure the import route-policy Group1_in and export route policy-Group1_out for
Group1.
l Configure the Group1_in policy to apply the community attribute aa1:nn1.
l Configure the Group1_out policy to filter routes based on the community attribute
aa1:nn1.
l Configure the import route-policy Group2_in and export route-policy Group2_out for
Group2.
l Configure Group2_in to apply the community attribute aa2:nn2.
l Configure Group2_out to apply the filtering community attribute aa2:nn2.
The route policies configured allow the RR to reflect routes only from the same tenant. In this
manner, services can be transmitted between CEs of the same tenant, and services of different
tenants can be isolated.
1.3.2 Using Backup PEs on an Auto VPN

Service Description
When a carrier provides services for tenants, backup PEs can be added so that more backup
channels are set up for forwarding. This ensures that service traffic can be switched to a
backup channel if the primary channel becomes unavailable.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-6 Auto VPN with a best-effort site
PE1 PE4
Route-Policy:
evpn_export_policy
CE1
RR
PE3 PE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On the network shown in Figure 1-6, PE1 and PE2 need to transmit data through the tunnel
between them. If the link between PE1 and PE2 or between PE1 and the RR goes Down, the
tunnel over the standby link between PE2 and PE3 is expected to transmit data.
To meet this requirement, the RR must add the Color extcommunity attribute of PE3 to the
BGP routes sent from PE1. Specifically, the following configurations need to be performed on
the RR:
l Configure a route-policy named evpn_export_policy.
l Specify PE1's RT and Color extcommunity attribute in the route-policy to filter routes.
l Apply the Color value of PE3 to the matched routes (PE3's priority must be lower than
PE2's priority).
In this manner, if the primary tunnel becomes unavailable, traffic is transmitted through the
tunnel configured on PE3 because the routes carry the Color value of PE3.
1.3.3 Routing Auto VPN Traffic Through a Hub Device

Service Description
When a carrier provides services over a network with a Hub device deployed, traffic is
expected to pass through the Hub device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-7 Routing auto VPN traffic through a hub device
IRT:200:1 Route-Policy: IRT:200:1

ERT:100:1 evpn_export_policy ERT:100:1
CE1 PE1 RR PE2
vpn_in IRT :100:1

HUB
vpn_out ERT:200:1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On the network shown in Figure 1-7, to transmit traffic through the Hub device, you need to
change the Color extcommunity attribute of BGP routes on PE1 and PE2 to the Color
extcommunity attribute of the Hub device on the RR. Specifically, the following
configurations need to be performed on the RR and Hub device:
l Enable the RR to modify the path attribute of BGP routes based on an export route-
policy.
l Specify the RTs and Color extcommunity attributes of PE1 and PE2 in the route-policy
to filter routes.
l Apply the Color value of the Hub device to the matched routes and change the next hop
to the Hub device.
Because the Color extcommunity attribute carried in the next hop of the routes passing
through the RR is the same as the Color value of the Hub device, traffic is transmitted through
the Hub device. That is, the traffic passes through the tunnel between PE1 and the Hub device
and then through the tunnel between the Hub device and PE2.
1.3.4 Routing Auto VPN Traffic Through a Hub-CE Device

Service Description
When a carrier provides services over a network with a Hub-PE device and a Hub-CE device
deployed, traffic is expected to pass through both of the two devices.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-8 Routing auto VPN traffic through a Hub-CE device
IRT:200:1 Route-Policy: IRT:200:1

ERT:100:1 evpn_export_policy ERT:100:1
CE1 PE1 RR PE2

HUB-PE
vpn_in IRT :100:1

vpn_out ERT:200:1
BGP Allow-AS-Loop
HUB-CE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On the network shown in Figure 1-8, to transmit traffic through the Hub-PE device and then
forward it to the Hub-CE device, the following configurations need to be performed on the
RR and Hub-PE device:
l Enable the RR to modify the path attribute of BGP routes based on an export route-
policy.
l Specify the RTs and Color extcommunity attributes of PE1 and PE2 in the route-policy
to filter routes.
l Apply the Color value of the Hub-PE device to the matched routes and change the next
hop to the Hub-PE device.
l Change the VN ID of the matched routes to the VN ID of vpn_out on the Hub-PE
device to guide subsequent route lookup and traffic forwarding.
l Create two VPN instances (vpn_in and vpn_out) on the Hub-PE device. The EVPN-
VPN target received by vpn_in is the same as that advertised by PE1. The EVPN-VPN
target advertised by vpn_out is different from that received by vpn_out and is the same
as that received by PE2.
l On the Hub-PE device, set the number of times that the local AS number can be repeated
to 1.
Because the Color value of the routes received by PE2 is the same as the Color value of the
Hub-PE device, traffic is recursively sent to the tunnel between PE1 and the Hub-PE device
for transmission. Because the VN ID in the routes received by PE2 is the same as the VN ID
of vpn_out on the Hub-PE device, the Hub-PE device searches the vpn_out routing table for
a route. Traffic is forwarded to the Hub-PE device through the Hub-CE device and then sent
to PE2 through the tunnel between the Hub-PE device and PE2.
1.4 Licensing Requirements and Limitations for Auto VPN

Involved Network Elements
None
License Requirements
Auto VPN is a basic feature of the device and is not under license control.
Feature Limitations
V300R003C10 and later versions support auto VPN.
1.5 Configuring Auto VPN

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1.5.1 Prerequisites for Configuring Auto VPN

Before configuring auto VPN functions, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Usage Scenario
When a carrier provides services for tenants, auto VPN is deployed to separate the service
network from the transport network. This allows full-mesh tunnels to be established between
PEs on the transport network and ensures secure transmission on the service network.
Figure 1-9 shows a Tunnel-encap-ext network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 1-9 Auto vpn networking model
PE3 PE4
CE3 C
RR
CE1 PE1 PE2 C

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Prerequisites
Before configuring auto VPN, complete the following configurations:
l The Agile Controller-Campus has delivered site TNP configurations to PEs.
For detailed configurations, see Configuring TNP information of a site in Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600
Series Enterprise Routers NETCONF YANG API.
l The Agile Controller-Campus has delivered interface TNP configurations to PEs.
For detailed configurations, see Configuring TNP information of an interface in
Huawei
l The Agile Controller-Campus has delivered DTLS configurations to PEs and CEs.
For detailed configurations, see DTLS in Huawei
l There are reachable routes between the WAN interface's IP address and the public
network.
Data Preparation
To configure auto VPN functions, you need the following data.
No. Data
1 IP addresses of interfaces interconnecting the PEs or connecting the PEs to the RR
1.5.2 Configuring Auto VPN Peer Relationships

After two PEs establish an auto VPN peer relationship, they can exchange auto VPN routes.
Context
On an auto VPN network, two PEs need to establish an auto VPN peer relationship before
they can exchange auto VPN routing information.
If no RR is deployed, perform the following steps on each PE. If an RR is deployed, perform
the following steps on each PE and the RR.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run bgp as-number
The BGP view is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 3 Run peer ipv4-address as-number { as-number-plain | as-number-dot }
The peer PE is specified as a BGP peer.
Step 4 Run peer ipv4-address connect-interface interface-type interface-number
An interface used to establish a TCP connection for a BGP peer relationship is specified.
Step 5 Run ipv4-family tunnel-encap-ext
The BGP Tunnel-encap-ext IPv4 address family is enabled, and its view is displayed.
Step 6 Run peer { ipv4-address | group-name } enable
The capability to exchange auto VPN routes with the specified peer or peer group is enabled.
Step 7 (Optional) Run peer ipv4-address group group-name
The auto VPN peer is added to the peer group.
Adding auto VPN peers to a peer group simplifies BGP network configuration and
management.
Step 8 (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-name export
A route-policy is specified for the auto VPN peer or peer group to advertise only specified
routes.
An export route-policy must be configured to precisely control auto VPN routes. An export
route-policy filters routes before they are advertised to other auto VPN peers or peer groups.
Step 9 (Optional) Run peer { ipv4-address | group-name } route-policy route-policy-name import
A route-policy is specified for the auto VPN peer or peer group to receive only specified
routes.
An import route-policy must also be configured to precisely control auto VPN routes. An
import route-policy filters routes that are received from other auto VPN peers or peer groups.
Step 10 (Optional) Run peer { ipv4-address | group-name } route-limit limit [ percentage ] [ alert-
only | idle-forever | idle-timeout minutes ]
The maximum number of routes that can be received from a peer is specified.
----End
1.5.3 (Optional) Configuring an Auto VPN RR

Configuring an auto VPN VPN RR helps minimize the number of Tunnel-encap-ext peer
relationships on a network and simplify configuration.
Context
After an RR is configured on a network, auto VPN peer relationships are established only
between PEs and the RR. This helps minimize the number of auto VPN peer relationships on
the network and simplify configuration. You can configure an existing device on the network
as an RR or add a device to function as a standalone RR.
Perform the following steps on the device that is to function as an RR.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Run ipv4-family tunnel-encap-ext
The BGP Tunnel-encap-ext IPv4 address family is enabled, and its view is displayed.
The capability to exchange auto VPN routes with the specified peer or peer group is enabled.
Step 5 Run peer { ipv4-address | group-name } reflect-client
The local device is configured as an RR, and a peer or peer group is specified as the RR
client.
----End
1.5.4 Setting a Value for the Color Attribute

You can set a value for the Color attribute so that the value is carried in service routes to
generate tunnel encapsulation information.
Context
A value for the Color attribute is set on a PE. The value is carried in service routes to generate
tunnel encapsulation information.
Procedure
Step 2 Run route-policy route-policy-name { permit | deny } node node
A route-policy node is created, and the route-policy view is displayed.
Step 3 Run apply extcommunity { color priority:site-id } & <1-16> [ additive ]
A value is set for the Color attribute in BGP routes.
----End
1.5.5 Configuring EVPN Services

Currently, only an EVPN can be used as a service network for auto VPN.
Context
On an auto VPN network, an EVPN needs to be configured between PEs to function as a
service network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Configure a VPN instance.
a. Run system-view

b. Run ip vpn-instance vpn-instance-name
A VPN instance is created, and the VPN instance view is displayed.

c. (Optional) Run evpn vn-id vn-id
A vn-id to is binded to the VPN instance.

d. Run ipv4-family
The IPv4 address family is enabled in the VPN instance, and the VPN instance IPv4
address family view is displayed.
e. Run route-distinguisher route-distinguisher
A route distinguisher (RD) is configured for the VPN instance.
A VPN instance takes effect only after an RD is configured for it. The RDs of
different VPN instances on the same PE must be different.
f. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] evpn
EVPN-VPN targets are configured for the VPN instance.
EVPN-VPN targets are BGP extended community attributes used to control the
receiving and advertisement of EVPN routes. A maximum of eight EVPN-VPN
targets can be configured using the vpn-target evpn command at a time. To
configure more EVPN-VPN targets in the EVPN instance address family, run the
vpn-target evpn command several times.
g. Run export route-policy route-policy-name evpn
The VPN instance IPv4 address family is associated with the route-policy created
when the Color attribute is set. In this manner, the routes advertised to the EVPN
address family carry the Color attribute for tunnel recursion.
h. (Optional) Run import route-policy policy-name evpn
The VPN instance IPv4 address family is associated with an import route-policy to
filter the EVPN routes imported from the EVPN address family.
To precisely control EVPN routes, an import route-policy must also be configured.

An import route-policy filters routes that are received from the EVPN address
family.
i. Run quit
Return to the VPN instance view.

j. Run quit
Return to the system view.

l Configure a BGP-EVPN peer. If no RR is deployed, perform the following steps on each
PE. If an RR is deployed, perform the following steps on each PE and the RR.
a. Run bgp as-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

b. Run l2vpn-family evpn
The BGP-EVPN address family is enabled, and the BGP-EVPN address family
view is displayed.
c. Run peer { ipv4-address | group-name } enable
The capability to exchange EVPN routes with a peer or peer group is enabled.
d. Run peer { ipv4-address | group-name } advertise encap-type sd-wan
The device is enabled to advertise SD-WAN tunnel routes to the BGP-EVPN peer.
e. (Optional) Run peer ipv4-address group group-name
The BGP-EVPN peer is added to a peer group.
Adding BGP-EVPN peers to a peer group simplifies BGP network configuration

and management.
f. Run peer { group-name | ipv4-address } route-policy route-policy-name export
A route-policy is specified for the BGP-EVPN peer or peer group to advertise only
specified routes.
n EVPN routes can be advertised only after this command is run.

n Only an existing route-policy can be specified in this command.
g. (Optional) Run peer { ipv4-address | group-name } route-policy route-policy-name
import
A route-policy is specified for the BGP-EVPN peer or peer group to receive only
specified routes.
To precisely control EVPN routes, an import route-policy must also be configured.

An import route-policy filters routes that are received from other BGP-EVPN peers
or peer groups.
h. (Optional) Run undo policy vpn-target
The device is disabled from filtering received EVPN routes based on EVPN-VPN
targets.
----End
1.5.6 (Optional) Configuring an EVPN RR

Configuring an EVPN RR helps minimize the number of BGP-EVPN peer relationships on a
network and simplify configuration.
Context
After an EVPN RR is configured on a network, BGP-EVPN peer relationships are established
only between PEs and the RR. This helps minimize the number of BGP-EVPN peer
relationships on the network and simplify configuration. You can configure an existing device
on the network as an RR or add a device to function as a standalone RR.
Perform the following steps on the device that is to function as an RR.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Run l2vpn-family evpn
The BGP-EVPN address family is enabled, and the BGP-EVPN address family view is
displayed.
The capability to exchange EVPN routes with a peer or peer group is enabled.
Step 5 Run peer { ipv4-address | group-name } reflect-client
The local device is configured as an RR, and a peer or peer group is specified as the RR
client.
Step 6 (Optional) Run undo policy vpn-target
The device is disabled from filtering received EVPN routes based on EVPN-VPN targets.
----End
1.5.7 (Optional) Configuring a Primary Channel
Context
In an auto VPN scenario, configuring a primary channel can implement synchronization and
backup of information including the flow table, route selection result in SPR, and TNP
between two gateways.
Procedure
Step 2 Run ms-channel
The primary channel view is displayed.
Step 3 Run channel-ip-port local-ip ip-address local-data-port port peer-ip ip-address peer-data-
port port [ vpn-instance vpn-instance-name ]
A primary channel is configured.
----End
1.5.8 Verifying the Auto VPN Configuration

After configuring auto VPN functions, verify the configuration.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Prerequisites
Auto VPN functions have been configured.
Procedure
l Run the display site-tnp [ site-id ] command to check TNP information about a site.
l Run the display dtls peer-connection configure [ device-id device-id ] command to
check the DTLS connection configuration.
l Run the display dtls peer-connection status [ device-id device-id ] command to check
the running status of the DTLS connection.
l Run the display dtls server status command to check the DTLS server status.
l Run the display bgp [ tunnel-encap-ext | evpn ] peer [ [ ipv4-address ] verbose ]
command to check information about BGP peers in the Tunnel-encap-ext or EVPN
address family.
l Run the display bgp [ tunnel-encap-ext | evpn ] routing-table peer statistics command
to check statistics about advertised and received BGP routes in the Tunnel-encap-ext or
EVPN address family.
l Run the display bgp tunnel-encap-ext all routing-table command to check information
about auto VPN routes.
l Run the display bgp evpn all routing-table command to check information about
EVPN routes.
l Run the display evpn connection [ site-id ] command to check connection information
about a site.
l Run the display ms-channel command to check information about a primary channel.
----End
1.6 References
The following table lists references of this feature.
Table 1-1 References

Document Description Remarks
Protocol Compliance
RFC 5512 The BGP Encapsulation Partial compliance. The following

Subsequent Address Family functions are supported:
Identifier (SAFI) and the BGP l Color Extended Community
Tunnel Encapsulation Attribute.
l Tunnel Encapsulation Attribute

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 2 L2TP Configuration
2 L2TP Configuration
About This Chapter
L2TP connections are established between the LAC and LNS in several application scenarios
so that remote users can access resources in the headquarters using L2TP tunnels.
2.1 Overview of L2TP
This section describes the definition and functions of L2TP.
2.2 Understanding L2TP
This section describes the implementation of L2TP.
2.3 Application Scenarios for L2TP
This section describes the application scenarios for L2TP.
2.4 Licensing Requirements and Limitations for L2TP
This section describes the notes that need to be taken during L2TP configuration.
2.5 Default Settings for L2TP
This section provides the default settings for L2TP.
2.6 Configuring L2TP
This section describes the procedures for configuring L2TP functions.
2.7 Maintaining L2TP
This section describes how to disconnect an L2TP tunnel forcibly and monitor the running
status of L2TP.
2.8 Configuration Examples for L2TP
This section provides L2TP configuration examples.
2.9 Troubleshooting L2TP
This section describes common faults caused by incorrect L2TP configurations.
2.10 FAQ About L2TP
This section describes the FAQ about L2TP.
2.11 References for L2TP
This section lists references for L2TP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.1 Overview of L2TP

This section describes the definition and functions of L2TP.
Definition
The Layer 2 Tunneling Protocol (L2TP) is a Virtual Private Dial-up Network (VPDN)
tunneling protocol and expands applications of the Point-to-Point Protocol (PPP) to allow
remote dial-up users to access the network of an enterprise headquarters.
Based on PPP negotiation, L2TP sets up tunnels between branch users and enterprise
headquarters over the dial-up network, so that remote users can access the headquarters
network. The PPP over Ethernet (PPPoE) technology further expands the application scale of
L2TP and can establish L2TP tunnels between remote users and the headquarters over the
Ethernet and Internet.
Figure 2-1 shows a typical networking for constructing a VPDN network using L2TP.
Figure 2-1 Typical networking of L2TP
RADIUS Server RADIUS Server
Branch
Headquarters
NAS
PC (LAC)
PC
Dial-up
Internet
Network
LNS
PC PC
Remote users L2TP Tunnel
L2TP Tunnel
Traveling employees
(L2TP dial-up
software) VPDN
Purpose
As enterprises develop and services increase, many branches are set up in different locations,
and some staff often go on business trips. They require fast, secure, and reliable network
connections with the headquarters. On traditional dial-up networks, they use phone lines
leased by the Internet Service Provider (ISP) and apply for a dial string or IP addresses from
the ISP. This results in high costs. Besides, leased lines cannot provide services for remote
users especially the staff on business trips. VPDN, a dial-up network based VPN, is
introduced to make a better use of dial-up networks to ease access of remote users. VPDN
establishes a point-to-point virtual link between remote users and the headquarters gateway.
VPDN provides the following tunneling technologies:
l Point-to-point tunneling protocol (PPTP)
l Layer 2 forwarding (L2F)
l Layer 2 Tunneling Protocol (L2TP)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
L2TP combines advantages of PPTP and L2F and is widely accepted. L2TP enables an
individual or a small number of remote users to access the internal network of an enterprise
over the public network.
Benefits
L2TP encapsulates PPP packets to transmit private data of an enterprise through virtual links
established over the public network. This releases the enterprise from renting expensive
physical lines. The enterprise only needs to manage remote access users and users on the
private network, reducing maintenance cost due to simplified network architecture.
L2TP provides convenient, secure, and reliable access services for remote users, and brings
the following benefits:
l Flexible identity authentication and high security

– L2TP uses PPP security features such as PAP and CHAP to authenticate user
identity.
– L2TP allows control messages to be transmitted in cipher text and supports tunnel
authentication.
– L2TP works with Internet Protocol Security (IPSec) to ensure high security data
transmission, although it does not encrypt data to be transmitted.
l Multi-protocol transmission
L2TP transmits PPP frames, which can be used to encapsulate packets of multiple
network layer protocols. Therefore, L2TP can be used on IP networks, Frame Relay (FR)
permanent virtual circuit (PVCs), X.25 virtual circuits (VCs), or ATM VCs.
l Remote Authentication Dial-in User Service (RADIUS) authentication
L2TP provides two authentication methods to manage access users: local authentication
and RADIUS authentication using the user name and password sent by a dial-up user.
l Internal address allocation
The enterprise headquarters gateway enabled with L2TP dynamically allocates private
addresses to remote users.
l Reliability
L2TP supports LNS backup. When the primary LNS is unreachable, an LAC can
establish a new connection with a secondary LNS. This enhances reliability of VPN
services.
2.2 Understanding L2TP

This section describes the implementation of L2TP.
2.2.1 Concepts
Figure 2-2 shows a typical L2TP networking. Basic concepts related to L2TP are listed as
follows:
l VPDN
l PPP Terminal
l NAS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l LAC
l LNS
l Tunnel and Session
Figure 2-2 L2TP networking diagram
VPDN
Headquarters
NAS
(LAC)
PC
Branch
Dial-up Internet
Network
LNS
PC
PPP L2TP Tunnel
Client
L2TP Session
IP UDP L2TP PPP DATA
VPDN
VPDN, as a VPN that carries PPP packets, provides access services for enterprise users,
small-scale ISPs, and traveling employees.
The PPP terminal accesses a dial-up network and dials up to the NAS. After receiving a PPP
packet, the NAS implements L2TP encapsulation, and forwards the packet with an outer IP
header over the public network to the LNS. After receiving the packet, the LNS decapsulates
the packet to obtain the original PPP packet, implementing transparent transmission of the
PPP packet over the public network. In this manner, a VPDN connection is set up between the
PPP terminal and the LNS.
As the Ethernet becomes popular, PPP terminals can be used on the traditional dial-up
networks and can also connect to the LAC over the Ethernet using the PPPoE technology.
PPP Terminal
In L2TP applications, PPP terminals are the devices that initiate dial-up calls and perform
PPP encapsulation on data. For example, the PPP terminal can be a remote PC or a gateway in
the branch.
NAS
A network access server (NAS) is maintained by the ISP and connected to a dial-up network.
It is an access point geographically closest to the PPP terminal. The NAS works on a
traditional dial-up network to provide VPDN services for remote dial-up users to set up tunnel
connections with the enterprise headquarters network.
LAC
An L2TP access concentrator (LAC) provides PPP and L2TP processing capabilities on the
packet switched network. The LAC establishes an L2TP connection with the L2TP network

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
server (LNS) based on the user name or domain name in PPP packets so that PPP frames can
be transmitted to the LNS.
The LAC can be deployed on different devices on various networks.
l On a traditional dial-up network, the ISP usually deploys an LAC on the NAS.
Headquarters
NAS
(LAC) PC
Branch
Dial-up
Network
Internet
LNS
PC
PPP Client
L2TP Tunnel
l On an Ethernet in an enterprise branch, an LAC is deployed on the gateway for PPP

terminals and also functions as a PPPoE server.
Headquarters
LAC
(PPPoE Server) LNS
Branch PC
Internet
PPPoE PC
PPP Terminal
L2TP Tunnel
(PPPoE Client)
l A traveling employee uses a PC to access the Internet. The L2TP dial-up software
installed on the PC functions as the LAC.
LAC Headquarters
(L2TP dial-up LNS
software) PC
Internet
PC
L2TP Tunnel
An LAC can establish different L2TP tunnels to isolate data flows. That is, multiple VPDN
connections can be set up on the LAC.
An LAC transmits data between the LNS and PPP terminal. The LAC encapsulates data
received from the PPP terminal based on L2TP, sends data to the LNS, decapsulates the data
received from the LNS, and sends it to the PPP terminal.
LNS
PPP sessions are initiated by user devices and received by the LNS. After being authenticated
by the LNS, remote users successfully set up PPP sessions with the LNS and can access
resources in the enterprise headquarters. As the other endpoint of an L2TP tunnel, the LNS is
a peer device of the LAC, and sets up an L2TP tunnel with the LAC. Additionally, the LNS is
the logical termination point of a PPP session; therefore, the PPP client (user device) and the
LNS establish a virtual point-to-point link.
The LNS is located at the border between the headquarters' private network and the public
network, and is often used as the gateway of the enterprise headquarters. In addition, the LNS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
provides the network address translation (NAT) function to translate private IP addresses in
the enterprise headquarters network into public IP addresses.
Tunnel and Session

There are two types of connections during the L2TP tunnel establishment between the LAC
and LNS.
l Tunnel connection
Multiple L2TP tunnels can be set up between an LNS and an LAC. A tunnel consists of
one or more sessions.
l Session connection
An L2TP session can be set up only after a tunnel is created successfully, and represents
a PPP session over the tunnel.
2.2.2 L2TP Implementation

L2TP Architecture
The L2TP protocol defines two message types: control messages and data messages that are
transmitted between an LAC and an LNS. L2TP uses these two types of messages to expand
PPP applications.
l Control message
Control messages are used to establish, maintain, and tear down tunnels and sessions.
L2TP uses retransmission and periodical tunnel connectivity check mechanisms to
ensure reliable transmission of control messages. L2TP also supports flow control and
congestion control on control messages.
l Data message
Data messages are used to encapsulate PPP frames and are transmitted over tunnels. Data
messages are transmitted over an unreliable channel without flow control, congestion
control, and retransmission mechanisms.
Figure 2-3 illustrates the relationship between PPP packets, control messages, and data
messages.
Figure 2-3 L2TP architecture

PPP Frame
L2TP data message L2TP control message
L2TP data channel L2TP control channel
(unreliable) (reliable)
Packet transmission network
Control messages encapsulated with L2TP headers are transmitted over a reliable L2TP
control channel on an IP network.
Data messages carrying PPP frames are transmitted over an unreliable data channel. PPP
frames are encapsulated using L2TP and then transmitted over an IP network.
The well-known UDP port for L2TP is 1701, which is only used in initial stage of tunnel
setup. The L2TP tunnel initiator randomly selects an idle port to forward packets to port 1701

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
of the receiver. After receiving the packets, the receiver randomly selects an idle port to
forward packets to the port selected by the initiator. Both ends use the selected ports to
communicate until the tunnel is disconnected.
L2TP Packet Structure

Figure 2-4 shows the format of an L2TP packet, which is generated by encapsulating a PPP
frame initiated by a remote dial-up user.
Figure 2-4 Format of an L2TP packet

20 bytes 8 bytes 6 bytes 4 bytes 20 bytes
New IP PPP Original IP

UDP Header L2TP Header Data
Header Header Header
After L2TP encapsulation, an L2TP packet has 38 bytes more than the original packet. (If an
L2TP packet carries sequence number information, it has 42 bytes more than the original
packet.) If the length of the encapsulated packets exceeds the MTU of the outbound interface,
the device must be able to fragment the IP packets because L2TP does not support packet
fragmentation. The receiver end reassembles fragmented packets into L2TP packets.
L2TP Packet Encapsulation

As an expansion to PPP, L2TP allows PPP packets to be transmitted through tunnels over the
public network.
If only PPP is deployed on the network, dial-up calls initiated by PPP terminals can only
reach the edge node NAS of the dial-up network. The NAS is the termination point of PPP
sessions. When L2TP is deployed, PPP packets can be transparently transmitted over the
public network and reach the LNS in the enterprise headquarters. In this case, the LNS is the
termination point of PPP sessions.
Figure 2-5 L2TP packet encapsulation

PPP Headquarters
LAC
Terminal LNS PC
(NAS)
Dial-up
Branch Network Internet
PPP L2TP
IP Packet
IP IP L2TP IP IP
PPP IP UDP PPP Packet
Packet Packet (AVP) Packet
+ + -
L2TP L2TP
PPP IP UDP IP UDP
(AVP) (AVP)
-
=
IP L2TP IP
PPP IP UDP PPP PPP
Packet (AVP) Packet
=
IP
Packet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 2-5, packets are sent from a branch to the headquarters following the
process as follows:
1. PPP terminal: encapsulates IP packets with PPP at the link layer and sends the packets.
2. LAC: receives PPP packets and determines whether access users are VPDN users based
on user names or domain names carried in the packets.
– If they are VPDN users, the LAC adds L2TP headers to PPP packets and then adds
UDP and IP headers to the packets based on the public network address of the LNS.
The outer layer of the encapsulated packets is the IP address of the public network
address. The packets are forwarded over the public network to the LNS.
– If they are non-VPDN users, the LAC decapsulates PPP packets. In this case, the
LAC is the termination point of PPP sessions.
3. LNS: receives L2TP packets and removes IP, L2TP, and PPP headers to obtain IP
packets sent by PPP terminals. The LNS searches the routing table for the destination
host in the headquarters based on the destination address contained in the packets.
When the destination host sends response packets to the branch device, the LNS searches the
routing table for the outbound interface and encapsulated the packet with L2TP in a similar
process.
L2TP Packet Transmission

L2TP tunnel connections and session connections must be set up before PPP packets can be
transmitted. L2TP connections are initiated for the first time according to the following
procedure:
1. Setting an L2TP tunnel connection

After receiving a PPP negotiation request from a remote user, the LAC initiates an L2TP
connection request to the LNS. The LAC and LNS exchange control messages to
negotiate the tunnel ID and tunnel authentication information. After negotiation
succeeds, an L2TP tunnel is set up and it is identified by a tunnel ID.
2. Setting an L2TP session connection
After an L2TP tunnel is set up, the LAC and LNS exchange control messages to
negotiate the session ID. The L2TP session carries LCP negotiation information and
authentication information. After authenticating such information, the LNS informs the
LAC that a session is set up. An L2TP session connection is identified by a session ID.
3. Transmitting PPP packets
After an L2TP session connection is set up successfully, the PPP terminal sends data
packets to the LAC. The LAC encapsulates the packets based on the tunnel ID and
session ID and sends the packets to the LNS. The LNS decapsulates the packets and
sends the packets to the destination host by searching for the host address in the routing
table.
2.2.3 Working Procedure

VPDN connections are set up between the remote user and LNS. ISPs deploy the NAS that is
geographically closest to the remote user as the LAC. L2TP tunnel connections are set up
between the LAC and LNS.
1. Remote users dial up on a PSTN or an ISDN to initiate PPP connections to a local NAS
deployed by an ISP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. The NAS accepts calls from remote users and performs PPP negotiation.
3. As the LAC, the NAS determines whether remote users are VPDN users based on user
names or domain names. If remote users are VPDN users, the L2TP module encapsulates
PPP packets from them and sends the packets through the L2TP tunnel to the LNS. If
remote users are not VPDN users, PPP packets from them are processed and forwarded
normally.
4. Upon receiving call connection requests sent through the L2TP tunnel, the LNS
authenticates remote users and assigns and sends IP addresses to remote users.
5. Remote users obtain IP addresses and send packets to hosts in the headquarters to
communicate.
6. The LNS receives packets transmitted through the tunnel and forwards the packets to
destination hosts according to the routing table.
After L2TP encapsulation, remote users set up point-to-point connections to the LNS, and the
LAC and Internet are transparent to users. The LAC and LNS use remote authentication.
Figure 2-6 shows the L2TP call setup procedure in details.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-6 L2TP call setup procedure
RADIUS Server DNS Server RADIUS Server
(10) (13)Access
request
(6) resolving (11) (14)Access
LNS domain accept
(4) Access (5) Access name
(10) (11)
request accept (13) (14)
Headquarters
Remote user
PC
Dial-up
Internet
Headquarters
Network
LAC LNS PC
(NAS)
(1) Call setup
(2) PPP LCP setup

(3) PAP/CHAP
authentication
(7) Tunnel establish
(8) Session establish
(9) PPP negotiatory

(12) (Optional) CHAP
reauthentication
(15) Assign IP address
(16) Communication
1. The PC of a remote user initiates a request for a call connection to the LAC.
2. The PC and the LAC perform PPP LCP negotiation.
3. The LAC authenticates the PC user using the Challenge Handshake Authentication
Protocol (CHAP).
4. The LAC sends authentication information including the user name and password to the
RADIUS server for authentication.
5. After authenticating the user, the RADIUS server sends the authentication result to the
user.
6. If the LNS domain name is specified on the LAC, the LAC checks whether the LNS
domain name is parsed. If the LNS domain name is not parsed, the LAC requests the
corresponding IP address based on the domain name from the DNS server. If an IP
address is parsed from the domain name, the tunnel setup process is triggered. If no IP
address is parsed from the domain name, the user cannot go online.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7. An L2TP tunnel connection is set up between the LAC and LNS.

8. An L2TP session connection is set up between the LAC and LNS.
9. The LNS processes PPP negotiation information contained in the session connection
request.
10. The LNS sends an access request to its RADIUS server for authentication.
11. The RADIUS server sends a response packet after the authentication succeeds. If the
Frame-IP and Frame-Route attributes or address pool name is specified on the RADIUS
server, the response packet carries the Frame-IP and Frame-Route attributes or the
specified address pool name.
12. (Optional) The LNS performs secondary CHAP authentication on the remote user.
13. The LNS sends secondary authentication information to its RADIUS server for
authentication.
14. The RADIUS server sends a response packet after the authentication succeeds.
15. The LNS saves the Frame-IP and Frame-Route attributes or the specified address pool
name carried in the response packet. An L2TP connection is set up and the LNS assigns
IP addresses to remote users.
16. The remote user can communicate with devices in the headquarters and the LNS
functions as a gateway.
NOTE
If you run step 12, step 13 and 14 are mandatory.
2.3 Application Scenarios for L2TP

This section describes the application scenarios for L2TP.
2.3.1 Client-Initiated L2TP Connection

Traveling employees need to communicate with employees in the headquarters and access the
headquarters gateway through the Internet to use internal resources. However, the
headquarters gateway cannot identify and manage access users. To solve this problem,
configure the headquarters gateway as the LNS to establish a virtual point-to-point connection
between the traveling employees and the headquarters gateway when the employees use the
L2TP dial-up software on the PC to initiate L2TP connections. The LNS can authenticate
access users and assign private network addresses. The LNS can use ACLs to manage users'
access rights.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-7 Client-initiated L2TP connection
Traveling
employees Headquarters
(L2TP dial-up
software) LNS
PC
Internet
PC
L2TP Tunnel
2.3.2 LAC-Initiated L2TP Connection upon Receiving a Call

Connection Request
An enterprise has a branch located in another city, and the branch network is a traditional dial-
up network. Branch users need to establish VPDN connections with users in the headquarters.
Therefore, the branch users apply for the L2TP service from the ISP. The ISP configures the
NAS as the LAC to send call connection requests to the LNS through the Internet. The
gateway in the headquarters is configured as the LNS to establish VPDN connections between
the branch and the headquarters.
Figure 2-8 LAC-initiated L2TP connection upon receiving a call connection request
Headquarters
LAC
(NAS) PC
Branch
Dial-up
Network
Internet
LNS
PC
PPP
L2TP Tunnel
Terminal
2.3.3 LAC-Initiated L2TP Connection upon Receiving a Call from

a PPPoE User
An enterprise has a branch located in another city, and its branch network uses the Ethernet
and has a gateway deployed, so branch hosts can access the Internet. Hosts in the headquarters
need to communicate with hosts in the branch. You can use L2TP to configure the headquarter
gateway as an LNS that manages access requests from branch hosts in a centralized manner.
Dial-up data of a branch host cannot be transmitted directly over the Ethernet network. When
PPPoE dial-up software is deployed on the branch host, the host functions as the PPPoE
client, and the branch gateway functions as the PPPoE server and the LAC. Dial-up data can
then be transmitted to the headquarters.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-9 LAC-initiated L2TP connection upon receiving a call from a PPPoE user
Headquarters
LAC
(PPPoE Server) LNS
Branch PC
Internet
PPPoE PC
PPP Terminal
L2TP Tunnel
(PPPoE Client)
2.3.4 L2TP Client-Initiated L2TP Connection

and has a gateway deployed, so branch hosts can access the Internet. A VPDN connection
must be established between the headquarters gateway and the branch so that the headquarters
can provide access services for users. Any user from the branch is allowed to access the
headquarters gateway which only authenticates the branch gateway. Configure the
headquarters gateway as the LNS and the branch gateway as the L2TP Client. Configure
virtual users on the branch gateway to initiate L2TP connections to the headquarters. In L2TP
Client-Initiated mode, virtual point-to-point connections are established between the L2TP
Client and LNS. After receiving IP packets from branch users, the L2TP Client forwards the
packets through a virtual dial-up interface and the L2TP tunnel to the LNS, which forwards
the packets to the destination host.
Figure 2-10 L2TP Client-Initiated L2TP connection

Headquarters
L2TP Client LNS
Branch PC
Internet
PC
PC L2TP Tunnel
2.3.5 LAC-Initiated L2TP Connection When Users from Multiple

Domains Are Connected
Different enterprise branches are allowed to access resources in different departments of the
enterprise headquarters. The headquarters provides access services for branch staff. The
headquarters establishes VPDN connections with branches using L2TP. The branch gateway
determines users based on domain names when there are many users, which facilitates VPDN
user management. Each branch uses a separate L2TP tunnel and obtains private addresses on
different segments. Because source and destination addresses are allocated by the
headquarters, you can configure an ACL to allow the headquarters to manage access rights of
branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-11 LAC-initiated L2TP connection when users from multiple domains are connected
Headquarters-
Branch A Department A
PC
PP
PC
Po
E
user@a.com LAC LNS
Internet
Headquarters-
PC Department B
E
Po
Branch B L2TP Tunnel 1
PC
PP
L2TP Tunnel 2
user@b.com
2.3.6 Authenticating VPDN Users Using the RADIUS Server

and has a gateway deployed, so branch hosts can access the Internet. A VPDN connection
must be established between the headquarters gateway and the branch so that the headquarters
can provide access services for users. Configure the branch gateway as the LAC and the
headquarters gateway as the LNS to set up a VPDN connection. In addition, the branch
gateway is configured as a PPPoE server to exchange PPP packets with the PPP client (branch
user) over Ethernet. The LAC and LNS can authenticate branch users. However, when there
are many users, a RADIUS server can be deployed to authenticate users remotely. The
RADIUS server on the LAC side must support L2TP authentication. The RADIUS server
determines whether remote users are VPDN users and sends the authentication result to the
LAC.
Figure 2-12 Authenticating VPDN users using the RADIUS server

LAC Headquarters
(PPPoE Server) LNS
Branch PC
Internet
PPPoE PC
PPP terminal
(PPPoE Client) L2TP Tunnel

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.3.7 Allocating the Frame-IP and Frame-Route Attributes and the

Specified Address Pool Name to L2TP Users by the RADIUS
Server
To facilitate management and reduce maintenance costs on user information, many enterprises
use the RADIUS server to uniformly manage user information. By specifying the Frame-IP
and Frame-Route attributes or the address pool name on the RADIUS server, the LNS
allocates planned IP addresses to each user after the user goes online.
Figure 2-13 Allocating the Frame-IP and Frame-Route attributes and the specified address
pool name to L2TP users by the RADIUS server
RADIUS
Server
Headquarters
LAC
L2TP user (NAS) LNS
Dial-up
Internet
Network
PC
L2TP Tunnel
2.3.8 Setting Up a Secure Tunnel Connection Using L2TP over

IPSec Encapsulation
and has a gateway deployed, so branch hosts can access the Internet. L2TP is enabled on the
headquarters and branch devices to set up VPDN connections so that branch users can access
resources in the headquarters. When the enterprise requires high security, L2TP is not enough
to provide protection on packet transmission. In this case, use L2TP together with IPSec to
prevent data from being intercepted or attacked. Data packets are encapsulated using IPSec
and L2TP on the LAC before being forwarded to the headquarters. Configure an IPSec policy
on the headquarters gateway to decapsulate the packets. L2TP over IPSec encapsulation
protects the original data packets and provides protection on access users as required.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-14 Setting up a secure tunnel connection using L2TP over IPSec encapsulation
LAC Headquarters
(PPPoE Server) LNS
Branch PC
Internet
PPPoE
PPP terminal PC
(PPPoE Client) IPSec L2TP
Related Topics
Example for Configuring L2TP over IPSec for Remote Dial-Up Users to Connect to the
Headquarters
2.3.9 Setting Up a Secure Tunnel Connection Using IPSec over

L2TP Encapsulation
Traveling employees need to communicate with staff in the headquarters. Therefore, L2TP is
implemented to set up VPDN connections between them and the LNS in the headquarters
authenticates access users. When traveling employees need to transmit confidential
information to the headquarters, L2TP is not enough to provide protection on packet
transmission. In this case, use L2TP together with IPSec to protect data transmission. Run the
dial-up software on the traveling employee's PC. Data packets are encapsulated using L2TP
and then IPSec on the PC before being forwarded to the headquarters. Configure an IPSec
policy on the headquarters gateway to decapsulate the packets. IPSec over L2TP
encapsulation protects all packets whose source and destination addresses are addresses of the
LAC and LNS.
Figure 2-15 Setting up a secure tunnel connection using IPSec over L2TP encapsulation
Traveling
employees Headquarters
(L2TP+IPSec
Dial-up software) LNS
PC
Internet
PC
L2TP IPSec
Related Topics
Example for Configuring L2TP over IPSec for Remote Dial-Up Users to Connect to the
Headquarters

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.4 Licensing Requirements and Limitations for L2TP

This section describes the notes that need to be taken during L2TP configuration.

None
L2TP is a basic feature of the device and is not under license control.
Feature Limitations
AR161EW-M1, AR169EGW-L, AR161EW and AR169EW do not support LAC and LNS.
But support L2TP Client.
2.5 Default Settings for L2TP

This section provides the default settings for L2TP.
Table 2-1 Default settings for L2TP

Parameter Default Setting
l2tp enable Disabled
tunnel authentication Enabled
tunnel password Not configured
tunnel name Device name
tunnel avp-hidden Disabled
mandatory-chap Disabled
mandatory-lcp Disabled
tunnel timer hello 60s
2.6 Configuring L2TP

This section describes the procedures for configuring L2TP functions.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.6.1 Configuring the LAC to Initiate Call-Triggered L2TP

Connections
The LAC functions as a PPPoE server to authenticate call connecting requests from remote
users, and initiates L2TP connections to the LNS based on the user information contained in
the request packets.
Context
An enterprise has some branches located in other cities, and its branches use the Ethernet and
have gateways deployed, so that branch hosts can access the Internet. Hosts at the
headquarters need to communicate with hosts at branches. You can use L2TP to configure the
headquarter gateway as an LNS that uniformly manages access requests from branch hosts.
Dial-up data of a branch host cannot be transmitted directly over the Ethernet network.
However, when PPPoE dial-up software is deployed on the branch host, the host functions as
the PPPoE client, and the branch gateway functions as the PPPoE server and the LAC. Dial-
up data can then be transmitted to the headquarters.
Figure 2-16 Networking diagram for the LAC to initiate an L2TP connection request on
receiving a dial-up call
Enterprise Enterprise
branch LAC headquarters
(PPPoE Server) LNS
PC
Internet
PPPoE PC
PPP Terminal
L2TP Tunnel
(PPPoE Client)
Prerequisite
A reachable route has been configured between the LNS and the LAC.
Configuration Process
Table 2-2 shows the configuration process on the LAC. Table 2-3 shows the configuration
process on the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 2-2 Configuration process on the LAC

Configuratio
Procedure Description
n
Configure
local Store user information, including the user name,
Configure authenticatio password, and service type, on the local device.
local or remote n.
AAA
Configure Configure RADIUS server parameters to enable the
authentication.
remote RADIUS server to store user information, including the
authenticatio user name, password, and service type, and authenticate
n. access users.
Enable
Enable L2TP globally.
L2TP.
Set the PPP negotiation mode to PAP or CHAP on the

virtual tunnel interface.
Configure
Assign an IP address for the VT interface to make the
PPP
Configure the configuration take effect.
negotiation.
LAC to initiate Configure a PPPoE server on the physical interface at the
an L2TP user side.
connection.
Configure L2TP parameters, including the LAC tunnel
name and password, LNS address, and VPDN user name.
Create an You can also configure the Attribute Value Pair (AVP)
L2TP group. data to be transmitted in cipher text, primary and
secondary LNSs, and an interval for sending Hello
packets.
Table 2-3 Configuration process on the LNS

Configuratio
n
Store user information, including the user name,

Configure password, and service type, on the local device.
local
authenticatio You can also enable LCP renegotiation or mandatory
n. CHAP authentication to implement second authentication
Configure on remote users.
local or remote
Configure RADIUS server parameters to enable the
AAA
RADIUS server to store user information, including the
authentication. Configure user name, password, and service type, and authenticate
remote access users.
authenticatio
n. You can also enable LCP renegotiation or mandatory
CHAP authentication to implement second authentication
on remote users.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuratio
n
Enable
Enable L2TP globally.
L2TP.
Assign an IP address dynamically for the remote user

Configure an after the user is authenticated.
IP address
pool. This step is not required when a static IP address is
assigned to the remote user.
Set PPP negotiation mode to PAP or CHAP on the VT

Configure the interface.
LNS to
respond to the Configure an IP address and use this address as the
Configure private network gateway address of the L2TP tunnel.
L2TP PPP
connection negotiation. Import an IP address pool to dynamically allocate IP
request. addresses for remote users.
If mandatory CHAP authentication is configured, the
PPP authentication mode must be CHAP.
Configure L2TP parameters, including the LNS tunnel

name and password, number of the VT, and LAC tunnel
Create an name.
L2TP group.
You can also configure the AVP data to be transmitted in
cipher text, and an interval for sending Hello packets.
2.6.1.1 Configuring AAA Authentication and Accounting
Context
The AAA provides authentication, authorization, and accounting security functions to manage
access users and ensure secure connections. You can configure local or remote authentication
on the LAC and LNS to authenticate remote users.
When users can access the Internet through only the LNS, you can configure the accounting
function on the LNS to manage the online duration and traffic of the users.
The LAC checks the user name or domain name of the users to determine whether to establish
a tunnel to the LNS. The user name and domain name are described as follows:
l User name: applies to the scenario where there are few users and each user is managed
independently. In this scenario, each user exclusively occupies an L2TP tunnel.
If remote users are authenticated based on user names, the device uses the default
domain named default, the authentication scheme named default. The authentication
scheme named default uses the default authentication mode local.
l Domain name: applies to the scenario where there are many access users and the users
are managed uniformly. In this scenario, users with the same domain name occupy an
L2TP tunnel.
If remote users are authenticated based on the domain name, you need to configure a
domain and an authentication scheme for the domain.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The LAC and LNS must have the same AAA authentication configurations.
For details about how to configure AAA authentication, see AAA Configuration in the Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series
Enterprise Routers Configuration Guide.
NOTE
If the LAC is trusted by the LNS, you can run the authentication-mode none command in the
authentication scheme view of the LNS to set the authentication mode to non-authentication. If the
command is configured, the LNS does not perform second authentication on remote users.
Procedure
l Configuring local authentication
a. Run system-view
Enter the system view.
b. Run aaa
Enter the AAA view.
c. Run authentication-scheme authentication-scheme-name
Create an authentication scheme, and enter the authentication scheme view.
By default, the device has an authentication scheme named default, and its
authentication mode is local.
d. Run authentication-mode local
Set the authentication mode to local.
By default, local authentication is used.
e. Run quit
Return to the AAA view.
f. Run domain domain-name
Create a domain, and enter the domain view.
By default, the device has a domain named default, and its authentication mode is
local.
g. Run authentication-scheme authentication-scheme-name
Specify an authentication scheme for the domain.
h. Run quit
i. Run local-user user-name password cipher password
Configure a user name and password for the local user, and store the user name and
password on the device as the VPDN user information. The information is used to
verify remote users.
The password is stored in cipher text mode.
NOTE
To fully ensure the safety of the equipment, the users needs change the password on a regular
basis.
j. Run local-user user-name service-type ppp
Configure a service type for the local user. The service type must be set to ppp
because L2TP uses PPP negotiation.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
k. Run return
Return to the user view.
l Configuring remote authentication and accounting
a. Run system-view
b. Run radius-server template template-name
Create a RADIUS server template, and enter the RADIUS server template view.
You can configure RADIUS server parameters in the RADIUS server template
view.
c. Run radius-server authentication ip-address port
Configure an IP address and a port number for the RADIUS server.
d. Run radius-server accounting ip-address port
Configure a RADIUS accounting server.
By default, no RADIUS accounting server is configured.
e. Run radius-server shared-key cipher key-string
Configure a shared key for connecting to the RADIUS server.
By default, the shared key is huawei in cipher text.
f. Run quit
g. Run aaa
Enter the AAA view.
h. Run authentication-scheme authentication-scheme-name
i. Run authentication-mode radius
Set the authentication mode to radius.
j. (Optional)Run accounting-scheme accounting-scheme-name
Create an accounting scheme and enter the accounting scheme view.
A default accounting scheme named default is available on the device. The default
scheme can only be modified but cannot be deleted.
k. (Optional)Run accounting-mode radius
Set the accounting mode to RADIUS.
By default, non-accounting is used.
l. (Optional)Run accounting start-fail { online | offline }
Configure a policy for accounting-start failures.
By default, users cannot go online if accounting-start fails.
m. (Optional)Run accounting realtime interval
Enable real-time accounting and set a real-time accounting interval.
n. (Optional)Run accounting interim-fail [ max-times times ] { online | offline }

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Specify the maximum number of real-time accounting requests and a policy for
real-time accounting failures.
o. Run quit
p. Run domain domain-name
local.
q. Run authentication-scheme authentication-scheme-name
r. Run radius-server template-name
Specify RADIUS server template for users in the domain.
s. (Optional)Run accounting-scheme accounting-scheme-name
Apply the accounting scheme to the domain.
By default, the accounting scheme default is applied to a domain. In this
accounting scheme, non-accounting is used and the real-time accounting function is
disabled.
t. (Optional)Run statistic enable
If traffic-based accounting is used, enable traffic statistics collection in the domain.
By default, traffic statistics collection is disabled for a domain.
u. Run return
----End
2.6.1.2 Configuring the LAC to Accept Dial-Up Calls and Initiate L2TP
Connections
Context
Configure the LAC to accept dial-up calls for users and implement PPP negotiation with these
users. Configure L2TP parameters to enable the LAC to initiate L2TP connections to the LNS
based on the user name or domain name.
When configuring the LAC, note the following:
l When the user initiates a call connection request, the authentication mode must be the
same as that configured for the virtual interface template on the LAC.
l Assign an IP address for the interface that connects the LAC to the user, to make the IP
protocol on the interface take effect.
l Tunnel authentication is enabled by default, and no authentication password is
configured.
– If tunnel authentication is used, configure the same authentication password for the
LAC and LNS.
– If tunnel authentication is not used, disable tunnel authentication on the LAC and
LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Configure the LAC.
a. Run system-view
b. Run l2tp enable
L2TP is enabled globally.
c. Run interface virtual-template vt-number
A virtual interface template is created, and the virtual template view is displayed.
You can configure PPP negotiation parameters for the interface that functions as the
PPPoE service interface.
NOTE
PPPoE and L2TP services cannot be configured on the same VT interface simultaneously.
d. Run ppp authentication-mode { pap | chap }
The PPP authentication mode is set to pap or chap.
The LAC and LNS must have the same authentication mode.
NOTE
In PAP authentication, passwords are transmitted in plain text on the network, bringing potential
security risks. CHAP authentication is recommended.
e. Run mtu size
The MTU of the interface is set.
When the device interconnects with a non-Huawei device, set an MTU value on the
virtual template interface to prevent an interconnection failure, for example, failure
of the non-Huawei device to reassemble data packets after they are fragmented on a
physical outbound interface of the Huawei device. The MTU value must be less
than or equal to the encapsulation header length of L2TP packets (the encapsulation
header length of an L2TP packet is 38 bytes but is 42 bytes when it carries sequence
number information) subtracted from the MTU value on the physical outbound
interface (1500 bytes by default). For example, when the MTU value on the
physical outbound interface is 1500 bytes and the encapsulation header length of an
L2TP packet is 42 bytes, the value of size in this step must be less than or equal to
1458.
If a physical interface performs packet fragmentation again after the packet is
fragmented on the corresponding VT interface, device performance degrades. To
prevent this case, you are advised to set the MTU value of the VT interface to the
range of 1400 to 1450.
f. Run quit
g. Run interface interface-type interface-number
The view of the physical interface connected to remote users is displayed.
h. Run pppoe-server bind virtual-template vt-number
The interface is configured to function as a PPPoE service interface, and bound to a
virtual interface template.
i. Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
j. Run l2tp-group group-number

An L2TP group is created, and the L2TP group view is displayed.
You can configure L2TP connection parameters to enable the LAC to initiate L2TP
connections to the LNS if the user information matches the configuration.
k. Run tunnel password { simple | cipher } password
The password of the L2TP tunnel is configured. The password must be the same as
that of the tunnel on the LNS.
Tunnel authentication is enabled by default, and no authentication password is
configured.
It is recommended that you enable the tunnel authentication function. If the tunnel
authentication function is not required, run the undo tunnel authentication
command to disable the function.
If simple is selected, the password is saved in the configuration file in plain text.
This brings security risks. It is recommended that you select cipher to save the
password in cipher text.
l. Run tunnel name tunnel-name

A tunnel name is configured to enable the LNS to accept L2TP connections based
on the LAC tunnel name.
By default, the device name is used as the tunnel name when no tunnel name is
specified.
m. Run either of the following commands to configure a public network address or
domain name for the LNS, which specifies the destination address of control
messages.
n start l2tp ip ip-address &<1-4> { domain domain-name | fullusername user-
name | interface interface-type interface-number | vpn-instance vpn-instance-
name fullusername user-name }
n start l2tp host hostname { domain domain-name | fullusername user-name }
The keywords define VPDN users.
n fullusername: specifies a name for VPDN users. L2TP connections can be
established for remote users with the same user name.
n domain: specifies a domain name for VPDN users. L2TP connections can be
established for remote users with the same domain name.
n vpn-instance: specifies the VPN instance to which the IP address of the L2TP
connections of a specific L2TP group belongs.
n. Run return
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.6.1.3 Configuring the LNS to Respond to the L2TP Connection Request
Context
Configure L2TP parameters to enable the LNS to respond to L2TP connection requests to the
LAC based on the LAC tunnel name.
When configuring the LNS, note the following:

l When you configure PPP negotiation parameters on the virtual interface template, the
authentication mode must be the same as that configured on the LAC.
l If the L2TP group number is not 1, you must specify an LAC tunnel name.
configured.
LAC and LNS.
LNS.
l If RADIUS authentication is used and Frame-IP and Frame-Route attributes are
specified by the RADIUS server for users, the LNS delivers the Frame-IP and Frame-
Route attributes to users and does not allocate IP addresses from the local address pool.
The Frame-IP must be included in the local address pool.
l If the VPN instance attributes are configured for users on the RADIUS server when
RADIUS authentication is used, you cannot bind the VPN instance to the VT interface of
the LNS.
NOTE
The LNS does not know users' real MAC addresses because user terminals use virtual MAC addresses
allocated by the device. These virtual MAC addresses change randomly and cannot be bound with static IP
addresses.
Procedure
l Configuring the LNS
a. Run system-view
b. Run l2tp enable
c. Run ip pool ip-pool-name
A global IP address pool is created, and the global IP address pool view is
displayed. The global IP address pool is used to allocate IP addresses to remote
users.
This step is not required if you have manually configured a static IP address for the
user.
NOTE
L2TP can only allocate IP addresses of the address pool configured using the ip pool command
but not attributes of other address pools to users.
If you want to allocate the DNS server address to users, add the service-scheme command to the
AAA configuration.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
d. Run network ip-address [ mask { mask | mask-length } ]

A network segment is configured to allocate IP addresses dynamically from the
largest to the smallest.
e. Run gateway-list ip-address &<1-8>
A gateway address is configured, and allocated to the remote user.
f. Run quit
g. Run interface virtual-template vt-number
You can configure PPP negotiation parameters on the interface that functions as the
private network gateway interface to accept L2TP connections of remote users.
NOTE
h. Run ip address ip-address { mask | mask-length }
An IP address is configured for the gateway in the headquarters.
i. Run remote address { ip-address | pool pool-name }
An IP address pool is configured to allocate IP addresses dynamically for remote
users.
This step is not required if you have configured static IP addresses for remote users.
This step is not required if RADIUS authentication is used and an address pool
name or Frame-IP attribute is specified by the RADIUS server. The LNS allocates
IP addresses for remote users from the address pool specified by the RADIUS
server.
When L2TP supports multiple address pools, omit this step if the service-scheme
command has been run to specify an address pool. The LNS allocates IP addresses
to remote users from the address pool specified by the service-scheme command.
NOTE
If multiple users dial up using the same static IP address, users can go online but their service
packets may fail to be forwarded if forcible address allocation is not configured on the LNS.
Customers need to correctly plan static IP addresses. If the device must identify users and allow
only one user terminal to connect to it, the planned address for the user terminal must be in the
address pool and the ppp ipcp remote-address forced command must be configured.
j. Run ppp authentication-mode { pap | chap }
The PPP authentication mode is set to pap or chap to authenticate remote users.
NOTE
k. Run mtu size

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1458.
l. Run quit
m. Run l2tp-group group-number
You can configure L2TP connection parameters to accept connections initiated by
the LAC.
When the L2TP group number is 1, the LNS accepts all the L2TP connections.
n. Run tunnel password { simple | cipher } password
that of the tunnel on the LAC.
configured.
If simple is selected, the password is saved in the configuration file in plain text. In
this case, users at a lower level can easily obtain the password by viewing the
configuration file. This brings security risks. Therefore, it is recommended that you
select cipher to save the password in cipher text.
o. Run tunnel name tunnel-name

A tunnel name is configured. The tunnel name is used for PPP negotiation during
tunnel establishment.
specified.
p. Run allow l2tp virtual-template virtual-template-number [ remote remote-name
[ vpn-instance vpn-instance-name ] ]
The L2TP group is configured as the LNS to respond to L2TP connection requests
initiated by the LAC.
You must specify a virtual interface template and an LAC tunnel name.
When the L2TP group number is 1, the LNS accepts any L2TP connection requests
from the LAC. You can choose not to specify the remote tunnel name.
q. Run return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

----End
2.6.2 Configuring L2TP Client-Initiated L2TP Connections

Access users do not need to dial up and they can access the L2TP Client in any means. The
L2TP Client uses a virtual dial-up interface to initiate PPP sessions and L2TP connection
requests to the LNS.
Context
An enterprise has some branches located in other cities, and its branches use the Ethernet and
have gateways deployed, so that branch hosts can access the Internet.
A VPDN connection must be established between the headquarters gateway and branches to
enable the headquarters to provide access services for the users. Any user from branches is
allowed to access the headquarters gateway which only authenticates the gateways in
branches. Configure the headquarters gateway as the LNS and the branch gateway as the
L2TP Client. Configure virtual users on the branch gateway which dial up to initiate L2TP
connections to the headquarters. In L2TP Client-Initiated mode, virtual point-to-point
connections are established between the L2TP Client and LNS. After receiving IP packets
from branch users, the L2TP Client forwards the packets through the virtual dial-up interface
and the packets pass through L2TP tunnels to the LNS, which forwards the packets to the
destination host.
Figure 2-17 Networking diagram for establishing L2TP Client-Initiated L2TP connections
branch headquarters
L2TP Client LNS

PC
Internet
PC
PPP terminal
L2TP Tunnel
Prerequisites
A reachable route has been configured between the LNS and the L2TP Client.
A LAN connection is established between branch users and the L2TP Client which functions
as the gateway.
Table 2-4 shows the configuration process on the L2TP Client. Table 2-5 shows the
configuration process on the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 2-4 Configuration process on the L2TP Client
Configuration Procedure Description
Enable L2TP. Enable L2TP globally.
Configure parameters for a virtual interface template

Configure PPP and use this template as a virtual dial-up interface.
negotiation. Assign an IP address for the VT interface to make the
Configure the
configuration take effect.
L2TP Client to
initiate an L2TP Configure L2TP parameters, including the LAC tunnel
connection. name and password, LNS address, and VPDN user
Create an name.
L2TP group. You can also configure the AVP data to be transmitted
in cipher text, primary and secondary LNSs, and an
interval for sending Hello packets.
Table 2-5 Configuration process on the LNS
Store user information, including the user name,

Configure password, and service type, on the local device.
local You can also enable LCP renegotiation or mandatory
authentication. CHAP authentication to implement second
authentication on remote users.
Configure local
or remote AAA Configure RADIUS server parameters to enable the
authentication. RADIUS server to store user information, including
Configure the user name, password, and service type, and
remote authenticate access users.
authentication. You can also enable LCP renegotiation or mandatory
CHAP authentication to implement second
Enable L2TP. Enable L2TP globally.
Assign an IP address dynamically for the remote user

Configure an after the user is authenticated.
IP address
pool. This step is not required when a static IP address is
Configure the assigned to the remote user.
LNS to respond Set PPP negotiation mode to PAP or CHAP on the VT
to the L2TP interface.
connection
request. Configure an IP address and use this address as the
Configure PPP private network gateway address of the L2TP tunnel.
negotiation. Import an IP address pool to dynamically allocate IP
addresses for remote users.
If mandatory CHAP authentication is configured, the
PPP authentication mode must be CHAP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure L2TP parameters, including the LNS tunnel

name and password, number of the VT, and L2TP
Create an Client tunnel name.
L2TP group. You can also configure the AVP data to be transmitted
in cipher text, and an interval for sending Hello
packets.
2.6.2.1 Configuring AAA Authentication and Accounting
Context
The AAA authentication provides authentication, authorization, and accounting security
functions to manage remote access users and ensure secure connections. In L2TP Client
initiated mode, you can configure local or remote authentication on the LNS to authenticate
the L2TP Client.
After users are authenticated by the LNS, they can access the Internet. If you want to charge
the users on their accessed network resources, you can configure the AAA accounting
function on the LNS.
For details about how to configure AAA authentication, see AAA Configuration in the Huawei
Enterprise Routers Configuration Guide.
NOTE
If the L2TP Client is trusted by the LNS, you can run the authentication-mode none command in the
authentication scheme view of the LNS to set the authentication mode to non-authentication. If the
command is configured, the LNS does not perform second authentication on remote users.
Procedure
l Configuring local authentication
a. Run system-view
b. Run aaa
Enter the AAA view.
c. Run authentication-scheme authentication-scheme-name
d. Run authentication-mode local
Set the authentication mode to local.
e. Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
f. Run domain domain-name

local.
g. Run authentication-scheme authentication-scheme-name
h. Run quit
i. Run local-user user-name password cipher password
Configure a user name and password for the local user, and store the user name and
password on the device as the VPDN user information. The information is used to
verify remote users.
The password is stored in cipher text mode.
NOTE
To fully ensure the safety of the equipment, the users needs change the password on a regular
basis.
j. Run local-user user-name service-type ppp
Configure a service type for the local user. The service type must be set to ppp
because L2TP uses PPP negotiation.
k. Run return
l Configuring remote authentication and accounting
a. Run system-view
b. Run radius-server template template-name
Create a RADIUS server template, and enter the RADIUS server template view.
You can configure RADIUS server parameters in the RADIUS server template
view.
c. Run radius-server authentication ip-address port
Configure an IP address and a port number for the RADIUS server.
d. Run radius-server accounting ip-address port
Configure a RADIUS accounting server.
By default, no RADIUS accounting server is configured.
e. Run radius-server shared-key cipher key-string
Configure a shared key for connecting to the RADIUS server.
By default, the shared key is huawei in cipher text.
f. Run quit
g. Run aaa
Enter the AAA view.
h. Run authentication-scheme authentication-scheme-name

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
i. Run authentication-mode radius
Set the authentication mode to radius.
j. (Optional)Run accounting-scheme accounting-scheme-name
Create an accounting scheme and enter the accounting scheme view.
A default accounting scheme named default is available on the device. The default
scheme can only be modified but cannot be deleted.
k. (Optional)Run accounting-mode radius
Set the accounting mode to RADIUS.
By default, non-accounting is used.
l. (Optional)Run accounting start-fail { online | offline }
Configure a policy for accounting-start failures.
By default, users cannot go online if accounting-start fails.
m. (Optional)Run accounting realtime interval
Enable real-time accounting and set a real-time accounting interval.
n. (Optional)Run accounting interim-fail [ max-times times ] { online | offline }
Specify the maximum number of real-time accounting requests and a policy for
real-time accounting failures.
o. Run quit
p. Run domain domain-name
local.
q. Run authentication-scheme authentication-scheme-name
r. Run radius-server template-name
Specify RADIUS server template for users in the domain.
s. (Optional)Run accounting-scheme accounting-scheme-name
Apply the accounting scheme to the domain.
By default, the accounting scheme default is applied to a domain. In this
accounting scheme, non-accounting is used and the real-time accounting function is
disabled.
t. (Optional)Run statistic enable
If traffic-based accounting is used, enable traffic statistics collection in the domain.
By default, traffic statistics collection is disabled for a domain.
u. Run return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

----End
2.6.2.2 Configuring the L2TP Client to Dial Up and Initiate L2TP Connections
Context
Create a virtual dial-up interface on the L2TP Client. The virtual users automatically dial up
to initiate L2TP connections to the LNS.
When configuring the L2TP Client, note the following:
l As a PPP dial-up client, the L2TP Client can obtain an IP address for its virtual tunnel
(VT) interface through PPP negotiation from the LNS. Or you can manually specify an
IP address for the VT interface.
l Dial-up parameters, including the user name, password, and authentication mode, of the
VT interface on the L2TP Client must be the same as those on the LNS.
configured.
L2TP Client and LNS.
– If tunnel authentication is not used, disable tunnel authentication on the L2TP
Client and LNS.
Procedure
l Configure the L2TP Client.
a. Run system-view
b. Run l2tp enable
c. Run interface virtual-template vt-number
You can configure dial-up parameters for the VT interface.
NOTE
d. Run ip address ppp-negotiate
The L2TP Client is configured to obtain an IP address from the LNS.
You can run either of the following commands to make the IP protocol take effect.
n Run the ip address ip-address { mask | mask-length } command to assign an
IP address for the interface.
n Run the ip address unnumbered interface interface-type interface-number
command to use one IP address of the other interfaces.
e. Run ppp pap local-user username password { cipher | simple } password
NOTE
When you specify simple, the password is saved in plain text in the configuration, which brings
potential security risks. You are advised to specify cipher to save the password in the cipher text.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The PPP negotiation mode is set to pap and a user name and password are
specified.
If the authentication mode is set to chap, run the following commands:
n ppp chap user username
n ppp chap password { cipher | simple } password
NOTE
In PAP authentication, the password is transmitted in plain text on the network, which brings
potential security risks.
f. Run l2tp-auto-client enable
The device dial-up function is enabled.
g. Run mtu size
1458.
h. Run quit
i. Run interface interface-type interface-number
The view of the physical interface connected to remote users is displayed.
j. Run ip address ip-address { mask | mask-length }
An IP address is configured for the interface and used as the gateway address.
k. Run quit
l. Run l2tp-group group-number
You can configure L2TP connection parameters to enable the L2TP Client to
initiate L2TP connections to the LNS if the user information matches the
configuration.
m. Run tunnel password { simple | cipher } password
that of the tunnel on the LNS.
configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
If simple is selected, the password is saved in the configuration file in plain text.
This brings security risks. It is recommended that you select cipher to save the
password in cipher text.
n. Run tunnel name tunnel-name

A tunnel name is configured to enable the LNS to accept L2TP connections based
on the LAC tunnel name.
specified.
o. Run either of the following commands to configure a public network address or
domain name for the LNS, which specifies the destination address of control
messages.
n start l2tp ip ip-address &<1-4> { domain domain-name | fullusername user-
name | interface interface-type interface-number | vpn-instance vpn-instance-
name fullusername user-name }
n start l2tp host hostname { domain domain-name | fullusername user-name }
The keywords define VPDN users.
n fullusername: specifies a name for VPDN users. L2TP connections can be
established for remote users with the same user name.
n domain: specifies a domain name for VPDN users. L2TP connections can be
established for remote users with the same domain name.
n vpn-instance: specifies the VPN instance to which the IP address of the L2TP
connections of a specific L2TP group belongs.
p. Run return
----End
2.6.2.3 Configuring the LNS to Respond to the L2TP Connection Request
Context
Configure L2TP parameters to enable the LNS to respond to L2TP connection requests to the
LAC based on the LAC tunnel name.
When configuring the LNS, note the following:

l When you configure PPP negotiation parameters on the virtual interface template, the
authentication mode must be the same as that configured on the LAC.
l If the L2TP group number is not 1, you must specify an LAC tunnel name.
configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
LAC and LNS.
LNS.
l If RADIUS authentication is used and Frame-IP and Frame-Route attributes are
specified by the RADIUS server for users, the LNS delivers the Frame-IP and Frame-
Route attributes to users and does not allocate IP addresses from the local address pool.
The Frame-IP must be included in the local address pool.
l If the VPN instance attributes are configured for users on the RADIUS server when
RADIUS authentication is used, you cannot bind the VPN instance to the VT interface of
the LNS.
NOTE
The LNS does not know users' real MAC addresses because user terminals use virtual MAC addresses
allocated by the device. These virtual MAC addresses change randomly and cannot be bound with static IP
addresses.
Procedure
l Configuring the LNS
a. Run system-view
b. Run l2tp enable
c. Run ip pool ip-pool-name
A global IP address pool is created, and the global IP address pool view is
displayed. The global IP address pool is used to allocate IP addresses to remote
users.
This step is not required if you have manually configured a static IP address for the
user.
NOTE
L2TP can only allocate IP addresses of the address pool configured using the ip pool command
but not attributes of other address pools to users.
If you want to allocate the DNS server address to users, add the service-scheme command to the
AAA configuration.
d. Run network ip-address [ mask { mask | mask-length } ]
A network segment is configured to allocate IP addresses dynamically from the
largest to the smallest.
e. Run gateway-list ip-address &<1-8>
A gateway address is configured, and allocated to the remote user.
f. Run quit
g. Run interface virtual-template vt-number
You can configure PPP negotiation parameters on the interface that functions as the
private network gateway interface to accept L2TP connections of remote users.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
h. Run ip address ip-address { mask | mask-length }
An IP address is configured for the gateway in the headquarters.
i. Run remote address { ip-address | pool pool-name }
An IP address pool is configured to allocate IP addresses dynamically for remote
users.
This step is not required if you have configured static IP addresses for remote users.
This step is not required if RADIUS authentication is used and an address pool
name or Frame-IP attribute is specified by the RADIUS server. The LNS allocates
IP addresses for remote users from the address pool specified by the RADIUS
server.
When L2TP supports multiple address pools, omit this step if the service-scheme
command has been run to specify an address pool. The LNS allocates IP addresses
to remote users from the address pool specified by the service-scheme command.
NOTE
If multiple users dial up using the same static IP address, users can go online but their service
packets may fail to be forwarded if forcible address allocation is not configured on the LNS.
Customers need to correctly plan static IP addresses. If the device must identify users and allow
only one user terminal to connect to it, the planned address for the user terminal must be in the
address pool and the ppp ipcp remote-address forced command must be configured.
j. Run ppp authentication-mode { pap | chap }
The PPP authentication mode is set to pap or chap to authenticate remote users.
NOTE
k. Run mtu size
1458.
l. Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
m. Run l2tp-group group-number

You can configure L2TP connection parameters to accept connections initiated by
the LAC.
When the L2TP group number is 1, the LNS accepts all the L2TP connections.
n. Run tunnel password { simple | cipher } password
that of the tunnel on the LAC.
configured.
If simple is selected, the password is saved in the configuration file in plain text. In
this case, users at a lower level can easily obtain the password by viewing the
configuration file. This brings security risks. Therefore, it is recommended that you
select cipher to save the password in cipher text.
o. Run tunnel name tunnel-name

A tunnel name is configured. The tunnel name is used for PPP negotiation during
tunnel establishment.
specified.
p. Run allow l2tp virtual-template virtual-template-number [ remote remote-name
[ vpn-instance vpn-instance-name ] ]
The L2TP group is configured as the LNS to respond to L2TP connection requests
initiated by the LAC.
You must specify a virtual interface template and an LAC tunnel name.
When the L2TP group number is 1, the LNS accepts any L2TP connection requests
from the LAC. You can choose not to specify the remote tunnel name.
q. Run return
----End
2.6.3 Configuring Other L2TP Functions

L2TP provides some other functions to ensure better L2TP services, such as LCP
Renegotiation, AVP Parameter Encryption and Tunnel Authentication.
Prerequisites
Basic L2TP functions have been configured, and L2TP connections have been established
between the LAC and the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Pre-Configuration Tasks
The L2TP functions supported by the device are as follows, and these configurations are
optional.
2.6.3.1 Configuring LCP Renegotiation
Context
The LAC authenticates access users. After the users are authenticated, the LAC sends
authentication information to the LNS that determines whether the users are authorized users.
If the LNS does not trust the LAC, you can configure LCP renegotiation to implement second
authentication on the users. The users renegotiate with the LNS, and L2TP connections can be
established only after renegotiation succeeds.
LCP renegotiation and mandatory CHAP authentication cannot be configured simultaneously.
LCP renegotiation has a higher priority than mandatory CHAP authentication. Therefore,
when both of them are configured, the device performs LCP renegotiation.
Procedure
Step 2 Run l2tp-group group-number
The L2TP group view is displayed.
Step 3 Run mandatory-lcp
LCP renegotiation is enabled.
----End
2.6.3.2 Configuring CHAP Mandatory Authentication
Context
You can configure mandatory CHAP authentication after the LNS receives authentication
information transmitted from the LAC, when the LNS demands high security. After
mandatory CHAP authentication is configured, the LNS performs only CHAP authentication
for remote users. If the authentication mode is set to PAP authentication on the LAC, the LNS
authentication fails and L2TP sessions cannot be established.
LCP renegotiation and mandatory CHAP authentication cannot be configured simultaneously.
LCP renegotiation has a higher priority than mandatory CHAP authentication. Therefore,
when both of them are configured, the device performs LCP renegotiation.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 3 Run mandatory-chap
Mandatory CHAP authentication is enabled.
----End
2.6.3.3 Configuring Primary and Secondary LNSs
Context
You can configure double gateways (one primary and one secondary) in an enterprise
headquarters if the enterprise demands high reliability. When the primary gateway fails,
services are switched to the secondary gateway. However, L2TP connection requests initiated
by the LAC cannot reach the primary LNS. To ensure that L2TP connection requests are sent
to the secondary LNS, you must configure the IP address of the secondary gateway on the
LAC, so that when the first IP address is unreachable, the LAC sends the request packets to
the address of the secondary gateway.
Figure 2-18 Networking diagram of primary and secondary LNSs
branch LAC LNS A headquarters
(PPPoE server)
PC
Internet
PPPoE PC
PPP terminal LNS B
(PPPoE client) L2TP tunnel
Procedure
Step 3 Run start l2tp ip ip-address &<1-4> { domain domain-name | fullusername user-name }
An L2TP connection is initiated. A maximum of four LNS addresses can be configured.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.6.3.4 Configuring AVP Parameter Encryption
Context
An L2TP connection is established so that control messages can be exchanged between the
LAC and LNS. Control messages carry various types of AVP parameters, including the user
name and password. When the AVP parameter encryption is configured, AVP parameters are
encrypted and the key information is hidden to improve communication security.
You must configure the L2TP tunnel authentication function before enabling the AVP
parameter encryption.
Procedure
Step 3 Run tunnel authentication
The L2TP tunnel authentication is enabled.
Step 4 Run tunnel password { simple | cipher } password
An authentication password is configured. This password can also be used for encrypting
AVP parameters.
If simple is selected, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you select cipher to save the password in cipher text.
Step 5 Run tunnel avp-hidden
The AVP parameter encryption is enabled to hide key AVP parameters in L2TP packets.
----End
2.6.3.5 Configuring L2TP Tunnel Authentication
Context
You can configure the L2TP tunnel authentication when a network has a high security
requirement. Configure the same authentication password on the LAC and LNS.
The LAC and LNS check the authentication password configured for each other. If the
authentication password is the same, an L2TP tunnel can be established.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Run tunnel authentication
The L2TP tunnel authentication is enabled.
Step 4 Run tunnel password { simple | cipher } password
An authentication password is configured.
If simple is selected, the password is saved in the configuration file in plain text. This brings
----End
2.6.3.6 Configuring L2TP Tunnel Connectivity
Context
Hello packets are used to detect tunnel connectivity between the LAC and LNS.
When Hello packets time out, L2TP tunnels are automatically deleted to release network
resources. The interval for sending Hello packets is set based on network requirements.
l If the network is stable, you can set a longer interval for sending Hello packets to reduce
network burdens.
l If the network is unstable, you can set a shorter interval for sending Hello packets to
detect tunnel status. When the primary and secondary LNSs are deployed, L2TP
connection requests are sent to the IP address of the secondary LNS if the tunnel
disconnection is detected.
When the device attempts to set up a tunnel to an LNS but the LNS runs abnormally, the
device marks the LNS as unusable and does not set up a tunnel to the LNS in a period. This
period is the LNS locking duration. After the locking duration, the device attempts to set up a
tunnel to the LNS again.
Procedure
l Configuring interval for sending Hello packets
a. Run system-view
b. Run l2tp-group group-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
c. Run tunnel timer hello interval
The interval for sending Hello packets is configured.
By default, Hello packets are sent at intervals of 60s.

l Configuring LNS locking duration
a. Run system-view

b. Run l2tp aging time
The LNS locking duration is configured.
By default, the LNS locking duration is 30 seconds.
Perform this step on the LAC only.
----End
2.6.4 Verifying the L2TP Configuration

After configurations of other L2TP functions are complete, run the following commands on
the LAC or the LNS to view the configurations, tunnel status, and session status.
Prerequisites
L2TP sessions have been established successfully between the LAC and LNS.
Procedure
l Run the display l2tp tunnel command to view information about L2TP tunnel IDs,
session IDs, and public network addresses of the local end and the remote end.
l Run the display l2tp session command to view information about L2TP session IDs of
the local end and the remote end and the local tunnel ID.
l Run the display l2tp-group [ group-number ] command to view configurations of the
specified L2TP group.
----End
2.7 Maintaining L2TP

This section describes how to disconnect an L2TP tunnel forcibly and monitor the running
status of L2TP.
2.7.1 Disconnecting an L2TP Tunnel Manually
Context
When there are no access users, a network fault occurs, or the administrator needs to
disconnect an L2TP tunnel, you can manually disconnect the L2TP tunnel and the sessions in
the tunnel. After the L2TP tunnel is disconnected manually, all the L2TP users who use the
tunnel or sessions will go offline.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Before you disconnect an L2TP tunnel, run the display l2tp tunnel command to view the
tunnel ID or the tunnel name of the remote end that you want to disconnect. Run the display
l2tp session command to view its local session ID.
After you forcibly disconnect an L2TP tunnel, all control and session connections in the
tunnel are removed. The tunnel can be re-established when a new user dials in.
Procedure
l Run the reset l2tp tunnel { peer-name remote-name | local-id tunnel-id } command in
the user view to forcibly disconnect an L2TP tunnel based on the local tunnel ID or the
remote tunnel name.
l Run the reset l2tp session session-id session-id command in the user view to forcibly
disconnect a session connection based on the local session ID.
----End
2.7.2 Monitoring the Running Status of L2TP
Context
In routine maintenance, you can run the following commands in any view to view the running
status of L2TP.
Procedure
l Run the display l2tp-group command to view the L2TP group number existing on the
device.
l Run the display l2tp tunnel [ tunnel-item tunnel-item | tunnel-name tunnel-name ]
command to view the detailed connection parameters of a specified tunnel based on the
local tunnel ID or the remote tunnel name.
l Run the display l2tp session [ destination-ip d-ip-address | session-item session-item |
source-ip s-ip-address ] command to view the detailed connection parameters of a
specified session based on the local session ID and to view a session ID corresponding to
a source or destination public network address of the L2TP tunnel.
----End
2.7.3 Collecting L2TP Packet Statistics
Context
When L2TP users go online, there are packet exchanges of multiple protocols. You can run
the display l2tp statistics tunnel command to display L2TP packet statistics.
Procedure
l Run the display l2tp statistics tunnel [ local-id tunnel-id ] command in the user view to
check L2TP packet statistics.
l Run the reset l2tp statistics tunnel [ local-id tunnel-id ] command in the user view to
reset L2TP packet statistics.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.8 Configuration Examples for L2TP

This section provides L2TP configuration examples.
2.8.1 Example for Configuring Client-Initiated L2TP Connections
Networking Requirements
As shown in Figure 2-19, traveling employees need to communicate with the headquarters
and access the headquarters gateway through the Internet to use internal resources. However,
the headquarters gateway cannot identify and manage access users. To solve this problem,
configure the headquarters gateway as the LNS to establish a virtual point-to-point connection
between the traveling employees and the headquarters gateway when the employees use the
L2TP dialup software on the PC to initiate L2TP connections. A PC running Windows 7
operating system is used in this example.
Figure 2-19 Networking diagram for establishing client-initiated L2TP connections
192.168.2.2/24
Traveling staff Enterprise
(L2TP dial-up headquarters
software) LNS PC2
GE1/0/0
Internet 202.1.1.1/24
PC1 202.1.2.1/24 VT1

192.168.1.1/24
PC3
L2TP encapsulation
Configuration Roadmap
The configuration roadmap is as follows:
1. Connect the headquarters gateway to the Internet, and configure the gateway as the LNS
to respond to L2TP connection requests sent by a traveling employee.
2. Connect the employee to the Internet, and enable the employee to initiate L2TP
connections to the LNS using the L2TP dialup software.
Procedure
Step 1 Configure the LNS.
# Configure an IP address and a route to the Internet. For example, set the next hop address to
the Internet to 202.1.1.2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
<Huawei> system-view
[Huawei] sysname LNS
[LNS] interface gigabitethernet 1/0/0
[LNS-GigabitEthernet1/0/0] ip address 202.1.1.1 255.255.255.0
[LNS-GigabitEthernet1/0/0] quit
[LNS] ip route-static 0.0.0.0 0 202.1.1.2
# Set the user name, password, and service type to huawei, Huawei@1234, and ppp
respectively.
[LNS] aaa
[LNS-aaa] local-user huawei password
Please configure the login password (8-128)
It is recommended that the password consist of at least 2 types of characters, i
ncluding lowercase letters, uppercase letters, numerals and special characters.
Please enter password:
Please confirm password:
Info: Add a new user.
Warning: The new user supports all access modes. The management user access mode
s such as Telnet, SSH, FTP, HTTP, and Terminal have security risks. You are advi
sed to configure the required access modes only.
[LNS-aaa] local-user huawei service-type ppp
[LNS-aaa] quit
# Configure an IP address pool used to assign addresses to dialup users.

[LNS] ip pool lns
[LNS-ip-pool-lns] network 192.168.1.0 mask 24
[LNS-ip-pool-lns] gateway-list 192.168.1.1
[LNS-ip-pool-lns] quit
# Configure a virtual interface template.

[LNS] interface virtual-template 1
[LNS-Virtual-Template1] ip address 192.168.1.1 255.255.255.0
[LNS-Virtual-Template1] ppp authentication-mode chap
[LNS-Virtual-Template1] remote address pool lns
[LNS-Virtual-Template1] quit
# Enable L2TP and create an L2TP group numbered 1.

[LNS] l2tp enable
[LNS] l2tp-group 1
# Disable the tunnel authentication function. The PC running Windows 7 operating system
does not support tunnel authentication.
[LNS-l2tp1] undo tunnel authentication
# Bind the LNS to the virtual interface template.

[LNS-l2tp1] allow l2tp virtual-template 1
Step 2 Configure the Windows 7 operating system.

# Modify the Windows registry and disable the digital certificate authentication function.
Choose Start > Run and enter regedit to open the Registry Editor. Open Parameters in
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\, create
DWORD and set the name and value to ProhibitIpSec and 1 respectively. After modifying
the parameters, restart the PC.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Create an L2TP network connection.

Choose Start > Run > Network and Sharing Center, click Set Up a Connection or
Network, choose Connect to a workplace, and click Next.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Click Use my Internet connection (VPN).
Enter an Internet address which is the IP address of the LNS (202.1.1.1), enter a destination
name (for example, L2TP) as the network connection name, and click Next. You can
customize a destination name.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Enter the user name huawei and password Huawei@1234 and click Create.
NOTE
You do not need to set the domain.
Click Close.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Set authentication parameters for the L2TP connection.

Choose Start > Run > Network and Sharing Center and click Connect to a network. The
created L2TP connection is displayed. Right-click L2TP and choose Properties to set
connection parameters.
You do not need to modify parameters on the General tab.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Select Display progress while connecting and Prompt for name and password certificate,
etc on the Options tab.
NOTE
Do not change the parameters that are displayed after you click PPP Settings.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On the Security tab, select Automatic or Layer 2 Tunneling Protocol with IPsec for Type
of VPN.
Select Unencrypted password [PAP], Challenge Handshake Authentication Protocol
[CHAP], and Microsoft CHAP Version 2 [MS-CHAP v2] in Allow these protocols.
NOTE
If you click Advanced settings, a dialog box is displayed on which you can set the IPSec pre-shared
key. Do not set the IPSec pre-shared key here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
You do not need to modify settings on the Networking and Sharing tabs.
Choose Start > Run > Network and Sharing Center and click Connect to a network. The
created L2TP connection is displayed. Right-click L2TP, enter the user name and password,
and click Connect.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 3 Verify the configuration.

# After the configurations are complete, PC 1 obtains a private network address
192.168.1.254 for the L2TP connection, and PC 1 can communicate with the PC in the
headquarters.
----End
Configuration File
Configuration file of the LNS
#
sysname LNS
#
l2tp enable
#
interface GigabitEthernet1/0/0
ip address 202.1.1.1 255.255.255.0
#
aaa
local-user huawei password cipher %^%#_<`.CO&(:LeS/$#F\H0Qv8B]KAZja3}3q'RNx;VI%^
%#
local-user huawei privilege level 0
local-user huawei server-type ppp
#
l2tp-group 1
undo tunnel authentication
allow l2tp virtual-template 1
#
interface Virtual-Template1
ppp authentication-mode chap
remote address pool lns
ip address 192.168.1.1 255.255.255.0
#
ip pool lns
network 192.168.1.0 mask 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
gateway-list 192.168.1.1
#
ip route-static 0.0.0.0 0.0.0.0 202.1.1.2
#
return
2.8.2 Example for Configuring the LAC to Initiate Call-Triggered

L2TP Connections (Dial-Up Users)
As shown in Figure 2-20, an enterprise has a branch located in another city, and the branch is
located in a traditional dial-up network.
Branch users need to establish VPDN connections with users at the headquarters. Therefore,
the branch users apply for the L2TP service from the ISP. The ISP configures the NAS as the
LAC to send call connecting requests to the LNS through the Internet.
The gateway in the headquarters is configured as the LNS to establish L2TP connections
between the branch and the headquarters.
Figure 2-20 Networking diagram for configuring the LAC to initiate call-triggered L2TP
connections (dial-up users)
VT1
192.168.1.1/24
L2TP tunnel
Dial-up LNS
Internet
Network
GE1/0/0
LAC 202.1.1.1/24
(NAS)
branch headquarters
PC1
PC2
PPP terminal PC3
1. Configure local AAA authentication for the LNS to authenticate dial-up users.
2. Create an IP address pool and allocate IP addresses to users, so that the LNS can manage
the users.
3. Configure negotiation parameters using the virtual interface template, so that the LNS
can implement PPP negotiation with the users.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4. Configure an L2TP group and create a tunnel between the LAC and LNS, so that the
LNS can accept L2TP connection requests.
Procedure
Step 1 Configure AAA authentication, and set the user name and password to huawei and
Huawei@1234.
[LNS] aaa
[LNS-aaa] quit
Step 2 Configure a private IP address pool.

[LNS] ip pool l
[LNS-ip-pool-1] network 192.168.1.0 mask 24
[LNS-ip-pool-1] gateway-list 192.168.1.1
[LNS-ip-pool-1] quit
Step 3 Set PPP negotiation parameters.

[LNS-Virtual-Template1] remote address pool 1
Step 4 Configure the LNS to accept L2TP connection requests.

# Enable L2TP and configure an L2TP group.
[LNS] l2tp enable
[LNS] l2tp-group 1
# Configure an LNS tunnel name and LAC tunnel name.

[LNS-l2tp1] tunnel name LNS
[LNS-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable the tunnel authentication function, and configure an authentication password.

[LNS-l2tp1] tunnel authentication
[LNS-l2tp1] tunnel password cipher huawei
[LNS-l2tp1] quit

# After PC 1 goes online, run the display l2tp tunnel command on the LNS. The tunnel and
session are established.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LNS] display l2tp tunnel
Total tunnel : 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
1 1 202.1.2.1 1701 1 LAC
# Check that PC 1 can communicate with hosts in the enterprise headquarters.
----End
Configuration File
Configuration file of the LNS
#
sysname LNS
#
l2tp enable
#
ip pool 1
network 192.168.1.0 mask 255.255.255.0
#
aaa
local-user huawei password cipher %^%#_<`.CO&(:LeS/$#F\H0Qv8B]KAZja3}3q'RNx;VI%^
%#
local-user huawei service-type ppp
#
remote address pool 1
ip address 192.168.1.1 255.255.255.0
#
interface
GigabitEthernet1/0/0
ip address 202.1.1.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote LAC
tunnel password cipher %@%@/-#)Lg[S4F:#2~ZNvqa$]\DL%@%@
tunnel name LNS
#
ip route-static 0.0.0.0 0.0.0.0 202.1.1.2
#
return
2.8.3 Example for Configuring the LAC to Initiate Call-Triggered

L2TP Connections (PPPoE Users)
As shown in Figure 2-21, an enterprise has some branches located in other cities, and
branches use the Ethernet network.
The branch staff need to establish VPDN connections with the headquarters. L2TP is
deployed between the branch and the headquarters. The branch has no dial-up network, and
its gateway functions as a PPPoE server to allow dial-up data to be transmitted over the
Ethernet. The branch gateway also functions as the LAC to establish L2TP tunnels with the
headquarters.
The gateway at the enterprise headquarters is configured as the LNS to establish L2TP
connections between the branch and headquarters.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-21 Networking diagram for the LAC to initiate call-triggered L2TP connections
(PPPoE users)
Enterprise
Enterprise GE2/0/0 headquarters
branch LAC 192.168.2.1/24
(PPPoE server)
LNS
GE1/0/0 GE1/0/0
202.1.2.1/24 202.1.1.1/24
Internet
oE GE2/0/0
PC1 PPP
L2TP tunnel PC2

PPP terminal
(PPPoE client) VT1
192.168.1.1/24
1. Configure the LAC as a PPPoE server and enable CHAP authentication so that the LAC
can accept dial-up data from branch users over the Ethernet.
3. Configure the LAC to establish L2TP connections to the headquarters for dial-up users
that are authenticated.
5. Create an IP address pool and allocate IP addresses to users, so that the LNS can manage
the users.
6. Configure negotiation parameters using the virtual interface template, so that the LNS
can implement PPP negotiation with the users.
7. Configure an L2TP group and create a tunnel between the LAC and LNS, so that the
LNS can accept L2TP connection requests.
Procedure
Step 1 Configure the LAC as a PPPoE server.
# Create a virtual interface template and configure PPP negotiation mode.
[Huawei] sysname LAC
[LAC] interface virtual-template 1
[LAC-Virtual-Template1] ppp authentication-mode chap
[LAC-Virtual-Template1] quit
# Configure the PPPoE service on the physical interface at the user side and bind the interface
to a virtual interface template.
[LAC] interface gigabitethernet 2/0/0
[LAC-GigabitEthernet2/0/0] pppoe-server bind virtual-template 1
[LAC-GigabitEthernet2/0/0] quit
Step 2 Configure the AAA authentication, and set the user name and password to huawei and
Huawei@1234 on the LAC.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LAC] aaa
[LAC-aaa] local-user huawei password
[LAC-aaa] local-user huawei service-type ppp
[LAC-aaa] quit
Step 3 Configure the LAC to initiate an L2TP connection.

[LAC] l2tp enable
[LAC] l2tp-group 1
# Configure a tunnel name for the LAC local end and specify a public IP address for the LNS.
[LAC-l2tp1] tunnel name lac
[LAC-l2tp1] start l2tp ip 202.1.1.1 fullusername huawei
# Enable the tunnel authentication function, and configure an authentication password. The
password must be the same as that on the LNS.
[LAC-l2tp1] tunnel authentication
[LAC-l2tp1] tunnel password cipher huawei
[LAC-l2tp1] quit
# Configure an IP address for the public-network-side interface.

[LAC-GigabitEthernet1/0/0] ip address 202.1.2.1 255.255.255.0
# Configure a static route to the LNS. For example, set the next hop IP address to 202.1.2.2.
[LAC] ip route-static 202.1.1.1 32 202.1.2.2
Step 4 Configure the AAA authentication on the LNS.

[LNS] aaa
[LNS-aaa] local-user huawei password cipher Huawei@1234
[LNS-aaa] quit
Step 5 Configure a private IP address pool for the LNS.

[LNS] ip pool 1
Step 6 Set PPP negotiation parameters for the LNS.

Step 7 Configure the LNS to respond to the L2TP connection request.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LNS] l2tp enable

[LNS] l2tp-group 1
# Configure an LNS tunnel name and LAC tunnel name.

[LNS-l2tp1] tunnel name lns
[LNS-l2tp1] allow l2tp virtual-template 1 remote lac

[LNS-l2tp1] quit

# Configure a static route to the LAC. For example, set the next hop IP address to 202.1.1.2.
# Configure a private IP address.


# After PC 1 goes on line, run the display pppoe-server session all command on the LAC to
view the PPPoE sessions.
[LAC] display pppoe-server session all
SID Intf State OIntf RemMAC
LocMAC
1 Virtual-Template1:0 UP GE2/0/0 5489.98f7.2fcb 5489.9872.366f
# Run the display l2tp tunnel command on the LAC or LNS to view L2TP tunnel and
session information. The command output for the LNS is shown as an example.
Total tunnel : 1
1 1 202.1.2.1 1701 1 lac
# Check that PC 1 can communicate with PC 2 in the enterprise headquarters.
----End
Configuration Files
l Configuration file of the LAC
#
sysname LAC
#
l2tp enable
#
aaa
local-user huawei password cipher %^%#_<`.CO&(:LeS/$#F
\H0Qv8B]KAZja3}3q'RNx;VI%^%#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ip address 202.1.2.1 255.255.255.0
#
pppoe-server bind Virtual-Template 1
#
l2tp-group 1
tunnel name lac
start l2tp ip 202.1.1.1 fullusername huawei
#
ip route-static 202.1.1.1 255.255.255.255 202.1.2.2
#
return
l Configuration file of the LNS

#
sysname LNS
#
l2tp enable
#
ip pool 1
network 192.168.1.0 mask 255.255.255.0
#
aaa
#
ip address 192.168.1.1 255.255.255.0
#
ip address 202.1.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote lac
tunnel password cipher %@%@EB~j7Je>;@>uNr''D=J<]\WL%@%@
tunnel name lns
#
ip route-static 202.1.2.1 255.255.255.255 202.1.1.2
#
return
2.8.4 Example for Configuring an L2TP Client-Initiated L2TP

Connection
The headquarters network provides VPDN services for the branch staff to allow them to
access the network of the headquarters. The LNS only authenticates the L2TP Client. The
L2TP Client dials up to establish an L2TP connection to the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-22 Networking diagram for establishing an L2TP Client-Initiated L2TP connection
Enterprise
headquarters
Enterprise GE2/0/0 GE2/0/0
branch 192.168.10.1/24 192.168.2.1/24
LAC GE1/0/0 LNS

GE1/0/0
202.1.2.1/24 202.1.1.1/24
Internet
PC1
L2TP tunnel PC2

192.168.10.2/24
192.168.2.2/24
VT1
192.168.1.1/24
1. Enable L2TP on the L2TP Client. The virtual PPP user sends a connection request to the
server in the headquarters over an L2TP tunnel. After the PPP user is authenticated, a
tunnel is set up.
2. On the L2TP Client, configure a reachable route to the LNS and the enable the dial-up
function.
3. On the LNS, configure L2TP, a virtual PPP user, and a route to the public network
segment.
Procedure
Step 1 Configure the L2TP Client.

[Huawei] sysname L2TP Client
[L2TP Client] interface gigabitethernet 1/0/0
[L2TP Client-GigabitEthernet1/0/0] ip address 202.1.2.1 255.255.255.0
[L2TP Client-GigabitEthernet1/0/0] quit
# Configure an IP address for the user-side interface.

[L2TP Client] interface gigabitethernet 2/0/0
[L2TP Client-GigabitEthernet2/0/0] ip address 192.168.10.1 255.255.255.0
[L2TP Client-GigabitEthernet2/0/0] quit
# Enable L2TP globally, create an L2TP group, and configure the user huawei to establish an
L2TP connection to the LNS.
[L2TP Client] l2tp enable
[L2TP Client] l2tp-group 1
[L2TP Client-l2tp1] tunnel name L2TP Client
[L2TP Client-l2tp1] start l2tp ip 202.1.1.1 fullusername huawei
# Enable tunnel authentication and set the tunnel password.

[L2TP Client-l2tp1] tunnel authentication
[L2TP Client-l2tp1] tunnel password cipher huawei
[L2TP Client-l2tp1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure the user name and password, authentication mode, and IP address for the virtual
PPP user.
[L2TP Client] interface virtual-template 1
[L2TP Client-Virtual-Template1] ppp chap user huawei
[L2TP Client-Virtual-Template1] ppp chap password cipher Huawei@1234
[L2TP Client-Virtual-Template1] ip address ppp-negotiate
[L2TP Client-Virtual-Template1] quit
# On the LNS, configure a static route to the public network. For example, set the next hop
address to 202.1.2.2.
[L2TP Client] ip route-static 202.1.1.1 255.255.255.255 202.1.2.2
# Enable the L2TP Client to dial up and establish an L2TP tunnel.

[L2TP Client] interface virtual-template 1
[L2TP Client-Virtual-Template1] l2tp-auto-client enable
[L2TP Client-Virtual-Template1] quit
# Configure private routes so that branches can communicate with the headquarters through
the private network.
[L2TP Client] ip route-static 192.168.2.0 255.255.255.0 virtual-template 1

[LNS] interface gigabitEthernet 1/0/0

[LNS] interface GigabitEthernet 2/0/0
# Configure AAA authentication, and set the user name and password to huawei and
Huawei@1234 on the LNS.
[LNS] aaa
[LNS-aaa] quit
# Configure an IP address pool for the LNS and allocate an IP address to the dial-up interface
of the L2TP Client.
[LNS] ip pool l
# Create a virtual interface template and configure PPP negotiation parameters.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[LNS] l2tp enable
[LNS] l2tp-group 1
# Configure an LNS tunnel name and L2TP Client tunnel name.

[LNS-l2tp1] allow l2tp virtual-template 1 remote L2TP Client

[LNS-l2tp1] quit
address to 202.1.1.2.
[LNS] ip route-static 202.1.2.1 255.255.255.255 202.1.1.2
# Configure private routes so that the headquarters can communicate with branches through
[LNS] ip route-static 192.168.10.0 255.255.255.0 virtual-template 1

# Run the display l2tp tunnel command on the L2TP Client or LNS to view L2TP tunnel and
session information. The command output for the LNS is shown as an example.
Total tunnel : 1
1 1 202.1.2.1 1701 1 L2TP Client
# Check that PC 1 can communicate with PC 2 in the enterprise headquarters.
----End
Configuration Files
l Configuration file of the L2TP Client
#
sysname L2TP Client
#
l2tp enable
#
ppp chap user huawei
ppp chap password cipher
%^%#'&=6Q(|7-#|.]EB`mK$(h7[CY`2m}-YT)Q=Oh2~2%^%#
ip address ppp-negotiate
l2tp-auto-client enable
#
ip address 202.1.2.1 255.255.255.0
#
ip address 192.168.10.1 255.255.255.0
#
l2tp-group 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
tunnel name L2TP Client

#
ip route-static 192.168.2.0 255.255.255.0 Virtual-Template1
ip route-static 202.1.1.1 255.255.255.255 202.1.2.2
#
return

#
sysname LNS
#
l2tp enable
#
ip pool 1
network 192.168.1.0 mask 255.255.255.0
#
aaa
#
ip address 192.168.1.1 255.255.255.0
#
ip address 202.1.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote L2TP Client
tunnel name lns
#
ip route-static 202.1.2.1 255.255.255.255 202.1.1.2
#
return
2.8.5 Example for Configuring L2TP Client-Initiated L2TP

Connections
The headquarters network provides VPDN services for the branch staff to allow them to
access the network of the headquarters. The LNS only authenticates the L2TP Client. The
L2TP Client dials up to establish L2TP connections to the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-23 Networking diagram for establishing L2TP Client-Initiated L2TP connections
GE2/0/0
Enterprise 10.1.10.1/24
branch L2TP Client_1
GE1/0/0
1.1.2.1/24
VT1
PC1 10.1.1.1/24 Enterprise
GE2/0/0
L2TP tunnel 10.1.2.1/24 headquarters
10.1.10.2/24
LNS
GE1/0/0
Internet 1.1.1.1/24
L2TP tunnel
GE2/0/0
10.1.20.1/24 VT1
Enterprise 10.1.1.1/24 PC2
branch
10.1.2.2/24
GE1/0/0
1.1.3.1/24
L2TP Client_2
PC3
10.1.20.2/24
tunnel is set up.
2. On the L2TP Client, configure a reachable route to the LNS and the enable the dial-up
function.
segment.
Procedure
Step 1 Configure the L2TP Client_1.
[Huawei] sysname L2TP Client_1
[L2TP Client_1] interface gigabitethernet 1/0/0
[L2TP Client_1-GigabitEthernet1/0/0] ip address 1.1.2.1 255.255.255.0
[L2TP Client_1-GigabitEthernet1/0/0] quit


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[L2TP Client_1] l2tp enable

[L2TP Client_1] l2tp-group 1
[L2TP Client_1-l2tp1] tunnel name L2TP Client_1
[L2TP Client_1-l2tp1] start l2tp ip 1.1.1.1 fullusername huawei

[L2TP Client_1-l2tp1] tunnel authentication
[L2TP Client_1-l2tp1] tunnel password cipher huawei
[L2TP Client_1-l2tp1] quit
PPP user.
[L2TP Client_1] interface virtual-template 1
[L2TP Client_1-Virtual-Template1] ppp chap user huawei
[L2TP Client_1-Virtual-Template1] ppp chap password cipher Huawei@1234
[L2TP Client_1-Virtual-Template1] ip address ppp-negotiate
[L2TP Client_1-Virtual-Template1] ospf p2mp-mask-ignore
[L2TP Client_1-Virtual-Template1] quit
address to 1.1.2.2.
[L2TP Client_1] ip route-static 1.1.1.1 255.255.255.255 1.1.2.2

[L2TP Client_1-Virtual-Template1] l2tp-auto-client enable
[L2TP Client_1] ospf 10
[L2TP Client_1-ospf-10] area 0
[L2TP Client_1-ospf-10-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[L2TP Client_1-ospf-10-area-0.0.0.0] quit
[L2TP Client_1-ospf-10] quit
Step 2 Configure the L2TP Client_2.

[Huawei] sysname L2TP Client_2

[L2TP Client_2] l2tp enable
[L2TP Client_2] l2tp-group 1
[L2TP Client_2-l2tp1] tunnel name L2TP Client_2
[L2TP Client_2-l2tp1] start l2tp ip 1.1.1.1 fullusername huawei

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[L2TP Client_2-l2tp1] tunnel authentication

[L2TP Client_2-l2tp1] tunnel password cipher huawei
[L2TP Client_2-l2tp1] quit
PPP user.
[L2TP Client_2-Virtual-Template1] ppp chap user huawei
[L2TP Client_2-Virtual-Template1] ppp chap password cipher Huawei@1234
[L2TP Client_2-Virtual-Template1] ip address ppp-negotiate
[L2TP Client_2-Virtual-Template1] ospf p2mp-mask-ignore
address to 1.1.3.2.
[L2TP Client_2] ip route-static 1.1.1.1 255.255.255.255 1.1.3.2

[L2TP Client_2-Virtual-Template1] l2tp-auto-client enable
[L2TP Client_2] ospf 10
[L2TP Client_2-ospf-10] area 0
[L2TP Client_2-ospf-10-area-0.0.0.0] quit
[L2TP Client_2-ospf-10] quit


# Configure AAA authentication, and set the user name and password to huawei and
Huawei@1234 on the LNS.
[LNS] aaa
[LNS-aaa] quit
# Configure an IP address pool for the LNS and allocate an IP address to the dial-up interface
of the L2TP Client.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LNS] ip pool l
# Create a virtual interface template and configure PPP negotiation parameters.

[LNS-Virtual-Template1] ospf network-type p2mp
[LNS-Virtual-Template1] ospf timer hello 10
[LNS-Virtual-Template1] ospf p2mp-mask-ignore

[LNS] l2tp enable
[LNS] l2tp-group 1
# Configure an LNS tunnel name and L2TP Client tunnel name.

[LNS-l2tp1] allow l2tp virtual-template 1

[LNS-l2tp1] quit
address to 1.1.1.2.
[LNS] ospf 10
[LNS-ospf-10] area 0
[LNS-ospf-10-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[LNS-ospf-10-area-0.0.0.0] network 10.1.2.0 0.0.0.255
[LNS-ospf-10-area-0.0.0.0] quit
[LNS-ospf-10] quit

# Run the display l2tp tunnel command on the L2TP Client or LNS to view L2TP tunnel and
session information in RemoteName and Sessions. The command output for the LNS is
shown as an example.
Total tunnel : 2
1 1 1.1.2.1 1701 1 L2TP Client_1
2 1 1.1.3.1 1701 1 L2TP Client_2
# Check that PC1 and PC3 can communicate with PC2 in the enterprise headquarters.
----End
Configuration Files
l Configuration file of the L2TP Client_1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname L2TP Client_1
#
l2tp enable
#
ppp chap password cipher %^%#'&=6Q(|7-#|.]EB`mK$(h7[CY`2m}-YT)Q=Oh2~2%^%#
ospf p2mp-mask-ignore
#
ip address 1.1.2.1 255.255.255.0
#
ip address 10.1.10.1 255.255.255.0
#
l2tp-group 1
tunnel name L2TP Client_1
#
ospf 10
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.10.0 0.0.0.255
#
ip route-static 1.1.1.1 255.255.255.255 1.1.2.2
#
return
l Configuration file of the L2TP Client_2
#
sysname L2TP Client_2
#
l2tp enable
#
#
ip address 1.1.3.1 255.255.255.0
#
ip address 10.1.20.1 255.255.255.0
#
l2tp-group 1
tunnel password cipher %@%@6Za[BAw}f$WX}sX`]:QP1%.t%@%@
tunnel name L2TP Client_2
#
ospf 10
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.20.0 0.0.0.255
#
ip route-static 1.1.1.1 255.255.255.255 1.1.3.2
#
return
#
sysname LNS
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l2tp enable
#
ip pool 1
network 10.1.1.0 mask 255.255.255.0
#
aaa
#
ip address 10.1.1.1 255.255.255.0
ospf network-type p2mp
ospf timer hello 10
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1
tunnel name lns
#
ospf 10
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
ip route-static 1.1.2.1 255.255.255.255 1.1.1.2
ip route-static 1.1.3.1 255.255.255.255 1.1.1.2
#
return
2.8.6 Example for Configuring L2TP Client-Initiated L2TP

Connections Using the 3G Interface
As shown in Figure 2-24, an enterprise has some branches located in other cities, and its
branches use the Ethernet network and have gateways deployed, so that branch hosts can
access the Internet.
The headquarters provides VPDN services for the branch staff to allow any staff to access the
network of the headquarters. The LNS only authenticates the L2TP Client. The L2TP Client
dials up to establish L2TP connections between the L2TP Client and LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-24 Networking diagram for L2TP Client-Initiated L2TP connections using the 3G
interface
3G Node B
RouterA RouterB
Cellular0/0/0 GE2/0/0
GE1/0/0 Internet 12.1.1.1/24 GE1/0/0
192.168.1.1/24 192.168.0.1/24
L2TP Client LNS
L2TP Tunnel
PC
VT1
13.1.1.1/24
LAN Server
192.168.1.2/24 Headquarters
192.168.0.2/24
1. Configure a dial string for dialup on a 3G interface and a route to the public network
address.
tunnel is set up.
3. Configure a route to the public network address with the 3G interface as the outbound
interface, and enable the dial function on the L2TP Client.
segment.
Procedure
Step 1 Configure RouterA (the L2TP Client side).
In this example, the IP address of Cellular0/0/0 on RouterA is allocated by the ISP, and the IP
address of GE2/0/0 on RouterB is 12.1.1.1.
# Configure dialup on Cellular0/0/0.
[Huawei] sysname RouterA
[RouterA] dialer-rule
[RouterA-dialer-rule] dialer-rule 1 ip permit
[RouterA-dialer-rule] quit
[RouterA] interface cellular 0/0/0
[RouterA-Cellular0/0/0] link-protocol ppp
[RouterA-Cellular0/0/0] ip address ppp-negotiate
[RouterA-Cellular0/0/0] dialer enable-circular
[RouterA-Cellular0/0/0] dialer-group 1
[RouterA-Cellular0/0/0] dialer timer autodial 60

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA-Cellular0/0/0] dialer number *99# autodial

[RouterA-Cellular0/0/0] mode wcdma wcdma-precedence
[RouterA-Cellular0/0/0] quit
[RouterA] apn profile 3gprofile
[RouterA-apn-profile-3gprofile] apn 3GNET
[RouterA-apn-profile-3gprofile] quit
[RouterA] interface cellular 0/0/0
[RouterA-Cellular0/0/0] apn-profile 3gprofile
[RouterA-Cellular0/0/0] shutdown
[RouterA-Cellular0/0/0] undo shutdown
[RouterA-Cellular0/0/0] quit

[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 192.168.1.1 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
# Configure an L2TP group and its attributes.

[RouterA] l2tp enable
[RouterA] l2tp-group 1
[RouterA-l2tp1] tunnel name L2TP Client
[RouterA-l2tp1] start l2tp ip 12.1.1.1 fullusername huawei

[RouterA-l2tp1] tunnel authentication
[RouterA-l2tp1] tunnel password cipher 123
[RouterA-l2tp1] quit
PPP user.
[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ppp chap user huawei
[RouterA-Virtual-Template1] ppp chap password ciphe Huawei@1234
[RouterA-Virtual-Template1] ip address 13.1.1.2 255.255.255.0
[RouterA-Virtual-Template1] quit
# Configure a public route so that the packets sent to the headquarters are forwarded through
the 3G interface.
[RouterA] ip route-static 0.0.0.0 0 Cellular0/0/0
# Enable the L2TP Client to establish an L2TP tunnel.

[RouterA] interface virtual-template 1
[RouterA-virtual-template1] l2tp-auto-client enable
[RouterA-virtual-template1] quit
[RouterA] ip route-static 192.168.0.0 255.255.255.0 virtual-template 1
Step 2 Configure RouterB (the LNS side).
# Assign an IP address to GigabitEthernet2/0/0 on RouterB.

[Huawei] sysname RouterB
[RouterB] interface gigabitEthernet 2/0/0
[RouterB-GigabitEthernet2/0/0] ip address 12.1.1.1 255.255.255.0
[RouterB-GigabitEthernet2/0/0] quit
# Configure a private IP address.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterB] interface GigabitEthernet 1/0/0

# Create and configure a virtual template.

[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ppp authentication-mode chap
[RouterB-Virtual-Template1] ip address 13.1.1.1 255.255.255.0
[RouterB-Virtual-Template1] quit

[RouterB] l2tp enable
[RouterB] l2tp-group 1
# Set the local and remote tunnel names for the LNS.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1] allow l2tp virtual-template 1 remote L2TP Client

[RouterB-l2tp1] tunnel authentication
[RouterB-l2tp1] tunnel password cipher 123
[RouterB-l2tp1] quit
# Set the user name and password to huawei and Huawei@1234, which must be the same as
those on the L2TP Client side.
[RouterB] aaa
[RouterB-aaa] local-user huawei password
[RouterB-aaa] local-user huawei service-type ppp
[RouterB-aaa] quit
[RouterB] ip route-static 0.0.0.0 0 12.1.1.2
[RouterB] ip route-static 192.168.1.0 255.255.255.0 virtual-template 1

# Run the display l2tp tunnel command on the L2TP Client and LNS. You can see that a
tunnel has been established. The command output on the L2TP Client is used as an example.
[RouterA] display l2tp tunnel
Total tunnel : 1
1 1 12.1.1.1 1701 1 LNS
# Run the display l2tp session command to check the session status. The command output on
the LNS is used as an example.
[RouterB] display l2tp session

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Total session : 1
LocalSID RemoteSID LocalTID
1 1 1
# Check that PCs in the branch can access servers in the headquarters.
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
l2tp
enable
#
interface Virtual-
Template1
ip address 13.1.1.2
255.255.255.0
l2tp-auto-client
enable
#
interface
Cellular0/0/0
link-protocol
ppp
ip address ppp-
negotiate
dialer enable-
circular
dialer-group 1
apn-profile 3GNET
dialer timer autodial
60
dialer number *99#
autodial
#
interface
ip address 192.168.1.1
255.255.255.0
#
l2tp-group
1
tunnel password cipher %@%@d'o6Xpp(i/i:WRC)`'0#3nJ*%@%@
tunnel name L2TP
Client
start l2tp ip 12.1.1.1 fullusername
huawei
#
dialer-rule
dialer-rule 1 ip permit
#
apn profile 3GNET
#
ip route-static 0.0.0.0 0.0.0.0 Cellular0/0/0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
return
l Configuration file of RouterB

#
sysname RouterB
#
l2tp
enable
#
aaa

local-user huawei service-type
ppp
#
interface Virtual-
Template1
ppp authentication-mode
chap
ip address 13.1.1.1
255.255.255.0
#
interface
255.255.255.0
#
interface
ip address 12.1.1.1
255.255.255.0
#
l2tp-group
1
allow l2tp virtual-template 1 remote L2TP
Client
tunnel password cipher %@%@5j*=S&AGXK'J}kG])REK]_-o%@%@
tunnel name
LNS
#
ip route-static 0.0.0.0 0.0.0.0 12.1.1.2

#
return
2.9 Troubleshooting L2TP

This section describes common faults caused by incorrect L2TP configurations.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.9.1 User Failed to Dial Up to the LNS

Fault Description
A remote user uses the built-in dial-up software of Windows XP to initiate L2TP connections
to the LNS in the enterprise headquarters. However, the dialup fails.
Procedure
Before handling this fault, ensure that a reachable route exists between the remote user and
the LNS.
The possible causes are:
l The user information differs from that configured on the LNS.
In the AAA view, you can check user information configured on the LNS.
l The IP address pool on the LNS is incorrectly configured.
No gateway address is specified in the IP address pool or the specified gateway address
is incorrect. Run the gateway-list ip-address &<1-8> command to specify the IP address
of the virtual template interface as the gateway address.
l The authentication modes on the PC and the LNS are different.
Run the display l2tp-group [ group-number ] command on the LNS to check the
TunnelAuth field to see whether tunnel authentication is enabled. Windows XP does not
support tunnel authentication. If the remote user supports tunnel authentication, check
whether the authentication password of the user is the same as that configured in the
L2TP group view.
l PPP negotiation parameters are not consistent on the two ends.
In the VT interface view, check whether the PPP authentication mode configured on the
LNS is pap or chap. Run the display l2tp-group [ group-number ] command to check
the ForceChap field to see whether mandatory CHAP authentication is enabled. If the
mandatory CHAP authentication is enabled, the authentication mode must be chap in the
VT interface view. Check the L2TP connection attributes on the PC to ensure that PAP
and CHAP are selected.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-25 L2TP connection attributes

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2.9.2 Data Transmission Fails After L2TP Connections Are

Established
Symptoms
An L2TP connection is established, but data transmission fails. The remote user cannot ping
IP addresses on the private network segment in the enterprise headquarters.
Troubleshooting Procedure
The possible causes and corresponding troubleshooting methods are as follows:
l No route to the private network segment in the enterprise headquarters is configured on
the LNS.
Run the display ip routing-table command on the LNS to check the routing table.
l Network congestion occurs.
L2TP is UDP-based, but UDP does not perform error control on packets. When L2TP is
enabled on an unstable network, the ping to the remote end may fail.
l The LNS cannot identify the format of received PPP packets after the PPP negotiation
between the LAC and remote user.
Generally, the LNS can identify the format of received PPP packets after the PPP
negotiation between the LAC and remote user. If PPP packets after the PPP negotiation

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
between the LAC of some vendors and remote user are compressed, the LNS may not be
able to identify these packets. In this case, the remote user cannot ping IP addresses on
the private network segment in the enterprise headquarters. If this problem occurs, run
the mandatory-lcp command on the LNS to enable LCP renegotiation. The remote user
and LNS can then start PPP negotiation again, and the LNS can identify PPP packets
sent by the remote user.
l The NAT ALG function is disabled for DNS.
Run the display nat alg command on the device to check whether NAT ALG is enabled
for DNS.
[Huawei]display nat alg
NAT Application Level Gateway
Information:
----------------------------------
Application
Status
----------------------------------
dns
Disabled
ftp
Disabled
rtsp
Enabled
sip
Disabled
pptp Disabled
----------------------------------
If NAT ALG is disabled, run the nat alg command to enable it.
2.10 FAQ About L2TP

This section describes the FAQ about L2TP.
2.10.1 Starting from Which Version Does the device Support NAT
Traversal in L2TP?
Starting from V200R002C00SPC200, the device supports this function.
2.10.2 L2TP Dialup Is Successful After Dozens of Attempts and

Error 691 Is Displayed. Why?
After L2TP is configured on the device, users can dial up successfully after several attempts
and error 691 is displayed during the attempts. The cause is that the device supports only 16-
byte challenge messages. When challenge messages are not of 16 bytes, CHAP authentication
fails and error 691 indicating user name or password error is displayed. Configure L2TP re-
negotiation so that the LNS and client can negotiate the 16-byte challenge messages.
2.10.3 How Can I Quickly Locate Why the LAC Cannot Set Up an
L2TP Tunnel with the LNS?
When configuring the L2TP function, the LAC cannot set up a tunnel with the LNS. How can
I quickly locate the fault?

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. Run the start l2tp command on the LAC to check whether there is a reachable route to
the LNS. If no, configure a reachable route to the LNS.
2. Check the L2TP configuration on the LNS and delete the parameter remote specified in
the allow l2tp command. If an L2TP tunnel can be established successfully, the LAC
cannot set up a tunnel with the LNS because the tunnel name on the LAC is incorrect or
the tunnel name specified by the LNS is incorrect. Use either of the following methods to
solve this problem:
– Run the tunnel name command on the LAC to set the local tunnel name to the
value of the parameter remote specified by the allow l2tp command on the LNS.
– Run the allow l2tp command on the LNS to change the value of the parameter
remote to the tunnel name configured on the LAC. If no local tunnel name is
configured using the tunnel name command on the LAC, the value of the
parameter remote is the device name of the LAC.
2.10.4 How Do I Configure the LNS That Trusts the LAC Not to
Perform Second Authentication on Remote Users?
The LAC authenticates access users. After the users are authenticated, the LAC sends
authentication information to the LNS which determines whether the users are valid users.
If the LAC is trusted by the LNS, you can run the authentication-mode none command in
the authentication scheme view of the LNS to set the authentication mode to non-
authentication. If the command is configured, the LNS does not perform second
2.10.5 What Can I Do If a PC Running the Windows 7 or XP

Operating System Fails to Establish an L2TP over IPSec Tunnel
with the Device?
The possible cause for an L2TP over IPSec tunnel establishment failure between a PC running
the Windows 7 or XP operating system and the device is that the system registry is not
modified.
The following describes how to modify the registry of the Windows 7 operating system so as
not to use digital certificate authentication.
NOTE
The operations in the 64-bit Windows 7 operating system are the same as those in the 32-bit operating
system.
1. Choose Start > cmd and enter regedit to open the registry.
2. Choose HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services
\RasMan\Parameters in the left, right-click a blank area in the right, and choose New >
DWORD (32–bit) Value to generate the New Value #1 file.
3. Right-click New Value #1 and choose Rename to rename the file as ProhibitIpSec.
4. Right-click the ProhibitIpSec file and choose Modify.
5. In the displayed Edit DWORD (32-bit) Value dialog box, set Value data to 1 and select
Hexadecimal under Base, as shown in Figure 2-26.
6. Restart the PC to make the configuration take effect.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 2-26 Registry Editor
2.11 References for L2TP

This section lists references for L2TP.
The following table lists the references for L2TP.
Document Description
RFC 2661 Layer Two Tunneling Protocol (L2TP)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 3 L2TPv3 Configuration
3 L2TPv3 Configuration
About This Chapter
This section describes how to configure L2TPv3 tunnels on IP network to implement

transparent transmission of Layer 2 data over Layer 3 networks.
3.1 Overview of L2TPv3

3.2 Understanding L2TPv3
3.3 Application Scenarios for L2TPv3
3.4 Licensing Requirements and Limitations for L2TPv3
3.5 Configuring L2TPv3
3.6 Monitoring the L2TPv3 Tunnel Running Status
3.7 Configuration Examples for L2TPv3
3.8 References for L2TPv3
3.1 Overview of L2TPv3

Definition
Layer 2 Tunneling Protocol - Version 3 (L2TPv3) sets up Layer 2 access links to transparently
transmit Layer 2 packets, such as Point-to-Point Protocol (PPP), Ethernet, High-Level Data
Link Control (HDLC), and asynchronous transfer mode (ATM) packets, over a packet
switched network (PSN).
NOTE
Currently, L2TPv3 feature of the router can transparently transmit only Ethernet packets, and user-side
interfaces must be VLANIF interfaces, wide area network (WAN) interfaces, or sub-interfaces.
Purpose
Virtual leased lines (VLL) can be deployed to set up Layer 2 connections between the
headquarters and branch or between branches. However, the VLL deployment cost is high.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
L2TPv3 can set up Layer 2 connections between enterprise branches and the headquarters or
between branches, without a need to reconstruct the existing IP networks. Compared with the
VLL solution, L2TPv3 helps carriers lower network construction costs, so that enterprises can
obtain network services at lower expenses.
3.2 Understanding L2TPv3

In Figure 3-1, enterprise branch LANs need to exchange Layer 2 data over the IP network;
therefore, L2TPv3 is configured on the egress gateways.
Figure 3-1 L2TPv3 tunnel
PW
PW interface PW interface
AC interface IP Network AC interface
LCCE1 LCCE2
LAN LAN
L2TPv3 Tunnel
Branch A Branch B
Concepts
l LCCE
An L2TP Control Connection Endpoint (LCCE) is a node at either end of an L2TP
control connection tunnel (L2TPv3 tunnel). An LCCE can be an L2TP access
concentrator (LAC) or an L2TP network server (LNS). The LCCE is an LAC if frames
to be forwarded over the tunnel are processed at the data link layer and is an LNS if the
frames are processed at the network layer.
l PW
A pseudo wire (PW) is a directly connected virtual data channel between two AC
interfaces, used to transparently transmit Layer 2 data. Each L2TPv3 session corresponds
to a PW.
l AC interface
An AC interface is connected to a user-side device, to receive and forward user-side
traffic. In this document, only Layer 3 Ethernet interfaces, including WAN interfaces,
sub-interfaces (not in selective QinQ mode), and VLANIF interfaces can be used as AC
interfaces.
l PW interface
A PW interface is connected to the remote LCCE, to receive and forward L2TPv3
packets from the network side.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Static tunnel
A static tunnel is established by manually configuring local and remote parameters. Data
is directly forwarded over a static tunnel without the packet negotiation process.
Only one tunnel can be established on an interface, and one tunnel supports only one
session. Multiple tunnels can be created at different interfaces of a device.
Working Process
In Figure 3-1, the gateways of enterprise branch A and branch B are LCCE1 and LCCE2
respectively. To establish an L2TPv3 tunnel between LCCE1 and LCCE2, perform the
following operations:
1. Enable L2TPv3 globally on the LCCEs.
2. Create a tunnel interface on each LCCE. Set the tunneling protocol to L2TPv3 and the
working mode to static. Configure the tunnel source address, tunnel destination address,
session ID and other parameters.
NOTE
An L2TPv3 tunnel can be established only when the same parameters are configured on the two ends.
3. Bind an AC interface to the tunnel interface on each LCCE.
4. The AC interface forwards traffic to the remote device through the L2TPv3 tunnel.
L2TPv3 Packet Format

Figure 3-2 shows the L2TPv3 encapsulation format.
Figure 3-2 L2TPv3 packet format
IP Head L2TP Head L2Head payload
L2TPv3 Packet Encapsulation
Figure 3-3 L2TPv3 packet encapsulation
LAN IP Network
LAN
Branch A Branch B
LCCE1 LCCE2
L2TPv3 encapsulation
Layer 2 packet
L2 L2TPv3 L2 L2
payload IP Head payload payload
Head Head Head Head

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
In Figure 3-3, packets sent from branch A to branch B are forwarded as follows:
1. Branch A sends a data packet to branch B.
2. LCCE1 receives the packet and adds VLAN encapsulation to it on the AC interface. The
AC interface then adds an L2TPv3 header to the data packet based on the tunnel
encapsulation table, and forwards the packet through the tunnel interface based on the
routing table.
3. LCCE2 receives the packet and checks whether it is an L2TPv3 packet. If the packet is
an L2TPv3 packet, LCCE2 searches the tunnel decapsulation table and checks whether
the local parameters of the LCCE1 are the same as the remote parameters of the LCCE2.
If they are the same, LCCE2 removes the L2TPv3 header. The AC interface on LCCE2
then processes the packet based on the VLAN encapsulation rule and forwards it to
branch B. If the packet is not an L2TPv3 packet or the local parameters of the sender are
different from the remote parameters of the remote device, LCCE2 discards the packet.
Service Access Modes

When two branches in different VLANs need to communicate, the branch devices send
packets to the L2TPv3 tunnel in either of the following ways:
l Directly forwarding packets: When the AC interface is a WAN interface, that is, it has
been bound to the tunnel using the link-bridge command, the L2TPv3 tunnel can
transparently transmit untagged, single-tagged, or double-tagged Layer 2 packets.
l Terminating one tag: The sub-interface of the AC interface removes the outer tag from
single-tagged or double-tagged packets and adds an L2TPv3 header before sending them
to the L2TPv3 tunnel. The sub-interface adds one tag to packets received from the
L2TPv3 tunnel before forwarding them.
– If the received packets contain one tag, the sub-interface removes the C-Tag.
– If the received packets contain double tags, the sub-interface removes the S-Tag.
l Terminating double tags: The sub-interface of the AC interface removes both S-Tag and
C-Tag from packets and adds an L2TPv3 header before sending them to the L2TPv3
tunnel. The sub-interface adds both S-Tag and C-Tag to packets received from the
L2TPv3 tunnel before forwarding them.
For details about tag termination on sub-interfaces, see VLAN Termination Configuration in
the Huawei AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600
Series Enterprise Routers CLI-based Configuration - Configuration Guide - Ethernet
Switching.
3.3 Application Scenarios for L2TPv3

An enterprise has branches located in different cities. The branches deploy Ethernet networks
and have gateways to allow access to the IP network. To establish Layer 2 connections
between the branches as well as between the headquarters and branches, L2TPv3 can be
enabled on the gateways. The gateways then become L2TP Control Connection Endpoints
(LCCEs) and set up L2TPv3 tunnels to transparently transmit Ethernet packets, lowering
carrier network investment.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
L2TPv3 can be used to set up point-to-point (LAC-LAC) connections, but not point-to-multipoint
connections.
L2TPv3 can be used only when the devices at both end of the tunnel connect to VLANs or use AC interfaces.
Only one VLAN can be configured for an L2TPv3 tunnel.
Figure 3-4 L2TPv3 tunnel setup
IP Network LAN
LAN
LCCE
LCCE
L2TPv3 Tunnel Enterprise A
Enterprise A
branch 1 branch 2
3.4 Licensing Requirements and Limitations for L2TPv3

None
For L2TPv3-capable devices, their licensing requirements for the L2TPv3 function are as
follows:
l AR100&AR120 series: L2TPv3 is a basic feature of the device and is not under license
control.
l AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 series: By default,
this function is disabled on a new device. To use the L2TPv3 function, apply for and
purchase the following license from the Huawei local office.
– AR150&AR160&AR200 series: AR150&160&200 value-added service package
for data services
– AR1200 series: AR1200 value-added service package for data services
Feature Limitations
None

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3.5 Configuring L2TPv3
3.5.1 Configuring a Static L2TPv3 Tunnel

Context
The Layer 2 Ethernet services are transparently transmitted over the L2TPv3 tunnel. This
section describes how to create a static L2TPv3 tunnel between two LCCE devices to transmit
Layer 2 data.
Procedure
Step 1 Enable the L2TPv3 function.
1. Run system-view
2. Run l2tpv3 enable
The L2TPv3 function is enabled.
By default, the L2TPv3 function is disabled.
Step 2 Configure the L2TPv3 tunnel parameters.
1. Run interface tunnel interface-number
A tunnel interface is created and the tunnel interface view is displayed.
2. Run tunnel-protocol svpn
A tunnel protocol on tunnel interface is set to SVPN.
By default, the tunnel protocol is none, indicating that packets are not encapsulated.
3. Run encapsulation l2tpv3 [ static ]
The tunnel type is set to static L2TPv3.
By default, the tunnel type is not specified.
4. Run l2tpv3 local session-id local-session-id
The local session ID is specified.
By default, the local session ID is not specified.
5. Run l2tpv3 remote session-id remote-session-id
The remote session ID is specified.
By default, the remote session ID is not specified.
6. (Optional) Run l2tpv3 local cookie { key cipher local-cookie { length 4 plain lower-
value local-lower-value | length 8 plain lower-value local-lower-value upper-value
local-high-value } }
The local cookie key is configured.
By default, the local cookie key is not configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7. (Optional) Run l2tpv3 remote cookie { key cipher local-cookie { length 4 plain lower-
value local-lower-value | length 8 plain lower-value local-lower-value upper-value
local-high-value } }
The remote cookie key is configured.
By default, the remote cookie key is not configured.
NOTE
The local cookie key must be the same as the remote cookie key. If they are different, traffic cannot be
forwarded.
8. Run tunnel-source { source-ip-address | interface-type interface-number }
A source address or source interface is specified for the tunnel interface.
By default, no source address is specified for the tunnel.
NOTE
The source address of a tunnel is the IP address of the interface that sends packets. The source interface
of a tunnel is the interface that sends packets.
9. Run tunnel-destination [ vpn-instance vpn-instance-name ] dest-ip-address
The destination address is specified for the tunnel.
By default, no destination address is specified for a tunnel.
NOTE
The destination address of a tunnel is the IP address of the interface that receives packets.
10. Run quit
Step 3 Bind an AC interface to a tunnel interface.
1. Run interface interface-type interface-number
The AC interface view is displayed.
2. Run link-bridge interface-type interface-number { tagged | raw }
The AC interface is bound to a tunnel interface.
By default, an AC interface is not bound to a tunnel interface.
3. Run quit
----End
3.5.2 Verifying the L2TPv3 Configuration

Prerequisites
The configurations of an L2TPv3 tunnel are complete.
Procedure
l Run the display interface tunnel [ interface-number | main ] command to view the
running status of the tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display interface brief [ main ] command to view the brief interface status and
configuration information.
----End
3.6 Monitoring the L2TPv3 Tunnel Running Status

Context
To check whether an L2TPv3 tunnel is running properly, view the status of AC and tunnel
interfaces.
After an AC interface is bound to a tunnel interface using the link-bridge command, the
status of the AC and tunnel interfaces are associated. The association between the AC and
tunnel interfaces are as follows:
1. If the physical status of the AC and tunnel interfaces is UP and the protocol status is UP
(Spoofing), the status of the tunnel is UP.
2. If the physical status of the tunnel interface is Standby (^down), the physical status of the
AC interface is down or *down.
Cause: No network cable is installed or the AC interface has been shut down.
3. If the physical status of the AC interface is Standby (^down), the protocol status of a
tunnel is down.
Cause: Parameters of the tunnel are incomplete, the route is not reachable, no license is
uploaded, or the tunnel has been shut down.
NOTE
If parameters are changed, a tunnel is deleted. If the new configuration is correct, a tunnel will be established
again.
Procedure
l Run the display interface tunnel [ interface-number ] command to view the running
status of the tunnel interface.
l Run the display interface brief [ main ] command to view the brief interface status and
configuration information.
----End
3.7 Configuration Examples for L2TPv3
3.7.1 Example for Establishing a Static L2TPv3 Tunnel

In Figure 3-5, enterprise A has two branches that connect to the IP network through LCCE1
and LCCE2 respectively. Branch 1 deploys a local area network (LAN) and uses LCCE1 as
the gateway. Branch 2 deploys a LAN and uses LCCE2 as the gateway.
Branches 1 and 2 need to transparently transmit Layer 2 data through an IP network,
implementing communication between LANs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 3-5 Transmitting packets over the L2TPv3 tunnel after removing one tag
IP
Network
GE0/0/1 GE0/0/1
10.1.1.2 10.1.2.2
L2TPv3 Tunnel
Enterprise A Enterprise A
LCCE1 LCCE2 branch 2
branch 1
GE0/0/2 GE0/0/2
PC1 P
To implement communication between branches 1 and 2 through a Layer 3 network, deploy
an L2TPv3 tunnel between LCCE1 and LCCE2 to transparently transmit Layer 2 data through
an IP network.
1. Configure a route to ensure communication between LCCE1 and LCCE2.
2. Enable the L2TPv3 function globally.
3. Establish tunnel interfaces and configure the L2TPv3 tunnel parameters.
4. Configure a Dot1q sub-interface on the AC interface and connect the Dot1q sub-
interface to the L2TPv3 tunnel.
5. Configure the link bridge function to bind an AC interface to a tunnel interface.
NOTE
Upload a license to enable the L2TPv3 function.
Procedure
Step 1 Configure IP addresses and a static route for the PW interfaces on LCCE1 and LCCE2
respectively.
# Configure an IP address for the PW interface on LCCE1.
[Huawei] sysname LCCE1
[LCCE1] interface gigabitethernet 0/0/1
[LCCE1-GigabitEthernet0/0/1] ip address 10.1.1.2 24
[LCCE1-GigabitEthernet0/0/1] quit
# Configure a static route to LCCE2 on LCCE1. This example assumes that the next hop
address in the route is 10.1.1.3.
[LCCE1]ip route-static 10.1.2.0 255.255.255.0 10.1.1.3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Enable the L2TPv3 function globally.

# Enable the L2TPv3 function on LCCE1.
[LCCE1] l2tpv3 enable

Step 3 Configure L2TPv3 parameters for tunnel interfaces.

# Create a tunnel on LCCE1 and configure parameters for the tunnel.
[LCCE1] interface tunnel 0/0/1
[LCCE1-Tunnel0/0/1] tunnel-protocol svpn
[LCCE1-Tunnel0/0/1] encapsulation l2tpv3 static
[LCCE1-Tunnel0/0/1] l2tpv3 local session-id 1
[LCCE1-Tunnel0/0/1] l2tpv3 remote session-id 4
[LCCE1-Tunnel0/0/1] l2tpv3 local cookie length 4 plain lower-value 11
[LCCE1-Tunnel0/0/1] l2tpv3 remote cookie length 4 plain lower-value 22
[LCCE1-Tunnel0/0/1] tunnel-source 10.1.1.2
[LCCE1-Tunnel0/0/1] tunnel-destination 10.1.2.2
[LCCE1-Tunnel0/0/1] quit

Step 4 Configure a Dot1q sub-interface on the AC interface and connect the Dot1q sub-interface to
the L2TPv3 tunnel.
# Create a sub-interface on LCCE1. Connect the sub-interface to the L2TPv3 tunnel as a
Dot1q sub-interface.
[LCCE1] interface gigabitethernet 0/0/2.1
[LCCE1-GigabitEthernet0/0/2.1] dot1q termination vid 9
# Create a sub-interface on LCCE2. Connect the sub-interface to the L2TPv3 tunnel as a

Dot1q sub-interface.
[LCCE2] interface gigabitethernet 0/0/2.1
[LCCE2-GigabitEthernet0/0/2.1] dot1q termination vid 20
Step 5 Configure the link bridge function.

# Configure the link bridge function on LCCE1 and bind an AC interface to a tunnel interface.
[LCCE1-GigabitEthernet0/0/2.1] link-bridge tunnel0/0/1 tagged

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LCCE2-GigabitEthernet0/0/2.1] link-bridge tunnel0/0/1 tagged

# After the configurations are complete, run the display interface brief command on LCCE1
and LCCE2 to view the brief interface and IP information, including the IP addresses, subnet
mask, physical and protocol status (Up or Down), and the number of interfaces in different
status. The command output on LCCE1 is used as an example.
[LCCE1] display interface brief
PHY: Physical
*down: administratively down
(l): loopback
(s): spoofing
(b): BFD down
^down: standby
(e): ETHOAM down
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Atm8/0/0 down down 0% 0% 0 0
Atm8/0/1 down down 0% 0% 0 0
Atm8/0/2 down down 0% 0% 0 0
Atm8/0/3 down down 0% 0% 0 0
Cellular0/0/0 down down 0% 0% 0 0
Ethernet1/0/0 up up 0% 0% 0 0
Ethernet1/0/1 up down 0.01% 0% 0 0
Ethernet2/0/0 down down 0% 0% 0 0
GigabitEthernet0/0/0 up up 0.01% 0.01% 0 0
GigabitEthernet0/0/1 up up 0.01% 0% 0 0
GigabitEthernet0/0/2.1 up up 0% 0% 0 0
GigabitEthernet0/0/3 up down 0.01% 0% 0 0
GigabitEthernet3/0/0 down down 0% 0% 0 0
MFR0/0/1 down down 0% 0% 0 0
Mp-group0/0/1 down down 0% 0% 0 0
NULL0 up up(s) 0% 0% 0 0
Serial4/0/0 up up 0.05% 0.05% 0 0
Serial6/0/0 down down 0% 0% 0 0
Tunnel0/0/1 up up(s) 0% 0% 0 0
Virtual-Template1 up down 0% 0% 0 0
# Run the display interface tunnel 0/0/1 command on LCCE1 and LCCE2 to view the tunnel
interface status. You can find that the status is Up (spoofing). The command output on
LCCE1 is used as an example.
[LCCE1] display interface tunnel 0/0/1
Tunnel0/0/1 current state : UP
Line protocol current state : UP (spoofing)
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet protocol processing : disabled
Encapsulation is TUNNEL, loopback not set
Tunnel protocol/transport SVPN/IP
Current system time: 2016-02-25 17:10:48
300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0 packets input, 0 bytes

0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : 0%
Output bandwidth utilization : 0%
----End
Configuration Files
l LCCE1 configuration file
#
sysname LCCE1
#
l2tpv3 enable
#
ip address 10.1.1.2 255.255.255.0
#
interface GigabitEthernet0/0/2.1
dot1q termination vid 9
link-bridge Tunnel0/0/1 tagged
#
interface Tunnel0/0/1
tunnel-protocol svpn
encapsulation l2tpv3
l2tpv3 local session-id 1
l2tpv3 remote session-id 4
l2tpv3 local cookie length 4 plain lower-value 11
l2tpv3 remote cookie length 4 plain lower-value 22
tunnel-source 10.1.1.2
tunnel-destination 10.1.2.2
#
ip route-static 10.1.2.0 255.255.255.0 10.1.1.3
#
return

#
sysname LCCE2
#
l2tpv3 enable
#
ip address 10.1.2.2 255.255.255.0
#
#
#
ip route-static 10.1.1.0 255.255.255.0 10.1.2.3
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3.7.2 Example for Configuring L2TPv3 over IPSec to Implement

Secure Communication Between Branches
In Figure 3-6, enterprise A has two branches that connect to the IP network through LCCE1
and LCCE2 respectively. Branch 1 deploys a local area network (LAN) and uses LCCE1 as
the gateway. Branch 2 deploys a LAN and uses LCCE2 as the gateway.
The enterprise wants to protect the services transmitted through the L2TPv3 tunnel against
interception and tampering. To encrypt and protect the services, L2TPv3 over IPSec can be
used.
Figure 3-6 Configuring L2TPv3 over IPSec for secure communication between branches
IP
Network
GE0/0/1 GE0/0/1
10.1.1.2 10.1.2.2
L2TPv3 over IPSec Enterpris

Enterprise A
branch 1 LCCE1 LCCE2 branch
GE0/0/2 GE0/0/2
PC1
1. Configure a route to ensure communication between LCCE1 and LCCE2.
2. Enable the L2TPv3 function globally.
3. Establish a tunnel and configure the L2TPv3 tunnel parameters.
4. Configure the link bridge function to bind an AC interface to a tunnel interface.
5. Configure an ACL to define the data flows to be protected by IPSec.
6. Configure an IPSec proposal and define the traffic protection method.
7. Configure an IKE peer and define the attributes used for IKE negotiation.
8. Configure an IPSec policy, and apply the ACL, IPSec proposal, and IKE peer to the
IPSec policy to define the data flows to be protected and protection method.
9. Apply the IPSec policy group to an interface so that the interface can protect traffic.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure IP addresses and a static route for the PW interfaces on LCCE1 and LCCE2
respectively.

Step 2 Enable the L2TPv3 function globally.


Step 3 Configure L2TPv3 parameters for tunnel interfaces.



Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LCCE1] interface GigabitEthernet 0/0/2
[LCCE1-GigabitEthernet0/0/2] link-bridge tunnel0/0/1 tagged
[LCCE2] interface GigabitEthernet 0/0/2
[LCCE2-GigabitEthernet0/0/2] link-bridge tunnel0/0/1 tagged
Step 5 Configure an ACL to define the data flows to be protected.

NOTE
The tunnel encapsulation protocol is IP (the protocol number is 115). UDP is not supported.
# Configure ACL on LCCE1.

[LCCE1] acl number 3000
[LCCE1-acl-adv-3000] rule permit 115 source 10.1.1.2 0 destination 10.1.2.2 0
[LCCE1-acl-adv-3000] quit
# Configure ACL on LCCE2.

[LCCE2] acl number 3000
[LCCE2-acl-adv-3000] rule permit 115 source 10.1.2.2 0 destination 10.1.1.2 0
[LCCE2-acl-adv-3000] quit
Step 6 Create an IPSec proposal.
# Create an IPSec proposal on LCCE1.

[LCCE1] ipsec proposal rtb
[LCCE1-ipsec-proposal-rtb] esp authentication-algorithm sha2-256
[LCCE1-ipsec-proposal-rtb] esp encryption-algorithm aes-192
[LCCE1-ipsec-proposal-rtb] quit
# Create an IPSec proposal on LCCE2.

[LCCE2] ipsec proposal rta
[LCCE2-ipsec-proposal-rta] esp authentication-algorithm sha2-256
[LCCE2-ipsec-proposal-rta] esp encryption-algorithm aes-192
[LCCE2-ipsec-proposal-rta] quit
Step 7 Configure an IKE peer.
# Configure an IKE proposal on LCCE1.

[LCCE1] ike proposal 1
[LCCE1-ike-proposal-1] encryption-algorithm aes-256
[LCCE1-ike-proposal-1] authentication-algorithm sha2-256
[LCCE1-ike-proposal-1] quit
# Configure an IKE peer on LCCE1 and configure the pre-shared key and the remote ID of
the IKE peer.
[LCCE1] ike peer rtb
[LCCE1-ike-peer-rtb] ike-proposal 1
[LCCE1-ike-peer-rtb] pre-shared-key cipher huawei@123
[LCCE1-ike-peer-rtb] remote-address 10.1.2.2
[LCCE1-ike-peer-rtb] quit
# Configure an IKE proposal on LCCE2.

[LCCE2] ike proposal 1
[LCCE2-ike-proposal-1] encryption-algorithm aes-256
[LCCE2-ike-proposal-1] authentication-algorithm sha2-256
[LCCE2-ike-proposal-1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure an IKE peer on LCCE2 and configure the pre-shared key and the remote ID of
the IKE peer.
[LCCE2] ike peer rta
[LCCE2-ike-peer-rta] ike-proposal 1
[LCCE2-ike-peer-rta] pre-shared-key cipher huawei@123
[LCCE2-ike-peer-rta] remote-address 10.1.1.2
[LCCE2-ike-peer-rta] quit
Step 8 Create an IPSec policy.

# Configure an IPSec policy in IKE negotiation mode on LCCE1.
[LCCE1] ipsec policy rtb 1 isakmp
[LCCE1-ipsec-policy-isakmp-rtb-1] ike-peer rtb
[LCCE1-ipsec-policy-isakmp-rtb-1] proposal rtb
[LCCE1-ipsec-policy-isakmp-rtb-1] security acl 3000
[LCCE1-ipsec-policy-isakmp-rtb-1] quit
# Configure an IPSec policy in IKE negotiation mode on LCCE2.

[LCCE2] ipsec policy rta 1 isakmp
[LCCE2-ipsec-policy-isakmp-rta-1] ike-peer rta
[LCCE2-ipsec-policy-isakmp-rta-1] proposal rta
[LCCE2-ipsec-policy-isakmp-rta-1] security acl 3000
[LCCE2-ipsec-policy-isakmp-rta-1] quit
Step 9 Apply the IPSec policy group to an interface so that the interface can protect traffic.
# Apply the IPSec policy group to the PW interface of LCCE1.
[LCCE1] interface gigabitethernet0/0/1
[LCCE1-GigabitEthernet0/0/1] ipsec policy rtb
# Apply the IPSec policy group to the PW interface of LCCE2.

[LCCE2] interface gigabitethernet0/0/1
[LCCE2-GigabitEthernet0/0/1] ipsec policy rta

After the configurations are complete, PC1 can ping PC2 successfully. The data transmitted
between PC1 and PC2 is encrypted.
# Run the display ipsec sa command on LCCE1 and LCCE2 to view the IPSec configuration.
The command output on LCCE1 is used as an example.
[LCCE1] display ipsec sa
ipsec sa
information:
===============================
Interface:
===============================

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-----------------------------
IPSec policy name:

"rtb"
Sequence number :
1
Acl group :
3000
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
9
Encapsulation mode:
Tunnel
Tunnel local :
10.1.1.2
Tunnel remote :
10.1.2.2
Flow source : 10.1.1.2/255.255.255.255

0/0
Flow destination : 10.1.2.2/255.255.255.255
0/0
[Outbound ESP
SAs]
SPI: 1380002640
(0x52412b50)
Proposal: ESP-ENCRYPT-AES-192 ESP-AUTH-

SHA2-256-128
SA remaining key duration (kilobytes/sec):

1532270/3514
Outpacket count :
2686500
Outpacket encap count :

2686495
Outpacket drop count :

0
Max sent sequence-number:

2686293
UDP encapsulation used for NAT traversal:

N
[Inbound ESP
SAs]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
SPI: 2595661893
(0x9ab6a845)
Proposal: ESP-ENCRYPT-AES-192 ESP-AUTH-

SHA2-256-128
SA remaining key duration (kilobytes/sec):

1490295/3514
Inpacket count :
3068764
Inpacket decap count :

3068761
Inpacket drop count :

0
Max received sequence-number:

3068590

N
Anti-replay :
Enable
Anti-replay window size: 1024
# Run the display interface brief command on LCCE1 and LCCE2 to view the brief
interface and IP information, including the IP addresses, subnet mask, physical and protocol
status (Up or Down), and the number of interfaces in different status. The command output on
[LCCE1] display interface brief
PHY: Physical
*down: administratively down
(l): loopback
(s): spoofing
(b): BFD down
^down: standby
(e): ETHOAM down
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Atm8/0/0 down down 0% 0% 0 0
Atm8/0/1 down down 0% 0% 0 0
Atm8/0/2 down down 0% 0% 0 0
Atm8/0/3 down down 0% 0% 0 0
Ethernet1/0/0 up up 0% 0% 0 0
Ethernet1/0/1 up down 0.01% 0% 0 0
Ethernet2/0/0 down down 0% 0% 0 0
GigabitEthernet0/0/0 up up 0.01% 0.01% 0 0
GigabitEthernet0/0/3 up down 0.01% 0% 0 0
GigabitEthernet3/0/0 down down 0% 0% 0 0
MFR0/0/1 down down 0% 0% 0 0
Mp-group0/0/1 down down 0% 0% 0 0
NULL0 up up(s) 0% 0% 0 0
Serial4/0/0 up up 0.05% 0.05% 0 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Tunnel0/0/1 up up(s) 0% 0% 0 0
Virtual-Template1 up down 0% 0% 0 0
# Run the display interface tunnel 0/0/1 command on LCCE1 and LCCE2 to view the tunnel
interface status. You can find that the status is Up (spoofing). The command output on
[LCCE1] display interface tunnel 0/0/1
Tunnel0/0/1 current state : UP
Line protocol current state : UP (spoofing)
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Internet protocol processing : disabled
Encapsulation is TUNNEL, loopback not set
Tunnel protocol/transport SVPN/IP
0 packets input, 0 bytes
0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : 0%
Output bandwidth utilization : 0%
----End
Configuration Files
#
sysname LCCE1
#
l2tpv3 enable
#
acl number 3000
rule 5 permit 115 source 10.1.1.2 0 destination 10.1.2.2 0
#
ipsec proposal rtb
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-192
#
ike proposal 1
encryption-algorithm aes-256
authentication-algorithm sha2-256
#
ike peer rtb
pre-shared-key cipher %^%#`KJ{)J4dRTcJ2eLBf[3SEp3hQbWrGA;#K()Bw*h1%^%#
ike-proposal 1
remote-address 10.1.2.2
#
ipsec policy rtb 1 isakmp
security acl 3000
ike-peer rtb
proposal rtb
#
ip address 10.1.1.2 255.255.255.0
ipsec policy rtb
#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip route-static 10.1.2.0 255.255.255.0 10.1.1.3
#
return

#
sysname LCCE2
#
l2tpv3 enable
#
acl number 3000
rule 5 permit 115 source 10.1.2.2 0 destination 10.1.1.2 0
#
ipsec proposal rta
#
ike proposal 1
#
ike peer rta
pre-shared-key cipher %^%#`KJ{)J4dRTcJ2eLBf[3SEp3hQbWrGA;#K()Bw*h1%^%#
ike-proposal 1
#
ipsec policy rta 1 isakmp
security acl 3000
ike-peer rta
proposal rta
#
ip address 10.1.2.2 255.255.255.0
ipsec policy rta
#
#
#
ip route-static 10.1.1.0 255.255.255.0 10.1.2.3
#
return
3.8 References for L2TPv3

The following table lists the references for L2TPv3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RFC3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
RFC4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol

Version 3 (L2TPv3)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 4 GRE Configuration
4 GRE Configuration
About This Chapter
Generic Routing Encapsulation (GRE) encapsulates packets of certain network protocols,

such as IP and Asynchronous Transfer Mode (ATM), so that the encapsulated packets can be
transmitted over the IPv4 network.
4.1 Overview of GRE
4.2 Understanding GRE
This section outlines the basic principles used when implementing GRE technology.
4.3 Application Scenarios for GRE
This section describes the application scenarios for GRE.
4.4 Licensing Requirements and Limitations for GRE
This section describes GRE configuration notes.
4.5 Default Settings for GRE
This section provides the default settings for GRE.
4.6 Configuring a GRE Tunnel
This section describes how to configure a GRE tunnel on an IPv4 network.
4.7 Maintaining the GRE Tunnel
This section describes how to collect and view statistics on tunnel interfaces, monitor the
GRE running status, and reset the Keepalive packet statistics on tunnel interfaces.
4.8 Configuration Examples for GRE
This section provides GRE configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.
4.9 Troubleshooting GRE
This section describes common faults caused by incorrect configurations and provides the
troubleshooting procedure.
4.10 FAQ About GRE
This section describes the FAQ about GRE.
4.11 References for GRE
This section lists references for GRE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.1 Overview of GRE

Definition
Generic Routing Encapsulation (GRE) is a protocol that encapsulates packets of some
network layer protocols, such as Internetwork Packet Exchange (IPX), Asynchronous
Transfer Mode (ATM), IPv6, and AppleTalk. Then the encapsulated packets can be
transmitted over a different network layer protocol, such as IPv4.
As Layer 3 tunneling technology, GRE encapsulates packets of a protocol into packets of
another protocol to transparently transmit packets over GRE tunnels. This technology enables
packet transmission on heterogeneous networks.
Benefits
l GRE is easy to implement and increases only a few loads on devices at both ends of a
tunnel.
l GRE sets up tunnels over an IPv4 network to connect networks running different
protocols, using the original network structure and reducing costs.
l GRE enlarges the operation scope of network protocols that support limited hop counts,
allowing for flexible topologies on enterprise networks.
l GRE can encapsulate multicast data and work with IPSec to ensure security of multicast
services such as voice and video services.
l GRE can work with Multiprotocol Label Switching (MPLS) Label Distribution Protocol
(LDP). MPLS LDP packets are transmitted over GRE tunnels to set up LDP label
switched paths (LSPs), so that MPLS backbone networks can be connected through a
heterogeneous network.
l GRE connects discontiguous subnets and sets up virtual private networks (VPNs) to
ensure secure connections between the enterprise headquarters and branches.
4.2 Understanding GRE

This section outlines the basic principles used when implementing GRE technology.
4.2.1 Basic Concepts

Implementation
Packets transmitted over a GRE tunnel undergo encapsulation and decapsulation processes.
As shown in Figure 4-1, if the ingress PE transmits X protocol packets to the egress PE, the
ingress PE encapsulates the packets and the egress PE decapsulates the packets. A GRE
tunnel is a path along which encapsulated packets are transmitted.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-1 Transmitting X protocol packets over a GRE tunnel

Payload Payload
Packet Packet
Delivery GRE Payload
Header Header Packet
X protocol X protocol
network network
IP/MPLS
backbone
network
GRE tunnel
Ingress PE Egress PE
l Encapsulation
a. After receiving an X protocol packet from the interface connected to the X network,
the ingress PE sends the packet to the X protocol.
b. The X protocol checks the destination address in the packet header and searches the
routing table or the forwarding table for the outbound interface. If the outbound
interface is a GRE tunnel interface, the ingress PE adds a GRE header to the packet.
c. The ingress PE adds an IP header to the packet because the backbone network runs
the IP protocol. The source address in the IP header is the tunnel source address and
the destination address in the IP header is the tunnel destination address.
d. The ingress PE searches the IP routing table for the outbound interface based on the
destination address in the IP header (tunnel destination address) and transmits the
packet over the IP backbone network.
For details on the format of the encapsulated packet, see Packet Format.
l Decapsulation
The decapsulation process is opposite to the encapsulation process.
a. After receiving the packet from the GRE tunnel interface, the egress PE analyzes
the IP header in the packet and finds that itself is the destination of the packet. Then
the egress PE removes the IP header and delivers the packet to the GRE protocol for
processing.
b. The GRE protocol removes the GRE header and delivers the packet to the X
protocol.
Packet Format
Figure 4-2 shows the format of a GRE-encapsulated packet.
l Passenger protocol: indicates the protocol of the original packet. The original packet is
encapsulated in a GRE packet as the payload.
l Encapsulation protocol: indicates the protocol used to encapsulate passenger protocol
packets by adding a GRE header. It is also called the carrier protocol.
l Transport protocol (or delivery protocol): indicates the protocol used to transmit the
encapsulated packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-2 GRE packet format

Encapsulation protocol
Transport protocol (carrier protocol) Passenger protocol
Delivery header GRE header Payload packet
Bit: 0 1 2 3 4 7 12 15 31
C 0 K 0 0 Recursion Flags Version Protocol type
Checksum (optional) 0
Key (optional)
Table 4-1 describes the fields in a GRE header.
Table 4-1 Description of fields in a GRE header

Field Description
C Checksum bit.
l 1: The GRE header contains the
Checksum field.
l 0: The GRE header does not contain the
Checksum field.
K Key bit.
l 1: The GRE header contains the Key
field.
l 0: The GRE header does not contain the
Key field.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Field Description
Recursion Number of times a packet is encapsulated

by GRE. The value of this field increases by
1 every time the packet is encapsulated. If
the packet is encapsulated more than three
times, the device discards the packet. This
field prevents a packet from being
encapsulated infinitely.
NOTE
l According to RFC1701, the default value of
this field is 0.
l According to RFC2784, no error will occur if
the field value on the transmit end is different
from that on the receive end, and the receive
end must ignore the field.
l This field is only used to indicate the number
of times a packet is encapsulated. When GRE
decapsulates a packet, this field does not
affect packet processing.
Flags Reserved field. The value must be set to 0.
Version Version number. The value must be set to 0.
Protocol Type Type of the passenger protocol. A common

passenger protocol is the IPv4 protocol,
with the value of 0800.
The protocol code of Ethernet over GRE is
0x6558.
Checksum Checksum of the GRE header and the

payload.
Key Key used to authenticate the packet at the

receive end.
NOTE
Currently, the GRE header does not contain the Source Route field; therefore, bit 1, bit 3, and bit 4 are all set
to 0.
4.2.2 GRE Security Mechanisms

GRE provides two types of security mechanisms:
l Checksum Verification
l Key Authentication
Checksum Verification
Checksum verification is an end-to-end check on encapsulated packets.
If the C bit in the GRE header is set to 1, the checksum is valid. The sender calculates the
checksum based on information in the GRE header and the payload and then sends the packet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
containing the checksum to the receiver. The receiver calculates the checksum based on
information in the received packet and compares the calculated value with the checksum in
the packet. If they are the same, the receiver forwards the packet. If they are different, the
receiver discards the packet.
You can enable or disable checksum verification on both ends of a tunnel in actual
applications. If checksum verification is enabled on the local end and disabled on the remote
end, the local end does not check the checksum values of received packets, but checks the
checksum values of packets to be sent. If checksum verification is disabled on the local end
and enabled on the remote end, the local end checks the checksum values of received packets,
but does not check the checksum values of packets to be sent.
Key Authentication
Key authentication is used to verify the validity of a tunnel interface. This security mechanism
ensures that a device accepts only packets sent from a valid tunnel interface and discards
invalid packets.
According to RFC 1701, if the K bit in the GRE header is set to 1, a four-byte Key field is
inserted into the GRE header. Both the receiver and the sender need to authenticate the key.
The Key field is used to identify the traffic in a tunnel. Packets transmitted over the same
tunnel use the same key. During decapsulation, GRE identifies data packets based on the key.
Packets pass key authentication only when the keys on both ends of the tunnel are consistent.
Otherwise, packets failing the key authentication are discarded. When both ends of a tunnel
have no key or the same key, the key configurations on the two ends are consistent.
4.2.3 Keepalive Detection

GRE does not provide the link status detection function. If the remote interface is
unreachable, the tunnel cannot be immediately torn down. As a result, the source continuously
forwards packets to the remote end which cannot receive the packets, generating a data black
hole.
The Keepalive detection function monitors the tunnel status to check whether the remote end
is reachable. If the remote end is unreachable, the source end tears down the tunnel
immediately. This prevents data loss and data black holes and ensures reliable data
transmission.
The Keepalive detection function is implemented as follows:

1. After the Keepalive detection function is enabled on the source end of a GRE tunnel, the
source end starts a timer to periodically send and count Keepalive probes. The number
increases by 1 every time a Keepalive probe is sent.
2. The remote end sends a reply packet to the source end after receiving a probe.
3. If the source end receives a reply packet before the counter value reaches the preset
value, the source end considers the remote end reachable. If the source end does not
receive any reply packet when the counter reaches the preset value (retry times), the
source end considers the remote end unreachable and tears down the tunnel. In this case,
the source interface still sends Keepalive probes to the remote interface. When the
remote interface becomes Up, the source interface becomes Up too and sets up a tunnel
with the remote interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
The Keepalive detection function takes effect on one end of a tunnel as long as it is configured at that
end, regardless of whether it is configured on the other end. If the remote end receives a Keepalive
probe, it sends a replay packet to the source end, regardless of whether it is configured with the
Keepalive detection function.
4.2.4 Ethernet over GRE

Generic Routing Encapsulation (GRE) provides a mechanism to encapsulate packets of a
protocol into packets of another protocol. This allows packets to be transmitted over
heterogeneous networks. A channel for transmitting heterogeneous packets is called a tunnel.
A GRE tunnel can be established using the following tunnel interfaces:
l GRE tunnel interface
A GRE tunnel interface is a point-to-point virtual interface used to encapsulate packets,
and has the source address, destination address, and tunnel interface IP address.
l mGRE tunnel interface
An mGRE tunnel interface is a point-to-multipoint virtual interface used in Dynamic
Smart VPN (DSVPN) applications, and has the source address, destination address, and
tunnel interface IP address.
The destination IP address of a GRE tunnel interface is manually configured, whereas
the destination IP address of an mGRE tunnel is resolved by the next hop resolution
protocol (NHRP). An mGRE tunnel interface has multiple remote ends because there are
multiple GRE tunnels on the interface.
In Figure 4-3, the enterprise headquarters and branch use Ethernet networks and are
connected by an IP backbone network. Ethernet over GRE can be deployed to transparently
transmit Ethernet packets over a GRE tunnel, enabling communication between the enterprise
headquarters and branch.
Figure 4-3 Ethernet over GRE networking
Ethernet IP GRE Ethernet

frame header header frame
Router_1 R
Branch IP/MPLS
GE1/0/0 GE1/0/0
Ethernet backbone
network GE2/0/0 network
VE0/0/2 GRE tunnel
Tunnel0/0/1 Tunnel0/0/1
VE0/0/1 VE0/0/1
Ethernet over GRE encapsulates Ethernet packets using GRE and transmits the encapsulated
packets over a network running another network layer protocol, such as IPv4. The detailed
working process is as follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. Layer 2 virtual Ethernet (VE) interfaces VE0/0/2 and VE0/0/1 are bound to the LAN-
side physical Ethernet interface GE2/0/0 and WAN-side tunnel interface Tunnel0/0/1 of
the routers, respectively.
2. LAN-side GE2/0/0 on Router_1 receives an Ethernet packet containing a VLAN tag
from the branch network.
3. GE2/0/0 forwards the packet to VE0/0/2. VE0/0/2 processes the VLAN tag, forwards the
packet at Layer 2 based on the MAC address and VLAN tag, and finds the outbound
interface VE0/0/1.
4. VE0/0/1 processes the VLAN tag in the Ethernet packet and forwards it to the bound
Tunnel0/0/1. Tunnel0/0/1 encapsulates the Ethernet packet using GRE (with the protocol
code 0x6558) and forwards the encapsulated packet over a GRE tunnel.
5. Tunnel0/0/1 on Router_2 decapsulates the received packet using GRE, finds that the
protocol code is 0x6558, and forwards the decapsulated Ethernet packet to the inbound
interface VE0/0/1.
6. VE0/0/1 processes the VLAN tag in the packet and forwards it to the outbound interface
VE0/0/2. VE0/0/2 processes the VLAN tag in the packet and sends it to the outbound
interface GE2/0/0.
7. GE2/0/0 sends the Ethernet packet containing a new VLAN tag to the headquarters
network.
4.2.5 Ethernet over mGRE

Generic Routing Encapsulation (GRE) provides a mechanism to encapsulate packets of a
protocol into packets of another protocol. This allows packets to be transmitted over
heterogeneous networks. A channel for transmitting heterogeneous packets is called a tunnel.
A GRE tunnel can be established using the following tunnel interfaces:
l GRE tunnel interface
A GRE tunnel interface is a point-to-point virtual interface used to encapsulate packets,
and has the source address, destination address, and tunnel interface IP address.
l mGRE tunnel interface
An mGRE tunnel interface is a point-to-multipoint virtual interface used in Dynamic
Smart VPN (DSVPN) applications, and has the source address, destination address, and
tunnel interface IP address.
The destination IP address of a GRE tunnel interface is manually configured, whereas
the destination IP address of an mGRE tunnel is resolved by the next hop resolution
protocol (NHRP). An mGRE tunnel interface has multiple remote ends because there are
multiple GRE tunnels on the interface.
In Figure 4-4, the enterprise headquarters (Hub) and branches (Spokes) use Ethernet
networks and are connected by an IP backbone network. Ethernet over mGRE can be
deployed to transparently transmit Ethernet packets over mGRE tunnels, enabling
communication between the Hub and Spokes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-4 Ethernet over mGRE networking

Tunnel0/0/1
GE2/0/0 VE0/0/1
Spoke1 VE0/0/2 mGR
E tun
Ethernet nel
network
Spoke1 GE1/0/0
IP/MPLS GE1/0/0
backbone
Spoke2 network
GE1/0/0 Tunnel0/0/1
Spoke2
Ethernet VE0/0/1
network GE2/0/0 nel
E tun
VE0/0/2 Tunnel0/0/1 mGR
VE0/0/1

Ethernet over mGRE encapsulates Ethernet packets using GRE and transmits the encapsulated
packets over a network running another network layer protocol, such as IPv4. The detailed
working process is as follows:
1. Layer 2 virtual Ethernet (VE) interfaces VE0/0/2 and VE0/0/1 are bound to the LAN-
side physical Ethernet interface GE2/0/0 and WAN-side tunnel interface Tunnel0/0/1 of
the routers, respectively.
2. LAN-side GE2/0/0 on Spoke1 receives an Ethernet packet containing a VLAN tag from
branch network 1.
3. GE2/0/0 forwards the packet to VE0/0/2. VE0/0/2 processes the VLAN tag, forwards the
packet at Layer 2 based on the MAC address and VLAN tag, and finds the outbound
interface VE0/0/1.
4. VE0/0/1 processes the VLAN tag in the Ethernet packet and forwards it to the bound
Tunnel0/0/1. Tunnel0/0/1 encapsulates the Ethernet packet using GRE (with the protocol
code 0x6558) and forwards the encapsulated packet over an mGRE tunnel.
5. Tunnel0/0/1 on Hub decapsulates the received packet using GRE, finds that the protocol
code is 0x6558, and forwards the decapsulated Ethernet packet to the inbound interface
VE0/0/1.
6. VE0/0/1 processes the VLAN tag in the packet and forwards it to the outbound interface
VE0/0/2. VE0/0/2 processes the VLAN tag in the packet and sends it to the outbound
interface GE2/0/0.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7. GE2/0/0 sends the Ethernet packet containing a new VLAN tag to the headquarters
network.
8. The forwarding process of packets from Spoke2 to Hub is the same as that from Spoke1
to Hub.
4.3 Application Scenarios for GRE

This section describes the application scenarios for GRE.
4.3.1 Transmitting Data of Multi-Protocol Local Networks

Through a GRE Tunnel
As shown in Figure 4-5, Term1 and Term2 are the local networks running IPv6. Term3 and
Term4 are local networks running the IP protocol. These subnets, located in different areas,
need to communicate through the public IP network.
Figure 4-5 Transmitting data of multi-protocol local networks through a GRE tunnel
IPv6 IPv6
Term 1 Router_1 Router_2 Term 2
Internet
GRE Tunnel
IP IP
Term 3 Term 4
Router_1 and Router_2 set up a GRE tunnel through which Term1 can communicate with
Term2 without affecting communication between Term3 and Term4.
4.3.2 Enlarging the Operation Scope of a Network with a Hop

Limit
As shown in Figure 4-6, the network runs the IP protocol. Assume that the IP protocol limits
the hop count to 255. If the hop count between two PCs is more than 255, they cannot
communicate with each other. You can set up a GRE tunnel between two devices on the
network to hide the hops between them. This enlarges the network operation scope.
For example, the Routing Information Protocol (RIP) protocol defines that a route is
unreachable when the hop count reaches 16. You can configure a GRE tunnel between two
devices to reduce the hop count of the RIP route passing through the GRE tunnel to less than
16. Then the route is reachable.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-6 Enlarging the network operation scope
IP network
IP network IP network
GRE Tunnel
PC PC
4.3.3 Combining GRE with IPSec to Protect Multicast Data

GRE can encapsulate multicast data and the data in a GRE tunnel. As show in Figure 4-7, for
multicast data that needs to be transmitted over an IPSec tunnel, you can set up a GRE tunnel,
encapsulate multicast data with GRE, encrypt the encapsulated data with IPSec, and then
transmit the data over the IPSec tunnel.
Figure 4-7 Application of the GRE over IPSec tunnel
Internet
Enterprise GRE over IPSec Enterprise

headquarters branch
tunnel
IP multicast flow
4.3.4 Setting Up an L2VPN and an L3VPN Using a GRE Tunnel

NOTE
The AR100&AR120&AR150&AR160&AR200 series routers cannot be used in this scenario.
Usually, a Multiprotocol Label Switching (MPLS) VPN backbone network uses label
switched paths (LSPs) as public network tunnels. If the core devices (P devices) on the
backbone network do not support MPLS but the edge devices (PE devices) support MPLS,
LSPs cannot be used as public network tunnels. In this scenario, a GRE tunnel can be used
instead to provide the Layer 3 virtual private network (L3VPN) or Layer 2 virtual private
network (L2VPN) solution on the backbone network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Label Distribution Protocol (LDP) over GRE enables MPLS LDP packets to be transmitted
over a GRE tunnel. After MPLS LDP is enabled on GRE tunnel interfaces, LDP LSPs can be
set up over the GRE tunnel.
As shown in Figure 4-8, L2VPN or L3VPN services are deployed on PE1 and PE2 to allow
communication between the L2VPN or L3VPN sites of the enterprise. When backbone
network devices have MPLS disabled or do not support MPLS, an LDP LSP over a GRE
tunnel needs to be set up between PE1 and PE2.
Figure 4-8 LDP over GRE application in an enterprise L3VPN or L2VPN solution (MPLS
not supported on the P devices)
L2VPN P1 P2 L2VPN
Site1 CE1 CE2
Site2
Backbone
network
PE1 PE2
GRE Tunnel
L3VPN
L3VPN CE3 CE4 Site2
Site1
LDP LSP for L2VPN

LDP LSP for L3VPN
As shown in Figure 4-9, MPLS is enabled only on P2 but not P1 on the backbone network. A
GRE tunnel can be set up between PE1 and P2, in order to set up an LDP LSP over the GRE
tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-9 LDP over GRE application in an enterprise L3VPN or L2VPN solution (MPLS
supported only on P2)
L2VPN P1 P2 L2VPN
Site1 CE1 CE2
Site2
el
Tunn
E
GR PE2
PE1
Backbone
Network
L3VPN
L3VPN CE3 CE4 Site2
Site1
LDP LSP for L2VPN

LDP LSP for L3VPN
4.3.5 Connecting CE Devices to an MPLS VPN Network

NOTE
The AR100&AR120&AR150&AR160&AR200 cannot work on an MPLS backbone network.
The MPLS VPN solution provides better services than the traditional IP VPN solution.
Therefore, MPLS VPN technology is now carrier's preferred VPN technology. However, the
Internet is IP based and a large number of backbone networks still use IP technology.
In the MPLS VPN solution, a customer edge (CE) device must have a direct physical link to a
provider edge (PE) device on the MPLS backbone network to connect to the VPN. That is, the
CE and PE devices must be on the same network. In this networking, you must associate the
VPN instance with the PE device's physical interface connected to the CE device.
In actual networking, the CE and PE devices may not be directly connected by physical links.
For example, the CE devices of multiple organizations that are connected to the Internet or an
IP-based backbone network may be far away from the PE devices on the MPLS backbone
network; therefore, they cannot be connected directly. These organizations cannot directly
connect to the internal sites of the MPLS VPN through the Internet or the IP backbone
network.
Figure 4-10 Connecting CE devices to an MPLS VPN backbone network through an IP

backbone network
VPN IP IP/MPLS VPN

site network backbone
site
network
CE PE PE CE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
To connect a CE device to an MPLS VPN backbone network, create a logical direct

connection between the CE and PE devices. You can connect the CE and PE devices using a
public or private network, and create a GRE tunnel between the CE and PE devices. Then, the
CE and PE devices can communicate as if they were directly connected, and the GRE tunnel
can be associated with the VPN as a physical interface.
A GRE tunnel can be set up in the following ways to connect CE devices to an MPLS VPN
network:
l GRE tunnel over a private network: The GRE tunnel is associated with a VPN instance,
and the source interface (or the source address) and the destination address of the GRE
tunnel belong to this VPN instance.
l GRE tunnel over a public network: The GRE tunnel is associated with a VPN instance.
However, the source address and destination address of the GRE tunnel are public IP
addresses and do not belong to the VPN instance.
l GRE over a VPN: The GRE tunnel is associated with a VPN instance (such as VPN1),
while the source interface of the GRE tunnel is bound to another VPN instance (such as
VPN2). The GRE tunnel traverses VPN2.
GRE Tunnel over a Public Network

In this networking, the CE and PE devices must have one interface using a public IP address.
The CE and PE devices must have a route to each other in their public network routing tables.
Figure 4-11 GRE tunnel over a public network
Internet IP/MPLS
backbone
network PE2
R1
PE1 CE2
el
nn
Tu
E
R
G
CE1 VPN1
VPN1
GRE Tunnel over a VPN

This networking differs from a GRE tunnel over a public network in that the CE device is
connected to the PE device across a VPN (VPN2 in this example), but not a public network.
Both the outbound interface of the private data from the CE and the outbound interface of the
private data from the PE belong to VPN2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-12 GRE tunnel over a VPN

Class 1 carrier
PE1 IP/MPLS
Class 2 carrier backbone
network
PE2
VPN2 CE2
l
ne
n
Tu
E
R
G
CE1 VPN1
VPN1
In Figure 4-12, PE1 and PE2 are the edge devices of the first carrier on the MPLS backbone
network. VPN2 is a VPN of a second carrier network. CE1 and CE2 are customer devices.
To deploy a VPN (VPN1 in this example) based on the MPLS network, you can set up a GRE
tunnel between PE1 and CE1 across VPN2. Then CE1 and PE1 are directly connected
through the GRE tunnel.
GRE Tunnel over a Private Network

In this networking, the source address and the destination address of the GRE tunnel belong to
the private network. In actual applications, creating a tunnel on a private network serves no
purpose; therefore, this networking is not recommended. As shown in Figure 4-13, R1 can be
used as a CE device so no GRE tunnel is required.
Figure 4-13 GRE tunnel over a private network
PE1
IP/MPLS
GRE Tunnel backbone
network
CE1
VPN1
R1
CE2
VPN1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.3.6 Ethernet over GRE Application

In Figure 4-14, LAN-side interfaces of Router_1 and Router_2 connect to Ethernet networks,
and their WAN-side interfaces connect to an IP backbone network. Ethernet packets need to
be transparently transmitted over a GRE tunnel.
Figure 4-14 Ethernet over GRE application
Branch IP/MPLS Headquarters

Ethernet backbone Ethernet
network network network
Router_1 Router_2
GRE tunnel
Ethernet over GRE can be configured on Router_1 and Router_2 and Layer 2 VE interfaces
are bound to the physical Ethernet interface and tunnel interface to transparently transmit
Ethernet packets over a GRE tunnel.
4.3.7 Ethernet over mGRE Application

In Figure 4-15, the enterprise headquarters (Hub) and branches (Spokes) use Ethernet
networks and are connected by an IP backbone network. Ethernet packets between the Hub
and Spokes need to be transparently transmitted over mGRE tunnels.
Figure 4-15 Ethernet over mGRE application
Spoke1 mGR
Spoke1 E tun
nel
Ethernet
network
IP/MPLS
Hub Ethernet
backbone
network
network
Spoke2 Hub
Ethernet l
network Et unne
Spoke2 mGR
Ethernet over mGRE can be configured on Spoke1, Spoke2, and Hub and Layer 2 VE
interfaces are bound to the physical Ethernet interfaces and tunnel interfaces to transparently
transmit Ethernet packets over mGRE tunnels.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.4 Licensing Requirements and Limitations for GRE

This section describes GRE configuration notes.

None
GRE is a basic feature of the device and is not under license control.
Feature Limitations
None
4.5 Default Settings for GRE

This section provides the default settings for GRE.
Table 4-2 Default settings for GRE
Keepalive detection Disabled
GRE checksum Disabled
GRE key Disabled
4.6 Configuring a GRE Tunnel

This section describes how to configure a GRE tunnel on an IPv4 network.
Pre-configuration Tasks
Before configuring a GRE tunnel, complete the following task:
l Configuring a reachable route between the source and destination interfaces according to
IP Unicast Routing Configuration Guide
Configuration Procedure
Perform the following operations in sequence to configure a GRE tunnel. You can determine
whether to perform optional operations based on site requirements.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Protocol Task
Network layer protocol, 4.6.1 Configuring a Tunnel Interface

such as IPX, ATM, IPv6, 4.6.2 Configuring a Route on a Tunnel Interface
and AppleTalk
4.6.4 (Optional) Configuring a Security Mechanism for
GRE
4.6.5 (Optional) Enabling the Keepalive Detection
Function for GRE
FR, HDLC, or PPP protocol 4.6.1 Configuring a Tunnel Interface

4.6.3 (Optional) Configuring the Link Bridge Function
GRE
Function for GRE
Ethernet protocol 4.6.1 Configuring a Tunnel Interface

4.6.2 Configuring a Route on a Tunnel Interface
or 4.6.6 (Optional) Configuring Ethernet over GRE
GRE
Function for GRE
4.6.1 Configuring a Tunnel Interface

Context
A GRE tunnel is established between two tunnel interfaces; therefore, you need to configure
tunnel interfaces on devices at both ends of a tunnel. Set the protocol type to GRE, specify the
tunnel source address (or interface) and tunnel destination address, and specify IP addresses
for tunnel interfaces.
l Source IP address of the tunnel: Indicates the source IP address defined in the packet
transmission protocol. When the configured value is an IP address, the value is directly
used as the source IP address. When the configured value is a source interface, the IP
address of the interface is used as the source IP address.
l Destination IP address of the tunnel: Indicates the destination IP address defined in the
packet transmission protocol.
l IP address of the tunnel interface: Indicates an IP address assigned to the tunnel
interface. A dynamic or static routing protocol uses this IP address to advertise the tunnel
interface. The IP address of the tunnel interface may be a public network address or not.
It can also be an IP address borrowed from another interface to save IP addresses.
However, if the IP address of the tunnel interface is borrowed from another interface,
tunnel interface communication cannot be implemented using this IP address. Therefore,
to achieve tunnel reachability if the IP address is borrowed, you must configure a static
route or a routing protocol to implement reachability of the IP address.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run interface tunnel interface-number
Step 3 Run tunnel-protocol gre
The protocol type of the tunnel interface is set to GRE.
Step 4 (Optional) Run gre key { plain key-number | [ cipher ] plain-cipher-text }
The key number of a GRE tunnel.
NOTE
Normally, only one GRE tunnel can be established over a physical link that has only one source address and
one destination address. To solve this problem, GRE keys are introduced to identify tunnel interfaces with the
same source address and same destination address. This implementation allows multiple GRE tunnels to be
established over a physical link that has only one source address and one destination address to carry different
types of services.
If you want to configure the same source and destination addresses for multiple GRE tunnels, configure the
gre key command first. Otherwise, the configuration fails.
Step 5 Run source { source-ip-address | interface-type interface-number }

A source address or source interface is specified for the tunnel.
NOTE
When configuring the source interface of a tunnel, note the following:

l Do not specify the tunnel interface of a GRE tunnel as its own source interface. You can specify the
tunnel interface of another tunnel as the source interface.
l You can configure the virtual address of a VRRP group as the source address of a tunnel.
l Do not configure a bridge-if interface as the source interface of a tunnel.
Step 6 Run destination [ vpn-instance vpn-instance-name ] dest-ip-address

A destination address is specified for the tunnel.
If a customer edge (CE) is connected to a provider edge (PE) through the GRE tunnel, specify
a virtual private network (VPN) instance to add the tunnel interface to a private network
routing table when configuring the destination address for the tunnel.
Step 7 (Optional) Run tunnel route-via interface-type interface-number { mandatory | preferred }
The routing outbound interface for the GRE tunnel is specified.
By default, a GRE tunnel does not have a routing outbound interface.
GRE packets are forwarded based on routing tables. If there are multiple equal-cost routes to
the destination address, GRE packets are shared among these routes. In some situations, the
actual routing outbound interface of GRE packets transmitted over a GRE tunnel may be the
routing outbound interface for another GRE tunnel. If Unicast Reverse Path Forwarding
(URPF) is enabled on the next hop device, this device checks the source addresses of these
GRE packets to identify their outbound interface and then determines whether the outbound
interface for these packets are the same as the actual interface that receives these packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After the device finds that the outbound interface for these packets is different from the actual
interface that receives these packets, the device drops these packets. To solve this problem,
run the tunnel route-via command to specify the routing outbound interface for each GRE
tunnel.
If you configure mandatory when running the tunnel route-via command, traffic is strictly
forwarded through the specified routing outbound interface. Specifically, if the available
routing outbound interfaces for GRE packets transmitted over a GRE tunnel do not include
the routing outbound interface specified for the tunnel, packets cannot be forwarded. If you
configure preferred when running the tunnel route-via command, traffic is preferentially
forwarded through the specified routing outbound interface. Specifically, if the available
routing outbound interfaces for GRE packets transmitted over a GRE tunnel do not include
the routing outbound interface specified for the tunnel, packets can still be forwarded through
available routing outbound interfaces.
Step 8 (Optional) Run mtu mtu
A maximum transmission unit (MTU) is configured for the tunnel interface.
By default, the MTU of a tunnel interface is 1500 bytes.
NOTE
To change the MTU of a tunnel interface, run the shutdown command and then the undo shutdown
command on the interface to make the new MTU effective.
Step 9 (Optional) Run description text
An interface description is provided.
By default, the following description is provided for the tunnel interface: HUAWEI, AR
Series, Tunnel interface-number Interface.
For example, the description of Tunnel0/0/1 is "HUAWEI, AR Series, Tunnel0/0/1

Interface."
Step 10 Run either of the following commands to specify an IP address for the tunnel interface.
l Specify an IP address.
– Specify an IPv4 address for the tunnel interface when IPv4 networks communicate
using the GRE tunnel.
Run ip address ip-address { mask | mask-length } [ sub ]
An IPv4 address is specified for the tunnel interface.
– Specify an IPv6 address for the tunnel interface when IPv6 networks communicate
using the GRE tunnel.
Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
An IPv6 address is specified for the tunnel interface.
NOTE
Before specifying an IPv6 address for an interface, run the ipv6 command in the system
view to enable IPv6 packet forwarding and run the ipv6 enable command on the interface to
enable the IPv6 function.
l Borrow an IP address.
Run ip address unnumbered interface interface-type interface-number
The tunnel interface is configured to borrow an IP address.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
A tunnel interface cannot borrow an IPv6 address.
----End
4.6.2 Configuring a Route on a Tunnel Interface

Context
GRE-encapsulated packets can be correctly forwarded only when a local and a remote device
on the backbone network has a reachable route to each other and the route passes through the
tunnel interfaces on the devices. The route can be a static route or a dynamic route.
NOTE
As shown in Figure 4-16, the X network runs the protocol frame relay (FR), High-Level Data Link
Control (HDLC), or Point-to-Point Protocol (PPP). If packets from the X network need to be
transparently transmitted over an IP network, the route configured on a tunnel interface does not take
effect. In this case, you need to perform steps in 4.6.3 (Optional) Configuring the Link Bridge
Function.
Router_1 in Figure 4-16 is used as an example to illustrate the configuration notes.

l When configuring a static route, configure a route on both the local and the remote
devices. Set the destination address of a static route to the original destination address of
original packets (address of GE2/0/0 on Router_2), and set the outbound interface to the
tunnel interface on the local device (Tunnel0/0/1 on Router_1).
l When configuring a dynamic routing protocol, configure the protocol on both the tunnel
interface and the interface connected to the network running the X protocol.
For example, as shown in Figure 4-16, you must configure the dynamic routing protocol
on the tunnel interface and GE2/0/0 connected to the network running the X protocol,
and set the outbound interface to GE2/0/0 on Router_2 in the routing table to
Tunnel0/0/1.
In practice, you must configure different types of routing protocols or different processes
of the same type of routing protocol to advertise routes for the tunnel interface and the
backbone network. This ensures that user packets are forwarded by a physical interface
rather than the tunnel interface.
NOTE
When a dynamic routing protocol is configured and the route import function is enabled on the tunnel
interface, use a dynamic route or a 32-bit host route to implement interworking with the destination
address. This ensures that the route to the destination address is not advertised to the tunnel interface,
preventing tunnel flapping.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-16 Networking for configuring a dynamic routing protocol for GRE
IP/MPLS
backbone
network
GE1/0/0 GE1/0/0
Router_1 GRE Tunnel Router_2

GE2/0/0 Tunnel0/0/1 Tunnel0/0/2
GE2/0/0
X protocol
X protocol
network
network
Term 2
Term 1
Procedure
Step 2 Choose either of the following methods to configure a route passing through a tunnel
interface:
l Run ip route-static ip-address { mask | mask-length } { nexthop-address | tunnel
interface-number [ nexthop-address ] } [ description text ]
A static route is configured.
l Configure a dynamic routing protocol. Dynamic routing can be implemented using
Interior Gateway Protocol (IGP) or Exterior Gateway Protocol (EGP), such as Open
Shortest Path First (OSPF) and Routing Information Protocol (RIP). For details on how
to configure a dynamic routing protocol, see Huawei
Enterprise Routers Configuration Guide - IP Routing.
When IPv6 networks communicate with each other over the GRE tunnel, you must configure
an IPv6 routing protocol on the tunnel interface and the physical interface connected to the
network running IPv6.
----End
Context
Customers want to use GRE to transparently transmit FR, HDLC, PPP, or Ethernet packets
over networks of a different network layer protocol, such as the IPv4 network. To transmit
FR, HDLC, PPP, or Ethernet packets over a GRE tunnel, they need to configure the link
bridge function to bind a serial, an Ethernet, a GE, an XGE, or a VLANIF interface with a

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
tunnel interface, so that packets received from the serial, Ethernet, GE, XGE, or VLANIF
interface can be directly sent out from the tunnel interface bound to it.
Procedure
Step 2 Run link-bridge tag-id interface interface-type interface-number out-interface interface-
type interface-number [ untagged | tagged vlan-id ]
The link-bridge command binds an inbound interface to an outbound interface, so that packets
received from the specified inbound interface can only be sent through the specified outbound
interface.
By default, the link bridge function is not configured.
When configuring the link bridge function, pay attention to the following points:
l After you configure the link bridge function, the protocol status of the inbound interface
turns Down and network-layer configurations on the inbound interface do not take effect.
The inbound interface only functions as a bridge.
l After you configure this command, the protocol status of the inbound interface which is
a serial interface turns Down and network-layer configurations on the inbound interface
do not take effect. The inbound interface only functions as a bridge.
l After link bridge is bound to an interface, the interface does not support QoS.The
inbound interface to which link bridge is bound supports traffic policy, traffic policing,
traffic statistics collection, and mapping between 802.1p and DSCP priorities.
l Two link bridges must be configured with different tag IDs. The tag ID of a link bridge
must be globally unique. If the tag ID of two link bridges is the same, an error message is
displayed.
l Only one link bridge can be configured on a physical interface. If two link bridges are
configured on the same physical interface, an error message is displayed.
l Only one link bridge can be configured on a tunnel interface. If two link bridges are
configured on the same tunnel interface, an error message is displayed.
l If you specify the untagged mode, Ethernet packets transmitted over a GRE tunnel do
not contain VLAN tags; otherwise, packets contain VLAN tags. You can determine
whether to configure the untagged mode based on your actual networking to ensure
normal traffic transmission over a tunnel. The following table describes the packet
transmission rules.
Interface Traffic Flow Default With Tag Without Tag
Type Processing (Untagged)
on Ethernet
Packet
Layer 2 From an The interface The interface If the packet

Ethernet Ethernet transparently adds an outer contains a tag,
interface interface to a transmits the tag to the the interface
tunnel packet. packet before removes the
interface sending the tag before
packet. sending the
packet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

on Ethernet
Packet
From a tunnel The interface If the tag The interface

interface to an transparently differs from transparently
Ethernet transmits the the specified transmits the
interface packet. one, the packet.
interface
discards the
packet.
Otherwise, the
interface
removes the
outer tag
before sending
the packet.
Layer 3 From an The interface The interface If the packet

Ethernet Ethernet transparently adds an outer contains a tag,
interface interface to a transmits the tag to the the interface
packet. sending the
packet.
From a tunnel The interface If the tag The interface

interface to an transparently differs from transparently
Ethernet transmits the the specified transmits the
interface packet. one, the packet.
interface
discards the
packet.
Otherwise, the
interface
removes the
outer tag
before sending
the packet.
VLANIF From a If the VLAN The interface If the packet

interface VLANIF ID in the adds an outer contains a tag,
interface to a packet is the tag to the the interface
tunnel same as the packet before removes the
interface PVID, the sending the tag before
interface packet. sending the
removes the packet.
tag; otherwise,
the interface
transparently
transmits the
packet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

on Ethernet
Packet
From a tunnel The device If the tag The interface

interface to a checks differs from adds the
VLANIF whether the the specified VLAN ID of
interface VLAN ID in one, the the VLANIF
the packet is interface interface to the
the same as discards the packet before
that of the packet. sending the
VLANIF Otherwise, the packet.
interface. If so, interface
the interface removes the
sends the outer tag
packet; before sending
otherwise, the the packet.
interface
discards the
packet.
Ethernet sub- From an The interface The interface If the packet

interface Ethernet sub- transparently adds an outer contains a tag,
interface to a transmits the tag to the the interface
packet. sending the
packet.
From a tunnel The device If the tag The interface

interface to an checks differs from adds the
Ethernet sub- whether the the specified VLAN ID of
interface VLAN ID in one, the the Dot1q or
the packet is interface QinQ sub-
the same as discards the interface to the
that of the packet. packet before
Dot1q or QinQ Otherwise, the sending the
sub-interface. interface packet.
If so, the removes the
interface sends outer tag
the packet; before sending
otherwise, the the packet.
interface
discards the
packet.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.6.4 (Optional) Configuring a Security Mechanism for GRE
Context
You can configure the end-to-end check or a key for both ends of a GRE tunnel to improve
the GRE tunnel security. This mechanism prevents devices from incorrectly identifying and
receiving invalid packets.
Procedure
The tunnel interface view is displayed.
Step 3 Run gre checksum
The checksum verification function is enabled for the GRE tunnel.
By default, the end-to-end checksum verification function is disabled on a tunnel.
Step 4 Run gre key { plain key-number | [ cipher ] plain-cipher-text }
A key is configured for the GRE tunnel.
Specify the same value for the parameter key number on tunnel interfaces on both ends of the
GRE tunnel, or configure no key number for either end of the tunnel.
By default, no key is configured for the GRE tunnel.
NOTE
If plain is selected, the key is saved in the configuration file in plain text. This brings security risks. It is
recommended that you select cipher to save the key in cipher text.
The commands in Step 3 and Step 4 are independent of each other.
----End
4.6.5 (Optional) Enabling the Keepalive Detection Function for

GRE
Context
After the Keepalive detection function is enabled, the local device periodically sends
Keepalive probes to the peer to check tunnel connectivity. If the peer is reachable, the local
device receives a reply packet from the peer. Otherwise, the local device cannot receive a
reply packet, and then disconnects the tunnel connection.
The Keepalive detection function takes effect on one end of the tunnel as long as this end is
configured with the Keepalive detection function. The other end of the tunnel is not required
to have the Keepalive detection function configured. To ensure that both ends of the tunnel
can detect whether the peer is reachable, you are advised to enable the Keepalive detection
function on both ends.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Run keepalive [ period period [ retry-times retry-times ] ]
The Keepalive detection function is enabled for GRE.
By default, the Keepalive detection function of GRE is disabled.
----End
4.6.6 (Optional) Configuring Ethernet over GRE
Context
Customers want to use GRE to transparently transmit Ethernet packets over networks of a
different network layer protocol, such as the IPv4 network. Ethernet over GRE can be
configured to transparently transmit Ethernet packets over a GRE tunnel. After you bind
Layer 2 virtual Ethernet (VE) interfaces to the LAN-side physical Ethernet interface and
WAN-side tunnel interface of a device, Ethernet packets received from the LAN-side interface
are forwarded by the VE interfaces to the WAN-side tunnel interface. The WAN-side tunnel
interface encapsulates the packets using GRE and transparently transmits the packets over a
GRE tunnel.
Procedure
l Configuring a LAN-side physical Ethernet interface
a. Run system-view
b. Run interface virtual-ethernet ve-number
A VE interface is created and the VE interface view is displayed.
c. Run portswitch
The VE interface is changed from Layer 3 mode to Layer 2 mode.
By default, a VE interface works in Layer 3 mode.
d. Perform the following configurations on a Layer 2 VE interface:
n VLAN configuration: Configuring VLAN Assignment
n QinQ configuration: Configuring Basic QinQ, Configuring Selective QinQ,
and Configuring the TPID Value in an Outer VLAN Tag
n VLAN mapping configuration: Configuring VLAN ID-based VLAN Mapping
e. Run quit
f. Run interface interface-type interface-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The Ethernet interface view is displayed.

g. Run map interface virtual-ethernet ve-number
The Layer 2 VE interface is bound to the physical Ethernet interface.
By default, no Layer 2 VE interface is bound to a physical Ethernet interface.

l Configuring a WAN-side tunnel interface
a. Run system-view

b. (Optional) Run gre map virtual-ethernet forward-broadcast disable
A VE interface from forwarding broadcast, multicast, and unknown unicast packets

to devices is disabled in the same VLAN .
By default, a VE interface can forward broadcast, multicast, and unknown unicast

packets to devices in the same VLAN.
If branch CPE fails to obtain the MAC address of the HQ CPE, it will send
broadcast, multicast, and unknown unicast packets to the VE interface bound to the
tunnel interface of the HQ CPE. The VE interface then forwards the packets to
other CPEs in the same VLAN. This consumes large network bandwidth, increases
the workload of the HQ CPE, and may lead to drop of normal packets. To prevent
this problem, you can configure the gre map virtual-ethernet forward-broadcast
disable command on the HQ CPE to disable the VE interface from forwarding
broadcast, multicast, and unknown unicast packets to other CPEs in the same
VLAN.
c. Run interface virtual-ethernet ve-number

d. Run portswitch

e. Perform the following configurations on a Layer 2 VE interface:
f. Run quit

g. Run interface tunnel interface-number

h. Run map interface virtual-ethernet ve-number
The Layer 2 VE interface is bound to the tunnel interface.
By default, no Layer 2 VE interface is bound to a tunnel interface.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.6.7 (Optional) Configuring Ethernet over mGRE

Context
When the Hub and Spokes on a DSVPN network need to transparently transmit Ethernet
packets, Ethernet over mGRE can be configured. After you bind Layer 2 virtual Ethernet
(VE) interfaces to the LAN-side physical Ethernet interface and WAN-side tunnel interface of
a device, Ethernet packets received from the LAN-side interface are forwarded by the VE
interfaces to the WAN-side tunnel interface. The WAN-side tunnel interface encapsulates the
packets using GRE and transparently transmits the packets over mGRE tunnels.
Perform the following configurations on the Hub and Spokes.
Procedure
l Configuring a LAN-side physical Ethernet interface
a. Run system-view
b. Run interface virtual-ethernet ve-number
c. Run portswitch
d. Perform the following configurations on a Layer 2 VE interface:
e. Run quit
f. Run interface interface-type interface-number
g. Run map interface virtual-ethernet ve-number
The Layer 2 VE interface is bound to the physical Ethernet interface.
By default, no Layer 2 VE interface is bound to a physical Ethernet interface.
l Configuring a WAN-side tunnel interface
a. Run system-view
b. (Optional) Run gre map virtual-ethernet forward-broadcast disable
A VE interface from forwarding broadcast, multicast, and unknown unicast packets
to devices is disabled in the same VLAN .
By default, a VE interface can forward broadcast, multicast, and unknown unicast
packets to devices in the same VLAN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
If branch CPE fails to obtain the MAC address of the HQ CPE, it will send
broadcast, multicast, and unknown unicast packets to the VE interface bound to the
tunnel interface of the HQ CPE. The VE interface then forwards the packets to
other CPEs in the same VLAN. This consumes large network bandwidth, increases
the workload of the HQ CPE, and may lead to drop of normal packets. To prevent
this problem, you can configure the gre map virtual-ethernet forward-broadcast
disable command on the HQ CPE to disable the VE interface from forwarding
broadcast, multicast, and unknown unicast packets to other CPEs in the same
VLAN.
c. Run interface virtual-ethernet ve-number

d. Run portswitch

e. Perform the following configurations on a Layer 2 VE interface:
f. Run quit

g. Run interface tunnel interface-number

h. Run map interface virtual-ethernet ve-number
The Layer 2 VE interface is bound to the tunnel interface.
By default, no Layer 2 VE interface is bound to a tunnel interface.
----End
4.6.8 (Optional) Configuring the DF Flag Bit for GRE Packets
Context
The length of GRE-encapsulated packets may exceed the maximum transmission unit (MTU)
of the outbound interface on the local device. If the remote device on a GRE tunnel does not
support fragmentation and reassembly, it cannot decapsulate packets and will discard or
invalidly process packets, affecting packet transmission.
To prevent packet loss, you can set the DF flag bit for GRE packets to clear to allow
fragmentation of GRE packets. After the DF flag bit is set to clear, the local device pre-
calculates the packet length. If the packet length after GRE encapsulation exceeds the MTU,
the local device fragments the GRE packets and encapsulates each fragment. After packets
reach the GRE remote device, the remote device can decapsulate the fragments without
having to reassemble them. The decapsulated packets will be forwarded normally.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run gre df-bit { clear | set | copy }
The DF flag bit is set for GRE packets.
By default, the DF flag bit for GRE packets uses the clear mode.
----End
4.6.9 (Optional) Binding a GRE Tunnel to a BFD Session

You can bind a GRE tunnel to a BFD session so that BFD can monitor the link status.
Context
The configuration of binding a GRE tunnel to a BFD session provides a detection mechanism
for the GRE tunnel by using BFD to monitor the link status. If the BFD session goes Down,
the GRE tunnel also goes Down.
NOTE
V300R003C10 and later versions support this function.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface tunnel interface-number
Step 3 Run:
gre track bfd-session session-name bfd-session-name
The GRE tunnel is bound to a BFD session.
NOTE
Before running this command, ensure that a BFD session is created.
----End
4.6.10 Verifying the GRE Tunnel Configuration
Prerequisites
The configurations of a GRE tunnel are complete.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Run the display interface tunnel [ interface-number ] command to view the status of
the tunnel interface.
l Run the display tunnel-info { tunnel-id tunnel-id | all | statistics [ slots ] } command to
view tunnel information.
l Run the display ip routing-table command to view the IPv4 routing table to check
whether the outbound interface for a route to the specified destination address is a tunnel
interface.
l Run the display ipv6 routing-table command to view the IPv6 routing table to check
interface.
l Run the ping -a source-ip-address host command to check whether the local tunnel
interface can ping the remote tunnel interface successfully.
l After Keepalive detection is enabled, run the display keepalive packets count command
in the tunnel interface view to view the number of Keepalive probes and Keepalive reply
packets on the tunnel interface.
----End
4.7 Maintaining the GRE Tunnel

This section describes how to collect and view statistics on tunnel interfaces, monitor the
GRE running status, and reset the Keepalive packet statistics on tunnel interfaces.
4.7.1 Collecting and Viewing Statistics on Tunnel Interfaces
Context
To check the network status or locate network faults, you can enable traffic statistics
collection on tunnel interfaces and collect traffic statistics on the tunnel interfaces.
Procedure
Step 3 Run statistic enable { inbound | outbound }
The traffic statistics collection is enabled on a Tunnel interface.
By default, traffic statistics collection is disabled on a Tunnel interface.
Step 4 Run display interface tunnel
The traffic statistics on tunnel interfaces is displayed.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Follow-up Procedure
Run the reset counters interface tunnel [ interface-number ] command in the user view to
reset statistics on a tunnel interface to avoid interference of the original statistics.
After you reset the statistics on a specified tunnel interface, statistics information about the
number of sent and received packets and the packet transmission rate are cleared. Exercise
caution when you run this command.
4.7.2 Monitoring the GRE Running Status
Context
In routine maintenance, you can run the following commands in any view to check the GRE
running status, whether GRE tunnel interfaces are Up, whether error packets exist, and
whether packets are properly forwarded to the destination address through the tunnel
interface.
Procedure
l Run the display interface tunnel command to view the running status of the tunnel
interface.
l Run the display ip routing-table command to view the IPv4 routing table to check
interface.
l Run the display ipv6 routing-table command to view the IPv6 routing table to check
interface.
l Run the display ip routing-table vpn-instance vpn-instance command to check VPN
routing information on the tunnel interface.
When a tunnel interface is bound to a VPN instance, specify a VPN instance to check the
VPN routing information.
----End
4.7.3 Resetting the Keepalive Packet Statistics on a Tunnel

Interface
Context
When you need to calculate and analyze statistics on a tunnel interface, reset the statistics to
avoid interference of the original statistics.
After you reset the Keepalive packet statistics on a specified tunnel interface, statistics on the
number of Keepalive probes and Keepalive reply packets are cleared.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The cleared Keepalive packet statistics cannot be restored. Exercise caution when you run the
command.
Procedure
Step 3 Run reset keepalive packets count
The Keepalive packet statistics on the tunnel interface is reset.
----End
4.8 Configuration Examples for GRE

This section provides GRE configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.
4.8.1 Example for Configuring a Static Route for GRE to

Implement Interworking Between IPv4 Networks
As shown in Figure 4-17, RouterA, RouterB, and RouterC run OSPF to implement
interworking over the public network. PC1 and PC2 run the IPv4 proprietary protocol and
communicate with each other over the public network.
PC1 and PC2 use RouterA and RouterC as their default gateways respectively.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-17 Configuring a static route for GRE
Internet
RouterB
GE1/0/0 GE2/0/0
20.1.1.2/24 30.1.1.1/24
RouterA GE1/0/0 GE1/0/0 RouterC

20.1.1.1/24 30.1.1.2/24
GRE Tunnel
GE2/0/0 Tunnel0/0/1 Tunnel0/0/1 GE2/0/0
10.1.1.2/24 10.3.1.1/24 10.3.1.2/24 10.2.1.2/24
PC1 PC2
10.1.1.1/24 10.2.1.1/24
To allow PC1 to communicate with PC2, you can configure a direct link between RouterA
and RouterC to set up a GRE tunnel and configure a static route to forward packets through
tunnel interfaces to the peer.
1. Run OSPF on the devices to implement interworking among them.
2. Create tunnel interfaces on RouterA and RouterC to set up a GRE tunnel, and configure
a static route passing through tunnel interfaces on RouterA and RouterC, so that traffic
between PC1 and PC2 can be transmitted over the GRE tunnel.
Procedure
Step 1 Configure an IP address for each physical interface.
# Configure RouterA.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure RouterB.
[RouterB] interface gigabitethernet 1/0/0
# Configure RouterC.
[Huawei] sysname RouterC
[RouterC] interface gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] ip address 30.1.1.2 255.255.255.0
[RouterC-GigabitEthernet1/0/0] quit
Step 2 Configure OSPF on the devices.

[RouterA] ospf 1
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
[RouterC] ospf 1
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
# After the configuration is complete, run the display ip routing-table command on RouterA
and RouterC. The command output shows that they have learned the OSPF route destined for
the network segment of the peer.
# The command output on RouterA is used as an example.
[RouterA] display ip routing-table protocol ospf
<keyword conref="../commonterms/commonterms.xml#commonterms/route-flags"></
keyword>
------------------------------------------------------------------------------
Public routing table :

OSPF
Destinations : 1 Routes :
1
OSPF routing table status :

<Active>

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Destination/Mask Proto Pre Cost Flags NextHop

Interface
30.1.1.0/24 OSPF 10 2 D 20.1.1.2

OSPF routing table status :

<Inactive>
0
Step 3 Configure a tunnel interface.
[RouterA] interface tunnel 0/0/1
[RouterA-Tunnel0/0/1] tunnel-protocol gre
[RouterA-Tunnel0/0/1] ip address 10.3.1.1 255.255.255.0
[RouterA-Tunnel0/0/1] source 20.1.1.1
[RouterA-Tunnel0/0/1] destination 30.1.1.2
[RouterA-Tunnel0/0/1] quit
[RouterC] interface tunnel 0/0/1
[RouterC-Tunnel0/0/1] tunnel-protocol gre
[RouterC-Tunnel0/0/1] ip address 10.3.1.2 255.255.255.0
[RouterC-Tunnel0/0/1] source 30.1.1.2
[RouterC-Tunnel0/0/1] destination 20.1.1.1
[RouterC-Tunnel0/0/1] quit
# After the configuration is complete, the tunnel interfaces turn Up and can ping each other.
This indicates that a direct tunnel has been set up.

[RouterA] ping -a 10.3.1.1 10.3.1.2
PING 10.3.1.2: 56 data bytes, press CTRL_C to break
Reply from 10.3.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms
--- 10.3.1.2 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
Step 4 Configure a static route.
[RouterA] ip route-static 10.2.1.0 255.255.255.0 tunnel 0/0/1
[RouterC] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
and RouterC. The command output shows the static route from the tunnel interface to the
user-side network segment.
[RouterA] display ip routing-table 10.2.1.0
keyword>
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.2.1.0/24 Static 60 0 D 10.3.1.2 Tunnel0/0/1
PC1 and PC2 can ping each other.
----End
Configuration Files
#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
destination 30.1.1.2
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#
ip route-static 10.2.1.0 255.255.255.0 Tunnel0/0/1
#
return

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
l Configuration file of RouterC

#
sysname RouterC

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 30.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
#
return
4.8.2 Example for Configuring OSPF for GRE to Implement

Interworking Between IPv4 Networks
As shown in Figure 4-18, RouterA, RouterB, and RouterC run OSPF to implement
interworking over the public network. PC1 and PC2 run the IPv4 proprietary protocol and
communicate with each other over the public network. Transmission of private data must be
reliable.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-18 Configuring a dynamic routing protocol for GRE
OSPF 1
Internet
RouterB
GE1/0/0 GE2/0/0
20.1.1.2/24 30.1.1.1/24
GE1/0/0 GE1/0/0
20.1.1.1/24 30.1.1.2/24
RouterA GRE Tunnel RouterC

10.1.1.2/24 10.3.1.1/24 10.3.1.2/24 10.2.1.2/24
OSPF 2 OSPF 2
PC1 PC2
10.1.1.1/24 10.2.1.1/24
You can set up a directly connected GRE tunnel between RouterA and RouterC and configure
OSPF on tunnel interfaces and interfaces connected to the private networks to allow PC1 to
communicate with PC2. To monitor the tunnel link status, enable Keepalive detection on
tunnel interfaces on both ends of the GRE tunnel.
1. Configure an IGP (OSPF process 1 in this example) to implement interworking among
the devices.
2. Set up a GRE tunnel between devices connected to the PCs, enable Keepalive detection,
and run an IGP (OSPF process 2 in this example) on the network segments connected to
the PCs to transmit traffic between PC1 and PC2 over the GRE tunnel.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Configure OSPF on the devices.

[RouterA] ospf 1
[RouterB] ospf 1
[RouterC] ospf 1
and RouterC. The command output shows that they have learned the OSPF route destined for
keyword>
------------------------------------------------------------------------------
Public routing table : OSPF
Destinations : 1 Routes : 1
OSPF routing table status : <Active>


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
30.1.1.0/24 OSPF 10 2 D 20.1.1.2

OSPF routing table status : <Inactive>


[RouterA-Tunnel0/0/1] keepalive
[RouterC-Tunnel0/0/1] keepalive
[RouterA] ping -a 10.3.1.1 10.3.1.2

0.00% packet loss
# Run the display keepalive packets count command to check the statistics on Keepalive
packets.
[RouterA-Tunnel0/0/1] display keepalive packets count
Send 10 keepalive packets to peers, Receive 10 keepalive response packets from
peers
Receive 8 keepalive packets from peers, Send 8 keepalive response packets to
peers.
Step 4 Configure OSPF on tunnel interfaces.

[RouterA] ospf 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC] ospf 2

and RouterC. The routing table of each router contains the OSPF route from the tunnel
interface to the user-side network segment of the peer. In addition, the next hop of the route to
the destination physical interface (30.1.1.0/24) of the tunnel is not a tunnel interface.
keyword>
------------------------------------------------------------------------------

10.2.1.0/24 OSPF 10 1563 D 10.3.1.2 Tunnel0/0/1

30.1.1.0/24 OSPF 10 2 D 20.1.1.2

# PC1 and PC2 can ping each other.
----End
Configuration Files
#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
keepalive
source 20.1.1.1
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ospf 2
area 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return

#
sysname RouterC
#
ip address 30.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
keepalive
source 30.1.1.2
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
ospf 2
area 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
4.8.3 Example for Configuring a GRE Tunnel to Implement

Interworking Between IPv6 Networks
As shown in Figure 4-19, RouterA and RouterC on IPv6 networks connect to RouterB on an
IPv4 network. PC1 and PC2 on the two IPv6 networks need to communicate with each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-19 Configuring a GRE tunnel to implement interworking between IPv6 networks
Internet
RouterB
GE1/0/0 GE2/0/0
20.1.1.2/24 30.1.1.1/24
RouterA GE1/0/0 GE1/0/0 RouterC

20.1.1.1/24 30.1.1.2/24
GRE Tunnel

FC01::1/64 FC11::1/64 FC11::2/64 FC21::1/64
PC1 PC2
FC01::2/64 FC21::2/64
To allow PC1 and PC2 on the IPv6 networks to communicate with each other, you can
configure a direct link between RouterA and RouterC to set up a GRE tunnel and configure a
static route to forward packets through tunnel interfaces to the peer.
1. Configure IP addresses for physical interfaces and configure an IPv4 static route to
implement interworking over the IPv4 network.
2. Create tunnel interfaces on RouterA and RouterC to set up a GRE tunnel, and configure
an IPv6 static route passing through tunnel interfaces on RouterA and RouterC, so that
traffic between PC1 and PC2 can be transmitted over the GRE tunnel.
Procedure
[RouterA] ipv6

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterA-GigabitEthernet2/0/0] ipv6 enable
[RouterA-GigabitEthernet2/0/0] ipv6 address FC01::1 64
[RouterC] ipv6
[RouterC-GigabitEthernet2/0/0] ipv6 enable
[RouterC-GigabitEthernet2/0/0] ipv6 address FC21::1 64
Step 2 Configure an IPv4 static route.

[RouterA] ip route-static 30.1.1.2 255.255.255.0 20.1.1.2
[RouterC] ip route-static 20.1.1.1 255.255.255.0 30.1.1.1

[RouterA-Tunnel0/0/1] ipv6 enable
[RouterA-Tunnel0/0/1] ipv6 address FC11::1 64
[RouterC-Tunnel0/0/1] ipv6 enable
[RouterC-Tunnel0/0/1] ipv6 address FC11::2 64
Step 4 Configure a static tunnel route.

[RouterA] ipv6 route-static FC21::1 64 tunnel 0/0/1
[RouterC] ipv6 route-static FC01::1 64 tunnel 0/0/1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Ping the IPv4 address of RouterA from RouerC. RouterC can receive a Reply packet from
RouterA.
[RouterC] ping 20.1.1.1

0.00% packet loss
# Ping the IPv6 address of RouterA from RouerC. RouterC can receive a Reply packet from
RouterA.
[RouterC] ping ipv6 FC01::1
PING FC01::1 : 56 data bytes, press CTRL_C to break
Reply from FC01::1
bytes=56 Sequence=1 hop limit=64 time = 28 ms
Reply from FC01::1
Reply from FC01::1
Reply from FC01::1
Reply from FC01::1
--- FC01::1 ping statistics ---

0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ip address 20.1.1.1 255.255.255.0
#
ipv6 enable
ipv6 address FC01::1/64
#
ipv6 enable
tunnel-protocol gre
source 20.1.1.1
#
ip route-static 30.1.1.0 255.255.255.0 20.1.1.2
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipv6 route-static FC21:: 64 Tunnel0/0/1

#
return

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
return

#
sysname RouterC
#
ipv6
#
ip address 30.1.1.2 255.255.255.0
#
ipv6 enable
#
ipv6 enable
tunnel-protocol gre
source 30.1.1.2
#
ip route-static 20.1.1.0 255.255.255.0 30.1.1.1
#
ipv6 route-static FC01:: 64 Tunnel0/0/1

#
return
4.8.4 Example for Enlarging the Operation Scope of a Network

with a Hop Limit
As shown in Figure 4-20, RouterA, RouterB, RouterC, and RouterD run RIP to implement
interworking. Data sent from RouterA to RouterD must pass through only one hop. That is,
the route cost is 1. RIP is deployed without changing the network topology. There are two
hops between RouterA and RouterD. To reduce a hop, you need to set up a GRE tunnel
between RouterA and RouterC. Although the logical hop count is 1, there are two devices on
the path from RouterA to RouterD. Therefore, the hop count allowed on a RIP network is
increased.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-20 Enlarging the operation scope of a network with a hop limit
RouterB RouterC
GE2/0/0 GE1/0/0
30.1.1.1/24 30.1.1.2/24
GE1/0/0 GE2/0/0
20.1.1.2/24 RIP1 40.1.1.1/24
.2 /1
.1 /0
4
.1 el0
/2
50 nn
l
ne
Tu
n
Tu
E
R
G
RIP2
GE1/0/0 .1 /1
.1 /0 GE1/0/0
20.1.1.1/24 4 40.1.1.2/24
.1 el0
/2
50 unn
T
RouterA RouterD
1. Run RIP process 1 on RouterA, RouterB, and RouterC to implement interworking
among them.
2. Set up a GRE tunnel between RouterA and RouterC to hide RouterB.
3. Run RIP process 2 on RouterA, RouterC, and RouterD to forward packets over the GRE
tunnel. The actual hop counts allowed on a RIP network is increased.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure RouterD.
[Huawei] sysname RouterD
[RouterD] interface gigabitethernet 1/0/0
[RouterD-GigabitEthernet1/0/0] ip address 40.1.1.2 255.255.255.0
[RouterD-GigabitEthernet1/0/0] quit
Step 2 Run RIP process 1 on devices.
[RouterA] rip 1
[RouterA-rip-1] version 2
[RouterA-rip-1] network 20.0.0.0
[RouterA-rip-1] quit
[RouterB] rip 1
[RouterB-rip-1] version 2
[RouterB-rip-1] network 20.0.0.0
[RouterB-rip-1] network 30.0.0.0
[RouterB-rip-1] quit
[RouterC] rip 1
[RouterC-rip-1] version 2
[RouterC-rip-1] network 30.0.0.0
[RouterC-rip-1] quit
and RouterC. The command output shows that they have learned the RIP route destined for

[RouterA] display ip routing-table
keyword>
------------------------------------------------------------------------------
Routing Tables: Public
20.1.1.0/24 Direct 0 0 D 20.1.1.1

20.1.1.1/32 Direct 0 0 D 127.0.0.1
20.1.1.255/32 Direct 0 0 D 127.0.0.1
30.1.1.0/24 RIP 100 1 D 20.1.1.2
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA] ping -a 50.1.1.1 50.1.1.2

0.00% packet loss
Step 4 Run RIP process 2 on tunnel interfaces.

[RouterA] rip 2
[RouterA-rip-2] version 2
[RouterA-rip-2] network 50.0.0.0
[RouterA-rip-2] quit
[RouterC] rip 2
[RouterC-rip-2] version 2
[RouterC-rip-2] quit
# Configure RouterD.
[RouterD] rip 2
[RouterD-rip-2] version 2
[RouterD-rip-2] network 40.0.0.0
[RouterD-rip-2] quit

and RouterD. The command output shows that the cost of the route to the destination address
of the peer device is 1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
keyword>
------------------------------------------------------------------------------
20.1.1.0/24 Direct 0 0 D 20.1.1.1

20.1.1.1/32 Direct 0 0 D 127.0.0.1
20.1.1.255/32 Direct 0 0 D 127.0.0.1
30.1.1.0/24 RIP 100 1 D 20.1.1.2
40.1.1.0/24 RIP 100 1 D 50.1.1.2 Tunnel0/0/1
50.1.1.0/24 Direct 0 0 D 50.1.1.1 Tunnel0/0/1
50.1.1.1/32 Direct 0 0 D 127.0.0.1 Tunnel0/0/1
50.1.1.255/32 Direct 0 0 D 127.0.0.1 Tunnel0/0/1
----End
Configuration Files
#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 50.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
#
rip 1
version 2
network 20.0.0.0
#
rip 2
version 2
network 50.0.0.0
#
return

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
rip 1
version 2
network 20.0.0.0
network 30.0.0.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
sysname RouterC
#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
#
ip address 50.1.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
#
rip 1
version 2
network 30.0.0.0
#
rip 2
version 2
network 40.0.0.0
network 50.0.0.0
#
return
l Configuration file of RouterD

#
sysname RouterD
#
ip address 40.1.1.2 255.255.255.0
#
rip 2
version 2
network 40.0.0.0
#
return
4.8.5 Example for Configuring BGP/MPLS IP VPN to Use a GRE

Tunnel
NOTE
The AR100&AR120&AR150&AR160&AR200 cannot be used in this scenario.
In Figure 4-21:
l Branch 1 connects to the VPN backbone network through CE1 and PE1.
On the backbone network, PEs provide MPLS functions, and the P does not provide MPLS
functions.
The enterprise wants to establish a GRE tunnel between the PEs and use IP to forward VPN
packets over the IP network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-21 Networking diagram for configuring BGP/MPLS IP VPN to use a GRE tunnel
AS:100
GE1/0/0 GE2/0/0
172.1.1.2/24 172.2.1.1/24
P
Loopback1 Loopback1
10.10.1.1/32 10.10.2.1/32
GE2/0/0 GE2/0/0
172.1.1.1/24 172.2.1.2/24
PE1 PE2
GRE Tunnel
10.1.1.2/24 10.3.1.1/24 10.3.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE1 CE2
vpn1 vpn1
AS: 65410 AS: 65420
1. Configure OSPF between the PEs and P to implement IP connectivity on the backbone
network.
2. Create a GRE tunnel between PEs so that VPN packets can be transmitted over the GRE
tunnel.
3. Configure VPN instances on PEs and bind each PE interface connected to a CE to a VPN
instance.
4. Because the P device does not support MPLS functions, an LSP cannot be used to
transmit VPN packets. Configure a tunnel policy on the PEs to specify that VPN packets
are transmitted over a GRE tunnel, and apply the tunnel policy.
5. Establish EBGP peer relationships between PEs and CEs to exchange routes so that a CE
can learn routes from the peer CE and CE1 can communicate with CE2.
Procedure
Step 1 Configure an IP address for each interface.
# Configure CE1.
[Huawei] sysname CE1
[CE1] interface gigabitethernet 1/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24

[CE1-GigabitEthernet1/0/0] quit
# Configure IP addresses for interfaces on PE1 except the interface to be bound to a VPN
instance. This is because all configurations on this interface are deleted when the interface is
bound to a VPN instance.
[Huawei] sysname PE1
[PE1] interface gigabitethernet 2/0/0
[PE1-GigabitEthernet2/0/0] ip address 172.1.1.1 24
[PE1-GigabitEthernet2/0/0] quit
[PE1] interface loopback 1
[PE1-LoopBack1] ip address 10.10.1.1 32
[PE1-LoopBack1] quit
# Configure the P device.

[Huawei] sysname P
[P] interface gigabitethernet 1/0/0
[P-GigabitEthernet1/0/0] ip address 172.1.1.2 24
[P-GigabitEthernet1/0/0] quit
# Configure CE2.
Step 2 Configure IGP on the MPLS backbone network to implement interworking between PEs.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 10.10.1.1 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit

[P] ospf 1
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] ospf 1
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configurations are complete, OSPF neighbor relationships can be set up between
PE1, P, and PE2. Run the display ospf peer command. You can see that the neighbor status is
Full. Run the display ip routing-table command. You can see that PEs have learnt the routes
to Loopback1 of each other.
Step 3 Configure a GRE tunnel.
# Configure PE1.
[PE1] interface tunnel 0/0/1
[PE1-Tunnel0/0/1] tunnel-protocol gre
[PE1-Tunnel0/0/1] source loopback 1
[PE1-Tunnel0/0/1] destination 10.10.2.1
[PE1-Tunnel0/0/1] ip address 10.3.1.1 24
[PE1-Tunnel0/0/1] quit
# Configure PE2.
Step 4 Enable basic MPLS functions on the PEs.

# Configure PE1.
[PE1] mpls lsr-id 10.10.1.1
[PE1] mpls
[PE1-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
Step 5 Configure VPN instances on PEs and bind each interface that connects a PE to a CE to a VPN
instance. Apply tunnel policies on the PEs to specify the GRE tunnel used to forward VPN
packets.
# Configure PE1.
[PE1] tunnel-policy gre1
[PE1-tunnel-policy-gre1] tunnel select-seq gre load-balance-number 1
[PE1-tunnel-policy-gre1] quit
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] ipv4-family
[PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 100:1 both
[PE1-vpn-instance-vpn1-af-ipv4] tnl-policy gre1
[PE1-vpn-instance-vpn1-af-ipv4] quit
[PE1-vpn-instance-vpn1] quit
[PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

After the configurations are complete, run the display ip vpn-instance verbose command on
PEs to view the configurations of VPN instances. Each PE can ping its local CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP address by setting -a
source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address dest-ip-address
command to ping a remote CE. If the source IP address is not specified, the ping operation fails.
Step 6 Set up EBGP peer relationships between the PEs and CEs and import VPN routes to EBGP.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] quit
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65420
[CE2-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
After the configurations are complete, run the display bgp vpnv4 vpn-instance peer
command on PEs. You can see that BGP peer relationships have been established between
PEs and CEs and are in Established state.
The command output on PE1 is used as an example.
[PE1] display bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 10.10.1.1

Local AS number : 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN-Instance vpn1, Router ID 10.10.1.1:

Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
10.1.1.1 4 65410 6 3 0 00:01:14

Established 3
Step 7 Set up an MP-IBGP peer relationship between PEs.

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 10.10.2.1 as-number 100
[PE1-bgp] peer 10.10.2.1 connect-interface loopback 1
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 10.10.2.1 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
After the configurations are complete, run the display bgp vpnv4 all peer command on a PE.
The command output shows that the BGP peer relationships have been established between
the PEs and are in the Established state.
[PE1] display bgp vpnv4 all peer


PrefRcv
10.10.2.1 4 100 4 7 0 00:02:54

Established 0
Peer of IPv4-family for vpn instance :

10.1.1.1 4 65410 122 119 0 01:57:43
Established 3

# After the configuration is complete, CEs can learn routes to each other. CEs can
successfully ping each other.
# The command output on CE1 is used as an example.
[CE1] display ip routing-table 10.2.1.0
Route Flags: R - relay, D - download to fib, T -
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1] ping 10.2.1.1


0.00% packet loss
----End
Configuration Files
l Configuration file of CE1
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
peer 10.1.1.2 as-number 100
#
ipv4-family unicast
undo synchronization
import-route direct
peer 10.1.1.2 enable
#
return
l Configuration file of PE1

#
sysname PE1
#
ip vpn-instance vpn1
ipv4-family
route-distinguisher 100:1
tnl-policy gre1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
mpls lsr-id 10.10.1.1
mpls
#
ip binding vpn-instance vpn1
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.10.1.1 255.255.255.255
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
source LoopBack1
#
tunnel-policy gre1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
tunnel select-seq gre load-balance-number 1

#
bgp 100
peer 10.10.2.1 connect-interface LoopBack1
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
ipv4-family vpn-instance vpn1
import-route direct
#
ospf 1
area 0.0.0.0
network 10.10.1.1 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l Configuration file of the P device
#
sysname P
#
ip address 172.1.1.2 255.255.255.0
#
ip address 172.2.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
tnl-policy gre1
#
mpls
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 10.10.2.1 255.255.255.255
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
source LoopBack1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
tunnel-policy gre1
#
bgp 100
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
#
ospf 1
area 0.0.0.0
network 10.10.2.1 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
4.8.6 Example for Configuring VLL to Use a GRE Tunnel
NOTE
AR100&AR120&AR150&AR160&AR200 cannot be used in this scenario.
An ISP network provides the L2VPN service for users. Many users connect to the MPLS
network through PE1 and PE2, and users on the PEs change frequently. A proper VPN
solution is required to provide secure VPN services for users and to simplify configuration
when new users connect to the network.
A Martini VLL connection can be set up between CE1 and CE2 to meet these requirements.
By default, the system uses Label Switched Paths (LSPs) for Martini VLL, and does not
perform load balancing. When the P does not provide MPLS functions, VLL cannot be
implemented.
To solve the problem, apply a tunnel policy to Martini VLL to specify that VLL services are
transmitted over a GRE tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-22 Networking diagram for configuring VLL to use a GRE tunnel
P
GE2/0/0 GE1/0/0
172.1.1.2/24 172.2.1.2/24
Loopback1 Loopback1
10.10.1.1/32 10.10.2.1/32
GE2/0/0 GE1/0/0
172.1.1.1/24 172.2.1.1/24
PE1 GRE Tunnel PE2

10.2.1.1/24 10.2.1.2/24
CE1 CE2
10.1.1.1/24 10.1.1.2/24
1. Configure a routing protocol on the PE and P devices on the backbone network to ensure
reachability between them.
2. Enable MPLS and MPLS LDP on PEs. Set up a remote LDP session between the PEs to
exchange VC labels between the PEs.
3. Enable MPLS L2VPN on PEs. Enabling MPLS L2VPN is the prerequisite for VLL
configuration.
4. Create GRE tunnel interfaces on PEs and establish a GRE tunnel between PEs.
5. Create VC connections on PEs. Because the P does not support MPLS functions,
configure a tunnel policy and apply it when you create VC connections so that VLL
services can be transmitted over a GRE tunnel.
Procedure
Step 1 Configure interface IP addresses and a routing protocol on the PEs and P.
# Configure PE1. The configurations of PE2 and P are similar to the configuration of PE1,
and are not mentioned here.
[PE1-GigabitEthernet2/0/0] ip address 172.1.1.1 255.255.255.0
[PE1-LoopBack1] ip address 10.10.1.1 255.255.255.255
[PE1] ospf 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
Step 2 Configure basic MPLS functions and LDP on PEs and establish a remote LDP session
between PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] mpls ldp remote-peer 10.10.2.1
[PE1-mpls-ldp-remote-10.10.2.1] remote-ip 10.10.2.1
[PE1-mpls-ldp-remote-10.10.2.1] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configurations are complete, run the display mpls ldp session command on PE1 to
view the LDP session status. You can see that an LDP session is set up between PE1 and PE2.
The display on PE1 is used as an example.
[PE1] display mpls ldp session
LDP Session(s) in Public Network

Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------------
PeerID Status LAM SsnRole SsnAge KASent/Rcv
------------------------------------------------------------------------------
10.10.2.1:0 Operational DU Passive 0000:00:01 1/1
------------------------------------------------------------------------------
TOTAL: 1 session(s) Found.
Step 3 Enable MPLS L2VPN on PEs.

# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
Step 4 Create GRE tunnel interfaces on PEs and establish a GRE tunnel between PEs.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-Tunnel0/0/1] ip address 10.2.1.1 255.255.255.0
[PE1-Tunnel0/0/1] source 10.10.1.1
# Configure PE2.
After the configurations are complete, the tunnel interfaces go Up and can ping each other.
[PE1] ping -a 10.2.1.1 10.2.1.2

0.00% packet loss
Step 5 Configure a tunnel policy, create VC connections, and apply the policy to the VC connections
so that VLL services can be transmitted over a GRE tunnel.
# Configure PE1.
[PE1-GigabitEthernet1/0/0] mpls l2vc 10.10.2.1 39 tunnel-policy gre1
# Configure PE2.

# After the configurations are complete, check the L2VPN connection on PEs. You can see
that an L2VC connection has been set up and is in Up state.
# The display on PE1 is used as an example.
[PE1] display mpls l2vc interface gigabitethernet 1/0/0
*client interface : GigabitEthernet1/0/0 is up
Administrator PW : no
session state : up
AC status : up
Ignore AC state : disable
VC state : up
Label state : 0
Token state : 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VC ID : 39
VC type : Ethernet
destination : 10.10.2.1
local group ID : 0 remote group ID : 0
local VC label : 1025 remote VC label : 1024
local AC OAM State : up
local PSN OAM State : up
local forwarding state : forwarding
local status code : 0x0
remote AC OAM state : up
remote PSN OAM state : up
remote forwarding state: forwarding
remote status code : 0x0
ignore standby state : no
BFD for PW : unavailable
VCCV State : up
manual fault : not set
active state : active
forwarding entry : exist
link state : up
local VC MTU : 1500 remote VC MTU : 1500
local VCCV : alert ttl lsp-ping bfd
remote VCCV : alert ttl lsp-ping bfd
local control word : disable remote control word : disable
tunnel policy name : gre1
PW template name : --
primary or secondary : primary
load balance type : flow
Access-port : false
Switchover Flag : false
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : gre , TNL ID : 0x2
Backup TNL type : lsp , TNL ID : 0x0
create time : 0 days, 2 hours, 37 minutes, 1 seconds
up time : 0 days, 0 hours, 2 minutes, 11 seconds
last change time : 0 days, 0 hours, 2 minutes, 11 seconds
VC last up time : 2013/02/20 18:58:24
VC total up time : 0 days, 2 hours, 35 minutes, 58 seconds
CKey : 2
NKey : 1
PW redundancy mode : frr
AdminPw interface : --
AdminPw link state : --
Diffserv Mode : uniform
Service Class : --
Color : --
DomainId : --
Domain Name : --
# Run the display tunnel-info tunnel-id command on PEs according to the tunnel ID in the
preceding command output. You can view details of the specified tunnel ID.
[PE1] display tunnel-info tunnel-id 2
Tunnel ID: 0x2
Tunnel Token: 2
Type: gre
Destination: 10.10.2.1
Out Slot: 0
Instance ID: 0
Interface: Tunnel0/0/1
# CE1 and CE2 can ping each other successfully.

# The display on CE1 is used as an example.
[CE1] ping 10.1.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls
#
mpls l2vpn
#
mpls ldp
#
mpls ldp remote-peer 10.10.2.1
remote-ip 10.10.2.1
#
mpls l2vc 10.10.2.1 39 tunnel-policy gre1
#
ip address 172.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.10.1.1 255.255.255.255
#
ip address 10.2.1.1 255.255.255.0
tunnel-protocol gre
source 10.10.1.1
#
ospf 1
area 0.0.0.0
network 10.10.1.1 0.0.0.0
network 172.1.1.0 0.0.0.255
#
tunnel-policy gre1
#
return
l Configuration file of P
#
sysname P
#
ip address 172.1.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 172.2.1.2 255.255.255.0

#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return

#
sysname PE2
#
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 10.10.1.1
#
ip address 172.2.1.1 255.255.255.0
#
#
interface LoopBack1
ip address 10.10.2.1 255.255.255.255
#
ip address 10.2.1.2 255.255.255.0
tunnel-protocol gre
source 10.10.2.1
#
ospf 1
area 0.0.0.0
network 10.10.2.1 0.0.0.0
network 172.2.1.0 0.0.0.255
#
tunnel-policy gre1
#
return

#
sysname CE2
#
ip address 10.1.1.2 255.255.255.0
#
return
4.8.7 Example for Connecting a CE to a VPN Through a GRE

Tunnel over a Public Network
In Figure 4-23:
l PE1 and PE2 reside on the MPLS backbone network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l R1 connects CE1 and PE1 over the public network.

l CE2 is directly connected to PE2.
l CE1 and CE2 reside on the same VPN and are reachable to each other.
PE1 is indirectly connected to CE1. Therefore, no VPN instance can be bound to the physical
interface of PE1. A GRE tunnel is set up between CE1 and PE1 and this tunnel traverses the
public network. On PE1, bind the GRE tunnel to a VPN to connect CE1 to the VPN using the
GRE tunnel.
NOTE
Figure 4-23 Connecting a CE to a VPN through a GRE tunnel over a public network
IP/MPLS
Loopback1 backbone Loopback1
1.1.1.9/32 network 3.3.3.9/32
GE1/0/0
Internet 50.1.1.2/24
R1 GE2/0/0 PE2
110.1.1.1/24
GE1/0/0 GE2/0/0 GE1/0/0
30.1.1.2/24 50.1.1.1/24 110.1.1.2/24 GE2/0/0
PE1
GE2/0/0 el
Tunn 11.1.1.2/24
30.1.1.1/24 GRE GE1/0/0
CE1 Tunnel0/0/1 Tunnel0/0/1 11.1.1.1/24
2.2.2.1/24 2.2.2.2/24
CE2
GE1/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
vpn1 vpn1
1. Run OSPF process 10 on PE1 and PE2 to implement interworking between them, and
enable MPLS.
2. Run OSPF process 20 on CE1, R1, and PE1 to implement interworking among them.
3. Set up a GRE tunnel between CE1 and PE1.
4. Create vpn1 on PE1 and PE2. On PE1, bind vpn1 to the GRE tunnel interface. On PE2,
bind vpn1 to the physical interface connected to CE2.
5. Configure IS-IS on CE1 and PE1 to calculate routes between CE2 and PE2 and their
connected PEs.
6. Run BGP on the PEs to implement interworking between CE1 and CE2.
Procedure
# Configure CE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure R1.
[Huawei] sysname R1
[R1] interface gigabitethernet 1/0/0
[R1-GigabitEthernet1/0/0] ip address 30.1.1.2 24
[R1-GigabitEthernet1/0/0] quit
[R1] interface gigabitethernet 2/0/0
[R1-GigabitEthernet2/0/0] ip address 50.1.1.1 24
[R1-GigabitEthernet2/0/0] quit
# Configure PE1.
instance, because all configurations on this interface are deleted when the interface is bound
to a VPN instance.
# Configure CE2.
Step 2 Configure routes between the PEs and enable MPLS.

# On PE1, enable MPLS LDP, and run OSPF process 10 to configure reachable routes
between the PEs. LSPs are set up automatically.
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] ospf 10
[PE1-ospf-10] area 0
[PE1-ospf-10] quit
[PE1-GigabitEthernet2/0/0] mpls
[PE1-GigabitEthernet2/0/0] mpls ldp
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] ospf 10
[PE2-ospf-10] quit
Step 3 Create a VPN instance vpn1 on PE1 and bind vpn1 to the GRE tunnel.
[PE1-vpn-instance-vpn1] route-distinguisher 100:1
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 export-extcommunity
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 import-extcommunity
[PE1-Tunnel0/0/1] ip binding vpn-instance vpn1
Step 4 Create a VPN instance vpn1 on PE2 and bind vpn1 to a user-side interface.
Step 5 Configure tunnel interfaces of the GRE tunnel.

# Configure CE1.
[CE1] interface tunnel 0/0/1
[CE1-Tunnel0/0/1] tunnel-protocol gre
[CE1-Tunnel0/0/1] source 30.1.1.1
[CE1-Tunnel0/0/1] destination 50.1.1.2
[CE1-Tunnel0/0/1] ip address 2.2.2.1 24
[CE1-Tunnel0/0/1] quit
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 6 Configure OSPF on CE1, R1, and PE1.

# Configure CE1.
[CE1] ospf 20
[CE1-ospf-20] area 0
[CE1-ospf-20-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[CE1-ospf-20-area-0.0.0.0] quit
[CE1-ospf-20] quit
# Configure R1.
[R1] ospf 20
[R1-ospf-20] area 0
[R1-ospf-20-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[R1-ospf-20-area-0.0.0.0] network 50.1.1.0 0.0.0.255
[R1-ospf-20-area-0.0.0.0] quit
[R1-ospf-20] quit
# Configure PE1.
[PE1] ospf 20
[PE1-ospf-20] quit
Step 7 Configure IS-IS on CE1 and PE1 to calculate routes between them.
# Configure CE1.
[CE1] isis 50
[CE1-isis-50] network-entity 50.0000.0000.0001.00
[CE1-isis-50] quit
[CE1-GigabitEthernet1/0/0] isis enable 50
[CE1-Tunnel0/0/1] isis enable 50
# Configure PE1.
[PE1] isis 50 vpn-instance vpn1
[PE1-isis-50] network-entity 50.0000.0000.0002.00
[PE1-isis-50] quit
[PE1-Tunnel0/0/1] isis enable 50
# Configure CE2.
[CE2] isis 50
[CE2-isis-50] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE2-isis-50] quit
[PE2-GigabitEthernet2/0/0] isis enable 50
Step 9 Set up an MP-IBGP peer relationship between the PEs.
# On PE1, configure an IBGP peer relationship with PE2 using a loopback interface to
exchange VPN IPv4 route information.
[PE1] bgp 100
# Import IS-IS routes to vpn1.

[PE1-bgp-vpn1] import-route isis 50
[PE2] bgp 100

Step 10 Import BGP routes to the IS-IS routing table.
# Configure PE1.
[PE1] isis 50
[PE1-isis-50] import-route bgp
# Configure PE2.
[PE2] isis 50
# After the configuration is complete, CE1 and CE2 have reachable routes to each other. The
command output on CE1 is used as an example.
<CE1> display ip routing-table 41.1.1.0
keyword>
------------------------------------------------------------------------------
Summary Count : 1
41.1.1.0/24 ISIS-L2 15 74 D 2.2.2.2 Tunnel0/0/1
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname CE1
#
isis 50
network-entity 50.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 50
#
ip address 30.1.1.1 255.255.255.0
#
ip address 2.2.2.1 255.255.255.0
tunnel-protocol gre
source 30.1.1.1
isis enable 50
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return
l Configurations file of R1
#
sysname R1
#
ip address 30.1.1.2 255.255.255.0
#
ip address 50.1.1.1 255.255.255.0
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
network 50.1.1.0 0.0.0.255
#
return

#
sysname PE1
#
#
mpls lsr-id 1.1.1.9
mpls
lsp-trigger all
#
mpls ldp
#
isis 50 vpn-instance vpn1
network-entity 50.0000.0000.0002.00
import-route bgp
#
ip address 50.1.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 110.1.1.1 255.255.255.0

mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ip address 2.2.2.2 255.255.255.0
tunnel-protocol gre
source 50.1.1.2
isis enable 50
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route isis 50
#
ospf 10
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
ospf 20
area 0.0.0.0
network 50.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger all
#
mpls ldp
#
network-entity 50.0000.0000.0003.00
import-route bgp
#
ip address 110.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 11.1.1.2 255.255.255.0
isis enable 50
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
ospf 10
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
isis 50
network-entity 50.0000.0000.0004.00
#
ip address 11.1.1.1 255.255.255.0
isis enable 50
#
ip address 10.2.1.2 255.255.255.0
isis enable 50
#
return
4.8.8 Example for Connecting a CE to a VPN Through a GRE

Tunnel over a VPN
In Figure 4-24:
l PE1 and PE2 reside on a class 1 carrier's MPLS backbone network.

l The VPN instance vpn2 belongs to a class 2 carrier's network, and CE1 is directly
connected to PE1.
l CE2 and CE3 connect to user hosts. CE2 is directly connected to PE2, and CE3 is
directly connected to CE1. CE2 and CE3 belong to vpn1 and are reachable to each other.
PE1 is indirectly connected to CE3. Therefore, no VPN instance can be bound to the physical
interface of PE1. A GRE tunnel is set up between CE3 and PE1 and this tunnel traverses
vpn2. On PE1, bind the GRE tunnel to vpn1 to connect CE3 to vpn1 using the GRE tunnel.
NOTE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-24 Connecting a CE to a VPN through a GRE Tunnel over a VPN
IP/MPLS
backbone
Loopback1 network Loopback1
1.1.1.9/32 3.3.3.9/32
CE1 GE1/0/0 GE2/0/0

vpn2 50.1.1.2/24 110.1.1.1/24
PE2
GE2/0/0 GE1/0/0
GE1/0/0
50.1.1.1/24 PE1 110.1.1.2/24 GE2/0/0
30.1.1.2/24
Tunnel0/0/1 11.1.1.2/24
el
2.2.2.2/24
nn
Tu
GE2/0/0 GE1/0/0
E
R
30.1.1.1/24 G 11.1.1.1/24
CE3 Tunnel0/0/1 CE2
2.2.2.1/24
GE1/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
vpn1 vpn1
1. Run OSPF process 10 on PE1 and PE2 to implement interworking between them, and
enable MPLS.
2. Configure a VPN instance vpn2 on PE1, and run OSPF process 20 on PE1, CE1, and
CE3 to implement interworking among the three devices.
3. Set up a GRE tunnel between CE3 and PE1. CE3 is connected to PE1 over vpn2, and the
interface on PE1 directly connected to CE1 is bound to vpn2. Therefore, the interfaces
directly connecting CE3 to CE1 and directly connecting PE1 to CE1 belong to vpn2.
When configuring a GRE tunnel between PE1 and CE3, you need to set a tunnel
destination address that belongs to vpn2.
4. Create vpn1 on PE1 and PE2. On PE1, bind vpn1 to the GRE tunnel interface. On PE2,
bind vpn1 to the physical interface connected to CE2.
5. Run IS-IS on the devices to dynamically calculate routes between the CEs and PEs.
6. Run BGP on the PEs to implement interworking between CE2 and CE3.
Procedure
# Configure CE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure CE1.
to a VPN instance.
to a VPN instance.
# Configure CE2.
Step 2 Configure routes between the PEs and enable MPLS.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] ospf 10

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-10] quit
[PE2] mpls lsr-id 3.3.3.9 32
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] ospf 10
[PE2-ospf-10] quit
Step 3 Create a VPN instance vpn2 on PE1 and bind vpn2 to an interface on a class 2 carrier's
network.
Step 4 Create a VPN instance vpn1 on PE1 and bind vpn1 to the GRE tunnel.
[PE1-Tunnel0/0/1] ip binding vpn-instance vpn1
Step 5 Create a VPN instance vpn1 on PE2 and bind vpn1 to a user-side interface.
Step 6 Configure tunnel interfaces of the GRE tunnel.
# Configure CE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[CE3-Tunnel0/0/1] tunnel-protocol gre
[CE3-Tunnel0/0/1] source 30.1.1.1
[CE3-Tunnel0/0/1] destination 50.1.1.2
[CE3-Tunnel0/0/1] ip address 2.2.2.1 24
# Configure PE1.
[PE1-Tunnel0/0/1] destination vpn-instance vpn2 30.1.1.1
Step 7 Configure routing protocols on CE3, CE1, and PE1.

# Configure CE3.
[CE3] ospf 20
[CE3-ospf-20] quit
# Configure CE1.
[CE1] ospf 20
[CE1-ospf-20] quit
# Configure PE1.
[PE1] ospf 20 vpn-instance vpn2
[PE1-ospf-20] quit
# Configure CE3.
[CE3] isis 50
[CE3-isis-50] quit
[CE3-Tunnel0/0/1] isis enable 50
# Configure PE1.
[PE1-isis-50] quit
[PE1-Tunnel0/0/1] isis enable 50
# Configure CE2.
[CE2] isis 50

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE2-isis-50] quit
# Configure PE2.
[PE2-isis-50] quit

[PE1] bgp 100

[PE2] bgp 100

Step 11 Import BGP routes to the IS-IS routing table.

# Configure PE1.
[PE1] isis 50
# Configure PE2.
[PE2] isis 50

# After the configuration is complete, CE1 and CE2 have reachable routes to each other. The
command output on CE1 is used as an example.
<CE1> display ip routing-table 41.1.1.0
to vpn-instance

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
------------------------------------------------------------------------------
Summary Count : 1
41.1.1.0/24 ISIS-L2 15 74 D 2.2.2.2 Tunnel0/0/1
----End
Configuration Files
#
sysname CE3
#
isis 50
network-entity 50.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 50
#
ip address 30.1.1.1 255.255.255.0
#
ip address 2.2.2.1 255.255.255.0
tunnel-protocol gre
source 30.1.1.1
isis enable 50
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return

#
sysname CE1
#
ip address 30.1.1.2 255.255.255.0
#
ip address 50.1.1.1 255.255.255.0
#
ospf 20
area 0.0.0.0
network 30.1.1.0 0.0.0.255
network 50.1.1.0 0.0.0.255
#
return

#
sysname PE1
#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls lsr-id 1.1.1.9
mpls
lsp-trigger all
#
mpls ldp
#
network-entity 50.0000.0000.0002.00
import-route bgp
#
ip address 50.1.1.2 255.255.255.0
#
ip address 110.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ip address 2.2.2.2 255.255.255.0
tunnel-protocol gre
source 50.1.1.2
destination vpn-instance vpn2 30.1.1.1
isis enable 50
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
ospf 10
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
ospf 20 vpn-instance vpn2
area 0.0.0.0
network 50.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger all
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls ldp
#
network-entity 50.0000.0000.0003.00
import-route bgp
#
ip address 110.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 11.1.1.2 255.255.255.0
isis enable 50
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
ospf 10
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 110.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
isis 50
network-entity 50.0000.0000.0004.00
#
ip address 11.1.1.1 255.255.255.0
isis enable 50
#
ip address 10.2.1.2 255.255.255.0
isis enable 50
#
return
4.8.9 Example for Configuring GRE to Implement

Communication Between FR Networks
As shown in Figure 4-25, Router_1 and Router_2 use the OSPF protocol to implement
communication over the public network. The customer requires that FR networks can
communicate over the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-25 Configuring GRE to implement communication between FR networks
Router_1 Router_2
GE1/0/0 Internet GE1/0/0
1.1.1.1/24 2.1.1.1/24
GRE Tunnel
Serial1/0/0 Serial1/0/0
10.3.1.1/24 10.3.1.2/24
FR network FR network
10.1.1.1/24 10.1.1.2/24
To implement communication between FR networks, you need to directly connect Router_1
and Router_2 using a GRE tunnel and configure the link bridge function.
1. Configure an IGP (OSPF process 1 in this example) to implement interworking between

the devices.
2. Set up a GRE tunnel between the routers and configure the link bridge function, so that
traffic from FR networks can be transmitted over the GRE tunnel.
Procedure
# Configure Router_1.
[Huawei] sysname Router_1
[Router_1] interface gigabitethernet 1/0/0
[Router_1-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[Router_1-GigabitEthernet1/0/0] quit
[Router_1] interface serial 1/0/0
[Router_1-Serial1/0/0] link-protocol fr
[Router_1-Serial1/0/0] fr dlci 200
[Router_1-fr-dlci-Serial1/0/0-200] quit
[Router_1-Serial1/0/0] quit
[Router_2] interface serial 1/0/0
[Router_2-Serial1/0/0] link-protocol fr
[Router_2-Serial1/0/0] fr dlci 200
[Router_2-fr-dlci-Serial1/0/0-200] quit
[Router_2-Serial1/0/0] quit
Step 2 Configure OSPF to ensure reachable routes between the routers over the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router_1] ospf 1
[Router_1-ospf-1] area 0
[Router_1-ospf-1-area-0.0.0.0] network 1.1.1.0 0.0.0.255
[Router_1-ospf-1-area-0.0.0.0] quit
[Router_1-ospf-1] quit
[Router_2] ospf 1
[Router_2-ospf-1] area 0
[Router_2-ospf-1-area-0.0.0.0] network 2.1.1.0 0.0.0.255
[Router_2-ospf-1-area-0.0.0.0] quit
[Router_2-ospf-1] quit
Step 3 Configure tunnel interfaces.

[Router_1] interface tunnel 0/0/1
[Router_1-Tunnel0/0/1] tunnel-protocol gre
[Router_1-Tunnel0/0/1] ip address 10.3.1.1 255.255.255.0
[Router_1-Tunnel0/0/1] source 1.1.1.1
[Router_1-Tunnel0/0/1] destination 2.1.1.1
[Router_1-Tunnel0/0/1] quit
[Router_1] link-bridge 2 interface serial 1/0/0 out-interface tunnel 0/0/1
[Router_2] link-bridge 2 interface serial 1/0/0 out-interface tunnel 0/0/1

# FR networks can communicate over the public network.
----End
Configuration Files
l Configuration file of Router_1
#
sysname Router_1
#
link-bridge 2 interface Serial1/0/0 out-interface Tunnel0/0/1
#
interface Serial1/0/0
link-protocol fr
fr dlci 200
#
ip address 1.1.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
#
ospf 1
area 0.0.0.0
network 1.1.1.0 0.0.0.255
#
return

#
sysname Router_2
#
link-bridge 2 interface Serial1/0/0 out-interface Tunnel0/0/1
#
link-protocol fr
fr dlci 200
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
source 2.1.1.1
destination 1.1.1.1
#
ospf 1
area 0.0.0.0
network 2.1.1.0 0.0.0.255
#
return
4.8.10 Example for Configuring an Ethernet over GRE Tunnel

In Figure 4-26, RouterA, RouterB, and RouterC use the Open Shortest Path First (OSPF)
protocol to implement communication over the public network. PC1 and PC2 on the branch
Ethernet networks belong to the same network segment, and need to communicate over the
public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 4-26 Ethernet over GRE tunnel
Internet
RouterB
GE1/0/0 GE2/0/0
20.1.1.2/24 30.1.1.1/24
GE1/0/0 GE1/0/0
20.1.1.1/24 30.1.1.2/24
RouterA RouterC
GRE Tunnel

VE0/0/2 10.3.1.1/24 10.3.1.2/24 VE0/0/2
VE0/0/1 VE0/0/1
PC1 PC2
10.1.1.1/24 10.1.1.2/24
1. Run OSPF on all the routers to implement reachable routes among them.
2. Create a GRE tunnel between RouterA and RouterC and configure Ethernet over GRE
on them to transmit packets between PC1 and PC2 over the GRE tunnel.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Configure OSPF on the routers.
[RouterA] ospf 1
[RouterB] ospf 1
[RouterC] ospf 1
and RouterC. You can find that they have learned the OSPF routes destined for the network
segment of the peer.

keyword>
------------------------------------------------------------------------------

30.1.1.0/24 OSPF 10 2 D 20.1.1.2


Step 3 Configure tunnel interfaces and create a GRE tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[RouterA] ping -a 10.3.1.1 10.3.1.2

0.00% packet loss
Step 4 Configure Ethernet over GRE.
# The configuration on RouterC is the same as that on RouterA. The configuration on

RouterA is used as an example.
# Configure a Layer 2 VE interface VE0/0/2 and bind it to the LAN-side physical Ethernet
interface GE2/0/0.
[RouterA] vlan 100
[RouterA-vlan100] quit
[RouterA] interface virtual-ethernet 0/0/2
[RouterA-Virtual-Ethernet0/0/2] portswitch
[RouterA-Virtual-Ethernet0/0/2] port link-type access
[RouterA-Virtual-Ethernet0/0/2] port default vlan 100
[RouterA-Virtual-Ethernet0/0/2] quit
[RouterA-GigabitEthernet0/0/2] map interface virtual-ethernet 0/0/2
# Configure a Layer 2 VE interface VE0/0/1 and bind it to the WAN-side tunnel interface
Tunnel0/0/1.
[RouterA] interface virtual-ethernet 0/0/1
[RouterA-Virtual-Ethernet0/0/1] portswitch
[RouterA-Virtual-Ethernet0/0/1] port link-type trunk
[RouterA-Virtual-Ethernet0/0/1] port trunk allow-pass vlan 100
[RouterA-Virtual-Ethernet0/0/1] quit
[RouterA-Tunnel0/0/1] map interface virtual-ethernet 0/0/1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# After the configurations are complete, PC1 and PC2 can ping each other successfully.
----End
Configuration Files
l RouterA configuration file
#
sysname RouterA
#
vlan batch 100
#
ip address 20.1.1.1 255.255.255.0
#
map interface Virtual-Ethernet0/0/2
#
interface Virtual-Ethernet0/0/1
portswitch
port link-type trunk
port trunk allow-pass vlan 100
#
portswitch
port link-type access
port default vlan 100
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return
l RouterB configuration file

#
sysname RouterB
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
l RouterC configuration file

#
sysname RouterC
#
vlan batch 100
#
ip address 30.1.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
portswitch
#
portswitch
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return
4.8.11 Example for Configuring an Ethernet over mGRE Tunnel
In Figure 4-27, a medium-sized enterprise has the headquarters (Hub) and two branches
(Spoke1 and Spoke2) located in different areas. The Hub and Spoke subnets use Ethernet
networks, and Spokes connect to the public network using dynamic addresses. The enterprise
requires that the Hub and Spoke subnets can communicate over the public network.
Assume that the dynamic addresses obtained by Spoke1 and Spoke2 are 1.1.2.10 and 1.1.3.10,
respectively.
Figure 4-27 Ethernet over mGRE tunnel
Tunnel0/0/1
GE2/0/0 10.16.1.2/24
VE0/0/2 VE0/0/1
Spoke1
subnet mGR
E Tu
nnel
10.1.1.2/24 Spoke1 GE1/0/0 GE1/0/0
1.1.2.10/24 1.1.1.10/24 Hub
Internet
GE1/0/0 Tunnel0/0/1 GE2
Spoke2 1.1.3.10/24 10.16.1.1/24 VE0
e l
Spoke2 E Tunn VE0/0/1
subnet mGR
10.1.1.3/24 GE2/0/0
VE0/0/2 Tunnel0/0/1
10.16.1.3/24
VE0/0/1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. Configure DSVPN to implement VPN interconnection between the Spokes because the
Spokes connect to the public network using dynamic IP addresses and the Spokes do not
know the public IP addresses of each other.
2. Configure the non-shortcut mode because there are only two Spokes.
3. Configure Ethernet over mGRE to enable communication between the Hub and Spoke
subnets that are Ethernet networks.
Procedure
# Configure an IP address for the interface on the Hub.
[Huawei] sysname Hub
[Hub] interface gigabitethernet 1/0/0
[Hub-GigabitEthernet1/0/0] ip address 1.1.1.10 255.255.255.0
[Hub-GigabitEthernet1/0/0] quit
# Configure an IP address for the interface on Spoke1.

[Huawei] sysname Spoke1
[Spoke1] interface gigabitethernet 1/0/0
[Spoke1-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[Spoke1-GigabitEthernet1/0/0] quit
# Configure an IP address for the interface on Spoke2.

Step 2 Configure OSPF to ensure reachable routes between the routers over the public network.
# Configure OSPF on the Hub.
[Hub] ospf 2
[Hub-ospf-2] area 0.0.0.1
[Hub-ospf-2-area-0.0.0.1] network 1.1.1.0 0.0.0.255
[Hub-ospf-2-area-0.0.0.1] quit
[Hub-ospf-2] quit
# Configure OSPF on Spoke1.

[Spoke1] ospf 2
[Spoke1-ospf-2] area 0.0.0.1
[Spoke1-ospf-2-area-0.0.0.1] network 1.1.2.0 0.0.0.255
[Spoke1-ospf-2-area-0.0.0.1] quit
[Spoke1-ospf-2] quit

[Spoke2] ospf 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 3 Configure tunnel interfaces and create mGRE tunnels.

Configure tunnel interfaces on the Hub and Spokes and configure the static NHRP peer entry
of the Hub on Spoke1 and Spoke2.
# Configure a tunnel interface on the Hub.
[Hub] interface tunnel 0/0/1
[Hub-Tunnel0/0/1] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/1] ip address 10.16.1.1 255.255.255.0
[Hub-Tunnel0/0/1] source gigabitethernet 1/0/0
[Hub-Tunnel0/0/1] nhrp entry multicast dynamic
[Hub-Tunnel0/0/1] quit
# Configure a tunnel interface and a static NHRP peer entry of the Hub on Spoke1.
[Spoke1] interface tunnel 0/0/1
[Spoke1-Tunnel0/0/1] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/1] ip address 10.16.1.2 255.255.255.0
[Spoke1-Tunnel0/0/1] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/1] nhrp entry 10.16.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/1] quit
# Configure a tunnel interface and a static NHRP peer entry of the Hub on Spoke2.
Step 4 Configure Ethernet over mGRE.

# The configurations on Spoke1 and Spoke2 are the same as that on the Hub. The
configuration on the Hub is used as an example.
# Configure a Layer 2 VE interface VE0/0/2 and bind it to the LAN-side physical Ethernet
interface GE2/0/0.
[Hub] vlan 100
[Hub-vlan100] quit
[Hub] interface virtual-ethernet 0/0/2
[Hub-Virtual-Ethernet0/0/2] portswitch
[Hub-Virtual-Ethernet0/0/2] port link-type access
[Hub-Virtual-Ethernet0/0/2] port default vlan 100
[Hub-Virtual-Ethernet0/0/2] quit
[Hub-GigabitEthernet2/0/0] map interface virtual-ethernet 0/0/2
# Configure a Layer 2 VE interface VE0/0/1 and bind it to the WAN-side tunnel interface
Tunnel0/0/1.
[Hub] interface virtual-ethernet 0/0/1
[Hub-Virtual-Ethernet0/0/1] portswitch
[Hub-Virtual-Ethernet0/0/1] port link-type trunk
[Hub-Virtual-Ethernet0/0/1] port trunk allow-pass vlan 100
[Hub-Virtual-Ethernet0/0/1] quit
[Hub-Tunnel0/0/1] map interface virtual-ethernet 0/0/1

After the configurations are complete, check the NHRP peer entries on Spoke1 and Spoke2.
# Run the display nhrp peer all command on Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Spoke1] display nhrp peer all

-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
10.16.1.1 32 1.1.1.10 10.16.1.1 hub up
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/1
Created time : 00:10:58
Expire time : --
Number of nhrp peers: 1

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.1 32 1.1.1.10 10.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE
The output of the display nhrp peer all command indicates that only the static NHRP peer entry of the
Hub is displayed on Spoke1 and Spoke2.
On the Hub, check registration information about Spoke1 and Spoke2.

# Run the display nhrp peer all command on the Hub.
[Hub] display nhrp peer all
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.2 32 1.1.2.10 10.16.1.2 registered up|unique
-------------------------------------------------------------------------------
Expire time : 01:57:58
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Step 6 Run the ping command and check the configuration result.
The subnet addresses of the Hub, Spoke1, and Spoke2 can successfully ping each other.
Spoke1 and Spoke2 can obtain the dynamic NHRP peer of each other.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.1 32 1.1.1.10 10.16.1.1 hub up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.2 32 1.1.2.10 10.16.1.2 local up|unique
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.1 32 1.1.1.10 10.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
10.16.1.3 32 1.1.3.10 10.16.1.3 local up|unique
-------------------------------------------------------------------------------
----End
Configuration Files
l Hub configuration file
#
sysname Hub
#
vlan batch 100
#
ip address 1.1.1.10 255.255.255.0
#
#
portswitch

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
portswitch
#
ip address 10.16.1.1 255.255.255.0
tunnel-protocol gre p2mp
source GigabitEthernet1/0/0
nhrp entry multicast dynamic
#
ospf 2
area 0.0.0.1
network 1.1.1.0 0.0.0.255
return
l Spoke1 configuration file
#
sysname Spoke1
#
vlan batch 100
#
ip address 1.1.2.10 255.255.255.0
#
#
portswitch
#
portswitch
#
ip address 10.16.1.2 255.255.255.0
nhrp entry 10.16.1.1 1.1.1.10 register
#
ospf 2
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return
#
sysname Spoke2
#
vlan batch 100
#
ip address 1.1.3.10 255.255.255.0
#
#
portswitch

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
portswitch
#
ip address 10.16.1.3 255.255.255.0
#
ospf 2
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
4.9 Troubleshooting GRE

This section describes common faults caused by incorrect configurations and provides the
troubleshooting procedure.
4.9.1 Failed to Ping the IP Address of the Remote Tunnel Interface

Fault Description
Failed to ping the IP address of the remote tunnel interface.
Procedure
l When the network layer protocol of one or both ends of a tunnel is Down
a. Check that interfaces on both ends of the tunnel use the same tunnel encapsulation
mode.
Run the display this interface command in the tunnel interface view on both ends
of the tunnel to check whether interfaces on both ends use the same tunnel
encapsulation mode. If Tunnel protocol/transport GRE/IP is displayed, the tunnel
encapsulation mode is GRE.
n If the two interfaces use different tunnel encapsulation modes, run the tunnel-
protocol command in the tunnel interface view to reconfigure the tunnel
encapsulation mode of one interface to be the same as that of the other
interface.
NOTE
After reconfiguring the tunnel encapsulation mode, reconfigure the tunnel source and
destination addresses because configurations of the original source and destination
addresses are lost.
n If the two interfaces use the same tunnel encapsulation mode, go to step 2.
b. Check that an IP address, a tunnel source address (or interface), and a tunnel
destination address are configured for interfaces on both ends of the tunnel.
Check whether the local tunnel source address (or interface) is the peer tunnel
destination address and the local tunnel destination address is the peer tunnel source

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
address (or interface). If not, no tunnel can be established between the two
interfaces. A tunnel source address (or interface) and a tunnel destination address
uniquely identify a tunnel.
Run the display this command in the tunnel interface view to check the interface
configuration. Ensure that the local tunnel source address (or interface) is the peer
tunnel destination address and the local tunnel destination address is the peer tunnel
source address.
n If the tunnel source (or interface) and destination addresses are incorrect, run
the source and destination commands in the tunnel interface view to
reconfigure the tunnel source (or interface) and destination addresses.
n If the tunnel source (or interface) and destination addresses are correct, go to
step 3.
c. Check that there are reachable routes between the tunnel source and destination
addresses.
If the interface configurations on both ends are correct but the tunnel status is still
Down, check whether there are reachable routes between interfaces on both ends of
the tunnel.
n If the tunnel is established between two indirectly connected interfaces, check

whether there are reachable routes between the two interfaces.
n If the tunnel is established between two directly connected interfaces, a direct
route exists.
Run the display ip routing-table command to view the IP routing table. If the IP
routing table is correct, run the display fib command to check the forwarding table
(FIB table) and check whether data is correctly forwarded.
If there is no reachable route between the tunnel source (or interface) and
destination addresses, configure static routes between the tunnel source and
destination addresses or configure a dynamic routing protocol to calculate reachable
routes.
l When the network layer protocol of interfaces on both ends of a tunnel is Up
a. Check that GRE key configurations of interfaces on both ends are consistent.
Run the display interface tunnel command on the two interfaces to check whether
their GRE key configurations are consistent. Ensure that:
n Neither of the two interfaces is configured with a GRE key.

n The two interfaces are configured with the same key.
If GRE key configurations of interfaces on both ends are consistent but the fault
persists, go to step 2.
b. Check IP addresses of interfaces on both ends of the tunnel.
If the network protocol status of the two interfaces is Up but they cannot ping each
other, check whether their IP addresses are on the same network segment. If the IP
addresses are on different network segments, configure static routes between the
two devices or configure a dynamic routing protocol to calculate reachable routes.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4.9.2 Tunnel Interface Alternates Between Up and Down States
Fault Description
After a GRE tunnel is configured, the tunnel interface alternates between Up and Down states.
Troubleshooting Procedure
Run the display fib destination-address command in any view multiple times to check
whether the outbound interface in the FIB entry to the specified destination network segment
changes. For example, the command outputs are displayed as follows:
<Huawei> display fib 10.2.1.0
Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
10.2.1.0/24 10.3.1.2 SU t[631838] Tun0/0/1 0x0
<Huawei> display fib 10.2.1.0
Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
10.2.1.0/24 1.1.1.2 GSU t[631840] GE1/0/0 0x0
The command outputs show that the outbound interface to 10.2.1.0 changes. As a result, the
tunnel interface flaps.
If the outbound interface changes, adjust the network topology to ensure that the outbound
interface is not a GRE tunnel interface. For VLL, PWE3, and BGP/MPLS IP VPN services,
you are advised to run the tunnel-policy (system view) command to select the GRE tunnel by
tunnel policy.
4.10 FAQ About GRE

This section describes the FAQ about GRE.
4.10.1 Can the MTU of the GRE Tunnel Interface Take Effect?
If you set an MTU value on a GRE tunnel interface, forwarding of data packets through the
GRE tunnel will be affected. If the packet length exceeds the MTU value on the tunnel
interface, the device fragments the packet.
4.11 References for GRE

This section lists references for GRE.
The following table lists the references for GRE.
Table 4-3 References for GRE

RFC1701 Generic Routing Encapsulation -

(GRE)

over IPv4 networks

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

(GRE)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 5 DSVPN Configuration
5 DSVPN Configuration
About This Chapter
5.1 Overview of DSVPN

5.2 Understanding DSVPN
5.3 Application Scenarios for DSVPN
5.4 Licensing Requirements and Limitations for DSVPN
5.5 Default Settings for DSVPN
5.6 Configuring DSVPN
5.7 Maintaining DSVPN
5.8 Configuration Examples for DSVPN
5.9 Troubleshooting DSVPN
5.10 References for DSVPN
5.1 Overview of DSVPN

Definition
Dynamic Smart Virtual Private Network (DSVPN) establishes VPN tunnels between Spokes
with dynamically variable public addresses in the Hub-Spoke model.
Purpose
More enterprises want to build the IPSec VPN in Hub-Spoke model to connect the Hub to
Spokes in different geographical locations. This enhances enterprise communication security
and reduces communication costs. When the Hub uses the static public address to connect to
the Internet and Spokes use dynamic public addresses to connect to the Internet, Spokes
cannot communicate with each other directly if traditional IPSec or GRE over IPSec is used to
build the VPN. This is because Spokes cannot learn the public addresses of the remote ends in

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
advance and tunnels cannot be set up between Spokes. In this case, communication data
between Spokes must be forwarded by the Hub. Figure 5-1 shows the networking.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-1 Typical Hub-Spoke networking without DSVPN enabled
Public interface (static IP address)

Hub
Public interface (dynamic IP address)
VPN tunnel
Data flows between Spokes
Internet
Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When all communication data between Spokes is forwarded by the Hub, the following
problems may occur:
l The Hub consumes many CPU and memory resources to forward data flows between
Spokes, causing resource shortage.
l The Hub needs to encapsulate and decapsulate data flows between Spokes, which causes
extra delay.
When the IPSec network scale increases continuously, dynamic routing protocols need to be
deployed to reduce route configuration and maintenance. There is a common issue when
IPSec and dynamic routing protocols are deployed. Dynamic routing protocols use multicast
or broadcast packets for route update, whereas IPSec does not support transmission of
broadcast and multicast packets.
Huawei proposes the DSVPN solution that integrates the Next Hop Resolution Protocol
(NHRP) and Multipoint Generic Routing Encapsulation (mGRE) with IPSec to solve the
preceding issue.
l DSVPN uses NHRP to dynamically collect, maintain, and advertise dynamic public
network addresses of nodes, and allows the source Spoke to obtain the public network
address of the destination Spoke so that a dynamic VPN tunnel can be set up between
Spokes. Spokes can communicate with each other directly, reducing the burden of the
Hub and preventing the network delay.
l DSVPN uses mGRE technology to transmit multicast and broadcast packets over VPN
tunnels that can be established between one tunnel interface and multiple remote devices,
reducing the tunnel configuration workload. In addition, when a Spoke is added or the
public address of a Spoke changes, DSVPN automatically maintains the tunnel between
the Hub and Spoke. There is no need to change the tunnel configuration of the Hub, and
DSVPN facilitates network maintenance.
Figure 5-2 shows a VPN using DSVPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-2 Hub-Spoke networking enabled with DSVPN

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Benefits
l Reduce costs on VPN construction.
DSVPN implements dynamic connections between the Hub and Spokes, and between
Spokes. Spokes do not need to purchase static public network addresses.
l Simplify configuration on the Hub and Spokes.
The Hub and Spokes use an mGRE tunnel interface but not multiple GRE tunnel
interfaces to establish tunnels. When a new Spoke is added to the network, the network
administrator does not need to change configurations on the Hub or any existing Spokes.
The administrator only needs to configure the new Spoke, and then the Spoke
dynamically registers with the Hub.
l Reduce the forwarding delay between Spokes.
Spokes can dynamically establish tunnels to directly exchange service data, reducing the
forwarding delay and improving forwarding performance and efficiency.
5.2 Understanding DSVPN
5.2.1 Basic Concepts

Figure 5-3 shows the typical network architecture of the DSVPN solution. An enterprise
connects the Hub to Spokes in different geographical locations through the public network.
The Hub uses the static public address, and Spokes use dynamic public addresses.
On the network, when the source Spoke sends data packets to the destination Spoke, the
source Spoke obtains the public address of the destination Spoke by exchanging NHRP
packets over the static mGRE tunnel between itself and the Hub and establishes a dynamic
mGRE tunnel with the destination Spoke. After the tunnel is set up, data packets between
Spokes are sent to the remote end over the dynamic mGRE tunnel, but are not forwarded by
the Hub.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-3 Typical enterprise networking
Subnet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
DSVPN Node
DSVPN involves the following entities:
A DSVPN node is a device on which DSVPN is deployed, which can be a Spoke or Hub.
l Spoke
A Spoke is the network gateway of a branch. Generally, a Spoke uses a dynamic public
network address.
l Hub
A Hub is the gateway in the headquarters and receives registration packets from Spokes.
On a DSVPN network, the Hub can use a fixed public network address or a domain
name.
mGRE, mGRE Tunnel Interface, and mGRE Tunnel

mGRE is a point-to-multipoint GRE technology developed based on GRE. It extends
traditional P2P tunnel interfaces to P2MP mGRE tunnel interfaces. One tunnel interface can
be used to establish tunnels with multiple remote devices by changing the interface type.
Therefore, only one tunnel interface needs to be configured on the Hub or Spoke, reducing the
GRE tunnel configuration workload.
The mGRE tunnel interface has the following attributes:

l Source tunnel address: is the source address of a GRE encapsulated packet, that is, public
network address of one end in Figure 5-3.
l Destination tunnel address: is the destination address of a GRE encapsulated packet, that
is, public network address of the other end in Figure 5-3. This address is based on
NHRP, which is different from the manually specified destination address of the GRE
tunnel interface.
l Tunnel interface IP address: is the tunnel address in Figure 5-3. Similar to an IP address
of a physical interface, a tunnel interface IP address is used for communication between
devices, for example, routing information is obtained.
NOTE
mGRE tunnel interfaces do not support keepalive detection of the GRE interface.
A GRE tunnel established using an mGRE tunnel interface is called an mGRE tunnel. mGRE
tunnels fall into static and dynamic mGRE tunnels:
l A static mGRE tunnel is set up between a Spoke and the Hub and always exists. The
Spoke sends registration packets to the Hub periodically. When receiving a registration
packet a Spoke, the Hub resets the aging timer of the matching NHRP mapping entry to
maintain the tunnel with the Spoke.
l A dynamic mGRE tunnel is established between Spokes. It is automatically torn down if
no packet is forwarded through it within a period.
NHRP and NHRP Mapping Entry

On a DSVPN network, NHRP is used to establish and resolve the mapping between the
protocol address (tunnel address in Figure 5-3 or subnet address) and Non-Broadcast
Multiple Access (NBMA) address (public address in Figure 5-3). By doing this, the source
Spoke can obtain the dynamic public address of the destination Spoke.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The NHRP mapping table contains the entries that are generated based on the mapping
between protocol addresses and NBMA addresses. NHRP entries fall into static and dynamic
entries based on the entry generation mode:
l Static NHRP mapping entry: is manually configured by an administrator. When a Spoke
needs to establish a static mGRE tunnel with the Hub, the administrator needs to
manually configure the tunnel address and public network address of the Hub on the
Spoke.
l Dynamic NHRP mapping entry: is dynamically generated by NHRP. For example, the
Hub obtains the tunnel address and public address of each Spoke from an NHRP
Registration packet and generates an NHRP mapping table. Each Spoke obtains the
tunnel address or subnet address and public address of the remote Spoke from an NHRP
Resolution packet and generates an NHRP mapping table.
For details about NHRP Registration and Resolution packets, see RFC 2332.
5.2.2 Implementation
DSVPN establishes tunnels based on mGRE and NHRP to implement direct communication
between Spokes. Unlike GRE, mGRE does not need to define the destination tunnel address
during tunnel setup. Instead, mGRE obtains the destination tunnel address through NHRP,
making it possible to set up tunnels between Spokes with dynamic addresses.
When the device forwards an IP packet, it sends the IP packet to the mGRE tunnel interface
based on the routing table. mGRE queries and obtains the remote public address mapping the
next-hop address in the NHRP mapping table. mGRE adds a new IP header to the IP packet
in which the destination address is the remote public address. Then the IP packet can be sent
to the remote end over the tunnel.
The NHRP mapping table and routing table are the basis for tunnel setup when mGRE and
NHRP are deployed. If a Spoke has a route to the remote Spoke and the NHRP mapping entry
between the tunnel address or subnet address of the remote Spoke and public address, an
mGRE tunnel can be set up between Spokes. At the beginning, a Spoke has only the route to
the Hub and one static NHRP mapping entry between the tunnel address of the Hub and
public address. Spokes cannot establish tunnels directly. They have to learn routes to each
other through the Hub and generate NHRP mapping entries between tunnel addresses or
subnet addresses and public addresses. There are three processes:
1. Establishing mGRE Tunnels Between Spokes and the Hub

After mGRE tunnels are set up between Spokes and the Hub, packets of one Spoke can
be forwarded to the remote Spoke through the Hub.
DSVPN establishes a static mGRE tunnel between a Spoke and the Hub. This tunnel
always exists regardless of whether there is traffic between the Spoke and Hub.
2. Learning Routes Between Spokes
The route from one Spoke to the remote Spoke is generated.
3. Establishing mGRE Tunnels Between Spokes
mGRE tunnels are set up so that Spokes can communicate directly. When one Spoke
forwards data packets to the other Spoke and the source Spoke cannot find the public
address of the destination Spoke, DSVPN establishes an mGRE tunnel between Spokes.
The mGRE tunnel between Spokes is a dynamic tunnel. When there is traffic between
Spokes, the tunnel keeps connected automatically. When there is no traffic between
Spokes during a period of time, the tunnel is terminated automatically.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When an mGRE tunnel is established between Spokes, data packets between Spokes are
directly forwarded over this mGRE tunnel and do not pass through the Hub.
Establishing mGRE Tunnels Between Spokes and the Hub

At the beginning, the Hub has no NHRP mapping entry, and the Spoke has the route to the
Spoke and a static mapping entry between the tunnel address of the Hub and public address.
To establish mGRE tunnels between Spokes and the Hub, the Hub needs to generate NHRP
mapping entries between tunnel addresses of the Spokes and public addresses. The Spokes
initiate NHRP registration to the Hub so that entries can be generated. Figure 5-4 shows the
process.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-4 Establishing mGRE tunnels between Spokes and the Hub
Destination Address Next-Hop Address

192.168.3.0/24 Public
Routing table 192.168.1.0 10.1.1.1
1.1.1.1
192.168.2.0 10.1.1.2
Public
Tunnel Address Public Address Hub
NHRP mapping table 10.1.1.1 1.1.1.1 Tunne
10.1.1.2 2.2.2.2 Public IP address: 3.3.3.3
Tunnel IP: 10.1.1.3 Sta
NH
1 1 NH
2 2
Public address: 1.1.1.1 Internet

Public address:
Tunnel Address: 10.1.1.1 Tunnel Address:
192.168.1.0/24 192.16
Spoke1 Spoke2
Destination Address Next-Hop Address Destination Address Next-Hop Addr
Routing table 192.168.3.0 10.1.1.3 192.168.3.0 10.1.1.3
Tunnel Address Public Address Tunnel Address Public Addr

NHRP mapping table
10.1.1.3 3.3.3.3 10.1.1.3 3.3.3.3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. Spokes send NHRP Registration Request packets to the Hub.

After the administrator manually configures the Hub's tunnel address and public address
on the Spokes, the Spokes periodically send NHRP Registration Request packets to the
Hub. The packets carry the Spokes' tunnel addresses and public addresses.
2. The Hub responds to NHRP Registration Request packets of the Spokes.
The Hub obtains the Spokes' tunnel addresses and public addresses from NHRP
Registration Request packets (fonts in red in Figure 5-4), generates NHRP mapping
entries, and establishes mGRE tunnels.
The Spokes periodically send NHRP Registration Request packets to the Hub. When
receiving a registration packet from a Spoke, the Hub resets the aging timer of the matching
NHRP mapping entry to maintain the tunnel with the Spoke.
Learning Routes Between Spokes

DSVPN supports the following route learning modes:
l Route learning between Spokes (non-shortcut mode)
The next-hop address of the route from the source Spoke to the destination Spoke is the
tunnel address of the destination Spoke (see the routing table in Figure 5-5), and each
Spoke needs to learn the route to the remote end. This consumes many CPU and memory
resources and requires large routing tables and high performance on Spokes. In practice,
the Spokes have low performance and store a limited number of routes. The route
learning solution applies to small- and medium-sized networks where there are fewer
network nodes and a small number of routes.
l Spoke routes summarized to the Hub (shortcut mode)
tunnel address of the Hub (see the routing table in Figure 5-6), and Spokes only need to
store routes to the Hub. The number of routes of Spokes is reduced, so the route learning
solution applies to large-sized networks with many Spokes.
Establishing mGRE Tunnels Between Spokes

After the preceding two processes are complete, each Spoke has the route to the remote
Spoke, but has no NHRP mapping entry between the destination Spoke's tunnel address or
subnet address and public address. To establish mGRE tunnels between Spokes, NHRP is
used to generate NHRP mapping entries based on learned routes. When different route
learning modes are used, Spokes learn different routes and NHRP mapping entry generation
processes are also different:
l Non-shortcut: The source Spoke can learn the tunnel address of the destination Spoke.
The source Spoke can query the destination Spoke's public address based on destination
Spoke's tunnel address and generate the NHRP mapping entry between the destination
Spoke's tunnel address and public address.
l Shortcut: Next-hop addresses of all Spokes are the Hub's tunnel address, and the source
Spoke cannot learn the tunnel address of the destination Spoke. The source Spoke can
query the destination Spoke's public address based on destination address of packets and
generate the NHRP mapping entry between the destination Spoke's subnet address and
public address.
Figure 5-5 and Figure 5-6 describe the processes.
Establishing an mGRE tunnel between Spokes in non-shortcut mode

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-5 shows the mGRE tunnel setup between Spokes in non-shortcut mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-5 Establishing an mGRE tunnel between Spokes in non-shortcut mode

Public
192.168.1.0 10.1.1.1
Routing table 192.168.3.0/24
192.168.2.0 10.1.1.2
Public
Tunnel Address Public Address
NHRP mapping table Tunne
10.1.1.1 1.1.1.1 Hub
10.1.1.2 2.2.2.2
Public address: 3.3.3.3
Tunnel address: 10.1.1.3
N
2
1
1
2 S
D
Internet
Public address: 1.1.1.1 Public addres
3
Tunnel address: 10.1.1.1 Tunnel addres
4
192.168.1.0/24 192.1
Spoke1 Spoke2
Destination Address Next-Hop Address Destination Address Next-Hop Addres
Routing table 192.168.3.0 10.1.1.3 192.168.3.0 10.1.1.3
192.168.2.0 10.1.1.2 192.168.1.0 10.1.1.1
Tunnel Address Public Address Tunnel Address Public Addres

NHRP mapping table 10.1.1.3 3.3.3.3 10.1.1.3 3.3.3.3
10.1.1.2 2.2.2.2 10.1.1.1 1.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When a user on Spoke1 first accesses a user on Spoke2, the setup of a dynamic mGRE tunnel
between Spoke1 and Spoke2 is triggered. The tunnel setup process is as follows.
1. After Spoke1 receives a data packet destined for Spoke2:
– Spoke1 finds next-hop address 10.1.1.2 (tunnel address of Spoke2) based on
destination address 192.168.2.0 of the data packet, but no NHRP mapping entry
defines the public address mapping 10.1.1.2. Spoke1 directly forwards the data
packet to the Hub by default.
– Spoke1 constructs and sends an NHRP Resolution Request packet to the Hub,
requesting for the public address mapping 10.1.1.2.
2. After the Hub receives the data packet and NHRP Resolution Request packet from
Spoke1, it forwards the packets to Spoke2 through the mGRE tunnel between them.
3. After Spoke2 receives the NHRP Resolution Request packet:
– Spoke2 obtains the tunnel address and public address of Spoke1 from the NHRP
Resolution Request packet, and updates such information in its NHRP mapping
table (see fonts in red in Figure 5-5).
– Spoke2 constructs and sends an NHRP Resolution Reply packet that carries tunnel
address 10.1.1.2 and public address 2.2.2.2 of Spoke2.
4. After Spoke1 receives the NHRP Resolution Reply packet, it obtains the tunnel address
and public address of Spoke2 from the NHRP Resolution Reply packet, and updates its
NHRP mapping table (see fonts in red in Figure 5-5). A dynamic mGRE tunnel between
Spoke1 and Spoke2 is set up.
When Spoke1 receives a data packet destined for Spoke2 again, it finds next-hop address
10.1.1.2 in the routing table based on destination address 192.168.2.0 of the data packet
and public address 2.2.2.2 mapping 10.1.1.2 in the NHRP mapping table. Then Spoke1
adds an mGRE header to the data packet based on public address 2.2.2.2 and directly
forwards it to Spoke2.
Establishing an mGRE tunnel between Spokes in shortcut mode
Figure 5-6 shows the mGRE tunnel setup between Spokes in shortcut mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-6 Establishing an mGRE tunnel between Spokes in shortcut mode

Public inter
Routing table 192.168.1.0 Public inter

10.1.1.1 192.168.3.0/24
192.168.2.0 10.1.1.2
Tunnel inte
Tunnel Address Public Address
User d
NHRP mapping table 1.1.1.3
10.1.1.1 1.1.1.1 Hub
10.1.1.2 2.2.2.2
Public IP address: 3.3.3.3 NHRP
Tunnel IP address: 10.1.1.3 NHRP
2
NHRP
3
2
Static
4
1
Dynam
Internet
Public address: 1.1.1.1 Public address: 2.2
5
Tunnel Address: 10.1.1.1 Tunnel address: 10
6
192.168.1.0/24 192.168.2.0
Spoke1 Spoke2
Destination Address Next-Hop Address Destination Address Next-Hop Addres

Routing table 192.168.2.0 10.1.1.3 192.168.1.0 10.1.1.3
192.168.3.0 10.1.1.3 192.168.3.0 10.1.1.3
Tunnel or Subnet Tunnel or Subnet Public Address

Public Address
Address Address
NHRP mapping table 1.1.1.3 1.1.1.3
10.1.1.3 3.3.3.3 10.1.1.3 3.3.3.3
192.168.2.0 2.2.2.2 10.1.1.1 1.1.1.1
between Spoke1 and Spoke2 is triggered. The tunnel setup process is as follows.
1. When Spoke1 receives a data packet destined for Spoke2, it finds next-hop address
10.1.1.3 (tunnel address of the Hub) based on destination address 192.168.2.0 of the data
packet and public address 3.3.3.3 mapping 10.1.1.3 (public address of the Hub) in the
NHRP mapping table. Then Spoke1 forwards the data packet to the Hub.
2. After the Hub receives the data packet forwarded by Spoke1:
– The Hub forwards the data packet to Spoke2 over the mGRE tunnel between the
Hub and Spoke2.
– The Hub finds that the tunnel interfaces receiving and sending the data packet
belong to the same NHRP domain (see nhrp network-id). It constructs and sends an
NHRP Redirect packet to Spoke1. The packet carries only the tunnel address and
public address of the Hub.
3. After Spoke1 receives the NHRP Redirect packet, it constructs and sends an NHRP
Resolution Request packet to the Hub. The packet carries tunnel address 10.1.1.1 and
public address 1.1.1.1 of Spoke1, and destination address 192.168.2.0 of the data packet
to be resolved.
4. The Hub forwards the received NHRP Resolution Request packet to Spoke2.
5. After Spoke2 receives the NHRP Resolution Request packet:
– Spoke2 obtains the subnet address and public address of Spoke1 from the NHRP
Resolution Request packet, and updates its NHRP mapping table (see fonts in red in
Figure 5-6).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– Spoke2 constructs and sends an NHRP Resolution Reply packet that carries the
subnet address 192.168.2.0, tunnel address 10.1.1.2, and public address 2.2.2.2 of
Spoke2.
6. After Spoke1 receives the NHRP Resolution Reply packet, it obtains the subnet address
and public address of Spoke2 from the NHRP Resolution Reply packet, and updates its
NHRP mapping table (see fonts in red in Figure 5-6). A dynamic mGRE tunnel between
Spoke1 and Spoke2 is set up.
When Spoke1 receives a data packet destined for Spoke2 again, it searches the NHRP
mapping table for Spoke2's public address 2.2.2.2 based on destination address
192.168.2.0 of the data packet. Then Spoke1 adds an mGRE header to the data packet
based on public address 2.2.2.2 and directly forwards it to Spoke2.
between Spoke2 and Spoke1 is also triggered. The tunnel setup process is similar to that when
a user on Spoke1 first accesses a user on Spoke2.
5.2.3 DSVPN NAT Traversal

In Figure 5-7, when private networks of Spokes connect to the Hub through Network Address
Translation (NAT), NAT traversal must be implemented to establish VPN tunnels between the
Hub and Spokes, and between Spokes. DSVPN NAT traversal can be deployed so that Spokes
can directly communicate across the NAT device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-7 DSVPN NAT traversal
Hub
Public
Public
mGRE
Internet
S
D
D
NAT NAT
Spoke1 Spoke2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
DSVPN NAT traversal is implemented by encapsulating original and translated addresses of

Spokes in NAT extension fields of NHRP Registration Reply packets and NHRP Resolution
Request or Reply packets. The implementation is as follows:
1. The Spokes send NHRP Registration Request packets to the Hub. The NHRP
Registration Request packets carry public or private network addresses of the Spokes.
2. NHRP on the Hub detects whether a NAT device exists between the Hub and Spokes. If
the NAT device exists, the Hub encapsulates translated public addresses of Spokes in
NAT extension fields of NHRP Registration Reply packets and sends the packets to the
Spokes.
3. The source Spoke sends an NHRP Resolution Request packet to the destination Spoke.
The packet carries the original address and translated public address in NAT extension
fields of the source Spoke.
4. The destination Spoke sends an NHRP Resolution Reply packet to the source Spoke.
The packet carries the original address and translated public address in NAT extension
fields of the destination Spoke.
5. The source and destination Spokes learn the original address and translated public
network address of each other and establish an mGRE tunnel based on the translated
public address. By doing this, Spokes can directly communicate across the NAT device.
NOTE
l NAT traversal cannot be implemented on a DSVPN network if two Spokes use the same NAT device
and their original addresses are translated to the same public network address.
l NAT traversal cannot be implemented if two Spokes are behind different NAT devices, and Port
Address Translation (PAT) is enabled on the NAT device.
l When branches need to communicate with each other, the NAT device must be configured with an
NAT server or static NAT. NAT traversal cannot be implemented if outbound NAT is configured on
the NAT device.
l When you deploy IPSec on a DSVPN network, the IPSec encapsulation mode can only be transport
if two branches are connected to different NAT devices or the headquarters is connected to a NAT
device.
5.2.4 DSVPN Protected by IPSec

DSVPN uses an mGRE tunnel to transmit data, but data is not encrypted over the mGRE
tunnel and data transmission on the Internet is insecure. You are advised to deploy IPSec to
ensure secure communication data transmission between Spokes when DSVPN is used.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-8 DSVPN protected by IPSec
Public interface (static IP a

Hub
Public interface (dynamic
mGRE tunnel interface
l IP Static mGRE tunne

ne Se
un c
ct tu
nn
Se el Dynamic mGRE tu
IP
Internet
IPSec tunnel
IPS
ec
Spoke1 tun
ne
Spoke2
l
Spoke3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On a DSVPN network, IPSec profiles are configured on the Hub and Spokes and bound to
mGRE tunnel interfaces. mGRE tunnel setup will trigger IPSec tunnel setup. The
implementation is as follows:
1. All the Spokes on the network send NHRP Registration Request packets to the Hub and
report the NHRP mapping entries to IPSec. The Internet Key Exchange (IKE) modules
of the Spokes and the Hub negotiate with each other for IPSec tunnel parameters.
2. The Hub generates local NHRP mapping entries between tunnel addresses and public
network addresses of the Spokes based on the NHRP Registration Request packets
received. The Hub then sends NHRP Registration Reply packets to the Spokes.
3. The Spokes trigger an mGRE tunnel immediately when they transmit traffic. For details
about how to establish an mGRE tunnel, see Establishing mGRE Tunnels Between
Spokes.
4. After the Spokes establish an mGRE tunnel, the IPSec module obtains NHRP mapping
entries, adds or deletes IPSec peers based on the mapping entries, and triggers the
Spokes to dynamically establish an IPSec tunnel.
5. After an IPSec tunnel is established between the Spokes, packets are routed based on the
destination IP addresses. If the outbound interface is an mGRE interface, the Spoke
searches the NHRP mapping table for the public network address mapping the next hop
private address. After obtaining the public network address, the Spoke searches for the
IPSec security association (SA) matching the public network address to encrypt the
packets and send them.
Compared with IPSec in traditional Hub-Spoke networking, integrating DSVPN and IPSec
has the following advantages:
l Traditional IPSec uses ACLs to identify unicast traffic to be encrypted. The ACL
configuration is complex and its maintenance is difficult. In DSVPN scenarios, you only
need to bind mGRE tunnel interfaces to IPSec profiles, without defining complex ACLs.
The network deployment is more simple.
l Because an IPSec tunnel is dynamically established between Spokes, IPSec packets
transmitted between Spokes are not decrypted or encrypted by the Hub. This shortens the
packet forwarding delay.
NOTE
When you deploy IPSec on a DSVPN network, the IPSec encapsulation mode can only be transport if
two branches are connected to different NAT devices or the headquarters is connected to a NAT device.
5.2.5 DSVPN Reliability
5.2.5.1 Dual Hubs in Active/Standby Mode
In basic DSVPN networking, all Spokes are connected to one Hub. Spokes cannot
communicate with each other if the Hub fails. Multiple Hubs can be deployed to improve
network reliability.
In Figure 5-9, Hub1 and Hub2 are deployed in the headquarters. Routing policies are
deployed on Spokes so that routes to Hub1 have a higher priority than those to Hub2.
Normally, Hub1 is the active Hub and Hub2 is the standby Hub.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-9 Dual Hubs in active/standby mode
Hub1 Hub2
(Active) (Standby) Hub1 (A
Hub1 fails
Internet Internet
Spoke1 Spoke2 Spoke1
Public interface Static mGRE tunnel (active)

(static IP address)
Public interface Static mGRE tunnel (standby)
(dynamic IP address)
mGRE tunnel interface Dynamic mGRE tunnel
NHRP packets Data flows between Spokes

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The working mechanism is as follows:

1. All Spokes are registered with Hub1 and Hub2, and establish active and standby static
mGRE tunnels with Hub1 and Hub2 respectively.
2. The source Spoke sends an NHRP Resolution Request packet to request the public
address of the destination Spoke, which is used to establish a dynamic mGRE tunnel.
– When Hub1 and Hub2 work properly, the NHRP Resolution Request packet is sent
to the Hub over the active static mGRE tunnel because the route from the source
Spoke to Hub1 has a higher priority. Hub2 forwards the NHRP Resolution Request
packet to the destination Spoke.
– When Hub1 fails, the priority of the route from the source Spoke to Hub1 is
reduced and the NHRP Resolution Request packet is sent to Hub2 over the standby
static mGRE tunnel. Hub2 then sends the NHRP Resolution Request packet to the
destination Spoke.
– When Hub1 recovers, the NHRP Resolution Request packet is forwarded by Hub1.
This is because the route from each Spoke to Hub1 has a higher priority than the
route from each Spoke to Hub2.
3. The destination Spoke sends an NHRP Resolution Reply packet to the source Spoke, and
a dynamic mGRE tunnel is set up.
4. After the dynamic mGRE tunnel is set up, Spokes can directly communicate with each
other. In this case, the Hub running status does not affect service flows between Spokes.
If the dynamic mGRE tunnel between branch Spokes is torn down because no traffic
passes through the tunnel for a long period of time, the Spokes need to reestablish a
dynamic mGRE tunnel. The Spokes then determine the Hub to which they send NHRP
Resolution Request packets based on the route priority.
5.2.5.2 Dual Hubs in Load Balancing Mode

A single Hub can connect to a certain number of Spokes due to its performance limitation.
When there are many Spokes on a network, you can deploy two or more Hubs to improve the
processing capability of the headquarters.
In Figure 5-10, Hub1 and Hub2 are deployed in the headquarters. Not all Spokes can register
with one Hub because there are many Spokes, so some Spokes are registered with Hub1 and
Hub2 to implement load balancing.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-10 DSVPN load balancing
Hub1 Hub2
Public interface (static IP address)
Public interface (dynamic IP address)

Static mGRE tunnel between
Hub1 and Hub2
Internet Static mGRE tunnel registered on Hub1
Static mGRE tunnel registered on Hub2
Dynamic mGRE tunnel
Spoke1 SpokeN
...
Spoke2
The principle of direct communication between Spokes connected to the same Hub is similar
to Principles. Static mGRE tunnels need to be set up between Hubs to allow Spokes
connected to different Hubs to directly communicate with each other.
The direct communication process between Spokes connected to different Hubs is as follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. A source Spoke1 sends an NHRP Resolution Request packet to Hub1 to request the
public network address of destination SpokeN.
2. Hub1 forwards the NHRP Resolution Request packet to Hub2 over the static mGRE
tunnel between Hub1 and Hub2.
3. Hub2 forwards the NHRP Resolution Request packet to the destination SpokeN.
4. The destination SpokeN obtains the public network address of the source Spoke1 from
the NHRP Resolution Request packet and sends an NHRP Resolution Reply packet to
the source Spoke1.
5. The source Spoke1 obtains the public network address of the destination SpokeN from
the NHRP Resolution Reply packet and establishes a dynamic mGRE tunnel with the
destination SpokeN.
After the dynamic mGRE tunnel is set up, Spokes connected to the two Hubs can directly
communicate with each other.
5.3 Application Scenarios for DSVPN
5.3.1 DSVPN Deployment on a Small- or Medium-sized Network

Small- and medium-sized networks have only a few branches, and the branches can
dynamically establish VPNs by deploying Non-Shortcut Scenario of DSVPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-11 DSVPN deployment on a small- or medium-sized network
Hub
Public interface (static IP
Public interface (dynamic
Static mGRE tunnel
Dynamic mGRE tun

Internet
Data flows between
Spoke1 Spoke2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 5-11, Spoke1 and Spoke2 connect to the Hub through the public network.
DSVPN is deployed to enable Spoke1 and Spoke2 to learn routes from each other. Spoke1
and Spoke2 can communicate with each other directly because they are each other's next hop.
5.3.2 DSVPN Deployment on a Large-sized Network

A large-sized network has a large number of branch offices. The deployment of Non-Shortcut
Scenario of DSVPN requires the Spokes to have a large routing table and high forwarding
performance. Shortcut Scenario of DSVPN can be deployed without upgrading the Spokes.
This deployment reduces the routing entries on the Spokes, lowering the requirements on the
Spokes' routing table size and forwarding performance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-12 DSVPN deployment on a large-sized network
Public interface (sta

Hub
Public interface (dy
mGRE tunnel interf
Static mGRE tu
Dynamic mGR
Data flows betw

Internet
Spoke1 SpokeN
Spoke2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 5-12, all the Spokes only have routes to the Hub. When two Spokes need
to communicate with each other, the first packet is sent to the Hub. After that, a tunnel is
established between the Spokes, and the Spokes can directly exchange data traffic.
5.3.3 Deploying DSVPN in Hierarchical Hub Networking

Figure 5-13 shows a network topology of an enterprise. The organizations of the enterprise
are hierarchical. DSVPN is deployed on the network. Some intermediate nodes function as
both the Spokes and Hubs. For example, Hub1 and Hub2 function as Hubs for its downstream
Spokes and serve as Spokes for the Hub in the headquarters.
The principles of establishing dynamic mGRE tunnels between Spokes of Hub1 and Hub2 are
similar to Principles. When a Spoke of Hub1 needs to establish a dynamic mGRE tunnel with
a Spoke of Hub2, the source Spoke sends an NHRP Resolution Request packet to Hub1.
Hub1 sends the NHRP Resolution Request packet to the Hub, the Hub sends the NHRP
Resolution Request packet to Hub2, and Hub2 sends the NHRP Resolution Request packet to
the destination Spoke. Finally, a dynamic mGRE tunnel is set up between Spokes in
hierarchical Hub networking.
NOTE
When DSVPN is deployed in hierarchical Hub networking, branches can learn routes from each other in
shortcut mode only.
During the DSVPN deployment, two tunnel interfaces need to be created on Hub1 and Hub2 separately,
so that Hub1 and Hub2 can set up static mGRE tunnels with the Hub and corresponding Spoke. Hub1
and Hub2 can be regarded as Spokes of the Hub.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-13 Deploying DSVPN in hierarchical Hub networking
Public interface (static Static mGRE tunnel registered Dynamic mGRE tunnels
IP address) on the Hub between Spokes
Public interface Static mGRE tunnel registered on Hub1
(dynamic IP address) Static mGRE tunnel registered on Hub2
Hub
(headquarters)
Hub1 Hub2
Spoke Spoke
Spoke Spoke
5.4 Licensing Requirements and Limitations for DSVPN

None

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
For DSVPN-capable devices, their licensing requirements for the DSVPN function are as
follows:
NOTE
DSVPN is a Huawei proprietary protocol and can only be used to interconnect AR routers.
l AR100&AR120 series: DSVPN is a basic feature of the device and is not under license
control.
DSVPN function is disabled on a new device. To use the DSVPN function, apply for and
purchase the following license from the Huawei local office.
– AR150&AR160&AR200 series: AR150&160&200 Value-Added Security Package
– AR1200 series: AR1200 Value-Added Security Package
Feature Limitations
When IPSec tunnels are deployed on the DSVPN network, rapidly updating the NHRP
mapping table will cause IKE re-negotiation and may even interrupt services. Do not update
the NHRP mapping table frequently.
5.5 Default Settings for DSVPN

NHRP domain of an interface 0
NHRP authentication Unspecified
Time interval at which a Spoke registers 1800 seconds

with the Hub
Holding time of NHRP mapping entries 7200 seconds
NHRP redirect function Disabled
NHRP shortcut function Disabled
Adding dynamically registered branches to Unspecified

the NHRP multicast member table
Method to process conflicting NHRP Not overridden

mapping entries during NHRP registration
Referencing an IKE peer in the IPSec Not referenced

profile
Referencing an IPSec proposal in the IPSec Not referenced

profile

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Using PFS in IPSec negotiation Unused
5.6 Configuring DSVPN

Before configuring DSVPN, configure public network addresses to ensure that routes between
nodes are reachable.
After DSVPN is configured, a Spoke can dynamically obtain the public network address of its
peer device and establish a tunnel with the peer device to exchange data.
Perform the following operations on the Hub and Spokes to configure DSVPN. Configuring
an IPSec profile is optional. You are advised to perform this operation to protect packets
against attacks because NHRP does not provide the encryption and decryption functions.
5.6.1 Configuring mGRE
Context
To implement DSVPN, create a tunnel interface and set the interface type to Multipoint GRE
(mGRE). You only need to configure the source address or source interface but not the
destination address on the mGRE interface. An mGRE tunnel interface has multiple remote
ends and allows multiple GRE tunnels to be established on the interface. This simplifies GRE
configuration on devices.
Perform the following operations on the Hub and Spokes.
Procedure
Step 3 Run ip address ip-address { mask | mask-length }
The IP address of the tunnel interface is configured.
Step 4 Run tunnel-protocol gre p2mp
The tunnel encapsulation mode is set to mGRE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Changing the encapsulation mode of a tunnel interface deletes other parameters of the tunnel
interface, including the source address or source interface configured for the tunnel interface,
and NHRP parameters.
Step 5 Run source { [ vpn-instance vpn-instance-name ] source-ip-address | interface-type

interface-number [ standby ] }
The source address or source interface is configured for the tunnel interface.
Changing the source command configuration will cause the IPSec configuration on the tunnel
interface to be deleted.
Step 6 (Optional) Run gre key { plain key-number | [ cipher ] plain-cipher-text }

The key number of a tunnel interface is set.
By default, no key number is set for a tunnel interface.
When multiple mGRE tunnel interfaces are configured with the same source address or source
interface, run this command to set a key number for each interface.
If plain is selected, the password is saved in the configuration file in plain text. This brings
----End
5.6.2 Configuring Routes
Context
The routes forwarded by a tunnel must be available on Spokes and the Hub so that packets
encapsulated with mGRE can be forwarded correctly. These routes can be static routes or
dynamic routes.
DSVPN supports the following route learning modes:
l Route learning between Spokes (non-shortcut)
tunnel address of the destination Spoke, and each Spoke needs to learn the route to the
remote end. This consumes many CPU and memory resources and requires large routing
tables and high performance on Spokes. In practice, the Spokes have low performance
and store a limited number of routes. The route learning solution applies to small- and
medium-sized networks where there are fewer network nodes and a small number of
routes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mGRE tunnels between Spokes are set up in non-shortcut mode.

l Spoke routes summarized to the Hub (shortcut mode)
tunnel address of the Hub, and Spokes only need to store routes to the Hub. The number
of routes of Spokes is reduced, so the route learning solution applies to large-sized
networks with many Spokes.
mGRE tunnels between Spokes are set up in shortcut mode.
Static routes and dynamic routing protocols can be deployed in the preceding two route
learning modes. DSVPN supports RIP, OSPF and BGP.
Perform the following configurations on the Hub and Spokes.
Procedure
l Configure a static route.
a. Run system-view
b. Run ip route-static ip-address { mask | mask-length } nexthop-address
[ description text ]
A static route is configured.
NOTE
l When Spokes learn routes from each other, the next-hop address of the static route from
a Spoke to the Hub or another Spoke is the tunnel address of the remote device.
l When routes of Spokes are summarized to the Hub, the next-hop address of the static
route from a Spoke to the Hub or another Spoke is the tunnel address of the Hub.
l Configuring a dynamic route
a. Run system-view
b. Configure a dynamic route.
Dynamic routes can be implemented using RIP, OSPF, or BGP. For the
configuration of a dynamic routing protocol, see Huawei
Series V300R003 Configuration Guide - IP Unicast Routing.
When configuring dynamic routing protocols, pay attention to the following points:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Scenario and RIP OSPF BGP

Routing
Protocol
Non-Shortcut Disable the split Configure the Route aggregation

Scenario of horizon and OSPF network cannot be
DSVPN automatic route type to multicast configured on the
aggregation using the ospf Hub.
functions on the network-type
mGRE interface broadcast
of the Hub. command on the
Hub and Spokes.
Shortcut Scenario Enable the split Configure the Configure route

of DSVPN horizon and OSPF network aggregation on
automatic route type to Point-to- the Hub.
aggregation Multipoint
functions on the (P2MP) using the
mGRE interface ospf network-
of the Hub. type p2mp
command on the
Hub and Spokes.
----End
5.6.3 Configuring NHRP
Context
NHRP enables a source Spoke on a public network to dynamically obtain the public network
address of a destination Spoke. When a Spoke connects to a public network, it sends NHRP
Registration Request packets to the Hub by using the public network address of the outbound
interface. The Hub creates or updates NHRP mapping entries based on the packets received.
Two Spokes exchange NHRP Resolution Request and Reply packets to create or update
NHRP mapping entries between them.
When configuring the NHRP authentication string, if simple is selected, the password is
saved in the configuration file in plain text. This brings security risks. It is recommended that
you select cipher to save the password in cipher text.
Perform the following operations on the Hub and Spokes.
Procedure
l Configure the Hub.
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
b. Run interface tunnel interface-number

c. (Optional) Run nhrp network-id number
An NHRP domain is configured for the tunnel interface.
By default, a tunnel interface belongs to NHRP domain 0.
d. Run nhrp entry multicast dynamic
The dynamically registered Spoke is added to the NHRP multicast member table.
By default, no dynamically registered Spoke is added to the NHRP multicast
member table.
e. Run nhrp authentication { simple string | cipher cipher-string }
The NHRP authentication string is configured.
By default, no NHRP authentication string is configured.
f. (Optional) Run nhrp entry holdtime seconds seconds
The aging time of NHRP mapping entries is configured.
By default, the aging time of NHRP mapping entries is 7200 seconds.
g. (Optional) Run nhrp redirect
The NHRP redirect function is enabled.
This configuration is required only when the shortcut mode is used. By default, the
NHRP redirect function is disabled.
h. (Optional) Run nhrp dscp dscp-value
The DSCP value of NHRP packets is set.
By default, the global DSCP value of NHRP packets is 48 (CS6).
In DSVPN scenarios, if the DSCP value of NHRP packets is small, NHRP packets
may be discarded when network congestion occurs, causing DSVPN tunnel
teardown. In this case, perform this step to configure a proper DSCP value to
provide preferential treatment to NHRP packets on the network.
NOTE
V300R003C10 and later versions support this command.
l Configure the Spokes.
a. Run system-view
c. (Optional) Run nhrp network-id number
An NHRP domain is configured for the tunnel interface.
By default, a tunnel interface belongs to NHRP domain 0.
d. Run nhrp entry protocol-address { dns-name | nbma-address } [ register
[ preference preference-value ] ] [ track apn apn-name ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An NHRP mapping entry is configured.

When the track apn parameter is specified, whether the NHRP mapping entry takes
effect depends on the APN status. If the APN is valid, the NHRP mapping entry
takes effect; otherwise, the configuration is saved but the NHRP mapping entry
does not take effect.
e. (Optional) Run nhrp registration no-unique
The device is configured to send NHRP packets that carry the no-unique flag to
instruct the remote end to overwrite conflicting NHRP peer entries.
By default, the device sends NHRP packets that do not carry the no-unique flag to
instruct the remote end not to overwrite conflicting NHRP peer entries.
f. Run nhrp authentication { simple string | cipher cipher-string }
The NHRP authentication string is configured.
By default, no NHRP authentication string is configured.
NOTE
If the NHRP authentication string is configured on the Hub, it must also be configured on
the Spoke.
g. (Optional) Run nhrp registration interval seconds
The NHRP registration interval is configured.
By default, a Spoke registers with the Hub at an interval of 1800 seconds.
h. (Optional) Run nhrp entry holdtime seconds seconds
The aging time of NHRP mapping entries is configured.
By default, the aging time of NHRP mapping entries is 7200 seconds.
i. (Optional) Run nhrp shortcut
The NHRP shortcut function is enabled.
This configuration is required only when the shortcut mode is used. By default, the
NHRP shortcut function is disabled.
j. (Optional) Run nhrp dynamic-entry track hub-entry
The dynamic NHRP mapping table of a Spoke is associated with the Hub status.
By default, the dynamic NHRP mapping table of a Spoke is not associated with the
Hub status.
If a Spoke detects that the Hub status becomes Down, the Spoke does not
immediately delete the dynamic NHRP mapping table. Then the tunnel between
Spokes is retained and traffic between Spokes remains uninterrupted until the
dynamic NHRP mapping table is aged out. If you want to remove this tunnel,
perform this step. Subsequently, if the Spoke detects that the Hub status becomes
Down, it immediately deletes the dynamic NHRP mapping table to remove the
tunnel.
k. (Optional) Run nhrp tunnel-if-state related
The mGRE interface status of a Spoke is associated with the Hub status.
By default, the mGRE interface status of a Spoke is not associated with the Hub
status.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
If you want to associate the mGRE interface status of a Spoke with the Hub status
for rapid fault detection on the monitor topology, that is, the mGRE interface
becomes Down when the Hub status is Down, and to enable the system to send an
email to instruct network administrators to rectify faults in a timely manner when
the mGRE interface becomes Down, perform this step.
NOTE
l. (Optional) Run nhrp dscp dscp-value
The DSCP value of NHRP packets is set.
By default, the global DSCP value of NHRP packets is 48 (CS6).
In DSVPN scenarios, if the DSCP value of NHRP packets is small, NHRP packets
may be discarded when network congestion occurs, causing DSVPN tunnel
teardown. In this case, perform this step to configure a proper DSCP value to
provide preferential treatment to NHRP packets on the network.
NOTE
----End
5.6.4 (Optional) Configuring DSVPN QoS
Context
In a DSVPN scenario, the headquarters or branch can perform QoS classification on traffic of
each tunnel for QoS management (traffic shaping and traffic policing). For example, the
headquarters performs QoS management on branch traffic:
l Configure an NHRP group on a branch.
The NHRP packet sent by the branch carries the NHRP group name. After receiving the
NHRP packet, the headquarters obtains the NHRP group name from the packet, records
the NHRP group name in an NHRP peer entry, and generates the mapping between the
IP address and QoS policy based on the locally configured NHRP group name and QoS
policy. In this way, the headquarters can perform QoS management on branch traffic.
l Create a matching rule based on the NHRP group in the QoS traffic classifier view on
the headquarters and configure the corresponding QoS policy.
The procedure is as follows:Configure a traffic classifier to match an NHRP group >
Configure a traffic behavior > Configure a traffic policy > Apply the traffic policy.
For details on QoS, see Huawei
V300R003 Configuration Guide - QoS Configuring MQC.
NOTE
V300R003C10 and later versions support this configuration.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 3 Run nhrp group group-name [ vendor-id vendor-id ]
An NHRP group is configured.
By default, no NHRP group is configured.
----End
5.6.5 (Optional) Configuring an IPSec Profile

Context
Data transmitted between the central office and a branch, and between branches can be
encrypted to increase data security. Binding an IPSec profile to DSVPN can dynamically
establish an mGRE over IPSec tunnel.
Before configuring an IPSec profile for DSVPN, you need to perform the following
operations:
l Create an IKE peer. For details, see 6.11.2 Configuring an IKE Peer.
l Create an IPSec proposal. For details, see 6.8.1 Configuring an IPSec Proposal.
After completing the preceding configuration, perform the following operations on the Hub
and Spokes.
Procedure
Step 2 Run ipsec profile profile-name
An IPSec profile is created and the IPSec profile view is displayed.
Step 3 Run ike-peer peer-name
An IKE peer is bound to the IPSec profile.
Step 4 Run proposal proposal-name
An IPSec proposal is bound to the IPSec profile.
Step 5 (Optional) Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-
group20 | dh-group21 }
The perfect forward secrecy (PFS) feature is used in IPSec negotiation.
By default, PFS is not used in IPSec negotiation.
If PFS is specified on the local end, you also need to specify PFS on the remote peer. The
Diffie-Hellman groups specified on the two ends must be the same. Otherwise, the negotiation
fails.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 6 Run quit
Step 8 Run tunnel-protocol gre p2mp
The tunnel encapsulation mode is configured.
The tunnel interface is bound to an IPSec profile.
----End
5.6.6 Verifying the DSVPN Configuration
Prerequisites
All DSVPN configurations have been completed.
Procedure
l Run the display nhrp peer command to check NHRP mapping entries.
l Run the display nhrp peer maximum-history command to check the history statistics
on NHRP peer entries.
l Run the display ipsec profile [ brief | name profile-name ] command to check the IPSec
profile configuration.
l Run the display ipsec sa profile profile-namecommand to check the information of
IPSec SA.
----End
5.7 Maintaining DSVPN
5.7.1 Clearing DSVPN Running Statistics
Context
Statistics cannot be restored after being cleared. Exercise caution when you run the command.
Procedure
l Run the reset nhrp statistics [ interface tunnel interface-number ] command in the user
view to clear NHRP packet statistics on a specified tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the reset nhrp peer maximum-history command in the user view to clear
historical statistics on NHRP peer entries.
----End
5.7.2 Monitoring DSVPN Running Statistics

Prerequisites
All DSVPN configurations have been completed.
Procedure
l Run the display nhrp statistics [ interface tunnel interface-number ] command to
check NHRP packet statistics.
l Run the display nhrp peer maximum-history command to check historical statistics on
NHRP peer entries.
----End
5.8 Configuration Examples for DSVPN
5.8.1 Example for Configuring Non-Shortcut Scenario of DSVPN

(Static Route)
A small enterprise has a central office (Hub) and two branches (Spoke1 and Spoke2) which
are located in different areas. The network between the Hub and Spokes is stable. The Spokes
use dynamic addresses to connect to the public network.
The enterprise wants to establish a VPN between the Spokes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-14 Networking diagram for the Non-Shortcut DSVPN configuration
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
Branch 2 Tunnel0/0/0
subnet 172.16.1.3/24
192.168.2.0/24
1. Because a Spoke uses a dynamic address to connect to the public network, it does not
know the public IP address of the other Spoke. DSVPN is implemented to establish a
VPN between the Spokes.
2. Non-Shortcut Scenario of DSVPN is implemented because the enterprise has a small
number of branches.
3. Static routes can be configured to realize communication between the Hub and Spokes
because the network is stable.
Procedure
Step 1 Assign an IP address to each interface.
Configure IP addresses for the interfaces of each Router.
# Configure IP addresses for interfaces of Hub.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub] interface loopback 0

[Hub-LoopBack0] ip address 192.168.0.1 255.255.255.0
[Hub-LoopBack0] quit
Configure IP addresses for interfaces of Spoke1 and Spoke2 as shown in Figure 5-14. The
specific configuration is not mentioned here.
Step 2 Configure routes between the Routers.
Configure OSPF on each Router to provide reachable routes to the public network.
# Configure OSPF on Hub.
[Hub] ospf 2 router-id 1.1.1.10
[Hub-ospf-2] quit

[Spoke1] ospf 2 router-id 1.1.2.10

Step 3 Configure static routes.

# Configure Hub.
[Hub] ip route-static 192.168.1.0 255.255.255.0 172.16.1.2
[Hub] ip route-static 192.168.2.0 255.255.255.0 172.16.1.3
# Configure Spoke1.
[Spoke1] ip route-static 192.168.0.0 255.255.255.0 172.16.1.1
# Configure Spoke2.

Configure tunnel interfaces on Hub and Spokes and configure static NHRP peer entries of
Spoke1 and Spoke2.
# Configure a tunnel interface on Hub.
# Configure a tunnel interface and a static NHRP peer entry of Hub on Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure a tunnel interface and a static NHRP mapping entry of Hub on Spoke2.
After the preceding configurations are complete, check the NHRP mapping entries of Spoke1
and Spoke2.
# Run the display nhrp peer all command on Spoke1. The command output is as follows:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the static
NHRP mapping entry of Hub.
On Hub, check the NHRP mapping entries of Spoke1 and Spoke2.
# Run the display nhrp peer all command on Hub. The command output is as follows:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 6 Check the static routes.
Check the static routes on Hub.
# Run the display ip routing-table protocol static command on Hub. The command output
is as follows:
[Hub] display ip routing-table protocol static
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Public routing table : Static
Destinations : 2 Routes : 2 Configured Routes : 2
Static routing table status : <Active>

192.168.1.0/24 Static 60 0 RD 172.16.1.2 Tunnel0/0/0

192.168.2.0/24 Static 60 0 RD 172.16.1.3 Tunnel0/0/0
Static routing table status : <Inactive>

Check the static routes on the Spokes.
# Run the display ip routing-table protocol static command on Spoke1. The command
output is as follows:
[Spoke1] display ip routing-table protocol static
------------------------------------------------------------------------------

192.168.0.0/24 Static 60 0 RD 172.16.1.1 Tunnel0/0/0

192.168.2.0/24 Static 60 0 RD 172.16.1.3 Tunnel0/0/0

# Run the display ip routing-table protocol static command on Spoke2. The command
[Spoke2] display ip routing-table protocol static
------------------------------------------------------------------------------

192.168.0.0/24 Static 60 0 RD 172.16.1.1 Tunnel0/0/0

192.168.1.0/24 Static 60 0 RD 172.16.1.2 Tunnel0/0/0


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 7 Run the ping command to check the configuration result.

Ping 192.168.2.1 on Spoke1. You can see that Spoke1 and Spoke2 have learned dynamic
NHRP mapping entries from each other.
# Run the ping -a 192.168.1.1 192.168.2.1 command on Spoke1. The command output is as
follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ospf 2 router-id 1.1.1.10
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
ip route-static 192.168.1.0 255.255.255.0 172.16.1.2
ip route-static 192.168.2.0 255.255.255.0 172.16.1.3
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
ip route-static 192.168.0.0 255.255.255.0 172.16.1.1
ip route-static 192.168.2.0 255.255.255.0 172.16.1.3
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
ip route-static 192.168.0.0 255.255.255.0 172.16.1.1
ip route-static 192.168.1.0 255.255.255.0 172.16.1.2
#
return

(RIP)
are located in different areas. The networks of the central office and branches frequently
change. The Spokes use dynamic addresses to connect to the public network. Routing
Information Protocol (RIP) is used on the enterprise network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
number of branches.
3. The networks of the central office and branches frequently change. RIP is deployed to
realize communication between the Hub and Spokes and to simplify maintenance.
Procedure


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Configure IP addresses for interfaces of the Spoke1 and Spoke2 as shown in Figure 5-15. The

[Hub-ospf-2] quit


Step 3 Configure the basic RIP functions.
# Configure Hub.
[Hub] rip 1
[Hub-rip-1] version 2
[Hub-rip-1] undo summary
[Hub-rip-1] network 172.16.0.0
[Hub-rip-1] quit
# Configure Spoke1.
[Spoke1] rip 1
[Spoke1-rip-1] version 2
[Spoke1-rip-1] network 172.16.0.0
[Spoke1-rip-1] quit
# Configure Spoke2.
[Spoke2] rip 1
[Spoke2-rip-1] quit
NOTE
The RIP configuration on a Spoke subnet is given as an example. Perform the same configuration on
other Spoke subnets.
When the subnet of a branch changes, you only need to configure the dynamic routing policy on the
local device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Configure route attributes on Hub to allow Spokes to learn routes from each other. Configure
static NHRP mapping entries of Hub on Spoke1 and Spoke2.
# Configure a tunnel interface and RIP on Hub.
[Hub-Tunnel0/0/0] undo rip split-horizon

and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
undo rip split-horizon
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
rip 1
undo summary
version 2
network 172.16.0.0
network 192.168.0.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
rip 1
version 2
network 172.16.0.0
network 192.168.1.0
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
rip 1
version 2
network 172.16.0.0
network 192.168.2.0
#
return

(OSPF)
are located in different areas. The networks of the central office and branches frequently
change. The Spokes use dynamic addresses to connect to the public network. Open Shortest
Path First (OSPF) is used on the enterprise network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
number of branches.
3. The networks of the central office and branches frequently change. OSPF is deployed to
Procedure
[Hub] interface GigabitEthernet 1/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[Hub-ospf-2] quit


Step 3 Configure the basic OSPF functions.
# Configure Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
The OSPF configuration on a Spoke subnet is given as an example. Perform the same configuration on
local device.

Set the OSPF network type to broadcast on Hub and Spokes to allow Spokes to learn routes
from each other. Configure static NHRP mapping entries of Hub on Spoke1 and Spoke2.
# Configure a tunnel interface and OSPF on Hub.
[Hub-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Hub-Tunnel0/0/0] ospf network-type broadcast
# On Spoke1, configure a tunnel interface, OSPF, and a static NHRP mapping entry of Hub.
[Spoke1-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Spoke1-Tunnel0/0/0] ospf network-type broadcast
[Spoke1-Tunnel0/0/0] ospf dr-priority 0
# On Spoke2, configure a tunnel interface, OSPF, and a static NHRP mapping entry of Hub.
[Spoke2-Tunnel0/0/0] ospf network-type broadcast
[Spoke2-Tunnel0/0/0] ospf dr-priority 0

and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Expire time : --
NOTE

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
ospf network-type broadcast
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
ospf dr-priority 0
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
ospf dr-priority 0
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return

(BGP)
are located in different areas and belong to different ASs. The networks of the central office
and branches frequently change. The Spokes use dynamic addresses to connect to the public
network. On the enterprise network, Open Shortest Path First (OSPF) is used for intra-AS
routing and External Border Gateway Protocol (EBGP) is used for inter-AS routing.
192.168.1.1/24
GE2/0/0 Tunnel0/0/0
172.16.1.2/24
Branch 1 subnet GE1/0/0
192.168.1.0/24
1.1.2.10/24
LoopBack0 AS 100
Spoke1 192.168.0.1/24
AS 200 GE1/0/0
1.1.1.10/24
Central office
Tunnel0/0/0 subnet
172.16.1.1/24 192.168.0.0/24
AS 300 Hub
Spoke2
Branch 2 GE1/0/0
subnet 1.1.3.10/24
192.168.2.0/24 Tunnel0/0/0
GE2/0/0 172.16.1.3/24
192.168.2.1/24
number of branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3. The networks of the central office and branches frequently change. BGP is deployed to
Procedure
[Hub-ospf-2] quit


Step 3 Configure reachable routes between the ASs.

Configure OSPF to implement reachable routes between Hub and Spokes that are located in
different ASs.
# Configure Hub.
[Hub-ospf-1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure Spoke1.
# Configure Spoke2.
Step 4 Configure Basic EBGP Functions

# Configure Hub.
[Hub] bgp 100
[Hub-bgp] router-id 172.16.1.1
[Hub-bgp] import-route ospf 1
[Hub-bgp] peer 172.16.1.2 as-number 200
[Hub-bgp] quit
# Configure Spoke1.
[Spoke1] bgp 200
[Spoke1-bgp] router-id 172.16.1.2
[Spoke1-bgp] import-route ospf 1
[Spoke1-bgp] peer 172.16.1.1 as-number 100
[Spoke1-bgp] quit
# Configure Spoke2.
[Spoke2] bgp 300
[Spoke2-bgp] quit
NOTE
The basic BGP configuration on a Spoke subnet is given as an example. Perform the same configuration
on other Spoke subnets.
local device.

Configure route attributes on Hub and Spokes to allow Spokes to learn routes from each other.
Configure static NHRP mapping entries of Hub on Spoke1 and Spoke2.
NOTE
In the non-shortcut scenario, configure BGP and set relevant attributes in the BGP view.
# Configure a tunnel interface on Hub.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE
When you run the display nhrp peer all command, you can view the static NHRP mapping entries of
Hub and dynamic NHRP mapping entries of each other on Spoke1 and Spoke2. Exchange of BGP
packets triggers the Spokes to establish a dynamic tunnel.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
On Spoke1, ping the subnet address 192.168.2.1 of Spoke2.
follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
bgp 100
router-id 172.16.1.1
#
ipv4-family unicast
import-route ospf 1
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
#
bgp 200
#
ipv4-family unicast
import-route ospf 1
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
#
bgp 300
#
ipv4-family unicast
import-route ospf 1
#
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5.8.5 Example for Configuring Shortcut Scenario of DSVPN (RIP)
A large-scale enterprise has a central office (Hub) and multiple branches which are located in
different areas (this example shows only two Spokes Spoke1 and Spoke2). The networks of
the central office and branches frequently change. The Spokes use dynamic addresses to
connect to the public network. Routing Information Protocol (RIP) is used on the enterprise
network.
Figure 5-18 Networking diagram for the Shortcut DSVPN configuration
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
2. Shortcut Scenario of DSVPN is implemented because the enterprise has a large number
of branches.
3. The networks of the central office and branches frequently change. RIP is deployed to

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
[Hub-ospf-2] quit


Step 3 Configure the basic RIP functions.

# Configure Hub.
[Hub] rip 1
[Hub-rip-1] version 2
[Hub-rip-1] quit
# Configure Spoke1.
[Spoke1] rip 1
[Spoke1-rip-1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure Spoke2.
[Spoke2] rip 1
[Spoke2-rip-1] quit
NOTE
The RIP configuration on a Spoke subnet is given as an example. Perform the same configuration on
local device.

Configure RIP-2 route summarization on Hub and RIP-2 on the Spokes, so that the Spokes
have reachable routes to Hub. Enable the NHRP redirect function on Hub. Configure NHRP
mapping entries of Hub and enable the NHRP shortcut function on Spoke1 and Spoke2.
# On Hub, configure a tunnel interface, configure RIP, and enable the NHRP redirect
function.
[Hub-Tunnel0/0/0] rip version 2 multicast
[Hub-Tunnel0/0/0] rip summary-address 192.168.0.0 255.255.0.0
[Hub-Tunnel0/0/0] nhrp redirect
NOTE
When configuring route summarization, the specified summarized address must exist on the local
device. Therefore, a LoopBack address must be configured.
# On Spoke1, configure a tunnel interface, RIP, and a static NHRP mapping entry of Hub, and
enable the NHRP shortcut function.
[Spoke1-Tunnel0/0/0] rip version 2 multicast
[Spoke1-Tunnel0/0/0] nhrp shortcut
# On Spoke2, configure a tunnel interface, RIP, and a static NHRP mapping entry of Hub, and
[Spoke2-Tunnel0/0/0] rip version 2 multicast

and Spoke2.
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
192.168.2.1 32 1.1.3.10 172.16.1.3 remote-network up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
rip version 2 multicast
rip summary-address 192.168.0.0 255.255.0.0
nhrp redirect
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
rip 1
version 2
network 172.16.0.0
network 192.168.0.0
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
nhrp shortcut
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
rip 1
version 2
network 172.16.0.0
network 192.168.1.0
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
rip 1
version 2
network 172.16.0.0
network 192.168.2.0
#
return
5.8.6 Example for Configuring Shortcut Scenario of DSVPN

(OSPF)
connect to the public network. Open Shortest Path First (OSPF) is used on the enterprise
network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
of branches.
Procedure


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[Hub-ospf-2] quit


# Configure Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
The OSPF configuration on a Spoke subnet is given as an example. Perform the same configuration on
local device.

Configure the OSPF network type to Point-to-Multipoint (P2MP) on Hub and Spokes. Enable
the NHRP redirect function on Hub. Configure NHRP mapping entries of Hub and enable the
NHRP shortcut function on Spoke1 and Spoke2.
# On Hub, configure a tunnel interface, configure OSPF, and enable the NHRP redirect
function.
[Hub-Tunnel0/0/0] ospf network-type p2mp
# On Spoke1, configure a tunnel interface, OSPF, and a static NHRP mapping entry of Hub,
and enable the NHRP shortcut function.
[Spoke1-Tunnel0/0/0] ospf network-type p2mp

and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.8.7 Example for Configuring Shortcut Scenario of DSVPN

(BGP)
different areas and belong to different ASs (this example shows only two Spokes Spoke1 and
Spoke2). The networks of the central office and branches frequently change. The Spokes use
dynamic addresses to connect to the public network. On the enterprise network, Open Shortest
Path First (OSPF) is used for intra-AS routing and External Border Gateway Protocol (EBGP)
is used for inter-AS routing.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
192.168.1.1/24
GE2/0/0 Tunnel0/0/0
172.16.1.2/24
Branch 1 subnet GE1/0/0
192.168.1.0/24
1.1.2.10/24
AS 100
Spoke1
AS 200 GE1/0/0
1.1.1.10/24
Central office
Tunnel0/0/0 subnet
172.16.1.1/24 192.168.0.0/24
AS 300 Hub
Spoke2
Branch 2 GE1/0/0
subnet 1.1.3.10/24
192.168.2.0/24 Tunnel0/0/0
GE2/0/0 172.16.1.3/24
192.168.2.1/24
of branches.
3. The networks of the central office and branches frequently change. BGP is deployed to
Procedure


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub-ospf-2] quit


Step 3 Configure reachable routes between the ASs.

Configure OSPF to implement reachable routes between Hub and Spokes that are located in
different ASs.
# Configure Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.
NOTE
The BGP configuration on a Spoke subnet is given as an example. Perform the same configuration on
local device.
Step 4 Configure Basic EBGP Functions

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure Hub.
[Hub] bgp 100
[Hub-bgp] router-id 172.16.1.1
[Hub-bgp] import-route ospf 1
[Hub-bgp] aggregate 192.168.0.0 16 detail-suppressed
[Hub-bgp] quit
# Configure Spoke1.
[Spoke1] bgp 200
[Spoke1-bgp] quit
# Configure Spoke2.
[Spoke2] bgp 300
[Spoke2-bgp] quit

Configure route attributes on Hub and Spokes to ensure that the routes from the Spokes to
Hub are reachable. Enable the NHRP redirect function on Hub. Configure NHRP mapping
entries of Hub and enable the NHRP shortcut function on Spoke1 and Spoke2.
NOTE
In the shortcut scenario, configure BGP and set relevant attributes in the BGP view.
# On Hub, configure a tunnel interface and enable the NHRP redirect function.
# On Spoke1, configure a tunnel interface and a static NHRP mapping entry of Hub, and
# On Spoke2, configure a tunnel interface and a static NHRP mapping entry of Hub, and

and Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
bgp 100
#
ipv4-family unicast
aggregate 192.168.0.0 255.255.0.0 detail-suppressed
import-route ospf 1
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

nhrp shortcut
#
bgp 200
#
ipv4-family unicast
import-route ospf 1
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return
#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
#
bgp 300
#
ipv4-family unicast
import-route ospf 1
#
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.8.8 Example for Configuring DSVPN NAT traversal

An enterprise has a central office (Hub) and multiple branches which are located in different
areas (this example shows only two Spokes Spoke1 and Spoke2). The subnets of the branches

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
frequently change. The Spokes use addresses translated by NAT devices to connect to the
public network. Open Shortest Path First (OSPF) is used on the enterprise network.
Figure 5-21 Networking diagram for DSVPN NAT traversal configuration
Branch 1 subnet Tunnel0/0/0

192.168.1.0/24 172.16.1.2/24
GE1/0/0
10.1.1.1/24 NAT1
10.1.1.1→1.1.2.10
Spoke1 GE1/0/0
LoopBack0
LoopBack0 192.168.0.1/24
GE2/0/0 1.1.2.1/24
192.168.1.1/24 10.1.1.254/24 GE1/0/0
1.1.1.10/24 Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 GE2/0/0 172.16.1.1/24
192.168.2.1/24 10.2.2.254/24 GE1/0/0 Hub
1.1.3.1/24
Spoke2 NAT2
GE1/0/0 10.2.2.2→1.1.3.10
10.2.2.2/24
Tunnel0/0/0
Branch 2 subnet
172.16.1.3/24
192.168.2.0/24
1. Because a Spoke uses a translated address to connect to the public network, it does not
know the translated public address of the other Spoke. DSVPN NAT traversal is
implemented to establish a VPN between the Spokes.
of branches.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[Hub-ospf-2] quit
# Configure OSPF on NAT1.

[NAT1] ospf 2 router-id 1.1.2.1
[NAT1] import-route unr
[NAT1-ospf-2] area 0.0.0.1
[NAT1-ospf-2-area-0.0.0.1] network 1.1.2.0 0.0.0.255
[NAT1-ospf-2-area-0.0.0.1] quit
[NAT1-ospf-2] quit
# Configure OSPF on NAT2.

[NAT2] ospf 2 router-id 1.1.3.1
[NAT2] import-route unr
[NAT2-ospf-2] area 0.0.0.1
[NAT2-ospf-2-area-0.0.0.1] quit
[NAT2-ospf-2] quit


Step 3 Configure NAT.
Configure addresses before and after NAT traversal.
# Configure NAT1.
[NAT1] interface GigabitEthernet 1/0/0
[NAT1-GigabitEthernet1/0/0] nat server global 1.1.2.10 inside 10.1.1.1
# Configure NAT2.
[NAT2] interface GigabitEthernet 1/0/0
[NAT2-GigabitEthernet1/0/0] nat server global 1.1.3.10 inside 10.2.2.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
The NAT devices must be configured with an NAT server or static NAT. NAT traversal cannot be
implemented if outbound NAT is configured on the NAT devices.

# Configure Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.

Configure the OSPF network type to Point-to-Multipoint (P2MP) on Hub and Spokes. Enable
the NHRP redirect function on Hub. Configure NHRP mapping entries of Hub and enable the
NHRP shortcut function on Spoke1 and Spoke2.
# On Hub, configure a tunnel interface, configure OSPF, and enable the NHRP redirect
function.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


and Spoke2.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Before NAT NBMA-addr: 10.2.2.2
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
192.168.1.1 32 10.1.1.1 172.16.1.2 local up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
192.168.2.1 32 10.2.2.2 172.16.1.3 local up
-------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Hub
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
area 0.0.0.1
network 10.1.1.0 0.0.0.255
#
return
#
sysname Spoke2
#
ip address 10.2.2.2 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
area 0.0.0.1
network 10.2.2.0 0.0.0.255
#
return
l NAT1 configuration file
#
sysname NAT1
#
ip address 1.1.2.1 255.255.255.0
nat server global 1.1.2.10 inside 10.1.1.1
#
ip address 10.1.1.254 255.255.255.0
#
import-route unr
area 0.0.0.1
network 10.1.1.0 0.0.0.255
network 1.1.2.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
l NAT2 configuration file

#
sysname NAT2
#
ip address 1.1.3.1 255.255.255.0
nat server global 1.1.3.10 inside 10.2.2.2
#
ip address 10.2.2.254 255.255.255.0
#
import-route unr
area 0.0.0.1
network 10.2.2.0 0.0.0.255
network 1.1.3.0 0.0.0.255
#
return
5.8.9 Example for Configuring Dual Hubs in Active/Standby

Mode
A large-scale enterprise has a central office (Hub1 and Hub2) and multiple branches which
are located in different areas (this example shows only two Spokes Spoke1 and Spoke2). The
networks of the central office and branches frequently change. The Spokes use dynamic
addresses to connect to the public network. Open Shortest Path First (OSPF) is used on the
enterprise network.
The enterprise wants to establish a VPN between the Spokes. Hub1 functions as the master
device and Hub2 functions as the backup device. Hub2 takes over the services and forwards
protocol packets if Hub1 fails. When Hub1 recovers, services are switched back to Hub1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-22 Networking diagram for dual-Hub DSVPN configuration
Branch 1 subnet Tunnel0/0/0

192.168.1.0/24 172.16.1.2/24 LoopBack0
GE1/0/0 192.168.0.1/24
1.1.2.10/24 Tunnel0/0/0
172.16.1.1/24
Spoke1 GE1/0/0
LoopBack0 1.1.1.10/24
192.168.1.1/24 Hub1
Central office
subnet
192.168.0.0/24
LoopBack0 Hub2
192.168.2.1/24 GE1/0/0
1.1.254.10/24
Spoke2
Tunnel0/0/0
GE1/0/0 172.16.1.254/24
1.1.3.10/24
LoopBack0
Tunnel0/0/0 192.168.0.2/24
Branch 2 subnet 172.16.1.3/24
192.168.2.0/24
of branches.
4. Dual-Hub DSVPN is implemented to provide redundant backup by using Hub2.
Procedure
# Configure IP addresses for interfaces of Hub1.
[Huawei] sysname Hub1
[Hub1] interface GigabitEthernet 1/0/0
[Hub1-GigabitEthernet1/0/0] ip address 1.1.1.10 255.255.255.0
[Hub1-GigabitEthernet1/0/0] quit
[Hub1] interface tunnel 0/0/0
[Hub1-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub1-Tunnel0/0/0] quit
[Hub1] interface loopback 0
[Hub1-LoopBack0] ip address 192.168.0.1 255.255.255.0
[Hub1-LoopBack0] quit
Configure IP addresses for interfaces of the Spoke1, Spoke2 and Hub2 as shown in Figure
5-22. The specific configuration is not mentioned here.
# Configure OSPF on Hub1.
[Hub1] ospf 2 router-id 1.1.1.10
[Hub1-ospf-2] area 0.0.0.1
[Hub1-ospf-2-area-0.0.0.1] network 1.1.1.0 0.0.0.255
[Hub1-ospf-2-area-0.0.0.1] quit
[Hub1-ospf-2] quit

[Hub2-ospf-2] quit


Step 3 Configure basic OSPF functions.

# Configure Hub1.
[Hub1-ospf-1] quit
# Configure the basic OSPF functions on Hub2.

[Hub2-ospf-1] quit
# Configure Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure Spoke2.

Configure the OSPF network type to Point-to-Multipoint (P2MP) on Hubs and Spokes.
Enable the NHRP redirect function on Hub1 and Hub2. Configure NHRP mapping entries of
Hubs and enable the NHRP shortcut function on Spoke1 and Spoke2.
# Configure a tunnel interface and OSPF on Hub1 and enable the NHRP redirect function.
[Hub1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Hub1-Tunnel0/0/0] source GigabitEthernet 1/0/0
[Hub1-Tunnel0/0/0] nhrp entry multicast dynamic
[Hub1-Tunnel0/0/0] ospf network-type p2mp
[Hub1-Tunnel0/0/0] ospf cost 1000
[Hub1-Tunnel0/0/0] nhrp redirect
# Configure a tunnel interface and OSPF on Hub2 and enable the NHRP redirect function.
[Hub2-Tunnel0/0/0] ospf cost 3000
# Configure a tunnel interface, OSPF, and a static NHRP mapping entry of Hubs on Spoke1,
[Spoke1-Tunnel0/0/0] nhrp registration interval 300
# Configure a tunnel interface, OSPF, and a static NHRP mapping entry of Hubs on Spoke2,

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l Configure different OSPF cost values on Hub1 and Hub2 to ensure that the Spokes prefer Hub1 as
the next hop device.
l When Hub1 recovers, it restarts to forward OSPF protocol packets when receiving NHRP
Registration Request packets from Spokes. The Spokes learn routes to Hub1 after the routes they
have already learned are aged out. Set the interval for sending NHRP Registration Request packets
to a proper value to ensure that the Spokes can quick detect Hub1 recovery. The interval is set to
1800 seconds by default.

After the preceding configurations are complete, check the NHRP mapping entries of Spoke
and Hub. Take Spoke1 as an example.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.254 32 1.1.254.10 172.16.1.254 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE
# Run the ping -a 192.168.1.1 192.168.2.1 command on Spoke. Take Spoke1 as an example.
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss

-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.254 32 1.1.254.10 172.16.1.254 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
192.168.1.1 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
Step 7 Shutdown the physical interface GE1/0/0 of Hub1.

# Run the shutdown command on GE1/0/0 of Hub1.
[Hub1-GigabitEthernet1/0/0] shutdown
Before you run the ping command, ensure that no default route to Hub1 exists on the local
device.
# Run the ping -a 192.168.1.1 192.168.2.1 command on Spoke1.

[Spoke1] ping -a 192.168.1.1 192.168.2.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


0.00% packet loss
# Run the display nhrp peer all command on Spoke. Take Spoke1 as an example.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub down
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.254 32 1.1.254.10 172.16.1.254 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
192.168.1.1 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
NOTE
Run the undo nhrp peer command to clear the NHRP mapping entries existing on the Spokes before
running the ping command.
----End
Configuration Files
l Hub1 configuration file

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname Hub1
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
ospf cost 1000
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return
#
sysname Hub2
#
ip address 1.1.254.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.2 255.255.255.0
#
ip address 172.16.1.254 255.255.255.0
ospf cost 3000
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.254.0 0.0.0.255
#
return
#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 172.16.1.2 255.255.255.0

nhrp shortcut
nhrp registration interval 300
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
nhrp registration interval 300
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.8.10 Example for Configuring DSVPN Protected by IPSec

connect to the public network. Open Shortest Path First (OSPF) is used on the enterprise
network.
The enterprise wants to establish a VPN between the Spokes and encrypt data transmitted
between the Hub and Spokes, and between Spokes to increase data security.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-23 Networking diagram for DSVPN protected by IPSec configuration
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
of branches.
4. DSVPN protected by IPSec is implemented to encrypt data transmitted between the
central office and branches, and between branches.
NOTE
When you deploy IPSec on a DSVPN network, the IPSec encapsulation mode can only be transport if
two branches are connected to different NAT devices or the headquarters is connected to a NAT device.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Hub-ospf-2] quit



# Configure Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 Configure IKE proposals.

On Hub, Spoke1, and Spoke2, configure IKE proposals and set the same authentication mode.
# Configure Hub.
[Hub] ike proposal 1
[Hub-ike-proposal-1] dh group5
[Hub-ike-proposal-1] authentication-algorithm sha2-256
[Hub-ike-proposal-1] prf aes-xcbc-128
[Hub-ike-proposal-1] quit
# Configure Spoke1.
[Spoke1] ike proposal 1
[Spoke1-ike-proposal-1] dh group5
[Spoke1-ike-proposal-1] authentication-algorithm sha2-256
[Spoke1-ike-proposal-1] prf aes-xcbc-128
[Spoke1-ike-proposal-1] quit
# Configure Spoke2.
Step 5 Configure IKE peers.

Configure IKE peers used during IKE negotiation on Hub, Spoke1, and Spoke2.
# Configure Hub.
[Hub] ike peer hub
[Hub-ike-peer-hub] ike-proposal 1
[Hub-ike-peer-hub] pre-shared-key cipher Huawei@1234
[Hub-ike-peer-hub] dpd type periodic
[Hub-ike-peer-hub] dpd idle-time 40
[Hub-ike-peer-hub] quit
# Configure Spoke1.
[Spoke1] ike peer spoke1
[Spoke1-ike-peer-spoke1] ike-proposal 1
[Spoke1-ike-peer-spoke1] pre-shared-key cipher Huawei@1234
[Spoke1-ike-peer-spoke1] dpd type periodic
[Spoke1-ike-peer-spoke1] dpd idle-time 40
[Spoke1-ike-peer-spoke1] quit
# Configure Spoke2.
Step 6 Create IPSec proposals.

Configure IPSec proposals on Hub, Spoke1, and Spoke2.
# Configure Hub.
[Hub] ipsec proposal pro1
[Hub-ipsec-proposal-pro1] transform ah-esp
[Hub-ipsec-proposal-pro1] ah authentication-algorithm sha2-256
[Hub-ipsec-proposal-pro1] esp authentication-algorithm sha2-256

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub-ipsec-proposal-pro1] esp encryption-algorithm aes-192

[Hub-ipsec-proposal-pro1] quit
# Configure Spoke1.
[Spoke1] ipsec proposal pro1
[Spoke1-ipsec-proposal-pro1] transform ah-esp
[Spoke1-ipsec-proposal-pro1] ah authentication-algorithm sha2-256
[Spoke1-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Spoke1-ipsec-proposal-pro1] esp encryption-algorithm aes-192
[Spoke1-ipsec-proposal-pro1] quit
# Configure Spoke2.
Step 7 Configure IPSec profiles.
Configure IPSec profiles on Hub, Spoke1, and Spoke2.
# Configure Hub.
[Hub] ipsec profile profile1
[Hub-ipsec-profile-profile1] ike-peer hub
[Hub-ipsec-profile-profile1] proposal pro1
[Hub-ipsec-profile-profile1] quit
# Configure Spoke1.
[Spoke1] ipsec profile profile1
[Spoke1-ipsec-profile-profile1] ike-peer spoke1
[Spoke1-ipsec-profile-profile1] proposal pro1
[Spoke1-ipsec-profile-profile1] quit
# Configure Spoke2.
# On Hub, configure a tunnel interface, configure OSPF, and apply the IPSec profile.
[Hub-Tunnel0/0/0] ipsec profile profile1
and apply the IPSec profile.
[Spoke1-Tunnel0/0/0] ipsec profile profile1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
and apply the IPSec profile.
Step 9 Verify the DSVPN configuration.

and Spoke2.
# Run the display nhrp peer all command on Spoke and Hub. Take Spoke1 as an example.
The command output is as follows:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
NOTE
Step 10 Verify the IPSec SA configuration.

Check the IPSec SAs generated on Hub, Spoke1, and Spoke2. Take Spoke1 as an example.
# Run the display ipsec sa command on Spoke1. The command output is as follows:
[Spoke1] display ipsec sa
ipsec sa information:
===============================
===============================
-----------------------------
IPSec profile name: "profile1"
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 2
Encapsulation mode: Tunnel
Tunnel local : 1.1.2.10:500
Tunnel remote : 1.1.1.10:500
[Outbound ESP SAs]

SPI: 2485560141 (0x9426a34d)
Proposal: ESP-ENCRYPT-AES-192 SHA2-512-256
SA remaining key duration (bytes/sec): 1887426800/2652
Outpacket count : 8
Outpacket encap count : 8
Outpacket drop count : 0
Max sent sequence-number: 107
UDP encapsulation used for NAT traversal: N

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Outbound AH SAs]
SPI: 3662509166 (0xda4d746e)
Proposal: SHA2-512-256
Outpacket count : 8
[Inbound AH SAs]
SPI: 833505824 (0x31ae4a20)
Inpacket count : 10
Inpacket decap count : 10
Inpacket drop count : 0
Max received sequence-number: 119
Anti-replay : Enable
[Inbound ESP SAs]

SPI: 2140030022 (0x7f8e4446)
Inpacket count : 10

follows:
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
# Run the display nhrp peer all command on Spoke. Take Spoke1 as an example. The
command output is as follows:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.1 32 1.1.1.10 172.16.1.1 hub up
-------------------------------------------------------------------------------
Expire time : --
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.3 32 1.1.3.10 172.16.1.3 remote up
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.16.1.2 32 1.1.2.10 172.16.1.2 local up
-------------------------------------------------------------------------------
# Run the display ipsec sa command on Spoke. Take Spoke1 as an example. The command
[Spoke1] display ipsec sa
===============================
===============================
-----------------------------
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 2
[Outbound ESP SAs]

SPI: 2485560141 (0x9426a34d)
Outpacket count : 8
[Outbound AH SAs]
SPI: 3662509166 (0xda4d746e)
Outpacket count : 8
[Inbound AH SAs]
SPI: 833505824 (0x31ae4a20)
Inpacket count : 10

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Inbound ESP SAs]

SPI: 2140030022 (0x7f8e4446)
Inpacket count : 10
-----------------------------
Mode : PROF-ISAKMP
-----------------------------
Connection ID : 5
[Outbound ESP SAs]

SPI: 576349831 (0x225a6687)
Outpacket count : 8
[Outbound AH SAs]
SPI: 3363305474 (0xc877f802)
Outpacket count : 8
[Inbound AH SAs]
SPI: 3753703982 (0xdfbcfa2e)
Inpacket count : 10
[Inbound ESP SAs]

SPI: 3361785078 (0xc860c4f6)
Inpacket count : 10

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
----End
Configuration Files
#
sysname Hub
#
ipsec proposal pro1
transform ah-esp
ah authentication-algorithm sha2-256
#
ike proposal 1
encryption-algorithm
aes-256
dh
group5
authentication-method pre-
share
integrity-algorithm hmac-
sha2-256
prf aes-xcbc-128
#
ike peer hub
pre-shared-key cipher %^%#O3uIP\/YNF+`AcJhbZ&C7y*iVlOOU@DraF58J4=;%^%#
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
ipsec profile profile1
ike-peer hub
proposal pro1
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

#
sysname Spoke1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipsec proposal pro1
transform ah-esp
#
ike proposal 1
aes-256
dh
group5
share
sha2-256
prf aes-xcbc-128
#
ike peer spoke1
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
ike-peer spoke1
proposal pro1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return
#
sysname Spoke2
#
ipsec proposal pro1
transform ah-esp
#
ike proposal 1
aes-256
dh
group5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
share
sha2-256
prf aes-xcbc-128
#
ike peer spoke2
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
ike-peer spoke2
proposal pro1
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.8.11 Example for Configuring a Dual-Hub DSVPN Protected by

IPSec
In a large-size enterprise, two hubs (Hub1 and Hub2) in the headquarters communicate with
multiple branches (Spoke1 and Spoke2 in this example) over the Internet. Spokes in branches
use dynamic addresses to connect to the Internet.
The enterprise wants to protect traffic exchanged between the headquarters and branch and
has the following requirements: Normally, the branch should communicate with the
headquarters through Hub1. Traffic should be switched to Hub2 when Hub1 becomes faulty
but back to Hub1 when Hub1 recovers.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-24 Configuring a dual-hub DSVPN protected by IPSec
10.1.1.0/24 10.2.1.2/24 LoopBack0
GE1/0/0 10.1.0.1/24
1.1.2.10/24 Tunnel0/0/0
10.2.1.1/24
Spoke1 GE1/0/0
LoopBack0 1.1.1.10/24
10.1.1.1/24
Hub1
Headquarters
10.1.0.0/24
LoopBack0 Hub2
10.1.2.1/24 GE1/0/0
1.1.254.10/24
Spoke2
Tunnel0/0/0
GE1/0/0 10.2.1.4/24
1.1.3.10/24
LoopBack0
Branch 2 Tunnel0/0/0 10.1.0.2/24
10.1.2.0/24 10.2.1.3/24
1. Branches use dynamic addresses to connect to the Internet; therefore, they do not know
the public addresses of each other. Configure DSVPN to implement direct
communication between branches.
2. Use the shortcut DSVPN because there are a large number of branches.
3. Subnets of the headquarters and branches frequently change. To simplify maintenance,
configure OSPF based on the enterprise network plan to enable communication between
the headquarters and branches.
4. To protect data transmitted between the headquarters and branch as well as between
branches, configure IPSec for DSVPN.
Procedure
Step 1 Configure IP addresses for interfaces.
Configure IP addresses for the interfaces of each Router. The configurations of Spoke1,
Spoke2, and Hub2 are similar to that of Hub1, and are not mentioned here.
# Configure an IP address for each interface on Hub1.
[Huawei] sysname Hub1
[Hub1-GigabitEthernet1/0/0] ip address 1.1.1.10 255.255.255.0
[Hub1-Tunnel0/0/0] ip address 10.2.1.1 255.255.255.0
[Hub1] interface loopback 0
[Hub1-LoopBack0] ip address 10.1.0.1 255.255.255.0
[Hub1-LoopBack0] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Configure OSPF on each Router to enable reachable routes over the Internet.
[Hub1-ospf-2] quit

[Hub2-ospf-2] quit



# Configure Hub1.
[Hub1-ospf-1] quit
# Configure Hub2.
[Hub2-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Set the OSPF network type to p2mp on the hubs and spokes. Enable NHRP redirect on Hub1
and Hub2. Configure static NHRP peer entries of Hub1 and Hub2 and enable NHRP shortcut
on Spoke1 and Spoke2.
# Configure a tunnel interface and OSPF attributes and enable NHRP redirect on Hub1.
[Hub1-Tunnel0/0/0] nhrp authentication cipher huawei@1
[Hub1-Tunnel0/0/0] gre key cipher 1999
# Configure a tunnel interface and OSPF attributes and enable NHRP redirect on Hub2.
[Hub2-Tunnel0/0/0] nhrp authentication cipher huawei@1
[Hub2-Tunnel0/0/0] gre key cipher 1999
# Configure tunnel interfaces, OSPF attributes, and static NHRP peer entries of Hub1 and
Hub2, and enable NHRP shortcut on Spoke1.
[Spoke1-Tunnel0/0/0] nhrp authentication cipher huawei@1
[Spoke1-Tunnel0/0/0] gre key cipher 1999
# Configure tunnel interfaces, OSPF attributes, and static NHRP peer entries of Hub1 and
Hub2, and enable NHRP shortcut on Spoke2.
[Spoke2-Tunnel0/0/0] nhrp authentication cipher huawei@1
[Spoke2-Tunnel0/0/0] gre key cipher 1999
Step 5 Configure an IKE proposal.
Configure an IKE proposal on the hubs and spokes. Ensure that the authentication mode is the
same on all the devices.
# Configure Hub1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub1] ike proposal 1

[Hub1-ike-proposal-1] dh group5
[Hub1-ike-proposal-1] encryption-algorithm aes-256
[Hub1-ike-proposal-1] authentication-algorithm sha2-256
[Hub1-ike-proposal-1] prf aes-xcbc-128
[Hub1-ike-proposal-1] quit
# Configure Hub2.
[Hub2] ike proposal 1
[Hub2-ike-proposal-1] dh group5
[Hub2-ike-proposal-1] encryption-algorithm aes-256
[Hub2-ike-proposal-1] authentication-algorithm sha2-256
[Hub2-ike-proposal-1] prf aes-xcbc-128
[Hub2-ike-proposal-1] quit
# Configure Spoke1.
[Spoke1-ike-proposal-1] encryption-algorithm aes-256
# Configure Spoke2.
Configure an IKE peer for IKE negotiation on the hubs and spokes.
# Configure Hub1.
[Hub1] ike peer hub1
[Hub1-ike-peer-hub1] undo version 2
[Hub1-ike-peer-hub1] ike-proposal 1
[Hub1-ike-peer-hub1] pre-shared-key cipher Huawei@1234
[Hub1-ike-peer-hub1] dpd type periodic
[Hub1-ike-peer-hub1] dpd idle-time 40
[Hub1-ike-peer-hub1] quit
# Configure Hub2.
[Hub2] ike peer hub2
[Hub2-ike-peer-hub2] undo version 2
[Hub2-ike-peer-hub2] ike-proposal 1
[Hub2-ike-peer-hub2] pre-shared-key cipher Huawei@1234
[Hub2-ike-peer-hub2] dpd type periodic
[Hub2-ike-peer-hub2] dpd idle-time 40
[Hub2-ike-peer-hub2] quit
# Configure Spoke1.
[Spoke1-ike-peer-spoke1] undo version 2
# Configure Spoke2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


Create an IPSec proposal on the hubs and spokes.
# Configure Hub1.
[Hub1] ipsec proposal pro1
[Hub1-ipsec-proposal-pro1] transform ah-esp
[Hub1-ipsec-proposal-pro1] ah authentication-algorithm sha2-256
[Hub1-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Hub1-ipsec-proposal-pro1] esp encryption-algorithm aes-192
[Hub1-ipsec-proposal-pro1] quit
# Configure Hub2.
[Hub2] ipsec proposal pro1
[Hub2-ipsec-proposal-pro1] transform ah-esp
[Hub2-ipsec-proposal-pro1] ah authentication-algorithm sha2-256
[Hub2-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Hub2-ipsec-proposal-pro1] esp encryption-algorithm aes-192
[Hub2-ipsec-proposal-pro1] quit
# Configure Spoke1.
# Configure Spoke2.
Step 8 Create an IPSec profile.

Create an IPSec profile on the hubs and spokes.
# Configure Hub1.
[Hub1] ipsec profile profile1
[Hub1-ipsec-profile-profile1] ike-peer hub1
[Hub1-ipsec-profile-profile1] proposal pro1
[Hub1-ipsec-profile-profile1] quit
# Configure Hub2.
[Hub2] ipsec profile profile1
[Hub2-ipsec-profile-profile1] ike-peer hub2
[Hub2-ipsec-profile-profile1] proposal pro1
[Hub2-ipsec-profile-profile1] quit
# Configure Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure Spoke2.
Step 9 Apply the IPSec profile to interfaces.

# Configure Hub1.
[Hub1-Tunnel0/0/0] ipsec profile profile1
# Configure Hub2.
[Hub2-Tunnel0/0/0] ipsec profile profile1
# Configure Spoke1.
# Configure Spoke2.

The headquarters and branch as well as branches can communicate with each other, and data
flows between them are protected by IPSec.
1. Check whether IKE SAs are established.
Run the display ike sa command to check whether IKE SAs are established. The
command output on Hub1 and Spoke1 is used as an example.
[Spoke1] display ike sa
Conn-ID Peer VPN Flag(s)
Phase
---------------------------------------------------------------
442 1.1.1.10 0 RD|ST
v1:2
138 1.1.1.10 0 RD|ST
v1:1
409 1.1.254.10 0 RD|ST
v1:2
5 1.1.254.10 0 RD|ST
v1:1
Number of IKE SA : 4
--------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
You can find that Spoke1 establishes IPSec tunnels with Hub1 and Hub2 successfully.
# Run the ping -a 10.1.1.1 10.1.2.1 command on Spoke1, and the command output is as
follows.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Spoke1] ping -a 10.1.1.1 10.1.2.1


0.00% packet loss
Conn-ID Peer VPN Flag(s)
Phase
---------------------------------------------------------------
442 1.1.1.10 0 RD|ST
v1:2
138 1.1.1.10 0 RD|ST
v1:1
342 1.1.3.10 0 RD|ST
v1:2
284 1.1.3.10 0 RD|ST
v1:1
409 1.1.254.10 0 RD|ST
v1:2
5 1.1.254.10 0 RD|ST
v1:1
--------------------------------------------------------------------
Flag Description:
When branches communicate with each other, Spoke1 and Spoke2 establish an IPSec
tunnel.
2. When Hub1 fails, the headquarters and branch as well as branches can still communicate
with each other.
# Run the ping -a 10.1.1.1 10.1.2.1 command on Spoke1, and the command output is as
follows.
[Spoke1] ping -a 10.1.1.1 10.1.2.1

0.00% packet loss
----End
Configuration Files
#
sysname Hub1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipsec proposal
pro1
transform ah-
esp
ah authentication-algorithm
sha2-256
esp authentication-algorithm
sha2-256
esp encryption-algorithm
aes-192
#
ike proposal
1
dh
group5
authentication-algorithm
sha2-256
authentication-method pre-share
integrity-algorithm hmac-sha2-256
prf aes-xcbc-128
#
ike peer hub1

undo version 2
pre-shared-key cipher %^%#r]yCG7r(%Obe2oGBu,[XG'[76vVusGq|D9KF,7K@%^%#
ike-proposal
1
dpd type
periodic
dpd idle-time
40
#
ipsec profile
profile1
ike-peer
hub1
proposal
pro1
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 10.1.0.1 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
gre key cipher %^%#q'~GF"30`<g3mxV46;`!_&1{>'e5ALQLkU6~+T>C%^%#
nhrp authentication cipher %^%#!Noa/<I+/WhpAwVfx`QI=vcV),t#@Ihg=PQeN]%C%^%#
nhrp redirect
#
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.1.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
#
sysname Hub2
#
ipsec proposal
pro1
transform ah-
esp
sha2-256
sha2-256
#
ike proposal
1
dh
group5
sha2-256
prf aes-xcbc-128
#
ike peer hub2
undo version 2
pre-shared-key cipher %^%#W8t$Ji82`Y-RX')iNvw9dZ3.K8bxvKioU4LNKx*7%^%#
ike-proposal
1
dpd type
periodic
dpd idle-time
40
#
ipsec profile
profile1
ike-peer
hub2
proposal
pro1
#
ip address 1.1.254.10 255.255.255.0
#
interface LoopBack0
ip address 10.1.0.2 255.255.255.0
#
ip address 10.2.1.4 255.255.255.0
tunnel-protocol gre
p2mp
gre key cipher %^%#[*8)P`\Ra>LdAI7Hamn2t=W5D$M]kMjMEH:9^tr-%^%#
ospf network-type
p2mp
ipsec profile
profile1
nhrp authentication cipher %^%#T(U)=!7|/2^zbH",\BxIKTySV/5xQ*n+<U,dc!36%^%#
nhrp redirect
#
area 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.1.0.0 0.0.0.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

area 0.0.0.1
network 1.1.254.0 0.0.0.255
#
return
#
sysname Spoke1
#
ipsec proposal
pro1
transform ah-
esp
sha2-256
sha2-256
aes-192
#
ike proposal
1
dh
group5
sha2-256
prf aes-xcbc-128
#
ike peer spoke1

undo version 2
pre-shared-key cipher %^%#yRiB!lV4gKvCG_LJ&QDF'FuTPhzX,)QVajSs&M_I%^%#
ike-proposal
1
dpd type
periodic
dpd idle-time
40
#
ipsec profile
profile1
ike-peer
spoke1
proposal
pro1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 10.1.1.1 255.255.255.0
#
ip address 10.2.1.2
255.255.255.0
tunnel-protocol gre
p2mp
gre key cipher %^%#qi,=:z}BQCPT5D>A}20MCIEc6-SBY*d<|bE~>i;2%^%#
ospf network-type
p2mp
ipsec profile
profile1
nhrp authentication cipher %^%#e1an+f[D*$J{NJ4ubbMM$N1L1F2O6#O/u:-[EkSJ%^%#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
nhrp
shortcut
nhrp registration interval
300
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return
#
sysname Spoke2
#
ipsec proposal
pro1
transform ah-
esp
sha2-256
sha2-256
aes-192
#
ike proposal
1
dh
group5
sha2-256
prf aes-xcbc-128
#
ike peer spoke2

undo version 2
pre-shared-key cipher %^%#yRiB!lV4gKvCG_LJ&QDF'FuTPhzX,)QVajSs&M_I%^%#
ike-proposal
1
dpd type
periodic
dpd idle-time
40
#
ipsec profile
profile1
ike-peer
spoke2
proposal
pro1
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 10.1.2.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.2.1.3
255.255.255.0
tunnel-protocol gre
p2mp
gre key cipher %^%#y0|R0B_>==#l"D)42/nU!;A56Zx=oDj,7O7>#:4.%^%#
ospf network-type
p2mp
ipsec profile
profile1
nhrp authentication cipher %^%#FosR<0omi.W{)Y7gp`XP|I-V"|]+7S>{'T/(vKO0%^%#
nhrp
shortcut
300
#
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.8.12 Example for Configuring a DSVPN Based on the LTE

Dialup Status
As shown in Figure 5-25, an enterprise headquarters (Hub_1 as the primary device and
Hub_2 as the secondary device) and branch (Spoke) locate in different areas. The branch
connects to the headquarters through an LTE network, that is, LTE network 1 shown in the
figure. The enterprise requires that the branch communicate with the headquarters through a
VPN and data transmitted between them be encrypted.
To ensure that the enterprise users can still connect to the headquarters even when the primary
SIM card 1 or LTE network 1 is faulty, the enterprise leases the other LTE network, that is
LTE network 2 shown in the figure, to set up a backup link (through the secondary SIM card
2) for temporary service transmission.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-25 Configuring a DSVPN based on the LTE dialup status
Spoke:
Tunnel0/0/1:172.16.1.2/24 GE1/0/0 Hub_1
Tunnel0/0/2:172.16.2.2/24 1.10.1.2/30
Tunnel0/0/3:172.16.3.2/24 LTE network 1 GE3/0/0
Tunnel0/0/4:172.16.4.2/24 (primary)
192.168.1.1/24
Spoke GE2/0/0
SIM card 1 Tunnel0/0/1
Tunnel0/0/2 1.10.1.6/30
Cellular0/0/0
Tunnel0/0/3 GE2/0/0
Tunnel0/0/4 1.10.1.10/30
SIM card 2
GE1/0/0
GE3/0/0
192.168.3.1/24 LTE network 2 192.168.1.2/24
(secondary) GE1/0/0
1.10.1.14/30
Hub_2
Hub_1:
Tunnel0/0/1:172.16.1.1/24
Tunnel0/0/3:172.16.3.1/24
Hub_2:
Enterprise Tunnel0/0/2:172.16.2.1/24 Enterprise
branch Tunnel0/0/4:172.16.4.1/24 headquarters
The branch address is not fixed because it connects to the headquarters through an LTE
network; therefore, the branch and headquarters must be connected through a VPN.
To ensure reliable data transmission, two SIM cards in redundancy mode need to be
configured in the branch and they connect to different LTE networks. A tunnel can be
established between the headquarters and branch based on the association between the LTE
dialup status and DSVPN to ensure uninterrupted data transmission.

1. Configure a cellular interface and APN profile, so that the branch can connect to the LTE
network.
2. Use the non-shortcut DSVPN scenario because the enterprise has only few branches. Use
the RIP protocol to advertise private network routes between the headquarters and
branch and associate NHRP peer information with the APN profile. When the APN
profile is in use, the associated NHRP peer information takes effect; therefore, a tunnel
can be established between the headquarters and branch.
3. Configure the NQA function to implement switching between the primary and secondary
SIM cards.
4. Install a primary and a secondary SIM card on the cellular interface to ensure reliable
data transmission.
5. Bind IPSec policies to the cellular interface on the branch device and the public network
interfaces on the headquarters devices, so that data transmitted between them can be
encrypted.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Configure an IP address for each interface on Hub_1 and Hub_2 according to Figure 5-25.
# Configure an IP address for each interface on Hub_1.
[Huawei] sysname Hub_1
[Hub_1] interface GigabitEthernet 1/0/0
[Hub_1-GigabitEthernet1/0/0] ip address 1.10.1.2 255.255.255.252
[Hub_1-GigabitEthernet1/0/0] quit
[Hub_1] interface gigabitethernet 2/0/0
[Hub_1] interface tunnel 0/0/1
[Hub_1-Tunnel0/0/1] ip address 172.16.1.1 255.255.255.0
[Hub_1-Tunnel0/0/1] quit
[Hub_1-Tunnel0/0/3] ip address 172.16.3.1 255.255.255.0
The configurations of Hub_2 and the Spoke are similar to the configuration of Hub_1, and are
not mentioned here.
Step 2 Configure a cellular interface and APN profile.
# Configure the Spoke.
[Spoke] dialer-rule
[Spoke-dialer-rule] dialer-rule 1 ip permit
[Spoke-dialer-rule] quit
[Spoke] interface cellular 0/0/0
[Spoke-Cellular0/0/0] ip address negotiate
[Spoke-Cellular0/0/0] dialer enable-circular
[Spoke-Cellular0/0/0] dialer-group 1
[Spoke-Cellular0/0/0] dialer timer autodial 15
[Spoke-Cellular0/0/0] dialer timer probe-interval 15
[Spoke-Cellular0/0/0] dialer number *99# autodial
[Spoke-Cellular0/0/0] mode lte auto
[Spoke-Cellular0/0/0] quit
[Spoke] apn profile ltenet
[Spoke-apn-profile-ltenet] sim-id 1
[Spoke-apn-profile-ltenet] apn LTENET1
[Spoke-apn-profile-ltenet] quit
[Spoke] apn profile ltewap
[Spoke-apn-profile-ltewap] sim-id 2
[Spoke-apn-profile-ltewap] apn LTENET2
[Spoke-apn-profile-ltewap] quit
Step 3 Configure reachable public network routes between the devices.

Configure static routes on each device to ensure that the public network routes between the
devices are reachable.
# Configure Hub_1.
[Hub_1] ip route-static 0.0.0.0 0 1.10.1.1
# Configure Hub_2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Spoke] ip route-static 0.0.0.0 0 cellular 0/0/0
Step 4 Configure the DSVPN function.

Configure tunnel interfaces on the Hubs and Spoke and associate NHRP peer information
with the APN profile. Configure the RIP protocol to advertise private network routes and
configure the Spoke to add different metric values to the routes when different tunnel
interfaces send or receive RIP packets to implement communication between the headquarters
and branch.
# Configure Hub_1.
[Hub_1-Tunnel0/0/1] tunnel-protocol gre p2mp
[Hub_1-Tunnel0/0/1] source GigabitEthernet 1/0/0
[Hub_1-Tunnel0/0/1] nhrp registration no-unique
[Hub_1-Tunnel0/0/1] nhrp entry multicast dynamic
[Hub_1-Tunnel0/0/1] gre key 111
[Hub_1-Tunnel0/0/1] nhrp authentication cipher Huawei@1
[Hub_1-Tunnel0/0/1] nhrp entry holdtime seconds 60
[Hub_1-Tunnel0/0/3] source gigabitethernet 2/0/0
[Hub_1] rip 1
[Hub_1-rip-1] version 2
[Hub_1-rip-1] undo summary
[Hub_1-rip-1] network 172.16.0.0
[Hub_1-rip-1] network 192.168.1.0
[Hub_1-rip-1] quit
# Configure Hub_2.
[Hub_2-Tunnel0/0/2] source gigabitethernet 2/0/0
[Hub_2-Tunnel0/0/4] source GigabitEthernet 1/0/0
[Hub_2] rip 1
[Hub_2-rip-1] version 2
[Hub_2-rip-1] undo summary
[Hub_2-rip-1] network 172.16.0.0
[Hub_2-rip-1] network 192.168.1.0
[Hub_2-rip-1] quit
# Associate NHRP peer information with the APN profile on the Spoke and configure the
Spoke to add different metric values to the routes when different tunnel interfaces send or
receive RIP packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Spoke] rip 1
[Spoke-rip-1] version 2
[Spoke-rip-1] network 172.16.0.0
[Spoke-rip-1] network 192.168.3.0
[Spoke-rip-1] quit
[Spoke] interface tunnel 0/0/1
[Spoke-Tunnel0/0/1] tunnel-protocol gre p2mp
[Spoke-Tunnel0/0/1] source cellular 0/0/0
[Spoke-Tunnel0/0/1] gre key 111
[Spoke-Tunnel0/0/1] nhrp authentication cipher Huawei@1
[Spoke-Tunnel0/0/1] nhrp registration interval 20
[Spoke-Tunnel0/0/1] nhrp entry 172.16.1.1 1.10.1.2 register track apn ltenet
[Spoke-Tunnel0/0/1] rip metricin 1
[Spoke-Tunnel0/0/1] quit
[Spoke-Tunnel0/0/2] nhrp entry 172.16.2.1 1.10.1.10 register track apn ltenet
[Spoke-Tunnel0/0/2] rip metricout 7
[Spoke-Tunnel0/0/3] nhrp entry 172.16.3.1 1.10.1.6 register track apn ltewap
[Spoke-Tunnel0/0/4] nhrp entry 172.16.4.1 1.10.1.14 register track apn ltewap
Step 5 Configure the NQA function.
Determine whether to perform a primary/secondary SIM card switching based on the NQA
detection results on tunnel interfaces and the LTE dialup status.

[Spoke] nqa test-instance admin Tunnel0/0/1
[Spoke-nqa-admin-Tunnel0/0/1] test-type icmp
[Spoke-nqa-admin-Tunnel0/0/1] destination-address ipv4 172.16.1.1
[Spoke-nqa-admin-Tunnel0/0/1] source-address ipv4 172.16.1.2
[Spoke-nqa-admin-Tunnel0/0/1] frequency 15
[Spoke-nqa-admin-Tunnel0/0/1] source-interface tunnel 0/0/1
[Spoke-nqa-admin-Tunnel0/0/1] start now
[Spoke-nqa-admin-Tunnel0/0/1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 6 Install a primary and a secondary SIM card on the Spoke.

[Spoke-Cellular0/0/0] apn-profile ltenet priority 200 track nqa admin Tunnel0/0/1
admin Tunnel0/0/2
[Spoke-Cellular0/0/0] apn-profile ltewap priority 150 track nqa admin Tunnel0/0/3
admin Tunnel0/0/4
[Spoke-Cellular0/0/0] shutdown
[Spoke-Cellular0/0/0] undo shutdown
Step 7 Configure the IPSec function to protect data transmitted between the headquarters and branch.
# Configure Hub_1.
[Hub_1] acl number 3001
[Hub_1-acl-adv-3001] rule 5 permit ip source 1.10.1.2 0
[Hub_1-acl-adv-3001] quit
[Hub_1] ipsec proposal 1
[Hub_1-ipsec-proposal-1] quit
[Hub_1] ike peer 1 v1
[Hub_1-ike-peer-1] pre-shared-key cipher Huawei@1234
[Hub_1-ike-peer-1] quit
[Hub_1] ipsec policy-template use1 10
[Hub_1-ipsec-policy-templet-use1-10] ike-peer 1
[Hub_1-ipsec-policy-templet-use1-10] proposal 1
[Hub_1-ipsec-policy-templet-use1-10] security acl 3001
[Hub_1-ipsec-policy-templet-use1-10] quit
[Hub_1] ipsec policy policy1 10 isakmp template use1
[Hub_1-GigabitEthernet1/0/0] ipsec policy policy1
# Configure Hub_2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[Spoke] acl number 3001
[Spoke-acl-adv-3001] rule 5 permit ip destination 1.10.1.2 0
[Spoke-acl-adv-3001] quit
[Spoke] ipsec proposal 1
[Spoke-ipsec-proposal-1] quit
[Spoke] ike peer 1 v1
[Spoke-ike-peer-1] pre-shared-key cipher Huawei@1234
[Spoke-ike-peer-1] remote-address 1.10.1.2
[Spoke-ike-peer-1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Spoke] ipsec policy policy1 10 isakmp
[Spoke-ipsec-policy-isakmp-policy1-10] ike-peer 1
[Spoke-ipsec-policy-isakmp-policy1-10] proposal 1
[Spoke-ipsec-policy-isakmp-policy1-10] security acl 3001
[Spoke-ipsec-policy-isakmp-policy1-10] quit
[Spoke-Cellular0/0/0] ipsec policy policy1

After the configuration is complete, run the display nhrp peer all command on Hub_1 and
Hub_2 to check the registration information of the Spoke. The display on Hub_1 is used as an
example:
[Hub_1] display nhrp peer all
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
The branch can ping the headquarters successfully and data transmitted between them is
encrypted.
Run the display ipsec sa command on the Spoke. You can see that the Spoke has set up an
IPSec tunnel with Hub_1.
# Shut down GE1/0/0 on Hub_1 and GE2/0/0 on Hub_2 to simulate a fault on LTE network 1.
[Hub_1-GigabitEthernet1/0/0] shutdown
[Hub_2-GigabitEthernet2/0/0] shutdown
Run the display nhrp peer all command on Hub_1 and Hub_2. You can see that the Spoke
registers to the headquarters through LTE network 2. The display on Hub_1 is used as an
example:
[Hub_1] display nhrp peer all
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

The branch can ping the headquarters successfully and data transmitted between them is
encrypted.
[Spoke] ping -a 192.168.3.1 192.168.1.1

0.00% packet loss
----End
Configuration Files
l Hub_1 configuration file
#
sysname Hub_1
#
acl number
3001
rule 5 permit ip source 1.10.1.2 0
acl number
3003
#
ipsec proposal
1
ipsec proposal
3
#
ike peer 1
v1
ike peer 3
v1
#
ipsec policy-template use1

10
security acl
3001
ike-peer
1
proposal
1
10
security acl
3003
ike-peer
3
proposal
3
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipsec policy policy1 10 isakmp template

use1
use3
#
ip address 1.10.1.2 255.255.255.252
ipsec policy policy1
#
ip address 1.10.1.6 255.255.255.252
#
ip address 192.168.1.1 255.255.255.0
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
gre key cipher %^%#3isY%"^lX6F&N'Us)3x+\m@F0A2(SQ&=2|;K8abO%^%#

nhrp authentication cipher %^%#1"<9Jp7D_'(SE-N.oVH5B5wZ=WO^KClOL|-UOIQ$%^%#
nhrp registration no-
unique
nhrp entry multicast
dynamic
nhrp entry holdtime seconds
60
#
interface
Tunnel0/0/3
255.255.255.0
tunnel-protocol gre
p2mp
source
gre key cipher %^%#=SXc*PbQgMQ|6<1H|8_W!PU!XFrjE7}LVC(ycs38%^%#

nhrp authentication cipher %^%#EjU:.Y]}.8YZ8JK07')Qw\rTXJ|;LFAFfIH:C]W=%^%#
unique
dynamic
60
#
rip
1
undo
summary
version
2
network
172.16.0.0
network
192.168.1.0
#
ip route-static 0.0.0.0 0.0.0.0 1.10.1.1
ip route-static 0.0.0.0 0.0.0.0 1.10.1.5
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Hub_2 configuration file

#
sysname Hub_2
#
acl number
3002
rule 5 permit ip source 1.10.1.10
0
acl number
3004
#
ipsec proposal
2
ipsec proposal
4
#
ike peer 2
v1
ike peer 4
v1
#

10
security acl
3002
ike-peer
2
proposal
2
10
security acl
3004
ike-peer
4
proposal
4
#

use2
use4
#
255.255.255.252
#
255.255.255.252
#
ip address 192.168.1.2 255.255.255.0
#
interface
Tunnel0/0/2
255.255.255.0
tunnel-protocol gre
p2mp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
gre key cipher %^%#9gxVF{"ZQT;-D<%Gm2I1OQd5(uV!2>(3#q2%V3R#%^

%#
nhrp authentication cipher %^%#g9*MEwPqQOCw:@Jt2WS9:,LNDn[|8If>@9&!2zQQ%^
%#
unique
dynamic
60
#
interface
Tunnel0/0/4
255.255.255.0
tunnel-protocol gre
p2mp
gre key cipher %^%#Y4YfQCCO%Of+{(KpezQ9b!nWTt:6I9wR)o#:Kr,!%^%#
nhrp authentication cipher %^%#BChE#]PR%Z'[<-&:Eq/GM@z=L%^%#BChE#]PR%Z'[<-
&:Eq/GM@z=L
unique
dynamic
60
#
rip
1
undo
summary
version
2
network
172.16.0.0
network
192.168.1.0
#
ip route-static 0.0.0.0 0.0.0.0 1.10.1.9
ip route-static 0.0.0.0 0.0.0.0 1.10.1.13
#
return
l Spoke configuration file
#
sysname Spoke
#
acl number
3001
rule 5 permit ip destination 1.10.1.2 0
acl number
3002
acl number
3003
acl number
3004
#
ipsec proposal
1
ipsec proposal
2
ipsec proposal
3
ipsec proposal
4

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ike peer 1 v1
ike peer 2 v1
ike peer 3
v1
ike peer 4
v1
#
ipsec policy policy1 10

isakmp
security acl
3001
ike-peer
1
proposal
1
isakmp
security acl
3002
ike-peer
2
proposal
2
isakmp
security acl
3003
ike-peer
3
proposal
3
isakmp
security acl
3004
ike-peer
4
proposal
4
#
ip address 192.168.3.1 255.255.255.0
#
interface
Cellular0/0/0
dialer enable-
circular
dialer-group
1
dialer timer autodial
15
dialer timer probe-interval
15
dialer number *99#
autodial
apn-profile ltenet priority 200 track nqa admin Tunnel0/0/1 admin Tunnel0/0/2
apn-profile ltewap priority 150 track nqa admin Tunnel0/0/3 admin Tunnel0/0/4
ip address negotiate

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface
Tunnel0/0/1
255.255.255.0
rip metricin
1
tunnel-protocol gre
p2mp
source
Cellular0/0/0
gre key cipher %^%#3isY%"^lX6F&N'Us)3x+\m@F0A2(SQ&=2|;K8abO%^%#
nhrp authentication cipher %^%#1"<9Jp7D_'(SE-N.oVH5B5wZ=WO^KClOL|-UOIQ$%^%#
20
nhrp entry 172.16.1.1 1.10.1.2 register track apn
ltenet
#
interface
Tunnel0/0/2
255.255.255.0
rip metricin
7
rip metricout
7
tunnel-protocol gre
p2mp
source
Cellular0/0/0
gre key cipher %^%#9gxVF{"ZQT;-D<%Gm2I1OQd5(uV!2>(3#q2%V3R#%^%#
nhrp authentication cipher %^%#g9*MEwPqQOCw:@Jt2WS9:,LNDn[|8If>@9&!2zQQ%^%#
20
ltenet
#
interface
Tunnel0/0/3
255.255.255.0
rip metricin
4
rip metricout
4
tunnel-protocol gre
p2mp
source
Cellular0/0/0
gre key cipher %^%#=SXc*PbQgMQ|6<1H|8_W!PU!XFrjE7}LVC(ycs38%^%#
nhrp authentication cipher %^%#EjU:.Y]}.8YZ8JK07')Qw\rTXJ|;LFAFfIH:C]W=%^
%#
20
ltewap
#
interface
Tunnel0/0/4
255.255.255.0
rip metricin
10
rip metricout
10
tunnel-protocol gre

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
p2mp
source
Cellular0/0/0
gre key cipher %^%#Y4YfQCCO%Of+{(KpezQ9b!nWTt:6I9wR)o#:Kr,!%^%#
nhrp authentication cipher %^%#BChE#]PR%Z'[<-&:Eq/GM@z=L%^%#BChE#]PR%Z'[<-
&:Eq/GM@z=L
20
ltewap
#
dialer-
rule
dialer-rule 1 ip
permit
#
apn profile
ltenet
apn LTENET1
sim-id 1
apn profile
ltewap
apn LTENET2
sim-id 2
#
rip
1
version
2
network
172.16.0.0
network
192.168.3.0
#
#
nqa test-instance admin
Tunnel0/0/1
test-type
icmp
destination-address ipv4
172.16.1.1
source-address ipv4
172.16.1.2
frequency
15
source-interface
Tunnel0/0/1
start
now
Tunnel0/0/2
test-type
icmp
172.16.2.1
source-address ipv4
172.16.2.2
frequency
15
source-interface
Tunnel0/0/2
start
now
Tunnel0/0/3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
test-type
icmp
172.16.3.1
source-address ipv4
172.16.3.2
frequency
15
source-interface
Tunnel0/0/3
start
now
Tunnel0/0/4
test-type
icmp
172.16.4.1
source-address ipv4
172.16.4.2
frequency
15
source-interface
Tunnel0/0/4
start
now
#
return
5.8.13 Example for Configuring DSVPN QoS

A large enterprise has the headquarters (Hub) and multiple branches (Spoke1 and Spoke2 in
this example). The Hub and Spokes are interconnected through DSVPN.
The enterprise needs to control Hub access traffic of the Spokes to prevent bandwidth
congestion and jitter in the Hub. To meet this requirement, configure DSVPN QoS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 5-26 Configuring DSVPN QoS
Branch 1
subnet Tunnel0/0/0
192.168.1.0/24 172.16.1.2/24
GE1/0/0
1.1.2.10/24
Spoke1 LoopBack0
LoopBack0 192.168.0.1/24
192.168.1.1/24 GE1/0/0
1.1.1.10/24
Central office
subnet
Tunnel0/0/0 192.168.0.0/24
LoopBack0 172.16.1.1/24
192.168.2.1/24
Hub
Spoke2
GE1/0/0
1.1.3.10/24
subnet 172.16.1.3/24
192.168.2.0/24
1. Configure DSVPN for interconnection between the Spokes and Hub.
2. Configure DSVPN QoS on the Hub for QoS management on traffic of the Spokes.
– Configure an NHRP group on the Spokes.
– Configure matching rules for traffic classification based on the NHRP group, traffic
policing, and traffic shaping on the Hub.
NOTE
V300R003C10 and later versions support this configuration.
Procedure
Configure IP addresses for interfaces on each Router.
# Configure IP addresses for interfaces of the Hub.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure IP addresses for interfaces of Spoke1 and Spoke2 according to Figure 5-26. The
configuration is similar to that of the Hub.
Step 2 Configure reachable public network routes between Routers.
Configure OSPF on each Router to provide reachable public network routes.
# Configure OSPF on the Hub.
[Hub-ospf-2] quit



# Configure the Hub.
[Hub-ospf-1] quit
# Configure Spoke1.
# Configure Spoke2.
NOTE
Here, each Spoke has one subnet. If the subnet environment changes, you only need to configure
dynamic route attributes on the local device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

On the Hub and Spokes, set the OSPF network type to P2MP for interconnection between the
Spokes and Hub. Enable NHRP redirect on the Hub. Configure the Hub's static NHRP peer
entries and enable NHRP shortcut on Spoke1 and Spoke2.
# Configure a tunnel interface and OSPF route attributes and enable NHRP redirect on the
Hub.
# Configure a tunnel interface, OSPF route attributes, and the Hub's static NHRP peer entry,
and enable NHRP shortcut on Spoke1.
# Configure a tunnel interface, OSPF route attributes, and the Hub's static NHRP peer entry,
and enable NHRP shortcut on Spoke2.
Step 5 Configure DSVPN QoS.

# Configure traffic policing and shaping on the Hub.
[Hub] traffic classifier test
[Hub-classifier-test] if-match nhrp-group spoke
[Hub-classifier-test] quit
[Hub] traffic behavior test
[Hub-behavior-test] car cir 1024 cbs 192512 pbs 320512 green pass yellow pass red
discard
[Hub-behavior-test] gts cir pct 60 queue-length 100
[Hub-behavior-test] statistic enable
[Hub-behavior-test] quit
[Hub] traffic policy p1
[Hub-trafficpolicy-p1] classifier test behavior test
[Hub-trafficpolicy-p1] quit
[Hub-Tunnel0/0/0] traffic-policy p1 inbound
[Hub-Tunnel0/0/0] traffic-policy p1 outbound
# Configure an NHRP group on Spoke1.

[Spoke1-Tunnel0/0/0] nhrp group spoke
# Configure an NHRP group on Spoke2.

[Spoke2-Tunnel0/0/0] nhrp group spoke

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

l The Spokes can ping the Hub and each other successfully. For example, you can run the
ping -a 192.168.1.1 192.168.2.1 on Spoke1 to ping the private address of Spoke2.
[Spoke1] ping -a 192.168.1.1 192.168.2.1

0.00% packet loss
l When the Hub's outgoing traffic exceeds the peak burst traffic 320512 bytes, traffic
statistics show that traffic loss occurs. When the bandwidth percentage exceeds 60%, the
rate of outgoing packets is controlled to ensure that packets are sent at an even rate.
----End
Configuration Files
#
sysname Hub
#
traffic classifier test operator or
if-match nhrp-group spoke
#
traffic behavior test
car cir 1024 cbs 192512 pbs 320512 mode color-blind green pass yellow pass
red discard
gts cir pct 60 queue-length 100
statistic enable
#
traffic policy p1
classifier test behavior test precedence 5
#
ip address 1.1.1.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.0.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
traffic-policy p1 inbound
traffic-policy p1 outbound
nhrp redirect
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
sysname Spoke1
#
ip address 1.1.2.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.1.1 255.255.255.0
#
ip address 172.16.1.2 255.255.255.0
nhrp shortcut
nhrp group spoke
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
ip address 1.1.3.10 255.255.255.0
#
interface LoopBack0
ip address 192.168.2.1 255.255.255.0
#
ip address 172.16.1.3 255.255.255.0
nhrp shortcut
nhrp group spoke
#
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return
5.9 Troubleshooting DSVPN

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5.9.1 Spoke Fails to Register with a Hub
Fault Description
After the display nhrp peer command is executed on the Hub, no NHRP mapping entry that
records the mapping between the tunnel address of the Spoke and the public network address
is displayed.
Procedure
Step 1 Check that the Spoke has reachable routes to the remote Spoke and the Hub.
Run the display ip routing-table command to check whether there are routes to the remote
end.
l If there is no reachable route between the Spoke and Hub, check the configurations of
routes on the Spoke and Hub. For the configurations of routes, see the Huawei
V300R003 Configuration Guide - IP Routing.
l If there are reachable routes between the Spoke and Hub, go to step 2.
Step 2 Check that configurations of the Spoke and Hub are correct.
Run the display nhrp peer command on the Spoke and Hub to check NHRP mapping entries.
If the Hub does not have dynamic NHRP mapping entries of the Spoke, run the display this
command on mGRE tunnel interfaces of the Spoke and Hub to check whether the
configurations on both ends are consistent. The following table lists the fields in the command
output that you need to check the follow-up operations.
Item Check Standard and Operation
nhrp Check whether NHRP authentication string configurations of the Spoke

authenticatio and Hub are the same. If they are different, run the nhrp authentication
n command to modify the configurations.
nhrp entry Check whether the static NHRP mapping entries on the Spoke contain the
interface information of the Hub. If not, run the nhrp entry command to
modify the configurations.
----End
5.9.2 Subnets Between Spokes Cannot Communicate Directly in

Non-Shortcut Mode
Fault Description
After the non-shortcut mode is configured, subnets between Spokes cannot communicate.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Check whether subnet routes are available between Spokes, and between Spokes and the Hub,
and whether the next-hop addresses of subnet routes are the tunnel addresses of the peer
devices.
Run the display ip routing-table command on the local Spoke to check whether routes to the
remote Spoke exist in the local IP routing table. Run the display ip routing-table command
on the Hub to check whether subnet routes to Spokes exist in the local IP routing table.
l If no subnet route is available between Spokes, and between Spokes and the Hub,
configure subnet routes. For the configurations of routes, see the Huawei
l If subnet routes are available between Spokes, and between Spokes and the Hub, but the
next hop to the destination subnet is not the tunnel address of the remote device,
configure routing information to set the next hop to the destination subnet to the tunnel
address of remote device. For details, see Configuring Routes.
l If subnet routes are available between Spokes, and between Spokes and the Hub, and the
next hop to the destination subnet is the tunnel address of remote device, go to step 2.
Step 2 Check whether NHRP mapping entries of a local Spoke have been generated on the Hub and
the remote Spoke.
Run the display nhrp peer command on the Hub and Spoke to check NHRP mapping entries.
If no NHRP mapping entry of the Spoke is generated on the Hub, rectify the fault according
to 5.9.1 Spoke Fails to Register with a Hub.
----End
5.9.3 Subnets Between Spokes Cannot Communicate Directly in

Shortcut Mode
Fault Description
After the shortcut mode is configured, subnets between Spokes cannot communicate.
Procedure
Step 1 Check that subnet routes are available between Spokes, and between Spokes and the Hub.
remote Spoke exist in the local IP routing table. Run the display ip routing-table command
on the Hub to check whether subnet routes to Spokes exist in the local IP routing table.
l If no subnet route is available between Spokes, and between Spokes and the Hub,
configure subnet routes. For the configurations of routes, see the Huawei
l If subnet routes are available between Spokes, and between Spokes and the Hub, go to
step 2.
Step 2 Check whether the next hop to the destination subnet is the tunnel address of the Hub.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
remote Spoke exist.
l If the next hop to the destination subnet is not the tunnel address of the Hub, configure
routing information to set the next hop to the destination subnet to the tunnel address of
the Hub. For details, see Configuring Routes.
l If the next hop to the destination subnet is the tunnel address of the Hub, go to step 3.
Step 3 Check whether NHRP mapping entries of a local Spoke have been generated on the Hub and
the remote Spoke.
Run the display nhrp peer command on the Hub and Spoke to check NHRP mapping entries.
If no NHRP mapping entry of the Spoke is generated on the Hub, rectify the fault according
to 5.9.1 Spoke Fails to Register with a Hub.
----End
5.9.4 Backup Hub Only Forwards Data After the Master Hub Fails
Fault Description
In dual-Hub DSVPN scenario, the backup Hub only forwards data after the master Hub fails.
No tunnel can be established between the Spokes.
Procedure
Step 1 Check whether the public addresses configured on the master and backup Hubs are on the
same network segment.
Run the display this command on the mGRE interfaces of the master and backup Hubs to
check whether the IP addresses of the Hubs are on the same network segment.
l If so, change the IP address of one Hub to an IP address on a different network segment.
l If not, go to step 2.
Step 2 Check whether routes to the master Hub are available on the Spokes.
Run the display ip routing-table command on the Spokes to check whether routes to the Hub
exist.
If the IP routing table contains routes to the master Hub, deletes the routes. For details, see
Huawei AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600
Series V300R003 Configuration Guide - IP Routing.
----End
5.10 References for DSVPN

The following table lists the references for DSVPN.
RFC2332 Next Hop Resolution Protocol

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 6 IPSec Configuration
6 IPSec Configuration
About This Chapter
6.1 Overview of IPSec

6.2 Understanding IPSec
6.3 Application Scenarios for IPSec
6.4 Summary of IPSec Configuration Tasks
6.5 Licensing Requirements and Limitations for IPSec
6.6 Default Settings for IPSec
6.7 Using an ACL to Establish an IPSec Tunnel
6.8 Using a Virtual Tunnel Interface to Establish an IPSec Tunnel
6.9 Establishing an IPSec Tunnel Using an Efficient VPN Policy
6.10 Configuring an IPSec Tunnel in the Auto VPN Scenario
6.11 Configuring IKE
6.12 Maintaining IPSec
6.13 Configuration Examples for IPSec
6.14 Troubleshooting IPSec
6.15 FAQ About IPSec
This section describes the FAQ about IPSec.
6.16 References for IPSec

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.1 Overview of IPSec

Definition
Internet Protocol Security (IPSec), defined by the Internet Engineering Task Force (IETF), is
a series of open network security protocols and services provided on an IP network. Figure
6-1 shows the IPSec protocol framework.
Figure 6-1 IPSec protocol framework
Security protocols ESP AH
Encryption DES 3DES AES
Authenication MD5 SHA1 SHA2 MD5 SHA1 SHA2
Key exchange IKE (ISAKMP, DH)
IPSec protects IP packets using two security protocols: Authentication Header (AH) and
Encapsulating Security Payload (ESP).
l AH provides data origin authentication, data integrity check, and anti-replay, but does
not provide encryption.
l ESP provides encryption, data origin authentication, data integrity check, and anti-replay.
Security functions provided by the AH and ESP protocols depend on authentication and
encryption algorithms.
l Both AH and ESP can provide data origin authentication and data integrity check using
authentication algorithms Message Digest 5 (MD5), Secure Hash Algorithm 1 (SHA1),
Secure Hash Algorithm 2 (SHA2)-256, SHA2-384, and SHA2-512.
l ESP can also encrypt IP packets using symmetric encryption algorithms, including Data
Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advanced
Encryption Standard (AES).
NOTE
l The MD5 and SHA1 authentication algorithms have security risks. The SHA2 algorithm is
recommended.
l The DES and 3DES encryption algorithms have security risks. The AES algorithm is recommended.
The keys used in IPSec encryption and authentication algorithms can be manually configured
or dynamically negotiated through the Internet Key Exchange (IKE) protocol. IKE works in
the Internet Security Association and Key Management Protocol (ISAKMP) framework. It
uses the Diffie-Hellman (DH) algorithm to securely deliver keys and authenticate identities
over an insecure network, ensuring data transmission security. IKE improves key security and
simplifies IPSec management.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Purpose
On the Internet, most data is transmitted in plain text, causing security risks. For example,
bank accounts and passwords face risks of eavesdropping or tampering, user identities may be
counterfeited, or bank networks may be attacked. IPSec can protect IP packets transmitted
over an insecure network to reduce the risk of information leaks.
Benefits
Taking advantage of encryption and authentication, IPSec ensures secure service data
transmission over the Internet in terms of:
l Data origin authentication: The receiver checks validity of the sender.
l Data encryption: The sender encrypts data packets and transmits them in cipher text on
the Internet. The receiver decrypts or directly forwards the received data packets.
l Data integrity check: The receiver validates received data to check whether the data has
been tampered with.
l Anti-replay: The receiver rejects old or duplicate packets to prevent attacks that
malicious users initiate by re-sending obtained packets.
6.2 Understanding IPSec
6.2.1 Basic Concepts of IPSec

A security association (SA) needs to be established between IPSec peers (two IPSec
endpoints) before IPSec can implement secure data transmission. An SA defines a set of
parameters for data transmission between two IPSec peers, including the security protocol,
characteristics of data flows to be protected, data encapsulation mode, encryption algorithm,
authentication algorithm, Key Exchange, IKE, and SA lifetime.
6.2.1.1 Security Association

An SA is identified by three parameters: security parameter index (SPI), destination IP
address, and security protocol ID (AH or ESP). The SPI is a 32-bit value generated for
uniquely identifying an SA, and is transmitted in an AH or ESP header. The SPI needs to be
specified when an SA is manually configured. When an SA is generated during IKE
negotiation, an SPI is generated randomly.
Because SAs are unidirectional, at least two SAs are required to protect incoming and
outgoing data flows. In Figure 6-2, two SAs need to be established if an IPSec tunnel needs
to be established between IPSec peers A and B. SA1 defines the protection mode for data sent
from Peer A to Peer B, and SA2 defines the protection mode for data sent from Peer B to Peer
A.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-2 IPSec SAs
Internet
SA1(A→B)
SA2(A←B)
IPSec Tunnel
Peer A Peer B
Original packet
Encrypted packet
How many SAs are required also depends on the security protocol used. If you use either AH
or ESP to protect traffic between two peers, two SAs are required to protect incoming and
outgoing flows. If you use both AH and ESP to protect traffic between two peers, four SAs
are required, two for each protocol.
An IPSec SA is established in manual or IKE auto-negotiation mode. The two modes differ in
the following:
l Key generation mode
In manual mode, all the parameters used to establish an SA, including the encryption key
and authentication key, need to be manually configured and updated, leading to high key
management costs on large and medium-sized networks. In IKE auto-negotiation mode,
the encryption key and authentication key are generated using the DH algorithm and can
be dynamically updated, reducing key management costs and improving security.
l SA lifetime
An SA established manually exists permanently. How long an SA established in IKE
auto-negotiation mode can exist depend on the lifetime parameters configured on two
peers.
Based on the differences, the manual mode applies to small networks with a small number of
IPSec peers, where as IKE auto-negotiation mode is recommended on large and medium-
sized networks.
6.2.1.2 Security Protocol

IPSec uses two security protocols, Authentication Header (AH) and Encapsulating Security
Payload (ESP), to transmit and encapsulate data. The security protocols provide security
services such as authentication and encryption.
AH
AH is an IP-based transport-layer protocol with protocol number 51. According to the AH
protocol, an AH header is appended to the standard IP header in each packet, as shown in
6.2.1.3 Encapsulation Mode. The sender performs hash calculation on packets and the
authentication key. When the packets carrying the calculation result arrive at the receiver, the
receiver also performs hash calculation and compares the calculation result with the received
calculation result. Any changes to the data during transmission will make the calculation

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
result invalid. AH provides data origin authentication and data integrity check in this way. An
integrity check is performed on an entire IP packet.
Figure 6-3 shows the AH header format.
Figure 6-3 AH header format

Next Payload
Reserved
Header Len
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable)

Integrity Check Value (ICV)
32 bits
Table 6-1 describes the fields in an AH header.
Table 6-1 AH header fields

Field Length Description
Next 8 bits This field identifies the type of the payload following the AH
Header header. In transport mode, the Next Header field is the number of
the protected upper-layer protocol (TCP or UDP) or ESP. In tunnel
mode, the Next Header field is the number of the IP or ESP
protocol.
NOTE
When both AH and ESP are used, the next header following an AH header is
an ESP header.
Payload 8 bits The value of this field is the AH packet length in 32-bit words
Length minus 2. The default value is 4.
Reserve 16 bits This field is reserved and defaults to 0.

d
SPI 32 bits This field uniquely identifies an IPSec security association (SA).
Sequenc 32 bits This field is a counter that monotonically increases from 1. It

e uniquely identifies a packet to prevent replay attacks.
Number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Authenti Integral This field contains the Integrity Check Value (ICV) and is used by
cation multiple the receiver for data integrity check. Authentication algorithms
Data of 32 include MD5, SHA1, and SHA2.
bits. It is NOTE
96 bits The MD5 and SHA1 authentication algorithms have security risks. The
in SHA2 algorithm is recommended.
common
cases.
ESP
ESP is an IP-based transport-layer protocol, with the protocol number 50. According to the
ESP protocol, an ESP header is appended to the standard IP header in each packet, and an
ESP tail and ESP Auth data are appended to each packet, as shown in 6.2.1.3 Encapsulation
Mode. Unlike AH, ESP encrypts the valid payload and then encapsulates it to a packet to
ensure data confidentiality. However, ESP does not protect an IP header.
Figure 6-4 shows the ESP header format.
Figure 6-4 ESP header format
Security Parameters Index (SPI)

ESP
Sequence Number header
Payload data Authenticated

Encrypted
Padding
(0-255 octets) ESP
Pad Next tail
Length Header
Authentication Data (Variable) ESP
Integrity Check Value (ICV) authentication
32 bits
Table 6-2 describes the fields in an ESP header.
Table 6-2 ESP header fields

SPI 32 bits This field uniquely identifies an IPSec SA.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Sequenc 32 bits This field is a counter that monotonically increases from 1. It

e uniquely identifies a packet to prevent replay attacks.
Number
Payload - This field contains variable-length data identified by the Next Header
Data field.
Padding - This field extends the size of an ESP header. The Padding field
length depends on the payload data length and algorithm. If the
plaintext length of the packet to be encrypted does not comply with
the encryption algorithm, the Padding field is used.
Pad 8 bits This field specifies the length of the Padding field. The value 0
Length indicates no padding.
Next 8 bits This field identifies the type of the payload following the ESP
Header header. In transport mode, the Next Header field is the number of the
protected upper-layer protocol (TCP or UDP). In tunnel mode, the
Next Header field is the IP protocol number.
Authenti Integral This field contains the Integrity Check Value (ICV) and is used by
cation multipl the receiver for data integrity check. Authentication algorithms
Data e of 32 which are the same as those of AH.
bits. It The authentication function of ESP is optional. If data check is
is 96 enabled, an ICV value is appended to encrypted data.
bits in
commo
n cases.
Comparisons Between AH and ESP

Table 6-3 compares AH and ESP.
Table 6-3 Comparisons between AH and ESP

Security Feature AH ESP
Protocol number 51 50
Data integrity Supported (checking the entire IP Supported (not checking the IP
check packet) header)
Data origin Supported Supported

authentication
Data encryption Not supported Supported
Anti-replay Supported Supported
IPSec NAT-T Not supported Supported

(NAT traversal)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
According to Table 6-3, AH does not provide data encryption and ESP does not check an IP
header. Therefore, use both AH and ESP when high security is required.
6.2.1.3 Encapsulation Mode

Encapsulation is a process of adding AH or ESP fields to original IP packets for packet
authentication and encryption. This process is implemented in transport or tunnel mode.
Transport Mode
In transport mode, an AH or ESP header is added between an IP header and a transport-layer
protocol header to protect the TCP, UDP, or ICMP payload. The transport mode does not
change the IP header, so the source and destination addresses of an IPSec tunnel must be the
same as those in the IP header. This encapsulation mode applies only to communication
between two hosts or between a host and a VPN gateway.
Figure 6-5 shows an example of TCP packet encapsulation in transport mode.
Figure 6-5 Packet encapsulation in transport mode
IP AH TCP
AH data
Authenticated
(except variable fields in IP Header)
IP ESP TCP ESP ESP
data
ESP Header Header Header Tail Auth data
Encrypted
Authenticated
IP AH ESP TCP ESP ESP
data
Header Header Header Header Tail Auth data
AH-ESP
ESP encrypted
ESP authenticated
AH authenticated (except variable fields in IP Header)
In transport mode, AH checks the integrity of the entire IP packet. ESP checks the integrity of
the ESP header, transport layer protocol header, data, and ESP tail, excluding the IP header.
Therefore, ESP cannot protect the IP header. ESP encrypts the transport-layer protocol header,
data, and ESP tail.
Tunnel Mode
In tunnel mode, an AH or ESP header is added outside the raw IP header, and a new IP header
added outside the AH or ESP header to protect the IP header and payload. The tunnel mode
applies to communication between two VPN gateways or between a host and a VPN gateway.
Figure 6-6 shows an example of TCP packet encapsulation in tunnel mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-6 Packet encapsulation in tunnel mode

New IP AH Raw IP TCP
data
AH Header Header Header Header
Authenticated
(except variable fields in New IP Header)
New IP ESP Raw IP TCP ESP ESP
data
ESP Header Header Header Header Tail Auth data
Encrypted
Authenticated
New IP AH ESP Raw IP TCP ESP ESP

data
Header Header Header Header Header Tail Auth data
AH-ESP
ESP encrypted
ESP authenticated
AH authenticated (except variable fields in New IP Header)
In tunnel mode, AH checks the integrity of the entire IP packet including the new IP header.
ESP checks the integrity of the ESP header, raw IP header, transport layer protocol header,
data, and ESP tail, excluding the new IP header. Therefore, ESP cannot protect the new IP
header. ESP encrypts the raw IP header, transport-layer protocol header, data, and ESP tail.
Comparisons Between the Transport Mode and Tunnel Mode

The two encapsulation modes differ in the following:
l The tunnel mode is more secure because original IP packets can be completely
authenticated and encrypted in tunnel mode. This mode hides the IP address, protocol
type, and port number in an original IP packet.
l The tunnel mode generates an additional IP header, occupying more bandwidth than the
transport mode.
When both AH and ESP are used to protect traffic, they must use the same encapsulation
mode.
6.2.1.4 Encryption
Encryption is a process of converting plaintext data into ciphertext data using an algorithm.
The receiver can decrypt ciphertext data only when it has the correct key. The encryption
mechanism ensures data confidentiality and prevents data from being eavesdropped during
transmission. IPSec involves data encryption and protocol message encryption.
Data Encryption
IPSec uses symmetric encryption algorithms to encrypt and decrypt data. Symmetric
encryption algorithms require that the sender and receiver use the same key to encrypt and
decrypt data.
Figure 6-7 shows the process of using a symmetric encryption algorithm to encrypt and
decrypt data.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-7 Data encryption and decryption
IPSec receiver IPSec sender

IP packet IP packet
Encryption algorithm Symmetric key Encryption algorithm

(decryption) Manually configured (encryption)
or generated through
Encrypted IP DH algorithm and Encrypted IP
packet shared packet
The symmetric key can be manually configured or generated through IKE auto-negotiation.
Common symmetric encryption algorithms include:
l Data Encryption Standard (DES)
DES was developed by the National Institute of Standards and Technology (NIST). It
uses a 56-bit key to encrypt a 64-bit plaintext block.
l Triple Data Encryption Standard (3DES)
3DES is an enhancement to DES and uses three different 56-bit keys (168 bits in total) to
encrypt a plaintext block.
Compared with DES, 3DES is slower but more secure.
l Advanced Encryption Standard (AES)
AES is designed to replace 3DES and is faster and more secure than 3DES. AES
supports three types of keys: AES-128, ES-192, and AES-256, which have key lengths
of 128 bits, 192 bits, and 256 bits, respectively.
The encryption algorithm with a longer key is more secure but slower. In general,
AES-128 can meet security requirements.
Protocol Message Encryption

Protocol message encryption occurs in IKE negotiation. Symmetric encryption algorithms,
such as DES, 3DES, and AES, are used to encrypt protocol messages. The symmetric key
used for protocol message encryption is generated through IKE auto-negotiation.
6.2.1.5 Authentication
Authentication is an operation that a receiver performs to verify the identity of the sender
(source origin authentication) and whether data has been tampered with during transmission
data integrity check. IPSec ensures data reliability using source origin authentication and data
integrity check together.
Although encrypted data can only be decrypted using the original encryption key, the
decrypted data cannot be proved to be the original data. Additionally, data encryption and
decryption consume many CPU resources, and malicious users may send spoofing packets to
consume CPU resources. Keyed-Hash Message Authentication Code (HMAC) compares
digital signatures to check data integrity and authenticity. This process consumes only a few
CPU resources and is very efficient. Therefore, IPSec uses HMAC for authentication.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Encryption and authentication are often used together on the IPSec sender. The sender
encrypts IP packets, generates a digital signature during HMAC authentication, and then
sends both the encrypted IP packets and digital signature to the receiver. The digital signature
is included in the Integrity Check Value (ICV) field in an AH or ESP header. For details, see
6.2.1.2 Security Protocol. The receiver compares the received digital signature with the
locally generated one to check data integrity and authenticity in the received IP packets. The
receiver discards the packets that fail the authentication and decrypts those that pass the
authentication. Figure 6-8 shows the process of encryption and HMAC authentication.
Figure 6-8 Encryption and HMAC authentication
IPSec sender IPSec receiver

IP packet IP packet
Encryption algorithm Symmetric key Encryption algorithm

(encryption) (decryption)
Manually configured
or generated through
DH algorithm and Encrypted IP
shared packet
Yes
Are ICVs
Encrypted IP calculated on both No
Discard
packet ends consistent?
Encrypted ICV
ICV
IP packet
Authentication Symmetric key Authentication

algorithm (HMAC) algorithm (HMAC)
Manually configured or
generated through DH
algorithm and shared
Encrypted
ICV
IP packet
Like an encryption key, a symmetric authentication key can be manually configured or

generated through IKE auto-negotiation.
Common authentication algorithms include:
l MD5
MD5 is defined in RFC 1321. It generates a 128-bit signature based on a message of any
length.
MD5 is faster but less secure than Secure Hash Algorithm (SHA).
l SHA1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
SHA was developed by the National Institute of Standards and Technology (NIST).
SHA1 is a revision to SHA and was published in 1994. Defined in RFC 2404, SHA1
converts a message of a length less than 264 bits into a 160-bit message digest.
SHA1 is slower but more secure than MD5. SHA1 generates a long signature to prevent
key cracking, and discovers the shared key efficiently.
l SHA2
SHA2 is an enhancement to SHA1. It has a larger key length and is much more secure
than SHA1. SHA2 includes SHA2-256, SHA2-384, and SHA2-512, with 256-bit, 384-
bit, and 512-bit key lengths, respectively.
The authentication algorithm with a longer key is more secure but slower. In general,
SHA2-256 can meet security requirements.
l AES-XCBC-MAC-96 is a type of AES-based message authentication algorithm and is
described in RFC 3566.
The algorithms have their own strengths and weaknesses. MD5 is faster than SHA1, but less
secure. SHA2 has a longer key than SHA1, which means that SHA2 is more difficult to
defeat, and therefore more secure.
6.2.1.6 Key Exchange
How to securely share a key is an important issue during symmetric key encryption and
authentication. Two ways are available to address this issue:
l Out-of-band key sharing
The encryption key and authentication key are manually configured on the sender and
receiver. The two parties ensure key consistency in out-of-band mode (through phones or
mails for example). This mode has poor scalability and multiplies the workload in
configuring the key in point-to-multipoint networking. In addition, this mode is difficult
to implement because the keys need to be changed periodically to improve network
security.
l Using a secure key distribution protocol
The key is generated through IKE auto-negotiation. The Internet Key Exchange (IKE)
protocol uses DH (Diffie-Hellman) algorithm to implement secure key distribution over
an insecure network. This mode is easy to configure and has high scalability, especially
on a large dynamic network. Two communicating parties exchange key materials to
calculate the shared key. Even through a third party obtains all the exchanged data used
to calculate the shared key, it cannot calculate the shared key.
6.2.1.7 IKE
Internet Key Exchange (IKE) is a User Datagram Protocol (UDP)-based application-layer
protocol built on the Internet Security Association and Key Management Protocol (ISAKMP)
framework. It implements automatic key negotiation and IPSec 6.2.1.1 Security Association
setup, to simplify IPSec use and management, and facilitate IPSec configuration and
maintenance.
Figure 6-9 shows the relationship between IKE and IPSec. The two peers establish an IKE
SA for identity authentication and key information exchange. Protected by the IKE SA, the
peers negotiate a pair of IPSec SAs using the Authentication Header (AH) or Encapsulating
Security Payload (ESP) protocol and other parameters configured. Subsequently, data is
encrypted and transmitted between the peers in an IPSec tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-9 Relationship between IKE and IPSec

①IKE SA
negotiation
IKE IKE
Peer A Peer B
IKE SA IKE SA
UDP UDP
AH/ESP AH/ESP
IP
Encry IP
packet
②Establishment of bidirectional IPSec SAs
IKE Security Mechanisms

IKE defines a series of self-protection mechanisms that can securely authenticate identities,
distribute keys, and establish IPSec SAs on an insecure network:
l Identity authentication
Two peers authenticate the identity (IP address or name) of each other, using Pre-shared
key (PSK) authentication, RSA signature authentication.
– Pre-shared key authentication: An authentication key is used to generate a key. The
two peers compute the hash value of packets using a shared key and check whether
they obtain the same hash value. If they obtain the same hash value, the
authentication succeeds. Otherwise, the authentication fails.
– RSA signature authentication: The two peers use a certificate issued by a certificate
authority (CA) to verify validity of a digital certificate. Each peer has a public key
(transmitted over the network) and a private key (possessed by itself). The sender
computes a hash value for original packets, and then encrypts the hash value using
its private key to generate a digital signature. The receiver decrypts the digital
signature using the public key received from the sender, and then computes a hash
value. If the computed hash value is the same as that decrypted from the digital
signature, the authentication succeeds. Otherwise, the authentication fails.
When a peer has multiple peers, PSK authentication requires that the same pre-shared
key be configured on all peers. This authentication method can be easily implemented on
small-scale networks but has low security. RSA signature authentication provides high
security but requires digital certificates issued by a CA. This authentication method is
applicable to large-scale networks.
IKE supports the following authentication algorithms: AES-XCBC-MAC-96, MD5,
SHA1, SHA2-256, SHA2-384, and SHA2-512.
l Identity protection
After a key is generated, identity data is encrypted to ensure secure transmission.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IKE supports the following encryption algorithms: DES, 3DES, AES-128, AES-192, and
AES-256.
l DH
Diffie-Hellman (DH) is a public key exchange mechanism that generates key materials
and uses ISAKMP messages to exchange key materials between the initiator and
responder. Then the devices at both ends calculate the same symmetric key to generate
the encryption key and authentication key. The two devices do not exchange the real key
in any cases. DH key exchange is the core part of IKE.
The MD5, SHA1, DES, 3DES and AES algorithms can use the DH algorithm to enable
sharing of a symmetric key between two parties.
DH uses key groups to define the key length. A longer key indicates a stronger key.
Table 6-4 DH key group
Key Group Key Length
1 768 bits
2 1024 bits
5 1536 bits
14 2048 bits
15 3072 bits
16 4096 bits
19 256 bits ECP (Elliptic Curve Groups

modulo a Prime)
20 384 bits ECP
21 521 bits ECP
l PFS
Perfect Forward Secrecy (PFS) is a security feature that protects security of other keys in
case a key is deciphered, because these keys are independent of one another. The key
used in an IPSec SA is derived from the key used in an IKE SA. An IKE SA generates
one or more pairs of IPSec SAs through negotiation. After obtaining the IKE key, an
attacker may collect enough information to calculate the key used in the IPSec SA. To
ensure security of the key, PFS performs an additional DH key exchange.
NOTE
l The MD5 and SHA1 authentication algorithms are insecure. The more secure AES-XCBC-MAC-96,
SHA2-256, SHA2-384, or SHA2-512 algorithm is recommended.
l The DES and 3DES encryption algorithms are insecure. The more secure AES algorithm is
recommended.
Comparison Between IKEv1 and IKEv2

IKE has two versions: IKEv1 and IKEv2. IKEv2 has the following advantages over IKEv1:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Simplifies SA negotiation and improves negotiation efficiency.

IKEv1 goes through two phases to negotiate the key and establish SAs for IPSec. In
phase 1, two IKE peers negotiate to establish a secure channel, IKE SA. In phase 2, IKE
peers establish a pair of IPSec SAs using the secure channel established in phase 1.
IKEv2 generates the key and establishes SAs for IPSec in just one negotiation,
simplifying the negotiation process. For details about IKEv1 negotiation and IKEv2
negotiation, see 6.2.2.2 Establishing an SA Through IKEv1 Negotiation and 6.2.2.3
Establishing an SA Through IKEv2 Negotiation.
l Fixes many cryptographic vulnerabilities, enhancing security.
6.2.2 IPSec Fundamentals

IPSec establishes bidirectional security associations between IPSec peers to form a secure
IPSec tunnel, imports data flows to be protected to the tunnel, and then uses security
protocols to encrypt and authenticate the data passing through the tunnel to securely transmit
the data over the Internet.
IPSec SAs can be established manually or through IKEv1 or IKEv2 auto-negotiation. In
manual mode, all the parameters used to establish an SA need to be manually configured and
maintained, and an SA is established when parameters on two IPSec peers match and IPSec
SA negotiation succeeds. In IKE auto-negotiation mode, only IKE negotiation information
needs to be configured, and an SA is established and maintained through IKE auto-
negotiation. The IKE auto-negotiation mode is recommended because it is easy to configure
and maintain and has a secure key. This document describes only the process of establishing
an SA through IKE auto-negotiation.
6.2.2.1 Defining IPSec Protected Data Flows

IPSec supports the following method to define data flows to be protected:
l Using an ACL
On an IPSec tunnel established in manual mode or IKE negotiation mode, data flows that
will be protected by IPSec can be defined by an ACL. The packets matching permit
clauses in the ACL are protected, and those matching the deny clauses are not protected.
The ACL can define packet attributes such as the IP address, port number, and protocol
type, which provide flexibility in defining IPSec policies.
l Using an IPSec profile
In this method, an IPSec tunnel is established through IPSec virtual tunnel interfaces,
and these interfaces protect all the packets routed to them. An IPSec virtual tunnel
interface is a type of Layer 3 logical interface.
This method has the following advantages:
– Simplifies configuration.
You only need to import data flows to be protected to an IPSec tunnel interface, and
do not need to use an ACL to define the characteristics of traffic to be encrypted
and decrypted.
– Supports more types of traffic.
An IPSec tunnel interface protects traffic of dynamic routing protocols and
multicast traffic through GRE over IPSec.
6.2.2.2 Establishing an SA Through IKEv1 Negotiation

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IKEv1 negotiation goes through two phases: In phase 1, two IPSec peers negotiate and
establish a secure tunnel (an IKE SA). In phase 2, two IPSec peers establish a pair of IPSec
SAs for secure data transmission through the secure tunnel established in phase 1.
IKEv1 Negotiation Phase 1

Phase 1 needs to establish an IKE SA. After an IKE SA is established, all the Internet
Security Association and Key Management Protocol (ISAKMP) messages transmitted
between the two IPSec peers will be encrypted and authenticated. The secure tunnel
established in phase 1 enables IPSec peers to communicate securely in phase 2. An IKE SA is
bidirectional, so only one IKE SA needs to be established between two IPSec peers.
Phase 1 supports two negotiation modes: main mode and aggressive mode.
The main mode uses six ISAKMP messages to implement three bidirectional exchanges, as
shown in Figure 6-10. The three exchanges are as follows:
1. Messages (1) and (2) are used for policy exchange.
The initiator sends one or multiple IKE proposals to the responder. The responder
searches for the first matching IKE proposal and then sends the matching proposal to the
initiator. IKE proposals of the initiator and responder match if they have the same
encryption algorithm, authentication algorithm, authentication method, and Diffie-
Hellman group identifier.
2. Messages (3) and (4) are used for key information exchange.
The initiator and responder exchange the Diffie-Hellman public value and nonce value to
generate the IKE SA authentication and encryption key.
3. Messages (5) and (6) are used for identity and authentication information exchange.
The initiator and responder use the generated key to authenticate each other and the
information exchanged in main mode.
NOTE
l An IKE proposal is a set of algorithms used to secure IKE negotiation, including encryption
algorithm, authentication algorithm, Diffie-Hellman group, and authentication method.
l A nonce value is a random number that guarantees IKE SA liveness and protects against replay
attacks.
The aggressive mode uses only three messages. Messages (1) and (2) are used to negotiate
IKE proposal and exchange the Diffie-Hellman public value, mandatory auxiliary
information, and identity information. Message (2) also contains the identity information sent
by the responder to the initiator for authentication. Message (3) is used by the responder to
authenticate the initiator. Figure 6-10 shows IKEv1 negotiation phase 1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-10 IKEv1 negotiation phase 1
Main mode Aggressive mode
Initiator Responder Initiator Responder
1 Search Send IKE proposals,

Send IKE 1 Search algorithm,
matching IKE key generation
proposals generate keys, and
proposal and identity
authenticate identity
information
2 Send
Receive the IKE Send key
acknowledged
proposal generation
IKE proposal Accept IKE proposal 2
information, identity,
Send key 3 and generate keys and authentication
generation Generate keys data
information
Send authentication 3
Send key Authenticate
4
Generate keys generation data exchange
information
Send identity Authenticate
and 5 Encrypted information
identifies and
authentication exchange Non-encrypted information
data
Send identity
Authenticate 6 and
identifies and
authentication
exchange
data
Compared with the main mode, the aggressive mode reduces the number of exchanged
messages and speeds up the negotiation, but it does not encrypt identity information.
Although the aggressive mode does not provide identity protection, it applies to the following
scenarios:
l If the IP address of the initiator is variable or unknown, and both the initiator and
responder need to use a pre-shared key to establish an IKE SA, only the aggressive mode
can be used.
l If the initiator already knows the IPSec policy used by the responder, it is faster to
establish an IKE SA in aggressive mode.
IKEv1 Negotiation Phase 2

Phase 2 establishes IPSec SAs used to securely transmit data and generates the key for data
transmission. The quick mode is used in phase 2. This mode uses the key generated in phase 1
to verify the integrity of ISAKMP messages and identities of the initiator and responder, and
to encrypt ISAKMP messages, ensuring exchange security. Figure 6-11 shows IKEv1
negotiation phase 2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-11 IKEv1 negotiation phase 2
Initiator Responder
Send IPSec
1 Search matching
proposals, identity,
IPSec proposal and
and authentication
generate keys
data
Accept IPSec Send acknowledged
2 IPSec proposal,
proposal and
identity, and
generate keys authentication data
Send acknowledge 3
Accept information
information
Phase 2 establishes two IPSec SAs through three ISAKMP messages:

1. The initiator sends local security parameters and identity authentication information to
the responder.
Security parameters include protected data flows and parameters to be negotiated such as
IPSec proposal. Identity authentication information includes the key generated in phase 1
and key materials generated in phase 2, and can be used to authenticate the peer again.
NOTE
An IPSec proposal is a set of protocols and algorithms used for negotiation, including security
protocol, encryption algorithm, and authentication algorithm.
2. The responder sends confirmed security parameters and identity authentication
information, and generates a new key.
The encryption key and authentication key used for IPSec SA data transmission are
generated based on the key generated in phase 1 and parameters such as SPI and
protocols, to ensure that each IPSec SA has a unique key.
If Perfect Forward Secrecy (PFS) needs to be enabled, the shared key calculated
through DH algorithm needs to be used again to generate the encryption key and
authentication key. During parameter negotiation, a DH key group needs to be negotiated
for PFS.
3. The initiator sends confirmed information to communicate with the responder. IKEv1
negotiation then ends.
6.2.2.3 Establishing an SA Through IKEv2 Negotiation
The process of establishing an SA through IKEv2 negotiation is much simpler than that
through IKEv1 negotiation. To establish a pair of IPSec SAs, IKEv1 requires two phases:
main mode (or aggressive mode) + quick mode. At least nine messages are exchanged in main
mode + quick mode, and at least six messages are exchanged in aggressive mode + quick
mode. In normal cases, IKEv2 can establish a pair of IPSec SAs only through four messages
in two exchanges. One additional Create_Child_SA Exchange can be used to establish
another pair of IPSec SAs if required, during which only two messages are exchanged.
IKEv2 defines three exchanges: Initial Exchanges, Create_Child_SA Exchange, and
Informational Exchange.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Initial Exchanges
In normal cases, IKEv2 can establish the first pair of IPSec SAs through Initial Exchanges.
Mapping phase 1 in IKEv1 negotiation, Initial Exchanges involves four messages in two
exchanges, as shown in Figure 6-12.
Figure 6-12 Initial Exchanges process
Initiator Responder
1 Search matching
Send IKE SA
IKE SA
parameters
parameters
Send matching
Accept 2
IKE SA
parameters parameters
Authenticate
Send identity 3
identity and
ifnoramtion
exchange
Authenticate 4 Send identity
identity and information
exchange
Messages (1) and (2) are used in exchange 1 (called IKE_SA_INIT) to negotiate IKE SA
parameters in plain text, including the encryption key and authentication key, random number,
and DH key. After IKE_SA_INIT is complete, a shared key material is generated, from which
all IPSec SA keys are derived.
Messages (3) and (4) are used in exchange 2 (called IKE_AUTH) to authenticate identities of
the two parties and the first two messages, and to negotiate IPSec SA parameters in
encryption mode. IKEv2 supports authentication modes including the RSA signature, pre-
shared key, and Extensible Authentication Protocol (EAP). EAP authentication is
implemented in IKE as an additional IKE_AUTH exchange. The initiator does not set the
authentication payload in message (3) to indicate that EAP authentication is required.
Create_Child_SA Exchange
When an IKE SA requires multiple pairs of IPSec SAs, Create_Child_SA Exchange is
performed to negotiate these IPSec SAs. In addition, Create_Child_SA Exchange can be
performed for IKE SA re-negotiation.
Create_Child_SA Exchange involves two messages in one exchange and maps phase 2 in
IKEv1 negotiation. The initiator can be the initiator or responder in Initial Exchanges.
Create_Child_SA Exchange can be performed only after Initial Exchanges are complete.
Exchange messages in Create_Child_SA Exchange are protected by keys negotiated in Initial
Exchanges.
Similar to IKEv1, if PFS is enabled, Create_Child_SA Exchange requires an additional DH

exchange to generate a new key material. All keys of child SAs are derived from this key
material.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Informational Exchange
IKEv2 peers perform Informational Exchange to exchange control information, including
error information and notifications, as shown in Figure 6-13.
Informational Exchange must be performed with IKE SA protection, that is, performed after
Initial Exchanges are complete. Control information may belong to an IKE SA or a child SA.
Therefore, Informational Exchange must be protected by the IKE SA or the IKE SA that
generates the child SA accordingly.
Figure 6-13 Informational Exchange process
Initiator Responder
1 Perform operations
Send control
based on control
information information
2 Respond to
Accept
control
information
information
6.2.3 IPSec Enhancements
6.2.3.1 L2TP over IPSec

L2TP over IPSec encapsulates packets using L2TP and then IPSec. It uses L2TP to
implement user authentication and address allocation and IPSec to ensure secure
communication. L2TP over IPSec ensures that branches or traveling employees connect to the
headquarters.
Figure 6-14 illustrates how L2TP over IPSec allows branches to connect to the headquarters.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-14 L2TP over IPSec packet encapsulation and tunnel negotiation
1 . Negotiating IPSec Tunnel
2. Negotiating L2TP Tunnel
L2TP over IPSec

Access user Server
Router_A(LAC) Router_B(LNS)
PPP L2TP encapsulation, IPSec decapsulation,

encapsulation IPSec encapsulation L2TP decapsulation,
PPP decapsulation
Data PPP packets IPSec packets Data Data
Private IP
Data Ethernet
Private IP Header
PPP
Header
PPPoE
Header
1. L2TP 2. Two IPSec encapsulation Type
Ethernet
encapsulation Transport mode Tunnel mode
Header
Data Data Data
Direction of data flow Private IP Private IP Private IP
Packet PPP PPP PPP
L2TP L2TP L2TP
UDP UDP UDP
Public IP AH Public IP
Header AH
Public IP Header
Public IP
The Public IP is The Public IP is

adding by the L2TP adding by the IPSec
encapsulation encapsulation
Packets are encapsulated by L2TP, and then by IPSec. In the IP header added during IPSec
encapsulation, the source IP address is the IP address of the interface to which the IPSec
policy is applied, and the destination IP address is the IP address of the peer interface to
which the IPSec policy on the remote peer is applied.
IPSec protects the data flows from the source to the destination of the L2TP tunnel. In the
new IP header added during L2TP encapsulation, the source IP address is the address of the
L2TP source interface, and the destination IP address is the address of the L2TP destination
interface. When a branch connects to the headquarters, the source address of the L2TP tunnel

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
is the IP address of the outbound interface on the LAC, and the designation address is the IP
address of the inbound interface on the LNS.
A public IP address is added to the header in L2TP encapsulation, and one more public IP
address is added in tunnel mode. As a result, the packets are larger and more packets will be
fragmented in tunnel mode. Therefore, the transport mode of L2TP over IPSec is
recommended.
The L2TP over IPSec negotiation sequence and packet encapsulation process are the same for
employees on the move and employees at branch offices. The difference is that, L2TP and
IPSec encapsulation is performed on clients when employees on the move connect to the
headquarters. The L2TP source address is the private address assigned to the client. The
address can be any address in the address pool configured on the LNS. The destination
address of the L2TP tunnel is the address of the inbound interface on the LNS.
6.2.3.2 GRE over IPSec

Integrating the advantages of both GRE and IPSec, GRE over IPSec uses GRE to encapsulate
multicast, broadcast, and non-IP packets into common IP packets, and uses IPSec to provide
secure communication for encapsulated IP packets. Therefore, broadcast and multicast
services such as video conference or messages of dynamic routing protocols, can be securely
transmitted between the headquarters and branch.
GRE over IPSec encapsulates packets using GRE, and then IPSec. The encapsulation can be
implemented in tunnel mode and transport mode. The tunnel mode uses an extra IPSec
header, which increases packet size and makes packets more likely to be fragmented.
Therefore, the transport mode is recommended.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-15 Packet encapsulation and tunnel negotiation in GRE over IPSec
1 . Negotiating IPSec Tunnel
2. Negotiating GRE Tunnel
Branch workers GRE over IPSec

Router_A Router_B Server
GRE encapsulation, IPSec decapsulation

then IPSec and GRE Data Data
encapsulation decapsulation
Data IPSec packets Private IP
Ethernet
Direction of data flow Header
Packet
1. GRE 2. Two IPSec encapsulation Type
encapsulation Transport mode Tunnel mode
Data Data Data
Private IP Private IP Private IP
GRE GRE GRE
Public IP AH Public IP
Header AH
Public IP Header
Public IP
The Public IP is The Public IP is

adding by the GRE adding by the IPSec
encapsulation encapsulation
In the IP header added during IPSec encapsulation, the source IP address is the IP address of
the interface to which the IPSec policy is applied, and the destination IP address is the IP
address of the peer interface to which the IPSec policy on the remote peer is applied.
IPSec protects the data flows from the GRE source address to the GRE destination address. In
the IP header added during GRE encapsulation, the source address is the source address of the
GRE tunnel, and the destination address is the destination address of the GRE tunnel.
6.2.3.3 IPSec Multi-instance

IPSec multi-instance is used to provide the firewall lease service to isolate networks of small
enterprises.
As shown in Figure 6-16, branches of three small enterprises share a VPN gateway. The three
enterprise networks must be isolated. IP addresses of each enterprise are planned
independently, and therefore IP addresses on different private networks may overlap. The
IPSec multi-instance function can be configured on the VPN gateway to bind IPSec tunnels of

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
the three enterprises to different VPN instances. This ensures that packets with the same
destination IP addresses can be correctly forwarded.
Figure 6-16 Typical IPSec multi-instance network
Entrprise 1 Enterprise 1
headquarters VPN gateway
Branch
FW VPN1
Entrprise 2 VPN2 Enterprise 2
headquarters Branch
VPN3
Entrprise 2
headquarters Enterprise 3
Branch
6.2.3.4 Efficient VPN

On an enterprise network with many branches, IPSec must be configured on headquarters and
branch gateways. These IPSec configurations are complex and difficult to maintain. IPSec
Efficient VPN can solve these problems with its high security, reliability, and flexibility. It has
become the first choice for enterprises to establish VPNs.
Efficient VPN uses the client/server model. It concentrates IPSec and other configurations on
the Efficient VPN server (headquarters gateway). When basic parameters for establishing an
SA are configured on the remote devices (branch gateways), the remote devices initiate a
negotiation and establish an IPSec tunnel with the server. After IPSec tunnels are established,
the Efficient VPN server allocates other IPSec attributes and network resources to the remote
devices. Efficient VPN simplifies configurations and maintenance of IPSec and network
resources for the branches. In addition, Efficient VPN supports automatic upgrades on remote
devices.
Operation Modes
l Client mode
a. When a remote device requests an IP address from the Efficient VPN server, a
loopback interface is dynamically created on the remote device and the IP address
obtained from the server is assigned to the loopback interface.
b. The remote device automatically enables NAT to translate its original IP address
into the obtained IP address, and then uses this IP address to establish an IPSec
tunnel with the headquarters.
c. The remote device automatically enables NAT to translate its original IP address

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The client mode applies to scenarios where traveling staff or small-scale branches
connect to the headquarters network through private networks, as shown in Figure 6-17.
In client mode, devices connected to the Efficient VPN server or remote devices can use
the same IP address. However, the number of devices allowed depends on the number of
IP addresses assigned by the Efficient VPN server.
Figure 6-17 Client mode

192.168.0.5/32
SOHO office
10.1.0.1/24
192.168.0.6/32 Remote
SOHO office
Headquarters
Remote
10.1.0.5/32 Server
Traveling staff
Remote
10.1.0.6/32
Traveling staff
Remote
NOTE
Traveling staff use software to establish a virtual network adapter on a PC. The virtual network
adapter then uses parameters such as addresses sent by the Efficient VPN server.
l Network mode
In network mode, a remote device does not apply to the Efficient VPN server for an IP
address. Therefore, NAT is not automatically enabled in network mode. Figure 6-18
shows the network mode.
Figure 6-18 Network mode
10.1.1.X
Branch 1 10.1.0.X
Remote
Headquarters
Server
10.1.2.X
Branch N
Remote

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The network mode applies to scenarios where IP addresses of the headquarters and
branches are planned uniformly. Ensure that IP addresses do not conflict.
l Network-plus mode
Compared with the network mode, the remote device applies to the Efficient VPN server
for an IP address in network-plus mode. IP addresses of branches and headquarters are
configured beforehand. A remote device applies to the Efficient VPN server for an IP
address. The Efficient VPN server uses the IP address to perform ping, STelnet, or other
management and maintenance operations on the remote device. NAT is not automatically
enabled on the remote device.
l Network-auto-cfg mode
Compared with the network-plus mode, the remote device applies to the Efficient VPN
server for an IP address pool in network-auto-cfg mode. The IP address pool is used for
allocating addresses to users.
The Efficient VPN server also delivers the following resources in addition to parameters for
establishing an IPSec tunnel:
l Network resources including the DNS domain name, DNS server IP addresses, and
WINS server IP addresses
The Efficient VPN server delivers the preceding resources so that branches can access
them on the Efficient VPN server.
l ACL resources
The Efficient VPN server delivers headquarters network information defined in an ACL
to the remote device. The ACL defines the headquarters subnets that branches can
access. Traffic not destined for the subnets specified in the ACL is directly forwarded to
the Internet. Such traffic does not pass through the IPSec tunnel.
NOTE
In the Network-auto-cfg mode, delivering of parameters defined in the ACL is not supported.
Automatic Upgrade of Efficient VPN Remote Devices

The server defines the uniform resource locator (URL) used to upgrade remote devices. A
remote device automatically downloads the version file, patch file, and configuration file
according to the URL configuration file to complete an upgrade. Automatic upgrade
facilitates network deployment and maintenance. Figure 6-19 shows the procedure for
automatically upgrading the remote device.
Figure 6-19 Automatic upgrade of remote devices
Server
3 Version file, patch
file, and configuration
file download and
delivery
1 URL request
Branch Headquarters
subnet 2 URL delivery network
Remote Server

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. A remote device with basic IPSec Efficient VPN configuration connects to the
headquarters.
2. The remote device applies to the server for the address and version number of the URL
configuration file.
3. The remote device obtains the address and version number of the URL configuration file
and downloads the URL configuration file from the specified server.
4. The remote device downloads the corresponding version file, patch file, and
configuration file according to the URL configuration file.
5. The remote device performs the upgrade according to the version file, patch file, and
configuration file.
6.2.4 IPSec Reliability
6.2.4.1 Link Redundancy

To improve network reliability, an enterprise connects a branch network to the headquarters
network through two or more links. When a link fails, services are immediately switched to
another link. The device provides two redundancy modes: active/standby IPSec links and
IPSec multi-link.
Active and Standby IPSec Links

In Figure 6-20, Router_A connects to Router_B through active/standby links. Two tunnel
interfaces are created on Router_A and they borrow the IP address of the same physical
interface. Different IPSec policies are applied to the two tunnel interfaces to create active and
standby IPSec tunnels. Different IPSec policies are applied to the two physical interfaces on
Router_B. When the active link fails, traffic is switched to the standby link. A new IPSec
tunnel is established on the standby link, and the old IPSec tunnel is deleted.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-20 Active and standby IPSec links

IPSec Tunnel
Interface Tunnel 1 Active

PC link Router_B PC
Router_A
Branch Standby HQ
link
Server Interface Tunnel 2

Server
Interface Tunnel 1 Active

PC link Router_B PC
Router_A
Branch Standby HQ
link
Interface Tunnel 2
Server Server
IPSec Tunnel
Data flows
IPSec Multi-link
In Figure 6-21, Router_A connects to Router_B through active/standby links. An IPSec
tunnel is established between the physical interface of Router_A and tunnel interface of
Router_B. Traffic is processed by IPSec on the tunnel interface and sent out by a physical
interface according to the routing table. When the active link fails, the route is unreachable
and traffic is switched to the standby link. Re-negotiation is not required for the IPSec tunnel,
so traffic can be rapidly switched.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-21 Using the tunnel interface to implement link redundancy

IPSec Tunnel
PC
PC
Active link
Branch Tunnel1 HQ
Standby Router_B
Router_A
Server link Server
IPSec Tunnel
PC
Active PC
link
Branch Tunnel1 HQ
Standby Router_B
Router_A
Server link
Server
Data flows
A tunnel interface can implement multi-link redundancy. This mode is more simple and
switches traffic faster than the active/standby links.
In the scenario where an IPSec gateway is connected to different ISP networks or the same
ISP network but the active and standby links are connected to different access routers of the
same ISP network across LANs or areas, if the active link becomes faulty, the device on the
standby link may discard the IPSec packets whose source address belongs to a different ISP
network or access router. Therefore, before configuring link redundancy, check whether
active/standby link switching is allowed in the actual network environment.
6.3 Application Scenarios for IPSec

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.3.1 Using IPSec VPN to Implement Secure Interconnection

Between LANs
The headquarters and branches of an enterprise are interconnected in various ways.
Site-to-Site VPN — IPSec

A site-to-site VPN, also called LAN-to-LAN VPN or gateway-to-gateway VPN, is used to set
up an IPSec tunnel between two gateways, implementing secure access of LANs. Figure 6-22
shows a typical site-to-site IPSec VPN network.
Figure 6-22 Typical site-to-site IPSec VPN network

IPSec Tunnel
PC PC
Branch Headquarters
Router_A Router_B
Server
Server
This network requires that the two gateways on both ends of the tunnel have fixed IP
addresses or fixed domain names, and both parties be able to initiate a connection.
NOTE
l A Router can serve as both an IPSec gateway and a NAT gateway.

l When a NAT device exists between two IPSec gateways, Routers support IPSec NAT traversal.
Site-to-Site VPN — L2TP over IPSec

L2TP over IPSec encapsulates packets using L2TP before transmitting them using IPSec.
L2TP and IPSec are used together to allow branches to securely access VPNs by dialing the
L2TP access concentrator (LAC). Branches use L2TP to dial the LAC and obtain private IP
addresses on the headquarters network. IPSec is used to ensure communication security
during this process.
Figure 6-23 shows a network for the branch to access the headquarters through an L2TP over
IPSec tunnel. The outbound interfaces of the LAC (FW_A) and L2TP network server (LNS)
(FW_B) have fixed IP addresses. A user in the branch dials FW_A through PPPoE. FW_A
then initiates a tunnel setup request to FW_B over the Internet. An L2TP over IPSec is set up
between FW_A and FW_B. Then FW_A authenticates the user, and FW_B can also
authenticate the user again if the user is successfully authenticated by FW_A. After the user is
successfully authenticated by FW_B, FW_B assigns a private IP address to the user.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-23 Branch accessing the headquarters through an L2TP over IPSec tunnel
L2TP over IPSec Tunnel
PPPoE
PC PC
Router_A Router_B
(LAC) (LNS)
Branch Headquarters
Site-to-Site VPN — GRE over IPSec

Generic Routing Encapsulation (GRE) is a generic tunneling protocol that encapsulates
multicast, broadcast, and non-IP packets. GRE, however, provides only simple password
authentication but not data encryption, and therefore cannot ensure data transmission security.
IPSec provides high data transmission security but cannot encapsulate multicast, broadcast, or
non-IP packets. Leveraging advantages of GRE and IPSec, GRE over IPSec encapsulates
multicast, broadcast, and non-IP packets into common IP packets. For example, to hold a
video conference between the branch and headquarters, use GRE over IPSec to transmit
service traffic on an IPSec VPN.
Figure 6-24 shows a typical GRE over IPSec VPN network.
Figure 6-24 Typical GRE over IPSec VPN network

GRE over IPSec Tunnel
PC PC
Branch Headquarters
Router_A Router_B
Server Server
GRE over IPSec supports the transport and tunnel encapsulation modes. Compared to the
transport mode, the tunnel mode has an IPSec header, which makes the packet longer and
easier to be fragmented. Therefore, GRE over IPSec in transport mode is recommended.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Hub-Spoke VPN
In most cases, the headquarters of an enterprise are connected to multiple branches through
IPSec VPN tunnels. Figure 6-25 shows a typical network.
Figure 6-25 Typical hub-spoke IPSec VPN network

IPSec Tunnel
Router_A
(Spoke) Server
Branch 1 Router_C
(Hub)
HQ
Branch 1
Router_B PC
(Spoke)
IPSec Tunnel
The headquarters has a fixed public IP address or fixed domain name. Branches support static
or dynamic public IP addresses and private IP addresses. Data traffic is transmitted in the
following scenarios:
l Branches do not need to communicate with each other.
Deploy IPSec VPN between the headquarters and branches.
l Branches need to communicate with each other.
If branches access the Internet using dynamic public IP addresses, traditional IPSec VPN
will lead to a communication failure between branches. Communication data between
branches has to be forwarded through the headquarters. This consumes the CPU and
memory resources of the hub (FW_C). In addition, the headquarters must encapsulate
and decapsulate traffic between branches, causing additional network delay.
To resolve this problem, deploy Dynamic Smart VPN (DSVPN) to set up VPN tunnels
between branches using dynamic IP addresses. However, multipoint GRE (mGRE)
tunnels do not have the encryption function and cannot ensure communication security.
To achieve communication security, bind DSVPN with the IPSec security framework,
that is, deploy DSVPN over IPSec. For details about DSVPN over IPSec, see 5.2.4
DSVPN Protected by IPSec.
6.3.2 Using IPSec VPN to Provide Secure Remote Access for

Mobile Users
In public places, such as hotels and airports, traveling staff or partners connect to the core
network through the insecure access network or public network such as the Internet to access
internal resources of the core network. This process is called remote access. In remote access,
traveling staff or partners access the core network through the insecure network; therefore,
security is a major concern in remote access. IPSec VPN can be deployed to establish an

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IPSec tunnel between a user terminal and the gateway of the core network. IPSec ensures
secure and reliable data transmission.
As shown in Figure 6-26, mobile users (such as traveling staff) use built-in VPN dial-up
software of Windows or other dial-up software to dial to access the enterprise network. L2TP
provides the user authentication function, but no encryption function. To ensure security,
deploy L2TP over IPSec and set up an L2TP over IPSec tunnel between the PC and enterprise
gateway Router. Packets are encapsulated using L2TP and encrypted using IPSec before
being transmitted, ensuring communication security.
Access users are authenticated locally or remotely by the authentication server (RADIUS
server, for example) in the headquarters. After authentication is successful, Router assigns
private IP addresses within the headquarters network to users (PCs or mobile terminals).
Figure 6-26 Remote access of mobile users using L2TP over IPSec
L2TP over IPSec Tunnel
Router
Enterprise
network
PC
RADIUS Server
6.3.3 Secure LAN Interconnection Through Efficient VPN

In Figure 6-27, when many branches and traveling staff need to communicate with the
headquarters over IPSec tunnels, many similar or duplicate IPSec configurations and other
network resource configurations need to be performed on the gateways of branches and
headquarters. Efficient VPN provides a method to simplify the configurations. It allows you
to perform complex configurations on the headquarters gateway and simple configurations on
each branch gateway, freeing you from complex IPSec VPN configuration and maintenance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-27 Efficient VPN networking

SOHO office/
Traveling staff 1
…
SOHO office/
Traveling staff N
Branch 1 Headquarters
…
Branch N
IPSec Tunnel
6.4 Summary of IPSec Configuration Tasks

Two IPSec peers establish inbound and outbound security associations (SAs) to form a secure
IPSec tunnel through which data packets can be transmitted securely on the Internet.
Table 6-5 lists IPSec configuration tasks.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 6-5 IPSec configuration tasks

Scenario Description Task
Using an ACL to establish An ACL defines data flows 6.7 Using an ACL to
an IPSec tunnel to be protected. You need to Establish an IPSec Tunnel
configure an IPSec policy
and apply the IPSec policy
to an interface to protect
IPSec packets. You can use
an ACL to establish an
IPSec tunnel in manual
mode or IKE negotiation
mode.
SAs can be established in
either of the following
modes:
l Manual mode: All
information required by
SAs must be manually
configured.
l IKE negotiation mode:
IPSec peers use IKE to
negotiate keys and
dynamically create and
maintain SAs.
The manual mode applies to
small-sized networks or
scenarios where a few IPSec
peers exist. The IKE
negotiation mode applies to
medium- and large-sized
networks.
Using a tunnel interface to An IPSec tunnel is 6.8 Using a Virtual Tunnel

establish an IPSec tunnel established using a tunnel Interface to Establish an
interface based on routes. In IPSec Tunnel
this mode, routes determine
the data flows to be
protected.
You need to configure an
IPSec profile and apply the
IPSec profile to the IPSec
tunnel interface to protect
IPSec packets. All the
packets routed to the IPSec
tunnel interface are
protected by IPSec.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Using the Efficient VPN Efficient VPN uses the 6.9 Establishing an IPSec
policy to establish an IPSec client/server model. It Tunnel Using an Efficient
tunnel concentrates IPSec and VPN Policy
other configurations on the
Efficient VPN server
(headquarters gateway).
When basic parameters for
establishing an SA are
configured on the remote
devices (branch gateways),
the remote devices initiate a
negotiation and establish an
IPSec tunnel with the server.
After IPSec tunnels are
established, the Efficient
VPN server allocates other
IPSec attributes and network
resources to the remote
devices. Efficient VPN
simplifies configurations
and maintenance of IPSec
and network resources of
branches.
In addition, Efficient VPN
supports automatic upgrades
of remote devices.
In manual mode, an ACL is used to establish an IPSec tunnel. In other modes, SAs are
generated through IKE negotiation to establish an IPSec tunnel and an IKE peer needs to be
configured and referenced.
6.5 Licensing Requirements and Limitations for IPSec

None
Licensing Requirements
When using the Efficient VPN policy to establish an IPSec tunnel, note the following points:
l If a branch server needs to provide services for external users through NAT, the nat
static command must be used on the remote device.
l When a remote device requests an IP address from the Efficient VPN server, a loopback
interface is dynamically created on the remote device. Other services cannot be
configured on the loopback interface.
For Efficient VPN-capable devices, their licensing requirements for the Efficient VPN
function are as follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l AR100&AR120 series: Efficient VPN is a basic feature of the device and is not under
license control.
Efficient VPN function is disabled on a new device. To use the Efficient VPN function,
apply for and purchase the following license from the Huawei local office.
– AR150&AR160&AR200 series: AR150&160&200 Value-Added Security Package
Impact on Performance
l The DH group value has impacts on IKE negotiation performance (such as the tunnel
creation rate). A higher DH group value has greater impacts on IKE negotiation
performance (for example, the tunnel creation rate greatly decreases).
l When the number of IPSec tunnels is larger than 50% of the maximum limit, high CPU
usage alarms may be generated in a short period of time after the undo ipsec policy or
undo ipsec profile command is run. After all the SAs are cleared, the CPU usage
restores to the normal range.
Restrictions on the Use of IPSec

l The security protocol, authentication algorithm, encryption algorithm, and packet
encapsulation mode on both tunnel endpoints must be the same when you configure a
security proposal. Otherwise, tunnel negotiation will fail. If the PFS algorithm is
configured, ensure that the two ends use the same PFS algorithm. Otherwise, tunnel
negotiation will fail.
l In L2TP over IPSec scenarios, the function that the responder accepts the security
proposal of the initiator is usually used together with L2TP. Separate use of this function
will reduce network security, and is therefore not preferred.
l To reference an ACL in an IPSec policy, ensure that rules must be configured in this
ACL view and the number of rules configured in this ACL view does not exceed 256.
Otherwise, this ACL cannot be referenced in this IPSec policy.
l When configuring IPSec to-be-encrypted data flows, configure refined ACL rules based
on services to prevent unnecessary data flows from entering the encryption tunnel due to
loose ACL rules, causing service interruption.
l Setting the MTU to a value smaller than 256 bytes is not recommended for the interface
to which an IPSec security policy group applies. As IP packets become longer after
IPSec processing, a small MTU makes the interface divide a large IP packet into
multiple fragments. The peer device may not properly receive or process such
fragmented packets.
l When a NAT device is deployed between IPSec peers, NAT traversal must be enabled
and the security protocol must be ESP.
l In AH encapsulation mode, the DF flag bit of the inner packet is inherited to the outer
packet, and the Router combines it with the DF flag bit of the outer layer to calculate the
checksum of the packet. If the peer end of the tunnel removes the DF flag bit from the
outer packet and then calculates the checksum, the checksum on both ends of the tunnel
is inconsistent. As a result, the interconnection fails. To prevent this, run the ipsec df-bit
clear command to ensure that the checksum on both ends of the tunnel is consistent.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l When the IPSec protocol on both the AR and its connected other device uses the SHA-2
algorithm, an IPSec tunnel can be established but traffic cannot be transmitted if the
SHA-2 encryption and decryption modes on the two devices are different. If so, you are
advised to run the ipsec authentication sha2 compatible enable command on the AR to
set the SHA-2 encryption and decryption modes to be the same as those on the other
device.
l It is not recommended that IPSec be deployed on both physical interfaces and tunnel
interfaces. If IPSec is deployed on both physical interfaces and tunnel interfaces, the
device functioning as the negotiation responder first attempts to perform tunnel
negotiation through IPSec of a tunnel interface. If the device does not match IPSec
access requirements of the tunnel interface, the device attempts to perform tunnel
negotiation through IPSec of a physical interface.
l In transport mode, the flow information after IPSec negotiation must be consistent with
the IPSec tunnel address, a 32-bit host address.
Restrictions on the Use with NAT

If NAT is configured on an interface where an IPSec policy group applies, the IPSec
configuration may not take effect because the device performs NAT first.
l If the interface implements IPSec but not NAT, the action of the ACL rule referenced by
NAT needs to be set to deny, and the destination IP address of the rule needs to be set to
that of the ACL rule referenced by the IPSec policy.
l If the interface implements NAT but not IPSec, the destination IP address of the ACL
rule referenced by the IPSec policy cannot be a NATed IP address.
l If the interface implements both NAT and IPSec, the destination IP address of the ACL
rule referenced by the IPSec policy must be a NATed IP address.
6.6 Default Settings for IPSec

Table 6-6 Default settings for IPSec
Local host name used in IKE negotiation Local device name
Interval for sending NAT keepalive packets 20s
IKE proposal An IKE proposal with the lowest priority.

For details, see 6.11.1 Configuring an IKE
Proposal.
IPSec proposal no IPSec proposal is configured. For

detailed parameters in the created IPSec
proposal, see 6.7.2 Configuring an IPSec
Proposal.
SA trigger mode Auto
IKE SA hard lifetime 86400s

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Global IPSec SA hard lifetime l Time-based: 3600s

l Traffic-based: 1843200 Kbytes (1800
Mbytes)
ACL check for decrypted packets Disabled
Global IPSec anti-replay Enabled
Global IPSec anti-replay window size 1024
Packet fragmentation mode Fragmentation after encryption
NAT traversal Enabled
6.7 Using an ACL to Establish an IPSec Tunnel

On an IPSec tunnel established in manual or IKE negotiation mode, an ACL defines data
flows to be protected. The packets that match the permit clauses in the ACL are protected, and
the packets that match the deny clauses are not protected. The ACL can define packet
attributes such as the IP address, port number, and protocol type, which help you flexibly
define IPSec policies.
Before establishing an IPSec tunnel using an ACL, complete the following tasks:
l Configure a reachable route between source and destination interfaces.
l (Optional) If L2TP over IPSec needs to be configured, perform the following
configurations:
a. Configure LAC on the branch gateway. If a client on the branch network dials to
connect to the headquarters network through the LAC, configure NAS-initiated
VPN LAC. If the LAC connects to the headquarters network through automatic
dial-up, configure LAC auto-dial.
b. Configure LNS on the headquarters gateway.
l (Optional) If ACL-based GRE over IPSec needs to be configured, perform the following
configurations:
a. Create a tunnel interface and set the type of the interface to GRE.
b. Configure source and destination IP addresses, and interface IP addresses. The
source IP address is the IP address of the outbound interface on the gateway, and
the destination IP address is the IP address of the outbound interface on the remote
gateway.
c. Add tunnel interfaces to a zone.
Figure 6-28 shows the configuration process (IKEv1 is used).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-28 Using an ACL to establish an IPSec tunnel
1 Preparations
(1) Define data flows to be
protected by IPSec (3) Define IKE protection method (4) Define attributes of IKE peers
(1) Configure an advanced ACL (3) Configure an IKE proposal (4) Configure an IKE peer
ike proposal ike peer
Configure an advanced Configure an authentication
ACL rule mode Reference an IKE proposal
rule permit ip authentication-method ike-proposal
(2) Define IPSec protection method Configure an authentication
algorithm Configure an authentication
(2)Configure an IPSec proposal authentication-algorithm key
ipsec proposal
Configure an encryption Configure a remote IP
Configure a security algorithm address
protocol encryption-algorithm remote-address
transform
Configure a DH group Configure a phase 1
Configure an authentication negotiation mode
dh
algorithm exchange-mode
IKE SA lifetime (Optional) Set parameter
Configure an encryption
sa duration extensions
algorithm
(Optional) Set parameter
Configure an encapsulation
extensions
mode
encapsulation-mode
2 Configure an IPSec policy. Use a specified protection method for specified data flows.
· Manually created IPSec policy · IPSec policy established · IPSec policy established using
in IKE negotiation mode an IPSec policy template
Configure an IPSec policy
Configure an IPSec policy Configure an IPSec policy
template
ipsec policy manual ipsec policy isakmp
ipsec policy-template
Reference an IPSec
Reference an ACL Reference an ACL
proposal
security acl security acl
proposal
Reference an IPSec
Reference an IPSec proposal Reference an IKE peer
proposal
proposal ike-peer
proposal
Configure source and
Reference an IKE peer (Optional) Set parameter
destination of an IPSec tunnel
ike-peer extensions
tunnel local
tunnel remote
Configure SPIs of the inbound (Optional) Set parameter
and outbound Sas extensions Reference an IPSec policy
sa spi outbound template in an IPSec policy
sa spi inbound ipsec policy policy-name
seq-number isakmp
Configure authentication and template
encryption keys of inbound and
outbound SAs

extensions
3 Apply an IPSec policy group to an interface. An IPSec tunnel is established when IPSec parameters at
both ends are the same.
Enter the system view Enter the interface view
system-view interface
+ Apply the IPSec policy
group
extensions
ipsec policy

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.1 Defining Data Flows to Be Protected
Context
IPSec can protect one or more data flows, and the ACL specifies data flows to be protected by
IPSec. Therefore, you need to create an ACL and apply the ACL to an IPSec policy. An IPSec
policy can reference only one ACL. Note the following points:
l If data flows have different security requirements, create different ACLs and IPSec
policies.
l If data flows have the same security requirements, configure multiple rules in an ACL.
ACL Keyword Usage
Each ACL rule is a deny or permit clause. In IPSec applications, a permit clause identifies a
data flow protected by IPSec, and a deny clause identifies a data flow that is not protected by
IPSec. An ACL can contain multiple rules. A packet is processed according to the first rule
that it matches.
l In the outbound direction of an SA

If a packet matches a permit clause, IPSec encapsulates and sends the packet. If a packet
matches a deny clause or does not match a permit clause, IPSec directly forwards the
packet. A matched permit clause indicates that a data flow needs to be protected and a
pair of SAs is created.
l In the inbound direction of an SA
The packet protected by IPSec is decrypted and the packet not protected by IPSec is
forwarded.
NOTE
If 6.7.8 (Optional) Configuring IPSec Check is performed, the device re-checks whether the IP
header of the decrypted IPSec packet is in the range defined by the ACL. If the decrypted IPSec packet
matches the permit clause, the device continues to process the IPSec packet. If the decrypted IPSec
packet does not match the permit clause, the device discards the IPSec packet.
Precautions
l The protocols defined in the ACLs on both ends of the IPSec tunnel must be the same.
For example, if the protocol on one end is IP, the protocol must also be IP on the other
end.
l When ACL rules at both ends of an IPSec tunnel mirror each other, SAs can be set up
successfully no matter which party initiates negotiation. If ACL rules at both ends of an
IPSec tunnel do not mirror each other, SAs can be set up successfully only when the
range specified by ACL rules on the initiator is included in the range specified by ACL
rules on the responder. It is recommended that ACL rules at both ends of an IPSec tunnel
mirror each other. That is, the source and destination addresses of an ACL rule at one
end are the destination and source addresses of an ACL rule at the other end. The IKEv1
and IKEv2 configurations are as follows:
If IPSec policies in ISAKMP mode are configured at both ends, ACL rules at both ends
of an IPSec tunnel must mirror each other. If an IPSec policy in ISAKMP mode is
configured at one end and an IPSec policy using an IPSec policy template is configured
at the other end, the range specified by ACL rules in the IPSec policy in ISAKMP mode
can be included in the range specified by ACL rules in the IPSec policy using an IPSec
policy template. The devices use overlapping ACL rules as the negotiation result.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Avoid overlapped address segments in ACL rules. Rules with overlapped address
segments may affect each other, causing data flow mismatch.
l The ACL referenced in an IPSec policy group cannot contain rules of the same ID.
l ACL rules referenced in all IPSec policies of an IPSec policy group cannot overlap. In
the following example, ACL 3001 and ACL 3002 overlap.
acl number 3001
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
acl number 3002
l When the responder uses an IPSec policy template, note the following points:
If data flows to be protected are not specified, the responder accepts the range of data
flows to be protected on the initiator. If data flows to be protected are specified, the ACL
on the responder must mirror the ACL on the initiator or the range specified by the ACL
on the responder must cover the range specified by the ACL on the initiator.
After an IPSec tunnel has been established, if both permit and deny actions are
configured in an ACL rule in the IPSec policy template view, the deny action does not
take effect.
l If NAT is configured on an interface to which an IPSec policy is applied, IPSec may not
take effect because NAT is performed first. You can use the following methods:
– Configure the destination IP address that matches the deny clause in an ACL
referenced by NAT as the destination IP address in an ACL rule referenced by
IPSec. In this case, data flows protected by IPSec are not translated by NAT.
– Configure the ACL rule referenced by NAT to match the IP address translated by
NAT.
Procedure
Step 2 Run acl [ number ] acl-number [ match-order { config | auto } ]
An advanced ACL is created and the advanced ACL view is displayed. acl-number ranges
from 3000 to 3999.
Step 3 Run the following commands as required.
l Run the rule [ rule-id ] { deny | permit } ip [ destination { destination-address
destination-wildcard | any } | source { source-address source-wildcard | any } | dscp
dscp | vpn-instance vpn-instance-name ] * command to configure a rule to match the IP
protocol.
l Run the rule [ rule-id ] { deny | permit } tcp [ destination { destination-address
destination-wildcard | any } | destination-port eq port | source { source-address source-
wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *
command to configure a rule to match the TCP protocol.
l Run the rule [ rule-id ] { deny | permit } udp [ destination { destination-address
destination-wildcard | any } | destination-port eq port | source { source-address source-
wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *
command to configure a rule to match the UDP protocol.
l Run the rule [ rule-id ] { deny | permit } gre [ destination { destination-address
destination-wildcard | any } | source { source-address source-wildcard | any } | dscp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
dscp | precedence precedence | tos tos | time-range time-name | logging | vpn-instance

vpn-instance-name ] * command to configure a rule to match the GRE protocol.
l Run the rule [ rule-id ] { deny | permit } gre [ destination { destination-address
destination-wildcard | any } | source { source-address source-wildcard | any } | [ dscp
dscp | [ tos tos | precedence precedence ] * ] | time-range time-name | logging | vpn-
instance vpn-instance-name ] * command to configure a rule to match the GRE protocol.
NOTE
If the data flow to be protected carries VPN labels, the corresponding vpn-instance-name must be specified
during the ACL configuration.
----End
Configuration Guidelines
The configurations of rules vary in different scenarios. For details, see the following
examples:
Site-to-Site IPSec VPN
A site-to-site IPSec tunnel is set up between gateway A and gateway B. Gateway A protects
subnet 10.1.1.0/24 and gateway B protects subnet 192.168.196.0/24.
Configurations on gateway A:
[Huawei] acl 3001
[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination
192.168.196.0 0.0.0.255
Configurations on gateway B:
[Huawei] acl 3001
10.1.1.0 0.0.0.255
Ensure that the subnets on both ends use the same wildcard.
Hub-Spoke IPSec VPN
Hub-Spoke IPSec tunnels are set up between the headquarters and branches. The headquarters
resides at subnet 192.168.196.0/24; branch A resides at subnet 10.1.1.0/24; branch B resides
at subnet 10.1.2.0/24.
l To allow the communication between branches and the headquarters but forbid the
communication between branches, configure the ACL for the branch network in the
same way as in the site-to-site IPSec VPN. Note that the destination address of the ACL
at the headquarters must include all branch subnets.
The ACL at the headquarters is configured as follows:
[Huawei] acl number 3001
[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255
destination 10.1.1.0 0.0.0.255
destination 10.1.2.0 0.0.0.255
[Huawei-acl-adv-3001] quit
l To allow the communication between branches and the headquarters, and between
branches through the headquarters, set the source address of the ACL at the headquarters
to all subnets of the headquarters and branches. Set the destination address to all branch
subnets. The source addresses of the ACLs at the branch offices remain, but the
destination addresses must be the subnets of the headquarters and all other branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The ACL at the headquarters is configured as follows:

destination 10.1.1.0 0.0.0.255
destination 10.1.2.0 0.0.0.255
10.1.2.0 0.0.0.255
10.1.1.0 0.0.0.255
The ACL at branch A is configured as follows:

10.1.2.0 0.0.0.255
192.168.196.0 0.0.0.255
The ACL at branch B is configured as follows:

10.1.1.0 0.0.0.255
192.168.196.0 0.0.0.255
IPSec Gateway with NAT Configured

l If endpoint A uses NAT only for the Internet access, not for IPSec traffic, you must reject
the IPSec traffic from NAT.
Endpoint A protects network 10.1.1.0/24 and endpoint B protects network
192.168.196.0/24. The ACL and NAT configurations on endpoint A are as follows:
# Define the data flow to be protected.
[Huawei] acl 3001
192.168.196.0 0.0.0.255
# Exclude the networks connected by the IPSec tunnel from the ACL referenced in the
NAT policy.
[Huawei] acl 3005
[Huawei-acl-adv-3005] rule deny ip source 10.1.1.0 0.0.0.255 destination
192.168.196.0 0.0.0.255
Configurations on gateway B:
[Huawei] acl 3001
destination 10.1.1.0 0.0.0.255
l If the two networks overlap, endpoint A performs NAT for all traffic and then performs
IPSec.
If the networks protected by endpoints A and B are both network 10.1.1.0/24, the private
addresses are translated to 10.1.2.1, the configurations on endpoints A and B are as
follows:
On endpoint A:
[Huawei] acl 3001
10.1.1.0 0.0.0.255
On endpoint B:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Huawei] acl 3001

10.1.2.0 0.0.0.255
L2TP over IPSec

In a scenario where L2TP over IPSec is deployed, IPSec protects data flows that are
encapsulated through L2TP, that is, data flows sent from the LAC to the LNS or from the
LNS to the LAC.
– If the LAC uses a fixed IP address, source and destination network segments in
ACL rules are addresses of public interfaces (LAC-side outbound interface and
LNS-side inbound interface) on devices at both ends. Assume that the IP address of
the LAC-side outbound interface is 1.1.1.1/24 and the IP address of the LNS-side
inbound interface is 1.2.1.1/24.
Configuration on the LAC:
[Huawei-acl-adv-3001] rule permit ip source 1.1.1.1 0 destination
1.2.1.1 0
Configuration on the LNS:

[Huawei-acl-adv-3001] rule permit ip source 1.2.1.1 0 destination
1.1.1.1 0
– If the LAC does not use a fixed IP address, specify UDP port 1701 in an ACL to
match L2TP over IPSec data flows. On the LAC, configure destination UDP port
1701.
Configuration on the LAC:
[Huawei-acl-adv-3001] rule permit udp destination-port eq 1701
Configuration on the LNS:

[Huawei-acl-adv-3001] rule permit udp source-port eq 1701
GRE over IPSec

When a GRE over IPSec tunnel is set up using an ACL, data flows protected by IPSec
are encapsulated with the GRE header. The source and destination network segments of
an ACL are source and destination addresses of the GRE tunnel, that is, addresses of
gateway interfaces at both ends.
Assume that the public addresses on endpoints A and B are 1.1.1.1/24 and 1.2.1.1/24,
respectively.
Configuration on endpoint A:
[Huawei-acl-adv-3001] rule permit ip source 1.1.1.1 0 destination 1.2.1.1 0
Configuration on endpoint B:
[Huawei-acl-adv-3001] rule permit ip source 1.2.1.1 0 destination 1.1.1.1 0
6.7.2 Configuring an IPSec Proposal

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
An IPSec proposal, as part of an IPSec policy or an IPSec profile, defines security parameters
for IPSec SA negotiation, including the security protocol, encryption and authentication
algorithms, and encapsulation mode. Both ends of an IPSec tunnel must be configured with
the same parameters.
Procedure
Step 2 Run ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.
Step 3 Run transform { ah | esp | ah-esp }
A security protocol is configured.
By default, an IPSec proposal uses ESP.
Step 4 An authentication or encryption algorithm is configured.
l If AH is used, you can only configure the AH-specific authentication algorithm because
AH only authenticates packets.
Run ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
An AH-specific authentication algorithm is configured.
By default, the AH authentication algorithm is SHA2-256.
l When ESP is specified, ESP can encrypt/authenticate, or encrypt and authenticate
packets. Configure the ESP-specific authentication or encryption algorithm.
– Run esp authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 |
sha2-512 }
An ESP-specific authentication algorithm is configured.
By default, the ESP authentication algorithm is SHA2-256.
– Run esp encryption-algorithm { 3des | des | aes-128 | aes-192 | aes-256 }
An ESP-specific encryption algorithm is configured.
By default, the ESP encryption algorithm is AES-256.
l When both AH and ESP are used, AH authenticates packets, and ESP can encrypt and
authenticate packets. You can choose to configure an AH-specific authentication
algorithm, or ESP-specific authentication and encryption algorithms. The device first
encapsulates the ESP header, and then the AH header to packets.
NOTE
l Authentication algorithms SHA2-256, SHA2-384, and SHA2-512 are recommended to improve

packet transmission security, whereas authentication algorithms MD5 and SHA1 are not
recommended.
l Encryption algorithms AES-128, AES-192, and AES-256 are recommended to improve packet
transmission security, whereas encryption algorithm DES and 3DES are not recommended.
Step 5 Run encapsulation-mode { transport | tunnel }

An IP packet encapsulation mode is configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, IPSec uses the tunnel mode to encapsulate IP packets.
When IKEv2 is used, the encapsulation modes in all the IPSec proposals configured on the
IKE initiator must be the same; otherwise, IKE negotiation fails.
NOTE
When L2TP over IPSec or GRE over IPSec is configured, a public IP header is added to packets during L2TP
or GRE encapsulation. Compared with the transport mode, the tunnel mode adds another public IP header. In
tunnel mode, the packet length is longer and packets are more likely to be fragmented. The transport mode is
therefore recommended.
Step 6 Run quit
Exit the IPSec proposal view.
Step 7 (Optional) Run ipsec authentication sha2 compatible enable
The SHA-2 algorithm is compatible with earlier software versions.
By default, the SHA-2 algorithm is not compatible with earlier software versions.
When IPSec uses the SHA-2 algorithm, if the devices on two ends of an IPSec tunnel are
from different vendors or run different software versions, they may use different encryption
and decryption methods. In this situation, traffic between devices is interrupted.
To solve this problem, enable SHA-2 to be compatible with earlier versions.
----End
6.7.3 Configuring an IPSec Policy
Context
An IPSec policy defines the IPSec proposals used to protect data flows of different types, and
is the prerequisite for creating an SA. An IPSec policy binds an ACL to an IPSec proposal,
and specifies the SA negotiation mode, source and destination of the IPSec tunnel, key, and
SA lifetime.
An IPSec policy is identified by its name and sequence number, and multiple IPSec policies
with the same IPSec policy name constitute an IPSec policy group. An IPSec policy can be
established manually, in ISAKMP mode, or using an IPSec policy template. For IPSec
policies that are established in ISAKMP mode and using an IPSec policy template, parameters
are generated through IKE negotiation.
Select an IPSec policy establishment mode as needed:
NOTE
l When a GRE over IPSec tunnel is established using an ACL, an IPSec policy in ISAKMP mode can only
be configured on gateways at both ends.
l When an L2TP over IPSec tunnel is established using an ACL and the LAC is used as the initiator, an
IPSec policy in ISAKMP mode can only be configured on the LAC. When the LNS functions as the
responder, an IPSec policy in ISAKMP mode or using an IPSec policy template can be configured on the
LNS. In the Hub-Spoke VPN, an IPSec policy using an IPSec policy template is recommended.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.3.1 Configuring an IPSec Policy in Manual Mode
Context
All security parameters of an IPSec policy configuring in manual mode need to be configured
manually. The configuration workload is heavy, so the IPSec policy applies to a small-scale
network environment.
When configuring an IPSec policy in manual mode, ensure that:
l Inbound and outbound SAs' parameters, including the authentication/encryption key and
security parameter index (SPI), are configured on IPSec peers.
l The inbound SA's parameters on the local end is the same as the outbound SA's
parameters on the remote end, and the outbound SA's parameters on the local end is the
same as the inbound SA's parameters on the remote end.
After an IPSec policy group is applied to an interface, to add or delete an IPSec policy in the
IPSec policy group or modify parameters of the IPSec policy, unbind the IPSec policy group
from the interface and then apply the IPSec policy group to the interface again so that IPSec
policies in the IPSec policy group take effect.
Procedure
Step 2 Run ipsec policy policy-name seq-number manual
An IPSec policy is created in manual mode and the IPSec policy view is displayed.
By default, no IPSec policy is created.
Step 3 Run security acl acl-number
An ACL is referenced in the IPSec policy.
By default, an IPSec policy does not reference an ACL.
acl-number is an advanced ACL that has been created.
An IPSec policy can reference only one ACL. Before referencing a new ACL, you must
delete the original ACL that has been referenced.
An IPSec proposal is referenced in the IPSec policy.
By default, an IPSec policy does not reference an IPSec proposal.
proposal-name is an IPSec proposal that has been created.
One IPSec policy can reference only one IPSec proposal. Before referencing a new IPSec
proposal, you must delete the original IPSec proposal that has been referenced.
Step 5 Configure the local and remote IP addresses of an IPSec tunnel.
1. Run tunnel local ip-address
A local IP address is configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. Run tunnel remote ip-address

A remote IP address is configured.
By default, the local and remote IP addresses of an IPSec tunnel are not configured.
The remote IP address at the local end must be the same as the local IP address at the remote
end.
Step 6 Configure the SPI for the inbound or outbound SA.
1. Run sa spi outbound { ah | esp } spi-number
An SPI is configured for the outbound SA.
2. Run sa spi inbound { ah | esp } spi-number
An SPI is configured for the inbound SA.
The security protocol must be the same as that specified in the transform command in 6.7.2
Configuring an IPSec Proposal. If the security protocol specified in the transform
command is ah-esp, both ah and esp must be specified in the sa spi command.
To retain a unique SA, SPIs for inbound and outbound SAs must be different.
Step 7 Configure authentication and encryption keys for the inbound or outbound SA.
NOTE
l The security protocol specified in authentication and encryption key configuration commands must
be the same as that specified in the transform command in 6.7.2 Configuring an IPSec Proposal.
If the security protocol specified in the transform command is ah-esp, both ah and esp
authentication and encryption keys must be specified.
l The two ends of an IPSec tunnel must use the authentication keys in the same format. For example,
if the key on one end is a character string but the key on the other end is a hexadecimal number, the
IPSec tunnel cannot be established.
l If simple is specified, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you specify cipher to save the password in cipher text.
l If the inbound authentication keys in a character string and hexadecimal notation are configured, the
one configured later overwrites the original one.
If AH is used, configure an authentication key.

l Run sa string-key { inbound | outbound } ah { simple | cipher } string-key
An authentication key in a character string is configured for AH.
l Run sa authentication-hex { inbound | outbound } ah { simple | cipher } hex-string
An authentication key in hexadecimal notation is configured for AH.
If ESP is used, configure an authentication key.
l Run sa string-key { inbound | outbound } esp { simple | cipher } string-key
An authentication key in a character string is configured for ESP.
NOTE
When ESP is used and the authentication key in a character string is used, the device automatically
generates the encryption key of ESP. You do not need to configure the encryption key of ESP.
If ESP is used, configure authentication and encryption keys.

1. (Optional) Run sa authentication-hex { inbound | outbound } esp { simple | cipher }
hex-string
An authentication key in hexadecimal notation is configured for ESP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. (Optional) Run sa encryption-hex { inbound | outbound } esp { simple | cipher } hex-

string
An encryption key in hexadecimal notation is configured for ESP.
You must run at least one of the preceding commands.
----End
6.7.3.2 Configuring an IPSec Policy in ISAKMP Mode
Context
An IPSec policy configured in Internet Security Association and Key Management Protocol
(ISAKMP) mode applies to a scenario where the remote IP address is fixed, and is often used
in branch configuration.
Negotiated IPSec parameters of an IPSec policy are defined in the IPSec policy view, and the
negotiation initiator and responder must use the same IPSec parameters. The end that has an
ISAKMP IPSec policy configured can initiate IKE negotiation.
After an IPSec policy group to which an IPSec policy belongs is applied to an interface, the
following situations occur:
l To modify the IPSec proposal parameters, unbind the IPSec policy group from the
interface and then apply the IPSec policy group to the interface again.
l If other parameters are modified, these parameters will take effect during the next
negotiation and are invalid for the tunnels that have been established through
negotiation.
Procedure
Step 2 Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in ISAKMP mode and the IPSec policy view is displayed.
By default, no IPSec policy is created.
Step 3 (Optional) Run alias alias
The alias of the IPSec policy is specified.
By default, the system uses the combination of the name and sequence number of an IPSec
policy as the alias. If the default alias has been used by another IPSec policy, the system uses
the combination of the name, sequence number, and current time of an IPSec policy as the
alias.
Step 4 Run security acl acl-number [ dynamic-source ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An IPSec policy can reference only one ACL. Before referencing a new ACL, you must
delete the original ACL that has been referenced.
An IPSec proposal is referenced in the IPSec policy.
By default, an IPSec policy does not reference an IPSec proposal.
proposal-number specifies a created IPSec proposal.
An IPSec policy configured in ISAKMP mode can reference a maximum of 12 IPSec

proposals. During IKE negotiation, the two ends of an IPSec tunnel first use the IPSec
proposals with the same parameter settings. If IPSec proposals with the same parameter
settings cannot be found, an SA cannot be set up.
NOTE
When referencing multiple IPSec proposals in an IPSec policy, ensure that the encapsulation modes of all
IPSec proposals referenced by the IPSec policy at both ends are the same. That is, the encapsulation modes
are all transport or tunnel modes.
An IKE peer is referenced in the IPSec policy.
By default, an IPSec policy does not reference an IKE peer.
peer-name specifies a created IKE peer. For the detailed configuration of an IKE peer, see
6.11.2 Configuring an IKE Peer.
IPSec policies with different sequence numbers in the same IPSec policy group cannot
reference IKE peers with the same IP address.
Step 7 (Optional) Run tunnel local { ipv4-address | applied-interface }
A local IP address of an IPSec tunnel is configured.
By default, the local IP address of an IPSec tunnel is not configured.
For the IKE negotiation mode, you do not need to configure an IP address for the local end of
an IPSec tunnel. During SA negotiation, the device will select a proper address based on route
information. The local address needs to be configured in the following situations:
l If the IP address of the interface to which an IPSec policy is applied varies or is
unknown, run the tunnel local ipv4-address command to specify the IP address of
another interface (such as the loopback interface) on the device as the IP address for the
local end of an IPSec tunnel. Otherwise, run the tunnel local applied-interface
command to specify the IP address of the interface to which an IPSec policy is applied as
the local address of an IPSec tunnel.
l If the interface to which an IPSec policy is applied has multiple IP addresses (one
primary IP address and several secondary IP addresses), run the tunnel local ipv4-
address command to specify one of these IP addresses as the IP address for the local end
of an IPSec tunnel. Otherwise, run the tunnel local applied-interface command to
specify the primary IP address of the interface as the local address of an IPSec tunnel.
l If equal-cost routes exist between the local and remote ends, run the tunnel local
command to specify a local IP address for an IPSec tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l If an IPSec policy is created in IKE negotiation mode, the tunnel local on the local end must be the
same as remote-address (IKE peer view) that the remote end references from the IKE peer.
l You do not need to specify the tunnel local (local address) for the IKE peer referenced in an IPSec
profile, because the local address is the source address of the GRE, mGRE or IPSec virtual tunnel
interface. For the IKE peer referenced in an IPSec profile, tunnel local do not take effect.
l When applying an IPSec policy to a tunnel interface and running the source command to specify an
IP address for the interface, you must run the tunnel local command to configure a tunnel local
address. Otherwise, IKE negotiation will fail.
l In an IPSec hot standby scenario, tunnel local must be set to a virtual IP address.
Step 8 (Optional) Run tunnel remote { applied-interface | interface interface-type interface-

number }
An outbound interface on the IPSec tunnel for IKE negotiation packets is configured.
By default, no outbound interface is configured on the IPSec tunnel for IKE negotiation
packets.
When there are multiple outbound interfaces, the device determines the outbound interface for
IKE negotiation packets based on routes. If the outbound interface for IKE negotiation
packets differs from that for IPSec service packets, IKE negotiation may fail. In this case,
perform this step to specify a correct outbound interface.
Step 9 (Optional) Run sa trigger-mode { auto | traffic-based }
An IPSec tunnel trigger mode is configured.
By default, the IPSec tunnel trigger mode is auto.
The device is configured to use perfect forward secrecy (PFS) when the local end initiates
negotiation.
By default, PFS is not used when the local end initiates negotiation.
When the local end initiates negotiation, there is an additional Diffie-Hellman (DH) exchange
in IKEv1 phase 2 or IKEv2 CREATE_CHILD_SA exchange. The additional DH exchange
ensures security of the IPSec SA key and improves communication security.
If PFS is specified on the local end, you also need to specify PFS on the remote end. The DH
group specified on the two ends must be the same; otherwise, negotiation fails. When an
IPSec policy in ISAKMP mode is used on the local end while an IPSec policy configured
using an IPSec policy template is used on the remote end, no DH group needs to be
configured on the remote end. The DH group on the responder is used for negotiation.
Step 11 (Optional) Run respond-only enable
The local end is configured not to initiate negotiation.
By default, if the local end establishes an IPSec tunnel based on the IPSec policy configured
in ISAKMP mode, the local end initiates an IPSec negotiation.
If two IPSec peers establish an IPSec tunnel based on the IPSec policy configured in
ISAKMP mode, both ends initiate negotiation. You can configure one end as the responder
that does not initiate negotiation, which can help you check packet processing and locate
IPSec faults.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 12 (Optional) Run policy enable

The IPSec policy is enabled.
By default, IPSec policies in an IPSec policy group are enabled.
----End
6.7.3.3 Configuring an IPSec Policy Using an IPSec Policy Template
Context
When an IPSec policy template is used to configure IPSec policies, the configuration
workload for establishing multiple IPSec tunnels can be reduced. This IPSec policy
configuration mode is often used in the headquarters in scenarios where the remote IP address
is not fixed (for example, the remote end obtains an IP address through PPPoE) or there are
multiple remote devices.
When an IPSec tunnel is set up using an IPSec policy through an IPSec policy template, the
initiator determines optional parameters, and the responder accepts the parameters delivered
by the initiator. The end that has an IPSec policy configured using an IPSec policy template
can only function as the responder to receive negotiation requests.
When using an IPSec policy template to configure an IPSec policy, note the following points:
l If one end (responder) of an IPSec tunnel has an IPSec policy configured using an IPSec
policy template, the other end (initiator) must have an IPSec policy configured in
ISAKMP mode.
l In an IPSec policy template, an IPSec proposal and IKE peer must be referenced, and
other parameters are optional. The initiator determines optional parameters in the IPSec
policy template, and the responder accepts the parameters delivered by the initiator.
Procedure
Step 2 Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is displayed.
By default, no IPSec policy template is created.
Step 3 (Optional) Run alias alias
The alias name of the IPSec policy template is specified.
By default, the system uses the combination of the name and sequence number of an IPSec
policy template as the alias. If the default alias has been used by another IPSec policy
template, the system uses the combination of the current time as well as the name and
sequence number of an IPSec policy template as the alias.
Step 4 (Optional) Run security acl acl-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

One IPSec policy template can reference only one ACL. Before referencing a new ACL, you
must delete the ACL that has been referenced.
If data flows to be protected are not specified, the responder accepts the range of data flows to
be protected on the initiator. If data flows to be protected are specified, the ACL on the
responder must mirror the ACL on the initiator or the range specified by the ACL on the
responder must cover the range specified by the ACL on the initiator.
An IPSec proposal is referenced in the IPSec policy template.
By default, an IPSec policy template does not reference an IPSec proposal.
proposal-name is an IPSec proposal that has been created.
An IPSec policy template can reference a maximum of 12 IPSec proposals. During IKE
negotiation, the two ends of an IPSec tunnel first use the IPSec proposals with the same
parameter settings. If IPSec proposals with the same parameter settings cannot be found, an
SA cannot be set up.
NOTE
When referencing multiple IPSec proposals in an IPSec policy template, ensure that the encapsulation mode
of IPSec proposals referenced by the IPSec policy template at one end are the same as the encapsulation
mode of IPSec proposals referenced by the IPSec policy at the other end. That is, the encapsulation mode at
both ends must be transport or tunnel.

An IKE peer is referenced in the IPSec policy template.
By default, an IPSec policy template does not reference an IKE peer.
peer-name is an IKE peer that has been created.
Step 7 (Optional) Run tunnel local ipv4-address
A local IP address of an IPSec tunnel is configured.
By default, the local IP address of an IPSec tunnel is not configured.
NOTE
l If an IPSec policy is created in IKE negotiation mode, the tunnel local on the local end must be the same
as remote-address (IKE peer view) that the remote end references from the IKE peer.
l When applying an IPSec policy to a tunnel interface and running the source command to specify an IP
address for the interface, you must run the tunnel local command to configure a tunnel local address.
Otherwise, IKE negotiation will fail.
l In an IPSec hot standby scenario, tunnel local must be set to a virtual IP address.
Step 8 (Optional) Run tunnel remote { applied-interface | interface interface-type interface-

number }
packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 9 (Optional) Run match ike-identity identity-name
The identity filter set is referenced.
By default, an IPSec policy template does not reference an identity filter set.
identity-name is an identity filter that has been created. For details on how to configure an
identity filter set, see 6.11.5 (Optional) Configuring an Identity Filter Set.
NOTE
When an IPSec policy template references the identity filter set, the allowed IKE peer can be specified
at the local end. An IPSec tunnel can be established successfully only when the remote end matches one
or more access conditions in the identity filter set and IPSec parameters at both ends match.
negotiation.
Step 11 (Optional) Run policy enable
The IPSec policy is enabled.
By default, IPSec policies in an IPSec policy group are enabled.
Step 12 Run quit
Step 13 Run ipsec policy policy-name seq-number isakmp template template-name
An IPSec policy template is referenced in the IPSec policy.
The referenced IPSec policy template name template-name must be different from the IPSec
policy name policy-name.
Only one IPSec policy in an IPSec policy group can reference the policy template, and
number of this policy must be larger than that of other policies. If the IPSec policy created
using the policy template does not have the lowest priority, other IPSec policies in the same
IPSec policy group do not take effect.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.4 (Optional) Setting the IPSec SA Lifetime
Context
NOTE
l The IPSec SA lifetime is only valid for the IPSec SAs established in IKE negotiation mode.
Manually established IPSec SAs are always valid.
l The configured IPSec SA lifetime is only valid for the new IPSec SAs established in IKE
negotiation mode.
For a dynamic SA, configure the SA hard lifetime so that the SA can be updated in real time,
reducing the crash risk and improving security.
There are two methods to measure the lifetime:

l Time-based lifetime
The period from when an SA is set up to when the SA is expired.
l Traffic-based lifetime
The maximum volume of traffic that this SA can process.
The lifetime is classified as follows:

l Hard lifetime: specifies the lifetime of an IPSec SA.
When two devices negotiate an IPSec SA, the actual hard lifetime is the smaller of the
two values configured on the two devices.
l Soft lifetime: specifies the time after which a new IPSec SA is negotiated so that the new
IPSec SA will be ready before the hard lifetime of the original IPSec SA expires.
Table 6-7 lists the default soft lifetime values.
Table 6-7 Soft lifetime values
Soft Lifetime Type Description
Time-based soft lifetime (soft timeout The value is 7/10 of the actual hard
period) lifetime (hard timeout period).
Traffic-based soft lifetime (soft timeout The value is 7/10 of the actual hard
traffic) lifetime (hard timeout traffic).
Before an IPSec SA becomes invalid, IKE negotiates a new IPSec SA for the remote end. The
remote end uses the new IPSec SA to protect IPSec communication immediately after the new
IPSec SA is negotiated. If service traffic is transmitted, the original IPSec SA is deleted
immediately. If no service traffic is transmitted, the original IPSec SA will be deleted after
10s or the hard lifetime expires.
If the time-based lifetime and traffic-based lifetime are both set for an IPSec SA, the IPSec
SA becomes invalid when either lifetime expires.
You can set the global IPSec SA lifetime or set the IPSec SA lifetime in an IPSec policy. If
the IPSec SA lifetime is not set in an IPSec policy, the global lifetime is used. If both the
global IPSec SA lifetime or the IPSec SA lifetime in an IPSec policy are set, the IPSec SA
lifetime in the IPSec policy takes effect.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Set the global IPSec SA hard lifetime.
a. Run system-view
b. Run ipsec sa global-duration { time-based interval | traffic-based size }
The global IPSec SA hard lifetime is set.
By default, the global time-based SA hard lifetime is 3600 seconds and the global
traffic-based SA hard lifetime is 1843200 Kbytes.
l Set the IPSec SA hard lifetime in an IPSec policy.
a. Run system-view
b. Configure an IPSec policy in IPSec ISAKMP mode or using an IPSec policy
template.
n Run ipsec policy policy-name seq-number isakmp
An IPSec policy in IPSec ISAKMP mode is created and the IPSec policy view
is displayed.
n Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is
displayed.
c. Run sa duration { time-based seconds | traffic-based kilobytes }
The IPSec SA hard lifetime is set in the IPSec policy.
By default, the IPSec SA hard lifetime is not set in an IPSec policy. The system
uses the global IPSec SA hard lifetime.
d. (Optional) Run sa keep-holding-to hard-duration
The device is configured to delete the original IPSec SA after the hard lifetime
expires during IPSec SA re-negotiation.
By default, during IPSec SA re-negotiation, the device deletes the original IPSec
SA immediately after using the new IPSec SA to transmit data.
After a new IPSec SA is negotiated, if the peer device still uses the original IPSec
SA to transmit data while the local device deletes the original IPSec SA
immediately after using the new IPSec SA to transmit data, the IPSec SAs on the
two devices will be different. This will cause IPSec traffic interruption. In this case,
it is recommended to perform this step on the local device.
This function takes effect only for IPSec SAs established through IKEv1
negotiation.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.5 (Optional) Enabling the Anti-replay Function

Context
NOTE
Only SAs established in IKE negotiation mode support the anti-replay function. Manually configured
SAs do not support the anti-replay function.
To ensure non-stop service forwarding, the configured IPSec anti-replay window size takes effect only
for new or re-negotiated IPSec policies but not for existing ones.
Replayed packets are packets that have been processed. IPSec uses the sliding window (anti-
replay window) mechanism to check replayed packets. Each AH or ESP packet has a 32-bit
sequence number. In an SA, sequence numbers of packets increase. If the sequence number of
a received authenticated packet is the same as that of a decapsulated packet or if the sequence
number is out of the sliding window, the device considers the packet as a replayed packet.
Decapsulating replayed packets consumes many resources and makes system performance
deteriorate, resulting in a Denial Of Service (DoS) attack. After the anti-replay function is
enabled, the system discards replayed packets and does not encapsulate them, saving system
resources.
In some situations, for example, when network congestion occurs or QoS is performed for
packets, the sequence numbers of some service data packets may be different from those in
common data packets. The device that has IPSec anti-replay enabled considers the packets as
replayed packets and discards them. You can disable global IPSec anti-replay to prevent
packets from being discarded incorrectly or adjust the IPSec anti-replay window size to meet
service requirements.
The anti-replay function can be configured globally or in an IPSec policy or profile:
l Configuring the anti-replay function globally
The global anti-replay function is valid for all existing IPSec policies. When the same
anti-replay window parameters need to be set for many IPSec policies, you do not need
to run commands one by one. You only need to set global parameters. The configuration
efficiency is therefore improved.
l Configuring the anti-replay function in an IPSec policy or policy template
The anti-replay function can be configured separately for an IPSec policy. In this case,
the anti-replay function for the IPSec policy is not affected by the global configuration.
Procedure
Step 2 Enable the anti-replay function. Run the following commands as required.
l Enable the anti-replay function globally.
a. Run ipsec anti-replay enable
The anti-replay function is enabled globally.
b. Run ipsec anti-replay window window-size
The global IPSec anti-replay window size is configured.
By default, the global IPSec anti-replay window size is 1024 bits.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Enable the anti-replay function in an IPSec policy.

a. Run ipsec policy policy-name seq-number [ isakmp | manual ]
An IPSec policy is created and the IPSec policy view is displayed.
b. Run anti-replay window window-size
The IPSec anti-replay window size is configured in the IPSec policy.
By default, the anti-replay window size of a single IPSec tunnel is not set. The
global value is used.
l Enable the anti-replay function in an IPSec policy template.
a. Run ipsec policy-template template-name seq-number
An IPSec policy template is created and the IPSec policy template view is
displayed.
The IPSec anti-replay window size is configured in the IPSec policy template.
By default, the anti-replay window size of a single IPSec tunnel is not set. The
global value is used.
----End
6.7.6 (Optional) Configuring IPSec Fragmentation Before

Encryption
Context
The length of IPSec-encapsulated packets may exceed the maximum transmission unit (MTU)
of the outbound interface on the local device. If the IPSec remote device does not support
fragmentation and reassembly, it cannot decapsulate packets and will discard or incorrectly
process packets, affecting packet transmission.
To prevent this problem, configure IPSec fragmentation before encryption on the local device.
Subsequently, the local device calculates the length of encapsulated packets. If the length
exceeds the MTU, the device fragments the packets and then encapsulates each fragment.
After packets reach the IPSec remote device, the remote device can decapsulate the fragments
without having to reassemble them. The decapsulated packets will be forwarded normally.
Procedure
Step 2 Run ipsec fragmentation before-encryption
The fragmentation mode of packets is set to fragmentation before encryption for all IPSec
tunnels.
By default, the packet fragmentation mode for all IPSec tunnels is fragmentation after
encryption.
The DF flag in IPSec packets determines whether IPSec packets can be fragmented. If DF
flag settings disable fragmentation when the fragmentation mode is used, run the ipsec df-bit
{ clear | set | copy } command in the system view to enable fragmentation on IPSec packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
For the established IPSec tunnels, you need to restart them after running this command.
Otherwise, the command function does not take effect.
----End
6.7.7 (Optional) Configuring Route Injection

Context
NOTE
Only SAs established in IKE negotiation mode support the route injection function. Manually
configured SAs do not support the route injection function.
The device does not support route injection function when the IPSec policy group is bound to a Layer 2
interface.
When an enterprise headquarters and its branch establish an IPSec tunnel, a static route to the
branch subnet needs to be configured on the headquarters gateway. If there are many branch
subnets, a large number of static routes need to be configured on the headquarters gateway.
When branch subnets change, the static route configuration needs to be modified on the
headquarters gateway, causing a difficulty in network maintenance. Route injection injects
routes to branch subnets to the headquarters gateway based on IPSec tunnel information,
which reduces manual configuration and improves configuration correctness. If a static route
from the branch to the headquarters gateway does not need to be configured manually,
configure route injection.
The route injection function enables a device to generate a route based on the destination
network segment in the flow information of the IPSec SA established on the device. The next
hop of the route is the peer address in the IPSec SA by default.
In Figure 6-29, an IPSec tunnel is established between the branch gateway and headquarters
gateway. The host a1 indicates the branch subnet and the host b1 indicates the headquarters
subnet. An ACL rule is configured on the headquarters gateway and branch gateway to enable
IPSec to protect data traffic from b1 to a1 and data traffic from a1 to b1 respectively. When the
route injection function is disabled, the headquarters gateway needs to ensure that the route to
the branch subnet is reachable. After the route injection function is enabled on the
headquarters gateway, the gateway automatically generates a routing entry with the
destination IP address being the destination network segment in the flow information of the
IPSec SA established by the local end and the next hop being the IPSec tunnel local IP
address of the branch gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-29 Route injection
IPSec Tunnel
Host a1 IP3 Host b1
IPa1 IP1 IP2 IPb1
Branch Headquarters
gateway gateway
① ① Headquarters
Branch rule permit ip source
subnet
rule permit ip source subnet
IPa1 destination IPb1 IPb1 destination IPa1
② Original route ③ Route added after route
injection is enabled
Destination IP Next Hop Destination IP Next Hop
IP1 IP3 IPa1 IP1
Route injection works in two modes:

l Static mode: The generated route is added to the local device immediately, and is
independent of IPSec tunnel status change.
l Dynamic mode: If the IPSec tunnel is Up, the generated route can be added to the local
device. If the IPSec tunnel is Down, the generated route can be deleted from the local
device.
Compared with static route injection, dynamic route injection is relevant to the IPSec
tunnel status. Dynamic route injection prevents IPSec peers from sending IPSec packets
over the IPSec tunnel in Down state, reducing packet loss.
You can configure a priority for the route generated through route injection. For example,
when there is another route to the same destination as the route, specify the same priority for
the routes so that traffic can be load balanced. If different priorities are specified for the
routes, the routes can back up each other.
Procedure
Step 2 An IPSec policy in IKE negotiation mode or an IPSec policy template is configured.
l Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in IKE negotiation mode and the IPSec policy view is
displayed.
l Run ipsec policy-template template-name seq-number
Step 3 Run route inject [ nexthop ipv4-address ] { static | dynamic } [ preference preference ]
Route injection is enabled.
By default, route injection is disabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
static is only available in the ISAKMP IPSec policy view.

After the next hop is specified using the route inject nexthop command, the generated route is not used for
IPSec packet forwarding if the IPSec tunnel remote address is not within the destination network segment of
the injected route.
----End
6.7.8 (Optional) Configuring IPSec Check
Context
IPSec check ensures that data flows are correctly encrypted. After IPSec check is enabled, the
device checks packets received on the interface where an IPSec policy is applied. In tunnel
mode, the IP header in the decrypted IPSec packet of the inbound SA may be not defined in
an ACL, for example, the IP header of attack packets may be out of the range defined in the
ACL. After IPSec check is configured, the device re-checks whether the IP header of the
decrypted IPSec packet is in the range defined by an ACL. If the decrypted IPSec packet
matches the permit action, the device continues to process the IPSec packet. If the decrypted
IPSec packet does not match the permit action, the device discards the IPSec packet. This
improves network security.
When IPSec is deployed using an IPSec policy template, IPSec check function checks only
the data that matches the rule with the smallest number in the ACL referenced in the IPSec
policy template. If an ACL rule matches a wide range of packets, for example, permit ip is
configured, IPSec check function may discard packets even if no tunnel exists. In this
situation, if the remote device needs to receive packets, disable the IPSec check function to
allow the packets to pass through.
Procedure
Step 2 Run ipsec decrypt check
Post-IPSec check is enabled.
By default, the device does not check decrypted IPSec packets.
----End
6.7.9 (Optional) Enabling the QoS Function for IPSec Packets
Context
In network planning, QoS needs to be configured to provide differentiated services for
different traffic flows to optimize network service capabilities. QoS groups the packets
sharing common features into one class and provides the same QoS level for traffic of the
same type. In this manner, QoS provides differentiated services for different types of packets.
QoS for IPSec packets implements refined QoS management on IPSec packets, choose either
of the following configurations as required:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l After packets are encapsulated using IPSec, the packets do not contain QoS related
parameters, such as header of the original packet and protocol number. Pre-extraction of
original IP packets needs to be configured if QoS needs to group encapsulated packets
based on the 5-tuple information such as original packet header and protocol number.
l When a device implements IPSec encapsulation and decapsulation on packets, it will
result in transmission delay and require higher bandwidth. Therefore, the device needs to
provide differentiated services for IPSec packets to reduce the delay, lower the packet
loss ratio, and maximize bandwidth for IPSec traffic. You can group IPSec packets into
one QoS group to allow QoS to implement differentiated services for IPSec packets.
Figure 6-30 shows the procedure for configuring QoS.
Figure 6-30 Procedure for configuring QoS

Configure a traffic
Enable pre-
classifier
extraction of
based on access
original IP oackets Configure a Configure a Apply the
control List
Configure a traffic traffic behavior traffic policy traffic policy
Enable the QoS
classifier
function for IPSec
based on QoS
packets
group

Procedure
Step 2 Enter the view where QoS for IPSec packets is configured.
l View of the IPSec policy established in manual mode
Run ipsec policy policy-name seq-number manual
l View of the IPSec policy established in IKE negotiation mode
Run ipsec policy policy-name seq-number isakmp
An IPSec policy is created in IKE negotiation mode and the IPSec policy view is
displayed.
l IPSec policy template view
Run ipsec policy-template policy-template-name seq-number
Choose either of the preceding methods.
Step 3 Enable the QoS function for IPSec packets.

l Run qos pre-classify
Pre-extraction of original IP packets is enabled.
By default, pre-extraction of original IP packets is disabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run qos group qos-group-value

The QoS group to which IPSec packets belong is configured.
By default, no QoS group is configured.
You only need to run one of the preceding commands.
----End
Follow-up Procedure
l After pre-extraction of original IP packets is enabled, run the if-match acl { acl-number |
acl-name } command in the traffic classifier view to configure a matching rule based on
the ACL.
l After QoS for IPSec packets is enabled, run the if-match qos-group qos-group-value
command in the traffic classifier view to configure a matching rule based on the QoS
group.
6.7.10 (Optional) Configuring IPSec VPN Multi-instance

Context
NOTE
If an SA is established in manual mode, you can bind a VPN instance to an IPSec tunnel in an IPSec
policy. If an SA is established in IKE negotiation mode, you can bind a VPN instance to an IPSec tunnel
on an IKE peer. For details, see 6.11.8 (Optional) Configuring IPSec VPN Multi-instance.
When multiple branches connected to the headquarters network across the Internet using
IPSec, you can configure IPSec VPN Multi-instance, thereby isolating traffic of different
branches.
Procedure
Step 2 Run ipsec policy policy-name seq-number manual
Step 3 Run sa binding vpn-instance vpn-instance-name
A VPN instance is bound to an IPSec tunnel.
The VPN instance specified by vpn-instance-name must have been created using the ip vpn-
instance command, and must be the same as the VPN instance bound to the ACL that is
referenced by an IPSec policy.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.11 (Optional) Allowing New Users with the Same Traffic Rule
as Original Branch Users to Access the Headquarters Network
Context
After the enterprise branch and its headquarters establish an IPSec tunnel, the IP address of
the branch gateway interface to which an IPSec policy group is applied changes due to the
link status change. For example, the branch gateway connects to the Internet through dial-up
and establishes an IPSec tunnel with the headquarters. The headquarters gateway has an
existing IPSec tunnel to protect IPSec packets exchanged between the headquarters gateway
and branch gateway (original users). Because data flows of new users are the same, the branch
gateway and headquarters gateway cannot reestablish an IPSec tunnel. After the local IP
address of the IPSe tunnel on the branch gateway changes, the branch gateway (new users)
and headquarters gateway cannot rapidly reestablish an IPSec tunnel to protect IPSec traffic
exchanged between them.
You can configure the device to allow new users with the same traffic rule as original branch
users to access the headquarters network so that the existing IPSec SAs can be rapidly aged
and a new IPSec tunnel can be established.
NOTE
The prerequisites are as follows:
l The headquarters gateway functions as the responder and uses an IPSec policy template to establish
an IPSec tunnel with the branch gateway.
l The ACL rules for the new users must be the same as those for original users.
l The interface used by new users to access the headquarters gateway must be the same as that used by
original users.
Procedure
Step 2 Run ipsec remote traffic-identical accept
The device is configured to allow new users with the same traffic rule as original branch users
to access the headquarters network.
By default, the device allows branch or other users to quickly access the headquarters network
after their IP addresses are changed.
----End
6.7.12 (Optional) Configuring the Device to Keep IPSec Tunnel

Indexes Unchanged Based on the Peer IP Address During IPSec
Tunnel Re-establishment
Context
In an MIB table, an IPSec tunnel index is the unique identifier of an IPSec tunnel. During
IPSec tunnel establishment, the device generates an IPSec tunnel index mapping table to
record IPSec tunnel index to IPSec tunnel mapping. In this mapping table, the device searches

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
for the corresponding IPSec tunnel based on an IPSec tunnel index. However, when an IPSec
tunnel is re-established, its IPSec tunnel index changes by default. As a result, the IPSec
tunnel cannot be found based on its previous IPSec tunnel index. In this case, configure the
device to keep IPSec tunnel indexes unchanged based on the peer IP address during IPSec
tunnel re-establishment. This configuration ensures that an IPSec tunnel can be found using
its fixed IPSec tunnel index.
NOTE
l This function works only when devices on both ends use fixed IPv4 addresses and establish only one
IPSec tunnel.
l During IPSec tunnel re-establishment, this function allows the device to keep only the first 1024
IPSec tunnel indexes unchanged based on the sequence in which IPSec tunnels are re-established.
l An IPSec tunnel index mapping table cannot be backed up, so this function does not work in an
active/standby switchover scenario.
Procedure
Step 2 Run ipsec tunnel-index based remote-ip
The device is configured to keep IPSec tunnel indexes unchanged based on the peer IP
address during IPSec tunnel re-establishment.
By default, the device is not configured to keep IPSec tunnel indexes unchanged based on the
peer IP address during IPSec tunnel re-establishment.
----End
6.7.13 (Optional) Configuring a Multi-link Shared IPSec Policy

Group
Context
To improve network reliability, the enterprise gateway often connects to the Internet Service
Provider (ISP) through two egress links, which work in backup or load balancing mode.
When two outbound interfaces are configured with IPSec policies with the same parameter
settings, services need to be smoothly switched between the two links corresponding to the
two outbound interfaces. The two outbound interfaces negotiate with their peers to establish
IPSec SAs respectively. When an active/standby switchover occurs, the two peers need to
perform IKE negotiate again to generate IPSec SAs. The IKE re-negotiation causes IPSec
service interruption in a short time.
You can configure a multi-link shared IPSec policy group and use a loopback interface on the
local device to establish an IPSec tunnel with the remote device. When an active/standby
switchover occurs, IPSec services are not interrupted. The two IPSec-enabled physical
interfaces share the same IPSec SA. When services are switched between links corresponding
to the physical interfaces, the IPSec SA is not deleted as long as the loopback interface status
remains unchanged. In addition, IKE re-negotiation is not required because the same IPSec
SA is used to protect IPSec services.
As shown in Figure 6-31, packets of branch gateway RouterA reach headquarters gateway
RouterB through two egress links. If an egress link is faulty, IPSec communication between

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RouterA and RouterB is not affected. The multi-link shared mode improves network
reliability.
Figure 6-31 Using an IPSec tunnel in multi-link shared mode

LoopBack0
Interface 1
RouterA RouterB
Branch Headquarters
gateway subnet
Interface 2
IPSec Tunnel
SubnetA SubnetB
NOTE
One loopback interface maps to only one multi-link shared IPSec policy group.
Procedure
Step 2 Run ipsec policy policy-name shared local-interface loopback interface-number
An IPSec policy is configured as a multi-link shared security policy.
By default, no IPSec policy is configured as a multi-link shared security policy.
----End
6.7.14 (Optional) Configuring Redundancy Control of IPSec

Tunnels
Context
On a live network, to improve network reliability, a branch gateway connects to the
headquarters using multiple links. The branch gateway needs to determine on which link an
IPSec tunnel is established. You can associate IPSec with NQA so that the branch gateway
controls IPSec tunnel setup or teardown according to the , which ensures that only one link is
available at any time. The association implements redundancy control of the IPSec tunnel.
Prerequisites
l If an NQA test instance is used to control IPSec tunnel setup or teardown, ensure that the
NQA test instance has been created and configured. The device supports only association
between IPSec and NQA of ICMP type. For details on how to configure an NAQ test
instance of ICMP type, see Configuring an ICMP Test Instance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l If an NQA group is used to control IPSec tunnel setup or teardown, ensure that the NQA
group has been created and bound to an NQA test instance. The device supports only
association between IPSec and NQA of ICMP type. For details on how to configure an
NAQ group, see Configuring an ICMP Test Instance.
l If a BFD session is used to control IPSec tunnel setup or teardown, ensure that the BFD
session has been created and configured. For details on how to configure a BFD session,
see Configuring Single-Hop BFD.
l If a BFD group is used to control IPSec tunnel setup or teardown, ensure that the BFD
group has been created and bound to a BFD session. For details on how to configure a
BFD group, see Configuring BFD Group.
Procedure
The view of the ISAKMP IPSec policy is displayed.
Step 3 Run connect track { nqa admin-name test-name | nqa-group nqa-group-name } { up |

down }
The device is configured to control IPSec tunnel setup according to status.
By default, the device is configured to not control IPSec tunnel setup according to status.
Step 4 Run disconnect track { nqa admin-name test-name | nqa-group nqa-group-name } { up |

down }
The device is configured to control IPSec tunnel teardown according to status.
By default, the device is configured to not control IPSec tunnel teardown according to status.
----End
6.7.15 (Optional) Configuring IPSec Gateway Redundancy

Control
Context
To improve network reliability, a branch can connect to the headquarters using multiple
gateways. Therefore, the branch needs to determine through which gateway it establishes an
IPSec tunnel with the headquarters. You can associate IPSec with VRRP so that the device
controls IPSec tunnel setup according to the detected VRRP status. An IPSec tunnel can be
established using a specified IPSec policy (corresponding to a specific gateway) to ensure that
only one gateway is in use at any time, implementing gateway redundancy.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The view of the ISAKMP IPSec policy is displayed.
Step 3 Run connect track vrrp vrid interface interface-type interface-number { master | backup }
The device is configured to control IPSec tunnel setup according to the VRRP status.
By default, the device is not configured to control IPSec tunnel setup according to the VRRP
status.
The connect track and disconnect track commands must be configured simultaneously to
implement gateway redundancy.
Step 4 Run disconnect track vrrp vrid interface interface-type interface-number { master |
backup }
The device is configured to control IPSec tunnel teardown according to the VRRP status.
By default, the device is not configured to control IPSec tunnel teardown according to the
VRRP status.
----End
6.7.16 (Optional) Configuring IPSec Mask Filtering
Context
In scenarios where branches connect to the headquarters, if a branch has a too large protection
data flow range configured, traffic of other branches may be incorrectly diverted to the
branch. In this case, you can configure IPSec mask filtering to check and restrict access of
flow information negotiated by the IPSec tunnel. After this function is configured, the device
checks the source and destination IP address masks of the peer device. If the mask values are
greater than or equal to the configured values, subsequent negotiation continues. Otherwise,
the IPSec SA negotiation fails.
NOTE
The device checks and restricts the access of flow information only when it adopts the IPSec policy
template.
Procedure
Step 2 Run ipsec netmask { source source-mask | [ source source-mask ] destination destination-
mask }
IPSec mask filtering is configured.
By default, IPSec mask filtering is not configured in the system.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.7.17 Applying an IPSec Policy Group to an Interface

Context
To use IPSec to protect data flows on an interface, apply an IPSec policy group to the
interface. After an IPSec policy group is unbound from an interface, the interface does not
provide IPSec protection.
An IPSec policy group is a set of IPSec policies with the same name but different sequence
numbers. An IPSec policy group can contain multiple IPSec policies established manually or
in IKE negotiation mode but only one IPSec policy template, as shown in Figure 6-32. One
IPSec policy corresponds to one advanced ACL. In an IPSec policy group, an IPSec policy
with a smaller sequence number has a higher priority.
Figure 6-32 IPSec policy group

ACL 3000
1 isakmp rule 5
rule 10
…
ACL 3005
20 isakmp rule 5
rule 10
21 template
policy-name
ACL 3007
22 manual rule 5
rule 10
…
ACL 3010
30 manual
rule 5
…
After an IPSec policy group is applied to an interface, all IPSec policies in the group are
applied to the interface and protect different data flows.
When sending a packet, an interface matches the packet with IPSec policies in an IPSec
policy group in ascending order of sequence number. If the packet matches the ACL
referenced by an IPSec policy, the packet is processed based on the IPSec policy. If no
matching ACL is found after all IPSec policies are checked, the interface sends the packet
directly without IPSec protection.
When applying an IPSec policy group to an interface, note the following points:
l The interface where IPSec policies are applied must be the interface where an IPSec
tunnel is established, and the interface must be the outbound interface in the private route
to the remote end. If an IPSec policy is applied to another interface but not the target
interface, VPN service forwarding may fail.
l Only one IPSec policy group can be applied to an interface, and an IPSec policy group
can be applied to only one interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l After an IPSec policy group is applied to an interface, referenced ACLs and IKE peers in
IPSec policies of the IPSec policy group cannot be modified.
NOTE
l When applying an IPSec policy to a tunnel interface and running the source command to specify an IP
address for the interface, you must run the tunnel local command to configure a tunnel local address.
Otherwise, IKE negotiation will fail.
l When multiple branches connect to the headquarters, multiple tunnel interfaces in the headquarters
borrow the same physical interface IP address. In this scenario, the headquarters can identify the tunnel
interface connected to a branch through the peer IP address or peer ID of the IKE peer (Only IKEv1 in
aggressive mode supports the peer ID mode.).
l When multiple branches are connected to the headquarters, if some tunnel interfaces at the headquarters
borrow an IP address from a physical interface, borrow an IP address from a physical interface as their
source address, or borrow a virtual IP address from a physical interface as their tunnel local address, the
mappings between IKE peers and tunnel interfaces may be incorrect. As a result, an IPSec tunnel fails to
be established.
Procedure
Step 2 Run the following commands as required.
l Run interface interface-type interface-number
The interface view is displayed.
l Run interface interface-type interface-number.subinterface-number
The sub-interface view is displayed.
l Run interface tunnel interface-number
The virtual tunnel interface view is displayed.
Step 3 Run ipsec policy policy-name
An IPSec policy group is applied to the interface.
After an IPSec policy established in manual mode is applied to an interface, an SA is
generated immediately.
After an IPSec policy established in IKE negotiation mode is applied to an interface, an IPSec
tunnel can be triggered in auto or traffic mode using the sa trigger-mode { auto | traffic-
based } command.
After an SA is created successfully, data flows are transmitted securely over the IPSec tunnel.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high CPU usage
alarms may be generated in a short period of time after the undo ipsec policy command is
run. After all the SAs are cleared, the CPU usage restores to the normal range.
----End
Precautions
If you modify the tunnel-protocol parameter of a tunnel interface, the IPSec policy group
applied to the tunnel interface will be deleted. After the modification, apply the IPSec policy
group to the tunnel interface as required.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
In an IPSec policy group, if multiple policies are bound to different IKE peers, the remote
addresses specified in the IKE peers cannot be the same. Otherwise, IKE negotiation of some
IPSec policies fails.
6.7.18 Verifying the Configuration of IPSec Tunnel Establishment

Prerequisites
The configurations of the ACL-based IPSec tunnel are complete.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] command to check
IPSec proposal information.
l Run the display ipsec policy [ brief | name policy-name [seq-number ] ] command to
check IPSec policy information.
l Run the display ike identity [ name identity-name ] command to check identity filter set
information.
l Run the display ipsec policy-template [ brief | name policy-template-name [ seq-
number ] ] command to check IPSec policy template information.
l Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | remote
ipv4-address ] command to check IPSec SA information.
l Run the display ipsec global config command to check global IPSec configuration.
l If an IPSec tunnel is established in IKE negotiation mode, check the IKE configuration.
See 6.11.16 Verifying the IKE Configuration.
----End
6.8 Using a Virtual Tunnel Interface to Establish an IPSec

Tunnel
A virtual tunnel interface is a Layer 3 logical interface where the encapsulation protocol is
GRE, mGRE, and IPSec. The device can provide the IPSec service for the virtual tunnel
interface. All the packets routed to the virtual tunnel interface are protected by IPSec. The
virtual tunnel interface can simplify IPSec parameters.
Before using an IPSec tunnel interface to establish an IPSec tunnel, complete the following
tasks:
l Determine data flows to be protected by IPSec and importing data flows to the IPSec
tunnel interface.
l Determine parameters in an IPSec proposal.
After an IPSec policy is referenced by an IPSec profile, apply the IPSec profile to an IPSec
tunnel interface and establish an IPSec tunnel through the virtual tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
NOTE
The IPSec proposal referenced by an IPSec tunnel interface supports only the tunnel mode, that is, you
must specify tunnel in the encapsulation-mode command.
Procedure

By default, the AH authentication algorithm is SHA2-256.
sha2-512 }
By default, the ESP authentication algorithm is SHA2-256.
By default, the ESP encryption algorithm is AES-256.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE

recommended.
NOTE
When L2TP over IPSec or GRE over IPSec is configured, a public IP header is added to packets during L2TP
or GRE encapsulation. Compared with the transport mode, the tunnel mode adds another public IP header. In
tunnel mode, the packet length is longer and packets are more likely to be fragmented. The transport mode is
therefore recommended.
Step 6 Run quit
----End
6.8.2 Configuring an IPSec Profile
Context
An IPSec profile defines how to protect data flows, including IPSec proposals, IKE
negotiation parameters for SA setup, SA lifetime, and PFS status. An IPSec profile is similar
to an IPSec Policy. Compared with the IPSec policy, the IPSec profile is identified by its
name and can be configured only in IKE negotiation mode.
In an IPSec profile, you do not need to use ACL rules to define data flows. Instead, all the
data flows routed to the IPSec tunnel interface are protected. After an IPSec profile is applied
to an IPSec tunnel interface, only one IPSec tunnel is created. The IPSec tunnel protects all
the data flows routed to the IPSec tunnel interface, simplifying IPSec policy management.
To ensure successful IKE negotiation, parameters in the IPSec profile on the local and remote
ends must match.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
By default, no IPSec profile is created.
An IPSec proposal is referenced in the IPSec profile.
By default, no IPSec proposal is referenced in an IPSec profile.
The IPSec proposal must have been created.
An IKE peer is referenced in the IPSec profile.
By default, no IKE peer is referenced in an IPSec profile.
The IKE peer must have been created.
NOTE
l When an IPSec profile is used, the destination address of the IPSec tunnel interface configured using
the destination command is preferentially used as the remote address for IKE negotiation. When the
remote-address and destination commands are configured at the same time, ensure that the
configured IP addresses are the same; otherwise, IKE negotiation will fail. To implement IKE peer
redundancy, do not configure the destination command on the IPSec tunnel interface. Instead,
configure the remote-address command on the IKE peer referenced by the IPSec profile.
l For the detailed configuration of an IKE peer, see 6.11.2 Configuring an IKE Peer.
Step 5 (Optional) Run tunnel remote interface interface-type interface-number

packets.
Step 6 (Optional) Run match ike-identity identity-name
The identity filter set is referenced.
identity-name is an identity filter that has been created.
NOTE
For details on how to configure an identity filter set, see 6.11.5 (Optional) Configuring an Identity
Filter Set.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
negotiation.
----End
6.8.3 (Optional) Setting the SA Lifetime
Context
NOTE
l The configured IPSec SA lifetime is only valid for the new IPSec SAs established in IKE
negotiation mode.
For a dynamic SA, configure the SA hard lifetime so that the SA can be updated in real time,
reducing the crash risk and improving security.
There are two methods to measure the lifetime:

l Time-based lifetime
The period from when an SA is set up to when the SA is expired.
l Traffic-based lifetime
The maximum volume of traffic that this SA can process.
The lifetime is classified as follows:

l Hard lifetime: specifies the lifetime of an IPSec SA.
When two devices negotiate an IPSec SA, the actual hard lifetime is the smaller of the
two values configured on the two devices.
l Soft lifetime: specifies the time after which a new IPSec SA is negotiated so that the new
IPSec SA will be ready before the hard lifetime of the original IPSec SA expires.
Time-based soft lifetime (soft timeout The value is 7/10 of the actual hard
period) lifetime (hard timeout period).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Traffic-based soft lifetime (soft timeout The value is 7/10 of the actual hard
traffic) lifetime (hard timeout traffic).
Before an IPSec SA becomes invalid, IKE negotiates a new IPSec SA for the remote end. The
remote end uses the new IPSec SA to protect IPSec communication immediately after the new
IPSec SA is negotiated. If service traffic is transmitted, the original IPSec SA is deleted
immediately. If no service traffic is transmitted, the original IPSec SA will be deleted after
10s or the hard lifetime expires.
If the time-based lifetime and traffic-based lifetime are both set for an IPSec SA, the IPSec
SA becomes invalid when either lifetime expires.
You can set the global SA hard lifetime or set the SA hard lifetime in an IPSec profile. If the
SA hard lifetime is not set in an IPSec profile, the global hard lifetime is used. If both the
global SA hard lifetime and the SA hard lifetime in an IPSec profile are set, the SA hard
lifetime in the IPSec profile takes effect.
Procedure
l Set the global IPSec SA hard lifetime.
a. Run system-view
b. Run ipsec sa global-duration { time-based interval | traffic-based size }
The global IPSec SA hard lifetime is set.
By default, the global time-based SA hard lifetime is 3600 seconds and the global
traffic-based SA hard lifetime is 1843200 Kbytes.
l Setting the IPSec SA hard lifetime in an IPSec profile.
a. Run system-view
b. Run ipsec profile profile-name
c. Run sa duration { time-based interval | traffic-based size }
The IPSec SA hard lifetime is set in the IPSec profile.
By default, the IPSec SA hard lifetime is not set in an IPSec profile. The system
uses the global IPSec SA hard lifetime.
----End
6.8.4 (Optional) Enabling the Anti-replay Function

Context
Replayed packets are packets that have been processed. IPSec uses the sliding window (anti-
replay window) mechanism to check replayed packets. Each AH or ESP packet has a 32-bit
sequence number. In an SA, sequence numbers of packets increase. If the sequence number of

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
a received authenticated packet is the same as that of a decapsulated packet or if the sequence
number is out of the sliding window, the device considers the packet as a replayed packet.
Decapsulating replayed packets consumes many resources and makes system performance
deteriorate, resulting in a Denial Of Service (DoS) attack. After the anti-replay function is
enabled, the system discards replayed packets and does not encapsulate them, saving system
resources.
In some situations, for example, when network congestion occurs or QoS is performed for
packets, the sequence numbers of some service data packets may be different from those in
common data packets. The device that has IPSec anti-replay enabled considers the packets as
replayed packets and discards them. You can disable global IPSec anti-replay to prevent
packets from being discarded incorrectly or adjust the IPSec anti-replay window size to meet
service requirements.
The anti-replay function can be configured globally or in an IPSec profile.

l Configuring the anti-replay function globally
The global anti-replay function is valid for all created IPSec profiles. When the same
anti-replay window parameters need to be set for many IPSec profiles, you do not need
to run commands one by one. You just need to set global parameters. The configuration
efficiency is therefore improved.
l Configuring the anti-replay function in an IPSec profile
The anti-replay function can be configured separately for an IPSec profile. In this case,
the anti-replay function for the IPSec profile is not affected by the global configuration.
Procedure
Step 2 Enable the anti-replay function. Run the following commands as required.
l Enable the anti-replay function globally.
a. Run ipsec anti-replay enable
The anti-replay function is enabled globally.
b. Run ipsec anti-replay window window-size
The global IPSec anti-replay window size is configured.

By default, the IPSec anti-replay window size is 1024 bits.
l Enable the anti-replay function in an IPSec policy.
a. Run ipsec profile profile-name
The IPSec anti-replay window size is configured in the IPSec profile.
By default, the anti-replay window size of a single IPSec tunnel is not set. The global
value is used.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.8.5 (Optional) Configuring IPSec Fragmentation Before

Encryption
Context
The length of IPSec-encapsulated packets may exceed the maximum transmission unit (MTU)
of the outbound interface on the local device. If the IPSec remote device does not support
fragmentation and reassembly, it cannot decapsulate packets and will discard or incorrectly
process packets, affecting packet transmission.
To prevent this problem, configure IPSec fragmentation before encryption on the local device.
Subsequently, the local device calculates the length of encapsulated packets. If the length
exceeds the MTU, the device fragments the packets and then encapsulates each fragment.
After packets reach the IPSec remote device, the remote device can decapsulate the fragments
without having to reassemble them. The decapsulated packets will be forwarded normally.
Procedure
The fragmentation mode of packets is set to fragmentation before encryption for all IPSec
tunnels.
By default, the packet fragmentation mode for all IPSec tunnels is fragmentation after
encryption.
The DF flag in IPSec packets determines whether IPSec packets can be fragmented. If DF
flag settings disable fragmentation when the fragmentation mode is used, run the ipsec df-bit
{ clear | set | copy } command in the system view to enable fragmentation on IPSec packets.
For the established IPSec tunnels, you need to restart them after running this command.
Otherwise, the command function does not take effect.
----End
6.8.6 (Optional) Configuring IPSec Check
Context
IPSec check ensures that data flows are correctly encrypted. After IPSec check is enabled, the
device checks packets received on the interface where an IPSec policy is applied.
After an IPSec profile is applied to a virtual tunnel interface, the device generates an ACL
based on the encapsulation mode of the tunnel interface. In tunnel mode, the IP header in the
decapsulated IPSec packet of the inbound SA may be not defined in an ACL. For example,
the IP header of attack packets may be out of the range defined in the ACL. After post-IPSec
check is configured, the device re-checks whether the IP header of the decapsulated IPSec
packet is in the range defined in an ACL. If the IP header matches the permit rule, the device
performs subsequent operations on the packet. Otherwise, the device discards the IPSec
packet. The network security is therefore improved.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The generated ACL varies depending on the encapsulation mode of the virtual tunnel
interface:
l When the encapsulation mode is set to IPSec, the source and destination addresses in the
ACL are both any, indicating that all data flows destined for the tunnel interface are
protected.
l When the encapsulation mode is set to GRE, the source and destination addresses in the
ACL are the source and destination addresses of the tunnel interface respectively.
Procedure
Step 2 Run ipsec decrypt check
Post-IPSec check is enabled.
By default, the device does not check decrypted IPSec packets.
----End
6.8.7 (Optional) Enabling the QoS Function for IPSec Packets

Context
In network planning, QoS needs to be configured to provide differentiated services for
different traffic flows to optimize network service capabilities. QoS groups the packets
sharing common features into one class and provides the same QoS level for traffic of the
same type. In this manner, QoS provides differentiated services for different types of packets.
QoS for IPSec packets implements refined QoS management on IPSec packets, choose either
of the following configurations as required:
l After packets are encapsulated using IPSec, the packets do not contain QoS related
parameters, such as header of the original packet and protocol number. Pre-extraction of
original IP packets needs to be configured if QoS needs to group encapsulated packets
based on the 5-tuple information such as original packet header and protocol number.
l When a device implements IPSec encapsulation and decapsulation on packets, it will
result in transmission delay and require higher bandwidth. Therefore, the device needs to
provide differentiated services for IPSec packets to reduce the delay, lower the packet
loss ratio, and maximize bandwidth for IPSec traffic. You can group IPSec packets into
one QoS group to allow QoS to implement differentiated services for IPSec packets.

Configure a traffic
Enable pre-
classifier
extraction of
based on access
original IP oackets Configure a Configure a Apply the
control List
Configure a traffic traffic behavior traffic policy traffic policy
Enable the QoS
classifier
function for IPSec
based on QoS
packets
group

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Procedure
Step 2 Enter the view where QoS for IPSec packets is configured.
l IPSec profile view
Run ipsec profile profile-name
l The tunnel interface view
Run interface tunnel interface-number
Choose either of the preceding methods.
Step 3 Enable the QoS function for IPSec packets.
The QoS group to which IPSec packets belong is configured.
By default, no QoS group is configured.
NOTE
This command can only be executed in the IPSec profile view.

----End
Follow-up Procedure
l After pre-extraction of original IP packets is enabled, run the if-match acl { acl-number |
acl-name } command in the traffic classifier view to configure a matching rule based on
the ACL.
l After QoS for IPSec packets is enabled, run the if-match qos-group qos-group-value
command in the traffic classifier view to configure a matching rule based on the QoS
group.
6.8.8 (Optional) Configuring the Device to Keep IPSec Tunnel

Indexes Unchanged Based on the Peer IP Address During IPSec
Tunnel Re-establishment
Context
In an MIB table, an IPSec tunnel index is the unique identifier of an IPSec tunnel. During
IPSec tunnel establishment, the device generates an IPSec tunnel index mapping table to

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
record IPSec tunnel index to IPSec tunnel mapping. In this mapping table, the device searches
for the corresponding IPSec tunnel based on an IPSec tunnel index. However, when an IPSec
tunnel is re-established, its IPSec tunnel index changes by default. As a result, the IPSec
tunnel cannot be found based on its previous IPSec tunnel index. In this case, configure the
device to keep IPSec tunnel indexes unchanged based on the peer IP address during IPSec
tunnel re-establishment. This configuration ensures that an IPSec tunnel can be found using
its fixed IPSec tunnel index.
NOTE
l This function works only when devices on both ends use fixed IPv4 addresses and establish only one
IPSec tunnel.
l During IPSec tunnel re-establishment, this function allows the device to keep only the first 1024
IPSec tunnel indexes unchanged based on the sequence in which IPSec tunnels are re-established.
l An IPSec tunnel index mapping table cannot be backed up, so this function does not work in an
active/standby switchover scenario.
Procedure
Step 2 Run ipsec tunnel-index based remote-ip
The device is configured to keep IPSec tunnel indexes unchanged based on the peer IP
address during IPSec tunnel re-establishment.
By default, the device is not configured to keep IPSec tunnel indexes unchanged based on the
peer IP address during IPSec tunnel re-establishment.
----End
6.8.9 (Optional) Configuring Requesting, Sending or Accepting of

Subnet Route Information
Context
As shown in Figure 6-34, a headquarters sets up an IPSec tunnel with its branch using a
tunnel interface. If requesting, sending or accepting of subnet route information is not
configured, data flows to be protected through IPSec need to be imported to the tunnel
interface based on the static or dynamic routes.
In the IPSec configuration,
l When the remote network topology changes, you must modify routes on the local device
to ensure IPSec protection for nonstop data transmission.
l When a new branch is added to the network and wants to establish an IPSec tunnel with
the headquarters, you must configure routes to the branch on the headquarters gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-34 Requesting, sending or accepting of subnet route information not configured
TunnelA TunnelB
PC a1 IPSec Tunnel PC b1
IPA IPB
PC a2 Branch Headquarters PC b2
… gateway gateway
…
ip route-static IPB tunnelA
ip route-static IPA tunnelB
PC aM PC bN
As shown in Figure 6-35, you only need to configure the subnet address to be protected
through IPSec on the local device. The local device then sends subnet route information to the
remote device that generates routes based on the information.
In the IPSec configuration,
l When the remote network topology changes, you do not need to modify routes on the
local device.
l When a new branch is added to the network and wants to establish an IPSec tunnel with
the headquarters, you do not need to add routes to the branch on the headquarters
gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-35 Requesting, sending or accepting of subnet route information configured

Branch Headquarters
TunnelA Tunnel-TemplateB
192.168.1.1/24 192.168.1.2/24
PC a1 IPSec Tunnel PC b1
IPA IPB
PC a2 Branch Headquarters PC b2
gateway gateway
…
…
· Requesting subnet route information
PC aM Request subnet route PC bN
① information Receive the request
ACL 3000
Generate routes rule permit ip source IPB
② interface Tunnel-TemplateB
Destination IP Next Hop
IPB Tunnel-TemplateB Send subnet route
information
· Sending and accepting subnet route information
ACL 3000
rule permit ip source IPA
① interface TunnelA Accept subnet route
Send subnet route information
information ACL 3000
rule permit ip source IPB
Accept subnet route interface Tunnel-TemplateB
②
information Send subnet route
information
③ Generate routes
Destination IP Next Hop Destination IP Next Hop
IPB Tunnel-TemplateB IPA TunnelA
NOTE
This function is supported by IKEv2 only.
Procedure
l Configuring requesting of subnet route information
After a local device is enabled to request subnet route information, the remote device
will send subnet route information directly without enabling send subnet route
information.
NOTE
Requesting of subnet route information takes effect on the IKE negotiation initiator only.
The local device requests subnet route information, generates a route based on the
received subnet route information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
a. Run system-view
b. Run ike peer peer-name
An IKE peer is created and the IKE peer view is displayed.
c. Run undo version 1
The IKE protocol version used by IKE peers is configured.
By default, IKE peers support IKEv1 and IKEv2.
If IKEv1 and IKEv2 are enabled, IKEv2 is used in the negotiation initiation, and
IKEv1 and IKEv2 are used in negotiation response.
d. (Optional) Run config-exchange request
The device is enabled to request subnet route information from a peer.
By default, the device does not request subnet route information from a peer.
e. Run route accept [ preference preference-number ] [ tag tag-value ]
The device is enabled to generate a route based on the received subnet route
information and define the priority and tag value for the route.
By default, the device does not generate routes based on the received subnet route
information.
The remote device configures subnet route information to be sent, sends subnet
route information directly after receiving the request.
a. Run system-view
b. Run aaa
The AAA view is displayed.
c. Run service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.
d. Run route set acl acl-number
Local subnet information to be sent to the peer is configured.
By default, no local subnet information to be sent to the peer is configured.
acl-number specifies an advanced ACL that has been created.
e. Run route set interface
An IP address which is to be sent to the peer is configured for the interface.
By default, no IP address which is to be sent to the peer is configured for the
interface.
l Configuring sending and accepting of subnet route information
After a local device is enabled to send subnet route information and a remote device is
enabled to accept subnet route information, sending of subnet route information is
enabled in one direction. To enable bidirectional sending of subnet route information, the
headquarters and branch devices must be enabled to send and accept subnet route
information at the same time.
The local device sends subnet route information.

a. Configure subnet route information to be sent.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
i. Run system-view
ii. Run aaa
iii. Run service-scheme service-scheme-name
iv. Run route set acl acl-number
Local subnet information to be sent to the peer is configured.
By default, no local subnet information to be sent to the peer is configured.
acl-number specifies an advanced ACL that has been created.
v. Run route set interface
An IP address which is to be sent to the peer is configured for the interface.
By default, no IP address which is to be sent to the peer is configured for the
interface.
b. Configure sending of subnet route information.
i. Run quit
ii. Run quit
iii. Run ike peer peer-name
iv. Run undo version 1
If IKEv1 and IKEv2 are enabled, IKEv2 is used in the negotiation initiation,
and IKEv1 and IKEv2 are used in negotiation response.
v. Run service-scheme service-scheme-name
Binds a service scheme to an IKE peer.
By default, no service scheme binds to an IKE peer.
vi. Run config-exchange set send
The device is enabled to send subnet route information to a peer.
By default, the device does not send subnet route information to a peer.
The remote device accepts subnet route information.
a. Run system-view
c. Run undo version 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
If IKEv1 and IKEv2 are enabled, IKEv2 is used in the negotiation initiation, and
IKEv1 and IKEv2 are used in negotiation response.
d. Run config-exchange set accept
The device is enabled to accept subnet route information from a peer.
By default, the device does not accept subnet route information from a peer.
e. Run route accept [ preference preference-number ] [ tag tag-value ]
The device is enabled to generate a route based on the received subnet route
information and define the priority and tag value for the route.
By default, the device does not generate routes based on the received subnet route
information.
----End
6.8.10 Configuring a Tunnel Interface or a Tunnel Template

Interface
Context
A tunnel interface is a Layer 3 logical interface where the encapsulation protocol of GRE,
mGRE, and IPSec, the device can provide IPSec service. The IPSec tunnel interface is
established based on IKE negotiation. After you configure a tunnel interface and apply an
IPSec profile to the tunnel interface, the IPSec tunnel is set up.
The IP address of an IPSec tunnel interface can be manually configured or dynamically
requested through IKEv2 negotiation. Dynamically requesting an IP address of the IPSec
tunnel interface through IKEv2 negotiation reduces the configuration and maintenance
workload of branch devices in scenarios where many branches connect to the headquarters.
A tunnel template interface is similar to a tunnel interface; however, the tunnel template
interface can only function as the responder but not the initiator. Generally, a tunnel template
interface is created on the headquarters gateway. When a new branch gateway is added to the
network, the headquarters gateway will generate a virtual tunnel interface dynamically.
NOTE
If you apply an IPSec profile to the tunnel template interface, the IKE peer referenced in the IPSec profile can
only be IKEv2.
In V300R003C10 and later versions, when multiple branches connect to the headquarters, multiple tunnel
interfaces in the headquarters borrow the same physical interface IP address. In this scenario, the headquarters
can identify the tunnel interface connected to a branch through the peer IP address or peer ID of the IKE peer
(only IKEv1 in aggressive mode supports the peer ID mode). If you run the destination command on a tunnel
interface of the headquarters to specify the IP address of a branch interface, the headquarters preferentially
uses this IP address to identify the access of the branch.
When multiple branches are connected to the headquarters, if some tunnel interfaces at the headquarters
borrow an IP address from a physical interface and borrow an IP address from a physical interface as their
source address, the mappings between IKE peers and tunnel interfaces may be incorrect. As a result, an IPSec
tunnel fails to be established.
Procedure
l Configuring a Tunnel Interface
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

c. Run tunnel-protocol { gre [ p2mp ] | ipsec }
The encapsulation mode of a tunnel interface is configured.
NOTE
An IPSec profile can be bound to an IPSec tunnel interface only when the tunnel
encapsulation mode is set to IPSec, GRE, or Multipoint GRE (mGRE):
l IPSec: An IPSec tunnel established on a tunnel interface ensures security of unicast
data transmitted on the Internet.
l GRE: The IPSec tunnel interface provides GRE over IPSec and transmits unicast and
multicast data. The IPSec tunnel interface first adds a GRE header to packets, and then
adds an IPSec header to the packets so that packets are reliably transmitted.
l mGRE (specified by gre and p2mp): The IPSec tunnel interface provides Dynamic
Smart Virtual Private Network (DSVPN) functions. See 5 DSVPN Configuration.
d. Run the following commands as required.
n Run ip address ip-address { mask | mask-length } [ sub ]
A private IPv4 address is configured for the tunnel interface.
n On the IPSec tunnel interface, run ip address ike-negotiated
An IPv4 address is requested for the tunnel interface through IKEv2
negotiation.
e. Run source { [ vpn-instance vpn-instance-name ] source-ip-address | interface-
type interface-number [ standby ] }
The source address or source interface is configured.
You can specify the vpn-instance vpn-instance-name parameter only when the
encapsulation mode of a tunnel interface is set to IPSec or mGER.
NOTE
It is recommended that the source interface be specified. This is because a dynamic IP

address may affect IPSec configuration recovery.
f. (Optional) Run destination [ vpn-instance vpn-instance-name ] dest-ip-address
The destination address is configured.
When the destination address of an IPSec tunnel interface is not configured, the
remote address of the IKE peer referenced by the IPSec profile can be used for
initiating negotiation. When the destination address of an IPSec tunnel interface and
remote address of an IKE peer are not configured, the local end can only accept the
negotiation request initiated by the remote end.
If the encapsulation mode of a tunnel interface is set to GRE, you need to configure
destination addresses at both ends.
g. (Optional) Run tunnel pathmtu enable

The device is enabled to learn the maximum transmission unit (MTU) of packets
allowed on an IPSec tunnel.
By default, the device cannot learn the MTU of packets allowed on an IPSec tunnel.
NOTE
This command takes effect only when the encapsulation mode of the tunnel interface is IPSec or
GRE and the destination command has been configured on the tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
h. Run ipsec profile profile-name [ shared ]

An IPSec profile is applied to the tunnel interface.
By default, no IPSec profile is applied to a tunnel interface.
Only one IPSec profile can be applied to a tunnel interface, and when shared is not
specified, an IPSec profile can be applied to a maximum of 4 tunnel interfaces;
when shared is specified, an IPSec profile can be applied to a maximum of 64
tunnel interfaces.
Only the tunnel interface of mGRE type supports shared.
If the same outbound interface is specified for multiple tunnel interfaces, the same
IPSec profile must be applied to and the shared parameter must be configured for
these tunnel interfaces. Otherwise, both ends cannot establish an IPSec tunnel.
When shared is specified, the source command is not supported to specify the
standby parameter in V300R003C10 and later versions.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high
CPU usage alarms may be generated in a short period of time after the undo ipsec
profile command is run. After all the SAs are cleared, the CPU usage restores to the
normal range.
i. (Optional) Run standby interface interface-type interface-number [ priority ]
A standby tunnel interface is configured and its priority is specified.
By default, no standby tunnel interface is configured.
The headquarters provides two gateways and more than two gateways for the
branch gateway to improve network reliability. When an IPSec tunnel is set up
using virtual tunnel interfaces, you can configure a standby tunnel interface on the
branch gateway and apply an IPSec profile to the standby interface to provide a
standby link for IPSec setup. Meanwhile, you need to configure the heartbeat or
DPD mechanism to implement fast switching between the active and standby
tunnels upon a tunnel fault.
l Configuring a Tunnel Template Interface
a. Run system-view
b. Run interface tunnel-template interface-number
The tunnel template interface view is displayed.
c. Configuring the IP address of the tunnel template interface.
n Run ip address ip-address { mask | mask-length } [ sub ]
The IPv4 address of the tunnel template interface is configured.
n Run ip address unnumbered interface interface-type interface-number
The tunnel template interface is configured to borrow an IP address from
another interface.
d. Run tunnel-protocol ipsec
The encapsulation mode of the tunnel template interface is set to IPSec.
e. Run source { [ vpn-instance vpn-instance-name ] source-ip-address | interface-
type interface-number }
The source address or source interface is configured for the tunnel template
interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
If the source address of the tunnel template interface is dynamically obtained, you are
advised to specify the source interface when running the source command. This prevents the
impact of address change on the IPSec configuration.
f. (Optional) Run tunnel pathmtu enable
The device is enabled to learn the MTU of packets allowed on an IPSec tunnel.
By default, the device cannot learn the MTU of packets allowed on an IPSec tunnel.
g. Run ipsec profile profile-name
The IPSec profile is applied to a tunnel template interface so that data flows on the
interface are protected by IPSec.
By default, no IPSec profile is applied to the tunnel template interface.
You can apply only one IPSec profile to a tunnel template interface. An IPSec
profile can be applied to only one tunnel template interface.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high
CPU usage alarms may be generated in a short period of time after the undo ipsec
profile command is run. After all the SAs are cleared, the CPU usage restores to the
normal range.
----End
Configuration Guidelines
l The IPSec profile configuration applied to a tunnel interface is deleted if you modify the
value of the parameter source or destination on the tunnel interface. Apply the IPSec
profile to the tunnel interface again.
l If you modify the tunnel-protocol parameter of a tunnel interface, the IPSec policy
group applied to the tunnel interface will be deleted. After the modification, apply IPSec
policy group to the tunnel interface as required.
l The IPSec profile configuration applied to a tunnel template interface is deleted if you
modify the value of the parameter source on the tunnel template interface. Apply the
IPSec profile to the tunnel template interface again.
l To disable IPSec negotiation, you must run the shutdown command to shut down the
corresponding physical interface but not the tunnel interface.
6.8.11 Verifying the Configuration of IPSec Tunnel Establishment

Using a Virtual Tunnel Interface
Prerequisites
The configurations of the IPSec tunnel that is established using a virtual tunnel interface are
complete.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] command to check
IPSec proposal information.
l Run the display ipsec profile [ brief | name profile-name ] command to check IPSec
profile information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ike identity [ name identity-name ] command to check IKE identity
information.
l Run the display ipsec global config command to check global IPSec configuration.
l Check IKE information. See 6.11.16 Verifying the IKE Configuration.
----End
6.9 Establishing an IPSec Tunnel Using an Efficient VPN

Policy
Context
Figure 6-36 Using an Efficient VPN policy to establish an IPSec tunnel

SOHO office/
Traveling staff 1
…
SOHO office/
Traveling staff N
Branch 1 Headquarters
…
Branch N
IPSec Tunnel
Before using an Efficient VPN policy to establish an IPSec tunnel, complete the following
tasks:
l Determine the initiator as the remote device and the responder as the Efficient VPN
server.
l Determine data flows to be protected by IPSec.
l Determine parameters in an IPSec proposal.
Configure an Efficient VPN policy on a remote device, and configure an IPSec policy
template on the Efficient VPN server to establish an IPSec tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.9.1 Configuring the Remote Device
Context
Only mandatory parameters, such as the Efficient VPN server IP address and pre-shared key,
need to be configured on a remote device. Other parameters, such as authentication and
encryption algorithms used in IKE negotiation, and the IPSec proposal, are preconfigured on
the Efficient VPN server. Configuring parameters on the remote device includes configuring
basic and optional parameters:
1. Basic parameters: Efficient VPN operation mode, IP address of the remote device
connected to the Efficient VPN server, and authentication key.
2. Optional parameters can be set on the remote device and Efficient VPN server. If
optional parameters are configured at one end, the two ends use these parameters. If
optional parameters are configured at two ends, the two ends must use the same
parameters to implement successful IKE negotiation.
Efficient VPN provides the following modes:
l Client mode
a. When a remote device requests an IP address from the Efficient VPN server, a
loopback interface is dynamically created on the remote device and the IP address
obtained from the server is assigned to the loopback interface.
b. The remote device automatically enables NAT to translate its original IP address
The client mode applies to scenarios where traveling staff or small-scale branches
connect to the headquarters network through private networks, as shown in Figure 6-37.
In client mode, devices connected to the Efficient VPN server or remote devices can use
the same IP address. However, the number of devices allowed depends on the number of
IP addresses assigned by the Efficient VPN server.
Figure 6-37 Client mode

192.168.0.5/32
SOHO office
10.1.0.1/24
192.168.0.6/32 Remote
SOHO office
Headquarters
Remote
10.1.0.5/32 Server
Traveling staff
Remote
10.1.0.6/32
Traveling staff
Remote

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
Traveling staff use software to establish a virtual network adapter on a PC. The virtual network
adapter then uses parameters such as addresses sent by the Efficient VPN server.
l Network mode
In network mode, a remote device does not apply to the Efficient VPN server for an IP
address. Therefore, NAT is not enabled in network mode. Figure 6-38 shows the
network mode.
Figure 6-38 Network mode
10.1.1.X
Branch 1 10.1.0.X
Remote
Headquarters
Server
10.1.2.X
Branch N
Remote
The network mode applies to scenarios where IP addresses of the headquarters and
branches are planned uniformly. Ensure that IP addresses do not conflict.
l Network-plus mode
Compared with the network mode, the remote device applies to the Efficient VPN server
for an IP address in network-plus mode. IP addresses of branches and headquarters are
configured beforehand. A remote device applies to the Efficient VPN server for an IP
address. The Efficient VPN server uses the IP address to perform ping, STelnet, or other
management and maintenance operations on the remote device. NAT is not enabled on
the remote device.
l Network-auto-cfg mode
Compared with the network-plus mode, the remote device applies to the Efficient VPN
server for an IP address pool in network-auto-cfg mode. The IP address pool is used for
allocating addresses to users.
The Efficient VPN server also delivers the following resources in addition to parameters for
establishing an IPSec tunnel:
l Network resources including the DNS domain name, DNS server IP addresses, and
WINS server IP addresses
The Efficient VPN server delivers the preceding resources so that branches can access
them on the Efficient VPN server.
l ACL resources
The Efficient VPN server delivers headquarters network information defined in an ACL
to the remote device. The ACL defines the headquarters subnets that branches can

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
access. Traffic not destined for the subnets specified in the ACL is directly forwarded to
the Internet. Such traffic does not pass through the IPSec tunnel.
NOTE
In the Network-auto-cfg mode, delivering of parameters defined in the ACL is not supported.
Procedure
Step 1 Set basic parameters and optional parameters on the remote device.
1. Run system-view
2. Create an Efficient VPN policy and determine whether to reference an ACL based on the
Efficient VPN mode.
– Create an IPSec Efficient VPN policy in client mode.
Run ipsec efficient-vpn efficient-vpn-name [ mode client ]
An IPSec Efficient VPN policy in client mode is created and the IPSec Efficient
VPN policy view is displayed.
By default, no IPSec Efficient VPN policy is created in the system.
The remote device in client mode applies to the headquarters for an IP address to
establish an IPSec tunnel with the Efficient VPN server. The source address in
packets sent from the branch to the headquarters is the requested IP address, so
ACLs are not required.
– Create an IPSec Efficient VPN policy in network-auto-cfg mode.
Run ipsec efficient-vpn efficient-vpn-name [ mode network-auto-cfg ]
An IPSec Efficient VPN policy in network-auto-cfg mode is created and the IPSec
Efficient VPN policy view is displayed.
The network-auto-cfg mode is supported in IKEv1 only.
– Create an IPSec Efficient VPN policy in network or network-plus mode and
reference an ACL.
i. Run ipsec efficient-vpn efficient-vpn-name [ mode { network | network-
plus } ]
An IPSec Efficient VPN policy in network or network-plus mode is created
and the IPSec Efficient VPN policy view is displayed.
ii. Run security acl acl-number
An ACL is referenced in the IPSec Efficient VPN policy.
By default, no ACL is referenced.
If an ACL is referenced, the rule can only match IP packets, that is, rule permit ip.
3. Run remote-address { ip-address | host-name host-name } { v1 | v2 }
A peer address or a domain name in IKE negotiation is configured.
By default, no IP address or domain name is configured for the remote IKE peer during
IKE negotiation.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
You can configure a maximum of two IP addresses or two domain names in the same
view.
To improve network reliability, two devices can be deployed at the headquarters to
connect to the branch gateway. In an IPSec policy, two IP addresses or domain names of
the remote IKE peer can be configured on the branch gateway. The branch gateway first
attempts to use the first configured IP address or domain name to establish an IKE
connection with the headquarters gateway. If establishing an IKE connection fails, the
branch gateway uses the second IP address or domain name to establish an IKE
connection.
4. Configure an authentication key according to the authentication mode in the IKE
proposal.
NOTE
The system uses the pre-shared key authentication by default. The remote device and Efficient
VPN server select the authentication mode using the authentication-method command.
– If pre-shared key authentication is used, configure a pre-shared key.
Run pre-shared-key { simple | cipher } key
A pre-shared key is configured.
By default, no pre-shared key is configured on IKE peers.
The pre-shared key at the two ends must be the same.
If simple is used, passwords are saved in the configuration file in plain text,
resulting in security risks. Therefore, cipher is recommended to save passwords in
cipher text.
– When RSA signature authentication is used, obtain a digital signature.
i. Run pki realm realm-name
A PKI domain that the digital signature in the Efficient VPN policy belongs to
is specified. The system obtains the local CA certificate and device certificate
according to the PKI configuration.
By default, no PKI domain is bound to an IKE peer or an Efficient VPN
policy.
realm-name specifies a PKI domain that has been created using the pki realm
command.
ii. (Optional) Run inband ocsp
The device is configured to validate the remote certificate based on the OCSP
validation result sent from the remote device when IKEv2 uses RSA signature
authentication.
By default, the device does not validate the remote certificate based on the
OCSP validation result sent from the remote device when IKEv2 uses RSA
signature authentication.
iii. (Optional) Run inband crl
The device is configured to validate the remote certificate based on the CRL
sent from the remote device when IKEv2 uses RSA signature authentication.
CRL sent from the remote device when IKEv2 uses RSA signature
authentication.
5. Run dh { group1 | group2 | group5 | group14 | group19 | group20 | group21 }
A Diffie-Hellman group used for IKE negotiation is configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, group14 is used for IKE negotiation.

You are advised not to use group1, group2, or group5; otherwise, security defense
requirements may be not met.
6. (Optional) Set optional parameters.
– Run authentication-method { pre-share | rsa-signature }
An authentication method is specified for an IKE proposal.
By default, pre-shared key authentication is used.
– Run local-id-type { dn | ip | key-id | fqdn | user-fqdn }
The local ID type used in IKE negotiation is set.
By default, the IP address of the local end is used as the local ID.
When the device functions as the remote end to communicate with a Cisco device
in the Efficient VPN policy, you need to specify the key-id parameter in the
command. Meanwhile, you also need to run the service-scheme command to
specify the service scheme that the Cisco device uses.
– Run service-scheme service-scheme-name
A server-end service scheme is configured in an Efficient VPN policy.
By default, no server-end service scheme is configured in an Efficient VPN policy.
If an AAA service scheme is configured in the Efficient VPN policy, you need to
specify the AAA service scheme configured on the server before the server can
authorize the remote device. Meanwhile, you also need to specify the key-id
parameter in the local-id-type command. If the key-id parameter is not specified,
the configuration does not take effect. If authorization is performed using the
service scheme used on the server, this step is not required.
If the aaa authorization command is configured on the server to enable AAA
RADIUS server authorization, run the service-scheme command to specify the
AAA domain configured on the server.
– Run sim-based-username type { imei | imsi } password password
The type of the user name used by the remote device to be authenticated by the
RADIUS server is configured.
By default, the type of the user name used by the remote device to be authenticated
by the RADIUS server is not configured.
The configuration of this step takes effect in the network-auto-cfg mode only.
– Run dpd msg { seq-hash-notify | seq-notify-hash }
The sequence of the payload in DPD packets is set.
By default, the sequence of the payload in DPD packets is notify-hash.
The two ends must use the same sequence of the payload in DPD packets;
otherwise, DPD is invalid.
– Run dpd msg notify-hash-sequence learning
Automatic learning of the payload sequence of DPD packets is enabled.
By default, automatic learning of the payload sequence of DPD packets is enabled.
After this command is configured, when the local end receives a DPD packet from
the remote end, the local end learns the payload sequence of the DPD packet and
sends a DPD packet in the same payload sequence.
NOTE
Only V300R003C10 and later versions support.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– Run tunnel local { ip-address | applied-interface }

A local IP address is configured.
By default, the local IP address is not configured.
For the IKE negotiation mode, you do not need to configure an IP address for the
local end of an IPSec tunnel. During SA negotiation, the device will select a proper
address based on route information. The local address needs to be configured in the
following situations:
n If the IP address of the interface to which an IPSec policy is applied varies or
is unknown, run the tunnel local ipv4-address command to specify the IP
address of another interface (such as the loopback interface) on the device as
the IP address for the local end of an IPSec tunnel. Otherwise, run the tunnel
local applied-interface command to specify the IP address of the interface to
which an IPSec policy is applied as the local address of an IPSec tunnel.
n If the interface to which an IPSec policy is applied has multiple IP addresses
(one primary IP address and several secondary IP addresses), run the tunnel
local ipv4-address command to specify one of these IP addresses as the IP
address for the local end of an IPSec tunnel. Otherwise, run the tunnel local
applied-interface command to specify the primary IP address of the interface
as the local address of an IPSec tunnel.
n If equal-cost routes exist between the local and remote ends, run the tunnel
local command to specify a local IP address for an IPSec tunnel.
– Run remote-id id
The remote ID for IKE negotiation is configured.
By default, the remote ID for IKE negotiation is not configured.
– Run sa binding vpn-instance vpn-instance-name
A VPN instance is bound to an IPSec tunnel.
This command specifies the VPN that the remote end of the IPSec tunnel belongs
to. The tunnel initiator then can obtain the outbound interface and send packets
through the outbound interface.
– Run qos group qos-group-value
The QoS group to which the IPSec packets belong is set.
By default, no QoS group to which the IPSec packets belong is set.
– Run qos pre-classify
– Run pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-
The device is configured to use Perfect Forward Secrecy (PFS) in IPSec
negotiation.
By default, PFS is not used in IPSec negotiation.
– Run anti-replay window window-size
The IPSec anti-replay window size is set.
By default, the IPSec anti-replay window size is 1024 bits.
7. Apply the Efficient VPN policy to an interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
a. Run quit
b. Run interface interface-type interface-number
c. Run ipsec efficient-vpn efficient-vpn-name
The Efficient VPN policy is applied to the interface.
You can bind only one Efficient VPN policy to the remote device in a scenario except
that the remote device has multiple egress links.
Step 2 (Optional) Set optional parameters in the system view on the remote device.
l 6.7.8 (Optional) Configuring IPSec Check
l 6.7.6 (Optional) Configuring IPSec Fragmentation Before Encryption
l Set the global IPSec SA lifetime.
l 6.7.5 (Optional) Enabling the Anti-replay Function
----End
6.9.2 Configuring the Efficient VPN Server
Context
Parameters on the Efficient VPN server include network resource parameters and IPSec
parameters:
1. Network resource parameters include the IP address, domain name, DNS server address,
and WINS server address. The Efficient VPN server can deliver network resource
parameters to the remote device over the IPSec tunnel.
2. An SA must be set up through an IPSec policy template. There are limitations on other
IPSec parameters.
Procedure
Step 1 (Optional) Set network resource parameters on the Efficient VPN server.
1. (Optional) Configure a global address pool and deliver the IP address used to establish
an IPSec tunnel to the remote device.
NOTE
If the Efficient VPN policy on the remote device uses the client, network-plus, or network-auto-cfg
mode, the Efficient VPN server must deliver the IP address.
a. Run system-view
b. Run ip pool ip-pool-name
A global address pool is created.
c. Run network ip-address [ mask { mask | mask-length } ]
An allocatable network segment address is specified for the global address pool.
d. Run gateway-list ip-address &<1-8>
An egress gateway address is configured for the global address pool.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. Configure resources to be delivered in the service scheme view.

a. Run system-view
b. Run aaa
c. Run service-scheme service-scheme-name
d. (Optional) Run ip-pool pool-name [ move-to new-position ]
An IP address pool is configured.
pool-name specifies the global address pool configured in step a.
e. (Optional) Run auto-update url url-string version version-number
The URL and version number are configured.
The remote device can download the version file, patch file, and configuration file
through the URL and branch devices can be upgraded automatically.
f. (Optional) Run dns-name domain-name
A DNS domain name is configured.
g. (Optional) Configure DNS server IP addresses and WINS server IP addresses.
i. Run dns ip-address
The IP address of the primary DNS server is configured.
ii. (Optional) Run dns ip-address secondary
The IP address of the secondary DNS server is configured.
iii. Run wins ip-address
The IP address of the primary WINS server is configured.
iv. (Optional) Run wins ip-address secondary
The IP address of the secondary WINS server is configured.
Step 2 Set IPSec parameters on the Efficient VPN server.
1. Run system-view
2. Configure an IPSec proposal.
NOTE
– encapsulation-mode must be set to tunnel to establish an IPSec tunnel using an Efficient VPN
policy.
– When IKEv1 is used, IPSec supports non-authentication and non-encryption. When IKEv2 is used,
IPSec does not support non-authentication or non-encryption.
– The Efficient VPN policy supports only ESP.
For details on how to configure an IPSec proposal, see 6.7.2 Configuring an IPSec
Proposal.
3. Configure an IKE proposal.
NOTE
– The encryption algorithm used during IKEv1 negotiation must be 3des-cbc, and the
authentication algorithm must be md5, sha1 or sha2. 3des-cbc, md5, and sha1 are insecure.
Exercise caution when you use 3des-cbc, md5, or sha1. md5 is recommended.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
For details on how to configure an IKE proposal, see 6.11.1 Configuring an IKE
Proposal.
4. Configure an IKE peer.
NOTE
– When IKEv1 is used, exchange-mode must be set to aggressive.

– You can run the resource acl acl-number command in IKEv1 to implement ACL delivery.
ACL delivering is not supported in the Network-auto-cfg mode.
– Run the service-scheme command to bind the IKE peer to the AAA service scheme so that network
resources including the IP address, domain name, DNS server IP addresses, and WINS server IP
addresses can be delivered.
– In the Efficient VPN policy, run the aaa authorization [ domain domain-name ] command on an
IKE peer to enable AAA RADIUS server authorization.
If the domain parameter is specified, the remote device obtains authorization information using the
specified domain. If the domain parameter is not specified, the remote device obtains authorization
information using the domain name it sends to the server. The domain name is specified using the
service-scheme command in the Efficient VPN policy view.
If the aaa authorization command is configured on the IKE peer, the service-scheme command
configured on the server does not take effect.
For details on how to configure an IKE peer, see 6.11.2 Configuring an IKE Peer.
5. Configure an IPSec policy using an IPSec policy template.
For details on how to configure an IPSec policy using an IPSec policy template, see
6.7.3.3 Configuring an IPSec Policy Using an IPSec Policy Template.
6. (Optional) Configure the following extensions.
– 6.7.8 (Optional) Configuring IPSec Check
– 6.7.6 (Optional) Configuring IPSec Fragmentation Before Encryption
– Set the global IPSec SA lifetime
– Enabling the Anti-replay Function
– Allowing New Users with the Same Traffic Rule as Original Branch Users to
Access the Headquarters Network
7. Apply an IPSec policy group to an interface.
For details on how to apply an IPSec policy group to an interface, see 6.7.17 Applying
an IPSec Policy Group to an Interface.
----End
6.9.3 Verifying the Efficient VPN Configuration

Prerequisites
The Efficient VPN configurations are complete.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] or display ipsec
proposal [ brief | name proposal-name ] ctrl-plane command to check IPSec proposal
information.
l Run the display ipsec efficient-vpn [ brief | capability | name efficient-vpn-name |
remote ] command to check Efficient VPN policy information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ipsec sa [ brief | duration | efficient-vpn efficient-vpn-name | policy

policy-name [ seq-number ] | profile profile-name | remote ip-address ] command to
check IPSec SA information.
l Run the display ipsec interface brief command to check information about the IPSec
policies applied to interfaces.
l Check IKE information. See 6.11.16 Verifying the IKE Configuration.
----End
6.10 Configuring an IPSec Tunnel in the Auto VPN

Scenario
Context
This chapter describes how to configure an IPSec tunnel to encrypt data during transmission
and ensure data communication security after the tunnel optimization configurations are
completed.
NOTE
Context
Procedure
By default, AH uses the SHA2-256 authentication algorithm.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

sha2-512 }
By default, ESP uses the SHA2-256 authentication algorithm.
By default, ESP uses the AES-256 encryption algorithm.
NOTE

recommended.
Step 6 Run quit
----End
6.10.2 Configuring an IPSec P2MP Security Policy
Context
An IPSec point-to-multipoint (P2MP) security policy is a prerequisite for creating SAs and
determines the methods used to protect specified data flows.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run ipsec p2mp-policy policy-name
An IPSec P2MP security policy is created and the IPSec P2MP security policy view is
displayed.
By default, no IPSec P2MP security policy is configured in the system.
An IPSec proposal is referenced.
By default, no IPSec proposal is referenced in the system.
proposal-name specifies a created IPSec proposal.
An IPSec P2MP security policy can reference only one IPSec proposal. A new IPSec proposal
can be referenced only after the precious referenced one has been deleted.
Step 4 (Optional) Run sa duration time-based minutes
The lifetime of an IPSec SA in the IPSec P2MP security policy is configured.
By default, the lifetime of an IPSec SA in an IPSec P2MP security policy is 1440 minutes.
Step 5 (Optional) Run anti-replay enable
The IPSec anti-replay function is enabled.
By default, the IPSec anti-replay function is enabled.
Step 6 (Optional) Run anti-replay window window-size
The anti-replay window size of a single IPSec tunnel is configured.
By default, the anti-replay window size of a single IPSec tunnel is not configured on a device
and the system uses the current global IPSec anti-replay window size.
----End
6.10.3 Enabling the IPSec P2MP Security Policy Function on a

Tunnel Interface
Context
In a tunnel optimization scenario, you need to enable the IPSec P2MP security policy function
on a tunnel interface before performing IPSec encryption for BGP packets.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The virtual tunnel interface view is displayed.
Step 3 Run ipsec p2mp-policy enable
The IPSec P2MP security policy function is enabled on a tunnel interface.
By default, the IPSec P2MP security policy function is disabled on a tunnel interface.
----End
6.10.4 Verifying the IPSec Tunnel Configuration
Prerequisites
All configurations of the IPSec tunnel have been completed.
Procedure
l Run the display ipsec proposal [ brief | name proposal-name ] or display ipsec
proposal [ brief | name proposal-name ] ctrl-plane command to check information
about the IPSec proposal.
l Run the display ipsec p2mp-policy [ name policy-name ] command to check
configuration information about the IPSec P2MP security policy.
l Run the display ipsec local p2mp-sa command to check configuration information
about the local IPSec P2MP SA.
l Run the display ipsec peer p2mp-sa command to check configuration information about
the remote IPSec P2MP SA.
----End
6.11 Configuring IKE

IKE provides key negotiation and SA establishment to simplify IPSec use and management.
Before configuring IKE, complete the following tasks:
l Determine parameters in an IKE proposal.
l Determine the PKI domain that the IKE peer belongs to if RSA signature authentication
is used.
NOTE
For details on how to configure PKI, see Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series V300R003
Configuration Guide - Security.
Configure matching parameters at the two ends to complete IKE negotiation.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.11.1 Configuring an IKE Proposal
Context
An IKE proposal is a component of an IKE peer, and it defines IKE negotiation parameters,
including the encryption algorithm, authentication method, authentication algorithm, Diffie-
Hellman (DH) group, and security association (SA) lifetime.
During IKE negotiation, the initiator sends its own IKE proposal to the peer end for matching.
The responder starts with the highest-priority IKE proposal and matches the peer in the order
of priority until it finds a matching IKE proposal to use. The matching IKE proposal will be
used to establish an IKE tunnel.
A smaller IKE proposal number indicates a higher priority. You can create multiple IKE
proposals with different priorities. The two ends must have at least one matching IKE
proposal for IKE negotiation.
Two matching IKE proposals define the same encryption algorithm, authentication mode,
authentication algorithm, and DH group. If the IKE SA lifetimes of two ends are different, the
two ends use the smaller IKE SA lifetime for IKE negotiation.
NOTE
If no IKE proposal is created, the system has a default IKE proposal with the lowest priority. If you specify
only the sequence number when creating an IKE proposal, the parameters of the IKE proposal are also the
default parameters.
Procedure
Step 2 Run ike proposal proposal-number
An IKE proposal is created and the IKE proposal view is displayed.
Step 3 Run authentication-method { pre-share | rsa-signature | digital-envelope }
An authentication method is configured.
By default, an IKE proposal uses pre-shared key authentication.
The authentication methods in the IKE proposals used by the IKE peer must be the same.
Otherwise, IKE negotiation fails.
NOTE
Digital envelope authentication is released by the State Encryption Administration of China. It can be used
only for IKEv1 negotiation in main mode. It cannot be used for IKEv1 negotiation in aggressive mode or for
IKEv2 negotiation.
When IKE peers use IKEv2, you need to run the re-authentication interval command to make the
configured authentication method take effect.
Step 4 Run authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
The authentication algorithm used in IKEv1 negotiation is configured.
By default, the SHA2-256 authentication algorithm is used in IKEv1 negotiation.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An authentication algorithm needs to be configured for IKEv1 negotiation. The following

authentication algorithms are listed in descending order of security level: SHA2-512,
SHA2-384, SHA2-256, SHA1, MD5.
The MD5 and SHA1 algorithms are susceptible to attacks and their use is not recommended.
NOTE
In IKEv1 certificate negotiation, if the authentication algorithm sha2-512 is configured, the RSA key length
must be greater than 1024.
Step 5 Run encryption-algorithm { des | 3des | aes-128 | aes-192 | aes-256 }
The encryption algorithm used in IKE negotiation is configured.
By default, the AES-256 encryption algorithm is used in IKE negotiation.
The following encryption algorithms are listed in descending order of security level:
AES-256, AES-192, AES-128, 3DES, and DES.
The DES and 3DES algorithms are susceptible to attacks and their use is not recommended.
Step 6 Run dh { group1 | group2 | group5 | group14 | group19 | group20 | group21 }
The DH group used in IKE negotiation is configured.
By default, the DH group, group14, is used in IKE negotiation.
The following DH groups are listed in descending order of security level:group21, group20,
group19, group14, group5, group2, and group1.
The DH groups, group1, group2, and group5 are susceptible to attacks and their use is not
recommended.
Step 7 Run prf { aes-xcbc-128 | hmac-md5 | hmac-sha1 | hmac-sha2-256 | hmac-sha2-384 |

hmac-sha2-512 }
The pseudo-random function (PRF) algorithm used in IKEv2 negotiation is configured.
By default, the HMAC-SHA2-256 PRF algorithm is used in IKEv2 negotiation.
The HMAC-MD5 and HMAC-SHA1 algorithms are susceptible to attacks and their use is not
recommended.
Step 8 Run integrity-algorithm { aes-xcbc-96 | hmac-md5-96 | hmac-sha1-96 | hmac-sha2-256 |

hmac-sha2-384 | hmac-sha2-512 }
The integrity algorithm used in IKEv2 negotiation is configured.
By default, the HMAC-SHA2-256 integrity algorithm is used in IKEv2 negotiation.
----End
Relevant Content
Video: Configuring an IKE Proposal

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.11.2 Configuring an IKE Peer
Context
When an IPSec tunnel is established in IKE negotiation mode, you need to reference an IKE
peer and configure attributes between IKE peers during IKE negotiation. When configuring
attributes between IKE peers, note the following points:
l The IKE peers must use the same IKE version.
l The IKE peers that use IKEv1 must use the same negotiation mode.
l Identity authentication parameters of the IKE peers must match.
IKE has two versions: IKEv1 and IKEv2. The differences between IKEv1 and IKEv2 are as
follows:
l IKEv1 requires the phase 1 negotiation mode, whereas IKEv2 does not.
l IKEv1 does not support the Online Certificate Status Protocol (OCSP) for an IKE peer,
whereas IKEv2 supports.
l IKEv2 supports the re-authentication interval to enhance security, whereas IKEv1 does
not support the re-authentication interval.
Before configuring an IKE peer, complete the following tasks:
l Import the local certificate and CA root certificate on the authenticated end and import
the CA root certificate on the authenticating end if RSA signature authentication is used.
l Generate the RSA key pair on the authenticated end if RSA key authentication is used.
In IKEv1 certificate negotiation, if the authentication algorithm sha2-512 is configured,
the RSA key length must be greater than 1024.
Procedure
Step 2 Run ike peer peer-name
By default, no IKE peer is created in the system.
Step 3 Run version { 1 | 2 }
Step 4 (Optional) Run exchange-mode { main | aggressive | auto }
IKEv1 phase 1 negotiation mode is set.
By default, the main mode is used in IKEv1 phase 1.
l Main mode: protects identities.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Aggressive mode: provides faster negotiation speed, but cannot protect identities.
l Auto-sensing mode: The main mode is used if the device serves as the initiator. If the
device serves as the responder, both the main mode and aggressive mode can be used.
Step 5 (Optional) Run local-address ipv4-address
The local IP address in IKE negotiation is configured.
By default, the system selects an outbound interface according to a route and uses the IP
address of the outbound interface as the local IP address.
Generally, you do not need to configure the local IP address.
l If the IP address of an interface bound to an IPSec policy is variable or unknown, run the
local-address ipv4-address command to specify the IP address of another interface such
as a loopback interface as the local IP address.
l If an interface bound to an IPSec policy is configured with one primary IP address and
multiple secondary IP addresses, run the local-address ipv4-address command to specify
one IP address as the local IP address.
l If the local and remote ends have equal-cost routes, run the local-address ipv4-address
command to specify the local IP address so that IPSec packets can be sent out from the
specified interface.
Step 6 (Optional) Run remote-address { [ vpn-instance vpn-instance-name ] { ipv4-address | host-
name host-name } | authentication-address start-ipv4-address [ end-ipv4-address ] }
The remote IP address or domain name used in IKE negotiation is configured.
By default, an IKE peer has no domain name, remote IP address, or remote IP address range
configured.
If a VPN instance has been configured on the interface applied with an IPSec policy, the vpn-
instance-name parameter needs to be configured. After this parameter is configured, the
device searches for a route to the remote IP address in the specified VPN during IPSec tunnel
negotiation. If more than one remote IP address or domain name is configured, the specified
vpn-instance-name must be the same.
If the remote device has a variable IP address and a fixed domain name, you must specify
host-name to configure the remote domain name. In this situation, the remote end must have
Dynamic Domain Name System (DDNS) configured to bind domain names to dynamic IP
addresses, and the local end must have DNS configured for domain name resolution.
You can specify authentication-address to configure the pre-NAT IP address as the remote
authentication address when the following conditions are met:
l Two devices use IKEv2.
l The remote device uses the internal IP address.
l Packets traverse the NAT device.
l The IP address is used for authentication.
The post-NAT IP address needs to be used as the remote address in this situation.
Step 7 Run ike-proposal proposal-number
An IKE proposal is referenced.
The IKE proposal must have been created.
By default, an IKE peer does not reference an IKE proposal

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 8 Configure identity authentication parameters.
Identity authentication parameters are different in different authentication modes. Configure

identity authentication parameters based on the authentication mode defined in an IKE
proposal.
l Pre-shared key authentication

a. Configure a pre-shared key for pre-shared key authentication.
You can use the following methods to configure the pre-shared key. When both of
the two methods are used, the pre-shared key configured in the IKE user table is
preferred.
n A single IKE peer or multiple IKE peers use the same ID and pre-shared key.
Run the pre-shared-key { simple | cipher } key command to configure a pre-
shared key.
The pre-shared key at the two ends must be the same.
n Multiple IKE peers use different IDs and pre-shared keys.
NOTE
○ In a point-to-multipoint scenario, the device functions as the VPN gateway of the

headquarters, an IPSec policy is created using an IPSec policy template, and the
VPN gateway receives IPSec connection setup requests of different branches.
When the pre-shared key is used for identity authentication and all branches use
the same ID and pre-shared key, there are security risks. That is, if the ID and pre-
shared key of one branch leak, the ID and pre-shared key of all branches leak. The
IKE user table can prevent this problem.
○ When the IKE user table is used, you do not need to use the remote-id-type
command subsequently.
1) Run quit
2) Run ike user-table user-table-id
An IKE user table is created and its view is displayed, or the view of an
existing IKE user table is displayed directly.
3) Run user user-name
An IKE user is created and its view is displayed, or the view of an
existing IKE user is displayed directly.
4) Run pre-shared-key key
The pre-shared key used by IKE peers is configured when IKE peers use
pre-shared key authentication during IKE negotiation.
By default, the pre-shared key used by IKE peers is not configured when
IKE peers use pre-shared key authentication during IKE negotiation.
5) Run id-type { any any-id | fqdn remote-fqdn | ip ipv4-address | user-
fqdn remote-user-fqdn }
The IKE user ID type and ID are configured.
By default, the IKE user ID type and ID are not configured.
The value of id-type is the remote ID.
When IKEv1 in main mode is used, the value of id-type must be set to ip.
In NAT traversal scenarios, ipv4-address should be set to the IP address
that is translated using NAT.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6) (Optional) Run interface-assign interface-type interface-number

An interface associated with the IKE user is assigned.
By default, no interface on the device is associated with the IKE user.
Currently, the interface can only be a tunnel interface.
The IKE user table in the headquarters contains multiple IKE users for
managing parameters for interconnection between the headquarters and
branches. If one IPSec profile in the headquarters is applied to multiple
tunnel interfaces, IPSec negotiation may fail because the IKE peer in the
headquarters fails to match the tunnel interface of each branch. In this
case, you can perform this step to assign an interface associated with an
IKE user.
7) (Optional) Run description description
The description of an IKE user is configured.
By default, the description of an IKE user is not configured.
8) Run quit
Return to the IKE user table view.
9) Run quit
10) Run ike peer peer-name
The IKE peer view is displayed.
11) Run user-table user-table-id
An IKE user table is reference in the IKE peer.
b. Configure the ID type and ID value.
For pre-shared key authentication, the local ID type or local ID on the local end
must be the same as the remote ID type or remote ID on the remote end. Configure
the ID type and ID value according to Table 6-9.
Table 6-9 Relationship between the local ID type, local ID, remote ID type, and
remote ID
Local ID Type Local ID Remote ID Remote ID
Type
FQDN Local name: FQDN remote-id device

local-id device
IP Local IP address: IP remote-address

10.1.1.3 10.1.1.3
User-FQDN Local user User-FQDN remote-id

domain name: devicea@exampl
local-id e.com
devicea@exampl
e.com
i. Run local-id-type { fqdn | ip | user-fqdn }

The local ID type used in IKE negotiation is set.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ii. (Optional) Run local-id id
The local ID used in IKE negotiation is set.
You need to configure the local ID when the ID type of an IKE peer is FQDN
or User-FQDN.
NOTE
○ When the local ID type is IP, you do not need to perform this step. In this case, the
device uses the IP address of the interface for establishing an IPSec tunnel as the local
ID by default. If the interface has multiple IP addresses, for example, primary and
secondary IP addresses are configured, the device uses the IP address configured by the
tunnel local command as the local ID.
○ You can also run the ike local-name local-name command in the system view to
configure the local ID during IKE negotiation. Then all IKE peers of the device use this
local ID for identity authentication.
○ The local ID configured by the local-id command takes precedence over the local ID
configured by the ike local-name command.
iii. Run remote-id-type { any | fqdn | ip | user-fqdn | none }
The remote ID type used in IKE negotiation is set.
By default, no remote ID type is set.
iv. (Optional) Run remote-id id
The remote ID used in IKE negotiation is set.
When the remote ID type is IP, the value configured by the remote-address
command is used as the remote ID by default, regardless of whether the
remote-id command is configured.
l RSA signature authentication
a. Configure the ID type and ID value.
For RSA signature authentication, the remote ID type or remote ID on the local end
must be consistent with corresponding fields in the local certificate on the remote
end. Configure the ID type and ID value according to Table 6-10.
Table 6-10 Relationship between the local ID type, local ID, remote ID type, and
remote ID
Local ID Type Local ID Remote ID Remote ID
Type
DN Subject: DN remote-id /
CN=devicea CN=devicea
FQDN DNS:devicea.exa FQDN remote-id

mple.com devicea.example.
com
IP Local IP address: IP remote-address

10.1.1.3 10.1.1.3
User-FQDN email: User-FQDN remote-id

devicea@exampl devicea@exampl
e.com e.com

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
i. (Optional) Run ikev2 authentication sign-hash { md5 | sha1 | sha2-256 |

sha2-384 | sha2-512 }
The certificate signature algorithm used by IKEv2 is configured.
By default, IKEv2 uses the certificate signature algorithm SHA1.
ii. Run rsa signature-padding { pkcs1 | pss }
A padding mode is configured for the RSA signature.
By default, the padding mode of the RSA signature is PKCS1.
iii. Run pki realm realm-name
The PKI domain that the digital certificate of the IKE peer belongs to is
specified. The local digital certificate is obtained based on the configuration of
the PKI domain.
If the authentication mode is RSA signature, the local certificate contains the
IP address, DN, name, and User-FQDN information about the local end.
iv. (Optional) Run local-id-reflect enable
During IKEv2 negotiation, the local ID of the responder is used as the remote
ID carried in the IKE packets sent by the initiator.
By default, this function is disabled.
During IKEv2 negotiation, if the user does not know the remote ID configured
for the initiator, you can perform this step on the responder. When the
responder receives an IKE packet from the initiator, the responder uses the IDr
payload (remote ID) in the received packet as its local ID. If the responder
does not obtain the IDr payload, it obtains its local ID based on the local
configuration.
Currently, the ID type can only be IP address, FQDN, or User-FQDN.
When both the local-id-reflect enable and local-id-preference certificate
enable commands are configured, the local-id-reflect enable command takes
effect.
v. (Optional) Run local-id-preference certificate enable
The device is enabled to preferentially obtain the local ID from a field in a
certificate when IKE uses certificate negotiation.
By default, the device does not preferentially obtain the local ID from a field
in a certificate when IKE uses certificate negotiation.
When IKE uses certificate negotiation, the device can obtain its local ID from
a field (IP address, FQDN, or email address) in the certificate, removing the
need to configure the local ID.
After this command is configured, the device preferentially obtains its local ID
from a field in the certificate. If this method fails, it obtains its local ID based
on the local configuration. If this method also fails, IKE negotiation fails.
vi. Run local-id-type { dn | fqdn | ip | user-fqdn }
The ID type is configured.
The specified ID type must be the same as that displayed in the display pki
certificate command output.
vii. (Optional) Run local-id id
The local ID used in IKE negotiation is set.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
You need to configure the local ID when the ID type of an IKE peer is FQDN
or User-FQDN.
viii. Run remote-id-type { any | dn | fqdn | ip | user-fqdn | none }
The remote ID type used in IKE negotiation is set.
By default, no remote ID type is set.
The local and remote ID types of an IKE peer must be the same.
ix. (Optional) Run remote-id id
The remote ID used in IKE negotiation is set.
If the remote ID type is IP, you do not need to configure the remote-id
command. In this case, the device uses the value specified by the remote-
address command as the remote ID by default.
NOTE
If the local ID type is FQDN or User-FQDN, the remote end uses the remote-id
specified in the IKE peer as the remote ID for IKEv1 negotiation. However, for IKEv2
negotiation, the remote end preferentially uses the value of the DNS (corresponding to
FQDN) or email (corresponding to User-FQDN) field in the certificate. If the fields are
unavailable, the remote end uses the remote-id specified in the IKE peer for
negotiation.
x. (Optional) Run inband ocsp
The device is configured to validate the remote certificate based on the OCSP
validation result sent from the remote device when IKEv2 uses RSA signature
authentication.
OCSP validation result sent from the remote device when IKEv2 uses RSA
signature authentication.
xi. (Optional) Run inband crl
The device is configured to validate the remote certificate based on the CRL
sent from the remote device when IKEv2 uses RSA signature authentication.
CRL sent from the remote device when IKEv2 uses RSA signature
authentication.
If both the inband ocsp and inband crl commands are run, the certificate is
considered valid only when the certificate verifications in OCSP and CRL
modes are passed.
xii. (Optional) Run ikev2 id-match-certificate enable
The device is enabled to check certificate identity information of the remote
device during IKEv2 certificate negotiation.
By default, the device does not check certificate identity information of the
remote device during IKEv2 certificate negotiation.
After this command is configured, the local device only checks the Subject
field, IP address, FQDN, or email of the remote device. If the information
differs from the ID (DN, IP address, FQDN, or User-FQDN) of the remote
device, IKEv2 negotiation fails.
xiii. (Optional) Run certificate-request empty-payload enable
The certificate request payload is empty.
By default, certificate request payloads carry CA information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When a template-based IPSec policy is configured for the Router in

headquarters and certificate-based authentication is used, you can run the
certificate-request empty-payload enable command to empty certificate
request payloads so that users who use different CA certificates in branch
offices can access the Router. Based on the certificate information about
branch offices, the Router obtains certificates from associated certificate
domains for authentication.
If the access devices cannot process certificate request packets with an empty
authentication and authorization field, do not configure this command.
Otherwise, tunnel negotiation fails.
Step 9 (Optional) Run lifetime-notification-message enable
The device is enabled to send IKE SA lifetime notification messages.
By default, the device does not send IKE SA lifetime notification messages.
IKEv1 peers negotiate the lifetime, and a smaller SA lifetime at the two ends is used. When a
Huawei device and a non-Huawei device establish an IPSec tunnel and they use different IKE
SA lifetimes, run this command to enable the device to send IKE SA lifetime notification
messages. By doing this, two ends can successfully perform IKE negotiation.
Step 10 (Optional) Run re-authentication interval interval
The IKEv2 re-authentication interval is set.
By default, IKEv2 does not perform re-authentication.
In remote access, IPSec peers periodically send re-authentication packets, which reduces
potential risks of attacks and improves IPSec network security.
----End
6.11.3 (Optional) Setting the IKE SA Lifetime
Context
After the SA lifetime is set, SAs are updated in real time and difficult to decipher, enhancing
security.
The IKE SA lifetime is classified as follows:

l Hard lifetime (hard timeout period): specifies the lifetime of an IKE SA.
When two devices negotiate an IKE SA, the actual hard lifetime is the smaller of the two
values configured on the two devices.
l Soft lifetime (soft timeout period): refers to the time after which a new IKE SA is
negotiated so that the new IKE SA will be ready before the hard lifetime of the original
IKE SA expires.

IKE Protocol Type Description
IKEv1 7/10 of the actual hard SA lifetime

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IKE Protocol Type Description
IKEv2 7/10 of the actual hard SA lifetime
Before an IKE SA becomes invalid, IKE negotiates a new IKE SA for the remote end. The
remote end uses the new IKE SA to protect IPSec communication immediately after the new
IKE SA is negotiated. If service traffic is transmitted, the original IKE SA is deleted
immediately. If no service traffic is transmitted, the original IKE SA will be deleted after 10s
or the hard lifetime expires.
Changing the lifetime does not affect the established IKE SAs, and the changed value is used
for establishing new IKE SAs in subsequent negotiation.
Procedure
Step 2 Run ike proposal proposal-number
The IKE proposal view is displayed.
Step 3 Run sa duration time-value
The IKE SA hard lifetime is set.
By default, the IKE SA lifetime is 86400s.
If the hard lifetime ends, IKE SAs are updated automatically. IKE negotiation involves Diffie-
Hellman key calculation, which takes a long period of time. To ensure that IKE SA update
does not affect secure communication, you are advised to set the lifetime to a value greater
than 600s.
----End
6.11.4 (Optional) Configuring IKE Peer Status Detection
Context
IKE does not provide peer status detection. In IPSec communication, if one end becomes
faulty, the other end may not detect the fault because of system failures and continues to send
IPSec packets to the faulty end. The problem can be solved only when the SA lifetime ends.
Before the SA lifetime ends, the SA between IKE peers exists, causing traffic loss.
Unreachability of an IKE peer can result in black holes where traffic is discarded. IPSec
communication can be restored rapidly only when black holes are identified and detected in a
timely manner.
The device provides heartbeat detection and dead peer detection (DPD) to detect the IKE peer
status. Configure heartbeat detection or DPD as needed.
6.11.4.1 (Optional) Configuring Heartbeat Detection

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
Heartbeat detection enables the local end to periodically send heartbeat packets to the remote
end. If the local end does not receive heartbeat packets within the timeout interval, the local
end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between
IKE peers.
There are limitations on heartbeat detection:

l Enabling heartbeat detection will consume CPU resources used to process IKE keepalive
messages, so the number of established IPSec sessions is limited.
l There are no uniform standards, so devices from different vendors may fail to interwork.
The interval at which heartbeat packets are sent at the local end must be used with the timeout
interval of heartbeat packets at the remote end. If the remote end does not receive any
heartbeat packet within the timeout interval and the IKE SA carries a timeout tag, the IKE SA
and its corresponding IPSec SA are deleted. If the IKE SA does not carry a timeout tag, it is
marked as timeout.
NOTE
If IKE peers use IKEv1 during negotiation, the device supports heartbeat detection. If IKE peers use
IKEv2 during negotiation, the device does not support heartbeat detection.
Procedure
Step 2 Run ike heartbeat { seq-num { new | old } | spi-list }
Parameters of heartbeat packets are set.
By default, a heartbeat packet uses old type sequence number mechanism and does not carry
the SPI list.
Step 3 Run ike heartbeat-timer interval interval
The interval at which heartbeat packets are sent by an IKE SA is set.
By default, an IKE SA does not send heartbeat packets.
Step 4 Run ike heartbeat-timer timeout seconds
The timeout interval of heartbeat packets is set.
By default, the timeout interval during which an IKE SA waits for a heartbeat packet is not
configured.
When ike heartbeat-timer interval is configured at one end, the ike heartbeat-timer
timeout command must be used at the other end.
The timeout interval of heartbeat packets must be longer than the interval at which heartbeat
packets are sent. Generally, packet loss does not occur for more than three consecutive times
on a network. Therefore, it is recommended that the timeout interval of heartbeat packets be
three times the interval at which heartbeat packets are sent.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.11.4.2 (Optional) Configuring DPD
Context
In IPSec communication, heartbeat detection technology detects faults at the remote end and
prevents packet loss. However, periodically sending heartbeat messages consumes CPU
resources at both ends and limits the number of established IPSec sessions.
Dead Peer Detection (DPD) technology sends DPD packets based on IPSec packets between
IKE peers, and does not periodically send heartbeat packets. When the local end can receive
IPSec traffic from the remote end, the local end considers the remote end as active. The local
end sends DPD packets to detect the status of the remote end when the local end does not
receive IPSec traffic from the remote end within a given period of time. If the local end does
not receive response packets after sending DPD packets several times, the local end considers
the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.
If heartbeat detection is used, the two ends periodically send heartbeat packets and settings at
the two ends must match. If DPD is used, settings except the payload sequence in DPD
packets at the two ends do not need to match. When IPSec packets are exchanged between
IKE peers, DPD packets are not sent. DPD packets are sent only when one end does not
receive IPSec packets from the other end in a period of time. This saves resources.
NOTE
When both heartbeat detection and DPD are used, DPD takes effect.
When the configured DPD detection parameters do not match the end, the device restarts IKE negotiation
after the DPD probe fails, which affects the performance of the end device.
The detection mode and DPD are configured based on the dpd type or ike dpd type
command. Two DPD modes are available:
l On-demand DPD
When the local end needs to send IPSec packets to the remote end, the local end
determines that the DPD idle time is reached and sends a DPD request packet to the
remote end.
l Periodic DPD
The local end determines that the DPD idle time is reached, and periodically sends a
DPD request packet to the remote end based on the DPD idle time.
If the local end does not receive a DPD response packet from the remote end within the DPD
packet retransmission interval, the local end retransmits the DPD request packet. If the local
end still does not receive a DPD response packet after the DPD packet retransmission count is
reached, the local end considers that the remote end goes offline, and deletes the IKE SA and
IPSec SA.
Procedure
1. Run system-view
2. Run ike peer peer-name
3. (Optional) Run dpd msg { seq-hash-notify | seq-notify-hash }
The sequence of the payload in DPD packets is configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, the sequence of the payload in DPD packets is seq-notify-hash.

The two ends must use the same sequence of the payload in DPD packets; otherwise,
DPD does not take effect.
4. (Optional) Run dpd msg notify-hash-sequence learning
Automatic learning of the payload sequence of DPD packets is enabled.
By default, automatic learning of the payload sequence of DPD packets is enabled.
After this command is configured, when the local end receives a DPD packet from the
remote end, the local end learns the payload sequence of the DPD packet and sends a
DPD packet in the same payload sequence.
NOTE
5. Run dpd { idle-time interval | retransmit-interval interval | retry-limit times }
The DPD idle time, DPD packet retransmission interval, and maximum number of DPD
packet retransmissions are set.
By default, the DPD idle time is 30s, the DPD packet retransmission interval is 15s, and
the maximum number of DPD packet retransmissions is 3.
6. Run dpd type { on-demand | periodic }
The on-demand or periodic DPD mode is configured.
By default, the DPD mode is not configured on an IKE peer.
7. Run dpd packet receive if-related enable
The function that checks whether the interface that receives DPD packets is the interface
that establishes an IPSec SA is enabled.
By default, the function that checks whether the interface that receives DPD packets is
the interface that establishes an IPSec SA is disabled.
When IPSec policies with different names and the same parameters have been applied to
multiple interfaces of the device, the interface that receives encrypted traffic is not the
interface that establishes an IPSec SA during an interface switchover. If you want the
two interfaces to be the same, run the dpd packet receive if-related enable command to
enable the function that checks whether the interface that receives DPD packets is the
interface that establishes an IPSec SA. If the two interfaces are different, DPD packets
are discarded and the DPD detection result becomes abnormal. This causes the IPSec SA
to be deleted and triggers IKE re-negotiation.
This function applies only to the scenario where IPSec policies have been applied to
physical interfaces.
NOTE
6.11.5 (Optional) Configuring an Identity Filter Set
Context
l When a device functions as a responder during IKE negotiation, it can specify the peer
allowed to connect to it to improve security.
An IPSec policy template or an IPSec profile specifies the peer based on the identity
filter set.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 6-39, the headquarters gateway RouterC functions as the responder.
An IPSec policy template is configured on RouterC, only RouterA matches the IP
address in the identity filter set.
Figure 6-39 Responder specifying a qualified initiator

RouterA
Branch A
gateway ike identity
ip address 60.1.1.1 255.255.255.0
Branch A IPSe
c Tun
nel
RouterC
Headquarters
GE0/0/1 gateway
60.1.1.1/24 GE0/0/1
60.1.3.1/24
GE0/0/1
60.1.2.1/24
Headquarters
Branch B
RouterB
Branch B
gateway
l In an IPSec over DSVPN application, multiple mGRE tunnel interfaces are configured
on the hub which provides only one IP address for spoke access. The mGRE tunnel
interfaces use the same source address or source interface. To solve this problem, set
parameters in the identity filter set to specify the mGRE tunnel interface of each IKE
packet.
For the detailed configuration of DSVPN, see DSVPN Configuration.
In a DSVPN application as shown in Figure 6-40, Spoke1 and Spoke2 belong to
DSVPN 1, while Spoke3 and Spoke4 belong to DSVPN 2. Spoke1 wants to
communicate with Spoke2, and Spoke3 wants to communicate with Spoke4. However,
the hub provides only one public network IP address for spokes access. After you
configure an identity filter set on the hub, it determines the mGRE tunnel interface of
each spoke based on parameters in the identity filter set.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-40 Responder specifying a qualified initiator in the IPSec over DSVPN
application
ike identity identity1

fqdn Spoke1
fqdn Spoke2
HQ ike identity identity2
fqdn Spoke3
Hub fqdn Spoke4
172.10.1.1/24 172.10.2.1/24
172.10.1.2/24 Tunnel0/0/0 Tunnel0/0/0 172.10.2.3/24
172.10.1.3/24 172.10.2.2/24
Spoke1 Spoke2 Spoke3 Spoke4
Branch 1 Branch 2 Branch 3 Branch 4
DSVPN 1
DSVPN 2
Procedure
Step 2 Run ike identity identity-name
The identity filter set view is displayed.
NOTE
You can set one or more parameters in the identity filter set view, depending on the device specification.
Step 3 (Optional) Run dn name
The DN of an allowed peer for IKE negotiation is configured.
By default, no DN of allowed peer for IKE negotiation is configured.
Step 4 (Optional) Run ip address ip-address { mask | mask-length }
The IP address of an allowed peer for IKE negotiation is configured.
By default, no IP address of allowed peer for IKE negotiation is configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 5 (Optional) Run fqdn fqdn-name

The name of an allowed peer for IKE negotiation is configured.
By default, no name of allowed peer for IKE negotiation is configured.
Step 6 (Optional) Run user-fqdn fqdn-name
The domain name of an allowed peer for IKE negotiation is configured.
By default, no domain name of allowed peer for IKE negotiation is configured.
----End
Follow-up Procedure
Run the match ike-identity identity-name command in the ipsec policy template view or
IPSec profile view to reference the identity filter set.
6.11.6 (Optional) Configuring DSCP Priority for IKE Packets

Context
IKE packets are used to negotiate IKE SAs and IPSec SAs or used for Deal Peer Detection
(DPD). If IKE packets are lost during transmission, problems such as failures to negotiate
IKE SAs and IPSec SAs may occur. As a result, packets cannot be protected by IPSec SAs.
To solve these problems, ensure that network devices process IKE packets before service
packets.
You can increase IKE packet priority by specifying the DSCP priority for IKE packets. This
configuration ensures that IKE packets are processed in time on a busy network, improving
transmission reliability of IKE packets.
You can configure the DSCP priority for IKE packets globally or on an IKE peer. The DSCP
priority configured on an IKE peer takes precedence over that configured globally. When the
DSCP priority is not configured on an IKE peer, the DSCP priority configured globally takes
effect.
Procedure
l Configure the DSCP priority globally.
a. Run system-view
b. Run ike dscp dscp-value
The DSCP priority of IKE packets is configured globally.
By default, the global DSCP priority of IKE packets is 0.
l Configure the DSCP priority on an IKE peer.
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
c. Run dscp dscp-value

The DSCP priority of IKE packets is configured on the IKE peer.
By default, the DSCP priority of IKE packets on a specified IKE peer is 0.
----End
6.11.7 (Optional) Configuring NAT Traversal
Context
During IPSec VPN deployment, the initiator on a private network may need to establish an
IPSec tunnel with the responder on a public network. To ensure that an IPSec tunnel can be
established when a network address translation (NAT) device exists, NAT traversal is
required, as shown in Figure 6-41.
Figure 6-41 NAT traversal in IPSec

NAT gateway
RouterA IPSec Tunnel RouterB

Public
network
Private
network
Authentication Header (AH) integrity check involves the hash calculation for IP packets
including the IP address, whereas NAT changes the IP address and causes the hash value
change. Packets on the IPSec tunnel that has AH enabled cannot traverse a NAT device.
During Encapsulating Security Payload (ESP) integrity check, an outer IP header is not
checked. If only address translation is performed, ESP can work properly. ESP is a Layer 3
protocol and does not support port setting, so there is also a problem in ESP when NAT port
translation is used. To address this issue, NAT traversal encapsulates ESP packets with a UDP
header. In transport mode, a standard UDP header is inserted between the original IP header
and an ESP header during NAT traversal. In tunnel mode, a standard UDP header is inserted
between the new IP header and an ESP header during NAT traversal. When ESP packets pass
through a NAT device, the NAT device translates the IP address and port number of the outer
IP header and inserted UDP header. After the translated packets reach the remote end of the
IPSec tunnel, the remote end processes these packets in the same manner as IPSec packets.
If no IPSec packets are transmitted on an IPSec tunnel in a period of time, NAT session
entries may be aged out and deleted because the NAT session entries have the keepalive time.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As a result, the IPSec tunnel cannot transmit IPSec packets between the NAT device and the
IKE peer connected to the public network. To prevent NAT session entries from being aged,
an IKE SA on the private network side of the NAT device sends NAT Keepalive packets to its
remote end at an interval to maintain the NAT session.
NOTE
If NAT traversal is enabled, the IPSec proposal referenced using the ipsec proposal command supports
only ESP. AH authenticates the entire IP packet. Any modification in the IP header causes an AH check
failure. Therefore, NAT traversal cannot be implemented on an IPSec tunnel protected by AH.
Procedure
Step 3 Run nat traversal
NAT traversal is enabled.
By default, the NAT traversal is enabled.
Step 4 Run quit
Step 5 Run ipsec nat-traversal source-port port-number
The UDP port number for IPSec NAT traversal is configured.
By default, the UDP port number for IPSec NAT traversal is 4500.
Step 6 Run ike nat-keepalive-timer interval interval
The interval for sending Keepalive packets is set.
By default, the interval for sending NAT Keepalive packets is 20 seconds.
----End
6.11.8 (Optional) Configuring IPSec VPN Multi-instance

Context
When multiple branches connected to the headquarters network across the Internet using
IPSec, you can configure IPSec VPN Multi-instance, thereby isolating traffic of different
branches.
You can use the following two modes to configure a VPN instance that IPSec tunnel traffic
belongs to according to the IKE negotiation mode:
l Binding a VPN instance in SA mode
l Binding a VPN instance in IKE user mode
When a VPN instance is bound to traffic in SA mode, the device determines the VPN instance
to which site traffic passing through the IPSec tunnel belongs by the user type, isolating traffic

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
from different sites. A VPN instance bound in SA mode has a higher priority than a VPN
instance bound in IKE user mode.
NOTE
The configuration takes effect only on the initiator of an IPSec tunnel. The initiator needs to obtain the
outbound interface when sending packets. The packets received by the remote peer contain the VPN
attribute, so the remote peer can still receive packets when no VPN is specified for it.
Procedure
l Binding a VPN instance in SA mode
a. Run system-view
c. Run sa binding vpn-instance vpn-instance-name
A VPN instance that IPSec tunnel traffic belongs to is specified.
By default, a VPN instance that IPSec tunnel traffic belongs to is not configured.
The VPN instance has been created using the ip vpn-instance command and the route
distinguisher (RD) has been configured for the VPN instance using the route-
distinguisher command.
The specified VPN instance must be the same as the VPN instance bound to the ACL
rule that is referenced by the 6.7.3 Configuring an IPSec Policy.
l Binding a VPN instance in IKE user mode
a. Run system-view
b. Run ike user-table user-table-id
An IKE user table is created and its view is displayed, or the view of an existing
IKE user table is displayed directly.
c. Run user user-name
An IKE user is created and its view is displayed, or the view of an existing IKE user
is displayed directly.
d. Run vpn-instance-traffic { public | name vpn-instance-name }
A VPN instance corresponding to user traffic of the IKE user table is configured.
By default, the VPN instance corresponding to user traffic of the IKE user table is
not configured.
The VPN instance has been created using the ip vpn-instance command and the
route distinguisher (RD) has been configured for the VPN instance using the route-
distinguisher command.
The specified VPN instance must be the same as the VPN instance bound to the
ACL rule that is referenced by the 6.7.3 Configuring an IPSec Policy.
e. Run quit
Return to the IKE user table view.
f. Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
g. Run ike peer peer-name

h. Run user-table user-table-id
An IKE user table is reference in the IKE peer.
----End
6.11.9 (Optional) Configuring Network Resource Delivery
Context
resources of branches.
1. If an Efficient VPN policy in client or network-plus mode is used, the Efficient VPN
server delivers an IP address to the remote device. The remote device then uses this IP
address to establish an IPSec tunnel with the Efficient VPN server.
2. The Efficient VPN server delivers network resources including the DNS domain name,
DNS server IP address, and WINS server IP address so that the branch can access server
resources on the headquarters network.
Procedure
Step 3 Run service-scheme service-scheme-name
A service scheme is bound to the IKE peer.
By default, no service scheme is bound to an IKE peer.
service-scheme-name specifies a service scheme that has been created using the service-
scheme (AAA view) command.
----End
Follow-up Procedure
Configure an Efficient VPN policy and reference the IKE peer on the Efficient VPN server so
that the IP address, DNS domain name, DNS server IP address, and WINS server IP address
can be delivered to the branch gateway.
6.11.10 (Optional) Configuring ACL Delivery

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
NOTE
Only IKEv1 supports ACL delivery.
resources for the branches.
The Efficient VPN server delivers headquarters network information defined in an ACL to the
remote device. The ACL defines the headquarters subnets that branches can access. Traffic
not destined for the subnets specified in the ACL is directly forwarded to the Internet. Such
traffic does not pass through the IPSec tunnel.
Procedure
Step 3 Run resource acl acl-number
An ACL is created to define subnet information about the headquarters in the Efficient VPN.
By default, no ACL is created to define subnet information about the headquarters in the
Efficient VPN.
acl-number is an advanced ACL.
The sum of ACL rules pushed by the headquarters and ACL rules configured on the branch
cannot exceed 512. Otherwise, the IPSec tunnels cannot be established.
----End
Follow-up Procedure
Configure an Efficient VPN policy and reference the IKE peer on the Efficient VPN server to
implement ACL delivery.
6.11.11 (Optional) Enabling Dependency Between IPSec SA and

IKE SA During IKEv1 Negotiation
Context
By default, no dependency exists between IPSec SA and IKE SA, that is, the two SAs can be
deleted separately. If the IKE SA is deleted but the corresponding IPSec SA still exists, traffic
forwarding will be effected. You can enable dependency between IPSec SA and IKE SA to
ensure that an IPSec SA is deleted when its corresponding IKE SA is deleted.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The system supports two configuration modes: global configuration and configuration on an
IKE peer. Parameters configured on an IKE peer take precedence over those configured
globally. When parameters are not configured on an IKE peer, the global parameter settings
take effect.
Procedure
l Global configuration
a. Run system-view

b. Run ikev1 phase1-phase2 sa dependent
Dependency between IPSec SA and IKE SA during IKEv1 negotiation is enabled.
By default, no dependency exists between IPSec SA and IKE SA during IKEv1

negotiation.
l Configuration on an IKE peer
a. Run system-view

An IKE peer view is displayed.

c. Run ikev1 phase1-phase2 sa dependent
Dependency between IPSec SA and IKE SA during IKEv1 negotiation is enabled.
By default, no dependency exists between IPSec SA and IKE SA during IKEv1

negotiation.
NOTE
----End
6.11.12 (Optional) Configuring Rapid Switchover and Revertive

Switching of an IKE Peer
Context
To improve network reliability, two devices can be deployed at the headquarters to connect to
the branch gateway. In an IPSec policy, two IP addresses or domain names of the remote IKE
peer can be configured on the branch gateway. The branch gateway first attempts to use the
first configured IP address or domain name to establish an IKE connection with the
headquarters gateway. If establishing an IKE connection fails or the dead peer detection
(DPD) fails, the branch gateway uses the second IP address or domain name to establish an
IKE connection.
If the IP address of the first IKE peer is unreachable in the scenario that two IP addresses are
configured, the branch gateway uses the second IP address to establish an IKE connection
only when establishing an IKE connection fails or DPD fails. It takes a long time, and traffic
cannot be switched back to the faulty gateway when it recovers.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
You can use the Network Quality Analysis (NQA) or Bidirectional Forwarding Detection
(BFD) to detect the status of the IP address of an IKE peer and to make sure whether the IP
address of the IKE peer is valid according to the detection result. When the IP address of one
IKE peer is invalid, the traffic can be quickly switched to another IKE peer. This ensures that
when one headquarters gateway fails, the traffic can be quickly switched to another
headquarters gateway. You can also configure revertive switching of an IKE peer to ensure
that traffic can be switched back to the originally restored headquarters gateway.
Prerequisites
l If the NQA test instance status is used to determine whether the remote address of an
IKE peer is valid, ensure that the NQA test instance has been created. The device
supports only association between IPSec and NQA of ICMP type. For details on how to
configure an NAQ test instance of ICMP type, see Configuring an ICMP Test Instance.
l If the BFD session instance status is used to determine whether the remote address of an
IKE peer is valid, ensure that the BFD session has been created. For details on how to
configure a BFD session, see Configuring Single-Hop BFD.
Procedure
Step 3 Run remote-address [ vpn-instance vpn-instance-name ] { ip-address | host-name host-

name } track { nqa admin-name test-name | bfd-session session-name } { up | down }
The device is configured to determine whether the remote address of an IKE peer is valid
according to the NQA test instance or BFD session status.
By default, the device is configured to not determine whether the remote address of an IKE
peer is valid according to the NQA test instance or BFD session status.
Step 4 (Optional) Run switch-back enable
Revertive switching is enabled for the IKE peer.
By default, revertive switching of an IKE peer is disabled.
----End
6.11.13 (Optional) Disabling Validity Verification on Certificates
Context
When IPSec uses certificate authentication, users cannot update certificates after they become
invalid, leading to unavailable certificates and IPSec authentication failure. If users still want
to use invalid certificates, you can disable validity verification on certificates.
You can disable validity verification on certificates in the system view or IKE peer view. If
you disable validity verification on certificates in the system view, the device does not verify
certificates of all IKE peers.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l System view
a. Run system-view

b. Run ike certificate-check disable
The device is configured not to verify certificates of all IKE peer.
By default, the device verifies certificates of all IKE peer.

l IKE peer view
a. Run system-view


c. Run certificate-check disable
The device is configured not to verify certificates of an IKE peer.
By default, the device verifies certificates of an IKE peer.
----End
6.11.14 (Optional) Configuring IKEv2 Packet Fragmentation
Context
During IKEv2 negotiation, if the length of an encrypted IKEv2 packet exceeds the MTU of
the outbound interface of the device, the device fragments the IKEv2 packet for transmission.
However, some network devices (such as firewalls and NAT devices) do not permit UDP
fragments because of attack defense. As a result, IKEv 2 fragments are discarded and IKEv2
negotiation between the IKE peers fails. In this case, you need to configure IKEv2 packet
fragmentation so that the IKEv2 packet longer than the MTU specified by mtu-size is
fragmented before being encrypted. This configuration prevents the encrypted IKEv2 packet
from being fragmented before transmission.
Procedure
Step 3 Run ikev2 fragmentation [ mtu mtu-size ]
IKEv2 packet fragmentation is enabled.
By default, IKEv2 packet fragmentation is disabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IKEv2 packet fragmentation must be enabled on both ends. Otherwise, this function does not
take effect.
----End
6.11.15 (Optional) Disabling the Function of Instructing the Peer

Device to Delete the Old Child SA
Context
In an IKEv2 scenario, when the local device deletes the child SA and initiates IKEv2
negotiation to the peer device again, the default negotiation message carries the
IKEV2_NOTIFY_DELETE_OLD_CHILDSA payload, instructing the peer device to delete
the old child SA. If the peer device does not support the processing of this payload, IKEv2
negotiation between the two ends fails. To prevent this problem, disable the local device from
instructing the peer device to delete the old child SA so that the IKEv2 negotiation message
does not carry this payload.
NOTE
Procedure
Step 2 Run undo ikev2 delete old child-sa enable
The function of instructing the peer device to delete the old child SA is disabled.
By default, the function of instructing the peer device to delete the old child SA is enabled.
----End
6.11.16 Verifying the IKE Configuration

Prerequisites
The IKE configurations are complete.
Procedure
l Run the display ike identity [ name identity-name ] command to check information
about an identity filter set.
l Run the display ike peer [ brief | name peer-name ] command to check IKE peer
information.
l Run the display ike proposal [ number proposal-number ] command to check
parameters in the IKE proposal.
l Run the display ike sa [ remote ipv4-address ] command to check brief information
about IKE SAs.
l Run the display ike sa [ remote-id-type remote-id-type ] remote-id remote-id command
to check brief information about IKE SAs based on the remote ID.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ike sa verbose { remote ipv4-address | connection-id connection-id |

[ remote-id-type remote-id-type ] remote-id remote-id } command to check detailed
information about IKE SAs.
l Run the display ike global config command to check global IKE configuration.
l Run the display ike user-table [ number user-table-id [ user-name user-name ] ]
command to check IKE user table information.
----End
6.12 Maintaining IPSec
6.12.1 Monitoring the IPSec Running Status
Prerequisites
All IPSec configurations are complete.
In routine maintenance, you can run the following commands in any view to check whether
IPSec is functioning properly.
Procedure
about IKE SAs.
l Run the display ipsec p2mp-sa-statistics command to check statistics on P2MP SA
packets.
NOTE
l Run the display ipsec history record [ remote-address remote-address ] command to
check history information about IPSec tunnels.
l Run the display ipsec statistics [ tunnel-number ] command to check IPSec packet
statistics.
l Run the display ike statistics { v1 | v2 } command to check IKE statistics.
l Run the display ikev2 statistics { eap | error | notify-info | packet | sa } command to
check statistics on IPSec tunnels negotiated using IKEv2.
l Run the display ipsec statistics route command to check IPSec route injection statistics.
l Run the display ike error-info [ verbose ] [ peer remote-address ] command to check
information about IPSec tunnel negotiation failures using IKE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ike offline-info [ peer remote-address ] command to check information
about deleted IPSec tunnels established through IKE negotiation.
----End
6.12.2 Clearing IPSec Statistics

Context
Statistics cannot be restored after being cleared. Exercise caution when you run the reset
commands.
When the number of IPSec tunnels is larger than 50% of the maximum limit, high CPU usage
alarms may be generated in a short period of time after the reset ipsec sa or reset ike sa
command is run. After all the SAs are cleared, the CPU usage restores to the normal range.
Procedure
l Run the reset ipsec sa [ remote ipv4-address | policy policy-name [ seq-number ] |
parameters ipv4-address { ah | esp } spi | efficient-vpn efficient-vpn-name | profile
profile-name ] command in the user view to clear established SAs.
l Run the reset ipsec sa efficient-vpn efficient-vpn-name command in the user view to
clear SAs established using an Efficient VPN policy.
l After confirming information to be cleared, run the reset ipsec p2mp-sa command in the
user view to clear IPSec P2MP SA.
NOTE
l Run the reset ipsec statistics command in the user view to clear statistics about IPSec
packets.
l After confirming information to be cleared, run the reset ipsec p2mp-sa-statistics
command in the user view to clear statistics on IPSec P2MP SA packets.
NOTE
l Run the reset ike error-info command in the user view to clear information about IPSec
tunnel negotiation failures using IKE.
l Run the reset ike offline-info command in the user view to clear information about
deleted IPSec tunnels established through IKE negotiation.
l Run the reset ike sa [ conn-id conn-id | remote [ ipv4-address ] ] command in the user
view to clear the SA established using IKE.
l Run the reset ike statistics command in the user view to clear statistics about IKE
packets.
l Run the reset ipsec history record command in the user view to clear history
information about IPSec tunnels.
l Run the reset ipsec statistics route command in the user view to clear IPSec route
injection statistics.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13 Configuration Examples for IPSec
6.13.1 Example for Manually Establishing an IPSec Tunnel
As shown in Figure 6-42, RouterA (branch gateway) and RouterB (headquarters gateway)
communicate through the Internet. The branch subnet is 10.1.1.0/24 and the headquarters
subnet is 10.1.2.0/24.
The enterprise wants to protect data flows between the branch subnet and the headquarters
subnet. An IPSec tunnel can be manually set up between the branch gateway and headquarters
gateway because they communicate over the Internet and only a few branches gateway need
to be maintained.
Figure 6-42 Manually establishing an IPSec tunnel
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
Branch gateway Headquarter gateway
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24
10.1.2.2/24
Branch subnet Headquarters subnet
1. Configure IP addresses and static routes for interfaces on RouterA and RouterB so that
routes between RouterA and RouterB are reachable.
2. Configure ACLs to define data flows to be protected.
3. Configure IPSec proposals to define the method used to protect IPSec traffic.
4. Configure IPSec policies and reference ACLs and IPSec proposals in the IPSec policies
to determine the methods used to protect data flows.
5. Apply IPSec policy groups to interfaces.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA and RouterB.
# Assign an IP address to an interface on RouterA.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure a static route to the peer on RouterA. This example assumes that the next hop
address in the route to RouterB is 1.1.1.2.
# Assign an IP address to an interface on RouterB.

# Configure a static route to the peer on RouterB. This example assumes that the next hop
address in the route to RouterA is 2.1.1.2.
[RouterB] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure ACLs on RouterA and RouterB to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 10.1.1.0/24 to 10.1.2.0/24.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[RouterA-acl-adv-3101] quit
# Configure an ACL on RouterB to define data flows sent from 10.1.2.0/24 to 10.1.1.0/24.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[RouterB-acl-adv-3101] quit
Step 3 Create IPSec proposals on RouterA and RouterB.

# Create an IPSec proposal on RouterA.
[RouterA] ipsec proposal tran1
[RouterA-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[RouterA-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[RouterA-ipsec-proposal-tran1] quit
# Create an IPSec proposal on RouterB.

[RouterB] ipsec proposal tran1
[RouterB-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[RouterB-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[RouterB-ipsec-proposal-tran1] quit
Run the display ipsec proposal command on RouterA and RouterB to view the IPSec
proposal configuration.
Step 4 Create IPSec policies on RouterA and RouterB.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Manually create an IPSec policy on RouterA.

[RouterA] ipsec policy map1 10 manual
[RouterA-ipsec-policy-manual-map1-10] security acl 3101
[RouterA-ipsec-policy-manual-map1-10] proposal tran1
[RouterA-ipsec-policy-manual-map1-10] tunnel remote 2.1.1.1
[RouterA-ipsec-policy-manual-map1-10] tunnel local 1.1.1.1
[RouterA-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[RouterA-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
[RouterA-ipsec-policy-manual-map1-10] sa string-key outbound esp cipher huawei
[RouterA-ipsec-policy-manual-map1-10] sa string-key inbound esp cipher huawei
[RouterA-ipsec-policy-manual-map1-10] quit
# Manually create an IPSec policy on RouterB.

[RouterB] ipsec policy use1 10 manual
[RouterB-ipsec-policy-manual-use1-10] security acl 3101
[RouterB-ipsec-policy-manual-use1-10] proposal tran1
[RouterB-ipsec-policy-manual-use1-10] tunnel remote 1.1.1.1
[RouterB-ipsec-policy-manual-use1-10] tunnel local 2.1.1.1
[RouterB-ipsec-policy-manual-use1-10] sa spi outbound esp 54321
[RouterB-ipsec-policy-manual-use1-10] sa spi inbound esp 12345
[RouterB-ipsec-policy-manual-use1-10] sa string-key outbound esp cipher huawei
[RouterB-ipsec-policy-manual-use1-10] sa string-key inbound esp cipher huawei
[RouterB-ipsec-policy-manual-use1-10] quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations
of the IPSec policies.
Step 5 Apply IPSec policy groups to interfaces on RouterA and RouterB.
# Apply the IPSec policy group to the interface of RouterA
[RouterA-GigabitEthernet1/0/0] ipsec policy map1
# Apply the IPSec policy group to the interface of RouterB.

[RouterB-GigabitEthernet1/0/0] ipsec policy use1

# After the configurations are complete, PC A can ping PC B successfully. You can run the
display ipsec statistics command to view packet statistics.
# Run the display ipsec sa command on RouterA and RouterB to view the IPSec
configuration. The display on RouterA is used as an example.
[RouterA] display ipsec sa
===============================
Interface: GigabitEthernet1/0/0
===============================
-----------------------------
IPSec policy name: "map1"
Sequence number: 10
Acl group: 3101
Acl rule: -
Mode: Manual
-----------------------------
Tunnel local : 1.1.1.1
Tunnel remote : 2.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Outbound ESP SAs]

SPI: 12345 (0x3039)
No duration limit for this SA
[Inbound ESP SAs]

SPI: 54321 (0xd431)
No duration limit for this SA
Anti-replay : Disable
----End
Configuration Files
#
sysname RouterA
#
acl number 3101
#
ipsec proposal tran1
#
ipsec policy map1 10 manual
security acl 3101
proposal tran1
tunnel local 1.1.1.1
tunnel remote 2.1.1.1
sa spi inbound esp 54321
sa string-key inbound esp cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!
%^%#
sa spi outbound esp 12345
sa string-key outbound esp cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj
%5W5=)%^%#
#
ip address 1.1.1.1 255.255.255.0
ipsec policy map1
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
#
return

#
sysname RouterB
#
acl number 3101
#
#
ipsec policy use1 10 manual
security acl 3101
proposal tran1
tunnel local 2.1.1.1
tunnel remote 1.1.1.1
sa spi inbound esp 12345
sa string-key inbound esp cipher %^%#IRFGEiFPJ1$&a'Qy,L*XQL_+*Grq-

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
=yMb}ULZdS6%^%#
sa spi outbound esp 54321
sa string-key outbound esp cipher %^%#(3fr1!&6O=)!GN#~{)n,2fq>4#4+
%;lMTs5(]:c)%^%#
#
ip address 2.1.1.1 255.255.255.0
ipsec policy use1
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
#
return
6.13.2 Example for Establishing an IPSec Tunnel in IKE

Negotiation Mode Using Default Settings
subnet is 10.1.2.0/24.
subnet. An IPSec tunnel can be set up between the branch gateway and headquarters gateway
because they communicate over the Internet.
Figure 6-43 Establishing an IPSec tunnel in IKE negotiation mode using default settings
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24
10.1.2.2/24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4. Configure IKE peers to define IKE negotiation attributes.

Procedure

10.1.2.0 0.0.0.255
10.1.1.0 0.0.0.255


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


Step 4 Configure IKE peers on RouterA and RouterB.
# Configure an IKE proposal on RouterA.

[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-128
[RouterA-ike-proposal-5] authentication-algorithm sha2-256
[RouterA-ike-proposal-5] dh group14
[RouterA-ike-proposal-5] quit
# Configure an IKE peer on RouterA and set the pre-shared key and remote ID according to
default settings.
[RouterA] ike peer spub
[RouterA-ike-peer-spub] undo version 2
[RouterA-ike-peer-spub] ike-proposal 5
[RouterA-ike-peer-spub] pre-shared-key cipher huawei@123
[RouterA-ike-peer-spub] remote-address 2.1.1.1
[RouterA-ike-peer-spub] quit
# Configure an IKE proposal on RouterB.

[RouterB] ike proposal 5
[RouterB-ike-proposal-5] encryption-algorithm aes-128
[RouterB-ike-proposal-5] authentication-algorithm sha2-256
[RouterB-ike-proposal-5] dh group14
[RouterB-ike-proposal-5] quit
# Configure an IKE peer on RouterB and set the pre-shared key and remote ID according to
default settings.
[RouterB] ike peer spua
[RouterB-ike-peer-spua] undo version 2
[RouterB-ike-peer-spua] ike-proposal 5
[RouterB-ike-peer-spua] pre-shared-key cipher huawei@123
[RouterB-ike-peer-spua] remote-address 1.1.1.1
[RouterB-ike-peer-spua] quit
# Create an IPSec policy in IKE negotiation mode on RouterA.

[RouterA] ipsec policy map1 10 isakmp
[RouterA-ipsec-policy-isakmp-map1-10] ike-peer spub
[RouterA-ipsec-policy-isakmp-map1-10] proposal tran1
[RouterA-ipsec-policy-isakmp-map1-10] security acl 3101
[RouterA-ipsec-policy-isakmp-map1-10] quit
# Create an IPSec policy in IKE negotiation mode on RouterB.

[RouterB] ipsec policy use1 10 isakmp
[RouterB-ipsec-policy-isakmp-use1-10] ike-peer spua
[RouterB-ipsec-policy-isakmp-use1-10] proposal tran1
[RouterB-ipsec-policy-isakmp-use1-10] security acl 3101
[RouterB-ipsec-policy-isakmp-use1-10] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA-GigabitEthernet1/0/0] ipsec policy map1

[RouterB-GigabitEthernet1/0/0] ipsec policy use1

# After the configurations are complete, PC A can ping PC B successfully. Data exchanged
between PC A and PC B is encrypted. You can run the display ipsec statistics command to
view packet statistics.
# Run the display ike sa command on RouterA. The following information is displayed:
[RouterA] display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase RemoteType RemoteID
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname RouterA
#
acl number 3101
#
#
ike proposal 5
aes-128
dh
group14
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spub

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
undo version 2
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
ike-proposal 5
#
ipsec policy map1 10 isakmp
security acl 3101
ike-peer spub
proposal tran1
#
ip address 1.1.1.1 255.255.255.0
ipsec policy map1
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
ip route-static 10.1.2.0 255.255.255.0 1.1.1.2
#
return

#
sysname RouterB
#
acl number 3101
#
#
ike proposal 5
aes-128
dh
group14
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spua
undo version 2
pre-shared-key cipher %^%#K{JG:rWVHPMnf;5\|,GW(Luq'qi8BT4nOj%5W5=)%^%#
ike-proposal 5
#
ipsec policy use1 10 isakmp
security acl 3101
ike-peer spua
proposal tran1
#
ip address 2.1.1.1 255.255.255.0
ipsec policy use1
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13.3 Example for Establishing an IPSec Tunnel Between the

Enterprise Headquarters and Branch Using an IPSec Policy
Template
In Figure 6-44, RouterA and RouterB are enterprise branch gateways. RouterA uses a fixed
IP address to access the public network, whereas RouterB uses a dynamic IP address to access
the public network. RouterC is the enterprise headquarters gateway. Branches and the
headquarters communicate through the public network.
The enterprise wants to protect the data flows between the branch subnets and the
headquarters subnet and wants the headquarters gateway to specify a branch gateway meeting
specific criteria to access it for security.
IPSec tunnels can be set up between the branch gateways and headquarters gateway because
they communicate over the Internet.
Figure 6-44 Establishing an IPSec tunnel between the enterprise headquarters and branch
using an IPSec policy template
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
Headquarters gateway
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
gateway 192.168.2.2/24 Headquarters
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The headquarters gateway can only respond to IPSec negotiation requests initiated by branch
gateways because it cannot identify IP addresses of branch gateways. An IPSec policy
template is configured on RouterC and is referenced in an IPSec policy so that RouterC can
receive IPSec negotiation requests initiated by branch gateways to complete setup of multiple
IPSec tunnels.
1. Configure IP addresses and static routes for interfaces so that routes among the three
gateways are reachable.
2. Configure ACLs to define the data flows to be protected.
– Configure RouterA to use its IP address for authentication with RouterC because
RouterA uses a fixed IP address for access.
– Configure RouterB to use its name for authentication with RouterC because
RouterB uses a dynamic IP address for access.
5. Configure an identity filter set on RouterC to permit access from RouterA and RouterB.
This prevents other unauthorized initiators from establishing an IPSec tunnel with
RouterC.
– Check the IP address of RouterA.
– Check the name of RouterB.
6. Configure IPSec policies on RouterA, RouterB, and RouterC. RouterC uses an IPSec
policy template to create an IPSec policy.
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA, RouterB, and RouterC so
that routes among them are reachable.
# Assign an IP address to each interface on RouterA.

# Configure a static route to the peer on RouterA. This example assumes that the next-hop
address of the route to RouterC is 60.1.1.2.
# Assign an IP address to each interface on RouterB.

[RouterB-GigabitEthernet0/0/1] ip address dhcp-alloc

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure a static route to the peer on RouterB. This example assumes that the outbound
interface of the route to the headquarters is GE0/0/1.
[RouterB] ip route-static 60.1.3.0 255.255.255.0 gigabitethernet 0/0/1
[RouterB] ip route-static 192.168.3.0 255.255.255.0 60.gigabitethernet 0/0/1
# Assign an IP address to each interface on RouterC.

# Configure a static route to the peer on RouterC. This example assumes that the next-hop
address of the route to RouterA and RouterB is 60.1.3.2.
Step 2 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
NOTE
Because RouterC uses an IPSec policy template to create an IPSec policy, so referencing an ACL is optional.
If an ACL is configured on RouterC, specify the destination address in the ACL.
# Configure an ACL on RouterA to define the data flows sent from 192.168.1.0/24 to
192.168.3.0/24.
192.168.3.0 0.0.0.255
# Configure an ACL on RouterB to define the data flows sent from 192.168.2.0/24 to
192.168.3.0/24.
192.168.3.0 0.0.0.255
Step 3 Create IPSec proposals on RouterA, RouterB, and RouterC.


# Create an IPSec proposal on RouterC.

[RouterC] ipsec proposal tran1
[RouterC-ipsec-proposal-tran1] esp authentication-algorithm sha2-256

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC-ipsec-proposal-tran1] esp encryption-algorithm aes-128

[RouterC-ipsec-proposal-tran1] quit
Step 4 Configure IKE peers on RouterA, RouterB, and RouterC.

# Create an IKE proposal on RouterA.
# Configure an IKE peer on RouterA.

[RouterA] ike peer rut1
[RouterA-ike-peer-rut1] undo version 2
[RouterA-ike-peer-rut1] ike-proposal 5
[RouterA-ike-peer-rut1] pre-shared-key cipher huawei@123
[RouterA-ike-peer-rut1] remote-address 60.1.3.1
[RouterA-ike-peer-rut1] quit
# Create an IKE proposal on RouterB.

# Configure an IKE peer on RouterB.
NOTE
Configure the local name as huaweirt1 and the local ID type as FQDN for IKE negotiation because RouterB
uses a dynamic IP address for access.
[RouterB] ike local-name huaweirt1
[RouterB] ike peer rut1
[RouterB-ike-peer-rut1] undo version 2
[RouterB-ike-peer-rut1] ike-proposal 5
[RouterB-ike-peer-rut1] pre-shared-key cipher huawei@123
[RouterB-ike-peer-rut1] local-id-type fqdn
[RouterB-ike-peer-rut1] remote-address 60.1.3.1
[RouterB-ike-peer-rut1] quit
# Create an IKE peer on RouterC.

[RouterC] ike proposal 5
[RouterC-ike-proposal-5] encryption-algorithm aes-128
[RouterC-ike-proposal-5] authentication-algorithm sha2-256
[RouterC-ike-proposal-5] dh group14
[RouterC-ike-proposal-5] quit
# Configure an IKE peer on RouterC.
NOTE
RouterC functions as the IKE responder and uses an IPSec policy template to create an IPSec policy, so the
remote-address command does not need to be used.
[RouterC] ike peer rut1
[RouterC-ike-peer-rut1] undo version 2
[RouterC-ike-peer-rut1] ike-proposal 5
[RouterC-ike-peer-rut1] pre-shared-key cipher huawei@123
[RouterC-ike-peer-rut1] quit
Step 5 Configure an identity filter set on RouterC.

[RouterC] ike identity identity1
[RouterC-ike-identity-identity1] ip address 60.1.1.1 24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC-ike-identity-identity1] fqdn huaweirt1

[RouterC-ike-identity-identity1] quit
Step 6 Configuring IPSec policies on RouterA, RouterB, and RouterC. RouterC uses an IPSec policy
template to create an IPSec policy.
# Create an IPSec policy on RouterA.
[RouterA] ipsec policy policy1 10 isakmp
[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rut1
[RouterA-ipsec-policy-isakmp-policy1-10] proposal tran1
[RouterA-ipsec-policy-isakmp-policy1-10] security acl 3002
[RouterA-ipsec-policy-isakmp-policy1-10] quit
# Create an IPSec policy on RouterB.

[RouterB] ipsec policy policy1 10 isakmp
[RouterB-ipsec-policy-isakmp-policy1-10] ike-peer rut1
[RouterB-ipsec-policy-isakmp-policy1-10] proposal tran1
[RouterB-ipsec-policy-isakmp-policy1-10] security acl 3002
[RouterB-ipsec-policy-isakmp-policy1-10] quit
# Configure an IPSec policy template on RouterC and reference the IPSec policy template in
the IPSec policy.
[RouterC] ipsec policy-template use1 10
[RouterC-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterC-ipsec-policy-templet-use1-10] proposal tran1
[RouterC-ipsec-policy-templet-use1-10] match ike-identity identity1
[RouterC-ipsec-policy-templet-use1-10] quit
[RouterC] ipsec policy policy1 10 isakmp template use1
Step 7 Apply IPSec policy groups to interfaces on RouterA, RouterB, and RouterC.
# Apply an IPSec policy group to the interface of RouterA
[RouterA-GigabitEthernet0/0/1] ipsec policy policy1
# Apply an IPSec policy group to the interface of RouterB.

[RouterB-GigabitEthernet0/0/1] ipsec policy policy1
# Apply an IPSec policy group to the interface of RouterC.

[RouterC-GigabitEthernet0/0/1] ipsec policy policy1

# After the configurations are complete, PC A and PC B can ping PC C successfully. The data
transmitted between PC A, PC B, and PC C is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE SA
---------------------------------------------------------------------------
24366 60.1.3.1:500 RD|ST v1:2 IP 60.1.3.1
24274 60.1.3.1:500 RD|ST v1:1 IP 60.1.3.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
---------------------------------------------------------------------------
Flag Description:
# Run the display ike sa command on RouterC. The following information is displayed:
[RouterC] display ike sa
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 FQDN huaweirt1
933 60.1.2.1:500 RD v1:1 FQDN huaweirt1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ipsec policy policy1 10 isakmp
security acl 3002
ike-peer rut1
proposal tran1
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip route-static 60.1.3.0 255.255.255.0 60.1.1.2

ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return
#
sysname RouterB
#
ike local-name huaweirt1
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
local-id-type fqdn
#
security acl 3002
ike-peer rut1
proposal tran1
#
ip address dhcp-alloc
#
ip address 192.168.2.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 GigabitEthernet0/0/1
ip route-static 192.168.3.0 255.255.255.0 GigabitEthernet0/0/1
#
return
#
sysname RouterC
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#IRFGEiFPJ1$&a'Qy,L*XQL_+*Grq-=yMb}ULZdS6%^%#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ike-proposal 5
#
ike identity identity1
fqdn huaweirt1
ip address 60.1.1.0 255.255.255.0
#
ipsec policy-template use1 10
ike-peer rut1
proposal tran1
match ike-identity identity1
#
ipsec policy policy1 10 isakmp template use1
#
ip address 60.1.3.1 255.255.255.0
#
ip address 192.168.3.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 60.1.3.2
#
return
6.13.4 Example for Establishing Multiple IPSec Tunnels Between

the Enterprise Headquarters and Branches Using IPSec Policy
Groups
As shown in Figure 6-45, RouterA and RouterB are branch gateways, and RouterC is the
headquarters gateway. The headquarters and branches communicate through the Internet. The
gateways' IP addresses are fixed. The subnets of branch A, branch B, and headquarters are
192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 respectively.
The enterprise wants to protect data flows between the branch subnets and the headquarters
subnet. IPSec tunnels can be set up between the branch gateways and headquarters gateway
because they communicate over the Internet. Because branch gateways' IP addresses can be
specified on the headquarters gateway, an IPSec policy group can be configured on RouterC.
Then the headquarters gateway can initiate IPSec negotiation to each branch gateway or
receive IPSec negotiation requests from each branch gateway to complete setup of multiple
IPSec tunnels.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-45 Establishing multiple IPSec tunnels between the enterprise headquarters and
branches using IPSec policies
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24
1. Configure IP addresses and static routes for interfaces so that routes among the three
gateways are reachable.
5. Configure IPSec policies on RouterA and RouterB. Create IPSec policy groups on
RouterC to define protection methods for data flows between RouterA and RouterC, and
between RouterB and RouterC.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure IP addresses and static routes for interfaces on RouterA, RouterB, and RouterC so
that routes among them are reachable.
address in the route to RouterC is 60.1.1.2.

address in the route to RouterC is 60.1.2.2.
# Assign an IP address to an interface on RouterC.

# Configure a static route to the peer on RouterC. This example assumes that the next hop
address in the route to RouterA and RouterB is 60.1.3.2.
Step 2 Configure ACLs on RouterA, RouterB, and RouterC to define data flows to be protected.
# Configure an ACL on RouterA to define data flows sent from 192.168.1.0/24 to
192.168.3.0/24.
192.168.3.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure an ACL on RouterB to define data flows sent from 192.168.2.0/24 to

192.168.3.0/24.
192.168.3.0 0.0.0.255
# Configure an ACL on RouterC to define data flows sent from 192.168.3.0/24 to

192.168.1.0/24 and 192.168.2.0/24.
[RouterC] acl number 3002
[RouterC-acl-adv-3002] rule permit ip source 192.168.3.0 0.0.0.255 destination
192.168.1.0 0.0.0.255
[RouterC-acl-adv-3002] quit
192.168.2.0 0.0.0.255
Step 3 Create IPSec proposals on RouterA, RouterB, and RouterC.



Run the display ipsec proposal command on RouterA, RouterB, and RouterC to view the
IPSec proposal configuration. The display on RouterA is used as an example.
[RouterA] display ipsec proposal name tran1
IPSec proposal name: tran1

Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-256
Encryption AES-128
Step 4 Configure IKE peers on RouterA, RouterB, and RouterC.



Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR



# Create an IKE proposal on RouterC.

# Configure an IKE peer on RouterC.

[RouterC-ike-peer-rut1] remote-address 60.1.1.1
Step 5 Configure IPSec policies on RouterA and RouterB, and configure an IPSec policy group on
RouterC.

# Create an IPSec policy group on RouterC.

[RouterC] ipsec policy policy1 10 isakmp
[RouterC-ipsec-policy-isakmp-policy1-10] ike-peer rut1
[RouterC-ipsec-policy-isakmp-policy1-10] proposal tran1
[RouterC-ipsec-policy-isakmp-policy1-10] security acl 3002
[RouterC-ipsec-policy-isakmp-policy1-10] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Run the display ipsec policy command on RouterC.
Step 6 Apply IPSec policy groups to interfaces on RouterA, RouterB, and RouterC.

# Apply the IPSec policy group to the interface of RouterC.


transmitted between PC A, PC B, and PC C is encrypted.
---------------------------------------------------------------------------
24366 60.1.3.1:500 RD|ST v1:2 IP 60.1.3.1
24274 60.1.3.1:500 RD|ST v1:1 IP 60.1.3.1
---------------------------------------------------------------------------
Flag Description:
# Run the display ike sa command on RouterC. The following information is displayed:
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 IP 60.1.2.1
933 60.1.2.1:500 RD v1:1 IP 60.1.2.1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
--------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
#
ip address 60.1.2.1 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.2.2
ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
#
return
#
sysname RouterC
#
acl number 3002
0.0.0.255
acl number 3003
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike peer rut2
undo version 2
pre-shared-key cipher %^%#(3fr1!&6O=)!GN#~{)n,2fq>4#4+%;lMTs5(]:c)%^%#
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
security acl 3003
ike-peer rut2
proposal tran1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 60.1.3.1 255.255.255.0
#
ip address 192.168.3.2 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.3.2
ip route-static 60.1.2.0 255.255.255.0 60.1.3.2
ip route-static 192.168.1.0 255.255.255.0 60.1.3.2
ip route-static 192.168.2.0 255.255.255.0 60.1.3.2
#
return
6.13.5 Example for Establishing IPSec Tunnels for Branch Access

to the Headquarters Using Different Pre-shared Keys
In Figure 6-46, RouterA and RouterB are the branch gateways of an enterprise, and RouterC
is the gateway of the headquarters. They communicate over the Internet.
The enterprise wants to protect traffic transmitted between the branches and headquarters. To
improve security, branch gateways are required to use different pre-shared keys to connect to
the headquarters gateway.
IPSec tunnels can be established between the headquarters gateway and branch gateways to
protect communication between the headquarters and branches over the Internet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-46 Establishing IPSec tunnels for branch access to the headquarters using different
pre-shared keys
PC A
192.168.1.1/24
Branch A
GE0/0/2
192.168.1.2/24
RouterA
Branch A IPSe
c Tunn
gateway GE0/0/1 e l
GE0/0/1
60.1.1.1/24
60.1.3.1/24
RouterC
GE0/0/1 e l GE0/0/2
60.1.2.1/24 c Tunn
IPSe 192.168.3.2/24
RouterB
Branch B GE0/0/2
PC C
Branch B 192.168.3.1/24
PC B
192.168.2.1/24
The headquarters gateway can only respond to IPSec negotiation requests initiated by branch
gateways because it is difficult to specify IP addresses for branch gateways on the
headquarters gateway. As a result, you can deploy a policy template on RouterC and reference
this template in an IPSec policy. To allow branch gateways to connect to the headquarters
using different pre-shared keys, configure an IKE user table on RouterC to allocate pre-shared
keys for branches. The branches initiate IPSec negotiation using allocated pre-shared keys to
establish IPSec tunnels.
1. Configure an IP address and a static route on each interface to implement

communication between both ends.
3. Configure an IPSec proposal to define the traffic protection method.
4. Configure an IKE peer and define the attributes used for IKE negotiation. The IKE user
table on RouterC allocates pre-shared keys for branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. Create an IPSec policy on RouterA, RouterB, and RouterC respectively to determine

protection methods used for protecting different types of data flows. On RouterC, an
IPSec policy is created through a policy template.
Procedure
Step 1 Configure an IP address and a static route for each interface on RouterA, RouterB, and
RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface on RouterA.
address in the route to the headquarters is 60.1.1.2.
# Configure an IP address for each interface on RouterB.

address in the route to the headquarters is 60.1.2.2.
# Configure an IP address for each interface on RouterC.

address in the route to the branch gateways A and B is 60.1.3.2.
Step 2 Configure an ACL on RouterA and RouterB to define the data flows to be protected.
NOTE
RouterC creates an IPSec policy through the IPSec policy template; therefore, this step is optional. If you
configure an ACL on RouterC, you must specify the destination address in the ACL rule.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure an ACL on RouterA to define the data flows from 192.168.1.0/24 to

192.168.3.0/24.
192.168.3.0 0.0.0.255
# Configure an ACL on RouterB to define the data flows from 192.168.2.0/24 to

192.168.3.0/24.
192.168.3.0 0.0.0.255
Step 3 Create an IPSec proposal on RouterA, RouterB, and RouterC respectively.



Step 4 Create an IKE peer on RouterA, RouterB, and RouterC respectively.

# Create an IKE peer on RouterA.

# Configure an IKE proposal on RouterB.

# Create an IKE peer on RouterB.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Create an IKE proposal on RouterC.

# Configure an IKE user table on RouterC to allocate pre-shared keys for branches.
NOTE
When the IKEv1 main mode and pre-shared key authentication are used, id-type can only be set to ip,
and in NAT traversal scenarios, the IP address must be set to the post-NAT address. If a branch
dynamically obtains an IP address, you must use the IKEv1 aggressive mode or IKEv2 and advised to
set id-type to fqdn.
[RouterC] ike user-table 10
[RouterC-ike-user-table-10] user routera
[RouterC-ike-user-table-10-routera] id-type ip 60.1.1.1
[RouterC-ike-user-table-10-routera] pre-shared-key huawei@123
[RouterC-ike-user-table-10-routera] quit
[RouterC-ike-user-table-10] user routerb
[RouterC-ike-user-table-10-routerb] id-type ip 60.1.2.1
[RouterC-ike-user-table-10-routerb] pre-shared-key huawei@124
[RouterC-ike-user-table-10-routerb] quit
NOTE
As the responder to IKE negotiation requests, RouterC creates an IPSec policy through the IPSec policy
template. You do not need to set remote-address.
[RouterC-ike-peer-rut1] user-table 10
Step 5 Create an IPSec policy on RouterA, RouterB, and RouterC respectively. RouterC creates an
IPSec policy through the IPSec policy template.

# Create a policy template on RouterC and apply the policy template to an IPSec policy.
[RouterC] ipsec policy-template use1 10
[RouterC-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterC-ipsec-policy-templet-use1-10] proposal tran1
[RouterC-ipsec-policy-templet-use1-10] quit
[RouterC] ipsec policy policy1 10 isakmp template use1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 6 Apply an IPSec policy group to the interface of RouterA, RouterB, and RouterC.
# Apply an IPSec policy group to an interface of RouterA.
# Apply an IPSec policy group to an interface of RouterB.

# Apply an IPSec policy group to an interface of RouterC.


transmitted among them is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE configuration.
The command output on RouterA is used as an example.
---------------------------------------------------------------------------
24366 60.1.3.1:500 RD|ST v1:2 IP 60.1.3.1
24274 60.1.3.1:500 RD|ST v1:1 IP 60.1.3.1
---------------------------------------------------------------------------
Flag Description:
# Run the display ike sa command on RouterC. The command output is displayed as follows:
--------------------------------------------------------------------------
961 60.1.2.1:500 RD v1:2 IP 60.1.2.1
933 60.1.2.1:500 RD v1:1 IP 60.1.2.1
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
l RouterA configuration file

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname RouterA
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.1.2
ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return
#
sysname RouterB
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
#
ip address 60.1.2.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 192.168.2.2 255.255.255.0
#
ip route-static 60.1.3.0 255.255.255.0 60.1.2.2
ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
#
return

#
sysname RouterC
#
#
ike proposal 5
dh group14
#
ike user-table
10
user routerb
id-type ip 60.1.2.1
pre-shared-key %^%#@q!5$RKXkQN'Sc&0D}$.T}vBUy,=TYy]rBOZl|04%^
%#
user routera
id-type ip 60.1.1.1
pre-shared-key %^%#C&&/)4psiA%=7T"/!J)B|CuiH4$us1x3muJpnTr&%^%#
#
ike peer rut1
undo version 2
ike-proposal 5
user-table 10
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.3.1 255.255.255.0
#
ip address 192.168.3.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 60.1.3.2
#
return

Headquarters and Branch (One Tunnel Interface Corresponds to
One Branch)
As shown in Figure 6-47, Router_B and Router_C are the gateways of enterprise branches,
and Router_A is the gateway of the headquarters. The headquarters and branches
communicate through the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The enterprise requires IPSec protection for the traffic between the headquarters and
branches. Multiple tunnel interfaces of the headquarters borrow the same physical interface IP
address, and one tunnel interface corresponds to one branch.
Figure 6-47 Networking diagram
PC2
10.1.2.2/24
Branch
GE1/0/3
10.1.2.1/24 Tunnel0/0/0
Router_B IPSe
Tunnel0/0/0
c Tunn
GE1/0/1 el
GE1/0/1
1.1.5.1/24
1.1.3.1/24
Router_A
GE1/0/1 el GE1/0/3
1.1.6.1/24 c Tunn
IPSe 10.1.1.1/24
Tunnel0/0/1
Router_C
Tunnel0/0/1
HQ
GE1/0/3
10.1.3.1/24
Branch PC1
10.1.1.2/24
PC3
10.1.3.2/24
1. Configure the IP address and static route on each interface to implement communication
between interfaces.
2. Configure security policies in ISAKMP mode, including the data flows to be protected
and proposal parameters.
Multiple tunnel interfaces of the headquarters borrow the same physical interface IP
address to establish an IPSec tunnel with a branch. Therefore, the headquarters uses the
peer IP address of the IKE peer to identify the tunnel interface connected to the branch.
In this instance, multiple IKE peers need to be configured and multiple IPSec policies

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
created at the headquarters. In addition, different IPSec policies are applied to the tunnel
interfaces.
NOTE
When multiple branches connect to the headquarters, multiple tunnel interfaces in the headquarters
borrow the same physical interface IP address. In this scenario, the headquarters can identify the tunnel
interface connected to a branch through the peer IP address or peer ID of the IKE peer (Only IKEv1 in
aggressive mode supports the peer ID mode.).
Procedure
Step 1 Configure Router_A.
1. Configure interface IP addresses and static routes.
a. Configure interface IP addresses.
[Huawei] sysname Router_A
[Router_A] interface gigabitethernet 1/0/3
[Router_A-GigabitEthernet1/0/3] ip address 10.1.1.1 24
[Router_A-GigabitEthernet1/0/3] quit
[Router_A] interface gigabitethernet 1/0/1
[Router_A-GigabitEthernet1/0/1] ip address 1.1.3.1 24
[Router_A-GigabitEthernet1/0/1] quit
[Router_A] interface tunnel 0/0/0
[Router_A-Tunnel0/0/0] tunnel-protocol ipsec
[Router_A-Tunnel0/0/0] ip address unnumbered interface gigabitethernet
1/0/1
[Router_A-Tunnel0/0/0] quit
[Router_A-Tunnel0/0/1] tunnel-protocol ipsec
[Router_A-Tunnel0/0/1] ip address unnumbered interface gigabitethernet
1/0/1
b. Configure static routes to the branches. Assume that the next hop of the static routes
is 1.1.3.2.
[Router_A] ip route-static 0.0.0.0 0.0.0.0 1.1.3.2
[Router_A] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/0
[Router_A] ip route-static 10.1.3.0 255.255.255.0 tunnel 0/0/1
2. Configure IPSec policies.

a. Define data flows to be protected.
[Router_A] acl 3000
[Router_A-acl-adv-3000] rule 5 permit ip source 10.1.1.0 0.0.0.255
destination 10.1.2.0 0.0.0.255
[Router_A-acl-adv-3000] quit
[Router_A] acl 3001
[Router_A-acl-adv-3001] rule 10 permit ip source 10.1.1.0 0.0.0.255
destination 10.1.3.0 0.0.0.255
[Router_A-acl-adv-3001] quit
b. Configure an IPSec proposal.

[Router_A] ipsec proposal tran1
[Router_A-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router_A-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[Router_A-ipsec-proposal-tran1] quit
c. Configure an IKE proposal.

[Router_A] ike proposal 10
[Router_A-ike-proposal-10] authentication-method pre-share
[Router_A-ike-proposal-10] prf hmac-sha2-256
[Router_A-ike-proposal-10] encryption-algorithm aes-256
[Router_A-ike-proposal-10] dh group14

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router_A-ike-proposal-10] integrity-algorithm hmac-sha2-256

[Router_A-ike-proposal-10] quit
d. Configure IKE peers.

[Router_A] ike peer b
[Router_A-ike-peer-b] ike-proposal 10
[Router_A-ike-peer-b] remote-address 1.1.5.1
[Router_A-ike-peer-b] pre-shared-key cipher Test!123
[Router_A-ike-peer-b] quit
[Router_A] ike peer c
[Router_A-ike-peer-c] ike-proposal 10
[Router_A-ike-peer-c] remote-address 1.1.6.1
[Router_A-ike-peer-c] pre-shared-key cipher Test!123
[Router_A-ike-peer-c] quit
e. Create security policies.

[Router_A] ipsec policy map1 10 isakmp
[Router_A-ipsec-policy-isakmp-map1-10] proposal tran1
[Router_A-ipsec-policy-isakmp-map1-10] ike-peer b
[Router_A-ipsec-policy-isakmp-map1-10] security acl 3000
[Router_A-ipsec-policy-isakmp-map1-10] quit
[Router_A] ipsec policy map2 10 isakmp
[Router_A-ipsec-policy-isakmp-map2-10] proposal tran1
[Router_A-ipsec-policy-isakmp-map2-10] ike-peer c
[Router_A-ipsec-policy-isakmp-map2-10] security acl 3001
[Router_A-ipsec-policy-isakmp-map2-10] quit
f. Apply the security policies to the corresponding interface.

[Router_A-Tunnel0/0/0] ipsec policy map1
[Router_A-Tunnel0/0/1] ipsec policy map2
Step 2 Configure Router_B. The configuration of Router_C is similar and will not be mentioned
here.
1. Configure interface IP addresses and static routes.
a. Configure interface IP addresses.
[Huawei] sysname Router_B
[Router_B] interface gigabitethernet 1/0/3
[Router_B-GigabitEthernet1/0/3] ip address 10.1.2.1 24
[Router_B-GigabitEthernet1/0/3] quit
[Router_B] interface gigabitethernet 1/0/1
[Router_B-GigabitEthernet1/0/1] ip address 1.1.5.1 24
[Router_B-GigabitEthernet1/0/1] quit
[Router_B] interface tunnel 0/0/0
[Router_B-Tunnel0/0/0] tunnel-protocol ipsec
[Router_B-Tunnel0/0/0] ip address unnumbered interface gigabitethernet
1/0/1
[Router_B-Tunnel0/0/0] quit
b. Configure the static route to the branches. Assume that the next hop of the static
route is 1.1.5.2.
[Router_B] ip route-static 0.0.0.0 0.0.0.0 1.1.5.2
[Router_B] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0
2. Configure IPSec policies.

a. Define data flows to be protected.
[Router_B] acl 3000
[Router_B-acl-adv-3000] rule 5 permit ip source 10.1.2.0 0.0.0.255
destination 10.1.1.0 0.0.0.255
[Router_B-acl-adv-3000] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
b. Configure an IPSec proposal.

[Router_B] ipsec proposal tran1
[Router_B-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router_B-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[Router_B-ipsec-proposal-tran1] quit
c. Configure an IKE proposal.

[Router_B] ike proposal 10
[Router_B-ike-proposal-10] authentication-method pre-share
[Router_B-ike-proposal-10] prf hmac-sha2-256
[Router_B-ike-proposal-10] encryption-algorithm aes-256
[Router_B-ike-proposal-10] dh group14
[Router_B-ike-proposal-10] integrity-algorithm hmac-sha2-256
[Router_B-ike-proposal-10] quit
d. Configure an IKE peer.

[Router_B] ike peer a
[Router_B-ike-peer-a] ike-proposal 10
[Router_B-ike-peer-a] remote-address 1.1.3.1
[Router_B-ike-peer-a] pre-shared-key cipher Test!1234
[Router_B-ike-peer-a] quit
e. Create an IPSec policy.

[Router_B] ipsec policy map1 10 isakmp
[Router_B-ipsec-policy-isakmp-map1-10] security acl 3000
[Router_B-ipsec-policy-isakmp-map1-10] proposal tran1
[Router_B-ipsec-policy-isakmp-map1-10] ike-peer a
[Router_B-ipsec-policy-isakmp-map1-10] quit
f. Apply the IPSec policy to the corresponding interface.

[Router_B] interface tunnel 0/0/0
[Router_B-Tunnel0/0/0] ipsec policy map1
[Router_B-Tunnel0/0/0] quit
# Run the ping -a source-ip-address host command to ping the private network addresses. If
the headquarters and branches can ping each other, services between them are reachable. The
following uses Router_A as an example:
[Router_A] ping -a 10.1.1.1 10.1.2.2

0.00% packet loss
[Router_A] ping -a 10.1.1.1 10.1.3.2

0.00% packet loss

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Run the display ike sa command. If information about the IKE SA and IPSec SA is
displayed, the IPSec tunnel is established successfully. The following uses Router_A as an
example:
[Router_A] display ike sa
------------------------------------------------------------------------------
50336907 1.1.5.1:500 RD|ST|A v2:2 IP 1.1.5.1
50336906 1.1.5.1:500 RD|ST|A v2:1 IP 1.1.5.1
33554436 1.1.6.1:500 RD|ST|A v2:2 IP 1.1.6.1
33554435 1.1.6.1:500 RD|ST|A v2:1 IP 1.1.6.1
------------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
l Router_A configuration file
#
sysname Router_A
#
acl number 3000
acl number 3001
#
#
ike proposal 10
dh group14
prf hmac-sha2-256
#
ike peer b
pre-shared-key cipher %^%#W)04NhZ:bP=~"=KQu\CN6KcK#NE5:(Os2L57]r5I%^%#
ike-proposal 10
ike peer c
ike-proposal 10
#
security acl 3000
ike-peer b
proposal tran1
security acl 3001
ike-peer c
proposal tran1
#
ip address 1.1.3.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.1 255.255.255.0
#
ip address unnumbered interface GigabitEthernet1/0/1
tunnel-protocol ipsec
ipsec policy map1
#
ipsec policy map2
#
ip route-static 0.0.0.0 0.0.0.0 1.1.3.2
#
return
l Router_B configuration file
#
sysname Router_B
#
acl number 3000
#
#
ike proposal 10
dh group14
prf hmac-sha2-256
#
ike peer a
ike-proposal 10
#
security acl 3000
ike-peer a
proposal tran1
#
ip address 1.1.5.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ipsec policy map1
#
ip route-static 0.0.0.0 0.0.0.0 1.1.5.2
#
return
l Configuration file of Router_C
#
sysname Router_C
#
acl number 3000

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
#
ike proposal 10
dh group14
prf hmac-sha2-256
#
ike peer a
ike-proposal 10
#
security acl 3000
ike-peer a
proposal tran1
#
ip address 1.1.6.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ipsec policy map1
#
ip route-static 0.0.0.0 0.0.0.0 1.1.6.2
#
return

Branch and Headquarters with a Redundant Gateway
As shown in Figure 6-48, two gateways RouterA and RouterB are deployed in the
headquarters to improve security. RouterC in the branch communicates with the headquarters
through the public network.
The enterprise requires to protect traffic transmitted over the public network between the
enterprise branch and headquarters.
IPSec tunnels can be set up between the branch gateways and headquarters gateway because
they communicate over the Internet. The branch gateway attempts to establish an IPSec tunnel
with the headquarters gateway RouterA. If the attempt fails, the branch gateway establishes an
IPSec tunnel with the headquarters gateway RouterB.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-48 Establishing an IPSec tunnel between the branch and headquarters with a
redundant gateway RouterA
Headquarters
gateway A
GE0/0/2
192.168.1.2/24
RouterC el
e c Tunn
Branch IPS GE0/0/1
gateway 60.1.1.1/24
GE0/0/1 GE0/0/1 Headquarters

GE0/0/2 70.1.1.1/24 60.1.2.1/24
192.168.3.2/24 IPSe PC A
c Tun 192.168.1.1/24
nel GE0/0/2
192.168.1.2/24
RouterB
Branch Headquarters
gateway B
PC C
192.168.3.1/24
between interfaces.
2. Configure an ACL to define the data flows to be protected by the IPSec tunnel.
5. Create an IPSec policy on RouterA, RouterB, and RouterC respectively to determine
protection methods used for protecting different types of data flows. On RouterA and
RouterB, IPSec policies are created through IPSec policy templates.
6. Apply an IPSec policy group to an interface so that the interface can protect traffic.
Procedure
Step 1 Configure an IP address and a static route for each interface on RouterA, RouterB, and
RouterC to ensure that there are reachable routes among them.
# Assign an IP address to each interface on RouterA.

address in the route to the headquarters subnet is 60.1.1.2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Assign an IP address to each interface on RouterB.

address in the route to the headquarters subnet is 60.1.2.2.
# Assign an IP address to each interface on RouterC.

address in the route to the headquarters gateway A and B is 70.1.1.2.
NOTE
RouterA and RouterB create an IPSec policy through the IPSec policy template; therefore, this step is
optional. If you configure an ACL on RouterA and RouterB, you must specify the destination address in the
ACL rule.
# Configure an ACL on RouterC to define the data flows from subnet 192.168.3.0/24 to
subnet 192.168.1.0/24.
192.168.1.0 0.0.0.255



Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Run the display ipsec proposal command on RouterA, RouterB, and RouterC to view the
configuration of the IPSec proposal. The command output on RouterA is used as an example.
[RouterA] display ipsec proposal name tran1
IPSec proposal name: tran1

Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-256
Encryption AES-128
Step 4 Create an IKE peer on RouterA, RouterB, and RouterC respectively.




NOTE
RouterA and RouterB function as responders to respond to an IKE negotiation request; therefore, they create
IPSec policies through IPSec policy templates. You do not need to set remote-address.



Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 5 Create an IPSec policy on RouterA, RouterB, and RouterC respectively. On RouterA and
RouterB, IPSec policies are created through IPSec policy templates.
# Create an ipsec policy template on RouterA and apply the ipsec policy template to an IPSec
policy.
[RouterA] ipsec policy-template use1 10
[RouterA-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterA-ipsec-policy-templet-use1-10] proposal tran1
[RouterA-ipsec-policy-templet-use1-10] quit
[RouterA] ipsec policy policy1 10 isakmp template use1
# Create an ipsec policy template on RouterB and apply the ipsec policy template to an IPSec
policy.
[RouterB] ipsec policy-template use1 10
[RouterB-ipsec-policy-templet-use1-10] ike-peer rut1
[RouterB-ipsec-policy-templet-use1-10] proposal tran1
[RouterB-ipsec-policy-templet-use1-10] quit
[RouterB] ipsec policy policy1 10 isakmp template use1
# Create an IPSec policy on RouterC.

Step 6 Apply an IPSec policy group to the interface of RouterA, RouterB, and RouterC.
# Apply an IPSec policy group to the interface of RouterA.
# Apply an IPSec policy group to the interface of RouterB.

# Apply an IPSec policy group to the interface of RouterC.


# After the configurations are complete, PC C can ping PC A successfully. The data
transmitted between PC C and PC A is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE configuration.
The command output on RouterA is used as an example.
---------------------------------------------------------------------------
24366 70.1.1.1:500 RD|ST v1:2 IP 70.1.1.1
24274 70.1.1.1:500 RD|ST v1:1 IP 70.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
---------------------------------------------------------------------------
Flag Description:
# Run the display ike sa command on RouterC. The command output is displayed as follows:
--------------------------------------------------------------------------
937 60.1.1.1:500 RD v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 192.168.3.0 255.255.255.0 60.1.1.2
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.2.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
ip route-static 192.168.3.0 255.255.255.0 60.1.2.2
#
return
#
sysname RouterC
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 70.1.1.1 255.255.255.0
#
ip address 192.168.3.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
#
return

Enterprise Headquarters and Branch Using a Multi-Link Shared
IPSec Policy Group
communicate through the Internet. RouterA uses two egress links in backup or load balancing
mode. The branch subnet is 10.1.1.0/24 and the headquarters subnet is 10.1.2.0/24.
The Enterprise wants to protect traffic between the branch subnet and headquarters subnet. If
an active/standby switchover occurs or the egress link becomes faulty, IPSec services need to
be smoothly switched. IPSec tunnels can be set up between the branch gateway and
headquarters gateway because they communicate over the Internet. The two outbound
interfaces negotiate with their peers to establish IPSec SAs respectively. When one interface
alternates between Up and Down states and an active/standby switchover occurs, the two
peers need to perform IKE negotiate again to generate IPSec SAs. The IKE re-negotiation
causes IPSec service interruption in a short time. To ensure that IPSec services are smoothly
switched, the two egress links on the branch gateway and the headquarters gateway only
negotiate a shared IPSec SA.
using a multi-link shared IPSec policy group
LoopBack0
1.1.1.1/32 GE1/0/0
GE1/0/0 60.1.1.1/24
70.1.1.1/24
RouterA RouterB
Branch gateway Headquarters gateway
GE3/0/0 GE2/0/0 GE3/0/0
10.1.1.1/24 80.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
The branch gateway uses a loopback interface to establish an IPSec tunnel with the
headquarters gateway, and the two egress links and the headquarters gateway only negotiate a
shared IPSec SA. The configuration roadmap is as follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6. Apply IPSec policy groups to interfaces. Configure a multi-link shared IPSec policy
group on RouterA so that the IPSec policy group can be shared by multiple interfaces.
Procedure
[RouterA] interface loopback 0
[RouterA-LoopBack0] ip address 1.1.1.1 255.255.255.255
[RouterA-LoopBack0] quit
addresses corresponding to the two outbound interfaces in the route to RouterB are 70.1.1.2
and 80.1.1.2.
[RouterA] ip route-static 10.1.2.0 255.255.255.0 70.1.1.2 preference 10


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

10.1.2.0 0.0.0.255
10.1.1.0 0.0.0.255

[RouterA] ipsec proposal prop
[RouterA-ipsec-proposal-prop] esp authentication-algorithm sha2-256
[RouterA-ipsec-proposal-prop] esp encryption-algorithm aes-128
[RouterA-ipsec-proposal-prop] quit

[RouterB] ipsec proposal prop
[RouterB-ipsec-proposal-prop] esp authentication-algorithm sha2-256
[RouterB-ipsec-proposal-prop] esp encryption-algorithm aes-128
[RouterB-ipsec-proposal-prop] quit
Step 4 Create IKE proposals on RouterA and RouterB.



# Configure an IKE peer on RouterA, reference the IKE proposal, and set the pre-shared key
and remote ID.
[RouterA] ike peer rut
[RouterA-ike-peer-rut] undo version 2
[RouterA-ike-peer-rut] ike-proposal 5
[RouterA-ike-peer-rut] pre-shared-key cipher huawei
[RouterA-ike-peer-rut] remote-address 60.1.1.1
[RouterA-ike-peer-rut] quit
# Configure an IKE peer on RouterB, reference the IKE proposal, and set the pre-shared key
and remote ID.
[RouterB] ike peer rut
[RouterB-ike-peer-rut] undo version 2
[RouterB-ike-peer-rut] ike-proposal 5
[RouterB-ike-peer-rut] pre-shared-key cipher huawei
[RouterB-ike-peer-rut] remote-address 1.1.1.1
[RouterB-ike-peer-rut] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rut
[RouterA-ipsec-policy-isakmp-policy1-10] proposal prop

[RouterB-ipsec-policy-isakmp-policy1-10] ike-peer rut
[RouterB-ipsec-policy-isakmp-policy1-10] proposal prop

# Configure a multi-link shared IPSec policy group on RouterA and apply the IPSec policy
group to the two interfaces.
[RouterA] ipsec policy policy1 shared local-interface loopback 0


--------------------------------------------------------------------------
937 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD|ST v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3101

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipsec proposal prop
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut
undo version 2
ike-proposal 5
#
security acl 3101
ike-peer rut
proposal prop
#
ipsec policy policy1 shared local-interface LoopBack0
#
ip address 70.1.1.1 255.255.255.0
#
ip address 80.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ip route-static 10.1.2.0 255.255.255.0 70.1.1.2 preference 10
#
return
#
sysname RouterB
#
acl number 3101
#
ipsec proposal prop
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut
undo version 2
ike-proposal 5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
security acl 3101
ike-peer rut
proposal prop
#
ip address 60.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.1 255.255.255.255 60.1.1.2
ip route-static 10.1.1.0 255.255.255.0 60.1.1.2
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 80.1.1.0 255.255.255.0 60.1.1.2
#
return

Enterprise Headquarters and Branch Through PPPoE
subnet is 10.1.2.0/24. The branch gateway connects to the Internet using PPPoE, and obtains
an IP address from the PPPoE server.
The enterprise wants to protect data flows between the branch subnets and the headquarters
because they communicate over the Internet. The branch gateway functions as the PPPoE
client to obtain an IP address, so the headquarters gateway cannot obtain the branch gateway's
IP address and can only respond to IPSec negotiation requests initiated by the branch gateway.
through PPPoE
PPPoE_Server
PPPoE_Client
GE1/0/0
RouterA GE1/0/0 6.6.6.6/24 RouterB
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
If both the branch gateway and headquarters gateway connect to the public network through PPPoE, the
remote-address host-name host-name command must be run on them to specify the domain name for
IPSec negotiation. Otherwise, the IPSec tunnel cannot be established.
1. Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from
the PPPoE server.
2. Configure the IKE negotiation mode in which an IPSec tunnel is set up. RouterB
functions as the responder to receive IPSec negotiation requests initiated by RouterA.
Procedure
Step 1 Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from the
PPPoE server.
# Configure a dialer access group to permit all IPv4 packets to pass through.
# Create a dialer interface and set parameters of the dialer interface.

[RouterA] interface dialer 1
[RouterA-Dialer1] link-protocol ppp
[RouterA-Dialer1] ppp chap user user@huawei.com
[RouterA-Dialer1] ppp chap password cipher Huawei@1234
[RouterA-Dialer1] ip address ppp-negotiate
[RouterA-Dialer1] dialer user huawei
[RouterA-Dialer1] dialer bundle 1
[RouterA-Dialer1] dialer-group 1
[RouterA-Dialer1] quit
# Bind the dialer interface to a physical interface and establish a PPPoE session.
[RouterA] interface gigabitethernet1/0/0
[RouterA-GigabitEthernet1/0/0] pppoe-client dial-bundle-number 1
# Assign IP addresses to interfaces.

# Configure LAN users to dial up using public network addresses translated through NAT.
[RouterA-acl-adv-3002] rule 5 permit ip source 10.1.1.0 0.0.0.255
[RouterA-Dialer1] nat outbound 3002
# On RouterA, configure a static route to PC B. The route uses the IP address of the dialer
interface as the next hop address.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA] ip route-static 6.6.6.0 24 dialer1

Step 2 On RouterA, set parameters for establishing an IPSec tunnel in IKE negotiation mode.
# Configure an ACL to control data flows from the branch subnet 10.1.1.0/24 to the
headquarters subnet 10.1.2.0/24. Assume that the NAT-translated branch subnet address is
1.1.1.0/24 (that is, public network address obtained through PPPoE dial-up).
10.1.2.0 0.0.0.255
# Configure an IPSec proposal.

[RouterA] ipsec proposal prop1
[RouterA-ipsec-proposal-prop1] esp authentication-algorithm sha2-256
[RouterA-ipsec-proposal-prop1] esp encryption-algorithm aes-128
[RouterA-ipsec-proposal-prop1] quit
# Configure an IKE proposal.

# Configure an IKE peer.

# Configure an IPSec policy.

[RouterA-ipsec-policy-isakmp-policy1-10] proposal prop1
Run the display ipsec policy command to view the IPSec policy configuration.
# Apply the IPSec policy group to the dialer interface.

[RouterA-Dialer1] ipsec policy policy1
Step 3 On RouterB used as the responder, set parameters for establishing an IPSec tunnel in IKE
negotiation mode.
# Configure an IP address for an interface and a static route to the peer.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure a static route to the peer. This example assumes that the next hop address in the
route is 6.6.6.254.

[RouterB] ipsec proposal prop1
[RouterB-ipsec-proposal-prop1] esp authentication-algorithm sha2-256
[RouterB-ipsec-proposal-prop1] esp encryption-algorithm aes-128
[RouterB-ipsec-proposal-prop1] quit


Because RouterB as the responder uses an IPSec policy template to configure an IPSec policy,
so you do not need to specify the remote IP address for the IKE peer.
# Configure an IPSec policy template.

[RouterB] ipsec policy-template temp1 10
[RouterB-ipsec-policy-templet-temp1-10] ike-peer rut1
[RouterB-ipsec-policy-templet-temp1-10] proposal prop1
[RouterB-ipsec-policy-templet-temp1-10] quit
Run the display ipsec policy-template command to view the IPSec policy template
configuration.
# Reference the IPSec policy template in the IPSec policy.
[RouterB] ipsec policy policy1 10 isakmp template temp1
# Apply the IPSec policy group to an interface.


-------------------------------------------------------------------------
246 6.6.6.6:500 RD|ST v1:2 IP 6.6.6.6
245 6.6.6.6:500 RD|ST v1:1 IP 6.6.6.6
-------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3002
rule 5 permit ip source 10.1.1.0 0.0.0.255
acl number 3003
#
ipsec proposal prop1
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3003
ike-peer rut1
proposal prop1
#
interface Dialer1
link-protocol ppp
ppp chap user user@huawei.com
ppp chap password cipher %@%@^_PfANXK0(,Jr-(3p]"R,eOL%@%@
dialer user huawei
dialer bundle 1
dialer-group 1
nat outbound 3002
#
pppoe-client dial-bundle-number 1
#
ip address 10.1.1.1 255.255.255.0
#
dialer-rule
#
ip route-static 6.6.6.0 255.255.255.0 dialer1
ip route-static 10.1.2.0 255.255.255.0 Dialer1
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ipsec policy-template temp1
ike-peer rut1
proposal prop1
#
ipsec policy policy1 10 isakmp template temp1
#
ip address 6.6.6.6 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 6.6.6.254
#
return
6.13.10 Example for Establishing an IPSec Tunnel Through NAT

Traversal
As shown in Figure 6-51, RouterA and RouterB communicate through the NAT gateway.
RouterA is located on the subnet at 10.1.0.2/24, and RouterB is located on the subnet at
10.2.0.2/24.
The enterprise wants to protect traffic exchanged between RouterA and RouterB.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-51 Establishing an IPSec tunnel providing NAT traversal

GE1/0/0 NAT GE1/0/0
192.168.0.2/24 gateway 1.2.0.1/24
RouterA RouterB
GE2/0/0 GE2/0/0
10.1.0.1/24 10.2.0.1/24
IPSec Tunnel
PC A PC B
10.1.0.2/24 10.2.0.2/24
RouterA subnet RouterB subnet
RouterA and RouterB communicate through the NAT gateway, so NAT traversal must be
enabled for establishing an IPSec tunnel. The configuration roadmap is as follows:
2. Configure an ACL on RouterA to define data flows to be protected.
5. Configure IPSec policies on RouterA and RouterB. RouterB uses an IPSec policy
template to create an IPSec policy.
Procedure


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 2 # Configure an ACL on RouterA to define data flows sent from 10.1.0.0/24 to 10.2.0.0/24.
10.2.0.0 0.0.0.255


Step 4 Set the local ID type to name on RouterA and RouterB.

# Set the local ID type to name on RouterA.
[RouterA] ike local-name rta
# Set the local ID type to name on RouterB.

[RouterB] ike local-name rtb


[RouterA] ike peer rta
[RouterA-ike-peer-rta] undo version 2
[RouterA-ike-peer-rta] exchange-mode aggressive
[RouterA-ike-peer-rta] ike-proposal 5
[RouterA-ike-peer-rta] pre-shared-key cipher huawei@123
[RouterA-ike-peer-rta] local-id-type fqdn
[RouterA-ike-peer-rta] remote-address 1.2.0.1
[RouterA-ike-peer-rta] remote-id rtb
[RouterA-ike-peer-rta] nat traversal
[RouterA-ike-peer-rta] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[RouterB] ike peer rtb
[RouterB-ike-peer-rtb] undo version 2
[RouterB-ike-peer-rtb] exchange-mode aggressive
[RouterB-ike-peer-rtb] ike-proposal 5
[RouterB-ike-peer-rtb] pre-shared-key cipher huawei@123
[RouterB-ike-peer-rtb] local-id-type fqdn
[RouterB-ike-peer-rtb] remote-id rta
[RouterA-ike-peer-rta] nat traversal
[RouterB-ike-peer-rtb] quit

[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rta

[RouterB-ipsec-policy-templet-temp1-10] ike-peer rtb
[RouterB-ipsec-policy-templet-temp1-10] proposal tran1


---------------------------------------------------------------------------
15 1.2.0.1:4500 RD|ST v1:2 FQDN rtb
14 1.2.0.1:4500 RD|ST v1:1 FQDN rtb

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
---------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
ike local-name rta
#
acl number 3101
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rta
undo version 2
exchange-mode aggressive
ike-proposal 5
local-id-type fqdn
remote-id rtb
#
security acl 3101
ike-peer rta
proposal tran1
#
ip address 192.168.0.2 255.255.255.0
#
ip address 10.1.0.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 192.168.0.1
#
return

#
sysname RouterB
#
ike local-name rtb
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rtb
undo version 2
ike-proposal 5
local-id-type fqdn
remote-id rta
#
ipsec policy-template temp1 10
ike-peer rtb
proposal tran1
#
#
ip address 1.2.0.1 255.255.255.0
#
ip address 10.2.0.1 255.255.255.0
#
ip route-static 10.1.0.0 255.255.255.0 1.2.0.2
ip route-static 192.168.0.0 255.255.255.0 1.2.0.2
#
return
6.13.11 Example for Establishing an IPSec Tunnel in IKE

Negotiation Mode by Specifying DNs
communicate through the Internet. The headquarters gateway and branch gateway apply for
digital certificates from the CA server. The branch subnet is 10.1.1.0/24 and the headquarters
subnet is 10.1.2.0/24.
The enterprise wants to use distinguished names (DNs) to identify identities and creat SAs to
protect data flows between the branch subnet and the headquarters subnet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-52 Establishing an IPSec tunnel in IKE negotiation mode by specifying DNs
CA Server
70.1.1.7
RouterA RouterB
Remote GE1/0/0 GE1/0/0 Server
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Branch Headquarters
Subnet Subnet
2. Apply for digital certificates from the CA server. The digital certificates are used for
RSA signature authentication.
6. Configure IPSec policies and reference ACLs, IPSec proposals, and IKE peers in the
IPSec policies to define protection methods for data flows between RouterA and
RouterB.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

10.1.2.0 0.0.0.255
10.1.1.0 0.0.0.255
Step 3 Configure PKI entities and PKI domains on RouterA and RouterB, which are used to apply
for digital certificates from the CA server.
# Create an RSA key pair on RouterA.
[RouterA] pki rsa local-key-pair create rsa_scep exportable
Info: The name of the new key-pair will be: rsa_scep
The size of the public key ranges from 512 to
4096.
Input the bits in the modules:2048
Generating key-
pairs...
......+++
.......+++
# Configure a PKI entity on RouterA.

[RouterA] pki entity rta
[RouterA-pki-entity-rta] country CN
[RouterA-pki-entity-rta] state jiangsu
[RouterA-pki-entity-rta] locality nanjing
[RouterA-pki-entity-rta] organization huawei
[RouterA-pki-entity-rta] organization-unit VPN
[RouterA-pki-entity-rta] common-name ipsec
[RouterA-pki-entity-rta] quit
# Configure a PKI domain on RouterA.

[RouterA] pki realm rta
[RouterA-pki-realm-rta] ca id ca_root

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA-pki-realm-rta] enrollment-url http://70.1.1.7:8080/certsrv/mscep/

mscep.dll times 4 ra
[RouterA-pki-realm-rta] entity rta
[RouterA-pki-realm-rta] rsa local-key-pair rsa_scep
[RouterA-pki-realm-rta] fingerprint sha256
e71add0744360e91186b828412d279e06dcc15a4ab4bb3d13842820396b526a0
[RouterA-pki-realm-rta] password cipher 6AE73F21E6D3571D
# Create an RSA key pair on RouterB.

[RouterB] pki rsa local-key-pair create rsa_scep exportable
Info: The name of the new key-pair will be: rsa_scep
The size of the public key ranges from 512 to
4096.
Input the bits in the modules:2048
Generating key-
pairs...
......+++
.......+++
# Configure a PKI entity on RouterB.

[RouterB] pki entity rtb
[RouterB-pki-entity-rtb] country CN
[RouterB-pki-entity-rtb] state jiangsu
[RouterB-pki-entity-rtb] locality nanjing
[RouterB-pki-entity-rtb] organization huawei
[RouterB-pki-entity-rtb] organization-unit VPN
[RouterB-pki-entity-rtb] common-name ipsec
[RouterB-pki-entity-rtb] quit
# Configure a PKI domain on RouterB.

[RouterB] pki realm rtb
[RouterB-pki-realm-rtb] ca id ca_root
[RouterB-pki-realm-rtb] enrollment-url http://70.1.1.7:8080/certsrv/mscep/
mscep.dll times 4 ra
[RouterB-pki-realm-rtb] entity rtb
[RouterB-pki-realm-rtb] rsa local-key-pair rsa_scep
[RouterB-pki-realm-rtb] fingerprint sha256
[RouterB-pki-realm-rtb] password cipher 6AE73F21E6D3571D
Step 4 Request digital certificates on RouterA and RouterB.

# Request a local certificate on RouterA.
[RouterA-pki-realm-rta] auto-enroll 60 regenerate 2048
[RouterA-pki-realm-rta] quit
Before obtaining and installing a local certificate, the device obtains and installs a CA
certificate first. The CA and local certificates are named rta_ca.cer and rta_local.cer.
# Request a local certificate on RouterB.
[RouterB-pki-realm-rtb] auto-enroll 60 regenerate 2048
[RouterB-pki-realm-rtb] quit
Before obtaining and installing a local certificate, the device obtains and installs a CA
certificate first. The CA and local certificates are named rtb_ca.cer and rtb_local.cer.
[RouterA] ipsec proposal prop
[RouterA-ipsec-proposal-prop] esp authentication-algorithm sha2-256
[RouterA-ipsec-proposal-prop] esp encryption-algorithm aes-128
[RouterA-ipsec-proposal-prop] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterB] ipsec proposal prop
[RouterB-ipsec-proposal-prop] esp authentication-algorithm sha2-256
[RouterB-ipsec-proposal-prop] esp encryption-algorithm aes-128
[RouterB-ipsec-proposal-prop] quit
# Configure an IKE proposal that defines RSA signature authentication on RouterA.

[RouterA-ike-proposal-5] authentication-method rsa-signature

[RouterA] ike peer rta
[RouterA-ike-peer-rta] undo version 2
[RouterA-ike-peer-rta] ike-proposal 5
[RouterA-ike-peer-rta] local-id-type dn
[RouterA-ike-peer-rta] pki realm rta
[RouterA-ike-peer-rta] remote-address 60.1.2.1
[RouterA-ike-peer-rta] quit
# Configure an IKE proposal that defines RSA signature authentication on RouterB.

[RouterB-ike-proposal-5] authentication-method rsa-signature

[RouterB] ike peer rtb
[RouterB-ike-peer-rtb] undo version 2
[RouterB-ike-peer-rtb] ike-proposal 5
[RouterB-ike-peer-rtb] local-id-type dn
[RouterB-ike-peer-rtb] pki realm rtb
[RouterB-ike-peer-rtb] remote-address 60.1.1.1
[RouterB-ike-peer-rtb] quit

[RouterA-ipsec-policy-isakmp-policy1-10] ike-peer rta
[RouterA-ipsec-policy-isakmp-policy1-10] proposal prop

[RouterB-ipsec-policy-isakmp-policy1-10] ike-peer rtb
[RouterB-ipsec-policy-isakmp-policy1-10] proposal prop

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR



---------------------------------------------------------------------------
4 60.1.2.1:500 RD|ST v1:2 DN C=CN, ST=jiangsu,
L=nanjing, O=huawei, OU=VPN, CN=ipsec
3 60.1.2.1:500 RD|ST v1:1 DN C=CN, ST=jiangsu,
L=nanjing, O=huawei, OU=VPN, CN=ipsec
---------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
pki entity rta
country CN
state jiangsu
locality nanjing
organization huawei
organization-unit VPN
common-name ipsec
#
pki realm rta
ca id ca_root
enrollment-url http://70.1.1.7:8080/certsrv/mscep/mscep.dll times 4 ra
entity rta
fingerprint sha256
rsa local-key-pair
rsa_scep
password cipher %$%$\1HN-bn(k;^|O85OAtYF3(M4%$%
$
auto-enroll 60 regenerate
#
acl number 3001
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipsec proposal prop

#
ike proposal 5
dh group14
authentication-method rsa-signature
prf hmac-sha2-256
#
ike peer rta
undo version 2
ike-proposal 5
local-id-type dn
pki realm rta
#
security acl 3001
ike-peer rta
proposal prop
#
ip address 60.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
pki entity rtb
country CN
state jiangsu
locality nanjing
organization huawei
organization-unit VPN
common-name ipsec
#
pki realm rtb
ca id ca_root
enrollment-url http://70.1.1.7:8080/certsrv/mscep/mscep.dll times 4 ra
entity rtb
fingerprint sha256
rsa local-key-pair
rsa_scep
password cipher %$%$\1HN-bn(k;^|O85OAtYF3(M4%$%
$
auto-enroll 60 regenerate
#
acl number 3001
#
ipsec proposal prop
#
ike proposal 5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
dh group14
authentication-method rsa-signature
prf hmac-sha2-256
#
ike peer rtb
undo version 2
ike-proposal 5
local-id-type dn
pki realm rtb
#
security acl 3001
ike-peer rtb
proposal prop
#
ip address 60.1.2.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
#
return
6.13.12 Example for Establishing an IPSec Tunnel Through

Negotiation Initiated by the Branch User That Dynamically
Obtains an IP Address
communicate through the Internet. The branch subnet IP addresses are allocated by the branch
gateway through DHCP, and the headquarters subnet is located on 10.1.2.0/24. The branch
gateway connects to the Internet using PPPoE, and obtains an IP address from the
PPPoE_server.
because they communicate over the Internet. The branch gateway functions as the PPPoE
client to obtain an IP address, so the headquarters gateway cannot obtain the branch gateway's
IP address and can only respond to IPSec negotiation request sent by the branch gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-53 Establishing an IPSec tunnel through negotiation initiated by the branch user that
dynamically obtains an IP address
PPPoE_Server
PPPoE_Client
GE1/0/0
RouterA GE1/0/0 6.6.6.6/24 RouterB
GE2/0/0 GE2/0/0
10.1.2.1/24
IPSec Tunnel
PC B
PC A
10.1.2.2/24
Branch subnet
Headquarters subnet
1. Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from
the PPPoE server.
2. Enable DHCP on RouterA so that IP addresses can be dynamically allocated through
DHCP.
3. Configure the IKE negotiation mode in which an IPSec tunnel is set up. RouterB
functions as the responder to receive IPSec negotiation requests initiated by RouterA.
Procedure
Step 1 Configure the PPPoE client on RouterA so that RouterA can obtain an IP address from the
PPPoE server.
# Configure a dialer access group to permit all IPv4 packets to pass through.
# Create a dialer interface and set parameters of the dialer interface.

[RouterA-Dialer1] link-protocol ppp
[RouterA-Dialer1] ppp chap user user@huawei.com
[RouterA-Dialer1] ppp chap password cipher Huawei@1234
[RouterA-Dialer1] ip address ppp-negotiate
[RouterA-Dialer1] dialer user huawei
[RouterA-Dialer1] dialer bundle 1
[RouterA-Dialer1] dialer-group 1
# Bind the dialer interface to a physical interface and establish a PPPoE session.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA] interface gigabitethernet1/0/0

[RouterA-GigabitEthernet1/0/0] pppoe-client dial-bundle-number 1
# On RouterA, configure a static route to PC B. The route uses the IP address of Dialer1 as
the next hop address.
Step 2 Enable DHCP on RouterA so that IP addresses can be dynamically allocated through DHCP.
# Enable DHCP and configure a global address pool.
[RouterA] dhcp enable
[RouterA] ip pool pooltest
[RouterA-ip-pool-pooltest] network 10.1.1.0 mask 255.255.255.0
[RouterA-ip-pool-pooltest] quit
# Configure RouterA to assign IP addresses from a global address pool on an interface.

[RouterA-GigabitEthernet2/0/0] dhcp select global
Step 3 On RouterA, set parameters for establishing an IPSec tunnel in IKE negotiation mode.
# Configure an ACL to define data flows destined for 10.1.2.0/24.
[RouterA-acl-adv-3003] rule permit ip destination 10.1.2.0 0.0.0.255



[RouterA-ike-peer-rut1] pre-shared-key cipher Huawei@1234
# Configure an IPSec policy.

[RouterA-ipsec-policy-isakmp-policy1-10] proposal prop1
[RouterA-ipsec-policy-isakmp-policy1-10] security acl 3003 dynamic-source
# Apply the IPSec policy group to the dialer interface.

[RouterA-Dialer1] ipsec policy policy1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 On RouterB used as the responder, set parameters for establishing an IPSec tunnel in IKE
negotiation mode.
# Configure an IP address for an interface and a static route to the peer.

# Configure a static route to peer. This example assumes that the next hop address in the route
is 6.6.6.1.


Because RouterB as the responder uses an IPSec policy template to configure an IPSec policy,
so you do not need to specify the remote IP address for the IKE peer.
[RouterB-ike-peer-rut1] pre-shared-key cipher Huawei@1234
# Configure an IPSec policy template.

# Reference the IPSec policy template in the IPSec policy.

# Apply the IPSec policy group to an interface.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------
246 6.6.6.6:500 RD|ST v1:2 IP 6.6.6.6
245 6.6.6.6:500 RD|ST v1:1 IP 6.6.6.6
-------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3003
rule 5 permit ip destination 10.1.2.0 0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3003 dynamic-source
ike-peer rut1
proposal prop1
#
interface Dialer1
link-protocol ppp
ppp chap user user@huawei.com
ppp chap password cipher %@%@^_PfANXK0(,Jr-(3p]"R,eOL%@%@
policy policy1
#
pppoe-client dial-bundle-number 1
#
dhcp select global
#
dialer-rule
#
ip route-static 6.6.6.0 255.255.255.0 dialer1
ip route-static 10.1.2.0 255.255.255.0 Dialer1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ipsec policy-template temp1
ike-peer rut1
proposal prop1
#
#
interface Ethernet1/0/0
ip address 6.6.6.6 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 6.6.6.1
#
return
6.13.13 Example for Establishing an IPSec Tunnel Using a Tunnel

Interface
subnet is 10.1.2.0/24.
because they communicate over the Internet. There are many branch subnets and many data
flows need to be protected by IPSec. You can use a tunnel interface to create an IPSec tunnel
to protect IPSec packets. You do not need to configure ACLs to define traffic characteristics.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-54 Establishing an IPSec tunnel using a tunnel interface
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
10.1.1.1/24 192.168.1.1/24 192.168.1.2/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
4. Configure IPSec profiles and reference IPSec proposals and IKE peers in the IPSec
profiles to determine the methods used to protect data flows.
5. Apply IPSec profiles to IPSec tunnel interfaces.
6. Configure static routes on IPSec tunnel interfaces and import data flows to be protected
by IPSec to the tunnel interfaces.
Procedure


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[RouterAike-proposal-5] dh group14

[RouterA-ike-peer-spub] pre-shared-key cipher Huawei@1234


[RouterB-ike-peer-spua] pre-shared-key cipher Huawei@1234
Step 4 Create IPSec profiles on RouterA and RouterB.

# Create an IPSec profile on RouterA.
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] proposal tran1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterA-ipsec-profile-profile1] ike-peer spub

[RouterA-ipsec-profile-profile1] quit
# Create an IPSec profile on RouterB.

[RouterB] ipsec profile profile1
[RouterB-ipsec-profile-profile1] proposal tran1
[RouterB-ipsec-profile-profile1] ike-peer spua
[RouterB-ipsec-profile-profile1] quit
Step 5 Apply the IPSec profiles to IPSec tunnel interfaces on RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.

[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] ipsec profile profile1
# Apply the IPSec policy to the interface of RouterB.

[RouterB] interface tunnel 0/0/0
[RouterB-Tunnel0/0/0] ip address 192.168.1.2 255.255.255.0
[RouterB-Tunnel0/0/0] tunnel-protocol ipsec
[RouterB-Tunnel0/0/0] source 2.1.1.1
[RouterB-Tunnel0/0/0] destination 1.1.1.1
[RouterB-Tunnel0/0/0] ipsec profile profile1
[RouterB-Tunnel0/0/0] quit
Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
Step 6 Configure static routes on IPSec tunnel interfaces and import data flows to be protected by
IPSec to the tunnel interfaces.
# Configure a static route on the tunnel interface of RouterA.

# Configure a static route on the tunnel interface of RouterB.

[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0
# After the configurations are complete, run the display ike sa command on RouterA and
RouterB to view the IKE SA configuration. The display on RouterA is used as an example.
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
--------------------------------------------------------------------------------
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname RouterA
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
ike-peer spub
proposal tran1
#
ip address 192.168.1.1 255.255.255.0
source 1.1.1.1
destination 2.1.1.1
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.12
ip route-static 10.1.2.0 255.255.255.0 tunnel0/0/0
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5
#
ike-peer spua
proposal tran1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 192.168.1.2 255.255.255.0
source 2.1.1.1
destination 1.1.1.1
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.10 255.255.255.0 2.1.1.2
#
return
6.13.14 Example for Establishing GRE over IPSec Using a Tunnel

Interface
communicate through the Internet.
The enterprise wants to protect traffic including multicast data between the headquarters and
branch. As IPSec cannot be applied to multicast data directly, GRE over IPSec can be
established between virtual tunnel interfaces to protect traffic on tunnel interfaces.
Figure 6-55 Establishing GRE over IPSec using a tunnel interface
GE1/0/0 GE1/0/0
1.1.1.1/24 2.1.1.1/24
RouterA RouterB
10.1.1.1/24 192.168.1.1/24 192.168.1.2/24 10.1.2.1/24
GRE over IPSec
PC A PC B
10.1.1.2/24 10.1.2.2/24
1. Configure IP addresses and static routes for physical interfaces on RouterA and RouterB
so that routes between RouterA and RouterB are reachable.
2. Configure a GRE tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

5. Configure IPSec profiles and reference IPSec proposals and IKE peers in the IPSec
profiles.
6. Apply IPSec profiles to IPSec tunnel interfaces.
7. Configure static routes on IPSec tunnel interfaces and import data flows to be protected
by IPSec to the tunnel interfaces.
Procedure
Step 1 Configure IP addresses and static routes for physical interfaces on RouterA and RouterB.

Step 2 Configure a GRE tunnel interface.

[RouterB-Tunnel0/0/0] ip address 192.168.1.2 255.255.255.0
[RouterB-Tunnel0/0/0] tunnel-protocol gre
[RouterB-Tunnel0/0/0] source 2.1.1.1
[RouterB-Tunnel0/0/0] destination 1.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR




[RouterA-ike-peer-spub] pre-shared-key cipher Huawei@1234


[RouterB-ike-peer-spua] pre-shared-key cipher Huawei@1234
Step 5 Create IPSec profiles on RouterA and RouterB.

[RouterA-ipsec-profile-profile1] proposal tran1
[RouterA-ipsec-profile-profile1] ike-peer spub

[RouterB-ipsec-profile-profile1] proposal tran1
[RouterB-ipsec-profile-profile1] ike-peer spua
Step 6 Apply the IPSec profiles to IPSec tunnel interfaces on RouterA and RouterB.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterB-Tunnel0/0/0] ipsec profile profile1
Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
# Configure a static route on the tunnel interface of RouterA.
# Configure a static route on the tunnel interface of RouterB.

[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0

# After the configurations are complete, run the display ike sa command on RouterA and
RouterB to view the IKE SA configuration. The display on RouterA is used as an example.
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname RouterA
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
ike-peer spub
proposal tran1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5
#
ike-peer spua
proposal tran1
#
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 2.1.1.1
destination 1.1.1.1
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13.15 Example for Establishing IPSec over GRE Using a Tunnel

Interface
As shown in Figure 6-56, Router_1 (branch gateway) and Router_2 (headquarters gateway)
communicate through the Internet.
The branch communicates with the headquarters through a GRE tunnel. The enterprise wants
to protect traffic excluding multicast data between the headquarters and branch. IPSec over
GRE can be established between virtual tunnel interfaces to protect traffic between the
Figure 6-56 Establishing IPSec over GRE using a tunnel interface

Branch Headquarters
gateway GE1/0/0 gateway
GE1/0/0
Router_1 1.1.1.1/24 2.1.1.1/24 Router_2
GE2/0/0 GE2/0/0
192.168.1.1/24 192.168.1.2/24
10.1.1.1/24 10.1.2.1/24
IPSec over GRE
192.168.2.1/24 192.168.2.2/24
PC_1 PC_2
10.1.1.2/24 10.1.2.2/24
Branch HQ
1. Configure IP addresses and static routes for physical interfaces on Router_1 and
Router_2 so that routes between Router_1 and Router_2 are reachable.
2. Configure a GRE tunnel interface.
5. Configure IPSec profiles and reference IPSec policies and IKE peers in the IPSec
profiles.
6. Configure IPSec tunnel interfaces and specify a GRE tunnel interface as the source
interface of the IPSec tunnel and the other GRE tunnel interface as the outbound
interface for routes to the destination address of the IPSec tunnel.
7. Apply IPSec profiles to the IPSec tunnel interfaces to enable IPSec on the interfaces.
8. Configure static routes for the IPSec tunnel interfaces to import data flows to be
protected by IPSec to the interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure IP addresses and static routes for physical interfaces on Router_1 and Router_2.
# Assign an IP address to an interface on Router_1.
# Configure a static route to the peer on Router_1. This example assumes that the next hop
address in the route to Router_2 is 1.1.1.2.
[Router_1] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
# Assign an IP address to an interface on Router_2.

# Configure a static route to the peer on Router_2. This example assumes that the next hop
address in the route to Router_1 is 2.1.1.2.
[Router_2] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure a GRE tunnel interface.

Step 3 Create IPSec proposals on Router_1 and Router_2.

# Create an IPSec proposal on Router_1.
[Router_1] ipsec proposal tran1
[Router_1-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router_1-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[Router_1-ipsec-proposal-tran1] quit

[Router_2] ipsec proposal tran1
[Router_2-ipsec-proposal-tran1] esp authentication-algorithm sha2-256

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router_2-ipsec-proposal-tran1] esp encryption-algorithm aes-128

[Router_2-ipsec-proposal-tran1] quit
Step 4 Configure IKE peers on Router_1 and Router_2.

# Create an IKE proposal on Router_1.
[Router_1] ike proposal 5
[Router_1-ike-proposal-5] authentication-algorithm sha2-256
[Router_1-ike-proposal-5] encryption-algorithm aes-128
[Router_1-ike-proposal-5] dh group14
[Router_1-ike-proposal-5] quit
# Configure an IKE peer on Router_1.

[Router_1] ike peer spub
[Router_1-ike-peer-spub] undo version 2
[Router_1-ike-peer-spub] ike-proposal 5
[Router_1-ike-peer-spub] pre-shared-key cipher Huawei@1234
[Router_1-ike-peer-spub] quit

[Router_2-ike-proposal-5] authentication-algorithm sha2-256
# Configure an IKE peer on Router_2.

[Router_2] ike peer spua
[Router_2-ike-peer-spua] undo version 2
[Router_2-ike-peer-spua] ike-proposal 5
[Router_2-ike-peer-spua] pre-shared-key cipher Huawei@1234
[Router_2-ike-peer-spua] quit
Step 5 Create IPSec profiles on Router_1 and Router_2.

# Create an IPSec profile on Router_1.
[Router_1] ipsec profile profile1
[Router_1-ipsec-profile-profile1] proposal tran1
[Router_1-ipsec-profile-profile1] ike-peer spub
[Router_1-ipsec-profile-profile1] quit
# Create an IPSec profile on Router_2.

[Router_2] ipsec profile profile1
[Router_2-ipsec-profile-profile1] proposal tran1
[Router_2-ipsec-profile-profile1] ike-peer spua
[Router_2-ipsec-profile-profile1] quit
Step 6 Configure an IPSec tunnel interface on Router_1 and Router_2 respectively. Specify a GRE
tunnel interface as the source interface of the IPSec tunnel and the other GRE tunnel interface
as the outbound interface for routes to the destination address of the IPSec tunnel.
[Router_1-Tunnel0/0/1] tunnel-protocol ipsec
[Router_1-Tunnel0/0/1] source tunnel 0/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router_2-Tunnel0/0/1] tunnel-protocol ipsec

[Router_2-Tunnel0/0/1] source tunnel 0/0/0
Step 7 Apply IPSec profiles to the IPSec tunnel interfaces.

# Apply the IPSec profile to the interface of Router_1.
[Router_1-Tunnel0/0/1] ipsec profile profile1
# Apply the IPSec policy to the interface of Router_2.

[Router_2-Tunnel0/0/1] ipsec profile profile1
Run the display ipsec profile command on Router_1 and Router_2 to view the IPSec profile
configuration.
# Configure a static route on the tunnel interface of Router_1.
[Router_1] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/1
# Configure a static route on the tunnel interface of Router_2.

[Router_2] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/1

# After the configurations are complete, run the display ike sa command on Router_1 and
Router_2 to view the IKE SA configuration. The display on Router_1 is used as an example.
[Router_1] display ike sa
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname Router_1
#
#
ike proposal 5
dh group14

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
ike-peer spub
proposal tran1
#
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
#
ip address 192.168.2.1 255.255.255.0
source Tunnel0/0/0
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
#
return
#
sysname Router_2
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5
#
ike-peer spua
proposal tran1
#
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 1.1.1.2
destination 1.1.1.1
#
ip address 192.168.2.2 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
source Tunnel0/0/0
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return
6.13.16 Example for Establishing an IPSec over GRE Tunnel

Between the Headquarters and Branch (Based on ACL)
In Figure 6-57, Router1 is the gateway of an enterprise branch, and Router2 is the gateway of
the headquarters. Router1 and Router2 communicate through the public network.
On the live network, the enterprise branch communicates with the headquarters through a
GRE tunnel. The enterprise wants to protect traffic excluding multicast data between the
headquarters and branch. An IPSec over GRE tunnel can be established based on ACL to
protect traffic between the headquarters and branch.
Figure 6-57 Establishing an IPSec over GRE tunnel between the headquarters and branch
Branch gateway Headquarters
Router1 GE1/0/0 GE1/0/0 gateway
1.1.1.1/24 2.1.1.1/24 Router2
GE2/0/0 GE2/0/0
10.2.1.1/24 10.2.1.2/24
10.1.1.1/24 10.1.2.1/24
IPSec over GRE
PC1 PC2
10.1.1.2/24 10.1.2.2/24
Branch Headquarters
1. Configure the IP address and static route on each physical interface to ensure reachable
routes between the interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. Configure GRE tunnel interfaces.

3. Configure static routes for tunnel interfaces so that data flows are imported to the tunnel
interfaces.
6. Configure an IKE peer and IKE proposal to define the attributes used for IKE
negotiation.
7. Configure a security policy and apply the IKE proposal, IKE peer, and ACL.
8. Apply the security policy to the tunnel interfaces to enable IPSec protection.
Procedure
Step 1 Configure an IP address and a static route for each physical interface on the routers.
# Configure Router1.
[Huawei] sysname Router1
[Router1] interface gigabitethernet 1/0/0
[Router1-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
[Router1-GigabitEthernet1/0/0] quit
# Configure a static route to the remote end on Router1. This example assumes that the next
hop address of the route is 1.1.1.2.
[Router1] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
# Configure a static route to the remote end on Router2. This example assumes that the next
hop address of the route is 2.1.1.2.
[Router2] ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
Step 2 Configure GRE tunnel interfaces.

[Router1] interface tunnel 0/0/0
[Router1-Tunnel0/0/0] ip address 10.2.1.1 255.255.255.0
[Router1-Tunnel0/0/0] tunnel-protocol gre
[Router1-Tunnel0/0/0] source 1.1.1.1
[Router1-Tunnel0/0/0] destination 2.1.1.1
[Router1-Tunnel0/0/0] quit
[Router2-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[Router2-Tunnel0/0/0] tunnel-protocol gre
[Router2-Tunnel0/0/0] source 2.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router2-Tunnel0/0/0] destination 1.1.1.1

Step 3 Configure static routes for tunnel interfaces so that data flows are imported to the tunnel
interfaces.
[Router1] ip route-static 10.1.2.0 255.255.255.0 tunnel 0/0/0
[Router2] ip route-static 10.1.1.0 255.255.255.0 tunnel 0/0/0
After the configuration is complete, run the display tunnel-info all command on the routers
to view GRE tunnel establishment information. The command output on Router1 is used as an
example.
[Router1] display tunnel-info all
* -> Allocated VC Token
Tunnel ID Type Destination Token
----------------------------------------------------------------------
0x1 gre 2.1.1.1 1
Step 4 Create an ACL on the routers to define the data flows to be protected.
[Router1] acl number 3101
[Router1-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[Router1-acl-adv-3101] quit
10.1.1.0 0.0.0.255
Step 5 Create an IPSec proposal on the routers.

[Router1] ipsec proposal tran1
[Router1-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router1-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[Router1-ipsec-proposal-tran1] quit
[Router2] ipsec proposal tran1
[Router2-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[Router2-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[Router2-ipsec-proposal-tran1] quit
Step 6 Configure an IKE proposal and an IKE peer on the routers.

[Router1] ike proposal 5
[Router1-ike-proposal-5] authentication-algorithm sha2-256
[Router1-ike-proposal-5] encryption-algorithm aes-128
[Router1-ike-proposal-5] dh group14
[Router1-ike-proposal-5] quit
[Router1] ike peer spub
[Router1-ike-peer-spub] undo version 2
[Router1-ike-peer-spub] ike-proposal 5
[Router1-ike-peer-spub] pre-shared-key cipher Huawei@1234

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router1-ike-peer-spub] remote-address 10.2.1.2

[Router1-ike-peer-spub] quit
[Router2] ike peer spua
[Router2-ike-peer-spua] undo version 2
[Router2-ike-peer-spua] ike-proposal 5
[Router2-ike-peer-spua] pre-shared-key cipher Huawei@1234
[Router2-ike-peer-spua] remote-address 10.2.1.1
[Router2-ike-peer-spua] quit
Step 7 Create a security policy on the routers.
[Router1] ipsec policy map1 10 isakmp
[Router1-ipsec-policy-isakmp-map1-10] proposal tran1
[Router1-ipsec-policy-isakmp-map1-10] ike-peer spub
[Router1-ipsec-policy-isakmp-map1-10] security acl 3101
[Router1-ipsec-policy-isakmp-map1-10] quit
[Router2] ipsec policy use1 10 isakmp
[Router2-ipsec-policy-isakmp-use1-10] proposal tran1
[Router2-ipsec-policy-isakmp-use1-10] ike-peer spua
[Router2-ipsec-policy-isakmp-use1-10] security acl 3101
[Router2-ipsec-policy-isakmp-use1-10] quit
Step 8 Apply the security policy to the router interfaces.
[Router1-Tunnel0/0/0] ipsec policy map1
[Router2-Tunnel0/0/0] ipsec policy use1
# After the configuration is complete, run the display ike sa command on the routers to view
the SA establishment information. The command output on Router1 is used as an example.
[Router1] display ike sa
------------------------------------------------------------------------------
20 10.2.1.2:500 RD|A v1:2 IP 10.2.1.2
19 10.2.1.2:500 RD|A v1:1 IP 10.2.1.2
------------------------------------------------------------------------------
Flag Description:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After an SA is successfully established, data transmitted between the headquarters and branch
is encrypted.
----End
Configuration Files
l Router1 configuration file
#
sysname Router1
#
acl number 3101
#
#
ike proposal 5
dh group14
#
ike peer spub
undo version 2
ike-proposal 5
#
security acl 3101
ike-peer spub
proposal tran1
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
tunnel-protocol gre
source 1.1.1.1
destination 2.1.1.1
ipsec policy map1
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
#
return

#
sysname Router2
#
acl number 3101
#
#
ike proposal 5
dh group14
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ike peer spua

undo version 2
ike-proposal 5
#
security acl 3101
ike-peer spua
proposal tran1
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
tunnel-protocol gre
source 2.1.1.1
destination 1.1.1.1
ipsec policy use1
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return
6.13.17 Example for Establishing IPSec over DSVPN Tunnels

Between Hub and Spokes (Based on ACL)
In Figure 6-58, a large-sized enterprise has the headquarters (Hub) and multiple branches
(Spoke1 and Spoke2 in this example) located in different areas, and the Spokes connect to
public networks using dynamic IP addresses obtained through DHCP. DSVPN is deployed to
enable communication between Spokes as well as between Spoke and Hub.
The enterprise requires that data transmitted between Spokes as well as between Spoke and
Hub be encrypted. IPSec over DSVPN can be configured on Hub and Spokes to provide
traffic protection.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-58 Establishing IPSec over DSVPN tunnels between Hub and Spokes
Tunnel0/0/0
Branch 1 10.2.1.2/24
GE1/0/0
GE1/0/1 1.1.2.10/24
10.1.2.1/24
Spoke1
GE1/0/1
10.1.1.1/24
GE1/0/0
1.1.1.10/24
Headquarters
Tunnel0/0/0
10.2.1.1/24
Hub
Spoke2
GE1/0/1
10.1.3.1/24 GE1/0/0
1.1.3.10/24
Tunnel0/0/0
Branch 2
10.2.1.3/24
NOTE
Assume that the dynamic addresses obtained by Spoke1 and Spoke2 are 1.1.2.10 and 1.1.3.10,
respectively.
1. Configure DSVPN to implement VPN interconnection between the Spokes because the
Spokes connect to the public network using dynamic IP addresses and the Spokes do not
know the public IP addresses of each other.
2. Deploy DSVPN in shortcut mode because there are a large number of Spokes.
3. Configure OSPF to simplify maintenance because subnets of the Hub and Spokes
frequently change.
4. Configure IPSec over DSVPN to encrypt data transmitted between the Hub and Spokes
using IPSec before transmitting the data using DSVPN.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure Spoke1.
[Spoke1-GigabitEthernet1/0/0] ip address dhcp-alloc
# Configure Spoke2.
[Spoke2-GigabitEthernet1/0/0] ip address dhcp-alloc
Step 2 Configure OSPF to ensure reachable routes over the public network.
[Hub] ospf 2
[Hub-ospf-2] quit
# Configure Spoke1.
[Spoke1] ospf 2
# Configure Spoke2.
[Spoke2] ospf 2
Step 3 Configure OSPF to ensure reachable routes between private networks.

[Hub-ospf-1] quit
# Configure Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure Spoke2.

On the Hub and Spokes, set the OSPF network type to broadcast to enable the Spokes to learn
routes from each other. On Spoke1 and Spoke2, configure static NHRP peer entries of the
Hub.
# Configure Spoke1.
# Configure Spoke2.
Step 5 Configure an ACL to define the data flows to be protected by IPSec.

# Configure Spoke1.
[Spoke1] acl number 3101
[Spoke1-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
10.1.3.0 0.0.0.255
[Spoke1-acl-adv-3101] quit
# Configure Spoke2.
[Spoke2] acl number 3101
10.1.1.0 0.0.0.255
10.1.2.0 0.0.0.255
[Spoke2-acl-adv-3101] quit
Step 6 Configure an IKE proposal.

[Hub] ike proposal 1
[Hub-ike-proposal-1] dh group14

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub-ike-proposal-1] encryption-algorithm aes-256

[Hub-ike-proposal-1] authentication-algorithm sha2-256
[Hub-ike-proposal-1] prf aes-xcbc-128
[Hub-ike-proposal-1] quit
# Configure Spoke1.
# Configure Spoke2.

[Hub] ike peer hub
[Hub-ike-peer-hub] undo version 2
[Hub-ike-peer-hub] ike-proposal 1
[Hub-ike-peer-hub] pre-shared-key cipher Huawei@1234
[Hub-ike-peer-hub] dpd type periodic
[Hub-ike-peer-hub] dpd idle-time 40
[Hub-ike-peer-hub] quit
# Configure Spoke1.
[Spoke1-ike-peer-spoke1] remote-address 10.2.1.1
# Configure Spoke2.
[Spoke2-ike-peer-spoke2] remote-address 10.2.1.1

On the Hub and Spokes, create an IPSec proposal.
[Hub] ipsec proposal pro1
[Hub-ipsec-proposal-pro1] transform esp
[Hub-ipsec-proposal-pro1] esp authentication-algorithm sha2-256
[Hub-ipsec-proposal-pro1] esp encryption-algorithm aes-256
[Hub-ipsec-proposal-pro1] quit
# Configure Spoke1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Spoke1-ipsec-proposal-pro1] transform esp
# Configure Spoke2.
[Spoke2-ipsec-proposal-pro1] transform esp
Step 9 Configure a security policy.

[Hub] ipsec policy-template use1 10
[Hub-ipsec-policy-templet-use1-10] ike-peer hub
[Hub-ipsec-policy-templet-use1-10] proposal pro1
[Hub-ipsec-policy-templet-use1-10] quit
[Hub] ipsec policy policy1 10 isakmp template use1
# Configure Spoke1.
[Spoke1] ipsec policy policy1 10 isakmp
[Spoke1-ipsec-policy-isakmp-policy1-10] ike-peer spoke1
[Spoke1-ipsec-policy-isakmp-policy1-10] proposal pro1
[Spoke1-ipsec-policy-isakmp-policy1-10] security acl 3101
[Spoke1-ipsec-policy-isakmp-policy1-10] quit
# Configure Spoke2.
[Spoke2] ipsec policy policy1 10 isakmp
[Spoke2-ipsec-policy-isakmp-policy1-10] ike-peer spoke2
[Spoke2-ipsec-policy-isakmp-policy1-10] proposal pro1
[Spoke2-ipsec-policy-isakmp-policy1-10] security acl 3101
[Spoke2-ipsec-policy-isakmp-policy1-10] quit
Step 10 Apply the security policy to the tunnel interfaces to enable IPSec protection.
[Hub-Tunnel0/0/0] ipsec policy policy1
# Configure Spoke1.
[Spoke1-Tunnel0/0/0] ipsec policy policy1
# Configure Spoke2.
[Spoke2-Tunnel0/0/0] ipsec policy policy1

# After the configuration is complete, run the display ike sa command on the Spokes to view
the SA establishment information. The command output on Spoke1 is used as an example.
------------------------------------------------------------------------------
20 10.2.1.1:500 RD|A v1:2 IP 10.2.1.1
19 10.2.1.1:500 RD|A v1:1 IP 10.2.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
------------------------------------------------------------------------------
Flag Description:
The command output shows that an SA is successfully established between Spoke1 and the
Hub to encrypt data transmitted between them.
After pinging 10.1.3.1 from Spoke1, run the display ike sa command to view the SA
establishment information. The command output on Spoke1 is used as an example.
------------------------------------------------------------------------------
22 10.2.1.3:500 RD|A v1:2 IP 10.2.1.3
21 10.2.1.3:500 RD|A v1:1 IP 10.2.1.3
20 10.2.1.1:500 RD|A v1:2 IP 10.2.1.1
19 10.2.1.1:500 RD|A v1:1 IP 10.2.1.1
------------------------------------------------------------------------------
Flag Description:
The command output shows that an SA is successfully established between Spoke1 and
Spoke2 to encrypt data transmitted between them.
----End
Configuration Files
#
sysname Hub
#
ipsec proposal pro1
#
ike proposal 1
aes-256
dh
group14
prf aes-xcbc-128
#
ike peer hub
undo version 2
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
ike-peer hub
proposal pro1
#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 1.1.1.10 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
ospf 2
area 0.0.0.1
network 1.1.1.0 0.0.0.255
#
return
#
sysname Spoke1
#
acl number 3101
#
ipsec proposal pro1
#
ike proposal 1
dh group14
prf aes-xcbc-128
#
ike peer spoke1
undo version 2
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
security acl 3101
ike-peer spoke1
proposal pro1
#
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
ospf 2
area 0.0.0.1
network 1.1.2.0 0.0.0.255
#
return

#
sysname Spoke2
#
acl number 3101
#
ipsec proposal pro1
#
ike proposal 1
aes-256
dh
group14
prf aes-xcbc-128
#
ike peer spoke2
undo version 2
ike-proposal 1
dpd type periodic
dpd idle-time 40
#
security acl 3101
ike-peer spoke2
proposal pro1
#
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.2.1.3 255.255.255.0
#
area 0.0.0.0
network 10.1.3.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
ospf 2
area 0.0.0.1
network 1.1.3.0 0.0.0.255
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13.18 Example for Configuring L2TP Over IPSec to Implement

Secure Communication Between the Headquarters and Branch
As shown in Figure 6-59, the LAC is the enterprise branch gateway and the LNS is the
enterprise headquarters gateway. The LAC automatically dials up to establish L2TP
connections between the LNS for secure communication.
The enterprise requires that service packets transmitted over the L2TP tunnel be protected
from being intercepted and tampered. L2TP over IPSec can be configured to encrypt service
packets transmitted between the enterprise headquarters and branch.
Figure 6-59 Configuring L2TP over IPSec to implement secure communication between the
headquarters and branch
Enterprise GE2/0/0 GE2/0/0 Enterprise

branch 10.1.10.1/24 10.1.2.1/24 headquarters
LAC GE1/0/0 GE1/0/0 LNS
1.1.2.1/24 1.1.1.1/24
PC1
10.1.10.2/24
L2TP over IPSec PC2
VT1 10.1.2.2/24
10.1.1.1/24
between interfaces.
2. Enable L2TP on the LAC. The PPP user sends a connection request to the LNS in the
headquarters through an L2TP tunnel. After the PPP user is authenticated, a tunnel is set
up.
3. On the LAC, configure a reachable route to the LNS and the enable the auto dial-up
function.
4. On the LNS, configure L2TP, create a PPP user, and configure a route to the public
network segment.
5. Configure an ACL to define the data flows to be protected by the IPSec tunnel.
8. Configure an IPSec policy, and apply the ACL, IPSec proposal, and IKE peers to the
IPSec policy to define the data flows to be protected and protection method.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Assign IP addresses to interfaces and configure a static route to the remote device.
# Assign an IP address to each interface on the LAC.

[Huawei] sysname LAC
# Configure a public network route on the LAC to implement a reachable route to the LNS. A
static route is used in this example, and the next-hop IP address is 1.1.2.2.
[LAC] ip route-static 1.1.1.1 255.255.255.0 1.1.2.2
# Assign an IP address to each interface on the LNS.

# Configure a public network route on the LNS to implement a reachable route to the LAC. A
static route is used in this example, and the next-hop IP address is 1.1.1.2.
Step 2 Configure L2TP.
# On the LAC, enable L2TP globally, create an L2TP group, and configure the user huawei to
establish an L2TP connection to the LNS.
[LAC] l2tp enable
[LAC] l2tp-group 1
[LAC-l2tp1] tunnel name lac
[LAC-l2tp1] start l2tp ip 1.1.1.1 fullusername huawei
# Enable tunnel authentication and set the tunnel password on the LAC.
[LAC-l2tp1] tunnel authentication
[LAC-l2tp1] tunnel password cipher huawei
[LAC-l2tp1] quit
# Configure the user name and password, PPP authentication, and IP address for the virtual
PPP user on the LAC.
[LAC-Virtual-Template1] ppp chap user huawei
[LAC-Virtual-Template1] ppp chap password cipher Huawei@1234
[LAC-Virtual-Template1] ip address ppp-negotiate
# Enable the LAC to dial up and establish an L2TP tunnel.

[LAC-Virtual-Template1] l2tp-auto-client enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure a private network route on the LAC, so users in the enterprise branch can
communicate with users in the headquarters.
[LAC] ip route-static 10.1.2.0 255.255.255.0 virtual-template 1
# Configure AAA authentication, user name huawei, and password Huawei@1234 on the
LNS.
[LNS] aaa
[LNS-aaa] quit
# Configure an IP address pool for the LNS and assign an IP address to the dial-up interface
of the LAC.
[LNS] ip pool 1
# Create a virtual interface template and configure PPP negotiation parameters on the LNS.
# Enable L2TP and configure an L2TP group on the LNS.

[LNS] l2tp enable
[LNS] l2tp-group 1
# Configure the LNS tunnel name and specify the LAC tunnel name.
[LNS-l2tp1] allow l2tp virtual-template 1 remote lac

[LNS-l2tp1] quit
# Configure a private network route on the LNS, so users in the headquarters can
communicate with users in the enterprise branch.
[LNS] ip route-static 10.1.10.0 255.255.255.0 virtual-template 1
Step 3 Configure an ACL to define the traffic to be protected.
# Configure an ACL on the LAC.

[LAC] acl number 3101
[LAC-acl-adv-3101] rule permit ip source 1.1.2.0 0.0.0.255 destination 1.1.1.0
0.0.0.255
[LAC-acl-adv-3101] quit
# Configure an ACL on the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LNS] acl number 3101

[LNS-acl-adv-3101] rule permit ip source 1.1.1.0 0.0.0.255 destination 1.1.2.0
0.0.0.255
[LNS-acl-adv-3101] quit

# Create an IPSec proposal on the LAC.
[LAC] ipsec proposal tran1
[LAC-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[LAC-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[LAC-ipsec-proposal-tran1] quit
# Create an IPSec proposal on the LNS.

[LNS] ipsec proposal tran1
[LNS-ipsec-proposal-tran1] esp authentication-algorithm sha2-256
[LNS-ipsec-proposal-tran1] esp encryption-algorithm aes-128
[LNS-ipsec-proposal-tran1] quit
Step 5 Configure IKE peers.

# Configure an IKE proposal on the LAC.
[LAC] ike proposal 5
[LAC-ike-proposal-5] encryption-algorithm aes-128
[LAC-ike-proposal-5] authentication-algorithm sha2-256
[LAC-ike-proposal-5] dh group14
[LAC-ike-proposal-5] quit
# Create an IKE peer on the LAC and set the pre-shared key and remote ID based on the
default configuration.
[LAC] ike peer spub
[LAC-ike-peer-spub] undo version 2
[LAC-ike-peer-spub] ike-proposal 5
[LAC-ike-peer-spub] pre-shared-key cipher Huawei@1234
[LAC-ike-peer-spub] remote-address 1.1.1.1
[LAC-ike-peer-spub] quit
# Configure an IKE proposal on the LNS.

[LNS] ike proposal 5
[LNS-ike-proposal-5] encryption-algorithm aes-128
[LNS-ike-proposal-5] authentication-algorithm sha2-256
[LNS-ike-proposal-5] dh group14
[LNS-ike-proposal-5] quit
# Create an IKE peer on the LNS and set the pre-shared key and remote ID based on the
default configuration.
[LNS] ike peer spua
[LNS-ike-peer-spua] undo version 2
[LNS-ike-peer-spua] ike-proposal 5
[LNS-ike-peer-spua] pre-shared-key cipher Huawei@1234
[LNS-ike-peer-spua] remote-address 1.1.2.1
[LNS-ike-peer-spua] quit
Step 6 Create an IPSec policy.

# Configure an IPSec policy in IKE negotiation mode on the LAC.
[LAC] ipsec policy map1 10 isakmp
[LAC-ipsec-policy-isakmp-map1-10] ike-peer spub
[LAC-ipsec-policy-isakmp-map1-10] proposal tran1
[LAC-ipsec-policy-isakmp-map1-10] security acl 3101
[LAC-ipsec-policy-isakmp-map1-10] quit
# Configure an IPSec policy in IKE negotiation mode on the LNS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[LNS] ipsec policy use1 10 isakmp

[LNS-ipsec-policy-isakmp-use1-10] ike-peer spua
[LNS-ipsec-policy-isakmp-use1-10] proposal tran1
[LNS-ipsec-policy-isakmp-use1-10] security acl 3101
[LNS-ipsec-policy-isakmp-use1-10] quit
Step 7 Apply the IPSec policy group to an interface so that the interface can protect traffic.
# Apply an IPSec policy group to the interface of the LAC.
[LAC-GigabitEthernet1/0/0] ipsec policy map1
# Apply an IPSec policy group to the interface of the LNS.

[LNS-GigabitEthernet1/0/0] ipsec policy use1

After the configurations are complete, PC1 can ping PC2 successfully. The data transmitted
between PC1 and PC2 is encrypted. Run the display ipsec statistics command to view packet
statistics.
Run the display ike sa command on the LAC to view the SAs established through IKE
negotiation.
[LAC] display ike sa
--------------------------------------------------------------------------------
16 1.1.1.1:500 RD|ST v1:2 IP 1.1.1.1
14 1.1.1.1:500 RD|ST v1:1 IP 1.1.1.1
--------------------------------------------------------------------------------
Flag Description:
# Run the display l2tp tunnel command on the LAC or LNS to view L2TP tunnel and
session information. The command output for the LAC is shown as an example.
[LAC] display l2tp tunnel
Total tunnel : 1
1 1 1.1.1.1 1701 1 lns
----End
Configuration Files
l Configuration file of the LAC
#
sysname LAC
#
l2tp enable
#
acl number 3101
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
security acl 3101
ike-peer spub
proposal tran1
#
ppp chap password cipher %@%@U>upTZ}mQM:rhRL:4;s$,(xf%@%@
#
ip address 1.1.2.1 255.255.255.0
ipsec policy map1
#
ip address 10.1.10.1 255.255.255.0
#
l2tp-group 1
tunnel name lac
#
ip route-static 1.1.1.1 255.255.255.0 1.1.2.2
#
return
#
sysname LNS
#
l2tp enable
#
acl number 3101
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
security acl 3101
ike-peer spua
proposal tran1
#
ip pool 1
network 10.1.1.0 mask 255.255.255.0
#
aaa
local-user huawei password cipher $1a$_<`.CO&(:LeS/$#F
\H0Qv8B]KAZja3}3q'RNx;VI$
#
ip address 10.1.1.1 255.255.255.0
#
ip address 1.1.1.1 255.255.255.0
ipsec policy use1
#
ip address 10.1.2.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote lac
tunnel name lns
#
ip route-static 1.1.2.1 255.255.255.0 1.1.1.2
#
return
6.13.19 Example for Configuring a Tunnel Template Interface for

IPSec Tunnel Setup
As shown in Figure 6-60, enterprise's branch and headquarters communicate through the
public network. However, the topologies of headquarters and branch networks change
frequently. The enterprise requires to protect traffic transmitted over the public network
between the branch and headquarters, and the enterprise hopes that the IPSec configuration
does not change when the network topologies change.
1. The branch gateway RouterA and headquarters gateway RouterB can set up an IPSec
tunnel over the public network to protect traffic between them.
2. The topologies of headquarters and branch networks change frequently, the IPSec tunnel
needs to be set up using tunnel interfaces, and information about the subnet and interface
to be protected by IPSec needs to be configured locally.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-60 Configuring a virtual tunnel template interface for IPSec Tunnel setup
Tunnel0/0/0 Tunnel-Template0
192.168.1.1/24 192.168.1.2/24
IPSec Tunnel
RouterA RouterB
Branch gateway GE1/0/0 GE1/0/0 Headquarters gateway
GE2/0/0 GE2/0/0
1.1.1.1/24 2.1.1.1/24
10.1.1.1/24 10.1.2.1/24
PC A PC B
10.1.1.2/24 10.1.2.2/24
Branch subnet Headquarters
subnet
1. Configure IP addresses and static routes on the interfaces to implement communication

between them.
2. Configure ACLs to define the subnet that the local device needs to protect.
3. Configure AAA service schemes to define the subnet route information and the ip-
address interface that the local device needs to send.
4. Configure IPSec proposals to define the data flow protection method.
5. Configure IKE peers and define the attributes used for IKE negotiation.
6. Configure IPSec profiles, and apply the IPSec proposal and IKE peers to the IPSec
profile to define the data flows to be protected and protection method.
7. Apply the IPSec profiles to the tunnel template interface and tunnel interface
respectively to enable IPSec protection on the interfaces.
Procedure
Step 1 Configure IP addresses and static routes on the interfaces of RouterA and RouterB.
# Configure an IP address for each interface of RouterA.

# Configure a static route from RouterA to RouterB. This example assumes that the next hop
address of the route is 1.1.1.2.
# Configure an IP address for each interface of RouterB.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure a static route from RouterB to RouterA. This example assumes that the next hop
address of the route is 2.1.1.2.
Step 2 Configure ACLs to define the subnet that the local device needs to protect.
# Configure an ACL on RouterA to permit data flows with the source address 10.1.1.0/24 to
pass through.
[RouterA-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255
# Configure an ACL on RouterB to permit data flows with the source address 10.1.2.0/24 to
pass through.
[RouterB-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255
Step 3 Configure AAA service schemes to define the subnet route information that the local device
needs to send.
# Configure an AAA service scheme on RouterA.
[RouterA] aaa
[RouterA-aaa] service-scheme schemetest
[RouterA-aaa-service-schemetest] route set acl 3001
[RouterA-aaa-service-schemetest] route set interface
[RouterA-aaa-service-schemetest] quit
[RouterA-aaa] quit
# Configure an AAA service scheme on RouterB.

[RouterB] aaa
[RouterB-aaa] service-scheme schemetest
[RouterB-aaa-service-schemetest] route set acl 3001
[RouterB-aaa-service-schemetest] route set interface
[RouterB-aaa-service-schemetest] quit
[RouterB-aaa] quit


Run the display ipsec proposal command on RouterA and RouterB to view the configuration
of the IPSec proposal.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 5 Create IKE peers on RouterA and RouterB.


[RouterA] ike peer peer2
[RouterA-ike-peer-peer2] undo version 2
[RouterA-ike-peer-peer2] ike-proposal 5
[RouterA-ike-peer-peer2] pre-shared-key cipher Huawei@1234
[RouterA-ike-peer-peer2] service-scheme schemetest
[RouterA-ike-peer-peer2] config-exchange request
[RouterA-ike-peer-peer2] config-exchange set accept
[RouterA-ike-peer-peer2] config-exchange set send
[RouterA-ike-peer-peer2] route accept
[RouterA-ike-peer-peer2] quit


[RouterB] ike peer peer2
[RouterB-ike-peer-peer2] undo version 2
[RouterB-ike-peer-peer2] ike-proposal 5
[RouterB-ike-peer-peer2] pre-shared-key cipher Huawei@1234
[RouterB-ike-peer-peer2] service-scheme schemetest
[RouterB-ike-peer-peer2] config-exchange set accept
[RouterB-ike-peer-peer2] config-exchange set send
[RouterB-ike-peer-peer2] route accept
[RouterB-ike-peer-peer2] quit
Step 6 Create IPSec profiles on RouterA and RouterB respectively.

[RouterA-ipsec-profile-profile1] proposal prop1
[RouterA-ipsec-profile-profile1] ike-peer peer2

[RouterB-ipsec-profile-profile1] proposal prop1
[RouterB-ipsec-profile-profile1] ike-peer peer2
Step 7 Apply the IPSec profiles to the interfaces of RouterA and RouterB.
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet1/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Apply the IPSec profile to the interface of RouterB.

[RouterB] interface loopback0
[RouterB-LoopBack0] ip address 192.168.1.2 255.255.255.255
[RouterB-LoopBack0] quit
[RouterB] interface tunnel-template 0
[RouterB-Tunnel-Template0] ip address unnumbered interface loopback0
[RouterB-Tunnel-Template0] tunnel-protocol ipsec
[RouterB-Tunnel-Template0] source gigabitethernet1/0/0
[RouterB-Tunnel-Template0] ipsec profile profile1
[RouterB-Tunnel-Template0] quit
# Run the display ipsec profile command on RouterA and RouterB to view the IPSec profile
configuration.
--------------------------------------------------------------------------------
16 2.1.1.1:500 RD|ST v1:2 IP 2.1.1.1
14 2.1.1.1:500 RD|ST v1:1 IP 2.1.1.1
--------------------------------------------------------------------------------
# Run the display ip routing-table command on RouterA and RouterB to view route
information. This example only shows information about subnet routes that are successfully
sent.
------------------------------------------------------------------------------
10.1.2.0/24 Unr 0 0 D 192.168.1.2 Tunnel0/0/0

[RouterB] display ip routing-table
------------------------------------------------------------------------------
10.1.1.0/24 Unr 62 0 RD 192.168.1.1 Tunnel-Template0
----End
Configuration Files
#
sysname RouterA
#
acl number 3001
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer peer2
undo version 2
ike-proposal 5
service-scheme schemetest
route accept
config-exchange request
config-exchange set accept
config-exchange set send
#
ike-peer peer2
proposal prop1
#
aaa
route set acl 3001
route set interface
#
ip address 1.1.1.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
destination 2.1.1.1
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
#
return
#
sysname RouterB
#
acl number 3001
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer peer2
undo version 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ike-proposal 5
route accept
config-exchange set accept
config-exchange set send
#
ike-peer peer2
proposal prop1
#
aaa
route set acl 3001
route set interface
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
interface Tunnel-Template0
ip address unnumbered interface LoopBack0
#
interface LoopBack0
ip address 192.168.1.2 255.255.255.255
#
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
#
return
6.13.20 Example for Establishing an IPSec Tunnel Using an

Efficient VPN Policy in Client Mode
As shown in Figure 6-61, RouterA (remote small-scale branch gateway) and RouterB
(headquarters gateway) communicate through the Internet. The headquarters and branch
networks are not planned uniformly. The branch subnet is 10.1.1.0/24 and the headquarters
subnet is 10.1.2.0/24. The DHCP server is located on the headquarters network and allocates
an IP address to the branch gateway.
The enterprise requires that traffic between headquarters and branch networks should be
securely transmitted and the headquarters gateway should manage the branch gateway with
simplified configuration in centralized manner. An Efficient VPN policy in client mode can
be used to establish an IPSec tunnel to protect traffic. This method facilitates IPSec tunnel
establishment and maintenance.
In client mode, RouterA requests an IP address from RouterB to establish an IPSec tunnel,
and requests the DNS domain name, DNS server IP addresses, and WINS server IP addresses
for the branch subnet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-61 Establishing an IPSec tunnel using an Efficient VPN policy in client mode
DHCP Server
GE3/0/0
10.1.3.1/24
RouterA RouterB
Remote Server
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24
Headquarters
Branch subnet
subnet
2. Configure the DHCP server address on RouterB so that IP addresses can be dynamically
allocated through DHCP.
3. Configure RouterB as the responder to use an IPSec policy template to establish an
IPSec tunnel with RouterA.
4. Configure an Efficient VPN policy in client mode on RouterA. RouterA as the initiator
establishes an IPSec tunnel with RouterB.
Procedure
# Assign an IP address to an interface on RouterB. The IP address of GigabitEthernet4/0/0

must be on the same network segment as the IP address assigned by the DHCP server.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 2 Configure the DHCP server address on RouterB so that IP addresses can be dynamically
allocated through DHCP.
# Enable DHCP, create a DHCP server group, and add DHCP servers to the DHCP server
group.
[RouterB] dhcp enable
[RouterB] dhcp server group dhcp-ser1
[RouterB-dhcp-server-group-dhcp-ser1] dhcp-server 10.1.3.2
[RouterB-dhcp-server-group-dhcp-ser1] gateway 100.1.1.3
[RouterB-dhcp-server-group-dhcp-ser1] quit
Step 3 Configure RouterB as the responder to use an IPSec policy template to establish an IPSec
tunnel with RouterA.
# In the service scheme view, configure the resources to be allocated, including the IP
address, DNS domain name, DNS server IP addresses, and WINS server IP addresses.
[RouterB] aaa
[RouterB-aaa-service-schemetest] dhcp-server group dhcp-ser1
[RouterB-aaa-service-schemetest] dns-name mydomain.com.cn
[RouterB-aaa-service-schemetest] dns 2.2.2.2
[RouterB-aaa-service-schemetest] dns 2.2.2.3 secondary
[RouterB-aaa-service-schemetest] wins 3.3.3.2
[RouterB-aaa-service-schemetest] wins 3.3.3.3 secondary
[RouterB-aaa] quit
# Configure an IKE proposal and an IKE peer, and bind the service scheme to the IKE peer.
[RouterB-ike-peer-rut3] pre-shared-key cipher huawei
[RouterB-ike-peer-rut3] service-scheme schemetest
# Configure an IPSec proposal and establish an IPSec policy using an IPSec policy template.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Apply the IPSec policy to an interface.

Step 4 Configure an Efficient VPN policy in client mode on RouterA to establish an IPSec tunnel.
# Configure an Efficient VPN policy in client mode and specify the remote address and pre-
shared key.
[RouterA] ipsec efficient-vpn evpn mode client
[RouterA-ipsec-efficient-vpn-evpn] remote-address 60.1.2.1 v1
[RouterA-ipsec-efficient-vpn-evpn] pre-shared-key cipher huawei
[RouterA-ipsec-efficient-vpn-evpn] dh group14
[RouterA-ipsec-efficient-vpn-evpn] quit
# Apply the Efficient VPN policy to the interface.

[RouterA-GigabitEthernet1/0/0] ipsec efficient-vpn evpn

-----------------------------------------------------------------------------
26 60.1.2.1:500 RD|ST v1:2 IP 60.1.2.1
25 60.1.2.1:500 RD|ST v1:1 IP 60.1.2.1
-----------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
ipsec efficient-vpn evpn mode client
remote-address 60.1.2.1 v1
dh group14
#
ip address 60.1.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipsec efficient-vpn evpn

#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
dhcp enable
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut3
undo version 2
ike-proposal 5
#
ike-peer rut3
proposal prop1
#
#
dhcp server group dhcp-ser1
dhcp-server 10.1.3.2 0
gateway 100.1.1.3
#
aaa
dns 2.2.2.2
dns 2.2.2.3 secondary
dhcp-server group dhcp-ser1
wins 3.3.3.2
wins 3.3.3.3 secondary
dns-name mydomain.com.cn
#
ip address 60.1.2.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 100.1.1.3 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
ip route-static 100.1.1.0 255.255.255.0 60.1.2.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
6.13.21 Example for Configuring an IPSec Tunnel Using an

Efficient VPN Policy in Network Mode
As shown in Figure 6-62, RouterA (remote branch gateway) and RouterB (headquarters
gateway) communicate through the Internet. The headquarters and branch networks are
planned uniformly. The branch subnet is 10.1.1.0/24 and the headquarters subnet is
10.1.2.0/24.
simplified configuration in centralized manner. An Efficient VPN policy in network mode can
be used to establish an IPSec tunnel to protect traffic. This method facilitates IPSec tunnel
establishment and maintenance.
In network mode, RouterA does not request an IP address from RouterB, and uses the original
IP address to establish an IPSec tunnel with RouterB. RouterA applies to RouterB for the
DNS domain name, DNS server IP addresses, and WINS server IP addresses for the branch
subnet.
Figure 6-62 Establishing an IPSec tunnel using an Efficient VPN policy in network mode
RouterA RouterB
Remote Server
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24

subnet
2. Configure an Efficient VPN policy in network mode on RouterA. RouterA as the
initiator establishes an IPSec tunnel with RouterB.
3. On RouterB, configure the resources to be allocated, including the DNS server IP
addresses, and WINS server IP addresses.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure

Step 2 Configure an Efficient VPN policy in network mode on RouterA. RouterA as the initiator
[RouterA-acl-adv-3001] rule 1 permit ip source 10.1.1.2 0.0.0.255 destination
10.1.2.2 0.0.0.255
# Configure an Efficient VPN policy in network mode and specify the ACL, remote address,
and pre-shared key.
[RouterA] ipsec efficient-vpn evpn mode network
[RouterA-ipsec-efficient-vpn-evpn] security acl 3001
[RouterA-ipsec-efficient-vpn-evpn] pre-shared-key cipher Huawei@1234

# In the service scheme view, configure the resources to be allocated, including the DNS
domain name, DNS server IP addresses, and WINS server IP addresses.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterB] aaa
[RouterB-aaa] quit
# Configure an IKE proposal and an IKE peer.


-----------------------------------------------------------------------------
26 60.1.2.1:500 RD|ST v1:2 IP 60.1.2.1
25 60.1.2.1:500 RD|ST v1:1 IP 60.1.2.1
-----------------------------------------------------------------------------
Flag Description:
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname RouterA
#
acl number 3001
#
ipsec efficient-vpn evpn mode network
security acl 3001
dh group14
#
ip address 60.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut3
undo version 2
ike-proposal 5
#
ike-peer rut3
proposal tran1
#
#
aaa
dns 2.2.2.2
wins 3.3.3.2
#
ip address 60.1.2.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
#
return
6.13.22 Example for Configuring an IPSec Tunnel Using an

Efficient VPN Policy in Network-Plus Mode
As shown in Figure 6-63, RouterA (remote branch gateway) and RouterB (headquarters
gateway) communicate through the Internet. The headquarters and branch networks are
planned uniformly. The branch subnet is 10.1.1.0/24 and the headquarters subnet is
10.1.2.0/24.
simplified configuration in centralized manner. Ping and Telnet techniques are used for
management and maintenance. An Efficient VPN policy in network-plus mode can be used to
establish an IPSec tunnel to protect traffic. This method facilitates IPSec tunnel establishment
and maintenance.
In network-plus mode, RouterA requests an IP address from RouterB to establish an IPSec
tunnel, and requests the DNS domain name, DNS server IP addresses, and WINS server IP
addresses for the branch subnet. The obtained IP address is used for the headquarters to
perform ping and Telnet operations for the branch.
Figure 6-63 Establishing an IPSec tunnel using an Efficient VPN policy in network-plus
mode
RouterA RouterB
Remote Server
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24

subnet
2. Configure an Efficient VPN policy in network-plus mode on RouterA. RouterA as the
3. On RouterB, configure the resources to be allocated, including the IP address, DNS
domain name, DNS server IP addresses, and WINS server IP addresses.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Procedure

Step 2 Configure an Efficient VPN policy in network-plus mode on RouterA. RouterA as the
[RouterA-acl-adv-3001] rule 1 permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
# Configure an Efficient VPN policy in network-plus mode and specify the ACL, remote
address, and pre-shared key.
[RouterA] ipsec efficient-vpn evpn mode network-plus
[RouterA-ipsec-efficient-vpn-evpn] security acl 3001


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure the resources to be allocated, including the IP address, DNS domain name, DNS
server IP addresses, and WINS server IP addresses.
[RouterB] ip pool po1
[RouterB-ip-pool-po1] network 100.1.1.0 mask 255.255.255.128
[RouterB-ip-pool-po1] gateway-list 100.1.1.1
[RouterB-ip-pool-po1] quit
[RouterB] aaa
[RouterB-aaa-service-schemetest] ip-pool po1
[RouterB-aaa] quit

[RouterB-ike-peer-rut3] exchange-mode aggressive


---------------------------------------------------------------------------
118 60.1.2.1:500 RD|ST v1:2 IP 60.1.2.1
117 60.1.2.1:500 RD|ST v1:2 IP 60.1.2.1
116 60.1.2.1:500 RD|ST v1:1 IP 60.1.2.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
---------------------------------------------------------------------------
Flag Description:
----End
Configuration Files
#
sysname RouterA
#
acl number 3001
#
ipsec efficient-vpn evpn mode network-plus
security acl 3001
dh group14
#
ip address 60.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut3
undo version 2
ike-proposal 5
#
ike-peer rut3
proposal tran1
#
#
ip pool po1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network 100.1.1.0 mask 255.255.255.128

#
aaa
dns 2.2.2.2
ip-pool po1
wins 3.3.3.2
#
ip address 60.1.2.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
ip route-static 100.1.1.0 255.255.255.0 60.1.2.2
#
return
6.13.23 Example for Configuring Efficient VPN in Network-auto-

cfg Mode to Establish an IPSec Tunnel
As shown in Figure 6-64, Router_1 is a remote enterprise branch gateway and Router_2 is
the enterprise headquarters gateway. The branch connects to the headquarters over the LTE
network. The headquarters and branch networks are planned beforehand.
The enterprise requires to protect traffic transmitted between the enterprise branch and
headquarters. The headquarters gateway is required to uniformly manage and maintain the
branch gateway with simple configuration using the ping and Telnet technologies. The
enterprise branch and headquarters communicate over the LTE network. An IPSec tunnel can
be established between them using Efficient VPN in Network-auto-cfg mode to provide
security protection. This mode facilitates establishment, management, and maintenance of the
IPSec tunnel.
In Efficient VPN Network-auto-cfg mode, Router_1 applies for authorization information
from the RADIUS server located in the headquarters. The authorization information includes
an IP address for establishing the IPSec tunnel, an IP address pool for allocating addresses to
users, a DNS domain name, DNS server addresses, and WINS server addresses used by the
branch users. The headquarters uses the IP address to perform ping, Telnet, or other
management and maintenance operations.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-64 Configuring Efficient VPN in Network-auto-cfg mode to establish an IPSec

tunnel
Router_1 Router_2
Remote LTE network Server
branch Headquarters
GE1/0/0 gateway
gateway Cellular0/0/0 2.1.1.2/24 GE2/0/0
192.168.2.1/24
IPSec Tunnel
Branch Headquarters
RADIUS server
192.168.10.1/24
1. Configure a Cellular interface on Router_1 to connect it to the LTE network.
2. Configure static routes to ensure that the devices are reachable to each other over the
LTE network.
3. Configure a RADIUS server template on Router_2.
4. Configure Router_2 as the responder to establish an IPSec tunnel with Router_1 in
policy template mode.
5. Configure Efficient VPN in Network-auto-cfg mode on Router_1 to initiate an IPSec
tunnel establishment request to Router_2.
Procedure
Step 1 Configure a Cellular interface and an APN profile.
[Router_1] dialer-rule
[Router_1-dialer-rule] dialer-rule 1 ip permit
[Router_1-dialer-rule] quit
[Router_1] interface cellular 0/0/0
[Router_1-Cellular0/0/0] dialer enable-circular
[Router_1-Cellular0/0/0] ip address negotiate
[Router_1-Cellular0/0/0] dialer-group 1
[Router_1-Cellular0/0/0] dialer number *99#
[Router_1-Cellular0/0/0] mode lte auto
[Router_1-Cellular0/0/0] quit
[Router_1] apn profile lteprofile
[Router_1-apn-profile-lteprofile] apn LTENET
[Router_1-apn-profile-lteprofile] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Router_1-Cellular0/0/0] apn-profile lteprofile
[Router_1-Cellular0/0/0] shutdown
[Router_1-Cellular0/0/0] undo shutdown
After Cellular0/0/0 dials up successfully, it obtains the IP address 2.1.10.1/24.

Step 2 Configure IP addresses for the interfaces of Router_2.
Step 3 Configure static routes to ensure that the devices are reachable to each other over the LTE
network.
[Router_1] ip route-static 0.0.0.0 0 cellular 0/0/0
[Router_2] ip route-static 0.0.0.0 0 2.1.1.1
Step 4 Configure a RADIUS server template on Router_2.

[Router_2] radius-server template shiva
[Router_2-radius-shiva] radius-server authentication 192.168.10.1 1812
[Router_2-radius-shiva] radius-server accounting 192.168.10.1 1813
[Router_2-radius-shiva] radius-server shared-key cipher hello
[Router_2-radius-shiva] quit
[Router_2] aaa
[Router_2-aaa] authentication-scheme rds
[Router_2-aaa-authen-rds] authentication-mode radius
[Router_2-aaa-authen-rds] quit
[Router_2-aaa] domain rds
[Router_2-aaa-domain-rds] authentication-scheme rds
[Router_2-aaa-domain-rds] radius-server shiva
[Router_2-aaa-domain-rds] quit
[Router_2-aaa] quit
Step 5 Configure Router_2 as the responder to establish an IPSec tunnel with Router_1 in policy
template mode.
[Router_2] ike peer rut1
[Router_2-ike-peer-rut1] undo version 2
[Router_2-ike-peer-rut1] exchange-mode aggressive
[Router_2-ike-peer-rut1] pre-shared-key cipher Huawei@1234
[Router_2-ike-peer-rut1] ike-proposal 1
[Router_2-ike-peer-rut1] aaa authorization domain rds
[Router_2-ike-peer-rut1] quit
# Configure an IPSec proposal and an IPSec policy using the policy template.
[Router_2] ipsec proposal prop1
[Router_2-ipsec-proposal-prop1] undo esp authentication-algorithm
[Router_2-ipsec-proposal-prop1] undo esp encryption-algorithm
[Router_2-ipsec-proposal-prop1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router_2] ipsec policy-template temp1 10

[Router_2-ipsec-policy-templet-temp1-10] ike-peer rut1
[Router_2-ipsec-policy-templet-temp1-10] proposal prop1
[Router_2-ipsec-policy-templet-temp1-10] quit
[Router_2] ipsec policy policy1 10 isakmp template temp1
# Apply the IPSec policy group to the interface.

[Router_2-GigabitEthernet1/0/0] ipsec policy policy1
Step 6 Configure Efficient VPN in Network-auto-cfg mode on Router_1 to establish an IPSec tunnel.
# Set the Efficient VPN mode to Network-auto-cfg, and specify the remote address and pre-
shared key for IKE negotiation in the Network-auto-cfg mode view.
[Router_1] ipsec efficient-vpn evpn mode network-auto-cfg
[Router_1-ipsec-efficient-vpn-evpn] remote-address 2.1.1.2 v1
[Router_1-ipsec-efficient-vpn-evpn] pre-shared-key cipher Huawei@1234
[Router_1-ipsec-efficient-vpn-evpn] sim-based-username type imsi password
huawei@123
[Router_1-ipsec-efficient-vpn-evpn] dh group14
[Router_1-ipsec-efficient-vpn-evpn] quit
# Apply Efficient VPN to the interface.

[Router_1-Cellular0/0/0] ipsec efficient-vpn evpn

# After the configurations are complete, perform the ping operation on Router_1. Router_1
can still ping Router_2 successfully.
[Router_1] ping 2.1.1.2

0.00% packet loss
# Run the display ipsec sa brief command on Router_1 and Router_2 respectively to check
whether an IPSec SA is successfully negotiated. The command output on Router_1 is used as
an example.
[Router_1] display ipsec sa brief
Src address Dst address SPI VPN Protocol Algorithm
-------------------------------------------------------------------------------
2.1.10.1 2.1.1.2 2622706230 0 ESP
2.1.10.1 2.1.1.2 3375760671 0 ESP
2.1.1.2 2.1.10.1 645145990 0 ESP
2.1.1.2 2.1.10.1 3429582856 0 ESP
----End
Configuration Files

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname Router_1
#
ipsec efficient-vpn evpn mode network-auto-cfg
sim-based-username type imsi password %^
%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
dh group14
#
interface Cellular0/0/0
dialer enable-circular
dialer-group 1
apn-profile lteprofile
dialer timer autodial 10
dialer number *99#
ip address negotiate
mode lte auto
#
#
dialer-rule
#
apn profile lteprofile
apn LTENET
#
return
#
sysname Router_2
#
radius-server template shiva
radius-server shared-key cipher %#%#R,T#A1Imu&K9;*-wF=/
2x{Ib*(^v><;=s*)mBup9%#%
radius-server authentication 192.168.10.1 1812 weight 80
radius-server accounting 192.168.10.1 1813 weight 80
#
undo esp authentication-algorithm
undo esp encryption-algorithm
#
ike proposal 1
aes-256
dh
group14
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 1
aaa authorization domain rds
#
ike-peer rut1
proposal prop1
#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
aaa
authentication-scheme rds
authentication-mode radius
domain rds
authentication-scheme rds
radius-server shiva
#
ip address 2.1.1.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 2.1.1.1
#
return
6.13.24 Example for Configuring Automatic Upgrade of the

Efficient VPN Remote Device
As shown in Figure 6-65, RouterA (remote small-sized branch gateway) and RouterB
(headquarters gateway) communicate through the Internet. The branch subnet is 10.1.1.0/24
and the headquarters subnet is 10.1.2.0/24. The branch gateway can download upgrade files
from the FTP server. The branch gateway and headquarters gateway establish an IPSec tunnel
to protect data flows using an Efficient VPN policy in client mode. Efficient VPN facilitates
IPSec tunnel establishment and maintenance.
The enterprise requires that RouterA should obtain the FTP server IP address and network
resources from RouterB through the IPSec tunnel to implement automatic upgrade so that the
headquarters can manage the branch in centralized manner. Network deployment and
maintenance can be also improved.
Figure 6-65 Configuring automatic upgrade of the Efficient VPN remote device
FTP Server
70.1.1.1/24
RouterA RouterB
Remote Server
GE2/0/0 60.1.1.1/24 60.1.2.1/24 GE2/0/0
10.1.1.1/24 10.1.2.1/24
IPSec Tunnel
PC A PC B
10.1.1.2/24 10.1.2.2/24

subnet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2. Prepare the *.ini file on the FTP server. This file provides guidance for the upgrade of
the branch gateway.
3. Configure an Efficient VPN policy in client mode on RouterA. RouterA as the initiator
After the device is upgraded, the original configuration is deleted. You can save the original
configuration before the upgrade or write the required configuration in the configuration file
for upgrade.
Procedure
Step 1 Prepare the huawei.ini file on the FTP server. This file provides guidance for the upgrade of
the branch gateway.
Format of the huawei.ini file:
MAC=5489-9874-
ce3b;vrpfile=devicesoft_nocounter.cc;vrpver=V200R003C00B160;patchfile=patch.pat;cfgfile
=cfg_1.cfg;restartflag=Y;location=nanjing;
The parameters are described as follows:
l MAC: MAC address of the branch device interface to which an Efficient VPN policy is
applied. The branch device downloads the version file, patch file, and configuration file
in which the MAC address is matched.
l vrpfile: path and file name of the version file. The file name extension of the version file
is *.cc.
l vrpver: version number of the version file on the server.
l patchfile: path and file name of the patch file. The file name extension of the patch file is
*.pat.
l cfgfile: path and file name of the configuration file on the server. The file name
extension of the configuration file can be *.cfg or *.zip.
l restartflag: whether the device needs to restart. Y indicates that the device needs to
restart. If hot patch files are used, the device does not need to restart. If cold patch files
or files of other types are used, the device needs to restart; otherwise, the device upgrade
fails.
l location: device location.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


Step 3 Configure an Efficient VPN policy in client mode on RouterA. RouterA as the initiator
# Configure an Efficient VPN policy in client mode and specify the remote address and pre-
shared key.
[RouterA] ipsec efficient-vpn evpn mode client

# Configure the URL and version number to be delivered in the service scheme view so that
the IKE peer can reference them.
[RouterB] ip pool poo1test
[RouterB-ip-pool-poo1test] network 100.1.1.0 mask 255.255.255.0
[RouterB-ip-pool-poo1test] gateway-list 100.1.1.2
[RouterB-ip-pool-poo1test] quit
[RouterB] aaa
[RouterB-aaa-service-schemetest] ip-pool poo1test
[RouterB-aaa-service-schemetest] auto-update url ftp://
username:userpassword@70.1.1.1/huawei.ini version 1
[RouterB-aaa] quit
NOTE
The branch gateway determines whether to perform the upgrade according to the version number in the auto-
update url command. The upgrade is performed only when the version to be delivered is later than the
current version of the branch gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterB] ike peer rut
[RouterB-ike-peer-rut] undo version 2
[RouterB-ike-peer-rut] exchange-mode aggressive
[RouterB-ike-peer-rut] pre-shared-key cipher Huawei@1234
[RouterB-ike-peer-rut] ike-proposal 5
[RouterB-ike-peer-rut] service-scheme schemetest
[RouterB-ike-peer-rut] quit
[RouterB-ipsec-policy-templet-temp1-10] ike-peer rut


--------------------------------------------------------------------------
117 60.1.2.1:500 RD|ST V1:2 IP 60.1.2.1
116 60.1.2.1:500 RD|ST V1:1 IP 60.1.2.1
--------------------------------------------------------------------------
Flag Description:
# Run the display ipsec efficient-vpn command on RouterA to view information about the
Efficient VPN policy. In the command output, Auto-update url and Auto-update version
indicate that the URL and version number are delivered to RouterA.
[RouterA] display ipsec efficient-vpn
===========================================
IPSec efficient-vpn name: evpn
Using interface : GigabitEthernet1/0/0
===========================================
IPSec Efficient-vpn Name : evpn
IPSec Efficient-vpn Mode : 1 (1:Client 2:Network 3:Network-plus 4:Network-auto-
cfg)
ACL Number :

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Auth Method : 8 (8:PSK 9:RSA)

VPN name :
Local ID Type : 1 (1:IP 2:Name 3:User-fqdn 9:DN 11:Key-id)
IKE Version : 1 (1:IKEv1 2:IKEv2)
Remote Address : 60.1.2.1 (selected)
Pre Shared Key Cipher : %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#
PFS Type : 0 (0:Disable 1:Group1 2:Group2 5:Group5 14:Group14
15:Group15 16:Group16)
Remote Name :
PKI Object :
Anti-replay window size : 32
Qos pre-classify : 0 (0:Disable 1:Enable)
Qos group : -
Service-scheme name :
DPD Msg Type : seq-notify-hash
Sim-based-username Type :
Interface loopback : LoopBack100
Interface loopback IP : 100.1.1.254/24
Dns server IP :
Wins server IP :
Dns default domain name :
Auto-update url : ftp://70.1.1.1/huawei.ini
Auto-update version : 1
IP pool :
# Run the display ipsec efficient-vpn remote command on RouterB to view device running
information including the device MAC address, version information, and whether the last
upgrade is successful.
# After an IPSec SA is established successfully, RouterA starts to download the version file,
patch file, and configuration file. Then RouterA restarts. Run the display startup command
to check whether the software version, configuration file, and patch file are target ones.
[RouterA] display startup
MainBoard:
Startup system software: sd1:/devicesoft_nocounter.cc
Next startup system software: sd1:/devicesoft_nocounter.cc
Backup system software for next startup: null
Startup saved-configuration file: sd1:/cfg_1.cfg
Next startup saved-configuration file: sd1:/cfg_1.cfg
Startup license file: null
Next startup license file: null
Startup patch package: sd1:/patch.pat
Next startup patch package: sd1:/patch.pat
Startup voice-files: null
Next startup voice-files: null
# Run the display patch-information command on RouterA to view the patch file version.
----End
Configuration Files
#
sysname RouterA
#
ipsec efficient-vpn evpn mode client
dh group14
#
ip address 60.1.1.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.1 255.255.255.0

#
ip route-static 60.1.2.0 255.255.255.0 60.1.1.2
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
#
ike proposal 5
aes-256
dh
group14
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer rut
undo version 2
ike-proposal 5
#
ike-peer rut
proposal prop1
#
#
ip pool poo1test
network 100.1.1.0 mask 255.255.255.0
#
aaa
ip-pool poo1test
auto-update url ftp://username:%#%#[HXY>~%M:~$uaIE@=Q.'gp=*B5]QO%zr>MIy+QuK
%#%#@70.1.1.1/huawei.ini version 1
#
ip address 60.1.2.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 60.1.1.0 255.255.255.0 60.1.2.2
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.13.25 Example for Configuring Rapid Switchover and Revertive

Switching
As shown in Figure 6-66, the branch communicates with the headquarters over the public
network. To improve reliability, the headquarters uses two gateways RouterA and RouterB to
connect to the branch gateway RouterC.
has the following requirements: Normally, the branch should communicate with the
headquarters through RouterA. Traffic should be switched to RouterB when RouterA
becomes faulty but back to RouterA when RouterA recovers.
Figure 6-66 Networking diagram for configuring rapid switchover and revertive switching
RouterA
Headquarters
gateway A
GE0/0/2
192.168.1.2/24
RouterC GE0/0/1
Branch gateway GE0/0/1
60.1.1.1/24
70.1.1.1/24
Headquarters
GE0/0/2
GE0/0/1
192.168.2.2/24
60.1.2.1/24
PC_2
GE0/0/2 192.168.1.1/24
192.168.1.2/24
RouterB
Branch
Headquarter
s gateway B
PC_1
192.168.2.1/24
Since the branch and headquarters communicate over the public network, you can set up an
IPSec tunnel between them to provide security protection. The configuration roadmap is as
follows:
1. Configure the IP address on each interface and static routes to the peer to implement
communication between interfaces.
2. Configure an NQA test instance to monitor the link between the branch gateway and
headquarters gateway A.
3. Configure ACLs to define the data flows to be protected by the IPSec tunnel.
4. Configure IPSec proposals to define the traffic protection methods.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. Create IKE peers and configure the device to determine the validity of the peer address
according to the NQA test instance status, so that traffic can be rapidly switched from
gateway A to gateway B when gateway A fails. Enable revertive switching of the IKE
peer to ensure that traffic can be switched back to gateway A when gateway A recovers.
6. Configure IPSec security policies to define the data protection methods.
7. Apply the IPSec policies to interfaces so that the interfaces can protect traffic.
Procedure
Step 1 Configure an IP address for each interface and static routes to the peer on RouterA, RouterB,
and RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface and static routes to the peer on RouterA. This
example assumes that the next hop address in the route to the branch gateway is 60.1.1.2.
# Configure an IP address for each interface and static routes to the peer on RouterB. This
# Configure an IP address for each interface and a static route to the peer on RouterC. This
example assumes that the next hop addresses in the route to the headquarters gateways A and
B are both 70.1.1.2.
Step 2 Configure an NQA test instance on RouterC.

# Configure an NQA test instance of ICMP type (administrator name admin and instance
name test) on RouterC to detect faults on the link 70.1.1.1/24 -> 60.1.1.1/24.
[RouterC] nqa test-instance admin test
[RouterC-nqa-admin-test] test-type icmp
[RouterC-nqa-admin-test] destination-address ipv4 60.1.1.1
[RouterC-nqa-admin-test] frequency 10
[RouterC-nqa-admin-test] probe-count 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC-nqa-admin-test] start now

[RouterC-nqa-admin-test] quit
Step 3 Configure an ACL on RouterA, RouterB, and RouterC respectively to define the data flows to
be protected.
# Configure an ACL on RouterA to define the data flows from subnet 192.168.1.0/24 to
subnet 192.168.2.0/24. The configuration of RouterB is similar to that of RouterA, and is not
provided here.
192.168.2.0 0.0.0.255
subnet 192.168.1.0/24.
192.168.1.0 0.0.0.255

# Create an IPSec proposal on RouterA. The configurations of RouterB and RouterC are
similar to that of RouterA, and are not provided here.
Step 5 Configure an IKE proposal and an IKE peer on RouterA, RouterB, and RouterC respectively.
# Configure an IKE proposal and an IKE peer on RouterA.
# Configure an IKE proposal and an IKE peer on RouterB.

# Configure an IKE proposal and IKE peer rut1 on RouterC, and set the address 60.1.1.1 to
take effect when the status of the NQA test instance is Up and the address 60.1.2.1 to take
effect when the status of the NQA test instance is Down.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[RouterC-ike-peer-rut1] pre-shared-key cipher Huawei@123
[RouterC-ike-peer-rut1] remote-address 60.1.1.1 track nqa admin test up
[RouterC-ike-peer-rut1] remote-address 60.1.2.1 track nqa admin test down
[RouterC-ike-peer-rut1] switch-back enable
Step 6 Configure an IPSec policy on RouterA, RouterB, and RouterC respectively.

# Configure an IPSec policy using an IPSec policy template on RouterA.
[RouterA] ipsec policy-template temp1 10
[RouterA-ipsec-policy-templet-temp1-10] ike-peer rut1
[RouterA-ipsec-policy-templet-temp1-10] proposal tran1
[RouterA-ipsec-policy-templet-temp1-10] quit
[RouterA] ipsec policy policy1 10 isakmp template temp1
# Configure an IPSec policy using an IPSec policy template on RouterB.

# Create an IPSec policy in ISAKMP mode on RouterC.

Step 7 Apply the IPSec policies to the corresponding interfaces on RouterA, RouterB, and RouterC
to make the interfaces able to protect traffic.
# Apply the IPSec policy to the interface of RouterA.

# Apply the IPSec policy to the interface of RouterC.


After completing the configuration:
1. PC_1 can ping PC_2 successfully and data transmitted between them is encrypted.
# Run the display ike sa command on RouterA and RouterB to view the IKE
configuration. The command output on RouterA is used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

---------------------------------------------------------------------------
24366 70.1.1.1:500 RD v1:2 IP 70.1.1.1
24274 70.1.1.1:500 RD v1:1 IP 70.1.1.1
---------------------------------------------------------------------------
Flag Description:
# Run the display ike sa command on RouterC. The command output is as follows:
--------------------------------------------------------------------------
937 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1
936 60.1.1.1:500 RD|ST v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
The command output shows that an IKE SA is successfully established between the
branch gateway and headquarters gateway A.
2. Disconnect the link from the Internet to the headquarters gateway A. The IP address of
the IKE peer changes to RouterB.
# After you disconnect the link from the Internet to the headquarters gateway A, run the
display nqa results test-instance admin test command on RouterC. The command
[RouterC] display nqa results test-instance admin
test
NQA entry(admin, test) :testflag is active ,testtype is

icmp
1 . Test 26 result The test is
finished
Send operation times: 2 Receive response times:
0
Completion:failed RTD OverThresholds number:
0
Attempts number:1 Drop operation number:
0
Disconnect operation number:0 Operation timeout number:
2
System busy operation number:0 Connection fail number:
0
Operation sequence errors number:0 RTT Status errors number:
0
Destination ip address:
60.1.1.1
Min/Max/Average Completion Time:
0/0/0
Sum/Square-Sum Completion Time:
0/0
Last Good Probe Time: 0000-00-00
00:00:00.0
Lost packet ratio: 100 %
......

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The command output shows that the status of gateway A is failed in NQA test results,
and the status of the NQA test instance is Down.
--------------------------------------------------------------------------
21576 60.1.2.1:500 RD v1:2 IP 60.1.2.1
21575 60.1.2.1:500 RD v1:1 IP 60.1.2.1
--------------------------------------------------------------------------
Flag Description:
The command output shows that the IKE peer address is 60.1.2.1, indicating that traffic
is switched to gateway B.
3. Recover the link from the Internet to the headquarters gateway A. The IP address of the
IKE peer changes to RouterA.
# After you recover the link from the Internet to the headquarters gateway A, run the
display nqa results test-instance admin test command on RouterC. The command
[RouterC] display nqa results test-instance admin
test
NQA entry(admin1, test) :testflag is active ,testtype is

icmp
finished
2
Completion:success RTD OverThresholds number:
0
0
0
0
0
60.1.1.1
3/4/3
7/25
16:38:07.3
Lost packet ratio:
0 %
......
The command output shows that the status of gateway A is success in NQA test results,
and the status of the NQA test instance is Up.
--------------------------------------------------------------------------
21578 60.1.1.1:500 RD|ST v1:2 IP 60.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
21577 60.1.1.1:500 RD|ST v1:1 IP 60.1.1.1
--------------------------------------------------------------------------
Flag Description:
The command output shows that the IKE peer address is 60.1.1.1, indicating that traffic
is switched back to gateway A. Rapid switchover and revertive switching are
successfully configured.
----End
Configuration Files
#
sysname RouterA
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %#%#u;3RGfy.^D2'oEC%wwnU](q"Y2O&b'L=,NI`-qWE%#%#
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
acl number 3002
0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.2.1 255.255.255.0
#
ip address 192.168.1.2 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
#
return
#
sysname RouterC
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
remote-address 60.1.1.1 track nqa admin test up
remote-address 60.1.2.1 track nqa admin test down
switch-back enable
#
security acl 3002
ike-peer rut1
proposal tran1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 70.1.1.1 255.255.255.0

#
ip address 192.168.2.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 70.1.1.2
#

test
test-type
icmp
60.1.1.1
frequency
10
probe-count
2
start now
#
return
6.13.26 Example for Configuring Redundancy Control of IPSec

Tunnels
As shown in Figure 6-67, the branch communicates with the headquarters over the public
network. To improve reliability, the headquarters uses two gateways RouterA and RouterB to
connect to the branch gateway RouterC. RouterC sets up IPSec Tunnel1 with RouterA
through GE0/0/1 and IPSec Tunnel2 with RouterB through GE0/0/2.
requires that traffic be switched to the other IPSec tunnel when one IPSec tunnel fails and
back to the faulty IPSec tunnel when the faulty IPSec tunnel recovers.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 6-67 Networking diagram for configuring redundancy control of IPSec tunnels
RouterA
Headquarters
gateway A
GE0/0/1 GE0/0/2
el1 192.168.1.1/24
RouterC 70.1.1.1/24 u nn
T
Branch ec VIP
IPS GE0/0/1
gateway 60.1.1.1/24
GE0/0/2 Headqua
70.1.2.1/24 GE0/0/1
GE0/0/0
60.1.2.1/24
192.168.2.2/24 IPSe PC_
c Tun 192.168.
nel2 GE0/0/2
RouterB
192.168.1.3/24
Branch Headquarters
gateway B
PC_1
192.168.2.1/24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Since the branch and headquarters communicate over the public network, you can set up an
IPSec tunnel between them to provide security protection. The configuration roadmap is as
follows:
1. Configure the IP address on each interface and static routes to the peer to implement
2. Configure an NQA group and an NQA test instance to monitor the link between the
branch gateway and headquarters gateway A.
3. Configure ACLs to define the data flows to be protected by the IPSec tunnel.
4. Configure IPSec proposals to define the traffic protection methods.
5. Configure IKE peers.
6. Configure IPSec security policies to define the data protection methods. Configure the
device to control IPSec tunnel setup and teardown according to the NQA group status
and enable the device to switch traffic to the other IPSec tunnel when one IPSec tunnel
becomes faulty.
7. Apply the IPSec policies to interfaces so that the interfaces can protect traffic.
NOTE
VRRP backup is configured on the two gateways in the headquarters. For detailed configuration, see VRRP
Configuration.
Procedure
Step 1 Configure an IP address for each interface and static routes to the peer on RouterA, RouterB,
and RouterC to ensure that there are reachable routes among them.
# Configure an IP address for each interface and static routes to the peer on RouterA. This
# Configure an IP address for each interface and static routes to the peer on RouterB. This

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure an IP address for each interface and static routes to the peer on RouterC. This
example assumes that the next hop addresses in the route to the headquarters gateways A and
B are 70.1.1.2 and 70.1.2.2, respectively.
Step 2 Configure an NQA test instance on RouterC.
# Configure an NQA test instance of ICMP type (administrator name admin and instance
name test) on RouterC to detect faults on the link 70.1.1.1/24 -> 60.1.1.1/24.
[RouterC] nqa test-instance admin test
[RouterC-nqa-admin-test] test-type icmp
[RouterC-nqa-admin-test] destination-address ipv4 60.1.1.1
[RouterC-nqa-admin-test] frequency 10
[RouterC-nqa-admin-test] probe-count 2
[RouterC-nqa-admin-test] start now
[RouterC-nqa-admin-test] quit
Step 3 Configure an ACL on RouterC to define the data flows to be protected.

NOTE
An IPSec policy is created on RouterA and RouterB using the IPSec policy template; therefore, this step
is optional. If you configure an ACL on RouterA and RouterB, you must specify the destination address
in the ACL rule.
subnet 192.168.1.0/24.
192.168.1.0 0.0.0.255
# Create an IPSec proposal on RouterA. The configurations of RouterB and RouterC are
similar to that of RouterA, and are not provided here.
Step 5 Configure an IKE proposal and an IKE peer on RouterA, RouterB, and RouterC respectively.
NOTE
RouterA and RouterB function as responders to respond to an IKE negotiation request; therefore, IPSec
policies are created on them through IPSec policy templates. You do not need to set remote-address.
# Configure an IKE proposal and an IKE peer on RouterA.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure an IKE proposal and an IKE peer on RouterB.

# Configure an IKE proposal and IKE peer rut1 and rut2 on RouterC.
Step 6 Create an IPSec policy on RouterA, RouterB, and RouterC respectively.

# Create an IPSec policy through an IPSec policy template on RouterA.
[RouterA] ipsec policy-template temp1 10
[RouterA-ipsec-policy-templet-temp1-10] ike-peer rut1
[RouterA-ipsec-policy-templet-temp1-10] proposal tran1
[RouterA-ipsec-policy-templet-temp1-10] quit
[RouterA] ipsec policy policy1 10 isakmp template temp1
# Create an IPSec policy through an IPSec policy template on RouterB.

# Create IPSec policies policy1 and policy2 in ISAKMP mode on RouterC.

[RouterC-ipsec-policy-isakmp-policy1-10] connect track nqa admin test up
[RouterC-ipsec-policy-isakmp-policy1-10] disconnect track nqa admin test down

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC-ipsec-policy-isakmp-policy2-20] connect track nqa admin test down
[RouterC-ipsec-policy-isakmp-policy2-20] disconnect track nqa admin test up
Step 7 Apply the IPSec policies to the corresponding interfaces on RouterA, RouterB, and RouterC
to make the interfaces able to protect traffic.
# Apply the IPSec policy to the interface of RouterA.

# Apply the IPSec policies to the interfaces of RouterC.


After completing the configuration:
1. PC_1 can ping PC_2 successfully and data transmitted between them is encrypted.
# Run the display ipsec sa command on RouterC to check the IPSec configuration.
[RouterC] display ipsec sa
===============================
Interface:
Path MTU:
1500
===============================
-----------------------------
IPSec policy name:
"policy1"
Sequence number :
10
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21812

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Encapsulation mode:
Tunnel
Tunnel local :
70.1.1.1
Tunnel remote :
60.1.1.1
Flow source : 192.168.2.0/255.255.255.0
0/0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 870098030
(0x33dca46e)
Proposal: ESP-ENCRYPT-AES-128
SHA2-256-128
SA remaining key duration (bytes/sec):
1887436800/3395
0
N
[Inbound ESP
SAs]
SPI: 2558349639
(0x987d5147)
SHA2-256-128
1887436800/3395
0
Anti-replay window size:
32
The command output shows that traffic from PC_1 to PC_2 is transmitted over IPSec
Tunnel1 (source IP address: 70.1.1.1, destination IP address: 60.1.1.1).
2. Disable GE0/0/1 of RouterC. Traffic is switched to IPSec Tunnel2 (source IP address:
70.1.2.1/24, destination IP address: 60.1.2.1/24).
# Run the shutdown command on GE0/0/1 of RouterC, and then run the display nqa
results test-instance admin test command. The command output is as follows:
[RouterC] display nqa results test-instance admin test

icmp
finished
0
Completion:failed RTD OverThresholds number:
0
2
0
0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0
60.1.1.1
0/0/0
0/0
00:00:00.0
......
The command output shows that the NQA test result is failed, indicating that the status
of the NQA test instance is Down.
===============================
Interface:
Path MTU:
1500
===============================
-----------------------------
IPSec policy name:
"policy2"
Sequence number :
20
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21839
Encapsulation mode:
Tunnel
Tunnel local :
70.1.2.1
Tunnel remote :
60.1.2.1
Flow source : 192.168.2.0/255.255.255.0
0/0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 437762941
(0x1a17bb7d)
SHA2-256-128
1887436800/3575

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0
N
[Inbound ESP
SAs]
SPI: 1765690761
(0x693e4d89)
SHA2-256-128
1887436800/3575
0
32
The command output shows that traffic is switched to IPSec Tunnel2 (source IP address:
70.1.2.1, destination IP address: 60.1.2.1).
3. Enable GE0/0/1 of RouterC again. Traffic is switched back to IPSec Tunnel1 (source IP
address: 70.1.1.1, destination IP address: 60.1.1.1).
# Run the undo shutdown command on GE0/0/1 of RouterC, and then run the display
nqa results test-instance admin test command. The command output is as follows:
[RouterC] display nqa results test-instance admin test

icmp
finished
2
Completion:success RTD OverThresholds number:
0
0
0
0
0
60.1.1.1
4/4/4
8/32
20:43:23.2
......
The command output shows that the NQA detection result is success, indicating that the
status of the NQA test instance is Up.
===============================
Interface:
Path MTU:
1500

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
===============================
-----------------------------
IPSec policy name:
"policy1"
Sequence number :
10
Acl group :
3002
Acl rule :
5
Mode :
ISAKMP
-----------------------------
Connection ID :
21992
Encapsulation mode:
Tunnel
Tunnel local :
70.1.1.1
Tunnel remote :
60.1.1.1
Flow source : 192.168.2.0/255.255.255.0
0/0
0/0
Qos pre-classify :
Disable
Qos group :
-
[Outbound ESP
SAs]
SPI: 2749069243
(0xa3db77bb)
SHA2-256-128
1887436800/3583
0
N
[Inbound ESP
SAs]
SPI: 21830677
(0x14d1c15)
SHA2-256-128
1887436800/3583
0
32
The command output shows that traffic is switched back to IPSec Tunnel1 (source IP
address: 70.1.1.1, destination IP address: 60.1.1.1). The configuration succeeds.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname RouterA
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 60.1.1.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.1.2
ip route-static 70.1.2.0 255.255.255.0 60.1.1.2
ip route-static 192.168.2.0 255.255.255.0 60.1.1.2
#
return

#
sysname RouterB
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 60.1.2.1 255.255.255.0
#
ip address 192.168.1.3 255.255.255.0
#
ip route-static 70.1.1.0 255.255.255.0 60.1.2.2
ip route-static 70.1.2.0 255.255.255.0 60.1.2.2
ip route-static 192.168.2.0 255.255.255.0 60.1.2.2
#
return
#
sysname RouterC
#
acl number 3002
0.0.0.255
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike peer rut2
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
connect track nqa admin test up
disconnect track nqa admin test down
#
security acl 3002
ike-peer rut2
proposal tran1
connect track nqa admin test down
disconnect track nqa admin test up
#
ip address 192.168.2.2 255.255.255.0
#
ip address 70.1.1.1 255.255.255.0
#
ip address 70.1.2.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip route-static 60.1.1.0 255.255.255.0 70.1.1.2

ip route-static 60.1.2.0 255.255.255.0 70.1.2.2
ip route-static 192.168.1.0 255.255.255.0 70.1.1.2
ip route-static 192.168.1.0 255.255.255.0 70.1.2.2
#
nqa test-instance admin test

test-type
icmp
60.1.1.1
frequency
10
probe-count
2
start now
#
nqa-group group1
nqa admin test
#
return
6.13.27 Example for Configuring IPSec Gateway Redundancy

Control
In Figure 6-68, the branch communicates with the headquarters over the Internet. To improve
reliability, the branch connects to the headquarters gateway RouterC through two branch
gateways RouterA and RouterB, and the two branch gateways form a VRRP group to
implement gateway redundancy.
The enterprise wants traffic transmitted between the branch and headquarters to be protected.
If the master device RouterA is faulty, the backup device RouterB takes over as the master
device. After RouterA recovers from the failure, it becomes the master device again to act as
the gateway.
Figure 6-68 Configuring IPSec gateway redundancy control
RouterA
Branch gateway
GE0/0/2 GE0/0/1
10.1.1.1/24 1.1.1.1/24
RouterC
Headquarters
IPSec tunnel gateway
Headqu
Branch VRRP GE0/0/1 GE0/0/2
VIP:10.1.1.11 2.1.1.1/24 10.2.1.1/24
PC_2
GE0/0/2 GE0/0/1
PC_1 10.2.1.2/
10.1.1.2/24 1.1.2.1/24
10.1.1.3/24
RouterB
Branch gateway

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An IPSec tunnel can be established between the headquarters gateway and branch gateway to
protect traffic transmitted between the headquarters and branch over the Internet. The
configuration roadmap is as follows:
1. Configure IP addresses for interfaces and configure static routes to the remote end to
ensure that there are reachable routes between two ends.
2. Configure a VRRP group on RouterA and RouterB to implement gateway redundancy.
3. Configure an ACL on RouterA and RouterB to define IPSec-protected data flows.
5. Configure an IKE peer.
6. Configure an IPSec policy to protect data flows.
– Configure RouterA and RouterB to control IPSec tunnel setup or teardown
according to the VRRP status. This configuration ensures that traffic can be
switched to the other gateway for transmission after one gateway is faulty.
– Configure an IPSec policy using an IPSec policy template on RouterC to respond to
the branch gateway access request.
7. Apply the IPSec policy to interfaces to enable IPSec protection.
Procedure
Step 1 Configure IP addresses for interfaces and configure static routes to the remote end to ensure
that there are reachable routes between RouterA, RouterB, and RouterC.
# On RouterA, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the headquarters
gateway is 1.1.1.2.
[RouterA] ip route-static 0.0.0.0 0 1.1.1.2
# On RouterB, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the headquarters
gateway is 1.1.2.2.
[RouterB] ip route-static 0.0.0.0 0 1.1.2.2
# On RouterC, configure IP addresses for interfaces and configure a static route to the remote
end. This example assumes that the next-hop address of the static route to the branch gateway
is 2.1.1.2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC] ip route-static 0.0.0.0 0 2.1.1.2
Step 2 Configure a VRRP group on RouterA and RouterB.

# Configure VRRP group 1 on RouterA, and set the VRRP priority of RouterA to 120 and the
preemption delay to 20s.
[RouterA-GigabitEthernet0/0/2] vrrp vrid 1 virtual-ip 10.1.1.11
[RouterA-GigabitEthernet0/0/2] vrrp vrid 1 priority 120
[RouterA-GigabitEthernet0/0/2] vrrp vrid 1 preempt-mode timer delay 20
# Configure VRRP group 1 on RouterB, and set the VRRP priority of RouterB to 80.
[RouterB-GigabitEthernet0/0/2] vrrp vrid 1 virtual-ip 10.1.1.11
[RouterB-GigabitEthernet0/0/2] vrrp vrid 1 priority 80
10.2.1.0 0.0.0.255
10.2.1.0 0.0.0.255
Step 4 Configure an IPSec proposal.

Step 5 Configure an IKE proposal and an IKE peer.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 6 Configure an IPSec policy.

# Configure an IPSec policy in ISAKMP mode on RouterA.
[RouterA-ipsec-policy-isakmp-policy1-10] connect track vrrp 1 interface
gigabitethernet 0/0/2 master
[RouterA-ipsec-policy-isakmp-policy1-10] disconnect track vrrp 1 interface
gigabitethernet 0/0/2 backup
# Configure an IPSec policy in ISAKMP mode on RouterB.

[RouterB-ipsec-policy-isakmp-policy1-10] connect track vrrp 1 interface
gigabitethernet 0/0/2 master
[RouterB-ipsec-policy-isakmp-policy1-10] disconnect track vrrp 1 interface
gigabitethernet 0/0/2 backup
# Configure an IPSec policy using an IPSec policy template on RouterC.

[RouterC] ipsec policy-template temp1 10
[RouterC-ipsec-policy-templet-temp1-10] ike-peer rut1
[RouterC-ipsec-policy-templet-temp1-10] proposal tran1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[RouterC-ipsec-policy-templet-temp1-10] quit
[RouterC] ipsec policy policy1 10 isakmp template temp1
Step 7 Apply the IPSec policy to interfaces to enable IPSec protection.

# Apply the IPSec policy to an interface on RouterA.
# Apply the IPSec policy to an interface on RouterB.

# Apply the IPSec policy to an interface on RouterC.


1. PC_1 can ping PC_2 successfully, and data transmitted between them is encrypted.
# Run the display ipsec sa command on RouterC to check the configuration.
===============================
===============================
-----------------------------
IPSec policy name: "policy1"
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Holding time : 0d 0h 26m 12s
Flow source : 10.2.1.0/255.255.255.0 0/0
Flow destination : 10.1.1.0/255.255.255.0 0/0
[Outbound ESP SAs]

SPI: 184667519 (0xb01cd7f)
Proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-SHA2-256-128
SA remaining key duration (kilobytes/sec): 1843197/2030
Outpacket count : 40
Slice Failure: 0
[Inbound ESP SAs]

SPI: 4822111 (0x49945f)
Inpacket count : 40
Authentication Failure: 0
Replay Failure: 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Decrypt Check Failure: 0

The preceding command output shows that traffic from PC_1 to PC_2 is transmitted by
RouterA.
2. Traffic is switched to RouterB for transmission after GE0/0/2 of RouterA is shut down.
# Run the shutdown command on GE0/0/2 of RouterA, and then run the display ipsec
sa command on RouterC to check the configuration.
===============================
===============================
-----------------------------
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Flow source : 10.2.1.0/255.255.255.0 0/0
[Outbound ESP SAs]

SPI: 184667519 (0xb01cd7f)
Slice Failure: 0
[Inbound ESP SAs]

SPI: 4822111 (0x49945f)
Inpacket count : 40
Replay Failure: 0
The preceding command output shows that traffic is transmitted by RouterB.
3. Traffic is switched back to RouterA for transmission 20s after GE0/0/2 of RouterA is
enabled again..
# Run the undo shutdown command on GE0/0/2 of RouterA, and then run the display
ipsec sa command on RouterC to check the configuration.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
===============================
===============================
-----------------------------
Sequence number : 1
Acl group : 3002
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 2
Flow source : 10.2.1.0/255.255.255.0 0/0
[Outbound ESP SAs]

SPI: 184667519 (0xb01cd7f)
Slice Failure: 0
[Inbound ESP SAs]

SPI: 4822111 (0x49945f)
Inpacket count : 40
Replay Failure: 0
The preceding command output shows that traffic is transmitted by RouterA. This
indicates that the configurations are successful.
----End
Configuration Files
l Router A configuration file
#
sysname RouterA
#
acl number 3002
#
#
ike proposal 5
dh group14

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
prf hmac-sha2-256
#
ike peer rut1
undo version 2
pre-shared-key cipher %^%#oDRPE$1Da37|xCPSm+/5/-!{P3CaO/cdZ4EX"Sf"%^%#
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
connect track vrrp 1 interface GigabitEthernet0/0/2 master
disconnect track vrrp 1 interface GigabitEthernet0/0/2 backup
#
ip address 1.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.11
vrrp vrid 1 priority 120
vrrp vrid 1 preempt-mode timer delay 20
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2
#
return
#
sysname RouterB
#
acl number 3002
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
security acl 3002
ike-peer rut1
proposal tran1
connect track vrrp 1 interface GigabitEthernet0/0/2 master
disconnect track vrrp 1 interface GigabitEthernet0/0/2 backup
#
ip address 1.1.2.1 255.255.255.0
#
ip address 10.1.1.2 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.1.11

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
vrrp vrid 1 priority 80

#
ip route-static 0.0.0.0 0.0.0.0 1.1.2.2
#
return

#
sysname RouterC
#
#
ike proposal 5
dh group14
prf hmac-sha2-256
#
ike peer rut1
undo version 2
ike-proposal 5
#
ike-peer rut1
proposal tran1
#
#
ip address 2.1.1.1 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 2.1.1.2
#
return
6.14 Troubleshooting IPSec

6.14.1 IKE SA Negotiation Failed
Symptom
The IPSec service cannot be normally transmitted. The output of the display ike sa command
shows that IKE SA negotiation failed.
The following shows an example of the command output. If the Flag parameter is displayed
as RD or RD|ST, an SA is established successfully. ST indicates that the local end is the IKE
initiator.
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
13118 10.1.3.2 0 RD v1:2
12390 10.1.3.2 0 RD v1:1
---------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Flag Description:
If IKE SA negotiation fails, the Flag parameter is empty, the Peer parameter is 0.0.0.0, or the
command output contains no record.
Procedure
Step 1 Run the display ike proposal command to check whether the IKE peer uses the same IKE
proposal.
If not, change IKE proposals on the peer to be the same. If the authentication algorithms in the
IKE proposals are different, perform the following operations.
On the IKE initiator:
ike proposal 10
On the IKE responder:

ike proposal 10
Step 2 Run the display ike peer command to check whether the configuration in the peer view is
correct.
l Check whether the remote IP address is configured.
When the ACL mode is used for IPSec tunnel establishment, the remote IP address must
be specified for the device in IKE main negotiation mode. In addition, the remote IP
addresses specified for the IKE peer must match each other.
If the IP addresses of the IKE initiator and responder are 10.1.1.2 and 10.2.1.2, the
configuration is as follows.
ike peer mypeer1

ike peer mypeer2
If the IKE responder uses the policy template mode, you do not need to configure the
remote IP address for the responder.
l Check whether the pre-shared keys of the IKE peer are the same.
ike peer mypeer
pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%# //
The key is Huawei@123.
If not, change the pre-shared keys to be the same.

l Check whether the IKE proposals referenced by the IKE peer are the same.
For example, the IKE initiator references IKE proposal 10.
ike peer mypeer
ike-proposal 10
The related configuration of IKE proposal 10 is as follows.

ike proposal 10

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
If the configurations in the IKE proposals are different, change them to be the same.
----End
6.14.2 IPSec SA Negotiation Failed

Symptom
The IPSec service cannot be normally transmitted. The output of the display ike sa command
shows that IPSec SA negotiation failed.
The following shows an example of the command output. If the Flag parameter is displayed
as RD or RD|ST, an SA is established successfully. ST indicates that the local end is the IKE
initiator.
---------------------------------------------------------------
13118 10.1.3.2 0 RD v1:2
12390 10.1.3.2 0 RD v1:1
---------------------------------------------------------------
Flag Description:
If IKE SA negotiation is successful, but IPSec SA negotiation fails, the command output
contains no information about phase 2 or the Flag parameter is empty.
Procedure
Step 1 Run the display ipsec proposal command to check whether the IKE peer uses the same IPSec
proposal.
If not, change IPSec proposals on the peer to be the same. If the ESP authentication
algorithms in the IPSec proposals are different, perform the following operations.

Step 2 Run the display ipsec policy command to check whether the configuration in the IPSec
policy view is correct.
l Check whether the ACLs referenced in the IPSec policies are the same.
If the ACLs referenced by IPSec policies at both ends of the IPSec tunnel mirror each
other, an IPSec SA can be successfully established when either party initiates the
negotiation. If the ACLs do not mirror each other, an IPSec SA can be established only
when the IP address range defined in the ACL on the initiator is included in the IP
address range defined in the ACL on the responder. Therefore, it is recommended that
the ACLs at both ends of the IPSec tunnel mirror each other. That is, the source and
destination addresses in the ACL at one end are the same as the destination and source
addresses in the ACL at the other end.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
For example, if the source and destination addresses of the initiator are 10.1.1.2 and
10.2.1.2, the source and destination addresses of the responder are10.2.1.2 and 10.1.1.2.
acl number 3101
security acl 3101

acl number 3101
security acl 3101
l Check whether the IKE peer configurations referenced in the IPSec policies are the
same.
For example, the IKE initiator reference IKE proposal peer spub.
ike-peer spub
The related configuration of the IKE peer is as follows.
If the IKE peer configurations at two ends of the tunnel are different, change them to be
the same.
l Check whether the IPSec proposal configurations referenced in the IPSec policies are the
same.
For example, the IKE initiator reference IPSec proposal tran1.
proposal tran1
The related configuration of the IPSec proposal is as follows.

If the IPSec proposal configurations at two ends of the tunnel are different, change them
to be the same.
----End
6.14.3 Services Are Interrupted After an IPSec Tunnel Is

Established
Fault Symptom
If IPSec SA information is displayed in the display ike sa command output, an IPSec tunnel
has been established successfully. However, the following problems exist:
l Users in the branches and the headquarters cannot communicate with each other.
l Only unidirectional communication is implemented between users of the branches and
headquarters. For example, users of the headquarters can access servers in the branch,
but users of the branches cannot access servers in the headquarters.
l Users of the branch and headquarters can access only some network segments.
l On a point-to-multipoint network, users of the branches may communicate with the
headquarters normally, but users of different branches cannot communicate with each
other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Check whether security ACLs on both ends are correctly configured.
Run the display ipsec sa command to check whether the source and destination network
segments of the protected data flows matching security ACLs include actual service flows. If
not, run the display acl acl-number command to check whether ACLs are correctly
configured on both ends.
For details about configuring IPSec-protected data flows, see 6.7.1 Defining Data Flows to
Be Protected.
For example, run the display ipsec sa command to check the security ACL 3101.
[Huawei] display ipsec sa
===============================
===============================
-----------------------------
Sequence number : 1
Acl group : 3101
Acl rule : 5
Mode : ISAKMP
-----------------------------
Connection ID : 67108879
Flow source : 10.1.1.0/255.255.255.0 17/1701
......
If the protected data flows matching the security ACL do not include actual service flows, run
the display acl 3101 command to check the ACL configuration.
[Huawei] display acl 3101
Advanced ACL 3101, 1 rule
Acl's step is 5
If the security ACLs on both ends do not match, modify the security ACL configurations to
make them match.
Step 2 Check whether the NAT policy configuration affects the IPSec-protected data flows.
Run the display ipsec interface brief command to check the interface to which an IPSec
policy is applied, and then run the display current-configuration interface interface-type
interface-number command to check whether a NAT policy is configured on the specified
IPSec interface.
If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take
effect because the device performs NAT first. In this case, you need to ensure:
l The destination IP address denied in the ACL rule referenced by NAT is the destination
IP address in the ACL rule referenced by IPSec. This prevents the device from
performing NAT on the IPSec-protected data flows.
l The ACL rule referenced by IPSec matches the post-NAT IP address.
For example, the following command output indicates that a NAT policy is configured on
GE1/0/0.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Huawei] display current-configuration interface gigabitethernet 1/0/0

ip address 1.1.1.1 255.255.255.0
nat outbound 3000 //A NAT policy is configured for the interface.
The ACL rule configuration referenced by IPSec is as follows:

acl number 3101
The ACL rule configuration referenced by NAT is as follows:

acl number 3000
rule 5 permit ip
You can modify the configuration using either of the following methods:
l If NAT needs to be performed on data flows to the peer need before IPSec encryption,
change the source IP address in the ACL 3101 to the post-NAT IP address.
acl number 3101
rule permit ip source 1.1.1.0 0.0.0.255 destination 2.1.1.0 0.0.0.255
l If NAT does not need to be performed on data flows to the peer need before IPSec
encryption, add a deny policy to the ACL.
acl number 3000
rule 1 deny ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
rule 5 permit ip
Step 3 Check whether NAT traversal is enabled on both ends if a NAT device exists between both
ends.
Run the display ike peer command to check whether NAT traversal is enabled on both ends.
If not, run the nat traversal command in the IKE peer view.
[Huawei] display ike peer
Number of IKE peers: 1
------------------------------------------
Peer name : pa
IKE version : v1v2
VPN instance : -
Remote IP : 2.1.1.1
Authentic IP address : -
Proposal : tran1
Pre-shared-key : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY
%^%#
Local ID type :
IP
Local ID : -
Remote ID type : -
Remote ID : -
certificate peer-name : -
PKI realm : -
......
NAT-traversal : Disable
.......
[Huawei] ike peer pa
[Huawei-ike-peer-pa] nat traversal
Step 4 Check whether the security protocol is AH when a NAT device exists between both ends and
NAT traversal is enabled.
Run the display ipsec proposal brief command to check the security protocol. The security
protocol can only be ESP during NAT traversal.
If the security protocol is AH, run the transform command to change the security protocol to
ESP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Huawei] display ipsec proposal brief

Current ipsec proposal number: 1
---------------------------------------------------------
Proposal Name Encapsulation mode Transform
---------------------------------------------------------
tran1 Tunnel ah-new
[Huawei] ipsec proposal tran1
[Huawei-ipsec-proposal-tran1] transform esp
Step 5 Check whether the encryption/decryption modes on both ends are consistent if the
authentication algorithm used in an IPSec proposal is SHA2.
Run the display ipsec proposal command to check whether the authentication algorithm is
SHA2-256, SHA2-384, or SHA2-512.
[Huawei] display ipsec proposal
Number of proposals: 1
IPSec proposal name: 1

Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-256 //Authentication algorithm
Encryption AES-256
When IPSec uses the SHA-2 algorithm, if the devices on both ends of an IPSec tunnel are
from different vendors or run different software versions, they may use different encryption/
decryption modes. In this situation, IPSec traffic between the devices will be interrupted.
To solve the problem, run the ipsec authentication sha2 compatible enable command in the
system view to enable the SHA-2 algorithm to be compatible with earlier versions.
[Huawei] ipsec authentication sha2 compatible enable
----End
6.15 FAQ About IPSec

This section describes the FAQ about IPSec.
6.15.1 Private Network Communication Fails After IPSec Is

Configured. What Are the Causes?
Private networks fail to communicate with each other after IPSec is configured. The possible
causes are as follows:
l The public addresses of two IPSec-enabled devices cannot ping each other.
l The data flow defined for IPSec encapsulation is the same as that defined for NAT. You
can run the display acl all command to view the matching ACL rule. In this case, use
either of the following methods to prevent the data flow overlapping:
– Ensure that the destination IP address in the ACL rule referenced by IPSec is denied
in the ACL rule referenced by NAT. By doing so, the device does not perform NAT
on the data flow protected by IPSec.
– The ACL rule referenced by IPSec matches NAT-translated IP address.
l The device incorrectly learns private routes. The outbound interface to the destination
private network is not the public network interface with IPSec enabled.
l When the authentication algorithm used in an IPSec proposal is SHA2, the encryption
and decryption methods on both ends are inconsistent.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6.15.2 How Do I Rectify the Failure to View SA Information by

Running the display ipsec sa Command After IPSec Is
Configured?
To rectify the failure, perform the following operations:
1. Perform the ping operation to check the public network connectivity.
2. If the IPSec tunnel is established through IKE negotiation, run the display ike sa
command to check whether the IKE SA is successfully established.
3. Wait about 10 seconds and run the display ipsec sa command again.
4. Run the display interface brief command to verify that the interface bound to the IPSec
policy is in the Up state.
5. Verify that IPSec is configured correctly.
6.15.3 Does the Interface with a Dynamic IP Address Support

IPSec?
Yes.
When the local interface has a dynamic IP address and the peer interface has a fixed IP
address, configure an IPSec policy template on the peer interface to implement IPSec.
The following uses the 3G interface as an example to implement IKE auto negotiation.
Dynamic IP address
#
ike peer peer_3g_1
pre-shared-key cipher %@%@VsiNAx"H;$1jaO'QE%[=I\O6%@%@ //Set the pre-shared key
to huawei.
remote-address 10.5.39.160 //Specify a fixed IP address for the peer end.
#
ipsec proposal ipsec //Use the default security parameters.
#
ipsec policy ipsec 1 isakmp //Configure an IPSec policy and import the policy on
a 3G interface.
security acl 3000
ike-peer peer_3g_1
proposal ipsec
#
interface Cellular0/0/0
ipsec policy ipsec //Configure the IPSEC policy on the 3G interface.
#
acl 3000 //Configure ACL rules. The IPSec policy protects packets that match ACL
rules.
...
#
Fixed IP address
#
ipsec proposal ipsec
#
ike peer peer_3g_2 //The peer end uses a dynamic IP address.
pre-shared-key cipher %@%@VsiNAx"H;$1jaO'QE%[=I\O6%@%@ //Set the pre-shared key
to huawei.
#
ipsec policy-template temp 1 //Configure an IPSec policy template.
ike-peer peer_3g_2
proposal ipsec

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipsec policy ipsec 1 isakmp template temp //Configure an IPSec policy and bind
the policy to the template.
#
interface GigabitEthernet 1/0/0 //This interface uses a fixed IP address.
ipsec policy ipsec
ip address 10.5.39.160 255.255.255.255
#
NOTE
In V200R002C00 and earlier versions, run the pre-shared-key huawei command to set the pre-shared
key to huawei.
In V200R008C00 and later versions, the v1 and v2 parameters are deleted from the ike peer peer-name
[ v1 | v2 ] command. To configure the IKE protocol, run the version { 1 | 2 } command.
6.15.4 IPSec Does Not Take Effect When Both IPSec and NAT Are
Configured on a Device Interface. How This Problem Is Solved?
If NAT is configured on an interface to which an IPSec policy is applied, IPSec may not take
effect. You can use the following methods:
l Configure the destination IP address that matches the deny clause in an ACL referenced
by NAT as the destination IP address in an ACL referenced by IPSec. In this case, data
flows protected by IPSec are not translated by NAT.
l Configure the ACL rule referenced by NAT to match the IP address translated by NAT.
NOTE
After a deny rule is configured in NAT, you are advised to run the reset session all or reset nat session
all command to delete incorrect NAT entries.
6.15.5 Why Cannot an IPSec Tunnel Be Established Until It Is

Restarted?
When the same traffic needs to be sent to the headquarters but an IPSec tunnel exists between
the branch and headquarters to protect access traffic from existing users, a new IPSec tunnel
cannot be established before the old IPSec tunnel is torn down after it is restarted on the
headquarters device.
To solve the problem, run the ipsec remote traffic-identical accept command to enable new
users with the same IPSec rule to quickly access the headquarters. This function quickly ages
an existing IPSec SA between the branch and headquarters to re-establish a new IPSec tunnel.
6.16 References for IPSec

The following table lists the references for IPSec.
Table 6-12 References for IPSec

RFC 1829 The ESP DES-CBC Transform
RFC 1851 The ESP Triple DES Transform
RFC 2367 PF_KEY Key Management API, Version 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RFC 2401 Security Architecture for the Internet Protocol
RFC 2402 IP Authentication Header
RFC 2403 The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2406 IP Encapsulating Security Payload (ESP)
RFC 2407 The Internet IP Security Domain of Interpretation for

ISAKMP
RFC 2408 Internet Security Association and Key Management

Protocol (ISAKMP)
RFC 2409 The Internet Key Exchange (IKE)
RFC 2410 The NULL Encryption Algorithm and Its Use With
IPsec
RFC 3456 Dynamic Host Configuration Protocol (DHCPv4)

Configuration of IPsec Tunnel Mode
RFC 3706 A Traffic-Based Method of Detecting Dead Internet

Key Exchange (IKE) Peers
RFC 3947 Negotiation of NAT-Traversal in the IKE
RFC 3948 UDP Encapsulation of IPsec ESP Packets
RFC 4301 Security Architecture for the Internet Protocol
RFC 4302 IP Authentication Header
RFC 4303 IP Encapsulating Security Payload (ESP)
RFC 4306 Internet Key Exchange (IKEv2) Protocol
RFC 4307 Cryptographic Algorithms for Use in the Internet Key

Exchange Version 2 (IKEv2)
RFC 4308 Cryptographic Suites for IPsec
RFC 4434 The AES-XCBC-PRF-128 Algorithm for the Internet

Key Exchange Protocol (IKE)
RFC 4478 Repeated Authentication in Internet Key Exchange

(IKEv2) Protocol
RFC 4718 IKEv2 Clarifications and Implementation Guidelines
RFC 4835 Cryptographic Algorithm Implementation

Requirements for Encapsulating Security Payload
(ESP) and Authentication Header (AH)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RFC 4945 The Internet IP Security PKI Profile of IKEv1/

ISAKMP, IKEv2, and PKIX
RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2)
draft-dukes-ike-mode-cfg-02 The ISAKMP Configuration Method
draft-ietf-ipsec-heartbeats-00 Using Isakmp Heartbeats for Dead Peer Detection

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 7 A2A VPN Configuration
7 A2A VPN Configuration
About This Chapter
7.1 Overview of A2A VPN

7.2 Understanding A2A VPN
7.3 Application Scenarios for A2A VPN
7.4 Licensing Requirements and Limitations for A2A VPN
7.5 Default Settings for A2A VPN
7.6 Configuring A2A VPN
7.7 Maintaining A2A VPN
7.8 Configuration Examples for A2A VPN
7.9 Troubleshooting A2A VPN
7.10 A2A VPN FAQ
7.11 References for A2A VPN
7.1 Overview of A2A VPN

Definition
Any to Any VPN (A2A VPN) is a VPN solution that uses the Group Domain of Interpretation
(GDOI) protocol to manage keys and GDOI policies in a centralized manner. A2A VPN is
mainly used to protect enterprises' internal service traffic that is transmitted over a wide area
network (WAN).
For details about GDOI, see RFC 6407.
Purpose
As networks develop, enterprises have not only data services but also increasing intelligent
services such as voice and video services. These new services impose demands for instant

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interconnection between enterprise branches. Generally, enterprises deploy dedicated lines

such as MPLS VPN to implement interconnection between branches.
However, dedicated lines provide secure communication for enterprises to only a certain
extent. Some government regulations, such as Health Insurance Portability and Accountability
Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS), require that data
must be encrypted before it can be transmitted over dedicated lines.
Currently, IPSec is the commonly used encryption solution for dedicated lines. IPSec is a
Layer 3 encryption protocol defined by the Internet Engineering Task Force (IETF) and is
widely used for data encryption in WAN interconnections between branches. As a traditional
Layer 3 VPN technology, IPSec sets up tunnels between specified communicating parties to
protect data confidentiality, providing high-quality, interoperable, and cryptology-based
security.
IPSec VPN is a point-to-point tunneling technology that focuses on data security and
encryption. It has the following disadvantages:
l Networks face the N2 problem (N branches require N (N-1)/2 tunnels). The
configuration and management are complicated and network expansion is difficult.
l IPSec VPN results in changes to the original route deployment and cannot provide better
QoS processing.
l IPSec VPN does not support multicast services and can hardly support intelligent
services.
The A2A VPN solution is developed to overcome the preceding disadvantages. A2A VPN
adds a new IP header, same as the raw IP header, to establish non-tunnel connections between
branches. It manages keys and GDOI policies in a centralized manner, simplifying network
deployment and facilitating network expansion. In addition, it supports multicast features and
provides QoS guarantee for voice and video services.
7.2 Understanding A2A VPN

7.2.1 Basic Networking
As shown in Figure 7-1, the basic A2A VPN networking is composed of two types of
devices: key server (KS) and group member (GM). A2A VPN provides a group-based IPSec
security model. A group is a collection of GDOI policies, and all the GMs in the same group
share the same GDOI policies and keys.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 7-1 Basic A2A VPN networking

KS
A2A VPN GM
GM
Protocal packet
GM Data packet
GM
GMs are a group of network devices that share the same GDOI policies and keys and have the
same security requirements. Generally, GMs are branch egress routers. A GM registers with
the KS, and obtains GDOI policies from the KS to communicate with other GMs in the same
group. A GM provides a group identifier (ID) when it registers with the KS, and the KS
delivers matching GDOI policies and keys to the GM based on the group ID.
KS
The KS is a network device that creates and maintains GDOI policies and keys. Generally, the
KS is a router located beside the egress router of a data center. The KS responds to
registration requests from GMs and sends Rekey messages to GMs. After a GM registers with
the KS, the KS delivers the GDOI policies and keys to the GM. The keys will be updated
periodically. Before the key lifetime is reached, the KS sends Rekey messages to instruct all
the GMs to update keys.
The KS delivers two types of keys:
l Traffic encryption key (TEK): shared by all the GMs in a group and used for encryption
and decryption of traffic between GMs.
l Key encryption key (KEK): shared by all the GMs in a group and used for encryption
and decryption of Rekey messages between the KS and GM.
NOTE
AR routers cannot function as the KS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7.2.2.1 GM Registering with the KS

After GDOI policies of A2A VPN are applied to an interface of a GM, the GM registers with
the KS. The registration process consists of two stages: IKE negotiation and GDOI
negotiation.
1. IKE negotiation (first stage): The GM and KS negotiate with each other to authenticate
the peer's identity and to establish an IKE SA after identity authentication succeeds.
For details on the IKE negotiation process, see "IKE" in Huawei
V300R003 Configuration Guide - IPSec.
2. GDOI negotiation (second stage): After the IKE SA is established in the first stage, the
GM uses the GDOI protocol to negotiate with the KS and download keys (KEK and
TEK) from the KS.
Figure 7-2 outlines the detailed GDOI negotiation process.
Figure 7-2 GDOI negotiation process
GM KS
Group ID
Step 1
GDOI policy
Step 2
Confirm
Step 3
Key
Step 4 information
a. The GM obtains the group ID configured by an administrator and sends the group
ID to the KS.
b. The KS authenticates the received group ID. After the authentication succeeds, the
KS delivers GDOI policies (including information about the data flows to be
protected, authentication algorithm, encryption algorithm, and encapsulation mode)
to the GM based on the group ID.
c. The GM authenticates the received GDOI polices. If the policies are acceptable (for
example, the authentication and encryption algorithms are supported by the GM),
the GM sends a Confirm message to the KS.
d. After receiving the Confirm message, the KS sends keys (KEK and TEK) to the
GM.
After the negotiation process completes, the GM obtains GDOI policies and keys from
the KS, saves the information locally, and generates the TEK SA and KEK SA. The TEK
SA protects data flows between GMs, and the KEK SA protects rekey messages between
the GM and KS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7.2.2.2 GM Data Protection

After a GM registers with the KS, it uses the obtained TEK SA to protect packets matching
the GDOI policies. The protected packets can be unicast or multicast packets.
A2A VPN uses a data encapsulation mode similar to that used in IPSec. However, A2A VPN
can only use the Encapsulating Security Payload (ESP) protocol to encrypt packets, and
supports only the tunnel encapsulation mode. The encapsulation and encryption modes are
configured on the KS and delivered to the GMs.
In tunnel mode, the device adds an ESP header to the raw IP header and then adds a new IP
header that is the same as the raw IP header to the ESP header. In this way, the encrypted
packets retain the raw IP header information, including the source and destination addresses
and protocol type. Using a TCP packet as an example, Figure 7-3 shows the structure of the
IP packet generated after the encapsulation.
Figure 7-3 A2A VPN tunnel encapsulation mode
New IP Header Raw IP Header

ESP TCP ESP ESP
Src=10.1.1.3 Src=10.1.1.3 data
Header Header Tail Auth data
Dst=10.2.1.3 Dst=10.2.1.3
In an A2A VPN solution, encapsulated packets contain raw IP header information; therefore,
the packets can be forwarded using the existing routing architecture, making full use the
existing network structure.
Apart from the encapsulation mode, the data processing method of A2A VPN is of great
importance. A2A VPN supports three SA modes:
l Receive_Only: After a GM successfully registers with the KS, the GM can receive both
ciphertext and plaintext packets but can send only plaintext packets.
l Receive_Option: After a GM successfully registers with the KS, the GM can receive
both ciphertext and plaintext packets but can send only ciphertext packets.
l Normal: After a GM successfully registers with the KS, the GM can send or receive
ciphertext packets only.
If SA modes cannot be configured in stages when you deploy the A2A VPN on an existing
network (such as the MPLS VPN), services will be interrupted because a GM that joins a
group can send and receive only ciphertext packets but the GM that has not joined the group
can send and receive only plaintext packets. In this case, you can deploy the A2A VPN in
stages in SA mode to solve this issue. The process is as follows:
1. Deploy the KS and set the SA mode to Receive_Only on the KS. The KS will deliver
this SA mode to the GMs.
2. Deploy GMs on the A2A VPN network one by one. The registered GMs work in
Receive_Only mode, so they can communicate with the newly deployed GMs before
they register with the KS.
3. After all the GMs are deployed, set the SA mode to Receive_Option on the GMs. A GM
in Receive_Option mode can still communicate with a GM in Receive_Only mode.
4. After all the GMs are switched to Receive_Option mode, set the SA mode to Normal on
the KS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7.2.2.3 Rekey
The KS not only creates and encrypts GDOI polices and keys, but also updates keys and
allocates keys to GMs. After GMs register with the KS, the KS periodically sends new TEK
SAs or KEK SAs to GMs through rekey messages to improve security. A rekey message
carries information about the data flows to be protected, authentication algorithm, encryption
algorithm, encapsulation mode, and the lifetime of keys and SAs. A rekey message is
protected by the current KEK SA. GMs will receive rekey messages from the KS periodically.
If a GM does not receive any rekey message within the lifetime of the TEK SA or KEK SA, it
needs to register with the KS again to download GDOI policies and keys.
Two rekey modes are available: multicast rekey and unicast rekey.
Multicast Rekey
In multicast rekey mode, the KS multicasts rekey messages to members in a multicast group.
After successfully registering with the KS, GMs join a specific multicast group. All GMs in
the group will receive the rekey messages. If the GDOI policies on the KS are modified, the
KS sends rekey messages to all GMs in the multicast group.
Unicast Rekey
In unicast rekey mode, the KS unicasts rekey messages to each GM. The KS sends a rekey
message carrying the same new TEK SA or KEK SA to all the GMs before the old SA
expires. After receiving the rekey message, each GM sends an ACK message to the KS. The
KS updates the current active GM list based on the received ACK message. The KS sends
rekey messages only to active GMs.
In unicast mode, if the KS does not receive ACK messages from a GM for three consecutive
rekey messages, it removes the GM from the current active GM list and stops sending rekey
messages to the GM. If the GM wants to receive rekey messages, it must register with the KS
again.
7.3 Application Scenarios for A2A VPN

7.3.1 Typical A2A VPN Networking
Although the traditional IPSec VPN can meet the encryption requirement, it cannot
implement instant interconnection between enterprise branches and cannot provide better QoS
or multicast services. Besides, the network deployment is complex and network maintenance
is difficult. With ever increasing network security risks, a WAN interconnection solution is in
urgent need for a balance among security, intelligence, and easy management.
A2A VPN uses a KS to manage keys in a centralized manner, shares keys among GDOI
group members, and allows for hierarchical encryption and decryption among GMs.
Compared with traditional tunnel encryption, this solution simplifies configuration, facilitates
network expansion, and improves reliability, providing security for WAN interconnection and
intelligent service deployment.
As shown in Figure 7-4, a large-sized enterprise leases an MPLS VPN network (for example,
BGP/MPLS IP VPN) from a carrier to construct dedicated lines for connecting its branches
across the country. The headquarters and branches need to frequently exchange packets of

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
complex services including data, voice, and video services. These service packets must be
encrypted to prevent data tampering.
To meet the enterprise's requirements, a KS is deployed in the headquarters, with shared keys
and GDOI policies configured. The GDOI policies define the mode for encrypting service
packets transmitted between the branches and headquarters. The egress routers of the
headquarters and branches function as GMs. The GMs register with the KS to obtain the
shared keys and GDOI policies, which they use to encrypt/decrypt and forward packets. After
this solution is deployed, data packets transmitted between the branches or between a branch
and headquarters are encrypted; therefore, services can be safely transmitted over the carrier
network.
Figure 7-4 Typical A2A VPN networking
VPN
Site
Headquarters
KS GM_1
GM_2
VPN BGP/MPLS IP
Site VPN GM_4
Branch
VPN
Site
Branch
GM_3 Branch
VPN
Site
The enterprise requires that branch GM_4 can directly communicate with headquarter GM_1,
but traffic between GM_4 and other branches must pass through the headquarters. As shown
in Figure 7-5, two outbound interfaces are configured on GM_1: one interface is added to
group 1 together with GM_2 and GM_3, and the other interface is added to group 2 together
with GM_4. GM_4 cannot directly communicate with other branches as they are not in the
same group. Traffic between GM_4 and another branch, such as GM_2, must pass through the
headquarters.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 7-5 Headquarters router interfaces joining different groups
VPN
Site
Headquarters
GM_1
KS
GM_2
BGP/MPLS IP
VPN
Site VPN
GM_4
Branch
VPN
Site
Branch
GM_3 Branch
VPN Group 1
Site Group 2
Data flow
NOTE
When the router functions the PE device, it does not support multicast Rekey.
7.3.2 A2A VPN Redundancy

To improve network reliability, redundant links can be deployed for GMs (link redundancy)
or a GM can register with four KSs (KS redundancy).
Link Redundancy
As shown in Figure 7-6, each GM has two egress links that have the same group ID and are
bound with different GDOI policy groups. The egress links register with the KS and
download the same GDOI policies. When traffic needs to be forwarded, the GM selects the
outbound interface based on routing information. If any link fails, traffic is switched to the
other link based on route convergence, ensuring uninterrupted traffic between the GMs and
service availability.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 7-6 Link redundancy
KS
GM GM
A2A VPN
KS Redundancy
As shown in Figure 7-7, each GM registers with two KSs: one primary KS and one secondary
KS. Generally, a GM registers with the primary KS. If the primary KS fails, the GM registers
with the secondary KS. This improves reliability of the entire network.
Primary Secondary
Figure 7-7 KS redundancy
KS KS
GM
A2A VPN
GM
7.4 Licensing Requirements and Limitations for A2A VPN

l Key server
l Group member
Licensing Requirements
For A2A VPN-capable devices, GM function is not under license control, license their
licensing requirements for the KeySever function are as follows:
l AR2200&AR3200&AR3600 series: By default, KeySever function is disabled on a new
device. To use the KeySever function, apply for and purchase the following license from
the Huawei local office.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Feature Limitations
l When the device connects to a Cisco device that is used as the KS, you are advised to
use the Cisco device version of 2013 or later, for example, Cisco IOS Software, C3900e
Software (C3900e-UNIVERSALK9-M), Version 15.2(4)M5, RELEASE
SOFTWARE (fc2). If the Cisco device of a version earlier than 2013 is used, the
multicast rekey may fail.
l When the TEK SA lifetime is reached, the GM sends a re-registration request to the KS.
When the KEK SA lifetime is reached, the GM does not send a re-registration request to
the KS.
l The GM does not support time-based anti-replay. If time-based anti-replay is configured
on a KS, traffic will be interrupted when the GM communicates with a GM from another
vendor that supports time-based anti-replay.
l A2A VPN does not support NAT traversal.
l The GM can register with four KSs. The KSs work in primary/secondary mode
according to the configuration sequence. The GM first attempts to register with the first
KS. If the registration fails, the GM tries the second KS. This process continues in the
preceding manner.
7.5 Default Settings for A2A VPN

Table 7-1 Default settings for A2A VPN
IKE proposal The system provides an IKE proposal with

the lowest priority by default. For the
detailed parameters, see ike proposal.
Fragmentation mode of A2A VPN packets Fragmentation after encryption
7.6 Configuring A2A VPN

7.6.1 Configuring a GM
Before configuring a GM, complete the following tasks:
l Configure reachable routes between the GMs and between the GM and KS.
l Determine the data flows to be protected by A2A VPN.
l Determine the encryption algorithm for IKE negotiation, that is, configure parameters for
an IKE proposal.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Specify the PKI domain to which the peer belongs if digital certificate PKI
authentication is used.
NOTE
For details on the PKI configuration, see "PKI Configuration" in Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series V300R003
Configuration Guide - Security.
Perform the following operations in sequence to configure a GM. You can determine whether
to perform optional operations based on site requirements.
7.6.1.1 Configuring IKE
Context
To configure IKE, you need to configure an IKE proposal and an IKE peer for the first-stage
IKE negotiation between the GM and KS.
NOTE
GM does not support IKEv2.
Procedure
In A2A VPN, the detailed IKE configuration procedure is as follows:
1. Configure an IKE proposal. For details, see "6.11.1 Configuring an IKE Proposal" in
"IPSec Configuration".
2. (Optional) Configure the IKE SA Lifetime, see "6.11.3 (Optional) Setting the IKE SA
Lifetime" in "IPSec Configuration".
3. Configure an IKE peer. For details, see "6.11.2 Configuring an IKE Peer" in "IPSec
Configuration".
4. (Optional) Bind a VPN instance to A2A VPN. For details, see "6.11.8 (Optional)
Configuring IPSec VPN Multi-instance" in "IPSec Configuration".
7.6.1.2 (Optional) Defining Data Flows Not to Be Protected
Context
After a GM registers with the KS, the GM obtains security policies including the ACL rules
from the KS. The ACL rules configured on the KS determine data flows to be encrypted and
data flows to be forwarded in plain text. The GM matches received data flows with the ACL
rules obtained from the KS. If the matched ACL rule defines a permit action, the GM encrypts
the data flows and forwards them; if the matched ACL rule defines a deny action, the GM
forwards the data flows in plain text. If a data flow matches an ACL rule that defines a permit
action, but the GM wants to forward the data flow in plain text, you can configure a local
ACL rule to define data flows not to be protected. When a device forwards a data flow, it
matches the data flow with the local ACL rule first. If the data flow matches the local ACL
rule, the device forwards the data flow in plain text. If not, the device matches the data flow
with the ACL rules obtained from the KS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
If the KS sends more than 100 ACL rules to a GM, only 100 ACL rules take effect. If more than 100
ACL rules are configured on a GM, only 100 ACL rules take effect.
Procedure
Step 2 Run acl [ number ] acl-number [ match-order { config | auto } ]
An advanced ACL with acl-number ranging from 3000 to 3999 is created and the advanced
ACL view is displayed.
Step 3 Run rule [ rule-id ] deny ip [ destination { destination-address destination-wildcard | any } |
source { source-address source-wildcard | any } | vpn-instance vpn-instance-name | dscp
dscp ] *
An ACL rule is configured in the ACL view.
A2A VPN also support advanced ACLs that define various protocols such as ICMP, TCP,
UDP, and IGMP.
----End
7.6.1.3 Configuring a GDOI Policy
Context
The name and sequence number identify a GDOI policy.
A GDOI policy contains key information submitted by a GM when it registers with the KS.
The information includes the group ID, referenced IKE peer, and the registration interface.
l Group ID: identifies a GDOI group in A2A VPN. The KS determines the GDOI group to
which a GM is to be added based on the group ID submitted by the GM.
l Referenced IKE peer: used for the first stage IKE negotiation.
l Registration interface: A GM registers with the KS through the registration interface.
Procedure
Step 2 Run ipsec policy policy-name seq-number gdoi
A GDOI policy is created and the GDOI policy view is displayed.
By default, no GDOI policy is configured in the system.
Step 3 Run group identity number { group-number | ip-address }
An identifier is configured for a GDOI group.
By default, a GDOI group has no identifier.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The group identifier is also called group ID. A GDOI group can only use its group number or
IP address as the group ID and can only have one group ID.
An IKE peer is applied to the GDOI policy.
peer-name specifies the name of a created IKE peer.
By default, no IKE peer is referenced in the system.
Step 5 (Optional) Run security acl acl-number
An ACL is referenced in a GDOI policy.
acl-number specifies an advanced ACL that defines the data flows not to be protected.
By default, no ACL is referenced.
A GDOI policy can reference only one ACL.
A local ACL (supporting the deny action only) has a higher priority than an ACL downloaded
from the KS.
Step 6 (Optional) Run tunnel local { ip-address | applied-interface }
The local address is configured for A2A VPN.
By default, no local address is configured for A2A VPN.
For a GDOI policy, you do not need to configure a local address for A2A VPN because the
device will select an appropriate local address based on routing information during SA
negotiation.
l If the IP address of the interface to which a GDOI policy is applied varies or is unknown,
run the tunnel local ip-address command to specify the IP address of another interface
(such as the loopback interface) on the device as the local IP address for A2A VPN.
Otherwise, run the tunnel local applied-interface command to specify the IP address of
the interface as the local IP address for A2A VPN.
l If the interface to which a GDOI policy is applied has multiple IP addresses (one primary
IP address and several secondary IP addresses), run the tunnel local ip-address
command to specify one of these IP addresses as the local IP address for A2A VPN.
Otherwise, run the tunnel local applied-interface command to specify the primary IP
address of the interface as the local IP address for A2A VPN.
l If equal-cost routes exist between the local and remote ends, run the tunnel local { ip-
address | applied-interface } command to specify a local IP address for A2A VPN.
----End
7.6.1.4 Configuring an IP Address for Multicast Rekey Messages
Context
After an IP address for multicast Rekey messages is configured, GMs with this IP address and
a UDP port number 848/4500 update TEK SAs or KEK SAs based on the multicast Rekey
messages.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run ipsec gdoi multicast-rekey ip ip-address
An IP address is configured for multicast Rekey messages.
By default, no IP address is configured for multicast Rekey messages.
The IP address for multicast Rekey messages configured on the GM must be the same as that
configured on the KS.
----End
7.6.1.5 (Optional) Configuring the Receive_Option Mode
Context
If SA modes cannot be configured in stages when you deploy A2A VPN on an existing
network (such as the MPLS VPN network), services will be interrupted because a GM that
joins a group can send and receive only cipher text packets but the GM that has not joined the
group can send and receive only plain text packets. To prevent this problem, you can set the
SA mode to Receive_Option on the GMs and set the SA mode to Receive_Only or Normal in
different stages, to implement the phased deployment to A2A VPN.
The SA mode deployment of GMs and the KS are as follows:
1. Deploy the KS and set the SA mode to Receive_Only on the KS. The KS will deliver
this SA mode to the GMs.
2. Deploy GMs on the A2A VPN network one by one. The registered GMs work in
Receive_Only mode, so they can communicate with the newly deployed GMs before
they register with the KS.
3. After all the GMs are deployed, set the SA mode to Receive_Option on the GMs. A GM
in Receive_Option mode can still communicate with a GM in Receive_Only mode.
4. After all the GMs are switched to Receive_Option mode, set the SA mode to Normal on
the KS.
When configuring the SA mode on the KS, refer to the KS configuration of other vendors.
Procedure
Step 1 Run gdoi sa direction receive-option
The SA mode is set to Receive_Option. In this mode, the device can receive both cipher text
and plain text packets but can send only cipher text packets.
----End
7.6.1.6 (Optional) Configuring the QoS Function for A2A VPN
Context
In network planning, the QoS function needs to be configured to improve network service
capabilities and provide differentiated services to different types of traffic. QoS groups the

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
packets sharing common features into one class and provides the same QoS level for traffic of
the same type. In this manner, the class-based QoS technology provides differentiated
services.
You can configure the QoS function to implement refined QoS management on A2A VPN
packets. Choose either of the following method based on site requirements:
l If you want to classify packets to be encapsulated based on quintuple information
including the source address, destination address, protocol type, source port number, and
destination port number, configure the pre-extract original packet function. If you want
to classify packets based on the source address, destination address, or protocol type
only, you do not need to configure the pre-extract original packet function because the
new IP header added to A2A VPN packets is the same as the raw IP header.
l Packet encapsulation and decapsulation may result in transmission delay and consume
network bandwidth; therefore, A2A VPN requires differentiated services to shorten the
transmission delay, reduce the packet loss ratio, and maximize bandwidth. Classify A2A
VPN packets into a QoS group to provide differentiated services for A2A VPN packets
in the QoS group.

Configuring a
Configuring pre-extract traffic classifier to
original packet match the ACL
Configuring a
Configuring a Applying the
traffic
traffic policy traffic policy
behavior
Configuring a
Adding A2A VPN traffic classifier to
packets to a QoS group match the QoS
group
For details on QoS, see "MQC Configuration" in Huawei

V300R003 Configuration Guide - QoS.
Procedure
Step 2 Run ipsec policy policy-name seq-number gdoi
The GDOI policy view is displayed.
Step 3 Configure the QoS function for A2A VPN.

The device is configured to pre-extract original packet information.
By default, the device does not pre-extract original packet information.
A QoS group is configured for A2A VPN packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, A2A VPN packets do not belong to a QoS group.
----End
Follow-up Procedure
l After configuring the pre-extract original packet function, you need to run the if-match
acl { acl-number | acl-name } command in the traffic classifier view to create ACL-
based matching rules.
l After adding A2A VPN packets to a QoS group, you need to run the if-match qos-group
qos-group-value command in the traffic classifier view to create QoS group-based
matching rules.
7.6.1.7 (Optional) Configuring A2A VPN Multi-Link Sharing
Context
To improve network reliability, a GM is connected to a KS through multiple egress links for
link backup or load balancing. When the same A2A VPN protection method is used on
multiple outbound interfaces to ensure smooth service switchover, these outbound interfaces
register with the KS independently and negotiate to generate their own KEK SA. If a large
number of GMs need to be connected to the KS, the KS will become heavily loaded.
To reduce the load on the KS, configure a GDOI policy as a multi-link shared security policy.
GMs then register with the KS through loopback interfaces and negotiate to generate one
KEK SA. In this situation, multiple interfaces to which the GDOI policy is applied share one
KEK SA. That is, multiple links share one KEK SA.
NOTE
One loopback interface maps to only one multi-link shared security policy.
A GM can select an outbound interface according to a route to negotiate with the KS for a KEK SA as
long as the loopback interface of the GM is routable to the KS.
Procedure
Step 2 Run ipsec policy policy-name shared local-interface loopback interface-number
A GDOI policy is configured as a multi-link shared security policy.
By default, no GDOI policy is configured as a multi-link shared security policy.
----End
7.6.1.8 (Optional) Configuring Fragmentation Before Encryption
Context
After packets are encapsulated in A2A VPN, the packet length may exceed the maximum
transmission unit (MTU) allowed by the device outbound interface. In this case, you need to
fragment the packets to prevent packet loss. Two methods are available to fragment packets:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Fragmentation before encryption: Before encapsulating A2A VPN packets, the

encryption device calculates the predicted length of the encapsulated packets. If the
predicted length of the encapsulated packets exceeds the MTU of the outbound interface,
the device fragments the A2A VPN packets and then encapsulates the fragmented
packets. In this case, the terminal host decrypts and assembles A2A VPN fragments.
This reduces the CPU usage of the peer decryption device.
l Fragmentation after encryption: If the size of the encapsulated A2A VPN packets
exceeds the MTU of the outbound interface, the encryption device fragments the packets
based on the MTU of the outbound interface. In this case, the peer decryption device
assembles and decrypts A2A VPN fragments and then sends decrypted packets to the
terminal host.
Procedure
Step 2 Run ipsec df-bit { clear | set | copy }
The Don't Fragment (DF) flag bit is configured for A2A VPN packets, indicating whether
packets can be fragmented.
By default, the DF flag bit in A2A VPN is the flag bit of original packets.
Only after clear is specified to allow packet fragmentation, the following command takes
effect.
The fragmentation mode of packets is set to fragmentation before-encryption.
By default, packets are fragmented after being encrypted.
----End
7.6.1.9 Applying a GDOI Policy Group to an Interface
Context
A GDOI policy group is a collection of security policies with the same name but different
sequence numbers. In a GDOI policy group, a GDOI policy with a smaller sequence number
has a higher priority.
To protect data flows on an interface through A2A VPN, you need to apply a GDOI policy
group to the interface. If the GDOI policy group is deleted from the interface, the interface no
longer provides the A2A VPN protection function.
When sending a data flow, an interface matches the data flow with the GDOI policies in the
GDOI policy group in ascending order of sequence numbers. If the data flow matches a local
ACL referenced in a GDOI policy, the interface forwards the data flow in plain text; if the
data flow does not match any local ACL, the interface matches the data flow with the ACLs
downloaded from the KS; if the data flow does not match any ACL downloaded from the KS,
the interface forwards the data flow in plain text by default.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
Only one GDOI policy group can be applied on an interface. A GDOI policy group can be applied to
only one interface.
In a GDOI policy group, if multiple policies are bound to different IKE peers, the remote addresses
specified in the IKE peers cannot be the same. Otherwise, IKE negotiation of some GDOI policies fails.
Procedure
Step 2 Run interface interface-type interface-number
Step 3 Run ipsec policy policy-name
A GDOI policy group is applied to the interface.
By default, no GDOI policy group is applied to an interface.
----End
7.6.1.10 Verifying the GM Configuration
Prerequisites
All A2A VPN configurations are complete.
Procedure
l Run the display ike peer [ brief | name peer-name ] command to check information
about the IKE peer.
l Run the display ike proposal [ number proposal-number ] command to check
parameters in the IKE proposal.
about IKE SAs.
l Run the display ipsec gdoi-sa [ policy-name [ seq-number ] ] command to check
information about the GDOI SA.
l Run the display ipsec gdoi-policy [ policy-name [ seq-number ] ] command to check
information about GDOI policies.
----End
7.7 Maintaining A2A VPN

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7.7.1 Monitoring the A2A VPN Status

Context
All A2A VPN configurations are complete.
Procedure
l Run the display ipsec gdoi-sa [ policy-name [ seq-number ] ] command to check
information about the GDOI SA.
l Run the display ipsec statistics command to check the statistics about IPSec packets.
l Run the display ike statistics { v1 | v2 } command to check the statistics about IKE
packets.
----End
7.7.2 Clearing A2A VPN Statistics

Context
Statistics cannot be restored after being cleared. Exercise caution when you run the reset
command.
Procedure
l To clear statistics about IPSec packets, run the reset ipsec statistics command in the user
view.
l To clear statistics about IKE packets, run the reset ike statistics command in the user
view.
l To clear the TEK SA and KEK SA in a created GDOI policy, run the reset ipsec gdoi-sa
[ policy policy-name [ seq-number ] ] command in the user view.
l To clear the SA established by the current IKE, run the reset ike sa { remote ip-address |
conn-id conn-id } command in the user view.
The reset ike sa command does not clear the GDOI SA.
----End
7.8 Configuration Examples for A2A VPN
7.8.1 Example for Configuring a Typical A2A VPN Networking

A large-scale enterprise has many branches distributed in a wide area and a large number of
multicast services. BGP/MPLS IP VPN is deployed on the enterprise to implement secure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
communication between the headquarters and branches. As shown in Figure 7-9, GM_1 is the
enterprise branch gateway and GM_2 is the enterprise headquarters gateway. (The enterprise
has only one branch in this example.)
The enterprise requires that traffic between the branch and headquarters be encrypted and the
existing MPLS VPN network structure be made full use of. A2A VPN can be deployed
between the branch and headquarters to meet these requirements.
NOTE
The device can not function as a KS.

When the router functions the PE device, it does not support multicast Rekey.
Figure 7-9 Typical A2A VPN networking
KS
Loopback1 Loopback1
3.3.3.9/32 GE1/0/0
1.1.1.9/32 BGP/MPLS IP 192.168.3.1/24
GE1/0/0 VPN GE3/0/0
PE_1 2.1.1.1/24 PE_2 192.168.3.2/24
GE2/0/0 GE1/0/0 GE2/0/0
192.168.1.2/24 2.1.1.2/24 192.168.2.2/24
Branch GE1/0/0 GE1/0/0 Headquarters

gateway 192.168.1.1/24 192.168.2.1/24 gateway
GM_1 GM_2
GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.2.1/24
vpna
AS: 65410 vpna
AS: 65430
1. Set the AS number of the KS to 65420 and perform the same configuration on PE_2 to
add the KS to vpna, ensuring reachable routes between the KS and GMs.
2. Configure an ACL on the KS to define the data flows to be protected by A2A VPN.
3. Configure an IKE peer on the GMs and KS and define the attributes used for IKE
negotiation.
4. Configure a security proposal on the KS to define the protection method used for A2A
VPN.
5. Configure GDOI policies on the GMs and KS and reference an IKE peer.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6. Apply GDOI policy groups to the GM interfaces to enable the A2A VPN protection
function on the interfaces.
NOTE
When configuring the KS, refer to the configuration guide for KSs from other vendors.
Procedure
Step 1 Configure OSPF on the MPLS backbone network so that the PE devices can communicate
with each other.
# Configure PE_1.
[Huawei] sysname PE_1
[PE_1] interface loopback 1
[PE_1-LoopBack1] ip address 1.1.1.9 32
[PE_1-LoopBack1] quit
[PE_1] interface gigabitethernet 1/0/0
[PE_1-GigabitEthernet1/0/0] ip address 2.1.1.1 24
[PE_1-GigabitEthernet1/0/0] quit
[PE_1] ospf 1
[PE_1-ospf-1] area 0
[PE_1-ospf-1-area-0.0.0.0] network 2.1.1.0 0.0.0.255
[PE_1-ospf-1-area-0.0.0.0] quit
[PE_1-ospf-1] quit
# Configure PE_2.
[Huawei] sysname PE_2
[PE_2] interface loopback 1
[PE_2-LoopBack1] ip address 3.3.3.9 32
[PE_2-LoopBack1] quit
[PE_2] ospf
[PE_2-ospf-1] area 0
[PE_2-ospf-1-area-0.0.0.0] quit
[PE_2-ospf-1] quit
Step 2 Enable basic MPLS capabilities and MPLS LDP on the PE devices to set up LDP LSPs on the
MPLS backbone network.
# Configure PE_1.
[PE_1] mpls lsr-id 1.1.1.9
[PE_1] mpls
[PE_1-mpls] quit
[PE_1] mpls ldp
[PE_1-mpls-ldp] quit
[PE_1-GigabitEthernet1/0/0] mpls
[PE_1-GigabitEthernet1/0/0] mpls ldp
# Configure PE_2.
[PE_2] mpls lsr-id 3.3.3.9
[PE_2] mpls
[PE_2-mpls] quit
[PE_2] mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE_2-mpls-ldp] quit
[PE_2-GigabitEthernet1/0/0] mpls
[PE_2-GigabitEthernet1/0/0] mpls ldp
Step 3 Configure a VPN instance on each PE device and connect the GMs to the PEs.
# Configure PE_1.
[PE_1] ip vpn-instance vpna
[PE_1-vpn-instance-vpna] ipv4-family
[PE_1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[PE_1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[PE_1-vpn-instance-vpna-af-ipv4] quit
[PE_1-vpn-instance-vpna] quit
[PE_1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
# Configure PE_2.
[PE_2] ip vpn-instance vpna
[PE_2-vpn-instance-vpna] ipv4-family
[PE_2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[PE_2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[PE_2-vpn-instance-vpna-af-ipv4] quit
[PE_2-vpn-instance-vpna] quit
# Configure GM_1.
[Huawei] sysname GM_1
[GM_1] interface gigabitethernet 1/0/0
[GM_1-GigabitEthernet1/0/0] ip address 192.168.1.1 24
[GM_1-GigabitEthernet1/0/0] quit
# Configure GM_2.
[GM_2-GigabitEthernet1/0/0] ip address 192.168.2.1 24
Step 4 Set up an MP-IBGP peer relationship between PE1 and PE2.
# Configure PE_1.
[PE_1] bgp 100
[PE_1-bgp] peer 3.3.3.9 as-number 100
[PE_1-bgp] peer 3.3.3.9 connect-interface loopback 1
[PE_1-bgp] ipv4-family vpnv4
[PE_1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE_1-bgp-af-vpnv4] quit
[PE_1-bgp] quit
# Configure PE_2.
[PE_2] bgp 100
[PE_2-bgp] peer 1.1.1.9 as-number 100
[PE_2-bgp] peer 1.1.1.9 connect-interface loopback 1
[PE_2-bgp] ipv4-family vpnv4
[PE_2-bgp-af-vpnv4] peer 1.1.1.9 enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE_2-bgp-af-vpnv4] quit
[PE_2-bgp] quit
Step 5 Set up EBGP peer relationships between the PEs and GMs and import VPN routes.
# Configure GM_1.
[GM_1] bgp 65410
[GM_1-bgp] peer 192.168.1.2 as-number 100
[GM_1-bgp] import-route direct
[GM_1-bgp] quit
# Configure GM_2.
[GM_2] bgp 65430
[GM_2-bgp] peer 192.168.2.2 as-number 100
[GM_2-bgp] import-route direct
[GM_2-bgp] quit
# Configure PE_1.
[PE_1] bgp 100
[PE_1-bgp] ipv4-family vpn-instance vpna
[PE_1-bgp-vpna] peer 192.168.1.1 as-number 65410
[PE_1-bgp-vpna] import-route direct
[PE_1-bgp-vpna] quit
[PE_1-bgp] quit
# Configure PE_2.
[PE_2] bgp 100
[PE_2-bgp-vpna] import-route direct
[PE_2-bgp] quit
After the configuration is complete, the GMs can successfully ping each other.
For example, GM_1 can ping GM_2 (192.168.2.1).
[GM_1] ping 192.168.2.1

0.00% packet loss
Step 6 Configure PE_2 and the KS to add the KS to vpna and implement communication between
the KS and GMs.
# Configure PE_2.
[PE_2] bgp 100
[PE_2-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The VPN configuration of the KS is similar to that of GM_2. For details, see the L3VPN
Configuration Guide of other vendors.
Step 7 Configure an IKE peer for the two GMs. The IKE negotiation parameters must be the same as
those on the KS.
# Configure an IKE proposal on GM_1.
[GM_1] ike proposal 5
[GM_1-ike-proposal-5] quit
# Create an IKE peer on GM_1.

[GM_1] ike peer spub
[GM_1-ike-peer-spub] undo version 2
[GM_1-ike-peer-spub] ike-proposal 5
[GM_1-ike-peer-spub] pre-shared-key cipher Huawei@1234
[GM_1-ike-peer-spub] remote-address 192.168.3.1
[GM_1-ike-peer-spub] quit


[GM_2] ike peer spua
[GM_2-ike-peer-spua] undo version 2
[GM_2-ike-peer-spua] ike-proposal 5
[GM_2-ike-peer-spua] pre-shared-key cipher Huawei@1234
[GM_2-ike-peer-spua] remote-address 192.168.3.1
[GM_2-ike-peer-spua] quit
Step 8 Create GDOI policies for the GMs. The group ID of the GMs must be the same as that of the
KS.
# Configure GM_1.
[GM_1] ipsec policy map1 10 gdoi
[GM_1-ipsec-policy-gdoi-map1-10] group identity number 10
[GM_1-ipsec-policy-gdoi-map1-10] ike-peer spub
[GM_1-ipsec-policy-gdoi-map1-10] quit
# Configure GM_2.
[GM_2-ipsec-policy-gdoi-map2-10] ike-peer spua
Step 9 Apply a GDOI policy group to each interface on each GM.

# Apply a GDOI policy group to the interface on GM_1.
[GM_1-GigabitEthernet1/0/0] ipsec policy map1


# After the configurations are complete, run the display ike sa command on each device to
check the configuration. The command output of GM_1 is used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[GM_1] display ike sa

---------------------------------------------------------------
1109 192.168.3.1 0 RD|ST v1:1
---------------------------------------------------------------
Flag Description:
# After the configurations are complete, run the display ipsec gdoi-sa command on each
device to check the configuration. The command output of GM_1 is used as an example.
[GM_1] display ipsec gdoi-sa
===============================
Path MTU: 1500
===============================
---------------------------------
Gdoi policy name : "map1"
Sequence number : 10
---------------------------------
[TEK SA]
Protected vrf : vpna
Protocol : 0
Flow source : 10.1.1.0/255.255.255.0/0
Flow destination : 10.1.2.0/255.255.255.0/0
Inpacket count : 0
Outpacket count : 0
SA mode : normal
SPI: 99152831 (0x5e8f3bf)
Proposal : ESP-ENCRYPT-3DES-192 ESP-AUTH-SHA1
SA remaining lifetime(secs) : 66409
Anti-Replay(Time Based) : disable
[KEK POLICY]
Rekey Transport Type : multicast
SPI: 0x2ad569a935d15b75174446fbb0feaf5b
Received rekey seqno : 8
Lifetime (secs) : 75342
Encrypt Algorithm : DES
Encrypt Key Size : 64
Signature Hash Algorithm : HMAC_AUTH_SHA
Signature Key Length (bits) : 512
Signature Algorithm : SIG_ALG_RSA
NOTE
The ESP-ENCRYPT-3DES-192, ESP-AUTH-SHA1, DES, HMAC_AUTH_SHA, and SIG_ALG_RSA

algorithms have security risks; therefore, exercise caution when you use them.
----End
Configuration Files
l Configuration file of PE_1
#
sysname PE_1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip vpn-instance vpna
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 2.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance vpna
ip address 192.168.1.2 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
peer 192.168.1.1 as-number 65410
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 2.1.1.0 0.0.0.255
#
return
l Configuration file of PE_2
#
sysname PE_2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 2.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 192.168.2.2 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 192.168.3.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
peer 192.168.2.1 as-number 65430
peer 192.168.3.1 as-number 65420
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 2.1.1.0 0.0.0.255
#
return
l Configuration file of GM_1
#
sysname GM_1
#
ike proposal 5
aes-256
dh
group2
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
ipsec policy map1 10 gdoi
group identity number 10
ike-peer spub
#
ip address 192.168.1.1 255.255.255.0
ipsec policy map1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route direct
#
returnreturn
l Configuration file of GM_2
#
sysname GM_2
#
ike proposal 5
aes-256
dh
group2
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5
#
ike-peer spua
#
ip address 192.168.2.1 255.255.255.0
ipsec policy map2
#
ip address 10.1.2.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
7.8.2 Example for Configuring GM Link Redundancy

A large-scale enterprise has many branches distributed in a wide area and a large number of
multicast services. As shown in Figure 7-10, GM_1 is the enterprise branch gateway and
GM_2 is the enterprise headquarters gateway. (The enterprise has only one branch in this
example.) GM_1 uses two egress links in backup or load balancing mode to communicate
with the headquarters over the public network.
It is required that traffic between the branch and headquarters be protected and services be
transmitted securely when an active/standby switching occurs or one egress link becomes
faulty.
A2A VPN can be deployed between the branch and headquarters to ensure secure
communication within the enterprise. Meanwhile, GM link redundancy can be used to allow

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
the two outbound interfaces on GM_1 to register with the KS and download the same group
SA. GM_1 selects an appropriate outbound interface based on routing information to forward
services. When any egress link fails, traffic is switched to the other link based on route
convergence and the SA between group members is not changed.
Figure 7-10 Networking for configuring GM link redundancy
KS
GE1/0/0
2.1.2.1/24
Headquarters
Branch Gateway gateway
GM_1 GE1/0/0 GM_2
GE1/0/0
1.1.1.1/24 2.1.1.1/24
GE2/0/0
GE3/0/0 GE2/0/0
1.1.2.1/24
10.1.1.1/24 10.1.2.1/24
PC_1
10.1.1.2/24 PC_2
10.1.2.2/24
Branch Headquarters
1. Configure the IP address and static route on each physical interface of the GM and KS to
implement communication between interfaces.
2. Configure an ACL on the KS to define the data flows to be protected by A2A VPN.
3. Configure an IKE peer on the GMs and KS and define the attributes used for IKE
negotiation.
4. Configure a security proposal on the KS to define the protection method used for A2A
VPN.
5. Configure GDOI policies on the GMs and KS. You need to configure two GDOI policies
on GM_1 and reference an IKE peer.
6. Configure an IP address for multicast Rekey messages on the GMs. The IP address must
be the same as that configured on the KS.
7. Apply GDOI policy groups to the GM interfaces. You need to apply two GDOI policy
groups to the two outbound interfaces on GM_1 and add the two interfaces to the same
group to enable the A2A VPN protection function on the interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
When configuring the KS, refer to the configuration guide for KSs from other vendors.
You can run the ipsec policy shared command on GM_1 to configure the multi-link sharing function.
GM_1 then registers with the KS through a loopback interface, removing the need to register with the
KS through two GE interfaces. This reduces the load on the KS. In addition, only one shared KEK SA is
negotiated between the two ends. When traffic is switched between the active and standby links, a
smooth KEK SA switchover can be implemented. For details, see 6.13.8 Example for Establishing an
IPSec Tunnel Between the Enterprise Headquarters and Branch Using a Multi-Link Shared IPSec
Policy Group.
Procedure
Step 1 Configure the IP address and static route on each physical interface to implement
# Assign an IP address to each interface on GM_1.

[GM_1-GigabitEthernet1/0/0] ip address 1.1.1.1 255.255.255.0
# Configure static routes to the peer on GM_1.

[GM_1] ip route-static 2.1.2.0 255.255.255.0 1.1.1.2 preference 10
# Assign an IP address to each interface on GM_2.

# Configure static routes to the peer on GM_2.

[GM_2] ip route-static 2.1.2.0 255.255.255.0 2.1.1.2
Step 2 Configure an IKE peer for the two GMs. The IKE negotiation parameters must be the same as
those on the KS.


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[GM_1] ike peer spub

[GM_1-ike-peer-spub] undo version 2
[GM_1-ike-peer-spub] ike-proposal 5
[GM_1-ike-peer-spub] pre-shared-key cipher Huawei@1234
[GM_1-ike-peer-spub] remote-address 2.1.2.1
[GM_1-ike-peer-spub] quit


[GM_2] ike peer spua
[GM_2-ike-peer-spua] undo version 2
[GM_2-ike-peer-spua] ike-proposal 5
[GM_2-ike-peer-spua] pre-shared-key cipher Huawei@1234
[GM_2-ike-peer-spua] remote-address 2.1.2.1
[GM_2-ike-peer-spua] quit
Step 3 Create GDOI policies for the GMs. The group ID of the GMs must be the same as that of the
KS.
# Configure GM_1.
[GM_1-ipsec-policy-gdoi-map1-10] tunnel local applied-interface
[GM_1-ipsec-policy-gdoi-map2-10] tunnel local applied-interface
# Configure GM_2.
[GM_2-ipsec-policy-gdoi-map3-10] ike-peer spua
Step 4 Configure an IP address for multicast Rekey messages on the GMs. The IP address must be
the same as that configured on the KS.
# Configure GM_1.
[GM_1] multicast routing-enable
[GM_1] ipsec gdoi multicast-rekey ip 239.0.1.2
[GM_1-GigabitEthernet1/0/0] pim dm
[GM_1-GigabitEthernet1/0/0] igmp static-group 239.0.1.2
# Configure GM_2.
[GM_2] multicast routing-enable
[GM_2] ipsec gdoi multicast-rekey ip 239.0.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 5 Apply a GDOI policy group to each interface on each GM.

# Apply a GDOI policy group to each interface on GM_1.


# After the configurations are complete, run the display ike sa command on each device to
check the configuration. The command output of GM_1 is used as an example.
[GM_1] display ike sa
---------------------------------------------------------------
1109 2.1.2.1 RD|ST v1:1
---------------------------------------------------------------
Flag Description:
# After the configurations are complete, run the display ipsec gdoi-sa command on each
device to check the configuration. The command output of GM_1 is used as an example.
===============================
Path MTU: 1500
===============================
---------------------------------
---------------------------------
[TEK SA]
Protected vrf : 0
Protocol : 0/permit
Flow source : 10.1.1.0/255.255.255.0/0
Inpacket count : 0
Outpacket count : 0
SA mode : normal
SPI: 99152831 (0x5e8f3bf)
[KEK POLICY]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Shut down GigabitEthernet1/0/0 on GM_1 and run the display ipsec gdoi-sa command to
check the SA status. The command output shows that the SA is established with
GigabitEthernet2/0/0 and traffic goes out from GigabitEthernet2/0/0; thereby, service
continuity is ensured.
===============================
Path MTU: 1500
===============================
---------------------------------
---------------------------------
[TEK SA]
Protected vrf : 0
Protocol : 0/permit
Flow source : 10.1.1.0/255.255.255.0/0
Inpacket count : 0
Outpacket count : 0
SA mode : normal
SPI: 99152831 (0x5e8f3bf)
[KEK POLICY]
NOTE
The ESP-ENCRYPT-3DES-192, ESP-AUTH-SHA1, DES, HMAC_AUTH_SHA, and SIG_ALG_RSA

algorithms have security risks; therefore, exercise caution when you use them.
----End
Configuration Files
l GM_1 configuration file
#
sysname GM_1
#
multicast routing-enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipsec gdoi multicast-rekey ip 239.0.1.2
#
ike proposal 5
aes-256
dh
group2
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spub
undo version 2
ike-proposal 5
#
ike-peer spub
tunnel local applied-interface
#
ike-peer spub
tunnel local applied-interface
#
ip address 1.1.1.1 255.255.255.0
pim dm
igmp static-group 239.0.1.2
ipsec policy map1
#
ip address 1.1.2.1 255.255.255.0
pim dm
ipsec policy map2
#
ip address 10.1.1.1 255.255.255.0
#
#
return
l GM_2 configuration file
#
sysname GM_2
#
multicast routing-enable
#
ipsec gdoi multicast-rekey ip 239.0.1.2
#
ike proposal 5
aes-256
dh
group2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer spua
undo version 2
ike-proposal 5
#
ike-peer spua
#
ip address 2.1.1.1 255.255.255.0
pim dm
ipsec policy map3
#
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 2.1.1.2
ip route-static 2.1.2.0 255.255.255.0 2.1.1.2
ip route-static 1.1.1.0 255.255.255.0 2.1.1.2
ip route-static 1.1.2.0 255.255.255.0 2.1.1.2
#
return
7.9 Troubleshooting A2A VPN

7.9.1 GM Fails to Register with the KS
Fault Description
After a GM and a KS are configured, the GM fails to register with the KS.
Procedure
Step 1 Run the display ike sa command to check whether the first-stage IKE SA is successfully
established.
l If no IKE SA is established, the IKE proposal or IKE peer configured on the GM differs
from that on the KS. You can run the display ike peer (all views) or display ike
proposal (All views) command to check the IKE proposal or IKE peer.
Change the IKE proposal or IKE peer configuration to the same as that on the KS. For
details, see 7.6.1.1 Configuring IKE.
l If an IKE SA is established successfully, go to Step 2.
Step 2 Run the display ipsec gdoi-policy command to check whether the GM and KS have the same
group ID.
l If the group ID of the GM differs from that of the KS, change them to the same. For
details, see 7.6.1.3 Configuring a GDOI Policy.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l If the GM and KS have the same group ID, check whether other related configurations
are correct.
----End
7.10 A2A VPN FAQ
7.10.1 Why Some Service Packets Are Lost After A2A VPN Is
Deployed?
After A2A VPN is deployed, A2A VPN packets are discarded if their size exceeds the
interface MTU but the DF flag is not set to 0. To solve the problem, run the ipsec df-bit clear
command to enable fragmentation of A2A VPN packets.
7.11 References for A2A VPN

The following table lists the references for A2A VPN.
Table 7-2 References for A2A VPN
RFC2401 Security Architecture for the Internet Protocol
RFC2402 IP Authentication Header
RFC2403 The Use of HMAC-MD5-96 within ESP and AH
RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH
RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC2406 IP Encapsulating Security Payload (ESP)
RFC2407 The Internet IP Security Domain of Interpretation for

ISAKMP
RFC2408 Internet Security Association and Key Management

Protocol (ISAKMP)
RFC2409 The Internet Key Exchange (IKE)
RFC2410 The NULL Encryption Algorithm and Its Use With

IPsec
RFC3706 A Traffic-Based Method of Detecting Dead Internet

Key Exchange (IKE) Peers
RFC6407 The Group Domain of Interpretation
RFC3740 The Multicast Group Security Architecture
RFC3947 Negotiation of NAT-Traversal in the IKE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RFC3948 UDP Encapsulation of IPsec ESP Packets
RFC4301 Security Architecture for the Internet Protocol
RFC4302 IP Authentication Header
RFC4303 IP Encapsulating Security Payload (ESP)
RFC4308 Cryptographic Suites for IPsec
RFC4835 Cryptographic Algorithm Implementation

Requirements for Encapsulating Security Payload
(ESP) and Authentication Header (AH)
RFC4945 The Internet IP Security PKI Profile of IKEv1/

ISAKMP, IKEv2, and PKIX
RFC5374 Multicast Extensions to the Security Architecture for

the Internet Protocol
draft-dukes-ike-mode-cfg-02.txt The ISAKMP Configuration Method

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 8 BGP/MPLS IP VPN Configuration
8 BGP/MPLS IP VPN Configuration
About This Chapter
An enterprise can build its own BGP/MPLS IP VPN network to implement secure
interconnection between its headquarters and branches. The BGP/MPLS IP VPN network
ensures high-quality communication within the enterprise network.
8.1 Overview of BGP/MPLS IP VPN
This section describes the definition, background, and functions of BGP/MPLS IP VPN.
8.2 Understanding BGP/MPLS IP VPN
This section describes the implementation of BGP/MPLS IP VPN.
8.3 Application Scenarios for BGP/MPLS IP VPN
This section describes the application scenarios for BGP/MPLS IP VPN.
8.4 Summary of BGP/MPLS IP VPN Configuration Tasks
After basic BGP/MPLS IP VPN configurations are complete, a simple VPN network can be
established using MPLS technology. To deploy special BGP/MPLS IP VPN networking,
perform other configuration tasks according to the reference sections provided in the
following table.
8.5 Licensing Requirements and Limitations for BGP/MPLS IP VPN
8.6 Default Settings for BGP/MPLS IP VPN
This section describes the default settings for BGP/MPLS IP VPN.
8.7 Configuring BGP/MPLS IP VPN
This section describes the procedures for configuring BGP/MPLS IP VPN functions.
8.8 Maintaining BGP/MPLS IP VPN
You can check route summary information in a VPN instance, monitor network connectivity,
and reset BGP connections when maintaining a BGP/MPLS IP VPN network.
8.9 Configuration Examples for BGP/MPLS IP VPN
This section provides several configuration examples of BGP/MPLS IP VPN networking. In
each configuration example, the networking requirements, configuration roadmap,
configuration procedures, and configuration files are provided.
8.10 FAQ About BGP/MPLS IP VPN
This section describes the FAQ about BGP/MPLS IP VPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.11 References for BGP/MPLS IP VPN

This section lists references for BGP/MPLS IP VPN.
8.1 Overview of BGP/MPLS IP VPN

This section describes the definition, background, and functions of BGP/MPLS IP VPN.
Definition
A BGP/MPLS IP VPN is a Layer 3 virtual private network (L3VPN). A BGP/MPLS IP VPN
uses the Border Gateway Protocol (BGP) to advertise VPN routes and uses Multiprotocol
Label Switching (MPLS) to forward VPN packets on backbone networks. Here, IP that
Internet Protocol (IP) packets are carried by the VPN.
Figure 8-1 shows the BGP/MPLS IP VPN model.
Figure 8-1 BGP/MPLS IP VPN model
VPN 2
VPN 1 CE Site
Site CE IP/MPLS
P Backbone P
PE
PE
PE
VPN 2 P P
CE VPN 1
Site
CE Site
The BGP/MPLS IP VPN model consists of the following entities:

l Customer Edge (CE): a device that is deployed at the edge of a customer network and
has interfaces directly connected to the service provider (SP) network. A CE device can
be a router, a switch, or a host. Generally, CE devices do not detect VPNs and do not
need to support MPLS.
l Provider Edge (PE): a device that is deployed at the edge of an SP network and directly
connected to a CE device. On an MPLS network, PE devices process all VPN services
and must have high performance.
l Provider (P): a backbone device that is deployed on an SP network and is not directly
connected to CE devices. P devices only need to provide basic MPLS forwarding
capabilities and do not maintain VPN information.
PE and P devices are managed by SPs. CE devices are managed by customers unless
customers authorize SPs to manage their CE devices.
A PE device can connect to multiple CE devices. A CE device can connect to multiple PE
devices of the same SP or different SPs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Purpose
A traditional VPN sets up full-mesh tunnels or permanent virtual circuits (PVCs) between all
sites to forward VPN data. This method makes networks difficult to maintain and expand.
When a new site is added to an established VPN, a network administrator must modify the
configuration of all edge nodes connected to this site.
A BGP/MPLS IP VPN uses a peer model that enables SPs and customers to exchange routing
information. The SPs are responsible for forwarding data of customers, without participation
of the customers. A BGP/MPLS IP VPN is more scalable and more easier to manage than a
traditional VPN. When a new site is added, a network administrator only needs to modify the
configuration of the edge nodes serving the new site.
BGP/MPLS IP VPN allows overlapping address spaces and overlapping VPNs so that VPNs
can be flexibly deployed and expanded. In addition, BGP/MPLS IP VPN supports MPLS
Traffic Engineering (TE). Because of these merits, BGP/MPLS IP VPN becomes an important
approach for IP network carriers to provide value-added services and is now widely used.
8.2 Understanding BGP/MPLS IP VPN

This section describes the implementation of BGP/MPLS IP VPN.
8.2.1 Concepts
Site
The site is frequently mentioned in VPN technology. The following describes a site from
different aspects:
l A site is a group of IP systems with IP connectivity, which can be achieved independent
of SP networks.
Figure 8-2 shows an example of sites. On the networks on the left side in Figure 8-2, the
headquarters of company X in city A is a site, and the branch of company X in city B is
another site. IP devices can communicate within each site without using the carrier
network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-2 Sites

Two sites One site
Site A Site X
CE
CE
Carrier's Carrier's Headquarters
network Headquarters of network
X company in of X company
City A in City A
Router
CE
Branch of X Branch of X
company in company in
City B City B
Site B
l Sites are configured based on topologies between devices but not their geographic
locations, although devices in a site are geographically adjacent to each other in most
cases. Two geographically separated IP systems can also compose a site if they are
connected through leased lines and can communicate without the use of the carrier
network.
On the right of Figure 8-2, the branch network in city B connects to the headquarters
network in city A through leased lines but not a carrier network. The branch network and
the headquarters network compose a site.
l The devices in a site may belong to multiple VPNs. That is, a site may belong to more
than multiple VPNs.
As shown in Figure 8-3, the decision-making department of company X in city A (Site
A) is allowed to communicate with the R&D department in city B (Site B) and the
financial department in city C (Site C). Site B and Site C are not allowed to
communicate with each other. In this case, two VPNs, VPN1 and VPN2, can be
established. Site A and Site B belong to VPN1; Site A and Site C belong to VPN2. Site
A belongs to two VPNs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-3 One site belonging to multiple VPNs
VPN 1
X Company CE X Company
Decision-making R&D
Site A department Site B department
CE
VPN 2
X Company Carrier's
Financial network
department CE
Site C
l A site connects to a carrier network through CE devices. A site may have more than one
CE device, but a CE device belongs to only one site.
CE devices are selected according to sites:
If a site is a host, the host is the CE device of the site.
If a site is a subnet, switches are used as CE devices.
If a site has multiple subnets, routers are used as CE devices.
Sites connected to the same carrier network can be grouped into different sets using
policies. Only sites that belong to the same set can communicate with each other through
the carrier network. Such a set is a VPN.
Address Space Overlapping

As a private network, each VPN manages an address space. Address spaces of different VPNs
may overlap. For example, if both VPN1 and VPN2 use addresses on the network segment
10.110.10.0/24, their address spaces overlap.
VPNs can use overlapping address spaces in the following situations:
l Two VPNs do not cover the same site.
l Two VPNs cover the same site, but devices in the site do not need to communicate with
devices using overlapping address spaces in the VPNs.
VPN Instance
In BGP/MPLS IP VPN implementation, routes of different VPNs are isolated by VPN
instances.
A PE device establishes and maintains a VPN instance for each directly connected site. A
VPN instance contains VPN member interfaces and routes of the corresponding site.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Specifically, information in a VPN instance includes the IP routing table, label forwarding
table, interface bound to the VPN instance, and VPN instance management information. VPN
instance management information includes the route distinguisher (RD), route filtering policy,
and member interface list of the VPN instance.
The relationships between VPNs, sites, and VPN instances are as follows:
l A VPN consists of multiple sites. A site may belong to multiple VPNs.
l A site is associated with a VPN instance on a PE device. A VPN instance integrates VPN
members and routing policies of associated sites. Multiple sites compose a VPN based
on rules of the VPN instance.
l VPN instances are not mapped to VPNs on a one-to-one basis, whereas VPN instances
are mapped to sites on a one-to-one basis.
A VPN instance is also called a VPN routing and forwarding table (VRF). A PE device has
multiple routing and forwarding tables, including a public routing and forwarding table and
one or more VRFs. Figure 8-4 shows VPN instances.
Figure 8-4 VPN instances
VPN1
Site1 CE
IP/MPLS
VPN1 PE
Backbone
VPN-instance
VPN2 Public
VPN-instance forwarding table
VPN2
Site2 CE
A public routing and forwarding table and a VRF differ in the following aspects:
l A public routing table contains IPv4 routes of all the PE and P devices. The routes are
static routes or dynamic routes generated by routing protocols on the backbone network.
l A VPN routing table contains routes of all sites that belong to a VPN instance. The
routes are obtained through the exchange of VPN routing information between PE
devices or between CE and PE devices.
l Information in a public forwarding table is extracted from the public routing table
according to route management policies, whereas information in a VPN forwarding table
is extracted from the corresponding VPN routing table.
VPN instances on a PE device are independent of each other and maintain a VRF
independent of the public routing and forwarding table.
Each VPN instance can be considered as a virtual device, which maintains an
independent address space and connects to VPNs through interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
RD and VPN-IPv4 Address

Traditional BGP cannot process VPN routes with overlapping address spaces. For example,
VPN1 and VPN2 use addresses on the network segment 10.110.10.0/24, and they each
advertise a route to this network segment. The local PE device can identify routes based on
VPN instances. However, when the routes are advertised to the remote PE device, BGP
selects only one of the two routes because load balancing is not performed between routes of
different VPNs. The other route is lost.
To address the preceding problem, PE devices use Multiprotocol Extensions for BGP-4 (MP-
BGP) to advertise VPN routes and use the VPN-IPv4 address.
A VPN-IPv4 address has 12 bytes. The first eight bytes represent the RD, and the last four
bytes represent the IPv4 address prefix, as shown in Figure 8-5.
Figure 8-5 VPN-IPv4 address
Route Distinguisher ( 8-Byte )
Type Field Administrator Assigned IPv4 Address Prefix

( 2-Byte ) Subfield Number Subfield ( 4-Byte )
RDs distinguish IPv4 prefixes with the same address space. IPv4 addresses with RDs are
VPN-IPv4 addresses (VPNv4 addresses). After receiving IPv4 routes from a CE device, a PE
device converts the routes into globally unique VPN-IPv4 routes and advertises the routes on
the public network.
SPs can allocate RDs independently because of the RD format. When CE devices are dual-
homed to PE devices, the RD must be globally unique to ensure correct routing. As shown in
Figure 8-6, a CE device is dual-homed to PE1 and PE2. PE1 also functions as a route
reflector (RR).
Figure 8-6 Networking diagram of CE dual-homing
CE RR
VPN site
PE1
10.1.1.1/8 PE3
IP/MPLS
Backbone
PE2
PE1 is an edge device of the backbone network and advertises a VPN-IPv4 route with the
IPv4 prefix 10.1.1.1/8 to PE3. PE1 also functions as an RR and reflects a VPN-IPv4 route
with the IPv4 prefix 10.1.1.1/8 from PE2 to PE3.
l If the VPN has the same RD on PE1 and PE2, the two VPN-IPv4 routes to 10.1.1.1/8
have the same destination address. Therefore, PE3 receives only one VPN-IPv4 route
(CE -> PE1 -> PE3) to 10.1.1.1/8 from PE1. When the direct link between PE1 and CE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
becomes faulty, PE3 deletes the VPN-IPv4 route to 10.1.1.1/8. As a result, VPN data
destined for 10.1.1.1/8 cannot be forwarded to the destination. Actually, PE3 has another
route to 10.1.1.1/8, PE3 -> PE1 -> PE2 -> CE.
l If the VPN has the same RD on PE1 and PE2, the two VPN-IPv4 routes to 10.1.1.1/8
have different destination addresses. Therefore, PE3 receives two VPN-IPv4 route to
10.1.1.1/8 from PE1. When any link between PE1 and CE becomes faulty, PE3 deletes
the corresponding route and reserves the other one. Data destined for 10.1.1.1/8 can still
be correctly forwarded.
VPN Target
A VPN target, also called the route target (RT), is a BGP extension community attribute.
BGP/MPLS IP VPN uses VPN targets to control VPN routes advertisement.
A VPN instance is associated with one or more VPN target attributes. VPN target attributes
are classified into the following types:
l Export target: After a PE device learns IPv4 routes from directly connected sites, it
converts the routes to VPN-IPv4 routes and sets the export target attribute for those
routes. The export target attribute is advertised with the routes as a BGP extended
community attribute.
l Import target: After a PE device receives VPN-IPv4 routes from other PE devices, it
checks the export target attribute of the routes. If the export target is the same as the
import target of a VPN instance on the local PE device, the local PE device adds the
route to the VPN routing table.
BGP/MPLS IP VPN uses VPN targets to control advertisement and receiving of VPN routes
between sites. VPN export targets are independent of import targets. An export target and an
import target can be configured with multiple values to implement flexible VPN access
control and VPN networking.
For example, if the import target of a VPN instance contains 100:1, 200:1, and 300:1, any
route with the export target of 100:1, 200:1, or 300:1 is added to the routing table of the VPN
instance.
This section describes BGP/MPLS IP VPN implementation:
l VPN Label Distribution
l VPN Route Cross
l Public Network Tunnel Iteration
l VPN Route Selection Rules
l Route Advertisement in BGP/MPLS IP VPN
l Packet Forwarding in BGP/MPLS IP VPN
VPN Label Distribution

Before advertising private routes to other PE devices on the backbone network through MP-
BGP, a PE device must assign MPLS labels (VPN label) to the private routes. Packets
transmitted over the backbone network carry MPLS labels.
A PE device allocates MPLS labels in either of the following ways:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l One label per route

Each route in a VRF is assigned one label. When a large number of routes exist on the
network, the Incoming Label Map (ILM) maintains a large number of entries, which
requires high router capacity.
l One label per instance
Each VPN instance is assigned one label. All the routes of a VPN instance share the
same label, saving labels.
NOTE
MP-BGP can allocate labels to private routes only after MPLS is enabled on the PE device.
VPN Route Cross

The routes exchanged between two PE devices through MP-BGP are VPNv4 routes. A PE
device checks received VPNv4 routes and drops the following routes:
l VPNv4 routes with unreachable next hops

l VPNv4 routes received from an RR with the cluster_id of the PE device in the
cluster_list
l VPNv4 routes that are denied by the BGP routing policy
The PE device matches the remaining routes with the Import Targets of VPN instances. The
matching process is called VPN route cross.
Some routes sent from local CE devices belong to different VPNs. The PE device also
matches these routes with Import Targets of local VPN instances if these routes have
reachable next hops or can be iterated. The matching process is called local VPN route cross.
For example, CE1 resides in a site of VPN1, and CE2 resides in a site of VPN2. Both CE1
and CE2 connect to PE1. When PE1 receives routes of VPN1 from CE1, PE1 also matches
the routes with the Import Target of the instance of VPN2.
NOTE
To correctly forward a packet, a BGP-enabled device must find out a directly reachable address, through
which the packet can be forwarded to the next hop in the routing table. The route to the directly
reachable address is called dependent route, because BGP guides packet forwarding based on the route.
The process of finding a dependent route based on the next-hop address is called route iteration.
Public Network Tunnel Iteration

To transmit traffic of private networks across a public network, tunnels need to be established
on the public network. After VPN route cross is complete, PE devices perform route iteration
based on destination IPv4 prefixes to find the appropriate tunnels (except for local cross
routes). Then tunnel iteration is performed. The routes are injected into the VPN routing table
only after tunnel iteration succeeds. The process of iterating routes to corresponding tunnels is
called tunnel iteration.
After tunnel iteration succeeds, tunnel IDs are reserved for subsequent packet forwarding. A
tunnel ID identifies a tunnel. In VPN packet forwarding, the PE devices search for tunnels
based on tunnel IDs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN Route Selection Rules

Not all the cross routes processed by tunnel iteration are installed to VPN routing tables.
Similarly, not all the routes received from the local CE devices and the local cross routes are
injected into VPN routing tables.
When multiple routes to the same destination are available, a PE device selects one route
based on the following rules if load balancing is not configured:
l If a route received from a local CE device and a cross route are destined to the same
destination, the PE device selects the route received from the local CE device.
l If a local cross route and a cross route received from another PE device are destined for
the same destination, the PE device selects the local cross route.
If load balancing is configured, the PE device selects one route based on the following rules:
l Preferentially selects the route from the local CE device. When one route from the local
CE device and multiple cross routes exist, the PE device selects the route from the local
CE device.
l Performs load balancing between the routes from the local CE device or between the
cross routes. The PE device does not perform load balancing between the routes from the
local CE device and the cross routes.
l The AS_Path attributes of the routes participating in load balancing must be the same.
Route Advertisement in BGP/MPLS IP VPN

In basic BGP/MPLS IP VPN application, CE and PE devices are responsible for advertising
VPN routes, whereas P devices only need to maintain routes of the backbone network without
knowing VPN routes. Generally, PE devices maintain all VPN routes.
VPN routes are advertised from the local CE device to the ingress PE device, from the ingress
PE device to the egress PE device, and from the egress PE device to the remote CE device.
After the whole route advertisement process is complete, the local and remote CE devices
have reachable routes to each other, and VPN routes can be advertised on the backbone
network.
The route advertisement process is as follows:
l Route advertisement from the local CE device to the ingress PE device
After a neighbor or peer relationship is set up between a CE device and the directly
connected PE device, the CE device advertises the local IPv4 routes to the PE device.
The CE and PE devices can use static routes, the Routing Information Protocol (RIP), the
Open Shortest Path First (OSPF) protocol, the Intermediate System-to-Intermediate
System (IS-IS) protocol, or BGP (Border Gateway Protocol). No matter which routing
protocol is used, the routes advertised by the CE device to the PE device are standard
IPv4 routes.
l Route advertisement from the ingress PE device to the egress PE device
– After learning VPN routes from a CE device, the egress PE device adds RDs to
standard IPv4 routes. The routes are changed into VPN-IPv4 routes.
– The ingress PE device advertises the MP-BGP Update messages containing VPN-
IPv4 routes to the egress PE device. The Update messages contain Export Targets
and MPLS labels.
– When the egress PE device receives the VPN-IPv4 routes and if the next hops are
reachable, it performs VPN route cross, tunnel iteration, and route selection to

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
determine whether to inject the routes into the VRF. For the routes added to the
VPN routing table, the local PE stores the tunnel IDs and MPLS labels carried in
MP-BGP Update messages for subsequent packet forwarding.
l Route advertisement from the egress PE device to the remote CE device
The remote CE device can learn VPN routes from the egress PE device through static
routes, RIP, OSPF, IS-IS, or BGP. Route advertisement from the egress PE device to the
remote CE device is the same as that from the local CE device to the ingress PE device.
The routes advertised by the egress PE device to the remote CE device are standard IPv4
routes.
Figure 8-7 shows route advertisement from CE2 to CE1. In this example, BGP runs between
CE and PE devices, and LSPs are used.
Figure 8-7 Route advertisement from CE2 to CE1
CE1 Ingress PE P Egress PE CE2
IGP IP/MPLS IGP

routing table Backbone routing table
Import Import
BGP BGP
routing table routing table
BGP VPN routing VPN routing BGP
Update table table Update
Route cross&
tunnel iteration BGP
Update Routing table
Carrying label,RD,
and export RT Message
1. Interior Gateway Protocol (IGP) routes are imported into the BGP IPv4 unicast address
family of CE2.
2. CE2 advertises an EBGP Update message with routing information to the egress PE
device. After receiving the message, the egress PE device converts the route to a VPN-
IPv4 route, and then installs the route to the VPN routing table.
3. The egress PE device allocates an MPLS label to the route. Then it adds the label and
VPN-IPv4 routing information to the NLRI field and the export target to the extended
community attribute field of the MP-IBGP Update message. After that, the egress PE
device sends the Update message to the ingress PE device.
4. After receiving the message, the ingress PE device performs VPN route cross. After the
VPN route cross succeeds, the ingress PE device performs tunnel iteration based on the
destination IPv4 address to find the appropriate tunnel. If tunnel iteration succeeds, the
ingress PE device stores the tunnel ID and label, and then adds the route to the VPN
routing table of the VPN instance.
5. The ingress PE device advertises a BGP Update message with the route to CE1. The
advertised route is an IPv4 route.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6. After receiving the route, CE1 installs the route to the BGP routing table. CE1 can
import the route to the IGP routing table by importing BGP routes to IGP.
To ensure that CE1 and CE2 can communicate, CE1 also needs to advertise routes to CE2, of
which the process is similar to the preceding process.
Packet Forwarding in Basic BGP/MPLS IP VPN

In basic BGP/MPLS IP VPN applications (excluding inter-AS VPN), VPN packets are
forwarded with double labels:
l Outer label (public network label): is swapped on the backbone network, identifies an
LSP from a PE device to a remote PE device, and enables VPN packets to reach the
remote PE device through the LSP.
l Inner label (VPN label): is used when VPN packets are sent from the remote PE device
to a CE device, and identifies the site (or specifically, the CE device) to which VPN
packets are sent. The remote PE device finds the outbound interface for VPN packets
according to the inner label.
If two sites of a VPN connect to the same PE device, the PE device only needs to know how
VPN packets can reach the remote CE device.
Figure 8-8 shows packet forwarding from CE1 to CE2. In Figure 8-8, I-L indicates an inner
label, and O-L indicates an outer label.
Figure 8-8 Forwarding of a VPN packet from CE1 to CE2
IP/MPLS Backbone
CE1 Ingress PE P Egress PE CE2
data data data data data data data data

I-L I-L I-L I-L
Push O-L1 O-L1 O-L2 O-L2 Pop
Out-Label Switch
1. CE1 sends a VPN packet.

2. After receiving the packet on the interface bound to a VPN instance, the ingress PE
device processes the packet as follows:
– Searches for the corresponding VPN forwarding table based on the RD of the VPN
instance.
– Matches the destination IPv4 prefix to find the corresponding tunnel ID.
– Adds I-L to the packet and finds the tunnel based on the tunnel ID.
– Sends the packet through the tunnel and adds O-L1 to the packet.
Then the packet travels across the backbone network with double MPLS labels. Each P
device on the backbone network swaps the outer label of the packet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3. After receiving the packet with double labels, the egress PE device delivers the packet to
MPLS for processing. MPLS pops the outer label. In this example, the final outer label
of the packet is O-L2. If the PHP function is configured, the outer label is popped on the
hop before the egress PE device, and the egress PE device receives the packet with only
the inner label.
4. At this time, the egress PE device can only identify the inner label. Finding the label is at
the bottom of the label stack, and the egress PE device pops the inner label.
5. The egress PE device sends the packet to CE2. At this time, the packet is an IP packet.
The packet is successfully transmitted from CE1 to CE2. CE2 transmits the packet to the
destination according to the IP forwarding process.
8.2.3 Basic Networking
Intranet VPN
In an intranet VPN, all the users in the VPN can transmit packets to each other, but cannot
communicate with users outside the VPN. The sites within an intranet VPN usually belong to
the same organization.
In intranet VPN networking, each VPN is allocated a VPN target as the export target and
import target. The VPN target of a VPN cannot be used by other VPNs.
Figure 8-9 Intranet VPN networking

VPN1 VPN1 VPN2
Import: 100:1 Import: 200:1 VPN2
Export: 100:1 Export: 200:1
CE CE
Site1
Site4
IP/MPLS Backbone
VPN2
PE P PE VPN1
CE
CE
Site2
VPN2 VPN1 Site3
Import: 200:1 Import: 100:1
Export: 200:1 Export: 100:1
As shown in Figure 8-9, PE devices allocate the VPN target 100:1 to VPN1 and the target
200:1 to VPN2. The two sites in the same VPN can communicate with each other, whereas
sites in different VPNs cannot communicate.
Extranet VPN
If users in a VPN need to access some sites of another VPN, extranet networking can be used.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
In extranet networking, if a VPN needs to access a shared site, its export target must be
included in the import target of the VPN instance covering the shared site, and its import
target must be included in the export target of the VPN instance covering the shared site.
Figure 8-10 Extranet VPN networking

VPN1
CE VPN1
Site1 Import: 100:1
Export: 100:1
VPN1
IP/MPLS
Backbone
CE
PE1 Site3
PE2 PE3
VPN1
VPN2 Import: 100:1, 200:1
VPN2 Export: 100:1, 200:1
CE
Import: 200:1
Site2 Export: 200:1
As shown in Figure 8-10, VPN1 and VPN2 can access Site3 of VPN1.
l PE3 can receive VPN-IPv4 routes advertised by PE1 and PE2.
l PE1 and PE2 can receive VPN-IPv4 routes advertised by PE3.
Site1 and Site3 of VPN1 can communicate with each other. Site2 of VPN2 and Site3 of VPN1
PE3 does not advertise the VPN-IPv4 routes learned from PE1 to PE2 and does not advertise
the VPN-IPv4 routes learned from PE2 to PE1. Therefore, Site1 of VPN1 and Site2 of VPN2
cannot communicate with each other.
Hub and Spoke

If a central access control device needs to be deployed to control communication between
VPN users, the Hub and Spoke networking can be used. The site with the access control
device deployed is the Hub site, and other sites are Spoke sites. The following devices are
used in Hub and Spoke networking:
l Hub-CE: is deployed in the Hub site and connected to the VPN backbone network.
l Spoke-CE: is deployed in a Spoke site and connected to the VPN backbone network.
l Hub-PE: is deployed on the VPN backbone network and connected to the Hub site.
l Spoke-PE: is deployed on the VPN backbone network and connected to a Spoke site.
A Spoke site advertises routes to the Hub site, and then the Hub site advertises the routes to
other Spoke sites. Spoke sites do not advertise routes to each other. The Hub site controls
communication between all Spoke sites.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
In Hub and Spoke networking, two VPN targets are configured to represent Hub and Spoke
respectively. Figure 8-11 shows the Hub and Spoke networking.
Figure 8-11 Hub and Spoke networking

VPN1
Import:Hub
Export:Spoke
VPN1 VPN1-out
Spoke-PE Export:Hub
6
Site1 5 VPN1
Spoke-CE 4
IP/MPLS
Backbone Hub-CE
VPN1 Hub-PE 3 Site3
2
1
Spoke-CE Spoke-PE VPN1-in
Site2 VPN1 Import:Spoke
Import:Hub
Export;Spoke
The VPN targets of a PE device must comply with the following rules:
l The export target and import target of a Spoke-PE device are Spoke and Hub
respectively. The import target of any Spoke-PE device must be different from the export
target of any other Spoke-PE device.
l A Hub-PE device requires two interfaces or sub-interfaces.
– One interface or sub-interface receives routes from Spoke-PE devices. The import
target of the VPN instance on the interface is Spoke.
– The other interface or sub-interface advertises routes to Spoke-PE devices. The
export target of the VPN instance on the interface is Hub.
As shown in Figure 8-11, the Hub site controls communication between Spoke sites. The
arrows show the process of advertising a route from Site2 to Site1:
l The Hub-PE device can receive VPN-IPv4 routes advertised by all the Spoke-PE
devices.
l All the Spoke-PE devices can receive VPN-IPv4 routes advertised by the Hub-PE.
l The Hub-PE device advertises the routes learned from Spoke-PE devices to the Hub-CE
device, and advertises the routes learned from the Hub-CE device to all the Spoke-PE
devices. By doing this, the Spoke sites can access each other through the Hub site.
l The import target of any Spoke-PE device is different from the export targets of other
Spoke-PE devices. Therefore, any two Spoke-PE devices do not directly advertise VPN-
IPv4 routes to each other. The Spoke sites cannot directly communicate with each other.
8.2.4 Inter-AS VPN

The MPLS VPN solution is widely used, serving an increasing number of users in a large
number of applications. As more sites are developed in an enterprise, a site at one

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
geographical location often needs to connect to an ISP network at another geographical

location. Consider, for example, the inter-AS issue facing operators who manage different
metropolitan area networks (MANs) or backbone networks that span different autonomous
systems (AS).
Generally, MPLS VPN architecture runs within an AS. Routes of any VPN can be flooded
within the AS, and cannot be flooded to other ASs. To implement exchange of VPN routes
between different ASs, the inter-AS MPLS VPN model is used. The inter-AS MPLS VPN
model is an extension to MPLS VPN framework. Through this model, route prefixes and
labels can be advertised over links between different carrier networks.
RFC 4364 defines the following inter-AS VPN solutions:
l Inter-Provider Backbones Option A: Autonomous system boundary routers (ASBRs)

manage VPN routes for inter-AS VPNs through dedicated interfaces. This solution is
also called VRF-to-VRF.
l Inter-Provider Backbones Option B: ASBRs advertise labeled VPN-IPv4 routes to each
other through MP-EBGP. This solution is also called EBGP redistribution of labeled
VPN-IPv4 routes.
l Inter-Provider Backbones Option C: PE devices advertise labeled VPN-IPv4 routes to
each other through Multi-hop MP-EBGP. This solution is also called Multi-hop EBGP
redistribution of labeled VPN-IPv4 routes.
Inter-Provider Backbones Option A

l Introduction
Option A is a basic BGP/MPLS IP VPN application in an inter-AS scenario. In this
solution, ASBRs do not require extra configurations for inter-AS VPN or run MPLS.
ASBRs of the two ASs are directly connected and function as the PE devices of the ASs.
Each ASBR considers the peer ASBR as its CE device and creates a VPN instance for
each VPN. The ASBRs use EBGP to advertise IPv4 routes.
As shown in Figure 8-12, ASBR2 in AS200 is a CE of ASBR1 in AS 100, and ASBR1
is the CE of ASBR2. VPN LSP indicates a private tunnel, and LSP indicates a public
tunnel.
Figure 8-12 Inter-Provider Backbones Option A

VPN1-CE2
VPN1-CE1
PE1 PE3
MP
-IB GP
GP ASBR1 ASBR2 -IB
MP
AS100 AS200
P MP
Create a VPN instance -IB
- IBG GP
MP and logical interface for
each VPN
PE2 PE4
VPN LSP1 IP forwarding VPN LSP2
VPN2-CE1 LSP1 LSP2 VPN2-CE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Route advertisement
In Option A, PE and ASBR devices use MP-IBGP to exchange VPN-IPv4 routes. Two
ASBRs can run BGP, IGP multi-instance, or use static routes to exchange VPN
information. EBGP is recommended for inter-AS route exchange.
Figure 8-13 shows the process of advertising the route destined for 10.1.1.1/24 from
CE1 to CE2. In Figure 8-13, D indicates the destination address; NH indicates the next
hop; L1 and L2 are private labels. Figure 8-13 does not show advertisement of public
IGP routes and distribution of public network labels.
Figure 8-13 Route advertisement of Option A

VPN-v4 update: VPN-v4 update:
RD: 1:27:10.1.1.1/24 RD: 1:27:10.1.1.1/24
NH=PE1 NH=ASBR2
RT=100:1, Label=(L1) RT=100:1, Label=(L2)
PE1 ASBR1 ASBR2 PE3 BGP, OSPF, RIP

BGP, OSPF, RIP 10.1.1.1/24, NH=PE3
10.1.1.1/24, NH=CE1 AS100 AS200
CE1 D: 10.1.1.1/24 CE2

NH=ASBR1
10.1.1.1/24
l Packet forwarding
Figure 8-14 shows how packets are forwarded over the LSPs, which serve as the tunnels
on the public network. L1 and L2 are inner labels; Lx and Ly are outer tunnel labels.
Figure 8-14 Packet forwarding of Option A

Ly L1 10.1.1.1/24 Lx L2 10.1.1.1/24
PE1 ASBR1 ASBR2 PE3

24
10
1/
.1
1.
AS200
.
AS100
1.
.
.1
1/
10.1.1.1/24
10
24
CE1 CE2
10.1.1.1/24
l Characteristics
– Simplified configuration: MPLS does not need to run between ASBRs and no extra
configuration is required.
– Low scalability: ASBRs need to manage all VPN routes and create VPN instances
for each VPN. Because IP forwarding is performed between the ASBRs, the
ASBRs must reserve an interface for each inter-AS VPN. Therefore, the PE devices
must have high performance. If a VPN spans multiple ASs, the intermediate ASs
must support the VPN service. The configuration is complex and intermediate ASs
is affected. Option A is applicable when the number of inter-AS VPNs is small.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Inter-Provider Backbones Option B

l Introduction
In Option B, two ASBRs use MP-EBGP to exchange labeled VPN-IPv4 routes received
from the PE devices in the ASs. In the figure, VPN LSPs are private network tunnels,
and LSPs are public network tunnels.
Figure 8-15 Inter-Provider Backbones Option B

VPN1-CE2
VPN1-CE1
PE1 PE3
MP P
-IB
GP ASBR1 ASBR2 -IBG
MP
AS100 AS200
(VPN-v4) MP
P -IB
- IBG GP
MP
PE2 PE4
VPN LSP1 VPN LSP2 VPN LSP2
VPN2-CE1 LSP1 LSP2 VPN2-CE2
In Option B, the ASBRs receive all inter-AS VPN-IPv4 routes within or outside the local
AS and advertise the routes. In basic MPLS VPN implementation, a PE device stores
only the VPN routes that match the VPN target of the local VPN instance. The ASBRs
are configured to store all the received VPN routes, regardless of whether any local VPN
instance matches the routes.
All the traffic is forwarded by the ASBRs. This facilitates traffic control but increases the
load on the ASBRs. BGP routing policies, such as VPN target filtering policies, can be
configured on the ASBRs so that the ASBRs only save some of VPN-IPv4 routes.
Figure 8-16 shows how the route destined for 10.1.1.1/24 is advertised from CE1 to
CE2. D indicates the destination address; NH indicates the next hop; L1, L2, and L3 are
inner labels. Figure 8-16 does not show advertisement of public IGP routes and
distribution of public network labels.
Figure 8-16 Route advertisement of Option B

VPN-v4 update: VPN-v4 update:
RD: 1:27:10.1.1.1/24 RD: 1:27:10.1.1.1/24
NH=PE1 NH=ASBR2
RT=100:1, Label=(L1) RT=100:1, Label=(L3)
BGP, OSPF, RIP
PE1 ASBR1 ASBR2 PE3 10.1.1.1/24, NH=PE3
BGP, OSPF, RIP
10.1.1.1/24, NH=CE1 AS200
AS100
CE1 CE2
VPN-v4 update:
RD: 1:27:10.1.1.1/24
NH=ASBR1
RT=100:1, Label=(L2)
10.1.1.1/24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The route advertisement process is as follows:

a. CE1 uses BGP, OSPF, or RIP to advertise routes to PE1 in AS 100.
b. PE1 in AS 100 uses MP-IBGP to advertise labeled VPNv4 routes to ASBR1 in AS
100. If a route reflector (RR) is deployed on the network, PE1 advertises the
VPNv4 routes to the RR, and then the RR reflects the routes to ASBR1.
c. ASBR1 uses MP-EBGP to advertise the labeled VPNv4 routes to ASBR2. Because
MP-EBGP changes the next hop of the routes when advertising the routes, ASBR1
allocates a new label to the VPNv4 routes.
d. ASBR2 uses MP-IBGP to advertise the labeled VPNv4 routes to PE3 in AS 200. If
an RR is deployed on the network, ASBR2 advertises the VPNv4 routes to the RR,
and then the RR reflects the routes to PE3. When ASBR2 advertises routes to an
MP-IBGP peer in the local AS, it changes the next hop of the routes to itself.
e. PE3 in AS 200 uses BGP, OSPF, or RIP to advertise the routes to CE2.
Both ASBR1 and ASBR2 swap inner labels of the VPNv4 routes. The inter-AS labels
are carried in BGP messages, so the ASBRs do not need to run signaling protocols such
as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP).
l Packet forwarding
In Option B, both the ASBRs swap labels during packet forwarding. Figure 8-17 shows
how packets are forwarded over the LSPs, which serve as the tunnels on the public
network. L1, L2, and L3 are inner labels; Lx and Ly are outer tunnel labels.
Figure 8-17 Packet forwarding of Option B

P Ly L1 10.1.1.1/24 P
L3 10.1.1.1/24
L1 10.1.1.1/24 Lx L3 10.1.1.1/24
ASBR1 ASBR2
MP-EBGP
24
AS200
10
1/
AS100
1.
(VPN-v4)
.1
.
.1
.1
PE1
.1
L2 10.1.1.1/24
10
PE3
/2
4
CE1
CE2
10.1.1.1/24
l Characteristics
– Unlike Option A, Option B is not limited by the number of links between ASBRs.
– Information about VPN routes is stored on and advertised by ASBRs. When a large
number of VPN routes exist, the overburdened ASBRs are likely to encounter
bottlenecks. Therefore, in the MP-EBGP solution, the ASBRs that maintain VPN
routes do not perform IP forwarding on the public network.
Inter-Provider Backbones Option C

l Introduction
Option A and Option B can meet inter-AS VPN requirements. However, ASBRs need to
maintain and distribute VPN-IPv4 routes. When each AS needs to exchange a large
number of VPN routes, ASBRs may hinder network extension.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
To address this issue, PE devices can directly exchange VPN-IPv4 routes, and ASBRs do
not maintain or advertise VPN-IPv4 routes.
– The ASBRs use MP-IBGP to advertise labeled IPv4 routes to PE devices in their
respective ASs. The ASBRs also advertise labeled IPv4 routes received from PE
devices in the local AS to the ASBR peers in other ASs. The ASBRs in the transit
AS also advertise labeled IPv4 routes. A VPN LSP can be established between the
ingress PE and egress PE.
– The PE devices in different ASs establish a multi-hop EBGP connection to
exchange VPN-IPv4 routes.
– The ASBRs do not store or advertise VPN-IPv4 routes to each other.
Figure 8-18 shows the networking of inter-AS VPN Option C. In the figure, VPN LSPs
are private network tunnels, and LSPs are public network tunnels. A BGP LSP enables
two PE devices to exchange loopback interface information, and it consists of two parts,
for example, BGP LSP1 from PE1 to PE3 and BGP LSP2 from PE3 to PE1.
Figure 8-18 Inter-Provider Backbones Option C

VPN1-CE2
VPN1-CE1 Multi-Hop MP-BGP
PE1 PE3
MP P
-IB - IBG
GP ASBR1 ASBR2 MP
AS100 AS200
EBGP
GP MP
-IB -IB
MP GP
PE2 PE4
Multi-Hop MP-BGP
VPN LSP
VPN2-CE1 VPN2-CE2
LSP1 LSP2
BGP LSP2 BGP LSP1
To improve network scalability, you can specify an RR in each AS. The RR stores all
VPN-IPv4 routes and exchanges VPN-IPv4 routes with the PE devices in the local AS.
The RRs in two ASs establish an MP-EBGP connection to advertise VPN-IPv4 routes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-19 Inter-Provider Backbones Option C with an RR

VPN1-CE1 VPN1-CE2
PE1 PE3
MP-IBGP MP-IBGP
EBGP
AS100 AS200
ASBR1 ASBR2
RR1 RR2
PE2 Multi-Hop MP-EBGP

PE4
VPN LSP
VPN2-CE1 VPN2-CE2
The key to Option C is establishment of inter-AS tunnels on a public network.
Figure 8-20 shows how the route destined for 10.1.1.1/24 is advertised from CE1 to
CE2. D indicates the destination address; NH indicates the next hop; L3 indicates the
inner label. L9 and L10 are BGP LSP labels. Figure 8-20 does not show advertisement
of public IGP routes and distribution of public network labels.
Figure 8-20 Route advertisement of Option C

VPN-v4 update:
RD: 1:27:10.1.1.1/24
NH=PE1
RT=100:1, Label=(L3)
k1 D: 1.1.1.1/32
ac
o kb /32 NH=ASBR2
Lo 1.1.1 Label=(L10)
1.
PE1 ASBR1 ASBR2 PE3 BGP, OSPF, RIP
BGP, OSPF, RIP 10.1.1.1/24, NH=PE3
10.1.1.1/24, NH=CE1 AS100 AS200
CE1 D: 1.1.1.1/32 CE2

NH=ASBR1
Label=(L9)
10.1.1.1/24
l Packet forwarding
Figure 8-21 shows how packets are forwarded over the LSPs, which serve as the tunnels
on the public network. L3 is the inner label; L9 and L10 are BGP LSP labels; Lx and Ly
are outer tunnel labels.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-21 Packet forwarding of Option C

P Ly L3 10.1.1.1/24 P
L10 L3 10.1.1.1/24
L3 10.1.1.1/24 Lx L10 L3 10.1.1.1/24
ASBR1 ASBR2
EBGP
24
AS200
10
1/
AS100
.1
.1
.1
.1
PE1 L9 L3 10.1.1.1/24
.
10
1/
PE3
24
CE1
CE2
10.1.1.1/24
Before forwarding a packet to PE1, PE2 adds three labels to the packet: VPN route label,
BGP LSP label, and public LSP label. When the packet reaches ASBR2, two labels are
left: VPN route label and BGP LSP label. When the packet reaches ASBR1, the BGP
LSP label is terminated. Then common MPLS VPN forwarding is performed.
l Characteristics
– VPN routes are directly exchanged between the ingress PE and the egress PE. The
routes do not need to be stored and forwarded by intermediate devices.
– Only PE devices need to exchange VPN routes. P devices and ASBRs are only
responsible for packet forwarding. The intermediate devices need to support only
MPLS forwarding, and do not need to support MPLS VPN services. ASBRs are
unlikely to encounter bottlenecks. Option C is suitable for the VPNs that span
multiple ASs.
– MPLS VPN load balancing is easy to carry out in Option C.
– Managing an end-to-end connection between PE devices has high costs.
8.2.5 MCE
Definition
A multi-VPN-instance CE (MCE) device can function as a CE device for multiple VPN
instances in BGP/MPLS IP VPN networking. The MCE function helps reduce expenses of
network devices.
Background
BGP/MPLS IP VPN uses tunnels to transmit data of private networks on a public network. In
the traditional BGP/MPLS IP VPN architecture, each VPN instance must use a CE device to
connect to a PE device, as shown in Figure 8-22.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-22 Networking without an MCE device
CE VPN1
Site
PE CE
VPN2
IP/MPLS Site
Backbone
VPN3
CE Site
In many cases, a private network must be divided into multiple VPNs to implement fine-
grained service management and enhance security. Services of users in different VPNs must
be completely isolated. Deploying a CE device for each VPN increases the cost of device
procurement and maintenance. If multiple VPNs share one CE device, data security cannot be
ensured because all the VPNs use the same routing and forwarding table.
MCE technology ensures data security between different VPNs while reducing network
construction and maintenance costs. Figure 8-23 shows MCE networking.
Figure 8-23 Networking with an MCE device
VPN1
Site
PE MCE
VPN2
IP/MPLS
Site
Backbone
VPN3
Site
An MCE device has some PE functions. By binding each VPN instance to a different
interface, an MCE device creates and maintains an independent VRF for each VPN. This
application is also called multi-VRF application. The MCE device isolates forwarding paths
of different VPNs on a private network and advertises routes of each VPN to the peer PE
device, ensuring that VPN packets are correctly transmitted on the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Implementation
An MCE device maintains a VRF for each VPN and binds each VPN instance to an interface.
When the MCE device receives a route, it checks the receiving interface to determine the
origin of the route and adds the route to the VRF of the VPN instance bound to the interface.
The PE interfaces connected to the MCE device must also be bound to the VPN instances.
The bindings between interfaces and VPN instances on the PE device must be the same as
those on the MCE device. When the PE device receives a packet, it checks the receiving
interface to determine to which VPN the packet belongs, and then transmits the packet in the
corresponding tunnel.
In Figure 8-23:
l The MCE device saves routes learned from VPN1 in VRF1.
l The PE device saves routes of VPN1 learned from the MCE device in VRF1.
l Routes of VPN2 and VPN3 are isolated from routes of VPN1, and are not saved in
VRF1.
The MCE device exchanges routes with VPN sites and PE device in the following ways:
l Route exchange with VPN sites
Route Implementation
Exchange
Method
Static routes Static routes are bound to VPN instances on the MCE device. Static
routes of different VPNs are isolated even if VPNs use overlapping
address spaces.
Routing Each VPN instance is bound to a RIP process on the MCE device so that
Information routes of different VPNs are exchanged between the MCE device and
Protocol VPN sites using different RIP processes. This isolates routes of different
(RIP) VPNs and ensures security of VPN routes.
Open Each VPN instance is bound to an OSPF process on the MCE device to
Shortest isolate routes of different VPNs.
Path First
(OSPF)
Intermediate Each VPN instance is bound to an IS-IS process on the MCE device to
System to isolate routes of different VPNs.
Intermediate
System (IS-
IS)
Border Each VPN instance is configured with a BGP peer on the MCE device.
Gateway The MCE imports IGP routes of each VPN to the BGP routing table of
Protocol the VPN.
(BGP)
l Route exchange with the PE device

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Routes of different VPN instances are isolated on the MCE device. The MCE and PE
devices identify packets of different VPN instances according to bindings between
interfaces and VPN instances. An administrator only needs to perform simple routing
configuration on the MCE and PE devices, and to import the VPN routes of the MCE
device to the routing protocol running between the MCE and PE devices.
The MCE and PE devices can use static routes, RIP, OSPF, IS-IS, or BGP to exchange
routes.
8.2.6 HoVPN
Definition
Hierarchy of VPN (HoVPN) is a multi-layer VPN architecture that deploys PE functions on
multiple PE devices. In this architecture, multiple PE devices play different roles and fulfill
the functions of one PE. HoVPN is also called hierarchy of PE (HoPE).
Background
As key devices on a BGP/MPLS IP VPN network, PE devices provide must provide a large
number of interfaces for user access, and provide large-capacity memory and high forwarding
capabilities to manage and advertise VPN routes, and process user packets.
Most networks use typical hierarchical architecture. For example, a MAN uses a three-layer
architecture consisting of the core, aggregation, and access layers. From the core layer to the
access layer, the requirements for device performance decreases, but the network scale
increases.
BGP/MPLS IP VPN uses a plane model, which has the same performance requirement for all
the PE devices. If some PE devices do not provide high performance or scalability, the entire
network is affected.
Because the plane model of BGP/MPLS IP VPN is different from the typical hierarchical
architecture, deployment of new PE devices at each layer is difficult due to low scalability.
This plane model hinders large-scale VPN deployment. The HoVPN solution is developed to
address this issue.
In the HoVPN model, devices at higher layers must have high routing and forwarding
capabilities, whereas devices at lower layers can have lower capabilities.
Implementation
l HoVPN architecture

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-24 HoVPN architecture

CE
VPN1
Site1 VPN2
CE
Site3
PE
VPN2
SPE
Site1 UPE
CE IP/MPLS
Backbone
HoPE
CE
CE
VPN1 PE
Site2
VPN1
UPE Site3
VPN2
Site2 CE
As shown in Figure 8-24, the devices directly connected to user devices are called
underlayer PE or user-end PE (UPE) devices. The device that is deployed within the
backbone network and connected to UPE devices is called a superstratum PE or service
provider-end PE (SPE) device.
Multiple UPE devices and an SPE device form a hierarchy of PE and provide functions
of a traditional PE device.
l Relationship between the UPE and SPE
– The UPE device provides user access. It maintains routes of directly connected
VPN sites, but does not maintain routes of remote VPN sites or only maintains
summarized routes of remote VPN sites. Each UPE device assigns an inner label to
routes of directly connected sites and uses MP-BGP to advertise the label with the
VPN routes to the SPE device.
– The SPE device manages and advertises VPN routes. It maintains all the routes of
the VPN sites connected through the UPE devices, including routes of local and
remote sites. However, the SPE does not advertise routes of remote sites to the UPE
devices. Instead, it advertises only default routes of VPN instances with labels.
– The UPE and SPE devices use label forwarding. The SPE device uses only one
interface to connect to each UPE device and does not need to provide many
interfaces for access users. An UPE device can connect to the SPE device through a
physical interface, a sub-interface, or a tunnel interface. If a tunnel interface is used,
the UPE and SPE devices can communicate across an IP or MPLS network.
Labeled packets are transmitted between the UPE and SPE devices through a
tunnel. If a GRE tunnel is used, GRE must support encapsulation of MPLS packets.
As an SPE device and a UPE device play different roles, requirements for them are
different:
n An SPE device has a large routing table, high forwarding performance, but few
interfaces.
n A UPE device has a small routing table, low forwarding performance, and high
access capabilities.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
A PE device is a SPE device for a lower-layer PE device and is a UPE device for an
upper-layer PE device.
An HoPE can coexist with common PE devices on an MPLS network.
l SPE-UPE
If a UPE device and an SPE device belong to the same AS, MP-BGP running between
them is MP-IBGP. If they belong to different ASs, MP-BGP running between them is
MP-EBGP.
When MP-IBGP is used, an SPE device can function as an RR of multiple UPE devices
to advertise routes between the IBGP peers. To reduce the number of routes on the UPE
devices, do not use the SPE as an RR for other PE devices.
A UPE device can connect to multiple SPE devices. This networking is called UPE
multi-homing. In this networking, the SPE devices advertise the VRF default routes to
the UPE device. The UPE device selects one route as the optimal route or selects
multiple routes to perform load balancing. The UPE device advertises all the VPN routes
to the SPE devices or advertises some of VPN routes to each SPE to implement load
balancing.
l Label operation in HoVPN
Figure 8-25 shows an example of label operation in HoVPN. In this example, an LSP
tunnel is set up between the SPE and PE devices.
Figure 8-25 Label operation in HoVPN

Swap inner label
Inner Out-layer
Inner Data
Data SPE label-2 label PE
label-1
Inner Out-layer
UPE Inner Data
Data label-1 label
label-2
Data
Swap inner label Data
Data Data
CE1 CE2
– CE1 → CE2 (marked by the black line)

n After receiving a packet from CE1, the UPE device adds an inner label to the
packet and forwards the packet to the SPE device.
n After receiving the labeled packet, the SPE device swaps the inner label, adds
an outer LSP label to the packet, and sends the packet to the PE device.
n After the packet arrives at the previous hop of the PE device, this hop pops the
outer LSP label. The process is called penultimate hop popping.
n After the PE device receives the packet, it pops the inner label.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– CE2 → CE1 (marked by the blue line)

n After receiving a packet from CE2, the PE device adds an inner label and an
outer LSP label to the packet, and then forwards the packet to the SPE device.
n After the packet arrives at the previous hop of the SPE device, this hop pops
the outer LSP label.
n The SPE device swaps the inner label for a new one and forwards the packet to
the UPE device.
n After the UPE device receives the packet, it pops the inner label.
l HoVPN embedding and extension
HoVPN supports HoPE embedding.
– An HoPE can function as a UPE device and compose a new HoPE with an SPE
device.
– An HoPE can function as an SPE device and compose a new HoPE with multiple
UPE devices.
– HoPEs can be embedded multiple times in the preceding two modes.
HoPE embedding can infinitely extend a VPN.
Figure 8-26 HoPE embedding

SPE
MPE UPE
UPE UPE
CE CE CE CE
Site Site Site Site
Figure 8-26 shows a three-layer HoPE, and the PE device in the middle is called the
middle-level PE (MPE) device. MP-BGP runs between the SPE and MPE devices, and
between the MPE and UPE devices.
NOTE
Actually, the MPE device does not exist in an HoVPN model. The concept is used just for the
convenience of description.
MP-BGP advertises all the VPN routes of the UPE devices to the SPE device, but
advertises only the default VPN routes of the SPE device to the UPE devices.
The SPE device maintains the routes of all VPN sites connected to the PE devices,
whereas the UPE devices maintain only the VPN routes of the directly connected VPN
sites. The quantities of routes maintained by the SPE, MPE, and UPE devices are in
descending order.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Advantages of HoVPN
The HoVPN model has the following advantages:
l A BGP/MPLS IP VPN network can be divided into different hierarchies. If the
performance of UPE devices does not satisfy service requirements, an SPE device can be
added above UPE devices. When access capabilities of an SPE device are insufficient,
UPE devices can be added below the SPE device.
l Label forwarding is performed between UPE and SPE devices. Therefore, a UPE device
and an SPE device are interconnected through only a pair of interfaces or sub-interfaces.
This saves interface resources.
l If a UPE device and an SPE device are separated by an IP or MPLS network, they can
set up a GRE or LSP tunnel. A layered MPLS VPN has enhanced scalability.
l The UPE devices maintain only the local VPN routes, and all the remote routes are
represented by a default or summarized route. This reduces loads on the UPE devices.
l SPE and UPE devices use MP-BGP to exchange routes and advertise labels. Each UPE
device sets up only one MP-BGP peer, reducing the protocol cost and configuration
workload.
8.2.7 VPN FRR

Definition
As networks develop rapidly, the time used for end-to-end service convergence if a fault
occurs on a carrier's network has been used as an indicator to measure bearer network
performance. MPLS TE Fast Reroute (FRR) is one of the commonly used fast switching
technologies. The solution is to create an end-to-end TE tunnel between two PEs and a
backup LSP that protects a primary LSP. When either of the PE devices detects that the
primary LSP is unavailable because of a node or link failure, the PE switches the traffic to the
backup LSP.
MPLS TE FRR protects services in the case of a link or node failure between two PE devices
at both ends of a TE tunnel; however, MPLS TE FRR cannot protect services in the case of a
PE device failure. If a fault occurs on the ingress or egress, services can only be restored
through end-to-end route convergence and LSP convergence. The service convergence time is
closely related to the number of routes inside an MPLS VPN and the number of LSP hops on
the bearer network. The more VPN routes, the longer the service convergence time, and the
more traffic is lost.
VPN FRR sets in advance on a remote PE device forwarding entries pointing to the active and
standby PE devices, respectively. In collaboration with fast PE fault detection, VPN FRR can
reduce end-to-end service convergence time if a fault occurs on an MPLS VPN where a CE
device is dual-homed to two PE devices. In VPN FRR, service convergence time depends on
only the time required to detect remote PE device faults and change tunnel status. VPN FRR
enables the service convergence time to be irrelevant to the number of VPN routes on the
bearer network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Implementation
Figure 8-27 Typical VPN FRR networking

IP/MPLS
Backbone PE2
VPN Site Link A VPN Site

CE1 PE1 CE2
Link B
PE3
As shown in Figure 8-27, normally, CE1 accesses CE2 over Link A. If PE2 is Down, CE1
accesses CE2 over Link B.
l Based on the traditional BGP/MPLS VPN technology, both PE2 and PE3 advertise
routes destined for CE2 to PE1, and assign VPN labels to these routes. PE1 then selects a
preferred VPNv4 route based on the routing policy. In this example, the preferred route
is the one advertised by PE2, and only the routing information, including the forwarding
prefix, inner label, selected LSP, advertised by PE2 is filled in the forwarding entry of
the forwarding engine to guide packet forwarding.
l When PE2 fails, PE1 detects the fault of PE2 (the BGP peer relationship becomes Down
or the outer LSP is unavailable). Then PE1 selects the route advertised by PE3 and
updates the forwarding entry to complete end-to-end convergence. Before PE1 delivers
the forwarding entry matching the route advertised by PE3, CE1 cannot communicate
with CE2 for a certain period because the destination of the outer LSP, PE2, is Down. As
a result, end-to-end services are interrupted.
l VPN FRR is an improvement on the traditional reliability technology. VPN FRR enables
PE1 to add the optimal route advertised by PE2 and the secondary optimal route
advertised by PE3 to a forwarding entry. The optimal route is used for traffic forwarding,
and the secondary optimal route is used as a backup route.
l If a fault occurs on PE2, the MPLS LSP between PE1 and PE2 becomes unavailable.
After detecting the fault, PE1 marks the corresponding entry in the LSP status table as
unavailable, and delivers the setting to the forwarding table. After selecting a forwarding
entry, the forwarding engine examines the status of the LSP corresponding to the
forwarding entry. If the LSP is unavailable, the forwarding engine uses the second-best
route carried in the forwarding entry to forward packets. After being tagged with the
inner labels assigned by PE3, packets are transmitted to PE3 over the LSP between PE1
and PE3 and then forwarded to CE2. In this manner, fast end-to-end service convergence
is implemented and traffic from CE1 to CE2 is restored.
VPN FRR performs fast switching based on inner labels. Outer tunnels can be LDP LSPs or
RSVP TE tunnels. When the forwarding engine detects that the outer tunnel is unavailable, it
triggers fast switching based on inner labels.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.2.8 VPN GR
NOTE
The AR3260 can function as both the GR restarter and GR helper, and other devices can only function
as the GR helper.
Definition
VPN GR is an application of GR technology on a VPN. VPN GR ensures uninterrupted VPN
traffic forwarding when an active/standby switchover is performed on a device transmitting
VPN services. The purposes of VPN GR are as follows:
l Reduce the impact of route flapping on the entire network during the switchover.
l Reduce the impact on important VPN services.
l Reduce single-point failures on PE or CE devices to improve VPN network reliability.
Prerequisites for VPN GR

The device where an active/standby switchover occurs and its connected devices must have
GR capabilities. They must retain forwarding information of all VPN routes within a period to
ensure uninterrupted VPN traffic forwarding. That is, the devices must support IGP GR, BGP
GR, and LDP GR. If TE tunnels are deployed on the backbone network, the devices must
support RSVP GR.
Implementation
On a common BGP/MPLS VPN network, active/standby switchovers may occur on any PE,
CE, or P device.
l Active/standby switchover on a PE device
The GR process on a PE device is the same as that on the GR restarter in IGP GR, BGP
GR, or LDP GR.
When a CE device connected to the PE device detects the restart of the PE device, the
CE device acts the same as the GR helper IGP GR or BGP GR and retains all IPv4 routes
in a period.
When the P device connected to the PE device detects the restart of the PE device, the P
device acts the same as the GR helper in IGP GR, BGP GR, or LDP GR and retains all
public IPv4 routes in a period.
When other PE devices (including those functioning as ASBRs) and the RR reflecting
VPNv4 routes detect the restart of the PE device, they act the same as the GR helper in
BGP GR, and retain all the public IPv4 routes and VPNv4 routes in a period.
l Active/standby switchover on a P device
The GR process on a P device is the same as that on the GR restarter in IGP GR, BGP
GR, or LDP GR.
When a P or PE device connected to this P device detects the restart, the P or PE device
acts the same as the GR helper in IGP GR, BGP GR or LDP GR and retains all the
public IPv4 routes in a period.
l Active/standby switchover on a CE device
The GR process on a CE device is the same as that on the GR restarter in IGP GR or
BGP GR.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When the PE device connected to the CE device detects the restart of the CE device, the
PE device acts the same as the GR helper in IGP GR or BGP GR and retains all the
private IPv4 routes in a period.
For details about IGP GR and BGP GR, see "GR" in the Huawei
For details about LDP GR and RSVP GR, see "GR" in the Huawei
Enterprise Routers Configuration Guide - MPLS.
8.2.9 VPN NSR

The BGP/MPLS IP VPN supports Non-stop Routing (NSR), which ensures uninterrupted
VPN operating during an active/standby switchover. For details about NSR, see "NSR" in the
Feature Description - ReliabilityHuawei
Enterprise Routers Configuration Guide - Reliability.
NSR backs up the following data to ensure uninterrupted BGP/MPLS IP VPN operating:
l VPN forwarding table
l Labels
8.2.10 VPN Tunnel Policy

Introduction to VPN Tunnels
VPN data is transmitted over tunnels, including LSP tunnels, GRE tunnels, and Traffic
Engineering (TE) tunnels. TE tunnels are constraint-based routed label switched path (CR-
LSP) tunnels.
l GRE tunnel
If PE devices support MPLS functions but P devices on the backbone network provide
only IP functions, LSPs cannot serve as tunnels. In this situation, GRE tunnels can be
used as the tunnels of the VPN backbone network.
For details about GRE, see 4 GRE Configuration in the Huawei
Enterprise Routers Configuration Guide - VPN.
l LSP
An LSP forwards packets through label switching and is often used in BGP/MPLS IP
VPN. If LSPs are used as public network tunnels, only PE devices need to analyze IP
packet headers, and other devices that VPN packets pass do not need to analyze IP
packet headers. This reduces VPN packet processing time and packet transmission delay.
In addition, MPLS labels are supported by all link layers. An LSP is similar to an ATM
virtual circuit (VC) or FR VC in functions and security. If all the devices on the
backbone network support MPLS, it is recommended that LSP tunnels or MPLS TE
tunnels be used as public network tunnels.
For details about LSPs, see MPLS LDP Configuration in the Huawei
l MPLS TE tunnel

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As a combination of MPLS and TE technologies, MPLS TE can balance network traffic

by setting up LSPs along specified nodes and steering traffic away from congested
nodes. LSPs in MPLS TE are called MPLS TE tunnels, which are also widely used in
BGP/MPLS IP VPN.
Besides advantages of LSP, MPLS TE tunnels is capable of handling network
congestion. Using MPLS TE tunnels, SPs can fully utilize existing network resources to
provide diversified services. MPLS TE tunnels also allow SPs to optimize network
resources and manage resources.
Usually, carriers are required to provide VPN users with end-to-end QoS for various
services, such as voice, video, key-data services, and Internet access. MPLS TE tunnels
can offer users with QoS guarantee.
Using MPLS TE tunnels, carriers can also provide required QoS guaranteed services for
different VPN users based on policies.
For details about MPLS TE, see MPLS TE Configuration in the Huawei
Tunnel Policy
VPN services are transmitted over tunnels. By default, LSPs are preferred in VPN service
transmission, and only one LSP serves one VPN service.
When VPN services need to be transmitted over a specified TE tunnel or when load balancing
needs to be performed among multiple tunnels to fully use network resources, tunnel policies
need to be applied to VPNs. Tunnel policies are classified into two types, which cannot be
configured simultaneously:
l Tunnel type prioritization policy: specifies the sequence in which each type of tunnel is
selected and the number of tunnels participating in load balancing. Tunnels defined in a
tunnel type prioritization policy are selected in sequence: The tunnels of the type
specified first are selected as long as the tunnels are in Up state, regardless of whether
they are in use. The tunnels of the type specified later are not selected unless load
balancing is required or the tunnels of the type specified first are all Down.
For example, a tunnel policy defines the following rules: Both CR-LSPs and LSPs can
be used, CR-LSPs are prior to LSPs, and the number of tunnels participating in load
balancing is 3. Tunnels are selected as follows:
– CR-LSPs in Up state are preferred. If three or more CR-LSPs are in Up state, the
three CR-LSPs listed earlier are selected.
– If there are less than three CR-LSPs in Up state, LSPs are selected. For example, if
only one CR-LSP is in Up state, two LSP tunnels can be selected. If only one LSP
or none is in Up state, the existing tunnels in Up state are used. If more than two
LSPs are in Up state, only the first two LSPs are selected.
NOTE
If a TE tunnel is reserved for tunnel binding, the TE tunnel cannot be selected.

The tunnel type prioritization policy cannot specify the desired tunnels to use when
multiple tunnels of the same type are available.
l Tunnel binding policy: specifies TE tunnels for carrying services of a VPN. You can
specify multiple TE tunnels to the same destination for load balancing. You can also
determine whether to use other tunnels to prevent traffic interruption when the specified
tunnels are all unavailable. The rules for tunnel selection are as follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– Specified TE tunnels in Up state are selected to perform load balancing.

– If all the specified TE tunnels are unavailable, no other tunnel is selected by default.
If you enable a PE device to select other tunnels in this situation, the PE device
selects an available tunnel in the order of LSP and CR-LSP.
A tunnel binding policy can specify accurate TE tunnels over which VPN services are
transmitted. TE tunnels have high reliability and guaranteed bandwidth, so tunnel
binding policies can be used for VPN services requiring QoS guarantee. As shown in
Figure 8-28, two MPLS TE tunnels, Tunnel1 and Tunnel2, are set up between PE1 and
PE3.
Figure 8-28 Networking diagram of VPN tunnel binding
VPNA VPNA
CE1 CE3 Site3

Site1 IP/MPLS
Backbone
TE Tunnel1 for VPNA
PE1 PE3
TE Tunnel2 for VPNB
Site4
Site2
CE2 CE4
VPNB VPNB
If you bind VPN A to Tunnel1 and VPN B to Tunnel2, VPN A and VPN B use different
TE tunnels. Tunnel1 serves only VPN A, and Tunnel2 serves only VPN B. In this
manner, services of VPN A and VPN B are isolated from each other and also from other
services. The bandwidth for VPN A and VPN B is ensured. This facilitates subsequent
QoS deployment.
Tunnel Selector
In HoVPN or inter-AS VPN Option B, SPE devices or ASBRs accept VPNv4 routes from all
the UPE or PE devices. Currently, PE devices iterate LSP tunnels for VPNv4 routes.
Sometimes, TE tunnels need to be iterated for VPNv4 routes to provide guaranteed
bandwidth; the PE devices cannot provide this function by default.
In inter-AS VPN Option C, PE devices select LSP tunnels for BGP-IPv4 labeled routes. To
provide guaranteed bandwidth, TE tunnels need to be iterated for VPNv4 routes, which
cannot be implemented on the PE devices by default.
Tunnel selector addresses this issue.
The tunnel selector can filter VPNv4 routes or BGP-IPv4 labeled routes and apply a tunnel
policy to the routes that pass the filtering criteria. In this way, expected tunnels can be
selected based on the tunnel policy.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.3 Application Scenarios for BGP/MPLS IP VPN

This section describes the application scenarios for BGP/MPLS IP VPN.
8.3.1 BGP/MPLS IP VPN Application

Service Overview
Figure 8-29 shows a typical networking diagram for a carrier. Site1 and Site2 represent two
networks in different cities. The two networks may be networks for two branches of a
company, or networks for municipal governments of the two cities. During communication
between Site1 and Site2, data security must be ensured. The two networks must be separated
from other networks and packets exchanged between the two networks must be transparently
transmitted over the carrier's backbone network. BGP/MPLS VPN technology can meet such
service requirements. VPN labels assigned using MP-BGP enable packets to enter the correct
VPN site and MPLS enables packets to be transparently transmitted over tunnels on the
carrier's backbone network.
Figure 8-29 BGP/MPLS IP VPN application
IP/MPLS Backbone
PE1 P1 PE3
CE1 CE2
VPN 1 VPN 1
RR2 Site2
Site1
RR1
PE2 P2
PE4
PE and P devices on the carrier's backbone network must be used to transmit routes and
packets between Site1 and Site2 from the two networks to communicate. CE devices can be
dual-homed to PE devices to ensure high network availability. Generally, a carrier deploys
route reflectors (RRs) on the backbone network to reflect VPNv4 and VPNv6 routes.
Feature Deployment
In BGP/MPLS IP VPN networking, the following configurations must be performed:
l Configure static routes between CE devices and PE devices or configure RIP, OSPF, IS-
IS, or BGP on CEs and PEs for them to exchange routing information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configure MP-BGP peer relationships between all PE devices and RR1 and between all
PE devices and RR2. Configure all PE devices as the clients of RR1 and RR2 and
configure RR1 and RR2 to back up each other. These configurations ensure network
reliability.
l Configure MPLS and an IGP on PE and P devices and establish MPLS tunnels for traffic
forwarding.
l Adjust IGP costs of links to:
– Ensure that the two links between CE1 and CE2 work in active/standby mode. If
one link fails, traffic is switched to the other link for transmission.
– Adjust the costs of links between RRs and the backbone network. Ensure that RRs
are used only for route reflection, not for traffic forwarding.
l Configure VPN FRR for services that have high requirements on real-time transmission
to enhance network reliability.
8.3.2 Hub and Spoke Networking Application

Service Overview
Financial enterprises such as banks can use the Hub&Spoke networking mode to ensure
financial data security. Hub&Spoke networking allows branches to exchange data only
through the headquarters. In this manner, data transmission between branches is under
effective supervision.
In Hub&Spoke networking, the site where the access control device of the headquarters is
located is called a Hub site; other sites where branches are located are called Spoke sites. At
the Hub site, a device that connects to the VPN backbone network is called a Hub-CE device.
At a Spoke site, a device that connects to the VPN backbone network is called a Spoke-CE
device. On the VPN backbone network, a device that connects to the Hub site is called a Hub-
PE device, and a device that connects to a Spoke site is called a Spoke-PE device.
A Spoke site advertises routes to the Hub site. The Hub site then advertises the routes to other
Spoke sites. Spoke sites do not advertise routes to each other. The Hub site controls
communication between all the Spoke sites.
In Hub and Spoke networking, the following solutions can be used:
l EBGP running between the Hub-CE and Hub-PE devices, and between Spoke-PE and
Spoke-CE devices
l IGP running between the Hub-CE and Hub-PE devices, and between Spoke-PE and
Spoke-CE devices
l EBGP running between the Hub-CE and Hub-PE devices, and IGP running between
Spoke-PE and Spoke-CE devices
The following describes these networking solutions in detail:
l EBGP running between the Hub-CE and Hub-PE devices, and between Spoke-PE and
Spoke-CE devices
As shown in Figure 8-30, a route advertised by a Spoke-CE device is forwarded to the
Hub-CE and Hub-PE device before being transmitted to other Spoke-PE devices. If
EBGP runs between the Hub-PE and the Hub-CE device, the Hub-PE device performs an

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
AS-Loop check on the route. When the Hub-PE device detects its own AS number in the
route, it discards the route. To implement Hub and Spoke networking, the Hub-PE device
must be configured to allow repeated AS numbers.
Figure 8-30 EBGP running between the Hub-CE and Hub-PE devices, and between
AS65401 Spoke-PE1
EBGP
Spoke-CE1 EBGP
IBGP Hub-CE
VPN_in
IP/MPLS Backbone
AS100
Spoke-CE2 IBGP EBGP
AS65403
EBGP Hub-PE VPN_out
Spoke-PE2
AS65402
l IGP running between the Hub-CE and Hub-PE devices, and between Spoke-PE and
Spoke-CE devices
As shown in Figure 8-31, all PE and CE devices exchange routes using an IGP, and IGP
routes do not contain the AS_Path attribute. Therefore, the AS_Path field of BGP
VPNv4 routes is empty.
Figure 8-31 IGP running between the Hub-CE and Hub-PE devices, and between
AS65401 Spoke-PE1
OSPF100
Spoke-CE1 vpn1 OSPF 100 Hub-CE
IBGP
vpn_in
IP/MPLS Backbone
AS100 OSPF 200
Spoke-CE2 IBGP
OSPF100 vpn_out AS65403
vpn1 Hub-PE
Spoke-PE2
AS65402
l EBGP running between the Hub-CE and Hub-PE devices, and IGP running between
As shown in Figure 8-32, the network topology is similar to that shown in Figure 8-30.
The AS_Path attribute of the routes forwarded by the Hub-CE device to the Hub-PE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
device contains the AS number of the Hub-PE device. Therefore, the Hub-PE device
must be configured to allow repeated AS numbers.
Figure 8-32 EBGP running between the Hub-CE and Hub-PE devices, and IGP running
between Spoke-PE and Spoke-CE devices
AS65401 Spoke-PE1
OSPF100
Spoke-CE1 vpn1 EBGP
IBGP Hub-CE
vpn_in
IP/MPLS Backbone
AS100 EBGP
Spoke-CE2 IBGP
OSPF100 vpn_out AS65403
vpn1 Hub-PE
Spoke-PE2
AS65402
8.3.3 Interconnection Between VPNs and the Internet

Generally, users within a VPN can only communicate with other users in the same VPN. They
cannot communicate with users on the Internet or connect to the Internet. However, VPN sites
may need to access the Internet. To implement interconnection between a VPN and the
Internet, the following conditions must be met:
l The devices in the VPN that need to access the Internet have reachable routes to the
Internet.
l Routes are available from the Internet to the devices in the VPN.
l Similar to interconnection between non-VPN users and the Internet, security
mechanisms such as firewalls must be used.
Interconnection between a VPN and the Internet can be implemented in the following ways:
l Interconnection implemented on a PE device: PE devices of the backbone network
identify data streams destined for the VPN and those destined for the Internet, and then
forward the data to the Internet and the VPN respectively. PE devices provide the
firewall function between the VPN and the Internet.
l Interconnection implemented on an Internet gateway: Internet gateways are carrier
devices connected to the Internet. They must support VPN route management. For
example, a PE device that has no VPN user attached can function as an Internet gateway.
l Interconnection implemented on a CE device: CE devices of the private network
identify data streams destined for the VPN and those destined for the Internet, and then
direct the data to two areas. One area connects to the VPN through a PE device, and the
other area connects to the Internet through an ISP router that does not belong to the
VPN. The CE devices provide the firewall function.
Interconnection Implemented on a PE Device

Generally, default static routes are used.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l The PE device sends a default route destined for the Internet to the CE device.
l The PE device adds a default route destined for the Internet gateway to the VPN routing
table.
l To ensure that the Internet has a route to the VPN, the PE device must have a static route
to the CE in the public routing table and advertise this route to the Internet. The static
route is manually added to the public routing table of the PE device. In the static route,
the destination address is the address of the VPN user, and the outbound interface is the
PE interface that connects to the CE device. The PE uses an IGP to advertise the route to
the Internet.
Figure 8-33 Interconnection implemented on a PE Device
Internet
Internet
Gateway
IP/MPLS
Backbone
VPN site
CE PE
Interconnection Implemented on an Internet Gateway

An instance is configured for each VPN on the Internet gateway. Each VPN uses one interface
to access the Internet, and the interface is bound to the VPN instance.
Figure 8-34 Interconnection implemented on an Internet gateway
Internet
VPN-instance
Internet
Gateway
IP/MPLS
Backbone
VPN site
CE PE
Interconnection Implemented on a CE Device

Interconnection between a VPN and the Internet can be implemented on a CE device in the
following ways:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l The CE device directly connects to the Internet, as shown in Figure 8-35.

A direct connection with the Internet can be achieved in the following modes:
– One of sites (for example, central site) connects to the Internet. The CE device in
the central site has a default route to the Internet, which is advertised to other sites
through the backbone network. The firewalls are deployed only in the central site.
In this mode, all the traffic to the Internet passes through the VPN backbone
network except the traffic of the central site. A typical application of this mode is
connections between the Internet and Hub sites in Hub and Spoke networking.
– Each site connects to the Internet. Each CE device has a default route to the Internet
and configured with the firewall functions. None of traffic to the Internet passes
through the VPN backbone network.
Figure 8-35 A CE device directly connects to the Internet
Internet
IP/MPLS
Backbone
VPN site
CE PE
l A single CE interface or sub-interface connects to a PE device. The PE device injects

routes of the CE device into the public routing table and advertises the routes to the
Internet. Then the PE device advertises the default route or the Internet routes to the CE
device. The interface that connects to the PE device does not belong to any VPN and is
not associated with any VPN instance. That is, the interface can act as a VPN user and a
non-VPN user to connect to the PE device, as shown in Figure 8-36.
It is recommended that a tunnel be set up between the VPN backbone device connected
to the Internet and the PE device connected to the CE device. Internet routes are
transmitted through the tunnel, and P devices do not accept the Internet routes.
Figure 8-36 A single CE interface connects to a PE device
Internet
CE IP/MPLS
VPN-instance Backbone
VPN site
PE
Comparison Between the Three Solutions

Interconnection implemented on a PE device can save interface resources and allow different
VPNs to share one public IP address. However, the configuration on the PE device is

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
complex, and security cannot be guaranteed. Denial of Service (DoS) attacks from the Internet
may occur on the PE device. When this occurs, the link between the PE and CE devices is
occupied by a large amount of attack traffic, and cannot transmit valid VPN packets.
Interconnection implemented on an Internet gateway provides higher security than that on a

PE device. An Internet gateway, however, must be configured with multiple VPN instances,
which may overburden the gateway. In addition, an Internet gateway has multiple interfaces
connected to the Internet, and each interface has a public network IP address. Each VPN uses
an interface on the gateway and one public network IP address.
Interconnection implemented on a CE device is simple to deploy. This solution has high

security and reliability because public routes are separated from VPN routes. However, this
solution consumes interface resources and each VPN needs a public network address.
Table 8-1 Comparison between three solutions
Solution Security Used Interface Used Public IP Easiness

Address of
Deployme
nt
Interconne Low The PE device reserves Multiple VPNs on Difficult

ction only one interface for the PE device
implement both VPN access and share a public IP
ed on a PE Internet access. This address.
device solution saves interface
resources.
Interconne High The Internet gateway Each VPN uses a Difficult

ction must reserve an interface public IP address.
implement for each VPN to access
ed on an the Internet. This
Internet solution consumes
gateway interface resources of the
gateway.
Interconne High The CE device must Each VPN uses a Easy

ction reserve an interface for public IP address.
implement each VPN to access the
ed on a CE Internet. This solution
consumes interface
resources of the CE.
8.4 Summary of BGP/MPLS IP VPN Configuration Tasks

After basic BGP/MPLS IP VPN configurations are complete, a simple VPN network can be
established using MPLS technology. To deploy special BGP/MPLS IP VPN networking,
perform other configuration tasks according to the reference sections provided in the
following table.
Table 8-2 lists the BGP/MPLS IP VPN configuration tasks.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 8-2 BGP/MPLS IP VPN configuration tasks

Configure basic This configuration establishes a 8.7.1 Configuring Basic BGP/

BGP/MPLS IP simple BGP/MPLS IP L3VPN MPLS IP VPN Functions
VPN functions network with basic functions.
Configure BGP/ You adjust the basic BGP/MPLS 8.7.1 Configuring Basic BGP/
MPLS IP VPN in IP L3VPN configurations in MPLS IP VPN Functions
various different networking mode to 8.7.2 Configuring Hub and
networking implement flexible Spoke
modes communication and isolation
between VPNs:
l Intranet VPN and extranet
VPN networking: The
configurations are same as the
configurations in basic BGP/
MPLS IP VPN networking
except for the VPN target
setting.
l Hub and Spoke networking:
configure the Hub and Spoke.
Configure inter- Configure inter-AS VPN if the 8.7.3 Configuring Inter-AS VPN
AS VPN backbone network spans multiple Option A
ASs. Three inter-AS VPN 8.7.4 Configuring Inter-AS VPN
solutions are available, applicable Option B
to different scenarios:
8.7.5 Configuring Inter-AS VPN
l Inter-AS VPN Option A: Use Option C (Solution 1)
this solution when only a few
VPNs are configured on the 8.7.6 Configuring Inter-AS VPN
PE devices. The ASBRs must Option C (Solution 2)
support VPN instances.
l Inter-AS VPN Option B: Use
this solution when many VPNs
are configured on the PE
devices, and the ASBRs do not
have enough interfaces to
reserve an interface for each
inter-AS VPN. The ASBRs
must be able to maintain and
advertise VPN-IPv4 routes.
l Inter-AS VPN Option C: Use
this solution when a large
number of VPN routes need to
be exchanged between ASs.
This solution mitigates the
loads on ASBRs so that they
will not become the bottleneck
on the network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure an An MCE device can connect to 8.7.7 Configuring an MCE

MCE device multiple VPNs. The MCE Device
solution isolates services of
different VPNs while reducing
cost of CE devices.
Configure HoVPN can reduce loads on PE 8.7.8 Configuring HoVPN

HoVPN devices. In an HoVPN
networking, aggregation and
access devices function as user-
end provider edge (UPE) devices
and work with the superstratum
provider edge (SPE) devices on
the backbone to provide PE
functions.
Configure OSPF To ensure that VPN traffic is 8.7.10 Configuring an OSPF

sham links forwarded over the backbone Sham Link
network but not through backdoor
routes, configure OSPF sham
links between PE devices. Then
routes on the MPLS VPN
backbone network change into
intra-area OSPF routes and can be
preferred in VPN traffic
forwarding.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure BGP/ To improve VPN network 8.7.11 Configuring Route

MPLS IP VPN reliability, you can deploy a VPN Reflection to Optimize the VPN
reliability networking with full-mesh Backbone Layer
connections on the backbone 8.7.12 Configuring IP FRR for
network, nested PE devices on the VPN Routes
MPLS network, and CE dual-
homing (or multi-homing) on the 8.7.13 Configuring VPN FRR
access layer. In this networking, a 8.7.14 Configuring VPN GR
BGP route reflector (RR) can be
configured to reduce the number
of MP-IBGP connections. This
configuration mitigates loads on
the network devices and facilitates
device maintenance and
management.
The following technologies can
also be used to improve VPN
network reliability:
l IP fast reroute (IP FRR) for
VPN routes: enables traffic to
be quickly switched to another
PE-CE link between when the
primary route is unreachable.
This technology reduces the IP
service interruption time.
l VPN fast reroute (VPN FRR):
enables traffic to be quickly
switched to another PE-PE
link the primary link between
them fails. This technology
implements end-to-end fast
convergence of VPN services.
l VPN graceful restart (VPN
GR): ensures uninterrupted
VPN traffic forwarding during
an active/standby switchover
on a PE, P, or CE device. This
technology minimizes the
impact of PE or CE failures on
VPN services. The AR3260
can function as both the GR
restarter and GR helper, and
other devices can only
function as the GR helper.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure VPN When VPN services need to be 8.7.15 Configuring Tunnel

tunnel policies transmitted over a specified traffic Policies
engineering (TE) tunnel or when
load balancing needs to be
performed among multiple
tunnels to fully use network
resources, configure VPN tunnel
policies.
Connect VPNs to If users in a VPN need to connect 8.7.16 Connecting a VPN to the
the Internet to the Internet, configure Internet
interconnection between the VPN
and the Internet.
8.5 Licensing Requirements and Limitations for BGP/

MPLS IP VPN
None
BGP/MPLS IP VPN is a basic feature of the device and is not under license control.
Feature Limitations
When configuring BGP/MPLS IP VPN on the router, pay attention to the following points:
The AR100&AR120&AR150&AR160&AR200 series do not supports BGP/MPLS IP VPN,

only supports MCE.
8.6 Default Settings for BGP/MPLS IP VPN

This section describes the default settings for BGP/MPLS IP VPN.
Table 8-3 lists the default settings for BGP/MPLS IP VPN.
Table 8-3 Default settings for BGP/MPLS IP VPN
BGP/MPLS IP VPN feature Disabled
Alarm function for BGP/MPLS IP VPN events Disabled

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Number of local AS number repetitions 0

allowed (applicable to Hub and Spoke
networking)
Label allocation mode on PE devices Label per route
Label allocation mode on ASBRs (inter-AS Label per route

VPN)
8.7 Configuring BGP/MPLS IP VPN

This section describes the procedures for configuring BGP/MPLS IP VPN functions.
8.7.1 Configuring Basic BGP/MPLS IP VPN Functions

Basic BGP/MPLS VPN applies to the scenario in which there is only one carrier, the MPLS
backbone network belong to the same AS, and PEs, Ps, and CEs are not multi-role hosts.
After basic BGP/MPLS VPN is configured, different sites in a VPN can communicate with
each other.
8.7.1.1 Configuration Tasks
Table 8-4 Basic BGP/MPLS IP VPN configuration tasks

Configurati Sub-task Configuration
on Task
Configure the Confirm requirements 1. Determine number of devices and interfaces

MPLS VPN of VPN users. based on the network scale, including:
backbone l Number of users
network.
l Number of VPNs for each user
l Number of VPN instances for each VPN
2. Routing protocol used on the backbone
network
NOTE
When RIP-1 runs on the backbone network, you
need to enable LDP to search for routes to establish
LSPs based on the longest match rule. For details,
see Configuring LDP Extensions for Inter-Area
LSPs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configurati Sub-task Configuration

on Task
Configure routing Configure an Interior Gateway Protocol (IGP) on

between backbone the PE and P devices of the MPLS backbone
devices. network to achieve IP connectivity on the
backbone network.
For detailed configuration, see the Huawei
AR100&AR120&AR150&AR160&AR200&AR12
00&AR2200&AR3200&AR3600 Series
Enterprise Routers Configuration Guide - IP
Routing.
Enable MPLS on Enable MPLS and configure a Label Distribution

backbone devices. Protocol (LDP) to set up public network tunnels.
The LDP can be MPLS LDP or Resource
Reservation Protocol-Traffic Engineering (RSVP-
TE).
l For detailed configuration, see the MPLS LDP
Configuration in the Huawei
AR100&AR120&AR150&AR160&AR200&AR
1200&AR2200&AR3200&AR3600 Series
Enterprise Routers Configuration Guide -
MPLS.
l For detailed configuration, see the RSVP-TE
AR100&AR120&AR150&AR160&AR200&AR
1200&AR2200&AR3200&AR3600 Series
Enterprise Routers Configuration Guide -
MPLS.
You also need to configure VPN tunnel policies
when VPN services need to be transmitted over
TE tunnels or when multiple tunnels need to
perform load balancing to fully use network
resources. For detailed configuration, see 8.7.15
Configuring Tunnel Policies.
Configure MP-IBGP See 8.7.1.2 Establishing MP-IBGP Peer

between PE devices. Relationships Between PE Devices.
Connect Configure VPN See 8.7.1.3 Configuring a VPN Instance on a

MPLS VPN instances on PE PE Device.
users. devices.
Bind VPN instances See 8.7.1.4 Binding a VPN Instance to an

to interfaces. Interface.
Configure route See 8.7.1.5 Configuring Route Exchange

exchange between PE Between PE and CE Devices.
and CE devices.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.1.2 Establishing MP-IBGP Peer Relationships Between PE Devices
Context
Perform the following steps on the PE devices.
Procedure
Step 2 Run bgp { as-number-plain | as-number-dot }
Step 3 Run peer ipv4-address as-number as-number
The peer PE is configured as a BGP peer.
Step 4 Run peer ipv4-address connect-interface loopback interface-number
An interface is used to set up a Transmission Control Protocol (TCP) connection with the
BGP peer.
NOTE
A PE must use a loopback interface address with a 32-bit mask to set up an MP-IBGP peer relationship
with the peer PE so that VPN routes can be iterated to tunnels. The route to the local loopback interface
is advertised to the peer PE using an IGP on the MPLS backbone network.
Step 5 Run ipv4-family vpnv4 [ unicast ]

The BGP-VPNv4 address family view is displayed.
Step 6 Run peer ipv4-address enable
The ability to exchange VPN IPv4 routes with the BGP peer is enabled.
----End
Related Tasks
When a large number of PE devices on the backbone network need to establish MP-IBGP
peer relationships to exchange VPN routes, configure a route reflector (RR) to reduce the
number of MP-IBGP connections between PE devices. The PE devices only need to establish
MP-IBGP peer relationships with the RR. For detailed configuration, see 8.7.11 Configuring
Route Reflection to Optimize the VPN Backbone Layer.
8.7.1.3 Configuring a VPN Instance on a PE Device
Context
In BGP/MPLS IP VPN application, each VPN has an instance to maintain forwarding
information of the local VPN. Such an instance is called a VPN instance or VPN routing and
forwarding table (VRF).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN instances isolate VPN routes from routes on the public network and isolate the routes of
different VPN instances. VPN instances must be configured in all types of BGP/MPLS IP
VPN networking.
Perform the following steps on each PE device.
Procedure
Step 2 Run ip vpn-instance vpn-instance-name
A VPN instance is created, and its view is displayed.
NOTE
A VPN instance name is case sensitive. For example, "vpn1" and "VPN1" are different VPN instances.
Step 3 (Optional) Run description description-information

The description is configured for the VPN instance.
Step 4 (Optional) Run service-id service-id
A service ID is created for the VPN instance.
A service ID is unique on a device. It distinguishes a VPN service from other VPN services
on the network.
Step 5 Run ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN instance IPv4 address
family view is displayed.
VPN instances support both the IPv4 and IPv6 address families. Configurations in a VPN
instance can be performed only after an address family is enabled for the VPN instance based
on the advertised route and forwarding data type.
Step 6 Run route-distinguisher route-distinguisher
An RD is configured for the VPN instance IPv4 address family.
A VPN instance IPv4 address family takes effect only after being configured with an RD. The
RDs of different VPN instances on a PE must be different.
NOTE
l An RD can be modified or deleted only after the VPN instance is deleted or the VPN instance IPv4
address family is disabled.
l If you configure an RD for the VPN instance IPv4 address family in the created VPN instance view,
the VPN instance IPv4 address family is enabled and the VPN instance IPv4 address family is
displayed.
Step 7 Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]

A VPN target is configured for the VPN instance IPv4 address family.
A VPN target is a BGP extended community attribute. It is used to control the receiving and
advertisement of VPN routing information. A maximum of eight VPN targets can be
configured using a vpn-target command.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 8 (Optional) Restrict the number of routes in a VRF.

The configuration restricts the number of routes or route prefixes imported from the attached
CE devices and peer PE devices into a VPN instance on a PE device. It is recommended that
you use only one of the following commands.
By default, the number of routes in a VRF is not limited as long as the total number of routes
does not exceed the maximum number of unicast routes supported by the PE device.
l To set the maximum number of routes in the VPN instance IPv4 address family, run
routing-table limit number { alert-percent | simply-alert }.
NOTE
The routing-table limit command enables the system to display a message when the number of
routes added to the routing table of VPN instance IPv4 address family exceeds the limit. If you run
the routing-table limit command to increase the maximum number of routes in the VPN instance
IPv4 address family or run the undo routing-table limit command cancel the limit, the system
adds newly received routes of various protocols to the private network IP routing table.
l To set the maximum number of route prefixes in the VPN instance IPv4 address family,
run prefix limit number { alert-percent [ route-unchanged ] | simply-alert }.
NOTE
If the prefix limit command is run, the system gives a prompt when the number of route prefixes
added to the routing table of the VPN instance IPv4 address family exceeds the limit. After the
prefix limit command is run to increase the allowed maximum number of route prefixes in a VPN
instance IPv4 address family or the undo prefix limit command is run to cancel the limit, the
system adds newly received route prefixes of various protocols to the private network IP routing
table.
After the number of route prefixes exceeds the maximum limit, direct and static routes can still be
added to the IPv4 address family routing table of VPN instances.
Step 9 (Optional) Run limit-log-interval interval

The interval for logging the event that the number of routes exceeds the threshold is set for the
VPN instance IPv4 address family.
If the routes or prefixes in the IPv4 address family of a VPN instance reach the maximum, the
system will generate logs at intervals (defaulting to 5 seconds). To prevent logs from being
displayed frequently, run this step to prolong the interval of log generation.
Step 10 (Optional) Configure a routing policy for the VPN instance.
In addition to using VPN targets to control VPN route advertisement and reception, you can
configure a routing policy for the VPN instance to better control VPN routes.
l An import routing policy filters routes before they are imported into the VPN instance
IPv4 address family.
l An export routing policy filters routes before they are advertised to other PE devices.
NOTE
Before applying a routing policy to a VPN instance, create the routing policy. For details about how to
configure a routing policy, see Routing Policy Configuration in the Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series Enterprise
Routers Configuration Guide - IP Routing.
Run the following command as required:

l To configure an import routing policy for the VPN instance IPv4 address family, run
import route-policy policy-name.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l To configure an export routing policy for the VPN instance IPv4 address family, run
export route-policy policy-name.
Step 11 (Optional) Run one of the following commands to configure the label allocation mode in the
l Run apply-label per-instance
MPLS label allocation based on the VPN instance IPv4 address family (known as label
per instance) is configured. One label is assigned to all the routes of the VPN instance
IPv4 address family.
When a large number of VPN routes on the PE exhausts MPLS label resources, the label
per instance mode saves label resources on the PE and lowers the requirement for the PE
capacity.
l Run apply-label per-route
MPLS label allocation based on each route (known as label per route) is configured. The
VPN instance address family assigns a unique label to each route to be sent to the peer
PE.
When only a small number of VPN routes exists on the PE and MPLS label resources are
sufficient, the label per route mode improves system security. In this way, downstream
devices can load balance VPN traffic based on the inner labels of packets.
By default, the VPN instance IPv4 address family assigns the same label to all routes to be
sent to the peer PE.
----End
8.7.1.4 Binding a VPN Instance to an Interface
Prerequisites
A VPN instance has been created and the IPv4 address family has been enabled for the VPN
instance.
Context
l After configuring a VPN instance on a PE device, bind the VPN instance to the interface
that belongs to the VPN. Otherwise, the interface functions as a public network interface
and cannot forward VPN data.
l An interface becomes a private network interface after a VPN instance is bound to it.
You must configure an IP address for the interface so that the PE device can exchange
routing information with its attached CE device.
l After a VPN instance is bound to an interface, configuration of the Layer 3 features
(IPv4 and IPv6 features) including IP addresses and routing protocols is deleted from the
interface.
l When you disable an address family (IPv4 or IPv6 address family) in a VPN instance,
configuration of the address family is deleted from the interface. No interface is bound to
a VPN instance if no address family configuration exists in the VPN instance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Run ip binding vpn-instance vpn-instance-name
A VPN instance is bound to the interface.
By default, an interface is a public network interface and is not associated with any VPN
instance.
An IP address is configured for the interface.
----End
8.7.1.5 Configuring Route Exchange Between PE and CE Devices
Context
In BGP/MPLS IP VPN, a routing protocol or static routes must be configured between a PE
and a CE to allow them to communicate and allow the CE to obtain routes to other CEs. The
routing protocol can be EBGP (External/Exterior BGP), IBGP (Internal/Interior BGP), RIP
(Routing Information Protocol), OSPF (Open Shortest Path First), or IS-IS (Intermediate
System to Intermediate System). Choose one of the following configurations as needed:
l Configure EBGP between a PE and a CE
l Configure IBGP between a PE and a CE
l Configure static route between a PE and a CE
l Configure RIP between a PE and a CE
l Configure OSPF between a PE and a CE
l Configure IS-IS between a PE and a CE
The routing protocol configurations on the CE and PE are different:
l The CE is located at the client side. It does not know the existence of a VPN. Therefore,
you do not need to configure VPN parameters when configuring a routing protocol on
the CE device.
l The PE device is located at the edge of the carrier's network. It connects to a CE device
and exchanges VPN routing information with other PE devices. If the CE devices that
access a PE device belong to different VPNs, the PE must maintain different VRF tables.
When configuring a routing protocol on the PE device, specify the name of the VPN
instance to which the routing protocol applies and configure the routing protocol and
MP-BGP to import routes from each other.
Configure EBGP Between a PE and a CE

Perform the following configuration on the PE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 8-5 PE configuration

Action Command Description
Enter the system-view -

system
view.
Enter the bgp { as-number-plain | as-number- -

BGP view. dot }
Enter the ipv4-family vpn-instance vpn-instance- -

BGP-VPN name
instance
IPv4
address
family
view.
(Optional) as-number as-number A VPN instance uses the AS

Configure a number of BGP by default.
unique AS To smoothly re-assign a device to
number for another AS or transmit different
the VPN services in different instances,
instance run this command to configure a
IPv4 different AS number for each
address VPN instance IPv4 address
family. family.
NOTE
The AS number configured in the
BGP-VPN instance IPv4 address
family view must be different from
the AS number configured in the
BGP view.
Configure a peer ipv4-address as-number as- -

CE device number
as a VPN
peer.
Set the peer { ipv4-address | group-name } Generally, EBGP peers are

maximum ebgp-max-hop [ hop-count ] connected by a directly physical
number of link. If no directly physical link
hops of an is available, this command must
EBGP be used to allow EBGP peers to
connection. establish a multi-hop TCP
connection.
The default value of hop-count is
255. If the maximum number of
hops is set to 1, the PE cannot
establish an EBGP connection
with a peer if they are not
directly connected.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
(Optional) Use either of the following commands: The PE device needs to import
Import l import-route direct [ med med | the routes destined for the local
direct CE device into its VPN routing
route-policy route-policy-name ] *
routes table so that it can advertise the
destined for l network ipv4-address [ mask | mask- routes to the remote PE device.
the local length ] [ route-policy route-policy-
NOTE
CE device name ] The PE device can automatically
into the learn the direct routes destined for
routing the local CE device. The learned
routes take precedence over the
table of the
direct routes advertised from the
IPv4 VPN local CE device using EBGP. If this
instance. step is not performed, the PE does
not use MP-BGP to advertise the
direct routes destined for the local
CE device to the remote PE device.
(Optional) peer { group-name | ipv4-address } soo Several CE devices at a VPN site

Configure site-of-origin may establish BGP connections
the Site-of- with different PE devices. The
Origin VPN routes advertised from the
(SoO) CE devices to the PE devices
attribute for may be re-advertised to the same
a CE VPN site after the routes traverse
device. the backbone network. This may
cause route loops at the VPN
site.
If the SoO attribute is configured
for a specified CE device, the PE
device adds the attribute to a
route sent from the CE device
and advertises the route to the
remote PE. The remote PE
device checks the SoO attribute
of the route before sending it to
its attached CE device. If the
SoO attribute is the same as the
local SoO attribute on the remote
PE device, the remote PE device
does not send the route to its
attached CE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
(Optional) peer ipv4-address substitute-as BGP uses AS numbers to detect

Enable routing loops. Sites located at
BGP AS different geographical locations
number must be assigned different AS
substitution numbers to ensure correct
. transmission of routing
information. If CE devices
scattered at different
geographical locations use the
same AS number, configure BGP
AS number substitution on the
PE devices.
NOTICE
Enabling BGP AS number
substitution may cause route loops
in a CE multi-homing network.
(Optional) routing-table rib-only [ route-policy If the BGP routing table has

Prohibit route-policy-name ] large numbers of VPN routes,
BGP these routes will consume large
private numbers of memory resources
routes from after being delivered to the IP
being VPN routing table. If these
delivered to routes are not used in traffic
the private forwarding, you can run the
IP routing routing-table rib-only
table. command to prevent these routes
from being added to the IP VPN
routing table. If some of these
routes are not used in traffic
forwarding, you can run the
routing-table rib-only route-
policy command to prevent this
part of routes from being added
to the IP VPN routing table.
NOTICE
If traffic is interrupted after the
routing-table rib-only command is
run, you can configure a static route
or default route to guide traffic
forwarding.
Perform the following configurations on the CE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 8-6 CE configuration


system
view.

BGP view. dot }
Configure peer ipv4-address as-number as- -

the PE number
device as a
VPN peer.
Set the peer { ipv4-address | group-name } Generally, EBGP peers are

maximum ebgp-max-hop [ hop-count ] connected by a directly physical
number of link. If no directly physical link
hops of an is available, this command must
EBGP be used to allow EBGP peers to
connection. establish a multi-hop TCP
connection.
The default value of hop-count is
255. If the maximum number of
hops is set to 1, the PE cannot
establish an EBGP connection
with a peer if they are not
directly connected.
Import import-route protocol [ process-id ] The CE device advertises the

routes of [ med med | route-policy route-policy- routes of its own VPN network
the local name ] * segment to the connected PE
sites. device. The PE device forwards
the routes to the remote CE
device. The type of routes
imported at this step may vary
according to the networking
mode.
Configure IBGP Between a PE and a CE

Perform the following configuration on the PE device.


system
view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

BGP view. dot }

BGP-VPN name
instance
IPv4
address
family
view.
(Optional) as-number as-number A VPN instance uses the AS

Configure a number of BGP by default.
unique AS To smoothly re-assign a device to
number for another AS or transmit different
the VPN services in different instances,
instance run this command to configure a
IPv4 different AS number for each
address VPN instance IPv4 address
family. family.
NOTE
The AS number configured in the
BGP-VPN instance IPv4 address
family view must be different from
the AS number configured in the
BGP view.
Configure a peer ipv4-address as-number as- -

CE device number
as a VPN
peer.
(Optional) Use either of the following commands: The PE device needs to import
Import l import-route direct [ med med | the routes destined for the local
direct CE device into its VPN routing
routes table so that it can advertise the
destined for l network ipv4-address [ mask | mask- routes to the remote PE device.
the local length ] [ route-policy route-policy-
NOTE
CE device name ] The PE device can automatically
into the learn the direct routes destined for
routing the local CE device. The learned
routes take precedence over the
table of the
direct routes advertised from the
IPv4 VPN local CE device using IBGP. If this
instance. step is not performed, the PE does
not use MP-BGP to advertise the
direct routes destined for the local
CE device to the remote PE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
(Optional) routing-table rib-only [ route-policy If the BGP routing table has

Prohibit route-policy-name ] large numbers of VPN routes,
BGP these routes will consume large
private numbers of memory resources
routes from after being delivered to the IP
being VPN routing table. If these
delivered to routes are not used in traffic
the private forwarding, you can run the
IP routing routing-table rib-only
table. command to prevent these routes
from being added to the IP VPN
routing table. If some of these
routes are not used in traffic
forwarding, you can run the
routing-table rib-only route-
policy command to prevent this
part of routes from being added
to the IP VPN routing table.
NOTICE
If traffic is interrupted after the
routing-table rib-only command is
run, you can configure a static route
or default route to guide traffic
forwarding.
Perform the following configurations on the CE device.
Table 8-8 CE configuration


system
view.

BGP view. dot }

the PE number
device as a
VPN peer.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Import import-route protocol [ process-id ] The CE device advertises the

routes of [ med med | route-policy route-policy- routes of its own VPN network
the local name ] * segment to the connected PE
sites. device. The PE device forwards
the routes to the remote CE
device. The type of routes
imported at this step may vary
according to the networking
mode.
When many CE devices connect to a PE device, the PE device can function as an RR and the
CE devices function as clients. This reduces the number of IBGP connections between CE
devices and facilitates route maintenance and management.
Configure Static Routes Between a PE and a CE

Perform the following configuration on the PE device. The procedure for configuring static
routes on the CE device is not provided here. For details about how to configure a static route,
see Static Route Configuration in the Huawei


system
view.
Configure a ip route-static vpn-instance vpn- -

static route source-name destination-address { mask
for a VPN | mask-length } interface-type interface-
instance. number [ nexthop-address ] [ preference
preference | tag tag ] *

BGP view. dot }

BGP-VPN name
instance
IPv4
address
family
view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Import the import-route static [ med med | route- After this command is run in the
configured policy route-policy-name ] * BGP-VPN instance IPv4 address
static route family view, the PE will import
to the the VPN routes learned from the
routing attached CE into the BGP
table of the routing table and advertise
BGP-VPN VPNv4 routes to the remote PE.
instance
IPv4
address
family.
Configure RIP between a PE and a CE

Perform the following configuration on the PE device. Configure RIPv1 or RIPv2 on the CE,
and the CE configuration details are not provided here. For details on how to configure RIP,
see RIP Configuration in the Huawei
Deleting a VPN instance or disabling a VPN instance IPv4 address family will delete all the
RIP processes bound to the VPN instance or the VPN instance IPv4 address family on the PE
device.


system
view.
Create a rip process-id vpn-instance vpn- A RIP process can be bound to

RIP instance-name only one VPN instance. If a RIP
process process is not bound to any VPN
running instance before it is started, this
between process becomes a public
the PE and network process and can no
CE devices longer be bound to a VPN
and enter instance.
the RIP
view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Enable RIP network network-address -

on the
network
segment of
the
interface to
which the
VPN
instance is
bound.
Import import-route bgp [ cost { cost | After this command is executed

BGP routes transparent } | route-policy route- in the RIP view, the PE device
to the RIP policy-name ] * can import the VPNv4 routes
routing learned from the remote PE
table. device into the RIP routing table
and advertise them to the
attached CE device.
Return to quit -
system
view.

BGP view. dot }

BGP-VPN name
instance
IPv4
address
family
view.
Import RIP import-route rip process-id [ med med | After this command is run in the
routes into route-policy route-policy-name ] * BGP-VPN instance IPv4 address
the routing family view, the PE will import
table of the the VPN routes learned from the
BGP-VPN attached CE into the BGP
instance routing table and advertise
IPv4 VPNv4 routes to the remote PE.
address
family.
Configure OSPF Between a PE and a CE

Configure OSPF on the CE, and the CE configuration details are not provided here. Perform
the following configuration on the PE device. For details on how to configure OSPF, see
OSPF Configuration in the Huawei

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
OSPF processes bound to the VPN instance or the VPN instance IPv4 address family on the
PE device.


system
view.
Create an ospf process-id [ router-id router-id ] An OSPF process can be bound

OSPF vpn-instance vpn-instance-name to only one VPN instance. If an
process OSPF process is not bound to
running any VPN instance before it is
between started, this process becomes a
the PE and public network process and can
CE device no longer be bound to a VPN
and enter instance.
the OSPF A router ID needs to be specified
view. when an OSPF process is started
after it is bound to a VPN
instance. The router ID must be
different from the public network
router ID configured in the
system view. If the router ID is
not specified, OSPF selects the
IP address of one of the
interfaces bound to the VPN
instance as the router ID based
on a certain rule.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
(Optional) domain-id domain-id [ secondary ] The domain ID of an OSPF

Configure a process is contained in the routes
domain ID generated by the process. When
for the OSPF routes are imported into
OSPF BGP, the domain ID is added to
process. the BGP VPN routes and
forwarded as the BGP extended
community attribute.
There are no restrictions on the
domain IDs of the OSPF
processes of different VPNs on a
PE device. The OSPF processes
of the same VPN must be
configured with the same domain
ID to ensure proper route
advertisement.
The default domain ID is 0.
(Optional) route-tag tag The VPN route tag prevents

Configure a loops of Type-5 LSAs in CE
VPN route dual-homing networking.
tag. By default, the VPN route tag is
calculated using the BGP AS
number. If BGP is not
configured, the VPN route tag is
0.
Import import-route bgp [ permit-ibgp ] [ cost After this command is executed

BGP routes cost | route-policy route-policy-name | in the OSPF view, the PE can
to the tag tag | type type ] * import the VPNv4 routes learned
OSPF from the remote PE into the
routing OSPF routing table and advertise
table. them to the attached CE.
Enter the area area-id -

OSPF area
view.
Enable network ip-address wildcard-mask -

OSPF on
the network
segment of
the
interface to
which the
VPN
instance is
bound.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Return to quit -
the OSPF
view.
Return to quit -
system
view.

BGP view. dot }

BGP-VPN name
instance
IPv4
address
family
view.
Import import-route ospf process-id [ med After this command is run in the
OSPF med | route-policy route-policy-name ] * BGP-VPN instance IPv4 address
routes into family view, the PE will import
the routing the VPN routes learned from the
table of the attached CE into the BGP
BGP-VPN routing table and advertise
instance VPNv4 routes to the remote PE.
IPv4
address
family.
Configure IS-IS Between a PE and a CE

Configure IS-IS on the CE, and the CE configuration details are not provided here. Perform
the following configuration on the PE device. For details on how to configure IS-IS, see "IPv4
IS-IS Configuration" in the Huawei
IS-IS processes bound to the VPN instance or the VPN instance IPv4 address family on the
PE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


system
view.
Create an isis process-id vpn-instance vpn- An IS-IS process can be bound

IS-IS instance-name to only one VPN instance. If an
process IS-IS process is not bound to any
running VPN instance before it is started,
between this process becomes a public
the PE and network process and can no
CE devices longer be bound to a VPN
and enter instance.
the IS-IS
view.
Set a network-entity net A NET specifies the current IS-

network IS area address and the system
entity title ID of the router. An IS-IS
(NET) for process on one router can be
the IS-IS configured with a maximum of
process. three NETs.
(Optional) is-level { level-1 | level-1-2 | level-2 } By default, the IS-IS level of the
Set the router is Level-1-2.
level of the
PE device.
Import l import-route bgp [ cost-type If the IS-IS level is not specified

BGP routes { external | internal } | cost cost | in the command, BGP routes
to the IS-IS tag tag | route-policy route-policy- will be imported into the Level-2
routing name | [ level-1 | level-2 | level-1-2 ] ] IS-IS routing table.
table. *
After this command is executed
l import-route bgp inherit-cost in the ISIS view, the PE can
[ { level-1 | level-2 | level-1-2 } | tag import the VPNv4 routes learned
tag | route-policy route-policy- from the remote PE into the IS-
name ] * IS routing table and advertise
them to the attached CE.
Return to quit -
system
view.
Enter the interface interface-type interface- -

view of the number
interface to
which the
VPN
instance is
bound.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Enable IS- isis enable [ process-id ] -

IS on the
interface.
Return to quit -
system
view.
Enter the bgp { as-number-plain | as-number-dot } -

BGP view.

BGP-VPN name
instance
IPv4
address
family
view.
Import IS- import-route isis process-id [ med med | After this command is run in the
IS routes route-policy route-policy-name ] * BGP-VPN instance IPv4 address
into the family view, the PE will import
routing the VPN routes learned from the
table of the attached CE into the BGP
BGP-VPN routing table and advertise
instance VPNv4 routes to the remote PE.
IPv4
address
family.
8.7.1.6 Verifying the Configuration of Basic BGP/MPLS IP VPN Functions
Prerequisites
All configurations for a basic BGP/MPLS IP VPN are complete.
Procedure
l Run the following commands on the PE to check information about the created VPN
instance IPv4 address family, including the RD and other attributes.
– Run the display ip vpn-instance vpn-instance-name command to check brief
information about a specified VPN instance.
– Run the display ip vpn-instance verbose vpn-instance-name command to check
detailed information about a specified VPN instance.
– Run the display ip vpn-instance import-vt ivt-value command to check
information about the VPN instances with the specified import VPN target.
– Run the display ip vpn-instance [ vpn-instance-name ] interface command to view
information about the interface bound to a specified VPN instance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the following commands on the PE and CE to check information about the IPv4
VPN routes to the local and remote sites.
– Run the display ip routing-table vpn-instance vpn-instance-name command on
the PE to check the routing information of a specified VPN instance IPv4 address
family.
– Run the display ip routing-table command on the CE to check routing
information.
----End
8.7.2 Configuring Hub and Spoke

In Hub and Spoke networking, a central site is deployed and all the other sites communicate
through the central site. The central site controls communication between sites.
Before configuring Hub and Spoke, complete the following tasks:
l Configuring IGP on PE devices and P devices in the MPLS backbone network
NOTE
When RIP-1 runs on the backbone network, you need to enable LDP to search for routes to
establish LSPs based on the longest match rule. For details, see Configuring LDP Extensions for
Inter-Area LSPs.
l Configuring basic MPLS capabilities and MPLS LDP (or RSVP-TE) on PE devices and
P devices in the MPLS backbone network
l Configuring the IP addresses, through which the CE devices access the PE devices, on
the CE devices
NOTE
You also need to configure VPN tunnel policies when VPN services need to be transmitted over TE
tunnels or when multiple tunnels need to perform load balancing to fully use network resources. For
detailed configuration, see 8.7.15.1 Configuring and Applying a Tunnel Policy.
All the following tasks are mandatory. Perform these tasks in this sequence to complete the
Hub and Spoke configuration.
8.7.2.1 Configuring MP-IBGP Between Hub-PE and Spoke-PE
Context
The Hub-PE must set up the MP-IBGP peer with all the Spoke-PE devices. Spoke-PE devices
do not need to set up the MP-IBGP peer between each other.
Perform the following steps on the Hub-PE and Spoke-PE devices.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

The peer PE is configured as a BGP peer.
An interface is used to set up a Transmission Control Protocol (TCP) connection with the
BGP peer.
NOTE
A PE must use a loopback interface address with a 32-bit mask to set up an MP-IBGP peer relationship
with the peer PE so that VPN routes can be iterated to tunnels. The route to the local loopback interface
is advertised to the peer PE using an IGP on the MPLS backbone network.

The ability to exchange VPN IPv4 routes with the BGP peer is enabled.
----End
8.7.2.2 Configuring VPN Instances on PE Devices
Context
Configure VPN instances on each Spoke-PE device and the Hub-PE device. This section
provides only the mandatory configuration for a VPN instance. For the optional configuration
of a VPN instance, see 8.7.1.3 Configuring a VPN Instance on a PE Device.
Procedure
l Configure VPN instances on the Hub-PE device.
Configure the following two VPN instances for the Hub-PE device:
– VPN-in: accepts and maintains all the VPNv4 routes advertised by all the Spoke-PE
devices.
– VPN-out: maintains the routes of the Hub site and all the Spoke sites and advertises
those routes to all the Spoke-PE devices.
a. Run system-view
b. Run ip vpn-instance VPN-in
The VPN-in instance is created and the VPN-in instance view is displayed.
c. Run ipv4-family
The IPv4 address family is enabled for the VPN-in instance, and the VPN-in
instance IPv4 address family view is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
d. Run route-distinguisher route-distinguisher

The RD of the VPN-in instance IPv4 address family is configured.
e. Run vpn-target vpn-target1 &<1-8> import-extcommunity
The VPN target extended community for the VPN-in instance IPv4 address family
is created to import the VPNv4 routes advertised by all the Spoke-PE devices.
vpn-target1 lists the Export VPN targets advertised by all the Spoke-PE devices.
f. Run quit
The VPN instance view is displayed.
g. Run quit
h. Run ip vpn-instance VPN-out
The VPN-out instance is created and the VPN-out instance view is displayed.
i. Run ipv4-family
The IPv4 address family is enabled for the VPN-out instance, and the VPN-out
instance IPv4 address family view is displayed.
j. Run route-distinguisher route-distinguisher
The RD of the VPN-out instance IPv4 address family is configured.
k. Run vpn-target vpn-target2 &<1-8> export-extcommunity
The VPN target extended community for the VPN-out instance IPv4 address family
is created to advertise the routes of all the Hubs and Spokes.
vpn-target2 lists the Import VPN targets advertised by all the Spoke-PE devices.
l Configure a Spoke-PE device.
Every Spoke-PE device is configured with a VPN instance.
a. Run system-view
b. Run ip vpn-instance vpn-instance-name
The VPN instance view of VPN-in is displayed.
c. Run ipv4-family
The VPN instance IPv4 address family view is displayed.
d. Run route-distinguisher route-distinguisher
The RD of the VPN-in instance is configured.
e. Run vpn-target vpn-target2 &<1-8> import-extcommunity
The VPN target extended community is configured for the VPN instance IPv4
address family to receive the VPNv4 routes advertised by the Hub-PE device.
vpn-target2 must be in the export VPN target list configured on the Hub-PE device.
f. Run vpn-target vpn-target1 &<1-8> export-extcommunity
The VPN target extended community is configured for the VPN instance IPv4
address family to advertise the routes of Spoke sites.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
vpn-target1 must be in the import VPN target list configured on the Hub-PE device.
----End
8.7.2.3 Binding a VPN Instance to an Interface
Prerequisites
A VPN instance has been created and the IPv4 address family has been enabled for the VPN
instance.
Context
The configuration on the Hub-PE involves two interfaces or sub-interfaces: one is bound with
the VPN-in and receives the routes advertised by the Spoke-PE; the other is bound with the
VPN-out and advertises the routes of the Hub and all the Spokes.
l After configuring a VPN instance on a PE device, bind the VPN instance to the interface
that belongs to the VPN. Otherwise, the interface functions as a public network interface
l An interface becomes a private network interface after a VPN instance is bound to it.
You must configure an IP address for the interface so that the PE device can exchange
routing information with its attached CE device.
l After a VPN instance is bound to an interface, configuration of the Layer 3 features
(IPv4 and IPv6 features) including IP addresses and routing protocols is deleted from the
interface.
l When you disable an address family (IPv4 or IPv6 address family) in a VPN instance,
configuration of the address family is deleted from the interface. No interface is bound to
a VPN instance if no address family configuration exists in the VPN instance.
Perform the following steps on the Hub-PE and all the Spoke-PE devices.
Procedure
A VPN instance is bound to the interface.
By default, an interface is a public network interface and is not associated with any VPN
instance.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.2.4 Configuring Route Exchange Between PE device and CE Devices
Context
The Hub-PE and Hub-CE devices can use IGP or EBGP to exchange routing information.
When they use EBGP, you must configure the Hub-PE device to allow repeated local AS
number.
As shown in Figure 8-37, the routing information advertised by a Spoke-CE is forwarded to
the Hub-CE and Hub-PE device before being transmitted to other Spoke-PE devices. If EBGP
runs between the Hub-PE device and the Hub-CE, the Hub-PE device performs the AS-Loop
detection on the route. If the Hub-PE device detects its own AS number in the route, it
discards the route. In this case, to implement the Hub and Spoke networking, the Hub-PE
device must be configured to permit the existence of repeated local AS numbers.
Figure 8-37 EBGP running between the Hub-CE and Hub-PE devices
AS65401 Spoke-PE1
Spoke-CE1 EBGP
IBGP Hub-CE
VPN_in
VPN backbone
AS100
Spoke-CE2 IBGP EBGP
AS65403
Hub-PE VPN_out
Spoke-PE2
AS65402
Procedure
l Configure EBGP between the Hub-PE and Hub-CE devices.
For detailed configuration procedures, see Configuring a Routing Protocol Between
PE device and CE.
The Spoke-PE and Spoke-CE devices can use EBGP, IGP, or static routes.
To set up an EBGP peer relationship between the Hub-PE and Hub-CE devices and
between a Spoke-PE device and a Spoke-CE device, perform the following steps on the
Hub-PE device:
a. Run system-view
b. Run bgp { as-number-plain | as-number-dot }
c. Run ipv4-family vpn-instance vpn-instance-name

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The BGP-VPN instance IPv4 address family view is displayed.

d. Run peer ip-address allow-as-loop [ number ]
The Hub-PE is configured to allow the routing loop. Here the value of number is set
as 1, which means the route with the AS repeated once can be sent.
l Configure an IGP between the Hub-PE and Hub-CE devices.

PE and CE.
In this way, instead of BGP, IGP or static routes are adopted between the Spoke-PE and
the Spoke-CE. If BGP is used, the source BGP route's AS number will get lost when the
route is transmitted through the IGP running between the Hub-PE and Hub-CE. The
Spoke-PE will receive both the source BGP route sent by the Spoke-CE and the source
BGP route with no AS number forwarded by the Hub-PE. The source BGP route sent by
the Spoke-CE has an AS number and is therefore not preferred by the Spoke-PE. After
the route is withdrawn, the Spoke-PE prefers the source BGP route received from the
Spoke-CE again and advertises this route again. As this process repeats, route flapping
occurs.
l Configure static routes between the Hub-PE and the Hub-CE devices.

PE device and CE.
EBGP, IGP, or static routes can be used between the Spoke-PE and the Spoke-CE
devices.
If the Hub-CE device uses the default route to access the Hub-PE device, perform the
following steps on the Hub-PE device to advertise the default route to all the Spoke-PE
devices:
a. Run system-view

b. Run ip route-static vpn-instance vpn-source-name 0.0.0.0 0.0.0.0 nexthop-address
[ preference preference | tag tag ]* [ description text ]
Here, vpn-instance-name refers to the VPN-out. nexthop-address is the IP address

of the Hub-CE interface that is connected with the PE device interface bound with
the VPN-out instance.
c. Run bgp { as-number-plain | as-number-dot }

d. Run ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed. vpn-instance-name

refers to the VPN-out instance.
e. Run network 0.0.0.0 0
The default route is advertised to all the Spoke-PE devices through MP-BGP.
----End
8.7.2.5 Verifying the Hub and Spoke Configuration

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Prerequisites
The configurations of the Hub and Spoke function are complete.
Procedure
l Run the display ip routing-table vpn-instance vpn-instance-name command to check
routing information about the VPN-in and VPN-out on the Hub-PE.
If the VPN-in routing table has routes to all the Spoke stations, and the VPN-out routing
table has routes to the Hub and all the Spoke stations, it means the configuration is
successful.
l Run the display ip routing-table command to check routing information on the Hub-CE
and all the Spoke-CE devices.
The Hub-CE and all the Spoke-CE devices have routes to the Hub and all the Spoke
sites.
----End
8.7.3 Configuring Inter-AS VPN Option A

If the MPLS VPN backbone network spans multiple ASs, inter-AS VPN is required. Inter-AS
VPN-Option A can be used when each PE device has a few VPNs and VPN routes.
Procedure
To implement inter-AS VPN Option A, complete basic BGP/MPLS IP VPN configuration in
each AS and configure the ASBR-PE devices as the CE device of each other. You need to
configure VPN instances for a PE device and an ASBR-PE device respectively. The PE
device connects to CE devices, and the ASBR-PE device connects to the remote ASBR-PE
device. For details about basic BGP/MPLS IP VPN configuration, see 8.7.1 Configuring
Basic BGP/MPLS IP VPN Functions.
NOTE
In inter-AS VPN Option A, the VPN targets of VPN instances on the ASBR and PE devices in the same
AS must match for the same VPN. This is not required for the PE devices in different ASs.
Verifying the Configuration

After inter-AS VPN Option A is configured, run the following commands to check previous
configurations.
l Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view
that the status of the BGP VPNv4 peer relationship between the PE and ASBR in the
same AS is "Established".
l Run the display bgp vpnv4 all routing-table command on the PE or ASBR, and you
can view the VPNv4 routes.
l Run the display ip routing-table vpn-instance vpn-instance-name command on the PE
or ASBR, and you can view that the VPN routing table of the PE or ASBR has related
VPN routes.
8.7.4 Configuring Inter-AS VPN Option B

If virtual private network (VPN) routes need to be established over a Multiprotocol Label
Switching (MPLS) backbone network spanning multiple autonomous areas (ASs), inter-AS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN is required. If the provider edge (PE) devices connect to many VPNs but the
autonomous area border routers (ASBRs) do not have enough interfaces to reserve an
interface for each inter-AS VPN, the inter-AS VPN Option B solution can be used on the
network.
Before configuring inter-AS VPN Option B, complete the following tasks:
l Configuring an Interior Gateway Protocol (IGP) for the MPLS backbone network of
each AS to ensure IP connectivity on the backbone network within each AS
l Configuring the basic MPLS functions and MPLS Label Distribution Protocol (LDP) or
Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for the MPLS backbone
network of each AS
l In each AS, configuring VPN instances on the PE devices connected to CE devices and
associating the VPN instances with PE interfaces connected to CE devices
l Configuring route exchange between the PE and CE devices in each AS
For details about the configurations, see 8.7.1 Configuring Basic BGP/MPLS IP VPN
Functions.
8.7.4.4 (Optional) Configuring Routing Policies to Control VPN Route Advertisement
and Acceptance and 8.7.4.5 (Optional) Enabling Next-Hop-based Label Allocation on the
ASBR are optional, and other tasks are mandatory. Perform these tasks in this sequence to
complete inter-AS VPN Option B configuration.
When VPN services need to be transmitted over TE tunnels or when multiple tunnels need to
perform load balancing to fully use network resources, you also need to complete the task of
8.7.15 Configuring Tunnel Policies.
NOTE
In inter-AS VPN Option B, the ASBRs maintain and advertise VPNv4 routes of inter-AS VPNs, and
they can also work as PE devices. When the ASBRs work as PE devices, configure VPN instances on
the ASBRs to enable them to exchange routing information with CE devices. The configuration is the
same as that on common PE devices.
8.7.4.1 Configuring MP-IBGP Between PE and ASBR in the Same AS
Context
Perform the following steps on the PE and ASBR in the same AS.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

The peer ASBR is specified as the IBGP peer.
The loopback interface is specified as the outgoing interface of the BGP session.
NOTE
The 32-bit mask IP addresses of the loopback interfaces must be used to establish the MP-IBGP peer
relationship between PEs. This can ensure that the tunnel can be iterated. The route destined to the
loopback interface is advertised to the remote PE based on IGP on the MPLS backbone network.

The BGP-VPNv4 address family is displayed.
The exchange of VPNv4 routes between the PE and ASBR in the same AS is enabled.
NOTE
When the ASBR sends a VPNv4 route to a PE, the ASBR can automatically change the next hop in the
VPNv4 route to the IP address of itself.
----End
8.7.4.2 Configuring MP-EBGP Between ASBRs in Different ASs
Context
In inter-AS VPN Option B, you need not create VPN instances on ASBRs. The ASBR does
not filter the VPNv4 routes received from the PE in the same AS based on VPN targets.
Instead, it advertises the received VPNv4 routes to the peer ASBR through MP-EBGP.
In the AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600,
an ASBR can only change the next-hop address of a VPNv4 route to the ASBR's address
before advertising the route to a PE.
Perform the following steps on the ASBR.
Procedure
The view of the interface connected with the ASBR interface is displayed.
The interface IP address is configured.
Step 4 Run mpls
The MPLS capability is enabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 5 Run quit

The peer ASBR is specified as the EBGP peer.
Step 8 (Optional) Run peer { ipv4-address | group-name } ebgp-max-hop [ hop-count ]
The maximum number of hops is configured for the EBGP connection.
Generally, one or multiple directly connected physical links exist between EBGP peers. If the
directly connected physical link(s) are not available, run this command to ensure that the TCP
connection can be set up between the EBGP peers through multiple hops.
The exchange of IPv4 VPN routes with the peer ASBR is enabled.
----End
8.7.4.3 Disabling an ASBR from Filtering VPNv4 Routes by VPN Targets
Context
By default, the PE performs VPN target filtering on the received IPv4 VPN routes. The routes
passing the filter are added to the routing table, and the others are discarded. If the PE is not
configured with VPN instance, or the VPN instance is not configured with the VPN target, the
PE discards all the received VPN IPv4 routes.
In Inter-AS VPN Option B, you do not need to configure VPN instances on the ASBRs. An
ASBR must save all the VPNv4 routes and advertises the VPNv4 routes to the remote ASBR.
In this case, the ASBR must accept all the VPNv4 routing information without the VPN target
filtering.
Procedure
Step 4 Run undo policy vpn-target

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The VPN IPv4 routes are not filtered by the VPN target.
----End
8.7.4.4 (Optional) Configuring Routing Policies to Control VPN Route

Advertisement and Acceptance
Context
The ASBRs accept all VPNv4 routes after they are configured not to filter VPNv4 routes by
VPN targets. When there are many VPN routes on the network, the ASBRs are overburdened.
If only some of VPNs or sites need to communicate across ASs, you can configure a routing
policy on the ASBRs to restrict the VPNv4 routes that can be accepted by the ASBRs. This
reduces loads on the ASBRs.
This section describes how to configure the following filtering policies to control VPNv4
route advertisement and acceptance:
l Filtering policy based VPN targets
l Filtering policy based on RDs
Procedure
Step 2 Run either of the following command to configure a route filter.
1. To configure an extended community filter, run ip extcommunity-filter extcomm-filter-
number { permit | deny } { rt { as-number:nn | ipv4-address:nn } } &<1-16>.
2. To configure an RD filter, run ip rd-filter rd-filter-number { deny | permit } route-
distinguisher &<1-10>.
Step 3 Run route-policy route-policy-name permit node node
A routing policy is configured.
Step 4 Run either of the following command to configure an if-match clause in the configured route
filter:
1. If you configured an extended community filter in Step 2, run the if-match
extcommunity-filter { { basic-extcomm-filter-num | advanced-extcomm-filter-num }
&<1-16> | advanced-extcomm-filter-name | basic-extcomm-filter-name } command to
configure an if-match clause based on the extended community filter in the routing
policy.
2. If you configured an RD filter in Step 2, run the if-match rd-filter rd-filter-number
command to configure an if-match clause based on the RD filter in the routing policy.
Step 5 Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 8 Run peer ipv4-address route-policy route-policy-name { export | import }
The routing policy is applied to controlling the VPN IPv4 routing information.
----End
8.7.4.5 (Optional) Enabling Next-Hop-based Label Allocation on the ASBR
Context
In an inter-AS VPN Option B scenario, ASBRs can be enabled to allocate labels to VPN
routes based on next hops. This saves labels on the ASBRs.
Next-hop-based label allocation means to allocate the same label for the routes with the same
forwarding behavior. In other words, VPN routes with the same forwarding path and
outbound label are assigned the same label. Different from the prefix-based label allocation
mode that is used by default, next-hop-based label allocation enrich the label allocation modes
and allows for flexible label allocation. In addition, when an ASBR functions as a PE device,
next-hop-based label allocation can be used together with one label per instance mode to save
labels on the ASBR.
As shown in Figure 8-38, the inter-AS VPN Option B networking is established; two VPN
instances, VPN1 and VPN2, are configured on PE1; the label allocation mode is one label per
VPN instance. CE1 in VPN1 and CE2 in VPN2 are respectively imported with 1 thousand
VPN routes. When the next-hop-based label allocation feature is not enabled for VPN routes
on ASBRs, the 2 thousand routes of PE1 advertised by ASBR1 to ASBR2 use 2 thousand
labels; after the next-hop-based label allocation feature is enabled for VPN routes on ASBR1,
ASBR1 only assigns one label for VPN routes of the same next hop and outgoing label. As a
result, ASBR1 needs to allocate only two labels for 2 thousands routes.
Figure 8-38 Next-hop-based label allocation for VPN routes on ASBR
VPN1
CE1 VPN1
CE3
BGP/MPLS backbone BGP/MPLS backbone
AS: 100 AS: 200
PE3
MP-EBGP
MP-IBGP
MP-IBGP
PE1 ASBR1 ASBR2
PE4
CE4
CE2
VPN2
VPN2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After next-hop-based label allocation is enabled or disabled, the label allocated by the ASBR
for a route changes, which leads to packet loss.
Procedure
Step 3 Run ipv4-family vpnv4
The BGP-VPNv4 view is displayed.
Step 4 Run apply-label per-nexthop
The next-hop-based label allocation for IPv4 VPN routes is enabled on the ASBR.
----End
8.7.4.6 Verifying the Inter-AS VPN Option B Configuration
Prerequisites
The configuration of inter-AS VPN Option B is complete.
Procedure
l Run the display bgp vpnv4 all peer command on the PE or ASBR. If the status of the
IBGP peer between the PE and ASBR in the same AS is "Established", and the status of
the EBGP peer between ASBRs in the different AS is "Established", the configuration is
successful.
l Run the display bgp vpnv4 all routing-table command on the ASBR. If the VPN IPv4
routes are displayed, the configuration is successful.
device. If the VPN routes are displayed, the configuration is successful.
l Run the display mpls lsp command on the ASBR. If information about the LSP and
label is displayed, it means that the configuration succeeds. If the ASBR is enabled with
the next-hop-based label allocation, only one label is allocated for the VPN routes with
the same next hop and outgoing label.
l Run the display ip extcommunity-filter command on an ASBR to check the configured
extended community filters.
l Run the display ip rd-filter command on an ASBR to check the configured RD filters.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.5 Configuring Inter-AS VPN Option C (Solution 1)

VPN is required. If each AS needs to exchange a large number of VPN routes, inter-AS VPN
Option C is a good choice to prevent the autonomous area border routers (ASBRs) from
becoming bottlenecks that impede network expansion.
Before configuring inter-AS VPN Option C, complete the following tasks:
network of each AS
Functions.
Context
The following solutions can be used to implement inter-AS VPN Option C:
l Solution 1: After learning the labeled BGP routes of the public network in the remote AS
from the remote ASBR, the local ASBR allocates labels for these routes, and advertises
these routes to the IBGP peer that supports the label switching capability. In this manner,
a complete LSP is set up.
l Solution 2: The IBGP peer relationship between the PE and ASBR is not needed. In this
solution, an ASBR learns the labeled public BGP routes of the remote AS from the peer
ASBR. Then these labeled public BGP routes are imported to an IGP to trigger the
establishment of an LDP LSP. In this manner, a complete LDP LSP can be established
between the two PEs.
Solution 1 is described in this section, and solution 2 is described in 8.7.6 Configuring Inter-
AS VPN Option C (Solution 2).
All the following tasks are mandatory. Perform these tasks in this sequence to complete inter-
AS VPN Option C configuration.
NOTE
In inter-AS VPN Option C mode, do not enable LDP between ASBRs. If LDP is enabled on the
interfaces between ASBRs, LDP sessions are then established between the ASBRs. When a lot of BGP
routes exist, many LDP labels are occupied.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.5.1 Enabling the Labeled IPv4 Route Exchange
Context
In inter-AS VPN Option C, establish an inter-AS VPN LSP. The related PEs and ASBRs
exchange public network routes with the MPLS labels.
The public network routes with the MPLS labels are advertised by the MP-BGP. Based on
RFC 3107 (Carrying Label Information in BGP-4), the label mapping information of a route
is carried by advertising BGP updates. This feature is implemented through BGP extension
attributes, which requires BGP peers to process the labeled IPv4 routes.
By default, BGP peers cannot process labeled IPv4 routes.
Procedure
l Configure a PE device.
a. Run system-view
c. Run peer ipv4-address as-number as-number
An IBGP peer relationship is established between the local PE and ASBR in the
same AS.
d. Run peer ipv4-address connect-interface loopback interface-number
A loopback interface is specified as the outbound interface of the BGP session.
e. Run peer ipv4-address label-route-capability
Exchange of the labeled IPv4 routes with the ASBR in the same AS is enabled.
l Configure an ASBR.
a. Run system-view
The view of the interface connected with the peer ASBR is displayed.
c. Run ip address ip-address { mask | mask-length }
d. Run mpls
The MPLS capability is enabled.
e. Run quit
f. Run bgp { as-number-plain | as-number-dot }
g. Run peer ipv4-address as-number as-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An IBGP peer relationship is established between the local PE and the remote PE in
the same AS.
h. Run peer ipv4-address connect-interface loopback interface-number
i. Run peer ipv4-address label-route-capability
Exchange of the labeled IPv4 routes with the remote PE in the same AS is enabled.
j. Run peer ipv4-address as-number as-number
k. (Optional) Run peer { ipv4-address | group-name } ebgp-max-hop [ hop-count ]
Generally, one or multiple directly connected physical links exist between EBGP
peers. If the directly connected physical links are not available, run the peer ebgp-
max-hop command to ensure that the TCP connection can be set up between the
EBGP peers through multiple hops.
If BGP uses a loopback interface establish an EBGP peer relationship, you must run
the peer ebgp-max-hop command and set to hot count to a value larger than or
equal to 2. Otherwise, the peer relationship cannot be established. If hop-count is
not specified, the default value 255 is used.
l. Run peer ipv4-address label-route-capability [ check-tunnel-reachable ]
The exchange of the labeled IPv4 routes with the peer ASBR is enabled.
n If tunnel reachability checking is enabled, BGP advertises IPv4 unicast routes
to peers when routed tunnels are unreachable or advertises labeled routes to
peers when routed tunnels are reachable. This eliminates the risk of
establishing an MP-EBGP peer relationship between PEs over a faulty LSP
because this will cause data forwarding failures.
n If tunnel reachability checking is disabled, BGP advertises labeled routes to
peers whether the tunnels for imported routes are reachable or not.
----End
8.7.5.2 Configuring a Routing Policy to Control Label Distribution
Context
You need to configure a routing policy to control label allocation for each inter-AS BGP LSP.
If labeled IPv4 routes are advertised to a PE of the local AS, you need to re-allocate MPLS
labels to these routes. If routes sent by a PE of the local AS are advertised to the peer ASBR,
you need to allocate MPLS labels to these routes.
Procedure
Step 1 Create a routing policy.
1. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

2. Run route-policy policy-name1 permit node node
The routing policy applied to the local PE is created.
For the labeled IPv4 routes received from peer ASBRs, and sent to the PEs in the same
AS, this policy ensures that a new MPLS label is allocated.
3. Run if-match mpls-label
The IPv4 routes with labels are matched.
4. Run apply mpls-label
The label is allocated to the IPv4 route.
5. Run quit
6. Run route-policy policy-name2 permit node node
The routing policy applied to the peer ASBR is created.
For the labeled IPv4 routes received from PE in the local AS, and sent to the remote
ASBR, this policy ensures that a new MPLS label is allocated.
The label is allocated to the IPv4 route.
Step 2 Apply the routing policy.
1. Run system-view
2. Run bgp { as-number-plain | as-number-dot }
3. Run peer ipv4-address route-policy policy-name1 export
The routing policy adopted when the route is advertised to the local PE is created.
The routing policy adopted when the route is advertised to the peer ASBR is created.
Step 3 (Optional) Control the creation of ingress LSPs for labeled BGP routes based on routing
policies.
Perform the following steps on each PE.
1. Run system-view
3. Run ingress-lsp trigger route-policy route-policy-name
The function to create ingress LSPs for labeled BGP routes based on routing policies is
configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On a MAN where the hybrid access mode is used, a large number of labeled BGP routes
are used to establish end-to-end LSPs. On certain intermediate nodes where VPN
services do not need to be supported, excessive ingress LSPs are created, wasting
network resources. In this case, you can run the ingress-lsp trigger command to create
ingress LSPs based on a routing policy to save network resources.
----End
8.7.5.3 Establishing an MP-EBGP Peer Relationship Between PE Devices
Context
By introducing extended community attributes into BGP, MP-EBGP can advertise VPNv4
routes between PEs.
Procedure
l Configure a PE device to advertise its loopback interface IP addresses used for peer
relationship establishment to the ASBRs of other ASs and peer PE devices. You can also
configure an ASBR to send the loopback interface IP addresses of a PE device used for
peer relationship establishment to the ASBRs of other ASs and peer PE devices.
a. Run system-view
c. Run network ip-address [ mask | mask-length ] [ route-policy route-policy-name ]
The loopback address of the PE in the local AS is advertised to the remote ASBR.
l (Optional) Disable an ASBR from advertising BGP supernet labeled routes.
In an inter-AS VPN Option C scenario, a PE uses a routing policy to assign a label to its
loopback address route and advertises this route as a BGP labeled route. When an ASBR
receives the route, the route is a BGP supernet labeled route in which the destination
address and next hop address are the same or the destination address is more detailed
than the next hop address. In V2R3C00 or earlier, the ASBR does not advertise the
received BGP supernet labeled route. After the ASBR is upgraded to a version later than
V2R3C00, the ASBR can advertise the received BGP supernet labeled route to other
BGP peers. This advertisement may change the traffic path on the network before and
after the upgrade. To ensure that the traffic path remains unchanged, disable the ASBR
from advertising BGP supernet labeled routes.
a. Run system-view
c. Run supernet label-route advertise disable
The ASBR is disabled from advertising BGP supernet labeled routes.
After you disable the ASBR from advertising BGP supernet labeled routes, to
advertise the loopback address route of a PE in the local AS to a PE in another AS,

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
run the network command on the ASBR to advertise the BGP route to the loopback
address of the PE in the same AS.
l Perform the following steps on the PE device:
a. Run system-view
c. Run peer ipv4-address as-number { as-number-plain | as-number-dot }
The peer PE is specified as the EBGP peer.
The source interface that sends BGP packets is specified.
e. Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum hop of the EBGP peer is configured.
PEs of different ASs are generally not directly connected. To set up the EBGP peer
between PEs of different ASs, configure the maximum hop between PEs and ensure
the PEs are reachable.
f. (Optional) Run peer { group-name | ipv4-address } mpls-local-ifnet disable
The ability to establish an MPLS local IFNET tunnel between PEs is disabled.
In the Option C scenario, PEs establish an MP-EBGP peer relationship. Therefore,
an MPLS local IFNET tunnel between PEs is established over the MP-EBGP peer
relationship. The MPLS local IFNET tunnel fails to transmit traffic because PEs are
indirectly connected.
If a fault occurs on the BGP LSP between PEs, traffic is iterated to the MPLS local
IFNET tunnel, not an FRR bypass tunnel. As the MPLS local IFNET tunnel cannot
forward traffic, traffic is interrupted. To prevent the traffic interruption, run this
command to disable the establishment of an MPLS local IFNET tunnel between
PEs.
g. Run ipv4-family vpnv4 [ unicast ]
The BGP VPNv4 address family is displayed.
h. Run peer ipv4-address enable
The exchange of VPN IPv4 routes with the peer PE is enabled.
----End
Related Tasks
To improve scalability, specify an RR in each AS and establish MP-EBGP peer relationships
between the RRs in ASs to save all VPNv4 routes on the RRs. Then configure PEs in each AS
as the RR's clients to exchange VPNv4 routing information with the RR. The configuration is
as follows:
l Configure a PE device to advertise its loopback interface IP addresses used for peer
relationship establishment to the ASBRs of other ASs and peer PE devices. You can also
configure an ASBR to send the loopback interface IP addresses of a PE device used for

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
peer relationship establishment to the ASBRs of other ASs and peer PE devices. The
configuration procedure is the same as the above mentioned procedure.
l Establish an MP-EBGP peer relationship between the RRs. The configuration procedure
is similar to the procedure for establishing an MP-EBGP peer relationship between two
PE devices, except that you need to run the peer ipv4-address next-hop-invariable
command in the BGP-VPNv4 address family view of the RRs to configure them not to
change the next hop when advertising routes to the EBGP peers.
l Configure PE devices as the clients of the RR in the local AS to exchange VPNv4
routing information with the RR. For details about the configurations, see 8.7.11
Configuring Route Reflection to Optimize the VPN Backbone Layer.
8.7.5.4 Verifying the Inter-AS VPN Option C Configuration (Solution 1)
Prerequisites
The configuration of inter-AS VPN Option C (Solution 1) is complete.
Procedure
l Run the display bgp vpnv4 all peer command to check the BGP peers on the PE device.
You can find the status of the EBGP peer between PEs is "Established".
l Run the display bgp vpnv4 all routing-table command to check the VPN IPv4 routing
table on the PE or ASBR. You can view that the PE has the VPN IPv4 routes while the
ASBR has no VPN IPv4 route.
l Run the display bgp routing-table label command to check information about the label
of the IPv4 route on the ASBR.
the VPN routing table on the PE device. The command displays all VPN routes to all the
CE devices in the VPN routing table of the PE device.
----End
8.7.6 Configuring Inter-AS VPN Option C (Solution 2)

VPN is required. If each AS needs to exchange a large number of VPN routes, inter-AS VPN-
Option C is a good choice to prevent the autonomous area border routers (ASBRs) from
becoming bottlenecks that impede network expansion.
Before configuring inter-AS VPN Option C, complete the following tasks:
network of each AS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Functions.
Context
The following solutions can be used to implement inter-AS VPN-Option C:
l Solution 1: After learning the labeled BGP routes of the public network in the remote AS
from the remote ASBR, the local ASBR allocates labels for these routes, and advertises
these routes to the IBGP peer that supports the label switching capability. In this manner,
a complete LSP is set up.
l Solution 2: The IBGP peer relationship between the PE and ASBR is not needed. In this
solution, an ASBR learns the labeled public BGP routes of the remote AS from the peer
ASBR. Then these labeled public BGP routes are imported to an IGP to trigger the
establishment of an LDP LSP. In this manner, a complete LDP LSP can be established
If an ASBR is ready to access a large number of PEs, solution 2 is recommended for its easy
configuration.
NOTE
In inter-AS VPN Option C mode, do not enable LDP between ASBRs. If LDP is enabled on the
interfaces between ASBRs, LDP sessions are then established between the ASBRs. When a lot of BGP
routes exist, many LDP labels are occupied.
All the following tasks are mandatory. Perform these tasks in this sequence to complete inter-
AS VPN Option C configuration.
8.7.6.1 Establishing the EBGP Peer Relationship Between ASBRs
Context
An EBGP peer relationship is established between ASBRs to advertise routes destined for the
loopback interfaces on PEs.
Perform the following steps on ASBRs.
Procedure
The view of the interface that connects the remote ASBR is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

The IP address is configured.
Step 4 Run quit
The remote ASBR is configured as the EBGP peer.
Step 7 (Optional) Run peer { ipv4-address | group-name } ebgp-max-hop [ hop-count ]
Generally, one or multiple directly connected physical links exist between EBGP peers. If the
directly connected physical link(s) are not available, run the peer ebgp-max-hop command to
ensure that the TCP connection can be set up between the EBGP peers through multiple hops.
----End
8.7.6.2 Advertising the Routes of the PE in the Local AS to the Remote PE
Context
After the routes of the loopback interface on a PE in an AS are advertised to the remote PE in
another AS, the MP-EBGP peer relationship is established between PEs.
Procedure
l The loopback address of the PE in the local AS is advertised to the remote ASBR.
Perform the following steps on the local ASBR:
a. Run system-view
c. Run network ip-address [ mask | mask-length ]
The loopback address of the PE in the local AS is advertised to the remote ASBR.
l The BGP routes are imported to IGP.
Perform the following steps on the peer ASBR:
a. Run system-view
b. Run ospf process-id
The OSPF view is displayed.
c. Run import-route bgp [ cost cost ] [ route-policy route-policy-name ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The BGP routes are imported to IGP.

----End
8.7.6.3 Enabling the Capability of Exchanging Labeled IPv4 Routes
Context
To establish an inter-AS BGP LSP, you must enable ASBRs to exchange labeled IPv4 routes.
Procedure
l Creating a routing policy.
a. Run system-view
b. Run route-policy route-policy-name permit node node
The routing policy applied to advertise routes to the remote ASBR is configured.
c. Run apply mpls-label
Labels for IPv4 routes are distributed.
d. Run quit
l Applying a Routing Policy
a. Run system-view
c. Run peer ipv4-address route-policy route-policy-name export
The routing policy applied to advertise routes to the remote ASBR is configured.
d. Run quit
l Enabling the function of labeled IPv4 route exchange.
a. Run system-view
The view of the interface connecting the remote ASBR is displayed.
c. Run mpls
The MPLS function is enabled.
d. Run quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
e. Run bgp { as-number-plain | as-number-dot }

----End
8.7.6.4 Establishing an LDP LSP for the Labeled BGP Routes of the Public
Network
Context
By enabling LDP on ASBRs to allocate labels for BGP routes, you can establish LDP LSPs
for labeled BGP routes of the public network that are filtered in the IP prefix list.
Procedure
Step 2 Run mpls
The MPLS view is displayed.
Step 3 Run lsp-trigger bgp-label-route [ ip-prefix ip-prefix-name ]
An LDP LSP is established for the labeled BGP routes of the public network that is filtered by
the IP prefix list.
----End
8.7.6.5 Establishing the MP-EBGP Peer Relationship Between PEs
Prerequisites
By introducing extended community attributes into BGP, MP-IBGP can advertise VPNv4
routes between PEs. PEs of different ASs are generally not directly connected. To set up an
EBGP connection between the PEs of different ASs, you must configure the permitted
maximum number of hops between PEs.
Perform the following steps on PEs.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The remote PE is specified as the EBGP peer.

Step 4 Run peer ipv4-address connect-interface interface-type interface-number ipv4-source-
address
The source interface that sends BGP packets is specified.
Step 5 Run peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops permitted to establish the EBGP peer is specified.
Step 6 (Optional) Run peer { group-name | ipv4-address } mpls-local-ifnet disable
The ability to establish an MPLS local IFNET tunnel between PEs is disabled.
In the Option C scenario, PEs establish an MP-EBGP peer relationship. Therefore, an MPLS
local IFNET tunnel between PEs is established over the MP-EBGP peer relationship. The
MPLS local IFNET tunnel fails to transmit traffic because PEs are indirectly connected.
If a fault occurs on the BGP LSP between PEs, traffic is iterated to the MPLS local IFNET
tunnel, not an FRR bypass tunnel. As the MPLS local IFNET tunnel cannot forward traffic,
traffic is interrupted. To prevent the traffic interruption, run this command to disable the
establishment of an MPLS local IFNET tunnel between PEs.
The BGP VPNv4 sub-address family view is displayed.
The VPNv4 route exchange capability with the remote PE is enabled.
----End
8.7.6.6 Verifying the Inter-AS VPN Option C Configuration (Solution 2)
Prerequisites
The configurations of the Inter-AS VPN Option C (Solution 2) function are complete.
Procedure
l Run the display bgp vpnv4 all peer command to check information about the specified
VPNv4 peer on a PE. You can find that the EBGP peer relationship between PEs is
established.
l Run the display bgp vpnv4 all routing-table command to check information about the
VPN-IPv4 routing table on a PE or an ASBR. You can find that BGP VPNv4 routes and
BGP VPN instance routes are on the PE, rather than on the ASBR.
l Run the display bgp routing-table label command to check information about the labels
of IPv4 routes on an ASBR.
the VPN routing table on a PE device. You can find that the VPN routing table of the PE
has the VPN routes to the CE related to the specified VPN instance.
l Run the display mpls route-state [ { exclude | include } { idle | ready | settingup } * |
destination-address mask-length ] [ verbose ] command to check the matching
relationship between routes and the LSP on an ASBR. You can find the routes with the
type as L, that is, the labeled BGP routes of the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ip routing-table command to check information about the routing table
on an ASBR. You can find that the routes to the remote PE are labeled BGP routes of the
public network: The routing table is "Public", the protocol type is "BGP", and the label
has a non-zero value.
l Run the display mpls lsp [ vpn-instance vpn-instance-name ] [ protocol ldp ]
[ { exclude | include } ip-address mask-length ] [ outgoing-interface interface-type
interface-number ] [ in-label in-label-value ] [ out-label out-label-value ] [ lsr-role
{ egress | ingress | transit } ] [ verbose ] command to check whether an LDP LSP is
established on an ASBR. You can find that an LDP LSP is established between the
ASBR and the remote PE. Besides, the LDP ingress LSP to the remote PE can be found
on the local PE.
----End
8.7.7 Configuring an MCE Device

A multi-VPN-instance CE (MCE) device can connect to multiple VPNs. The MCE solution
isolates services of different VPNs while reducing cost of network devices.
Before configuring an MCE device, complete the following tasks:
l Configuring a VPN Instance on the multi-instance CE, and the PE that is accessed by it
(each service with a VPN instance)
l Configuring the link layer protocol and network layer protocol for LAN interfaces and
connecting the LAN to the multi-instance CE (each service using an interface to access
the multi-instance CE)
l Binding related VPN instances to the interfaces of the multi-instance CE and PE
interfaces through which the PE accesses the multi-instance and configuring IP addresses
for those interfaces
The following tasks are mandatory and can be performed in a random order.
8.7.7.1 Configure Route Exchange Between an MCE Device and VPN Sites
Context
Routing protocols that can be used between an MCE device and VPN sites are static routing,
RIP (Routing Information Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate
System to Intermediate System), or BGP (Border Gateway Protocol).Choose one of the
following configurations as needed:
l Configure static routes between an MCE device and a site.
l Configure RIP between an MCE device and a site.
l Configure OSPF between an MCE device and a site.
l Configure IS-IS between an MCE device and a site.
l Configure BGP between an MCE device and a site.
The following configurations are performed on the MCE device. On the devices in the site,
you only need to configure the corresponding routing protocol.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure Static Routes Between an MCE Device and a Site

Perform the following configurations on the MCE device. You only need to configure a static
route to the MCE device in the site. The site configuration is not provided here. For detailed
configuration of static routes, see Static Route Configuration in the Huawei
Table 8-13 MCE configuration

Enter the system system-view -

view.
Configure a static ip route-static vpn-instance vpn-source- You must specify the next
route to the site. name destination-address { mask | mask- hop address on the MCE
length } { nexthop-address [ public ] | device.
interface-type interface-number
[ nexthop-address ] } [ preference
Configure RIP Between an MCE Device and a Site

Perform the following configurations on the MCE device. Configure RIPv1 or RIPv2 in the
site. The site configuration is not provided here. For detailed RIP configuration, see RIP


view.
Create a RIP rip process-id vpn-instance vpn- A RIP process can be

process running instance-name bound to only one VPN
between the instance. If a RIP process
MCE device and is not bound to any VPN
the site and enter instance before it is
the RIP view. started, this process
becomes a public network
process and can no longer
be bound to a VPN
instance.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Enable RIP on network network-address -

the network
segment of the
interface to
which the VPN
instance is
bound.
(Optional) Import import-route { { static | direct | unr } | Perform this step if

the routes to the { rip | ospf | isis } [ process-id ] } [ cost another routing protocol
remote sites cost | route-policy route-policy-name ] * is running between the
advertised by the MCE and PE devices in
import-route bgp [ cost { cost |
PE device in to the VPN instance.
transparent } | route-policy route-
the RIP routing
policy-name ] *
table.
Configure OSPF Between an MCE Device and a Site

Perform the following configurations on the MCE device. Configure OSPF in the site. The
site configuration is not provided here. For detailed OSPF configuration, see OSPF

view.
Create an OSPF ospf [ process-id | router-id router-id ] * -

process running vpn-instance vpn-instance-name
between the
MCE device and
the site and enter
the OSPF view.
(Optional) Import import-route { bgp [ permit-ibgp ] | Perform this step if

the routes to the direct | unr | rip [ process-id-rip ] | static another routing protocol
remote sites | isis [ process-id-isis ] | ospf [ process-id- is running between the
advertised by the ospf ] } [ cost cost | type type | tag tag | MCE and PE devices in
PE device into route-policy route-policy-name ] * the VPN instance.
the OSPF routing
table.
Configure an area { area-id | area-id-address } -

OSPF area and
enter the OSPF
area view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Enable OSPF on network ip-address wildcard-mask -

the network
segment of the
interface to
which the VPN
instance is
bound.
Configure IS-IS Between an MCE Device and a Site

Perform the following configurations on the MCE device. You only need to configure IS-IS in
the site. The site configuration is not provided here. For detailed IS-IS configuration, see IS-
IS Configuration in the Huawei


view.
Create an IS-IS isis process-id vpn-instance vpn- An IS-IS process can be

between the MCE instance. If an IS-IS
device and the site process is not bound to any
and enter the IS-IS VPN instance before it is
view. started, this process
be bound to a VPN
instance.
Set a network network-entity net A NET specifies the

entity title (NET) current IS-IS area address
for the IS-IS and the system ID of the
process. router. A maximum of
three NETs can be
configured for one process
on each router.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Import the routes Use either of the following commands: Perform this step if another
to the remote sites l import-route { direct | static | unr routing protocol is running
advertised by the | { ospf | rip | isis } [ process-id ] | between the MCE and PE
PE device into the bgp } [ cost-type { external | devices in the VPN
IS-IS routing internal } | cost cost | tag tag | instance.
table. route-policy route-policy-name |
[ level-1 | level-2 | level-1-2 ] ] *
l import-route { { ospf | rip | isis }
[ process-id ] | bgp | direct |
unr }inherit-cost [ { level-1 |
level-2 | level-1-2 } | tag tag |
Return to system quit -

view.
Enter the view of interface interface-type interface- -

the interface to number
which the VPN
instance is bound.
Enable IS-IS on isis enable [ process-id ] -

the interface.
Configure BGP between an MCE Device and a Site

Perform the following configurations on the MCE device.


view.
Enter the BGP bgp { as-number-plain | as-number-dot } -

view.
Enter the BGP- ipv4-family vpn-instance vpn-instance- -

VPN instance name
IPv4 address
family view.
Configure the peer ipv4-address as-number as-number -

device connected
to the MCE device
in the site as a
VPN peer.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Import the routes import-route protocol [ process-id ] Perform this step if

to the remote sites [ med med | route-policy route-policy- another routing protocol
advertised by the name ] * is running between the
PE device into the MCE and PE devices in
BGP routing table. the VPN instance.
Perform the following configurations on the device connected to the MCE device in the site.
Table 8-18 Site configuration


view.

view.
Configure the peer ipv4-address as-number as-number -

MCE device as a
VPN peer.
Import IGP routes import-route protocol [ process-id ] The site must advertise
of the VPN into [ med med | route-policy route-policy- routes to its attached
the BGP routing name ] * VPN network segments
table. to the MCE device.
8.7.7.2 Configure Route Exchange Between an MCE Device and a PE Device
Context
Routing protocols that can be used between an MCE device and a PE device are static routing,
RIP, OSPF, IS-IS, and BGP. Choose one of the following configurations as needed:
l Configure static routes between an MCE device and a PE device.
l Configure RIP between an MCE device and a PE device.
l Configure OSPF between an MCE device and a PE device.
l Configure IS-IS between an MCE device and a PE device.
l Configure BGP between an MCE device and a PE device.
The following configurations are performed on the MCE device. The configurations on the
PE device are similar to those on a PE device in the BGP/MPLS IP VPN networking. For
detailed configuration, see Configuring Route Exchange Between PE and CE Devices.
Configure Static Routes Between an MCE Device and a PE Device


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


view.
Configure a static ip route-static vpn-instance vpn-source- You must specify the

route to the PE name destination-address { mask | mask- next hop address on
device. length } vpn-instance vpn-destination- the MCE device.
name nexthop-address [ preference
Configure RIP Between an MCE Device and a PE Device



view.
Create a RIP rip process-id vpn-instance vpn-instance- A RIP process can be

process running name bound to only one
between the MCE VPN instance. If a RIP
and PE devices and process is not bound to
enter the RIP view. any VPN instance
before it is started, this
process becomes a
public network process
and can no longer be
bound to a VPN
instance.
Enable RIP on the network network-address -

network segment of
the interface to
which the VPN
instance is bound.
(Optional) Import import-route { { static | direct | unr } | Perform this step if

VPN routes of the { rip | ospf | isis } [ process-id ] } [ cost another routing
site into the RIP cost | route-policy route-policy-name ] * protocol is running
routing table. between the MCE
import-route bgp [ cost { cost |
device and VPN sites
transparent } | route-policy route-policy-
in the VPN instance.
name ] *

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure OSPF Between an MCE Device and a PE Device



view.
Create an OSPF ospf [ process-id | router-id router-id ] * -

process running vpn-instance vpn-instance-name
between the MCE
and PE devices and
enter the OSPF
view.
(Optional) Import import-route { bgp [ permit-ibgp ] | Perform this step if

VPN routes of the direct | unr | rip [ process-id-rip ] | static another routing
site into the OSPF | isis [ process-id-isis ] | ospf [ process-id- protocol is running
routing table. ospf ] } [ cost cost | type type | tag tag | between the MCE
route-policy route-policy-name ] * device and VPN sites
Disable routing vpn-instance-capability simple By default, routing

loop detection in loop detection is
the OSPF process. disabled in an OSPF
process. If routing loop
detection is not
disabled in the OSPF
process on the MCE
device, the MCE
device rejects OSPF
routes sent from the PE
device.
Configure an OSPF area { area-id | area-id-address } -

area and enter the
OSPF area view.
Enable OSPF on network ip-address wildcard-mask -

the network
segment of the
interface to which
the VPN instance is
bound.
Configure IS-IS Between an MCE Device and a PE Device


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


view.
Create an IS-IS isis process-id vpn-instance vpn-instance- An IS-IS process can

process running name be bound to only one
between the MCE VPN instance. If an IS-
and PE devices IS process is not bound
and enter the IS-IS to any VPN instance
view. before it is started, this
process becomes a
public network process
and can no longer be
bound to a VPN
instance.

entity title (NET) current IS-IS area
for the IS-IS address and the system
process. ID of the router. A
maximum of three
NETs can be
configured for one
process on each router.
(Optional) Import Use either of the following commands: Perform this step if
VPN routes of the l import-route { direct | static | unr | another routing
site into the IS-IS { ospf | rip | isis } [ process-id ] | bgp } protocol is running
routing table. [ cost-type { external | internal } | cost between the MCE
cost | tag tag | route-policy route- device and VPN sites
policy-name | [ level-1 | level-2 | in the VPN instance.
level-1-2 ] ] *
l import-route { { ospf | rip | isis }
[ process-id ] | bgp | direct |
unr }inherit-cost [ { level-1 | level-2 |
level-1-2 } | tag tag | route-policy
route-policy-name ] *

view.
Enter the view of interface interface-type interface-number -

the interface to
which the VPN
instance is bound.
Enable IS-IS on isis enable [ process-id ] -

the interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure BGP Between an MCE Device and a PE Device



view.

view.
Enter the BGP- ipv4-family vpn-instance vpn-instance- -

VPN instance name
IPv4 address
family view.
Configure the PE peer ipv4-address as-number as-number -

device as the VPN
peer of the MCE
device.
Import the routes import-route protocol [ process-id ] [ med Perform this step if
to the remote sites med | route-policy route-policy-name ] * another routing
advertised by the protocol is running
PE device into the between the MCE
BGP routing table. device and VPN sites
8.7.7.3 Verifying the MCE Configuration
Prerequisites
The configurations of the Multi-VPN-Instance CE function are complete.
Procedure
l Run the display ip routing-table vpn-instance vpn-instance-name [ verbose ]
command to check the VPN routing table on the multi-instance CE. If there are routes to
the LAN and the remote nodes for each service, the configuration is successful.
----End
8.7.8 Configuring HoVPN

The HoVPN networking reduces the requirements for PE devices.
Before configuring HoVPN, complete the task of 8.7.1 Configuring Basic BGP/MPLS IP
VPN Functions.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
In addition to basic BGP/MPLS IP VPN configuration, you need to specify UPE devices on
the SPE device and advertise default routes of VPN instances to the UPE devices.
NOTE
According to RFC 4382, the VPN instance status obtained from a management information base (MIB)
or schema is Up only if at least one interface bound to the VPN instance is Up. On an HoVPN, VPN
instances on SPEs are not bound to interfaces. As a result, the VPN instance status obtained from a MIB
or schema is always Down. To solve this problem, run the transit-vpn command in the VPN instance
view or VPN instance IPv4 address family view of an SPE. Then, the VPN instance status obtained from
a MIB or schema is always Up, no matter whether the VPN instance is bound to interfaces.
Perform the following steps on the SPE device.
Procedure
Step 1 Specify a UPE device.
1. Run system-view
3. Run peer { ipv4-address | group-name } as-number as-number
A UPE device is specified as the BGP peer of the SPE.
4. Run ipv4-family vpnv4 [ unicast ]
The BGP-VPNv4 family is displayed.
5. Run peer { ipv4-address | group-name } enable
The capability of exchanging BGP VPNv4 routing information with the peer is enabled.
6. Run peer { ipv4-address | group-name } upe
The peer is specified as the UPE of the SPE.
Step 2 Advertise default routes of a VPN instance.
1. Run system-view
3. Run ipv4-family vpnv4
The BGP-VPNv4 family view is displayed.
4. Run peer { ipv4-address | group-name } default-originate vpn-instance vpn-instance-
name
The default routes of a specified VPN instance are advertised to the UPE device.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After running the command, the SPE advertises a default route to the UPE with its local
address as the next hop, regardless of whether there is a default route in the local routing
table.
----End

After completing the HoVPN configuration, run the display ip routing-table command on
the CE devices. You can see that the local CE device does not have any route to the network
segment of the remote CE interface but has a default route with the next hop as the UPE
device.
8.7.9 Configuring PBR to an LSP for VPN Packets

Policy-based routing (PBR) to an LSP enables the device to forward VPN packets through
LSPs on the MPLS backbone network through PBR, without the need to search the
forwarding table of the VPN instance.
Context
The AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600
supports PBR to an LSP for VPN packets, which can be used for VPN data forwarding.
If VPN packets do not match the PBR rules, they are forwarded according to common VPN
data forwarding process. If VPN packets match the PBR rules, they are forwarded through the
specified LSP.
NOTE
PBR to an LSP for VPN packets requires two or more LSPs. If PBR to an LSP for VPN packets are used
together with LDP FRR, the LSPs must work in active/standby mode. In other situations, the LSPs can
work in active/standby mode or load balancing mode.
Perform the following configuration on the ingress PE device.
Before configuring PBR to an LSP for VPN packets, complete the following tasks:
l Configuring an ACL to filter packets if you want to filter packets based on IP addresses
l Configuring at least two LSPs from the ingress PE device to the egress PE device
l Configuring LDP FRR if necessary
Procedure
Step 1 Configure PBR to an LSP for VPN packets.
1. Run system-view

2. Run policy-based-route policy-name { deny | permit } node node-id
A routing policy or a policy node is created.

3. Run if-match acl acl-numberif-match packet-length min-length max-length

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
An if-match clause is configured to match the IP addresses of packets.
Or, run:
An if-match clause is configured to match the lengths of IP packets.

4. Run apply lsp vpn vpn-instance-name ce-address [ pe-address [ p-address | interface-
type interface-number | secondary ] ]
PBR to an LSP are configured for VPN packets.

5. (Optional) Run ip policy-based-route refresh-time [ refreshtime-value ]
The interval at which local PBR updates LSPs is configured.
By default, the interval at which local PBR updates LSPs is 5000 ms.
Step 2 Apply PBR.
Enable PBR in the system (local PBR).
1. Run system-view
2. Run ip local policy-based-route policy-name
Local PBR is enabled.
Local PBR takes effect only to locally originated packets and only one local PBR rule
can be configured.
----End

After completing the configuration of PBR to an LSP, run the tracert lsp [ -a source-ip | -exp
exp-value | -h ttl-value | -r reply-mode | -t time-out ] * { ip destination-address mask-length
[ ip-address ] [ nexthop nexthop-address | draft6 ] | te tunnel interface-number [ hot-
standby ] [ draft6 ] } command to check the VPN packet transmission path. The command
output shows that VPN packets are transmitted through the specified LSP.
NOTE
Before running the tracert lsp command on a CE device to check the packet forwarding path, run the ttl
propagate vpn command on the ingress and egress PE devices directly connected to the CE device to
enable MPLS IP TTL replication.
8.7.10 Configuring an OSPF Sham Link

The sham link between two PE devices on an MPLS VPN backbone network is considered as
an OSPF intra-area route. Then VPN traffic is transmitted through the route over the
backbone network but not backdoor routes.
Before configuring an OSPF sham link, complete the following tasks:
l 8.7.1 Configuring Basic BGP/MPLS IP VPN Functions (use OSPF between PE and
CE)
l Configuring OSPF in the LANs where the CE devices are located

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
OSPF sham links are IP unnumbered P2P links between two PE devices on an MPLS VPN
backbone network.
Generally, BGP peers use BGP extended community attributes to carry routing information
over the MPLS VPN backbone. OSPF running on a PE device can use the routing information
to generate inter-area routes from the PE to CE devices.
As shown in Figure 8-39, if an intra-area OSPF link exists between the network segments of
local and remote CE devices, this OSPF link is called a backdoor link.
Figure 8-39 OSPF sham link
MPLS VPN backbone
PE1 sham link PE2

Area 0
Area 0
OSPF 200
OSPF 200
CE2
CE1
VPN1
VPN1
site2
site1 backdoor
The routes that pass through a backdoor link are intra-area routes and have a higher
preference than the inter-area routes that pass through the MPLS VPN backbone network. As
a result, VPN traffic is always forwarded through the backdoor routes instead of the backbone
network. Generally, backdoor links are only used as backup links.
To avoid such a problem, an OSPF sham link can be established between the PE devices. In
this way, the routes that pass through the MPLS VPN backbone network become OSPF intra-
area routes and are preferred over the backdoor routes in VPN traffic forwarding.
Configure an OSPF sham link only when a backdoor link exists between two sites in the same
OSPF area. If no backdoor link exists between sites in the same area, you do not need to
configure any OSPF sham link.
Perform the following steps on the PE devices at both ends of a sham link.
Procedure
Step 1 Configure an endpoint address for the sham link.
Each VPN instance must have an endpoint address of the sham link. The endpoint address is a
loopback interface address with a 32-bit mask in the VPN address space on a PE device.
Multiple sham links of the same OSPF process share an endpoint address, but sham links of
different OSPF processes cannot have the same endpoint address.
1. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

2. Run interface loopback interface-number
A loopback interface is created and the loopback interface view is displayed.
3. Run ip binding vpn-instance vpn-instance-name
The loopback interface is bound to a VPN instance.
4. Run ip address ip-address { mask | mask-length }
An IP address is assigned to the loopback interface.
NOTE
The loopback interface address must have a 32-bit mask, 255.255.255.255.
Step 2 Advertise routes of the sham link endpoint address.

1. Run system-view
3. Run ipv4-family vpn-instance vpn-instance-name
4. Run import-route direct
Direct routes are imported to BGP. (The route of the sham link endpoint address is
imported to BGP).
BGP advertises the sham link endpoint address as a VPN IPv4 address.
NOTE
The route of the sham link endpoint address cannot be advertised to the peer PE through an OSPF
process bound to a VPN instance.
If the route of the sham link endpoint address is advertised to the peer PE through an OSPF
process bound to a VPN instance, the peer PE has two routes to the sham link endpoint address.
One route is learned from the OSPF process, and the other is learned from MP-BGP. The OSPF
route takes precedence over the BGP route, so the peer PE uses the OSPF route. As a result, the
sham link fails to be established.
Step 3 Create a sham link.

1. Run system-view
2. Run ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
3. Run area area-id
The OSPF area view is displayed.
4. Run sham-link source-ip-address destination-ip-address [ [ 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 ] | smart-
discover | cost cost | dead dead-interval | hello hello-interval | retransmit retransmit-
interval | trans-delay trans-delay-interval ] *

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
A sham link is configured.
The default settings of the parameters in the command are as follows:

– cost (sham link interface cost): 1
– dead-interval (sham link timeout interval): 40 seconds
– hello-interval (interval for sending Hello packets on the sham link interface): 10
seconds
– retransmit-interval (LSA packet retransmission interval on the sham link interface):
5 seconds
– trans-delay-interval (delay in sending LSA packets on the sham link interface): 1
second
Both ends of the sham link must use the same packet authentication method. If packet
authentication is configured, the PE devices accept only the OSPF packets that pass the
authentication. If packets fail the authentication, the neighbor relationship cannot be
established between the PE devices.
If simple-text authentication (simple) is used, the authentication key type is plain by

default. If the MD5 or HMAC-MD5 authentication (md5 | hmac-md5) is used, the
authentication key type is cipher by default.
NOTE
If plain is selected, the password is saved in the configuration file in plain text. This brings
MD5 and HMAC-MD5 authentication cannot ensure security. Keychain authentication is
recommended.
To forward VPN traffic over the MPLS backbone network, ensure that the cost of the sham link is
smaller than the cost of the OSPF route used for forwarding VPN traffic over the customer
network. A commonly used method is to set the cost of the forwarding interface on the customer
network to be larger than the cost of the sham link.
----End

After configuring an OSPF sham link, you can check the routing table on a CE, trace the
nodes that data packets pass through from local CE to the remote CE, and check whether the
sham link is successfully established on the PE.

to check the VPN routing table. You can see from the VPN routing table that the route
from the PE to the remote CE is an OSPF route that passes through the customer
network but not a BGP route that passes through the backbone network.
l Run the display ip routing-table and tracert host commands on a CE, and you can find
that the VPN traffic from the local CE to the remote CE is forwarded through the
backbone network.
l Run the display ospf process-id sham-link [ area area-id ] command on the PE to check
whether the sham link is established successfully. You can find that the OSPF neighbor
relationship between the PE and the remote CE is Full.
l Run the display ospf routing on the CE, and you can find that the route to the remote
CE is an intra-area route.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.11 Configuring Route Reflection to Optimize the VPN

Backbone Layer
Using an RR can reduce the number of MP IBGP connections between PEs. This not only
reduces the burden of PEs, but also facilitates network maintenance and management.
Before configuring route reflection to optimize the VPN backbone layer, complete the
following tasks:
l Configuring the routing protocol for the MPLS backbone network to implement IP
interworking between devices on the backbone network
l Establishing tunnels (LSPs, GRE, or MPLS TE tunnels) between the RR and all client
PE devices
All the following configuration tasks are mandatory. An RR can be any device such as P, PE,
and ASBR.
8.7.11.1 Configuring the Client PEs to Establish MP IBGP Connections with the
RR
Context
Perform the following steps on all Client PEs.
Procedure
The RR is specified as the BGP peer.
The interface is specified as an interface to establish the TCP connection.
The BGP VPNv4 address family view is displayed.
The capability of exchanging VPNv4 routes between the PE and RR is enabled.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.7.11.2 Configuring the RR to Establish MP IBGP Connections with the Client

PEs
Context
Choose one of the following schemes to configure the RR.
Procedure
l Configuring the RR to establish MP IBGP connections with the peer group
Add all the client PEs to the peer group and establish MP-IBGP connections with the
peer group.
a. Run system-view
c. Run group group-name [ internal ]
An IBGP peer group is created.
d. Run peer group-name connect-interface interface-type interface-number
e. Run ipv4-family vpnv4
f. Run peer group-name enable
The capability of exchanging IPv4 VPN routes between the RR and the peer group
is enabled.
By default, only the peer in the BGP IPv4 unicast address family view is
automatically enabled.
g. Run peer ip-address group group-name
The peer is added to the peer group.
l Configuring the RR to establish an MP IBGP connection with each client PE
Repeat the following steps on the RR to establish an MP IBGP connection with each
client PE.
a. Run system-view
The client PE is specified as the BGP peer.
d. Run peer ipv4-address connect-interface interface-type interface-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
e. Run ipv4-family vpnv4

f. Run peer ipv4-address enable
The capability of exchanging VPNv4 routes between the RR and the client PE is
enabled.
----End
8.7.11.3 Configuring Route Reflection for BGP IPv4 VPN Routes
Context
Perform the following steps on the RR.
Procedure
Step 4 Enable route reflection for BGP VPNv4 routes on the RR.
l Run the peer group-name reflect-client command to enable route reflection if the RR
establishes the MP IBGP connection with the peer group consisting of client PEs.
l Run the peer ipv4-address reflect-client command repeatedly to enable route reflection
if the RR establishes the MP IBGP connection with each PE rather than peer group.
Step 5 Run undo policy vpn-target
The filtering of VPNv4 routes based on the VPN target is disabled.
Step 6 (Optional) Run rr-filter { extcomm-filter-number | extcomm-filter-name }
The reflection policy is configured for the RR. Only the IBGP route of which route-target
extended community attribute meets the matching rules can be reflected. This allows load
balancing among RRs.
In the command, the extended community filter specified by extcomm-filter-number or
extcomm-filter-name must have been configured using the ip extcommunity-filter command.
Step 7 (Optional)Run undo reflect between-clients
Route reflection is disabled between clients.
If the clients of an RR have established full-mesh connections with each other, the undo
reflect between-clients command can be used to disable route reflection between clients in
order to reduce the link cost.By default, route reflection is enabled between the clients of an
RR.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
This command can only be configured on the RR.

Step 8 (Optional) Run reflector cluster-id cluster-id
The RR cluster ID is set.
If a cluster has multiple RRs, you can use this command to set the same cluster ID for these
RRs to prevent routing loops.By default, the cluster ID is the router ID.
----End
8.7.11.4 Verifying the Configuration of Route Reflection to Optimize the VPN

Backbone Layer
Prerequisites
The configurations of the reflection to optimize the VPN backbone layer function are
complete.
Procedure
l Run the display bgp vpnv4 all peer [ [ ipv4-address ] verbose ] command to check
information about the BGP VPNv4 peer on the RR or the Client PEs. You can find that
the status of the MP IBGP connections between the RR and all Client PEs is
"Established".
l Run the display bgp vpnv4 all routing-table peer ipv4-address { advertised-routes |
received-routes } command or display bgp vpnv4 all routing-table statistics
command to check information about the routes received from the peer or the routes
advertised to the peer on the RR or the Client PEs. You can find that the RR and each
Client PE can receive and send VPNv4 routing information between each other.
l Run the display bgp vpnv4 all group [ group-name ] command to check information
about the VPNv4 peer group on the RR. You can view information about the group
members and find that the status of the BGP connections between the RR and the group
members is "Established".
----End
8.7.12 Configuring IP FRR for VPN Routes

When multiple CE devices in a VPN site connect to the same PE, you can configure IP FRR
for VPN routes. IP FRR enables VPN traffic to be fast switched to another PE-CE link when
the next hop of the primary route is unreachable.
Before configuring IP FRR for VPN routes, complete the following tasks:
l 8.7.1 Configuring Basic BGP/MPLS IP VPN Functions
l Ensuring that the PE has learned VPN routes with the same prefix from the attached CE
devices
Context
IP FRR for VPN routes is used in scenarios where multiple CE devices connect to one PE
device. As shown in Figure 8-40, the PE device forwards data to the site of vpn1 through

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Link_A, and Link_B is a backup link. When the PE device detects that the route to CE1 is
unreachable, it immediately switches traffic to Link_B and then performs other operations to
trigger VPN route convergence. This minimizes impact of the link failure on VPN services.
Figure 8-40 IP FRR for VPN routes
CE1
VPN1 Site
IP/MPLS
Backbone Link_A
SwitchA
PE Link_B
CE2
The router supports IP FRR for VPN routes.
Perform the following steps on a PE device.
Procedure
l configuring IP FRR
a. Run system-view
b. Run route-policy route-policy-name { permit | deny } node node
A node is configured for a route-policy, and the route-policy view is displayed.
c. Run apply backup-interface interface-type interface-number
A backup outbound interface is specified.
d. (Optional) Run apply backup-nexthop ip-address
A backup next hop is specified.
The backup next hop is optional for a P2P link and mandatory for a non-P2P link.
e. Run quit
f. Run ip vpn-instance vpn-instance-name
g. Run ipv4-family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
h. Run ip frr route-policy route-policy-name
IP FRR is enabled for the VPN instance IPv4 address family.
----End

Run the display ip routing-table vpn-instance vpn-instance-name [ ipv4-address ] verbose
command to check the backup next hops and backup outbound interfaces of VPN-IPv4 routes
in the routing table.
8.7.13 Configuring VPN FRR

In the networking of CE dual-homing, you can configure VPN FRR to ensure VPN service
switchover to a secondary link when the primary link between PEs fails.
Before configuring VPN FRR, complete the following tasks:

l Generating two unequal-cost routes on the PE by setting different costs or metrics
Context
VPN FRR is used in PE multi-homing scenarios to enhance network reliability. As shown in
Figure 8-41, if the primary link (Link A) between PE1 and ASBR1 fails, VPN FRR quickly
switches traffic to the backup link (Link B) between PE1 and ASBR2 to minimize the impact
of the link failure on VPN services.
Figure 8-41 VPN FRR networking

ASBR1
CE1
PE1 A
Link
VPN Site AS100
Link B
CE2 ASBR2
You can configure VPN FRR in either of the following modes:

l Manual VPN FRR: Information such as the backup next hop is specified.
l Auto VPN FRR: The backup next hop is unspecified, but a proper next hop is selected
for the VPN route.
You can select either mode as required. If both of them are configured, manual VPN FRR has
a higher priority. When manual VPN FRR fails, auto VPN FRR takes effect.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l Configuring the lsp-trigger command on the P is not recommended when an LSP is created on the
VPN backbone network. Use the default configuration on the P. Otherwise, VPN FRR switchback
may fail.
l To implement fast switching within milliseconds, configure BFD for LSPs. For details about BFD,
see Configuring Static BFD to Detect an LDP LSP, Configuring Dynamic BFD for LDP LSPs and
Configuring Static BFD for TE Tunnels in Huawei
Routers Configuration Guide - MPLS. Perform the BFD configuration based on the tunnel used for
forwarding VPN services.
l In the L3VPN over GRE scenario, the device does not support VPN FRR function.
Perform the following steps on a PE device.
Procedure
l Configure manual VPN FRR.
a. Run system-view
The routing policy node is created and the routing policy view is displayed.
c. Run apply backup-nexthop ip-address
The backup next hop is configured.
d. Run ip vpn-instance vpn-instance-nameipv4-familyvpn frr route-policy route-
policy-name
quit
e. Run
f. Run
g. Run
The VPN FRR is enabled.
l Enable VPN auto FRR using a routing policy.
a. Run system-view
The routing policy node is created and the routing policy view is displayed.
c. Run apply backup-nexthop auto
The auto mode is used.
d. Run ip vpn-instance vpn-instance-nameipv4-familyvpn frr route-policy route-
policy-name
quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

e. Run

f. Run

g. Run
The VPN FRR is enabled.

l (Optional) Add multiple VPNv4 routes to the VPN instance with a different RD from
these routes' RDs.
By default, if the RD of the VPN instance on the local PE is different from the RDs of
the VPN instances on multiple remote PEs, and the RDs of the VPN instances on remote
PEs are the same, the local PE adds only the optimal route to the VPN instance after
receiving VPNv4 or VPNv6 routes with the same destination address from the remote
PEs. As a result, load balancing or VPN FRR does not take effect. To resolve this
problem, run the vpn-route cross multipath command on the local PE.
a. Run system-view


c. Run ipv4-family vpn-instance vpn-instance-name

d. Run vpn-route cross multipath
Multiple VPNv4 routes are added to the VPN instance with a different RD from
these routes' RDs.
l (Optional) Disable VPN FRR in all VPN instances.
To disable VPN FRR in a VPN instance, run the undo vpn frr command in the VPN
instance view. However, if multiple VPN instances are configured on a PE and VPN
FRR is enabled for each VPN instance, it is complex to disable VPN FRR one by one in
these VPN instances.
To address this problem, the device allows you to disable VPN FRR in all VPN instances
using one command.
a. Run system-view

b. Run undo vpn frr all
VPN FRR is disabled from all VPN instances.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

All VPN FRR configurations are complete, run the display ip routing-table vpn-instance
vpn-instance-name [ ip-address ] verbose command to check information about the backup
next-hop PE, backup tunnel, and backup label.
8.7.14 Configuring VPN GR

In the process of active/standby control board switchover or the system upgrade, you can
configure VPN GR to ensure that VPN traffic is not interrupted on the PE, CE, or P device.
Context
In GR process, two roles are defined according to their functions, that is, GR restarter and GR
helper.
l GR restarter: performs active/standby control board switchover or the system upgrade.
l GR helper: helps the GR restarter to implement uninterrupted service forwarding.
NOTE
The AR3260 can function as both the GR restarter and GR helper, and other devices can only function
as the GR helper.
VPN GR is the collection of GR capabilities of various protocols running on devices on VPN

networks. You need to configure IGP GR, BGP GR, MPLS LDP GR, or MPLS TE GR based
on the related protocol running on the GR restarter. You also need to configure neighboring
devices of the GR restarter as the GR helper to help the GR restarter implement uninterrupted
service forwarding.
Configure specified VPN GR on the PE, CE, and P as follows:
l Configure IGP GR, BGP GR and MPLS LDP (or MPLS TE) GR on the PE device.
l Configure IGP GR and the MPLS LDP (or MPLS TE) GR on the P device.
l Configure IGP GR or the BGP GR on the CE device.
l If a VPN spans multiple ASs, you must configure the IGP GR, BGP GR and MPLS LDP
GR on the ASBR.
NOTE
The GR capability cannot ensure uninterrupted traffic forwarding when the neighboring device performs
an active/standby switchover at the same time.
Before configuring VPN GR, complete the following tasks:
l Enabling GR Helper on all the devices on the network
Procedure
l Configure IS-IS GR or OSPF GR.
– For details about how to configure IS-IS GR, see section "Enabling IS-IS GR" in
Huawei
0 Series Enterprise Routers Configuration Guide - IP Routing.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– For details about how to configure OSPF GR, see section "Configuring OSPF GR"
in Huawei
l Configure BGP GR.
– For details about how to configure BGP GR, see section "Configuring the BGP GR
Function" in Huawei
l Configure MPLS LDP GR or MPLS TE GR.
– For details about how to configure MPLS LDP GR, see section "Configuring LDP
GR" in Huawei
0 Series Enterprise Routers Configuration Guide - MPLS.
– For details about how to configure MPLS TE GR, see section "Configuring RSVP
GR" in Huawei
0 Series Enterprise Routers Configuration Guide - MPLS.
----End
8.7.15 Configuring Tunnel Policies

This section describes how to configure a tunnel policy and tunnel selector. By default, VPN
services are transmitted through LSP tunnels. To use TE tunnels to transmit VPN services or
load balance VPN traffic on multiple tunnels, configure a tunnel policy.
Before configuring a tunnel policy, complete the following tasks:
l Creating GRE or LSP or MPLS TE tunnels used to transmit VPN services

NOTE
For details on how to create a GRE tunnel, see GRE Configuration in the Huawei
For details on how to create an LSP tunnel, see MPLS LDP Configuration in the Huawei
For details on how to create a TE tunnel, see MPLS TE Configuration in the Huawei
l Establishing the basic VPN network (For details about BGP/MPLS IP VPN
configuration, see Configuring Basic BGP/MPLS IP VPN Functions)
Before configuring and applying a tunnel selector, complete the following tasks:
l Configuring a tunnel policy (see 8.7.15.1 Configuring and Applying a Tunnel Policy)
l Configuring an RD filter if routes need to be filtered based on RDs
l Configuring an ACL or IPv4 prefix if routes need to be filtered based on the next hop
IPv4 address

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When VPN services need to be transmitted over TE or GRE tunnels, or when multiple tunnels
need to perform load balancing to fully use network resources, complete the task of 8.7.15.1
Configuring and Applying a Tunnel Policy.
To select TE or GRE tunnels to transmitted VPN services in HoVPN, inter-AS VPN Option
B, or inter-AS VPN Option C networking, complete the task of 8.7.15.2 Configuring and
Applying a Tunnel Selector on the SPE, ASBR, and PE devices.
NOTE
By default, if you specify a nonexistent tunnel policy in a command, the command does not take effect.
If you need the nonexistent tunnel policy can be specified in a command, run the tunnel-policy
nonexistent-config-check command.
8.7.15.1 Configuring and Applying a Tunnel Policy
Context
VPN data is transmitted over tunnels. By default, LSP tunnels are used to transmit data, and
each service is transmitted by only one LSP tunnel.
If the default tunnel configuration cannot meet VPN service requirements, apply tunnel
policies to VPNs. You can configure either of the following types of tunnel policies according
to service requirements:
l Tunnel type prioritization policy: This policy can change the type of tunnels selected for
VPN data transmission or select multiple tunnels for load balancing.
l Tunnel binding policy: This policy can bind multiple TE tunnels to provide QoS
guarantee for a VPN.
Perform the following steps on the PE devices that need to use a tunnel policy.
Procedure
Step 1 Configure a tunnel policy.
Use either of the following methods to configure a tunnel policy.
Configure a tunnel type prioritization policy.
By default, no tunnel policy is configured. LSP tunnels are used to transmit VPN data and
each VPN service is transmitted over one LSP tunnel.
1. Run system-view

2. Run tunnel-policy policy-name
A tunnel policy is created, and tunnel policy view is displayed.

3. (Optional) Run description description-information
The description of the tunnel policy is configured.

4. Run tunnel select-seq { gre | lsp | cr-lsp }* load-balance-number load-balance-number

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The sequence in which each type of tunnel is selected and the number of tunnels
participating in load balancing are set.
Configure a tunnel binding policy.
1. Run system-view


3. Run tunnel-protocol mpls te
MPLS TE is configured as a tunnel protocol.

4. Run mpls te reserved-for-binding
The binding capability of the TE tunnel is enabled.

5. Run mpls te commit
The MPLS TE configuration is committed for the configuration to take effect.

6. Run quit

A tunnel policy is created.


9. Run tunnel binding destination dest-ip-address te { tunnel interface-number }
&<1-16> [ ignore-destination-check ] [ down-switch ]
Bind specified TE tunnels in the policy.
NOTE
– If the PE device has multiple peers, you can run the tunnel binding command multiple times
to specify different destination IP addresses in a tunnel policy.
– If down-switch is specified in the command, the system selects available tunnels in an order
of LSP, CR-LSP, and GRE when the bound tunnels are unavailable.
Step 2 Apply the tunnel policy.

1. Run system-view

2. Run ip vpn-instance vpn-instance-name

3. Run ipv4-family

4. Run tnl-policy policy-name
A tunnel policy is applied to the VPN instance IPv4 address family.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

After configuring a tunnel policy and apply it to a VPN instance, you can check information
about the tunnel policy applied to the VPN instance and tunnels in the system.
check information about tunnels in the system.
l Run the display interface tunnel interface-number command to check detailed
information about a specified tunnel interface.
l Run the display tunnel-policy [ tunnel-policy-name ] command to check information
about the specified tunnel policy.
l Run the display ip vpn-instance verbose [ vpn-instance-name ] command to check the
tunnel policy applied to the specified VPN instance.
8.7.15.2 Configuring and Applying a Tunnel Selector
Context
By configuring a tunnel selector, you can set route filtering conditions to iterate expected
routes to the specified tunnels. A tunnel consists of two parts:
l if-match clause: matches an attribute of routes, for example, RD and next hop.
If no if-match clause is configured in a tunnel selector, all routes match the tunnel
selector.
l apply clause: applies a tunnel policy to the routes matching the filtering rules.
After a tunnel selector is applied to routes on a PE, ASBR, or SPE device, the device filters
routes using the specified filtering rules and iterates the matching routes to specified tunnels.
A tunnel selector takes effect for the following routes:

l VPNv4 routes: When a tunnel selector is applied to a BGP-VPNv4 address family on an
SPE device in HoVPN networking or an ASBR in inter-AS VPN Option B networking,
the SPE device or ASBR applies the tunnel policy to VPNv4 routes and iterates the
matching routes to expected tunnels.
l Labeled BGP-IPv4 routes: When a tunnel selector is applied to the BGP-IPv4 unicast
address family on a PE device or an ASBR in inter-AS VPN Option C networking, the
PE device or ASBR applies the tunnel policy to labeled BGP-IPv4 routes.
Procedure
Step 1 Create a tunnel selector.
1. Run system-view

2. Run tunnel-selector tunnel-selector-name { permit | deny } node node
A tunnel selector is created, and tunnel selector view is displayed.

3. (Optional) Configure if-match clauses.
If no if-match clause is configured in a tunnel selector, all routes match the tunnel
selector.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– To configure an if-match clause that filters routes based on router distinguishers

(RDs), run if-match rd-filter rd-filter-number.
– To configure an if-match clause that filters routes based on next-hop IPv4
addresses, run if-match ip next-hop { acl { acl-number | acl-name } | ip-prefix ip-
prefix-name }.
– To configure an if-match clause that filters routes based on next-hop IPv6
addresses, run if-match ipv6 next-hop prefix-list ipv6-prefix-name.
4. Run apply tunnel-policy tunnel-policy-name
An apply clause is configured to specify a tunnel policy for the routes matching the if-
match clause.
Step 2 Apply the tunnel selector.
Perform the following steps on an SPE device in HoVPN networking or an ASBR in inter-AS
VPN Option B networking:
1. Run system-view
4. Run tunnel-selector tunnel-selector-name
The tunnel selector is applied to VPNv4 routes on the local device. The tunnel policy
specified in the apply clause is applied to the VPNv4 routes that matching the if-match
clause. The VPNv4 routes that are filtered out by the if-match clause are iterated to LSP
tunnels.
Step 3 Apply the tunnel selector.
Apply the tunnel selector to VPNv4 routes.
Perform the following steps on an SPE device in HoVPN networking or an ASBR in inter-AS
VPN Option B networking:
1. Run system-view
The tunnel selector is applied to VPNv4 routes on the local device. The tunnel policy
specified in the apply clause is applied to the VPNv4 routes that matching the if-match
clause. The VPNv4 routes that are filtered out by the if-match clause are iterated to LSP
tunnels.
Apply the tunnel selector to labeled BGP-IPv4 routes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Perform the following steps on a PE device or an ASBR in inter-AS VPN Option C

networking:
1. Run system-view


The tunnel selector is applied to labeled BGP-IPv4 routes on the local device.
The tunnel policy specified in the apply clause is applied to the labeled BGP-IPv4 routes
that matching the if-match clause. The labeled BGP-IPv4 routes that are filtered out by
the if-match clause are iterated to LSP tunnels.
----End

After configuring and applying a tunnel selector, run the following commands to check
information about the tunnel selector and tunnel policy specified in the tunnel selector.
l Run the display tunnel-selector tunnel-selector-name command to check detailed

information about the tunnel selector.
l Run the display tunnel-policy tunnel-policy-name command to check information about
the tunnel policy specified by the apply clause in the tunnel selector.
l Run the display bgp vpnv4 all routing-table ipv4-address [ mask [ longer-prefixes ] |
mask-length [ longer-prefixes ] ] command to check tunnels selected for VPNv4 routes
on the ASBR or SPE device.
l Run the display ip routing-table ip-address [ mask | mask-length ] [ longer-match ]
verbose command to check the tunnels selected for labeled BGP-IPv4 routes on the PE
device.
8.7.16 Connecting a VPN to the Internet

Generally, users within a VPN cannot communicate with Internet users because VPN users
cannot access the Internet. If each VPN site needs to access the Internet, configure the
interconnection between the VPN and the Internet.
Step 1, step 2, and step 3 can be performed at any sequence.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure a static route on the CE device.
1. Run system-view
2. Run ip route-static ip-address { mask | mask-length } { interface-type interface-number
[ nexthop-address ] | nexthop-address } [ preference preference | tag tag ] *
The static route to a public network destination address is configured.
ip-address can be a public network address or 0.0.0.0. If the dest-ip-address is 0.0.0.0,
the static route is also called the default route. The mask of a default route must be
0.0.0.0 or the mask-length of the default route must be 0. The out-interface must be the
interface connected directly with the PE device, and the next-hop is the IP address of the
peer PE interface connected directly with the CE device.
NOTE
If the CE and PE devices are connected through an Ethernet network, the next-hop must be
specified.
Step 2 Configure a static VPN route to the Internet on the PE device.

1. Run system-view
2. Run ip route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } nexthop-address public [ preference preference | tag tag ] * [ description text ]
A static route from the VPN to the Internet is configured and the next-hop address is a
public network address.
Step 3 Configure a static route to the VPN on the PE device.
1. Run system-view
2. Run ip route-static ip-address { mask | mask-length } { interface-type interface-number
[ nexthop-address ] | vpn-instance vpn-instance-name nexthop-address | nexthop-
address } [ preference preference | tag tag ] * [ description text ]
The static route from the public network to the VPN is configured and the next-hop
address is a private network address.
NOTE
If the CE and PE devices are connected through an Ethernet network, the next-hop must be
specified.
3. Advertise the static route to the Internet.
For detailed configuration, see the Huawei
Enterprise Routers Configuration Guide - IP Routing. For example, if OSPF is running
between the PE device and the Internet, perform the following steps:
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
b. Run ospf [ process-id ]

c. Run import-route static
Static routes are imported into OSPF.
----End

the VPN routing table on the PE device. The command output shows that the route to the
CE and the route to the destination device in the public network exist in the VPN routing
table.
l Run the display ip routing-table command to check the routing table on the CE and the
destination device in the public network. The command output shows that the CE has the
route to the destination device in the public network and the destination device in the
public network has the route to the CE.
l Run the ping command to check the connectivity between the CE and the destination
device on the public network. The CE device and the destination device on the public
network can ping each other.
8.8 Maintaining BGP/MPLS IP VPN

You can check route summary information in a VPN instance, monitor network connectivity,
and reset BGP connections when maintaining a BGP/MPLS IP VPN network.
8.8.1 Collecting Statistics About L3VPN Traffic
Prerequisites
L3VPN traffic statistics collection is applicable to the interface traffic at the user side of a
VPN. Before collecting L3VPN traffic statistics, you need to enable the L3VPN traffic
statistics function.
NOTE
l Currently, L3VPN traffic statistics collection can count only unicast packets.
l In L3VPN over MPLS TE scenarios, if the device is enabled to collect L3VPN traffic statistics and
traffic statistics on an MPLS TE tunnel interface simultaneously, packets received from the interface
bound to a VPN instance are not counted as L3VPN traffic.
l Enabling L3VPN traffic statistics function may affect the forwarding performance. For example,
when all interfaces provide line-speed forwarding, some interface may be unable to forward packets
at line speed. Exercise caution when you enable traffic statistics on a VLANIF interface.
l L3VPN traffic statistics is unavailable for error packets.
Perform the following steps on the device:
Procedure
Step 1 Run the system-view command to enter the system view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Run the ip vpn-instance vpn-instance-name command to enter the VPN instance view.
Step 3 Run the traffic-statistics enable command to enable the function of collecting statistics about
L3VPN traffic.
----End
8.8.2 Checking L3VPN Traffic

Context
This function displays traffic statistics on the interface at the user side of the VPN. Note that
traffic statistics are collected only after the L3VPN traffic statistics function is enabled.
Procedure
l Run the display traffic-statistics vpn-instance vpn-instance-name command to check
the statistics about L3VPN traffic of a specified VPN instance.
----End
8.8.3 Clearing L3VPN Traffic

Context
Run the following command in the user view to clear L3VPN traffic statistics.
Statistics cannot be restored after being cleared. Therefore, use this command with caution.
Procedure
l Run the reset traffic-statistics vpn-instance { name vpn-instance-name | all }
command in the user view to clear statistics about L3VPN traffic of a specified VPN
instance or all VPN instances.
----End
8.8.4 Displaying BGP/MPLS IP VPN Information
Context
In routine maintenance, you can run the following commands in any view to check the status
of BGP/MPLS IP VPN.
Procedure
l Run the display ip vpn-instance [ verbose ] [ vpn-instance-name ] command to check
information about the VPN instance.
l Run the display default-parameter l3vpn command to check the default configuration
of L3VPN during initialization.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

the IP routing table of a VPN instance.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } routing-table
[ statistics ] label command to check information about labeled routes in the BGP
routing table.
l Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpn-
instance vpn-instance-name } routing-table ipv4-address [ mask | mask-length ]
command to check information about the BGP VPNv4 routing table.
instance vpn-instance-name } routing-table statistics command to check statistics
about the BGP VPNv4 routing table.
instance vpn-instance-name } routing-table command to check information about the
BGP VPNv4 routing table.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ group-
name ] command to check information about the BGP VPNv4 peer group.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } peer [ [ ipv4-
address ] verbose ] command to check BGP VPNv4 peer information.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } network
command to check the routing information advertised by BGP VPNv4.
l Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } paths [ as-
regular-expression ] command to check the AS path information of BGP VPNv4.
l Run the display bgp vpnv4 vpn-instance vpn-instance-name peer { group-name | ipv4-
address } log-info command to check the BGP peer's log information of a specified VPN
instance.
----End
8.8.5 Checking Network Connectivity and Reachability
Context
After completing VPN configuration, you can:
l Run the ping command on the local CE to check whether the local CE and the remote
CE in the same VPN can communicate with each other. If the ping fails, you can run the
tracert command to locate the faulty node.
l Run the ping command with the -vpn-instance vpn-instance-name parameter on the PE
to check whether the PE and the CE in the same VPN as the PE can communicate with
each other. If the ping fails, you can run the tracert command with the -vpn-instance
vpn-instance-name parameter to locate the faulty node.
If multiple interfaces on the PE are bound to the same VPN, you need to specify the source IP
address, that is, the -a source-ip-address when you ping or tracert the remote CE that
accesses the peer PE. If no source IP address is specified, the PE selects the smallest IP
address from the IP addresses of the interfaces on the PE bound to this VPN as the source
address of the Internet Control Message Protocol (ICMP) messages. If the CE has no route to
the selected IPv4 route, the CE discards the returned ICMP message.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
By default, as for the MPLS time to live (MPLS TTL) timeout packet with a single label, the router
returns the ICMP message according to the local IP route (that is, the public network route). However,
no VPN route exists in the public network routing table of the ASBR and therefore, the ICMP message
is discarded when being sent to or returned by the ASBR.
Procedure
l Run the ping [ ip ] [ -a source-ip-address | -c count | -d | -f | -h ttl-value | [ -i interface-
type interface-number | -si source-interface-type source-interface-number ] | -m time | -n
| -name | -p pattern | -q | -r | -s packetsize | -system-time | -t timeout | -tos tos-value | -v |
-vpn-instance vpn-instance-name | ignore-mtu ] * host [ ip-forwarding ] command to
check network connectivity from the local device to a specified destination IP address.
l Run the tracert [ -a source-ip-address | -f first-ttl | -m max-ttl | -name | -p port | -q
nqueries | -vpn-instance vpn-instance-name | -w timeout | -v ] * host command to check
the gateways that a data packet passes when it is sent from the local device to the
destination.
l Run the ping lsp [ -a source-ip | -c count | -exp exp-value | -h ttl-value | -m interval | -r
reply-mode | -s packet-size | -t time-out | -v ] * ip destination-address mask-length [ ip-
address ] [ nexthop nexthop-address | draft6 ] command to check connectivity of a
Label Switched Path (LSP).
l Run the tracert lsp [ -a source-ip | -exp exp-value | -h ttl-value | -r reply-mode | -t time-
out | -v ] * ip destination-address mask-length [ ip-address ] [ nexthop nexthop-address |
draft6 ] command to check the gateways that a data packet passes when it is sent from
the local device to the destination along the LSP.
----End
8.8.6 Viewing the Integrated Route Statistics of IPv4 VPN

Instances
Procedure
l Run the display ip routing-table vpn-instance vpn-instance-name statistics command
to check the integrated route statistics of an IPv4 VPN instance.
l Run the display ip routing-table all-vpn-instance statistics command to check the
integrated route statistics of all IPv4 VPN instances.
----End
8.8.7 Resetting BGP Statistics of a VPN Instance IPv4 Address

Family
Procedure
l Run the reset bgp vpn-instance vpn-instance-name ipv4-family [ ipv4-address ] flap-
info command in the user view to clear statistics of the BGP peer flap for a specified

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the reset bgp vpn-instance vpn-instance-name ipv4-family dampening [ ipv4-

address [ mask | mask-length ] ] command in the user view to clear dampening
information of the VPN instance IPv4 address family.
----End
8.8.8 Resetting BGP Connections
Context
VPN services are interrupted after the BGP connection is reset. Exercise caution when
running the commands.
When the BGP configuration changes, you can use the soft reset or reset BGP connections to
let the new configurations take effect. A soft reset requires that the BGP peers have route
refreshment capability (supporting Route-Refresh messages).
Procedure
l Run the refresh bgp vpn-instance vpn-instance-name ipv4-family { all | ipv4-address |
group group-name | internal | external } import command in the user view to trigger
the inbound soft reset of the VPN instance IPv4 address family's BGP connection.
l Run the refresh bgp vpn-instance vpn-instance-name ipv4-family { all | ipv4-address |
group group-name | internal | external } export command in the user view to trigger
the outbound soft reset of the VPN instance IPv4 address family's BGP connection.
l Run the refresh bgp vpnv4 { all | ipv4-address | group group-name | internal |
external } import command in the user view to trigger the inbound soft reset of the
BGP VPNv4 connection.
l Run the refresh bgp vpnv4 { all | ipv4-address | group group-name | internal |
external } export command in the user view to trigger the outbound soft reset of the
BGP VPNv4 connection.
l Run the reset bgp vpn-instance vpn-instance-name ipv4-family { as-number | ipv4-
address | group group-name | all | internal | external } command in the user view to
reset BGP connections of the VPN instance IPv4 address family.
l Run the reset bgp vpnv4 { as-number | ipv4-address | group group-name | all | internal
| external } command in the user view to reset BGP VPNv4 connections.
----End
8.8.9 Monitoring the Running Status of VPN Tunnels
Context
In routine maintenance, run the following commands in any check to check the tunnel status.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Run the display interface tunnel interface-number command to check information
about a specified tunnel interface.
l Run the display tunnel-info tunnel-id tunnel-id command to check detailed information
about a specified tunnel.
l Run the display tunnel-info all command to check information about all tunnels.
l Run the display tunnel-policy [ tunnel-policy-name ] command to check the
configuration of a tunnel policy.
l Run the display ip vpn-instance verbose [ vpn-instance-name ] command to check
information about the tunnel policy applied to a VPN instance.
l Run the display ip routing-table vpn-instance vpn-instance-name [ ip-address ]
verbose command to check the tunnel to which VPN routes are iterated.
----End
8.9 Configuration Examples for BGP/MPLS IP VPN

This section provides several configuration examples of BGP/MPLS IP VPN networking. In
each configuration example, the networking requirements, configuration roadmap,
configuration procedures, and configuration files are provided.
8.9.1 Example for Configuring BGP/MPLS IP VPN

As shown in Figure 8-42:
l CE1 connects to the headquarters R&D area of a company, and CE3 connects to the
branch R&D area. CE1 and CE3 belong to vpna.
l CE2 connects to the headquarters non-R&D area, and CE4 connects to the branch non-
R&D area. CE2 and CE4 belong to vpnb.
BGP/MPLS IP VPN needs to be deployed for the company to ensure secure communication
between the headquarters and branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-42 Networking diagram for configuring BGP/MPLS IP VPN
AS: 65410 AS: 65430

vpna vpna
GE1/0/0 CE1 CE3

GE1/0/0
10.1.1.1/24 10.3.1.1/24
Loopback1
GE1/0/0 2.2.2.9/32 GE1/0/0
10.1.1.2/24 10.3.1.2/24
PE1 GE1/0/0 GE2/0/0 PE2
Loopback1 172.1.1.2/24 172.2.1.1/24 Loopback1
1.1.1.9/32 GE3/0/0 GE3/0/0 3.3.3.9/32
172.1.1.1/24 P 172.2.1.2/24
GE2/0/0 GE2/0/0
10.2.1.2/24 AS: 100 10.4.1.2/24
VPN Backbone
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
vpnb vpnb
AS: 65420
AS: 65440
1. Configure OSPF between the P and PEs to ensure IP connectivity on the backbone
network.
2. Configure basic MPLS capabilities and MPLS LDP on the P and PEs to set up MPLS
LSP tunnels for VPN data transmission on the backbone network.
3. Configure VPN instances vpna and vpnb on PE1 and PE2. Set the VPN target of vpna to
111:1 and the VPN target of vpnb to 222:2. This configuration allows users in the same
VPN to communicate with each other and isolates users in different VPNs. Bind the
VPN instance to the PE interfaces connected to CEs to provide access for VPN users.
4. Configure MP-IBGP on PE1 and PE2 to enable them to exchange VPN routing
information.
5. Configure EBGP on the CEs and PEs to exchange VPN routing information.
Procedure
Step 1 Configure OSPF on the MPLS backbone network so that the PEs and Ps can communicate
with each other.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure P.
[Huawei] sysname P
[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.9 32
[P-LoopBack1] quit
[P] ospf
[P-ospf-1] area 0
[P-ospf-1] quit
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration is complete, OSPF neighbor relationships can be set up between PE1,
P, and PE2. Run the display ospf peer command. The command output shows that the
neighbor status is Full. Run the display ip routing-table command. The command output
shows that PEs have learned the routes to Loopback1 of each other.
The information displayed on PE1 is used as an example.
[PE1] display ip routing-table
to vpn-instance
------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack1

2.2.2.9/32 OSPF 10 1 D 172.1.1.2
3.3.3.9/32 OSPF 10 2 D 172.1.1.2
172.1.1.0/24 Direct 0 0 D 172.1.1.1
172.1.1.1/32 Direct 0 0 D 127.0.0.1
172.1.1.255/32 Direct 0 0 D 127.0.0.1
172.2.1.0/24 OSPF 10 2 D 172.1.1.2
[PE1] display ospf peer
OSPF Process 1 with Router ID 1.1.1.9

Neighbors
Area 0.0.0.0 interface 172.1.1.1(GigabitEthernet3/0/0)'s neighbors

Router ID: 2.2.2.9 Address: 172.1.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: 172.1.1.1 BDR: 172.1.1.2 MTU: 0
Dead timer due in 37 sec
Retrans timer interval: 5
Neighbor is up for 00:16:21
Authentication Sequence: [ 0 ]
Step 2 Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network to set up
LDP LSPs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls lsr-id 2.2.2.9
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P-GigabitEthernet1/0/0] mpls
[P-GigabitEthernet1/0/0] mpls ldp
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After the configuration is complete, LDP sessions can be set up between PE1 and the P and
between the P and PE2. Run the display mpls ldp session command. The command output
shows that the Status field is Operational. Run the display mpls ldp lsp command.
Information about the established LDP LSPs is displayed.


------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.9:0 Operational DU Active 0000:00:01 6/6
------------------------------------------------------------------------------
[PE1] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal/1024 DS/2.2.2.9
2.2.2.9/32 NULL/3 - 172.1.1.2 GE3/0/0
2.2.2.9/32 1024/3 2.2.2.9 172.1.1.2 GE3/0/0
3.3.3.9/32 NULL/1025 - 172.1.1.2 GE3/0/0
3.3.3.9/32 1025/1025 2.2.2.9 172.1.1.2 GE3/0/0
-------------------------------------------------------------------------------
TOTAL: 5 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is stale
A '*' before a DS means the session is stale
A '*' before a NextHop means the LSP is FRR LSP
Step 3 Configure VPN instances on PEs and bind the instances to the interfaces connected to CEs.
# Configure PE1.
[PE1] ip vpn-instance vpna
[PE1-vpn-instance-vpna] ipv4-family
[PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[PE1-vpn-instance-vpna-af-ipv4] quit
[PE1-vpn-instance-vpna] quit
[PE1] ip vpn-instance vpnb
[PE1-vpn-instance-vpnb] ipv4-family
[PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[PE1-vpn-instance-vpnb] quit
[PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpnb

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE2.
[PE2-vpn-instance-vpnb-af-ipv4] quit
# Assign IP addresses to interfaces on CEs according to Figure 8-42.

# Configure CE1. The configurations of CE2, CE3, and CE4 are similar to the configuration
of CE1, and are not mentioned here.
After the configuration is complete, run the display ip vpn-instance verbose command on
the PEs to check the configuration of VPN instances. Each PE can ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP addresses by setting
-a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address dest-ip-address
command to ping the remote CE. If the source IP address is not specified, the ping operation fails.

[PE1] display ip vpn-instance verbose
Total VPN-Instances configured : 2
Total IPv4 VPN-Instances configured : 2
VPN-Instance Name and ID : vpna, 1

Interfaces : GigabitEthernet1/0/0
Address family ipv4
Create date : 2012/07/25 00:58:17
Up time : 0 days, 22 hours, 24 minutes and 53 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label Policy : label per route
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2

Address family ipv4
Create date : 2012/07/25 00:58:17

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Log Interval : 5
[PE1] ping -vpn-instance vpna 10.1.1.1

0.00% packet loss
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
After the configuration is complete, run the display bgp peer or display bgp vpnv4 all peer
command on the PEs. The command output shows that BGP peer relationships have been
established between the PEs.
[PE1] display bgp peer

Peer V AS MsgRcvd MsgSent OutQ Up/Down

State PrefRcv
3.3.3.9 4 100 12 6 0 00:02:21

Established 0


PrefRcv
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
Step 5 Set up EBGP peer relationships between the PEs and CEs and import VPN routes into BGP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1] bgp 65410

[CE1-bgp] quit
# Configure PE1. The configuration on PE2 is similar to the configuration on PE1 and is not
mentioned here.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpna] import-route direct
[PE1-bgp-vpna] quit
[PE1-bgp] ipv4-family vpn-instance vpnb
[PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[PE1-bgp-vpnb] import-route direct
[PE1-bgp-vpnb] quit
[PE1-bgp] quit
After the configuration is complete, run the display bgp vpnv4 vpn-instance peer command
on the PEs. The command output shows that BGP peer relationships have been established
between the PEs and CEs.
The peer relationship between PE1 and CE1 is used as an example.
[PE1] display bgp vpnv4 vpn-instance vpna peer

VPN-Instance vpna, Router ID 1.1.1.9:


PrefRcv
10.1.1.1 4 65410 6 3 0 00:00:02

Established 4

# Run the display ip routing-table vpn-instance command on the PEs to view the routes to
the remote CEs.
# The information displayed on PE1 is used as an example.
[PE1] display ip routing-table vpn-instance vpna
to vpn-instance
------------------------------------------------------------------------------
Routing Tables: vpna
10.1.1.0/24 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24 IBGP 255 0 RD 3.3.3.9
[PE1] display ip routing-table vpn-instance vpnb
to vpn-instance
------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Routing Tables: vpnb


10.2.1.0/24 Direct 0 0 D 10.2.1.2
10.2.1.2/32 Direct 0 0 D 127.0.0.1
10.2.1.255/32 Direct 0 0 D 127.0.0.1
10.4.1.0/24 IBGP 255 0 RD 3.3.3.9
# CEs in the same VPN can ping each other, whereas CEs in different VPNs cannot.
# For example, CE1 can ping CE3 at 10.3.1.1 but cannot ping CE4 at 10.4.1.1.
[CE1] ping 10.3.1.1
0.00% packet loss
[CE1] ping 10.4.1.1
Request time out
Request time out
Request time out
Request time out
Request time out
100.00% packet loss
----End
Configuration Files
l PE1 configuration file
#
sysname PE1
#
ipv4-family
#
ip vpn-instance vpnb
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

ip address 10.1.1.2 255.255.255.0
#
ip binding vpn-instance vpnb
ip address 10.2.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l P configuration file
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
#
sysname PE2
#
ip vpn-instance
vpna
ipv4-family
#
ip vpn-instance
vpnb
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return
l CE1 configuration file

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE3
#
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.9.2 Example for Configuring BGP/MPLS IP VPNs with

Overlapping Address Spaces
As shown in Figure 8-43:
l CE1 connects to the headquarters R&D area of a company, and CE2 connects to the
branch R&D area. CE1 and CE2 belong to vpna.
l CE3 connects to the headquarters non-R&D area, and CE4 connects to the branch non-
R&D area. CE3 and CE4 belong to vpnb.
l The headquarters and branches use overlapping address spaces.
The company wants to ensure secure communication between the headquarters and branches
and isolate the R&D areas from non-R&D areas, without changing the current network
deployment.
Figure 8-43 Networking diagram for configuring BGP/MPLS IP VPNs with overlapping
address spaces
vpna vpna
CE1 CE2
GE1/0/0 GE1/0/0
14.1.1.2/24 34.1.1.2/24
Loopback0
GE2/0/0 2.2.2.9/32 GE1/0/0
14.1.1.1/24 GE1/0/0 PE2 34.1.1.1/24
GE2/0/0
12.1.1.1/24 23.1.1.1/24
Loopback0 Loopback0
1.1.1.9/32 3.3.3.9/32
GE1/0/0 GE2/0/0
GE3/0/0 PE1 12.1.1.2/24 P 23.1.1.2/24 GE3/0/0
14.1.1.1/24 34.1.1.1/24
VPN Backbone
GE1/0/0 GE1/0/0
14.1.1.2/24 34.1.1.2/24
CE3 CE4
vpnb vpnb

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network.
3. Configure MP-IBGP on PE1 and PE2 to enable them to exchange VPN routing
information.
4. Configure VPN instances vpna and vpnb on PE1 and PE2. Set the VPN target of vpna to
100:100 and the VPN target of vpnb to 200:200. This configuration allows users in the
same VPN to communicate with each other and isolates users in different VPNs. Bind
the VPN instance to the PE interfaces connected to CEs to provide access for VPN users.
5. Configure static routes on the CEs and PEs to exchange VPN routing information.
Procedure
Step 1 Assign IP addresses to interfaces according to Figure 8-43.
# Configure PE1. The configuration on PE2, P, and CE1 to CE4 is similar to the configuration
on PE1 and is not mentioned here.
Step 2 Configure OSPF on the MPLS backbone network so that the PEs and Ps can communicate
with each other.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure P.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1] quit
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration is complete, OSPF neighbor relationships can be set up between PE1,
P, and PE2. Run the display ospf peer command. The command output shows that the

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
neighbor status is Full. Run the display ip routing-table command. The command output
shows that PEs have learned the routes to Loopback0 of each other.
to vpn-instance
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 12.1.1.2
3.3.3.9/32 OSPF 10 2 D 12.1.1.2
12.1.1.0/24 Direct 0 0 D 12.1.1.1
12.1.1.1/32 Direct 0 0 D 127.0.0.1
12.1.1.255/32 Direct 0 0 D 127.0.0.1
23.1.1.0/24 OSPF 10 2 D 12.1.1.2
LDP LSPs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2-mpls-ldp] quit
After the configuration is complete, LDP sessions can be set up between PE1 and the P and
between the P and PE2. Run the display mpls ldp session command. The command output
shows that the Status field is Operational. Run the display mpls ldp lsp command.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal/1024 DS/2.2.2.9
2.2.2.9/32 NULL/3 - 12.1.1.2 GE1/0/0
2.2.2.9/32 1024/3 2.2.2.9 12.1.1.2 GE1/0/0
3.3.3.9/32 NULL/1025 - 12.1.1.2 GE1/0/0
3.3.3.9/32 1025/1025 2.2.2.9 12.1.1.2 GE1/0/0
-------------------------------------------------------------------------------
# Configure PE1.
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100 export-extcommunity
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100 import-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 export-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 import-extcommunity

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE2.
[PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:100 import-extcommunity
[PE2-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 import-extcommunity


Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2

Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Log Interval : 5

0.00% packet loss

# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpna] quit
[PE1-bgp-vpnb] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpna] quit
[PE2-bgp-vpnb] quit
[PE2-bgp] quit
After the configuration is complete, run the display bgp peer command on the PEs. The
command output shows that a BGP peer relationship has been set up between the PEs.
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
3.3.3.9 4 100 3 3 0 00:01:08 Established

0
Step 6 On CE1, CE2, CE3, and CE4, configure static routes to their connected PEs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1] ip route-static 0.0.0.0 0.0.0.0 gigabitethernet 1/0/0 14.1.1.1
# Run the display ip routing-table vpn-instance command on the PEs to view the routes to
the remote CEs.

to vpn-instance
------------------------------------------------------------------------------
14.1.1.0/24 Direct 0 0 D 14.1.1.1

14.1.1.1/32 Direct 0 0 D 127.0.0.1
14.1.1.255/32 Direct 0 0 D 127.0.0.1
34.1.1.0/24 IBGP 255 0 RD 3.3.3.9
[PE1] display ip routing-table vpn-instance vpnb
to vpn-instance
------------------------------------------------------------------------------
Routing Tables: vpnb
14.1.1.0/24 Direct 0 0 D 14.1.1.1

14.1.1.1/32 Direct 0 0 D 127.0.0.1
14.1.1.255/32 Direct 0 0 D 127.0.0.1
34.1.1.0/24 IBGP 255 0 RD 3.3.3.9
# Run the ping 34.1.1.2 command on CE1, and the ping is successful. Run the display
interface command on PE2 to view traffic statistics on GE1/0/0 and GE3/0/0. The command
output shows that there are packets passing through GE1/0/0 but no packet passing through
GE3/0/0. This indicates that the two VPN instances have overlapping address spaces but they
are isolated from each other.
----End
Configuration Files
#
sysname PE1
#
ipv4-family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 12.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 14.1.1.1 255.255.255.0
#
ip address 14.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 12.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 23.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 2.2.2.9 255.255.255.255

#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 23.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return

#
sysname PE2
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 34.1.1.1 255.255.255.0
#
ip address 23.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 34.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 23.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return

#
sysname CE1
#
ip address 14.1.1.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet 1/0/0 14.1.1.1
#
return

#
sysname CE2
#
ip address 34.1.1.2 255.255.255.0
#
#
return

#
sysname CE3
#
ip address 14.1.1.2 255.255.255.0
#
#
return

#
sysname CE4
#
ip address 34.1.1.2 255.255.255.0
#
#
return
8.9.3 Example for Configuring Communication Between Local

VPNs
As shown in Figure 8-44, company A and company B realize communication between their
respective headquarters and branches through BGP/MPLS IP VPN. The network deployment
is as follows:
l CE1 connects to the headquarters of company A, and CE3 connects to the branches of
company A. CE1 and CE3 belong to vpna.
l CE2 connects to the headquarters of company B, and CE4 connects to the branches of
company B. CE2 and CE4 belong to vpnb.
Headquarters of company A and headquarters of company B need to communicate with each

other for business.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-44 Networking diagram for configuring communication between local VPNs
A
A vpna
vpna Site2
Site1
CE1 CE3
GE1/0/0 GE1/0/0
GE1/0/0
10.1.1.2/24 10.3.1.2/24 GE1/0/0
10.1.1.1/24
10.3.1.1/24
IP/MPLS
GE1/0/0 PE1 PE2 GE1/0/0

10.2.1.1/24 10.4.1.1/24
GE2/0/0 GE2/0/0
10.4.1.2/24 CE4
CE2 10.2.1.2/24
B
vpnb B
vpnb
Site1
Site2
1. Configure VPN instances on PE1 and configure different VPN targets for the instances
to isolate VPNs.
2. On PE1, bind the VPN instances to the interfaces connected to CEs to provide access for
VPN users.
3. Import direct routes to the local CEs into the VPN routing table on PE1. On each CE
connected to PE1, configure a static route to the other local CE to enable the CEs to
Procedure
Step 1 # Assign IP addresses to interfaces on CEs according to Figure 8-44.
# Configure CE1. The configuration on CE2 is similar to the configuration on CE1 and is not
mentioned here.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 222:2 import-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 111:1 import-extcommunity
Each PE can ping its connected CE. The information displayed on PE1 and CE1 is used as an
example.


0.00% packet loss
Step 3 Configure BGP and import the direct routes to local CEs to the VPN routing table.
# Configure PE1.
[PE1] bgp 100
[PE1–bgp-vpna] import-route direct
[PE1–bgp-vpna] quit
[PE1–bgp-vpnb] import-route direct
[PE1–bgp-vpnb] quit
[PE1–bgp] quit
Step 4 Configure static routes on the CEs.

# Configure CE1.
[CE1] ip route-static 10.2.1.0 24 10.1.1.2
# Configure CE2.

# After the configuration is complete, run the display ip routing-table vpn-instance vpna
command on PE1. The command output shows that the VPNs have imported routes of each
other. The VPN instance vpna is used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 BGP 255 0 D 10.2.1.2
10.2.1.2/32 BGP 255 0 D 127.0.0.1 InLoopBack0
# CE1 and CE2 can ping each other.

[CE1] ping 10.2.1.1
0.00% packet loss
----End
Configuration Files
#
sysname PE1
#
ipv4-family
vpn-target 111:1 222:2 import-extcommunity
#
ipv4-family
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
bgp 100
#
ipv4-family unicast
#
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
import-route direct
#
return

#
sysname PE2
#
ipv4-family
#
ipv4-family
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.2 255.255.255.0
#
bgp 100
#
ipv4-family unicast
#
import-route direct
#
import-route direct
#
return

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.2
#
return

#
sysname CE3
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.3.1.1 255.255.255.0
#
ip route-static 10.4.1.0 255.255.255.0 10.3.1.2
#
return

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
ip route-static 10.3.1.0 255.255.255.0 10.4.1.2
#
return
8.9.4 Example for Configuring Hub and Spoke

A bank wants to realize secure communication between its headquarters and branches through
MPLS VPN. VPN traffic from branches passes the headquarters so that the headquarters can
monitor the traffic. The Hub and Spoke networking can meet the bank's needs. As shown in
Figure 8-45, the Spoke-CEs connect to branches, and the Hub-CE connects to the
headquarters. All traffic transmitted between Spoke-CEs is forwarded by the Hub-CE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-45 Networking diagram for configuring Hub and Spoke
vpna
AS: 65430
Hub-CE
GE1/0/0 GE2/0/0
110.1.1.1/24 110.2.1.1/24
GE3/0/0 GE4/0/0
110.1.1.2/24 110.2.1.2/24
Hub-PE
GE1/0/0 GE2/0/0
10.1.1.2/24 11.1.1.2/24
Loopback1
Loopback1 2.2.2.9/32 Loopback1
1.1.1.9/32 3.3.3.9/32
Spoke-PE1 GE2/0/0 GE2/0/0

Spoke-PE2
10.1.1.1/24 11.1.1.1/24
GE1/0/0 VPN Backbone GE1/0/0

100.1.1.2/24 AS100 120.1.1.2/24
GE1/0/0 GE1/0/0
100.1.1.1/24 120.1.1.1/24
Spoke-CE1 Spoke-CE2
AS: 65410 AS: 65420
vpna vpna
1. Configure an IGP protocol on the backbone network to enable the Hub-PE and Spoke-
PEs to communicate with each other.
2. Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up
LDP LSPs.
3. Set up MP-IBGP peer relationships between the Hub-PE and the Spoke-PEs. The Spoke-
PEs do not need to set up an MP-IBGP peer relationship or exchange VPN routing
information.
4. Create two VPN instances on the Hub-PE. One is used to receive routes from Spoke-
PEs, and the other is used to advertise routes to the Spoke-PEs. Set import target of the
first VPN instance to 100:1 and the export target of the other VPN instance to 200:1.
5. Create a VPN instance on the Spoke-PEs. Set the export target of the VPN instance to
100:1 and the import target to 200:1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6. Configure EBGP on the CEs and PEs to enable them to exchange VPN routing
information. Configure Hub-PE to allow Hub-PE to receive the route with the AS
repeated for one time.
Procedure
Step 1 Configure OSPF on the backbone network to enable the Hub-PE and Spoke-PEs to
# Configure Spoke-PE1. The configuration on the Hub-PE and Spoke-PE2 is similar to the
configuration on Spoke-PE1 and is not mentioned here.
[Huawei] sysname Spoke-PE1
[Spoke-PE1] interface loopback 1
[Spoke-PE1-LoopBack1] ip address 1.1.1.9 32
[Spoke-PE1-LoopBack1] quit
[Spoke-PE1] interface gigabitethernet 2/0/0
[Spoke-PE1-GigabitEthernet2/0/0] ip address 10.1.1.1 24
[Spoke-PE1-GigabitEthernet2/0/0] quit
[Spoke-PE1] ospf 1
[Spoke-PE1-ospf-1] area 0
[Spoke-PE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[Spoke-PE1-ospf-1-area-0.0.0.0] quit
[Spoke-PE1-ospf-1] quit
After the configuration is complete, Hub-PE can establish OSPF neighbor relationships with
the Spoke-PEs. Run the display ospf peer command on the PEs. The command output shows
that the status of OSPF neighbor relationships is Full. Run the display ip routing-table
command. The command output shows that the Hub-PE and the Spoke-PEs have learned the
route to the loopback interface of each other.
Step 2 Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up LDP
LSPs.
# Configure the Hub-PE. The configuration on the Spoke-PEs is similar to the configuration
on the Hub-PE and is not mentioned here.
[Hub-PE] mpls lsr-id 2.2.2.9
[Hub-PE] mpls
[Hub-PE-mpls] label advertise non-null
[Hub-PE-mpls] quit
[Hub-PE] mpls ldp
[Hub-PE-mpls-ldp] quit
[Hub-PE] interface gigabitethernet 1/0/0
[Hub-PE-GigabitEthernet1/0/0] mpls
[Hub-PE-GigabitEthernet1/0/0] mpls ldp
[Hub-PE-GigabitEthernet1/0/0] quit
[Hub-PE-GigabitEthernet2/0/0] mpls
[Hub-PE-GigabitEthernet2/0/0] mpls ldp
After the configuration is complete, the Hub-PE can set up LDP peer relationships with the
Spoke-PEs. Run the display mpls ldp session command on the PEs. In the command output,
the state is Operational. Run the display mpls ldp lsp command. Information about the
established LDP LSPs is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
The import target of the VPN instances on the Hub-PE is the export target of the VPN instance on the
Spoke-PEs. The import target and export target on the Hub-PE are different. The import VPN target on
the Spoke-PEs is the export VPN target on the Hub-PE.
# Configure Spoke-PE1.
[Spoke-PE1] ip vpn-instance vpna

[Spoke-PE1-vpn-instance-vpna] ipv4-family
[Spoke-PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:1 export-extcommunity
[Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 200:1 import-extcommunity
[Spoke-PE1-vpn-instance-vpna-af-ipv4] quit
[Spoke-PE1-vpn-instance-vpna] quit
[Spoke-PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
#Configure Spoke-PE2.
[Spoke-PE2] ip vpn-instance vpna

[Spoke-PE2-vpn-instance-vpna] ipv4-family
[Spoke-PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 100:3
[Spoke-PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:1 export-extcommunity
[Spoke-PE2-vpn-instance-vpna-af-ipv4] vpn-target 200:1 import-extcommunity
[Spoke-PE2-vpn-instance-vpna-af-ipv4] quit
[Spoke-PE2-vpn-instance-vpna] quit
[Spoke-PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
# Configure the Hub-PE.
[Hub-PE] ip vpn-instance vpn_in

[Hub-PE-vpn-instance-vpn_in] ipv4-family
[Hub-PE-vpn-instance-vpn_in-af-ipv4] route-distinguisher 100:21
[Hub-PE-vpn-instance-vpn_in-af-ipv4] vpn-target 100:1 import-extcommunity
[Hub-PE-vpn-instance-vpn_in-af-ipv4] quit
[Hub-PE-vpn-instance-vpn_in] quit
[Hub-PE] ip vpn-instance vpn_out
[Hub-PE-vpn-instance-vpn_out] ipv4-family
[Hub-PE-vpn-instance-vpn_out-af-ipv4] route-distinguisher 100:22
[Hub-PE-vpn-instance-vpn_out-af-ipv4] vpn-target 200:1 export-extcommunity
[Hub-PE-vpn-instance-vpn_out-af-ipv4] quit
[Hub-PE-vpn-instance-vpn_out] quit
[Hub-PE-GigabitEthernet3/0/0] ip binding vpn-instance vpn_in
[Hub-PE-GigabitEthernet3/0/0] ip address 110.1.1.2 24
[Hub-PE-GigabitEthernet4/0/0] ip binding vpn-instance vpn_out
[Hub-PE-GigabitEthernet4/0/0] ip address 110.2.1.2 24

# Configure Spoke-CE1. The configuration on other CEs is similar to the configuration on
Spoke-CE1 and is not mentioned here.
[Huawei] sysname Spoke-CE1
[Spoke-CE1] interface gigabitethernet 1/0/0
[Spoke-CE1-GigabitEthernet1/0/0] ip address 100.1.1.1 24
[Spoke-CE1-GigabitEthernet1/0/0] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
the PEs to check the configuration of VPN instances. Each PE can ping its connected CE by
using the ping -vpn-instance vpn-name ip-address command.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you need to specify the source IP
addresses by setting -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-
address dest-ip-address command to ping the remote CE. If the source IP address is not specified, the
ping operation fails.
NOTE
To accept the routes advertised by Hub-CE, configure the Hub-PE to allow AS number to be repeated
once.
# Configure Spoke-CE1.
[Spoke-CE1] bgp 65410
[Spoke-CE1-bgp] peer 100.1.1.2 as-number 100
[Spoke-CE1-bgp] import-route direct
[Spoke-CE1-bgp] quit
[Spoke-PE1] bgp 100
[Spoke-PE1-bgp] ipv4-family vpn-instance vpna
[Spoke-PE1-bgp-vpna] peer 100.1.1.1 as-number 65410
[Spoke-PE1-bgp-vpna] import-route direct
[Spoke-PE1-bgp-vpna] quit
[Spoke-PE1-bgp] quit
# Configure Spoke-CE2.
[Spoke-CE2] bgp 65420
[Spoke-CE2-bgp] peer 120.1.1.2 as-number 100
[Spoke-CE2-bgp] import-route direct
[Spoke-CE2-bgp] quit
[Spoke-PE2] bgp 100
[Spoke-PE2-bgp] ipv4-family vpn-instance vpna
[Spoke-PE2-bgp-vpna] peer 120.1.1.1 as-number 65420
[Spoke-PE2-bgp-vpna] import-route direct
[Spoke-PE2-bgp-vpna] quit
# Configure the Hub-CE.

[Hub-CE] bgp 65430
[Hub-CE-bgp] peer 110.1.1.2 as-number 100
[Hub-CE-bgp] peer 110.2.1.2 as-number 100
[Hub-CE-bgp] import-route direct
[Hub-CE-bgp] quit

[Hub-PE] bgp 100
[Hub-PE-bgp] ipv4-family vpn-instance vpn_in
[Hub-PE-bgp-vpn_in] peer 110.1.1.1 as-number 65430
[Hub-PE-bgp-vpn_in] import-route direct
[Hub-PE-bgp-vpn_in] quit
[Hub-PE-bgp] ipv4-family vpn-instance vpn_out
[Hub-PE-bgp-vpn_out] peer 110.2.1.1 as-number 65430
[Hub-PE-bgp-vpn_out] peer 110.2.1.1 allow-as-loop 1
[Hub-PE-bgp-vpn_out] import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Hub-PE-bgp-vpn_out] quit
[Hub-PE-bgp] quit
After the configuration is complete, run the display bgp vpnv4 all peer command on the
PEs. The command output shows that the BGP peer relationships have been set up between
the PEs and CEs and are in Established state.
Step 5 Set up MP-IBGP peer relationships between the Spoke-PEs and Hub-PE.
NOTE
The Spoke-PEs do not need to allow the repeated AS number, because the router does not check the
AS_Path attribute in the routing information advertised by the IBGP peers.
[Spoke-PE1] bgp 100
[Spoke-PE1-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE1-bgp] peer 2.2.2.9 connect-interface loopback 1
[Spoke-PE1-bgp] ipv4-family vpnv4
[Spoke-PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE1-bgp-af-vpnv4] quit
[Spoke-PE2] bgp 100

[Hub-PE] bgp 100
[Hub-PE-bgp] peer 1.1.1.9 as-number 100
[Hub-PE-bgp] peer 1.1.1.9 connect-interface loopback 1
[Hub-PE-bgp] peer 3.3.3.9 as-number 100
[Hub-PE-bgp] peer 3.3.3.9 connect-interface loopback 1
[Hub-PE-bgp] ipv4-family vpnv4
[Hub-PE-bgp-af-vpnv4] peer 1.1.1.9 enable
[Hub-PE-bgp-af-vpnv4] peer 3.3.3.9 enable
[Hub-PE-bgp-af-vpnv4] quit
command on the PEs. The command output shows that the BGP peer relationships have been
set up between the Spoke-PEs and the Hub-PE and are in Established state.
# After the configuration is complete, the Spoke-CEs can ping each other. Run the tracert
command on the CEs. The command output shows that the traffic between the Spoke-CEs is
forwarded through the Hub-CE. You can also deduce the number of forwarding devices
between the Spoke-CEs based on the TTL in the ping result.
# The information displayed on Spoke-CE1 is used as an example.
[Spoke-CE1] ping 120.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss

[Spoke-CE1] tracert 120.1.1.1
traceroute to 120.1.1.1(120.1.1.1), max hops: 30 ,packet length: 40,press CTRL
_C to break
1 100.1.1.2 10 ms 2 ms 1 ms
2 110.2.1.2 < AS=100 > 10 ms 2 ms 2 ms
3 110.2.1.1 < AS=100 > 10 ms 2 ms 2 ms
4 110.1.1.2 < AS=65430 > 10 ms 2 ms 2 ms
5 120.1.1.2 < AS=100 > 10 ms 2 ms 2 ms
6 120.1.1.1 < AS=100 > 10 ms 2 ms 5 ms
# Run the display bgp routing-table command on the Spoke-CEs. The command output
shows the repeated AS number in AS paths of the BGP routes to the remote Spoke-CE.
# The information displayed on Spoke-CE1 is used as an example.
[Spoke-CE1] display bgp routing-table
BGP Local router ID is 100.1.1.1

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 8

Network NextHop MED LocPrf PrefVal Path/Ogn
*> 100.1.1.0/24 0.0.0.0 0 0 ?

100.1.1.2 0 0 100?
*> 100.1.1.1/32 0.0.0.0 0 0 ?
*> 110.1.1.0/24 100.1.1.2 0 100 65430?
*> 110.2.1.0/24 100.1.1.2 0 100?
*> 120.1.1.0/24 100.1.1.2 0 100 65430
100?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
----End
Configuration Files
l Spoke-CE1 configuration file
#
sysname Spoke-CE1
#
ip address 100.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
l Spoke-PE1 configuration file

#
sysname Spoke-PE1
#
ipv4-family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls lsr-id 1.1.1.9
mpls
label advertise non-null
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
sysname Spoke-PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 120.1.1.2 255.255.255.0
#
ip address 11.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 11.1.1.0 0.0.0.255
#
return
l Spoke-CE2 configuration file
#
sysname Spoke-CE2
#
ip address 120.1.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
l Hub-CE configuration file
#
sysname Hub-CE
#
ip address 110.1.1.1 255.255.255.0
#
ip address 110.2.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
l Hub-PE configuration file
#
sysname Hub-PE
#
ip vpn-instance vpn_in
ipv4-family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip vpn-instance vpn_out
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 11.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance vpn_in
ip address 110.1.1.2 255.255.255.0
#
ip binding vpn-instance vpn_out
ip address 110.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn_in
import-route direct
#
ipv4-family vpn-instance vpn_out
peer 110.2.1.1 allow-as-loop
import-route direct
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 11.1.1.0 0.0.0.255
#
return
8.9.5 Example for Configuring Inter-AS VPN Option A

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The headquarters and branches of a company connect to networks of different carriers. To
enable the headquarters and branches to communicate, Inter-AS BGP/MPLS IP VPN needs to
be implemented. As shown in Figure 8-46, CE1 is located in the headquarters and connects to
PE1 in AS 100. CE2 is located at the branch and connects to PE2 in AS 200. Both CE1 and
CE2 belong to vpn1.
Figure 8-46 Networking diagram for configuring inter-AS VPN Option A
VPN Backbone VPN Backbone

AS 100 Loopback1 Loopback1 AS 200
2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE2/0/0
192.1.1.1/24 192.1.1.2/24
GE1/0/0 GE1/0/0
172.1.1.1/24 ASBR-PE1 ASBR-PE2 162.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0
172.1.1.2/24 162.1.1.2/24
PE1 PE2
GE2/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
CE1 CE2
10.1.1.1/24 10.2.1.1/24
vpn1 vpn1
AS 65001 AS 65002
Inter-AS Option A can be deployed to meet the company's requirement. The configuration
roadmap is as follows:
1. On the MPLS backbone network in AS 100 and AS 200, configure an IGP protocol to
enable the PE and ASBR-PEs to communicate with each other.
2. Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network to
set up LDP LSPs.
3. Set up an MP-IBGP peer relationship between the PE and ASBR-PEs in each AS to
exchange VPN routing information.
4. Create a VPN instance on the PE in each AS and bind the VPN instance to the interface
connected to the CE.
5. Set up an EBGP peer relationship between the PEs and CEs in each AS to exchange

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
6. Create a VPN instance on each ASBR-PE and bind the instance to the interface
connected to the other ASBR-PE (regarding the ASBR-PE as its CE). Set up an EBGP
peer relationship between the ASBR-PEs to exchange VPN routing information.
Procedure
# Configure PE1. The configuration on PE2, CE1, CE2, ASBR-PE1, and ASBR-PE2 is
similar to the configuration on PE1 and is not mentioned here.
Step 2 On the MPLS backbone network in AS 100 and AS 200, configure OSPF to enable the PEs
and the ASBR-PEs to communicate with each other.
# Configure PE1. The configuration on PE2 and ASBR-PEs is similar to the configuration on
PE1 and is not mentioned here.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
NOTE
The 32-bit loopback interface address used as LSR ID should be advertised by the PEs and ASBR-PEs
using OSPF.
After the configuration is complete, the ASBR-PEs and PEs in the same AS can set up an
OSPF neighbor relationship. Run the display ospf peer command to verify that the status of
the neighbor relationship is Full. Run the display ip routing-table command. The command
output shows that the ASBR and PEs in the same AS have learned the routes to Loopback1 of
each other.
Step 3 Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network of AS
100 and AS 200 to set up LDP LSPs.
# Configure basic MPLS capabilities on PE1 and enable LDP on the interface connected to
ASBR-PE1.

[PE1] mpls
[PE1-mpls] label advertise non-null
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure basic MPLS capabilities on ASBR-PE1 and enable LDP on the interface
connected to PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[ASBR-PE1] mpls lsr-id 2.2.2.9

[ASBR-PE1] mpls
[ASBR-PE1-mpls] label advertise non-null
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1-mpls-ldp] quit
[ASBR-PE1] interface gigabitethernet 1/0/0
[ASBR-PE1-GigabitEthernet1/0/0] mpls
[ASBR-PE1-GigabitEthernet1/0/0] mpls ldp
[ASBR-PE1-GigabitEthernet1/0/0] quit
connected to PE2.

[ASBR-PE2] mpls
[ASBR-PE2-mpls] label advertise non-null
[ASBR-PE2] mpls ldp
ASBR-PE2.

[PE2] mpls
[PE2-mpls] label advertise non-null
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, the PE and ASBR-PEs in the same AS can set up an LDP
peer relationship. Run the display mpls ldp session command on the PE and ASBR-PEs to
verify that the state is Operational.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Set up an MP-IBGP peer relationship between the PE and ASBR-PEs in each AS to exchange
# On PE1: set up an MP-IBGP peer relationship with ASBR-PE1. The configuration on PE2
is similar to the configuration on PE1 and is not mentioned here.
[PE1] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-bgp] quit
# On ASBR-PE1: set up an MP-IBGP peer relationship with PE1. The configuration on

ASBR-PE2 is similar to the configuration on ASBR-PE1 and is not mentioned here.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] peer 1.1.1.9 as-number 100
[ASBR-PE1-bgp] peer 1.1.1.9 connect-interface loopback 1
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpnv4] peer 1.1.1.9 enable
[ASBR-PE1-bgp-af-vpnv4] quit
[ASBR-PE1-bgp] quit
Step 5 On the PEs, create a VPN instance, enable the IPv4 address family in the instance, and bind
the instance to the interfaces connected to CEs.
NOTE
The VPN targets of the VPN instances on the ASBR-PE and PEs in an AS must match. In different ASs,
the VPN targets of the PEs do not need to match.
mentioned here.
Step 6 Set up EBGP peer relationships between the PEs and CEs to exchange VPN routing
information.
mentioned here.

[CE1] bgp 65001
[CE1-bgp] quit
mentioned here.
[PE1] bgp 100

[PE1-bgp-vpn1] quit
[PE1-bgp] quit
After the configuration is complete, run the display bgp vpnv4 vpn-instance vpn-instanc-
ename peer command on the PEs. The command output shows that the BGP peer
relationships have been set up between the PEs and CEs and are in Established state. Run the
display bgp vpnv4 all peer command on the PEs. The command output shows that each PE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
has set up a BGP peer relationship with the CE and ASBR-PEs in the same AS, and the BGP
peer relationships are in Established state.



PrefRcv
10.1.1.1 4 65001 5 4 0 00:00:01 Established 3



PrefRcv
2.2.2.9 4 100 11 11 0 00:07:09 Established 0

10.1.1.1 4 65001 5 4 0 00:00:12 Established 3
Step 7 Configure Inter-AS VPN Option A.

# On ASBR-PE1, create a VPN instance and bind the VPN instance to the interface connected
to ASBR-PE2 (ASBR-PE1 considers ASBR-PE2 as its CE).
[ASBR-PE1] ip vpn-instance vpn1
[ASBR-PE1-vpn-instance-vpn1] ipv4-family
[ASBR-PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[ASBR-PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[ASBR-PE1-vpn-instance-vpn1-af-ipv4] quit
[ASBR-PE1-vpn-instance-vpn1] quit
[ASBR-PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[ASBR-PE1-GigabitEthernet2/0/0] ip address 192.1.1.1 24
# On ASBR-PE2, create a VPN instance and bind the VPN instance to the interface connected
to ASBR-PE1 (ASBR-PE2 considers ASBR-PE1 as its CE).
[ASBR-PE2] ip vpn-instance vpn1
[ASBR-PE2-vpn-instance-vpn1] ipv4-family
[ASBR-PE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 200:2
[ASBR-PE2-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both
[ASBR-PE2-vpn-instance-vpn1-af-ipv4] quit
[ASBR-PE2-vpn-instance-vpn1] quit
[ASBR-PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
# On ASBR-PE1, set up an EBGP peer relationship with ASBR-PE2.

[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] ipv4-family vpn-instance vpn1
[ASBR-PE1-bgp-vpn1] peer 192.1.1.2 as-number 200
[ASBR-PE1-bgp-vpn1] import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[ASBR-PE1-bgp-vpn1] quit
[ASBR-PE1-bgp] quit
# On ASBR-PE2, set up an EBGP peer relationship with ASBR-PE1.

[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] ipv4-family vpn-instance vpn1
[ASBR-PE2-bgp-vpn1] peer 192.1.1.1 as-number 100
[ASBR-PE2-bgp-vpn1] import-route direct
[ASBR-PE2-bgp-vpn1] quit
[ASBR-PE2-bgp] quit
Run the display bgp vpnv4 vpn-instance vpn1 peer command on the ASBR-PEs. The
command output shows that a BGP peer relationship has been established between the ASBR-
PEs and is in Established state.
# After the configuration is complete, CE1 and CE2 learn routes to interfaces on each other
and can ping each other successfully.
# The information displayed on CE1 is used as an example.
[CE1] display ip routing-table
to vpn-instance
------------------------------------------------------------------------------
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
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2
192.1.1.0/24 EBGP 255 0 D 10.1.1.2
[CE1] ping 10.2.1.1
0.00% packet loss
# Run the display ip routing-table vpn-instance command on an ASBR-PE to check the

VPN routing table.
[ASBR-PE1] display ip routing-table vpn-instance vpn1
to vpn-instance
------------------------------------------------------------------------------
Routing Tables: vpn1
10.1.1.0/24 IBGP 255 0 RD 1.1.1.9

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
10.2.1.0/24 EBGP 255 0 D 192.1.1.2
192.1.1.0/24 Direct 0 0 D 192.1.1.1
192.1.1.1/32 Direct 0 0 D 127.0.0.1
192.1.1.255/32 Direct 0 0 D 127.0.0.1
# Run the display bgp vpnv4 all routing-table command on an ASBR-PE to check the
VPNv4 routes.
[ASBR-PE1] display bgp vpnv4 all routing-table

Total number of routes from all PE: 5

Route Distinguisher: 100:1
*>i 10.1.1.0/24 1.1.1.9 0 100 0 ?
*> 10.2.1.0/24 192.1.1.2 0 200?

*> 192.1.1.0 0.0.0.0 0 0 ?
* 192.1.1.2 0 0 200?
*> 192.1.1.1/32 0.0.0.0 0 0 ?

*>i 10.1.1.0/24 1.1.1.9 0 100 0 ?

*> 10.2.1.0/24 192.1.1.2 0 200?
*> 192.1.1.0 0.0.0.0 0 0 ?
192.1.1.2 0 0 200?
*> 192.1.1.1/32 0.0.0.0 0 0 ?
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65001
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipv4-family unicast
import-route direct
#
return
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l ASBR-PE1 configuration file
#
sysname ASBR-PE1
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
mpls ldp
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
import-route direct
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname ASBR-PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return

#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 162.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65002
#
ipv4-family unicast
import-route direct
#
return
8.9.6 Example for Configuring Inter-AS VPN Option B
CE2 belong to vpn1.
Figure 8-47 Networking diagram for configuring inter-AS VPN Option B

2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE2/0/0
192.1.1.1/24 192.1.1.2/24
GE1/0/0 GE1/0/0
172.1.1.1/24 ASBR-PE1 ASBR-PE2 162.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0
172.1.1.2/24 162.1.1.2/24
PE1 PE2
GE2/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
CE1 CE2
10.1.1.1/24 10.2.1.1/24
vpn1 vpn1
AS 65001 AS 65002

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Inter-AS Option B can be deployed to meet the company's requirement. The configuration
set up LDP LSPs.
5. Set up an EBGP peer relationship between the PEs and CEs between the ASs to
6. Enable MPLS on the interfaces connecting the ASBRs and set up an MP-EBGP peer
relationship between the ASBRs. Configure the ASBRs not to filter received VPNv4
routes based on VPN targets.
Procedure
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
NOTE
using OSPF.
After the configuration is complete, the ASBR and PEs in the same AS can set up an OSPF
neighbor relationship. Run the display ospf peer command to verify that the status of the
neighbor relationship is Full. Run the display ip routing-table command. The command
each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ASBR-PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
connected to PE1.

[ASBR-PE1] mpls
[ASBR-PE1] mpls ldp
connected to PE2.

[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
ASBR-PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Set up an MP-IBGP peer relationship between the PE and ASBR-PEs in each AS to exchange
[PE1] bgp 100
[PE1-bgp] quit

[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] quit
NOTE
mentioned here.
information.
mentioned here.

[CE1] bgp 65001

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[CE1-bgp] quit
# Configure PE1. The configuration on PE2 is similar to the configuration PE1 and is not
mentioned here.
[PE1] bgp 100

[PE1-bgp-vpn1] quit
[PE1-bgp] quit
After the configuration is complete, run the display bgp vpnv4 vpn-instance vpn-
instancename peer command on the PEs. The command output shows that the BGP peer



PrefRcv
10.1.1.1 4 65001 965 967 0 16:00:58

Established 3


PrefRcv
2.2.2.9 4 100 979 974 0 16:08:16

Established 0

10.1.1.1 4 65001 966 968 0 16:01:19
Established 3
Step 7 Configure Inter-AS VPN Option B.

# On ASBR-PE1: Enable MPLS on the interface connected to ASBR-PE2.
# On ASBR-PE1: set up the MP-EBGP peer relationship with ASBR-PE2, disable ASBR-
PE1 from filtering VPNv4 routes based on VPN targets, and enable next-hop-based label
allocation. The configuration on ASBR–PE2 is similar to the configuration on ASBR–PE1
and is not mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[ASBR-PE1] bgp 100

[ASBR-PE1-bgp-af-vpnv4] undo policy vpn-target
[ASBR-PE1-bgp-af-vpnv4] apply-label per-nexthop
[ASBR-PE1-bgp] quit

to vpn-instance
------------------------------------------------------------------------------
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
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2
[CE1] ping 10.2.1.1
0.00% packet loss
# Run the display bgp vpnv4 all routing-table command on an ASBR-PE to check the
VPNv4 routes.
[ASBR-PE1] display bgp vpnv4 all routing-table


*>i 10.1.1.0/24 1.1.1.9 0 100 0 ?

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
*> 10.2.1.0/24 192.1.1.2 0 200?
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65001
#
ipv4-family unicast
import-route direct
#
return

#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
apply-label per-nexthop
peer 1.1.1.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.2 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
apply-label per-nexthop
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 162.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65002
#
ipv4-family unicast
import-route direct
#
return
8.9.7 Example for Configuring Inter-AS VPN Option C (Solution

1)
CE2 belong to vpn1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-48 Networking diagram for configuring inter-AS VPN Option C

2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE2/0/0
192.1.1.1/24 192.1.1.2/24
GE1/0/0 GE1/0/0
172.1.1.1/24 ASBR-PE1 ASBR-PE2 162.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0
172.1.1.2/24 162.1.1.2/24
PE1 PE2
GE2/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
CE1 CE2
10.1.1.1/24 10.2.1.1/24
vpn1 vpn1
AS 65001 AS 65002
Inter-AS Option C can be deployed to meet the company's requirement. The configuration
set up LDP LSPs.
exchange the labeled IPv4 routes.
6. Enable the capability of exchanging labeled IPv4 routes between the local ASBR-PE and
the remote ASBR-PE.
7. Set up an MP-EBGP relationship between PEs in different ASs and set the maximum
hops between the PEs.
8. Configure a routing policy on the ASBR-PE: Assign MPLS labels to the routes
advertised to the emote ASBR-PE; assign new MPLS labels to the labeled IPv4 routes
advertised to the PE in the local AS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
NOTE
using OSPF.
each other.
ASBR-PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
connected to PE1.

[ASBR-PE1] mpls
[ASBR-PE1] mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

connected to PE2.

[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
ASBR-PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Set up an MP-IBGP peer relationship between the PE and ASBR-PEs.

[PE1] bgp 100
[PE1-bgp] quit

[ASBR-PE1] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[ASBR-PE1-bgp] quit
NOTE
mentioned here.
information.
mentioned here.

[CE1] bgp 65001
[CE1-bgp] quit
mentioned here.
[PE1] bgp 100

[PE1-bgp-vpn1] quit
[PE1-bgp] quit


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


PrefRcv
10.1.1.1 4 65001 1043 1048 0 17:17:21

Established 2


PrefRcv
2.2.2.9 4 100 59 52 0 00:45:16

Established 0

10.1.1.1 4 65001 1045 1050 0 17:19:21
Established 2
Step 7 Enable the capability of exchanging labeled IPv4 routes.

# On PE1: Enable the capability of exchanging labeled IPv4 routes with ASBR-PE1. The
configuration on PE2 is similar to the configuration on PE1 and is not mentioned here.
[PE1] bgp 100
[PE1-bgp] peer 2.2.2.9 label-route-capability
[PE1-bgp] quit
# On ASBR-PE1: Enable MPLS on the interface connected to ASBR-PE2. The configuration

on ASBR-PE2 is similar to the configuration on ASBR-PE1 and is not mentioned here.
# On ASBR-PE1: Create a routing policy. The configuration on ASBR-PE2 is similar to the

configuration on ASBR-PE1 and is not mentioned here.
[ASBR-PE1] route-policy policy1 permit node 1
[ASBR-PE1-route-policy] apply mpls-label
[ASBR-PE1-route-policy] quit
[ASBR-PE1-route-policy] if-match mpls-label
# On ASBR-PE1: Apply a routing policy to the routes advertised to PE1, and enable the
capability of exchanging labeled IPv4 routes with PE1. The configuration on ASBR-PE2 is
similar to the configuration on ASBR-PE1 and is not mentioned here.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] peer 1.1.1.9 route-policy policy2 export
[ASBR-PE1-bgp] peer 1.1.1.9 label-route-capability
# On ASBR-PE1: Apply a routing policy to the routes advertised to ASBR-PE2, and enable
the capability of exchanging labeled IPv4 routes with ASBR-PE2.
[ASBR-PE1-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# On ASBR-PE1: Advertise routes to loopback interfaces to ASBR-PE2, and then to PE2.

The configuration on ASBR-PE2 is similar to the configuration on ASBR-PE1 and is not
mentioned here.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] network 1.1.1.9 32
[ASBR-PE1-bgp] quit
Step 8 Set up an MP-EBGP peer relationship between PE1 and PE2.

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 4.4.4.9 connect-interface LoopBack 1
[PE1-bgp] peer 4.4.4.9 ebgp-max-hop 10
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit

to vpn-instance
------------------------------------------------------------------------------
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
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2
[CE1] ping 10.2.1.1


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss

# No VPNv4 route exists on ASBR-PEs. Run the display bgp routing-table label command
on an ASBR-PE to check information about labels of routes.
# ASBR-PE1 is used as an example.
[ASBR-PE1] display bgp routing-table label

Network NextHop In/Out Label
*> 1.1.1.9 172.1.1.2 1098/NULL

*> 4.4.4.9 192.1.1.2 1099/1067
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65001
#
ipv4-family unicast
import-route direct
#
return

#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 4.4.4.9 ebgp-max-hop 10
#
ipv4-family unicast
peer 2.2.2.9 enable
peer 2.2.2.9 label-route-capability
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
peer 4.4.4.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 1.1.1.9 255.255.255.255
peer 192.1.1.2 route-policy policy1 export
peer 1.1.1.9 enable
#
ipv4-family vpnv4

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
policy vpn-target
peer 1.1.1.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
route-policy policy1 permit node 1
apply mpls-label
if-match mpls-label
apply mpls-label
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 4.4.4.9 255.255.255.255
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
apply mpls-label
if-match mpls-label
apply mpls-label
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 162.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65002
#
ipv4-family unicast
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
8.9.8 Example for Configuring Inter-AS VPN Option C (Solution

2)
CE2 belong to vpn1.
Figure 8-49 Networking diagram for configuring Inter-AS VPN Option C

2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE2/0/0
192.1.1.1/24 192.1.1.2/24
GE1/0/0 GE1/0/0
172.1.1.1/24 ASBR-PE1 ASBR-PE2 162.1.1.1/24
Loopback1 Loopback1
1.1.1.9/32 4.4.4.9/32
GE1/0/0 GE1/0/0
172.1.1.2/24 162.1.1.2/24
PE1 PE2
GE2/0/0 GE2/0/0
10.1.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
CE1 CE2
10.1.1.1/24 10.2.1.1/24
vpn1 vpn1
AS 65001 AS 65002
No IBGP peer relationship is required between the PE and ASBR-PEs. The ASBR-PE learns
the labeled BGP routes of the public network at the remote AS from the remote ASBR-PE.
Then these BGP routes are imported to IGP. In this manner, LDP can distribute labels for
these routes and establish an inter-AS LDP LSP. The inter-AS BGP/MPLS IP VPN Option C
can then be implemented.
Inter-AS Option C can be deployed to meet the company's requirement. The configuration

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
set up LDP LSPs.
5. Advertise routes of the PE in an AS to the remote PE: First on the local ASBR-PE,
advertise the routes of the PE in an AS to the remote ASBR-PE through BGP; then on
the remote ASBR-PE, import these BGP routes to IGP. Then the remote PE learns routes
of the PE in the local AS through IGP.
6. Configure a routing policy on the ASBR-PE: Assign MPLS labels to the routes
advertised to the emote ASBR-PE.
7. Enable the capability of exchanging labeled IPv4 routes between the local ASBR-PE and
the remote ASBR-PE.
8. Configure LDP LSPs for the labeled BGP routes of the public network on ASBR-PEs.
9. Set up MP-EBGP peer relationships between PEs of different ASs. In most cases, these
PEs are not directly connected, and the maximum hops between them must be specified.
Procedure
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
NOTE
using OSPF.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
each other.

[PE1] display ospf peer

Neighbors
Area 0.0.0.0 interface 172.1.1.2(GigabitEthernet1/0/0)'s neighbors

Router ID: 2.2.2.9 Address: 172.1.1.1
State: Full Mode:Nbr is Master Priority: 1
DR: 172.1.1.2 BDR: 172.1.1.1 MTU: 0
Dead timer due in 34 sec
Retrans timer interval: 5
Neighbor is up for 18:50:53
Authentication Sequence: [ 0 ]
The ASBR-PE and PEs in the same AS have obtained the IP address of Loopback1 interface
of each other and can ping Loopback1 interface address of each other.
Step 3 Set up the EBGP peer relationship between ASBR-PEs.
# Configure ASBR-PE1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] quit
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] quit
After the configuration is complete, run the display bgp peer command on ASBR-PEs. The
command output shows that the statue of neighbors is Established.
ASBR-PE1 is used as an example.

[ASBR-PE1] display bgp peer

192.1.1.2 4 200 129 134 0 01:39:21 Established 1
Step 4 Advertise the routes of a PE in an AS to the remote PE.
# On ASBR-PE1: Advertise routes to loopback interfaces to ASBR-PE2.

[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] quit
# On ASBR-PE2: Advertise routes to loopback interfaces to ASBR-PE1.

[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] quit
# On ASBR-PE1: Import BGP routes to OSPF, and advertise the routes of PE2 to PE1
according to OSPF.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[ASBR-PE1] ospf 1
[ASBR-PE1-ospf-1] import-route bgp
# On ASBR-PE2: Import BGP routes to OSPF, and advertise the routes of PE1 to PE2
according to OSPF.
[ASBR-PE2] ospf 1
[ASBR-PE2-ospf-1] import-route bgp
After the configuration is complete, run the display ip routing-table command on PEs to
check the routing table. PE1 is used as an example.
to vpn-instance
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 172.1.1.1
4.4.4.9/32 O_ASE 150 1 D 172.1.1.1 GigabitEthernet1/0/0
172.1.1.0/24 Direct 0 0 D 172.1.1.2
172.1.1.2/32 Direct 0 0 D 127.0.0.1
172.1.1.255/32 Direct 0 0 D 127.0.0.1
ASBR-PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
connected to PE1.
[ASBR-PE1] mpls
[ASBR-PE1] mpls ldp
connected to PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[ASBR-PE2] mpls
[ASBR-PE2] mpls ldp
ASBR-PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, the LDP sessions between PE1 and the ASBR-PE1, and
between PE2 and ASBR-PE2 are set up. Run the display mpls ldp session command. The
command output shows that the status is "Operational". Run the display mpls ldp lsp
command. Information about the established LDP LSPs is displayed.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------

LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal/1024 DS/2.2.2.9
2.2.2.9/32 NULL/3 - 172.1.1.1 GE1/0/0
2.2.2.9/32 1024/3 2.2.2.9 172.1.1.1 GE1/0/0
-------------------------------------------------------------------------------
Step 6 Enable the capability of exchanging labeled IPv4 routes on ASBR-PEs.

# On ASBR-PE1: Enable MPLS on the interface connected to ASBR-PE2. The configuration
on ASBR-PE2 is similar to the configuration on ASBR-PE1 and is not mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# On ASBR-PE1: Create a routing policy. The configuration on ASBR-PE2 is similar to the

configuration on ASBR-PE1 and is not mentioned here.
# On ASBR-PE1: Apply a routing policy to the routes advertised to ASBR-PE2, and enable
the capability of exchanging labeled IPv4 routes with ASBR-PE2. The configuration on
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] quit
Step 7 Configure LDP LSPs for the labeled BGP routes of the public network on ASBR devices.
[ASBR-PE1] mpls
[ASBR-PE1-mpls] lsp-trigger bgp-label-route
[ASBR-PE2] mpls
[ASBR-PE2-mpls] lsp-trigger bgp-label-route
Step 8 Configure VPN instances to access CEs on PEs.
# Configure PE1.
# Configure PE2.
The information displayed on PE1 and CE1 is used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VPN-Instance Name and ID : vpn1, 1

Address family ipv4
Create date : 2008/02/27 09:53:47
Log Interval : 5
[PE1] ping -vpn-instance vpn1 10.1.1.1
Request time out

20.00% packet loss
Step 9 Set up an MP-EBGP peer relationship between PE1 and PE2.

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] quit
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] bgp 100

[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
on the PEs. The command output shows that BGP peer relationships have been established
between the PEs and CEs.
The peer relationship between PE1 and CE1 is used as an example.

VPN-Instance vpn1, router ID 1.1.1.9:


10.1.1.1 4 65001 3 3 0 00:00:52 Established 1

to vpn-instance
------------------------------------------------------------------------------
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
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2
[CE1] ping 10.2.1.1


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss
# After the configuration is complete, run the display ip routing-table dest-ip-address

verbose command on ASBR-PE1. The command output shows that the routes from ASBR-
PE1 to PE2 are labeled BGP routes of the public network: routing table is "Public", the
protocol type is "BGP", and the label has a non-zero value.
# The information displayed on ASBR-PE1 is used as an example.
[ASBR-PE1] display ip routing-table 4.4.4.9 verbose
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
Destination : 4.4.4.9/32
Protocol : BGP Process ID : 0
Preference : 255 Cost : 1
NextHop : 192.1.1.2 Neighbour : 192.1.1.2
State : Active Adv Age : 00h12m53s
Tag : 0 Priority : 0
Label : 15360 QoSInfo : 0x0
IndirectID : 0x0
RelayNextHop : 192.1.1.2 Interface : GigabitEthernet2/0/0
TunnelID : 0x6002006 Flags : D
# Run the display mpls lsp protocol ldp include dest-ip-address verbose on ASBR-PE1 and
PE2 respectively. The command output shows that an LDP LSP is established between
ASBR-PE1 and PE2. Besides, you can find an LDP Ingress LSP on a PE to the remote PE.
[ASBR-PE1] display mpls lsp protocol ldp include 4.4.4.9 32 verbose
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
No : 1
VrfIndex :
Fec : 4.4.4.9/32
Nexthop : 192.1.1.2
In-Label : 1024
Out-Label : NULL
In-Interface : ----------
Out-Interface : ----------
LspIndex : 13313
Token : 0x0
FrrToken : 0x0
LsrType : Egress
Outgoing token : 0x6002006
Label Operation : SWAPPUSH
Mpls-Mtu : ------
TimeStamp : 15829sec
Bfd-State : ---
BGPKey : 0x24
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
bgp 65001
#
ipv4-family unicast
import-route direct
#
return
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
lsp-trigger bgp-label-route
#
mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 1.1.1.9 255.255.255.255
#
ospf 1
import-route bgp
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
apply mpls-label
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
lsp-trigger bgp-label-route
#
mpls ldp
#
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 4.4.4.9 255.255.255.255
#
ospf 1
import-route bgp
area 0.0.0.0
network 3.3.3.9 0.0.0.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network 162.1.1.0 0.0.0.255

#
apply mpls-label
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 162.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65002
#
ipv4-family unicast

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route direct
#
return
8.9.9 Example for Configuring MCE

The headquarters and branches of a company need to communicate through MPLS VPN, and
two services of the company must be isolated. To reduce hardware costs, the company wants
the branches to connect to the PE through one CE.
As shown in Figure 8-50, the networking requirements are as follows:
l CE1 and CE2 connect to the headquarters. CE1 belongs to vpna, and CE2 belongs to
vpnb.
l The multi-VPN-instance CE (MCE) device connects to vpna and vpnb of the branches
through CE3 and CE4.
Users in the same VPN need to communicate with each other, but users in different VPNs
must be isolated.
Figure 8-50 Networking diagram for configuring MCE

vpna vpna
CE1 CE3
GE1/0/0 GE1/0/0
10.1.1.1/24 Loopback1 10.3.1.1/24
2.2.2.9/32 GE3/0/0
GE1/0/0
10.1.1.2/24 GE2/0/0.1 GE1/0/0.1 10.3.1.2/24
GE3/0/0
192.1.1.1/24 192.1.1.2/24 vpna
Loopback1 172.1.1.1/24
MCE
1.1.1.9/32 GE1/0/0 GE2/0/0.2 GE1/0/0.2 vpnb
GE2/0/0 PE1 172.1.1.2/24 PE2 192.2.1.1/24 192.2.1.2/24 GE4/0/0
10.2.1.2/24 10.4.1.2/24
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
vpnb vpnb
1. Configure OSPF between PEs to implement interworking between them and configure
MP-IBGP to exchange VPN routing information.
2. Configure basic MPLS capabilities and MPLS LDP on the PEs to set up LDP LSPs.
3. Create VPN instances vpna and vpnb on the MCEs and PEs to isolate services.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4. Set up EBGP peer relationships between PE1 and its connected CEs, and import BGP
routes to the VPN routing table on PE1.
5. Configure routing between the MCE and VPN sites and between the MCE and PE2.
Procedure
Step 1 Configure OSPF on PEs of the backbone network.
mentioned here.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After the configuration is complete, PEs can learn Loopback1 address of each other.

to vpn-instance
------------------------------------------------------------------------------
1.1.1.9/32 OSPF 10 1 D 172.1.1.1
172.1.1.0/24 Direct 0 0 D 172.1.1.2
172.1.1.2/32 Direct 0 0 D 127.0.0.1
172.1.1.255/32 Direct 0 0 D 127.0.0.1
Step 2 Configure basic MPLS capabilities and MPLS LDP on the PEs to set up LDP LSPs.
mentioned here.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After the configuration is complete, run the display mpls ldp session command on the PEs.
The command output shows that the MPLS LDP session between the PEs is in Operational
state.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 3 Configure VPN instances on the PEs. On PE1, bind the VPN instances to the interfaces
connected to CE1 and CE2 respectively. On PE2, bind the VPN instances to the interfaces
connected to the MCE.
# Configure PE1.
# Configure PE2.
[PE2] interface gigabitethernet 2/0/0.1
[PE2-GigabitEthernet2/0/0.1] dot1q termination vid 10
[PE2-GigabitEthernet2/0/0.1] ip binding vpn-instance vpna
[PE2-GigabitEthernet2/0/0.1] ip address 192.1.1.1 24
[PE2-GigabitEthernet2/0/0.1] quit
[PE2] interface gigabitethernet 2/0/0.2
[PE2-GigabitEthernet2/0/0.2] dot1q termination vid 20
[PE2-GigabitEthernet2/0/0.2] ip binding vpn-instance vpnb
[PE2-GigabitEthernet2/0/0.2] ip address 192.2.1.1 24
[PE2-GigabitEthernet2/0/0.2] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 Configure VPN instances on the MCE, and bind the VPN instances to the interfaces
connected to CE3, CE4, and PE2.
[Huawei] sysname MCE
[MCE] ip vpn-instance vpna
[MCE-vpn-instance-vpna] ipv4-family
[MCE-vpn-instance-vpna-af-ipv4] route-distinguisher 300:1
[MCE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[MCE-vpn-instance-vpna-af-ipv4] quit
[MCE-vpn-instance-vpna] quit
[MCE] ip vpn-instance vpnb
[MCE-vpn-instance-vpnb] ipv4-family
[MCE-vpn-instance-vpnb-af-ipv4] route-distinguisher 300:2
[MCE-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[MCE-vpn-instance-vpnb-af-ipv4] quit
[MCE-vpn-instance-vpnb] quit
[MCE] interface gigabitethernet 3/0/0
[MCE-GigabitEthernet3/0/0] ip binding vpn-instance vpna
[MCE-GigabitEthernet3/0/0] ip address 10.3.1.2 24
[MCE-GigabitEthernet3/0/0] quit
[MCE-GigabitEthernet4/0/0] ip binding vpn-instance vpnb
[MCE-GigabitEthernet4/0/0] ip address 10.4.1.2 24
[MCE] interface gigabitethernet 1/0/0.1
[MCE-GigabitEthernet1/0/0.1] dot1q termination vid 10
[MCE-GigabitEthernet1/0/0.1] ip binding vpn-instance vpna
[MCE-GigabitEthernet1/0/0.1] ip address 192.1.1.2 24
[MCE-GigabitEthernet1/0/0.1] quit
[MCE-GigabitEthernet1/0/0.2] ip binding vpn-instance vpnb
[MCE-GigabitEthernet1/0/0.2] ip address 192.2.1.2 24
Step 5 Set up an MP-IBGP peer relationship between PEs. Set up EBGP peer relationships between
PE1 and CE1, and between PE1 and CE2.
# Configure CE1. The configuration on other PE1 and PE2 is similar to the configuration on
CE1 and is not mentioned here.
[CE1] bgp 65410
[CE1-bgp] ipv4-family unicast
[CE1-bgp-af-ipv4] import-route direct
[CE1-bgp-af-ipv4] quit
[CE1-bgp] quit
After the configuration is complete, run the display bgp vpnv4 all peer command on PE1.
The command output shows that the PE1 has set up an IBGP peer relationship with PE2 and
EBGP peer relationships with CE1 and CE2. The peer relationships are in Established state.

2.2.2.9 4 100 288 287 0 01:19:16 Established 4
VPN-Instance vpna, router ID 1.1.1.9:

10.1.1.1 4 65410 9 11 0 00:04:14 Established 4

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN-Instance vpnb, router ID 1.1.1.9:

10.2.1.1 4 65420 9 12 0 00:04:09 Established 3
Step 6 Configure OSPF multi-instance between the MCE and PE2.

# Configure PE2.
[PE2] ospf 100 vpn-instance vpna
[PE2-ospf-100] import-route bgp
[PE2-ospf-100] quit
[PE2] ospf 200 vpn-instance vpnb
[PE2-ospf-200] quit
[PE2] bgp 100
[PE2-bgp-vpna] import-route ospf 100
[PE2-bgp-vpna] quit
[PE2-bgp-vpnb] import-route ospf 200
[PE2-bgp-vpnb] quit
[PE2-bgp] quit
# Configure the MCE.

[MCE] ospf 100 vpn-instance vpna
[MCE-ospf-100] area 0
[MCE-ospf-100-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[MCE-ospf-100-area-0.0.0.0] quit
[MCE-ospf-100] quit
[MCE] ospf 200 vpn-instance vpnb
[MCE-ospf-200] area 0
[MCE-ospf-200-area-0.0.0.0] network 192.2.1.0 0.0.0.255
[MCE-ospf-200-area-0.0.0.0] quit
[MCE-ospf-200] quit
Step 7 Configure RIPv2 between the MCE and CE3, and between the MCE and CE4.
# Configure the MCE.
[MCE] rip 100 vpn-instance vpna
[MCE-rip-100] version 2
[MCE-rip-100] network 10.0.0.0
[MCE-rip-100] import-route ospf 100
[MCE-rip-100] quit
[MCE] rip 200 vpn-instance vpnb
[MCE-rip-200] version 2
[MCE-rip-200] network 10.0.0.0
[MCE-rip-200] import-route ospf 200
[MCE-rip-200] quit
# Configure CE3.
[CE3] rip 100
[CE3-rip-100] version 2
[CE3-rip-100] network 10.0.0.0
[CE3-rip-100] import-route direct
# Configure CE4.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE4] rip 200

[CE4-rip-200] version 2
[CE4-rip-200] network 10.0.0.0
[CE4-rip-200] import-route direct
Step 8 Disable loop detection on the MCE device and import RIP routes.
[MCE] ospf 100 vpn-instance vpna
[MCE-ospf-100] vpn-instance-capability simple
[MCE-ospf-100] import-route rip 100
[MCE-ospf-100] quit
[MCE] ospf 200 vpn-instance vpnb
[MCE-ospf-200] vpn-instance-capability simple
[MCE-ospf-200] import-route rip 200
[MCE-ospf-200] quit
# After the configuration is complete, run the display ip routing-table vpn-instance

command on the MCE. The command output shows the route to the remote CE.
# The VPN instance vpna is used as an example.

[MCE] display ip routing-table vpn-instance vpna
to vpn-instance
------------------------------------------------------------------------------

10.1.1.0/24 O_ASE 150 1 D 192.1.1.1
GigabitEthernet1/0/0.1
10.3.1.0/24 Direct 0 0 D 10.3.1.2
10.3.1.2/32 Direct 0 0 D 127.0.0.1
10.3.1.255/32 Direct 0 0 D 127.0.0.1
192.1.1.0/24 Direct 0 0 D 192.1.1.2
192.1.1.2/32 Direct 0 0 D 127.0.0.1
192.1.1.255/32 Direct 0 0 D 127.0.0.1
# Run the display ip routing-table vpn-instance command on the PE. The command output
shows the route to the remote CE.
# The VPN instance vpna on PE1 is used as an example.

to vpn-instance
------------------------------------------------------------------------------

10.1.1.0/24 Direct 0 0 D 10.1.1.2
10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24 IBGP 255 2 RD 2.2.2.9
192.1.1.0/24 IBGP 255 0 RD 2.2.2.9

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# CE1 and CE3 can ping each other, and CE2 and CE4 can ping each other.
# The ping from CE1 to CE3 is used as an example.
[CE1] ping 10.3.1.1
0.00% packet loss
# CE1 cannot ping CE2 or CE4. CE3 cannot ping CE2 or CE4.
# For example, if you ping CE4 from CE1, the following information is displayed:
[CE1] ping 10.4.1.1
Request time out
Request time out
Request time out
Request time out
Request time out

100.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ipv4-family unicast
import-route direct
#
return
#
sysname PE1
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return
#
sysname PE2
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 192.1.1.1 255.255.255.0
#
ip address 192.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route ospf 100
#
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
ospf 100 vpn-instance vpna
import-route bgp
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ospf 200 vpn-instance vpnb

import-route bgp
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
return
l MCE configuration file
#
sysname MCE
#
ipv4-family
#
ipv4-family
#
ip address 192.1.1.2 255.255.255.0
#
ip address 192.2.1.2 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.2 255.255.255.0
#
ospf 100 vpn-instance vpna
import-route rip 100
vpn-instance-capability simple
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#
ospf 200 vpn-instance vpnb
import-route rip 200
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
rip 100 vpn-instance vpna
version 2
network 10.0.0.0
#
rip 200 vpn-instance vpnb
version 2
network 10.0.0.0
#
return
#
sysname CE3
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.3.1.1 255.255.255.0

#
rip 100
version 2
network 10.0.0.0
import-route direct
#
return

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
rip 200
version 2
network 10.0.0.0
import-route direct
#
return
8.9.10 Example for Configuring PBR to an LSP for VPN Packets

As shown in Figure 8-51, the BGP/MPLS IP VPN backbone network consists of PE1, PE2,
P1, and P2. CE1 and CE2 connect to the backbone network through PE1 and PE2
respectively. The path PE1->P2->PE2 is the primary LSP, and the path PE1->P1->PE2 is the
backup LSP.
If the PBR is configured on PE1, packets of 10 to 1000 bytes long sent from CE1 to CE2 are
forwarded through P2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-51 Networking diagram for configuring the PBR to an LSP for VPN packets
Loopback1
AS 100
2.2.2.9/32
GE1/0/0 GE2/0/0
172.1.1.2/24 172.2.1.1/24
P1
Loopback1 Loopback1
1.1.1.9/32 3.3.3.9/32
GE1/0/0 GE1/0/0
172.1.1.1/24 172.2.1.2/24
PE1 MPLS Backbone PE2
GE2/0/0 GE2/0/0
172.3.1.1/24 172.4.1.2/24
GE3/0/0 Loopback1 GE3/0/0
10.1.1.2/24 4.4.4.9/32 10.3.1.2/24
GE1/0/0 GE2/0/0
172.3.1.2/24 172.4.1.1/24
P2
GE1/0/0 GE1/0/0
10.1.1.1/24 10.3.1.1/24
vpna vpna
AS:65410 CE1 CE2 AS:65430
1. Configure BGP/MPLS VPN according to 8.9.1 Example for Configuring BGP/MPLS
IP VPN.
2. Configure the PBR and policy node on the PE that requires the configuration of the PBR
to an LSP. Set a matching rule of IP packet length and specify an LSP for forwarding
VPN instance packets that meet the matching rule in the policy-based route view.
3. Apply the PBR to the outbound interface bound to the VPN instance on the PE.
Procedure
Step 1 Configure BGP/MPLS VPN.
For the configuration procedure, refer to 8.9.1 Example for Configuring BGP/MPLS IP
VPN.
After the configuration is complete, run the display mpls lsp command to check LSPs on
PE1.
[PE1] display mpls lsp
----------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
LSP Information: BGP LSP

----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
10.1.1.0/24 15360/NULL -/- vpna
----------------------------------------------------------------------
----------------------------------------------------------------------
2.2.2.9/32 NULL/3 -/GE1/0/0
2.2.2.9/32 1024/3 -/GE1/0/0
3.3.3.9/32 NULL/1024 -/GE1/0/0
3.3.3.9/32 NULL/1024 -/GE2/0/0
4.4.4.9/32 NULL/3 -/GE2/0/0
4.4.4.9/32 1025/3 -/GE2/0/0
1.1.1.9/32 3/NULL -/-
The LSPs to PE2 have two outbound interfaces: GE1/0/0 and GE2/0/0.
Step 2 Configure the PBR to an LSP on PE1.
[PE1] policy-based-route policy1 permit node 10
[PE1-policy-based-route-policy1-10] if-match packet-length 10 1000
[PE1-policy-based-route-policy1-10] apply lsp vpn vpna 10.3.1.1 3.3.3.9 172.3.1.2
[PE1-policy-based-route-policy1-10] quit
Step 3 Enable the PBR on PE1.

[PE1] ip local policy-based-route policy1
Step 4 Clear statistics on GE2/0/0 of PE1.

[PE1] quit
<PE1> reset counters interface GigabitEthernet 2/0/0

# Ping CE2 from CE1 to check the forwarding path of the packets.
[CE1] ping –c 1500 –s 950 10.3.1.1
# Check packet statistics on the interface of PE1.

<PE1> display interface gigabitethernet 2/0/0
GigabitEthernet2/0/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2012-09-14 18:13:40
Description:HUAWEI, AR Series, GigabitEthernet2/0/0 Interface
Internet Address is 172.3.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 80fb-0635-45b6
Last physical up time : 2012-09-14 18:13:40
Last physical down time : 2012-09-14 18:13:23
Port Mode: COMMON COPPER
Speed : 1000, Loopback: NONE
Duplex: FULL, Negotiation: ENABLE
Mdi : AUTO
Last 300 seconds input rate 456 bits/sec, 0 packets/sec
Last 300 seconds output rate 472 bits/sec, 0 packets/sec
Input peak rate 18088 bits/sec,Record time: 2012-09-14 18:22:50
Output peak rate 18016 bits/sec,Record time: 2012-09-14 18:22:50
Input: 30 packets, 25402 bytes

Unicast: 26, Multicast: 4
Broadcast: 0, Jumbo: 0
Discard: 0, Total Error: 0
CRC: 0, Giants: 0
Jabbers: 0, Throttles: 0
Runts: 0, Symbols: 0
Ignoreds: 0, Frames: 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Output: 31 packets, 25970 bytes

Unicast: 27, Multicast: 4
Broadcast: 0, Jumbo: 0
Discard: 0, Total Error: 0
Collisions: 0, ExcessiveCollisions: 0
Late Collisions: 0, Deferreds: 0
Input bandwidth utilization threshold : 100.00%

Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.01%
# Run the display interface gigabitethernet 1/0/0 and display interface gigabitethernet
2/0/0 commands repeatedly on PE1 to check the change of packet statistics on interfaces of
PE1. The command output shows that packets are forwarded along the specified LSP.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 172.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.1.1.0 0.0.0.255
#
policy-based-route policy1 permit node 10
if-match packet-length 10 1000
apply lsp vpn vpna 10.3.1.1 3.3.3.9 172.3.1.2
#
ip local policy-based-route policy1
#
return
l P1 configuration file
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.3.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 172.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 172.3.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.4.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ipv4-family unicast
import-route direct
#
return

#
sysname CE2
#
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
8.9.11 Example for Configuring HoVPN

Figure 8-52 shows a hierarchical VPN network consisting of a provincial backbone network
and a city MPLS VPN network.
l The SPE is located on the provincial backbone network and connects to the city MPLS
VPN network.
l The UPE is located on the city network and connects to VPN users.
The routing and forwarding capabilities of the UPE are lower than those of the SPE and PEs.
The HoVPN networking can enable users in vpna to communicate with each other while
reducing the loads on the UPE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-52 Networking diagram for configuring HoVPN
Loopback1 Loopback1
AS: 100 2.2.2.9./32 3.3.3.9./32
GE2/0/0
GE1/0/0
172.2.1.1/24
172.1.1.2/24 PE
Loopback1
GE2/0/0
1.1.1.9./32 172.2.1.2/24
SPE GE1/0/0
UPE
10.2.1.2/24
GE2/0/0
172.1.1.1/24 VPN Backbone
GE1/0/0
10.1.1.2/24
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE1 CE2
AS: 65410 AS: 65420

vpna vpna
1. Configure an IGP on the backbone network to implement IP interworking.
2. Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up
MPLS LSPs.
3. Set up MP-IBGP peer relationships between the UPE and SPE and between the PE and
SPE to exchange VPN routing information.
4. On the UPE and PEs, create VPN instances and set up EBGP peer relationships with
CEs to exchange VPN routing information.
5. On the SPE, create a VPN instance and specify the UPE as its underlayer PE (or user-
end PE). Advertise the default route of the VPN instance to the UPE to reduce the loads
on the UPE.
Procedure
Step 1 Configure OSPF on the backbone network to implement IP interworking.
# Configure the UPE.
[Huawei] sysname UPE
[UPE] interface loopback 1
[UPE-LoopBack1] ip address 1.1.1.9 32
[UPE-LoopBack1] quit
[UPE] interface gigabitethernet 2/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[UPE-GigabitEthernet2/0/0] ip address 172.1.1.1 24

[UPE-GigabitEthernet2/0/0] quit
[UPE] ospf
[UPE-ospf-1] area 0
[UPE-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[UPE-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[UPE-ospf-1-area-0.0.0.0] quit
[UPE-ospf-1] quit
The configuration on the SPE and PEs is similar to the configuration on the UPE and is not
mentioned here.
After the configuration is complete, OSPF neighbor relationships are set up between the UPE,
SPE, and PE. Run the display ospf peer command on these devices. The command output
shows that the neighbor relationships are in Full state. Run the display ip routing-table
command on these devices. The command output shows that they have learned the route to
the loopback interface of each other.
Step 2 Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up LDP
LSPs.
[UPE] mpls lsr-id 1.1.1.9

[UPE] mpls
[UPE-mpls] quit
[UPE] mpls ldp
[UPE-mpls-ldp] quit
[UPE-GigabitEthernet2/0/0] mpls
[UPE-GigabitEthernet2/0/0] mpls ldp
The configuration on the SPE and PEs is similar to the configuration on the UPE and is not
mentioned here.
After the configuration is complete, LDP sessions are established between UPE and SPE, and
between SPE and PE. Run the display mpls ldp session command on these devices. The
command output shows that the status is Operational. Run the display mpls ldp lsp
command. Information about the established LDP LSPs is displayed.
Step 3 Set up MP-IBGP peer relationships between the UPE and SPE and between the PE and SPE.
[UPE] bgp 100

[UPE-bgp] peer 2.2.2.9 as-number 100
[UPE-bgp] peer 2.2.2.9 connect-interface loopback 1
[UPE-bgp] ipv4-family vpnv4
[UPE-bgp-af-vpnv4] peer 2.2.2.9 enable
[UPE-bgp-af-vpnv4] quit
[UPE-bgp] quit
# Configure the SPE.
[SPE] bgp 100

[SPE-bgp] peer 1.1.1.9 as-number 100
[SPE-bgp] peer 1.1.1.9 connect-interface loopback 1
[SPE-bgp] peer 3.3.3.9 as-number 100
[SPE-bgp] peer 3.3.3.9 connect-interface loopback 1
[SPE-bgp] ipv4-family vpnv4
[SPE-bgp-af-vpnv4] peer 1.1.1.9 enable
[SPE-bgp-af-vpnv4] peer 3.3.3.9 enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[SPE-bgp-af-vpnv4] quit
[SPE-bgp] quit
# Configure the PE.
[PE] bgp 100

[PE-bgp] peer 2.2.2.9 as-number 100
[PE-bgp] peer 2.2.2.9 connect-interface loopback 1
[PE-bgp] ipv4-family vpnv4
[PE-bgp-af-vpnv4] peer 2.2.2.9 enable
[PE-bgp-af-vpnv4] quit
[PE-bgp] quit
Step 4 On the UPE and PEs, create a VPN instance and set up EBGP peer relationships with the
CEs.
[UPE] ip vpn-instance vpna

[UPE-vpn-instance-vpna] ipv4-family
[UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[UPE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[UPE-vpn-instance-vpna-af-ipv4] quit
[UPE-vpn-instance-vpna] quit
[UPE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[UPE-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[UPE] bgp 100
[UPE-bgp] ipv4-family vpn-instance vpna
[UPE-bgp-vpna] peer 10.1.1.1 as-number 65410
[UPE-bgp-vpna] import-route direct
[UPE-bgp-vpna] quit
[UPE-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure the PE.
[PE] ip vpn-instance vpna

[PE-vpn-instance-vpna] ipv4-family
[PE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:2
[PE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[PE-vpn-instance-vpna-af-ipv4] quit
[PE-vpn-instance-vpna] quit
[PE] interface gigabitethernet 1/0/0
[PE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[PE-GigabitEthernet1/0/0] ip address 10.2.1.2 24
[PE-GigabitEthernet1/0/0] quit
[PE] bgp 100
[PE-bgp] ipv4-family vpn-instance vpna
[PE-bgp-vpna] peer 10.2.1.1 as-number 65420
[PE-bgp-vpna] import-route direct
[PE-bgp-vpna] quit
[PE-bgp] quit
# Configure CE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE2] bgp 65420
[CE2-bgp] quit
the UPE and PEs to check the configuration of VPN instances. Run the ping -vpn-instance
command on the UPE and PEs to ping the connected CEs. The ping operations succeed.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you need to specify the source IP
addresses by setting -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-
address dest-ip-address command to ping the remote CE. If the source IP address is not specified, the
ping operation fails.
UPE is used as an example.

[UPE] display ip vpn-instance verbose

Address family ipv4
Create date : 2012/09/14 14:34:10
Log Interval : 5
Step 5 On the SPE, create a VPN instance, specify the UPE as its underlayer PE, and advertise the
default route of the VPN instance to the UPE.
# Configure the VPN instance.
[SPE] ip vpn-instance vpna
[SPE-vpn-instance-vpna] route-distinguisher 200:1
[SPE-vpn-instance-vpna] vpn-target 1:1
[SPE-vpn-instance-vpna] quit
# Specify the UPE for the SPE.

[SPE] bgp 100
[SPE-bgp] ipv4-family vpnv4
[SPE-bgp-af-vpnv4] peer 1.1.1.9 upe
# Advertise the default route of the VPN instance to the UPE.

[SPE-bgp-af-vpnv4] peer 1.1.1.9 default-originate vpn-instance vpna
[SPE-bgp-af-vpnv4] quit
[SPE-bgp] quit

# After the configuration is complete, CE1 has no route to the network segment of the
interface on CE2, but CE1 has a default route with the next hop as UPE. CE2 has a BGP route
to the network segment of the interface on CE1. CE1 and CE2 can ping each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
to vpn-instance
------------------------------------------------------------------------------
0.0.0.0/0 EBGP 255 0 D 10.1.1.2

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
10.1.1.255/32 Direct 0 0 D 127.0.0.1
[CE1] ping 10.2.1.1


0.00% packet loss

to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 D 10.2.1.2

10.2.1.0/24 Direct 0 0 D 10.2.1.1
10.2.1.1/32 Direct 0 0 D 127.0.0.1
10.2.1.255/32 Direct 0 0 D 127.0.0.1
# Run the display bgp vpnv4 all routing-table command on the UPE. The command output
shows a default route of vpna with the next hop as SPE.
[UPE] display bgp vpnv4 all routing-table


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
*> 10.1.1.0/24 0.0.0.0 0 0 ?

* 10.1.1.1 0 0 65410?
*> 10.1.1.2/32 0.0.0.0 0 0 ?
*>i 0.0.0.0 2.2.2.9 0 100 0 i

*>i 0.0.0.0 2.2.2.9 0 100 0 i

*> 10.1.1.0/24 0.0.0.0 0 0 ?
10.1.1.1 0 0 65410?
*> 10.1.1.2/32 0.0.0.0 0 0 ?
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
l UPE configuration file

#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l SPE configuration file
#
sysname SPE
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
peer 1.1.1.9 enable

peer 1.1.1.9 upe
peer 1.1.1.9 default-originate vpn-instance vpna
peer 3.3.3.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
l PE configuration file
#
sysname PE
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
8.9.12 Example for Configuring an OSPF Sham Link
As shown in Figure 8-53, CE1 and CE2 belong to the same OSPF area of VPN1 and they
connect to PE1 and PE2 respectively. A backdoor link exists between CE1 and CE2 and is
used as a backup link.
The CEs and PEs need to run OSPF. When the backbone network is running properly, VPN
traffic of CE1 and CE2 should be forwarded over the MPLS backbone network without
passing through the backdoor link.
Figure 8-53 Networking diagram for configuring OSPF sham link

Loopback1 Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
PE1 PE2
GE2/0/0 GE1/0/0 GE2/0/0 GE2/0/0
10.1.1.1/24 10.1.1.2/24 40.1.1.1/24 40.1.1.2/24
GE1/0/0 P Lo GE1/0/0
10 o
100.1.1.2/24 ck 6.6 pba 120.1.1.2/24
p ba /32 sham link .6. ck1
o
Lo .5.5.5 6/3 0
2
5
GE1/0/0 GE1/0/0
100.1.1.1/24 120.1.1.1/24
GE2/0/0 GE1/0/0 GE2/0/0 GE2/0/0
20.1.1.1/24 20.1.1.2/24 30.1.1.1/24 30.1.1.2/24
CE1 RTA CE2

VPN1 VPN1
backdoor
1. Set up an ME-IBGP peer relationship between the PEs and configure OSPF between the
PEs and CEs.
2. Create a VPN instance on the PEs and bind it to the interfaces connected to CEs.
3. Create an OSPF sham link on the PEs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4. Set the cost of the backdoor link to be larger than the cost of the sham link so that VPN
traffic is transmitted over the MPLS backbone network.
Procedure
Step 1 Configure OSPF on the customer network.
Configure OSPF on CE1, RTA, and CE2 and advertise the network segment of each interface.
# Configure CE1.
[CE1] interface gigabitethernet2/0/0
[CE1] interface gigabitethernet1/0/0
[CE1] ospf
[CE1-ospf-1] area 0
[CE1-ospf-1] quit
# Configure RTA.
[Huawei] sysname RTA
[RTA] interface gigabitethernet 1/0/0
[RTA-GigabitEthernet1/0/0] ip address 20.1.1.2 24
[RTA-GigabitEthernet1/0/0] quit
[RTA] ospf
[RTA-ospf-1] area 0
[RTA-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RTA-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[RTA-ospf-1-area-0.0.0.0] quit
[RTA-ospf-1] quit
# Configure CE2.
[CE2] ospf
[CE2-ospf-1] area 0
[CE2-ospf-1] quit
Step 2 Complete basic BGP/MPLS IP VPN configuration on the backbone network: configure an
IGP, enable MPLS and LDP, and set up an MP-IBGP peer relationship between the PEs.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] ospf 1 router-id 1.1.1.9
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
[PE1] bgp 100
[PE1-bgp] quit
# Configure P.
[Huawei] sysname P
[P-LoopBack1] ip address 2.2.2.9 32
[P-LoopBack1] quit
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P] ospf 1 router-id 2.2.2.9
[P-ospf-1] area 0
[P-ospf-1] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] ospf 1 router-id 3.3.3.9
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
[PE2] bgp 100
[PE2-bgp] quit
After the configuration is complete, PE1 and PE2 can learn the route to the loopback interface
of each other and set up an MP-IBGP peer relationship.
Step 3 Configure OSPF between the PEs and CEs.
# Configure PE1.
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[PE1] ospf 100 router-id 5.5.5.5 vpn-instance vpn1
[PE1-ospf-100] domain-id 10
[PE1-ospf-100] quit
[PE1] bgp 100
[PE1-bgp-vpn1] import-route ospf 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] ospf 100 router-id 6.6.6.6 vpn-instance vpn1

[PE2-ospf-100] domain-id 10
[PE2-ospf-100] quit
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
After the configuration is complete, run the display ip routing-table vpn-instance command
on the PEs. The command output shows that the routes to the remote CEs are OSPF routes
through the customer network, not the BGP routes through the backbone network.
[PE1] display ip routing-table vpn-instance vpn1
to vpn-instance
------------------------------------------------------------------------------
20.1.1.0/24 OSPF 10 2 D 100.1.1.1
30.1.1.0/24 OSPF 10 3 D 100.1.1.1
100.1.1.0/24 Direct 0 0 D 100.1.1.2
100.1.1.2/32 Direct 0 0 D 127.0.0.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1
120.1.1.0/24 OSPF 10 4 D 100.1.1.1
Step 4 Configure an OSPF sham link.

NOTE
To forward VPN traffic through the MPLS backbone network, ensure that the cost of the sham link is
smaller than the cost of the OSPF route used for forwarding VPN traffic over the customer network. A
commonly used method is to set the cost of the forwarding interface on the customer network to be
larger than the cost of the sham link.
# Configure CE1.
[CE1-GigabitEthernet2/0/0] ospf cost 10
# Configure CE2.
[CE2-GigabitEthernet2/0/0] ospf cost 10
# Configure PE1.
[PE1-LoopBack10] ip binding vpn-instance vpn1
[PE1] ospf 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-100-area-0.0.0.0] sham-link 5.5.5.5 6.6.6.6 cost 1
[PE1-ospf-100] quit
# Configure PE2.
[PE2-LoopBack10] ip binding vpn-instance vpn1
[PE2] ospf 100
[PE2-ospf-100-area-0.0.0.0] sham-link 6.6.6.6 5.5.5.5 cost 1
[PE2-ospf-100] quit

# After the configuration is complete, run the display ip routing-table vpn-instance
command on the PEs. The command output shows that the routes to the remote CEs are BGP
routes through the backbone network, and there are routes to the destination of the sham link.
to vpn-instance
------------------------------------------------------------------------------
6.6.6.6/32 IBGP 255 0 RD 3.3.3.9
20.1.1.0/24 OSPF 10 11 D 100.1.1.1
30.1.1.0/24 OSPF 10 12 D 100.1.1.1
100.1.1.0/24 Direct 0 0 D 100.1.1.2
100.1.1.2/32 Direct 0 0 D 127.0.0.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1
120.1.1.0/24 IBGP 255 0 RD 3.3.3.9
# Run the display ip routing-table command on the CEs. The command output shows that
the cost of the OSPF route to the remote CE has changed to 3, and the next hop has changed
to the interface connected to PE. That is, VPN traffic to the remote CE is forwarded through
the backbone network.
to vpn-instance
------------------------------------------------------------------------------
5.5.5.5/32 O_ASE 150 1 D 100.1.1.2
6.6.6.6/32 O_ASE 150 1 D 100.1.1.2
20.1.1.0/24 Direct 0 0 D 20.1.1.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
20.1.1.1/32 Direct 0 0 D 127.0.0.1
20.1.1.255/32 Direct 0 0 D 127.0.0.1
30.1.1.0/24 OSPF 10 11 D 20.1.1.2
100.1.1.0/24 Direct 0 0 D 100.1.1.1
100.1.1.1/32 Direct 0 0 D 127.0.0.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1
120.1.1.0/24 OSPF 10 3 D 100.1.1.2
NOTE
Cost of the OSPF route from CE1 to CE2 = Cost of the path from CE1 to PE1 + Cost of the sham link +
Cost of the path from PE2 to CE2 = 1 + 1 + 1 = 3
# Run the tracert command on CE1. The command output shows that the data sent from CE1
to CE2 passes through the interface connected to PE1. That is, VPN traffic is transmitted
through the backbone network.
[CE1] tracert 120.1.1.1
traceroute to 120.1.1.1(120.1.1.1), max hops: 30 ,packet length: 40,press
CTRL_C to break
1 100.1.1.2 10 ms 1 ms 1 ms
2 10.1.1.2 10 ms 1 ms 1 ms
3 120.1.1.1 10 ms 2 ms 1 ms
[CE1] tracert 30.1.1.2
traceroute to 30.1.1.2(30.1.1.2), max hops: 30 ,packet length: 40,press CTRL_C
to break
1 20.1.1.2 10 ms 1 ms 1 ms
2 30.1.1.2 10 ms 2 ms 1 ms
# Run the display ospf 100 sham-link command on the PEs to check information about the
sham link.
[PE1] display ospf 100 sham-link

Sham Link:
Area NeighborId Source-IP Destination-IP State Cost
0.0.0.0 6.6.6.6 5.5.5.5 6.6.6.6 P-2-P 1
# Run the display ospf sham-link area command. The command output shows that the
neighbor relationship is in Full state.
[PE1] display ospf sham-link area 0
Sham-Link: 5.5.5.5 --> 6.6.6.6

Neighbor ID: 6.6.6.6, State: Full, GR status: Normal
Area: 0.0.0.0
Cost: 1 State: P-2-P, Type: Sham
Timers: Hello 10 , Dead 40 , Retransmit 5 , Transmit Delay 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Run the display ospf routing command on the CEs. The command output shows that the
route to the remote CE is learned as an intra-area route.
[CE1] display ospf routing
Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
120.1.1.0/24 3 Transit 100.1.1.2 6.6.6.6 0.0.0.0
20.1.1.0/24 10 Transit 20.1.1.1 100.1.1.1 0.0.0.0
30.1.1.0/24 11 Transit 20.1.1.2 30.1.1.1 0.0.0.0
100.1.1.0/24 1 Transit 100.1.1.1 100.1.1.1 0.0.0.0
Routing for ASEs
Destination Cost Type Tag NextHop AdvRouter
6.6.6.6/32 1 Type2 3489661028 100.1.1.2 5.5.5.5
5.5.5.5/32 1 Type2 3489661028 100.1.1.2 6.6.6.6
Total Nets: 6
Intra Area: 4 Inter Area: 0 ASE: 2 NSSA: 0
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
interface LoopBack10
ip address 5.5.5.5 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route direct
#
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
ospf 100 router-id 5.5.5.5 vpn-instance vpn1
import-route bgp
domain-id 0.0.0.10
area 0.0.0.0
network 100.1.1.0 0.0.0.255
sham-link 5.5.5.5 6.6.6.6
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 40.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 120.1.1.2 255.255.255.0
#
ip address 40.1.1.2 255.255.255.0
mpls
mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
interface LoopBack10
ip address 6.6.6.6 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 40.1.1.0 0.0.0.255
#
ospf 100 router-id 6.6.6.6 vpn-instance vpn1
import-route bgp
domain-id 0.0.0.10
area 0.0.0.0
network 120.1.1.0 0.0.0.255
sham-link 6.6.6.6 5.5.5.5
#
return
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
ip address 20.1.1.1 255.255.255.0
ospf cost 10
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
#
sysname CE2
#
ip address 120.1.1.1 255.255.255.0
#
ip address 30.1.1.2 255.255.255.0
ospf cost 10
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network 120.1.1.0 0.0.0.255

#
return
l RTA configuration file

#
sysname RTA
#
ip address 20.1.1.2 255.255.255.0
#
ip address 30.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
8.9.13 Example for Configuring BGP AS Number Substitution

As shown in Figure 8-54, CE1 and CE2 belong to the same VPN. CE1 connects to PE1, and
CE2 connects to PE2. Both CE1 and CE2 use AS number 600.
The PEs and CEs need to set up EBGP peer relationships to allow communication between
VPN users.
Figure 8-54 Networking diagram for configuring BGP AS number substitution

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE2/0/0
20.1.1.1/24 30.1.1.1/24
PE1
PE2
GE1/0/0 GE2/0/0
20.1.1.2/24 P 30.1.1.1/24
GE1/0/0 GE1/0/0
10.1.1.2/24 10.2.1.2/24
VPN Backbone
AS 100
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE2
CE1
GE2/0/0 GE2/0/0
10.3.1.1/24 10.4.1.1/24
vpn1 vpn1
AS 600 AS 600

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network.
3. Set up an MP-IBGP peer relationship between PEs to exchange VPNv4 routes.
4. Configure a VPN instance and set the VPN target to 1:1 on PE1 and PE2 so that users in
the VPN can communicate with each other. Bind the VPN instance to the PE interfaces
connected to CEs to provide access for VPN users.
5. Set up EBGP peer relationships between the PEs and CEs and import routes of the CEs
into routing tables of the PEs.
6. Configure BGP AS number substitution on the PEs to enable them to accept routes with
the local AS number.
Procedure
Step 1 Configure basic BGP/MPLS IP VPN functions.
The configurations include the following:
l Configure OSPF on the MPLS backbone network so that the PEs and P can learn the
routes to the loopback interface of each other.
l Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up
MPLS LSPs.
l Set up an MP-IBGP peer relationship between PEs to exchange VPNv4 routes.
l Configure the VPN instance of VPN1 on PE2 and bind the VPN instance to the interface
connected to CE2.
l Configure the VPN instance of VPN1 on PE1 and bind the VPN instance to the interface
connected to CE1.
l Set up BGP peer relationships between PE1 and CE1 and between PE2 and CE2 to
import routes of CEs to PEs.
For detailed configuration, refer to 8.9.1 Example for Configuring BGP/MPLS IP VPN.
After the configuration is complete, run the display ip routing-table command on CE2 to
check the routing table. The routing table on CE2 contains the route to the network segment
(10.1.1.0/24) of interface that connects CE1 to PE1 but contains no route to the VPN
(10.3.1.0/24) of CE1. This is the same on CE1.
to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 D 10.2.1.2
10.2.1.0/24 Direct 0 0 D 10.2.1.1
10.2.1.1/32 Direct 0 0 D 127.0.0.1
10.2.1.255/32 Direct 0 0 D 127.0.0.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
10.4.1.0/24 Direct 0 0 D 10.4.1.1
10.4.1.1/32 Direct 0 0 D 127.0.0.1
10.4.1.255/32 Direct 0 0 D 127.0.0.1
Run the display ip routing-table vpn-instance command on the PEs to check the routing
table of the VPN instance. The VPN routing table has routes to the VPN of the CEs.

to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 IBGP 255 0 RD 1.1.1.9
10.2.1.0/24 Direct 0 0 D 10.2.1.2
10.2.1.2/32 Direct 0 0 D 127.0.0.1
10.2.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24 IBGP 255 0 RD 1.1.1.9
10.4.1.0/24 EBGP 255 0 D 10.2.1.1
Run the display bgp routing-table peer received-routes command on CE2. The command
output shows that CE2 did not accept the route to 10.3.1.0/24.
[CE2] display bgp routing-table peer 10.2.1.2 received-routes


*> 10.1.1.0/24 10.2.1.2 0 100?

10.2.1.0/24 10.2.1.2 0 0 100?
Step 2 Configure BGP AS number substitution.
Configure BGP AS number substitution on the PEs.
# Configure PE2. PE2 is used as an example.

[PE2] bgp 100
[PE2-bgp-vpn1] peer 10.2.1.1 substitute-as
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
Check the routing information accepted by CE2 and routing table on CE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE2] display bgp routing-table peer 10.2.1.2 received-routes


*> 10.1.1.0/24 10.2.1.2 0 100?

10.2.1.0/24 10.2.1.2 0 0 100?
*> 10.3.1.0/24 10.2.1.2 0 100 100?

to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 D 10.2.1.2
10.2.1.0/24 Direct 0 0 D 10.2.1.1
10.2.1.1/32 Direct 0 0 D 127.0.0.1
10.2.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24 EBGP 255 0 D 10.2.1.2
10.4.1.0/24 Direct 0 0 D 10.4.1.1
10.4.1.1/32 Direct 0 0 D 127.0.0.1
10.4.1.255/32 Direct 0 0 D 127.0.0.1
After configuring BGP AS number substitution on PE1, you can find that CE1 and CE2 can
[CE1] ping –a 10.3.1.1 10.4.1.1

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.1 255.255.255.0
#
ip address 10.3.1.1 255.255.255.0
#
bgp 600
#
ipv4-family unicast
import-route direct
#
return
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
peer 10.1.1.1 substitute-as
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return
#
sysname P

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
ip address 10.4.1.1 255.255.255.0
#
bgp 600
#
ipv4-family unicast
import-route direct
#
return
8.9.14 Example for Configuring the BGP SoO Attribute
When multiple CEs in a VPN site connect to different PEs, VPN routes advertised from the
CEs to the PEs may be sent back to the VPN site after the routes traverse the backbone
network. This may cause routing loops in the VPN site.
As shown in Figure 8-55, CE1 and CE2 belong to site 1; CE2 and CE3 connect to PE2. Site 1
and site 2 have the same AS number. The PEs and CEs run EBGP. PE1 uses MP-IGBP to
advertise the routes learned from CE1 to PE2. Then PE2 advertises these routes to CE2 and
CE3. However, CE2 has learned the routes through IGP in site 1. As a result, a routing loop
may occur in site 1.
To prevent routing loops in site 1, configure the BGP Site of Origin (SoO) attribute on the
PEs. When PE2 advertises routes to CE2, PE2 checks whether the SoO attribute of the routes
is the same as the locally configured SoO attribute. If so, PE2 does not advertise these routes
to CE2. PE2 can advertise the routes to CE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-55 Networking diagram for configuring the BGP SoO attribute
Loopback 1
1.1.1.1/32
Loopback 1
11.11.11.11/32 GE1/0/0 PE1
192.168.1.1/30
CE1
GE1/0/0
GE2/0/0
192.168.1.2/30
GE2/0/0 10.1.1.1/30
192.168.4.1/30
AS 65410
AS 100
GE2/0/0
192.168.4.2/30
site1 GE3/0/0
GE1/0/0 Loopback 1
10.1.1.2/30
192.168.2.2/30 33.33.33.33/32
CE2 GE1/0/0
Loopback 1 GE1/0/0 192.168.3.2/30
22.22.22.22/32 192.168.2.1/30 site2
PE2 GE2/0/0 CE3
192.168.3.1/30 AS 65410
Loopback 1
2.2.2.2/32
1. Configure an IP address for each interface and an IGP on the backbone network so that
PEs can communicate.
2. Enable MPLS and MPLS LDP on the backbone network so that LDP LSPs can be
established between the PEs.
3. Set up an MP-IBGP peer relationship between the PEs.
4. Configure VPN instances on PEs and bind the instances to the interfaces connected to
CEs.
5. Set up EBGP peer relationships between the PEs and CEs and enable AS number
substitution on the PEs.
6. Configure the BGP SoO attribute for the connected CEs on the PEs.
Procedure
Step 1 Configure an IP address for each interface and an IGP on the backbone network so that PEs
can learn routes to loopback interfaces of each other.
In this example, OSPF is configured.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 and CEs is similar to the configuration on PE1 and is not
mentioned here.
After the configuration is complete, run the display ip routing-table command on the PEs.
The command output shows that the PEs have learned the route to loopback interfaces of each
other.
to vpn-instance
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1 D 10.1.1.2
10.1.1.0/30 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.3/32 Direct 0 0 D 127.0.0.1
Step 2 Enable MPLS and MPLS LDP on the backbone network to set up LDP LSPs.
Enable MPLS and MPLS LDP globally and on interfaces of the PE.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
The configuration on PE2 is the same as the configuration on PE1.

After the configuration is complete, run the display mpls ldp lsp command on the PEs. The
command output shows the labels assigned to the routes to loopback interfaces on the peer
PEs. The information displayed on PE1 is used as an example.
LDP LSP Information

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1024 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.1.2 GE2/0/0
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 GE2/0/0
-------------------------------------------------------------------------------

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 2.2.2.2 connect-interface loopback1
[PE1-bgp] quit
The configuration on PE2 is similar to the configuration on PE1 and is not mentioned here.
For configuration details, refer to "Configuration Files".
command on the PEs. The command output shows that BGP peer relationships have been
established between the PEs. The information displayed on PE1 is used as an example.


PrefRcv
2.2.2.2 4 100 187 186 0 02:44:06

Established 1
Step 4 On each PE, configure a VPN instance, enable the IPv4 address family in the instance, and
bind the instance to the interfaces connected to the CEs.
# Configure PE1.
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:100
the PEs to check the configuration of VPN instances.
Step 5 Set up EBGP peer relationships between PEs and CEs, enable AS number substitution on the
PEs, and configure PEs to import routes from CEs.
In this configuration example, the two VPN sites have the same AS number. Therefore, AS
number substitution needs to be enabled on PE1 and PE2.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpna] peer 192.168.1.2 substitute-as
[PE1-bgp-vpna] quit
[PE1-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] network 11.11.11.11 32
[CE1-bgp] network 192.168.4.0 30
[CE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpna] quit
[PE2-bgp] quit
# Configure CE2.
[CE2] bgp 65410
[CE2-bgp] network 22.22.22.22 32
[CE2-bgp] network 192.168.4.0 30
[CE2-bgp] quit
# Configure CE3.
[CE3] bgp 65410
[CE3-bgp] network 33.33.33.33 32
[CE3-bgp] quit
on the PEs. The command output shows that the status of EBGP peer relationships between

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
PEs and CEs is Established. This indicates that EBGP peer relationships have been
established between PEs and CEs. The information displayed on PE1 is used as an example.
[PE1] display bgp vpnv4 vpn-instance vpna peer

VPN-Instance vpna, router ID 10.1.1.1:


PrefRcv
192.168.1.2 4 65410 224 231 0 03:02:12

Established 1
Run the display bgp vpnv4 routing-table command on the PEs. The command output shows
the routes sent from the PEs to the PEs. The following shows the routes sent from PE2 to
CE2.
[PE2] display bgp vpnv4 vpn-instance vpna routing-table peer 192.168.2.2
advertised-routes


*>i 11.11.11.11/32 192.168.2.1 0 100 100i

*> 22.22.22.22/32 192.168.2.1 0 100 100i
*> 33.33.33.33/32 192.168.2.1 0 100 100i
*>i 192.168.1.0/30 192.168.2.1 0 100?
*> 192.168.2.0/30 192.168.2.1 0 0 100?
*> 192.168.3.0/30 192.168.2.1 0 0 100?
Step 6 Configure the BGP SoO attribute on the PEs.
CE1 and CE2 belong to the same site, so you need to set the same BGP SoO attribute value
for the two CEs on PE1 and PE2. PE2 connects to two VPN sites, so you need to set different
SoO attribute value for the CEs.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpna] peer 192.168.1.2 soo 100:101
[PE1-bgp-vpna] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpna] quit
[PE2-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# After the configuration is complete, run the display bgp vpnv4 routing-table command on
PE2 again. The command output shows that the routes sent from PE2 to CE2 have changed
and the routes sent from PE2 to CE3 remain unchanged.
advertised-routes


*> 33.33.33.33/32 192.168.2.1 0 100 100i

*>i 192.168.1.0/30 192.168.2.1 0 100?
*> 192.168.2.0/30 192.168.2.1 0 0 100?
*> 192.168.3.0/30 192.168.2.1 0 0 100?
advertised-routes


*>i 11.11.11.11/32 192.168.3.1 0 100 100i

*> 22.22.22.22/32 192.168.3.1 0 100 100i
*>i 192.168.1.0/30 192.168.3.1 0 100?
*> 192.168.2.0/30 192.168.3.1 0 0 100?
*> 192.168.3.0/30 192.168.3.1 0 0 100?
*> 192.168.4.0/30 192.168.3.1 0 100 100i
# Run the display bgp vpnv4 routing-table command on PE2. The command output shows
the SoO attribute carried in the routes sent from PE2 to CE3.
[PE2] display bgp vpnv4 vpn-instance vpna routing-table 11.11.11.11 32


Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 11.11.11.11/32:
Label information (Received/Applied): 1029/NULL
From: 1.1.1.1 (1.1.1.1)
Route Duration: 00h11m51s
Relay Tunnel Out-Interface: GigabitEthernet3/0/0
Relay token: 0x3d
Original nexthop: 1.1.1.1
Qos information : 0x0
Ext-Community:RT <100 : 100>, SoO <100 : 101>
AS-path 65410, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, b
est, select, active, pre 255, IGP cost 1
Advertised to such 1 peers:
192.168.3.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# The preceding command output shows that after the BGP SoO attribute is configured, the
VPN routes received from CEs carry the SoO attribute, and PE2 does not send any route to
CE2. This indicates that the configuration of the BGP SoO attribute has taken effect.
----End
Configuration Files
sysname CE1
#
ip address 192.168.1.2 255.255.255.252
#
ip address 192.168.4.1 255.255.255.252
#
interface LoopBack1
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 11.11.11.11 255.255.255.255
network 192.168.4.0 255.255.255.252
#
return
#
sysname CE2
#
ip address 192.168.2.2 255.255.255.252
#
ip address 192.168.4.2 255.255.255.252
#
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 22.22.22.22 255.255.255.255
network 192.168.4.0 255.255.255.252
#
return
#
sysname PE1
#
ipv4-family
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls lsr-id 1.1.1.1

mpls
#
mpls ldp
#
ip address 192.168.1.1 255.255.255.252
#
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
peer 192.168.1.2 as-number 65410
peer 192.168.1.2 soo 100:101
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 192.168.2.1 255.255.255.252
#
ip address 192.168.3.1 255.255.255.252
#
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
peer 192.168.2.2 as-number 65410
peer 192.168.2.2 soo 100:101
peer 192.168.3.2 as-number 65410
peer 192.168.3.2 soo 100:102
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return
#
sysname CE3
#
ip address 192.168.3.2 255.255.255.252
#
interface LoopBack1
ip address 33.33.33.33 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
network 33.33.33.33 255.255.255.255
#
return
8.9.15 Example for Configuring CE Dual-homing
It is a trend to transmit all telecommunication services on an IP network. Key services such
3G/NGN, IPTV streaming media, and VPN services require high reliability on networks. In
addition to improving the reliability of the network devices, you can improve the link
reliability by configuring fast route convergence, fault detection, fast reroute, and route
backup.
On the access layer, the CE dual-homing networking is a common method to improve the
network reliability. A dual-homed CE connects to two PEs that belong to the same VPN as the

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CE. In this networking, the CE connects to the backbone network through two links. The two
links work in load balancing mode or active/standby mode.
As shown in Figure 8-56, CE1 is located in site1 of vpn1, and CE2 is located in site2 of vpn1.
CE1 connects to PE1 and PE2, and CE2 connects to PE3 and PE4.
If the data traffic volume from CE1 to CE2 is large but traffic volume from CE2 to CE1 is
small, the data traffic from CE1 to CE2 can be transmitted in load balancing mode. The data
traffic from CE2 to CE1 is transmitted through PE4, and PE3 only works as a backup.
Figure 8-56 Networking diagram for configuring CE dual-homing
VPN backbone
AS 100
GE1/0/0 GE2/0/0 GE2/0/0

GE1/0/0 GE1/0/0 GE2/0/0
CE1 CE2
PE1 P1 PE3
GE1/0/0 GE1/0/0
GE2/0/0 GE2/0/0
GE3/0/0 PE2 P2 PE4 GE3/0/0
GE2/0/0 GE2/0/0
GE1/0/0 GE1/0/0 GE1/0/0 GE2/0/0
vpn1 site1 vpn1 site2
AS 65410 Loopback1 Loopback1 Loopback1 AS 65420
Device Interface and IP Address Device Interface and IP Address

Loopback1
PE2
PE1 1.1.1.1/32 PE2
GE1/0/0 GE2/0/0
GE1/0/0 GE2/0/0 10.2.1.2/30 100.2.1.1/30
10.1.1.2/30 100.1.1.1/30
Loopback1
PE1 2.2.2.2/32
Loopback1
P2
P1 5.5.5.5/32 P2
GE1/0/0 GE2/0/0
GE1/0/0 GE2/0/0
100.2.1.2/30 100.4.1.1/30
100.1.1.2/30 100.3.1.1/30
P1 Loopback1
6.6.6.6/32
Loopback1 Loopback1
PE3 3.3.3.3/32 PE4 4.4.4.4/32
GE1/0/0 GE2/0/0 GE1/0/0 GE2/0/0

100.3.1.2/30 10.3.1.1/30 100.4.1.2/30 10.4.1.1/30
PE3 PE4

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CE1 CE2 GE
/0 10 1/0
/0 0
CE1 E1 .1/3 .3.
1.2 0
/
CE2
G .1
.1 /30
GE3/0/0 10
GE3/0/0
10.5.1.1/24 0
2 /0/ 0
10.6.1.1/24
G
GE .2/3
E2 .1/
10
. 1
/0 30
4
.2
.
10
/0
.1
1. Configure basic BGP/MPLS IP VPN functions.

2. In the BGP view of CE1, configure load balancing for traffic sent to CE2.
3. Increase the MED value of the BGP-VPN route on PE3 to ensure that the next hop of the
route selected by CE2 to the customer network connected to CE1 is PE4.
Procedure
Step 1 Configure an IGP on the MPLS backbone network so that PEs and Ps can communicate with
each other.
# Configure PE1.
# Set IP addresses of interfaces. The IP addresses of the loopback interfaces must use a 32-bit
mask.

# Configure the ISIS protocol to advertise routes of the interfaces.

[PE1] isis 1
[PE1-isis-1] quit
[PE1-LoopBack1] isis enable 1
The configuration on PE2, PE3, PE4, P1, and P2 is similar to the configuration on PE1 and is
not mentioned here.
After the configuration is complete, run the display ip routing-table command. The
command output shows that PE1 and PE3 can learn the routes of Loopback1 interface of each
other; PE2 and PE4 can learn routes of Loopback1 interface of each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
LDP LSPs.
# Configure PE1.
# Enable MPLS and LDP in the system view, set the LSR ID to the IP address of the loopback
interface, and trigger the LSP.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Enable MPLS and LDP on the interface connected to the backbone network.
# The configuration on PE2, PE3, PE4, P1, and P2 is similar to the configuration on PE1 and
is not mentioned here.
After the configuration is complete, LDP sessions can be set up between PE1 and P1, and
between PE3 and P1. Run the display mpls ldp session command. The command output
shows that the status of the sessions is Operational. Run the display mpls ldp lsp command.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 5.5.5.5 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1024 DS/5.5.5.5
3.3.3.3/32 NULL/1025 - 100.1.1.2 GE2/0/0
3.3.3.3/32 1025/1025 5.5.5.5 100.1.1.2 GE2/0/0
5.5.5.5/32 NULL/3 - 100.1.1.2 GE2/0/0
5.5.5.5/32 1024/3 5.5.5.5 100.1.1.2 GE2/0/0
-----------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1.
# Create a VPN instance and set the RD and VPN target of the VPN instance. The VPN target
set on the local PE must match the VPN target of the MP-BGP peer PE so that the sites of the
same VPN can communicate with each other.

# Bind the VPN instance to the interface connected to the CE and set the IP address of the
interface.
# Configure PE2.
interface.
# Configure PE3.
interface.
# Configure PE4.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface.
[PE4]interface gigabitethernet 2/0/0
# Configure CE1.
The configuration on other CEs is similar to the configuration on Spoke-CE1 and is not
mentioned here.
the PEs to check the configuration of VPN instances.

VPN-Instance Name and ID : vpn1, 1

Address family ipv4
Create date : 2012/07/25 00:58:17
Log Interval : 5
Step 4 Set up MP-IBGP peer relationships between the PEs.
# Configure PE1.
# Specify PE3 as the IGBP peer and use the IP address of the loopback interface to set up an
IBGP connection with the peer.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] bgp 100

# Enter the VPNv4 address family view and enable the local PE to exchange VPN routing
information with the IGBP peer.
[PE1-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
# Configure PE4.
[PE4] bgp 100
[PE4-bgp] quit
PEs. The command output shows that the BGP peer relationships have been set up between
the PEs and are in Established state.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

3.3.3.3 4 100 70 81 0 01:00:23 Established 3
Step 5 Configure EBGP between the PE and the CEs to import the VPN routes.
# Configure CE1.
# Enable BGP, specify PE1 and PE2 as EBGP peers, and import direct routes.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure PE1.
# Enable BGP, specify CE1 as the EBGP peer, and import direct routes.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
# Configure CE2.
# Enable BGP, specify PE3 and PE4 as EBGP peers, and import direct routes.
[CE2] bgp 65420
[CE2-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp-vpn1] quit
[PE3-bgp] quit
# Configure PE4.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE4] bgp 100

[PE4-bgp-vpn1] quit
[PE4-bgp] quit
relationships have been set up between the PEs and CEs and are in Established state. Each PE
can ping its connected CE.


10.1.1.1 4 65410 408 435 0 06:16:09 Established 5
[PE1] ping -vpn-instance vpn1 10.1.1.1

PING 10.1.1.1 : 56 data bytes, press CTRL_C to break

0.00% packet loss
Step 6 On CE1, configure load balancing for the traffic sent from CE1 to CE2.
[CE1] bgp 65410
[CE1-bgp-af-ipv4] maximum load-balancing 2
[CE1-bgp] quit
Step 7 Configure a routing policy on PE3 to increase the MED value of the BGP routes advertised to
CE2. Then the traffic sent from CE2 to CE1 is forwarded by PE4, and PE3 is a backup of
PE4.
[PE3] route-policy policy1 permit node 10
[PE3-route-policy] apply cost 120
[PE3-route-policy] quit
[PE3] bgp 100
[PE3-bgp-vpn1] peer 10.3.1.2 route-policy policy1 export
[PE3-bgp-vpn1] quit
[PE3-bgp] quit
Check the BGP routing table on CE2. In the routing table, the route to 10.5.1.0/30 advertised
by PE3 has a MED value of 120, larger than the MED value of the route advertised by PE4
(the default MED value is 0). Therefore, CE2 selects the route advertised by PE4.
[CE2] display bgp routing-table


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

*> 10.5.1.0/24 10.4.1.1 0 100 65410?
* 10.3.1.1 120 0 100 65410?
*> 10.6.1.0/24 0.0.0.0 0 0 ?
*> 10.1.1.0/30 10.3.1.1 120 0 100?
* 10.4.1.1 0 100 65410?
*> 10.2.1.0/30 10.4.1.1 0 100?
* 10.3.1.1 120 0 100 65410?
*> 10.3.1.0/30 0.0.0.0 0 0 ?
* 10.3.1.1 120 0 100?
*> 10.4.1.0/30 0.0.0.0 0 0 ?
* 10.4.1.1 0 0 100?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/30 0.0.0.0 0 0 ?
#If the configuration is successful:
#The display ip routing-table command on CE1 displays the routes to the customer network
connected to CE2. The routes work in load balancing mode.
to vpn-instance
------------------------------------------------------------------------------
10.5.1.0/24 Direct 0 0 D 10.5.1.1

10.5.1.1/32 Direct 0 0 D 127.0.0.1
10.5.1.255/32 Direct 0 0 D 127.0.0.1
10.6.1.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.2.1.2
10.1.1.0/30 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.3/32 Direct 0 0 D 127.0.0.1
10.2.1.0/30 Direct 0 0 D 10.2.1.1
10.2.1.1/32 Direct 0 0 D 127.0.0.1
10.2.1.3/32 Direct 0 0 D 127.0.0.1
10.3.1.0/30 EBGP 255 0 D 10.1.1.2
10.4.1.0/30 EBGP 255 0 D 10.2.1.2
# The display ip routing-table command on CE2 displays the routes to the customer network
connected to CE1. The next hop of the route is 10.4.1.1, IP address of the interface that
connects PE4 to CE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

to vpn-instance
------------------------------------------------------------------------------
10.5.1.0/24 EBGP 255 0 D 10.4.1.1

10.6.1.0/24 Direct 0 0 D 10.6.1.1
10.6.1.1/32 Direct 0 0 D 127.0.0.1
10.6.1.255/32 Direct 0 0 D 127.0.0.1
10.1.1.0/30 EBGP 255 120 D 10.3.1.1
10.2.1.0/30 EBGP 255 0 D 10.4.1.1
10.3.1.0/30 Direct 0 0 D 10.3.1.2
10.3.1.2/32 Direct 0 0 D 127.0.0.1
10.3.1.3/32 Direct 0 0 D 127.0.0.1
10.4.1.0/30 Direct 0 0 D 10.4.1.2
10.4.1.2/32 Direct 0 0 D 127.0.0.1
10.4.1.3/32 Direct 0 0 D 127.0.0.1
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.252
#
ip address 10.2.1.1 255.255.255.252
#
ip address 10.5.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
maximum load-balancing 2
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.252
#
ip address 100.1.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
import-route direct
#
return

#
sysname PE2
#
ipv4-family
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

ip address 10.2.1.2 255.255.255.252
#
ip address 100.2.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 4.4.4.4 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.4 enable
#
import-route direct
#
return
#
sysname P1
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0005.00
#
ip address 100.1.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 100.3.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
return
#
sysname P2
#
mpls lsr-id 6.6.6.6
mpls
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
isis 1
network-entity 10.0000.0000.0006.00
#
ip address 100.2.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 100.4.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 1
#
return
#
sysname PE3
#
ipv4-family
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 100.3.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 10.3.1.1 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

apply cost 120
#
return
#
sysname PE4
#
ipv4-family
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 100.4.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 10.4.1.1 255.255.255.252
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
isis enable 1
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
import-route direct
#
return
#
sysname CE2
#
ip address 10.3.1.2 255.255.255.252
#
ip address 10.4.1.2 255.255.255.252
#
ip address 10.6.1.1 255.255.255.0
#
bgp 65420

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ipv4-family unicast
import-route direct
#
return
8.9.16 Example for Configuring VPN FRR
As shown in Figure 8-57, CE1 dual-homing networking is deployed to improve reliability of
VPN data transmission. Link_A is the primary link, and Link_B is the backup link. The
customer wants to transmit VPN services through the primary link and hopes that VPN traffic
can be quickly switched to the backup link when the primary link fails.
Figure 8-57 Networking diagram for configuring VPN FRR

VPN backbone Loopback1
2.2.2.2/32
GE1/0/0 GE2/0/0
100.1.1.2/30 10.1.1.2/30
GE2/0/0 PE2 GE1/0/0 vpn1 site

100.1.1.1/30 10.1.1.1/30
Link_A
AS65410
PE1 CE1
Link_B GE3/0/0
GE3/0/0 GE2/0/0 10.3.1.1/24
PE3
100.2.1.1/30 10.2.1.1/30
Lo .1.1
GE1/0/0 GE2/0/0
1
op .1
100.2.1.2/30 10.2.1.2/30
ba /32
AS100
ck
1
Loopback1
3.3.3.3/32
1. Configure OSPF on PE1, PE2, and PE3 to implement interworking on the backbone
network.
set up LDP LSPs.
3. Configure a VPN instance on PE1, PE2, and PE3. On PE2 and PE3, bind the VPN
instance to the interfaces connected to CE1.
4. Set up EBGP peer relationships between PE2 and CE1 and between PE3 and CE1. Set
up MP-IBGP peer relationships between the PEs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. On PE1, configure a routing policy for VPN FRR, configure the backup next hop, and
enable VPN FRR. When VPN FRR is not required, run the undo vpn frr command to
disable this function.
6. Configure multi-hop BFD on PE1 and PE2.
Procedure
# Configure PE1.
The configuration on PE2, PE3, and CE1 is similar to the configuration on PE1 and is not
mentioned here.
Step 2 Configure OSPF on the MPLS backbone network for IP connectivity between the PEs on the
backbone network.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 and PE3 is similar to the configuration on PE1 and is not
mentioned here.
LDP LSPs.
# Configure PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Configure PE3.

[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
Run the display mpls lsp command on the PEs. The command output shows that LSPs are
established between PE1 and PE2 and between PE1 and PE3. The information displayed on
PE1 is used as an example.
[PE1] display mpls lsp
----------------------------------------------------------------------
----------------------------------------------------------------------
1.1.1.1/32 3/NULL -/-
3.3.3.3/32 NULL/3 -/GE3/0/0
3.3.3.3/32 1025/3 -/GE3/0/0
2.2.2.2/32 NULL/3 -/GE2/0/0
2.2.2.2/32 1024/3 -/GE2/0/0
Step 4 Configure VPN instances on PEs and bind the instances to the interfaces connected to CE1.
# Configure PE1.
# Configure PE2.
# Configure PE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 5 Import direct VPN routes to PE1. Set up EBGP peer relationships between PE2 and CE1 and
between PE3 and CE1 to import VPN routes.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp-vpn1] quit
[PE3-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] network 10.3.1.0 24
[CE1-bgp] quit
After the configuration is complete, run the display bgp vpnv4 all peer command on PE2
and PE3. The command output shows that PE2 and PE3 have set up EBGP peer relationships
with CE1. The peer relationships are in Established state.


PrefRcv

10.1.1.1 4 65410 966 968 0 16:01:19
Established 5

# Configure PE1.
[PE1] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp] quit
Run the display bgp vpnv4 all peer command on the PEs. The command output shows that
an MP-IBGP peer relationship has been set up between the PEs and is in Established state.

2.2.2.2 4 100 20 17 0 00:13:26 Established 5

3.3.3.3 4 100 24 19 0 00:17:18 Established 5
Step 7 Configure the VPN FRR routing policy.

[PE1] ip ip-prefix vpn_frr_list permit 2.2.2.2 32
[PE1] route-policy vpn_frr_rp permit node 10
[PE1-route-policy] if-match ip next-hop ip-prefix vpn_frr_list
[PE1-route-policy] apply backup-nexthop 3.3.3.3
[PE1-route-policy] quit
Step 8 Configure multi-hop BFD.

# Configure multi-hop BFD on PE1.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd for_vpn_frr bind peer-ip 2.2.2.2
[PE1-bfd-session-for_vpn_frr] discriminator local 10
[PE1-bfd-session-for_vpn_frr] discriminator remote 20
[PE1-bfd-session-for_vpn_frr] min-tx-interval 100
[PE1-bfd-session-for_vpn_frr] min-rx-interval 100
[PE1-bfd-session-for_vpn_frr] commit
[PE1-bfd-session-for_vpn_frr] quit
# Configure multi-hop BFD on PE2.

[PE2] bfd
[PE2-bfd] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] bfd for_vpn_frr bind peer-ip 1.1.1.1

[PE2-bfd-session-for_vpn_frr] discriminator local 20
[PE2-bfd-session-for_vpn_frr] discriminator remote 10
[PE2-bfd-session-for_vpn_frr] min-tx-interval 100
[PE2-bfd-session-for_vpn_frr] min-rx-interval 100
[PE2-bfd-session-for_vpn_frr] commit
[PE2-bfd-session-for_vpn_frr] quit
After the configuration is complete, run the display bfd session all verbose command on PE1
and PE2. The command output shows that a multi-hop BFD session is established and the
status of the BFD session is Up.
Step 9 Enable VPN FRR.
# Enable VPN FRR on PE1.
[PE1-vpn-instance-vpn1-af-ipv4] vpn frr route-policy vpn_frr_rp

# Check the backup next hop, backup label, and backup tunnel ID on PE1.
[PE1] display ip routing-table vpn-instance vpn1 10.3.1.0 verbose
to vpn-instance
------------------------------------------------------------------------------
Routing Table : vpn1
Summary Count : 1
Destination: 10.3.1.0/24
Protocol: IBGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 2.2.2.2 Neighbour: 2.2.2.2
State: Active Adv Relied Age: 00h15m06s
Tag: 0 Priority: low
Label: 15361 QoSInfo: 0x0
IndirectID: 0x13
RelayNextHop: 100.1.1.2 Interface: GigabitEthernet2/0/0
TunnelID: 0x31 Flags: RD
BkNextHop: 3.3.3.3 BkInterface:GigabitEthernet3/0/0
BkLabel: 15362 SecTunnelID: 0x0
BkPETunnelID: 0x32 BkPESecTunnelID: 0x0
BkIndirectID: 0x15
# Run the shutdown command on GE1/0/0 of PE2 to simulate a link failure.

[PE2-GigabitEthernet1/0/0] shutdown
# Run the display ip routing-table vpn-instance command on the PE1 again. The command
output shows that the next hop of the route to 10.3.1.0/24 is 3.3.3.3.
[PE1] display ip routing-table vpn-instance vpn1 10.3.1.0 verbose
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Label: 15362 QoSInfo: 0x0
IndirectID: 0x15
RelayNextHop: 100.2.1.2 Interface: GigabitEthernet3/0/0
TunnelID: 0x32 Flags: RD
----End
Configuration Files
#
sysname PE1
#
ipv4-family
vpn frr route-policy vpn_frr_rp
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip address 100.1.1.1 255.255.255.252
mpls
mpls ldp
#
ip address 100.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bfd for_vpn_frr bind peer-ip 2.2.2.2
discriminator local 10
discriminator remote 20
min-tx-interval 100
min-rx-interval 100
commit
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
import-route direct
#
ospf 1
area 0.0.0.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network 100.1.1.0 0.0.0.3

network 100.2.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
#
ip ip-prefix vpn_frr_list index 10 permit 2.2.2.2 32
#
route-policy vpn_frr_rp permit node 10
if-match ip next-hop ip-prefix vpn_frr_list
apply backup-nexthop 3.3.3.3
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.252
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.252
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bfd for_vpn_frr bind peer-ip 1.1.1.1
min-tx-interval 100
min-rx-interval 100
commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname PE3
#
ipv4-family
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 100.2.1.2 255.255.255.252
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 100.2.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
#
Return
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.252
#
ip address 10.2.1.1 255.255.255.252
#
ip address 10.3.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
network 10.3.1.0 255.255.255.0
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
return
8.9.17 Example for Configuring IP FRR for VPN Routes
When multiple CEs in a site connect to the same PE, the PE learns multiple IP VPN routes
with the same VPN prefix. To use one of IP VPN routes as the primary route and the other as
backup routes, configure IP FRR for VPN routes. Then the PE generates primary and backup
routes to the VPN prefix. When the link of the primary route fails, IP traffic on the VPN is
quickly switched to the link of a backup route.
As shown in Figure 8-58, the PE has two OSPF routes to RTA. The route on Link_A is the
optimal route, and the route on Link_B is the suboptimal route. IP FRR for VPN routes needs
to be configured on the PE to quickly switch IP traffic on the VPN to Link_B when Link_A
fails.
Figure 8-58 Networking diagram for configuring IP FRR for VPN routes
CE1
vpn1 site
GE1/0/0 GE2/0/0
10.1.1.2/30 10.3.1.1/30
GE1/0/0 GE1/0/0
10.1.1.1/30 10.3.1.2/30 GE3/0/0
Link_A 10.5.1.1/24
VPN PE RTA
backbone Link_B
GE2/0/0 GE2/0/0
10.2.1.1/30 GE2/0/010.4.1.2/30
GE1/0/0
10.2.1.2/30 10.4.1.1/30
CE2
1. Enable basic OSPF functions on each router so that routes to RTA can be advertised to
CE1 and CE2.
2. On the PE, configure VPN instance vpn1, bind GE1/0/0 and GE2/0/0 to vpn1, and
configure OSPF multi-instance.
3. Set the cost on GE2/0/0 of the PE and RTA both to a large value so that OSPF
preferentially selects Link_A.
4. Configure IP FRR for VPN routes on the PE.
5. Configure BFD to detect the link status.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Assign IP addresses to interfaces.
# Assign IP addresses to the interfaces on RTA.

[Huawei] sysname RTA
The configuration on PE, CE1, and CE2 is similar to the configuration on RTA and is not
mentioned here.
Step 2 Configure OSPF on CE1, CE2, and RTA.
# Configure CE1.
[CE1] ospf 1
[CE1-ospf] area 0
[CE1-ospf-1] quit
The configuration on CE2 and RTA is similar to the configuration on CE1 and is not
mentioned here.
After the configuration is complete, CE1, CE2, and RTA can learn interface addresses from
each other. The information displayed on CE1 is used as an example.
to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.3/32 Direct 0 0 D 127.0.0.1
10.3.1.0/30 Direct 0 0 D 10.3.1.1
10.3.1.1/32 Direct 0 0 D 127.0.0.1
10.3.1.3/32 Direct 0 0 D 127.0.0.1
10.2.1.0/30 OSPF 10 3 D 10.3.1.2
10.4.1.0/30 OSPF 10 2 D 10.3.1.2
10.5.1.0/24 OSPF 10 2 D 10.3.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 3 Configure a VPN instance and OSPF multi-instance on the PE.

# On the PE, configure VPN instance vpn1 and bind GE1/0/0 and GE2/0/0 to vpn1.
[PE] ip vpn-instance vpn1
[PE-vpn-instance-vpn1] ipv4-family
[PE-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[PE-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[PE-vpn-instance-vpn1-af-ipv4] quit
[PE-vpn-instance-vpn1] quit
[PE-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[PE-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
# Configure OSPF multi-instance on the PE.

[PE] ospf vpn-instance vpn1
[PE-ospf-1] area 0
[PE-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.3
[PE-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.3
[PE-ospf-1-area-0.0.0.0] quit
[PE-ospf-1] quit
Step 4 Set the cost on the OSPF interface.

# Set the cost on GE2/0/0 of the PE to 100 so that OSPF preferentially selects Link_A.
[PE-GigabitEthernet2/0/0] ospf cost 100
# Set the cost on GE2/0/0 of RTA to 100 so that OSPF preferentially selects Link_A.
[RTA-GigabitEthernet2/0/0] ospf cost 100
Step 5 Configure a routing policy.

# Configure a routing policy, a backup next hop, and a backup outbound interface on the PE.
Configure an if-match clause.
[PE] ip ip-prefix frr1 permit 10.5.1.0 24
[PE] route-policy ip_frr_rp permit node 10
[PE-route-policy] if-match ip-prefix frr1
[PE-route-policy] apply backup-nexthop 10.2.1.2
[PE-route-policy] apply backup-interface gigabitethernet 2/0/0
[PE-route-policy] quit
Step 6 Configure association between BFD and IP FRR.

# Configure the PE.
[PE] bfd
[PE-bfd] quit
[PE] bfd for_ip_frr bind peer-ip 10.1.1.2 vpn-instance vpn1 interface
gigabitethernet 1/0/0
[PE-bfd-session-for_ip_frr] discriminator local 10
[PE-bfd-session-for_ip_frr] discriminator remote 20
[PE-bfd-session-for_ip_frr] min-tx-interval 100
[PE-bfd-session-for_ip_frr] min-rx-interval 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE-bfd-session-for_ip_frr] commit
[PE-bfd-session-for_ip_frr] quit
# Configure CE1.
[CE1] bfd
[CE1-bfd] quit
[CE1] bfd for_ip_frr bind peer-ip 10.1.1.1 interface gigabitethernet 1/0/0
[CE1-bfd-session-for_ip_frr] discriminator local 20
[CE1-bfd-session-for_ip_frr] discriminator remote 10
[CE1-bfd-session-for_ip_frr] min-tx-interval 100
[CE1-bfd-session-for_ip_frr] min-rx-interval 100
[CE1-bfd-session-for_ip_frr] commit
[CE1-bfd-session-for_ip_frr] quit
# Run the display bfd session all verbose command on the PE and CE1. The command
output shows that the BFD session status is Up.
Step 7 Enable IP FRR for VPN routes.
[PE] ip vpn-instance vpn1
[PE-vpn-instance-vpn1] ipv4-family
[PE-vpn-instance-vpn1-af-ipv4] ip frr route-policy ip_frr_rp
[PE-vpn-instance-vpn1-af-ipv4] quit
[PE-vpn-instance-vpn1] quit
Step 8 Verify the configurations.

# Run the display ip routing-table vpn-instance command on the PE. The command output
shows that the next hop of the route to 10.5.1.0/24 is 10.1.1.2, and the route has a backup next
hop and a backup outbound interface.
[PE] display ip routing-table vpn-instance vpn1 10.5.1.0 verbose
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
Protocol: OSPF Process ID: 1
State: Active Adv Age: 00h00m03s
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthetnet1/0/0
TunnelID: 0x0 Flags: D
BkNextHop: 10.2.1.2 BkInterface: GigabitEthetnet2/0/0
BkLabel: NULL SecTunnelID: 0x0
BkIndirectID: 0x0
# Run the shutdown command on GE1/0/0 of CE1 to simulate a link failure.

[CE1-GigabitEthernet1/0/0] shutdown
# Run the display ip routing-table vpn-instance command on the PE again. The command
output shows that the next hop of the route to 10.5.1.0/24 is 10.2.1.2.
[PE] display ip routing-table vpn-instance vpn1 10.5.1.0 verbose
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Protocol: OSPF Process ID: 1

State: Active Adv Age: 00h01m03s
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthetnet2/0/0
TunnelID: 0x0 Flags: D
BkNextHop: 10.2.1.2 BkInterface: GigabitEthetnet2/0/0
BkLabel: NULL SecTunnelID: 0x0
BkIndirectID: 0x0
----End
Configuration Files
l PE configuration file
#
sysname PE
#
ipv4-family
ip frr route-policy ip_frr_rp
#
bfd
#
ip address 10.1.1.1 255.255.255.252
#
ip address 10.2.1.1 255.255.255.252
ospf cost 100
#
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.2.1.0 0.0.0.3
#
ip ip-prefix frr1 index 10 permit 10.5.1.0 24
#
route-policy ip_frr_rp permit node 10
if-match ip-prefix frr1
apply backup-nexthop 10.2.1.2
apply backup-interface GigabitEthernet2/0/0
#
bfd for_ip_frr bind peer-ip 10.1.1.2 vpn-instance vpn1 interface
GigabitEthernet 1/0/0
min-tx-interval 100
min-rx-interval 100
commit
#
return

#
sysname CE1
#
bfd
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.2 255.255.255.252
#
ip address 10.3.1.1 255.255.255.252
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.3.1.0 0.0.0.3
#
bfd for_ip_frr bind peer-ip 10.1.1.1 interface GigabitEthernet 1/0/0
min-tx-interval 100
min-rx-interval 100
commit
#
return

#
sysname CE2
#
ip address 10.2.1.2 255.255.255.252
#
ip address 10.4.1.1 255.255.255.252
#
ospf 1
area 0.0.0.0
network 10.2.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
#
return
l RTA configuration file

#
sysname RTA
#
ip address 10.3.1.2 255.255.255.252
#
ip address 10.4.1.2 255.255.255.252
ospf cost 100
#
ip address 10.5.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.3.1.0 0.0.0.3
network 10.4.1.0 0.0.0.3
area 0.0.0.2
network 10.5.1.0 0.0.0.255
#
return
8.9.18 Example for Configuring VPN GR
NOTE
Only the AR3260 can be used in this scenario.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 8-59, CE1 and CE2 belong to the same VPN. PE1, P, PE2 on the
backbone network belong to the same AS and use the IS-IS protocol to exchange routing
information. CE1 connects to PE1, and CE2 connects to PE2. BGP runs between CE1 and
PE1, and OSPF runs between CE2 and PE2.
Figure 8-59 VPN GR networking

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE1/0/0
100.1.1.1/30 100.2.1.2/30
PE1 PE2
GE1/0/0 GE2/0/0
GE1/0/0 100.1.1.2/30 P 100.2.1.1/30 GE2/0/0
10.1.1.2/30 10.2.1.2/30
GE1/0/0 GE1/0/0
10.1.1.1/30 10.2.1.1/30
CE1 CE2

2. Configure IGP GR, BGP GR, and LDP GR on the backbone network. Configure GR for
the routing protocols running between the PE and CE devices to ensure uninterrupted
VPN traffic forwarding when an active/standby switchover occurs on any of the CE, PE,
and P devices.
Procedure
Step 1 Configure IP addresses for the interfaces on the backbone network.
# Configure PE1.
The configurations of PE2 and P are similar to the configuration of PE1, and are not
mentioned here.
Step 2 Configure basic BGP/MPLS IP VPN functions on the backbone network.
Configure IS-IS as the IGP on the backbone network, enable LDP on PE1 and PE2, and set up
an MP-IBGP peer relationship between PE1 and PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] isis 1
[PE1-isis-1] quit
[PE1] bgp 100
[PE1-bgp] quit
# Configure P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P] isis 1
[P-isis-1] network-entity 10.0000.0000.0002.00
[P-isis-1] quit
[P-LoopBack1] isis enable 1
[P-LoopBack1] quit
[P-GigabitEthernet1/0/0] isis enable 1
[P-GigabitEthernet2/0/0] isis enable 1
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] isis 1
[PE2-isis-1] quit
[PE2] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE2-bgp] quit
After the configuration is complete, run the display isis peer command on PE1 or PE2. You
can see that the IS-IS neighbor relationship is in Up state. Run the display bgp vpnv4 all
peer command, and you can see that the BGP peer relationship has been set up and is in
Established state. Run the display mpls ldp session command, and you can see that an LDP
session has been set up and the session status is Operational.
Step 3 Configure a VPN instance on the PE devices and bind the instance to the interfaces connected
to the CE devices.
Configure VPN instance vpn1 on PE1 and bind it to the interface connected to CE1.
Configure VPN instance vpn1 on PE2 and bind it to the interface connected to CE2. Set up an
EBGP peer relationship between CE1 and PE1. Set up an OSPF neighbor relationship
between CE2 and PE2.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE2.
[PE2-ospf-2] area 0
[PE2-ospf-2] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] bgp 100

[PE2-bgp-vpn1] quit
[PE2-bgp] quit
# Configure CE2.
[CE2] ospf 2
[CE2-ospf-2] area 0
[CE2-ospf-2] import-route direct
[CE2-ospf-2] quit
The basic BGP/MPLS IP VPN configuration is complete, and CE1 and CE2 can communicate
with each other.
Step 4 Configure IGP GR on the backbone network.
Configure IGP GR on PE1, P, and PE2.
# Configure PE1.
[PE1] isis 1
[PE1-isis-1] graceful-restart
[PE1-isis-1] quit
# Configure P.
[P] isis 1
[P-isis-1] graceful-restart
[P-isis-1] quit
# Configure PE2.
[PE2] isis 1
[PE2-isis-1] graceful-restart
[PE2-isis-1] quit
Run the display isis graceful-restart status command on PE1, P, and PE2. The command
output shows that IS-IS GR has been configured successfully.
The display on PE1 is used as an example:
[PE1] display isis graceful-restart status
Restart information for ISIS(1)

-------------------------------
IS-IS(1) Level-1 Restart Status

Restart Interval: 300
SA Bit Supported
Total Number of Interfaces = 2
Restart Status: RESTART COMPLETE
IS-IS(1) Level-2 Restart Status

Restart Interval: 300
SA Bit Supported
Total Number of Interfaces = 2
Restart Status: RESTART COMPLETE
Step 5 Configure MPLS LDP GR on the backbone network.

Configure MPLS LDP GR on PE1, P, and PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1.
[PE1] mpls ldp
[PE1-mpls-ldp] graceful-restart
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls ldp
[P-mpls-ldp] graceful-restart
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls ldp
[PE2-mpls-ldp] graceful-restart
[PE2-mpls-ldp] quit
Step 6 Configure GR for the routing protocols running between the PE and CE devices.
Configure BGP GR on PE1 and CE1. Configure OSPF GR on PE2 and CE2.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] graceful-restart
[PE1-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] graceful-restart
[CE1-bgp] quit
# Configure PE2.
[PE2-ospf-2] opaque-capability enable
[PE2-ospf-2] graceful-restart
[PE2-ospf-2] quit
# Configure CE2.
[CE2] ospf 2
[CE2-ospf-2] opaque-capability enable
[CE2-ospf-2] graceful-restart
[CE2-ospf-2] quit
Run the display ospf brief command on PE2 or CE2. The command output shows that OSPF
GR has been configured successfully.
[PE2] display ospf brief

OSPF Protocol Information
RouterID: 10.2.1.2 Border Router: AREA AS

ECA-route-type: 0x0306
Route Tag: 3489661028
PE Router, Multi-VPN-Instance is enabled
Opaque Capable
Global DS-TE Mode: Non-Standard IETF Mode
Graceful-restart capability: planned and un-planned, totally
Helper support capability : enabled
filter capability : disabled
policy capability : strict lsa check, planned and un-planned
Applications Supported: MPLS Traffic-Engineering

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Spf-schedule-interval: max 10000ms, start 500ms, hold 1000ms

Default ASE parameters: Metric: 1 Tag: 1 Type: 2
Route Preference: 10
ASE Route Preference: 150
SPF Computation Count: 17
RFC 1583 Compatible
Retransmission limitation is disabled
Area Count: 1 Nssa Area Count: 0
ExChange/Loading Neighbors: 0
Process total up interface count: 1
Process valid up interface count: 1
Area: 0.0.0.0 (MPLS TE not enabled)

Authtype: None Area flag: Normal
SPF scheduled Count: 17
ExChange/Loading Neighbors: 0
Router ID conflict state: Normal
Area interface up count: 1
Interface: 10.2.1.2 (GigabitEthernet2/0/0)

Cost: 1 State: DR Type: Broadcast MTU: 1500
Priority: 1
Designated Router: 10.2.1.2
Backup Designated Router: 10.2.1.1
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
Step 7 Configure BGP GR on the PE devices.

BGP GR has been configured in step 6, so you only need to configure BGP GR on PE2 in this
step.
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] graceful-restart
[PE2-bgp] quit
Run the display bgp vpnv4 all peer verbose command on PE1. The command output shows
that IBGP GR has taken effect between PE1 and PE2, and EBGP GR has taken effect between
PE1 and CE1.
[PE1] display bgp vpnv4 all peer verbose
BGP Peer is 3.3.3.9, remote AS 100

Type: IBGP link
BGP version 4, Remote router ID 3.3.3.9
Update-group ID: 1
BGP current state: Established, Up for 00h01m04s
BGP current event: RecvKeepalive
BGP last state: OpenConfirm
BGP Peer Up count: 3
Received total routes: 3
Received active routes total: 3
Received mac routes: 0
Advertised total routes: 2
Port: Local - 179 Remote - 56400
Configured: Connect-retry Time: 32 sec
Configured: Min Hold Time: 0 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp 4-byte-as capability
Graceful Restart Capability: advertised and received
Restart Timer Value received from Peer: 150 seconds
Address families preserved for peer in GR:
IPv4 Unicast (was preserved)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPNv4 (was preserved)

Address family IPv4 Unicast: advertised and received
Address family VPNv4: advertised and received
Received: Total 7 messages
Update messages 4
Open messages 1
KeepAlive messages 2
Notification messages 0
Refresh messages 0
Sent: Total 8 messages
Update messages 3
Open messages 2
Refresh messages 0
Authentication type configured: None
Last keepalive received: 2013/09/15 19:43:15
Last keepalive sent : 2013/09/15 19:43:15
Last update received: 2013/09/15 19:42:15
Last update sent : 2013/09/15 19:42:15
Minimum route advertisement interval is 0 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Connect-interface has been configured
Peer Preferred Value: 0
Routing policy configured:
No routing policy is configured
IPv4-family for VPN instance: vpn1
BGP Peer is 10.1.1.1, remote AS 65410

Type: EBGP link
Update-group ID: 1
BGP current event: KATimerExpired
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Graceful Restart Capability: advertised and received
Restart Timer Value received from Peer: 150 seconds
Address families preserved for peer in GR:
IPv4 Unicast (was preserved)
Update messages 3
Open messages 1
Refresh messages 0
Update messages 6
Open messages 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Refresh messages 0
Last keepalive received: 2013/09/15 19:42:37
Last keepalive sent : 2013/09/15 19:42:37
Last update received: 2013/09/15 19:37:37
Last update sent : 2013/09/15 19:42:15
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
Routing policy configured:

# Run the display switchover state command on PE1 to check the status of the slave SRU.
The following information is displayed:
[PE1] display switchover state
Slot 15 HA FSM State(master): realtime or routine backup.
Slot 14 HA FSM State(slave): receiving realtime or routine data.
# Perform an active/standby switchover on PE1.

[PE1] slave switchover
Are you sure to switch over? (y/n)[n]:y
# Communication between the site connected to CE1 and the site connected to CE2 is not
interrupted.
NOTE
Communication between the sites may be interrupted when two or more neighboring devices among
CE1, PE1, PE2, and CE2 perform an active/standby switchover at the same time.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
graceful-restart
#
isis 1
graceful-restart
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.252
#
ip address 100.1.1.1 255.255.255.252
isis enable 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
bgp 100
graceful-restart
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
graceful-restart
#
isis 1
graceful-restart
network-entity 10.0000.0000.0002.00
#
ip address 100.1.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 100.2.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
graceful-restart
#
isis 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
graceful-restart
network-entity 10.0000.0000.0003.00
#
ip address 100.2.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
bgp 100
graceful-restart
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route ospf 2
#
import-route bgp
opaque-capability enable
graceful-restart
area 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.252
#
bgp 65410
graceful-restart
ipv4-family
unicast
undo
synchronization
import-route
direct
peer 10.1.1.2
enable
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.252
#
ospf 2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route direct
graceful-restart
area 0.0.0.0
network 10.2.1.0 0.0.0.3
#
return
8.9.19 Example for Configuring Double RRs to Optimize the VPN

Backbone Layer
When deploying a VPN, you can configure double route reflectors (RRs) on the VPN. To
achieve this, you need to select two RRs from the Ps in the same AS on the backbone network
and ensure that the two RRs back up each other and reflect routes of the public network and
VPNv4.
As shown in Figure 8-60, PE1, PE2, RR1, and RR2 are located in AS 100 on the backbone
network. CE1 and CE2 belong to vpna. Select RR1 and RR2 as the RRs of the VPN.
Figure 8-60 Networking diagram for configuring double RRs on a VPN
Loopback1 Loopback1
2.2.2.9/32 AS100 3.3.3.9/32
RR1 GE2/0/0 GE1/0/0 RR2
GE1/0/0 GE2/0/0
GE3/0/0 GE3/0/0
GE1/0/0 GE1/0/0
Loopback1 Loopback1
1.1.1.9/32 GE3/0/0 GE3/0/0 4.4.4.9/32
PE1 GE2/0/0 GE2/0/0 PE2
VPN Backbone
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE1 CE2
AS65410 AS65420
vpna vpna

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
PE1 PE2
10 GE1
2. 0
24
0.
1. 0/
3. /0/0
1/
0. 1/
4.
10 GE
PE1 2/
24
GE3/0/0 Loopback1
Loopback1 GE3/0/0 4.4.4.9/32
1.1.1.9/32 100.1.3.1/24 100.2.4.2/24
/0
2/0 2/24 PE2
G 1.1
E
10
G .1.
E2 .2
.
.2
/0 /24
10
/0
Loopback1 Loopback1
RR1 2.2.2.9/32 RR2 3.3.3.9/32
GE2/0/0 RR2 GE2/0/0

RR1
100.2.3.1/24 100.3.4.1/24
GE1/0/0 GE1/0/0
100.1.2.2/24 GE3/0/0 100.2.3.2/24 GE3/0/0
100.2.4.1/24 100.1.3.2/24
1. Configure an IGP protocol on the MPLS backbone network for IP connectivity.

set up MPLS LSPs.
3. Configure VPN instances on PE1 and PE2 and bind the instances to the interfaces
connected to the CEs. Configure the same VPN target for the VPN instances to enable
users in the same VPN to communicate with each other.
4. Set up EBGP peer relationships between the PEs and CEs and import VPN routes into
BGP.
5. Set up MP-IBGP peer relationships between PEs and RRs. The PEs do not need to set up
an MP-IBGP peer relationship.
6. Configure the same reflector cluster ID for RR1 and RR2 so that they back up each
other.
7. Configure RR1 and RR2 to accept all VPNv4 routes without filtering the routes based on
VPN targets, because RR1 and RR2 must save all VPNv4 routes and advertise them to
PEs.
NOTE
On a VPN with double RRs, ensure that each RR has at least two paths to a PE and the paths do not
share the same network segment or node. If there is only one path between the RRs and PEs or if the
paths share the same network segment or node, double RRs cannot improve network reliability.
Procedure
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The configuration on PE2, RRs, CE1, and CE2 is similar to the configuration on PE1 and is
not mentioned here.
Step 2 Configure an IGP protocol on the MPLS backbone network for IP connectivity.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 and RRs is similar to the configuration on PE1 and is not
mentioned here.
NOTE
The IP addresses of loopback interfaces that are used as LSR IDs need to be advertised.
After the configuration is complete, the devices on the backbone network can learn the
loopback interface addresses from each other.

to vpn-instance
------------------------------------------------------------------------------

2.2.2.9/32 OSPF 10 1 D 100.1.2.2
3.3.3.9/32 OSPF 10 1 D 100.1.3.2
4.4.4.9/32 OSPF 10 2 D 100.1.3.2
OSPF 10 2 D 100.1.2.2
100.1.2.0/24 Direct 0 0 D 100.1.2.1
100.1.2.1/32 Direct 0 0 D 127.0.0.1
100.1.2.255/32 Direct 0 0 D 127.0.0.1
100.1.3.0/24 Direct 0 0 D 100.1.3.1
100.1.3.1/32 Direct 0 0 D 127.0.0.1
100.1.3.255/32 Direct 0 0 D 127.0.0.1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
100.2.3.0/24 OSPF 10 2 D 100.1.3.2
OSPF 10 2 D 100.1.2.2
100.2.4.0/24 OSPF 10 2 D 100.1.2.2
100.3.4.0/24 OSPF 10 2 D 100.1.3.2
LDP LSPs.
# Configure PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
The configuration on PE2 and RRs is similar to the configuration on PE1 and is not
mentioned here.
After the configuration is complete, run the display mpls ldp session command on the PEs
and RRs. The State field in the command output displays as Operational.
The information displayed on PE1 and RR1 is used as an example.


----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
[RR1] display mpls ldp session

----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 Configure VPN instances on the PEs.

# Configure PE1.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
The configuration on CE2 is similar to the configuration on CE1 and is not mentioned here.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpna] quit
[PE1-bgp] quit
Step 6 Set up MP-IBGP peer relationships between PEs and RRs.
# Configure PE1.
[PE1] bgp 100

[PE1-bgp] quit
# Configure RR1.
[RR1] bgp 100
[RR1-bgp] group rr1 internal
[RR1-bgp] peer rr1 connect-interface loopback 1
[RR1-bgp] peer 1.1.1.9 group rr1
[RR1-bgp] ipv4-family vpnv4
[RR1-bgp-af-vpnv4] peer rr1 enable
[RR1-bgp-af-vpnv4] peer 1.1.1.9 group rr1
[RR1-bgp-af-vpnv4] quit
[RR1-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure RR2.
[RR2] bgp 100

[RR2-bgp] group rr2 internal
[RR2-bgp] peer rr2 connect-interface loopback 1
[RR2-bgp-af-vpnv4] peer rr2 enable
[RR2-bgp] quit
PEs. The command output shows that the PEs have set up IBGP peer relationships with RRs,
and the peer relationships are in Established state. The PEs also set up EBGP peer
relationships with the CEs.


2.2.2.9 4 100 2 4 0 00:00:31 Established 0
3.3.3.9 4 100 3 5 0 00:01:23 Established 0

10.1.1.1 4 65410 79 82 0 01:13:29 Established 0
Step 7 Configure route reflection on RR1 and RR2.
# Configure RR1.
[RR1] bgp 100
[RR1-bgp-af-vpnv4] reflector cluster-id 100
[RR1-bgp-af-vpnv4] peer rr1 reflect-client
[RR1-bgp-af-vpnv4] undo policy vpn-target
[RR1-bgp] quit
# Configure RR2.
[RR2] bgp 100
[RR2-bgp-af-vpnv4] reflector cluster-id 100
[RR2-bgp-af-vpnv4] peer rr2 reflect-client
[RR2-bgp-af-vpnv4] undo policy vpn-target
[RR2-bgp] quit
# Check the VPN routing table on a PE. The routing table contains a route to the remote CE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

to vpn-instance
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 IBGP 255 0 RD 4.4.4.9
# If CE1 and CE2 can ping each other, the route reflection function has been configured
successfully.
# Run the shutdown command in the view of GE3/0/0 on PE1 and GE3/0/0 on PE2. CE1 and
CE2 can still ping each other, indicating that the RRs are successfully configured.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 100.1.2.1 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 100.1.3.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
ipv4-family unicast
peer 2.2.2.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 100.1.2.0 0.0.0.255
network 100.1.3.0 0.0.0.255
#
return
l RR1 configuration file
#
sysname RR1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 100.1.2.2 255.255.255.0
mpls
mpls ldp
#
ip address 100.2.3.1 255.255.255.0
mpls
mpls ldp
#
ip address 100.2.4.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
group rr1 internal
peer rr1 connect-interface LoopBack1
#
ipv4-family unicast
undo
synchronization
peer rr1
enable
peer 1.1.1.9
enable
peer 1.1.1.9 group
rr1
peer 3.3.3.9
enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
peer 3.3.3.9 group rr1

peer 4.4.4.9
enable
#
ipv4-family vpnv4
reflector cluster-id 100
peer rr1 enable
peer rr1 reflect-client
peer 1.1.1.9 enable
peer 3.3.3.9 enable
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 100.1.2.0 0.0.0.255
network 100.2.3.0 0.0.0.255
network 100.2.4.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
l RR2 configuration file
#
sysname RR2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 100.2.3.2 255.255.255.0
mpls
mpls ldp
#
ip address 100.3.4.1 255.255.255.0
mpls
mpls ldp
#
ip address 100.1.3.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
group rr2 internal
peer rr2 connect-interface LoopBack1
#
ipv4-family unicast
undo
synchronization
peer rr2
enable
peer 1.1.1.9
enable
peer 1.1.1.9 group
rr2
peer 3.3.3.9

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
enable
peer 4.4.4.9
enable
#
ipv4-family vpnv4
reflector cluster-id 100
peer rr2 enable
peer rr2 reflect-client
peer 1.1.1.9 enable
peer 2.2.2.9 enable
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 100.2.3.0 0.0.0.255
network 100.3.4.0 0.0.0.255
network 100.1.3.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 100.3.4.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
ip address 100.2.4.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
peer 3.3.3.9 enable
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 100.3.4.0 0.0.0.255
network 100.2.4.0 0.0.0.255
#
return

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
#
return
8.9.20 Example for Connecting a VPN to the Internet

As shown in Figure 8-61, CE1 and CE2 need to communicate with each other, and users
connected to CE1 need to connect to the Internet.
To enable users connected to CE1 to access the Internet, connect an agent server to CE1 and
configure a public IP address for the agent server. Then users connected to CE1 can access the
Internet through the agent server. In this example, the P represents on the Internet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-61 Networking diagram for connecting a VPN to the Internet
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32 Loopback1
3.3.3.3/32
GE1/0/0 GE1/0/0
PE1 100.1.1.2/24 100.2.1.2/24
PE2
GE2/0/0 GE2/0/0
GE1/0/0 100.1.1.1/24 P 100.2.1.1/24 GE2/0/0
10.1.1.2/24 10.2.1.2/24
Internet
AS100
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
GE2/0/0 CE2
10.3.1.2/24 Agent Server
CE1 10.3.1.1/24
vpn1 vpn1
AS 65420
AS 65410

2. Configure three static routes:
– On CE1, create a default route and specify PE1 as the next hop.
– On PE1, configure a default route from the VPN to the Internet and specify P as the
next hop. This route enables traffic to be transmitted from the agent server to the
Internet.
– On PE1, configure a static route from the Internet to the agent server and specify
CE1 as the next hop. Configure IGP to advertise the static route to the Internet. This
route enables traffic to be transmitted from the Internet to the agent server.
Procedure
# Configure PE1.
The configuration on PE2, P, CE1, and CE2 is similar to the configuration on PE1 and is not
mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Configure an IGP protocol on the MPLS backbone network for IP connectivity.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 and P is similar to the configuration on PE1 and is not mentioned
here.
NOTE
The IP addresses of loopback interfaces that are used as LSR IDs need to be advertised.
After the configuration is complete, the devices on the backbone network can learn the
loopback interface addresses from each other.
Step 3 Set up MPLS LDP LSPs and an MP-IBGP peer relationship between the devices on the
backbone network.
# Enable MPLS LDP on PE1 to set up MPLS LDP LSPs.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
The configuration on PE2 and P is similar to the configuration on PE1 and is not mentioned
here.
After the configuration is complete, run the display mpls ldp session command on P. The
command output shows that the LDP sessions between PE1 and P, and between PE2 and P are
in Operational state.
The information displayed on P is used as an example.
[P] display mpls ldp session

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
# Configure an MP-IBGP peer on PE1.
[PE1] bgp 100


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-bgp] quit
Run the display bgp vpnv4 all peer command on PE1 and PE2. The command output shows
that an MP-IBGP peer relationship has been set up between the PEs and is in Established
state. The information displayed on PE1 is used as an example.


3.3.3.3 4 100 6 8 0 00:03:48 Established 2
Step 4 Create VPN instances and set up EBGP peer relationships.
# Create VPN instance vpn1 on the PEs and bind it to the interfaces connected to CEs. The
information displayed on PE1 is used as an example.
Set up EBGP peer relationships between PE1 and CE1 and between PE2 and CE2 so that
routes of the CEs can be advertised to the PEs. The configuration on CE1 and PE1 is used as
an example.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
The configuration on CE2 is similar to the configuration on CE1 and is not mentioned here.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] import-route static
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
After the configuration is complete, run the display ip vpn-instance command on the PEs. In
the command output, vpn1 is displayed in the VPN-Instance Name field.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] display ip vpn-instance

VPN-Instance Name RD Address-family

vpn1 100:1 IPv4
Run the display bgp vpnv4 all peer command on the PEs. The command output shows that
the IBGP and EBGP peer relationships are all in Established state.


3.3.3.3 4 100 127 134 0 01:39:44 Established 2

10.1.1.1 4 65410 107 110 0 01:26:33 Established 3
Step 5 Configure static routes to enable VPN users to access the Internet.
# On CE1, create a default route and specify PE1 as the next hop.
# Configure PE1.
# Configure a default route from the agent server to the Internet and specify P as the next hop.
Specify the public keyword in the command to use the public IP address of P as the next hop
address.
[PE1] ip route-static vpn-instance vpn1 0.0.0.0 0 100.1.1.2 public
NOTE
If the CEs and PEs are connected through an Ethernet network, you must specify the next hop when
configuring the static route.
# Configure a static route from the Internet to the agent server and specify CE1 as the next
hop.
[PE1] ip route-static 10.3.1.0 24 vpn-instance vpn1 10.1.1.1
# Advertise the preceding static route to the Internet using an IGP (OSPF in this example).
[PE1] ospf 1
[PE1-ospf-1] import-route static
[PE1-ospf-1] quit
# Configure the agent server. Set the IP address of the agent server to 10.3.1.1/24 and the
default gateway address of the agent server to 10.3.1.2/24 (address of CE1). In addition, the
agent server must run the agent software.
# Run the display ip routing-table vpn-instance vpn1 command on PE1 to check the VPN
routing table of vpn1. The VPN routing table has a default route with the next hop address
100.1.1.2 and the outbound interface GE2/0/0.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

to vpn-instance
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 100.1.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.2
10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 IBGP 255 0 RD 3.3.3.3
10.3.1.0/24 EBGP 255 0 D 10.1.1.1
# Run the display ip routing-table command on PE1 to check the IP routing table on PE1.
The routing table has a route to the agent server, in which the next hop address is 10.1.1.1.
to vpn-instance
------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 1 D 100.1.1.2
3.3.3.3/32 OSPF 10 2 D 100.1.1.2
100.1.1.0/24 Direct 0 0 D 100.1.1.1
100.1.1.1/32 Direct 0 0 D 127.0.0.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1
100.2.1.0/24 OSPF 10 2 D 100.1.1.2
10.3.1.0/24 Static 60 0 RD 10.1.1.1
# P can ping the agent server.

[P] ping 10.3.1.1

0.00% packet loss
# The agent server can access the P on the Internet.

----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2
#
return

#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 100.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
import-route static
import-route direct
#
ospf 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route static
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 100.1.1.0 0.0.0.255
#
ip route-static 10.3.1.0 255.255.255.0 vpn-instance vpn1 10.1.1.1
ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 100.1.1.2 public
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 100.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 100.1.1.0 0.0.0.255
network 100.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 100.2.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 100.2.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
8.9.21 Example for Configuring BGP/MPLS IP VPN to Use a GRE

Tunnel
NOTE
The AR100&AR120&AR150&AR160&AR200 cannot be used in this scenario.
In Figure 8-62:
functions.
The enterprise wants to establish a GRE tunnel between the PEs and use IP to forward VPN
packets over the IP network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-62 Networking diagram for configuring BGP/MPLS IP VPN to use a GRE tunnel
AS:100
GE1/0/0 GE2/0/0
172.1.1.2/24 172.2.1.1/24
P
Loopback1 Loopback1
10.10.1.1/32 10.10.2.1/32
GE2/0/0 GE2/0/0
172.1.1.1/24 172.2.1.2/24
PE1 PE2
GRE Tunnel
10.1.1.2/24 10.3.1.1/24 10.3.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE1 CE2
vpn1 vpn1
AS: 65410 AS: 65420
network.
2. Create a GRE tunnel between PEs so that VPN packets can be transmitted over the GRE
tunnel.
instance.
4. Because the P device does not support MPLS functions, an LSP cannot be used to
transmit VPN packets. Configure a tunnel policy on the PEs to specify that VPN packets
are transmitted over a GRE tunnel, and apply the tunnel policy.
5. Establish EBGP peer relationships between PEs and CEs to exchange routes so that a CE
can learn routes from the peer CE and CE1 can communicate with CE2.
Procedure
# Configure CE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


[Huawei] sysname P
# Configure CE2.
Step 2 Configure IGP on the MPLS backbone network to implement interworking between PEs.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit

[P] ospf 1
[P-ospf-1] area 0
[P-ospf-1] quit
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE2] ospf 1
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
Step 3 Configure a GRE tunnel.
# Configure PE1.
# Configure PE2.
Step 4 Enable basic MPLS functions on the PEs.

# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
Step 5 Configure VPN instances on PEs and bind each interface that connects a PE to a CE to a VPN
instance. Apply tunnel policies on the PEs to specify the GRE tunnel used to forward VPN
packets.
# Configure PE1.
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

PEs to view the configurations of VPN instances. Each PE can ping its local CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP address by setting -a
source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address dest-ip-address
command to ping a remote CE. If the source IP address is not specified, the ping operation fails.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65420
[CE2-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


PrefRcv
10.1.1.1 4 65410 6 3 0 00:01:14

Established 3

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
The command output shows that the BGP peer relationships have been established between
the PEs and are in the Established state.


PrefRcv
10.10.2.1 4 100 4 7 0 00:02:54

Established 0

10.1.1.1 4 65410 122 119 0 01:57:43
Established 3

# After the configuration is complete, CEs can learn routes to each other. CEs can
# The command output on CE1 is used as an example.
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1] ping 10.2.1.1


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname PE1
#
ipv4-family
tnl-policy gre1
#
mpls
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.10.1.1 255.255.255.255
#
ip address 10.3.1.1 255.255.255.0
tunnel-protocol gre
source LoopBack1
#
tunnel-policy gre1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
bgp 100
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.10.1.1 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname P
#
ip address 172.1.1.2 255.255.255.0
#
ip address 172.2.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
tnl-policy gre1
#
mpls
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 10.10.2.1 255.255.255.255
#
ip address 10.3.1.2 255.255.255.0
tunnel-protocol gre
source LoopBack1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
tunnel-policy gre1
#
bgp 100
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
#
ospf 1
area 0.0.0.0
network 10.10.2.1 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
8.9.22 Example for Configuring L3VPN Using LDP Signaling over

GRE
In Figure 8-63:
functions.
The enterprise wants to deploy BGP/MPLS IP VPN between PE1 and PE2 and use LDP LSPs
to transmit VPN data so that CE1 can communicate with CE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 8-63 Networking for configuring L3VPN using LDP signaling over
AS:100
GE1/0/0 GE2/0/0
172.1.1.2/24 172.2.1.1/24
P
Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32
PE1 GE2/0/0 GE2/0/0 PE2
172.1.1.1/24 172.2.1.2/24
Loopback0 Loopback0
1.1.1.1/32 GRE tunnel 2.2.2.2/32
10.1.1.2/24 20.1.1.1/24 20.1.1.2/24 10.2.1.2/24
GE1/0/0 GE1/0/0
10.1.1.1/24 10.2.1.1/24
CE1 CE2
vpn1 vpn1
AS: 65410 AS: 65420
network.
2. Configure basic MPLS functions and MPLS LDP on PEs so that MPLS LSPs can be
established to transmit VPN data.
3. Because the P device does not support MPLS functions and an LSP is required to
transmit VPN data, use LDP over GRE so that a GRE tunnel is set up between PEs to
transmit services over LDP LSPs. Create GRE tunnel interfaces on PEs, specify source
and destination addresses of the tunnel, and establish a GRE tunnel between PEs to
implement interworking on the MPLS network.
4. Enable MPLS LDP on tunnel interfaces to implement LDP over GRE and establish
MPLS LSPs.
instance.
6. Establish an MP-IBGP peer relationship between PE1 and PE2, and establish EBGP peer
relationships between PEs and CEs and import VPN routes, so that CE1 can
communicate with CE2.
NOTE
The IP address of Loopback1 interface is used as the LSR ID, that is, LDP uses this IP address to establish a
session. A GRE tunnel interface must have an IP address configured, and uses addresses of Loopback0
interfaces as source and destination addresses. The source and destination addresses, and physical interface
are advertised by an IGP, and the IP address of Loopback1 interface and tunnel interface address are
advertised by another IGP or static route. If a static route is used, specify the tunnel interface as the outbound
interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure OSPF between the PEs and P to implement IP connectivity on the backbone
network.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configurations of PE2 and P are similar to the configuration of PE1, and are not
mentioned here.
Step 2 Enable basic MPLS functions and MPLS LDP on PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
Step 3 Create GRE tunnel interfaces on PEs, and specify source and destination addresses of the
tunnel.
Create and configure GRE tunnel interfaces on PE1 and PE2, and establish a GRE tunnel
between PEs to implement interworking on the MPLS network.
# Configure PE1.
[PE1] ospf 11

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-11] quit
# Configure PE2.
[PE2] ospf 11
[PE2-ospf-11] quit
After the configurations are complete, a GRE tunnel is set up between PE1 and PE2. Run the
display ip routing-table command. You can see that PEs have learnt the routes to Loopback1
of each other.
Step 4 Enable MPLS LDP on tunnel interfaces of PEs.
Enable MPLS LDP on tunnel interfaces of PE1 and PE2 so that MPLS LSPs can be
established.
# Configure PE1.
[PE1-Tunnel0/0/1] mpls
[PE1-Tunnel0/0/1] mpls ldp
# Configure PE2.
[PE2-Tunnel0/0/1] mpls
[PE2-Tunnel0/0/1] mpls ldp
After the configurations are complete, an LDP session can be set up between PE1 and PE2.
Run the display mpls ldp session command. You can see that the Status field is Operational
in the command output.
Step 5 Configure a VPN instance on each PE and connect CEs to PEs.
# Configure PE1.
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Configure IP addresses for CE interfaces according to Figure 8-63.

# Configure CE1.
The configuration of CE2 is similar to that of CE1, and is not mentioned here.
PEs to view the configurations of VPN instances. Each PE can successfully ping the
connected CE.
NOTE
If multiple interfaces on a PE is bound to the same VPN instance, specify a source IP addresses by
specifying -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address dest-
ip-address command to ping the remote CE. Otherwise, the ping operation fails.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65420
[CE2-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR



PrefRcv
10.1.1.1 4 65410 6 3 0 00:01:14

Established 3

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
You can see that the BGP peer relationship between PEs is in Established state.


PrefRcv
2.2.2.9 4 100 4 7 0 00:02:54

Established 0

10.1.1.1 4 65410 122 119 0 01:57:43
Established 3

# After the configurations are complete, CEs can learn routes to the interface of each other,
to vpn-instance
------------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Summary Count : 1
10.2.1.0/24 EBGP 255 0 D 10.1.1.2

[CE1] ping 10.2.1.1


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls
ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ip address 20.1.1.1 255.255.255.0
tunnel-protocol gre
source LoopBack0
destination 2.2.2.2
mpls
mpls ldp
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 172.1.1.0 0.0.0.255
#
ospf 11
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return
#
sysname P
#
ip address 172.1.1.2 255.255.255.0
#
ip address 172.2.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ip address 20.1.1.2 255.255.255.0
tunnel-protocol gre
source LoopBack0
destination 1.1.1.1
mpls
mpls ldp
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 172.2.1.0 0.0.0.255
#
ospf 11
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.9.23 Example for Configuring L3VPN with LDP Signals Carried

by DSVPN
As shown in Figure 8-64, a large-scale enterprise has deployed a production network vpn1
and an office network vpn2 in the headquarters and branches respectively. The enterprise
establishes an IP/MPLS backbone network in its headquarters, and its branches located in
different areas use Spoke-PE to connect to the IP/MPLS backbone network through the
Internet. In this example, the backbone network has only a Hub-P and PE1 and the enterprise
has only two branches. Spoke-PE2 and Spoke-PE3 in branches dynamically obtain their
public addresses. (Configurations related to dynamic address allocation is omitted in this
example and public addresses are manually specified.) Because the Internet cannot provide
the MPLS function for the enterprise, the production networks and office networks in
branches cannot communicate with those in the headquarters.
The enterprise wants to expand the IP/MPLS backbone network, deploy BGP/MPLS IP VPN
in the headquarters and branches, and use LDP LSP to transmit data from vpn1 and vpn2 to
implement secure interconnection between the headquarters and branches and between
branches. VPN data between branches needs to be forwarded by the headquarters so that the
headquarters can monitor traffic in real-time.
Figure 8-64 Networking diagram for configuring L3VPN with LDP signals carried by
DSVPN
Enterprise
branch1
Loopback1 Loopback1
2.2.2.9/32 1.1.1.9/32 vpn1
vpn1
GE2 Spoke-PE2 /0/0
/0/0 GE2
Tunnel0/0/1 PE1
172.10.1.2/24
GE3
/0 /0 GE1/0/0 /0/0
vpn2 GE3 GR
vpn2
GE1/0/0
E Tu
n ne
l GE2/0/0
Loopback1
Internet GE1/0/0 4.4.4.9/32
Hub-P
e l
nn
E Tu Tunnel0/0/1
vpn1 GE1/0/0 GR 172.10.1.1/24
GE2
/0/0
Tunnel0/0/1
172.10.1.3/24
/0/0
vpn2 GE3 Spoke-PE3
Loopback1 Enterprise
3.3.3.9/32 headquarters
Enterprise
branch2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Spoke- 192. GE PE1
1 68.1 2/0/0 / 0 /0 /2 4
PE2 1.1/2 Spoke-PE2 G E 2 6 8 .1 .1
. 1
4 192
GE1/0/0 PE1
202.2.1.2/24 GE3
/0/0 /
192. 0/0
GE3 /24 GE1/0/0 168.
. 1 2.1/2
.12 172.1.1.1/24
92.168 4
1
Spoke- Hub-P
PE3 192. G
168. E2/0/0
21.1
/24
GE1/0/0 GE2/0/0
202.3.1.2/24 172.1.1.2/24
/0 /0
G E 3 /2 4 Spoke-PE3
1
.2 2 . GE1/0/0
. 168
1 92 202.1.1.2/24
Hub-P
To expand the IP/MPLS backbone network and deploy BGP/MPLS IP VPN for an enterprise,
you need to add the Spoke-PE devices in the branches to the IP/MPLS backbone network in
the headquarters. MPLS LDP packets between the headquarters and branches need to be
transmitted over GRE tunnels because the Internet cannot provide the MPLS function. As
there are a large number of branches and devices in the branches dynamically obtain their
public addresses, DSVPN is used to establish GRE tunnels between the headquarters and
branches. As a result, L3VPN with LDP signals carried by DSVPN can meet the requirements
of the enterprise.
The configuration roadmap for L3VPN with LDP signals carried by DSVPN is as follows:
1. Configure branch devices to save only summarized routes to the headquarters, configure
OSPF on Hub-P and Spoke-PEs to advertise routes, and set the OSPF network type to
point-to-multipoint (P2MP), so that all VPN data between branches is forwarded by the
headquarters.
2. Enable MPLS LDP on tunnel interfaces of Spoke-PE2, Spoke-PE3, and Hub-P and set
up MPLS LSP tunnels to implement LDP over mGRE.
3. Configure L3VPN on Spoke-PE2, Spoke-PE3, and PE1 to implement secure
interconnection between the headquarters and branches and between branches. Because
there are a large number of branches, a route reflector can be used to reduce the number
of MP-IBGP connections between PEs.
NOTE
Do not configure NHRP redirection on the Hub because LDP over mGRE does not need to establish tunnels
for direct communication between branches.
Procedure
Step 1 Configure interface IP addresses and OSPF on Hub-P and PE1 to implement interconnection
on the IP/MPLS backbone network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration of Hub-P is similar to that of PE1, and is not mentioned here.
After the configuration is complete, an OSPF neighbor relationship can be set up between
Hub-P and PE1. Run the display ospf peer command. You can see that the neighbor status is
Full. Run the display ip routing-table command. You can see that Hub-P and PE1 have
learnt the routes to Loopback1 of each other.
Step 2 Configure interface IP addresses and static routes on Hub-P, Spoke-PE2, and Spoke-PE3 to
ensure that public routes are reachable.
Because Hub-P, Spoke-PE2, and Spoke-PE3 are directly connected to the Internet, IP
addresses and default static routes are manually specified here.
[Spoke-PE2] ip route-static 0.0.0.0 0 202.2.1.1
The configurations of Spoke-PE3 and Hub-P are similar to that of Spoke-PE2, and are not
mentioned here.
After the configuration is complete, devices can ping each other and public routes are
reachable.
Step 3 Create tunnel interfaces and configure DSVPN on Hub-P, Spoke-PE2, and Spoke-PE3.
1. Create an mGRE interface, configure an IP address, and specify a source tunnel
interface.
[Spoke-PE2] interface tunnel 0/0/1
[Spoke-PE2-Tunnel0/0/1] ip address 172.10.1.2 24
[Spoke-PE2-Tunnel0/0/1] tunnel-protocol gre p2mp
[Spoke-PE2-Tunnel0/0/1] source gigabitethernet 1/0/0
[Spoke-PE2-Tunnel0/0/1] quit
The configurations of Spoke-PE3 and Hub-P are similar to that of Spoke-PE2, and are
not mentioned here.
2. Configure OSPF to advertise the MPLS LSR ID as DSVPN subnet information through

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Spoke-PE2] ospf 1
not mentioned here.
3. Configure NHRP and set the OSPF network type to P2MP. Do not configure NHRP
redirection on the Hub-P.
# Configure Hub-P.
[Hub-P] interface tunnel 0/0/1
[Hub-P-Tunnel0/0/1] nhrp entry multicast dynamic
[Hub-P-Tunnel0/0/1] ospf network-type p2mp
[Hub-P-Tunnel0/0/1] ospf dr-priority 100
[Hub-P-Tunnel0/0/1] quit
[Spoke-PE2-Tunnel0/0/1] nhrp entry 172.10.1.1 202.1.1.2 register
[Spoke-PE2-Tunnel0/0/1] ospf network-type p2mp
[Spoke-PE2-Tunnel0/0/1] ospf dr-priority 0
After the configuration is complete, run the display nhrp peer all command on Hub-P to
view registration information about Spoke-PE2 and Spoek-PE3.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
172.10.1.2 32 202.2.1.2 172.10.1.2 dynamic route tunnel
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Run the display ip routing-table command on all devices on the IP/MPLS backbone
network. You can see that all devices have learnt the routes to Loopback1 of other devices.
Step 4 Enable basic MPLS functions and MPLS LDP on Spoke-PE2, Spoke-PE3, Hub-P, and PE1.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The configurations of Spoke-PE2, Spoke-PE3 and Hub-P are similar to that of PE1, and are
not mentioned here.
Step 5 Enable MPLS LDP on the interfaces of Spoke-PE2, Spoke-PE3, Hub-P, and PE1.
Enable MPLS LDP on interfaces of Hub-P and PE1 that are directly connected to each other
and enable MPLS LDP on tunnel interfaces of Spoke-PE2, Spoke-PE3 and Hub-P to establish
MPLS LSP tunnels.
# Configure PE1.
# Configure Hub-P.
[Hub-P] interface gigabitethernet 2/0/0
[Hub-P-GigabitEthernet2/0/0] mpls
[Hub-P-GigabitEthernet2/0/0] mpls ldp
[Hub-P-GigabitEthernet2/0/0] quit
[Hub-P-Tunnel0/0/1] mpls
[Hub-P-Tunnel0/0/1] mpls ldp
[Spoke-PE2-Tunnel0/0/1] mpls
[Spoke-PE2-Tunnel0/0/1] mpls ldp
After the configuration is complete, PE1, Spoke-PE2, and Spoke-PE3 can establish LDP
sessions with Hub-P. Run the display mpls ldp session command. You can see that the MPLS
LDP session status is Operational.
Step 6 Configure VPN instances on Spoke-PE2, Spoke-PE3, and PE1 and bind VPN instances to
interfaces.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Spoke-PE2] ip vpn-instance vpn1
[Spoke-PE2-vpn-instance-vpn1] ipv4-family
[Spoke-PE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 200:1
[Spoke-PE2-vpn-instance-vpn1-af-ipv4] vpn-target 111:1 both
[Spoke-PE2-vpn-instance-vpn1-af-ipv4] quit
[Spoke-PE2-vpn-instance-vpn1] quit
[Spoke-PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
each device to view the configuration of VPN instances.
Step 7 Set up MP-IBGP peer relationships between Spoke-PE2, Spoke-PE3, and PE1.
Configure PE1 as a route reflector. Spoke-PE2 and Spoke-PE3 can set up MP-IBGP peer
relationships with PE1.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] group rr1 internal
[PE1-bgp] peer rr1 connect-interface loopback 1
[PE1-bgp] peer 2.2.2.9 group rr1
[PE1-bgp-af-vpnv4] peer rr1 enable
[PE1-bgp-af-vpnv4] peer 2.2.2.9 group rr1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-bgp-af-vpnv4] reflector cluster-id 100

[PE1-bgp-af-vpnv4] peer rr1 reflect-client
[PE1-bgp-af-vpnv4] undo policy vpn-target
[PE1-bgp-vpn1] quit
[PE1-bgp-vpn2] quit
[PE1-bgp] quit
[Spoke-PE2] bgp 100
[Spoke-PE2-bgp] ipv4-family vpn-instance vpn1
[Spoke-PE2-bgp-vpn1] import-route direct
[Spoke-PE2-bgp-vpn1] quit
[Spoke-PE3] bgp 100
After the configuration is complete, run the display bgp vpnv4 all peer command on Spoke-
PE2, Spoke-PE3, and PE1. You can see that Spoke-PE2, Spoke-PE3, and PE1 have set up
BGP peer relationships with PE1 and are in Established state.


PrefRcv
2.2.2.9 4 100 5 12 0 00:02:00

Established 2
3.3.3.9 4 100 5 11 0 00:01:02
Established 2

# After the configuration is complete, Spoke-PE2, Spoke-PE3, and PE1 can learn the routes to
vpn1 and vpn2 of each other.
# The display on PE1 is used as an example:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

to vpn-instance
------------------------------------------------------------------------------
192.168.1.0/24 Direct 0 0 D 192.168.1.1

192.168.1.1/32 Direct 0 0 D 127.0.0.1
192.168.1.255/32 Direct 0 0 D 127.0.0.1
192.168.11.0/24 IBGP 255 0 RD 2.2.2.9
192.168.21.0/24 IBGP 255 0 RD 3.3.3.9

to vpn-instance
------------------------------------------------------------------------------
192.168.2.0/24 Direct 0 0 D 192.168.2.1

192.168.2.1/32 Direct 0 0 D 127.0.0.1
192.168.2.255/32 Direct 0 0 D 127.0.0.1
192.168.12.0/24 IBGP 255 0 RD 2.2.2.9
192.168.22.0/24 IBGP 255 0 RD 3.3.3.9
# Devices in the same VPN can successfully ping each other, whereas devices in different
VPNs cannot.
# The display on Spoke-PE2 is used as an example:
[Spoke-PE2] ping -vpn-instance vpn1 -a 192.168.11.1 192.168.1.1

0.00% packet loss


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss
----End
Configuration Files
NOTE
This example does not provide configuration files of devices on the Internet.
#
sysname PE1
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
100:1
vpn-target 111:1 export-
extcommunity
vpn-target 111:1 import-
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
100:2
extcommunity
extcommunity
#
mpls lsr-id
1.1.1.9
mpls
mpls ldp
#
255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance
vpn1
ip address 192.168.1.1 255.255.255.0
#
vpn2
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
bgp
100
group rr1
internal
peer rr1 connect-interface
LoopBack1
peer 2.2.2.9 as-number
100
peer 2.2.2.9 group
rr1
100
peer 3.3.3.9 group
rr1
ipv4-family
unicast
undo
synchronization
peer rr1
enable
peer 2.2.2.9
enable
peer 2.2.2.9 group
rr1
peer 3.3.3.9
enable
peer 3.3.3.9 group
rr1
ipv4-family
vpnv4
reflector cluster-id
100
undo policy vpn-
target
peer rr1
enable
peer rr1 reflect-
client
peer 2.2.2.9
enable
peer 2.2.2.9 group
rr1
peer 3.3.3.9
enable
peer 3.3.3.9 group
rr1
ipv4-family vpn-instance
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l Hub-P configuration file
#
sysname Hub-P
#
mpls lsr-id
4.4.4.9
mpls
mpls
ldp
#
ip address 202.1.1.2 255.255.255.0
#
255.255.255.0
mpls
mpls ldp
#
interface
LoopBack1
ip address 4.4.4.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type
p2mp
ospf dr-priority
100
mpls
mpls
ldp
dynamic
#
ospf
1
area
0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.10.1.0
0.0.0.255
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip route-static 0.0.0.0 0.0.0.0 202.1.1.1

#
return
#
sysname Spoke-PE2
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
200:1
extcommunity
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
200:2
extcommunity
extcommunity
#
mpls lsr-id
2.2.2.9
mpls
mpls
ldp
#
ip address 202.2.1.2 255.255.255.0
#
vpn1
ip address 192.168.11.1 255.255.255.0
#
vpn2
ip address 192.168.12.1 255.255.255.0
#
interface
LoopBack1
ip address 2.2.2.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type
p2mp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ospf dr-priority
0
mpls
mpls
ldp
nhrp entry 172.10.1.1 202.1.1.2
register
#
bgp
100
100
peer 1.1.1.9 connect-interface
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 1.1.1.9
enable
ipv4-family
vpnv4
policy vpn-
target
peer 1.1.1.9
enable
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf
1
area
0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.10.1.0
0.0.0.255
#
ip route-static 0.0.0.0 0.0.0.0 202.2.1.1

#
return
#
sysname Spoke-PE3
#
ip vpn-instance

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
vpn1
ipv4-
family
route-distinguisher
300:1
extcommunity
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
300:2
extcommunity
extcommunity
#
mpls lsr-id
3.3.3.9
mpls
mpls
ldp
#
ip address 202.3.1.2 255.255.255.0
#
vpn1
ip address 192.168.21.1 255.255.255.0
#
vpn2
ip address 192.168.22.1 255.255.255.0
#
interface
LoopBack1
ip address 3.3.3.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type
p2mp
ospf dr-priority
0
mpls
mpls
ldp
nhrp entry 172.10.1.1 202.1.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
register
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 1.1.1.9
enable
ipv4-family
vpnv4
policy vpn-
target
peer 1.1.1.9
enable
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf
1
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.10.1.0
0.0.0.255
#
ip route-static 0.0.0.0 0.0.0.0 202.3.1.1

#
return
8.9.24 Example for Configuring L3VPN with LDP Signals Carried

by DSVPN and Protected by IPSec
As shown in Figure 8-65, a large-scale enterprise has deployed a production network vpn1
and an office network vpn2 in the headquarters and branches respectively. The enterprise
establishes an IP/MPLS backbone network in its headquarters, and its branches located in
different areas use Spoke-PE to connect to the IP/MPLS backbone network through the

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Internet. In this example, the backbone network has only a Hub-P and PE1 and the enterprise
has only two branches. Spoke-PE2 and Spoke-PE3 in branches dynamically obtain their
public addresses. (Configurations related to dynamic address allocation is omitted in this
example and public addresses are manually specified.) Because the Internet cannot provide
the MPLS function for the enterprise, the production networks and office networks in
branches cannot communicate with those in the headquarters.
The enterprise wants to expand the IP/MPLS backbone network, deploy BGP/MPLS IP VPN
in the headquarters and branches, and use LDP LSP to transmit data from vpn1 and vpn2 to
implement secure interconnection between the headquarters and branches and between
branches. VPN data between branches needs to be forwarded by the headquarters and
encrypted using IPSec so that the headquarters can monitor and protect data.
Figure 8-65 Networking diagram for configuring L3VPN with LDP signals carried by
DSVPN and protected by IPSec
Enterprise
branch1
Loopback1 Loopback1
2.2.2.9/32 1.1.1.9/32 vpn1
vpn1
GE2 Spoke-PE2 /0/0
/0/0 GE2
Tunnel0/0/1 PE1
172.10.1.2/24
GR GE3
/0 /0 ET GE1/0/0 /0/0
vpn2 GE3 un vpn2
GE1/0/0 ne
l
IPS
ec
GE2/0/0
Loopback1
Internet GE1/0/0 4.4.4.9/32
Hub-P
ec
IPS
Tunnel0/0/1
vpn1 GE1/0/0 nel 172.10.1.1/24
un
GE2
/0/0 ET
GR
Tunnel0/0/1
172.10.1.3/24
/0/0 Enterprise
vpn2 GE3 Spoke-PE3
headquarters
Loopback1
Enterprise 3.3.3.9/32
branch2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Spoke- 192. GE PE1
1 68.1 2/0/0 / 0 /0 /2 4
PE2 1.1/2 Spoke-PE2 G E 2 6 8 .1 .1
. 1
4 192
GE1/0/0 PE1
202.2.1.2/24 GE3
/0/0 /
192. 0/0
GE3 /24 GE1/0/0 168.
. 1 2.1/2
.12 172.1.1.1/24
92.168 4
1
Spoke- Hub-P
PE3 192. G
168. E2/0/0
21.1
/24
GE1/0/0 GE2/0/0
202.3.1.2/24 172.1.1.2/24
/0 /0
G E 3 /2 4 Spoke-PE3
1
.2 2 . GE1/0/0
. 168
1 92 202.1.1.2/24
Hub-P
To expand the IP/MPLS backbone network and deploy BGP/MPLS IP VPN for an enterprise,
you need to add the Spoke-PE devices in the branches to the IP/MPLS backbone network in
the headquarters. MPLS LDP packets between the headquarters and branches need to be
transmitted over GRE tunnels because the Internet cannot provide the MPLS function. As
there are a large number of branches and devices in the branches dynamically obtain their
public addresses, DSVPN is used to establish GRE tunnels between the headquarters and
branches. In addition, IPSec is required to encrypt and protect VPN data transmitted over the
Internet. As a result, L3VPN with LDP signals carried by DSVPN and protected by IPSec can
meet the requirements of the enterprise.
The configuration roadmap for L3VPN with LDP signals carried by DSVPN and protected by
IPSec is as follows:
1. Configure branch devices to save only summarized routes to the headquarters, configure
OSPF on Hub-P and Spoke-PEs to advertise routes, and set the OSPF network type to
point-to-multipoint (P2MP), so that all VPN data between branches is forwarded by the
headquarters.
2. Configure IPSec on Spoke-PE2, Spoke-PE3, and Hub-P and apply IPSec profiles to
tunnel interfaces to encrypt and protect VPN data between branches.
3. Enable MPLS LDP on tunnel interfaces of Spoke-PE2, Spoke-PE3, and Hub-P and set
up MPLS LSP tunnels to implement LDP over mGRE.
4. Configure L3VPN on Spoke-PE2, Spoke-PE3, and PE1 to implement secure
interconnection between the headquarters and branches and between branches. Because
there are a large number of branches, a route reflector can be used to reduce the number
of MP-IBGP connections between PEs.
NOTE
Do not configure NHRP redirection on the Hub because LDP over mGRE does not need to establish tunnels
for direct communication between branches.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure interface IP addresses and OSPF on Hub-P and PE1 to implement interconnection
on the IP/MPLS backbone network.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration of Hub-P is similar to that of PE1, and is not mentioned here.
After the configuration is complete, an OSPF neighbor relationship can be set up between
Hub-P and PE1. Run the display ospf peer command. You can see that the neighbor status is
Full. Run the display ip routing-table command. You can see that Hub-P and PE1 have
learnt the routes to Loopback1 of each other.
Step 2 Configure interface IP addresses and static routes on Hub-P, Spoke-PE2, and Spoke-PE3 to
ensure that public routes are reachable.
Because Hub-P, Spoke-PE2, and Spoke-PE3 are directly connected to the Internet, IP
addresses and default static routes are manually specified here.
[Spoke-PE2] ip route-static 0.0.0.0 0 202.2.1.1
The configurations of Spoke-PE3 and Hub-P are similar to that of Spoke-PE2, and are not
mentioned here.
After the configuration is complete, devices can ping each other and public routes are
reachable.
Step 3 Create tunnel interfaces and configure DSVPN on Hub-P, Spoke-PE2, and Spoke-PE3.
1. Create an mGRE interface, configure an IP address, and specify a source tunnel
interface.
[Spoke-PE2-Tunnel0/0/1] ip address 172.10.1.2 24
[Spoke-PE2-Tunnel0/0/1] tunnel-protocol gre p2mp
[Spoke-PE2-Tunnel0/0/1] source gigabitethernet 1/0/0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
not mentioned here.
2. Configure OSPF to advertise the MPLS LSR ID as DSVPN subnet information through
[Spoke-PE2] ospf 1
not mentioned here.
3. Configure NHRP and set the OSPF network type to P2MP. Do not configure NHRP
redirection on the Hub-P.
# Configure Hub-P.
[Hub-P-Tunnel0/0/1] nhrp entry multicast dynamic
[Hub-P-Tunnel0/0/1] ospf network-type p2mp
[Hub-P-Tunnel0/0/1] ospf dr-priority 100
After the configuration is complete, run the display nhrp peer all command on Hub-P to
view registration information about Spoke-PE2 and Spoek-PE3.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Run the display ip routing-table command on all devices on the IP/MPLS backbone
network. You can see that all devices have learnt the routes to Loopback1 of other devices.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 Configure IPSec on Spoke-PE2, Spoke-PE3, and Hub-P.

Configure IPSec on the devices and bind IPSec profiles to the tunnel interfaces.
# Configure Hub-P.
[Hub-P] ipsec proposal pro1
[Hub-P-ipsec-proposal-pro1] transform ah-esp
[Hub-P-ipsec-proposal-pro1] ah authentication-algorithm sha2-512
[Hub-P-ipsec-proposal-pro1] esp authentication-algorithm sha2-512
[Hub-P-ipsec-proposal-pro1] esp encryption-algorithm aes-256
[Hub-P-ipsec-proposal-pro1] quit
[Hub-P] ike proposal 1
[Hub-P-ike-proposal-1] dh group5
[Hub-P-ike-proposal-1] authentication-algorithm aes-xcbc-mac-96
[Hub-P-ike-proposal-1] prf aes-xcbc-128
[Hub-P-ike-proposal-1] quit
[Hub-P] ike peer Hub-P v2
[Hub-P-ike-peer-Hub-P] ike-proposal 1
[Hub-P-ike-peer-Hub-P] pre-shared-key cipher huawei
[Hub-P-ike-peer-Hub-P] quit
[Hub-P] ipsec profile profile1
[Hub-P-ipsec-profile-profile1] proposal pro1
[Hub-P-ipsec-profile-profile1] ike-peer Hub-P
[Hub-P-ipsec-profile-profile1] quit
[Hub-P-Tunnel0/0/1] ipsec profile profile1
The configurations of Spoke-PE2 and Spoke-PE3 are similar to that of Hub-P, and are not
mentioned here.
After the configuration is complete, run the display ipsec sa command on Spoke-PE2, Spoke-
PE3, and Hub-P. You can see that security associations (SAs) have been established.
Step 5 Enable basic MPLS functions and MPLS LDP on Spoke-PE2, Spoke-PE3, Hub-P, and PE1.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
The configurations of Spoke-PE2, Spoke-PE3 and Hub-P are similar to that of PE1, and are
not mentioned here.
Step 6 Enable MPLS LDP on the interfaces of Spoke-PE2, Spoke-PE3, Hub-P, and PE1.
Enable MPLS LDP on interfaces of Hub-P and PE1 that are directly connected to each other
and enable MPLS LDP on tunnel interfaces of Spoke-PE2, Spoke-PE3 and Hub-P to establish
MPLS LSP tunnels.
# Configure PE1.
# Configure Hub-P.
[Hub-P] interface gigabitethernet 2/0/0
[Hub-P-GigabitEthernet2/0/0] mpls
[Hub-P-GigabitEthernet2/0/0] mpls ldp
[Hub-P-GigabitEthernet2/0/0] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Hub-P-Tunnel0/0/1] mpls
[Hub-P-Tunnel0/0/1] mpls ldp
After the configuration is complete, PE1, Spoke-PE2, and Spoke-PE3 can establish LDP
sessions with Hub-P. Run the display mpls ldp session command. You can see that the MPLS
LDP session status is Operational.
Step 7 Configure VPN instances on Spoke-PE2, Spoke-PE3, and PE1 and bind VPN instances to
interfaces.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

each device to view the configuration of VPN instances.
Step 8 Set up MP-IBGP peer relationships between Spoke-PE2, Spoke-PE3, and PE1.
Configure PE1 as a route reflector. Spoke-PE2 and Spoke-PE3 can set up MP-IBGP peer
relationships with PE1.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] group rr1 internal
[PE1-bgp] peer rr1 connect-interface loopback 1
[PE1-bgp-af-vpnv4] peer rr1 enable
[PE1-bgp-af-vpnv4] reflector cluster-id 100
[PE1-bgp-af-vpnv4] peer rr1 reflect-client
[PE1-bgp-af-vpnv4] undo policy vpn-target
[PE1-bgp-vpn1] quit
[PE1-bgp-vpn2] quit
[PE1-bgp] quit
[Spoke-PE2] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Spoke-PE3] bgp 100
After the configuration is complete, run the display bgp vpnv4 all peer command on Spoke-
PE2, Spoke-PE3, and PE1. You can see that Spoke-PE2, Spoke-PE3, and PE1 have set up
BGP peer relationships with PE1 and are in Established state.


PrefRcv
2.2.2.9 4 100 5 12 0 00:02:00

Established 2
3.3.3.9 4 100 5 11 0 00:01:02
Established 2

# After the configuration is complete, Spoke-PE2, Spoke-PE3, and PE1 can learn the routes to
vpn1 and vpn2 of each other.
to vpn-instance
------------------------------------------------------------------------------
192.168.1.0/24 Direct 0 0 D 192.168.1.1

192.168.1.1/32 Direct 0 0 D 127.0.0.1
192.168.1.255/32 Direct 0 0 D 127.0.0.1
192.168.11.0/24 IBGP 255 0 RD 2.2.2.9
192.168.21.0/24 IBGP 255 0 RD 3.3.3.9


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
to vpn-instance
------------------------------------------------------------------------------
192.168.2.0/24 Direct 0 0 D 192.168.2.1

192.168.2.1/32 Direct 0 0 D 127.0.0.1
192.168.2.255/32 Direct 0 0 D 127.0.0.1
192.168.12.0/24 IBGP 255 0 RD 2.2.2.9
192.168.22.0/24 IBGP 255 0 RD 3.3.3.9
# Devices in the same VPN can successfully ping each other, whereas devices in different
VPNs cannot.
# The display on Spoke-PE2 is used as an example:


0.00% packet loss


0.00% packet loss
----End
Configuration Files
NOTE
This example does not provide configuration files of devices on the Internet.
#
sysname PE1
#
ip vpn-instance
vpn1
ipv4-
family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
route-distinguisher
100:1
extcommunity
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
100:2
extcommunity
extcommunity
#
mpls lsr-id
1.1.1.9
mpls
mpls ldp
#
255.255.255.0
mpls
mpls ldp
#
vpn1
ip address 192.168.1.1 255.255.255.0
#
vpn2
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp
100
group rr1
internal
peer rr1 connect-interface
LoopBack1
100
peer 2.2.2.9 group
rr1
100
peer 3.3.3.9 group
rr1
ipv4-family
unicast
undo

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
synchronization
peer rr1
enable
peer 2.2.2.9
enable
peer 2.2.2.9 group
rr1
peer 3.3.3.9
enable
peer 3.3.3.9 group
rr1
ipv4-family
vpnv4
reflector cluster-id
100
undo policy vpn-
target
peer rr1
enable
peer rr1 reflect-
client
peer 2.2.2.9
enable
peer 2.2.2.9 group
rr1
peer 3.3.3.9
enable
peer 3.3.3.9 group
rr1
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9
0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l Hub-P configuration file
#
sysname Hub-P
#
mpls lsr-id
4.4.4.9
mpls
mpls
ldp
#
ipsec proposal
pro1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
transform ah-
esp
sha2-512
sha2-512
#
ike proposal
1
dh
group5
authentication-algorithm aes-xcbc-
mac-96
prf aes-
xcbc-128
#
ike peer Hub-P v2
ike-proposal
1
#
ipsec profile
profile1
ike-peer Hub-
P
proposal pro1
#
ip address 202.1.1.2 255.255.255.0
#
255.255.255.0
mpls
mpls ldp
#
interface
LoopBack1
ip address 4.4.4.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type
p2mp
ospf dr-priority
100
mpls
mpls
ldp
dynamic
#
ospf

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1
area
0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.1.1.0
0.0.0.255
network 172.10.1.0
0.0.0.255
#
ip route-static 0.0.0.0 0.0.0.0 202.1.1.1

#
return
#
sysname Spoke-PE2
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
200:1
extcommunity
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
200:2
extcommunity
extcommunity
#
mpls lsr-id
2.2.2.9
mpls
mpls
ldp
#
ipsec proposal
pro1
transform ah-
esp
sha2-512
sha2-512
aes-256
#
ike proposal
1
dh
group5
mac-96

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
prf aes-
xcbc-128
#
ike peer Spoke-PE2 v2

ike-proposal 1
#
ipsec profile
profile1
ike-peer Spoke-
PE2
proposal
pro1
#
ip address 202.2.1.2 255.255.255.0
#
vpn1
ip address 192.168.11.1 255.255.255.0
#
vpn2
ip address 192.168.12.1 255.255.255.0
#
interface
LoopBack1
ip address 2.2.2.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type
p2mp
ospf dr-priority
0
mpls
mpls
ldp
nhrp entry 172.10.1.1 202.1.1.2
register
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
peer 1.1.1.9
enable
ipv4-family
vpnv4
policy vpn-
target
peer 1.1.1.9
enable
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf
1
area
0.0.0.0
network 2.2.2.9
0.0.0.0
network 172.10.1.0
0.0.0.255
#
ip route-static 0.0.0.0 0.0.0.0 202.2.1.1

#
return
#
sysname Spoke-PE3
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
300:1
extcommunity
extcommunity
#
ip vpn-instance
vpn2
ipv4-
family
route-distinguisher
300:2
extcommunity
extcommunity
#
mpls lsr-id

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3.3.3.9
mpls
mpls
ldp
#
ipsec proposal
pro1
transform ah-
esp
sha2-512
sha2-512
aes-256
#
ike proposal
1
dh
group5
mac-96
prf aes-
xcbc-128
#
ike peer Spoke-PE3 v2

ike-proposal 1
#
ipsec profile
profile1
ike-peer Spoke-
PE3
proposal
pro1
#
ip address 202.3.1.2 255.255.255.0
#
vpn1
ip address 192.168.21.1 255.255.255.0
#
vpn2
ip address 192.168.22.1 255.255.255.0
#
interface
LoopBack1
ip address 3.3.3.9
255.255.255.255
#
interface
Tunnel0/0/1
255.255.255.0
tunnel-protocol gre
p2mp
source
ospf network-type

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
p2mp
ospf dr-priority
0
mpls
mpls
ldp
nhrp entry 172.10.1.1 202.1.1.2
register
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 1.1.1.9
enable
ipv4-family
vpnv4
policy vpn-
target
peer 1.1.1.9
enable
vpn1
import-route
direct
vpn2
import-route
direct
#
ospf
1
area
0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.10.1.0
0.0.0.255
#
ip route-static 0.0.0.0 0.0.0.0 202.3.1.1

#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.9.25 Example for Configuring a Tunnel Policy for an L3VPN

As shown in Figure 8-66, CE1 and CE3 belong to vpna, and CE2 and CE4 belong to vpnb.
Two MPLS TE tunnels and one LSP are set up between PE1 and PE2. To use the tunnels
more efficiently, vpnb uses multiple tunnels to share the loads and prefers the TE tunnels for
load balancing.
Figure 8-66 Networking diagram for configuring a tunnel policy for an L3VPN
Loopback1 Loopback1
3.3.3.3/32 5.5.5.5/32
vpna vpna
CE1 CE3
Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
MPLS TE tunnel 1
GE1/0/0 GE1/0/0
10.1.1.1/30 10.3.1.1/30
GE2/0/0 MPLS TE tunnel 2 ( binding) GE2/0/0
10.1.1.2/30 10.3.1.2/30
GE1/0/0 GE1/0/0
GE3/0/0 GE3/0/0
100.1.1.1/30 100.1.1.2/30
10.2.1.2/30 PE1 PE2 10.4.1.2/30
GE1/0/0 GE1/0/0
10.2.1.1/30 LSP 10.4.1.1/30
CE2 CE4
vpnb vpnb
Loopback1 Loopback1
4.4.4.4/32 6.6.6.6/32
1. Configure a routing protocol so that PEs can communicate with each other.
2. Configure basic MPLS capabilities on the routers on the backbone network and set up an
LSP and two MPLS TE tunnels between the PEs.
3. Configure VPN instances on PEs and connect CEs to the PEs.
4. Configure tunnel policies and apply the policies to different VPN instances.
5. Configure MP-IBGP to exchange VPN routing information.
Procedure
Step 1 Configure an IGP on the MPLS backbone network so that PEs can communicate.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1] interface gigabitethernet1/0/0
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure PE2.
[PE2] ospf 1
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
# After the configuration is complete, run the display ip routing-table command on PEs, and
you can view that PEs have learned the routes to Loopback1 interfaces from each other.
Route Flags: R - relay, D - download to forwarding
------------------------------------------------------------------------------
Routing Tables: _public_
2.2.2.2/32 OSPF 10 1 D 100.1.1.2
100.1.1.0/30 Direct 0 0 D 100.1.1.1
100.1.1.1/32 Direct 0 0 D 127.0.0.1
100.1.1.3/32 Direct 0 0 D 127.0.0.1
Step 2 Configure basic MPLS capabilities on the MPLS backbone to set up an LDP LSP between
PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# After the configuration is complete, an LDP LSP is set up between PE1 and PE2. Run the
display tunnel-info all command, and you can find the LSP destined for the address 2.2.2.2.
Run the display mpls ldp lsp command, and you can view LSP information.

[PE1] display tunnel-info all
----------------------------------------------------------------------
0x15 lsp 2.2.2.2 21
0x16 lsp 2.2.2.2 22
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/16 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 100.1.1.2 GE1/0/0
2.2.2.2/32 16/3 2.2.2.2 100.1.1.2 GE1/0/0
-------------------------------------------------------------------------------
Step 3 Set up MPLS TE tunnels between PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] mpls rsvp-te
[PE1-mpls] mpls te cspf
[PE1-mpls] quit
[PE1-GigabitEthernet1/0/0] mpls te
[PE1-GigabitEthernet1/0/0] mpls rsvp-te
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Enable OSPF on the devices along the TE tunnels to transmit TE attributes.

# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] mpls-te enable
[PE1-ospf-1] quit
# Configure PE2.
[PE2] ospf 1
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
# Configure an MPLS TE tunnel.

# Configure PE1.
[PE1-Tunnel0/0/1] ip address unnumbered interface loopback 1
[PE1-Tunnel0/0/1] tunnel-protocol mpls te
[PE1-Tunnel0/0/1] mpls te tunnel-id 11
[PE1-Tunnel0/0/1] mpls te commit
# Configure PE2.
# Configure an MPLS TE tunnel and bind the tunnel to the VPN.

# Configure PE1.
[PE1-Tunnel0/0/2] mpls te reserved-for-binding
# Configure PE2.
# After the configuration is complete, run the display mpls te tunnel-interface command on
PEs, and you can view that Tunnel0/0/1 and Tunnel0/0/2 are both Up. The information
displayed on PE1 is used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] display mpls te tunnel-interface

----------------------------------------------------------------
Tunnel0/0/1
----------------------------------------------------------------
Tunnel State Desc : UP
Active LSP : Primary LSP
Session ID : 11
Ingress LSR ID : 1.1.1.1 Egress LSR ID: 2.2.2.2
Admin State : UP Oper State : UP
Primary LSP State : UP
Main LSP State : READY LSP ID : 1
----------------------------------------------------------------
Tunnel0/0/2
----------------------------------------------------------------
Session ID : 22
# Configure PE1.
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Assign IP addresses to the interfaces on the CEs according to Figure 8-66. The
configuration procedure is not provided here.
# After the configuration is complete, run the display ip vpn-instance verbose command on
PEs, and you can view configuration of the VPN instances.
NOTE
If a PE has multiple interfaces bound to the same VPN, when you run the ping command to ping the CE
connected to the remote PE, specify the source IP address; that is, specify -a source-ip-address in the
ping -a source-ip-address -vpn-instance vpn-instance-name destination-address command. Otherwise,
the ping fails.
Step 5 Configure and apply a tunnel policy on PEs.

# Configure the tunnel policy for binding primary tunnel and apply the tunnel policy to vpna.
# Configure PE1.
[PE1] tunnel-policy policy1
[PE1-tunnel-policy-policy1] tunnel binding destination 2.2.2.2 te tunnel 0/0/2
[PE1-tunnel-policy-policy1] quit
[PE1-vpn-instance-vpna-af-ipv4] tnl-policy policy1
# Configure PE2.
[PE2-tunnel-policy-policy1] tunnel binding destination 1.1.1.1 te tunnel 0/0/2
[PE2-vpn-instance-vpna-af-ipv4] tnl-policy policy1
# Configure a tunnel type prioritizing policy and apply the policy to vpnb.
# Configure PE1.
[PE1-tunnel-policy-policy2] tunnel select-seq cr-lsp lsp load-balance-number 2
[PE1-vpn-instance-vpnb-af-ipv4] tnl-policy policy2
# Configure PE2.
[PE2-tunnel-policy-policy2] tunnel select-seq cr-lsp lsp load-balance-number 2
[PE2-vpn-instance-vpnb-af-ipv4] tnl-policy policy2

# Configure PE1.
[PE1] bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure PE2.
[PE2] bgp 100
# After the configuration is complete, run the display bgp peer or display bgp vpnv4 all
peer command on the PEs. The command output shows that a BGP peer relationship is set up
between PEs and the BGP peer relationship is in Established state.
Step 7 Set up EBGP peer relationships between PEs and CEs.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-af-vpna] peer 10.1.1.1 as-number 65410
[PE1-bgp-af-vpna] quit
[PE1-bgp-af-vpnb] peer 10.2.1.1 as-number 65410
[PE1-bgp-af-vpnb] quit
[PE1-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure CE2.
[CE2] bgp 65410
[CE2-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp-af-vpna] peer 10.3.1.1 as-number 65420
[PE2-bgp-af-vpna] quit
[PE2-bgp-af-vpnb] peer 10.4.1.1 as-number 65420
[PE2-bgp-af-vpnb] quit
[PE2-bgp] quit
# Configure CE3.
[CE3] bgp 65420
[CE3-bgp] quit
# Configure CE4.
[CE4] bgp 65420
[CE4-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Run the display bgp routing-table command on CEs, and you can find the routes to the
remote CEs.
[CE1] display bgp routing-table


*> 3.3.3.3/32 0.0.0.0 0 0 ?

*> 5.5.5.5/32 10.1.1.2 0 100 65420?
*> 10.4.1.0/24 0.0.0.0 0 0 ?
10.4.1.1 0 0 100?
*> 10.1.1.2/32 0.0.0.0 0 0 ?
*> 10.3.1.0/30 10.1.1.2 0 100?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
# Run the display ip routing-table vpn-instance verbose command on PEs, and you can find
the tunnels used by the VPN routes.
[PE1] display ip routing-table vpn-instance vpna 5.5.5.5 verbose
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
Label: 0x13 QoSInfo: 0x0
IndirectID: 0xb9
RelayNextHop: 0.0.0.0 Interface: Tunnel0/0/2
TunnelID: 0x3d Flags: RD
[PE1] display ip routing-table vpn-instance vpnb 6.6.6.6 verbose
Route Flags: R - relay, D - download for forwarding
------------------------------------------------------------------------------
Routing Table : vpnb
Summary Count : 1
Label: 0x15 QoSInfo: 0x0
IndirectID: 0xb8
RelayNextHop: 0.0.0.0 Interface: Tunnel0/0/1
TunnelID: 0x3b Flags: RD
RelayNextHop: 0.0.0.0 Interface: LDP LSP
TunnelID: 0x1c Flags: RD

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# CEs in the same VPN can ping each other, whereas CEs in different VPNs cannot.
----End
Configuration Files
#
sysname PE1
#
ipv4-family
tnl-policy policy1
#
ipv4-family
tnl-policy policy2
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
ip address 100.1.1.1 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls ldp
#
ip address 10.1.1.2 255.255.255.252
#
ip address 10.2.1.2 255.255.255.252
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
tunnel-protocol mpls te
destination 2.2.2.2
mpls te tunnel-id 11
mpls te commit
#
destination 2.2.2.2
mpls te reserved-for-binding
mpls te commit
#
bgp 100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
#
#
ospf 1
area 0.0.0.0
mpls-te enable
network 100.1.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
#
tunnel-policy policy1
tunnel binding destination 2.2.2.2 te Tunnel0/0/2
#
tunnel select-seq cr-lsp lsp load-balance-number 2
#
return
#
sysname PE2
#
ipv4-family
tnl-policy policy1
#
ipv4-family
tnl-policy policy2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.252
mpls
mpls te
mpls rsvp-te
mpls ldp
#
ip address 10.3.1.2 255.255.255.252
#
ip address 10.4.1.2 255.255.255.252

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
destination 1.1.1.1
mpls te commit
#
destination 1.1.1.1
mpls te commit
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
#
#
ospf 1
area 0.0.0.0
mpls-te enable
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
#
tunnel select-seq cr-lsp lsp load-balance-number 2
#
return

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
import-route direct

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
return

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.252
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE3
#
ip address 10.3.1.1 255.255.255.252
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.252
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
8.10 FAQ About BGP/MPLS IP VPN

This section describes the FAQ about BGP/MPLS IP VPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
8.10.1 Why Routes Cannot Be Imported When AS Numbers on the

BGP/MPLS IP VPN Are the Same?
When the AS number in the Update message to be received by the EBGP-enabled device is
the same as the AS number on the device, the device does not receive the Update message.
This prevents routing loops. In some scenarios, the device needs to receive an Update
message that carries the same AS number as the AS number on the device. In Hub and Spoke
networking, when the Hub-PE and Hub-CE use EBGP, the Update message received by the
Hub-CE contains the AS number of the Hub-PE. To prevent the Hub-PE from discarding such
Update message, run the peer allow-as-loop command to set the number of times for the
repeated AS number.
8.11 References for BGP/MPLS IP VPN

This section lists references for BGP/MPLS IP VPN.
The following table lists the references for BGP/MPLS IP VPN.
Docume Description Remarks

nt
RFC1772 Application of the Border Gateway Protocol in the -

Internet
RFC 4760 Multiprotocol Extensions for BGP-4 -
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs) -
RFC 2764 A Framework for IP Based Virtual Private Networks -
RFC 5492 Capabilities Advertisement with BGP-4 -
RFC 2917 A Core MPLS IP VPN Architecture -
RFC 3107 Carrying Label Information in BGP-4 -
RFC 4026 Provider Provisioned Virtual Private Network (VPN) -

Terminology
RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/ -

MPLS IP Virtual Private Networks (VPNs)
RFC3478 Graceful Restart Mechanism for Label Distribution -

Protocol

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 9 MCE IPv6 Configuration
9 MCE IPv6 Configuration
About This Chapter
In the IPv6 network, one CE device connects to only one VPN. If multiple VPNs are
deployed on a customer network, multiple CE devices are required. A multi-VPN-instance CE
(MCE) device can connect to multiple VPNs. The MCE solution isolates services of different
VPNs while reducing cost of network devices.
9.1 Overview of MCE IPv6

A multi-VPN-instance CE (MCE) device uses routing multi-instance to isolate services or
users of IPv6.
9.2 Licensing Requirements and Limitations for MCE IPv6.
9.3 Configuring an MCE Device
An MCE device can connect to multiple VPNs. The MCE solution isolates services of
different VPNs while reducing cost of network devices.
9.4 Configuration Examples for MCE IPv6
This section provides an example for configuring an MCE IPv6 device.
9.1 Overview of MCE IPv6

A multi-VPN-instance CE (MCE) device uses routing multi-instance to isolate services or
users of IPv6.
BGP/MPLS IP VPN uses tunnels to transmit data of private networks on a public network. In
the traditional BGP/MPLS IP VPN architecture, each VPN instance must use a CE device to
connect to a PE device, as shown in Figure 9-1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 9-1 Networking without an MCE device
CE VPN1
Site
PE CE
VPN2
MPLS Site
Backbone
VPN3
CE Site
In may cases, a private network must be divided into multiple VPNs to realize fine-grained
service management and enhance security. Services of users in different VPNs must be
completely isolated. Deploying a CE device for each VPN increases the cost of device
procurement and maintenance. If multiple VPNs share one CE device, data security cannot be
ensured because all the VPNs use the same routing and forwarding table.
The MCE technology ensures data security between different VPNs while reducing network
construction and maintenance costs. Figure 9-2 shows the MCE deployment.
Figure 9-2 Networking with an MCE device
VPN1
Site
PE MCE
VPN2
MPLS
Backbone Site
VPN3
Site
An MCE device has some PE functions. By binding each VPN instance to a different
interface, an MCE device creates and maintains an independent VRF for each VPN. This
application is also called multi-VRF application. The MCE device isolates forwarding paths
of different VPNs on a private network and advertises routes of each VPN to the peer PE
device, ensuring that VPN packets are correctly transmitted on the public network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
9.2 Licensing Requirements and Limitations for MCE

IPv6.
None
MCE IPv6 is a basic feature of the device and is not under license control.
Feature Limitations
The AR120 series do not support MCE IPv6.
9.3 Configuring an MCE Device

An MCE device can connect to multiple VPNs. The MCE solution isolates services of
different VPNs while reducing cost of network devices.
Before configuring an MCE device, complete the following task:
l Configuring the link layer protocol and network layer protocol for LAN interfaces and
connecting the LAN to the MCE device (reserve one interface for each service)
The first three tasks are mandatory.
9.3.1 Configuring a VPN Instance
Context
The following configurations are performed on the MCE device.
Similar configurations must be performed on the PE devices. The PE configuration procedure
and commands used vary in devices from different vendors and different product models. For
detailed configuration, see the documentation of the PE devices.
Procedure
Step 1 Enable IPv6 globally
1. Run system-view
2. Run ipv6

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
IPv6 is enabled globally.
Step 2 Create VPN instance

NOTE
A VPN instance name is case sensitive. For example, vpn1 and VPN1 are different VPN instances.
No default VPN instance is defined on an MCE device, and you can create multiple VPN
instances on the MCE device.
The description is configured for the VPN instance.
The description is similar to that of the host name and interface, which can be used to
record information about the relationship between a VPN instance and a VPN.
3. (Optional) Run service-id service-id
A service ID is created for the VPN instance.
A service ID is unique on a device. It distinguishes a VPN service from other VPN

services on the network.
4. Run ipv6-family
The IPv6 address family is enabled for the VPN instance, and the VPN instance IPv6
VPN instances support both the IPv4 and IPv6 address families. Configurations in a
VPN instance can be performed only after an address family is enabled for the VPN
instance based on the advertised route and forwarding data type.
5. Run route-distinguisher route-distinguisher
An RD is configured for the VPN instance IPv6 address family.
A VPN instance IPv6 address family takes effect only after being configured with an
RD. The RDs of different VPN instances on a PE must be different.
NOTE
– An RD can be modified or deleted only after the VPN instance is deleted or the VPN instance
IPv6 address family is disabled.
Step 3 Bind the VPN instance to an interface.

1. Run system-view


The VPN instance is bound to the interface.
By default, no VPN instance is bound to an interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
When you run the ip binding vpn-instance command on an interface, all configurations of Layer
3 features on the interface, such as the IP address and routing protocol, are deleted. To use these
features, reconfigure them.
4. Run ipv6 enable
IPv6 is enabled on the interface.
5. Run ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length }
An IPv6 address is configured for the interface.
----End
9.3.2 Configure Route Exchange Between an MCE Device and

VPN Sites
Context
Routing protocols that can be used between an MCE device and VPN sites are IPv6 static
routing, RIPng, OSPFv3, IS-IS IPv6, and BGP4+. Choose one of the following configurations
as needed:
l Configure IPv6 Static Routes Between an MCE Device and a Site
l Configure RIPng Between an MCE Device and a Site
l Configure OSPFv3 Between an MCE Device and a Site
l Configure IS-IS IPv6 Between an MCE Device and a Site
l Configure BGP4+ between an MCE Device and a Site
The following configurations are performed on the MCE device. On the devices in the site,
you only need to configure the corresponding routing protocol.
Configure IPv6 Static Routes Between an MCE Device and a Site

Perform the following configurations on the MCE device. You only need to configure a IPv6
static route to the MCE device in the site. The site configuration is not provided here.
NOTE
For detailed configuration of static routes, see Configuring IPv6 Static Routes in the Huawei
Routers Configuration Guide – IP Routing.

Enter the system view. system-view -

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure an ipv6 static ipv6 route-static vpn- You must specify the next
route to the site. instance vpn-instance-name hop address on the MCE
dest-ipv6-address prefix- device.
length { [ interface-type
interface-number ] nexthop-
ipv6-address | nexthop-ipv6-
address [ public ] | vpn-
instance vpn-destination-
name nexthop-ipv6-
address } [ preference
Configure RIPng Between an MCE Device and a Site

NOTE
For detailed RIPng configuration, see RIPng Configuration in the Huawei


Create a RIPng process ripng process-id vpn- A RIPng process can be

running between the MCE instance vpn-instance-name bound to only one VPN
device and the site and enter instance. If a RIPng process
the RIPng view. is not bound to any VPN
instance before it is started,
this process becomes a
public network process and
can no longer be bound to a
VPN instance.
(Optional) Import the routes import-route { { ripng | Perform this step if another
to the remote sites isis | ospfv3 } [ process-id ] | routing protocol is running
advertised by the PE device bgp | unr | direct | static } between the MCE and PE
in to the RIPng routing [ cost cost | route-policy devices in the VPN instance.
table. route-policy-name ] *
Return to system view. quit -
Enter the interface view. interface interface-type -

interface-number
Enable RIPng on the ripng process-id enable -

interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure OSPFv3 Between an MCE Device and a Site

Perform the following configurations on the MCE device. Configure OSPFv3 in the site. The
site configuration is not provided here.
NOTE
For detailed OSPFv3 configuration, see OSPFv3 Configuration in the Huawei


Create an OSPFv3 process ospfv3 [ process-id ] [ vpn- -

running between the MCE instance vpn-instance-
device and the site and enter name ]
the OSPFv3 view.
(Optional) Import the routes import-route { bgp Perform this step if another
to the remote sites [ permit-ibgp ] | unr | routing protocol is running
advertised by the PE device direct | ripng help-process- between the MCE and PE
into the OSPFv3 routing id | static | isis help-process- devices in the VPN instance.
table. id | ospfv3 help-process-id }
[ cost cost | type type | tag
tag | route-policy route-
policy-name ] *
Enter the interface view. interface interface-type -

interface-number
Enable OSPFv3 on the ospfv3 process-id area -

interface. area-id [ instance instance-
id ]
Configure IS-IS IPv6 Between an MCE Device and a Site

Perform the following configurations on the MCE device. You only need to configure IS-IS
IPv6 in the site. The site configuration is not provided here.
NOTE
For detailed IS-IS configuration, see IS-IS IPv6 Configuration in the Huawei

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


view.

between the MCE instance. If an IS-IS IPv6
device and the site process is not bound to any
IPv6 view. started, this process
be bound to a VPN
instance.

three NETs can be
on each router.
Enable IS-IS IPv6 ipv6 enable [ topology { compatible -

on the process. [ enable-mt-spf ] | ipv6 | standard } ]
(Optional) Import Use either of the following commands: Perform this step if another
the routes to the l ipv6 import-route { direct | unr | routing protocol is running
remote sites { ospfv3 | ripng | isis } [ process- between the MCE and PE
advertised by the id ] | bgp } inherit-cost [ tag tag | devices in the VPN
PE device into the route-policy route-policy-name | instance.
IS-IS IPv6 routing
{ level-1 | level-2 | level-1-2 } ] *
table.
l ipv6 import-route { static | direct |
unr | { ospfv3 | ripng | isis }
[ process-id ] | bgp } [ cost cost |
tag tag | route-policy route-policy-
name | { level-1 | level-2 |
level-1-2 } ] *

view.

which the VPN
instance is bound.
Enable IS-IS IPv6 isis ipv6 enable [ process-id ] -

on the interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure BGP4+ between an MCE Device and a Site



system
view.

BGP view. dot }
Enter the ipv6-family vpn-instance vpn- -

BGP-VPN instance-name
instance
IPv6
address
family
view.

the device number
connected
to the MCE
device in
the site as a
VPN peer.
Import the import-route protocol [ process-id ] Perform this step if another routing
routes to [ med med | route-policy route- protocol is running between the
the remote policy-name ] * MCE and PE devices in the VPN
sites instance.
advertised
by the PE
device into
the BGP
routing
table.
Perform the following configurations on the device connected to the MCE device in the site.
Table 9-6 Site configuration


system
view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

BGP view. dot }

the MCE number
device as a
VPN peer.
Enter the ipv6-family unicast -

BGP-VPN
instance
IPv6
address
family
view.
Configure peer { group-name | ipv6-address } -

the MCE enable
device as a
VPN peer.
Import IGP import-route protocol [ process-id ] The site must advertise routes to its
routes of [ med med | route-policy route- attached VPN network segments to
the VPN policy-name ] * the MCE device.
into the
BGP
routing
table.
9.3.3 Configure Route Exchange Between an MCE Device and a

PE Device
Context
Routing protocols that can be used between an MCE device and a PE device are IPv6 static
routing, RIPng, OSPFv3, IS-IS IPv6198742hw. Choose one of the following configurations
as needed:
l Configure IPv6 Static Routes Between an MCE Device and a PE Device
l Configure RIPng Between an MCE Device and a PE Device
l Configure OSPFv3 Between an MCE Device and a PE Device
l Configure IS-IS IPv6 Between an MCE Device and a PE Device
l Configure BGP4+ Between an MCE Device and a PE Device
Configure IPv6 Static Routes Between an MCE Device and a PE Device


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Configure a IPv6 static route ipv6 route-static vpn- You must specify the next
to the PE device. instance vpn-instance-name hop address on the MCE
dest-ipv6-address prefix- device.
length { [ interface-type
interface-number ] nexthop-
ipv6-address | nexthop-ipv6-
address [ public ] | vpn-
instance vpn-destination-
name nexthop-ipv6-
address } [ preference
Configure RIPng Between an MCE Device and a PE Device


Create a RIPng process ripng process-id vpn- A RIPng process can be

running between the MCE instance vpn-instance-name bound to only one VPN
and PE devices and enter the instance. If a RIPng process
RIPng view. is not bound to any VPN
instance before it is started,
this process becomes a
public network process and
can no longer be bound to a
VPN instance.
(Optional) Import VPN import-route { { ripng | Perform this step if another

routes of the site into the isis | ospfv3 } [ process-id ] | routing protocol is running
RIP routing table. bgp | unr | direct | static } between the MCE device
[ cost cost | route-policy and VPN sites in the VPN
route-policy-name ] * instance.
Enter an interface view. interface interface-type -

interface-number
Enable RIPng on the ripng process-id enable -

interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure OSPFv3 Between an MCE Device and a PE Device


Create an OSPFv3 process ospfv3 [ process-id ] vpn- -

running between the MCE instance vpn-instance-name
and PE devices and enter the
OSPFv3 view.
(Optional) Import VPN import-route { bgp Perform this step if another

routes of the site into the [ permit-ibgp ] | unr | routing protocol is running
OSPF routing table. direct | ripng help-process- between the MCE device
id | static | isis help-process- and VPN sites in the VPN
id | ospfv3 help-process-id } instance.
[ cost cost | type type | tag
tag | route-policy route-
policy-name ] *
Enter an interface view. interface interface-type -

interface-number
Enable OSPFv3 on the ospfv3 process-id area -

interface which the VPN area-id [ instance instance-
instance is bound. id ]
Configure IS-IS IPv6 Between an MCE Device and a PE Device



view.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

between the MCE instance. If an IS-IS
and PE devices process is not bound to any
view. started, this process
be bound to a VPN
instance.

three NETs can be
on each router.
Enable IPv6 for ipv6 enable [ topology { compatible -

the IS-IS process. [ enable-mt-spf ] | ipv6 | standard } ]
(Optional) Import Use either of the following commands: Perform this step if another
VPN routes of the l ipv6 import-route { direct | unr | routing protocol is running
site into the IS-IS { ospfv3 | ripng | isis } [ process- between the MCE device
routing table. id ] | bgp } inherit-cost [ tag tag | and VPN sites in the VPN
route-policy route-policy-name | instance.
{ level-1 | level-2 | level-1-2 } ] *
l ipv6 import-route { static | direct |
unr | { ospfv3 | ripng | isis }
[ process-id ] | bgp } [ cost cost |
tag tag | route-policy route-policy-
name | { level-1 | level-2 |
level-1-2 } ] *

view.

which the VPN
instance is bound.
Enable IS-IS IPv6 isis ipv6 enable [ process-id ] -

on the interface.
Configure BGP4+ Between an MCE Device and a PE Device


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


system
view.

BGP view. dot }
Enter the ipv6-family vpn-instance vpn- -

BGP-VPN instance-name
instance
IPv6
address
family
view.

the PE number
device as
the VPN
peer of the
MCE
device.
Import the import-route protocol [ process-id ] Perform this step if another routing
routes to [ med med | route-policy route- protocol is running between the
the remote policy-name ] * MCE device and VPN sites in the
sites VPN instance.
advertised
by the PE
device into
the BGP4+
routing
table.
9.3.4 Verifying the MCE Configuration
Prerequisites
The MCE configuration is complete.
Procedure
l Run the display ip vpn-instance vpn-instance-name command to check brief
information about a specified VPN instance.
l Run the display ip vpn-instance verbose vpn-instance-name command to check
detailed information about a specified VPN instance.
l Run the display ip vpn-instance [ vpn-instance-name ] interface command to check
brief information about the interface to which a specified VPN instance is bound.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display ipv6 routing-table vpn-instance vpn-instance-name [ verbose ]

command to check the IPv6 routing table on the MCE device. The routing table contains
routes to the LAN and remote sites for each service.
----End
9.4 Configuration Examples for MCE IPv6

This section provides an example for configuring an MCE IPv6 device.
9.4.1 Example for Configuring an MCE IPv6 Device

The headquarters and branch of a company need to communicate through MPLS VPN, and
two IPv6 services of the company must be isolated. To reduce hardware costs, the company
wants the branch to connect to the PE device through one CE device with high capability.
As shown in Figure 9-3, the networking requirements are as follows:
l CE1 and CE2 connect to the headquarters. CE1 belongs to vpna, and CE2 belongs to
vpnb.
l The MCE device connects to vpna and vpnb of the branch through CE3 and CE4.
This implements communication within the same VPN and service isolation between different
VPNs.
NOTE
CE1, CE2, CE3 and CE4 are huawei Ethernet Switches S5700.
PE1 and PE2 are huawei Ethernet Switches S9700.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 9-3 MCE IPv6 networking
vpna
CE1
C
GE1/0/0
VLANIF10 V
2001::2/64 FC
Loopback1
GE1/0/0 2.2.2.9./32
VLANIF10 VPN
2001::1/64 Backbone GE1/
GE2/0/0
2007:
Loopback1 PE1 GE1/0/0 VLANIF100: 2007::1/64
1.1.1.9./32 GE3/0/0 VLANIF30 VLANIF200: 2008::1/64 GE1/
GE2/0/0 VLANIF30 172.1.1.2/24 PE2 2008:
VLANIF20 172.1.1.1/24
2002::1/64
GE1/0/0 G
VLANIF20 VL
2002::2/64 FC
CE2
vpnb
1. Configure OSPF between PE devices to implement interworking between them and
configure MP-IBGP to exchange VPN routing information.
2. Enable basic MPLS capabilities and MPLS LDP on the PE devices to set up LDP LSPs.
3. Create VPN instances vpna and vpnb on the MCE and PE devices to isolate services.
4. Set up EBGP peer relationships between PE1 and local CE devices to exchange VPN
routes.
5. Configure routing between MCE and sites and between MCE and PE2 to exchange VPN
routes.
Procedure
Step 1 Configure OSPF on PE1 and PE2 to implement interworking between them.
mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
Take the display on PE2 as an example:

to vpn-instance
------------------------------------------------------------------------------
1.1.1.9/32 OSPF 10 2 D 172.1.1.1 Vlanif30

172.1.1.0/24 Direct 0 0 D 172.1.1.2 Vlanif30
172.1.1.2/32 Direct 0 0 D 172.1.1.1 Vlanif30
172.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif30
Step 2 Enable basic MPLS capabilities and MPLS LDP on the PE devices to set up LDP LSPs
between them.
mentioned here.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface vlanif 30
[PE1-Vlanif30] mpls
[PE1-Vlanif30] mpls ldp
[PE1-Vlanif30] quit
After the configuration is complete, run the display mpls ldp session command on the PE
devices. You can see that the MPLS LDP session between the PE devices is in Operational
state.
Take the display on PE2 as an example:


------------------------------------------------------------------------------
Peer-ID Status LAM SsnRole SsnAge KA-Sent/Rcv
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 3 Enable IPv6. Configure VPN instances on the PE devices. On PE1, bind the VPN instances to
the interfaces connected to CE1 and CE2 respectively. On PE2, bind the VPN instances to the
interfaces connected to the MCE device.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] ipv6
[PE1] vlan batch 10 20
[PE1-GigabitEthernet1/0/0] port hybrid pvid vlan 10
[PE1-GigabitEthernet1/0/0] port hybrid untagged vlan 10
[PE1-GigabitEthernet2/0/0] port hybrid pvid vlan 20
[PE1-GigabitEthernet2/0/0] port hybrid untagged vlan 20
[PE1-Vlanif10] ip binding vpn-instance vpna
[PE1-Vlanif10] ipv6 enable
[PE1-Vlanif10] ipv6 address 2001::1 64
[PE1-Vlanif10] quit
[PE1-Vlanif20] ip binding vpn-instance vpnb
[PE1-Vlanif20] quit
# Configure PE2.
[PE2] ipv6
[PE2] vlan batch 100 200
[PE2-GigabitEthernet2/0/0] port link-type trunk
[PE2-GigabitEthernet2/0/0] port trunk allow-pass vlan 100 200
[PE2-Vlanif60] ip binding vpn-instance vpna
[PE2-Vlanif60] quit
[PE2-Vlnaif70] ip binding vpn-instance vpnb
[PE2-Vlnaif70] ipv6 enable
[PE2-Vlnaif70] ipv6 address 2008::1 64
[PE2-Vlnaif70] quit
Step 4 Enable IPv6 and configure VPN instances on the MCE device. Bind the vpn instances to the
interfaces connected to CE3 and CE4 respectively.
[Huawei] sysname MCE
[MCE] ipv6

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[MCE] ip vpn-instance vpna

[MCE-vpn-instance-vpna] ipv6-family
[MCE-vpn-instance-vpna-af-ipv6] route-distinguisher 100:1
[MCE-vpn-instance-vpna-af-ipv6] quit
[MCE-vpn-instance-vpna] quit
[MCE] ip vpn-instance vpnb
[MCE-vpn-instance-vpnb] ipv6-family
[MCE-vpn-instance-vpnb-af-ipv6] route-distinguisher 200:2
[MCE-vpn-instance-vpnb-af-ipv6] quit
[MCE-vpn-instance-vpnb] quit
[MCE-GigabitEthernet1/0/0.1] ip binding vpn-instance vpna
[MCE-GigabitEthernet1/0/0.1] ipv6 enable
[MCE-GigabitEthernet1/0/0.1] ipv6 address 2007::2 64
[MCE-GigabitEthernet1/0/0.1] ipv6 nd ns multicast-enable
[MCE-GigabitEthernet1/0/0.2] ip binding vpn-instance vpnb
[MCE-GigabitEthernet1/0/0.2] ipv6 enable
[MCE-GigabitEthernet1/0/0.2] ipv6 address 2008::2 64
[MCE-GigabitEthernet1/0/0.2] ipv6 nd ns multicast-enable
[MCE-GigabitEthernet3/0/0] ip binding vpn-instance vpna
[MCE-GigabitEthernet3/0/0] ipv6 enable
[MCE-GigabitEthernet3/0/0] ipv6 address FC03::2 64
[MCE-GigabitEthernet4/0/0] ip binding vpn-instance vpnb
[MCE-GigabitEthernet4/0/0] ipv6 enable
[MCE-GigabitEthernet4/0/0] ipv6 address FC04::1 64
Step 5 Set up an MP-IBGP peer relationship between PE1 and PE2. Set up an EBGP peer
relationship between PE1 and CE1, and between PE1 and CE2.
# Configure PE1 to set up an MP-IBGP peer relationship between PE1 and PE2.
[PE1] bgp 100
The configuration of PE2 is the same as the configuration of PE1.

# Configure PE1 to set up an EBGP peer relationship between PE1 and CE1, and between
PE1 and CE2.
[PE1] bgp 100
[PE1-bgp6-vpna] peer 2001::2 as-number 65410
[PE1-bgp6-vpna] quit
[PE1-bgp6-vpnb] peer 2002::2 as-number 65420
[PE1-bgp6-vpnb] quit
[PE1-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] peer 2001::1 as-number 100
[CE1-bgp-af-ipv6] peer 2001::1 enable
[CE1-bgp-af-ipv6] import-route direct
[CE1-bgp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The configuration of CE2 is the same as the configuration of CE1.
After the configuration is complete, run the display bgp vpnv6 all peer command on PE1.
The command output shows that the PE1 has set up an IBGP peer relationship with PE2 and
EBGP peer relationships with CE1 and CE2. All the peer relationships are in Established
state.

2.2.2.9 4 100 288 287 0 01:19:16 Established 6
Peer of vpn instance :

vpn instance vpna :
2001::2 4 65410 9 11 0 00:04:14 Established 2
vpn instance vpnb :
2002::2 4 65420 9 12 0 00:04:09 Established 2
Step 6 Configure routing between the MCE device and VPN sites.
The MCE device directly connects to vpna, and no routing protocol is used in vpna.
Configure IPv6 static routes to implement communication between the MCE device and vpna.
l # Configure CE3.
Assign IPv6 address FC05::1/64 to the interface connected to vpna.
[CE3] ipv6
[CE3] vlan batch 60 80
[CE3-GigabitEthernet1/0/0] port link-type trunk
[CE3-GigabitEthernet1/0/0] port trunk allow-pass vlan 60
[CE3-GigabitEthernet1/0/0] port trunk pvid vlan 60
[CE3]interface vlanif 60
[CE3-Vlanif60]ipv6 enable
[CE3-Vlanif60]ipv6 address FC03::3 64
[CE3-Vlanif60] quit
[CE3]interface vlanif 80
[CE3-Vlanif80]ipv6 enable
[CE3-Vlanif80]ipv6 address FC05::1 64
[CE3-Vlanif80] quit
[CE3]ipv6 route-static 0::0 0 FC03::2
l # Configure the MCE device.

[MCE] ipv6 route-static vpn-instance vpna FC05:: 64 FC03::3
l # Check the IPv6 routes of vpna on the MCE device.

[MCE]display ipv6 routing-table vpn-instance vpna
Routing Table :
vpna
6
Destination : FC03:: PrefixLength :

64
NextHop : FC03::2 Preference :

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0
Cost : 0 Protocol :
Direct
RelayNextHop : :: TunnelID :
0x0
Interface : GigabitEthernet3/0/0 Flags :
D
Destination : FC03::2 PrefixLength :

128
NextHop : ::1 Preference :
0
Cost : 0 Protocol :
Direct
0x0
D

64
60
Cost : 0 Protocol :
Static
0x0
RD
Destination : 2007:: PrefixLength :

64
NextHop : 2007::2 Preference :
0
Cost : 0 Protocol :
Direct
0x0
Interface : GigabitEthernet1/0/0.1 Flags :
D
Destination : 2007::2 PrefixLength :

128
0
Cost : 0 Protocol :
Direct
0x0
D
Destination : FE80:: PrefixLength :

10
NextHop : :: Preference :
0
Cost : 0 Protocol :
Direct
0x0
Interface : NULL0 Flags :
D

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The preceding information shows that the MCE device has a static route to vpna.
The RIPng protocol runs in vpnb. Configure RIPng process 200 on the MCE device and bind
it to vpnb so that routes learned by RIPng are added to the IPv6 routing table of vpnb.
l # Configure the MCE device.

[MCE] ripng 200 vpn-instance vpnb
[MCE-ripng-200] import-route ospfv3 200
[MCE-ripng-200] quit
[MCE-GigabitEthernet4/0/0] ripng 200 enable
l # Configure CE4.
Assign IP address FC06::1/64 to the interface connected to vpnb.
[CE4] ipv6
[CE4] vlan batch 70 80
[CE4-GigabitEthernet1/0/0] port trunk pvid vlan 70
[CE4] interface vlanif 70
[CE4-Vlanif70] ipv6 enable
[CE4-Vlanif70] ipv6 address FC04::3 64
[CE4-Vlanif70] quit
[CE4-Vlanif80] ipv6 enable
[CE4-Vlanif80] ipv6 address FC06::1 64
[CE4-Vlanif80] quit
[CE4] ripng 200
[CE4-ripng-200] quit
[CE4-Vlanif70] ripng 200 enable
[CE4-Vlanif70] quit
[CE4-Vlanif80] ripng 200 enable
[CE4-Vlanif80] quit
l # Check the routes of vpnb on the MCE device.

[MCE] display ipv6 routing-table vpn-instance vpnb
Routing Table :
vpnb
6

64
0
Cost : 0 Protocol :
Direct
0x0
D
Destination : FC04::2 PrefixLength :

128

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

0
Cost : 0 Protocol :
Direct
0x0
D

64
NextHop : FE80::5689:98FF:FE28:8442 Preference :
100
Cost : 0 Protocol :
RIPng
0x0
D
Destination : 2008:: PrefixLength :

64
NextHop : 2008::2 Preference :
0
Cost : 0 Protocol :
Direct
0x0
D
Destination : 2008::2 PrefixLength :

128
0
Cost : 0 Protocol :
Direct
0x0
D
Destination : FE80:: PrefixLength :

10
NextHop : :: Preference :
0
Cost : 0 Protocol :
Direct
0x0
Interface : NULL0 Flags :
D
The preceding information shows that the MCE device has learned the route to vpnb
through RIPng. The route to vpnb and the route to vpna (FC05::/64) are maintained in
different VPN routing tables so that users in the two VPNs are isolated from each other.
Step 7 Configure OSPFv3 multi-instance between the MCE device and PE2.
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
To configure OSPFv3 multi-instance between the MCE device and PE2, complete the following tasks on
PE2:
l In the OSPFv3 view, import BGP routes and advertise VPN routes of PE1 to the MCE device.
l In the BGP view, import routes of the OSPFv3 processes and advertise the VPN routes of the
MCE device to PE1.
[PE2] ospfv3 100 vpn-instance vpna

[PE2-ospfv3-100] import-route bgp
[PE2-ospf-100] quit
[PE2] ospfv3 200 vpn-instance vpnb
[PE2-ospfv3-200] import-route bgp
[PE2-ospf-200] quit
[PE2] bgp 100
[PE2-bgp-vpna] import-route ospfv3 100
[PE2-bgp-vpna] quit
[PE2-bgp-vpnb] import-route ospfv3 200
[PE2-bgp-vpnb] quit
[PE2-Vlanif100] ospfv3 100 area 0
[PE2-Vlanif100] quit
[PE2-Vlnaif200] ospfv3 200 area 0
[PE2-Vlnaif200] quit
# Configure the MCE device.

NOTE
Import VPN routes to the OSPFv3 processes.
[MCE] ospfv3 100 vpn-instance vpna

[MCE-ospfv3-100] router-id 1.1.1.1
[MCE-ospfv3-100] import-route static
[MCE-ospfv3-100] vpn-instance-capability simple
[MCE-ospfv3-100] quit
[MCE] ospfv3 200 vpn-instance vpnb
[MCE-ospfv3-200] router-id 2.2.2.2
[MCE-ospfv3-200] import-route ripng 200
[MCE-ospfv3-200] vpn-instance-capability simple
[MCE-ospfv3-200] quit
[MCE-GigabitEthernet1/0/0.1] ospfv3 100 area 0
[MCE-GigabitEthernet1/0/0.2] ospfv3 200 area 0
# After the configuration is complete, run the display ipv6 routing-table vpn-instance
command on the MCE device to view the routes to the remote CE devices.
# Take the routing table of vpna as an example:

[MCE] display ipv6 routing-table vpn-instance vpna
Routing Table : vpna
Destination : 2001:: PrefixLength : 64

NextHop : FE80::5689:98FF:FE28:8472 Preference : 150
Cost : 0 Protocol : OSPFv3ASE
RelayNextHop : :: TunnelID : 0x0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Interface : GigabitEthernet1/0/0.1 Flags : D
Destination : FC03:: PrefixLength : 64

NextHop : FC03::2 Preference : 0
Cost : 0 Protocol : Direct
Interface : GigabitEthernet3/0/0 Flags : D
Destination : FC03::2 PrefixLength : 128

NextHop : ::1 Preference : 0
Interface : GigabitEthernet3/0/0 Flags : D

NextHop : FC03::3 Preference : 60
Cost : 0 Protocol : Static
Interface : GigabitEthernet3/0/0 Flags : RD

NextHop : 2007::2 Preference : 0
Destination : 2007::2 PrefixLength : 128

Destination : FE80:: PrefixLength : 10

NextHop : :: Preference : 0
Interface : NULL0 Flags : D
# Run the display ipv6 routing-table vpn-instance command on the PE devices to view the
routes to the remote CE devices.
# Take the VPN routing table of vpna on PE as an example:
[PE1] display ipv6 routing-table vpn-instance vpna
Routing Table : vpna

NextHop : 2001::1 Preference : 0
Interface : Vlanif30 Flags : D
Destination : 2001::1 PrefixLength : 128

Interface : Vlanif30 Flags : D

NextHop : ::FFFF:2.2.2.9 Preference : 255
Cost : 0 Protocol : BGP
Interface : Vlanif30 Flags : RD


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Destination : FE80:: PrefixLength : 10

NextHop : :: Preference : 0
Interface : NULL0 Flags : D
# CE1 and CE3 can communicate with each other. CE2 and CE4 can communicate with each
other.
# CE1 cannot ping CE2 or CE4. CE3 cannot ping CE2 or CE4.
----End
Configuration Files
#
sysname CE1
#
vlan batch 10
#
ipv6
#
interface Vlanif10
ipv6 enable
ipv6 address 2001::2/64
#
port hybrid pvid vlan 10
port hybrid untagged vlan 10
#
bgp 65410
peer 2001::1 as-number 100
#
ipv6-family unicast
import-route direct
peer 2001::1 enable
#
return

#
sysname CE2
#
ipv6
#
vlan batch 20
#
interface Vlanif20
ipv6 enable
#
#
bgp 65420

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ipv6-family unicast
import-route direct
peer 2002::1 enable
#
return
#
sysname PE1
#
ipv6
#
vlan batch 10 20 30
#
ipv6-family
#
ipv6-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Vlanif10
ipv6 enable
#
interface Vlanif20
ipv6 enable
#
interface Vlanif30
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
#
#
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
peer 2.2.2.9 enable

#
ipv6-family vpnv6
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv6
#
vlan batch 30 100 200
#
ipv6-family
#
ipv6-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ospfv3 100 vpn-instance vpna
router-id 3.3.3.3
import-route bgp
#
ospfv3 200 vpn-instance vpnb
router-id 4.4.4.4
import-route bgp
#
interface vlanif30
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Vlanif100
ipv6 enable
ospfv3 100 area 0.0.0.0
#
interface Vlanif200
ipv6 enable
ospfv3 200 area 0.0.0.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
#
port trunk allow-pass vlan 100 200
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.9 enable
#
import-route ospfv3 100
#
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l MCE configuration file
#
sysname MCE
#
ipv6
#
ipv6-family
#
ipv6-family
#
ospfv3 100 vpn-instance vpna
router-id 1.1.1.1
import-route static
#
ospfv3 200 vpn-instance vpnb
router-id 2.2.2.2
import-route ripng 200
#
ripng 200 vpn-instance vpnb
#
ipv6 enable
ipv6 nd ns multicast-enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ospfv3 100 area 0.0.0.0

#
ipv6 enable
ipv6 nd ns multicast-enable
ospfv3 200 area 0.0.0.0
#
ipv6 enable
#
ipv6 enable
ripng 200 enable
#
ipv6 route-static vpn-instance vpna FC05:: 64 FC03::3
#
return
#
sysname CE3
#
ipv6
#
vlan batch 60 80
#
interface vlanif60
ipv6 enable
#
interface vlanif80
ipv6 enable
#
port trunk pvid vlan 60
#
#
ipv6 route-static :: 0 FC03::2
#
return
#
sysname CE4
#
ipv6
#
vlan batch 70 80
#
ripng 200
#
interface vlanif70
ipv6 enable
ripng 200 enable
#
interface vlanif80

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipv6 enable
ripng 200 enable
#
port trunk pvid vlan 70
#
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 10 EVPN Configuration
10 EVPN Configuration
About This Chapter
This chapter provides an overview of Ethernet virtual private network (EVPN) and describes
its basic configurations.
10.1 Overview of EVPN

10.2 Understanding EVPN
10.3 Application Scenarios for EVPN
10.4 Licensing Requirements and Limitations for EVPN
10.5 Configuring EVPN Functions
Configuring EVPN functions involves configuring VPN instances, binding interfaces to VPN
instances, and configuring EVPN BGP peer relationships.
10.6 Maintaining EVPN
10.7 Configuration Examples for EVPN
10.8 References for EVPN
10.1 Overview of EVPN

Definition
An Ethernet virtual private network (EVPN) is a VPN used for Layer 2 interworking. EVPN
is similar to Border Gateway Protocol (BGP)/Multiprotocol Label Switching (MPLS) IP
VPN. Using extended reachability information, EVPN implements MAC address learning and
advertisement between Layer 2 networks at different sites on the control plane rather than on
the data plane.
Figure 10-1 shows the basic EVPN model.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 10-1 Basic EVPN model
Host1
192.168.10.1/32
PE1 PE2
VPN1 VPN1
P
CE1
Site
CE1
Host2 PE4
192.168.20.1/32 VPN1
Host3
192.168.10.2/32
Purpose
Originally, the Virtual Extensible LAN (VXLAN) solution did not provide the control plane.
VXLAN used traffic flooding on the data plane to implement VXLAN tunnel endpoint
(VTEP) discovery and host information learning, including IP and MAC addresses, VXLAN
Network Identifiers (VNIs), and gateway VTEP IP addresses. This way resulted in high traffic
volumes on data center networks. To resolve this problem, VXLAN uses EVPN as the control
plane. EVPN allows VTEPs to exchange EVPN routes so that VTEPs can be automatically
discovered and host information can be mutually advertised. Therefore, EVPN prevents
unnecessary data traffic flooding.
EVPN is similar to BGP/MPLS IP VPN and communicates EVPN routes over a public
network, improving security of customers' private data.
Additionally, manual configuration of the original VXLAN solution is time-consuming on a

large-scale network. Using EVPN helps reduce the manual configuration workload.
10.2 Understanding EVPN
Overview
An EVPN is a VPN used for Layer 2 interworking. EVPN is similar to BGP/MPLS IP VPN.
Using extended reachability information, EVPN implements MAC address learning and
advertisement between Layer 2 networks at different sites on the control plane rather than on
the data plane.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
EVPN Routes
EVPN defines a new type of BGP network layer reachability information (NLRI), called the
EVPN NLRI. The EVPN NLRI defines new types of EVPN routes for IP address learning and
advertisement between Layer 3 networks at different sites.
During dynamic establishment of a VXLAN tunnel, EVPN functions as the VXLAN control
plane and uses IP prefix routes defined by the EVPN NLRI to communicate VTEP addresses
and host information. Therefore, EVPN implements VTEP discovery and host information
learning on the control plane instead of the data plane.
An IP prefix route is type 5 route. The format of EVPN NLRI specific to IP prefix routes is
shown in Figure 10-2.
Figure 10-2 Format of EVPN NLRI specific to IP prefix routes

Route Distinguisher (8 bytes)
Ethernet Segment Identifier (10 bytes)
Ethernet Tag ID (4 bytes)
IP Prefix Length (1 byte)
IP Prefix (4 or 16 bytes)
GW IP Address (4 or 16 bytes)
MPLS Label (3 bytes)
The description of each field is as follows:
Field Description
Route Distinguisher Indicates the RD value of a VPN

instance.
Ethernet Segment Identifier Uniquely identifies a connection

between the current PE and a peer
CE.
Ethernet Tag ID Indicates the actual VLAN ID

configured on the current PE.
IP Prefix Length Indicates the mask length carried

in an IP prefix route.
IP Prefix Indicates the IP prefix address

carried in an IP prefix route.
GW IP Address Indicates the default gateway

address. This field is not used in a
VXLAN scenario.
MPLS Label Indicates the Layer 3 VNI carried

in an IP prefix route.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The IP Prefix Length and IP Prefix fields carry information of a host IP address or network
segment address to identify a host or network segment.
l If the fields carry information of a host IP address, the information is used to advertise
host IP routes on the control plane.
l If the fields carry information of a network segment address, the information is used for
hosts in a VXLAN to access an external network.
Related Concepts
l VXLAN tunnel endpoint (VTEP)
A VTEP encapsulates and decapsulates VXLAN packets. It is represented by an NVE.
A VTEP connects to a physical network and is assigned a physical network IP address.
This IP address is irrelevant to virtual networks.
In VXLAN packets, the source IP address is the local node's VTEP address, and the
destination IP address is the peer node's VTEP address. This pair of VTEP addresses
corresponds to a VXLAN tunnel.
l Network Virtualization Edge (NVE)
An NVE is a network entity that is deployed at the network edge and implements
network virtualization functions. NVEs encapsulate and convert VXLAN packets and
then establish a Layer 2 overlay virtual network over the Layer 3 infrastructure.
l VXLAN Network Identifier (VNI)
A VNI is similar to a VLAN ID and is used to identify a VXLAN segment.
A VNI identifies only one tenant. Even if multiple terminal users belong to the same
VNI, they are considered one tenant.
A VNI is associated with a VPN instance to allow VXLAN packets to be forwarded
between sub-networks.
l EVPN-VPN target
A VPN instance is associated with one or more EVPN-VPN targets. EVPN-VPN targets
are classified into the following types:
– Export EVPN-VPN targets are carried in the EVPN routes to be advertised to
remote EVPN peers.
– Import EVPN-VPN targets are compared with the export EVPN-VPN targets
carried in EVPN routes to determine which EVPN routes can be imported to the
routing table of the local VPN instance IPv4 address family.
EVPN-VPN targets control the sending and receiving of EVPN routes. During EVPN
route cross, if one of the export EVPN-VPN targets carried in EVPN routes is the same
as the import EVPN-VPN target configured in the local VPN instance IPv4 address
family, the EVPN routes can be imported to the local VPN instance IPv4 address family.
Deploying a VXLAN Tunnel Using EVPN
As shown in Figure 10-3, a VXLAN tunnel is established in the following process:

1. Device1 and Device2 each have a VPN instance created, and an EVPN peer relationship
is established between them.
2. Device1 and Device2 send IP prefix routes to each other. Device1 imports to its VPN
instance the address of Host1 or address of the network segment to which Host1 belongs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Then Device1 sends an IP prefix route carrying the address to Device2. Device2 also
performs the same operation.
3. After Device1 and Device2 receive the IP prefix routes from each other, they each check
the export EVPN-VPN target in the IP prefix routes. If the export EVPN-VPN target is
the same as the import EVPN-VPN target configured in the local VPN instance IPv4
address family, they each accept the IP prefix route sent by the peer device. If the export
and import EVPN-VPN targets are different, they each discard the IP prefix route. After
accepting the IP prefix routes, Device1 and Device2 each save the peer VTEP IP address
and VNI carried in the IP prefix routes. During packet forwarding, the saved information
is encapsulated in the outer layer of the data packets, and then they are transmitted
through the VXLAN tunnel.
Figure 10-3 Deploying a VXLAN tunnel using EVPN
VPN1 VPN1
VNI: 30 VNI: 20
VTEP: VTEP:
3.3.3.3/32 2.2.2.2/32
VXLAN Tunnel
Host1 Host2
192. 168.20.2/32 Device1 Device2 192. 168.20.1/32
NVE
10.3 Application Scenarios for EVPN
10.3.1 EVPN Applications

Service Overview
Figure 10-4 shows the basic networking in which EVPN functions as the VXLAN control
plane. A VXLAN tunnel is established using EVPN. Specifically, an EVPN peer relationship
is established between two VTEPs. The VTEPs exchange EVPN routes carrying the VNIs and
IP addresses of the VTEPs to establish a VXLAN tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 10-4 EVPN networking application
VNI : 10
VTEP:
1.1.1.1/ 32
Device1
Host1
192. 168. 10.1/ 32
VX
el
LA
nn
Tu
N
LA
N Tu
nn
el
VX
Device3 Device2
VNI : 30 VNI : 20
VTEP: VXLAN Tunnel VTEP:
3.3.3.3/ 32 2.2.2.2/ 32
Host3 Host2
192. 168.20.2/ 32 192. 168. 30.1/ 32
NVE
Device1, Device2, and Device3 each have a VPN instance created. An EVPN peer
relationship is configured between every two peers to exchange EVPN routes so that a
corresponding VXLAN tunnel is established between every two peers. As a result, Host1,
Host2, and Host3 communicate with each other through the VXLAN tunnels.
10.4 Licensing Requirements and Limitations for EVPN

None.
EVPN is a basic feature of the device and is not under license control.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Feature Limitations
When configuring Static EVPN on the router, pay attention to the following points:
Only the AR100, AR120, AR150, AR160 (except AR161EW, AR161EW-M1, AR169EW,
AR169EGW-L), AR200, AR1200 AR3600series, AR2220E and AR2240 support EVPN.
10.5 Configuring EVPN Functions

Configuring EVPN functions involves configuring VPN instances, binding interfaces to VPN
instances, and configuring EVPN BGP peer relationships.
10.5.1 Before You Start

Before configuring Ethernet virtual private network (EVPN), familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the required data. This can
help you complete the configuration task quickly and accurately.
Usage Scenario
Functioning as the control plane of Virtual Extensible LAN (VXLAN), EVPN allows EVPN
routes to be exchanged so that VXLAN tunnel endpoints (VTEPs) can be automatically
discovered and host information can be mutually advertised.
This section describes the EVPN networking configuration. As shown in Figure 10-5, the
hosts need to communicate with the Layer 3 network between sites. EVPN can be configured
to meet this requirement.
Figure 10-5 EVPN networking model

Host1
192.168.10.1/32
PE1 PE2
VPN1 VPN1
P
CE1
Site
CE1
Host2 PE4
192.168.20.1/32 VPN1
Host3
192.168.10.2/32
Before configuring EVPN functions, complete the following tasks:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configure an IGP on the PEs and Ps of a backbone network to ensure IP connectivity.

l Configure IP addresses for the interfaces that connect CEs to PEs.
Data Preparation
To configure EVPN functions, you need the following data.
No. Data
1 VPN instance data, including:

l VPN instance name
l RD and EVPN-VPN target of the VPN instance IPv4 address family
2 IP addresses of interfaces that connect PEs to CEs
3 IP addresses of interfaces that connect CEs to PEs
4 AS numbers of PEs, and interfaces and IP addresses used by PEs to establish

Border Gateway Protocol (BGP) peer relationships
5 Type of the routing protocol running between PEs and CEs, such as static route,
RIP, OSPF, IS-IS, or BGP
10.5.2 Configuring a VPN Instance

Configure VPN instances on PEs to manage EVPN routes.
Context
VPN instances isolate EVPN routes from public routes. The routes of VPN instances are also
isolated from each other. VPN instances are required in all EVPN networking solutions.
Perform the following steps on each PE:
Procedure
Step 2 Run ip vpn-instance vpn-instance-name
The IPv4 address family is enabled for the VPN instance, and the VPN instance IPv4 address
family view is displayed.
Step 4 Run route-distinguisher route-distinguisher
A VPN instance takes effect only after the RD is configured. The RDs of different VPN
instances on a PE must be different.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 5 Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]

evpn
EVPN-VPN targets are configured for the VPN instance.
An EVPN-VPN target is a BGP extended community attribute used to control the receiving
and advertisement of EVPN routes. A maximum of eight EVPN-VPN targets can be
configured using the vpn-target evpn command at a time. To configure more EVPN-VPN
targets for an EVPN instance address family, run the vpn-target evpn command several
times.
Step 6 (Optional) Run export route-policy policy-name evpn
An export route-policy is associated with the VPN instance IPv4 address family to filter the
EVPN routes that the VPN instance IPv4 address family advertises to the EVPN address
family.
An export route-policy must be configured to precisely control EVPN routes. An export

route-policy filters routes before they are advertised to the EVPN address family.
Step 7 (Optional) Run import route-policy policy-name evpn
An import route-policy is associated with the VPN instance IPv4 address family to filter the
EVPN routes imported from the EVPN address family.
An import route-policy must also be configured to precisely control EVPN routes. An import
route-policy filters routes received from the EVPN address family.
Step 8 Run quit
Step 9 Run bgp
Step 10 Run ipv4-family vpn-instance vpn-instance-name
Step 11 Run advertise l2vpn evpn
The VPN instance is enabled to advertise IP routes to the BGP EVPN address family.
----End
10.5.3 Binding an Interface to a VPN Instance

After an interface is bound to a VPN instance, the interface becomes a part of the VPN.
Packets entering the interface will be forwarded based on the virtual routing and forwarding
(VRF) table of the VPN.
Context
After a VPN instance is configured on a PE, an interface that belongs to the VPN must be
bound to the VPN instance. Otherwise, the interface functions as a public network interface
Perform the following steps on the PEs that are connected to CEs:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
The view of the interface to be bound to a VPN instance is displayed.
The interface is bound to the VPN instance.
NOTE
l Running the ip binding vpn-instance command deletes Layer 3 IPv4 and IPv6 configurations, such
as the IP address and routing protocol on the interface. Reconfigure them if needed.
l An interface cannot be bound to a VPN instance that has no address family enabled.

----End
10.5.4 Configuring an EVPN BGP Peer Relationship

After two PEs establish an EVPN BGP peer relationship, they can exchange EVPN routes.
Context
In EVPN networking, PEs need to have EVPN BGP peer relationships established before they
can exchange EVPN route information and implement communication between EVPN
instances.
Perform the following steps on each PE:
Procedure
Step 3 Run peer ipv4-address as-number { as-number-plain | as-number-dot }
An EVPN BGP peer IP address is specified.
The interface on which a TCP connection to the specified peer is to be established is
specified.
Step 5 Run l2vpn-family evpn
The BGP-EVPN address family is enabled, and its view is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

The capability to exchange EVPN routes with the specified peer or peer group is enabled.
Step 7 (Optional) Run peer ipv4-address group group-name
The EVPN BGP peer is added to a peer group.
Adding EVPN BGP peers to peer groups simplifies BGP network configuration and
management.
Step 8 (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-name export
A route-policy is specified for an EVPN BGP peer or peer group to advertise only specified
routes.
An export route-policy must be configured to precisely control EVPN routes. An export
route-policy filters routes before they are advertised to other EVPN BGP peers or peer groups.
Step 9 (Optional) Run peer { ipv4-address | group-name } route-policy route-policy-name import
A route-policy is specified for an EVPN BGP peer or peer group to receive only specified
routes.
An import route-policy must also be configured to precisely control EVPN routes. An import
route-policy filters routes that are received from other EVPN BGP peers or peer groups.
Step 10 (Optional) Run undo policy vpn-target
EVPN-VPN target-based filtering for received EVPN routes is disabled.
Step 11 (Optional) Run peer { group-name | ipv4-address } mac-limit mac-limit [ idle-forever | idle-
timeout times ]
The maximum number of MAC advertisement routes that can be received from each peer is
configured.
If an EVPN instance imports many invalid MAC advertisement routes from some peers and
these routes occupy a large proportion of the total MAC advertisement routes, run this
command to configure the maximum number of MAC advertisement routes that can be
received from each peer.
----End
10.5.5 Verifying the EVPN Configuration
Prerequisites
EVPN functions have been configured.
NOTE
If directly connected users exist in a centralized gateway deployment scenario, the VTEP address carried in
Type 2 routes (MAC/IP routes) is the device's VTEP address, causing an iteration failure. Therefore, check on
iteration results is not performed for Type2 routes (MAC/IP routes), and the routes are marked as valid routes.
Procedure
l Run the display bgp evpn group [ group-name ] command to check information about
an EVPN BGP peer group.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display bgp evpn peer [[ ipv4-address ]verbose ] command to check
information about peers in the EVPN address family.
l Run the display bgp evpn routing-table peer statistics command to check statistics
about routes advertised and received by the peers in the EVPN address family.
l Run the display bgp evpn all routing-table command to check information about
EVPN routes.
----End
Example
Run the display bgp evpn group [ group-name ] command on a PE to view information
about an EVPN BGP peer group.
# Display information about an EVPN BGP peer group named aa.
<Huawei> display bgp evpn group aa
Group in
EVPN:
BGP peer-group: aa Remote AS: 100

Type : internal
Configured hold timer value: 180
Keepalive timer value: 60
Connect-retry timer value: 32
PeerSession Members:
2.2.2.2
Status codes: * - Dynamic

Peer Members:
Peer V AS MsgRcvd MsgSent OutQ Up/
Down State PrefRcv
2.2.2.2 4 100 0 0 0
00:02:28 Idle 0
Run the display bgp evpn peer [ [ ipv4-address ] verbose ] command to view information
about peers in the EVPN address family.
# Display detailed information about the peer 2.2.2.2 in the EVPN address family.
<Huawei> display bgp evpn peer 2.2.2.2 verbose
Peer is 2.2.2.2, remote AS 100

Type: IBGP link
Update-group ID: 0
BGP current event: KATimerExpired

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configured: Active Hold Time: 180 sec

Keepalive Time:60 sec
Address family VPNv4: advertised
Address family L2VPN EVPN: advertised and received
Update messages 0
Open messages 1
Refresh messages 0
Update messages 0
Open messages 2
Refresh messages 0
Authentication type configured:
None
Last keepalive received: 2017-01-03
19:13:02-08:00
Last keepalive sent : 2017-01-03
19:13:02-08:00
Last update received: 2017-01-03
19:06:15-08:00
Last update sent : 2017-01-03
19:06:15-08:00
Minimum route advertisement interval is 15
seconds
Optional
capabilities:
Route refresh capability has been

enabled
4-byte-as capability has been
enabled
Connect-interface has been
configured
Peer Preferred Value:
0
Routing policy
configured:
Run the display bgp evpn routing-table peer statistics command to view statistics about
routes advertised and received by the peers in the EVPN address family.
# Display statistics about routes advertised and received by the peers in the BGP EVPN
address family.
<Huawei> display bgp evpn routing-table peer statistics
Local AS number : 200 Total number of peers : 7
Number of Peers in established state : 4
Peer Received routes Advertised routes
3.3.3.3 3 5
5.5.5.5 20132 5
10.1.1.2 0 0
11.11.11.11 0 0
16.1.1.1 0 0
24.1.1.2 312 5
24.24.24.2 312 5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Run the display bgp evpn all routing-tablecommand to view information about EVPN
routes.
# Display IP prefix information about all EVPN routes.

<Huawei> display bgp evpn all routing-table prefix-route
Local AS number :100 BGP Local router ID is 189.35.99.225

EVPN address family:
Number of Ip Prefix Routes : 1
Network(EthTagId/IpPrefix/IpPrefixLen) NextHop
*> 0:9.9.9.0:24 9.9.9.9
i 9.9.9.0/24 9.9.9.9 0 100 0 ?
10.6 Maintaining EVPN

10.6.1 Configuring EVPN BGP Soft Reset
Context
EVPN BGP soft reset allows a device to receive EVPN routes from EVPN BGP peers again.
EVPN BGP soft reset performs a soft reset on EVPN BGP connections, which triggers EVPN
BGP peers to send EVPN routes to a local device without tearing down the EVPN BGP
connections and allows the local device to apply a new filtering policy and refresh the EVPN
BGP routing table.
Procedure
l Run the refresh bgp evpn { all | peer-address | group group-name } { export | import }
command in the user view to configure EVPN BGP soft reset.
----End
10.6.2 Resetting EVPN BGP Connections
Context
This section describes how to use the reset bgp command to reset EVPN BGP connections.
Resetting EVPN BGP connections causes BGP peer relationships to be interrupted.
A BGP peer relationship between routers is interrupted if you reset an EVPN BGP connection
using the reset bgp command. Exercise caution when you reset an EVPN BGP connection.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Run the reset bgp evpn all command in the user view to reset all EVPN BGP
connections.
l Run the reset bgp evpn as-number-plain command in the user view to reset the EVPN
BGP connections with a specified AS.
l Run the reset bgp evpn ipv4-address command in the user view to reset the EVPN BGP
connections with specified BGP peers.
l Run the reset bgp evpn group group-name command in the user view to reset the
EVPN BGP connections with specified BGP peer groups.
----End
10.7 Configuration Examples for EVPN

10.7.1 Example for Dynamically Establishing a VXLAN Tunnel in
BGP EVPN Mode to Implement Communication Between Users
in Different Network Segments
In Figure 10-6, Router1 and Router2 are the branch and headquarters gateways of an
enterprise. As users in the headquarters and branch have different service requirements, they
are planned in different network segments. PC_1 in the branch and PC_2 in the headquarters
belong to VLAN 10 and VLAN 20, respectively. The enterprise requires that users in the
headquarters and branch can communicate over a VXLAN tunnel dynamically established
using BGP EVPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 10-6 Configuring communication between different network segments through a

Layer 3 VXLAN gateway
Cloud
CPE
Loopback 1
10.3.3.2/32
VTEP Router3
19
4
Eth 8.3.
2/2
2.1
68 /1
2.1 /0
2/0 2/2
.2.
6
19 Eth2
/2 4
4
19
1/2
68 /0
Eth 8.3.
2 .1
2.1 /0
.2.
2/0 1/2
19 Eth2
6
/0 4
Loopback 1 VTEP VTEP Loopback 1
VXLAN tunnel
10.1.1.2/32 10.2.2.2/32
Router1
Router2
Eth2/0/1 Eth2/0/1
Marketing dept. 1 Marketing dept. 2
PC_1 PC_2
192.168.10.1/24 192.168.20.1/24
1. Configure a routing protocol on Router1, Router2, and Router3 to ensure Layer 3
network connectivity.
2. Configure a deployment mode for the VXLAN access service on Router1 and Router2.
3. Establish a BGP EVPN peer relationship.
4. Configure an IP address for the source VTEP on Router1 and Router2.
5. Configure a VPN instance on Router1 and Router2.
6. Configure a Layer 3 gateway on Router1 and Router2.
7. Configure Router1, and Router2 to advertise IP prefix routes to the BGP peer.
Procedure
Step 1 Configure a routing protocol.
# Configure Router1. The configurations of Router2 and Router3 are similar to the
configuration of Router1, and are not mentioned here. When OSPF is used, the 32-bit
loopback address of each router must be advertised.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router1] interface loopback 1

[Router1-LoopBack1] ip address 10.1.1.2 32
[Router1-LoopBack1] quit
[Router1] interface ethernet 2/0/0
[Router1-Ethernet2/0/0] undo portswitch
[Router1-Ethernet2/0/0] ip address 192.168.2.1 24
[Router1-Ethernet2/0/0] quit
[Router1] ospf
[Router1-ospf-1] area 0
[Router1-ospf-1-area-0.0.0.0] network 10.1.1.2 0.0.0.0
[Router1-ospf-1-area-0.0.0.0] quit
[Router1-ospf-1] quit
# After OSPF is configured, the routers can learn the loopback interface address of each other
and successfully ping each other. The following shows the ping result from Router1 to
Router2.
[Router1] ping 10.2.2.2

0.00% packet loss
Step 2 Configure a service access point on Router1 and Router2, respectively.

# Configure Router1. The configuration of Router2 is similar to the configuration of Router1,
[Router1] bridge-domain 10
[Router1-bd10] quit
[Router1] interface ethernet 2/0/1.1 mode l2
[Router1-Ethernet2/0/1.1] encapsulation dot1q vid 10
[Router1-Ethernet2/0/1.1] bridge-domain 10
[Router1-Ethernet2/0/1.1] quit
Step 3 Establish a BGP EVPN peer relationship.

# Establish a BGP EVPN peer relationship on Router1. The configuration of Router2 is
similar to the configuration of Router1, and is not mentioned here.
[Router1] bgp 100
[Router1-bgp] peer 10.3.3.2 as-number 100
[Router1-bgp] peer 10.3.3.2 connect-interface LoopBack1
[Router1-bgp] l2vpn-family evpn
[Router1-bgp-af-evpn] peer 10.3.3.2 enable
[Router1-bgp-af-evpn] quit
[Router1-bgp] quit
[Router1] interface nve 1
[Router1-Nve1] source 10.1.1.2
[Router1-Nve1] quit
Step 4 Configure a VPN instance on Router1 and Router2.

[Router1] ip vpn-instance vpn1
[Router1-vpn-instance-vpn1] ipv4-family

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1

[Router1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 evpn
[Router1-vpn-instance-vpn1-af-ipv4] quit
[Router1-vpn-instance-vpn1] vxlan vni 5010
[Router1-vpn-instance-vpn1] quit
[Router1-bd10] vxlan vni 2010
[Router1-bd10] quit
Step 5 Configure a Layer 3 VXLAN gateway on Router1 and Router2 and bind the VPN instance to
the gateway.
[Router1] interface vbdif 10
[Router1-Vbdif10] ip binding vpn-instance vpn1
[Router1-Vbdif10] ip address 192.168.10.10 24
[Router1-Vbdif10] quit
Step 6 Configure Router1, and Router2 to advertise IP prefix routes to the BGP peer.
# Configure Router1. The configurations of Router2 are similar to the configuration of
Router1, and are not mentioned here.
[Router1] bgp 100
[Router1-bgp] ipv4-family vpn-instance vpn1
[Router1-bgp-vpn1] import-route direct
[Router1-bgp-vpn1] advertise l2vpn evpn
[Router1-bgp-vpn1] quit
[Router1-bgp] quit

# After the configuration is complete, run the display vxlan tunnel command on Router1 and
Router2. You can view VXLAN tunnel information. The command output on Router3 is used
as an example.
[Router3] display vxlan tunnel
Tunnel ID Source Destination State Type
----------------------------------------------------------------------------
4026531842 10.1.1.2 10.2.2.2 up dynamic
----------------------------------------------------------------------------
Number of vxlan tunnel : 2
----End
Configuration Files
#
sysname Router1
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
100:1
evpn
evpn
vxlan vni
5010

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
bridge-domain
10
vxlan vni 2010
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#
interface Ethernet2/0/1.1 mode

l2
encapsulation dot1q vid
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.1.1.2 255.255.255.255
#
interface
Vbdif10
vpn1
ip address 192.168.10.10
255.255.255.0
#
interface
Nve1
source
10.1.1.2
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 10.2.2.2
enable
l2vpn-family
evpn
policy vpn-
target
peer 10.2.2.2
enable
vpn1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
import-route
direct
advertise l2vpn
evpn
#
ospf
1
area
0.0.0.0
network 10.1.1.2
0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname Router2
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
100:1
evpn
evpn
vxlan vni
5020
#
bridge-domain
20
vxlan vni 2020
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
20
bridge-domain 20
#
interface
LoopBack1
ip address 10.2.2.2 255.255.255.255
#
interface
Vbdif20
vpn1
ip address 192.168.20.10
255.255.255.0
#
interface
Nve1
source

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
10.2.2.2
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 10.1.1.2
enable
l2vpn-family
evpn
policy vpn-
target
peer 10.1.1.2
enable
vpn1
import-route
direct
advertise l2vpn
evpn
#
ospf
1
area
0.0.0.0
network 10.2.2.2
0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
#
sysname Router3
#
undo
portswitch
255.255.255.0
#
undo
portswitch
255.255.255.0
#
interface
LoopBack1
ip address 10.3.3.2 255.255.255.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ospf
1
area
0.0.0.0
network 10.3.3.2
0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
10.8 References for EVPN

The following table lists the references for EVPN.
Docume Document Name Protocol

nt No. Compliance
draft-ietf- IP Prefix Advertisement in EVPN Partially

bess-evpn- compliant
prefix- Compliant only
advertise with IP prefix
ment-01 routes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 11 VLL Configuration
11 VLL Configuration
About This Chapter
This chapter describes principles, applications, and configurations of the Virtual Leased Line
(VLL).
11.1 Overview of VLL

11.2 Understanding VLL
This section describes the implementation of VLL.
11.3 Application Scenarios for VLL
This section describes application scenarios for application scenarios for VLL.
11.4 Summary of VLL Configuration Tasks
VLLs are classified into three modes: CCC, Martini, SVC. If a network spans multiple ASs,
you need to configure inter-AS VLL. You can also configure VLL FRR to provide link-layer
reliability for VLL networks.
11.5 Licensing Requirements and Limitations for VLL
This section describes licensing requirements and limitations for VLL.
11.6 Default Settings for VLL
This section provides the default settings for VLL.
11.7 Configuring VLL
This section describes how to configure VLL functions in details.
11.8 Maintaining VLL
This section describes how to maintain VLL, including collecting, querying, and clearing
VLL statistics, checking VLL network connectivity, and resetting BGP TCP connections.
11.9 Configuration Examples for VLL
This section describes VLL configuration examples including the networking requirements,
configuration notes, and configuration roadmap.
11.10 Troubleshooting VLL
This section describes the common configuration errors and troubleshooting methods.
11.11 References for VLL
This section lists the references for VLL.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.1 Overview of VLL

Definition
Virtual leased line (VLL) technology, also called Virtual Private Wire Service (VPWS),
emulates leased lines on an IP network to provide a low-cost asymmetrical digital data
network (DDN) service. It is a point-to-point (P2P) Layer 2 tunneling technology based on
Multiprotocol Label Switching (MPLS), which allows the exchange of data packets between
networks using different media. Figure 11-1 shows an example of VLL networking.
Figure 11-1 VLL networking
HDLC
ATM
IP/MPLS
backbone
network
PE Tunnel PE
Ethernet Frame
Relay
VLL
Purpose
l In network development, various Layer 2 networks have been deployed and are still in
use, for example, Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay (FR), and
High-level Data Link Control (HDLC) networks. These Layer 2 networks are isolated
from one another because they use different Layer 2 protocols. However, there is an
increasing demand for direct communication between different Layer 2 networks.
l As Ethernet develops rapidly, more Ethernet connections are required between large
cities or remote areas. Traditionally, service providers deploy direct leased lines or set up
Layer 2 tunnels between two areas. (The Layer 2 tunnels are set up between Layer 2
switching devices.) This solution has a high cost and is difficult to maintain and extend
in some areas.
Service providers need a solution to these problems. VLL technology is introduced to
establish a compatible Layer 2 switching network that is cost effective and easy to maintain
and extend. Based on MPLS technology, VLL allows multiple customers to share one leased
line and creates an exclusive virtual channel for each customer on the shared line. On an
Ethernet network, sites in different cities can communicate over a P2P VLL connection on an
MPLS network, just like communicating within a virtual local area network (VLAN).
Since Ethernet has replaced most types of Layer 2 networks, VLL is rarely used for
communication between different networks, but is widely used for Layer 2 transparent
transmission.
VLL is an MPLS-based Layer 2 virtual private network (L2VPN) technology to directly
transmit Layer 2 data. VLL establishes P2P VPN tunnels for P2P communication.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Benefits
VLL brings the following benefits:
l Extended network functions and service capabilities for carriers
Carriers can use VLL and enhanced MPLS technologies, such as traffic engineering (TE)
and quality of service (QoS), to provide users with differentiated services, meeting
diversified user requirements.
l Interconnection between networks using different Layer 2 protocols
VLL allows an Internet service provider (ISP) network to provide connections and
switching services using multiple Layer 2 protocols.
l Higher scalability
VLL uses label stacks to identify multiple virtual circuits (VCs) in one label switched
path (LSP). Therefore, the P device only needs to maintain information about one LSP,
improving system scalability.
l Smaller maintenance workload
VLL provides a method to establish VPNs in large-scale enterprises with large sites and
many routes. P devices on the ISP networks only need to forward packets over tunnels
on the public network according to MPLS labels and do not need to maintain any Layer
2 information.
l Smooth network upgrade
VLL is transparent to users; therefore, carriers can smoothly upgrade their traditional
L2VPN networks, such as ATM and FR networks, to MPLS L2VPN networks, without
affecting configurations on customer networks. The network upgrade does not affect user
services, except for a brief period of data loss during network migration.
11.2 Understanding VLL

This section describes the implementation of VLL.
Basic VLL Architecture
VLL transparently transmits Layer 2 data packets from CE devices over tunnels and provides
P2P L2VPN service for users.
The basic VLL architecture consists of three components: attachment circuit (AC), virtual
circuit (VC), and tunnel. Pseudo wire (PW) is also a common term used in the VLL service.
Figure 11-2 shows the basic VLL architecture.
Figure 11-2 Basic VLL architecture
AC VC AC
Tunnel
IP/MPLS
CE PE backbone PE CE
network
PW

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 11-1 Description of VLL components

Component Full Name Description
AC Attachment circuit A connection between a customer and an

ISP, namely, a CE-PE link.
VC Virtual circuit A unidirectional logical connection

between two PE devices.
PW Pseudo wire A bidirectional logical connection between

two PE devices. A PW, also called a
simulated circuit, consists of two
unidirectional VCs in forward and reverse
directions.
Tunnel Tunnel A logical channel that carries one or

multiple PWs. A tunnel is a direct channel
that transparently transmits data between
the local and remote PE devices. It can be
an LSP, an MPLS TE tunnel, or a GRE
tunnel.
VLL Implementation
VLL implementation involves VLL establishment and VLL packet forwarding.
VLL Establishment
To establish a VLL network, you need to establish a PW and bind the AC with the PW.
1. Establishing a PW: You can configure a static PW between two PE devices, or configure
a signaling protocol to enable two PE devices to set up a PW by exchanging VC
information. After a PW is established, it is used as a dedicated channel on the public
network.
2. Binding the AC to the PW: After a PW is established, bind the AC-side interfaces on the
PE devices to the PW to associate the AC with the PW.
VLL Packet Forwarding
After a VLL network is established, packets transmitted on the network undergo
encapsulation, transparent transmission, and decapsulation processes.
1. Encapsulation
Before a PE device sends a packet from an AC-side interface to a PW, it processes the
packet based on the outer tag type and PW encapsulation mode.
The outer tag of a packet may be a U-Tag or P-Tag.
– A U-Tag is inserted into the packet by a customer device and is irrelevant to
services of the service provider (SP). When a GE interface, XGE interface, Ethernet
interface, or Eth-Trunk interface is used as the AC-side interface, packets sent from
the AC-side interface to a PW carry a U-Tag by default.
– A P-Tag is inserted into the packet by an SP device to distinguish traffic from
different users. When a sub-interface or VLANIF interface is used as the AC-side
interface, packets sent from the AC-side interface to a PW carry a P-Tag by default.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Two PW encapsulation modes are available: Ethernet encapsulation (raw mode) and
VLAN encapsulation (tagged mode).
Table 11-2 describes how a PE device processes a packet sent from an AC-side interface
to a PW.
Table 11-2 Processing a packet sent from an AC-side interface to a PW

Packet from an AC-side PW Encapsulation Packet Processing on
Interface to a PW Mode the PE
Packet with a P-Tag Ethernet Removes the P-Tag from

the packet and adds two
MPLS labels (an inner VC
label and an outer tunnel
label) before forwarding
the packet.
VLAN Retains the P-Tag and adds

two MPLS labels (an inner
VC label and an outer
tunnel label) before
forwarding the packet.
Packet without a P-Tag Ethernet/VLAN Does not process the tag

and only adds two MPLS
labels (an inner VC label
and an outer tunnel label)
before forwarding the
packet, regardless of
which encapsulation mode
is used.
2. Transparent transmission
VLL uses an MPLS tunnel to transmit packets. Encapsulated packets are transparently
transmitted to the remote PE device over the MPLS tunnel, with their inner VC labels
unchanged.
3. Decapsulation
After the remote PE device receives a packet, it decapsulates the packet and forwards the
packet to the AC-side interface based on the VC label carried in the packet.
After the packet is decapsulated, the packet is transmitted through the PW to the AC.
The remote PE device processes the packet based on the outer tag type and AC-side
interface type. Table 11-3 describes how the PE device processes a packet sent from a
PW to an AC-side interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 11-3 Processing a packet sent from a PW to an AC-side interface

Packet from VLAN Tag Processing on the PE
a PW to an
AC-side
Interface
Packet with a The PE device processes the packet differently depending on the type
P-Tag of the AC-side interface.
l Main interface (Ethernet, GE, XGE, or Eth-Trunk interface): does
not process the packet.
l VLANIF interface: replaces the P-Tag in the packet.
l Dot1q termination sub-interface: does not process the packet.
When the Ethernet encapsulation mode is used, the Dot1q
termination sub-interface allows packets from only one VLAN to
pass through.
l QinQ termination sub-interface: replaces the P-Tag in the packet.
Packet The PE device processes the packet differently depending on the type
without a P- of the AC-side interface.
Tag l Main interface: does not process the packet.
l VLANIF interface: adds a P-Tag to the packet.
l Dot1q termination sub-interface: adds a P-Tag to the packet. When
the Ethernet encapsulation mode is used, the Dot1q termination
sub-interface allows packets from only one VLAN to pass
through.
l QinQ termination sub-interface: adds a P-Tag to the packet.
11.2.2 VLL Modes
11.2.2.1 VLL in CCC Mode
Introduction
A VLL connection in Circuit Cross Connect (CCC) mode is set up through the static
configuration.
A CCC connection does not require signaling negotiation or exchange of control packets;
therefore, it consumes few resources and is easy to configure. This mode applies to small
MPLS networks with simple topologies.
Topology
The CCC mode supports both local and remote connections. Figure 11-3 shows the topology
in CCC mode.
NOTE
Currently, the device does not support remote CCC connection.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-3 CCC connections
Site1
IP/MPLS backbone VPN2
network Site2
P P
PE3
VPN1 PE1
CE
CE
Site1
PE2 CE
P P VPN1
Site2
CCC local connection
CCC remote connection
Local connection: Site1 and Site2 of VPN2 are connected through a CCC local connection
(the black dashed line). PE3 acts as a Layer 2 switch for Site1 and Site2, and no LSP is
required between the CE devices connected to PE3.
Remote connection: Site1 and Site2 of VPN1 are connected through a CCC remote
connection (the blue dashed line). Site1 and Site2 require two static LSPs: one from PE1 to
PE2 and one from PE2 to PE1. The two blue dashed lines represent a bidirectional PW, or
CCC remote connection. This CCC remote connection is similar to a traditional L2VPN
connection.
A CCC remote connection uses static VCs and maps L2PDUs received on one end of a VC to
a static LSP. The L2PDUs are forwarded along the static LSP hop by hop based on the MPLS
configuration and finally reach the other end of the VC. Unlike other VLL modes, the CCC
mode uses a single label to transmit data. This label is swapped on each label switching router
(LSR). Therefore, each LSP is used exclusively, and two LSPs in forward and reverse
directions must be configured for each CCC connection. The LSPs associated with a CCC
connection can transmit only the data of this connection and cannot be used for other MPLS
L2VPN connections. In addition, the LSPs cannot be used to set up a BGP/MPLS IP VPN
connection or transmit common IP packets.
11.2.2.2 VLL in Martini Mode
Introduction
VLL in Martini mode uses the Label Distribution Protocol (LDP) as the signaling protocol to
transmit VC information. It complies with RFC4906 and extends LDP by adding a forwarding
equivalence class (FEC), VC FEC, for VC label switching. A PE device assigns a VC label to
each connection between CE devices. VC labels are carried in L2VPN information and
forwarded to a remote PE device through an LDP LSP over the public network. As VLL
connections are identified using VC labels, and multiple VC LSPs can be created on an LSP
on the public network. The mappings between VC labels and LSPs are saved only on PE
devices, while the P devices do not need to maintain any L2VPN information. Therefore,

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Martini mode is highly scalable. Additionally, it allows multiple VLL connections to use the
same public tunnel, which is not supported by the CCC mode.
In Martini mode, a VC is identified by its VC type and VC ID.
l VC type: indicates the encapsulation type of a VC, VLAN encapsulation or Ethernet

encapsulation.
l VC ID: identifies a VC. VCs of the same type must have different VC IDs on a PE
device.
Topology
VLL in Martini mode supports only remote connections. Figure 11-4 shows the topology in
Martini mode.
Figure 11-4 Topology in Martini mode

VPN1 VPN1
Site1 IP/MPLS Site2
backbone
network
CE CE
PE1 P PE2
Site1 Site2
CE Martini connection CE
VPN2 VPN2
Implementation
Martini implementation involves VLL establishment and VLL packet forwarding. PW
establishment is key to VLL establishment. As long as a PW is established, packets can be
forwarded.
1. PW Establishment and Teardown

2. Packet Forwarding
The Martini mode uses extended LDP to exchange VC labels. For details about LDP, see VC
Information Exchange.
PW Establishment and Teardown
l Establishing a PW
The downstream unsolicited (DU) label distribution mode and liberal label retention
mode are used to establish a PW. For details, see LDP LSP Establishment in the MPLS
Configuration.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-5 Establishing a PW using LDP
PE1 PE2
Reque
1 st
Mappin
g
ing 2
Mapp
3 PW up
After an LDP session is established between the PE devices, a PW is established in the

process shown in Figure 11-5.
a. PE1 sends a Request packet to PE2 and sends a Label Mapping message to PE2 in
DU mode. The Label Mapping message carries information including the VC label,
VC type, VC ID, and interface parameters.
b. After PE2 receives the Request packet, it sends a Label Mapping message to PE1.
After PE2 receives the Label Mapping message, it compares VC information
carried in the message with its own VC information. If they are the same, PE1 and
PE2 are in the same VLL. PE2 then accepts the Label Mapping message, and a
unidirectional VC1 is established. PE2 knows the inner VC label that it needs to add
to packets to sent the packets to PE1.
c. After PE1 receives the Label Mapping message from PE2, it processes the message
in the same way to establish VC2 in the reverse direction. The two unidirectional
VCs constitute a PW.
l Tearing down a PW
Figure 11-6 Tearing down a PW using LDP
PE1 PE2
Withdr
1 aw
Releas
e
se 2
Relea
3 PW delete
When the AC or tunnel goes Down or a VC is deleted, the PW is torn down. Figure 11-6
shows the process of tearing down a PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
a. When PE1 detects that the AC or tunnel has gone Down or a VC has been deleted,
it sends a Withdraw message to PE2 to instruct PE2 to delete the VC label. To tear
down the PW more quickly, PE1 sends a Withdraw message and a Release message
consecutively. The Release message notifies PE2 that PE1 has deleted the VC label.
b. After receiving the Withdraw and Release messages, PE2 deletes the VC1 label and
tears down VC1. PE2 then sends a Release message to PE1 to instruct PE1 to delete
the VC2 label.
c. After receiving the Release message, PE1 deletes the VC2 label and tears down
VC2. Then the PW is torn down.
Packet Forwarding
A VLL is established after VC information exchange and PW establishment. The following

describes the packet forwarding process in Martini mode.(This figure shows two VLL
networks: VPN1 and VPN2.)
Figure 11-7 Packet forwarding process in Martini mode

VPN1 VPN1
IP/MPLS backbone Site2

Site1 network
VL
1000 3000 1002 3000
0
CE
N1
CE
A
1000 4000 1002 4000

N1
A
VL
10
VL
0
P PE2
AN
PE1
AN
10
VL
0
VL
10
AN
AN
0
10
2002 3500 2000 3500 10

VL
VL
AN
0
2002 4500 2000 4500
AN
VL
Site2
10
Site1
0
CE CE
Site1 to Site2
VPN2 Site2 to Site1 VPN2
Figure 11-7 shows packet forwarding in two directions: from Site1 to Site2 and from Site2 to
Site1.
l From Site1 to Site2

When a packet of VLAN 10 is sent from Site1 of VPN1 to PE1, PE1 adds a VC label
3000 and an outbound label 1000 of LSP1 to the packet. Then the packet enters LSP1
(the black dashed line). When a packet of VLAN 100 is sent from Site1 of VPN2 to PE1,
PE1 adds a VC label 4000 and an outbound label 1000 of LSP1 to the packet. Then the
packet enters LSP1 (the black dashed line).
When packets sent from Site1 reach PE2, PE2 removes the inbound label 1002 of LSP1
and selects the outbound interface according to the inner VC label. If the inner VC label
is 3000, PE2 forwards the packets to the outbound interface connected to Site2 of VPN1.
If the inner VC label is 4000, PE2 forwards the packets to the outbound interface
connected to Site2 of VPN2. PE2 transmits VC labels 3000 and 4000 to PE1 using LDP
when they set up the VCs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l From Site2 to Site1

When a packet of VLAN 10 is sent from Site2 of VPN1 to PE2, PE2 adds a VC label
3500 and an outbound label 2000 of LSP2 to the packet. Then the packet enters LSP2
(the blue dashed line). When a packet of VLAN 100 is sent from Site2 of VPN2 to PE2,
PE2 adds a VC label 4500 and an outbound label 2000 of LSP2 to the packet. Then the
packet enters LSP2 (the blue dashed line).
When packets sent from Site2 reach PE1, PE1 removes the inbound label 2002 of LSP2
and selects the outbound interface according to the inner VC label. If the inner VC label
is 3500, PE1 forwards the packets to the outbound interface connected to Site1 of VPN1.
If the inner VC label is 4500, PE1 forwards the packets to the outbound interface
connected to Site1 of VPN2. PE1 transmits VC labels 3500 and 4500 to PE2 using LDP
when they set up the VCs.
In the transmission process, the outer labels specify the LSP for data transmission on the ISP
network, and the inner VC labels identify data from different users. Data from multiple VCs
can be transmitted over the same LSP.
To deploy VLL in Martini mode, the ISP network must be able to automatically set up LSPs.
Therefore, the ISP network must support MPLS forwarding and MPLS LDP. If the ISP
network does not support LDP, GRE tunnels can be used on the ISP network.
VC Information Exchange
The Martini VLL extends the standard LDP by adding a VC FEC (type 128) to a Label
Mapping message to carry VC information during PW establishment.
Figure 11-8 shows the format of a Label Mapping message. You can see the VC FEC in the
Label Mapping message.
Figure 11-8 LDP Label Mapping message

0 15 31
0 Label Message(0x0400) Message Length
Message ID
0 0 FEC TLV(0x0010) Length
VC TLV(0x80) c VC Type VC Info Length
Group ID
VC ID
Interface Parameters
0 0 Generic Label(0x0200) Length

Label
Optional Parameters
VC FEC
VC FEC contains the inner VC label and interface parameters.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 11-4 Description of fields in the VC FEC (Type 128)

Field Description Bits Remarks
VC TLV Type, Length, 8 The value is 0x80, or 128 in

and Value decimal notation.
(TLV) of a VC
C Control word 1 If the value is 1, control word is

supported. If the value is 0, control
word is not supported.
VC Type Type of a VC 15 The value can be Ethernet or

VLAN.
VC Info Length Length of VC 8 The value is the total length of the

information VC ID and the Interface Parameters
field.
Group ID ID of a VC 32 Multiple VCs can constitute a VC

group group and information about all
VCs in the group can be deleted
together.
VC ID ID of a VC 32 -
Interface Interface Variable, The frequently used interface

Parameters parameters smaller than parameters include MTU and
the value of interface description.
VC Info
Length
11.2.2.3 VLL in SVC Mode
Introduction
The static virtual circuit (SVC) mode is a simplified Martini mode. Unlike the Martini mode
that uses LDP to exchange VC labels, the SVC mode uses VC labels that are manually
configured on PE devices.
An SVC VLL uses static VC labels and does not need VC label mapping. Therefore, LDP is
not required for transmitting VC labels.
Topology
The SVC mode sets up a public tunnel (outer label) in the same way as the Martini mode. The
inner label is manually configured during VC setup, and PE devices do not need to exchange
VC labels using any signaling protocol. The SVC mode does not support local connections.
The network topology and packet exchange process in SVC mode are the same as those in
Martini mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-9 Packet exchange in SVC mode

VPN1 VPN1
Site1 IP/MPLS backbone Site2
network
1000 4000 1002 4000
CE CE
PE1 P PE2
Site1 2002 3500 2000 3500 Site2
CE Site1 to Site2 CE
Site2 to Site1
VPN2 VPN2
As shown in Figure 11-9, an SVC VLL is established between two sites of VPN1. On PE1,
the label for sent packets is set to 4000 and the label for received packets is set to 3500. On
PE2, the label for sent packets is set to 3500 and the label for received packets is set to 4000.
When a packet is sent from Site1 to Site2 of VPN1, PE1 adds the inner VC label 4000 to the
packet. After PE2 receives the packet with the inner VC label 4000, it sends the packet to the
CE device through the AC mapping the inner VC label.
11.2.2.4 Comparison of VLL Modes

Table 11-5 compares three VLL modes.
Table 11-5 Comparison of VLL modes

Implementati VC Label PW Signaling Characteristics
on Distribution Protocol
Mode
CCC Manually None This mode establishes

specified one-layer static LSP
tunnels for VC
information
transmission.
Martini Randomly LDP This mode establishes

distributed by the two layers of tunnels.
system The outer tunnel is a
public network tunnel
used to transparently
transmit data, and the
inner tunnels are
identified by VC labels
distributed by the
system.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Implementati VC Label PW Signaling Characteristics

on Distribution Protocol
Mode
SVC Manually None This mode establishes

specified two layers of tunnels.
The outer tunnel is a
public network tunnel
used to transparently
transmit data, and the
inner tunnels are
identified by VC labels
that are manually
specified.
11.2.3 Inter-AS VLL

number of applications. As additional sites are developed in an enterprise, sites in different
geographical locations are often connected to different ISP networks. Consider, for example,
the inter-AS issue facing operators who manage different metropolitan area networks (MANs)
or backbone networks that span different autonomous systems (AS). This scenario requires a
different interworking model than the MPLS VPN architecture. This interworking model,
called the inter-AS VLL, features a VPN that spans multiple ASs. In inter-AS networking, the
devices located at the edge of ASs are AS boundary routers (ASBRs).
Inter-AS VLL implementation depends on the VLL mode.

l The CCC mode uses a single label. Therefore, the inter-AS VLL can be set up when
static LSPs are set up between ASBRs.
l The SVC and Martini modes can implement inter-AS VLL Option A (VRF-to-VRF).
In inter-AS Option A, a sub-interface must be reserved for each inter-AS VC on an ASBR.

The ASBRs do not require MPLS or other additional inter-AS configuration. With Option A,
ASBRs of the two ASs are directly connected and function as PE devices in their respective
ASs. The two ASBRs regard each other as CE devices. Figure 11-10 shows the inter-AS
option A networking.
Figure 11-10 Inter-AS Option A

PE1 ASBR1 ASBR2 PE2
AS100 AS200
CE1 CE2
For details about inter-AS VPN, see 8.2.4 Inter-AS VPN in the BGP/MPLS IP VPN
Configuration.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.2.4 VLL FRR

Widespread adoption of MPLS L2VPN technologies has raised high reliability requirements
for L2VPNs, especially for L2VPNs that carry real-time services such as VoIP and IPTV.
Virtual Lease Line Fast Reroute (VLL FRR) uses redundant networking to improve MPLS
L2VPN reliability. When a PW or PE device fails, VLL FRR fast switches traffic to a backup
link. This mechanism implements end-to-end fault detection on PWs and provides PW
protection, greatly improving link-layer reliability for MPLS L2VPNs.
Figure 11-11 shows the application of VLL FRR in asymmetrical CE deployment: the CE
device is connected to one PE device at one end while the CE device is dual-homed to two PE
devices at the other end.
Figure 11-11 Asymmetrical CE deployment
IP/MPLS
backbone
network
PE2
PE1
P1
CE1 CE2
P2
Site1 PE3 Site2
In asymmetrical networking, PE1 or CE2 is the failover point and the last step in the fault
notification process. When the primary link fails, PE1 in the single-homed site detects the
fault, triggers traffic switching, and does not send fault notification to CE1. When the primary
link in the dual-homed site fails, CE2 receives the fault notification from the PE device on the
primary link and switches traffic to the backup link.
VLL FRR Implementation

l Fault Detection
When a fault occurs on the VLL network, devices can detect link failures through route
convergence. However, the detection speed is slow and cannot meet the requirements of
delay-sensitive services, such as VoIP services. To improve the fault detection speed, you
can deploy Bidirectional Forwarding Detection (BFD) on the PE device to rapidly detect
PW failures. BFD has a low cost and can implement millisecond-level fault detection.
l Switching Between Primary and Backup PWs

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
You can set up a backup PW on the VLL network. When the primary PW is working
properly, the backup PW does not transmit data. When the primary PW is faulty, data is
switched to the backup PW. The backup PW remains in Up state to ensure fast traffic
switching when the primary PW fails, preventing traffic loss.
As shown in Figure 11-12, PE1-P1-PE2 is the primary link and PE1-P2-PE3 is the
backup link. When the system detects that the primary PW or PE2 is faulty, PE1
performs switching between primary and backup PWs to import traffic to the backup
PW, ensuring traffic transmission from CE1 to CE2.
Figure 11-12 Switching between primary and backup PWs
IP/MPLS
backbone
network
PE2
P1
PE1
CE1 CE2
P2
Site1 PE3 Site2
Primary PW
Backup PW
l Fast Fault Notification

As shown in Figure 11-12, switching between primary and backup PWs ensures normal
traffic transmission from CE1 to CE2, while switching of traffic from CE2 to CE1 is
ensured by fast fault notification.
The OAM mapping between a PW and an AC interface can be created. In this manner,
when a PW or a PE is faulty, a CE can take measures in time to fast switch traffic to a
secondary path. The OAM messages are transparently transmitted on a PW. This enables
the PW with the end-to-end fault detection function.
– AC Fault Detection and Notification Mechanism
As shown in Figure 11-13, in the scenario where a fault occurs on an AC between
CE1 and PE1, the fault detection and notification mechanism works as follows:
i. AC OAM on PE1 detects an AC fault.
ii. According to the OAM mapping on the PE1, the PW status corresponding to
the AC is updated.
iii. BFD transparently sends an OAM fault message to PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
iv. When PE2 receives the BFD fault message, if a secondary PW is set up on the
remote PE, the traffic switchover is performed. Otherwise, OAM mapping is
performed and then the faulty AC is notified to CE2.
Figure 11-13 AC fault detection and notification mechanism
OAM mapping OAM mapping

BFD
PE1 PE2
OAM detection OAM notification
AC fault
CE1 CE2
– PSN Fault Detection and Notification Mechanism

As shown in Figure 11-14, when a fault occurs in a packet switched network
(PSN), the fault detection and notification mechanism works as follows:
i. The BFD session on the PE detects a fault in the PSN.
ii. The PE obtains the local AC according to the OAM mapping.
iii. If a secondary PW is set up, the traffic switchover is performed; otherwise, the
OAM mapping is performed and the corresponding AC is mapped and the
fault is notified to the local CE.
Figure 11-14 PSN fault detection and notification mechanism
OAM mapping OAM mapping

BFD BFD
PSN fault
PE1 PE2
OAM detection OAM notification
CE1 CE2
l PW Switchback Policy
In the networking of CEs asymmetrically accessing PEs, when PE1 is notified of fault
removal on the primary PW, PE1 works based on the PW switchback policy.
The PW switchback policies are as follows:
– No switchback: Traffic is not switched back to the primary PW.
– Immediate switchback: Traffic is immediately switched back to the primary PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– Delayed switchback: Traffic is switched back to the primary PW after a delay

period.
After the switchback, the PE immediately notifies the peer PE on the secondary PW of
the fault. In addition, after a delay period or immediately the PE notifies the peer PE on
the secondary PW of fault removal, which prevents packet loss due to transmission delay
between PEs.
11.3 Application Scenarios for VLL

This section describes application scenarios for application scenarios for VLL.
11.3.1 Point-to-Point Layer 2 Connection Between Sites in

Different Cities
VLL technology enables Layer 2 protocol data units (L2PDUs) to traverse a carrier network
without being changed. Sites in different cities can use this technology to set up P2P Layer 2
interconnection and communicate as if they were on a LAN.
Figure 11-15 P2P Layer 2 interconnection between sites in different cities

IP/MPLS
backbone
network
Tunnel
U
L2
PD
PD
L2
PE
U
PE
Site L2PDU: Layer 2 packets Site
11.3.2 Multi-service Transparent Transmission over PWs on a

MAN
In many carrier-class services, carriers use digital subscriber line access multiplexers
(DSLAMs) or Ethernet switches to provide access lines such as asymmetric digital subscriber
line (ADSL), very-high-data-rate digital subscriber line (VDSL), or Ethernet links and need to
control various services. Service control includes Point-to-Point Protocol over Ethernet
(PPPoE) access request termination, IP address assignment, user authentication, authorization,
and accounting. Terminal access gateways are responsible for service control. As large-
capacity and high-performance terminal access gateway (Huawei ME60 for example) are
developed, terminal access gateway are moving gradually upward to the metropolitan area
network (MAN) egress. This means that DSLAMs are connected to the MAN, and integrated
terminal access gateway are deployed at the MAN egress to control services.
Terminal access gateway usually exchange information with users through Layer 2 links. For
example, a terminal access gateway obtains user names and passwords through PPPoE

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
sessions. However, a MAN is a Layer 3 IP/MPLS network. If Layer 2 user information is

terminated on the UPE devices connected to DSLAMs, terminal access gateway cannot obtain
required information through Layer 2 connections, and therefore they cannot control services.
To solve this problem, VLLs can be set up on the MAN to transmit Layer 2 packets
exchanged between BRASs and users over PWs.
Figure 11-16 Multi-service transparent transmission over PWs on a MAN
L2PDU exchange between

CE and BRAS using a PW
over the MAN
L2PDU Metro L2PDU

IP/MPLS
backbone
network
DSLAM CE BRAS
PE PE-AGG
(NPE)
PW
11.4 Summary of VLL Configuration Tasks

VLLs are classified into three modes: CCC, Martini, SVC. If a network spans multiple ASs,
you need to configure inter-AS VLL. You can also configure VLL FRR to provide link-layer
reliability for VLL networks.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 11-6 VLL configuration tasks

Configure basic Basic VLL functions are l 11.7.1 Configuring the CCC
VLL functions configured on MPLS VLL VLL
backbone networks that do not l 11.7.2 Configuring the
span multiple ASs and do not Martini VLL
require VLL FRR. With basic
VLL functions configured, sites l 11.7.3 Configuring the SVC
can set up P2P Layer 2 VLL
connections for communication.
You need to select a proper VLL
mode based on the scale of the
current network and network
expansion requirements.
l The CCC VLL applies to
small-scale enterprises with a
few sites and simple
topologies.
l The Martini VLL applies to
large-scale enterprises or
LANs of small-scale carriers.
VLL in Martini mode is easy
to configure and extend and
mature in fault locating;
therefore, this mode is widely
used.
l The SVC VLL is a simplified
Martini mode, in which inner
labels are manually specified.
The SVC mode facilitates
planning of label resources on
VLL networks, but it increases
configuration workload and is
not easy to extend.
Configure inter- Configure inter-AS VLL if the 11.7.4 Configuring Inter-AS

AS VLL VLL backbone network spans VLL
multiple ASs.
Configure VLL Configure VLL FRR to ensure 11.7.5 Configuring VLL FRR
FRR link-layer reliability.
Configure and Tunnel policies are required when 11.7.7 Configuring and
apply a tunnel VLL services need to be Applying a Tunnel Policy
policy transmitted over TE tunnels or
when multiple tunnels need to
perform load balancing to fully
use network resources.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.5 Licensing Requirements and Limitations for VLL

This section describes licensing requirements and limitations for VLL.

None
For L2VPN-capable devices, their licensing requirements for the L2VPN function are as
follows:
l AR1200&AR2200&AR3200&AR3600 series: By default, L2VPN function is disabled
on a new device. To use the L2VPN function, apply for and purchase the following
license from the Huawei local office.
Feature Limitations
l VLL cannot be configured on the VLANIF 1.
l The VLANIF interface configured with VLL can only correspond to one member
interface. This limitation does not apply to AR1220E, AR1220EV, and AR1220EVW.
When configuring VLL on the devices, pay attention to the following points:
The AR100&AR120&AR150&AR160&AR200 series do not support VLL.
11.6 Default Settings for VLL

This section provides the default settings for VLL.
Table 11-7 Default settings for VLL

MPLS L2VPN Disabled
MTU of a PW 1500
Revertive switching policy for VLL FRR Delayed revertive switching
11.7 Configuring VLL

This section describes how to configure VLL functions in details.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.7.1 Configuring the CCC VLL

The CCC VLL does not require signaling negotiation or exchange of control packets;
therefore, it consumes few resources and is easy to configure. However, it requires manual
configuration and makes network maintenance and expansion difficult. This mode applies to
small-scale MPLS networks with simple topologies.
l Enabling basic MPLS capabilities on the PE and P devices of the MPLS backbone
network before configuring a local CCC connection
Procedure
l Configure a local CCC connection.
To create a local CCC connection, you only need to configure the inbound and outbound
interfaces of the CCC connection on the PE device. Perform the following operations on
the PE device:
a. Run system-view
b. Run mpls l2vpn
MPLS L2VPN is enabled and the MPLS L2VPN view is displayed.
Enable MPLS L2VPN on the PE device before you configure a VLL.
c. Run quit
d. Run ccc ccc-connection-name interface interface-type1 interface-number1 [ raw |
tagged ] out-interface interface-type2 interface-number2 [ raw | tagged ]
A local CCC connection is created.
The local CCC connection is bidirectional; therefore, only one connection is
required.

After you complete configuring the CCC VLL, run the following commands to check
information about the CCC connection and interfaces used by the connection.
l Run the display vll ccc [ ccc-name | type local ] command to check information about a
CCC connection.
l Run the display l2vpn ccc-interface vc-type ccc [ down | up ] command to check
information about interfaces used by the CCC connection.
11.7.2 Configuring the Martini VLL

The Martini VLL applies to LANs of large-scale enterprises or small-scale carriers.
Before configuring the Martini VLL, you need to complete the following tasks:
l Configuring static routes or an Interior Gateway Protocol (IGP) protocol for the PE and
P devices on the MPLS backbone network to implement IP connectivity.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Enabling basic MPLS capabilities on the PE and P devices and enabling MPLS LDP on
PEs.
You need to set up a remote LDP session between the PEs if they are not directly
connected.
l Setting up a tunnel (GRE tunnel, LSP tunnel, or TE tunnel) between the PEs.
You also need to configure tunnel policies when VLL services need to be transmitted
over TE tunnels or when VLL services need to be load balanced among multiple tunnels
to fully use network resources. For details, see step 1 in Configuring and Applying a
Tunnel Policy.
Procedure
Perform the following operations on PEs at both ends of the VC.
1. Run system-view
2. Run mpls l2vpn
3. Run quit
The Martini VLL can use the following interfaces as AC interfaces: GE interfaces, GE
sub-interfaces, XGE interfaces, XGE sub-interfaces, Ethernet interfaces, Ethernet sub-
interfaces, Eth-Trunk interfaces, Eth-Trunk sub-interfaces, and VLANIF interfaces.
The sub-interfaces can be dotlq sub-interfaces or QinQ sub-interfaces.
5. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ tunnel-policy
policy-name | [ control-word | no-control-word ] | [ raw | tagged ] | mtu mtu-value ] *
A VLL connection in Martini mode is created. VCs of the same encapsulation mode on a
PE must have a unique VC ID.
Configure a PW template before you can use it. Refer to Creating a PW Template and
Setting Attributes for the PW Template for details on the PW template configuration.
6. (Optional) Run bpdu transmit enable
The interface connected to a VLL is enabled to transparently transmit BPDU packets.
7. (Optional) Run mpls l2vpn frag
Fragmentation of L2VPN IPv4 packets is enabled.
8. (Optional) Run mpls l2vpn service-name service-name
A name is configured for the L2VPN service, so you can maintain the L2VPN service by
clicking the name directly on the NMS graphical user interface (GUI).

After completing the Martini VLL configuration, you can view Martini VLL connection
information on the PEs.
l Run the display mpls l2vc [ vc-id | interface interface-type interface-number ]
command to check Martini VLL connection information on the local PE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Run the display mpls l2vc remote-info [ vc-id ] command to check peer Martini VLL
connection information on the local PE.
l Run the display mpls l2vc brief command to check Martini VLL connection brief
information on the local PE.
11.7.3 Configuring the SVC VLL

The SVC VLL is a simplified Martini mode, in which inner labels are manually specified.
The SVC mode facilitates planning of label resources on VLL networks, but it increases
configuration workload and is not easy to extend.
Before configuring the SVC VLL, you need to complete the following tasks:
l Configuring static routes or an IGP protocol for the PE and P devices on the MPLS
backbone network to implement IP connectivity.
l Enabling the MPLS for PEs and Ps.
l Setting up a tunnel (GRE tunnel, LSP tunnel, or TE tunnel) between the PEs.
Tunnel Policy.
Procedure
Perform the following operations on the PE devices at both ends of a VC:
1. Run system-view
2. Run mpls l2vpn
3. Run quit
The SVC VLL can use the following interfaces as AC interfaces: GE interfaces, GE sub-
interfaces, XGE interfaces, XGE sub-interfaces, Ethernet interfaces, Ethernet sub-
interfaces, Eth-Trunk interfaces, Eth-Trunk sub-interfaces, and VLANIF interfaces.
The sub-interfaces can be dotlq sub-interfaces or QinQ sub-interfaces.
5. Run mpls static-l2vc { { destination ip-address | pw-template pw-template-name vc-
id } * | destination ip-address [ vc-id ] } transmit-vpn-label transmit-label-value
receive-vpn-label receive-label-value [ tunnel-policy tnl-policy-name | [ control-word |
no-control-word ] | [ raw | tagged ] ] *
The SVC VLL is created.
Configure a PW template before you can use it. Refer to Creating a PW Template and
Setting Attributes for the PW Template for details on the PW template configuration.
6. (Optional) Run bpdu transmit enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The interface connected to a VLL is enabled to transparently transmit BPDU packets.

7. (Optional) Run mpls l2vpn service-name service-name
A name is configured for the L2VPN service, so you can maintain the L2VPN service by
clicking the name directly on the NMS GUI.
8. (Optional) Run mpls l2vpn frag
Fragmentation of L2VPN IPv4 packets is enabled.

After you complete configuring the SVC VLL, run the following commands to check
information about the SVC connection and interfaces used by the SVC connection.
l Run the display mpls static-l2vc [ interface interface-type interface-number ] command

to check the SVC L2VPN connection information on the PE.
l Run the display mpls static-l2vc brief command to check the SVC L2VPN connection
brief information on the PE.
l Run the display l2vpn ccc-interface vc-type static-vc [ down | up ] command to check
the interface information of the SVC connections in Up/Down state.
11.7.4 Configuring Inter-AS VLL

If VLLs need to be set up over an MPLS backbone that spans multiple ASs, the inter-AS VLL
must be configured.
Context
The configuration of inter-AS varies with the VLL implementation mode.
l The CCC mode uses a single label. Therefore, the inter-AS VLL can be set up when
static LSPs are set up between ASBRs.
l The Martini and SVC modes can implement inter-AS VLL Option A (VRF-to-VRF).
To configure inter-AS Option A, you must specify an interface (a sub-interface, a physical

interface, or a bundled logical interface) for each inter-AS VC on ASBRs.
Procedure
To implement inter-AS Option A, complete basic VLL configurations in each AS and
configure the ASBR-PE devices as the CE devices of each other.
l To configure inter-AS CCC VLL, see 11.7.1 Configuring the CCC VLL.
l To configure inter-AS Martini VLL using Option A, see 11.7.2 Configuring the Martini
VLL.
l To configure inter-AS SVC VLL using Option A, create the SVC for each AS. For the
detailed configuration, see 11.7.3 Configuring the SVC VLL.
NOTE
You do not need to perform any additional configuration for inter-AS implementation on ASBRs and do
not need to configure IP addresses for the directly connected interfaces between ASBRs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

l Run the display vll ccc [ ccc-name | type local ] command to check information about a
CCC VLL.
l Run the display l2vpn ccc-interface vc-type ccc [ down | up ] command to check
information about interfaces used by the CCC VLL.
command to check PW information about the local end of a Martini VLL.
l Run the display mpls l2vc remote-info [ vc-id ] command on the PE device to check
PW information about the remote end of the Martini VLL.
to check information about an SVC VLL.
l Run the display l2vpn ccc-interface vc-type static-vc [ down | up ] command to view
information about VC interfaces in the Up/Down state on the SVC VLL.
11.7.5 Configuring VLL FRR

You can configure VLL FRR to provide link-layer protection to improve reliability for VLL
networks.
Context
Only the Martini VLL modes support VLL FRR. VLL FRR is mainly used in a CE
asymmetrical networking, as shown in Figure 11-17.
Figure 11-17 CE asymmetrical networking
IP/MPLS
backbone
network
PE2
PE1
P1
CE1 CE2
P2
Site1 PE3 Site2
In the networking:
l The primary and secondary IP addresses need to be configured on the interface on the
CE connected to the PE through a single link. When the primary link is available, the CE
in the single-homed site uses the primary IP address to communicate with the remote

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CE. When a fault occurs on the primary link, this CE communicates with the remote CE
by using the secondary IP address.
l The secondary PW cannot transmit data when the primary and secondary paths work
normally. On the CE in the dual-homed site, if the interface of the secondary PW
borrows the IP address of the interface of the primary PW, the following situations occur:
– The policy of none revertive switching cannot be configured.
– The local CE has two equal-cost and direct routes to the remote CE. The destination
addresses and next hops of the two routes are the same. Actually, the route that
passes through the secondary PW is invalid.
– If CEs exchange routing information by using routing protocols, you need to
modify the cost or metric of the AC interface of the secondary path to be greater
than that of the AC interface of the primary path. The local CE cannot communicate
with the peer CE, but can communicate with other user devices.
– If CEs use static routes to exchange routing information, you need to modify the
preference of the backup route to be lower than that of the primary route (the
greater the value, the lower the preference) by using the ip route-static dest-ip-
address mask out-interface preference preference-value command.
Before configuring VPN FRR, complete the following tasks:
l Configuring basic VLL functions
l Configuring CEs to exchange routing information by using routing protocols or static
routes
l Setting up a tunnel (GRE tunnel, LSP tunnel, or TE tunnel) between the PEs
Tunnel Policy.
Some of the following operations are optional. Perform the operations in the following
sequence.
11.7.5.1 Configuring Primary and Secondary PWs
Context
You can configure primary and secondary PWs for PW backup on a network. VLL FRR uses
redundant networking to improve L2VPN reliability. When a PW or PE device fails, VLL
FRR fast switches traffic to a backup link. VLL FRR is only supported by the Martini modes.
Perform the following configurations on the PEs.
Procedure
l Configure primary and secondary PWs for the Martini VLL.
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
b. Run mpls l2vpn
The MPLS L2VPN view is displayed.

c. Run quit

d. Run interface interface-type interface-number
The PE devices to which CE device is dual-homed must use a main interface as the
AC interface.
e. Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ tunnel-
policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ] | mtu
mtu-value ] *
The primary PW is configured.

f. (Optional) Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id
[ tunnel-policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ]
| mtu mtu-value ] * secondary
The secondary PW is configured.
If a CE device is single-homed to a PE device, configure primary and secondary

PWs. If a CE device is dual-homed to two PE devices, configure the primary PW on
each PE device.
Primary and secondary PWs must have different VC IDs.
----End
11.7.5.2 (Optional) Configuring Fast Fault Notification - OAM Mapping
Context
OAM mapping expedites the fault detection and notification on the AC end. OAM mapping
can be configured on various types of links. To configure OAM mapping on Ethernet links,
the PE and CE devices must support the Ethernet OAM function.
Choose either of the following procedures to configure OAM mapping according to the AC
types.
Procedure
The view of the AC interface is displayed.
Step 3 Run mpls l2vpn oam-mapping 3ah
The fault mapping between the AC and the PW is enabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l The PW need be configured in homogeneous interworking mode when the AC is an Ethernet.

Otherwise, the use device may learn a wrong outbound interface according to ARP.
l Before running the mpls l2vpn oam-mapping 3ah command, you need configure Ethernet OAM on
the AC link. For details, refer to "EFM Configuration" in the Huawei
Routers Configuration Guide - Reliability.
l If the mpls l2vpn oam-mapping command is configured, run the display mpls l2vc interface
command to check the VC status. In the command output, "Local AC OAM State" indicates the
status of the AC link; if the mpls l2vpn oam-mapping command is not configured, run the display
mpls l2vc interface command to check the VC status. In the command output, "Local AC OAM
State" is always Up, and has no relationship with the AC link status.
----End
11.7.5.3 (Optional) Configuring BFD for PW
Context
BFD for PW is recommended because it speeds up fault detection.
Procedure
For details, see the following topics.
l 12.8.5 Configuring Static BFD for PWs
NOTE
l BFD for PW on both PEs at the two ends must be configured or deleted simultaneously. Otherwise,
the statuses of PWs on the PEs are inconsistent.
l To monitor statuses of tunnels that carry PWs, configure BFD for tunnel. For detailed
configurations, see "MPLS LDP Configuration" and "MPLS TE Configuration" in Huawei
Routers Configuration Manual MPLS.
11.7.5.4 (Optional) Configuring a Revertive Switchover Policy
Context
Revertive switching policies are classified into the following types:
l Immediate revertive switchover: When the primary PW recovers from a fault, the local
PE switches traffic back to the primary PW immediately and notifies the peer PE on the
secondary PW of the fault. In FRR mode, the local PE notifies the peer PE on the
secondary PW of the recovery after a delay of resume-time. In PW redundancy master/
slave mode, the parameter resume-time is not supported.
This revertive switchover applies to scenarios in which users hope traffic to be restored
as soon as possible.
l Delayed revertive switchover: When the primary PW recovers from a fault, traffic is
switched back to the primary PW after a period specified by delay-time. After traffic is
switched back, the local device immediately notifies the peer device on the secondary
PW of the fault. If resume-time is configured in FRR mode, the local device notifies the
peer device on the secondary PW of the recovery after a delay of resume-time.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On a large-scale network, packet loss caused by incomplete route convergence may

occur during the switchback. To prevent this problem, configure traffic to be switched
back after a delay.
l None revertive switchover: When the primary PW recovers from a fault, traffic is not
switched back to the primary PW until the secondary PW becomes faulty.
If you do not want traffic to be frequently switched between the primary and secondary
PWs, you can use the non-revertive switchover.
By default, the delayed revertive switchover is performed.
A revertive switchover policy is configured on a PE. In asymmetric networking, if the active

PW is faulty, the PE to which a CE is connected through a single link switches traffic. When
the active PW is restored, configure a revertive switchover policy on this PE. The PE then
processes traffic based on the configured revertive switchover policy.
Perform the following operations on the PE (where traffic is switched) to which the CE is
connected through a single link.
Procedure
Step 3 Run mpls l2vpn reroute { { delay delay-time | immediately } [ resume resume-time ] |
never }
The revertive switchover policy is configured.
For an asymmetric networking with ACs of the Ethernet type, if the Ethernet OAM function
is configured on the PE interface connected to a CE, and a revertive switching policy is also
configured, do not set resume-time to 0 seconds. Set resume-time to 1 second or longer.
NOTE
On the network where CEs are asymmetrically connected to PEs, the secondary PW cannot transmit data
when the primary and secondary paths work normally. On the CE in the dual-homed site, if the interface
of the secondary PW borrows the IP address of the interface of the primary PW, you cannot configure
revertive switchover.
----End
11.7.5.5 Verifying the VLL FRR Configuration
Context
After configuring VLL FRR, you can check information about local and remote PWs, BFD
sessions, and L2VPN forwarding. You can also run the manual-set pw-ac-fault command to
set faults on a PW to verify whether the switchover between the primary and secondary PWs
is normal.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Run the manual-set pw-ac-fault command on the primary PW to set faults on it to
verify whether the switchover between the primary and secondary PWs is normal.
command to check information about the local end of the Martini VC.
l Run the display mpls l2vc remote-info [ vc-id ] command to check information about
the remote end of the Martini VC.
l Run the display bfd session pw interface interface-type interface-number [ secondary ]
[ verbose ] command to check information about the BFD session.
l Run the display mpls l2vpn forwarding-info [ vc-label ] interface interface-type
interface-number command to check forwarding information about the L2VPN.
l Run the display mpls l2vc oam-mapping [ interface interface-type interface-number ]
command to check OAM mapping between ACs and PWs.
----End
11.7.6 Configuring the Access of VLL to L3VPN

This section describes how to configure VLLs to access L3VPN. To achieve.
11.7.6.1 Before You Start
Applicable Environment
As shown in Figure 11-18, to allow a user to access the public network or an MPLS L3VPN
bearer network through an MPLS L2VPN access network, the carrier can deploy a VLL to
connect the user to the public network or the MPLS L3VPN.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-18 Networking diagram of connecting a VLL to an L3VPN
NPE1 NPE2
Bearernetwork
Access Access
MPLS L3VPN
network 1 network 2
UPE1 UPE2
Logical link between

CE and NPE CE2
CE1
VLL Tunnel
MPLS L3VPN
Before configuring a VLL to access an L3VPN, complete the following tasks:
l Connecting interfaces and configuring their physical parameters so as to make their

physical layer Up
l Enabling an IGP on the MPLS access network to implement IP connectivity
l Enabling MPLS L2VPN on UPEs and NPEs
l Creating L2VPN tunnels between UPEs and NPEs
l Creating LDP sessions between NPEs and UPEs
l Creating remote LDP sessions if NPEs and UPEs are not connected directly
l Enabling an IGP on the MPLS bearer network to implement IP connectivity
l Configuring basic functions of L3VPN on NPEs

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Data Preparation
To configure a VLL to access an L3VPN, you need the following data.
No. Data
1 VE interface number
2 VE-Group number
3 Martini VLL: Destination IP address of the L2VC, VC ID, and VC Type
11.7.6.2 Creating an L2VE Interface
Context
Perform the following steps on NPEs. This part describes how to configure an L2VE interface
that terminates the L2VPN, and how to bind the L2VE interface to the relevant VE group.
Procedure
Step 2 Run interface virtual-ethernet interface-number
Step 3 Run ve-group ve-group-id l2-terminate
The VE interface is set to an L2VE interface that terminates VLL, and the interface is bound
to a VE-Group.
----End
11.7.6.3 Creating an L3VE Interface
Context
Perform the following steps on NPEs. This part describes how to configure an L3VE interface
that terminates the L3VPN, and how to bind the L3VE interface to the relevant VE group.
Procedure
Step 2 Run interface virtual-ethernet interface-number
Step 3 Run ve-group ve-group-id l3-access

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The VE interface is set to an L3VE interface that accesses the MPLS L3VPN, and it is bound
to a VE-Group.
Step 4 (Optional) Run either of the following commands:

l Run l3ve track pw-state
Associates the L3VE interface state with the PW state.
In the L2VPN access L3VPN solution, if the primary and secondary PWs have been
established and corresponding L3VE interfaces have gone Up when the primary RSG
recovers, the downstream traffic may switch back to the primary RSG. However, if the
downstream traffic switches back to the primary RSG before the primary/secondary PW
switchover is complete, the downstream traffic may be temporarily dropped. To solve
this problem, run the l3ve track pw-state command to associate the L3VE interface
status with the PW status.
This configuration is mainly used in dynamic PW scenarios.
l Run l3ve track oam-state
Associates the L3VE interface state with the OAM state.
In L2VPN accessing L3VPN scenarios in which PW protection is configured, if OAM
(BFD, MPLS OAM, or MPLS-TP OAM) detects that services are interrupted between an
AGG and a CSG, OAM does not trigger the L3VE interface to withdraw reverse routes.
Therefore, reverse traffic is still forwarded along the faulty PW until route convergence
is complete, which causes traffic loss. To resolve this problem, run the l3ve track oam-
state command to enable the association between the L3VE interface status and the
OAM status.
This configuration is mainly used in static PW scenarios.
----End
11.7.6.4 Associating the L2VE Interface with a VLL
Context
Perform the following steps on NPEs. This part describes how to associate an L2VE interface
with a Martini VLL or an SVC VLL. At present, an L2VE interface can only be bound to a
Martini VLL or an SVC VLL.
Procedure
l Configure the Martini VLL.
a. Run system-view

b. Run mpls l2vpn

c. Run quit

d. Run interface virtual-ethernet interface-number.subinterface-number
The L2VE sub-interface view is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
At present, only the L2VE sub-interface can be configured with L2VPN. The VC
type of the Martini VLL for the VE sub-interface is VLAN.
e. Run dot1q termination vid low-pe-vid
Setting the single VLAN ID for Dot1q termination on a sub-interface.
f. Run mpls l2vc ip-address vc-id [ [ control-word | no-control-word ] | [ raw |
tagged ] | tunnel-policy policy-name ] *
A Martini VLL is created.
The tunnel policy for a Martini VLL defaults to LSP and no load balancing is
performed. If a tunnel of another type is needed, you can specify tunnel-policy
policy-name to apply the corresponding tunnel policy.
To create a Martini VLL, you need to specify the IP address and VC ID of the
destination PE. The VC IDs of PEs at both ends of the VC must be consistent.
l Configure the SVC VLL.
a. Run system-view
b. Run mpls l2vpn
The MPLS L2VPN is enabled.
c. Run quit
d. Run interface virtual-ethernet interface-number.subinterface-number
The L2VE sub-interface view is displayed.
e. Run dot1q termination vid low-pe-vid
f. Run mpls static-l2vc { { destination ip-address | pw-template pw-template-name
vc-id } * transmit-vpn-label transmit-label-value receive-vpn-label receive-label-
value [ [ tunnel-policy tnl-policy-name ] | [ { control-word | no-control-word } ] |
[ { raw | tagged } ] | [ secondary ] ]*
A static VC is created.
NOTE
The parameters raw and tagged are needed only for the Ethernet link.
----End
11.7.6.5 Configuring the Access of a User to L3VPN
Context
Perform the following steps on NPEs.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 2 Run interface virtual-ethernet interface-number.subinterface-number
The L3VE interface view is displayed.
At present, only the L2VE sub-interface can be configured with L2VPN.
Step 3 Run dot1q termination vid low-pe-vid
The L3VE interface is associated with a VPN instance.
An IP address is configured for the L3VE interface.
NOTE
The IP address is a private network address of MPLS L3VPN.
----End
11.7.6.6 Verifying the configuration of Martini VLL to Access L3VPN
Context
After configuring a Martini VLL to access L3VPN successfully, you can view the binding
relationship between VE interfaces and the VE group, and information about the Martini
VLL.
Procedure
l Run the display virtual-ethernet ve-group [ ve-group-id | slot slot-id ] command to
check the binding relationship between VE interfaces and the VE-Group.
command to check information about a Martini VLL.
l Run the display vll ccc [ ccc-name | type { local | remote } ] command to check the
status of the local CCC.
----End
11.7.7 Configuring and Applying a Tunnel Policy

You also need to configure tunnel policies when VLL services need to be transmitted over TE
tunnels or when VLL services need to be load balanced among multiple tunnels to fully use
network resources.
Context
Layer 2 data on the VLL network is transmitted over tunnels. By default, LSP tunnels are
used to transmit data, and each service is transmitted by only one LSP tunnel.
If the default tunnel configuration cannot meet VLL service requirements, apply tunnel
policies to VLLs. You can configure either of the following types of tunnel policies:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPN data transmission or select multiple tunnels for load balancing.
guarantee for a VPN.
NOTE
CCC VLL does not support tunnel policies.
Before configuring and applying a tunnel policy, complete the following task:
Creating a tunnel (an LSP, a GRE, or an MPLS TE tunnel) to transmit VLL services
For details on how to create an LSP tunnel , a GRE, and a TE tunnel, see MPLS LDP
Enterprise Routers Configuration Guide - MPLS, GRE Configuration and MPLS TE
Perform the following operations on the PE devices that need to use a tunnel policy:
Procedure
By default, no tunnel policy is configured. LSP tunnels are used to transmit VLL data and
each VLL service is transmitted over one LSP tunnel.
1. Run system-view
4. Run tunnel select-seq { cr-lsp | gre | lsp } * load-balance-number load-balance-
number
1. Run system-view
The tunnel interface view of the MPLS TE tunnel is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

5. Run quit
The TE tunnel is bound to a specified tunnel policy.
NOTE
If down-switch is specified in the command, the system selects available tunnels in an order of
LSP, CR-LSP, and GRE when the bound tunnels are unavailable.

l In Martini VLL Mode
Perform the following operations on the AC interfaces of the PE devices:
– Run mpls l2vc { ip-address | pw-template pw-template-name } * vc-id tunnel-
policy policy-name [ [ control-word | no-control-word ] | [ raw | tagged ] | mtu
mtu-value | secondary ] *
A Martini VLL connection is created and the tunnel policy is applied to the
connection.
l In SVC VLL Mode
Perform the following operations on the AC interfaces of the PE devices:
– Run mpls static-l2vc { { destination ip-address | pw-template pw-template-name
vc-id } * | destination ip-address [ vc-id ] } transmit-vpn-label transmit-label-
value receive-vpn-label receive-label-value tunnel-policy tnl-policy-name
[ [ control-word | no-control-word ] | [ raw | tagged ] | secondary ] *
An SVC VLL connection is created and the tunnel policy is applied to the
connection.
----End

After configuring a tunnel policy and applying it to a VLL, you can check information about
the tunnel policy applied to the VLL and tunnels in the system.
l Run the display interface tunnel interface-number command to check detailed
information about a specified tunnel interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

l Run the display mpls static-l2vc [ vc-id | interface interface-type interface-number |
state { down | up } ] command to check tunnel information about the SVC VLL.
l Run the display mpls l2vc [ vc-id | interface interface-type interface-number | remote-
info [ vc-id | verbose ] | state { down | up } ] command to check tunnel information
about the Martini VLL.
11.7.8 Configuring the Alarm Report Function
Context
You can configure the alarm report function, which help you obtain real-time running status
of the VLL network and facilitate operation and maintenance.
Procedure
l Configure alarm report for the CCC VLL.
a. Run system-view

b. Run snmp-agent trap enable feature-name l2vpn trap-name { hwcccvcdown |
hwcccvcup }
Alarm report for the CCC VLL is enabled.
By default, alarm report for the CCC VLL is disabled.

l Configure alarm report for the Martini VLL.
a. Run system-view

b. Run snmp-agent trap enable feature-name l2vpn trap-name { hwpwvcbackup |
hwpwvcdeleted | hwpwvcdown | hwpwvcstatuschange | hwpwvcswitchptow |
hwpwvcswitchwtop | hwpwvcup }
Alarm report for the Martini VLL is enabled.
By default, alarm report for the Martini VLL is disabled.

l Configure alarm report for the SVC VLL.
a. Run system-view

b. Run snmp-agent trap enable feature-name l2vpn trap-name { hwsvcdeleted |
hwsvcdown | hwsvcswitchptow | hwsvcswitchwtop | hwsvcup }
Alarm report for the SVC VLL is enabled.
By default, alarm report for the SVC VLL is disabled.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

After completing the alarm report for VLL, you can run the following command to check
whether alarm report is enabled.
l Run the display snmp-agent trap feature-name l2vpn all command to check whether
alarm report is enabled for the L2VPN module.
11.8 Maintaining VLL

This section describes how to maintain VLL, including collecting, querying, and clearing
VLL statistics, checking VLL network connectivity, and resetting BGP TCP connections.
11.8.1 Monitoring the Running Status of VLL
Context
This section describes how to monitor the VLL running status by viewing the VLL
connection information.
During the routine maintenance, you can run the following commands in any view to know
the running status of VLL.
Procedure
l Run the display vll ccc [ ccc-name | type local ] command to check information about
the CCC connection.
to check information about the SVC VLL connection.
command to check information about the local Martini VLL connection on the PE.
l Run the display mpls l2vpn label-space command to check information about label
space distribution and different types of labels in the label cache.
l Run the display mpls l2vpn vpws [ interface interface-type interface-number
[ verbose ] ] command to check information about VPWS service.
----End
11.8.2 Checking Connectivity of the VLL Network
Prerequisites
After a VLL network is established, perform a virtual circuit connectivity verification
(VCCV) to check connectivity of the VLL network.
VCCV is an end-to-end fault detection and diagnosis mechanism which includes VCCV ping
and VCCV tracert. VCCV ping is a tool for manually testing VC connectivity; while VCCV
tracert is tool for manually locating an abnormal node on a PW.
VCCV supports the following modes: control word channel mode and Label Alert mode. By
default, VCCV in Label Alert mode is enabled. Before using the control word channel mode,

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
you need to run the control-word command to enable the control word function. After that,
VCCV in control word channel mode can be used.
NOTE
When locating the fault on the VLL network in Martini mode, you can use either VCCV in control word
channel mode or VCCV in normal mode.
Procedure
l Check the connectivity of the VLL network.
Checking the connectivity of the VLL network in Martini mode.
– Control word channel
ping vc pw-type pw-id [ -c echo-number | -m time-value | -s data-bytes | -t timeout-
value | -exp exp-value | -r reply-mode | -v ] * control-word [ remote remote-ip-
address peer-pw-id | draft6 ] * [ ttl ttl-value ] [ uniform ]
value | -exp exp-value | -r reply-mode | -v ] * control-word remote remote-ip-
address peer-pw-id sender sender-address [ ttl ttl-value ] [ uniform ]
– Label Alert channel
value | -exp exp-value | -r reply-mode | -v ] * label-alert [ no-control-word ]
[ remote remote-ip-address | draft6 ] * [ uniform ]
– Normal mode
value | -exp exp-value | -r reply-mode | -v ] * normal [ no-control-word ] [ remote
remote-ip-address peer-pw-id ] [ ttl ttl-value ] [ uniform ]
l Locate the fault on the VLL network.
Locating the fault on the VLL network in Martini mode.
tracert vc pw-type pw-id [ -exp exp-value | -f first-ttl | -m max-ttl | -r reply-mode | -
t timeout-value ] * control-word [ draft6 ] [ full-lsp-path ] [ uniform ]
t timeout-value ] * control-word remote remote-ip-address [ ptn-mode | full-lsp-
path ] [ uniform ]
t timeout-value ] * control-word remote remote-pw-id draft6 [ full-lsp-path ]
[ uniform ]
t timeout-value ] * label-alert [ no-control-word ] [ remote remote-ip-address ]
[ full-lsp-path ] [ draft6 ] [ uniform ]
– Normal mode
t timeout-value ] * normal [ no-control-word ] [ remote remote-ip-address ] [ full-
lsp-path ] [ draft6 ] [ uniform ]
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
11.9 Configuration Examples for VLL

This section describes VLL configuration examples including the networking requirements,
configuration notes, and configuration roadmap.
11.9.1 Example for Configuring a Local CCC Connection

As shown in Figure 11-19, sites of an enterprise at different geographical locations connect to
a PE on the ISP network through CE1 and CE2. To simplify configuration, the enterprise
hopes that the two CEs communicate with each other like on a LAN. That is, data packets of
each CE traverse the ISP network without being modified by the PE. The enterprise will not
increase sites in the future and wants to use exclusive VPN resources on the ISP network to
protect data security.
To meet requirements of the enterprise, create a local CCC connection to enable CE1 and CE2
to exchange Layer 2 information directly.
Figure 11-19 Local CCC connection

CE 2
GE1/0/0
100.1.1.2/24
CCC local
connection
CE 1
GE 2/0/0
PE
GE 1/0/0 GE 1/0/0
100.1.1.1/24
Loopback1
1.1.1.9/32
The enterprise hopes that the two CEs communicate with each other like on a LAN. This
requirement can be satisfied by a VLL solution. Because the enterprise will not increase sites
in the future and the two CE1 connected to the same PE, a local CCC connection can be set
up between the CEs to meet the customer requirements.
1. Configure the basic MPLS capabilities on the PE and enable the MPLS L2VPN.
Enabling MPLS L2VPN is the prerequisite for VLL configuration.
2. Create a local connection between CE1 and CE2 on PE. The local CCC connection is
bidirectional, so only one connection is required.
Procedure
Step 1 Configure the CEs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure CE1.
# Configure CE2.
Step 2 Configure PE.

# Configure the LSR ID and enable MPLS and MPLS L2VPN.
[Huawei] sysname PE
[PE] interface loopback 1
[PE-LoopBack1] ip address 1.1.1.9 32
[PE-LoopBack1] quit
[PE] mpls lsr-id 1.1.1.9
[PE] mpls
[PE-mpls] quit
[PE] mpls l2vpn
[PE-l2vpn] quit
# Create a local connection between CE1 and CE2.

[PE] ccc ce1-ce2 interface gigabitethernet 1/0/0 out-interface gigabitethernet
2/0/0

# After completing the configuration, check the CCC information on the PE. The command
output shows that a local CCC connection has been set up and the status is Up.
[PE] display vll ccc
total ccc vc : 1
local ccc vc : 1, 1 up
remote ccc vc : 0, 0 up
name: ce1-ce2, type: local, state: up,

intf1: GigabitEthernet1/0/0 (up),access-port: false
intf2: GigabitEthernet2/0/0 (up),access-port: false

VC last up time : 2010/07/24 12:31:31
VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds
# Run the display l2vpn ccc-interface vc-type all command. The command output shows
that the VC type is ccc and the VC status is Up.
[PE] display l2vpn ccc-interface vc-type all
Total ccc-interface of CCC : 2
up (2), down (0)
Interface Encap Type State VC Type
GigabitEthernet1/0/0 ethernet up ccc
GigabitEthernet2/0/0 ethernet up ccc
[CE1] ping 100.1.1.2


Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return
l Configuration file of PE
#
sysname PE
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
ccc ce1-ce2 interface GigabitEthernet1/0/0 out-interface GigabitEthernet2/0/0
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
11.9.2 Example for Configuring a VLL Connection in SVC Mode

The MPLS network of an ISP provides the L2VPN service for sites of two users. Each user
has two sites at fixed locations, which connect to the MPLS network through CE1 and CE2.
The users hope that hosts in different sites can communicate at Layer 2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-20 SVC VLL

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE1/0/0
10.1.1.2/24 10.2.2.2/24
PE1 PE2
GE2/0/0 GE 1/0/0
GE1/0/0 10.1.1.1/24 P 10.2.2.1/24 GE2/0/0
SVC
GE1/0/0 connection GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
The users expect direct Layer 2 communication between their sites. VLL can be configured to
satisfy this requirement. The two PEs have fixed users, so signaling information can be
manually configured (SVC mode).
1. Configure an IGP on the MPLS backbone network to implement IP interworking.
2. Configure basic MPLS functions and LDP on the MPLS backbone network and set up an
LDP LSP tunnel. The LDP LSP tunnel is used as a dedicated tunnel to transmit data of
private networks on the public network.
3. On the PEs, enable MPLS L2VPN, create a static VC connection, and manually
configure VC labels. Enabling MPLS L2VPN is the prerequisite for VLL configuration,
and creating a static VC connection is the most important step in configuring VLL of the
SVC mode.
Procedure
Step 1 Configure IP addresses to each interface according to Figure 11-20.
# Configure CE1. The configuration on PE1, P, PE2, and CE2 is similar to the configuration
on CE1 and is not mentioned here.
[CE1-GigabitEthernet1/0/0] ip address 100.1.1.1 255.255.255.0
Step 2 Configure IGP on the MPLS backbone network. (In this example, OSPF is used.)
When configuring OSPF, advertise the 32-bit addresses of loopback interfaces on PEs and P.
The loopback interface addresses are the LSR IDs.
# Configure PE1. The configuration on P and PE2 is similar to the configuration on PE1 and
[PE1] ospf 1
[PE1-ospf-1] area 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-ospf-1] quit
Step 3 Configure basic MPLS functions and LDP on the MPLS backbone network. That is, set up
LDP LSPs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure the P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After completing the configuration, LDP sessions are set up between PE1 and P, and between
PE2 and P. Run the display mpls ldp session command. The command output shows that the
status of the LDP session is Operational.
Take the display on PE1 for example:

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Enable MPLS L2VPN and create static VCs on PEs.

# Configure PE1: Create a static VC on GE1/0/0, which is connected to CE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] mpls l2vpn

[PE1-l2vpn] quit
[PE1-GigabitEthernet1/0/0] mpls static-l2vc destination 3.3.3.9 transmit-vpn-
label 100 receive-vpn-label 200
# Configure PE2: Create a static VC on GE2/0/0, which is connected to CE2.

[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2-GigabitEthernet2/0/0] mpls static-l2vc destination 1.1.1.9 transmit-vpn-

# View the L2VPN connection information of the SVC on the PE. The command output
shows that a static L2VC connection is established.
# Take PE1 for example.
[PE1] display mpls static-l2vc interface gigabitethernet 1/0/0
*Client Interface : GigabitEthernet1/0/0 is up
AC Status : up
VC State : up
VC ID : 0
VC Type : Ethernet
Destination : 3.3.3.9
Transmit VC Label : 100
Receive VC Label : 200
Label Status : 0
Token Status : 0
Control Word : Disable
VCCV Capabilty : alert ttl lsp-ping bfd
Link State : up
Tunnel Policy : --
PW Template Name : --
Main or Secondary : Main
Access-port : false
NO.0 TNL Type : lsp , TNL ID : 0x3
Backup TNL Type : lsp , TNL ID : 0x0
Create time : 0 days, 0 hours, 4 minutes, 31 seconds
UP time : 0 days, 0 hours, 2 minutes, 14 seconds
Last change time : 0 days, 0 hours, 2 minutes, 14 seconds
VC last up time : 2012/08/16 19:05:13
CKey : 4
NKey : 3
Service Class : --
Color : --
DomainId : --
Domain Name : --
# Run the display l2vpn ccc-interface vc-type static-vc up command, you can view
information about an interface on which the VC Type is displayed as static-vc and State is
Up.. Take the display on PE1 for example.
[PE1] display l2vpn ccc-interface vc-type static-vc up
Total ccc-interface of SVC VC: 1
up (1), down (0)
Interface Encap Type State VC Type
GigabitEthernet1/0/0 ethernet up static-vc

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[CE1] ping 100.1.1.2
0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
mpls ldp
#
mpls static-l2vc destination 3.3.3.9 transmit-vpn-label 100 receive-vpn-
label 200
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 10.1.1.2 255.255.255.0

mpls
mpls ldp
#
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return

#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls ldp
#
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp
#
mpls static-l2vc destination 1.1.1.9 transmit-vpn-label 200 receive-vpn-
label 100
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.2.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
11.9.3 Example for Configuring a VLL Connection in Martini

Mode
As shown in Figure 11-21, the MPLS network of an ISP provides the L2VPN service for
users. Many users connect to the MPLS network through PE1 and PE2, and users on the PEs

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
change frequently. A proper VPN solution is required to provide secure VPN services for
users and to simplify configuration when new users connect to the network.
Figure 11-21 Martini VLL

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE1/0/0
10.1.1.2/24 10.2.2.2/24
PE1 PE2
GE2/0/0 GE 1/0/0
GE1/0/0 10.1.1.1/24 P 10.2.2.1/24 GE2/0/0
Martini
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Because users on the PEs change frequently, manual configuration is inefficient and may
cause configuration errors. In this scenario, the two PEs can set up a remote LDP connection
and use the LDP protocol to synchronize user information (VC IDs). This implementation is
the Martini mode.
1. Configure an IGP on the PE and P devices on the backbone network to ensure

reachability between them, and enable MPLS.
2. This example uses the default tunnel policy to set up an LSP tunnel. The LSP tunnel is
used as a dedicated tunnel to transmit data of private networks on the public network.
3. Set up a remote LDP session between the PEs to exchange VC labels between the PEs.
4. Enable MPLS L2VPN and create VC connections on the PEs. Enabling MPLS L2VPN
is the prerequisite for VLL configuration.
Procedure
Step 1 Configure IP addresses for interfaces on the CE, PE and P devices according to Figure 11-21.
Step 2 Configure IGP on the MPLS backbone network. (In this example, OSPF is used.)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When configuring OSPF, advertise the 32-bit addresses of loopback interfaces on PEs and P.
The loopback interface addresses are the LSR IDs.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
Step 3 Configure the basic MPLS capabilities and MPLS LDP on the MPLS network.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure the P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
Step 4 Set up a remote LDP session between PEs.
# Configure PE1.
# Configure PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After the configuration, run the display mpls ldp session command on PE1 to view the
establishment of the LDP session. You can find that an LDP session is set up between PE1
and PE2.
Take the display on PE1 for example.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 5 Enable MPLS L2VPN and create VCs on the PEs.

# Configure PE1: Create a VC on GE1/0/0, which is connected to CE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1-GigabitEthernet1/0/0] mpls l2vc 3.3.3.9 101
# Configure PE2: Create a VC on GE2/0/0, which is connected to CE2.

[PE2] mpls l2vpn
[PE2-l2vpn] quit

# View the L2VPN connection information on the PEs, and you can see that an L2VC is set
up and is in Up state.
# Take the display on PE1 for example.
*client interface : GigabitEthernet1/0/0 is
up
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 101
VC type : Ethernet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VCCV State : up
link state : up
tunnel policy name : --
Access-port : false
NO.0 TNL type : lsp , TNL ID : 0x5
VC last up time : 2011/09/26 15:29:03
CKey : 5
NKey : 4
Service Class : --
Color : --
DomainId : --
Domain Name : --

# Take the display on CE1 for example.
[CE1] ping 100.1.1.2
0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 3.3.3.9
#
mpls l2vc 3.3.3.9 101
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls ldp
#
remote-ip 1.1.1.9
#
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp
#
mpls l2vc 1.1.1.9 101
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.2.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
11.9.4 Example for Configuring Inter-AS Martini VLL (Option A)

users. PE1 becomes to AS 100 and PE2 belongs to AS 200. Many users connect to the MPLS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-22 Inter-AS Martini VLL (Option A)
IP/MPLS IP/MPLS
backbone network backbone network
AS 100 AS 200
Loopback0 Loopback0 Loopback0 Loopback0
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE2/0/0 GE1/0/0
10.1.1.1/24 GE2/0/0 GE1/0/0 30.1.1.2/24
GE1/0/0 GE2/0/0
PE1 10.1.1.2/24 ASBR-PE1 ASBR-PE2 30.1.1.1/24 GE2/0/0 PE2
GE1/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
The PEs connect to different ASs (AS100 and AS200) of the ISP, so an inter-AS VPN
solution is required. To simplify configuration when new users connect to the network,
configure Martini VLL using inter-AS Option A.
1. Run an IGP protocol on the backbone network so that the devices in the same AS can
2. Configure the basic MPLS capabilities on the backbone network and set up dynamic
LSPs between PEs and ASBR-PEs in the same AS. If PEs and ASBR-PEs are not
directly connected, set up a remote LDP session.
3. Establish MPLS L2VC connections between the PEs and ASBR-PEs in the same AS.
Procedure
Step 1 Configure IP addresses for interfaces according to Figure 11-22.
# Configure CE1. The configuration on PE1, ASBR-PE1, ASBR-PE2, PE2, and CE2 is
similar to the configuration on CE1 and is not mentioned here.
Step 2 Configure an IGP protocol on the MPLS backbone network.

PEs and ASBR-PEs on the backbone network can communicate with each other by using IGP.
In this example, IS-IS is used as IGP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1. The configuration on ASBR-PE1, ASBR-PE2, and PE2 is similar to the
configuration on PE1 and is not mentioned here.
[PE1] isis 1
[PE1-isis-1] quit
After the configuration, the ASBR and PE in the same AS can establish an IS-IS adjacency.
Run the display isis peer command, and you can see that the IS-IS adjacency is in Up state,
and the PEs can learn each other's loopback address.
[PE1] display isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI

-------------------------------------------------------------------------------
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 23s L1(L1L2) 64
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 22s L2(L1L2) 64
Total Peer(s): 2
The ASBR and PE in the same AS can ping each other.

[PE1] ping 2.2.2.9

0.00% packet loss
Step 3 Enable MPLS and configure dynamic LSPs.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
After this step, an LSP is established between the PE and ASBR-PE in the same AS.
Take the display on ASBR-PE1 for example.
[ASBR-PE1] display mpls ldp session

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Configure the MPLS L2VC connection.

Configure the L2VC connection on the PE and ASBR-PE and connect the PE to the CE.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[ASBR-PE1] mpls l2vpn
[ASBR-PE1-l2vpn] quit
[ASBR-PE1-GigabitEthernet2/0/0] mpls l2vc 1.1.1.9 100
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit

# Display information about the L2VPN connection on PE1. You can see that an L2VC has
been set up and the VC status is Up.
# Take the display on PE1 and ASBR-PE2 for example.
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VCCV State : up
link state : up
Access-port : false
VC last up time : 2010/10/09 19:26:37
CKey : 16
NKey : 15
Service Class : --
Color : --
DomainId : --
Domain Name : --
[ASBR-PE2] display mpls l2vc interface gigabitethernet 1/0/0
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet
VCCV State : up

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
link state : up
Access-port : false
VC last up time : 2010/10/09 19:26:37
CKey : 17
NKey : 18
Service Class : --
Color : --
DomainId : --
Domain Name : --

# Take the display on CE1 for example.
[CE1] ping 100.1.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
mpls l2vc 2.2.2.9 100
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return
l Configuration file of ASBR-PE1
#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
mpls l2vc 1.1.1.9 100
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
mpls l2vc 4.4.4.9 100
#
ip address 30.1.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return

#
sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
mpls l2vc 3.3.3.9 100
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
11.9.5 Example for Configuring Martini VLL FRR

(Asymmetrically Connected CEs)
users. All users connect to the MPLS network through PE1, PE2, and PE3, and new sites will
be added in the future. A proper VPN solution is required to provide secure VPN services for
users and to simplify configuration when new users connect to the network. In addition, this
solution must ensure highly stable communication between CE1 and CE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-23 Martini VLL FRR (asymmetrically connected CEs)

Loopback1
4.4.4.9/32
GE2/0/0
GE1/0/0
172.3.1.1/24 Loopback1
172.2.1.2/24
1 3.3.3.9/32
ck
p ba 32 P
o / GE2/0/0
Lo .1.9
1.1 172.2.1.1/24 GE1/0/0
172.3.1.2/24 PE3
MPLS TE Tunnel
PE1
Loopback1 GE2/0/0
MPL 2.2.2.9/32
S LSP
GE1/0/0
GE3/0/0
172.1.1.1/24
GE1/0/0
GE2/0/0
172.1.1.2/24
GE1/0/0 PE2
192.168.1.2/24 GE1/0/0
192.168.2.2/24 sub 192.168.1.3/24
CE1 GE2/0/0
192.168.2.3/24
GE2/0/0
192.168.3.1/24 CE2
VLL FRR can be configured to ensure highly stable communication between CE1 and CE2. If
a few sites will be added in the future, Martini VLL FRR can be configured.
1. Configure OSPF on the backbone network to implement interworking between backbone
devices.
2. Set up an MPLS TE tunnel between PE1 and PE3, which will be used by the primary
PW.
Set up an MPLS LSP tunnel between PE1 and PE2, which will be used by the secondary
PW.
3. Configure a PW template on each PE to simplify the PW configuration. Configure a
tunnel policy to enable the primary PW to use the MPLS TE tunnel.
4. Configure BFD for PW between PE1 and PE2 and between PE1 and PE3 to quickly
detect a PW fault.
5. Configure Ethernet in the First Mile (EFM) between CE2 and PE2, and PE3 and CE2 to
detect link connectivity.
6. Enable OAM mapping on the PEs so that L2VPN traffic can be quickly switched to the
secondary PW. When fault on the primary PW is recovered, L2VPN traffic can be
switched back to the primary PW.
7. Configure association between EFM and interfaces on CE2. When EFM detects a PW
fault, the interface is logically Down, quickly switching traffic to a right forwarding path.
8. Set the revertive switchover policy to immediate switchover on PE1 to prevent data loss
because CE2 can quickly detect a PW fault.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Assign IP addresses to interfaces.
# Configure PE1. The configuration on P, PE2, PE3, CE1, and CE2 is similar to the
Step 2 Configure an IGP protocol on the MPLS backbone network so that the PE and P devices can
# Configure PE1. The configuration on P, PE2, and PE3 is similar to the configuration on PE1
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After completing the configuration, run the display ip routing-table command on each PE.
The command output shows that PE1 and PE2, and PE1 and PE3 have learned the routes to
each other's Loopback1 interface.
Step 3 Enable MPLS on backbone devices to set up an MPLS TE tunnel between PE1 and PE3 and
an LDP LSP between PE1 and PE2.
l Set up an MPLS TE tunnel between PE1 and PE3.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[P] mpls
[P-mpls] mpls te
[P-mpls] mpls rsvp-te
[P-mpls] quit
[P] ospf 1
[P-ospf-1] opaque-capability enable
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] mpls-te enable
[P-ospf-1] quit
[P-GigabitEthernet1/0/0] mpls te
[P-GigabitEthernet1/0/0] mpls rsvp-te
[P]interface gigabitethernet 2/0/0
# Configure PE3.
[PE3] mpls
[PE3-mpls] mpls te
[PE3-mpls] quit
[PE3] ospf 1
[PE3-ospf-1] area 0
[PE3-ospf-1] quit
l Set up an LDP LSP between PE1 and PE2.

# Configure PE1.
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After completing the configuration, run the display tunnel-info all command on the PEs. The
command output shows that an MPLS TE tunnel has been set up between PE1 and PE3, and
an LSP tunnel has been set up between PE1 and PE2.
[PE1] display tunnel-info all
----------------------------------------------------------------------
0x1 cr lsp 3.3.3.9 1
0x2 lsp 3.3.3.9 2
0x3 lsp 2.2.2.9 3
0x4 lsp 2.2.2.9 4
Step 4 Create a remote LDP session between PE1 and PE3.

When configuring a remote LDP session, specify the loopback interface address of the LDP
remote peer as the IP address.
NOTE
PE1 and PE2 in this example are directly connected; therefore, you do not need to configure a remote
LDP session between them.
# Configure PE1.
# Configure PE3.
[PE3] mpls ldp
[PE3-mpls-ldp] quit
After completing the configuration, run the display mpls ldp session command on the PEs.
The command output shows that the status of the remote LDP peer relationship is
Operational. This indicates that remote LDP session has been set up.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 5 Configure tunnel policies on the PEs.

# Configure PE1.
[PE1] tunnel-policy p1
[PE1-tunnel-policy-p1] tunnel select-seq cr-lsp load-balance-number 1
[PE1-tunnel-policy-p1] quit
# Configure PE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE3] tunnel-policy p1
[PE3-tunnel-policy-p1] tunnel select-seq cr-lsp load-balance-number 1
[PE3-tunnel-policy-p1] quit
Step 6 Use a PW template to create PWs on the PEs.

Create primary and secondary PWs on PE1. Create a PW on each of PE2 and PE3.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1] pw-template 1to2
[PE1-pw-template-1to2] peer-address 2.2.2.9
[PE1-pw-template-1to2] control-word
[PE1-pw-template-1to2] quit
[PE1-GigabitEthernet3/0/0] mpls l2vc pw-template 1to3 200 tunnel-policy p1
[PE1-GigabitEthernet3/0/0] mpls l2vc pw-template 1to2 201 secondary
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2-GigabitEthernet2/0/0] mpls l2vc pw-template 2to1 201
# Configure PE3.
[PE3] mpls l2vpn
[PE3-l2vpn] quit
[PE3-GigabitEthernet2/0/0] mpls l2vc pw-template 3to1 200 tunnel-policy p1
Step 7 Configure devices to ensure network connectivity.

Configure two default routes on CE2, specify GE1/0/0 and GE2/0/0 as outbound interfaces,
and assign preference to the route with GE1/0/0 as the outbound interface.
# Configure CE2.
preference 100
Step 8 Configure BFD for PW on the PEs.

# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd pe1tope3 bind pw interface gigabitethernet 3/0/0
[PE1-bfd-lsp-session-pe1tope3] discriminator local 100
[PE1-bfd-lsp-session-pe1tope3] discriminator remote 200

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-bfd-lsp-session-pe1tope3] min-tx-interval 100

[PE1-bfd-lsp-session-pe1tope3] min-rx-interval 100
[PE1-bfd-lsp-session-pe1tope3] commit
[PE1-bfd-lsp-session-pe1tope3] quit
[PE1] bfd pe1tope2 bind pw interface gigabitethernet 3/0/0 secondary
# Configure PE3.
[PE3] bfd
[PE3-bfd] quit
# Configure PE2.
[PE2] bfd
[PE2-bfd] quit
After completing the configuration, you can find that BFD sessions have been set up between
PE1 and PE2, and between PE1 and PE3. Run the display bfd session all command on each
PE. The command output shows that both BFD sessions are Up.

[PE1] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
100 200 --.--.--.-- Up S_PW(M) GigabitEthernet3/0/0
101 201 --.--.--.-- Up S_PW(S) GigabitEthernet3/0/0
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 2/0
Step 9 Enable the OAM mapping function.
Before enabling the OAM mapping function on the PEs, enable EFM on AC interfaces to
detect link connectivity.
1. Enable EFM to detect link connectivity.
# Configure PE2. The configuration on PE3 and CE2 is similar to the configuration on
[PE2] efm enable
[PE2-GigabitEthernet2/0/0] efm enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
After completing the configuration, run the display efm session all command on each
device. You can find that the status of the EFM protocol on each interface is detect. The
display on PE2 is used as an example:
[PE2] display efm session all
Interface EFM State Loopback
Timeout
----------------------------------------------------------------------
GigabitEthernet2/0/0 detect
--
2. Enable the OAM mapping function.
# Configure PE2.
[PE2-GigabitEthernet2/0/0] mpls l2vpn oam-mapping 3ah
# Configure PE3.
[PE3-GigabitEthernet2/0/0] mpls l2vpn oam-mapping 3ah
After completing the configuration, run the display mpls l2vc oam-mapping interface
command on each PE. The command output shows information about OAM mapping.
You can find that the AC OAM status is Up. The display on PE2 is used as an example:
[PE2] display mpls l2vc oam-mapping interface gigabitethernet 2/0/0
AC OAM
Info:
EOAM Type :
802.3ah
AC OAM State :
Up
OAM-mapping :
Enable
PSN
info:
VC-ID :
201
VC status :
Primary
Active State :
Active
Link State :
Up
BFD for PW :
Disable
BFD for LSP : 0 TunnelNum: 1 PSN State :
up
Step 10 Configure association between EFM and interfaces.
Configure association between EFM and interfaces on CE2. When EFM detects a PW fault,
the interface is logically Down.
# Configure CE2.
[CE2-GigabitEthernet1/0/0] efm trigger if-down
[CE2-GigabitEthernet2/0/0] efm trigger if-down

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 11 Configure the revertive switchover policy.

When the primary PW becomes faulty, GE1/0/0 on CE2 becomes Down. When the primary
PW recovers, GE1/0/0 on CE2 becomes Up. If traffic is not switched back to the primary PW
on PE1 immediately (delayed switchover is configured by default), data loss will occur.
# Configure PE1.
[PE1-GigabitEthernet3/0/0] mpls l2vpn reroute immediately

# After completing the configurations, run the display mpls l2vc interface command on PE1.
You can find that primary and secondary PWs have been set up, the VC status for both is Up,
the status of the primary PW is active, and the status of the secondary PW is inactive.
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 200
VC type : Ethernet
VCCV State : up
link state : up
local VCCV : cw alert ttl lsp-ping bfd
remote VCCV : cw alert ttl lsp-ping bfd
local control word : enable remote control word : enable
tunnel policy name : p1
PW template name : 1to3
Access-port : false
NO.0 TNL type : cr lsp, TNL ID : 0x1
VC last up time : 2013/12/20 20:13:46
CKey : 2
NKey : 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Service Class : --
Color : --
DomainId : --
Domain Name : --

session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 201
VC type : Ethernet
VCCV State : up
active state : inactive
link state : up
primary or secondary : secondary
Access-port : false
VC last up time : 2013/12/20 20:12:54
CKey : 4
NKey : 3
Service Class : --
Color : --
DomainId : --
Domain Name : --
reroute policy : immediately, resume 10 s

reason of last reroute : New LDP mapping message was received
time of last reroute : 0 days, 0 hours, 11 minutes, 12 seconds
delay timer ID : -- residual time :--

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
resume timer ID : -- residual time :--
# Run the display ip routing-table command on CE2. You can find that the outbound
interface on CE2 for the default route is GE1/0/0. This indicates that traffic is transmitted
along the primary path.
# The display on CE2 is used as an example:
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
0.0.0.0/0 Static 60 0 D 192.168.1.2

# CE2 can ping address 192.168.3.1 of CE1 successfully.

[CE2] ping 192.168.3.1

0.00% packet loss
# Set the status of GE1/0/0 on PE3 to Down manually.

[PE3-GigabitEthernet1/0/0] shutdown
# Run the display bfd session all command on PE1. The command output shows that the
BFD session of the primary PW is Down.
[PE1] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
100 200 --.--.--.-- Down S_PW(M) GigabitEthernet3/0/0
101 201 --.--.--.-- Up S_PW(S) GigabitEthernet3/0/0
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/1
# Run the display mpls l2vc interface command on PE1. You can find that the VC status of
the primary PW changes to Down, the status of the primary PW changes to inactive, and the
status of the secondary PW changes to active.
session state : down
AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 200

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VC type : Ethernet
local forwarding state : not forwarding
VCCV State : up
forwarding entry : not exist
link state : down
remote VCCV : none
local control word : enable remote control word : none
tunnel policy name : p1
Access-port : false
VC last up time : 2013/12/20 20:44:26
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --

session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 201
VC type : Ethernet
VCCV State : up

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
link state : up
primary or secondary : secondary
Access-port : false
VC last up time : 2013/12/20 20:12:54
CKey : 4
NKey : 3
Service Class : --
Color : --
DomainId : --
Domain Name : --
reroute policy : immediately, resume 10 s

reason of last reroute : New LDP mapping message was received
time of last reroute : 0 days, 0 hours, 11 minutes, 58 seconds
delay timer ID : -- residual time :--
resume timer ID : -- residual time :--
# Run the display interface gigabitethernet 1/0/0 command on CE2 to check interface
status. You can find that the Line protocol current state field is displayed as DOWN (EFM
down), indicating that PE3 has notified CE2 of the primary PW fault.
[CE2] display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Line protocol current state : DOWN (EFM down)
Description:...
Check the routing table on CE2. You can find that the outbound interface of the default route
has changed to GE2/0/0. This indicates that L2VPN traffic has been switched to the secondary
path.
to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
0.0.0.0/0 Static 100 0 D 192.168.2.2

# Remove the fault on GE1/0/0 on PE3 manually.

[PE3-GigabitEthernet1/0/0] undo shudown
# Check the routing table on CE2. You can find that the outbound interface of the default
route has changed to GE1/0/0. This indicates that L2VPN traffic has been switched back to
the primary path.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

to vpn-instance
------------------------------------------------------------------------------
Summary Count : 1
0.0.0.0/0 Static 60 0 D 192.168.1.2

----End
Configuration Files
#
sysname CE1
#
ip address 192.168.1.2 255.255.255.0
ip address 192.168.2.2 255.255.255.0 sub
#
ip address 192.168.3.1 255.255.255.0
#
return

#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
pw-template 1to2
peer-address 2.2.2.9
control-word
#
pw-template 1to3
control-word
#
mpls ldp
#
remote-ip 3.3.3.9
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
mpls l2vc pw-template 1to3 200 tunnel-policy p1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls l2vc pw-template 1to2 201 secondary

mpls l2vpn reroute immediately resume 10
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
destination 3.3.3.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
bfd pe1tope2 bind pw interface GigabitEthernet3/0/0
secondary
discriminator local
101
discriminator remote
201
min-tx-interval 100
min-rx-interval 100
commit
bfd pe1tope3 bind pw interface

discriminator local
100
200
min-tx-interval 100
min-rx-interval 100
commit
#
return
#
sysname P
#
mpls lsr-id 4.4.4.9
mpls
mpls te
mpls rsvp-te
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 172.3.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9
0.0.0.0
network 172.2.1.0
0.0.0.255
network 172.3.1.0 0.0.0.255
mpls-te enable
#
return
#
sysname PE2
#
efm enable
#
bfd
#
mpls lsr-id 2.2.2.9
mpls
#
mpls l2vpn
#
pw-template 2to1
control-word
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
mpls l2vc pw-template 2to1
201
mpls l2vpn oam-mapping
3ah
efm enable
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
discriminator local
201
101
min-tx-interval 100
min-rx-interval 100
commit
#
return
#
sysname PE3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
efm enable
#
bfd
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
pw-template 3to1
control-word
#
mpls ldp
#
remote-ip 1.1.1.9
#
ip address 172.3.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
mpls l2vc pw-template 3to1 200 tunnel-policy
p1
mpls l2vpn oam-mapping
3ah
efm enable
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
destination 1.1.1.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 3.3.3.9
0.0.0.0
network 172.3.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
discriminator local
200
100
min-tx-interval 100
min-rx-interval 100
commit
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname CE2
#
efm enable
#
ip address 192.168.1.3 255.255.255.0
efm enable
efm trigger if-down
#
ip address 192.168.2.3 255.255.255.0
efm enable
efm trigger if-down
#
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet1/0/0 192.168.1.2
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet2/0/0 192.168.2.2 preference
100
#
return
11.9.6 Example for Configuring VLL to Use a GRE Tunnel

NOTE
AR100&AR120&AR150&AR160&AR200 cannot be used in this scenario.
An ISP network provides the L2VPN service for users. Many users connect to the MPLS
By default, the system uses Label Switched Paths (LSPs) for Martini VLL, and does not
perform load balancing. When the P does not provide MPLS functions, VLL cannot be
implemented.
To solve the problem, apply a tunnel policy to Martini VLL to specify that VLL services are
transmitted over a GRE tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-24 Networking diagram for configuring VLL to use a GRE tunnel
P
GE2/0/0 GE1/0/0
172.1.1.2/24 172.2.1.2/24
Loopback1 Loopback1
10.10.1.1/32 10.10.2.1/32
GE2/0/0 GE1/0/0
172.1.1.1/24 172.2.1.1/24
PE1 GRE Tunnel PE2

10.2.1.1/24 10.2.1.2/24
CE1 CE2
10.1.1.1/24 10.1.1.2/24
1. Configure a routing protocol on the PE and P devices on the backbone network to ensure
reachability between them.
2. Enable MPLS and MPLS LDP on PEs. Set up a remote LDP session between the PEs to
exchange VC labels between the PEs.
3. Enable MPLS L2VPN on PEs. Enabling MPLS L2VPN is the prerequisite for VLL
configuration.
4. Create GRE tunnel interfaces on PEs and establish a GRE tunnel between PEs.
5. Create VC connections on PEs. Because the P does not support MPLS functions,
configure a tunnel policy and apply it when you create VC connections so that VLL
services can be transmitted over a GRE tunnel.
Procedure
Step 1 Configure interface IP addresses and a routing protocol on the PEs and P.
# Configure PE1. The configurations of PE2 and P are similar to the configuration of PE1,
and are not mentioned here.
[PE1] ospf 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
Step 2 Configure basic MPLS functions and LDP on PEs and establish a remote LDP session
between PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configurations are complete, run the display mpls ldp session command on PE1 to
view the LDP session status. You can see that an LDP session is set up between PE1 and PE2.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------

# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
Step 4 Create GRE tunnel interfaces on PEs and establish a GRE tunnel between PEs.
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure PE2.
After the configurations are complete, the tunnel interfaces go Up and can ping each other.
[PE1] ping -a 10.2.1.1 10.2.1.2

0.00% packet loss
Step 5 Configure a tunnel policy, create VC connections, and apply the policy to the VC connections
so that VLL services can be transmitted over a GRE tunnel.
# Configure PE1.
# Configure PE2.

# After the configurations are complete, check the L2VPN connection on PEs. You can see
that an L2VC connection has been set up and is in Up state.
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VC ID : 39
VC type : Ethernet
VCCV State : up
link state : up
tunnel policy name : gre1
Access-port : false
NO.0 TNL type : gre , TNL ID : 0x2
VC last up time : 2013/02/20 18:58:24
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
# Run the display tunnel-info tunnel-id command on PEs according to the tunnel ID in the
preceding command output. You can view details of the specified tunnel ID.
[PE1] display tunnel-info tunnel-id 2
Tunnel ID: 0x2
Tunnel Token: 2
Type: gre
Destination: 10.10.2.1
Out Slot: 0
Instance ID: 0

[CE1] ping 10.1.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 10.10.2.1
#
#
ip address 172.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 10.10.1.1 255.255.255.255
#
ip address 10.2.1.1 255.255.255.0
tunnel-protocol gre
source 10.10.1.1
#
ospf 1
area 0.0.0.0
network 10.10.1.1 0.0.0.0
network 172.1.1.0 0.0.0.255
#
tunnel-policy gre1
#
return
#
sysname P
#
ip address 172.1.1.2 255.255.255.0
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 172.2.1.2 255.255.255.0

#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return

#
sysname PE2
#
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 10.10.1.1
#
ip address 172.2.1.1 255.255.255.0
#
#
interface LoopBack1
ip address 10.10.2.1 255.255.255.255
#
ip address 10.2.1.2 255.255.255.0
tunnel-protocol gre
source 10.10.2.1
#
ospf 1
area 0.0.0.0
network 10.10.2.1 0.0.0.0
network 172.2.1.0 0.0.0.255
#
tunnel-policy gre1
#
return

#
sysname CE2
#
ip address 10.1.1.2 255.255.255.0
#
return
11.9.7 Example for Configuring a VLL Using an MPLS TE Tunnel
users. Many users connect to the MPLS network through PE1 and PE2, and users connected
to the PE devices change frequently. A proper VPN solution is required to provide secure
VPN services for users and to simplify configuration when new users connect to the network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 11-25 Networking for configuring a Martini VLL

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE1/0/0
172.1.1.1/24 172.1.2.2/24
PE 1 PE 2
GE1/0/0 GE2/0/0
GE1/0/0 172.1.1.2/24 172.1.2.1/24
P GE2/0/0
MPLS TE Tunnel
GE1/0/0 GE1/0/0
192.168.1.1/24 192.168.1.2/24
CE 1 CE 2
As the number of access users is large and the users frequently change, a VLL in Martini
mode is recommended between the PEs to simplify configuration when new users connect to
the network. To ensure reliable transmission of VPN services, the highly reliable MPLS TE
tunnel is recommended as the public network tunnel.
1. Assign an IP address to each interface, and configure an IGP on the PE and P devices on
the backbone network to implement interworking between the devices.
2. Create an MPLS TE tunnel and configure a tunnel policy to transmit VLL data.
3. Create a VLL in Martini mode between the PEs to simplify configuration when new
users connect to the network. Create a remote LDP session between the PEs to transmit
local VC labels to the remote device. Create a VC connection between the PEs and apply
the tunnel policy to select the MPLS TE tunnel.
Procedure
Step 1 Configure an IP address and routing protocol for each interface.
Assign IP addresses to interfaces, and configure an IGP on the PE and P devices of the
backbone network according to Figure 11-25 to implement interworking between the devices.
mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
Step 2 Set up an MPLS TE tunnel and create a tunnel binding policy.

l Enable MPLS, MPLS TE, and RSVP-TE globally on PE1, P, and PE2, and on all
interfaces along the tunnel. Enable CSPF on the ingress of the tunnel.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls te
[PE1-mpls] quit

[P] mpls
[P-mpls] mpls te
[P-mpls] mpls rsvp-te
[P-mpls] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls te
[PE2-mpls] quit
l Configure OSPF TE on the MPLS backbone network to advertise TE information.

# Configure PE1. The configuration on P and PE2 is similar to the configuration on PE1
[PE1] ospf 1
[PE1-ospf-1] area 0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1-ospf-1] quit
l Configure tunnel interfaces for the MPLS TE tunnel.

On the ingress of the tunnel, create a tunnel interface and set the IP address, tunnel
protocol, destination IP address, tunnel ID. Then, run the mpls te commit command to
commit the configuration.
# Configure PE1.
# Configure PE2.
After the configuration is complete, run the display mpls te tunnel-interface command
on the PE devices at both ends of the tunnel. The command output shows that an MPLS
TE tunnel is set up successfully. The command output on PE1 is used as an example.
[PE1] display mpls te tunnel-interface
----------------------------------------------------------------
Tunnel0/0/1
----------------------------------------------------------------
Session ID : 100
l Configure a tunnel binding policy.

# Configure PE1.
[PE1] tunnel-policy 1
[PE1-tunnel-policy-1] tunnel binding destination 3.3.3.9 te tunnel 0/0/1
[PE1-tunnel-policy-1] quit
# Configure PE2.
[PE2] tunnel-policy 1
[PE2-tunnel-policy-1] tunnel binding destination 1.1.1.9 te tunnel 0/0/1
[PE2-tunnel-policy-1] quit
Step 3 Create a remote LDP session between PE1 and PE2.

# Configure PE1.
[PE1] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure PE2.
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command on PE1 to
view the LDP session status. The command output shows that the LDP session status is
Operational, indicating that a remote LDP session is established between PE1 and PE2.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Create a VC connection between the PE devices, and apply a tunnel binding policy to the
connection.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1-GigabitEthernet1/0/0] mpls l2vc 3.3.3.9 101 tunnel-policy 1
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2-GigabitEthernet2/0/0] mpls l2vc 1.1.1.9 101 tunnel-policy 1

# Check the L2VPN connections on the PE devices. You can see that an L2VC is set up and is
in Up state.
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 101
VC type : Ethernet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VCCV State : up
link state : up
tunnel policy name : 1
Access-port : false
NO.0 TNL type : cr lsp, TNL ID : 0x1
VC last up time : 2013/09/16 09:57:04
CKey : 4
NKey : 3
Service Class : --
Color : --
DomainId : --
Domain Name : --

The command output on CE1 is used as an example.
[CE1] ping 192.168.1.2

0.00% packet loss
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configuration Files
#
sysname CE1
#
ip address 192.168.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
mpls ldp
#
remote-ip 3.3.3.9
#
mpls l2vc 3.3.3.9 101 tunnel-policy 1
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
destination 3.3.3.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
mpls-te enable
#
tunnel-policy 1
#
return

#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
mpls te
mpls rsvp-te
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 172.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 172.1.2.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.1.2.0 0.0.0.255
mpls-te enable
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls l2vpn
#
mpls ldp
#
remote-ip 1.1.1.9
#
ip address 172.1.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
mpls l2vc 1.1.1.9 101 tunnel-policy 1
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
destination 1.1.1.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.1.2.0 0.0.0.255
mpls-te enable
#
tunnel-policy 1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

#
return

#
sysname CE2
#
ip address 192.168.1.2 255.255.255.0
#
return
11.10 Troubleshooting VLL

This section describes the common configuration errors and troubleshooting methods.
11.10.1 The VC of a Martini VLL Connection Cannot Go Up
Fault Description
After Martini VLL is configured, the local end cannot ping the remote end. The VC status is
Down.
Procedure
Step 1 Check whether the two ends use the same encapsulation type and MTU value.
Run the display mpls l2vc vc-id command to check VC information.
<Huawei> display mpls l2vc 102
Total LDP VC : 1 0 up 1 down
*client interface : Vlanif10 is up

session state : down
AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 102
VC type : VLAN
control word : disable
remote control word : none
local group ID : 0
remote group ID : 0
VCCV State : up
link state : down
remote VCCV : none

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
.....
If the two PEs use different encapsulation types or MTU values, configure the same type of
AC interfaces on the PEs and run the mpls mtu command to set the same MTU value on the
PEs.
If the two PEs use the same encapsulation type and MTU but the fault persists, go to step 2.
NOTE
A VC can go Up only when both ends use the same encapsulation type and MTU value.
Step 2 Check whether VC IDs on the two PEs are the same.

session state : up
AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 102
VC type : VLAN
.....
If the VC IDs are different, run the undo mpls l2vc command on one end to delete the
existing VC ID, and then run the mpls l2vc command to set the VC ID to the same as that on
the other end.
If the two ends use the same VC ID but the fault persists, go to step 3.
NOTE
A VC can go Up only when both ends use the same VC ID.
Step 3 Check whether the control words on the two PEs are the same.

session state : up
AC status : up
VC state : down
Label state : 0
Token state : 0
VC ID : 102
VC type : VLAN
control word : disable
remote control word : none
local group ID : 0
remote group ID : 0
VCCV State : up

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

link state : down
remote VCCV : none
.....
A VC can go Up only when both ends use the same control word. If the control words on two
ends are different, run the undo mpls l2vc command to delete a VC connection on one end
and then run the mpls l2vc command to create a VC connection and configure the same
control word for two ends.
----End
11.11 References for VLL

This section lists the references for VLL.
The following table lists the references for VLL.
Document Description Rema

rks
RFC 4664 Framework for Layer 2 Virtual Private -

Networks (L2VPNs)
RFC 4665 Service Requirements for Layer-2 Provider -

Provisioned Virtual Private Networks
RFC 6074 Provisioning Models and Endpoint -

Identifiers in L2VPN Signaling

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 12 PWE3 Configuration
12 PWE3 Configuration
About This Chapter
This chapter describes principles, applications, and configurations of the Pseudo-Wire

Emulation Edge to Edge (PWE3).
12.1 Overview of PWE3

This section describes the PWE3 definition, purpose, and functions.
12.2 Relationship Between PWE3 and L2VPN
PWE3 is a set of point-to-point (P2P) Layer 2 Virtual Private Network (L2VPN) technologies.
Martini L2VPN is only one of the PWE3 technologies. PWE3 uses some Martini L2VPN
techniques, including Label Distribution Protocol (LDP) signaling and encapsulation modes.
In addition, PWE3 extends the Martini L2VPN.
12.3 Understanding PWE3
This section describes the implementation of PWE3.
12.4 Application Scenarios for PWE3
This section describes application scenarios for PWE3.
12.5 Summary of PWE3 Configuration Tasks
When configuring PWE3, you can configure static PW, dynamic PW, TDM PWE3, or PW
switching. If a network spans multiple autonomous systems (ASs), you need to configure
inter-AS PWE3. When a reliability solution is required, you also need to perform other
configurations, such as Bidirectional Forwarding Detection (BFD) for PW and PWE3 fast
reroute (FRR).
12.6 Licensing Requirements and Limitations for PWE3
12.7 Default Settings for PWE3
12.8 Configuring PWE3
This section describes how to configure PWE3 functions in details.
12.9 Maintaining PWE3
This section describes how to maintain PWE3, including verifying connectivity of a PW and
locating a fault on a PW.
12.10 Configuration Examples for PWE3

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
This section describes PWE3 configuration examples including the networking requirements,
and configuration roadmap, configuration procedure, and configuration files.
12.11 References for PWE3
This section provides references for PWE3.
12.1 Overview of PWE3

This section describes the PWE3 definition, purpose, and functions.
Definition
Pseudo-Wire Emulation Edge to Edge (PWE3) is a point-to-point (P2P) technology that
transmits Layer 2 services on a multiprotocol label switching Layer 2 virtual private network
(MPLS L2VPN). PWE3 simulates essential attributes of a service such as Asynchronous
Transfer Mode (ATM), Frame Relay (FR), Ethernet, low-speed Time Division Multiplexing
(TDM) circuit, Synchronous Optical Network (SONET), or Synchronous Digital Hierarchy
(SDH) on a Packet Switched Network (PSN). PWE3 complies with RFC 4447 (only FEC 128
is supported currently), which is developed based on draft-martini-l2circuit-trans-mpls.
Purpose
The IP network has rapidly developed in recent years because of its flexible upgrade,
scalability, and interoperability. Limited by the transmission mode and services, the traditional
communications network has low flexibility. To make full use of existing or public network
resources during upgrade and expansion of the traditional communications network, PWE3 is
used to integrate the traditional communications network and PSN.
PWE3 often applies to the broadband metro access network (MAN) or mobile bearer network
to transmit various services including Ethernet, ATM, TDM, FR, and PPP. As shown in
Figure 12-1, the headquarters of company A and its branch are located on the traditional
communications network such as ATM or FR. PWE3 is used to establish a PW between PE1
and PE2 so that the headquarters of company A and its branch can communicate over the
MPLS network. PWE3 integrates original access modes with existing IP backbone network to
reduce repetitious network construction, saving operation costs.
Figure 12-1 PWE3 networking

PW
Headquarters Branch of
of enterprise IP/MPLS enterprise A
A Backbone
MPLS Tunnel
AC AC
CE1 PE1 PE2 CE2
PWE3 allows various services to be transmitted and supports migration from the mobile
network to Long Term Evolution (LTE). PWE3 protects carrier investments when ATM and
TDM services are migrated to the IP network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.2 Relationship Between PWE3 and L2VPN

PWE3 is a set of point-to-point (P2P) Layer 2 Virtual Private Network (L2VPN) technologies.
Martini L2VPN is only one of the PWE3 technologies. PWE3 uses some Martini L2VPN
techniques, including Label Distribution Protocol (LDP) signaling and encapsulation modes.
In addition, PWE3 extends the Martini L2VPN.
PWE3 is extended Martini and has the same signaling process as Martini.
12.2.1 Extensions to the Control Plane
Signaling Extension
PWE3 advertises the PW status using LDP signaling Notification messages. A PW is torn
down only when PW configurations are deleted or the LDP session is interrupted. PWE3
reduces control packets exchanged between PEs and signaling costs. LDP signaling used by
PWE3 is compatible with common LDP and Martini.
Multi-Segment Extension
Multi-segment PWE3 extends networking modes.
l Multi-segment PWE3 has low requirements for the number of LDP sessions supported
by an access device. That is, the costs of LDP sessions on the access device are reduced.
l The access node on a multi-segment PW provides PW aggregation. This allows for more
flexible networking and easily divides a network into access, aggregation, and core
layers.
TDM Interface Extension

PWE3 supports more low-speed Time Division Multiplexing (TDM) interfaces. PWE3
supports packet sequencing, clock extraction, and clock synchronization using the Real-time
Transport Protocol (RTP) on the forwarding plane and the control word.
PWE3 has the following advantages by supporting low-speed TDM interfaces:
l Adds encapsulation types (packets on low-speed TDM interfaces can be encapsulated).
l Integrates the PSTN, TV, and data networks.
l Substitutes the traditional Digital Data Network (DDN) service.
Other Extensions
PWE3 has the following extensions at the control plane:
l Fragmentation negotiation mechanism
l PW connectivity detection, such as VCCV and OAM, which speeds up network
convergence and enhances network reliability
12.2.2 Extensions at the Data Plane

l Extensions of the real-time information

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Importing RTP for clock extraction and time synchronization

l Guaranteeing the bandwidth, jitter, and delay of telecom signals
l Re-transmission of disordered packets
12.3 Understanding PWE3

This section describes the implementation of PWE3.
PWE3 Architecture
PWE3 uses the Label Distribution Protocol (LDP) as the signaling protocol, and transmits
Layer 2 packets of Customer Edges (CEs) through tunnels such as MPLS LSPs, Generic
Routing Encapsulation (GRE) tunnels, or multiprotocol label switching traffic engineering
(MPLS TE) tunnels. As shown in Figure 12-2, PWE3 uses the following entities:
l Attachment circuit (AC)

l Pseudo wire (PW)
l Forwarder
l Tunnels
l PW signaling protocol
Figure 12-2 PWE3 architecture
VPN1 VPN1
Site1 CE1 CE3 Site2
Forwarder Forwarder
AC
AC
PE1 P PE2
IP/MPLS
CE2 Backbone CE4 VPN2
VPN2
Site1 Site2
AC
PW
PW Signal
Tunnel
The following uses the flow direction of VPN1 packets from CE1 to CE3 as an example to
show the basic direction of data flows.
l CE1 sends Layer 2 packets to PE1 through an AC.

l After PE1 receives the packets, the forwarder selects a PW to forward the packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l PE1 generates double MPLS labels (private and public network labels) based on the
forwarding entry of the PW. The private network label is used to identify the PW, and the
public network label identifies the tunnel to PE2 on the public network.
l After Layer 2 packets arrive at PE2 through the tunnel on the public network, the
Penultimate Hop Popping (PHP) device (a P device) pops out the public network label,
and PE2 pops out the private network label.
l The forwarder of PE2 selects an AC to forward the Layer 2 packets to CE3.
PWE3 Classification
PWs are classified into the following types:
l Static PW and dynamic PW in terms of implementation
Martini VLL uses LDP to establish dynamic PWs. PWE3 also allows static PWs
established using the manually configured PW information.
l Single-segment PW and multi-segment PW in terms of networking modes
– Single-segment PW: Only one PW is set up between two PEs, and PW label
switching is not required. For example, PW1 in Figure 12-3 is a single-segment
PW.
– Multi-segment PW: Multiple segments of the PW exist between two PEs. The
forwarding mechanism of PEs on the multi-segment PW is the same as that of the
single-segment PW. The difference is that PW labels need to be switched on the
Switching PE (SPE). For example, PW2 in Figure 12-3 is a multi-segment PW.
NOTE
A multi-segment PW is required if a signaling connection or directly connected tunnel cannot be

established between two PEs. With the multi-segment PW, PWE3 makes networking flexible.
The two classification modes are independent of each other. PWE3 supports the
mixed PW, that is, a static PW at one end and a dynamic PW at the other end.
Figure 12-3 Single-segment PW and multi-segment PW

PW1
PE1 P PE2
CE1 CE2
IP/MPLS
Backbone
SPE
PW2 PW2
Segment1 Segment2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Setup, Maintenance, and Teardown of a Dynamic PW

A dynamic PW uses LDP and encapsulates VC information in the type-length-value (TLV) of
LDP packets. PEs need to establish an LDP session, and PW labels are allocated in
Downstream Unsolicited (DU) mode and retained in liberal label retention mode.
NOTE
If a P exists between PEs, a remote LDP session is established between the PEs. If PEs are directly
connected, a common LDP session is established.
After PWE3 configuration is complete on two PEs of the PW and an LDP session is
established between PE1 and PE2, PE1 and PE2 start to establish a dynamic PW, as shown in
Figure 12-4.
1. PE1 sends a Request message and a Mapping message that contain the local private
network label and relevant attributes to PE2.
2. After receiving the Request message from PE1, PE2 sends a Mapping message to PE1.
3. After receiving the Mapping message, PE2 checks whether the same PW parameters as
those in the Mapping message are configured locally. If the configured PW parameters
such as the VC ID, VC type, MTU, and control word status are the same, PE2 sets the
local PW in Up state.
4. After receiving the Mapping message from PE2, PE1 checks whether the locally
configured PW parameters are the same as those in the Mapping message. If they are the
same, PE1 sets the local PW in Up state. A dynamic PW is set up between PE1 and PE2.
5. After the PW is set up, PE1 and PE2 send Notification messages to report their status.
Figure 12-4 Setup and maintenance of a single-segment PW

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
PE1 PE2
mpls l2vc 2.2.2.2 101 Reque

st
Mappin mpls l2vc 1.1.1.1 101

g
Parameter match, VC up
ing
Mapp
Parameter match, VC up
Notification
AC/Tunnel state changed AC/Tunnel state changed
When the AC or the tunnel is Down, Martini and PWE3 take different measures:
l Martini sends a Withdraw message to the peer, requesting to tear down the PW. After the
AC or tunnel becomes Up, two PEs need to perform negotiation again to establish a PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l PWE3 sends a Notification message to notify the peer that packets cannot be forwarded.
The PW is not torn down. When the AC or tunnel becomes Up, PWE3 sends a
Notification message to notify the peer that packets can be forwarded.
Both PEs tear down the PW only when the PW configuration is deleted or the signaling
protocol is interrupted, for example, the public network or PW is Down. On an unstable
network, Notification messages can be sent to prevent repeated PW setup and deletion due to
link flapping.
Figure 12-5 Process of tearing down a single-segment PW

Loopback1 Loopback1
1.1.1.1/32 2.2.2.2/32
PE1 PE2
mpls l2vc 2.2.2.2 101 mpls l2vc 1.1.1.1 101

VC Deletion
Withdraw
Release
Release
VC Deletion
Figure 12-5 shows the PW teardown process.
1. After the PW configuration on PE1 is deleted, PE1 deletes the local VC label and sends
Withdraw and Release messages to PE2.
NOTE
A Withdraw message is used to inform the peer to withdraw labels. A Release message is used to
respond to a Withdraw message and request the peer to send a Withdraw message to withdraw labels.
To tear down a PW more quickly, PE1 sends a Withdraw message and a Release message consecutively.
2. After receiving Withdraw and Release messages from PE1, PE2 delete the remote VC
label and sends a Release message to PE1.
3. After PE1 receives a Release message from PE2, the PW between PE1 and PE2 is torn
down.
As shown in Figure 12-6, one or more SPEs are deployed between two PEs for a multi-
segment PW. PE1 and PE2 establish connections with the SPE and the SPE combines two
segments of the PW.
During signaling negotiation, the SPE forwards parameters in the Mapping message from
UPE1 to UPE2. Similarly, the SPE forwards parameters in the Mapping message from UPE2
to UPE1. If parameters on UPE1 and UPE2 are the same, the PW status becomes Up. Similar
to the Mapping message, Release, Withdraw, and Notification messages are transmitted
segment by segment.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-6 Signaling exchange on a multi-segment PW

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
UPE1 SPE UPE2
mpls l2vc 2.2.2.2 100 Request
Mapping
mpls l2vc 2.2.2.2 100
Request
Mapping
Switch PW
Request
Request
Mapping parameters match
parameters match Mapping VC up
VC up
12.3.2 Control Word

The Control Word is negotiated at the control plane, and is used for packet sequence
detection, packet fragmentation, and packet reassembly at the forwarding plane. In the PWE3
protocols, ATM Adaptation Layer Type 5 (AAL5) requires support for the CW. The
negotiation of the CW at the control plane is simple. If the CW is supported after the
negotiation, the negotiation result needs to be delivered to the forwarding module, which
detects the packet sequence and reassembles the packet.
The CW is a 4-byte encapsulated packet header, as shown in Figure 12-7. It is used to
transmit packets on an MPLS packet switched network (PSN).
Figure 12-7 Position of the CW in a packet

0 7 15 23 31
Tunnel Label(LDP or RSVP) EXP 0 TTL
VC Label(VC) EXP 1 TTL(Set to 2)
Rsvd Flags 0 0 Length Sequence Number
Layer-2 PDU
Tunnel Label /VC Label

Control Word
Layer-2 Protocol Data Unit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The CW has the following functions:

l Carries the sequence number for forwarding packets.
If the forwarding plane supports the CW, a 32-bit CW is added before the data packet to
indicate the packet sequence. When load balancing is supported, the packets may be out
of sequence. The CW can be used to number the packets so that the peer can reassemble
the packets.
l Pads the packets to prevent the packets from being too short.
For example, if two PEs connect to each other over an Ethernet and CEs connect to PEs
over PPP links, PPP negotiation cannot succeed because the size of PPP control packets
cannot meet the minimum MTU requirements of an Ethernet. To prevent this problem,
you can pad the CW as padding bits to the PPP control packet.
l Carries the control information of the Layer 2 frame header.
In certain cases, the frame does not need to be transmitted completely in the L2VPN
packets on the network. The frame header is stripped at the ingress and added at the
egress. This method, however, cannot be used if the information in the frame header
needs to be carried. You can use the CW to solve this problem. The CW can carry the
negotiated information between the ingress PE and the egress PE.
At the control plane, the negotiation succeeds only when both ends or neither end supports the
CW. At the forwarding plane, the negotiation result at the control plane determines whether
the CW is added to a packet.
12.3.3 VCCV
As MPLS is widely deployed and the MPLS network transmits various types of traffic, the
ISP must provide the capability to monitor the label switched path (LSP) status and locate
MPLS forwarding faults. Virtual Circuit Connectivity Verification (VCCV) provides the
service capability.
VCCV is an end-to-end PW fault detection and diagnosis mechanism, and tests and checks
connectivity of the PW forwarding path. VCCV provides the control channel through which
connectivity verification (CV) messages are sent between the PW ingress and egress.
Two VCCV modes are available: VCCV ping and VCCV tracert.
l VCCV ping, as an extension of LSP ping, is used to manually test connectivity of a
virtual circuit (VC). VCCV ping sends MPLS Echo Request messages through a PW to
determine connectivity of the PW. VCCV defines a series of messages transmitted
between PEs to verify connectivity of PWs. VCCV ping can be performed in control
word channel mode or label alert channel mode:
– Control word channel: End-to-end detection between UPEs is supported.
– Label alert channel: Segment by segment detection between the UPE and SPE and
end-to-end detection are supported.
l VCCV tracert, as an extension of LSP tracert, is used to locate the faulty node on a PW.
VCCV tracert sends MPLS Echo Request messages through a PW to collect information
about nodes on the PW. VCCV tracert is classified into PWE3 single-segment tracert and
PWE3 multi-segment tracert.
To ensure that both VCCV packets and PW packets are transmitted along the same path,
VCCV packets must be encapsulated in the same way and transmitted in the same channel as
PW packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.3.4 PWE3 FRR

Definition
As L2VPN is widely used, networks especially L2VPNs that carry real-time services such as
VoIP and IPTV require high reliability.
Pseudo-Wire Emulation Edge to Edge Fast Reroute (PWE3 FRR) is a feasible solution to
improve L2VPN reliability. It uses Operations, Administration and Maintenance (OAM) and
Bidirectional Forwarding Detection (BFD) to detect and report faults on the L2VPN and fast
switch traffic, then improving L2VPN reliability.
PWE3 FRR Implementation

PWE3 FRR is implemented as follows:
l The BFD mechanism is used to fast detect a fault on a PW. As a unified detection
mechanism used on the entire network, BFD can detect a fault in milliseconds. As the
BFD cost is low, if a great number of PWs exist, BFD for PWs greatly reduces the
system cost.
l The OAM mapping between a PW and an AC can be created. When a PW or a PE is
faulty, a CE can take measures in a timely manner. For example, the CE can rapidly
switch traffic to the secondary path.
l OAM messages are transparently transmitted on a PW so that this mechanism
implements end-to-end fault detection on PWs and provides PW protection.
In this way, OAM integrates with BFD to implement PWE3 FRR.
Switchover Mechanism
A fault on the PWE3 FRR network triggers traffic switchover. The device where traffic is
switched also reports the fault and terminates fault notification.
The node that performs fault switchover and terminates fault notification varies with the
networking:
l In a networking with asymmetrically connected CEs as shown in Figure 12-8, PE1 and
CE2 terminate fault propagation. When PE1 detects a fault, it switches traffic and does
not send a fault notification to CE1. CE2 receives the fault notification from PE2 and
switches traffic to the secondary link.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-8 Networking with asymmetrically connected CEs
P1 PE2
PE1
AC2
IP/MPLS
Backbone CE2
CE1
AC1
AC3
PE3
Site1 P2 Site2
PW
PW secondary
l As shown in Figure 12-9, two tunnels back up each other on a backbone network. PE1
and PE2 terminate fault notification, and only need to switch the tunnel.
l Figure 12-9 Tunnel backup on a backbone network
P1
PE1
IP/MPLS PE2
Backbone CE2
CE1
AC1 AC2
Site1 P2 PE3 Site2
Tunnel 1
Tunnel 2
When a CE detects a fault on the primary link, the CE checks whether the secondary link is
available. If so, the CE switches traffic to the secondary link. If not, the CE sends an alarm
about the service fault.
In a networking with asymmetrically connected CEs as shown in Figure 12-8, when PE1
detects a fault on the primary PW, it processes the fault as follows:
l If PE1 also detects a local AC fault, it reports a service fault. In this case, the fault cannot
be rectified.
l If PE1 does not detect a local AC fault or a secondary PW fault, it switches traffic to the
secondary PW.
l If PE1 does not detect a local AC fault but detects a secondary PW fault, it reports a
service fault, but does not switch traffic.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
PW Revertive Switchover Policy

In a networking with asymmetrically connected CEs as shown in Figure 12-8, when PE1 is
notified of fault recovery on the primary PW, PE1 works based on the configured revertive
switchover policy.
The PW revertive switchover policies are as follows:
l None revertive switchover: Traffic is not switched to the primary PW.
l Immediate revertive switchover: Traffic is immediately switched to the primary PW.
l Delayed revertive switchover: Traffic is switched to the primary PW after a delay.
After the switchover, PE1 immediately notifies PE3 on the secondary PW of the fault so that
CE2 fast switches the AC through association. In addition, the PE notifies the peer PE on the
secondary PW of fault recovery immediately or after a delay, preventing packet loss due to
transmission delay between PEs.
12.3.5 Inter-AS Technology

number of applications. As more sites are developed in an enterprise, sites in different
geographical locations often connect to different ISP networks. Consider, for example, the
inter-AS issue facing operators who manage different metropolitan area networks (MANs) or
backbone networks that span different autonomous systems (AS).
Generally, an MPLS VPN architecture runs within an AS in which VPN routing information
is flooded on demand. The VPN routing information within the AS cannot be flooded to the
AS of other service providers (SPs). To implement exchange of VPN routing information
between different ASs, the inter-AS MPLS VPN model is introduced. The inter-AS MPLS
VPN model is an extension of the existing protocol and MPLS VPN framework. This model
allows route prefixes and labels to be advertised over the links between different carrier
networks.
PWE3 supports inter-AS Option A.
Inter-AS Option A
With Option A, ASBRs of two ASs are directly connected and function as PEs in their
respective ASs. The two ASBRs regard each other as a CE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-10 Inter-AS Option A networking
CE-1
IP/MPLS IP/MPLS
Backbone Backbone
AS 100 AS 200
PE-1 PW ASBR1
ASBR2
PW AC
PE-2
LSP1
CE-2
In Figure 12-10, ASBR1 in AS 100 regards ASBR2 in AS 200 as a CE. Similarly, ASBR2
regards ASBR1 a CE.
Option A has the following advantages:
Inter-AS Option A is easy to implement. The two PEs used as ASBRs perform IP forwarding
but not MPLS forwarding. In addition, the two PEs do not require special configurations.
Option A has low scalability.
l The PE needs to manage all L2VPN information, which occupies many resources.
l As the ASBR works as the PE in an AS, each PW requires an AC interface, which can be
a sub-interface, physical interface, or bundled logical interface.
l If a VPN spans multiple ASs, intermediate ASs must support VPN services. As a result,
the configuration workload is heavy and the intermediate ASs are affected.
Therefore, inter-AS Option A is applicable only when there are a small number of inter-AS
L2VPNs.
12.4 Application Scenarios for PWE3

This section describes application scenarios for PWE3.
12.4.1 PWE3 Carrying Enterprise Leased Line Services on a MAN
Usage Scenario
Figure 12-11 shows a typical single-segment PWE3 networking. A carrier establishes a MAN
to provide PWE3 services. A customer has two branches far from each other. If the customer
use leased lines to connect the branches, it will result in high costs. The customer can request
the carrier to establish a PWE3 connection between PE1 in branch A and PE2 in branch B.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
PWE3 ensures stable Layer 2 communication between branches A and B, facilitates

networking, and allows branches A and B to communicate with each other like on a LAN.
Figure 12-11 PWE3 carrying enterprise leased line services on a MAN
PWE3 Deployment
1. IP addresses and IGPs are configured on the carrier MPLS backbone network so that PEs
can communicate.
2. MPLS is enabled on the carrier MPLS backbone network, and a TE tunnel is configured
between PE1 and PE2. Usually, two TE tunnels are configured to provide tunnel
protection.
3. MPLS L2VPN is enabled on PE1 and PE2 and a remote MPLS LDP session is set up
between them.
4. PWE3 is configured on AC interfaces of PE1 and PE2 so that PE1 and PE2 can
communicate over an MPLS L2VC.
12.5 Summary of PWE3 Configuration Tasks

When configuring PWE3, you can configure static PW, dynamic PW, TDM PWE3, or PW
switching. If a network spans multiple autonomous systems (ASs), you need to configure
inter-AS PWE3. When a reliability solution is required, you also need to perform other
configurations, such as Bidirectional Forwarding Detection (BFD) for PW and PWE3 fast
reroute (FRR).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 12-1 PWE3 configuration tasks

Configure PWE3 When configuring PWE3, you can l 12.8.1 Configuring a Static
configure static PW, dynamic PW, PW
TDM PWE3, or PW switching. l 12.8.2 Configuring a
The application scenario of each is Dynamic PW
as follows:
l 12.8.3 Configuring PW
l Configuring static PW: does Switching
not require signaling
negotiation or exchange of l 12.8.4 Configuring TDM
control packets; therefore, it PWE3
consumes few resources and is
easy to configure. However, it
requires manual configuration,
which makes network
maintenance and expansion
difficult. Static PW applies to
small-scale MPLS networks
with simple topologies.
l Configuring dynamic PW:
applies to large-scale
enterprises or local area
networks (LANs) of small-
scale carriers.
l Configuring PW switching:
PW labels need to be
exchanged during multi-
segment PW forwarding.
PW switching applies to the
following scenarios:
– Two PEs are not in the
same AS, and no signaling
connection or tunnel can be
set up between the two PEs.
– The signaling of two PEs
differs from each other.
– If the access device
supports MPLS, but is
incapable of setting up a
large number of LDP
sessions, you can use User
Facing Provider Edge
(UFPE) as the UPE. In
addition, you can use the
SPE as the switching node
of LDP sessions, which is
similar to a signaling
reflector.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configuring TDM PWE3:

applies when TDM services
are transmitted using PWE3.
TDM PWE3 encapsulates
TDM service data and
transparently transmits the
encapsulated data through PWs
to implement TDM service
transmission.
Configure inter- Configure inter-AS PWE3 if the 12.8.7 Configuring Inter-AS

AS PWE3 PWE3 backbone network spans PWE3
multiple ASs.
Configure PWE3 When you transmit key services l 12.8.5 Configuring Static
reliability over the PWE3 network, the BFD for PWs
following reliability solutions can l 12.8.6 Configuring PWE3
be used: FRR
l Configuring BFD for PW:
BFD for PW can rapidly detect
a fault on the PW and notify
the forwarding plane of the
fault, ensuring fast traffic
switchover.
l Configuring PWE3 FRR:
PWE3 FRR ensures link-layer
reliability for the PWE3
network.
Configure and This task is required when PWE3 12.8.8 Configuring and
apply a tunnel services need to be transmitted Applying a Tunnel Policy
policy over TE tunnels or when multiple
tunnels need to perform load
balancing to fully use network
resources.
12.6 Licensing Requirements and Limitations for PWE3

None
For L2VPN-capable devices, their licensing requirements for the L2VPN function are as
follows:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l AR1200&AR2200&AR3200&AR3600 series: By default, L2VPN function is disabled

on a new device. To use the L2VPN function, apply for and purchase the following
license from the Huawei local office.
Feature Limitations
l PWE3 cannot be configured on the VLANIF 1.
l The VLANIF interface configured with PWE3 can only correspond to one member
interface. This limitation does not apply to AR1220E, AR1220EV, and AR1220EVW.
The AR100&AR120&AR150&AR160&AR200 series do not support PWE3.
12.7 Default Settings for PWE3

Table 12-2 lists the default settings for PWE3.
Table 12-2 Default settings for PWE3

MPLS L2VPN Disabled
MTU 1500
VCCV Enabled
Control word Disabled
Jitter buffer depth 8 ms
Number of TDM frames encapsulated in 8

CESoPSN or SAToP packets
12.8 Configuring PWE3

This section describes how to configure PWE3 functions in details.
12.8.1 Configuring a Static PW

A static PW does not use signaling protocols to transmit L2VPN packets. Packets are
transmitted over the tunnel between PEs.
Before configuring a static PW, complete the following tasks:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configuring an IGP protocol on PEs and Ps on the MPLS backbone network to ensure IP
connectivity
l Enabling MPLS on PEs and Ps
You also need to configure tunnel policies when PWE3 services need to be transmitted
over TE tunnels or when PWE3 services need to be load balanced among multiple
tunnels to fully use network resources. For details, see step 1 in 12.8.8 Configuring and
Applying a Tunnel Policy.
To configure a static PW, perform the following operations on the device. Creating a PW
template and setting attributes for the PW template is optional.
12.8.1.1 Enabling MPLS L2VPN
Context
Before configuring a static PW, you must enable MPLS L2VPN.
Perform the following operations on the PEs at both ends of a PW.
Procedure
Step 2 Run mpls l2vpn
MPLS L2VPN is enabled.
By default, MPLS L2VPN is disabled.
----End
12.8.1.2 (Optional) Creating a PW Template and Setting Attributes for the PW

Template
Context
A PW template defines common attributes for PWs, so it can be shared by different PWs. You
can run the pw-template command to define some common attributes in a PW template to
simplify PW configuration. After creating a PW on an interface, you can apply a PW template
to the interface.
On the device, you can bind a PW template to a PW or reset the PW.
You can set the attributes for a PW through commands or a PW template. The attributes
include the peer, tunnel policy, and control word. Importing the PW template can simplify the
configuration of PWs with similar attributes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l Some PW attributes such as the MTU, PW type, and encapsulation type are obtained from the
interface connecting the PE to the CE.
l If you specify a PW attribute through a command, the same PW attribute specified in the PW
template does not take effect on the PW to which this PW template is applied.
Perform the following operations on the PEs.
Procedure
1. Run system-view
2. Run pw-template pw-template-name
A PW template is created and the PW template view is displayed.
3. Run peer-address ip-address
A remote IP address is assigned to a PW template.
4. Run control-word
The control word function is enabled.
By default, the control word function is disabled.
For dynamic single-segment PWs, dynamic multi-segment PWs, and static single-
segment PWs, VCCV in control word mode must be enabled on the UPEs. For static and
mixed multi-segment PWs, VCCV in control word mode must be enabled on both the
UPEs and SPEs.
5. Run mtu mtu-value
The MTU in the PW template is specified.
By default, the MTU in a PW template is 1500.
A tunnel policy is configured for the PW template.
Configure a tunnel policy before you can apply this policy. If no tunnel policy is
configured, an LSP tunnel is used and load balancing is not implemented. For details on
how to configure a tunnel policy, see step 1 in 12.8.8 Configuring and Applying a
Tunnel Policy.
After modifying the attributes of a PW template, run the reset pw pw-template command in
the user view to make the modification take effect. This may cause PW disconnection and
reconnection. If multiple PWs use this template simultaneously, system operation is affected.
12.8.1.3 Creating a Static PW
Context
When creating a static PW, specify the VC label.
Perform the following operations on the PEs at both ends of a PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 3 Create a static PW.

1. To create a primary PW, run:
mpls static-l2vc { { destination ip-address | pw-template pw-template-name vc-
id } * | destination ip-address [ vc-id ] } transmit-vpn-label transmit-label-
value receive-vpn-label receive-label-value [ tunnel-policy tnl-policy-name |
[ control-word | no-control-word ] | [ raw | tagged ] ] *
2. (Optional) To create a secondary PW, run:

mpls static-l2vc { { destination ip-address | pw-template pw-template-name vc-
id } * | destination ip-address [ vc-id ] } transmit-vpn-label transmit-label-
value receive-vpn-label receive-label-value [ tunnel-policy tnl-policy-name |
[ control-word | no-control-word ] | [ raw | tagged ] ] * secondary
NOTE
l When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and tagged.
l You can create a secondary PW only after a primary PW is created.
l The combination of the VC ID and VC type must be unique on each node. The VC IDs at both ends of a
switching PW can be the same. Primary and secondary PWs must have different VC IDs.
l Primary and secondary PWs must use the same control word; otherwise, many packets may be lost during
service switching.
Step 4 (Optional) Run mpls l2vpn service-name service-name
A name is configured for the L2VPN service.
After a name is configured for the L2VPN service, you can maintain the L2VPN service by
----End
12.8.1.4 Verifying the Static PW Configuration
Prerequisites
The configurations of the static PW are complete.
Procedure
l (Optional) Run the display pw-template [ pw-template-name ] command to check
information about the PW template.
state { down | up } ] command to check the information about static VCs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

----End
12.8.2 Configuring a Dynamic PW

This section describes how to configure a dynamic PW. A dynamic PW uses the extended
Label Distribution Protocol (LDP) to transmit Layer 2 information and VC labels.
Before configuring a dynamic PW, complete the following tasks:
l Configuring an Interior Gateway Protocol (IGP) protocol on PEs and Ps on the
Multiprotocol Label Switching (MPLS) backbone network to ensure IP connectivity
l Configuring basic MPLS functions on the backbone network
You also need to configure tunnel policies when Pseudo-Wire Emulation Edge to Edge
(PWE3) services need to be transmitted over TE tunnels or when PWE3 services need to
be load balanced among multiple tunnels to fully use network resources. For details, see
step 1 in 12.8.8 Configuring and Applying a Tunnel Policy.
l Setting up a remote LDP session between the PEs
To configure a dynamic PW, perform the following operations on the device. Creating a PW
template and setting attributes for the PW template is optional.
12.8.2.1 Enabling MPLS L2VPN
Context
Before configuring a PW, you must enable MPLS L2VPN.
Perform the following operations on the PEs or UPEs at both ends of a PW.
Procedure
MPLS L2VPN is enabled.
NOTE
If the non-Huawei device does not have the capability of processing L2VPN label requests, you need to run
the mpls l2vpn no-request-message command on the Huawei device to enable the two devices to
communicate.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Template
Context
A PW template defines common attributes for PWs, so it can be shared by different PWs. You
can run the pw-template command to define some common attributes in a PW template to
simplify PW configuration. After creating a PW on an interface, you can apply a PW template
to the interface.
On the device, you can bind a PW template to a PW or reset the PW.
NOTE
l If you specify a PW attribute through a command, the same PW attribute specified in the PW
template does not take effect on the PW to which this PW template is applied.
Procedure
1. Run system-view
2. Run pw-template pw-template-name
3. Run peer-address ip-address
A remote IP address is assigned to a PW template.
4. Run control-word
For dynamic single-segment PWs, dynamic multi-segment PWs, and static single-
segment PWs, VCCV in control word mode must be enabled on the UPEs. For static and
mixed multi-segment PWs, VCCV in control word mode must be enabled on both the
UPEs and SPEs.
A tunnel policy is configured for the PW template.
Configure a tunnel policy before you can apply this policy. If no tunnel policy is
configured, an LSP tunnel is used and load balancing is not implemented. For details on
how to configure a tunnel policy, see step 1 in 12.8.8 Configuring and Applying a
Tunnel Policy.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.8.2.3 Creating a Dynamic PW
Context
To create a dynamic PW, VCs using the same encapsulation type must have different IDs.
Procedure
Step 3 Create a PW.

1. To create a primary PW, run:
mpls l2vc { ip-address | pw-template pw-template-name } * vc-id [ tunnel-
policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ] |
mtu mtu-value ] *
2. (Optional) To create a secondary PW, run:

policy policy-name | [ control-word | no-control-word ] | [ raw | tagged ] |
mtu mtu-value ] * secondary
NOTE
l When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and tagged.
l A dynamic PW requires that the IDs of VCs using the same encapsulation type are different. Changing
the encapsulation type may cause a VC ID collision.
l You can create a secondary PW only after a primary PW is created.
l The combination of the VC ID and VC type must be unique on each node. The VC IDs at both ends of a
switching PW can be the same. Primary and secondary PWs must have different VC IDs.
l Primary and secondary PWs must use the same control word configuration; otherwise, many packets may
be lost during service switching.
Step 4 (Optional) Run mpls l2vpn service-name service-name
A name is configured for the L2VPN service.
After a name is configured for the L2VPN service, you can maintain the L2VPN service by
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.8.2.4 Verifying the Dynamic PW Configuration
Prerequisites
The configurations of the dynamic PW are complete.
Procedure
l Run the display pw-template [ pw-template-name ] command to check information
about the PW template.
info [ vc-id | verbose ] | state { down | up } ] command to check the information about
virtual circuits in LDP mode.
----End
12.8.3 Configuring PW Switching

You can configure a multi-segment PW to exchange PW labels.
Context
To forward packets through a multi-segment PW, configure PW switching so that PW labels
can be exchanged. PW switching must be configured on the Superstratum PE (SPE) where a
large number of MPLS LDP sessions can be established.
In the following cases, PW switching is required:
l Two PEs are in different ASs, and no signaling connection or tunnel can be set up
l Two PEs use different signaling.
l If the access device can run MPLS but does not support a large number of LDP sessions,
the User Facing Provider Edge (UFPE) can be used as a UPE and the SPE as a node for
switching LDP sessions. The SPE is similar to a signaling reflector.
PW switching supports three modes: static mode, dynamic mode, and mixed mode:
l When static PWs are used between the SPE and two connected PEs, configure static PW
switching.
l When dynamic PWs are used between the SPE and two connected PEs, configure
dynamic PW switching.
l When a static PW and a dynamic PW are used between the SPE and two connected PEs,
configure mixed PW switching.
Before configuring multi-segment PW switching, complete the following tasks:
l Enabling MPLS L2VPN on PEs

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configuring a Static PW on UPEs if PW switching is performed between two static
PWs
l Configuring a Dynamic PW on UPEs if PW switching is performed between two
dynamic PWs
Procedure
l Configuring static PW switching
Perform the following operations on the SPE.
a. Run system-view

b. Run mpls switch-l2vc ip-address vc-id trans trans-label recv received-label
[ tunnel-policy policy-name ] between ip-address vc-id trans trans-label recv
received-label [ tunnel-policy policy-name ] encapsulation encapsulation-type
[ control-word [ cc { alert | cw } * cv lsp-ping ] | [ no-control-word ] [ cc alert cv
lsp-ping ] ] [ control-word-transparent ]
Static PW switching is configured.
To configure static PW switching, you must configure PW labels on each SPE.
A static multi-segment PW is established as follows:
n On the UPE, when the AC status is Up and the PSN tunnel exists, the PW
status is Up.
n On the SPE, as long as the PSN tunnels exist on both sides, the PW is in Up
state even if the SPE and UPE use different PW encapsulation types.
It is recommended that you set the same PW encapsulation type by specifying the
encapsulation-type parameter on the SPE and UPE to facilitate management.
l Configuring dynamic PW switching
a. Run system-view

b. Run mpls switch-l2vc ip-address vc-id [ tunnel-policy policy-name ] between ip-
address vc-id [ tunnel-policy policy-name ] encapsulation encapsulation-type
[ control-word-transparent ]
Dynamic PW switching is configured.
Dynamic PW switching is easy to configure. Two neighboring endpoints (UPE or

SPE) will send remote labels to the SPE through signaling. The two UPEs will send
control word and VCCV to the SPE through signaling.
The PW encapsulation type (specified by the encapsulation-type parameter) on the

SPE must be the same as that on the UPE. Otherwise, the PW cannot go Up.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Configuring mixed PW switching

NOTE
When you configure mixed PW switching, ip-address vc-id before between specifies the VC ID of
a dynamic PW and ip-address vc-id after between specifies the VC ID of a static PW. The two
values cannot be interchanged.

a. Run system-view
b. Run mpls switch-l2vc ip-address vc-id [ tunnel-policy policy-name ] between ip-
address vc-id trans trans-label recv received-label [ tunnel-policy policy-name ]
encapsulation encapsulation-type [ mtu mtu-value ] [ control-word [ cc { alert |
cw } * cv lsp-ping ] | [ no-control-word ] [ cc alert cv lsp-ping ] ] [ control-word-
transparent ]
Mixed PW switching is configured.
To configure mixed PW switching, configure a PW label for the static PW. The PW
encapsulation type (specified by the encapsulation-type parameter) on the SPE must
be the same as that on the UPE connected to a dynamic PW.
To configure mixed PW switching, the following MTUs must be the same:
n Local MTU of the dynamic PW
n Peer MTU of the dynamic PW
n Local MTU of the static PW
n Peer MTU of the static PW
NOTE
In mixed PW switching, the MTUs of the interfaces on the two ends must be the same and
cannot be greater than 1500 bytes.
----End

l Run the display mpls switch-l2vc [ ip-address vc-id encapsulation encapsulation-type |
state { down | up } ] command on the SPE to view information about PW switching.
12.8.4 Configuring TDM PWE3

You can configure TDM PWE3 to encapsulate TDM service data and transparently transmit
the data through PWs to implement TDM service transmission through PWE3.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Before configuring TDM PWE3, complete the following tasks:
l Configuring an IGP protocol on the Ps and PEs on the MPLS backbone network to
implement IP connectivity
l Configuring basic MPLS capabilities on the backbone network
l Installing a 8SA, 6E&M, 8E1T1-M, or 8E1T1-F interface card on the device and
ensuring that it is registered successfully
NOTE
Only the AR2204XE, AR2204XE-DC, AR2220, AR2240 (using SRU40, SRU60, SRU80, SRU200, or
SRU200E, or SRU400), AR3200 (using SRU40, SRU60, SRU80, SRU200, or SRU200E, or SRU400),
and AR3600 (using SRUX5) series routers support this function.
To configure TDM PWE3, you need to perform the following configurations, among which
creating a PW template and setting attributes for the PW template is optional.
12.8.4.1 Configuring an AC Interface to Transparently Transmit TDM Cells
Context
You can configure an AC interface to transparently transmit TDM cells, so that after receiving
TDM packets, the AC interface encapsulates the packets and transmits the packets through a
PW.
Procedure
Step 1 Use either of the following methods to configure AC interface parameters based on the
interface card type:
l 8SA interface card: Configure interface parameters such as a working mode for serial
interfaces. Ensure that the parameters are the same as those of a CE's interface connected
to the AC interface.
NOTE
For the detailed configuration of a serial interface, see Configuring a Synchronous Serial Interface in
Huawei AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series
Enterprise Routers Configuration Guide - Interface Management.
l 6E&M interface card: Configure interface parameters for E&M interfaces. Ensure that
the parameters are the same as those of a CE's interface connected to the AC interface.
NOTE
For the detailed configuration of an E&M interface, see Configuring Line Attributes for an E&M
Interface in Huawei AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600
Series Enterprise Routers Configuration Guide - Interface Management.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l 8E1T1-M interface card: Configure interface parameters such as a working mode for
CE1/PRI interfaces. Ensure that the parameters are the same as those of a CE's interface
connected to the AC interface. To ensure that CEs exchange data successfully, the AC
interfaces must work in clock synchronization state.
NOTE
For the detailed configuration of a CE1/PRI interface, see Configuring CE1/PRI Interface in Huawei
Routers Configuration Guide - Interface Management.
l 8E1T1-F interface card: Configure interface parameters such as a working mode for E1-
F interfaces. Ensure that the parameters are the same as those of a CE's interface
connected to the AC interface. To ensure that CEs exchange data successfully, the AC
interfaces must work in clock synchronization state.
NOTE
For the detailed configuration of an E1-F interface, see Configuring E1-F Interface in Huawei
Routers Configuration Guide - Interface Management.
Step 2 Configure the AC interface to transparently transmit TDM cells.

1. Run system-view
2. Run interface serial interface-number
The serial interface view is displayed.
3. Run link-protocol tdm
The link layer protocol used for packet encapsulation on the serial interface is set to
TDM.
----End

Template
Context
A PW template defines common attributes for PWs, so it can be shared by different PWs. The
PW template simplifies PW configuration. You can use the PW template to create a PW on an
interface.
On the device, the PW can be bound to a PW template and can be reset.
NOTE
l If you specify a PW attribute through commands, the same PW attribute specified in the PW
template does not function on the PW to which this PW template is applied.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run pw-template pw-template-name
Step 3 Run peer-address ip-address
The remote device IP address of the PW is specified.
Step 4 Run control-word
To enable VCCV in control word mode, enable the control word function only on the UPE for
dynamic single-hop PWs, dynamic multi-hop PWs, and static single-hop PWs; enable the
control word function on both the UPE and SPE for static multi-hop PWs and mixed dynamic
multi-hop PWs.
Step 5 Run mtu mtu-value
Step 6 Run jitter-buffer depth depth
The jitter buffer depth is configured.
By default, the jitter buffer depth is 8 ms.
The jitter buffer is used to reduce jitter at the network side. A larger jitter buffer depth
indicates a stronger anti-jitter capability. However, when a long transmission delay is
introduced when data flows are reconstructed, improper jitter buffer depth degrades
transmission quality.
Step 7 Run tdm-encapsulation-number number
The number of encapsulated TDM frames in Circuit Emulation Services over Packet Switch
Network (CESoPSN) or Structure-Agnostic Time Division Multiplexing over Packet (SAToP)
packets in the TDMoPSN application is set.
By default, the number of encapsulated TDM frames in a CESoPSN or SAToP packet is 8.
When the interface card where the AC interface locates is 8SA, 8E1T1-M or 8E1T1-F, the
interface can encapsulate a maximum of 16 TDM frames in a packet. If the value is larger
than 16, the interface only encapsulates 16 TDM frames in a packet.
You can determine the number of TDM frames encapsulated into each PW packet. The
smaller the number of frames encapsulated into a packet, the shorter the encapsulation and
transmission delay but the more the encapsulation overhead. The larger the number of frames
encapsulated into a packet, the higher the bandwidth utilization but the longer the
encapsulation delay.
Step 8 Run idle-code idle-code-value
The device is configured to fill idle codes when a jitter buffer underflow occurs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, the system fills idle codes to FF.
A jitter buffer underflow occurs when the device needs to read packets but there are not
sufficient packets in the buffer. The idle code has no significance, and can be set to any value.
Step 9 Run tnl-policy policy-name
A tunnel policy is configured for the PW.
Configure a tunnel policy before you can apply this policy. If no tunnel policy is configured,
an LSP tunnel is used and load balancing is not implemented. For details on the tunnel policy
configuration, see step 1 in 12.8.8 Configuring and Applying a Tunnel Policy.
----End
Follow-up Procedure
12.8.4.3 Configuring PW
Context
When configuring TDM PWE3, you can create static PWs, dynamic PWs, or PW switching.
Procedure
Step 2 Run interface serial interface-number
The serial interface view is displayed.
Step 3 Configure PWE3 function.

Choose either of them based on the networking.
1. Configure a static PW.
a. To configure an active PW, run:
mpls static-l2vc { { destination ip-address | pw-template pw-template-
name vc-id } * | destination ip-address [ vc-id ] } transmit-vpn-label
transmit-label-value receive-vpn-label receive-label-value [ tunnel-
policy tnl-policy-name | [ control-word | no-control-word ] | idle-code
idle-code-value | jitter-buffer depth | tdm-encapsulation number | tdm-
sequence-number ] *
b. (Optional) To configure a standby PW, run:

transmit-label-value receive-vpn-label receive-label-value [ tunnel-
policy tnl-policy-name | [ control-word | no-control-word ] | idle-code
idle-code-value | jitter-buffer depth | tdm-encapsulation number | tdm-
sequence-number ] * secondary

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
– You can configure a standby PW only after an active PW is configured.

– The combination of the PW ID and PW type must be unique on each node. The IDs of PWs on two
ends can be the same. Active and standby PWs must have different VC IDs.
– Active and standby PWs must use the same control word configuration; otherwise, many packets
may be lost during service switching.
2. Configure a dynamic PW
a. To configure an active PW, run:
policy policy-name | [ control-word | no-control-word ] | mtu mtu-value
| idle-code idle-code-value | jitter-buffer depth | tdm-encapsulation-
number number | tdm-sequence-number ] *
b. (Optional) To configure a standby PW, run:

policy policy-name | [ control-word | no-control-word ] | mtu mtu-value
| idle-code idle-code-value | jitter-buffer depth | tdm-encapsulation-
number number | tdm-sequence-number ] * secondary
NOTE
– A dynamic PW requires that the VC ID of the same encapsulation type on a PE be unique.

Changing the encapsulation type may cause a VC ID collision.
– You can configure a standby PW only after an active PW is configured.
– The combination of the PW ID and PW type must be unique on each node. The IDs of PWs on two
ends can be the same. Active and standby PWs must have different VC IDs.
– Active and standby PWs must use the same control word configuration; otherwise, many packets
may be lost during service switching.
3. Configuring PW Switching
Perform this operation on the SPE only. Select static PW or dynamic PW based on the
PW switching mode on the UPE.
PW switching is classified into static mode, dynamic mode, and mixed mode:
– When static PWs are used between the SPE and two connected PEs, configure static
PW switching.
– When dynamic PWs are used between the SPE and two connected PEs, configure
dynamic PW switching.
– When a static PW and a dynamic PW are used between the SPE and two connected
PEs, configure mixed PW switching.
Perform either of the following operations based on actual needs.
– To configuring a static PW switching, run:
mpls switch-l2vc ip-address vc-id trans trans-label recv received-label
[ tunnel-policy policy-name ] between ip-address vc-id trans trans-label
recv received-label [ tunnel-policy policy-name ] encapsulation
encapsulation-type [ control-word [ cc { alert | cw } * cv lsp-ping ] |
[ no-control-word ] [ cc alert cv lsp-ping ] ] [ control-word-
transparent ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
When different PW encapsulation modes are selected, the parameters to be specified are as
follows:
n If encapsulation-type is set to satop-e1, the following parameters can be specified: [no-
control-word ] [ cc alert cv lsp-ping ].
n If encapsulation-type is set to cesopsn-basic, the following parameters can be specified:
control-word [ cc { alert | cw } * cv lsp-ping ], [no-control-word ] [ cc alert cv lsp-
ping ].
The timeslotnum timeslotnum needs to be configured.
– To configuring a dynamic PW switching, run:
mpls switch-l2vc ip-address vc-id [ tunnel-policy policy-name ] between
ip-address vc-id [ tunnel-policy policy-name ] encapsulation
encapsulation-type [ control-word-transparent ]
– To configuring a mixed PW switching, run:

ip-address vc-id trans trans-label recv received-label [ tunnel-policy
policy-name ] encapsulation encapsulation-type [ mtu mtu-value ]
[ control-word | no-control-word ] [ timeslotnum timeslotnum ] [ tdm-
encapsulation number ] [ control-word-transparent ]
NOTE
n When you configure mixed PW switching, ip-address vc-id before between specifies the
VC ID of a dynamic PW and ip-address vc-id after between specifies the VC ID of a
static PW. The two values cannot be interchanged.
n In mixed PW switching, the MTUs of the interfaces on the two ends must be the same
and cannot be greater than 1500 bytes.
n When different PW encapsulation modes are selected, the parameters to be specified are
as follows:
○ If encapsulation-type is set to satop-e1, the following parameters can be specified:
mtu mtu-value, control-word, no-control-word, and tdm-encapsulation number.
○ If encapsulation-type is set to cesopsn-basic, the following parameters can be
specified: mtu mtu-value, control-word, no-control-word, timeslotnum
timeslotnum, and tdm-encapsulation number.
The timeslotnum timeslotnum needs to be configured.
Step 4 (Optional) Run mpls l2vpn pw performance disable
The statistics collection function for PWs on the TDM interface is disabled.
After PW is configured on a TDM interface, the statistics collection function for PWs on the
TDM interface is enabled by default. The system collects statistics on sent and received
packets of the primary PW at an interval of 15 minutes. To improve statistics collection
efficiency for system performance or other performance, you can perform this step to disable
the statistics collection function for PWs on the TDM interface.
----End
12.8.4.4 Verifying the TDM PWE3 Configuration
Prerequisites
The configurations of the TDM PWE3 are complete.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
After a PW with the encapsulation type being TDM is configured on the AC side, PW performance statistics
collection is enabled on the related TDM interface by default. Run the undo mpls l2vpn pw performance
disable command can enable the function of PW performance information collection on a TDM interface.
Procedure
l Run the display pw-template [ pw-template-name ] command to check information
about the PW template.
l Run the display mpls switch-l2vc [ ip-address vc-id encapsulation encapsulation-type |
state { down | up } ] command on the SPE to view information about PW switching.
l Run the display mpls l2vpn interface interface-type interface-number performance
command to check PW performance information on a TDM interface.
----End
12.8.5 Configuring Static BFD for PWs

Static BFD for PWs enables the device to fast detect faults on PWs and trigger switching of
upper-layer applications. Static BFD applies to small-scale networks.
Before configuring static BFD for PWs, complete the following tasks:
l Setting IP parameters to make each node reachable

l Configuring a PW
The following configurations are mandatory and must be performed in sequence.
12.8.5.1 Enabling BFD Globally
Context
Before configure BFD for PWs, enable BFD globally. Perform the following operations on
the PEs at both ends of a PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run bfd
BFD is enabled globally on the local node and the BFD view is displayed.
----End
12.8.5.2 Configuring BFD for PWs
Context
You must configure or delete BFD for PWs on the two PEs of a PW simultaneously;
otherwise, the PW status on the two PEs may be different. Perform the following operations
on the two PEs of the PW to be detected.
Procedure
Step 2 Run bfd cfg-name bind pw interface interface-type interface-number [ secondary ]
BFD for PWs is configured.
The outbound interface interface interface-type interface-number bound to a BFD session is

the AC interface where a PW resides.
To detect a secondary PW, specify secondary.
Step 3 Configure BFD discriminators.

l Run discriminator local discr-value
The local discriminator is set.
l Run discriminator remote discr-value
The remote discriminator is set.
NOTE
The local discriminator at the local end must be the same as the remote discriminator at the peer end,
and the remote discriminator at the local end must be the same as the local discriminator at the peer end.
Step 4 Run commit
The configuration is committed.
When the PW status is Down, a BFD session can be set up but cannot go Up.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l The local and remote BFD discriminators cannot be modified once being configured. To modify the
local or remote BFD discriminator, run the undo bfd bfd-name command in the system view to
delete the configuration of BFD for PWs, and then reconfigure the local or remote BFD
discriminator.
l After the PW is deleted, the related BFD session and configuration are deleted.
Step 5 (Optional) Set the encapsulation type for BFD CV packets to be sent to remote peers.
1. Run quit
2. Run mpls l2vpn
3. Run either of the following commands:
– To set the encapsulation type to 0x04 for BFD CV packets to be sent to all remote
peers, run the mpls l2vpn vccv bfd-cv-negotiation fault-detection-only command.
– To set the encapsulation type 0x08 for BFD CV packets to be sent to all remote
peers, run the undo mpls l2vpn vccv bfd-cv-negotiation fault-detection-only
command.
– To set the encapsulation type to 0x04 for BFD CV packets to be sent to a specified
remote peer, run the mpls l2vpn vccv bfd-cv-negotiation fault-detection-only
peer peer-address enable command.
– To set the encapsulation type to 0x08 for BFD CV packets to be sent to a specified
remote peer, run the mpls l2vpn vccv bfd-cv-negotiation fault-detection-only
peer peer-address disable command.
– To restore the global encapsulation type of BFD CV packets to be sent to a
specified remote peer, run the undo mpls l2vpn vccv bfd-cv-negotiation fault-
detection-only peer peer-address command.
----End
12.8.5.3 Verifying the Configuration of Static BFD for PWs
Prerequisites
The configurations of static BFD for PWs are complete.
Procedure
l Run the display bfd configuration pw interface interface-type interface-number
[ secondary ] [ verbose ] command to check the BFD configuration.
----End
12.8.6 Configuring PWE3 FRR

After PWE3 FRR is configured, the L2VPN traffic is rapidly switched to the secondary path
when a fault occurs on the primary path. After the fault on the primary path is rectified, the
L2VPN traffic is switched back to the primary path based on a revertive switchover policy.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Context
On the network where CEs are asymmetrically connected to PEs, the secondary PW cannot
transmit data when the primary path and secondary path work properly. If the AC interface of
the secondary PW borrows the IP address of the AC interface of the primary PW, note the
following points:
l The switching policy No revertive switchover cannot be configured.
l The local CE has two equal-cost and direct routes to the remote CE. The destination
addresses and next hops of the two routes are the same. The route that passes through the
secondary PW is unreachable.
l If the CEs exchange routing information using routing protocols, change the cost or
metric value of the AC interface of the secondary path to a value greater than that of the
AC interface of the primary path. The local CE may be unable to communicate with the
remote CE, but can communicate with other remote user devices.
l If CEs use static routes and the AC links are Ethernet links, BFD for static routes needs
to be configured on CEs.
Before configuring PWE3 FRR, complete the following tasks:
l Configuring primary and secondary PWs of the same type on the network where CEs are
asymmetrically connected to PEs
l Configuring CEs to exchange routing information using routing protocols or static routes
Perform the operations in the following sequence. You can determine whether to perform
optional operations based on site requirements.
12.8.6.1 Configuring Primary and Secondary PWs
Context
You can configure primary and secondary PWs to protect services on the PWs.
l On the network where CEs are symmetrically dual-homed to PEs, configure one primary
PW for each of the primary and secondary paths. The primary and secondary paths can
be configured with different types of PWs.
l On the network where CEs are asymmetrically connected to PEs, configure primary and
secondary PWs for the primary and secondary paths respectively. The primary and
secondary PWs must be of the same type.
Devices support only dynamic primary and secondary PWs.
Perform the following operations on the two PEs of a PW.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure dynamic primary and secondary PWs on the PEs. For details, see 12.8.2
Configuring a Dynamic PW.
NOTE
l Primary and secondary PWs must have different VC IDs.

l Primary and secondary PWs must use the same control word; otherwise, many packets may be lost
during service switching.
Step 2 (Optional) Configure other primary and secondary PW functions.

2. Run mpls l2vpn stream-dual-receiving
The primary and secondary PWs are configured to receive packets simultaneously.
When PWE3 FRR is configured on a network, you must configure the primary and
secondary PWs to receive packets simultaneously on the PE to which the PWs are
single-homed, preventing packet loss during PW revertive switchover.
----End
12.8.6.2 (Optional) Configuring Fast Fault Notification - OAM Mapping
Context
OAM mapping expedites the fault detection and notification on the AC end. OAM mapping
can be configured on various types of links. To configure OAM mapping on Ethernet links,
the PE and CE devices must support the Ethernet OAM function.
Choose either of the following procedures to configure OAM mapping according to the AC
types.
Procedure
The view of the AC interface is displayed.
Step 3 Run mpls l2vpn oam-mapping 3ah
The fault mapping between the AC and the PW is enabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
l The PW need be configured in homogeneous interworking mode when the AC is an Ethernet.

Otherwise, the use device may learn a wrong outbound interface according to ARP.
l Before running the mpls l2vpn oam-mapping 3ah command, you need configure Ethernet OAM on
the AC link. For details, refer to "EFM Configuration" in the Huawei
Routers Configuration Guide - Reliability.
l If the mpls l2vpn oam-mapping command is configured, run the display mpls l2vc interface
command to check the VC status. In the command output, "Local AC OAM State" indicates the
status of the AC link; if the mpls l2vpn oam-mapping command is not configured, run the display
mpls l2vc interface command to check the VC status. In the command output, "Local AC OAM
State" is always Up, and has no relationship with the AC link status.
----End
12.8.6.3 (Optional) Configuring BFD for PW
Context
BFD for PW is recommended because it speeds up fault detection.
Procedure
For details, see the following topics.
l 12.8.5 Configuring Static BFD for PWs
NOTE
l BFD for PW on both PEs at the two ends must be configured or deleted simultaneously. Otherwise,
the statuses of PWs on the PEs are inconsistent.
l To monitor statuses of tunnels that carry PWs, configure BFD for tunnel. For detailed
configurations, see "MPLS LDP Configuration" and "MPLS TE Configuration" in Huawei
Routers Configuration Manual MPLS.
12.8.6.4 (Optional) Configuring a Revertive Switchover Policy
Context
Revertive switching policies are classified into the following types:
l Immediate revertive switchover: When the primary PW recovers from a fault, the local
PE switches traffic back to the primary PW immediately and notifies the peer PE on the
secondary PW of the fault. In FRR mode, the local PE notifies the peer PE on the
secondary PW of the recovery after a delay of resume-time. In PW redundancy master/
slave mode, the parameter resume-time is not supported.
This revertive switchover applies to scenarios in which users hope traffic to be restored
as soon as possible.
l Delayed revertive switchover: When the primary PW recovers from a fault, traffic is
switched back to the primary PW after a period specified by delay-time. After traffic is
switched back, the local device immediately notifies the peer device on the secondary
PW of the fault. If resume-time is configured in FRR mode, the local device notifies the
peer device on the secondary PW of the recovery after a delay of resume-time.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
On a large-scale network, packet loss caused by incomplete route convergence may

occur during the switchback. To prevent this problem, configure traffic to be switched
back after a delay.
l None revertive switchover: When the primary PW recovers from a fault, traffic is not
switched back to the primary PW until the secondary PW becomes faulty.
If you do not want traffic to be frequently switched between the primary and secondary
PWs, you can use the non-revertive switchover.
By default, the delayed revertive switchover is performed.
A revertive switchover policy is configured on a PE. In asymmetric networking, if the active

PW is faulty, the PE to which a CE is connected through a single link switches traffic. When
the active PW is restored, configure a revertive switchover policy on this PE. The PE then
processes traffic based on the configured revertive switchover policy.
Perform the following operations on the PE (where traffic is switched) to which the CE is
connected through a single link.
Procedure
Step 3 Run mpls l2vpn reroute { { delay delay-time | immediately } [ resume resume-time ] |
never }
The revertive switchover policy is configured.
For an asymmetric networking with ACs of the Ethernet type, if the Ethernet OAM function
is configured on the PE interface connected to a CE, and a revertive switching policy is also
configured, do not set resume-time to 0 seconds. Set resume-time to 1 second or longer.
NOTE
On the network where CEs are asymmetrically connected to PEs, the secondary PW cannot transmit data
when the primary and secondary paths work normally. On the CE in the dual-homed site, if the interface
of the secondary PW borrows the IP address of the interface of the primary PW, you cannot configure
revertive switchover.
----End
12.8.6.5 Verifying the PWE3 FRR Configuration
Prerequisites
All configurations about PWE3 FRR are complete.
After PWE3 FRR is configured, you can view information about the local and remote PWs,
BFD sessions, L2VPN forwarding, and OAM mapping. You can also run the manual-set pw-
ac-fault command to simulate faults on a PW to verify whether the switchover between the
primary and secondary PWs is normal.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
l Run the manual-set pw-ac-fault command on the interface of the primary PW to
simulate faults on it to verify whether the switchover between the primary and secondary
PWs is normal.
command to check information about the local PWs.
l Run the display mpls l2vc remote-info [ vc-id ] command to check information about
the remote PWs.
l Run the display mpls l2vpn forwarding-info [ vc-label ] interface interface-type
interface-number command to check the MPLS L2VPN forwarding information.
----End
12.8.7 Configuring Inter-AS PWE3

Inter-AS PWE3 allows the MPLS backbone network to transmit PWE3 services over multiple
ASs.
Context
The devices support inter-AS PWE3 Option A. Option A is easy to implement; however, each
ASBR must provide a dedicated interface for each inter-AS VC. The interface can be a sub-
interface, physical interface, or logical interface. If the number of inter-AS VCs is small, this
solution can be used.
Before configuring inter-AS PWE3, complete the following tasks:
l Configuring an IGP protocol for the MPLS backbone network in each AS to ensure IP
connectivity of the backbone network within an AS
l Configuring basic MPLS functions on the MPLS backbone network in each AS
l Configuring MPLS LDP and establishing the LDP LSP for the MPLS backbone in each
AS
Procedure
The configurations of inter-AS PWE3 Option A are as follows:
l Perform the operation of Configuring a Dynamic PW in each AS.

l Configure the ASBRs. Each ASBR considers the peer ASBR as its CE.
NOTE
You do not need to perform any additional configuration for inter-AS implementation on ASBRs and do
not need to configure IP addresses for the directly connected interfaces between ASBRs.
The configuration details are not mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

command on the PE to view information about the local PW.
l Run the display mpls l2vc remote-info [ vc-id ] command on the PE to view
information about the remote PW.
12.8.8 Configuring and Applying a Tunnel Policy

You need to configure tunnel policies on PEs when PWE3 services need to be transmitted
over TE tunnels or when PWE3 services need to be load balanced among multiple tunnels to
fully use network resources.
Context
Service data on the PWE3 network is transmitted over tunnels. By default, LSP tunnels are
used to transmit data, and each service is transmitted by only one LSP tunnel.
If the default tunnel configuration cannot meet PWE3 service requirements, apply tunnel
policies to VPNs. You can configure either of the following types of tunnel policies based on
service requirements:
PWE3 data transmission or select multiple tunnels for load balancing.
guarantee for PWE3.
Before configuring and applying a tunnel policy, complete the following task:
l For details on how to create a GRE tunnel, see GRE Configuration in the Huawei
l For details on how to create an LSP tunnel, see MPLS LDP Configuration in the Huawei
l For details on how to create a TE tunnel, see MPLS TE Configuration in the Huawei
Perform the following operations on the PEs that need to use a tunnel policy.
Procedure
By default, no tunnel policy is configured. LSP tunnels are used to transmit PWE3 data and
each VPN service is transmitted over one LSP tunnel.
1. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

4. Run tunnel select-seq { cr-lsp | gre | lsp } * load-balance-number load-balance-
number
1. Run system-view
The tunnel interface view of the MPLS TE tunnel is displayed.
5. Run quit
The TE tunnel is bound to a specified tunnel policy.
NOTE
– If the PE has multiple peers, you can run the tunnel binding command multiple times to
specify different destination IP addresses in a tunnel policy.
– If down-switch is specified in the command, the system selects available tunnels in an order
of LSP, CR-LSP, and GRE when the bound tunnels are unavailable.

Perform the following operations on AC interfaces on the PEs.
1. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3. Use either of the following methods to create a static PW, a dynamic PW, or PW
switching.
– To create a static PW, run:
transmit-label-value receive-vpn-label receive-label-value tunnel-policy
tnl-policy-name [ [ control-word | no-control-word ] | [ raw | tagged ]
| secondary ] *
NOTE
When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and tagged.
– To create a static PW, run:
transmit-label-value receive-vpn-label receive-label-value tunnel-policy
tnl-policy-name [ [ control-word | no-control-word ] | [ raw | tagged ]
| idle-code idle-code-value | jitter-buffer depth | tdm-encapsulation
number | tdm-sequence-number | secondary ] *
NOTE
n When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and
tagged.
n When the AC interfaces are serial interfaces, CE1/PRI interfaces, or E1-F interfaces, you can
specify the parameters idle-code, jitter-buffer, tdm-encapsulation, and tdm-sequence-
number.
– To create a dynamic PW, run:
mpls l2vc { ip-address | pw-template pw-template-name } * vc-id tunnel-
policy policy-name [ [ control-word | no-control-word ] | [ raw |
tagged ] | mtu mtu-value | secondary ] *
NOTE
When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and tagged.
– To create a dynamic PW, run:
mpls l2vc { ip-address | pw-template pw-template-name } * vc-id tunnel-
policy policy-name [ [ control-word | no-control-word ] | [ raw |
tagged ] | mtu mtu-value | idle-code idle-code-value | jitter-buffer
depth | tdm-encapsulation-number number | tdm-sequence-number |
secondary ] *
NOTE
n When the AC interfaces are Ethernet interfaces, you can specify the parameters raw and
tagged.
n When the AC interfaces are serial interfaces, CE1/PRI interfaces, or E1-F interfaces, you can
specify the parameters idle-code, jitter-buffer, tdm-encapsulation-number, and tdm-
sequence-number.
– To create static PW switching, run:
mpls switch-l2vc ip-address vc-id trans trans-label recv received-label
[ tunnel-policy policy-name ] between ip-address vc-id trans trans-label
recv received-label [ tunnel-policy policy-name ] encapsulation
encapsulation-type [ control-word [ cc { alert | cw } * cv lsp-ping ] |
[ no-control-word ] [ cc alert cv lsp-ping ] ] [ control-word-
transparent ]
– To create dynamic PW switching, run:

ip-address vc-id [ tunnel-policy policy-name ] encapsulation
encapsulation-type [ control-word-transparent ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
– To create mixed PW switching, run:

[ control-word [ cc { alert | cw } * cv lsp-ping ] | [ no-control-word ]
[ cc alert cv lsp-ping ] ] [ timeslotnum timeslotnum ] [ tdm-
encapsulation number ] [ control-word-transparent ]
– To create mixed PW switching, run:

[ control-word [ cc { alert | cw } * cv lsp-ping ] | [ no-control-word ]
[ cc alert cv lsp-ping ] ] [ control-word-transparent ]
----End

After configuring a tunnel policy and applying it to PWE3, you can check information about
the tunnel policy applied to the PWE3 and tunnels in the system.
l Run the display tunnel-policy [ tunnel-policy-name ] command to check the
configurations of tunnel policies.
12.9 Maintaining PWE3

This section describes how to maintain PWE3, including verifying connectivity of a PW and
locating a fault on a PW.
12.9.1 Verifying Connectivity of a PW
Context
Before using the ping vc and tracert vc commands to check connectivity of a PW, ensure that
the PWE3 network is correctly configured.
l VCCV ping can be performed in control word channel mode or Label alert channel
mode:
– Control word channel: supports detection between UPEs.
– Label alert channel: supports detection between CEs and per-hop detection between
the UPE and SPE.
By default, VCCV in Label Alert mode is enabled. Before using the control word channel, run
the control-word command to enable the control word function. VCCV in control word
channel mode is then enabled.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
When locating faults on the PW, you can use either VCCV in control word channel mode or
normal mode.
Checking connectivity of the PW is not supported in the following situations:
l SPEs do not support the ping vc and tracert vc command (these commands are
supported only by UPEs).
l Multiple users cannot run the command simultaneously. That is, the devices on the two
ends cannot ping a VC at the same time. On a device serving as both a UPE and an SPE,
if the PW serving as an SPE is performing VCCV ping, the PW serving as a UPE will be
unable to perform VCCV ping. That is, two VCCV pings cannot be performed on a same
device at the same time.
l The MTU check of the VC is not supported.
For an MH-PW, the local VC ID and VC type needs to be specified.
In the control word mode, if VC IDs are different, the VC ID of the remote UPE needs to be
specified. In the MPLS Label Alert mode, the addresses of the remote peer SPEs or UPEs
need to be specified.
Because a static PW does not support signaling negotiation, configurations of the UPE control
word on both ends of the PW are different, with the control word being enabled on one end,
but disabled on the other. When the MPLS Label Alert mode is enabled on both ends, the PW
can be Up and the ping vc command can work. CEs, however, cannot communicate with each
other because the control words are different.
Procedure
l Check the connectivity of the PW.
value | -exp exp-value | -r reply-mode | -v ] * control-word [ remote remote-ip-
address peer-pw-id | draft6 ] * [ ttl ttl-value ] [ uniform ]
To check the connectivity of a PW switching, run the following commands:
value | -exp exp-value | -r reply-mode | -v ] * control-word remote remote-ip-
address peer-pw-id sender sender-address [ ttl ttl-value ] [ uniform ]
value | -exp exp-value | -r reply-mode | -v ] * label-alert [ no-control-word ]
[ remote remote-ip-address | draft6 ] * [ uniform ]
– Normal mode
value | -exp exp-value | -r reply-mode | -v ] * normal [ no-control-word ] [ remote
remote-ip-address peer-pw-id ] [ ttl ttl-value ] [ uniform ]
l Locate a fault on the PW.
t timeout-value ] * control-word [ draft6 ] [ full-lsp-path ] [ uniform ]

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

t timeout-value ] * control-word remote remote-ip-address [ ptn-mode | full-lsp-
path ] [ uniform ]
t timeout-value ] * control-word remote remote-pw-id draft6 [ full-lsp-path ]
[ uniform ]
t timeout-value ] * label-alert [ no-control-word ] [ remote remote-ip-address ]
[ full-lsp-path ] [ draft6 ] [ uniform ]
– Normal mode
t timeout-value ] * normal [ no-control-word ] [ remote remote-ip-address ] [ full-
lsp-path ] [ draft6 ] [ uniform ]
----End
12.9.2 Locating a Fault on a PW
Context
After PWE3 is configured, you can locate any PW faults. To locate a fault on a PW, configure
basic PWE3 functions using a PW template, and then run the following commands on U-PEs.
Procedure
Step 1 Run the system-view command to enter the system view of the U-PE.
Step 2 Run the pw-template pw-template-name command to enter the PW template view.
Step 3 Run the control-word command to enable the control word function.
Step 4 Run either of the following commands to collect information about each LSR along the PW
and information about the egress PE.
l tracert vc pw-type pw-id [ -exp exp-value | -f first-ttl | -m max-ttl | -r reply-mode | -t

timeout-value ] * control-word [ draft6 ] [ full-lsp-path ] [ uniform ]
timeout-value ] * control-word remote remote-ip-address [ ptn-mode | full-lsp-path ]
[ uniform ]
timeout-value ] * control-word remote remote-pw-id draft6 [ full-lsp-path ]
[ uniform ]
timeout-value ] * label-alert [ remote remote-ip-address ] [ full-lsp-path ] [ draft6 ]
timeout-value ] * normal [ remote remote-ip-address ] [ full-lsp-path ] [ draft6 ]
When running the tracert vc command to locate a PW fault, pay attention to the following
points:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l The SPEs do not support this command. You can run this command on UPEs only.
l You can use this command to tracert a single-segment PW and a multi-segment PW
created using LDP.
l When tracerting a multi-segment PW, specify the remote PW ID in addition to the local
PW ID and PW type.
When the tracert vc command is run, the tracert operation is terminated in the following
cases:
l The PE that initiates tracert receives an MPLS Echo Reply packet from the egress PE.
l The TTL in the label of the previous MPLS Echo Request packet sent by the PE that
initiates tracert reaches the configured or default maximum number of hops.
l A user presses Ctrl+C on the PE that initiates tracert.
----End
12.10 Configuration Examples for PWE3

This section describes PWE3 configuration examples including the networking requirements,
and configuration roadmap, configuration procedure, and configuration files.
12.10.1 Example for Configuring a Dynamic Single-Segment PW
users. Many users connect to the MPLS network through PE1 and PE2, and users on the PEs
users, save network resources, and simplify configuration when new users connect to the
network.
Figure 12-12 Networking diagram for configuring a dynamic single-segment PW (using an

LSP tunnel)
10.10.1.1/32 10.10.2.1/32 10.10.3.1/32
GE2/0/0 GE1/0/0 GE2/0/0 GE2/0/0

10.1.1.1/24 10.1.1.2/24 10.2.2.1/24 10.2.2.2/24
PE1 PE2
P
GE1/0/0 GE1/0/0
PW
GE1/0/0 GE1/0/0
10.3.1.1/24 10.3.1.2/24
CE1 CE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Because users on the two PEs change frequently, manual configuration is inefficient and may
cause configuration errors. In this scenario, the two PEs can set up a remote LDP session and
use the LDP protocol to synchronize user information through a dynamic PW. Compared with
Martini, PWE3 reduces the signaling cost and defines the multi-segment negotiation mode,
making networking more flexible. PWE3 is recommended if network resources need to be
saved.
1. Configure an IGP protocol on the backbone network so that backbone network devices
can communicate.
2. Configure basic MPLS functions and establish LSP tunnels on the backbone network.
Then establish the remote MPLS LDP peer relationship between the PEs at both ends of
the PW.
3. Create MPLS L2VC connections on the PEs.
Procedure
Step 1 Configure an IP address for each interface on the CEs, PEs, and the P according to Figure
12-12.
Step 2 Configure an IGP protocol and Loopback address on the MPLS backbone network.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After the configuration is complete, run the display ip routing-table command. The
command out shows that PE1 and PE2 have learnt the routes to each other's Loopback0
interface through OSPF, and that PE1 and PE2 can ping each other.
Step 3 Enable MPLS, and set up tunnels and remote LDP sessions.
Enable MPLS on the MPLS backbone network, and set up an LSP tunnel and remote LDP
sessions between the PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure P.
[P] mpls
[P-mpls] mpls ldp
[P-mpls-ldp] quit
[P-GigabitEthernet1/0/0] ip address 10.1.1.2 255.255.255.0
[P-GigabitEthernet2/0/0] ip address 10.2.2.1 255.255.255.0
# Configure PE2.
[PE2] mpls
[PE2-mpls] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command on the
devices. The command output shows that LDP sessions are established between the PEs and
between the P and PEs, and the session status is Operational.
Step 4 Create VCs.
Enable MPLS L2VPN on PE1 and PE2, and create a VC on each PE.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit

# Run the following command on the PEs to check the L2VPN connections. The command
output shows that an L2VC connection is set up and is in Up state.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet
VCCV State : up
link state : up
Access-port : false
VC last up time : 2013/12/02 00:16:31
CKey : 8
NKey : 7
Service Class : --
Color : --
DomainId : --
Domain Name : --

[CE1] ping 10.3.1.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 10.3.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 10.10.3.1
#
mpls l2vc 10.10.3.1 100
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 10.10.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.10.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
l Configuration file of the P

#
sysname P
#
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
interface LoopBack0
ip address 10.10.2.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.10.2.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return

#
sysname PE2
#
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 10.10.1.1
#
mpls l2vc 10.10.1.1 100
#
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 10.10.3.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.10.3.1 0.0.0.0
network 10.2.2.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 10.3.1.2 255.255.255.0
#
return
12.10.2 Example for Configuring a Static Multi-Segment PW
As shown in Figure 12-13, sites of an enterprise at different geographical locations connect to
the MPLS network of an ISP through CE1 and CE2. The S-PE has powerful functions, and U-
PE1 and U-PE2 function as access devices and cannot directly establish remote LDP sessions.
To simplify configuration, the enterprise hopes that the two CEs communicate with each other
like on a LAN. That is, data packets of users traverse the ISP network without being modified
by the PEs. The enterprise will not increase sites in the future and wants to use exclusive VPN
resources of the ISP to protect user data security.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-13 Networking diagram for configuring a static multi-segment PW

2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE1/0/0 GE2/0/0
P1 20.1.1.2/24 30.1.1.1/24 P2
GE1/0/0 GE1/0/0 GE2/0/0
GE2/0/0
10.1.1.2/24 S-PE 30.1.1.2/24 40.1.1.1/24
20.1.1.1/24
Loopback0 Loopback0
1.1.1.9/32 5.5.5.9/32
PW U-PE2
U-PE1 ic
St
GE2/0/0 t GE1/0/0
ta
at
S 40.1.1.2/24
ic
10.1.1.1/24
PW
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Because the enterprise will not increase sites in the future and wants to use exclusive VPN
resources, you can configure a static PW to meet the customer requirements. To use
hierarchical networking, configure a static multi-segment PW.
1. Configure a common routing protocol on the backbone network so that backbone
network devices can communicate.
2. Configure basic MPLS functions and establish LSPs on the backbone network.
3. Establish static MPLS L2VC connections on U-PEs.
4. Configure PW switching on the S-PE for a multi-segment PW.
Procedure
Step 1 Configure an IP address for each interface on the devices according to Figure 12-13.
# Configure CE1. The configuration on U-PE1, P1, S-PE, P2, U-PE2, and CE2 is similar to
the configuration on CE1 and is not mentioned here.
# Configure U-PE1. The configuration on P1, S-PE, P2, and U-PE2 is similar to the
configuration on U-PE1 and is not mentioned here.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[U-PE1] interface loopback 0

[U-PE1-LoopBack0] ip address 1.1.1.9 255.255.255.255
[U-PE1-LoopBack0] quit
[U-PE1] ospf 1
[U-PE1-ospf-1] area 0
[U-PE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[U-PE1-ospf-1-area-0.0.0.0] quit
[U-PE1-ospf-1] quit
Step 3 Configure basic MPLS functions and set up LSP tunnels.

Configure basic MPLS functions on the MPLS backbone network, and set up LSP tunnels
between U-PE1 and S-PE, and between SPE and U-PE2. U-PE1 is used as an example. The
configurations of other devices are similar to the configuration of U-PE1 and are not
mentioned here.
# Configure U-PE1.
[U-PE1] mpls lsr-id 1.1.1.9
[U-PE1] mpls
[U-PE1-mpls] mpls ldp
[U-PE1-mpls-ldp] quit
[U-PE1] interface gigabitethernet 2/0/0
[U-PE1-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[U-PE1-GigabitEthernet2/0/0] mpls
[U-PE1-GigabitEthernet2/0/0] mpls ldp
[U-PE1-GigabitEthernet2/0/0] quit
Step 4 Create VCs.

Enable MPLS L2VPN on U-PE1, U-PE2, and S-PE, and set up VCs on U-PE1 and U-PE2.
# Configure U-PE1.
[U-PE1] mpls l2vpn
[U-PE1-l2vpn] quit
[U-PE1] pw-template pwt
[U-PE1-pw-template-pwt] peer-address 3.3.3.9
[U-PE1-pw-template-pwt] quit
[U-PE1-GigabitEthernet1/0/0] mpls static-l2vc pw-template pwt 100 transmit-vpn-
# Configure S-PE.
[S-PE] mpls l2vpn
[S-PE-l2vpn] quit
[S-PE] mpls switch-l2vc 5.5.5.9 100 trans 200 recv 200 between 1.1.1.9 100 trans
100 recv 100 encapsulation ethernet
# Configure U-PE2.
[U-PE2] mpls l2vpn
[U-PE2-l2vpn] quit
NOTE
The transmit-vpn-label configured on the U-PE must be the same as the recv label on the S-PE, and the
receive-vpn-label configured on the U-PE must be the same as the trans label on the S-PE. Otherwise,
CEs cannot communicate.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Run the following command on the PEs to check the L2VPN connections. The command
output shows that an L2VC connection is set up and is in Up state.
# The display on U-PE1 and the S-PE is used as an example.

[U-PE1] display mpls static-l2vc interface gigabitethernet 1/0/0
*Client Interface : GigabitEthernet1/0/0 is up
AC Status : up
VC State : up
VC ID : 100
VC Type : Ethernet
Destination : 3.3.3.9
Transmit VC Label : 100
Receive VC Label : 100
Label Status : 0
Token Status : 0
Control Word : Disable
VCCV Capabilty : alert ttl lsp-ping bfd
Link State : up
Tunnel Policy : --
PW Template Name : pwt
Main or Secondary : Main
Access-port : false
Backup TNL Type : lsp , TNL ID : 0x0
VC last up time : 2013/12/04 15:29:44
CKey : 2
NKey : 1
Service Class : --
Color : --
DomainId : --
Domain Name : --
[S-PE] display mpls switch-l2vc
Total Switch VC : 1, 1 up, 0 down
*Switch-l2vc type : SVC<---->SVC

Peer IP Address : 5.5.5.9, 1.1.1.9
VC ID : 100, 100
VC Type : Ethernet
VC State : up
In/Out Label : 200/200, 100/100
InLabel Status : 0 , 0
Control Word : Disable, Disable
VCCV Capability : alert ttl lsp-ping bfd , alert ttl lsp-ping bfd
Switch-l2vc tunnel info :
1 tunnels for peer 5.5.5.9
NO.0 TNL Type : lsp , TNL ID : 0xe
CKey : 8, 10
NKey : 7, 9
Tunnel policy : --, --
VC last up time : 2013/12/01 22:31:43

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[CE1] ping 100.1.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return
l Configuration file of U-PE1

#
sysname U-PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
pw-template pwt
#
mpls ldp
#
mpls static-l2vc pw-template pwt 100 transmit-vpn-label 100 receive-vpn-
label 100
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
l Configuration file of P1
#
sysname P1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls lsr-id 2.2.2.9

mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
l Configuration file of S-PE
#
sysname S-PE
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls switch-l2vc 5.5.5.9 100 trans 200 recv 200 between 1.1.1.9 100 trans 100
recv 100 encapsulation ethernet
#
mpls ldp
#
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 40.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 30.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return

#
sysname U-PE2
#
mpls lsr-id 5.5.5.9
mpls
#
mpls l2vpn
#
pw-template pwt
#
mpls ldp
#
ip address 40.1.1.2 255.255.255.0
mpls
mpls ldp
#
label 200
#
interface LoopBack0
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9 0.0.0.0
network 40.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.10.3 Example for Configuring a Dynamic Multi-Segment PW
users. The S-PE has powerful functions, and U-PE1 and U-PE2 function as access devices
and cannot directly establish remote LDP sessions. Many users connect to the MPLS network
through U-PE1 and U-PE2, and users on the U-PEs change frequently. A proper VPN solution
is required to provide secure VPN services for users and simplify configuration and
maintenance when new users connect to the network.
Figure 12-14 Networking diagram for configuring a dynamic multi-segment PW

2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE1/0/0 GE2/0/0
P1 P2
20.1.1.2/24 30.1.1.1/24
GE1/0/0 GE2/0/0
GE2/0/0 GE1/0/0
10.1.1.2/24 40.1.1.1/24
20.1.1.1/24 S-PE 30.1.1.2/24
Loopback0 Loopback0
0
1.1.1.9/32 PW 5.5.5.9/32
10
GE2/0/0 GE1/0/0
PW
U-PE1 20 U-PE2
10.1.1.1/24 0 40.1.1.2/24
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Because the S-PE has powerful functions, and U-PE1 and U-PE2 cannot directly establish
remote LDP sessions, you can configure a multi-segment PW and PW switching on the S-PE
to meet the customer requirements. To simplify maintenance, configure a dynamic multi-
segment PW.
can communicate.
2. Configure basic MPLS functions and establish LSPs on the backbone network. Establish
remote MPLS LDP peer relationships between U-PE1 and the S-PE, and between U-PE2
and the S-PE.
3. Create PW templates and enable the control word function and LSP ping.
4. Configure a dynamic PW on the S-PE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. Configure PW switching on the S-PE.
Procedure
[U-PE1] ospf 1
[U-PE1-ospf-1] quit
After the configuration is complete, run the display ip routing-table command on the U-PEs,
Ps or S-PE. The command output shows that these devices have learnt the routes of each
other.
Step 3 Enable MPLS and set up LSP tunnels and remote LDP sessions.
Configure basic MPLS functions on the MPLS backbone network, and set up LSP tunnels and
remote LDP sessions between U-PE1 and the S-PE, and between the S-PE and U-PE2.
# Configure U-PE1.
[U-PE1] mpls
[U-PE1-mpls] quit
[U-PE1] mpls ldp
[U-PE1] mpls ldp remote-peer 3.3.3.9
[U-PE1-mpls-ldp-remote-3.3.3.9] remote-ip 3.3.3.9
[U-PE1-mpls-ldp-remote-3.3.3.9] quit
# Configure P1.
[P1] mpls lsr-id 2.2.2.9
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit
[P1] interface gigabitethernet 1/0/0
[P1-GigabitEthernet1/0/0] mpls
[P1-GigabitEthernet1/0/0] mpls ldp
[P1-GigabitEthernet1/0/0] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure the S-PE.

[S-PE] mpls lsr-id 3.3.3.9
[S-PE] mpls
[S-PE-mpls] quit
[S-PE] mpls ldp
[S-PE-mpls-ldp] quit
[S-PE] interface gigabitethernet 1/0/0
[S-PE-GigabitEthernet1/0/0] mpls
[S-PE-GigabitEthernet1/0/0] mpls ldp
[S-PE-GigabitEthernet1/0/0] quit
[S-PE] mpls ldp remote-peer 1.1.1.9
[S-PE-mpls-ldp-remote-1.1.1.9] remote-ip 1.1.1.9
[S-PE-mpls-ldp-remote-1.1.1.9] quit
# Configure P2.
[P2] mpls
[P2-mpls] quit
[P2] mpls ldp
[P2-mpls-ldp] quit
# Configure U-PE2.
[U-PE2] mpls
[U-PE2-mpls] quit
[U-PE2] mpls ldp
After the configuration is complete, run the display mpls ldp session command on the U-
PEs, Ps, or S-PE. The command output shows that the LDP sessions are established and the
status is Operational. Run the display mpls ldp peer command. The command output shows
that LDP peer relationships are established. Run the display mpls lsp command. The
command output shows that LSPs are established.
Step 4 Create and configure PW templates.
Create PW templates on the U-PEs, and enable the control word function.
# Configure U-PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[U-PE1] mpls l2vpn

[U-PE1-l2vpn] quit
[U-PE1-pw-template-pwt] control-word
# Configure U-PE2.
[U-PE2] mpls l2vpn
[U-PE2-l2vpn] quit
[U-PE2-pw-template-pwt] control-word
NOTE
You can also configure a dynamic PW without using the PW template. If the PW template is not used,
PW connectivity cannot be verified and path information of the PW cannot be collected. That is, you
cannot run the ping vc or tracert vc command.
Step 5 Create VCs.

Enable MPLS L2VPN on U-PE1, U-PE2, and the S-PE.
Configure dynamic PWs on U-PEs, and configure PW switching on the S-PE.
# Configure U-PE1.
[U-PE1-GigabitEthernet1/0/0] mpls l2vc pw-template pwt 100

[S-PE] mpls l2vpn
[S-PE-l2vpn] quit
[S-PE] mpls switch-l2vc 1.1.1.9 100 between 5.5.5.9 200 encapsulation ethernet
# Configure U-PE2.
[U-PE2-GigabitEthernet2/0/0] mpls l2vc pw-template pwt 200

1. View the PWE3 connection.
View the L2VPN connection on the U-PEs and S-PE. The command output shows that
an L2VC is set up and the VC status is Up.
The display on U-PE1 is used as an example.
[U-PE1] display mpls l2vc interface gigabitethernet 1/0/0
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VCCV State : up
link state : up
PW template name : pwt
Access-port : false
VC last up time : 2013/12/04 16:09:45
CKey : 4
NKey : 3
Service Class : --
Color : --
DomainId : --
Domain Name : --
Check the L2VC status on the S-PE.
*Switch-l2vc type : LDP<---->LDP

Peer IP Address : 5.5.5.9, 1.1.1.9
VC ID : 200, 100
VC Type : Ethernet
VC State : up
VC StatusCode |PSN |OAM | FW | |PSN |OAM | FW |
-Local VC :| UP | UP | UP | | UP | UP | UP |
-Remote VC:| UP | UP | UP | | UP | UP | UP |
Session State : up, up
Local/Remote Label : 1031/1028, 1032/1028
Local/Remote MTU : 1500/1500, 1500/1500
Local/Remote Control Word : Enable/Enable, Enable/Enable
Local/Remote VCCV Capability : cw alert ttl lsp-ping bfd /cw alert ttl
lsp-ping bfd , cw alert ttl lsp-ping bfd /cw alert ttl lsp-ping bfd
CKey : 14, 16
NKey : 13, 15
Control-Word transparent : NO

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VC last up time : 2013/12/01 23:02:39
2. Detect connectivity of the PW.

Run the ping vc command on the U-PEs. The command output shows that connectivity
of the PW is normal. The display on U-PE1 is used as an example.
[U-PE1] ping vc ethernet 100 control-word remote 5.5.5.9 200
Reply from 5.5.5.9: bytes=100 Sequence=1 time = 740 ms
--- FEC: FEC 128 PSEUDOWIRE (NEW). Type = vlan, ID = 100 ping statistics ---
0.00% packet loss
3. Check connectivity between the CEs and information about the paths between the CEs.
CE1 and CE2 can ping each other.
[CE1] ping 100.1.1.2

0.00% packet loss
On CE1, perform the tracert operation.

[CE1] tracert 100.1.1.2
traceroute to 100.1.1.2(100.1.1.2) max hops: 30 ,packet length: 40,press
CTRL_C to break
1 100.1.1.2 250 ms 220 ms 130 ms
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname U-PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
pw-template pwt
control-word
#
mpls ldp
#
remote-ip 3.3.3.9
#
mpls l2vc pw-template pwt 100
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
l Configuration file of the S-PE
#
sysname S-PE
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls switch-l2vc 1.1.1.9 100 between 5.5.5.9 200 encapsulation ethernet
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

remote-ip 1.1.1.9
#
remote-ip 5.5.5.9
#
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 40.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 30.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
#
sysname U-PE2
#
mpls lsr-id 5.5.5.9
mpls
#
mpls l2vpn
#
pw-template pwt
control-word
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls ldp
#
remote-ip 3.3.3.9
#
ip address 40.1.1.2 255.255.255.0
mpls
mpls ldp
#
mpls l2vc pw-template pwt 200
#
interface LoopBack0
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9 0.0.0.0
network 40.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
12.10.4 Example for Configuring a Mixed Multi-Segment PW

users. The S-PE has powerful functions, and U-PE1 and U-PE2 (U-PE2 supports only static
PWs) function as access devices and cannot directly establish remote LDP session. Many
users connect to the MPLS network through U-PE1 and U-PE2, and users on the U-PEs
users and simplify configuration and maintenance when new users connect to the network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-15 Networking diagram for configuring a mixed multi-segment PW

2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE1/0/0 GE2/0/0
P1 P2
20.1.1.2/24 30.1.1.1/24
GE1/0/0 GE2/0/0
GE2/0/0 GE1/0/0
10.1.1.2/24 40.1.1.1/24
20.1.1.1/24 S-PE 30.1.1.2/24
Loopback0 Loopback0
0
10
St
1.1.1.9/32 5.5.5.9/32
a
PW
tic
GE2/0/0 GE1/0/0
PW
U-PE1 U-PE2
ic
10.1.1.1/24 40.1.1.2/24
20
a
yn
0
D
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Because the S-PE has powerful functions, and U-PE1 and U-PE2 cannot directly establish
remote LDP sessions, you can configure a multi-segment PW and PW switching on the S-PE
to meet the customer requirements. U-PE2 supports only static PWs, so a mixed multi-
segment PW is used.
can communicate.
2. Configure basic MPLS functions and establish LSP tunnels on the backbone network.
3. Set up a remote LDP session between U-PE1 and the S-PE.
4. Set up static or dynamic MPLS L2VC connections on the U-PEs.
5. Configure PW switching on the S-PE.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[U-PE1] ospf 1
[U-PE1-ospf-1] quit
Step 3 Enable MPLS, set up tunnels, and set up a remote LDP session between U-PE1 and the S-PE.
Configure basic MPLS functions and set up tunnels on the MPLS backbone network. In this
example, the LSP tunnel is used.
You need to set up a remote LDP session between U-PE1 and the S-PE. U-PE1 is used as an
example.
# Configure U-PE1.
[U-PE1] mpls
[U-PE1-mpls] quit
[U-PE1] mpls ldp
# Configure P1
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit

[S-PE] mpls lsr-id 3.3.3.9
[S-PE] mpls
[S-PE-mpls] quit
[S-PE] mpls ldp
[S-PE-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure P2
[P2] mpls
[P2-mpls] quit
[P2] mpls ldp
[P2-mpls-ldp] quit
# Configure U-PE2
[U-PE2] mpls
[U-PE2-mpls] quit
[U-PE2] mpls ldp
Step 4 Create VCs.

Enable MPLS L2VPN on U-PE1, U-PE2, and the S-PE.
Configure a dynamic VC on U-PE1 and a static VC on U-PE2, and configure mixed PW
switching on the S-PE.
# Configure U-PE1.
[U-PE1] mpls l2vpn
[U-PE1-l2vpn] quit
[U-PE1-GigabitEthernet1/0/0] mpls l2vc 3.3.3.9 100
NOTE
When you configure mixed PW switching, ip-address vc-id before between specifies the VC ID of a
dynamic PW and ip-address vc-id after between specifies the VC ID of a static PW. The two values
cannot be interchanged.

[S-PE] mpls l2vpn
[S-PE-l2vpn] quit
[S-PE] mpls switch-l2vc 1.1.1.9 100 between 5.5.5.9 200 trans 200 recv 100
encapsulation ethernet
# Configure U-PE2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[U-PE2] mpls l2vpn

[U-PE2-l2vpn] quit
# View information about L2VPN connections on the PEs. The command output shows that
an L2VC is set up and the VC status is Up.
# The display on U-PE1 and the S-PE is used as an example.

[U-PE1] display mpls l2vc interface gigabitethernet 1/0/0
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet
VCCV State : up
link state : up
Access-port : false
VC last up time : 2013/12/04 16:32:08
CKey : 6
NKey : 5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Service Class : --
Color : --
DomainId : --
Domain Name : --
*Switch-l2vc type : LDP<---->SVC

Peer IP Address : 1.1.1.9, 5.5.5.9
VC ID : 100, 200
VC Type : Ethernet
VC State : up
Session State : up, None
Local(In)/Remote(Out) Label : 1033/1029, 100/200
Local/Remote MTU : 1500/1500, 1500
Local/Remote Control Word : Disable/Disable, Disable
Local/Remote VCCV Capability : alert ttl lsp-ping bfd /alert ttl lsp-ping bfd ,
alert ttl lsp-ping bfd
CKey : 18, 20
NKey : 17, 19
VC last up time : 2013/12/01 23:25:03

[CE1] ping 100.1.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return
#
sysname U-PE1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
mpls ldp
#
remote-ip 3.3.3.9
#
mpls l2vc 3.3.3.9 100
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
l Configuration file of the S-PE
#
sysname S-PE
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls switch-l2vc 1.1.1.9 100 between 5.5.5.9 200 trans 200 recv 100
encapsulation ethernet

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls ldp
#
remote-ip 1.1.1.9
#
remote-ip 5.5.5.9
#
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 40.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 30.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
#
sysname U-PE2
#
mpls lsr-id 5.5.5.9
mpls
#
mpls l2vpn
#
pw-template pwt

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
mpls ldp
#
remote-ip 3.3.3.9
#
ip address 40.1.1.2 255.255.255.0
mpls
mpls ldp
#
label 200
#
interface LoopBack0
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9 0.0.0.0
network 40.1.1.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
12.10.5 Example for Configuring Inter-AS PWE3 Option A

users. PE1 becomes to AS 100 and PE2 belongs to AS 200. Many users connect to the MPLS
network through PE1 and PE2, and many new users will connect to the PEs in the future. A
proper VPN solution is required to provide secure VPN services for users, save network
resources, and simplify configuration when new users connect to the network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 12-16 Networking diagram for configuring inter-AS PWE3 Option A
IP/MPLS backbone IP/MPLS backbone

network network
AS 100 AS 200
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE2/0/0 GE1/0/0
GE2/0/0 GE1/0/0
10.1.1.1/24 30.1.1.2/24
GE1/0/0 GE2/0/0
10.1.1.2/24 ASBR -PE1 ASBR -PE2 30.1.1.1/24 PE2
PE1
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
MPLS backbone networks in the same AS use IS-IS as the IGP protocol.
The PEs connect to different ASs (AS 100 and AS 200) of the ISP, so an inter-AS VPN
solution is required. To simplify configuration when new users connect to the network and
save network resources, PWE3 Option A is recommended to meet the customer requirements.
1. Run an IGP protocol on the backbone network so that devices in an AS can

communicate.
2. Configure basic MPLS functions on the backbone network and establish a dynamic LSP
between the PE and ASBR-PE in the same AS. Establish a remote LDP session if the PE
and ASBR-PE are not directly connected.
3. Establish an MPLS L2VC between the PE and ASBR-PE in the same AS.
Procedure
Step 1 Configure an IP address for each interface on the devices according to Figure 12-16. CE1 is
used as an example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1. The configuration on ASBR-PE1, ASBR-PE2,and PE2 is similar to the

[PE1] isis 1
[PE1-isis-1] quit
After the configuration is complete, the IS-IS neighbor relationship can be established
between the ASBR-PE and PE in the same AS. Run the display isis peer command. The
command output shows that the neighbor relationship is Up.
Run the display ip routing-table command. The command output shows that the PE and
ASBR-PE in the same AS can learn the routes to the loopback interface of each other.
The ASBR-PE and PE in the same AS can ping each other successfully.
Step 3 Enable MPLS and configure a dynamic LSP.
Configure basic MPLS functions on the MPLS backbone network. Establish a dynamic LDP
LSP between the PE and ASBR-PE in the same AS.
# Configure PE1. The configuration on ASBR-PE1, ASBR-PE2,and PE2 is similar to the
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
After this step is performed, an LSP tunnel is established between the PE and ASBR-PE in
the same AS.
Step 4 Configure MPLS L2VCs.
Configure the L2VC on the PE and ASBR-PE and connect the PE to the CE.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
# Run the following command to check information about the L2VPN connection on the PEs.
The command output shows that an L2VC is set up and the VC status is Up.

session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : Ethernet
VCCV State : up
link state : up
Access-port : false
VC last up time : 2013/12/04 17:17:07
CKey : 8
NKey : 7

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Service Class : --
Color : --
DomainId : --
Domain Name : --

The display on CE1 is used as an example.
[CE1] ping 100.1.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
mpls l2vc 2.2.2.9 100
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
mpls l2vc 1.1.1.9 100
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
mpls l2vc 4.4.4.9 100
#
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls l2vpn
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0004.00

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
mpls l2vc 3.3.3.9 100
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
12.10.6 Example for Configuring TDM PWE3 (Using the 8E1T1-M

Interface Card)
NOTE
Only the AR2220, AR2240 (using SRU40, SRU60, SRU80, SRU200, or SRU400), AR3200 (using SRU40,
SRU60, SRU80, SRU200, or SRU400), and AR3600 (using SRUX5) series routers can be used in this
scenario.
As shown in Figure 12-17, the carrier MPLS network provides the L2VPN service for users
who access the network through low-speed TDM links. The backbone devices are connected
through the 4GECS interface cards on which the Combo interfaces work as electrical
interfaces with a rate of 1000 Mbit/s. Many users connect to the network through PE1 and
PE2, and users on the PEs change frequently. (This example lists only two user devices CE1
and CE2, and they are connected to the PEs which have 8E1T1-M interface cards installed.) A
proper VPN solution is required to provide secure VPN services for users, save network
resources, and simplify configuration when new users connect to the network.
Figure 12-17 Configuring TDM PWE3 using the 8E1T1-M interface card
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0

172.1.1.1/24 172.1.1.2/24 172.2.1.1/24 172.2.1.2/24
PE1 PE2
Serial2/0/0:0 P Serial2/0/0:0
Serial1/0/0:0 PW Serial1/0/0:0
192.168.1.1/24 192.168.1.2/24
CE1 CE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Martini, PWE3 reduces signaling costs and defines the multi-hop negotiation mode, making
networking more flexible. PWE3 is recommended if network resources need to be saved.
TDM PWE3 can be used to meet user requirements based on users' access modes.
1. Run an IGP protocol on the backbone network so that backbone devices can
communicate.
2. Enable basic MPLS capabilities, set up an LSP tunnel on the backbone network, and
establish a remote MPLS LDP peer relationship between the PEs at two ends of the PW.
3. Create an MPLS L2VC connection between CE1/PRI interfaces on the PEs to implement
TDM PWE3, so that users can communicate with each other.
4. Configure all the devices to work in clock synchronization state to ensure that CEs can
accurately exchange data with each other. In this example, the system clock of PE1 is
used as the clock source.
Procedure
Step 1 Configure IP addresses for the interfaces on the MPLS backbone network.

Configure an IGP protocol on the MPLS backbone network. In this example, OSPF is used.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After the configuration is complete, run the display ip routing-table command. You can view
that the devices have learnt routes to Loopback1 of each other.
Step 3 Enable MPLS, and set up LSPs and remote LDP sessions.
Enable MPLS on the MPLS backbone network and set up a remote MPLS peer relationship
between the PEs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command. You can
view that LDP sessions are established between PEs and between PEs and P, and the session
status is Operational.
Step 4 Configure user devices to access the PEs.
Configure interface parameters on the CEs and PEs because user devices access the PEs
through low-speed TDM links.
# Configure CE1.
[CE1] controller e1 1/0/0
[CE1-E1 1/0/0] using e1
[CE1-E1 1/0/0] quit
[CE1] interface serial 1/0/0:0
[CE1-Serial1/0/0:0] link-protocol ppp
[CE1-Serial1/0/0:0] ip address 192.168.1.1 255.255.255.0
[CE1-Serial1/0/0:0] quit
# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[PE1] controller e1 2/0/0

[PE1-E1 2/0/0] using e1
[PE1-E1 2/0/0] quit
[PE1] interface serial 2/0/0:0
[PE1-Serial2/0/0:0] link-protocol tdm
[PE1-Serial2/0/0:0] quit
# Configure PE2.
[PE2-E1 2/0/0] using e1
[PE2-E1 2/0/0] quit
[PE2-Serial2/0/0:0] link-protocol tdm
# Configure CE2.
[CE2-E1 1/0/0] using e1
[CE2-E1 1/0/0] quit
[CE2] interface serial 1/0/0:0
[CE2-Serial1/0/0:0] link-protocol ppp
[CE2-Serial1/0/0:0] ip address 192.168.1.2 255.255.255.0
[CE2-Serial1/0/0:0] quit
Step 5 Create a VC connection.

Enable MPLS L2VPN on PE1 and PE2, and create a VC connection between them.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1] pw-template pe2pe
[PE1-pw-template-pe2pe] peer-address 3.3.3.9
[PE1-pw-template-pe2pe] jitter-buffer depth 8
[PE1-pw-template-pe2pe] tdm-encapsulation-number 8
[PE1-pw-template-pe2pe] quit
[PE1-Serial2/0/0:0] mpls l2vc pw-template pe2pe 100
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2-Serial2/0/0:0] mpls l2vc pw-template pe2pe 100
Step 6 Configure the clock synchronization function.

Configure all the devices to work in clock synchronization state; otherwise, CEs cannot
accurately exchange data with each other. The system clock of PE1 is used as the clock source
for all the devices.
# Configure PE1.
[PE1-GigabitEthernet1/0/0] clock master

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-E1 2/0/0] clock system
[PE1-E1 2/0/0] quit
# Configure CE1.
[CE1-E1 1/0/0] clock slave
[CE1-E1 1/0/0] quit
# Configure the P.
[P-GigabitEthernet1/0/0] clock slave
[P] clock source 0 1/0/0
[P-GigabitEthernet2/0/0] clock master
# Configure PE2.
[PE2-GigabitEthernet1/0/0] clock slave
[PE2] clock source 0 1/0/0
[PE2-E1 2/0/0] clock system
[PE2-E1 2/0/0] quit
# Configure CE2.
[CE2-E1 1/0/0] clock slave
[CE2-E1 1/0/0] quit

# Check the L2VPN connections on PEs. You can see that an L2VC connection has been set
up and is in the Up state.
[PE1] display mpls l2vc interface serial 2/0/0:0
*client interface : Serial2/0/0:0 is up
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : SAT E1 over Packet
local TDM Encap Num : 8 remote TDM Encap Num : 8
jitter-buffer : 8
idle-code : ff
local rtp-header : disable remote rtp-header : disable
local bit-rate : 32 remote bit-rate : 32

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

VCCV State : up
link state : up
local VC MTU : -- remote VC MTU : --
PW template name : pe2pe
Access-port : false
VC last up time : 2013/11/02 09:30:04
CKey : 9
NKey : 8
Diffserv Mode : pipe
Service Class : ef
Color : green
DomainId : --
Domain Name : --

[CE1] ping 192.168.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
controller E1 1/0/0
using e1
#
interface Serial1/0/0:0
link-protocol ppp

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ip address 192.168.1.1 255.255.255.0

#
return
#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
pw-template pe2pe
#
mpls ldp
#
remote-ip 3.3.3.9
#
controller E1 2/0/0
using e1
clock system
#
link-protocol tdm
mpls l2vc pw-template pe2pe 100
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
clock master
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname P
#
clock source 0 1/0/0 priority 9
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
clock slave
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
clock master
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return

#
sysname PE2
#
clock source 0 1/0/0 priority 9
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
pw-template pe2pe
#
mpls ldp
#
remote-ip 1.1.1.9
#
controller E1 2/0/0
using e1
clock system
#
link-protocol tdm
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
clock slave
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return

#
sysname CE2
#
controller E1 1/0/0
using e1
#
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
#
return

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
12.10.7 Example for Configuring TDM PWE3 (Using the 8SA

interface card)
NOTE
Only the AR2220, AR2240 (using SRU40, SRU60, SRU80, SRU200, or SRU400), AR3200 (using SRU40,
SRU60, SRU80, SRU200, or SRU400), and AR3600 (using SRUX5) series routers can be used in this
scenario.
As shown in Figure 12-18, the MPLS network of an Internet service provider (ISP) provides
the L2VPN service for users who access the network through low-speed TDM links. Many
users connect to the network through PE1 and PE2, and users on the PEs change frequently.
(This example lists only two user devices CE1 and CE2, and they are connected to the PEs
which have 8SA interface cards installed.) A proper VPN solution is required to provide
secure VPN services for users, save network resources, and simplify configuration when new
users connect to the network.
Figure 12-18 Configuring TDM PWE3 using the 8SA interface card
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0

172.1.1.1/24 172.1.1.2/24 172.2.1.1/24 172.2.1.2/24
PE1 PE2
Serial2/0/0 P Serial2/0/0
Serial1/0/0 PW Serial1/0/0
192.168.1.1/24 192.168.1.2/24
CE1 CE2
Martini, PWE3 reduces signaling costs and defines the multi-hop negotiation mode, making
networking more flexible. PWE3 is recommended if network resources need to be saved.
TDM PWE3 can be used to meet user requirements based on users' access modes.
1. Run an IGP protocol on the backbone network so that backbone devices can
communicate.
2. Enable basic MPLS capabilities, set up an LSP tunnel on the backbone network, and
establish a remote MPLS LDP peer relationship between the PEs at two ends of the PW.
3. Create an MPLS L2VC connection between CE1/PRI interfaces on the PEs to implement
TDM PWE3, so that users can communicate with each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 1 Configure IP addresses for the interfaces on the MPLS backbone network.

Configure an IGP protocol on the MPLS backbone network. In this example, OSPF is used.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After the configuration is complete, run the display ip routing-table command. You can view
that the devices have learnt routes to Loopback1 of each other.
Step 3 Enable MPLS, and set up LSPs and remote LDP sessions.
Enable MPLS on the MPLS backbone network and set up a remote MPLS peer relationship
between the PEs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command. You can
view that LDP sessions are established between PEs and between PEs and P, and the session
status is Operational.
Step 4 Configure user devices to access the PEs.
Configure interface parameters on the CEs and PEs because user devices access the PEs
through low-speed TDM links.
# Configure CE1.
[CE1] interface serial 1/0/0
[CE1-Serial1/0/0] link-protocol ppp
[CE1-Serial1/0/0] ip address 192.168.1.1 255.255.255.0
[CE1-Serial1/0/0] physical-mode async
[CE1-Serial1/0/0] quit
# Configure PE1.
[PE1] interface serial 2/0/0
[PE1-Serial2/0/0] link-protocol tdm
[PE1-Serial2/0/0] physical-mode async
[PE1-Serial2/0/0] quit
# Configure PE2.
[PE2-Serial2/0/0] link-protocol tdm
[PE2-Serial2/0/0] physical-mode async
# Configure CE2.
[CE2] interface serial 1/0/0
[CE2-Serial1/0/0] link-protocol ppp
[CE2-Serial1/0/0] ip address 192.168.1.2 255.255.255.0
[CE2-Serial1/0/0] physical-mode async
[CE2-Serial1/0/0] quit
Step 5 Create a VC connection.

Enable MPLS L2VPN on PE1 and PE2, and create a VC connection between them.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-Serial2/0/0] mpls l2vc pw-template pe2pe 100
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2-Serial2/0/0] mpls l2vc pw-template pe2pe 100
# Check the L2VPN connections on PEs. You can see that an L2VC connection has been set
up and is in the Up state.

[PE1] display mpls l2vc interface serial 2/0/0
*client interface : Serial2/0/0 is up
session state : up
AC status : up
VC state : up
Label state : 0
Token state : 0
VC ID : 100
VC type : CESoPSN basic mode
local TDM Encap Num : 8 remote TDM Encap Num : 0
jitter-buffer : 8
idle-code : ff
local rtp-header : disable remote rtp-header : disable
local bit-rate : 0 remote bit-rate : 0
VCCV State : up
link state : up
local VC MTU : -- remote VC MTU : --
PW template name : pe2pe

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Access-port : false
VC last up time : 2013/11/02 09:30:04
CKey : 9
NKey : 8
Diffserv Mode : pipe
Service Class : ef
Color : green
DomainId : --
Domain Name : --

[CE1] ping 192.168.1.2

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
physical-mode async
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
pw-template pe2pe
#
mpls ldp
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

remote-ip 3.3.3.9
#
link-protocol tdm
physical-mode async
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
pw-template pe2pe
#
mpls ldp
#
remote-ip 1.1.1.9
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
link-protocol tdm
physical-mode async
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return

#
sysname CE2
#
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
physical-mode async
#
return
12.11 References for PWE3

This section provides references for PWE3.
The following table lists the references for PWE3.
Document Description Remark

s
RFC3916 Requirements for Pseudo-Wire Emulation Edge-to- -

Edge (PWE3)
RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) -

Architecture
RFC4446 IANA Allocations for Pseudowire Edge to Edge -

Emulation (PWE3)
draft-ietf-pwe3- Pseudo wire Setup and Maintenance using the Label -

control-protocol-17 Distribution Protocol
draft-martini-pwe3- Pseudo Wire Switching -

pw-switching-03
draft-ietf-pwe3-cw-00 PWE3 Control Word for use over an MPLS PSN -
draft-ietf-pwe3- Pseudo Wire Virtual Circuit Connectivity -

vccv-03 Verification (VCCV)

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Document Description Remark

s
draft-ietf-pwe3- Encapsulation Methods for Transport of Ethernet -

ethernet-encap-10 Over MPLS Networks
draft-ietf-pwe3-atm- Encapsulation Methods for Transport of ATM Over -

encap-11 MPLS Networks
draft-ietf-pwe3-cell- PWE3 ATM Transparent Cell Transport Service -

transport-05
RFC 5085 Pseudowire Virtual Circuit Connectivity Verification The

(VCCV) A Control Channel for Pseudowires device
does not
support
PW
VCCV in
L2TP V3
mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 13 VPLS Configuration
13 VPLS Configuration
About This Chapter
This chapter describes principles, applications, and configurations of the Virtual Private LAN
Service (VPLS).
13.1 Overview of VPLS

This section describes the definition, background, and functions of VPLS.
13.2 Understanding VPLS
This section describes the implementation of VPLS.
13.3 Application Scenarios for VPLS
This section describes the application scenarios for VPLS.
13.4 Licensing Requirements and Limitations for VPLS
13.5 Default Settings for VPLS
This section provides the default settings for VPLS.
13.6 Configuring Martini VPLS
This section describes how to configure VPLS in Martini mode using LDP as the signalling
protocol.
13.7 (Optional) Configuring Inter-AS Martini VPLS
Inter-AS VPLS allows a VPLS network to span multiple ASs on an MPLS backbone network.
13.8 (Optional) Setting Related Parameters for a VSI
This section describes how to set related parameters for a VSI.
13.9 Maintaining VPLS
VPLS maintenance includes collecting, clearing, and viewing traffic statistics on VPLS PWs,
enabling or disabling VSIs, clearing MAC address entries, and detecting the VPLS network
connectivity.
13.10 Configuration Examples for VPLS
This section provides several configuration examples of different VPLS networking,
including networking requirements, configuration notes, configuration roadmap,
configuration procedures, and configuration files.
13.11 Troubleshooting VPLS

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
This section describes common faults caused by incorrect VPLS configurations and provides
the troubleshooting procedure.
13.12 References for VPLS
This section lists references for VPLS.
13.1 Overview of VPLS

This section describes the definition, background, and functions of VPLS.
Definition
As a Multiprotocol Label Switching (MPLS)-based point-to-multipoint (P2MP) Layer 2
Virtual Private Network (L2VPN) service provided over a public network, the virtual private
LAN service (VPLS) ensures that geographically isolated user sites can communicate over
metropolitan area networks (MANs) and wide area networks (WANs) as if they were on the
same local area network (LAN). VPLS is also called the Transparent LAN Service (TLS).
Figure 13-1 shows a typical VPLS networking mode. In this networking, users located in
different geographical regions communicate with each other over different provider edges
(PEs). From the perspective of users, a VPLS network is a Layer 2 switched network that
allows them to communicate with each other in a way similar to communication over a LAN.
Figure 13-1 Typical VPLS networking
VPN1 VPN1
site1 CE1 CE3 site3
PE1 PE2
MPLS Backbone
VPN2
CE2 VPN2
PE3 CE4
site2 site4
CE5
VPN1
site5

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Purpose
As enterprises set up more and more branches in different regions and office flexibility
increases, applications such as VoIP, instant messaging, and teleconferencing are increasingly
widely used. This imposes high requirements for end-to-end (E2E) datacom technologies. A
network capable of providing P2MP services is the key to datacom function implementation.
Traditional asynchronous transfer mode (ATM) and frame relay (FR) technologies provide
only Layer 2 point-to-point (P2P) connections. In addition, those network types have
disadvantages such as high construction costs, low speed, and complex deployment. The
development of Internet Protocol (IP) has led to MPLS VPN technology, which can provide
VPN services over an IP network and offers advantages such as easy configuration and
flexible bandwidth control. MPLS VPNs can be classified into MPLS L2VPNs and MPLS
L3VPNs.
l Traditional MPLS L2VPNs, such as the virtual leased lines (VLLs), can provide P2P
services but not P2MP services over a public network.
l MPLS L3VPNs can provide P2MP services on the precondition that PEs keep routes
destined for end users. This implementation requires high routing performance of PEs.
To solve the preceding problems, VPLS, an MPLS-based Ethernet technology, is introduced
as an extension to a traditional MPLS L2VPN solution.
l Like Ethernet, VPLS supports P2MP communication.
l VPLS is a Layer 2 label switching technology. From the perspective of users, the entire
MPLS IP backbone network is a Layer 2 switching device. PEs do not need to keep
routes destined for end users.
VPLS provides a more complete multipoint communication solution, integrating the
advantages provided by Ethernet and MPLS. By emulating traditional LAN functions, VPLS
enables users on different LANs to communicate with each other over IP/MPLS networks as
if they were on the same LAN.
Benefits
l VPLS networks can be constructed based on carrier's IP networks, reducing construction
costs.
l VPLS networks inherit the high-speed advantage of the Ethernet.
l VPLS networks allow users to communicate over Ethernet links, regardless of whether
these links are on WANs or LANs. This feature allows services to be rapidly and flexible
deployed.
l VPLS allows enterprises to control and maintain routing policies on their networks,
improving the VPN network security and maintainability.
13.2 Understanding VPLS

This section describes the implementation of VPLS.
Basic VPLS Transport Structure
Figure 13-2 shows an example of a VPLS network. The entire VPLS network is similar to a
switch. PWs are established over MPLS tunnels between VPN sites to transparently transmit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Layer 2 packets between sites. When forwarding packets, Provider edges (PEs) learn the
source MAC addresses of these packets and create MAC entries, mapping MAC addresses to
attachment circuits (ACs) and pseudo wires (PWs).
The following table describes the various concepts related to VPLS networks.
Table 13-1 Description of VPLS concepts

Name Description
AC A link between a CE and a PE. An AC must be established using Ethernet

interfaces.
On a VPLS network, AC interfaces can be Ethernet interfaces, Ethernet
sub-interfaces.
PW A bidirectional virtual connection between two virtual switch instances

(VSIs) residing on two PEs. A PW consists of a pair of unidirectional
MPLS VCs transmitting in opposite directions.
A PW is a direct tunnel connecting the local AC and the remote AC, and
transparently transmits Layer 2 data.
VSI A virtual switching unit on the switch for each VPLS. Each VSI has an
independent MAC address table and a forwarder. A VSI is responsible for
terminating PWs.
PW signal A type of signaling used to create and maintain PWs. PW signaling is the
foundation for VPLS implementation. Currently, the PW signaling is
Label Distribution Protocol (LDP).
Tunnel A connection between a local PE and a remote PE used to transparently

transmit data between PEs. A tunnel can carry multiple PWs and the
tunnel type can be Label Switched Path (LSP).
Forwarder Similar to a VPLS forwarding table. After a PE receives packets from an

AC, the forwarder of the PE selects a PW to forward these packets.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-2 Basic VPLS transmission process
VPN1
Site3
VPN1
Site5 CE3
CE5 PE3
VPN2
Site4
MPLS CE4
Network
Forwarder PE2
PE1
CE1 AC
VPN1 CE2 PW
Site1 VPN2
Site2 PW Signal
Tunnel
The following uses the unicast packets sent from CE1 to CE3 in VPN1 as an example to
describe how a data flow is transmitted on a VPLS network.
1. PE1, PE2, and PE3 belong to the same VPLS domain. AC links connected to the VPLS
domain are mapped to PWs through a VSI to generate the forwarder of the VSI.
2. When CE1 receives a Layer 2 packet from a user at Site1, it forwards the Layer 2 packet
to PE1 through the AC link.
3. After receiving the packet, PE1 finds that the packet needs to be forwarded in VPLS
mode. PE1 then selects a PW from the forwarder to forward the packet based on the
destination MAC address of the packet.
4. PE1 generates double labels according to the forwarding entry of the PW. The inner
private network label identifies the PW, and the outer public network label enables the
packet to reach PE2 through the tunnel on the public network. Meanwhile, PE1 searches
for the destination MAC address based on the MAC address table index and encapsulates
the packet.
5. After the Layer 2 packet arrives at PE2 through the tunnel on the public network, the
private network label becomes the outer label (the public network label has been popped
out at the penultimate hop).
6. Upon receiving the packet, PE2 selects a VSI for forwarding the packet according to the
private network label, removes the private network label, and selects the forwarder of the
VSI. The forwarder forwards the Layer 2 packet to CE3 according to the destination
MAC address.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
VPLS Implementation Process

In Figure 13-2, transmission of packets between Customer Edges (CEs) relies on VSIs
configured on PEs, and PWs established between the VSIs. Figure 13-3 shows transmission
of Ethernet frames over full-mesh PWs between PEs.
Figure 13-3 VPLS forwarding model
CE1 CE3
VLAN1 VLAN1
VSI 1 VSI 1
PE1 PE3
VSI 2 VSI 2
CE4 CE6
VLAN2 VSI 1 VSI 2 VLAN2
PE2
CE2 CE5
VLAN1 VLAN2
A VPLS network consists of a control plane and a forwarding plane.
l The control plane of a VPLS PE provides the PW establishment function, including:

– Member discovery: a process in which a PE in a VSI discovers the other PEs in the
same VSI. This process can be implemented manually.
– Signaling mechanism: PWs between PEs in the same VSI are established,
maintained, or torn down using signaling protocols.
l The forwarding plane of a VPLS PE provides the data forwarding function, including:
– Encapsulation: After receiving Ethernet frames from a CE, a PE encapsulates the
frames into packets and sends the packets to VPLS network.
– Forwarding: A PE determines how to forward a packet based on the inbound
interface and destination MAC address of the packet.
– Decapsulation: After receiving packets from VPLS network, a PE decapsulates
these packets into Ethernet frames and sends the frames to a CE.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.2.2 PW Signaling Protocols
PW Signaling Protocols and VPLS Implementation Modes

A PW mainly uses LDP as its signaling protocol and LDP is the basis for implementation of
LDP VPLS.
LDP VPLS
Introduction to LDP VPLS
LDP VPLS (Martini VPLS) uses a static discovery mechanism to discover VPLS members
using LDP signaling. VPLS information is carried in extended TLV fields (type 128 and type
129 FEC TLVs) of LDP signaling packets. During the establishment of a PW, the label
distribution mode is downstream unsolicited (DU) and the label retention mode is liberal.
Implementation process
l Figure 13-4 shows the process of establishing a PW using LDP signaling.
Figure 13-4 Establishing a PW using LDP signaling
Label Mapping Message:

PW ID+VC Label
VSI VSI
VC1
VC2
PE1 PE2
Label Mapping Message:

PW ID+VC Label
a. After PE1 is associated with a VSI, and PE2 is configured as a peer of PE1, PE1
sends a Label Mapping message to PE2 in DU mode if an LDP session already
exists between PE1 and PE2. The Label Mapping message carries information
required to establish a PW, such as the PW ID, VC label, and interface parameters.
b. Upon receipt of the message, PE2 checks whether itself has been associated with
the VSI. If PE2 has been associated with the VSI and PW parameters on PE1 and
PE2 are consistent, PE1 and PE2 belong to the same VSI. In this case, PE2
establishes a unidirectional VC named VC1 immediately after PE2 receives the
Label Mapping message. Meanwhile, PE2 sends a Label Mapping message to PE1.
After receiving the message, PE1 takes a similar sequence of actions to PE2 and
establishes VC2.
l Figure 13-5 shows the process of tearing down a PW using LDP signaling.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-5 Tearing down a PW using LDP signaling
Label Withdrawal Message
VSI VC1 VSI

X
X
PE1 VC2 PE2
Label Release Message
a. After the peer configuration about PE2 is deleted from PE1, PE1 sends a Label
Withdrawal message to PE2. After receiving the Label Withdrawal message, PE2
withdraws its local VC label, tears down VC1, and sends a Label Release message
to PE1.
b. After receiving the Label Release message, PE1 withdraws its local VC label and
tears down VC2.
13.2.3 Packet Encapsulation
Packet Encapsulation on ACs

Packet encapsulation on ACs depends on the user access mode, which can be VLAN or
Ethernet access. The default user access mode is VLAN access.
Table 13-2 Packet encapsulation on ACs

Packet Description
Encapsulati
on Type
VLAN The header of each Ethernet frame sent between CEs and PEs carries a
VLAN tag, known as the provider-tag (P-Tag). This is a service delimiter
identifying users on an ISP network.
Ethernet The header of each Ethernet frame sent between CEs and PEs does not
carry a P-Tag. If the frame header contains a VLAN tag, it is an inner
VLAN tag called the user-tag (U-Tag). A CE does not add the U-Tag to an
Ethernet frame; instead, the tag is carried in a packet before the packet is
sent to the CE. A U-Tag informs the CE to which VLAN the packet
belongs, and is meaningless to PEs.
Packet Encapsulation on PWs

The PW ID and PW encapsulation type uniquely identify a PW. The PW IDs and PW
encapsulation types configured on the two end PEs of a PW must be the same. The packet
encapsulation types of packets on PWs can be raw or tagged. By default, packets on PWs are
encapsulated in tagged mode.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 13-3 Packet encapsulation on PWs

Packet Description
Encapsulatio
n Type
Raw Packets transmitted over a PW cannot carry P-Tags. If a PE receives a

packet with the P-Tag from a CE, the PE strips the P-Tag and adds double
labels (outer tunnel label and inner VC label) to the packet before
forwarding it. If a PE receives a packet with no P-Tag from a CE, the PE
directly adds double labels (outer tunnel label and inner VC label) to the
packet before forwarding it. The PE determines whether to add the P-Tag
to a packet based on actual configurations before sending it to a CE. The
PE is not allowed to rewrite or remove an existing U-Tag.
Tagged Packets transmitted over a PW must carry P-Tags. If a PE receives a

packet with the P-Tag from a CE, the PE directly adds double labels
(outer tunnel label and inner VC label) to the packet before forwarding it.
If a PE receives a packet with no P-Tag from a CE, the PE adds a null P-
Tag and double labels (outer tunnel label and inner VC label) to the
packet before forwarding it. The PE determines whether to rewrite,
remove, or preserve the P-Tag of a packet based on actual configurations
before forwarding it to a CE.
VPLS Packets and Encapsulation Modes

Encapsulation modes of packets transmitted over ACs and PWs can be used together. The
following uses Ethernet+raw encapsulation (without the U-Tag) and VLAN+tagged
encapsulation (with the U-Tag) as examples to describe the packet exchange process.
l Ethernet+raw encapsulation (without the U-Tag)
Figure 13-6 Ethernet+raw encapsulation (without the U-Tag)
CE1
AC L2 Header IP Header Data
PE1
PW L2 Header Tunnel Label VC Label L2 Header IP Header Data
PE2
AC L2 Header IP Header Data
CE2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
As shown in Figure 13-6, ACs use Ethernet encapsulation and PWs use raw
encapsulation; packets transmitted from CEs to PEs do not carry U-Tags.
The packet exchange process is as follows:
a. CE1 sends a Layer 2 packet without a U-Tag or P-Tag to PE1.
b. PE1 searches the corresponding VSI for a forwarding entry and selects a tunnel and
a PW to forward the packet based on the found forwarding entry.
c. PE2 receives the packet from PE1 and decapsulates the packet by removing the
Layer 2 encapsulation header added by PE1 and the inner VC label of the packet
(the outer tunnel label has been popped out at the penultimate hop).
d. PE2 sends the original Layer 2 packet to CE2.
The processing of sending a packet from CE2 to CE1 is similar to this process.
l VLAN+tagged encapsulation (with the U-Tag)
Figure 13-7 VLAN access in tagged mode (with the U-Tag)
CE1
L2 IP
AC P-TAG U-TAG Data
Header Header
PE1
L2 Tunnel VC L2 IP
PW P-TAG U-TAG Data
Header Label Label Header Header
PE2
L2 IP
AC P-TAG U-TAG Data
Header Header
CE2
As shown in Figure 13-7, ACs use VLAN encapsulation and PWs use tagged
encapsulation; packets transmitted from CEs to PEs carry U-Tags and P-Tags.
The packet exchange process is as follows:
a. CE1 sends a packet that has Layer 2 encapsulation and carries both a U-Tag and a
P-Tag to PE1.
b. Upon receipt, PE1 does not process the two tags. PE1 retains the U-Tag because it
treats the U-tag service data.
c. PE1 retains the P-Tag because a packet sent to a PW with the tagged packet
encapsulation mode must carry a P-Tag.
d. PE1 searches the corresponding VSI for a forwarding entry and selects a tunnel and
a PW to forward the packet based on the found forwarding entry.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
e. PE1 adds double labels (outer tunnel label and inner VC label) to the packet based
on the selected tunnel and PW, performs Layer 2 encapsulation, and forwards the
packet to PE2.
f. PE2 receives the packet from PE1 and decapsulates the packet by removing the
Layer 2 encapsulation header added by PE1 and the inner VC label of the packet
(the outer tunnel label has been popped out at the penultimate hop).
g. PE2 forwards the original Layer 2 packet to CE2. The packet carries the U-Tag and
P-Tag.
The processing of sending a packet from CE2 to CE1 is similar to this process.
Processing of Tags Carried in Packets

A PE device processes tags carried in packets based on the AC interface type.
Tag processing is not affected by the PW encapsulation type.
Table 13-4 PE's Tag Processing for Packets from an AC to a PW

AC Interface Type Packet Processing on the Packet Processing on the
AC Interface PW Interface
Main interface (Ethernet or Does not process the packet. l Does not process the
GE interface) packet if the default
VLAN of the AC
Dot1q termination sub- Removes the outer VLAN interface is not VLAN 0.
interface tag.
l Adds VLAN 0 to the
QinQ termination sub- Removes the inner and outer packet if the default
interface VLAN tags. VLAN of the AC
interface is VLAN 0.
Table 13-5 PE's Tag Processing for Packets from a PW to an AC

AC Interface Type Packet Processing on the Packet Processing on the
PW Interface AC Interface
Main interface (Ethernet or l Does not process the Does not process the packet.
GE interface) packet if the default
VLAN of the AC
Dot1q termination sub- interface is not VLAN 0. Adds an outer VLAN tag.
interface
l Removes VLAN 0 from
QinQ termination sub- the packet if the default Adds inner and outer VLAN
interface VLAN of the AC tags.
interface is VLAN 0.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.2.4 MAC Address Management
Background
A characteristic of the Ethernet is that an interface sends unicast packets with unknown
destination MAC addresses, broadcast packets, and multicast packets to all other interfaces on
the Ethernet. As an Ethernet-based technology, VPLS emulates an Ethernet bridge for user
networks. To forward packets on a VPLS network, PEs must establish MAC address tables
and forward packets based on MAC addresses or MAC addresses and VLAN tags.
MAC Address Learning and Flooding

MAC address learning
PEs create MAC address tables based on dynamic MAC address learning and associates
destination MAC addresses with PWs.
Table 13-6 describes MAC address learning modes.
Table 13-6 MAC address learning modes

MAC Address Description Characteristic
Learning
Mode
Qualified A PE learns the MAC addresses and The broadcast domain is

VLAN tags of received Ethernet confined to each user VLAN.
frames. In this mode, each user VLAN Qualified learning can result
is an independent broadcast domain in large Forwarding
and has independent MAC address Information Base (FIB) table
space. sizes, because the logical
MAC address is now a VLAN
tag + MAC address.
Unqualified A PE learns only the MAC addresses If an AC interface is

of Ethernet frames. In this mode, all associated with multiple user
user VLANs share the same broadcast VLANs, this AC interface
domain and MAC address space. The must be a physical interface
MAC address of each user VLAN bound to a unique VSI.
must be unique.
NOTE
At present, the device supports only MAC address learning in unqualified mode.
Flooding
Packets with unknown addresses are broadcast in Ethernet. Therefore, in VPLS, the received
packets with unknown unicast addresses, broadcast addresses, or multicast addresses are
flooded to all the other interfaces. If these packets need to be forwarded in multicast mode,
PEs use other methods such as Internet Group Management Protocol (IGMP) snooping.
Implementation

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 13-7 describes the MAC address learning process.
Table 13-7 MAC address learning process
MAC Address Description

Learning Process
Learning MAC After receiving packets from a CE, a PE maps their source
addresses from user-side MAC addresses to AC interfaces. Figure 13-8 shows a
packets mapping example with Port1.
Learning MAC A PW consists of a pair of MPLS Virtual Circuits (VCs)

addresses from PW-side transmitting in opposite directions. A PW will go Up only after
packets the two MPLS VCs are established. After a PE receives a
packet with an unknown source MAC address from a PW, the
PE maps the source MAC address to the PW receiving the
packet.
Figure 13-8 shows the process of MAC address learning and flooding on a PE. PC1 and PC2
both belong to VLAN10. When PC1 pings IP address 10.1.1.2, PC1 does not know the MAC
address corresponding to this IP address and advertises an Address Resolution Protocol
(ARP) Request packet.
Figure 13-8 MAC address learning and flooding process

PE1 PE3
VSI MAC Port VSI MAC Port
VPN1 A VLAN10, port1 VPN1 A PW2
VPN1 B PW1
CE1 PE1 PE3 CE3
Port1 PW2
PW1 PW3
PC3
PC1 MAC: C
PE2
MAC: A IP: 10.1.1.3/24
IP: 10.1.1.1/24 Port2
VLAN: 10 PE2
CE2 VSI MAC Port
VPN1 A PW1
VPN1 B VLAN10, port2
MAC: B
IP: 10.1.1.2/24 PC2 ARP Broadcast
VLAN: 10
ARP Reply

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. After receiving the ARP Request packet sent by PC1 from Port1 (VLAN10) that
connects to CE1, PE1 adds the MAC address of PC1 to its own MAC address table, as
shown in the blue section of the MAC entry.
2. PE1 floods the ARP Request packet (the blue dotted line on PE1) to other interfaces
(PW1 and PW2 are regarded as interfaces at this time).
3. After receiving the ARP Request packet from PW1, PE2 adds the MAC address of PC1
to its own MAC address table, as shown in the blue section of the MAC entry.
4. Based on split horizon, PE2 sends the ARP Request packet to only the interface
connecting to CE2 (as indicated by the blue dashed line), but not to PW1. This ensures
that only PC2 receives the ARP Request packet. VPLS split horizon ensures that packets
received from public network PWs are forwarded to only private networks, not to other
public network PWs.
5. After PC2 receives the ARP Request packet and finds that it is the destination of this
packet, PC2 sends an ARP Reply packet to PC1 (as indicated by the orange dashed line).
6. After receiving the ARP Reply packet from PC2, PE2 adds the MAC address of PC2 to
its own MAC address table, as indicated by the orange section of the MAC entry. The
destination MAC address of the ARP Reply packet is the MAC address of PC1 (MAC
A). After searching its MAC address table, PE2 sends the ARP Reply packet to PE1 over
PW1.
7. After receiving the ARP Reply packet from PE2, PE1 adds the MAC address of PC2 to
its own MAC address table, as shown in the orange section of the MAC entry. After
searching its MAC address table, PE1 sends the ARP Reply packet to PC1 through
Port1.
8. After receiving the ARP Reply packet from PC2, PC1 completes MAC address learning.
9. While advertising the ARP Request packet to PW1, PE1 also advertises the ARP
Request packet to PE3 over PW2. After receiving the ARP Request packet, PE3 adds the
MAC address of PC1 to its MAC address table, as shown in the blue section of the MAC
entry. Based on split horizon, PE3 sends the ARP Request packet to only PC3. Because
PC3 is not the destination of the ARP Request packet, PC3 does not send any ARP
Reply packet.
MAC Address Withdrawal

Dynamic MAC addresses need to be updated and relearned. The VPLS draft defines a MAC
Withdraw message with an optional MAC type-length-value (TLV) to remove or relearn the
MAC address list.
When the topology changes, MAC Withdraw messages enable devices to delete matching
MAC addresses quickly. MAC Withdraw messages are classified into two types:
l Messages with a MAC address list

l Messages without a MAC address list
When a backup link (AC link or VC link) becomes Up, a PE that detects the link status
change receives a MAC Withdraw message carrying a list of MAC addresses to be relearned.
After receiving the message, the PE updates the MAC address entries in the forward
information base (FIB) table of the corresponding VSI, and sends the message to PEs directly
connected to it through Label Distribution Protocol (LDP) sessions. If the MAC Withdraw
message contains an empty MAC address list TLV, the PE deletes all the MAC addresses in
the specified VSI except the MAC address learned from the PE that sends the message.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
MAC Address Aging

An aging mechanism removes MAC entries that a PE no longer needs. If a MAC entry is not
updated within a specified period of time, this entry will be aged.
13.2.5 Loop Prevention

On an Ethernet network, the Spanning Tree Protocol (STP) is often enabled to prevent loops.
However, VPLS users are not aware of the Internet Service Provider (ISP) network.
Therefore, STP enabled on the private network cannot prevent loops on the ISP network.
VPLS uses full-mesh PWs and split horizon to prevent loops.
l The PEs in a VSI must be fully meshed. That is, a PE must create a tree to every other
PE in the VSI.
l Each PE must support split horizon to avoid loops. Split horizon requires that packets
received from a PW in a VSI should not be forwarded to other PWs in the VSI. Any two
PEs in a VSI must communicate over a direct PW, which is why full-mesh PWs are
required between PEs in a VSI.
The full-mesh PEs and split horizon ensure route reachability and prevent loops on a VPLS
network. When a CE is connected to multiple PEs, or CEs on the same VPLS VPN are
interconnected, VPLS cannot avoid loops. In such a situation, other methods must be used to
prevent loops.
STP can run on an L2VPN private network, and all STP Bridge Protocol Data Units (BPDUs)
are transparently transmitted over the ISP network.
13.2.6 Inter-AS VPLS

Inter-AS VPLS refers to the application of the VPLS across multiple autonomous systems
(ASs). There are two inter-AS VPLS implementation modes: Option A and Option C.
When using the inter-AS VPLS, you do not need to consider the learning or forwarding
functions of VSIs, but consider the establishment of PWs between PEs. In this manner, the
inter-AS VPLS has the same principle and implementation method as those of inter-AS
L2VPN.
In Option A, configurations are easy, without the need to run MPLS between ASBRs or
perform particular configurations for inter-AS communications. Nevertheless, this mode has
the poor expansion ability and higher requirements for PEs. This mode is applicable in the
early servicing stage when the number of inter-AS VPNs is small.
Inter-AS Martini VPLS (Option A)

Figure 13-9 shows the networking of the inter-AS Martini VPLS (Option A).

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-9 Networking diagram of inter-AS Martini VPLS (Option A)
VPLS Backbone VPLS Backbone

AS 100 AS 200
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32
PE1 ASBR1 ASBR2 PE2
VLAN 10 VLAN 10
CE1 CE2
The inter-AS Martini VPLS (Option A) is implemented as follows:

l An IGP protocol is configured on the backbone network to implement the
communications between devices in the same AS.
l The basic MPLS functions are enabled on the backbone network; the dynamic LSP is set
up between the PE and ASBR in the same AS; a remote LDP session is set up between
the PE and ASBR if they are not directly connected.
l The VPLS connection is set up between the PE and ASBR in the same AS.
Inter-AS Martini VPLS (Option C)

The OptionA scheme requires ASBRs to participate in the distribution and maintenance of
PW labels. When multiple inter-AS PWs exist in each AS, ASBRs may be a bottleneck in
network expansion.
Inter-AS VPWS Option C avoids this problem by freeing ASBRs from setting up and
maintaining PWs. PW labels are directly switched between PEs, as shown in Figure 13-10.
In inter-AS VPWS Option C:
l ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through
Multiprotocol Interior Border Gateway Protocol (MP-IBGP), and advertise labeled IPv4
routes received by PEs in their respective ASs to the ASBR peers in other ASs. ASBRs
in the intermediate AS also advertise labeled IPv4 routes. As a result, an LDP LSP is set
up between the ingress PE and the egress PE.
l PEs in different ASs set up remote MPLS LDP sessions to exchange PW information.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-10 Networking diagram of inter-AS Martini VPLS (Option C)
BGP/MPLS BGP/MPLS
backbone backbone
EBGP
AS 100 AS 200
MP-IBGP MP-IBGP
ASBR1 ASBR2
PE1 Remote LDP Peer PE2
LSP
CE1 CE2
Inter-AS VPWS Option C has the following advantages:

l Similar to the network on which L2VPN users belong to the same AS, intermediate
devices do not need to store L2VPN information.
l Only PEs need to store L2VPN information. The devices in intermediate ASs only need
to function as ordinary ASBRs that support IP forwarding and do not need to support
L2VPN. Inter-AS virtual private wire service (VPWS) Option C is preferred when users
need to communicate across a large number of ASs.
13.3 Application Scenarios for VPLS

This section describes the application scenarios for VPLS.
13.3.1 VPLS Application in Individual Services
Service Overview
Individual services such as high speed Internet (HSI), voice over IP (VoIP), and broadband
TV (BTV) are usually carried over carriers' metropolitan area networks (MANs).
Individual service gateways (such as SR and terminal access gateway) are deployed at the
MAN egress. Layer 2 packets of a user need to be transparently transmitted to a service
gateway using VPLS or VLL technology. If Layer 2 packets are terminated on a PE and
forwarded through Layer 3 routing, user information in the Layer 2 packets is lost. The
service gateway fails to control the user because it cannot receive the user information. When
the primary and secondary service gateways are deployed on the MAN, user traffic needs to
be dual homed to the access service gateways. The VPLS technology must be used to achieve
this goal.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Individual services are transmitted to the Internet over the access layer, convergence layer,
and core layer of a MAN. Figure 13-11 shows the typical networking for individual services.
l HSI services access the Internet over the MAN.

l VoIP services request IP addresses from the Dynamic Host Configuration Protocol
(DHCP) server over the MAN.
l BTV multicast members apply for BTV services from multicast sources over the MAN.
Figure 13-11 Typical networking for individual services
DHCP
Server
NMS Source
Internet
MSCG1 MSCG2
/Terminal IP Core /Terminal
Access1 Access2
/SR1 /SR2 Core layer
PE3 PE4
VPLS
Aggregation layer
PE1 PE2
DSLAM Access layer
HG
PW
Backup PW
HSI VOIP BTV
Feature Deployment
VPLS is configured on PEs to transparently transmit traffic between them. Figure 13-11 uses
LDP VPLS as an example to show VPLS configuration:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Access-layer devices
VLANs are configured to differentiate different types of users.
PPPoE over AAL5 (PPPoEoA) and PPP over AAL5 (PPPoA) are configured to allow
access of HSI users through dialup.
Multicast VLAN and IGMP snooping are configured to transmit multicast services.
l Aggregation-layer devices
Interior Gateway Protocols (IGPs) are configured on PEs so that these PEs can
Basic MPLS functions are configured on PEs so that these PEs can establish remote LDP
sessions.
MPLS L2VPN and VSIs are configured on PEs.
A VPLS daisy chain is deployed on PEs to transmit multicast services.
l Core-layer devices
Authentication and accounting features are configured on terminal access gateway so
that terminal access gateway can terminate HSI services.
IGPs are configured on Service Routers (SRs) so that these SRs can communicate with
each other.
Basic MPLS functions are configured on SRs.
DHCP relay is configured on SRs, allowing VoIP users to obtain IP addresses from
DHCP servers.
Layer 3 multicast features are configured on SRs so that these SRs can communicate
with multicast sources.
13.3.2 VPLS Application in Enterprise Services
Service Overview
As enterprises set up more and more branches in different regions and office flexibility
increases, applications such as instant messaging and teleconferencing are increasingly widely
used. This imposes high requirements for E2E datacom technologies. A network capable of
providing P2MP services is the key to datacom function implementation. To ensure enterprise
data security, secure, reliable, and transparent data channels must be provided for multipoint
transmission.
An enterprise has multiple branches located in different regions across a MAN. Layer 2
service packets between enterprise branches need to be transmitted over the MAN using the
VPLS technology, so that the enterprise branches in different regions can communicate with
each other.
Enterprise services are transmitted over a MAN. Figure 13-12 shows a typical VPLS network
transmitting enterprise services. An enterprise has multiple branches. Site1, Site2, and Site3
are R&D departments. VPLS features are deployed to implement Layer 2 network
communication between the sites.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-12 Typical networking for enterprise services
Site3
VPN1
CE3
PE3
PE1 IP Core PE2
CE1 CE2
Site1 Site2
VPN1 VPN1
Feature Deployment
VPLS is configured on PEs to transparently transmit traffic between PEs. From the
perspective of enterprise users, the public network is like a Layer 2 switch. Figure 13-12 uses
LDP VPLS as an example to show VPLS configuration:
l Access-layer devices
VLAN is configured to differentiate different types of enterprise users.
l Convergence-layer devices
An IGP is configured on PEs for these PEs to communicate with each other.
Basic MPLS functions are configured on PEs so that these PEs can establish remote LDP
sessions.
MPLS L2VPN and VSIs are configured on PEs. Dual-homing is used on a VPLS
network to protect traffic.
Limit on the number of learned MAC addresses and traffic suppression are configured
on PEs to protect data.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.4 Licensing Requirements and Limitations for VPLS

None
For VPLS-capable devices, their licensing requirements for the VPLS function are as follows:
l AR1200&AR2200&AR3200&AR3600 series: By default, VPLS function is disabled on

a new device. To use the VPLS function, apply for and purchase the following license
from the Huawei local office.
Feature Limitations
l The device supports IPv4 VPLS only.
l The device supports only the unqualified mode in which the device learns MAC
addresses.
l BPDUs including LACP, LLDP, and OAM packets cannot be transparently transmitted
on a VPLS network by default. The device can transparently transmit BPDUs only after
transparent transmission of BPDUs is enabled. For details, see (Optional) Configuring
Transparent Transmission of BPDUs.
If both transparent transmission of BPDUs and EFM are enabled, the device terminates
OAM packets locally.
l The device can select LSP tunnels to transmit the VPLS service.
The AR100&AR120&AR150&AR160&AR200 series routers do not support VPLS.
13.5 Default Settings for VPLS

This section provides the default settings for VPLS.
Table 13-8 Default settings for VPLS

MTU value in the VSI view 1500
LDP MAC Withdraw message sent by the Disabled

VSI
Encapsulation type of an interface in the VLAN

VSI view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Statistics about the public network traffic on Disabled

a specified Martini VPLS PW
13.6 Configuring Martini VPLS

This section describes how to configure VPLS in Martini mode using LDP as the signalling
protocol.
Pre-configuration Task
Before configuring Martini VPLS, complete the following tasks:
l Configuring the LSR ID on the PEs and Ps and enabling MPLS and MPLS LDP
l Establishing tunnels between PEs for transmitting data
l Setting up an LDP session if PEs are indirectly connected
To configure Martini VPLS, perform the following configurations on PEs at both ends of a
PW.
13.6.1 Creating a VSI and Configuring LDP Signaling
Context
When using LDP as the PW signaling, you must configure the VSI ID for a VSI. VSI IDs
differentiate VSIs, and you can use these VSI IDs during PW signaling negotiation.
Do as follows on the PEs of the two ends of the PW:
Procedure
Step 3 Run quit
Step 4 Run vsi vsi-name static
A VSI is created and the VSI view is displayed.
Step 5 Run pwsignal ldp
The PW signaling protocol is specified as LDP and the VSI-LDP view is displayed.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, no signaling mode is configured for a VSI.

Step 6 Run vsi-id vsi-id
The VSI ID is configured.
By default, no VSI ID is set.
NOTE
The two ends of the VSI must agree on the same vsi-id.
The VSI exists only on the PE. One PE can have multiple VSIs. One VPLS on a PE has only
one VSI.
Step 7 Run peer peer-address [ negotiation-vc-id vc-id ]
The VSI peer is configured.
By default, no peer is configured for a VSI.
Step 8 Run peer peer-address [ negotiation-vc-id vc-id ] pw pw-name
A PW is created and the VSI-LDP-PW view is displayed.
By default, no PW is created.
NOTE
If you have created a PW, you can run the command pw pw-name to enter the VSI-LDP-PW view in the
VSI-LDP view.
Step 9 (Optional) Run undo interface-parameter-type vccv

The device is configured to delete the VCCV byte following the interface parameter in
Mapping packets.
By default, a mapping packet carries the VCCV byte.
Step 10 Run quit
Return to the VSI-LDP view.
Step 11 (Optional) Configure common VSI parameters.
Common VSI parameters include the VSI encapsulation mode, MTU for negotiation, and VSI
description.
1. Run quit
Return to the VSI view.
2. Run encapsulation { ethernet | vlan }
The VSI encapsulation type is configured.
By default, the encapsulation type of the interface is VLAN.
The maximum transmission unit (MTU) for packets sent by the VSI is configured.
The default value of MTU in the VSI view is 1500.
When configuring MTUs, note that MTUs of VSIs created for the same VPLS on
different PEs must be the same.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
– When an interface is bound to a VSI, the MTU can be configured in the interface view but
does not take effect. The PW signaling uses the MTU that is configured in the VSI for PW
MTU negotiation.
– On the router, the MTU value is used only for signaling negotiation and does not limit the size
of forwarded packets.
4. Run description description
The VSI description is configured.
By default, the description of a VSI is empty.
----End
13.6.2 Binding VSIs to AC Interfaces
Context
Based on the type of link between a PE and a CE, a VSI is bound to an AC interface on the
PE in one of the following modes:
l Binding the VSI with the Ethernet interface or GE interface when the PE and the CE are
connected through the Ethernet interface
l Binding the VSI with the Ethernet sub-interface or GE sub-interface when the PE and the
CE are connected through the Ethernet sub-interface
The sub-interfaces can be dotlq sub-interfaces, QinQ sub-interfaces, VLAN mapping sub-
interfaces, or VLAN stacking sub-interfaces. For details on how to access the VPLS through a
sub-interface, see Configuring a Dot1q Termination Sub-interface and Connecting It to an
L2VPN and Configuring a QinQ Termination Sub-interface and Connecting It to an L2VPN
in the Huawei
Enterprise Routers Configuration Guide - Ethernet.
When Ethernet or GE interfaces are used as AC interfaces, the outer Tags carried in the
packets sent from the AC to the PW are U Tags (inserted by user devices, which are
meaningless to the SP) by default.
When sub-interfaces are used as AC interfaces, the outer Tags carried in the packets sent from
the AC to the PW are P Tags (inserted by SP devices, which are used to differentiate user
traffic) by default.
NOTE
l In the VPLS application, different CEs are transparently connected in the same LAN segment
through VSIs, and the IP addresses of the CEs must be different. The IP address of the interface that
connects the PE to the CE and the IP address of the CE must be in different network segments.
Otherwise, the local CE may learn incorrect ARP entries. This leads to traffic loss between CEs in
the same VSI.
l When used on an AC-side interface, the qinq protocol command enables the system to identify
incoming packets and Tag outgoing packets with the TPID. The TPID must use the default value
8100. Do not change the TPID.
Procedure
l Bind a VSI to an Ethernet interface.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Do as follows on the PEs at both ends of a PW:

a. Run system-view
c. (Optional) Run undo portswitch
The Layer 2 interface is configured as a Layer 3 interface.
d. (Optional) Run mpls l2vpn default vlan
The default VLAN of the Ethernet interface is set to VLAN 0.
By default, no default VLAN is configured for an Ethernet interface.
If the remote PE device can only receive packets with VLAN tags, this step is
required before you bind a VSI to the local Ethernet interface.
e. Run l2 binding vsi vsi-name
The VSI is bound to the Ethernet interface.
l Bind a VSI to an Ethernet sub-interface.
Do as follows on the PEs at both ends of a PW:
a. Run system-view
b. Run interface interface-type interface-number.subinterface-number
The Ethernet sub-interface view is displayed.
c. Run one of the following commands to configure an Ethernet sub-interface based
on site requirements.
n Run dot1q termination vid low-pe-vid
The single VLAN ID for dot1q encapsulation on a sub-interface is configured.
n Run qinq termination pe-vid pe-vid ce-vid ce-vid1 [ to ce-vid2 ]
The Double VLAN IDs for QinQ encapsulation on a sub-interface is
configured.
n Run vlan mapping vid vlan-id1 map-vlan vlan-id2
Single-tagged VLAN mapping is configured on the sub-interface.
n Run vlan stacking vid vlan-id1 [ to vlan-id2 ] pe-vid vlan-id3
VLAN stacking is configured on the sub-interface.
d. (Optional) Run mpls l2vpn default vlan
The default VLAN of the Ethernet sub-interface is set to VLAN 0.
By default, no default VLAN is configured for an Ethernet sub-interface.
If the remote PE device can only receive packets with VLAN tags, this step is
required before you bind a VSI to the local Ethernet sub-interface.
e. Run l2 binding vsi vsi-name
The VSI is bound with the Ethernet sub-interface.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.6.3 Verifying the Martini VPLS Configuration
Prerequisites
All Martini VPLS configurations are complete.
Procedure
l Run the display vsi [ name vsi-name ] [ verbose ] command to check information about
a VPLS VSI.
l Run the display l2vpn ccc-interface vc-type { all | vc-type } [ down | up ] command to
check information about the interface used by an L2VPN connection.
l Run the display vsi remote ldp [ [ router-id ip-address ] [ pw-id pw-id ] | verbose ]
command to check information about a remote VSI.
l Run the display vpls connection [ ldp | vsi vsi-name ] [ down | up ] [ verbose ]
command to check information about a VPLS connection.
l Run the display vpls forwarding-info [ vsi vsi-name [ peer peer-address [ negotiation-
vc-id vc-id | remote-site site-id ] ] | state { up | down } ] [ verbose ] command to check
forwarding information of all VSIs.
l Run the display vsi services { all | vsi-name | interface interface-type interface-number |
vlan vlan-id } command to check information about the AC interface associated with the
VSI.
l Run the display vsi pw out-interface [ vsi vsi-name ] command to check information
about the outgoing interface of a PW in a VSI.
l Run the display mpls label-stack vpls vsi vsi-name peer peer-ip-address vc-id vc-id
command to check the information about label stacks in a VPLS scenario.
----End
13.7 (Optional) Configuring Inter-AS Martini VPLS

Inter-AS VPLS allows a VPLS network to span multiple ASs on an MPLS backbone network.
Usage Scenario
If multiple ASs exist on an MPLS backbone network, the VPLS network carried over the
MPLS backbone network must be an inter-AS VPLS network. Currently, the following inter-
AS VPLS solutions are available:
l Inter-AS VPLS Option A:
This solution is recommended for scenarios where few inter-AS VPLS PWs are required.
In this solution, ASBRs must support VSIs, manage VPLS label blocks, and reserve
interfaces for inter-AS PWs. This solution poses high performance requirements for
ASBRs, but does not require inter-AS configurations to be performed on ASBRs.
l Inter-AS VPLS Option C:
This solution is recommended for scenarios where large numbers of inter-AS Martini
L2VPN are required. In this solution, ASBRs do not need to create or maintain PWs and
are not a significant factor in network expansion.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Perform one or more of the following configurations as required.
13.7.1 Configuring Inter-AS Martini VPLS in OptionA Mode

When VPLS is deployed in a large area, PEs may belong to different ASs. In this case, PWs
cannot be established between PEs through LDP. To solve the problem in a normal network,
configure inter-AS Martini VPLS.
Before configuring inter-AS Martini VPLS in OptionA mode, complete the following tasks:
l Configuring IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS.
l Configuring basic MPLS functions on the MPLS backbone network of each AS.
l Configuring MPLS LDP and establishing the LDP LSP for the MPLS backbone network
of each AS.
l Establishing a tunnel between the PE and ASBR within an AS.
Context
The configuration is described as follows:
l Configuring Martini VPLS in each AS.

l An ASBR considers a peer ASBR as a CE.
l No inter-AS configuration needs to be performed on ASBRs.
l No IP address needs to be configured for the interfaces connecting ASBRs.
For details, see 13.6 Configuring Martini VPLS.
NOTE
In inter-AS Martini VPLS OptionA, each ASBR must reserve an AC interface for each inter-AS VC.
OptionA can be used when the number of inter-AS VCs is small. Compared with the L3VPN, the inter-
AS L2VPN OptionA consumes more resources and requires more configuration workload. Therefore,
the inter-AS L2VPN OptionA is not recommended.

l Run the display vsi [ name vsi-name ] [ verbose ] command to check information about
a VPLS VSI.
l Run the display vsi remote ldp [ router-id ip-address ] [ pw-id pw-id ] command to
check information about a remote VSI.
l Run the display vpls connection [ ldp | vsi vsi-name ] [ down | up ] [ verbose ]
command to check information about a VPLS connection.
l Run the ping vpls mac mac-address vsi vsi-name [ vlan vlan-id | -c count | -m time-
value | -s packsize | -t timeout | -exp exp | -r replymode | -h ttl ] * command to check the
connectivity of Layer 2 links on the VPLS network.
l Run the trace vpls mac mac-address vsi vsi-name [ vlan vlan-id ] [ -t timeout | -f first-ttl
| -m max-ttl | -exp exp | -r replymode ] * command to check the PEs and P that packets

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
pass from the sender to the receiver and check the connectivity of Layer 2 links, which
helps locate the faulty node on the network.
NOTE
In OptionA mode, the ping and trace functions support intra-AS detection.
13.7.2 Configuring Inter-AS Martini VPLS in OptionC Mode

In inter-AS LDP VPLS Option C, ASBRs do not need to maintain inter-AS LDP VPLS
information or reserve interfaces for inter-AS LDP VPLS PWs. As LDP VPLS information is
exchanged only between PEs, this solution requires few resources and is easy to deploy.
Before configuring inter-AS Martini VPLS in OptionC mode, complete the following tasks:
l Configure IGP for the MPLS backbone network of each AS to ensure IP connectivity of
the backbone network within an AS.
l Configure basic MPLS functions on the MPLS backbone network of each AS.
l Configure MPLS LDP and establish the LDP LSP for the MPLS backbone network of
each AS.
l Set up the IBGP peer relationship between the PE and the ASBR of the same AS and set
up the EBGP peer relationship between two inter-AS ASBRs.
Procedure
Step 1 Configure the capability to exchange labeled IPv4 routes.
l Perform the following steps on each PE:

a. Run system-view
The Border Gateway Protocol (BGP) view is displayed.
An IBGP peer relationship is established between the local PE and ASBR in the
same AS.
e. Run peer ipv4-address label-route-capability
Exchange of the labeled IPv4 routes with the ASBR in the same AS is enabled.
l Perform the following steps on each ASBR:
a. Run system-view
The view of the interface connecting to the peer ASBR is displayed.
c. Run ip address ip-address { mask | mask-length }

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
d. Run mpls
MPLS is enabled on the interface.
e. Run mpls ldp
MPLS LDP is enabled on the interface.
f. Run quit
g. Run bgp { as-number-plain | as-number-dot }
h. Run peer ipv4-address as-number as-number
An IBGP peer relationship is established between the local PE and the remote PE in
the same AS.
i. Run peer ipv4-address connect-interface loopback interface-number
j. Run peer ipv4-address label-route-capability
Exchange of the labeled IPv4 routes with the remote PE in the same AS is enabled.
k. Run peer ipv4-address as-number as-number
l. Run peer ipv4-address label-route-capability [ check-tunnel-reachable ]
The capability to exchange labeled IPv4 routes with the peer ASBR is configured.
In inter-AS LDP VPLS Option C, an inter-AS LSP must be established and the
public network routes advertised between PEs and ASBRs carry MPLS labels.
An EBGP peer relationship must be established between ASBRs in different ASs
for them to exchange labeled IPv4 routes.
The public network routes carrying MPLS labels are advertised through MP-BGP.
According to RFC 3107, label mappings about routes can be piggybacked inside the
BGP Update messages that are used to advertise these routes. This feature is
implemented through an extended BGP attribute, which enables BGP peers to
process labeled IPv4 routes.
By default, BGP peers cannot process labeled IPv4 routes.
Step 2 Configure a routing policy on the ASBR to control label distribution.
After the routing policy is applied to an ASBR, the ASBR allocates MPLS labels to routes
received from a PE in the local AS before advertising the routes to the remote ASBR, and
reallocates MPLS labels to labeled IPv4 routes advertised to a PE in the local AS.
By default, an IPv4 route does not carry any MPLS label.
Perform the following steps on each ASBR:
1. Run system-view
2. Run route-policy policy-name1 permit node seq-number
A routing policy applicable to the local PE is created.
The device reallocates MPLS labels to labeled IPv4 routes advertised to a PE in the local
AS.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3. Run if-match mpls-label

Filtering out labeled IPv4 routes is configured as a matching rule for the routing policy.
Allocating MPLS labels to IPv4 routes is configured as an action for the routing policy.
5. Run quit
6. Run route-policy policy-name2 permit node seq-number
A routing policy applicable to the peer ASBR is created.
When an ASBR advertises the routes received from a PE in the same AS to the peer
ASBR, the ASBR allocates MPLS labels to the routes.
Allocating MPLS labels to IPv4 routes is configured as an action for the routing policy.
8. Run quit
The routing policy applicable to the local PE is applied.
The routing policy applicable to the peer ASBR is applied.
Step 3 Establish remote MPLS LDP sessions between PEs.
Configure an ASBR to send the loopback interface IP addresses of a PE device used for peer
relationship establishment to the ASBRs of other ASs and the PEs in different ASs.
l Perform the following steps on each ASBR:
a. Run system-view
c. Run network ip-address [ mask | mask-length ] [ route-policy route-policy-name ]
The capability to advertise the local PE's loopback interface address used for BGP
sessions to the peer ASBR is configured.
d. Run quit
l Perform the following steps on each PE:
a. Run system-view
b. Run mpls ldp remote-peer peer-name
The name of the remote MPLS LDP session is specified.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Remote MPLS LDP sessions need to be established between PEs, so that they can
directly exchange PW information.
c. Run remote-ip ip-address
The peer IP address of the remote MPLS LDP session is specified.
Step 4 Configure Martini VPLS on each PE. For configuration details, see 13.6 Configuring
Martini VPLS.
----End
13.8 (Optional) Setting Related Parameters for a VSI

This section describes how to set related parameters for a VSI.
Before setting VSI-related parameters, complete the following tasks:
l 13.6 Configuring Martini VPLS
After creating a VSI and assigning a signaling protocol to it, you can adjust common
parameters of the VSI. According to different applicable environments, you can determine
whether to modify MAC address learning modes and MAC address entries.
Perform the following operations on the PE.
13.8.1 Configuring a PE to Send MAC Withdraw Messages to

Remove MAC Address Entries
Context
The local device cannot detect failure of the AC. When the AC is Down, the VSI remains Up
and the device does not delete the corresponding MAC address entry. This results in a black
hole when the local device sends data flows to the remote device. The MAC address withdraw
function solves this problem by enabling the local VSI to delete the local MAC address and
notify all remote peers when AC is faulty and the VSI remains Up.
Procedure
Step 2 Run vsi vsi-name [ static ]
The VSI view is displayed.
LDP is configured as the PW signaling protocol and the VSI-LDP view is displayed.
Step 4 Run mac-withdraw enable

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
The PE is configured to send a MAC Withdraw message when the AC or PW status changes.
By default, this function is disabled.
Step 5 Run interface-status-change mac-withdraw enable
The PE is configured to send LDP MAC Withdraw messages to all peers when the status of
the AC-side interface bound to the VSI changes.
By default, the PE does not send LDP MAC Withdraw messages to all peers when the status
of the AC-side interface bound to the VSI changes.
----End
13.8.2 Configuring MAC Withdraw Loop Detection

Context
This section describes how to configure Media Access Control (MAC) Withdraw loop
detection to prevent MAC Withdraw message loops.
Procedure
Layer 2 virtual private network (L2VPN) is enabled, and the L2VPN view is displayed.
Step 3 Run vpls mac-withdraw loop-detect enable
MAC Withdraw loop detection is enabled.
By default, MAC Withdraw loop detection is disabled.
----End

l Run the display vsi [ name vsi-name ] verbose command to check the MAC Withdraw
configuration.
l Run the display vsi [ name vsi-name ] mac-withdraw loop-detect command to check
information about MAC Withdraw message loops.
13.8.3 Configuring MAC Address Learning
Context
In VPLS, packets are forwarded according to MAC address forwarding entries. In most cases,
MAC address learning can be performed automatically. Nevertheless, to prevent attacks and
troubleshoot faults, you can adopt the VSI-based MAC address management mechanism
provided by the router.
Do as follows on the PEs of the two ends of the PW:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run mac-address aging-time aging-time
The aging time of MAC address entries for the VPLS is configured.
By default, the aging time of dynamic MAC address entries is 300 seconds.
Step 3 Run mac-address static mac-address interface-type interface-number vsi vsi-name
Static MAC address entries are configured.
By default, no static MAC address entry is configured in the system.
Step 4 Run mac-address blackhole mac-address vsi vsi-name
MAC address blackhole entries are configured.
By default, no blackhole MAC address entry is configured for the VSI.
Step 5 Run vsi vsi-name [ static ]
The PW signaling protocol is specified as LDP and the VSI-LDP view is displayed.
Step 7 Run vsi-id vsi-id
The VSI ID is configured.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.8.4 Configuring a VSI to Ignore the AC Status

Context
Figure 13-13 Networking diagram of configuring a VSI to ignore the AC status

Server A
A'
C B
C' B'
D
D'
DSLAM
Devices on the old network
Devices on the new network
As shown in Figure 13-13, devices A, B, C, and D are on the old network, while devices A',
B', C', and D' are on the new network, if the services running on the old network will switch
to the new network, and you want to check whether the VSI on the new network can work
normally before the service switchover, you need to configure the VSI to ignore the AC status
on D'. After the configuration, the VSI on D' keeps Up before the DSLAM is connected to the
new network.
If an AC interface is Down and the PW is Up, the VSI remains Up after being enabled to
ignore AC status. If an AC interface is Up and the PW is Down, the VSI remains Up after
being enabled to ignore AC status.
Do as follows on the PE (D' in Figure 13-13):
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Run the following commands as required:

l If your want to prevent the status of all the VSIs from being affected by the status of the
AC. Run mpls l2vpnvpls ignore-ac-state
a. The MPLS L2VPN view is displayed.
b. Prevents the status of a VSI from being affected by the status of the AC.
l If you want to prevent the status of one VSI from being affected by the status of the AC.
Run:
a. vsi vsi-name [ static ]

b. ignore-ac-state
Prevents the status of a VSI from being affected by the status of the AC.
----End
Follow-up Procedure
The vpls ignore-ac-state or ignore-ac-state are used only before the service switchover
between a new VPLS network and an old one. After the service switchover, run the undo vpls
ignore-ac-state or undo ignore-ac-state command to restore the default setting.
13.9 Maintaining VPLS

VPLS maintenance includes collecting, clearing, and viewing traffic statistics on VPLS PWs,
enabling or disabling VSIs, clearing MAC address entries, and detecting the VPLS network
connectivity.
13.9.1 Collecting Traffic Statistics on a VPLS PW
Context
To analyze the network traffic model, collect traffic statistics on the specified PW.
Perform the following steps on the device configured with the VSI:
Procedure
Step 2 Run the vsi vsi-name [ static ] command to enter the VSI view.
Step 3 Run the pwsignal ldp command to configure LDP as the PW signaling protocol and enter the
VSI-LDP view.
Step 4 Choose either of the following methods to enable traffic statistics collection based on the
number of PWs.
l When there are many PWs:
Run the traffic-statistics enable command to enable statistics collection on public
network traffic of all PWs in Martini VPLS mode.
l When there are a few PWs:

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Run the traffic-statistics peer peer-address [ negotiation-vc-id vc-id ] enable command

to enable statistics collection on public network traffic of a specified PW in Martini
VPLS mode.
----End
13.9.2 Clearing the Traffic Statistics
Context
The traffic statistics information cannot be restored after you clear it. So, confirm the action
before you use the command.
Procedure
l Run the reset traffic-statistics vsi all command in the user view to clear the traffic
statistics on all VPLS PWs.
l Run the reset traffic-statistics vsi name vsi-name command in the user view to clear the
traffic statistics on all VPLS PWs of a specified VSI.
l Run the reset traffic-statistics vsi name vsi-name peer peer-address [ negotiation-vc-
id vc-id ] command in the user view to clear the traffic statistics on a specified VPLS
PW of a specified VSI.
----End
13.9.3 Checking Traffic Statistics on a VPLS PW
Context
NOTE
Within five minutes, if a PW goes Down, traffic before the PW is Down cannot be used to compute the
traffic rate in the five minutes.
After the traffic statistics function is enabled on a VPLS PW, you can run the following
commands in any view to view the running status of traffic on the VPLS PW.
Procedure
l Run the display traffic-statistics vsi vsi-name command to view public network traffic
statistics on all PWs of a specified VSI.
l Run the display traffic-statistics vsi vsi-name peer peer-address [ negotiation-vc-id vc-
id ] command to view public network traffic statistics on a specified PW of a specified
VSI.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.9.4 Enabling or Disabling VSI
Context
Sometimes, to halt services, you can disable a VSI temporarily, and then add, cancel, or adjust
VSI functions.
Procedure
l Enable VSI
a. Run the system-view command to enter the system view.
b. Run the vsi vsi-name command to enter the vsi view.
c. Run the undo shutdown command to enable VSI.
l Disable VSI
a. Run the system-view command to enter the system view.
b. Run the vsi vsi-name command to enter the vsi view.
c. Run the shutdown command to disable VSI.
The shutdown command affects the PW connection. The AC is Down, and the
Layer 2 forwarding table is deleted.
----End
13.9.5 Clearing MAC Address Entries
Context
After MAC address entries are cleared, the entries cannot be restored. Confirm the action
before you clear the entries.
Procedure
l Run the undo mac-address static mac-address interface-type interface-number vsi vsi-
name command to clear MAC address entries for a VSI.
l Run the undo mac-address [ dynamic | all ] command to clear dynamic, or all MAC
address entries.
l Run the undo mac-address static command to clear static MAC address entries.
l Run the undo mac-address blackhole [ vsi vsi-name ] command to clear blackhole
MAC address entries.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
13.9.6 Checking Connectivity of the VPLS Network
Context
To check connectivity of a VPLS network, configure a VPLS network and run the following
functions on PE devices.
Procedure
l Checking VPLS network connectivity
– Run the ping vpls mac mac-address vsi vsi-name [ vlan vlan-id | -c count | -m
time-value | -s packsize | -t timeout | -exp exp | -r replymode | -h ttl ] * command to
check connectivity of the Layer 2 forwarding link on the VPLS network.
– Run the ping vpls [ -c echo-number | -m time-value | -s data-bytes | -t timeout-value
| -r reply-mode | -exp exp-value | -v ] * vsi vsi-name peer peer-address [ negotiate-
vc-id vc-id ] command to check connectivity of the link between PEs on the Martini
VPLS network.
– Run the trace vpls mac mac-address vsi vsi-name [ vlan vlan-id ] [-t timeout | -f
first-ttl | -m max-ttl | -exp exp | -r replymode ] * command to check PEs and P
devices along the PW on the VPLS network. This command is also used to check
the connectivity of Layer 2 forwarding links and locate faults on the network.
– Run the tracert vpls [ -exp exp-value | -f first-ttl | -m max-ttl | -r reply-mode | -t
timeout-value ] * vsi vsi-name peer peer-address [ negotiate-vc-id vc-id ] [ full-lsp-
path ] command to check connectivity of the Martini VPLS network.
l Checking ping/trace packet statistics
– Run the display vpls-ping statistics command to check the number of sent and
received VPLS MAC ping packets.
– Run the display vpls-trace statistics command to check the number of sent and
received VPLS MAC trace packets.
l Clearing ping/trace packet statistics
– Run the reset vpls-ping statistics command to clear VPLS MAC ping statistics.
– Run the reset vpls-trace statistics command to clear VPLS MAC trace statistics.
----End
13.9.7 Configuring the Upper and Lower Alarm Thresholds for

VPLS VCs
Context
A device supports only a limited number of VPLS VCs. After the total number of VPLS VCs
created on a device exceeds a certain limit, the device performance deteriorates. To prevent
device performance deterioration caused by excessive VPLS VCs, configure the upper and
lower alarm thresholds for VPLS VCs. You can flexibly adjust the upper and lower alarm
thresholds for VPLS VCs based on actual requirements.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run the mpls l2vpn command to enter the MPLS L2VPN view.
Step 3 Run the mpls l2vpn vsi-pw limit threshold-alarm upper-limit upper-limit-value lower-
limit lower-limit-value command to configure the upper and lower alarm thresholds for VPLS
VCs.
By default, the upper and lower alarm thresholds are 80% and 70% respectively.
l upper-limit-value specifies the upper alarm threshold for VPLS VCs. If the proportion of
VPLS VCs created to the maximum VPLS VCs allowed reaches this threshold, a VPLS
VC threshold-crossing alarm is reported.
l lower-limit-value specifies the lower alarm threshold for VPLS VCs. If the proportion of
VPLS VCs created to the maximum VPLS VCs allowed falls below this threshold, a
VPLS VC threshold-crossing clear alarm is reported.
l upper-limit-value must be greater than lower-limit-value.
----End
13.9.8 Checking MPLS L2VPN Usage Information
Context
In routine network maintenance, you can learn overall MPLS L2VPN information by
checking MPLS L2VPN specifications and usage information.
Procedure
l Run the display mpls l2vpn resource command to check MPLS L2VPN specifications
and usage information.
----End
13.10 Configuration Examples for VPLS

This section provides several configuration examples of different VPLS networking,
including networking requirements, configuration notes, configuration roadmap,
configuration procedures, and configuration files.
13.10.1 Example for Configuring Martini VPLS
Figure 13-14 shows a backbone network built by an enterprise. Few branch sites are
distributed on the network (only two sites are shown in this example). Site1 connects to PE1
through CE1 and then connects to the backbone network. Site2 connects to PE2 through CE2
and then connects to the backbone network. Users at Site1 and Site2 need to communicate at
Layer 2 and user information needs to be reserved when Layer 2 packets are transmitted over
the backbone network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 13-14 Networking diagram for configuring Martini VPLS

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
GE2/0/0 GE1/0/0
10.1.1.2/24 10.2.2.2/24
PE1 PE2
GE2/0/0 GE 1/0/0
GE1/0/0 10.1.1.1/24 P 10.2.2.1/24 GE2/0/0
Martini
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Site1 Site2
1. Configure transparent transmission of Layer 2 packets over the backbone network using
VPLS to enable users at Site1 and Site2 to communicate at Layer 2 and reserve user
information when Layer 2 packets are transmitted over the backbone network.
2. Use Martini VPLS to implement Layer 2 communication between CEs on an enterprise
network with few sites.
3. Configure the IGP routing protocol on the backbone network to implement data
transmission on the public network between PEs.
4. Configure basic MPLS functions and LDP on the backbone network to support VPLS.
5. Establish tunnels for transmitting data between PEs to prevent data from being known by
the public network.
6. Enable MPLS L2VPN on PEs to implement VPLS.
7. Create VSIs on PEs, specify LDP as the signaling protocol, and bind VSIs to AC
interfaces to implement Martini VPLS.
Procedure
Step 1 Configure IP addresses for interfaces on the CE, PE and P devices according to Figure 13-14.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 2 Configure the IGP protocol. OSPF is used in this example.

When configuring OSPF, advertise the 32-bit address of the loopback interface (LSR IDs) on
PE1, P and PE2.
# Configure PE1. The configuration on P and PE2 is similar to the PE1, and is not mentioned
here.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
After the configuration is complete, run the display ip routing-table command on PE1, P,
and PE2. You can view the routes learned by PE1, P, and PE2 from each other.
Step 3 Configure basic MPLS functions and LDP.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure the P.
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command on PE1, P
and PE2. You can see that peer relationships are set up between PE1 and P, and between P and
PE2. The status of the peer relationship is Operational. Run the display mpls lsp command to
view the LSP status.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 4 Set up remote LDP sessions between PEs.

# Configure PE1.
# Configure PE2.
After the configuration is complete, run the display mpls ldp session command on PE1 or
PE2, and you can see that the status of the peer relationship between PE1 and PE2 is
Operational. That is, the peer relationship is set up.

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------

# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
Step 6 Configure LDP VPLS on PEs.

# Configure PE1.
[PE1] vsi a2 static
[PE1-vsi-a2] pwsignal ldp
[PE1-vsi-a2-ldp] vsi-id 2
[PE1-vsi-a2-ldp] peer 3.3.3.9
[PE1-vsi-a2-ldp] quit
[PE1-vsi-a2] quit
# Configure PE2.
[PE2] vsi a2 static
[PE2-vsi-a2] quit
Step 7 Bind the interface on the PE to the VSI.

# Configure PE1.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1-GigabitEthernet1/0/0] l2 binding vsi a2
# Configure PE2.

# After the network becomes stable, run the display vsi name a2 verbose command on PE1,
and you can see that VSI a2 sets up a PW to PE2, and the status of the VSI is Up.
[PE1] display vsi name a2 verbose
***VSI Name : a2
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 0
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
Ignore AcState : disable
P2P VSI : disable
Create Time : 0 days, 0 hours, 1 minutes, 3 seconds
VSI State : up
VSI ID : 2
*Peer Router ID : 3.3.3.9
Negotiation-vc-id : 2
ignore-standby-state : no
VC Label : 1024
Peer Type : dynamic
Session : up
Tunnel ID :
Broadcast Tunnel ID : 0x0
Broad BackupTunnel ID : 0x0
CKey : 6
NKey : 5
Stp Enable : 0
PwIndex : 0
Control Word : disable
Interface Name : GigabitEthernet1/0/0

State : up
Access Port : false
Last Up Time : 2017/07/02 17:13:47
Total Up Time : 0 days, 0 hours, 1 minutes, 3 seconds
**PW Information:
*Peer Ip Address : 3.3.3.9

PW State : up
Local VC Label : 4096
Remote VC Label : 4096
Remote Control Word : disable
PW Type : label
Local VCCV : alert lsp-ping
Remote VCCV : alert lsp-ping

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Tunnel ID : 0x1a
Broadcast Tunnel ID : 0x1a
Ckey : 0x6
Nkey : 0x5
Main PW Token : 0x1a
Slave PW Token : 0x0
Tnl Type : LSP
OutInterface : GigabitEthernet2/0/0
Backup OutInterface :
Stp Enable : 0
PW Last Up Time : 2017/07/02 17:14:47
PW Total Up Time : 0 days, 0 hours, 0 minutes, 3 seconds

Take the display on CE1 for example.
[CE1] ping 100.1.1.2
0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
vsi a2 static
pwsignal ldp
vsi-id 2
peer 3.3.3.9
#
mpls ldp
#
remote-ip 3.3.3.9
#
l2 binding vsi a2
#
ip address 10.1.1.1 255.255.255.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.2.2.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return
#
sysname PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
vsi a2 static
pwsignal ldp
vsi-id 2
peer 1.1.1.9
#
mpls ldp
#
remote-ip 1.1.1.9
#
ip address 10.2.2.1 255.255.255.0
mpls
mpls ldp
#
l2 binding vsi a2
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.2.2.0 0.0.0.255
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
13.10.2 Example for Configuring Inter-AS Martini VPLS in

OptionA Mode
As shown in Figure 13-15, on an enterprise network, Site1 connects to PE1 through CE1 and
then connects to the VPLS domain of AS 100. Site2 connects to PE2 through CE2 and then
connects to the VPLS domain of AS 200. The network environments of the branch sites are
stable. AS 100 and AS 200 communicate with each other through ASBR-PE1 and ASBR-
PE2. IS-IS is used as the IGP on the MPLS backbone network in an AS. Users at Site1 and
Site2 need to communicate at Layer 2 and user information needs to be reserved when Layer
2 packets are transmitted over the backbone network.
Figure 13-15 Networking diagram of configuring inter-AS Martini VPLS in OptionA mode
MPLS Backbone MPLS Backbone
AS 100 AS 200
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32 4.4.4.9/32
GE2/0/0 GE1/0/0
10.1.1.1/24 GE2/0/0 GE1/0/0 30.1.1.2/24
GE1/0/0 GE2/0/0
PE1 10.1.1.2/24 ASBR-PE1 ASBR-PE2 30.1.1.1/24 GE2/0/0 PE2
GE1/0/0
GE1/0/0 GE1/0/0
100.1.1.1/24 100.1.1.2/24
CE1 CE2
Site1 Site2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
1. Configure transparent transmission of Layer 2 packets over the backbone network using
VPLS to enable users at Site1 and Site2 to communicate at Layer 2 and reserve user
information when Layer 2 packets are transmitted over the backbone network.
2. Use Martini VPLS to implement Layer 2 communication between CEs when the network
environments of the branch sites are stable.
3. Configure the IGP routing protocol on the backbone network to implement
communication between devices within an AS on the public network.
4. Configure basic MPLS functions and LDP on PEs on the backbone network to support
VPLS.
5. Establish tunnels for transmitting data between PEs within an AS to prevent data from
being known by the public network. Establish dynamic LSPs between ASBR-PEs and
PEs in the same AS. If PEs and ASBR-PEs are not directly connected, establish remote
LDP sessions.
6. Enable MPLS L2VPN on PEs to implement VPLS.
7. Create a VSI on PEs, specify LDP as the signaling protocol, and bind the VSI to the AC
interface in the same AS to implement Martini VPLS.
8. To implement VPLS inter-AS OptionA, configure the peer ASBR as the CE on the
ASBR PE, and bind VSIs to peer interfaces.
Procedure
Step 1 Configure IP addresses for interfaces according to Figure 13-15.
Step 2 Configure the IGP on the MPLS backbone network.

Configure the IGP on the MPLS backbone network to achieve connectivity between the PEs
and ASBR PEs. Note that IS-IS must be enabled on Loopback0.
PE1, and is not mentioned here.
[PE1] isis 1
[PE1-isis-1] quit
After the configuration is complete, the ASBR-PE and PE in the same AS can establish an IS-
IS neighbor. Run the display isis peer command, and you can see that the IS-IS neighbor is in
Up state.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[PE1] display isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI

-------------------------------------------------------------------------------
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 23s L1(L1L2) 64
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 22s L2(L1L2) 64
Total Peer(s): 2
ASBR-PEs and PEs in the same AS can Ping each other.

[PE1] ping 2.2.2.9

0.00% packet loss
Step 3 Configure basic MPLS functions and LDP.

Enable basic MPLS functions on the MPLS backbone network. Establish a dynamic LDP LSP
between the PE and ASBR PE in the same AS.
PE1, and is not mentioned here.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
After this step, an LSP is established between the PE and ASBR-PE in the same AS.
Run the display mpls ldp session command to view the LDP LSP status.
ASBR-PE1 is used as an example.
[ASBR-PE1] display mpls ldp session

------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Step 4 Configure LDP VPLS and bind VSIs to interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Configure VSIs on PEs and ASBR PEs respectively and bind the VSIs to the related
interfaces.
# Configure PE1.
[PE1] mpls l2vpn
[PE1-l2vpn] quit
[PE1] vsi a1 static
[PE1-vsi-a1] quit
[ASBR-PE1] vsi a1 static
[ASBR-PE1-vsi-a1] pwsignal ldp
[ASBR-PE1-vsi-a1-ldp] vsi-id 2
[ASBR-PE1-vsi-a1-ldp] peer 1.1.1.9
[ASBR-PE1-vsi-a1-ldp] quit
[ASBR-PE1-vsi-a1] quit
[ASBR-PE1-GigabitEthernet2/0/0] l2 binding vsi a1
[ASBR-PE2] vsi a1 static
[ASBR-PE2-vsi-a1] pwsignal ldp
[ASBR-PE2-vsi-a1-ldp] vsi-id 3
[ASBR-PE2-vsi-a1-ldp] peer 4.4.4.9
[ASBR-PE2-vsi-a1-ldp] quit
[ASBR-PE2-vsi-a1] quit
[ASBR-PE2-GigabitEthernet1/0/0] l2 binding vsi a1
# Configure PE2.
[PE2] mpls l2vpn
[PE2-l2vpn] quit
[PE2] vsi a1 static
[PE2-vsi-a1] quit

After the preceding configurations are complete, run the display vsi name a1 verbose
command on PE1, and you can see that the VSI named a1 has established a PW to PE2, and
the status of the VSI is Up.
# Take the display on PE1 and ASBR-PE2 for example.
[PE1] display vsi name a1 verbose

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
***VSI Name : a1
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 0
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
Service Class : --
Color : --
DomainId : 255
Domain Name :
Ignore AcState : disable
P2P VSI : disable
Create Time : 0 days, 3 hours, 30 minutes, 31 seconds
VSI State : up
VSI ID : 2
*Peer Router ID : 2.2.2.9
Negotiation-vc-id : 2
ignore-standby-state : no
VC Label : 23552
Peer Type : dynamic
Session : up
Tunnel ID :
CKey : 6
NKey : 5
Stp Enable : 0
PwIndex : 0
Control Word : disable
Interface Name : GigabitEthernet1/0/0

State : up
Access Port : false
Last Up Time : 2017/07/02 15:41:59
Total Up Time : 0 days, 0 hours, 1 minutes, 2 seconds
**PW Information:
*Peer Ip Address : 2.2.2.9

PW State : up
Local VC Label : 23552
Remote VC Label : 23552
Remote Control Word : disable
PW Type : label
Local VCCV : alert lsp-ping
Remote VCCV : alert lsp-ping
Tunnel ID : 0x20020
Ckey : 0x6
Nkey : 0x5
Main PW Token : 0x20020
Slave PW Token : 0x0
Tnl Type : LSP
OutInterface : GigabitEthernet2/0/0
Backup OutInterface :
Stp Enable : 0
PW Last Up Time : 2017/07/02 15:41:59
PW Total Up Time : 0 days, 0 hours, 1 minutes, 3 seconds

Take the display on CE1 for example.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[CE1] ping 100.1.1.2


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ip address 100.1.1.1 255.255.255.0
#
return

#
sysname PE1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls l2vpn
#
vsi a1 static
pwsignal ldp
vsi-id 2
peer 2.2.2.9
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0001.00
#
l2 binding vsi a1
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 1
#
return

#
sysname ASBR-PE1
#
mpls lsr-id 2.2.2.9
mpls
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
mpls l2vpn
#
vsi a1 static
pwsignal ldp
vsi-id 2
peer 1.1.1.9
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
l2 binding vsi a1
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
#
sysname ASBR-PE2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls l2vpn
#
vsi a1 static
pwsignal ldp
vsi-id 3
peer 4.4.4.9
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0003.00
#
l2 binding vsi a1
#
ip address 30.1.1.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 1
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls l2vpn
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
vsi a1 static
pwsignal ldp
vsi-id 3
peer 3.3.3.9
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 30.1.1.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
l2 binding vsi a1
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
isis enable 1
#
return

#
sysname CE2
#
ip address 100.1.1.2 255.255.255.0
#
return
13.11 Troubleshooting VPLS

This section describes common faults caused by incorrect VPLS configurations and provides
the troubleshooting procedure.
13.11.1 VSI Cannot Go Up in Martini VPLS Mode
Fault Symptom
After Martini VPLS is configured, the VSI cannot go Up.
Procedure
Step 1 Run the display vsi name vsi-name command to check whether the encapsulation types on
both ends are the same.
l If the encapsulation types on both ends are different, run the encapsulation { ethernet |
vlan } command in the VSI view to change the encapsulation type on one end to ensure
that the two ends use the same encapsulation type.
l If the encapsulation types on both ends are the same, go to step 2.
NOTE
A VSI can be Up only when encapsulation types configured on both ends are the same.
Step 2 Run the display vsi name vsi-name command to check whether MTUs of the two ends are the
same.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l If MTUs of the two ends are different, run the mtu mtu-value command in the VSI view
to change the MTU on one end to ensure that the two ends use the same MTU.
l If MTUs of the two ends are the same, go to step 3.
NOTE
A VSI can be Up only when MTUs configured for the two ends are the same.
Step 3 Run the display vsi name vsi-name verbose command to check whether VSI IDs or
negotiation IDs on both ends are the same.
l If VSI IDs or negotiation IDs on the two ends are different, run the vsi-id vsi-id
command in the VSI-LDP view to change the VSI ID on one end, or run the peer peer-
address [ negotiation-vc-id vc-id ] command to change the negotiation ID on one end to
ensure that VSI IDs or negotiation IDs on the two ends are the same.
l If the VSI IDs or negotiation IDs on both ends are the same, go to step 4.
Step 4 Run the display vsi name vsi-name verbose command to check whether the LDP session is
Up.
l If the LDP session is Down, see "LDP Session Goes Down" to make the LDP session go
Up.
l If the LDP session is Up, go to step 5.
NOTE
The two ends can perform L2VPN negotiation only after the LDP session is Up.
Step 5 Run the display vsi name vsi-name verbose command to check whether the AC interfaces on
both ends are Up.
If the AC interfaces on the two ends are Down, see "Physical Interconnection&Interface
Type" to make the AC interfaces go Up.
----End
13.12 References for VPLS

This section lists references for VPLS.
The following table lists the references for VPLS.
Document No. Description
RFC 4448 Encapsulation Methods for Transport of Ethernet over

MPLS Networks
RFC 4762 Virtual Private LAN Service (VPLS) Using Label

Distribution Protocol (LDP) Signaling

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
CLI-based Configuration Guide - VPN Configuration 14 VXLAN Configuration
14 VXLAN Configuration
About This Chapter
This document describes VXLAN features on the device and provides principles,
configuration procedures and configuration examples.
14.1 Overview of VXLANs

14.2 Understanding VXLANs
14.3 Application Scenario
14.4 Licensing Requirements and Limitations for VXLAN
This section describes VXLAN configuration notes.
14.5 Configuring VXLAN (in Static Mode)
14.6 Configuring VXLAN (in BGP EVPN Mode)
14.7 Configuration Examples for VXLANs
14.8 References for VXLANs
14.9 Further Reading
14.1 Overview of VXLANs

Definition
As defined by RFC 7348, Virtual eXtensible Local Area Network (VXLAN) is a Network
Virtualization over Layer 3 (NVO3) technology that uses the MAC in User Datagram
Protocol (MAC-in-UDP) mode to encapsulate packets.
Background
Cloud computing has become the new trend in enterprise IT construction with its features
such as high system utilization, low manpower and management costs, flexibility, and strong
scalability. As a core technology of cloud computing, server virtualization has a wide range of
applications.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
For detailed description about server virtualization, see 14.9.1 Server Virtualization.
The wide application of server virtualization technology greatly increases computing density
in a data center. In addition, VMs need to freely migrate on the network to meet service
change requirements. These bring challenges to traditional data center networks of the Layer
2 + Layer 3 architecture.
l VM scale limited by network devices' table entry capacities
On a traditional Layer 2 network, data packets are forwarded at Layer 2 based on the
MAC address table. Server virtualization leads to an exponential growth of the number
of VMs and the number of MAC addresses of the VM network interface cards (NICs).
However, the MAC address table size of a Layer 2 device at the access side is incapable
to meet this change.
l Insufficient network isolation capabilities
While VLAN is the most commonly used network isolation technology, it has its own
limitations. The VLAN field in packets is only 12 bits long, which means that at most
4096 VLANs can be used on a network. In public cloud or other cloud computing
scenarios involving tens of thousands or even more tenants, VLAN technology can no
longer meet network isolation requirements.
NOTE
A tenant is a complete collection of logical resources deployed on a data center network, including
network resources such as VLANs and IP address pools, as well as computing resources such as
physical servers and virtual machines (VMs). Each tenant has its own tenant administrator to
orchestrate and deploy network services.
l Limited VM migration scope
VMs on a data center network frequently migrate due to server resource issues, such as
high CPU usage and insufficient memory.
VM migration is a process in which a VM moves from one physical server to another. To
ensure uninterrupted services during VM migration, the IP and MAC addresses of VMs
must remain unchanged. To meet this requirement, server migration must occur in a
Layer 2 network. However, a traditional Layer 2 network limits the VM migration scope.
VXLAN addresses the preceding problems:
l For VM scale limitations imposed by table entry capacities
VXLAN encapsulates original data packets sent from VMs in the same region into UDP
packets, with the IP and MAC addresses used on the physical network in outer headers.
The network is only aware of the encapsulated parameters. This greatly reduces the
number of MAC address entries required on large Layer 2 networks.
l For limited network isolation capabilities
VXLAN uses a VXLAN Network Identifier (VNI) field similar to the VLAN ID field to
identify users. The VNI field has 24 bits and can identify up to 16M VXLAN segments,
effectively isolating massive tenants in cloud computing scenarios.
l For limited VM migration scope
VXLAN encapsulates original packets sent by VMs over a VXLAN tunnel. VMs at two
ends of a VXLAN tunnel do not need to know the physical architecture of the
transmission network. In this way, VMs using IP addresses in the same network segment
are in a Layer 2 domain logically, even if they are on different physical Layer 2
networks. VXLAN technology constructs a virtual large Layer 2 network over a Layer 3
network, so that VMs are on the same large Layer 2 network so long as there are

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
reachable routes between them. The virtual large Layer 2 network enlarges the VM
migration scope.
NOTE
For detailed description about large Layer 2 network, see 14.9.2 Large Layer 2 Network.
Purpose
VXLAN is developed to implement server virtualization and free VM migration on data
center networks. As a VPN technology, VXLAN can also be used on campus networks to
provide Layer 2 interconnection between dispersed physical sites and Layer 3 interconnection
between sites.
Currently, related devices and multiple Layer 2 and Layer 3 network technologies need to be
deployed on campus networks to implement Layer 2 and Layer 3 interconnection between
tenant sites. Overlay-based VXLAN technology establishes Layer 2 virtual networks between
any networks with reachable routes to implement Layer 2 interconnection. Layer 3
interconnection is implemented between sites by VXLAN Layer 3 gateway at the same time.
In all, VXLAN realizes faster and more flexible site interconnection.
14.2 Understanding VXLANs

14.2.1 VXLAN Network Architecture
VXLAN is an NVO3 network virtualization technology that encapsulates data packets sent
from original hosts into UDP packets and encapsulates IP and MAC addresses used on the
physical network in outer headers before sending the packets over an IP network. The virtual
tunnel endpoint (VTEP) then decapsulates the packets and sends the packets to the destination
host.
By leveraging VXLAN, a virtual network can accommodate a large number of tenants.
Tenants can plan their own virtual networks without being limited by physical network IP
addresses or broadcast domains. This technology significantly simplifies network
management.
Similar to a traditional VLAN, a VXLAN also allows for intra- and inter-VXLAN
communication.
Intra-VXLAN Communication
VXLAN technology constructs a virtual Layer 2 network over a Layer 3 network,
implementing Layer 2 communication between hosts. Figure 14-1 shows intra-VXLAN
communication.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-1 Intra-VXLAN Communication
Network
L2 gateway
VTEP VXLAN Tunnel VTEP L2 gateway
NVE NVE Tenant
Tenant
branch 2
branch 1
VAP VAP
… BD 10 BD 10
VNI 1000 VNI 1000 …
PC PC
Traffic
forwarding path
Involved concepts
l VXLAN Network Identifier (VNI)
A VNI is similar to a VLAN ID on a traditional network, and it identifies a VXLAN
segment. Tenants on different VXLAN segments cannot communicate at Layer 2. One
tenant may have one or more VNIs. A VNI consists of 24 bits and supports up to 16M
tenants.
l Broadcast Domain (BD)
Similar to VLANs divided on a traditional network, BD is used for broadcast domain
division on a VXLAN.
On a VXLAN, to allow Layer 2 communication between hosts in a BD, VNIs and BDs
are mapped in 1:1 mode.
l VXLAN Tunnel Endpoints (VTEP)
A VTEP encapsulates and decapsulates VXLAN packets.
The source and destination IP addresses in a VXLAN packet are the IP addresses of the
local and remote VTEPs, respectively. A pair of VTEP addresses defines one VXLAN
tunnel. A source VTEP encapsulates packets and selects a tunnel to forward them. The
corresponding destination VTEP decapsulates the received packets.
l Virtual Access Point (VAP)
A VAP is a VXLAN service access point used for service access based on VLANs or
packet encapsulation modes. For more information, see 14.2.3.1 Packet Identification:
– Service access based on VLANs: The 1:1 or N:1 mapping between VLANs and
BDs is configured on VTEPs. When a VTEP receives a service packet, it forwards
the packet in a BD based on the mapping between VLANs and BDs.
– Service access based on packet encapsulation modes: Layer 2 sub-interfaces are
created on a downlink physical interface of a VTEP, and different encapsulation
modes are configured for these sub-interfaces to enable different interfaces to
receive different data packets. The 1:1 mapping between Layer 2 sub-interfaces and
BDs is also defined. Then service packets are sent to specific Layer 2 sub-interfaces
after reaching the VTEP. That is, packets are forwarded in a BD based on the
mapping between Layer 2 sub-interfaces and BDs.
l Network Virtualization Edge (NVE)
An NVE is a network entity used to implement network virtualization functions. After
packets are encapsulated and decapsulated through NVEs, a Layer 2 VXLAN can be

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
established between NVEs over the basic Layer 3 network. In the preceding figure,
routers serve as NVEs.
l Layer 2 gateway
Similar to a Layer 2 access device on a traditional network, it allows tenant access to
VXLANs and intra-subnet VXLAN communication in the same network segment.
Inter-VXLAN Communication
Hosts in different BDs cannot directly communicate at Layer 2. VXLAN Layer 3 gateways
need to be configured to implement Layer 3 communication between hosts. Figure 14-2
shows inter-VLAN communication.
Figure 14-2 Inter-VXLAN Communication
VBDIF 10 NVE L3 gateway

VBDIF 20
NVE
l
VX
ne
n
LA
Tu
N
N
Tu
LA
Network
n
VX
ne
l
L2 gateway L2 gateway
NVE NVE
Tenant NVE NVE
Tenant
branch 1 branch 2
VAP VAP
… BD 10 BD 20
VNI 1000 VNI 2000 …
PC PC
Traffic
forwarding path
Involved concepts
l Layer 3 gateway
On a traditional network, users in different VLANs cannot directly communication at
Layer 2. Layer 2 communication is also not allowed between VXLANs identified by
different VNIs or between VXLANs and non-VXLANs. To address these problems, the
VXLAN Layer 3 gateway is introduced to enable data transmission between VXLANs or
between VXLANs and non-VXLANs.
The VXLAN Layer 3 gateway is used for cross-subnet communication on the VXLAN
and external network access.
l VBDIF interface
On a traditional network, VLANIF interfaces are used to enable communication between
different BDs. Similarly, VBDIF interfaces are introduced in a VXLAN to implement
such function.
The VBDIF interface is configured on the VXLAN Layer 3 gateway and is a Layer 3
logical interface based on BDs. After IP addresses are configured for VBDIF interfaces,
VXLANs on different network segments, VXLANs and non-VXLANs, and Layer 2 and
Layer 3 networks can communicate with each other.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Comparison Between VXLAN and VLAN

The following table lists the differences between VXLAN and VLAN.
Table 14-1 Comparison between VXLAN and VLAN

Item VLAN VXLAN
Concept Virtual Local Area Network. Virtual Extensible Local Area Network.
Impleme A physical LAN is divided into Layer 2 virtual networks are established
ntation multiple BDs logically to limit between networks with reachable routes.
Method the network to a small Such networks are not subject to geographical
geographic range. restrictions and can deliver a large-scale
scalability.
Supporte VLAN is the most commonly VXLAN is a new network isolation

d used network isolation technology defined in IETF RFC 7348. It has
capacity technology. The VLAN field in a 24-bit segment identifier (VNI) and can
packets is only 12 bits in isolate up to 16M (about 16 million) tenants.
length, which means that only This technology effectively enables isolation
a maximum of 4096 VLANs of mass tenants in cloud computing.
can be used on a network. In
public cloud or other cloud
computing scenarios involving
tens of thousands or even more
tenants, VLAN technology can
no longer meet network
isolation requirements.
Network VLAN IDs are used to divide BDs are used to divide broadcast domains.
division broadcast domains. Hosts Hosts within a BD can communicate at Layer
mode within a BD can communicate 2.
at Layer 2.
Encapsu A VLAN tag is added to During VXLAN encapsulation, a VXLAN

lation packets. header, UDP header, IP header, and outer
mode MAC header are added in sequence to an
original packet. For details, see 14.2.2 Packet
Encapsulation Format.
Network Inter-VLAN communication is Communication between VLANs or between

commun implemented by VLANIF VXLANs and non-VXLANs is implemented
ication interfaces. As Layer 3 logical by VBDIF interfaces.
mode interfaces, VLANIF interfaces VBDIF interfaces are configured on VXLAN
enable Layer 3 communication Layer 3 gateways and are Layer 3 logical
between VLANs. interfaces based on BDs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Item VLAN VXLAN
Benefits Limits broadcast domains: A Location-independent capability: Services

broadcast domain is limited in can be deployed flexibly at any location,
a VLAN, which saves solving network expansion issues related to
bandwidth and improves server virtualization.
network processing Flexible network deployment: VXLANs are
capabilities. constructed over the traditional network.
Enhances LAN security: They are easy to deploy and highly scalable
Packets from different VLANs while preventing broadcast storms on a large
are separately transmitted. Layer 2 network.
Hosts in a VLAN cannot Cloud service adaptation: A VXLAN is able
directly communicate with to isolate ten millions of tenants and support
hosts in another VLAN. large-scale deployment of cloud services.
Technical advantage: VXLAN uses MAC-in-
UDP encapsulation. Such encapsulation
mode does not rely on MAC addresses of
hosts, reducing the number of MAC address
entries required on a large Layer 2 network.
14.2.2 Packet Encapsulation Format

During VXLAN encapsulation, a VXLAN header, UDP header, IP header, and Ethernet
header are added in sequence to an original packet.
Figure 14-3 shows the packet encapsulation format.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-3 VXLAN packet format

48 bits 48 bits 32 bits 16 bits
MAC MAC 802.1Q Ethernet
DA SA Tag Type
72 bits 8 bits 16 bits 32 bits 32 bits
…... Protocol …... IP SA IP DA
VXLAN encapsulation Original packet
Outer Outer Outer Inner Inner

VXLAN
Ethernet IP UDP Ethernet IP Payload
header
header header header header header
VXLAN Flags
Reserved VNI Reserved
(00001000)
Source DestPort UDP UDP

Port (VXLAN Port) Length Checksum
Table 14-2 describes headers added to an original packet during VXLAN encapsulation.
Table 14-2 Description of headers added to an original packet

Field Description
VXLAN header l VXLAN Flags: specifies flags (8 bits). The value is

00001000.
l VNI: specifies an identifier (24 bits) used to identify a
VXLAN segment, with up to 16M tenants. Users in
different VXLAN segments cannot directly communicate at
Layer 2.
l Reserved: The two reserved fields (24 and 8 bits
respectively) are set to 0.
Outer UDP header l DestPort: specifies the destination UDP port number. The
value is 4789.
l Source Port: specifies the source port number. It is the hash
value calculated using parameters in the inner Ethernet
frame header.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Field Description
Outer IP header l IP SA: specifies the source IP address, which is the IP

address of the source VTEP.
l IP DA: specifies the destination IP address, which is the IP
address of the destination VTEP.
Outer Ethernet header l MAC DA: specifies the destination MAC address, which is
the MAC address of the next-hop device on the route to the
destination VTEP.
l MAC SA: specifies the source MAC address, which is the
MAC address of the source VTEP that sends the packet.
l 802.1Q Tag (optional): specifies the VLAN tag in the
packet.
l Ethernet Type: specifies the type of the Ethernet frame. The
value of this field is 0x0800 when an IP packet is
transmitted.
14.2.3 VXLAN Implementation

VXLAN needs to be deployed on a downlink interface to provide access services and an
uplink interface to establish a VXLAN tunnel. After VXLAN is deployed on both interfaces,
packets can be forwarded on the VXLAN network. VXLAN implementation is described in
three steps: Packet Identification, VXLAN tunnel establishment, and Packet Forwarding.
14.2.3.1 Packet Identification

On a VXLAN network, VNIs are mapped to BDs in 1:1 mode. After a packet reaches a
VTEP, the VTEP can identify the BD to which the packet belongs, then select a correct tunnel
to forward the packet. Two methods are available for a VTEP to identify the VXLAN to
which a packet belongs.
VXLAN Identification by VLAN

The 1:1 or N:1 mapping between VLANs and BDs is configured on VTEPs based on network
planning. After a VTEP receives a service packet, it correctly selects a VXLAN tunnel to
forward the packet based on the mapping between VLANs and BDs and the mapping between
BDs and VNIs.
In Figure 14-4, VLAN 10 and VLAN 20 belong to BD 10. The mapping between VLANs 10
and 20 and BD 10, as well as the mapping between BD 10 and VNI 1000 are configured on
the VTEP. After the VTEP receives a packet from PC_1 or PC_2, the VTEP forwards the
packet over the VXLAN tunnel for VNI 1000.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-4 VXLAN identification by VLAN
VTEP
Tenant BD 10:VLAN 10
BD 10:VLAN 20 VXLAN tunnel (VNI 1000)
PC_1 VLAN 10
VLAN 20
PC_2
BD 30:VLAN 30
VXLAN tunnel (VNI 3000)
VLAN 30
PC_3
VLAN 40 BD 40:VLAN 40 VXLAN tunnel (VNI 4000)

PC_4
VXLAN Identification by Encapsulation Mode

An encapsulation mode defines packet processing based on whether a packet contains VLAN
tags. To implement VXLAN identification by encapsulation mode, Layer 2 sub-interfaces
need to be configured on a downlink physical interface of a VTEP, and different encapsulation
modes need to be configured for these sub-interfaces. The 1:1 mapping between Layer 2 sub-
interfaces and BDs should also be defined. Then service packets are sent to specific Layer 2
sub-interfaces after reaching the VTEP. The VTEP selects a correct VXLAN tunnel to
forward packets based on the mapping between Layer 2 sub-interfaces and BDs and the
mapping between BDs and VNIs.
Table 14-3 lists the four encapsulation modes and packet processing methods.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Table 14-3 Packet processing in different encapsulation modes

Encapsulation Allowed Packet Packet Packet
Mode Type Encapsulation Decapsulation
dot1q With specified Removes the VLAN l Removes the

VLAN tag tag from original VLAN tag and
packets. adds a specified
VLAN tag before
forwarding them,
if the inner
packets contain a
VLAN tag.
l Adds a specified
VLAN tag to the
original inner
packets before
forwarding them,
if the inner
packets do not
contain a VLAN
tag.
untag Without VLAN tags Does not perform l Removes the

any operation on the outer VLAN tag
original packets. before
forwarding them,
if the inner
packets contain a
VLAN tag.
l Directly
forwards the
packets if the
inner packets do
not contain
VLAN tags.
default All packets Does not perform Does not perform

regardless of any operation on the any operation on the
whether they contain original packets. original packets.
VLAN tags

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Encapsulation Allowed Packet Packet Packet

Mode Type Encapsulation Decapsulation
qinq With specified Removes all the l Removes all the

double VLAN tags VLAN tags from VLAN tags and
original packets. adds specified
double VLAN
tags before
forwarding them,
if the inner
packets contain
VLAN tags.
l Adds specified
double VLAN
tags to the
original inner
packets before
forwarding them,
if the inner
packets do not
contain VLAN
tags.
In Figure 14-5, the physical interface Eth2/0/0 on the VTEP has two Layer 2 sub-interfaces,
which are configured with different encapsulation modes and associated with different BDs.
PC_1 and PC_2 belong to VLAN 10 and VLAN 30, respectively. An uplink interface on the
Layer 2 switch connecting to the VTEP is configured as a trunk interface with the PVID 30
and is configured to allow packets from VLANs 10 and 30 to pass through. When a packet
from PC_1 reaches this interface, the interface transparently transmits the packet to the VTEP
because the VLAN ID of the packet is different from the default VLAN ID of the interface.
When a packet from PC_2 reaches this interface, the interface removes the VLAN tag 30
from the packet before forwarding it to the VTEP because the VLAN ID of the packet is the
same as the default VLAN ID of the interface. As a result, when the packets reach Eth2/0/0 on
the VTEP, the packet from PC_1 contains VLAN tag 10, while the packet from PC_2 does not
contain a VLAN tag. To distinguish the two types of packets, Layer 2 sub-interfaces of the
dot1q and untag types need to be configured on Eth2/0/0:
l The encapsulation mode of the Layer 2 sub-interface Eth2/0/0.1 is dot1q, allowing
packets with VLAN tag 10 to enter the VXLAN tunnel.
l The encapsulation mode of the Layer 2 sub-interface Eth2/0/0.2 is untag, allowing
packets without a VLAN tag to enter the VXLAN tunnel.
After packets from PC_1 or PC_2 reach the VTEP, the VTEP sends the packets to different
Layer 2 sub-interfaces based VLAN tags in the packets. Then, the VTEP chooses a correct
VXLAN tunnel to forward the packets based on the mapping between sub-interface and BD,
as well as the mapping between BD and VNI.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-5 VXLAN identification by encapsulation mode

VTEP
Tenant VXLAN tunnel (VNI 1000)
dot1q vid 10
PC_1 Switch Eth2/0/0.1 : BD 10
VLAN 10
Eth2/0/1
Eth2/0/0
VLAN 30 Eth2/0/0.2 : BD 30
PC_2
Untag
Trunk VXLAN tunnel (VNI 4000)
pvid vlan:30
allow-pass vlan:10 30
14.2.3.2 Tunnel Establishment

A VXLAN tunnel is specified by a pair of VXLAN Tunnel Endpoint (VTEP) IP addresses. A
static VXLAN tunnel can be created after the VXLAN Network Identifiers (VNIs) and IP
addresses are configured for the source and destination VTEPs, and there is a reachable route
between the two VTEP IP addresses.
A VXLAN tunnel is specified by a pair of VTEP IP addresses. After two VTEPs obtain the IP
addresses from each other, a VXLAN tunnel is established so long as there is a reachable
route between the two IP addresses.
l A static VXLAN tunnel can be created by manually specifying the VNI of the tunnel
source and destination as well as the IP addresses of source and destination VTEPs. This
leads to heavy configuration workload and poor flexibility. Therefore, static VXLAN
tunnels do not apply on a large-scale network.
l BGP EVPN can be used to dynamically establish VXLAN tunnels by establishing a BGP
EVPN peer relationship between two VTEPs and using BGP EVPN routes to transmit
VNIs and VTEP IP addresses between the peer. In this mode, the EVPN protocol
automatically discovers VTEPs and dynamically creates VXLAN tunnels. With high
flexibility, this mode applies on a large-scale VXLAN network.
In Figure 14-6, Router1, Router2, Router3, and Router4 are enterprise egress gateways.
VXLAN tunnels need to be established to enable communication between tenant branches
and headquarters, as well as between tenant branches.
In this situation, VXLAN tunnels are established in the following two ways:
l Tenant branches 1 and 2 are in the same subnet and VNI. Tenants in a VNI are in the
same logical Layer 2 network, so they can directly communicate at Layer 2 over a
VXLAN tunnel. To enable communication between tenant branches 1 and 2, the VNI
and VTEP IP addresses need to be manually configured on Router1 and Router2. So
long as Router1 and Router2 have a reachable route to the peer VTEP, a VXLAN tunnel
can be established between them.
l The tenant branch 2 and headquarters belong to different subnets and VNIs. They cannot
directly communicate over a VXLAN tunnel, and a VXLAN Layer 3 gateway needs to
be configured. To enable communication between the tenant branch 2 and headquarters,
the static VNIs and VTEP IP addresses need to be manually configured for Router2 and
Router3, as well as Router4 and Router3. So long as Router2 and Router3 have a
reachable route to the peer VTEP, a VXLAN tunnel can be established between them.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Similarly, so long as Router4 and Router3 have a reachable route to the peer VTEP, a
VXLAN tunnel can be established between them.
Figure 14-6 VXLAN networking
Cloud
CPE VNI:20
Router3 VNI:10
L3 gateway VTEP:10.3.3.2/32
VTEP
l
ne
Network
VX
n
Tu
LA
N
N
LA
Tu
VX
nn
l e
Traffic
forwarding path
VTEP
Router4 VNI:20 el
N Tunn VTEP
Tenant
VTEP:10.4.4.2/32 VXLA VNI:10
Router2
headquarters VTEP VTEP:10.2.2.2/32
Router1 Tenant
VNI:10
VTEP:10.1.1.2/32 branch 2
Tenant
branch 1
14.2.3.3 Packet Forwarding

VXLAN encapsulates Layer 2 network packets to transmit them over traditional Layer 3
networks by constructing a large Layer 2 network among the Layer 3 networks.
MAC Address Learning

On a VXLAN, dynamic MAC address learning is supported to enable user communication.
Figure 14-7 and Figure 14-7 describe the MAC address learning process during
communication between hosts on the same subnet. For the first time, PC_1 does not know the
MAC address of PC_2. PC_1 then sends an ARP broadcast packet to request the MAC
address of PC_2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-7 Forwarding process of ARP request packets

MAC VNI Remote VTEP IP Address
Router3
VNI:20 MAC_1 20 10.1.1.2
VTEP3:10.3.3.2/32 PC_3
MAC_3
MAC VNI Inbound Interface IP_3
VTEP3
MAC_1 20 Port1 nnel
N Tu
PC_1 VXLA
VTEP1
Port1 Network
MAC_1
IP_1 VXLA
N Tu VTEP2
Router1 nnel
PC_2
VNI:20 MAC_2
VTEP1:10.1.1.2/32 Router2 IP_2
VNI:20 MAC VNI Remote VTEP IP Address
VTEP2:10.2.2.2/32 MAC_1 20 10.1.1.2
Router1 encapsulates Router2/Router3
ARP request packet the VXLAN packet. decapsulates the
sent by PC_1 Router1—>Router2 Router1—>Router3 VXLAN packet.
SMAC MAC_1 DMAC Net MAC DMAC Net MAC SMAC MAC_1
DMAC All Fs SMAC VTEP1 MAC SMAC VTEP1 MAC DMAC All Fs
SIP IP_1 SIP 10.1.1.2 SIP 10.1.1.2 SIP IP_1
DIP IP_2 DIP 10.2.2.2 DIP 10.3.3.2 DIP IP_2
UDP S_P HASH UDP S_P HASH
UDP D_P 4789 UDP D_P 4789
VNI 20 VNI 20
Traffic
SMAC MAC_1 SMAC MAC_1
forwarding path
DMAC All Fs DMAC All Fs
SIP IP_1 SIP IP_1
DIP IP_2 DIP IP_2
Figure 14-7 shows the forwarding process of ARP request packets.

1. PC_1 sends an ARP broadcast packet with the source MAC address MAC_1, all-F
destination MAC address, source IP address IP_1, and destination IP address IP_2 to
request the MAC address of PC_2.
2. Router1 receives an ARP request packet sent by PC_1, and chooses a VXLAN tunnel
based on the interface that receives the packet. Due to the 1:1 mapping between
interfaces and BDs, VTEP1 obtains the VNI to which the packet belongs after
determining the BD of the packet. VTEP1 then learns the mapping between MAC_1,
VNI, and interface receiving the packet, and saves the mapping to the local MAC
address table. After obtaining the ingress replication list for the VNI based on the
corresponding BD, VTEP1 replicates packets and performs VXLAN tunnel
encapsulation. During packet encapsulation, VTEP1 adds the IP addresses of the source
VTEP (VTEP1) and destination VTEPs (VTEP2 and VTEP3), the MAC addresses of
VTEP1 and the next-hop device on the route to the destination VTEP as the outer source
IP, destination IP, source MAC, and destination MAC addresses respectively. The
encapsulated packet is transmitted based on the outer MAC and IP addresses until it
reaches the destination VTEP (VTEP2/VTEP3).
3. VTEP2/VTEP3 on Router2/Router3 receives the encapsulated VXLAN packet and
decapsulates the packet to obtain the original packet sent by PC_1. VTEP2 and VTEP3
also learn the mapping between PC_1's MAC address, VNI, and IP address of the remote
VTEP, and saves the mapping in the local MAC address table. VTEP 2 and VTEP 3 then
process the packet based on the interface configuration and broadcast the packet in the
corresponding Layer 2 domain.
4. After receiving the ARP request packet, PC_2 and PC_3 check whether the destination
IP address in the packet is its own IP address. If so, PC_2 or PC_3 sends an ARP reply
packet. If not, PC_2 or PC_3 discards the packet.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-8 Forwarding process of ARP reply packets

Router3
VNI:20
VTEP3:10.3.3.2/32 PC_3
MAC_3
MAC VNI Remote VTEP IP Address IP_3
VTEP3
MAC_2 20 10.2.2.2 nnel
N Tu
PC_1 VXLA
VTEP1
MAC_1 Port1 Network
IP_1 VXLA
N Tu VTEP2
Router1 nnel
PC_2
VNI:20 MAC_2
VTEP1:10.1.1.2/32 Router2 IP_2
VNI:20 MAC VNI Inbound Interface
VTEP2:10.2.2.2/32 MAC_2 20 Port3
Router1 Router2 encapsulates ARP reply packet

decapsulates the VXLAN packet. the VXLAN packet. sent by PC_2
DMAC Net MAC SMAC MAC_2
SMAC MAC_2
SMAC VTEP2 MAC SIP IP_2
SIP IP_2 SIP 10.2.2.2
DMAC MAC_1 DMAC MAC_1
DIP 10.1.1.2 DIP IP_1
DIP IP_1
UDP S_P HASH
UDP D_P 4789
VNI 20
SMAC MAC_2
Traffic SIP IP_2
forwarding path DMAC MAC_1
DIP IP_1
Figure 14-8 shows the forwarding process of ARP reply packets.
1. PC_2 sends a unicast ARP reply packet after learning the MAC address of PC_1. The
source MAC, destination MAC, source IP, and destination IP addresses in the packet are
MAC_2, MAC_1, IP_2, and IP_1, respectively.
2. After receiving the ARP reply packet, VTEP2 checks the VNI to which the packet
belongs. At the same time, VTEP2 learns the mapping between MAC_2, VNI, and
interface receiving the packet, and saves the mapping to the local MAC address table.
VTEP2 then encapsulates the packet. During packet encapsulation, VTEP2 adds the IP
addresses of the source VTEP (VTEP2) and destination VTEP (VTEP1), the MAC
addresses of VTEP2 and the next-hop device on the route to VTEP1 as the outer source
IP, destination IP, source MAC, and destination MAC addresses respectively. The
encapsulated packet is transmitted based on the outer MAC and IP addresses until it
reaches the destination VTEP (VTEP1).
3. VTEP1 receives the encapsulated VXLAN packet and decapsulates the packet to obtain
the original packet sent by PC_2. VTEP1 also learns the mapping between PC_2's MAC
address, VNI, and IP address of the remote VTEP (VTEP2), and saves the mapping in
the local MAC address table. VTEP1 then sends the decapsulated packet to PC_1. After
learning the MAC address of each other, PC_1 and PC_2 communicate in unicast mode.
Intra-Subnet Packet Forwarding

The packet forwarding process is classified into known unicast packet forwarding and
broadcast, unknown unicast, and multicast (BUM) packet forwarding based on the type of
destination MAC address in original packets.
Only VXLAN Layer 2 gateways can implement known unicast packet forwarding in a subnet
and BUM packet forwarding. The forwarding processes do not require any Layer 3 gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l Forwarding Process of Known Unicast Packets

Figure 14-9 shows the known unicast packet forwarding process.
Figure 14-9 Forwarding process of known unicast packets
Router3
VTEP1 VTEP2
Router1 VXLAN Tunnel Router2
VNI:20 VNI:20
VTEP:10.1.1.2/32 VTEP:10.2.2.2/32
PC_1 PC_2
MAC_1 MAC_2
IP_1 IP_2
PC_2 decapsulates the VXLAN
PC_1 sends a VTEP1 encapsulatespacket and re-encapsulates the
Layer 2 packet the VXLAN packet Layer 2 packet
DMAC MAC_2 DMAC Net MAC DMAC MAC_2
SMAC MAC_1 SMAC VTEP1 MAC SMAC MAC_1
VLAN SIP 10.1.1.2 VLAN
2 2
Tag DIP 10.2.2.2 Tag
UDP S_P HASH
UDP D_P 4789 Traffic
VNI 20 forwarding path
DMAC MAC_2
SMAC MAC_1
Payload
a. After Router1 receives a packet from PC_1, Router1 determines the Layer 2 bridge
domain (BD) of the packet based on the access interface and VLAN information
carried in the packet, and searches for the outbound interface and encapsulation
information based on the BD.
b. The VXLAN Tunnel Endpoint (VTEP1) on Router1 encapsulates the packet based
on the found encapsulation information and forwards the packet to the outbound
interface.
c. After the VTEP2 on Router2 receives the VXLAN packet, it verifies the UDP
destination port number, source and destination IP addresses, and VXLAN Network
Identifier (VNI) of the packet to determine its validity. After confirming that the
packet is valid, the VTEP obtains the BD based on the VNI and decapsulates the
VXLAN packet to obtain the inner Layer 2 packet.
d. Router2 finds out the outbound interface and encapsulation information in the local
MAC address table based on the destination MAC address in the inner Layer 2
packet, adds a VLAN tag to the packet, and forwards it to PC_2.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Packet forwarding from PC_2 to PC_1 is similar to that described above, and is not
mentioned here.
l BUM Packet Forwarding Process
After a BUM packet enters the VXLAN tunnel, the source VTEP replicates the BUM
packet based on the tunnel list and encapsulates the original and replicated packets.
When these packets leave the VXLAN tunnels, the destination VTEPs decapsulate them.
Figure 14-10 shows the BUM packet forwarding process.
NOTE
On a VXLAN network, multiple destination VTEP IP addresses can be configured for a VNI, and
the list of these IP addresses is regarded as a tunnel list. After an interface receives the BUM
packet, the source VTEP replicates the packet based on the tunnel list and forwards it to all the
VTEPs with the same VNI.
Figure 14-10 BUM packet forwarding process

Router3
VNI:20
VTEP3:10.3.3.2/32
PC_3
MAC_3
VTEP3 IP_3
VTEP1
Network VLAN 2
PC_1
MAC_1
IP_1 Router1 VTEP2
VLAN 2 VNI:20
VTEP1:10.1.1.2/32 PC_2 Traffic
Router2 MAC_2 forwarding path
VNI:20 IP_2
VTEP2:10.2.2.2/32 Router2/Router3
Router1 encapsulates VLAN 2 decapsulates the VXLAN
PC_1 sends a the VXLAN packet packet and re-encapsulates
Layer 2 packet Router1—>Router2 Router1—>Router3 the Layer 2 packet
DMAC Net MAC DMAC Net MAC DMAC All F
DMAC All F
SMAC VTEP1 MAC SMAC VTEP1 MAC SMAC MAC_1
SMAC MAC_1 SIP 10.1.1.2 SIP 10.1.1.2 VLAN
VLAN 2
2 DIP 10.2.2.2 DIP 10.3.3.2 Tag
Tag
UDP S_P HASH UDP S_P HASH DMAC All F
UDP D_P 4789 UDP D_P 4789 SMAC MAC_1
VNI 20 VNI 20 VLAN
DMAC All F DMAC All F 2
Tag
Payload Payload
a. After Router1 receives a packet from PC_1, Router1 determines the BD of the
packet based on the access interface and VLAN information carried in the packet.
b. The VTEP1 on Router1 obtains the tunnel list for the VNI based on the BD,
replicates the packet based on the tunnel list, and performs VXLAN tunnel
encapsulation before forwarding it to the outbound interface.
c. After the VTEP2 on Router2 or Router3 receives the VXLAN packet, it verifies the
UDP destination port number, source and destination IP addresses, and VNI of the
packet to determine its validity. After confirming that the packet is valid, the VTEP
obtains the BD based on the VNI and decapsulates the VXLAN packet to obtain the
inner Layer 2 packet.
d. Router2 or Router3 checks the destination MAC address of the inner Layer 2 packet
and finds that it is a BUM packet, Router2 or Router3 then broadcasts the packet in

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
the corresponding BD to the user side. Router2 or Router3 finds out all outbound
interfaces to the user side and encapsulation information in the local MAC address
table, adds a VLAN tag to the packet, and forwards it to PC_2 or PC_3.
Packet forwarding from PC_2 or PC_3 to PC_1 is similar to the known unicast packet
forwarding process, and is not mentioned here.
Inter-Subnet Packet Forwarding

If end users in a VXLAN site need to access the Internet or communicate with end users in
another VXLAN site, a VXLAN Layer 3 gateway needs to be deployed to provide end users
with Layer 3 services. Figure 14-11 shows the inter-subnet packet forwarding process.
IP addresses of PC_1and PC_2 are in different network segments. For the first time, PC_1
needs to broadcast an ARP request packet to request the MAC address of VBDIF 10. After
obtaining the MAC address of the gateway, PC_1 sends a data packet to the gateway. The
gateway also broadcasts an ARP request packet to request the MAC address of PC_2. After
obtaining the MAC address, the gateway forwards the data packet to PC_2. The preceding
MAC address learning process is the same as that in MAC Address Learning.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-11 Inter-subnet packet forwarding process
Routing table
Destination NextHop Interface
192.168.10.1/32 192.168.10.10/24 VBDIF10
192.168.20.1/32 192.168.20.10/24 VBDIF20
Router3
VNI:10 L3 gateway
VNI:20 VBDIF10:192.168.10.10/24 MAC_3
VTEP:10.3.3.2/32 VTEP3 VBDIF20:192.168.20.10/24 MAC_4
VX
Traffic
le
LA
nn
forwarding path
N
Tu
Tu
N
n
LA
ne
VX
l
VTEP1 VTEP2
Router2
Router1
VNI:20
VNI:10
VTEP:10.2.2.2/32
VTEP:10.1.1.2/32
PC_1 PC_2
VLAN 10 IP_1 VLAN 20 IP_2
MAC_1 MAC_2
IP_1:192.168.10.1/32 IP_2:192.168.20.1/32
PC_1 sends an inter- Router1 encapsulates Router3 decapsulates Router2 decapsulates
subnet IP packet the VXLAN packet the VXLAN packet the VXLAN packet
DMAC MAC_3 DMAC Net MAC DMAC Net MAC DMAC MAC_2
SMAC MAC_1 SMAC VTEP1 MAC SMAC VTEP3 MAC SMAC MAC_4
SIP IP_1 SIP 10.1.1.2 SIP 10.3.3.2 SIP IP_1
DIP IP_2 DIP 10.3.3.2 DIP 10.2.2.2 DIP IP_2
Payload UDP S_P HASH UDP S_P HASH Payload
UDP D_P 4789 UDP D_P 4789
VNI 10 VNI 20
DMAC MAC_3 DMAC MAC_2
SIP IP_1 SIP IP_1
DIP IP_2 DIP IP_2
Payload Payload
1. After Router1 receives a packet from PC_1, Router1 determines the Layer 2 BD of the
packet based on the access interface and VLAN information carried in the packet, and
searches for the outbound interface and encapsulation information based on the BD.
2. The VTEP1 on Router1 performs VXLAN tunnel encapsulation based on the outbound
interface and encapsulation information, and forwards the packet to Router3.
3. Router3 decapsulates the received VXLAN packet, finds that the destination MAC
address in the inner packet is MAC_3 of the Layer 3 gateway interface VBDIF10, and
determines that the packet needs to be forwarded at Layer 3.
4. Router3 removes the Ethernet header from the inner packet to parse the destination IP
address. It then searches the routing table based on the destination IP to obtain the next-
hop address, and searches ARP entries based on the next hop to obtain the destination
MAC address, VXLAN tunnel outbound interface, and VNI.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. Router3 re-encapsulates the VXLAN packet and forwards it to Router2. The source
MAC address in the Ethernet header of the inner packet is MAC_4 of the Layer 3
gateway interface VBDIF20.
6. After the VTEP2 on Router2 receives the VXLAN packet, it verifies the UDP
destination port number, source and destination IP addresses, and VXLAN Network
Identifier (VNI) of the packet to determine its validity. The VTEP then obtains the BD
based on the VNI, decapsulates the packet to obtain the inner Layer 2 packet, and
searches for the outbound interface and encapsulation information in the corresponding
BD.
7. Router2 adds a VLAN tag to the packet based on the outbound interface and
encapsulation information, and forwards the packet to PC_2.
Packet forwarding from PC_2 to PC_1 is similar to that described above, and is not
mentioned here.
14.3 Application Scenario

In Figure 14-12, an enterprise deploys its departments in different areas. To facilitate
management and maintenance, departments with the same service requirements are planned in
the same network segment, while those with different service requirements are planned in
different network segments. End users in the same or different departments need to
communicate with each other. For example, R&D departments 1 and 2 need to communicate
in the same network segment; the R&D department 2 and marketing department need to
communicate across different network segments.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-12 Communication between end users on a VXLAN network
Cloud
CPE
L3 gateway
VTEP Router3
l e
nn
VX
Traffic forwarding path
Tu
LA
N
N
Network
LA
Tu
VX
nn
l e
VTEP
Router4 el
A N Tunn VTEP Router2
Marketing VXL
department VTEP
R&D
Router1
department 2
R&D
department 1
VXLAN provides Layer 2 interconnection for dispersed physical sites. For example, in
Figure 14-12, Router1 and Router2 are VXLAN Layer 2 gateway, and they establish a
VXLAN tunnel to enable end users in R&D departments 1 and 2 to communicate with each
other in the same network segment.
VXLAN provides Layer 3 interconnection for tenants in different sites. For example, when
the R&D department 2 wants to communicate with the marketing department, Router3
functions as the VXLAN Layer 3 gateway to establish VXLAN tunnels with Router2 and
Router4 respectively.
After static VXLAN tunnels are established between the routers, they dynamically learn flow
table information, such as MAC address entries and ARP entries. After flow table information
is learned, end users in the same or different network segments can communicate with each
other over the VXLAN tunnels.
14.4 Licensing Requirements and Limitations for VXLAN

This section describes VXLAN configuration notes.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Involved Network Element

None
License Support
VXLAN is a basic feature of the device and is not under license control.
Feature Dependencies and Limitations

l The router does not support VXLAN over MPLS LSP tunnel. If VXLAN packets
received from a peer are encapsulated by MPLS, the VTEP fails to decapsulate the
packets.
l The router does not support VXLAN over GRE tunnel. If VXLAN packets received
from a peer are encapsulated by GRE, the VTEP fails to decapsulate the packets.
l In VXLAN scenarios, do not advertise routes destined for the local VTEP address to the
peer end of a VXLAN tunnel through a VBDIF interface during route configuration.
Otherwise, the next hop of the remote VTEP address of the VXLAN tunnel may be the
VBDIF interface on the ingress of the tunnel, causing a loop on the device.
Only the AR100, AR120, AR150, AR160, AR200, AR1200 series, AR2220E, AR2240, and
AR3260 support VXLAN. The AR2220E, AR2240, and AR3260 need to change the working
mode of all ports on the SRU, 4GECS and 2X10GL from Layer 3 mode to Layer 2 mode to
support VXLAN, and the interface that change the working mode to layer 2 only support
VXLAN.
Only the AR100, AR120, AR150, AR160 (except AR161EW, AR161EW-M1, AR169EW,
AR169EGW-L), AR200, AR1200 AR3600series, AR2220E and AR2240 support EVPN.
14.5 Configuring VXLAN (in Static Mode)

Before configuring user communication over VXLAN tunnels, ensure Layer 3 route
reachability.
Figure 14-13 shows the process of configuring communication between end users in the same
VXLAN network segment.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-13 Configuring communication between end users in the same VXLAN network
segment
Configure a
deployment mode for
VXLAN access
services
Configure a VXLAN
tunnel
Configure static MAC

address entries
Mandatory
Optional
Figure 14-14 shows the process of configuring communication between end users in different
VXLAN network segments.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-14 Configuring communication between end users in different VXLAN network
segments
Configure a
deployment mode for
VXLAN access
services
Configure a VXLAN
tunnel
Configure a Layer 3
VXLAN gateway
Configure static ARP

entries
Configure static MAC

address entries
Mandatory
Optional
14.5.1 Configuring Deployment Mode for VXLAN Access Service

Context
When configuring VXLAN on a device, you need to select a deployment mode for the
VXLAN access service on the downlink interface.
At the access side, two methods are available for deploying VXLAN services:
l Based on VLAN: You can associate one or more VLANs with a BD to add users in these
VLANs to the BD. This VLAN-based mode implements larger-granularity control, but is
easy to configure. It applies to VXLAN deployment on a live network.
l Based on encapsulation mode: The device sends packets of different encapsulation
modes to different Layer 2 sub-interfaces based on the VLAN tags contained in the
packets. You can bind a Layer 2 sub-interface to a BD to add specified users to the BD.
This mode implements refined and flexible control but requires more complex
configuration. It applies to VXLAN deployment on a new network.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run bridge-domain bd-id
A BD is created and the BD view is displayed.
By default, no BD is created.
Step 3 (Optional) Run description description
The description is configured for the BD.
By default, no description is configured for a BD.
Step 4 Run quit
Exit from the BD view and return to the system view.
Step 5 Configure a service access point.

l Based on VLAN:
a. Run vlan vlan-id
A VLAN is created and the VLAN view is displayed.
b. Run quit
Exit from the VLAN view and return to the system view.
c. Run bridge-domain bd-id
The view of an existing BD is displayed.
d. Run l2 binding vlan vlan-id
A VLAN is associated with the BD so that data packets can be forwarded in the
BD.
By default, a VLAN is not associated with a BD.
NOTE
n The VLANs to be bound to the BD have been created.

n One VLAN can be associated with only one BD, but one BD can be associated with
multiple VLANs.
n After a global VLAN is associated with a BD, you need to add corresponding
interfaces to the VLAN. An Eth-Trunk cannot be added to the VLAN.
l Based on encapsulation mode:
a. Run interface interface-type interface-number.subnum mode l2
A Layer 2 sub-interface is created, and the sub-interface view is displayed.
b. Run encapsulation { dot1q vid pe-vid | default | untag | qinq vid vlan-vid ce-vid
ce-vid }
An encapsulation mode is configured for a Layer 2 sub-interface to specify the type
of packets that can pass through the sub-interface.
By default, the encapsulation mode of packets allowed to pass a Layer 2 sub-
interface is not configured.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
When configuring an encapsulation mode on a Layer 2 sub-interface, pay attention to the

following points:
n The VLAN ID in dot1q mode or outer VLAN ID in qinq mode cannot be the same as
the allowed VLAN of the corresponding main interface or the global VLAN.
n On the same main interface, the VLAN ID in dot1q mode and the outer VLAN ID in
qinq mode must be different.
n After NAC authentication is configured on the main interface, the traffic encapsulation
type on a Layer 2 sub-interface cannot be set to default.
n When the encapsulation mode of a Layer 2 sub-interface is default, the corresponding
main interface cannot be added to any VLAN, including VLAN 1.
n Before the encapsulation mode of a Layer 2 sub-interface is set to default, the main
interface has only one sub-interface.
n After the encapsulation mode of a Layer 2 sub-interface is set to default, no other sub-
interface can be created on the main interface.
n When the encapsulation mode of a Layer 2 sub-interface is set to untag, other sub-
interfaces of the main interface cannot be set to untag.
n You can configure only one encapsulation mode for each Layer 2 sub-interface. If an
encapsulation mode has been configured for a Layer 2 sub-interface, run the undo
encapsulation command to delete the original mode before you configure another mode.
n When the device functions as a Layer 3 VXLAN gateway, the traffic encapsulation type
on a Layer 2 sub-interface cannot be set to default.
A specified Layer 2 sub-interface is associated with a BD so that data packets can
be forwarded in the BD.
By default, a Layer 2 sub-interface is not associated with a BD.
----End
14.5.2 Configuring a VXLAN Tunnel

Context
When configuring VXLAN on a device, you need to configure related information for
VXLAN tunnel establishment on an uplink interface.
A VXLAN tunnel is established based on the IP addresses of two VXLAN Tunnel Endpoints
(VTEPs). Therefore, you need to configure the source VTEP IP address and destination VTEP
IP address on the devices on both ends of a tunnel.
Take Router1 in Figure 14-15 as an example. The following describes the configurations
required for establishment of a VXLAN tunnel:
l Source VTEP IP address: source IP address in a VXLAN packet, that is, IP address of
Eth2/0/0 on Router1
l Destination VTEP IP address: destination IP address in a VXLAN packet, that is, IP
address of Eth2/0/0 on Router1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-15 VXLAN tunnel establishment
Network
Eth2/0/0 Eth2/0/0
VTEP1 VTEP2
Router1 VXLAN Tunnel Router2
Tenant Tenant
branch 1 branch 2
NOTE
l You need to run the vni head-end peer-list command to configure the corresponding VTEP address
even if the source VTEP matches only one destination VTEP.
l Run the ping command to check whether a reachable route exists between two ends of the tunnel. If
there is a reachable route, the tunnel can be established and packets can be normally forwarded. If
the two devices have a route to each other but the route is unreachable, the tunnel can still go Up but
packets cannot be forwarded.
Procedure
The BD view is displayed.
Step 3 Run vxlan vni vni-id
A VNI is configured for the BD.
By default, no VNI is associated with a BD.
Step 4 Run quit
Step 5 Run interface nve nve-number
An NVE interface is created, and the NVE interface view is displayed.
Step 6 Run source ip-address
An IP address is configured for the source VTEP.
By default, no IP address is configured for a source VTEP.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Step 7 Run vni vni-id head-end peer-list ip-address &<1-10>

An IP address is configured for the destination VTEP with a specified VNI.
By default, no IP address is configured for the destination VTEP with a specified VNI.
Step 8 Run quit
Exit from the NVE interface view and return to the system view.
----End
14.5.3 Configuring a Layer 3 VXLAN Gateway

Context
A VBDIF interface is configured on a VXLAN Layer 3 gateway to forward packets across
network segments. You do not need to create a VBDIF interface for communication between
users in the same network segment.
another VXLAN site, a VXLAN Layer 3 gateway needs to be deployed to provide end users
with Layer 3 services.
In Figure 14-16, after you create a logical Layer 3 VBDIF interface and configure an IP
address for the VBDIF interface, the VBDIF interface functions as the gateway for tenants in
the BD to forward packets at Layer 3 based on the IP address. Each BD has only one VBDIF
interface.
To ensure that users in different network segments can communicate with each other, ensure
that the default gateway address is the IP address of the VBDIF interface on the VXLAN
Layer 3 gateway.
Figure 14-16 Layer 3 VXLAN gateway networking
Router3
VBDIF 10 VBDIF 20
VTEP3
BD 10 BD 20
l
VX
ne
n
LA
Tu
N
N
Tu
LA
nn
Network
VX
el
VTEP1 GE1/0/1 GE1/0/1 VTEP2
Router1 Router2
PC_1 PC_2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
Step 2 Run interface vbdif bd-id
A VBDIF interface is created and the VBDIF interface view is displayed.
NOTE
The number of the VBDIF interface must match an existing BD ID.
Step 3 Run ip address ip-address { mask | mask-length } [ sub ]

An IP address is configured for the VBDIF interface to implement Layer 3 communication.
By default, no IP address is configured for a VBDIF interface.
----End
14.5.4 (Optional) Configuring Static ARP Entries
Context
Static ARP entries are manually configured and maintained. They cannot be aged and
overridden by dynamic ARP entries. You can configure static ARP entries on a Layer 3
VXLAN gateway to improve communication security. Static ARP entries ensure
communication between the local device and a specified device by using a specified MAC
address so that attackers cannot modify mappings between IP addresses and MAC addresses
in static ARP entries.
Procedure
Step 2 Run arp static ip-address mac-address vni vni-id source-ip source-ip-address peer-ip peer-
ip-address
A static ARP entry of a VXLAN tunnel is configured.
By default, a static MAC address entry of a VXLAN tunnel is not configured.
NOTE
The value of ip-address must be in the same network segment as that of the Layer 3 gateway.
Step 3 On a VXLAN network, mapping between IP addresses and MAC addresses can be configured
on the user access side. When you configure static ARP entries by VLAN, the interface
interface-type interface-number parameter must be a Layer 2 Ethernet interface. When you
configure static ARP entries by traffic encapsulation type, the interface interface-type
interface-number parameter must be a Layer 2 sub-interface.
l By VLAN:
Run the arp static ip-address mac-address vni vni-id vid vlan-id interface interface-
type interface-number command to configure static ARP entries.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
l By traffic encapsulation type:

– If the traffic encapsulation type is dot1q, run the arp static ip-address mac-address
vni vni-id vid vlan-id interface interface-type interface-number command to
configure static ARP entries. The value of vid vlan-id in this command must be the
same as that in the encapsulation dot1q vid pe-vid command.
– If the traffic encapsulation type is qinq, run the arp static ip-address mac-address
vni vni-id vid vlan-id cevid ce-vid interface interface-type interface-number
command to configure static ARP entries. The values of vid vlan-id and cevid ce-
vid in this command must be the same as the values in the encapsulation qinq vid
vlan-vid ce-vid ce-vid command.
– If the traffic encapsulation type is untag, run the arp static ip-address mac-address
vni vni-id interface interface-type interface-number command to configure static
ARP entries.
----End
Checking the Configuration

Run the display arp [ all | brief ] command to view all ARP entries.
14.5.5 (Optional) Configuring a Static MAC Address Entry
Context
To reduce broadcast traffic and improve network security, you can configure static MAC
address entries on the VXLAN-enabled device to specify the forwarding path of BUM
packets. This prevents unauthorized users from intercepting data of authorized users.
For packet forwarding in different directions, static MAC address entries are configured in
two directions:
l Configure static MAC address entries on the VXLAN side to specify the VXLAN
encapsulation direction when traffic is forwarded from the LAN side to the VXLAN
side.
l Configure static MAC address entries on the LAN side to specify the outbound interface
when traffic is forwarded from the VXLAN side to the LAN side.
Procedure
l Configure a static MAC address entry on the VXLAN side.
a. Run system-view
b. Run mac-address static mac-address bridge-domain bd-id source source-ip-
address peer peer-ip-address vni vni-id
A static MAC address entry of a VXLAN tunnel is configured.
By default, a static MAC address entry of a VXLAN tunnel is not configured.
l Configure a static MAC address entry on the LAN side.
a. Run system-view

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
b. Run mac-address static mac-address interface-type interface-number.subnum

bridge-domain bd-id { default | untag | vid vid }
A static MAC address entry based on a BD is configured.
By default, no static MAC address entry based on a BD is configured.
----End
Checking the Configuration

Run the display mac-address [ mac-address ] bridge-domain bd-id command to check
MAC address entries in a BD.
14.5.6 (Optional) Configuring the IP Address of the Next Hop to

Which Traffic Entering a Dynamic VXLAN Tunnel Is Redirected
Context
You can configure the IP address of the next hop to which traffic entering a dynamic VXLAN
tunnel is redirected, implementing policy-based routing (PBR) for the traffic.
NOTE
If the IP address of the next hop to which traffic entering a dynamic VXLAN tunnel is redirected is
unreachable or invalid, the configured next hop IP address does not take effect.
When configuring the IP address of the next hop to which traffic entering a dynamic VXLAN tunnel is
redirected, ensure that the next hop and the local device are in the same VPN instance.
Procedure
Step 2 Run ip vpn-instance
By default, no VPN instance is configured.
The IPv4 address family is enabled for the VPN instance.
By default, the IPv4 address family is disabled for a VPN instance.
Step 4 Run quit
Return to the VPN instance view.
Step 5 Run vni redirect ip-nexthop ip-address
The IP address of the next hop to which traffic entering a dynamic VXLAN tunnel is
redirected is configured.
By default, the IP address of the next hop to which traffic entering a dynamic VXLAN tunnel
is redirected is not configured.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
14.5.7 Verifying the VXLAN Configuration in Centralized

Gateway Mode Using Static Mode
Context
After you complete configuring VXLAN service access points and VXLAN tunnels, run the
following commands to verify the VXLAN configuration.
Procedure
l Run the display bridge-domain [ bd-id [ brief | verbose ] ] command to view the BD
configuration.
l Run the display vxlan tunnel [ tunnel-id ] [ verbose ] command to view VXLAN tunnel
information.
l Run the display vxlan vni [ vni-id [ verbose ] ] command to view VXLAN
configuration of a specified VNI or all VNIs.
l Run the display vxlan peer [ vni vni-id ] command to view the destination VTEP IP
address with a specified VNI.
l Run the display vxlan encapsulation interface interface-type interface-number
[ bridge-domain bd-id | default | dot1q [ vid pe-vid ] | qinq [ vid vlan-vid [ ce-vid ce-
vid ] ] | untag ] command to view VXLAN encapsulation information about Layer 2
sub-interfaces of a main interface.
----End
14.6 Configuring VXLAN (in BGP EVPN Mode)

Before configuring user communication over VXLAN tunnels, ensure Layer 3 route
reachability.
Figure 14-17 shows the process of configuring communication between end users in different
VXLAN network segments.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-17 Configuring communication between end users in different VXLAN network
segments
Configure a
deployment mode for
VXLAN access
services
Configure a VXLAN
tunnel
Configure a Layer 3
VXLAN gateway
Mandatory
14.6.1 Configuring Deployment Mode for VXLAN Access Service
Context
When configuring VXLAN on a device, you need to select a deployment mode for the
VXLAN access service on the downlink interface.
At the access side, two methods are available for deploying VXLAN services:
l Based on VLAN: You can associate one or multiple VLANs with a BD to add users in
these VLANs to the BD. This VLAN-based mode implements larger-granularity control,
but is easy to configure. It applies to VXLAN deployment on a live network.
l Based on encapsulation mode: The device sends packets of different encapsulation
modes to different Layer 2 sub-interfaces based on the VLAN tags contained in the
packets. You can bind a Layer 2 sub-interface to a BD to add specified users to the BD.
This mode implements refined and flexible control but requires more complex
configuration. It applies to VXLAN deployment on a new network.
Procedure
A BD is created and the BD view is displayed.
By default, no BD is created.
Step 3 (Optional) Run description description
The description is configured for the BD.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
By default, no description is configured for a BD.

Step 4 Run quit
Step 5 Configure a service access point.
l Based on VLAN:
a. Run vlan vlan-id
A VLAN is created and the VLAN view is displayed.
b. Run quit
Exit from the VLAN view and return to the system view.
The view of an existing BD is displayed.
d. Run l2 binding vlan vlan-id
A VLAN is associated with the BD so that data packets can be forwarded in the
BD.
By default, a VLAN is not associated with a BD.
NOTE
n The VLANs to be bound to the BD have been created.

n One VLAN can be associated with only one BD, but one BD can be associated with
multiple VLANs.
n After a global VLAN is associated with a BD, you need to add corresponding
interfaces to the VLAN. An Eth-Trunk cannot be added to the VLAN.
l Based on encapsulation mode:
a. Run interface interface-type interface-number.subnum mode l2
A Layer 2 sub-interface is created, and the sub-interface view is displayed.
By default, no Layer 2 sub-interface is created.
b. Run encapsulation { dot1q { vid pe-vid } | default | untag | qinq { vid vlan-vid
ce-vid ce-vid } }
An encapsulation mode is configured for a Layer 2 sub-interface to specify the type
of packets that can pass through the sub-interface.
By default, the encapsulation mode of packets allowed to pass a Layer 2 sub-
interface is not configured.
A specified Layer 2 sub-interface is associated with a BD so that data packets can
be forwarded in the BD.
By default, a Layer 2 sub-interface is not associated with a BD.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
NOTE
When configuring an encapsulation mode on a Layer 2 sub-interface, pay attention to the

following points:
– The VLAN ID in dot1q mode or outer VLAN ID in qinq mode cannot be the same as the
allowed VLAN of the corresponding main interface or the global VLAN.
– On the same main interface, the VLAN ID in dot1q mode and the outer VLAN ID in qinq
mode must be different.
– When the encapsulation mode of a Layer 2 sub-interface is default, the corresponding main
interface cannot be added to any VLAN, including VLAN 1.
– Before the encapsulation mode of a Layer 2 sub-interface is set to default, the main interface
has only one sub-interface.
– After the encapsulation mode of a Layer 2 sub-interface is set to default, no other sub-
interface can be created on the main interface.
– When the encapsulation mode of a Layer 2 sub-interface is set to untag, other sub-interfaces
of the main interface cannot be set to untag.
– When the device functions as a Layer 3 VXLAN gateway, the traffic encapsulation type on a
Layer 2 sub-interface cannot be set to default.
----End
14.6.2 Configuring a VXLAN Tunnel
Context
When deploying a VXLAN network, you need to configure the uplink interfaces of the
devices for VXLAN tunnel establishment.
A VXLAN tunnel is established between IP addresses of two virtual tunnel end points
(VTEPs). Border Gateway Protocol (BGP) Ethernet VPN (EVPN) can be used to dynamically
establish VXLAN tunnels by establishing a BGP EVPN peer relationship between two
VTEPs and using BGP EVPN routes to transmit VXLAN network identifiers (VNIs) and
VTEP IP addresses between the peer.
NOTE
A VXLAN tunnel is specified by a pair of VTEP IP addresses. When a local VTEP receives the same remote
VTEP IP address repeatedly, only one VXLAN tunnel can be established, but packets are encapsulated with
different VNIs before being forwarded through the tunnel.
Procedure
1. Run system-view
2. Run bgp as-number
3. Run peer ipv4-address as-number { as-number-plain | as-number-dot }
The remote PE is configured as a BGP EVPN peer.
4. Run peer ipv4-address connect-interface loopback interface-number
An interface is specified for setting up a TCP connection with the BGP EVPN peer.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
5. Run l2vpn-family evpn

The BGP-EVPN address family view is displayed.
6. Run peer { ipv4-address | group-name } enable
The ability to exchange EVPN routes with the peer or in a group is enabled.
7. (Optional) Run peer ipv4-address group group-name
The BGP EVPN peer is added to a peer group.
Adding the BGP EVPN peer to a peer group simplifies configuration and management of
the BGP network.
8. (Optional) Run peer { group-name | ipv4-address } route-policy route-policy-name
export
The BGP EVPN peer (group) is configured to advertise only specified routes.
To strictly control EVPN route advertisement, you need to configure an export routing
policy. It can filter routes to be advertised to other EVPN peers (group).
9. (Optional) Run peer { ipv4-address | group-name } route-policy route-policy-name
import
The BGP EVPN peer (group) is configured to receive only specified routes.
To strictly control EVPN route acceptance, you need to configure an import routing
policy. It can filter routes received from other EVPN peers (group).
10. (Optional) Run undo policy vpn-target
The device is disabled from filtering received EVPN routes by the VPN target.
11. (Optional) Run peer { group-name | ipv4-address } mac-limit mac-limit [ idle-forever |
idle-timeout times ]
The maximum number of MAC advertisement routes received from a peer is specified.
An EVPN instance may import many unused MAC advertisement routes from some
peers. It is recommended that you run this command when the number of received MAC
advertisement routes from the peers occupies a large percentage of the total number of
MAC advertisement routes on the device.
12. Run quit
Exit from the BGP-EVPN address family view and return to the BGP view.
13. Run quit
Exit from the BGP view and return to the system view.
Step 2 Configure an IP address for the source VTEP.
1. Run interface nve nve-number
An NVE interface is created, and the NVE interface view is displayed.
By default, no NVE interface is created.
2. Run source ip-address
An IP address is configured for the source VTEP.
By default, no IP address is configured for a source VTEP.
----End

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
14.6.3 Configuring a Layer 3 VXLAN Gateway

Context
A VBDIF interface is configured on a Layer 3 VXLAN gateway to forward packets across
network segments. You do not need to create a VBDIF interface for communication between
users in the same network segment.
another VXLAN site, a Layer 3 VXLAN gateway needs to be deployed to provide end users
with Layer 3 services.
After you create a logical Layer 3 VBDIF interface and configure an IP address for the
VBDIF interface, the VBDIF interface functions as the gateway for tenants in the BD to
forward packets at Layer 3 based on the IP address. Each BD has only one VBDIF interface.
To ensure that users in different network segments can communicate with each other, ensure
that the default gateway address is the IP address of the VBDIF interface on the Layer 3
VXLAN gateway.
Procedure
Step 1 Configure a VPN instance.
1. Run system-view
3. Run ipv4-family
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4
By default, the IPv4 address family is disabled for the VPN instance.
4. Run route-distinguisher route-distinguisher
By default, no RD is configured for the VPN instance.
5. Run vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-
extcommunity ] evpn
The VPN target is configured for the VPN instance.
A VPN target is a BGP extended community attribute. It is used to control the receiving
and advertisement of EVPN routing information. A maximum of eight VPN targets can
be configured using a vpn-target command. If you want to configure more VPN targets
in the EVPN instance address family, run the vpn-target evpn command multiple times.
6. (Optional) Run export route-policy policy-name evpn
The VPN instance IPv4 address family is associated with an export routing policy to
filter EVPN routes to be advertised to the EVPN address family.
To strictly control EVPN route advertisement, you need to configure an export routing
policy. It can filter routes to be advertised to the EVPN address family.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
7. (Optional) Run import route-policy policy-name evpn

The VPN instance IPv4 address family is associated with an import routing policy to
filter EVPN routes received from the EVPN address family.
To strictly control EVPN route acceptance, you need to configure an import routing
policy. It can filter routes received from the EVPN address family.
8. Run quit
Exit from the VPN instance IPv4 address family view and return to the VPN instance
view.
9. Run vxlan vni vni-id
A VNI is bound to the VPN instance.
By default, no VNI is bound to the VPN instance.
10. Run quit
Exit from the VPN instance view and return to the system view.
Step 2 Configure a Layer 3 gateway and bind the VPN instance to it.
1. Run interface vbdif bd-id
A VBDIF interface is created and the VBDIF interface view is displayed.
NOTE
The number of the VBDIF interface must match an existing BD ID.

The VBDIF interface is bound to the VPN instance.
NOTE
– Using the ip binding vpn-instance command will delete Layer 3 configurations such as the IP
address and routing protocol on the VBDIF interface. Reconfigure them if needed.
– An interface cannot be bound to a VPN instance that is not enabled with an address family.
3. Run ip address ip-address { mask | mask-length } [ sub ]
An IP address is configured for the VBDIF interface to implement Layer 3
communication.
By default, no IP address is configured for a VBDIF interface.
4. (Optional) Run mac-address mac-address
A MAC address is configured for the VBDIF interface.
By default, the MAC address of a VBDIF interface is the system MAC address.
5. Run quit
Exit from the VBDIF interface view and return to the system view.
Step 3 Configure VXLAN gateways to advertise IP prefix routes to each other.
1. Run bgp as-number
2. Run ipv4-family vpn-instance vpn-instance-name

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
3. Run import-route protocol [ process-id ] [ med med | route-policy route-policy-name ]

*
Routes of other protocols are imported to the BGP-VPN instance IPv4 address family
view.
To enable advertisement of host IP routes, you only need to configure the device to
import direct routes. To enable advertisement of network segment routes, advertise these
routes using a dynamic routing protocol such as OSPF and enable the device to import
routes of dynamic routing protocols.
4. Run advertise l2vpn evpn
The VPN instance is enabled to advertise IP routes to the BGP-EVPN address family.
By default, the VPN instance is disabled from advertising IP routes to the BGP-EVPN
address family.
----End
14.6.4 Checking the Configuration
Context
After you complete configuring VXLAN service access points and VXLAN tunnels, run the
following commands to check the VXLAN configuration.
Procedure
l Run the display bridge-domain [ bd-id [ brief | verbose ] ] command to view the BD
configuration.
l Run the display vxlan tunnel [ tunnel-id ] [ verbose ] command to view VXLAN tunnel
information.
l Run the display vxlan vni [ vni-id [ verbose ] ] command to view VXLAN
configuration of a specified VNI or all VNIs.
l Run the display bgp evpn routing-table command to view EVPN route information.
----End
14.7 Configuration Examples for VXLANs

14.7.1 Example for Configuring Communication Within a
Network Segment Through a VXLAN Tunnel
In Figure 14-18, an enterprise has two departments scattered in different geographical
locations. As the two departments have the same service requirements, they are planned in the
same network segment. End users in both departments belong to VLAN 10. They need to
communicate over the VXLAN tunnel.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-18 Configuring communication within a network segment through a VXLAN

tunnel
Cloud
CPE
Loopback 1
10.3.3.2/32
Router3 VTEP
19
4
Eth 8.3.
2/2
2.1
68 /1
2.1 /0
2/0 2/2
.2.
6
19 Eth2
/2 4
4
19
1/2
68 /0
Eth 8.3.
2.1
2.1 /0
.2.
2/0 1/2
19 th2
6
/0 4
E
Router1 VTEP Router2

VXLAN Tunnel VTEP
Loopback 1 Loopback 1
10.1.1.2/32 10.2.2.2/32
Eth2/0/1 Eth2/0/1
Marketing Marketing
department 1 department 2
connectivity.
3. Configure information for VXLAN tunnel establishment on Router1 and Router2.
Procedure
# Configure IP addresses for interfaces on Router1. The configurations of Router2 and
Router3 are similar to the configuration of Router1, and are not mentioned here. When OSPF
is used, the 32-bit loopback address of each router must be advertised.
[Router1] ospf

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
# After OSPF is configured, the Routers can learn the loopback interface address of each
other and successfully ping each other. The following shows the ping result from Router1 to
Router2.

0.00% packet loss

[Router1-bd10] quit
[Router2-bd10] quit
Step 3 Configure information for VXLAN tunnel establishment on Router1 and Router2.
[Router1-bd10] quit
[Router1-Nve1] vni 2010 head-end peer-list 10.2.2.2
[Router1-Nve1] quit
[Router2-bd10] quit
[Router2-Nve1] quit

# After the configuration is complete, run the display vxlan vni command on Router1 and
Router2. The command output shows that the VNI status is up. Run the display vxlan tunnel

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
command, and you can see VXLAN tunnel information. The command output on Router1 is
used as an example.
[Router1] display vxlan vni
VNI BD-ID State
-----------------------------------------
2010 10 up
-----------------------------------------
Number of vxlan vni bound to BD is : 2
VNI VRF-ID
-----------------------------------------
-----------------------------------------
Number of vxlan vni bound to VPN is : 0

----------------------------------------------------------------------------
4026531841 10.1.1.2 10.2.2.2 up static
----------------------------------------------------------------------------
After the configuration is complete, users in the same network segment can communicate
over a VXLAN tunnel.
----End
Configuration Files
#
sysname Router1
#
bridge-domain
10
vxlan vni 2010
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.1.1.2 255.255.255.255
#
interface
Nve1
source
10.1.1.2
vni 2010 head-end peer-list
10.2.2.2
#
ospf
1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
area
0.0.0.0
network 10.1.1.2
0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname Router2
#
bridge-domain
10
vxlan vni 2010
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.2.2.2 255.255.255.255
#
interface
Nve1
source
10.2.2.2
10.1.1.2
#
ospf
1
area
0.0.0.0
network 10.2.2.2
0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
#
sysname Router3
#
interface
Ethernet2/0/1
undo
portswitch
255.255.255.0
#
interface

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Ethernet2/0/2
undo
portswitch
255.255.255.0
#
interface
LoopBack1
ip address 10.3.3.2 255.255.255.255
#
ospf
1
area
0.0.0.0
network 10.3.3.2
0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
14.7.2 Example for Configuring a Layer 3 VXLAN Gateway to

Enable Communication Between Users in Different Network
Segments
belong VLAN 10 and VLAN 20, respectively. The enterprise requires that users in the
headquarters and branch can communicate using a Layer 3 VXLAN gateway.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-19 Configuring a Layer 3 VXLAN gateway to enable communication between

users in different network segments
Cloud
CPE
L3 gateway:
VBDIF10:192.168.10.10/24 Loopback 1
VBDIF20:192.168.20.10/24 10.3.3.2/32
VTEP
Router3
19
/24
Eth .3.
2.1
19 Eth2 VX 2.16 2/0/1
N 8.2.2
2/0 2/2 AN 0/0 4

68
19 Eth
/2
VX Eth2 .3.1
2.1 /0 LA
4
L
4
19
1/2
68 /0
2 .1
.2.
68
/ /2
VTEP VTEP
Loopback 1 Router1 Router2 Loopback 1
10.1.1.2/32 Eth2/0/1 Eth2/0/1 10.2.2.2/32
branch headquarters
PC_1 PC_2
192.168.10.1/24 192.168.20.1/24
3. Configure information for VXLAN tunnel establishment on Router1, Router2, and
Router3.
4. Configure a Layer 3 gateway on Router3.
Procedure

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

[Router1] ospf
Router2.

0.00% packet loss

[Router1-bd10] quit
[Router2-bd20] quit
Step 3 Configure information for VXLAN tunnel establishment on Router1, Router2, and Router3.
[Router1-bd10] quit
[Router1-Nve1] quit
[Router2-bd20] quit
[Router2-Nve1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router3-bd10] quit
[Router3-Nve1] quit
[Router3-bd20] quit
[Router3-Nve1] quit
Step 4 Configure a Layer 3 VXLAN gateway on Router3.


# After the preceding configuration, run the display vxlan vni and display vxlan tunnel
commands on Router1, Router2, and Router3. You can find that the VNI status is Up and
VXLAN tunnel information is displayed. The command output on Router3 is used as an
example.
VNI BD-ID State
-----------------------------------------
2010 10 up
2020 20 up
-----------------------------------------
VNI VRF-ID
-----------------------------------------
-----------------------------------------

----------------------------------------------------------------------------
4026531842 10.3.3.2 10.1.1.2 up static
4026531841 10.3.3.2 10.2.2.2 up static
----------------------------------------------------------------------------
----End
Configuration Files
#
sysname Router1
#
bridge-domain
10
vxlan vni 2010
#
interface

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.1.1.2 255.255.255.255
#
interface
Nve1
source
10.1.1.2
10.3.3.2
#
ospf
1
area
0.0.0.0
network 10.1.1.2
0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname Router2
#
bridge-domain
20
vxlan vni 2020
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
20
bridge-domain 20
#
interface
LoopBack1
ip address 10.2.2.2 255.255.255.255
#
interface
Nve1
source
10.2.2.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

10.3.3.2
#
ospf
1
area
0.0.0.0
network 10.2.2.2
0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
#
sysname Router3
#
bridge-domain
10
vxlan vni 2010
bridge-domain
20
vxlan vni 2020
#
undo
portswitch
255.255.255.0
#
undo
portswitch
255.255.255.0
#
interface
LoopBack1
ip address 10.3.3.2 255.255.255.255
#
interface
Vbdif10
ip address 192.168.10.10
255.255.255.0
#
interface
Vbdif20
ip address 192.168.20.10 255.255.255.0
#
interface
Nve1
source
10.3.3.2
10.1.1.2
10.2.2.2
#
ospf
1
area
0.0.0.0
network 10.3.3.2

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
14.7.3 Example for Dynamically Establishing a VXLAN Tunnel in

BGP EVPN Mode to Implement Communication Between Users
in Different Network Segments
belong to VLAN 10 and VLAN 20, respectively. The enterprise requires that users in the
headquarters and branch can communicate over a VXLAN tunnel dynamically established
using BGP EVPN.
Figure 14-20 Configuring communication between different network segments through a

Layer 3 VXLAN gateway
Cloud
CPE
Loopback 1
10.3.3.2/32
VTEP Router3
19
4
Eth 8.3.
2/2
2.1
68 /1
2.1 /0
2/0 2/2
.2.
6
19 Eth2
/2 4
4
19
1/2
68 /0
Eth 8.3.
2.1
2.1 /0
.2.
2/0 1/2
19 Eth2
6
/0 4
Loopback 1 VTEP VTEP Loopback 1

VXLAN tunnel
10.1.1.2/32 10.2.2.2/32
Router1
Router2
Eth2/0/1 Eth2/0/1
Marketing dept. 1 Marketing dept. 2
PC_1 PC_2
192.168.10.1/24 192.168.20.1/24

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

3. Establish a BGP EVPN peer relationship.
4. Configure an IP address for the source VTEP on Router1 and Router2.
5. Configure a VPN instance on Router1 and Router2.
6. Configure a Layer 3 gateway on Router1 and Router2.
7. Configure Router1, and Router2 to advertise IP prefix routes to the BGP peer.
Procedure
[Router1] ospf
Router2.

0.00% packet loss

[Router1-bd10] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

# Establish a BGP EVPN peer relationship on Router1. The configuration of Router2 is
similar to the configuration of Router1, and is not mentioned here.
[Router1] bgp 100
[Router1-bgp] peer 10.3.3.2 as-number 100
[Router1-bgp] peer 10.3.3.2 connect-interface LoopBack1
[Router1-bgp] l2vpn-family evpn
[Router1-bgp-af-evpn] peer 10.3.3.2 enable
[Router1-bgp-af-evpn] quit
[Router1-bgp] quit
[Router1-Nve1] quit
Step 4 Configure a VPN instance on Router1 and Router2.

[Router1] ip vpn-instance vpn1
[Router1-vpn-instance-vpn1] ipv4-family
[Router1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[Router1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 evpn
[Router1-vpn-instance-vpn1-af-ipv4] quit
[Router1-vpn-instance-vpn1] vxlan vni 5010
[Router1-vpn-instance-vpn1] quit
[Router1-bd10] quit
Step 5 Configure a Layer 3 VXLAN gateway on Router1 and Router2 and bind the VPN instance to
the gateway.
[Router1-Vbdif10] ip binding vpn-instance vpn1
Step 6 Configure Router1, and Router2 to advertise IP prefix routes to the BGP peer.
# Configure Router1. The configurations of Router2 are similar to the configuration of
Router1, and are not mentioned here.
[Router1] bgp 100
[Router1-bgp] ipv4-family vpn-instance vpn1
[Router1-bgp-vpn1] import-route direct
[Router1-bgp-vpn1] advertise l2vpn evpn
[Router1-bgp-vpn1] quit
[Router1-bgp] quit

# After the configuration is complete, run the display vxlan tunnel command on Router1 and
Router2. You can view VXLAN tunnel information. The command output on Router3 is used
as an example.
----------------------------------------------------------------------------

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
4026531842 10.1.1.2 10.2.2.2 up dynamic

----------------------------------------------------------------------------
----End
Configuration Files
#
sysname Router1
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
100:1
evpn
evpn
vxlan vni
5010
#
bridge-domain
10
vxlan vni 2010
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
#

l2
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.1.1.2 255.255.255.255
#
interface
Vbdif10
vpn1
ip address 192.168.10.10
255.255.255.0
#
interface
Nve1
source
10.1.1.2
#
bgp
100

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 10.2.2.2
enable
l2vpn-family
evpn
policy vpn-
target
peer 10.2.2.2
enable
vpn1
import-route
direct
advertise l2vpn
evpn
#
ospf
1
area
0.0.0.0
network 10.1.1.2
0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname Router2
#
ip vpn-instance
vpn1
ipv4-
family
route-distinguisher
100:1
evpn
evpn
vxlan vni
5020
#
bridge-domain
20
vxlan vni 2020
#
interface
Ethernet2/0/0
undo
portswitch

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
255.255.255.0
#

l2
20
bridge-domain 20
#
interface
LoopBack1
ip address 10.2.2.2 255.255.255.255
#
interface
Vbdif20
vpn1
ip address 192.168.20.10
255.255.255.0
#
interface
Nve1
source
10.2.2.2
#
bgp
100
100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 10.1.1.2
enable
l2vpn-family
evpn
policy vpn-
target
peer 10.1.1.2
enable
vpn1
import-route
direct
advertise l2vpn
evpn
#
ospf
1
area
0.0.0.0
network 10.2.2.2
0.0.0.0

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
network 192.168.3.0 0.0.0.255

#
return

#
sysname Router3
#
undo
portswitch
255.255.255.0
#
undo
portswitch
255.255.255.0
#
interface
LoopBack1
ip address 10.3.3.2 255.255.255.255
#
ospf
1
area
0.0.0.0
network 10.3.3.2
0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
14.7.4 Example for Configuring the Headquarters and Branch to

Communicate Using VXLAN over IPSec Tunnels
enterprise. VXLAN tunnels are established to enable communication between the
The enterprise requires that services transmitted over VXLAN tunnels be protected by IPSec
to prevent eavesdropping and tampering. To meet this requirement, VXLAN over IPSec can
be configured to encrypt service packets transmitted between the headquarters and branch.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Figure 14-21 Configuring the headquarters and branch to communicate using VXLAN over
IPSec tunnels
Cloud
CPE
L3 gateway:
VBDIF10:192.168.10.10/24 Loopback 1
VBDIF20:192.168.20.10/24 10.3.3.2/32
VTEP Router3
19
Se /24
Eth .3.
2 .1
19 th2 AN o 2.16 2/0/1
r IP 8.2.2
2/0 2/2 er IP 0/0 4

68
c
VX
19 Eth
/2 4
LA
N
2.1 /0 ve
o
4
19
v
1/2
68 /0
E
2.1
t h
.2.
L
2
68
Se
VX
/
.3.
E
c
1/2
VTEP
Loopback 1 Router1 Router2 VTEP
Loopback 1
10.1.1.2/32 Eth2/0/1 Eth2/0/1 10.2.2.2/32
branch headquarters
PC_1 PC_2
192.168.10.1/24 192.168.20.1/24

3. Configure information for VXLAN tunnel establishment on Router1, Router2, and
Router3.
4. Configure a Layer 3 gateway on Router3.
5. Configure ACLs on Router1, Router2, and Router3 to define the data flows to be
protected by IPSec.
6. Configure an IPSec proposal on Router1, Router2, and Router3 to define the traffic
protection method.
7. Configure an IKE peer on Router1, Router2, and Router3 and define the attributes used
for IKE negotiation.
8. Configure IPSec policies on Router1, Router2, and Router3 and apply the ACLs, IPSec
proposal, and IKE peer to define the data flows to be protected and protection method.
9. Apply the IPSec policy groups to the interfaces on Router1, Router2, and Router3 to
enable the IPSec protection function on the interfaces.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
Procedure
[Router1] ospf
Router3.

0.00% packet loss
Step 2 Configure a service access point on Router1.

# Configure a service access point on Router1. The configuration on Router2 is similar to that
on Router1, and is not mentioned here.
[Router1-bd10] quit
Step 3 Configure information for VXLAN tunnel establishment on Router1, Router2, and Router3.
[Router1-bd10] quit
[Router1-Nve1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
[Router2-bd20] quit
[Router2-Nve1] quit
[Router3-bd10] quit
[Router3-Nve1] quit
[Router3-bd20] quit
[Router3-Nve1] quit
Step 4 Configure a Layer 3 VXLAN gateway on Router3.

Step 5 Configure ACLs on Router1, Router2, and Router3 to define the data flows to be protected by
IPSec.
# Configure an ACL on Router1.
10.3.3.2 0.0.0.0
# Configure an ACL on Router2.

10.3.3.2 0.0.0.0
# Configure two ACLs on Router3.

10.1.1.2 0.0.0.0
10.2.2.2 0.0.0.0
Step 6 Configure an IPSec proposal on Router1, Router2, and Router3.

# Configure an IPSec proposal on Router1.
[Router1] ipsec proposal s1
[Router1-ipsec-proposal-s1] esp authentication-algorithm sha2-256
[Router1-ipsec-proposal-s1] esp encryption-algorithm aes-256
[Router1-ipsec-proposal-s1] quit

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR


Step 7 Create an IKE peer on Router1, Router2, and Router3.

# Configure an IKE proposal on Router1.
# Create an IKE peer on Router1 and configure the pre-shared key and remote ID based on
default settings.
[Router1] ike peer 23
[Router1-ike-peer-23] ike-proposal 1
[Router1-ike-peer-23] pre-shared-key cipher Huawei@123
[Router1-ike-peer-23] remote-address 192.168.2.2
[Router1-ike-peer-23] quit

default settings.

default settings.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR

Step 8 Create IPSec policies on Router1, Router2, and Router3.

# Create an IPSec policy on Router1.
[Router1-ipsec-policy-isakmp-map1-2] ike-peer 23
[Router1-ipsec-policy-isakmp-map1-2] proposal s1

[Router2] ipsec policy user1 2 isakmp
[Router2-ipsec-policy-isakmp-user1-2] ike-peer 24
[Router2-ipsec-policy-isakmp-user1-2] proposal s1
[Router2-ipsec-policy-isakmp-user1-2] security acl 3001
[Router2-ipsec-policy-isakmp-user1-2] quit

[Router3-ipsec-policy-isakmp-map1-2] ike-peer 21
[Router3-ipsec-policy-isakmp-map1-2] proposal s1
[Router3] ipsec policy user1 2 isakmp
[Router3-ipsec-policy-isakmp-user1-2] ike-peer 22
[Router3-ipsec-policy-isakmp-user1-2] proposal s1
[Router3-ipsec-policy-isakmp-user1-2] security acl 3001
[Router3-ipsec-policy-isakmp-user1-2] quit
Step 9 Apply the IPSec policy groups to the interfaces on Router1, Router2, and Router3.
# Apply the IPSec policy to an interface on Router1.
[Router1-Ethernet2/0/0] ipsec policy map1
# Apply the IPSec policy to an interface on Router2.

[Router2-Ethernet2/0/0] ipsec policy user1
# Apply the IPSec policies to the interfaces on Router3.

[Router3-Ethernet2/0/1] ipsec policy map1
[Router3-Ethernet2/0/2] ipsec policy user1

# After the preceding configuration, PC_1 can still ping PC_2 and the data transmitted
between them is encrypted.
# Run the display ike sa command on Router3. You can find the established IKE SAs.
[Router3] display ike sa
------------------------------------------------------------------------------
2189 192.168.2.1:500 RD|A v2:2
2188 192.168.2.1:500 RD|A v2:1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
2183 192.168.3.1:500 RD|A v2:2

2178 192.168.3.1:500 RD|A v2:1
------------------------------------------------------------------------------
Flag Description:
# Run the display vxlan vni and display vxlan tunnel commands on Router1, Router2, and
Router3. You can find that the VNI status is Up and VXLAN tunnel information is displayed.
The command output on Router3 is used as an example.
VNI BD-ID State
-----------------------------------------
2010 10 up
2020 20 up
-----------------------------------------
VNI VRF-ID
-----------------------------------------
-----------------------------------------

----------------------------------------------------------------------------
4026531842 10.3.3.2 10.1.1.2 up static
4026531841 10.3.3.2 10.2.2.2 up static
----------------------------------------------------------------------------
----End
Configuration Files
#
sysname Router1
#
acl number
3000
rule 5 permit ip source 10.1.1.2 0 destination 10.3.3.2 0
#
ipsec proposal
s1
sha2-256
#
ike proposal
1
aes-256
dh
group2
sha2-256
share

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
sha2-256
prf hmac-sha2-256
#
ike peer
23
pre-shared-key cipher %^%#I:TE+I3nvA"|a6GX){:*][TI2!r-EJ&,Ck*+)N{N%^
%#
ike-proposal
1
#
ipsec policy map1 2

isakmp
security acl
3000
ike-peer
23
proposal s1
#
bridge-domain
10
vxlan vni 2010
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
ipsec policy map1
#

l2
10
bridge-domain 10
#
interface
LoopBack1
ip address 10.1.1.2 255.255.255.255
#
interface
Nve1
source
10.1.1.2
10.3.3.2
#
ospf
1
area
0.0.0.0
network 10.1.1.2
0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname Router2
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
acl number
3000
#
ipsec proposal
s1
sha2-256
#
ike proposal
1
aes-256
dh
group2
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer
24
pre-shared-key cipher %^%#%40zAxZ^A~Q}]@EPm$41CLh8A{AdV*Gl6\)G=GiM%^
%#
ike-proposal
1
#
ipsec policy user1 2

isakmp
security acl
3001
ike-peer
24
proposal s1
#
bridge-domain
20
vxlan vni 2020
#
interface
Ethernet2/0/0
undo
portswitch
255.255.255.0
ipsec policy user1
#

l2
20
bridge-domain 20
#
interface
LoopBack1
ip address 10.2.2.2 255.255.255.255

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
interface
Nve1
source
10.2.2.2
10.3.3.2
#
ospf
1
area
0.0.0.0
network 10.2.2.2
0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
#
sysname Router3
#
acl number 3000

acl number 3001
#
ipsec proposal
s1
sha2-256
#
ike proposal
1
aes-256
dh
group2
sha2-256
share
sha2-256
prf hmac-sha2-256
#
ike peer
21
pre-shared-key cipher %^%#T*hBB(Pci9Xmp=+|}(.@/2ki4h1G6N$`@`Ldj`+S%^
%#
ike-proposal
1
remote-address
192.168.2.1
ike peer
22
pre-shared-key cipher %^%#$giTMpBP{PPF^c%!K.^>`!z4Tw>qFX>kX`(\|xhI%^
%#
ike-proposal
1
remote-address
192.168.3.1
#

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
ipsec policy map1 2

isakmp
security acl
3000
ike-peer
21
proposal s1
ipsec policy user1 2
isakmp
security acl
3001
ike-peer
22
proposal s1
#
bridge-domain
10
vxlan vni 2010
bridge-domain
20
vxlan vni 2020
#
interface
Ethernet2/0/1
undo
portswitch
255.255.255.0
ipsec policy
map1
#
interface
Ethernet2/0/2
undo
portswitch
255.255.255.0
ipsec policy user1
#
interface
LoopBack1
ip address 10.3.3.2 255.255.255.255
#
interface
Vbdif10
ip address 192.168.10.10
255.255.255.0
#
interface
Vbdif20
ip address 192.168.20.10 255.255.255.0
#
interface
Nve1
source
10.3.3.2
10.1.1.2
10.2.2.2
#
ospf
1

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
area
0.0.0.0
network 10.3.3.2
0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
14.8 References for VXLANs

The following table lists the references for VXLANs.
RFC 7348 Virtual eXtensible Local Area Network (VXLAN): A

Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks
RFC 7432 BGP MPLS-Based Ethernet VPN
14.9 Further Reading

14.9.1 Server Virtualization
Server virtualization virtualizes one physical server into multiple logical servers, that is virtual
machines (VMs), as shown in Figure 14-22.
Figure 14-22 Basic architecture of server virtualization
VM1 VM2 ... VMn
vSwitch
l VM
Each VM has its own operating system and application software, and has an independent
MAC address and IP address. VMs can run independently.
l vSwitch
A vSwitch provides Layer 2 communication, isolation, and QoS capabilities for VMs.
Server virtualization has the following advantages:

l Effectively improves server utilization.
l Provides services and resources on demand.
l Reduces energy consumption.
l Lowers customers' operations and maintenance (O&M) costs.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
14.9.2 Large Layer 2 Network

Dynamic VM migration becomes a critical issue to meet flexible service changes. Dynamic
VM migration is a process of moving VMs from one physical server to another, while
ensuring normal running of the VMs. End users are unaware of this process, so administrators
can flexibly allocate server resources or maintain and upgrade servers without affecting server
usage by end users. The key of dynamic VM migration is to ensure uninterrupted services
during the migration, so the IP and MAC addresses of VMs must remain unchanged. To meet
this requirement, VM migration must occur within a Layer 2 domain but not across Layer 2
domains, as shown in Figure 14-23.
Figure 14-23 VM migration on a traditional network
Core layer
Layer 2 Layer 2
Aggregation network network
layer
Access layer
Server
vSwitch vSwitch vSwitch vSwitch vSwitch vSwitch

Server VM VM VM VM VM VM VM VM VM VM VM VM
VM
virtualization VM
VM migration allowed
× ×
VM migration not allowed
In the traditional data center network architecture, the Layer 2 network uses redundant
devices and links to improve reliability. This will inevitably result in physical loops during
VM migration.
To prevent broadcast storms caused by physical loops, a loop prevention protocol such as
Spanning Tree Protocol (STP) is required to block redundant links. Due to STP limitations, an
STP-enabled Layer 2 network can contain no more than 50 network nodes, so dynamic VM
migration can only occur in a limited scope.
To enable VM migration in a large scope or across domains, servers involved must be on the
same Layer 2 network, which is called large Layer 2 network.
Generally, the following technologies can be used to provide a large Layer 2 network:
l Network device virtualization
l Transparent Interconnection of Lots of Links (TRILL)
l VXLAN
l Ethernet Virtual Network (EVN)
Network device virtualization, TRILL, and EVN technologies can construct a physical large
Layer 2 network to enlarge the VM migration scope. However, a physical large Layer 2
network requires huge changes to the existing network structure, and still has many
restrictions on the VM migration scope. VXLAN can solve the preceding problems.

Huawei
AR100&AR120&AR150&AR160&AR200&AR1200&AR
A virtual large Layer 2 network can solve the problem and enable VM migration in a larger
scope, as shown in Figure 14-24.
Figure 14-24 VM migration on a large Layer 2 network
Core/
Aggregation Large Layer
layer 2 network
Access layer
Server
vSwitch vSwitch vSwitch vSwitch vSwitch vSwitch

Server VM VM VM VM VM VM VM VM VM VM VM VM
VM
virtualization VM
VM migration allowed

AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003 CLI-based Configuration Guide - VPN

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

AR100, AR120, AR160, AR1200, AR2200, AR3200, and AR3600 V300R003 CLI-based Configuration Guide - VPN

Încărcat de

Drepturi de autor:

Formate disponibile

Huawei

CLI-based Configuration Guide -

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. i

About This Document

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. ii

NOTE Calls attention to important information,

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

[ 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.

Interface Numbering Conventions

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. iii

– When configuring a password, the cipher text is recommended. To ensure device

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. iv

Mappings Between Product Software Versions and NMS

Changes in Issue 01 (2019-03-05)

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. v

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

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. vi

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. vii

3 L2TPv3 Configuration.............................................................................................................. 107

4 GRE Configuration................................................................................................................... 128

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. viii

4.6.6 (Optional) Configuring Ethernet over GRE............................................................................................................ 154

5 DSVPN Configuration............................................................................................................. 228

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. ix

5.5 Default Settings for DSVPN.......................................................................................................................................258

6 IPSec Configuration.................................................................................................................. 378

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. x

6.2.2 IPSec Fundamentals................................................................................................................................................ 392

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xi

6.8.1 Configuring an IPSec Proposal................................................................................................................................450

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xii

6.13 Configuration Examples for IPSec........................................................................................................................... 510

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xiii

7 A2A VPN Configuration.......................................................................................................... 686

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xiv

8 BGP/MPLS IP VPN Configuration........................................................................................ 723

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xv

8.7.5 Configuring Inter-AS VPN Option C (Solution 1)..................................................................................................802

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xvi

8.9.1 Example for Configuring BGP/MPLS IP VPN....................................................................................................... 851

9 MCE IPv6 Configuration........................................................................................................1099

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xvii

10.3 Application Scenarios for EVPN............................................................................................................................1134

11 VLL Configuration................................................................................................................ 1152

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xviii

11.7.5.4 (Optional) Configuring a Revertive Switchover Policy....................................................................................1180

12 PWE3 Configuration............................................................................................................. 1247

Issue 01 (2019-03-05) Copyright © Huawei Technologies Co., Ltd. xix

12.8.1 Configuring a Static PW......................................................................................................................................1263